Guides

CentOS is the community based clone of Red Hat Enterprise Linux.  Its stability and long release cycle make it perfect for building a home server or MythTV appliance.  Let's walk through the process of installing a stripped down but very functional version of CentOS 5.1 which can be the basis for your next Linux project.

Digg It!

History

History

Starting in March of 2000, Red Hat began rolling "enterprise" versions of their popular Linux distribution in an effort to increase income.  The idea was that individual users would continue using their standard Red Hat Linux product, but those wanting increased stability and enterprise centric features should transition to their new premium offering for a price.  Later in 2003, Red Hat stopped active support for their standard Red Hat Linux distro and instead turned it's attention toward their enterprise market.  Red Hat choose to give the project over to the community and the Fedora Project was born.  Even though the project was to be a "community" based project, Red Hat was still actively involved in its development.  They effectively used the Fedora Project as a breeding ground for their enterprise product.  It was a good match as those that wanted the bleeding edge drivers and features could use Fedora, and those that favored stability and support could purchase Red Hat Enterprise Linux (RHEL).

Because RHEL is based on open-source software, it is mandated that the source code be made available for review / download.  This is where the CentOS project comes in.  CentOS takes these source files, and compiles them into RPM packages exactly like Red Hat does when it creates it's package system.  The end result is any given RHEL or CentOS package is binary compatible.  The only things which are modified are Red Hat logos, and trademarks which are exchanged for CentOS logos.  In fact, CentOS never mentions "Red Hat" by name on its website, but instead refers to them as "the upstream provider".

What does one get for all this trouble?  A duplicate of RHEL without the costly support structure.  The user also gets a perfect platform for creating a home NAS server, firewall, or MythTV appliance.  Unlike the Fedora Project which releases a major version every 6 months, RHEL and CentOS are on a 2 year release cycle with several point releases in between.  This makes it much easier for a system administrator to stay current on bug fixes without requiring frequent complete system rebuilds.

Beginning The Install

Beginning The Install

To begin, grab the latest copy of CentOS 5.  As of the release of this guide, the latest version is 5.1, but this guide should be valid for subsequent point releases.  There are a few choices to make up front.  There are either 32-bit (i386) or 64-bit (x86_64) binary packages.  For the most part, both are equivalent in terms of speed and compatibility, but I still tend to use the 32-bit flavor out of old habit.  Visually, the install procedure is identical.

Next up is selecting the appropriate install media.  Either 6 CDs or a single DVD are available to choose from.  Again, I find the DVD to be simpler to keep track of, but if your hardware doesn't have a DVD drive, then at least there is a backup plan offered.  After selecting a reasonably close download mirror, there is yet another decision to be made: direct download or torrent.  From past experience, torrent downloads move much quicker, but this will be dependent on your ISP and their P2P filtering strategy.

Once the ISO has been downloaded, burn it to disk, and boot the disk in your chosen hardware.  Ensure that the hardware has at least 512 MB of RAM for a graphical based install (which we will be covering).  It is possible to install with less RAM, but it is advised to do a text based install instead.

Install Boot Option Screen

Upon booting from the install media, the user will be presented with the text based prompt shown above.  To continue with a graphical based install, either press <enter> or simply wait for the timeout.  If the user wishes to use the text mode install, type "linux text" and press <enter>.  This disk can also be used as a rescue disk buy typing "linux rescue" and <enter>.

Install Media Test

As we all know, downloads can sometimes be corrupted or media scratched, so the install process offers a feature to test the media prior to the install.  If it passes the test, the user can be sure that any install failure is probably not due to a corrupt media file.

GUI Install Splash Screen

If all goes well and your hardware is supported, you will be executing the graphical installer and shown the CentOS 5 install splash screen above.  If for some reason the graphical installer failed, all is not lost.  Usually an error is shown which can be searched on via Google.  If that fails then there is always the text mode install to fall back on.

Locale And Drive Partitioning

Locale And Drive Partitioning

Install Language Selection	Keyboard Selection

The first part of the install defines your language and keyboard configuration as shown above.

New Hard Drive Warning

