We recently took to installing our Linux servers from a USB stick.  This is much more efficient than downloading four of five cd iso’s time and again, since Linux distros like Fedora and CentOS keep spawning new releases constantly.  So we just write the rescue cd iso to a usb stick, and proceed with a network install.  This works like a charm, except that for a few times running, after completing the installation, instead of being met with the grub boot menu, we were dropped to the Grub shell brutally.  This had us stmied for a while, until we realized that for some dumb reason or other, Grub insists on recognizing the USB stick we install from as device hd0.  This means that during installation, Grub writes itself a nice config file containing the line

which points to the second drive, in our case our first hard disk, /dev/sda.  After installation - without the USB stick, Grub sees /dev/sda as the first device, hd0, and proceeds to boot the hd1 device, which now is /dev/sdb instead of /dev/sda.  Since the MBR (master boot record) was only written to /dev/sda, there’s no way Grub can boot from /dev/sdb.

In order to solve all this, from within the Grub shell, do the following:

This will instruct Grub to see both the hard disks as hd0 - since in case the first hard disk fails, /dev/sdb is effectively the first device, and install the MBR and Grub on them.  After this, reboot and do not forget to edit your grub.conf.  Change the line that reads

to

This way, Grub will once again boot from its first device as it was meant to.

Installing Grub and the MBR on the second device of your RAID 1 array should be done in any case, even if you don’t experience USB stick troubles.  If you do not, in case of a failure of your first hard disk, your system will be unable to boot until you install the MBR and Grub on your second hard disk.

Anyone who has ever played around with serial console operation, be it over a serial cable or with an IPMI-like serial redirection over LAN, has known the joys of trying to find working alternatives to the function keys.  Since one of the things you’ll be likely to do with a serial console is to enter the BIOS setup, and entering the bios setup usually requires the use of F1, F2 or F10, this is a bit of a poser.

Luckily for us, Dell in it’s neverending wisdom has seen fit to display all necessary escape sequences for its Serial BIOS at boot time.  The only hitch is that this screen flashes by so quickly that it’s impossible to read unless you’ve been gifted with x-ray eyes.  Armed with the Print-Screen key and Photoshop, we did some twenty reboots of the server and were able to decipher the following shortcuts:

Dell Serial Bios keyboard shortcuts

Note: Use your keypad for the <ESC>n sequences!

Authenticating with SSH without a password

Are you just as sick and tired as we are of eternally typing your password when transfering files between servers by using rsync or scp?  Or do you want to run automated tasks that copy files between servers?  Setting up public key authentication between *NIX servers is easy as can be. Try the following steps:

Generate your key:

While an empty passphrase is not secure, it’ll avoid certainly make life easier since the whole point is to avoid having to type in passwords.  ssh-keygen generates two files, id_rsa, which is your private key and which should be kept secure, and id_rsa.pub, the public key you can distribute to servers you want to access.  File permissions for the private key should be 0600, and 0644 for the public key.

Append your public key to the target server’s /.ssh/authorized_keys file:

That’s it!  You should now be able to move files without entering your password each and every time.

Note that the solution above is just a quick and dirty one, and it’s not recommended to use pubkey authentication without a passphrase, or to set up a root to root access between servers.  If you chose to use a passphrase, there’s still a way to alleviate the pain of entering your password every time.  Start a session with ssh-agent:

Enter your passphase when prompted, and you’ll be able to ssh to target servers without having to enter your password.

Limiting access to a server to certain clients

As an added precaution, you can limit access to a server by adding a ‘from’ statement to the authorized_keys file.  The from statement can contain multiple addresses separated by commas, and wildcard characters.