Debian

Nexenta (also called GNU/OpenSolaris) is a blend of OpenSolaris, GNU, and Debian (Ubuntu, specifically).  It’s pretty cool, actually—blending the OpenSolaris kernel with Ubuntu userland binaries to create something that’s not quite Solaris and not quite Linux, but has some of the values of both.  For those of you interested in running it on VMware ESX Server, I’m happy to report that it does work just fine.

To install Nexenta as a VM in ESX, I used the following settings:

• 512 MB of RAM
• 4GB virtual disk (pre-allocated); obviously, you would want more space if wanted to do anything useful with Nexenta
• LSI Logic SCSI controller
• “Flexible” network adapter

The installation went very smoothly and very quickly (quicker than Solaris 10 and a couple of the other Linux distributions I’ve tried on ESX).  The system came up very smoothly and was immediately accessible across the network.  I didn’t try anything useful or meaningful with it; it is an alpha version, after all.

It’s worth keeping an eye on, at least.  I’ll be interested to see how it develops.

I had a situation today where a customer forgot the root password to a Debian GNU/Linux 3.1 system in their office.  That left it up to me to try to find a way to get into the system.  Here’s how I managed to gain access.

(Note: As far as I am aware, NONE of the information I’m going to list in this article will work across the network; you MUST have physical access to the server.  Therefore, I’m not too terribly worried about “making it easier for the hackers”.  If you don’t have physical security, then no amount of electronic security is going to help you!)

Here’s how it works:

1. With physical console access, reboot the server.
2. When the Grub menu comes up, press “e” to edit the menu selections.
3. Use the arrow keys to select the Kernel line, then press “e” again.
4. Add “single init=/bin/bash” to the end of the existing line.
5. Press “b” to boot the modified line.
6. The system will boot up into single-user mode.  Unfortunately, the root filesystem will be mounted read-only, so you’ll need to remount it using “mount -o remount,rw /”.
7. Use the “passwd” command to change the password for root to whatever you like.
8. Reboot the computer again and log in as root with the new password.

There are ways to protect against even this (a BIOS-based power-on password, or passwords in Grub to prevent casual editing of the boot configuration), and those steps may be necessary depending upon the other aspects of physical security.  If this system is out where people can get to it, then I’d highly recommend taking these additional steps to secure the server.

Please note that I’ve only done this on Debian GNU/Linux 3.1, but I would be reasonably confident that the steps will work elsewhere as well.

As I’ve mentioned in a couple of previous posts, I have several servers running Red Hat Linux 9.0 that I am looking to upgrade to a newer distribution.  I’ve tried a couple of recent versions of CentOS (a clone version of Red Hat Enterprise Linux), but ran into problems with ntpd (I may have finally resolved those).  I’d heard good things about Debian GNU/Linux, so I decided to give that a try as well.

Prior experience with Ubuntu (as well as some time with Kubuntu) led me to believe that Debian would be equally polished.  So, I downloaded two ISO’s for Debian 3.1 (“Sarge”), the latest stable release.  Information I’d gained from some online research indicated by this release included a 2.6.8 version of the kernel, but upon installation I found I was running a patched 2.4 version instead.  After a couple of attempts to upgrade the kernel via apt-get, I finally managed to locate an appropriate package name in the stable distribution and installed it.

Unfortunately, the 2.6.8 kernel cause the system to fail to boot, listing numerous segmentation faults and finally just halting partway into the boot process.  I was extremely disappointed—after having spent that time downloading the software and then installing it, it was now completely unusable.

I’m sure that Debian fans will point out that I surely did something incorrect and things normally don’t happen that way.  Perhaps that is true; I will certainly be the first to admit that I may have done something incorrectly while using apt-get to upgrade the kernel.  I would be nice to know exactly what it was that went wrong, though.

In the meantime, I’m going to shelve Debian GNU/Linux as a possible replacement OS and continue searching.  At this point, OpenBSD is starting to look really good…