If the hard drive is completely void of partition table information, the user will be prompted to verify that it is OK to initialize the drive.  The install writers tend to lean on the side of caution whenever there may be doubt as to the next step.  Click "Yes" to continue.

Drive Partition Layout

I don't know about you, but I don't like things happening without my knowledge, so I always select "Create custom layout" from the drop down list.  This gives the user complete control over how the disk will be partitioned.

Partition Editor

Partitioning schemes for Linux are as varied as the users themselves.   Dual-booting, RAID, or LVM present their own challenges.  For the sake of simplicity, we will assume a clean single drive system.  As can be seen above, this install was done within VMware where 2 GB of drive space was provided.  Obviously, this is quite small by today's standards, but it will serve the purpose of this guide.

Add New Partition

Adding a partition is as simple as highlighting the free space on the drive and clicking the "New" button.  The install routine will prompt for the mount point, file system type, and size among other things.  In this case, we want to define a single root partition, so we configure the dialog as shown.  Note that although the size has "100" MB in the field, enabling "Fill to maximum allowable size" will tell it to fill the whole drive.

Partition Added

Clicking "OK" will show the above screen with "/" or root partition consuming the entire drive.  Also, note how drives are denoted in Linux.  If you are familiar with Windows, then you are probably used to thinking in terms of drive C or drive D.  As with other things in Linux, it gives the user a bit more info regarding what is happening behind the scenes.  In our case, "/dev/sda" is our first SATA or SCSI hard drive.  If we had a "/dev/sdb" in the list then that would be the second SATA or SCSI hard drive.  Partitions are simply an extension of this nomenclature.  For instance, the first primary partition on the first drive is labeled "/dev/sda1".  Due to historical reasons, IDE drives are denoted as "/dev/hda" or "/dev/hdb" along with their partitions such as "/dev/hdb2".

Most Linux users will want to add a swap partition to this configuration.  Just like Windows, Linux can make use of a swap partition to hold data which has been swapped out of RAM.  It is possible to make Linux use a file based swap like Windows.  However, Linux prefers to have the swap occupy its own partition as it can be better optimized.  Choosing the size of the swap space is also a bit of an art form, where there are many opinions.  If you plan to perform a suspend to disk on this PC, then you will need to ensure the swap is at least as big as the system RAM.

Swap Partition Warning

I have specifically decided not to create a swap partition (more on this in the CentOS 5.1: Flashed Guide ), so the installer is again warning me of my impending doom.  This is handy for the novice user, but I choose to ignore it.

Boot Loader, Network, Time Zone, And Root Password

Boot Loader, Network, Time Zone, And Root Password

Boot Loader Configuration

Because we are using a single drive system which will only be running CentOS, the boot loader configuration is relatively simple.  The boot loader will be installed in the Master Boot Record on the first drive and the CentOS install found on /dev/sda1 will be the default OS to boot.

Network Configuration

With this hardware, there is only a single network card which will be configured automatically via a DHCP server on the network, so the network setup is fairly simple as well.  Because I haven't switched over to IPv6, I have disabled IPv6 under the "Edit" button.  This isn't necessary, but it does release some resources.  Because we build HTPCs around here, we are going to give this a hostname of "HTPC".

Timezone Selection

Next up is the timezone selection.  Simply pick a city in your timezone which is closest to you.  Selecting "System clock uses UTC" will enable your PC to seamlessly deal with daylight savings time.  Enabling this feature on a dual-boot PC with Windows will cause the clock to display the wrong time.

Root Password

Here is the most important password you will create.  It is the root or administrative password for the system.  Whoever can provide this password will have complete access to the system.  Because of this, it is wise to not only pick a strong password, but one which is easily remembered without requiring sticky notes.

Package Selection

Package Selection And Install

Here we will see how flexible the CentOS install routine can be in regards to package selection.  For our project, we are going for a slim, fast, and functional install, so we will be disabling several packages which are installed by default.  I have found that after an install is completed, it is much easier to add packages to a minimalist setup than it is to rip packages out of a bloated setup.

General Task Selection

This screen allows the user to choose what general categories to install.  In our case, disable everything in the upper list.  CentOS comes with a standard set of software by default and we want to hand customize this in the following screen, so select the "Customize now" option at the bottom.  Ensure that the PC has an Internet connection and check the "Packages from CentOS Extras" option.

Extras Network Configuration

The install routine will now probe for the network card to determine the required driver.  It needs a network connection as it will pull the CentOS Extras packages over the Internet.

Base Package Selection

There are several packages which are enabled by default.  For our purposes, only enable "Base" and "X Window System" under "Base System".  Make sure to select each category on the left and disable any other package groups on the right.

Xfce Package Selection

Because using a GUI is a little more handy than fiddling with the console, enable "XFCE-4.4" under the "CentOS Extras" category.  Gnome and KDE are the GUI managers that most users typically associate with Linux.  As of late, I have found that they both have increasingly traded speed and a small footprint for candy graphics and dancing icons.  Xfce aims to keep the functionality bar high while not requiring a Cray Supercomputer to keep things moving.

To slim this package down a bit, ensure that "XFCE-4.4" is highlighted and click "Optional Packages".

Xfce Specific Package Selection

Scroll through the list and disable everything.  Upon closing the package list, ensure the installer says "0 of 36 optional packages selected" for "XFCE-4.4".

Checking Package Dependencies	Ready To Install

CentOS is now analyzing the selected package choices and determining if additional packages need to be added to satisfy any dependency issues.  Once that is complete, CentOS will announce that it is in fact ready to go ahead with the install.  From this point on, the hard drive will be modified.

Formatting Root Partition	Package Installation

First, the hard drive will be partitioned and formatted to match the user's requests.  Next, all the selected packages and their dependencies will be installed onto the hard drive.

Post Install Config	Install Complete

Lastly, it will write several configuration files to the hard drive and prompt the user to reboot.  Next up, CentOS nirvana.

Initial Boot

Initial Boot

Boot Manager	GUI Boot Progress

Upon reboot, the boot manager, GRUB, will briefly display the installed CentOS kernel version.  After a few items scroll by in text mode, the boot sequence will switch to a GUI where it will outline the remainder of the start up sequence.

First Boot Welcome Screen

Now the user is presented with the first boot welcome screen.  This is a short setup wizard which is run to customize the CentOS install further.

Firewall Config	Firewall Warning

Because this PC will be sitting behind a router/firewall and will not be receiving any direct Internet traffic it is safe to disable the firewall.  Of course, the CentOS install gurus will question your sanity and give you an option to change your mind.

SELinux Config	SELinux Warning

SELinux is a great application which gives the administrator exceptional control over what users and programs are allowed to do.  In this case, it is a nuisance, so it has been disabled.

Date And Time Config

Here, the user can indicate the local time and date.  There is also the option to use the network time protocol to keep the PC in sync.  Be sure to drop down the advanced options and disable "Use Local Time Source" as most people don't have an atomic clock attached to their PC.

Create Non-Root User

Because it is not a good habit to directly log in with your root account, CentOS prompts the user to create a standard user account.  Again, ensure to use a reasonably secure password.

Sound Card Config	Sound Card Test

CentOS will now attempt to detect the sound card.  If it finds one, play the sample sound to verify its selection.

Additional CDs	Reboot Warning

The installer now allows the user to install additional software.  In this case, it is not required.  Because of our changes to the SELinux sub-system, the PC must now be rebooted.

Xfce And Updates

Xfce And Updates

Initial Login

After the system restarts, CentOS will now show its login screen.

Session Selection	Default Session Verification

Before logging in, click the "Session" option at the bottom and choose "XFce 4" from the session list.  Once "Change Session" is pressed, CentOS will want to know if this session should be made the default.  Click "Make Default" to lock in Xfce.

Xfce Startup Splash Screen	Xfce Desktop

Once the user has logged in using the non-root username and password they created during the initial boot set up, the Xfce splash screen will start and shortly thereafter the Xfce desktop will be displayed.

Package Update Icon	Root Password Prompt

If an active internet connection is available, the package updater icon will be shown in the system tray in the upper right corner of the screen.  Right clicking on this icon and selecting "View Updates..." will prompt the user for the root password.  Any time a non-root user tries to run an administrative application, CentOS will prompt for the root password.

Retrieving Update Information	Updated Package List

Once the application is launched, it will search for available update packages.  By default, all updates will be selected.  Accept this list by clicking "Apply updates".

Downloading Packages	CentOS Repository Key

Now, Package Updater will download the packages.  Once that is completed, it will prompt the user to import the requested package key.  Package repositories can choose to sign their packages with a special key which authenticates their validity.  In this case, the software wants the user to import the key used by CentOS's repositories.  Click "Import key" to continue.

Updating Software	Reboot Request

With the key imported, the updated packages can now be installed.  Because one of the updated packages was a new kernel, the updater asks if the user would like to reboot now.  Choose "Reboot now".

New Kernel

Now that the new kernel is installed, GRUB will report a newer version.  Don't be alarmed if your version is different as new kernels are released regularly.

Conclusion

Conclusion

At this point, the PC has a minimalistic but functional install of CentOS which occupies only 1.3GB on the hard drive.  Where things go from here is up to the user.  In a following guide, we will further refine and optimize this install.  We will also explore some of the methods for its personalization.  For now, become familiar with the OS and GUI and how it operates.

If you have any questions or comments regarding your install,  post them in our forums by following the "Comments" link below.  Also, check out our SSH guide as well as our VNC guide for alternate ways to connect to your CentOS PC.  Both provide various ways to expand the Linux experience.

There comes a time in every Linux user's life where it would be quite handy to administer the box remotely. Whether it is to tweak some Linux settings from a Windows box or to fiddle with the Linux server in the basement from the comfort of your desktop system upstairs, SSH (Secure SHell) can make your dreams come true. Today, we are going to talk about some of the tricks this protocol can do and how to best secure it. Click on for more.

A Brief History

A Brief History

Back in the day, if you wanted to remotely connect to a *nix computer you used a protocol called "telnet".  It provided a command prompt after the user properly authenticated with a login and password.  However, all the traffic between the server and remote client was sent unencrypted including the login name and password.  Fortunately, those were the days when people could be trusted, and networks were rarely attacked.  As people with the capability to "sniff" network traffic became more common, the need to keep such information from them increased.  Thus, from this need the SSH protocol was born.  SSH still provides a remote command prompt, but it encrypts everything including the initial login and password exchange.  A third party can capture all the session packets and still not be able to determine a user's credentials.

Now, I can hear you saying, "But John, why would I deploy this in my own home where I'm the only user and I have a firewall to keep the riff-raff out?"  Actually, most Linux distributions come with the SSH service already configured and running on the server, so that takes care of half of the "deploy" part.  Second, there are some rather cool tricks that can be done with SSH once a connection has been established, but more on that later.

Simple Install And Configuration

Simple Install And Configuration

Let's start off with a common scenario.  A Linux distribution (CentOS/Fedora in this case) was just installed on a PC, but it's in a rather unhandy location of the house and the user would rather sit at their Windows PC upstairs to finish tweaking the install.  Before moving upstairs to the easy chair, do a couple quick checks on the Linux box.  As root, run:

netstat -n -a -A inet

Look for the line:

tcp        0      0 0.0.0.0:22         0.0.0.0:*        LISTEN

This means that the SSH service is up and running and listening for a connection.  If nothing is listening on port 22, then perhaps the service just needs to be started:

/etc/init.d/sshd start

After that, re-run the "netstat" command above and verify the above response.  Now it's time to determine what IP address the server has acquired by running:

ifconfig

There will be a listing of various network devices.  If your network card has been configured properly, "eth0" should be one of those listed.  Within that block of info should be a string like:

inet addr:192.168.10.1

In your case, the IP will be a different number, but in any case, write that number down as that's what will be needed to connect remotely.  If there are multiple "eth" devices, then you have a more complicated setup.  But I'm guessing if you knew enough to get that working, then you are sharp enough to figure out which IP to use.

Now we are ready to move to the remote PC to set up the client side of the connection.  As mentioned above, in this case the client PC will be Windows based, so we need to find a suitable SSH client.  While there are several commercial applications available, I have used PuTTY for some time now.  Why?  Because it is free, fast, and has all the functionality that I require.  So, go over to the download page and grab putty.exe.  There is no install as everything is contained within that executable.  Go ahead and launch PuTTY.  The first screen you come to will ask for a "Host Name".  Just type in the Linux server's IP that was found above.  Leave the port at "22" and leave "SSH" selected as the connection type and click "Open".  PuTTY will likely show a "Security Alert" stating the server's RSA2 key fingerprint and asking if you want to trust this server.  Go ahead and click "Yes" and there will be a login prompt presented.  Enter your user name and password.  Once the credentials are accepted, a shell prompt is provided and you are good to go.  Everything that is typed is encrypted, and the user has the luxury of not having to be in front of the Linux box. 

Pump Up The Security

Pump Up The Security 

Assume that the user is no longer within their own network, but instead has their laptop at work or at a friend's house.  For some reason they suddenly have a need to connect to their home server.  No problem.  Just configure the router/firewall to forward TCP port 22 traffic to the Linux server.  Next, you need to determine what your public IP address is on the router/firewall, so you know what IP to connect to.  Some ISPs change the IPs regularly, so it may be handy to utilize the services of DDNS which makes life easier.  Now, it is possible to access your Linux server from anywhere on the planet.  This can be pretty useful at times.  It can also be very useful for those looking to crack a server for their own purposes, so let's harden this up a bit.

Some Linux distributions come pre-configured to allow root to login remotely over SSH.  Why is this bad you ask?  Usually a potential cracker has two pieces of information that they need to acquire a SSH connection; login name and password.  In the case of the root account, they already know the name as it is universal.  They only need to guess at the password and they are in.  I have seen hundreds of attempts in a day to get in via this method.  There are software programs which are designed to do dictionary attacks on the root account via SSH.  Eventually, if your password is weak enough, they will get in.  Let's close this hole by disabling the SSH root login.

First, make sure you have remembered to create a non-root user.  If you haven't, then do that now (without the brackets):

adduser <username>
passwd <username>

Start up a new PuTTY SSH connection and use the new user credentials to login verifying that everything works as advertised.  It's quite simple to get root privileges from this user account by typing:

su -

You will be asked for the root password and then given a root shell prompt.  Now, that you can get in as a non-root user, let's lock down the SSH service to deny root access.

nano -w /etc/ssh/sshd_config

Scroll down until you see the line:

#PermitRootLogin yes

Remove the "#" to uncomment it and change the "yes" to a "no".  Save the changes by pressing Control-x, "y" to confirm the changes, and <enter> to confirm the file name.  Now restart the SSH service by typing:

/etc/init.d/sshd restart

At this point, verify that it is still possible to login giving the non-root user credentials, and that giving root credentials fails.  Congratulations, you are now slightly more secure.  Any hopeful cracker now has to determine your non-root user name and its password to successfully login.  A daunting task, but still possible if given enough time.  What else can be done?  Well, it is possible to run the SSH service on a non-standard port other than 22.  Re-open the sshd_config file using the command above and uncomment and change the following to a different port number:

#Port 22

Save the file and restart the service and it should now be listening on the new port.  Remember to change to the same port on the client side or you won't connect.  Also, the route/firewall forwarding rules will need to be updated to match this change.  This is a nice "security through obscurity" trick, but anyone with a port scanner can make short work of this.  What we need is a way to automatically authenticate our identity, but at the same time use ridiculously long keys that we don't have to remember.

Break Out The Keys

Break Out The Keys

What we are describing is public/private key authentication.  It is a way of distributing a "public" key to a SSH server you wish to connect and a "private" key which is kept secret on the client PC.  During the login process, both keys are compared to determine if they are correct.  If they are OK, then the server allows the client to connect.  Once this is configured and working, the old method of user names and passwords can be disabled forever blocking those looking to dictionary guess their way into your server.

First, download the puttygen.exe program which is used to create the key pair.  Like the main PuTTY application, this does not need to be installed.  After launching the PuTTY key generator, click on the "Generate" button.  The application needs a source of "random" data to ensure that the keys are strong.  There are several ways to go about this, but in this case it uses input from your mouse, so move the mouse pointer around the window until the progress bar fills completely.  Once that is complete, it will run the progress bar one more time while it completes the key creation process.

Once the keys are created, launch PuTTY, connect to your Linux server as the non-root user, and type the following commands:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano -w ~/.ssh/authorized_keys

At this point, copy/paste the contents of the "Public key for pasting into OpenSSH authorized_keys file" window in the PuTTY key gen software into the authorized_keys file that is open in the PuTTY client.  This should be a bunch of random characters which starts with "ssh-rsa".  In the PuTTY client, save the file and exit the nano editor.  In the PuTTY key gen, press the "Save private key" button and save this key somewhere safe.  Remember, this is your private key which grants you access to your server.  Whoever holds it can get in.

Close out the PuTTY key generator and launch a new instance of PuTTY and fill in the appropriate IP address and port number for the Linux server.  On the left in the "Category" tree menu, expand "Connection" then "SSH" and finally select "Auth".  Click the "Browse..." button and find the private key file that was just saved.  Click "Open" and type in the name of the non-root user when prompted.  If all went well, it should not ask for a password, but instead exchange keys and automatically log you in.

Once things are connecting smoothly by using keys, let's configure the SSH service to refuse password authentication.

nano -w /etc/ssh/sshd_config

Scroll down until you find "PasswordAuthentication yes" and change that to "no".  Exit nano and save the file.  Restart the SSH service by running:

/etc/init.d/sshd restart

The SSH service should now refuse any password style authentication, but continue to accept key authentication.  At this point, SSH is locked down pretty tight.  There are other things which can increase security further, but at the expense of increased aggravation for the end user.

Tunnel Me This

Tunnel Me This

So, what tricks can this SSH protocol do for us?  Let's consider this scenario:  Your Linux server has been configured as a MythTV appliance complete with a web interface which can be used to schedule recordings amongst other things.  You've gone to work only to discover that you forgot to schedule a show which will air while you are still at work.  You don't want to forward web connections on your router/firewall to your MythTV server because then anyone could change your recordings.  However, this kind of remote access would be extremely handy at times like this.  What is one to do?  SSH tunnels to the rescue!

A SSH tunnel is a way of routing traffic through the encrypted connection between your PuTTY client and the remote Linux server.  To configure a tunnel to handle the proposed scenario, launch PuTTY and fill in the IP and port number.  On the left, expand "Connection" then "SSH" and finally select "Tunnels".  Type "80" in the "Source port" field, "localhost:80" in the "Destination" field, and ensure that "Local" and "Auto" are selected.  Now click the "Add" button to lock in these options.  Port 80 is the port which is used to access web content (HTTP), so this in effect sets up a tunnel from port 80 on the client PC which will come out at port 80 on the Linux server.  Click "Open" and proceed to log into the Linux server.  Launch a web browser and type "localhost" into the web page address field.  If all went well, it should display the web page from the Linux server.  Remember, this will only work while PuTTY is connected to the Linux server.  If PuTTY is closed, then the SSH tunnel is broken.

SSH tunneling can be used for almost any application which communicates via the network.  Some of the more popular choices are VNC, MySQL database administration, NFS shares, Samba Windows shares, and POP3/IMAP/SMTP email traffic to name a few.  In fact, the remote destination doesn't need to be the Linux server at all.  In a pinch, it can be used to remotely administer your home router/firewall.  Just change the ports to be the same as those used to administer the router/firewall locally and change the destination to be the internal IP of the router/firewall.  A single SSH session can support many simultaneous tunnels.  In fact, it is mainly limited to the bandwidth of the connection between the client and the server.  This can be improved upon by enabling SSH compression under "Connection" and "SSH".  Some CPU power is used on both ends, but it can improve transfer rates.

SCP/FTP To The Rescue

SCP/FTP To The Rescue

One last capability of the SSH protocol is to transfer files between the connected computers.  There are two methods to accomplish this: SCP and SFTP.  SCP is a encrypted version of the insecure *NIX remote copy command "rcp".  As you might guess, SFTP is an encrypted FTP session.  Both transfer files, but SCP seems to transfer faster over a given network link due to its smaller protocol overhead, while SFTP supports all of the typical directory listing commands.  Some SCP clients get around this limitation by gathering the extra information via a shell account.

The remote Linux server should be configured to accept either transfer protocol by default, so we only need to find a Windows client.  Going on the fast, functional, and free method of software selection, we come across WinSCP.  Download the latest version and install it.  When you launch WinSCP, it will prompt for an IP, username, password, and port.  If you are using private/public keys for authentication in PuTTY, then simply point WinSCP to the same private key file.  WinSCP uses PuTTY in the background to perform encryption and authentication, so both packages naturally work well together.

Once you have connected using WinSCP, it will present a directory listing of the remote folder.  Moving around the folders is similar to navigating in Windows Explorer.  WinSCP also supports full drag and drop features.  Keep in mind that you have logged in with your non-root user account meaning that you will be limited to what that user is allowed to view, copy, and write.

Conclusion

Conclusion

I hope that this has provided a good overview of all the features and benefits of the SSH protocol.  Its various levels of security give the user the flexibility to choose the correct balance of user convenience and piece of mind for any application.  SSH tunnels provide a mechanism for a poor man's VPN access enabling functionality which is usually only available locally.  The SCP & SFTP protocols give a handy means for transferring files without the complicated configuration or security issues of the more popular FTP, NFS, or Samba protocols.

Perhaps you've used SSH in another way than what is mentioned above.  If so, give us shout in the forums.  Maybe you are having issues with an aspect of its configuration.  Your questions are of course welcome as well.

Buying a graphics card for video playback only 

Buying anything below the midrange line of the current AMD/ATI and NVIDIA GPUs is asking for trouble and certainly shutting you out of the best handling of high definition, as the low-end GPUs are underpowered for handling high quality 1080i deinterlacing and decoding HD DVD or Blu-ray content. This means you want to look at the NVIDIA GeForce 8600GT or GTS and the AMD/ATI Radeon HD 2600 Pro or XT, both companies have vendors that offer passively or quietly cooled models. These cards range from $90 to $150. Vendors that offer passive models include MSI, Gigabyte, and ASUS.

Buying a graphics card for gaming and video playback

Just a few short months ago, buying a gaming card meant you missed out on all the video features the mid-ranged cards offered. Two launches in the last month have changed this playing field dramatically.

First out of the gate was Nvidia's launch of the 8800GT. This is a new GPU with the 3D Horespower of the GeForce 8800 series for HD resolution gaming and has the new VP2 video processir silicon the GeFroce 8600 series first introduced. The price point for the 8800GT was meant to be below $250 but due to demand, you can expect to pay $275 plus until the supply catches up. The VP2 hardware decodes h.264 and accelerates VC-1.

Secondly, AMD recently released the 3850 and 3870 which offers very similar 3D horesepower at a competitive price point to the 8800GT. The 3850 has a MSRP of $179 and the 3870 has a MSRP of $219. Both models have ATI's UVD and as such hardware decodes H.264 and VC-1. Once again, demand has outstripped supply and we are getting gouged. Though the 3850's are much closer to MSRP and more frequently in stock.

Cooling

The theme you may be sensing here is passive, and yes here too passive tends to be desirable. Video cards can get hot, and with the motherboard also being passive, you may want to consider one of the large slow moving heatsink and fan options which exhaust out the back in a double-wide slot configuration, these can be found on some specialty models from vendors such as ASUS and HiS.

Driver Notes

An issue for NVIDIA cards to keep in mind is that currently only acceleration of the HD formats is enabled in Windows XP, any form of advanced post-processing such as proper 1080i deinterlacing and noise reduction are not working as of this writing in the Windows XP display drivers. Windows Vista users won’t have any problems, and really if you’re building a new High Definition ready HTPC, Windows Vista Home Premium or Ultimate should be your OS of choice anyway. AMD/ATI Radeon cards don’t have any such limitations in Windows XP.

This is the first article in a series as Missing Remote looks at getting the next generation HD optical formats into your HTPC. In this initial installment I discuss adding HD DVD playback to a typical Home Theater PC. While I use an HD DVD drive this article also applies to those wanting to add Blu-ray support. 

Digg It!