DSL Hard Drive Tweaks

This is an abridged version of what I’ve intended to post about setting up DSL on a hard drive. The same applies to hard drive/Debian-like install of Knoppix. My focus, though, is primarily on DSL because Knoppix installs as Debian and leverages Debian’s packaging.

DSL really isn’t intended for hard drive install even though it offers such an option. It’s a portable operating system that functions much better (imo) when used as intended — off the live CD, or off a USB pendrive or via frugal install.This is true not only with respect to its normal base operation but, perhaps more importantly, when it comes to available extensions.

The question has arisen several times about reverting DSL into a Debian-like system and taking advantage of dpkg and apt-get. Users must understand that these tools are from an era of Debian which even Debian no longer supports. This means using dpkg doesn’t get you to Debian stable or testing — nearly everything in the system would require updating. It also could very well break (my money is that it would result in an unusable system). If you want Debian, use Debian. If you want a tiny system with Debian Sid or Lenny, do a net install and only install the packages you want.

If you’re satisfied with things as they are on the live CD, it can function reasonably well on a hard drive install. There are a few things to remember about MyDSL extensions. The .dsl extensions are probably best for standard hard drive installs because they’re standard tarballs that untar across the traditional directory structure. The .tar.gz and UCI extensions will go in /opt. The former are fine for hard drive installs but you have to pay attention to PATH issues. Sometimes a symlink for an executable in /opt/bin is adequate; sometimes you’ll choose to just edit a menu entry (I remove the INCLUDE tag for the mydsl menu entry on hard drive installs because it’s much easier to manage without that; reboot a few times and you’ll understand). UCI extensions require that they be mounted, copied over to a temporary directory, unmounted, and then copied back to the directory name where they belong. In some cases, it may be more desirable to compile these from source yourself and just put them in a normal directory structure. Other things found as UCIs may be easier to install to /opt or even /usr/local on your own (such as Open Office and Firefox).

There are a few things I think are necessary to make DSL work better as a hard drive installed operating system. Some of these are security-related. What is acceptable for a live CD isn’t always a good idea everywhere else.

SUDO SHOULDN’T BE SYSTEM-WIDE EASY ROOT
First, I change sudo privileges. As a live CD, user dsl doesn’t need to use passwords. On a hard drive install, though, it’s a very good idea to require use of passwords: for logging in as well as for doing things across the system. The first thing to do is
export EDITOR=name-of-editor –> such as export EDITOR=vi

DSL comes with beaver and nano. Use whatever editor you feel comfortable using. This export command will allow you to use visudo to change things around in sudoers. Do not edit sudoers manually. Use visudo. No exceptions!

There are only a few things I want a normal user to be able to do: mount filesystems and shutdown. The rest will (should) require full root privileges by signing in as su. This is a sample default sudoers file. I know it’s much more involved than the one in DSL and Knoppix. It should be if it’s going to be used on a hard drive and taken seriously.

Why? Anyone coming across your computer can type “sudo su” and immediately have root access. They can get a console locally by killing X (if running a screensaver or slock or other weak barrier) or remotely by guessing your password if you use one. Not exactly a good thing. So don’t do that! Fix it so you either have to enter your own password or, my own preference, use su and your root password to do root-things.

FIX SSH/D CONFIGS
The ssh configurations used in DSL aren’t suitable for hard drive use, in my opinion. They allow root login, X forwarding, etc. There are many excellent guides for using SSH safely and securely. The documentation from OpenSSH is excellent and clear. Make good use of good documentation and set up ssh/sshd as securely as you can handle it.

ADD SOME TOOLS
Not everyone needs GNU utilities, but they come in handier than the stripped tools (busybox) that come with DSL. There’s a menu entry in apps-tools to “upgrade to gnu utils.” This will give you more options for things left out of busybox. If you don’t use commands to check on processes or to manage your computer, you can probably get away with using busybox. But if you ever need to do “ps aux,” busybox won’t cut it.

Another thing I highly recommend is installing gcc. There are things you’ll want to update from what DSL has since many things in DSL have had security updates since Debian Woody and Knoppix 3.4 were released. There are three things I update immediately. There are other things I add later.

SECURITY UPDATES
These are the first three things I download and compile:

zlib: The version in DSL has very critical security problems. These probably won’t harm you if you’re using a live CD, but you’ll need to upgrade this if you want to upgrade the next two things. And it’s also used as a dependency on many other applications and utilities. This is a very easy fix. It has a Makefile. Edit it so the prefix is just “/usr” instead of “/usr/local” so it overwrites the old version.

openssl: There have been continued updates and security patching for SSL since the version in DSL was released. It’s a smart idea to get this updated if you want to use SSL (and you do want to use it) on the Internet. It’s easy, too: a simple configure, make, make test, and make install (you can probably skip the test on older, slower hardware as long as you have no configure or make errors).

openssh: This, too, continues relentless development to keep you safe via remote logins. The version in DSL is adequate for a live CD (and I’m surprised DSL doesn’t use a smaller implementation like dropbear), but there’s no reason to use older versions if you’re committing enough hard drive space for a traditional install. Update and be safe. It will not compile with the older zlib version without skipping the zlib test, so go ahead and update zlib first. You can build OpenSSH against the version of OpenSSL in DSL, but the order of upgrading is important: OpenSSH builds against OpenSSL. If you decide to update OpenSSH initially without updating OpenSSL but later change your mind and update OpenSSL, you’ll have to re-compile OpenSSH against the newer OpenSSL again. Just get it out of the way up front and be done since it’s pretty simple. Once you have zlib installed (or have decided to skip the zlib test when configuring OpenSSH) and OpenSSL updated (or have made up your mind to stick with the older version), OpenSSH is a very easy /configure, make, and make install. I use the same prefixes as DSL so I overwrite older implementations — I find this easier than tracking down multiple binaries installed by packages like OpenSSH does. If you stick with installing to /usr/local (the default!), you’ll either need to check that /usr/local/bin is before /usr/bin in your PATH or go through and delete the older versions (which is a good idea but gets taken care of the way I suggest).
This is what it should look like today when you do ssh -V:

OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007

I have the latest and most secure shell. How recent and secure is yours?

SHRINK YOUR KERNEL, ADD FRESH APPS
Another thing you can do with gcc right off the bat is compile a custom kernel. Like most distros, the kernel that comes with DSL is one-size-fits-all. There are things built into the kernel you may never need; there are modules you can leave out altogether. The former bloats RAM and the latter bloats your hard drive. You can use the same kernel version of DSL or update to a more recent one. Your choice.

EDIT - If you think this is an insignificant step, consider this. I did a fresh hard drive reinstall of DSL 4.2.4. I did the upgrading of SSH, SSL, and zlib noted above. I also upgraded to BASH current. Then I turned my attention to a new kernel compiled for this particular computer. I put as much into the kernel as I could and left a few things I need either immediately, occasionally, or might eventually need as modules. Here’s an image of a file in which I kept track of the differences. In fairness, the amount free using the default kernel included more processes:

It’s also important to note the default torsmorc in DSL (like htop) doesn’t include cached memory. So what you see reported by torsmo (and htop) isn’t the full picture. The point is, the default kernel has a lot of stuff in it that you definitely don’t need and it has modules to support a variety of hardware you’ll probably never use. If you’ve committed to doing a traditional hard drive install, you should consider making it fit the hardware you have. DSL is intended to be used on a variety of hardware. Hard drives aren’t quite as nomadic.

I have all the kernel and driver support I need in a slightly smaller kernel (removed a lot of stuff, added back quite a few things that were modules in the default kernel) and am now using 8.5% of the space I was using before for my new modules. Some of those modules — for USB printing and scanning, etc. — are there just in case I add more hardware that may need it. I also just noticed I forgot to disable SMP for my lowly old Celeron. So I really didn’t get too carried away.

FWIW, this is what torsmo shows (with X, jwm, torsmo, sshd, etc., running):

(end edit)

And with a compiler and more function from the GNU tools, you can compile just about anything else you want. If you don’t care about that, don’t worry about it. But that does mean you’re restricted to what you have from the CD and from MyDSL.

REMOVE THINGS NOT USED
This can be tricky if you don’t know what you’re doing. There are many things in the system some users never use. Sometimes these are things you’re better off without, such as if they have vulnerabilities that can be triggered from cross-scripting or are otherwise susceptible. Most of what’s included with DSL is pretty safe. But you still may choose to remove it simply because you’re using something else — such as expunging Siag if you’re using gnumeric instead.

It’s also a pretty good idea to keep an eye on security updates for other parts of the system or whatever you choose to add to insure your apps bring you productivity and joy rather than headaches. (Yes, these things can be exploited in Linux the same way as in any other operating system.)

WHY KEEP EVERYTHING IN ONE PARTITION?
One of the benefits of a frugal install is that it can use a persistent home partition, so updating each new DSL release doesn’t overwrite your own files. You can do the same with a hard drive install but it’s manual.

If you have a spare partition, you can use fdisk or cfdisk to designate it Linux 83. You may have to reboot when you do that for the MBR to pick it up. Then you need to make a filesystem, choosing either ext2 or ext3. Once that’s done, cp your files (dsl/) over to that partition as root (using -p to maintain settings). Then you need to mv /home to /home-old (you’ll delete this later). Edit /etc/fstab to add a line like this (to suit your own needs):

/dev/hda3 /home ext3 defaults 0 2

Then issue the command (as root) to mount /home or just reboot. Check /etc/mtab to see if it’s mounted. If it is, you can safely delete /home-old.

Now your files and settings are on a separate partition. When Robert updates DSL, you can re-install over the / partition and then fix fstab (or copy a backup of it) so it mounts your /home on the separate partition and you can delete the new /home partition.

You can do the same with other directories which contain applications and utilities and libraries you’ve updated. You can do it for /opt or you can also do it for sub-directories like /usr/local (in fact, this is probably the best reason you might choose to manually delete ssl/ssh/zlib and install the updates to /usr/local — except DSL doesn’t follow standard practices and uses /usr/local so you’ll need to be sure to copy the directory tree completely and manually “update” anything that changes in /usr/local/bin when DSL has updates).

WHAT’S IN A NAME?
dsl@box isn’t a good security idea (neither is knoppix@box). Using “dsl” as your user account is perfectly fine — I do that — but it’s reasonably easy to guess that such a user is using DSL or Knoppix; some e-mail clients and web services include that in the header even if you’re using a remote pop server. I change my hostname right away. That may not yield much in the way of security, but it reduces the chances of a sniffer picking up that my hostname is box and I’m using one of two distinct distros and then running known exploits against things included therein (which is one of the reasons I start by tightening up ssh, ssl, and zlib).

I also add separate user accounts even if they’re not how I log in when I’m physically in front of a computer. These allow me remote access. I can add to sudoers or not (the adduser script does add new users to sudoers with full root permissions).

All these points above are things I think are good ideas if you want to use DSL as a normal distro installed in a more traditional manner. What you’re effectively doing is undoing changes John and Robert (and Klaus Knopper) have made to get DSL (and Knoppix) to work as a real operating system from a CD and other media where that paradigm works well. You’re also — hopefully — updating a few things for security. Maybe you don’t use SSH, but you do use zlib and SSL more than you probably realize.

These are not things I have against DSL or consider major issues insofar as DSL is intended to be used. DSL isn’t intended to be installed across a hard drive in a traditional manner. That’s not a shortcoming or complaint, just acknowledging that it’s unique and has its own roadmap. It’s meant to be nomadic — portable. If you use it as intended as a live CD, with a frugal install, or off a USB or CF device, these steps are overkill. If you run as intended by the developers, your / partition is read-only and restores to default with each reboot. If you run as any other hard drive installed Linux distro, you lose that.

I didn’t touch on everything. For example, I left out issues related to use of Knoppix (and native DSL) scripts to manage things in a live CD environment. These scripts are ingenious for CD use; they can make life a hassle in a normal hard drive environment. Whether you can live with some of the scripts is a personal call. My experiences with hotplug have led me to disdain it. If you reboot on a regular basis, you won’t notice anything. If your computer stays on for a long period of time (weeks or longer at a time), you’ll want to do something about it even if you’re using a recent version of DSL which has had extraneous filesystem modules removed from the base.

The point, though, goes back to what I wrote above: using DSL in a traditional hard drive install requires a bit of undoing the changes to make it work well in a CD/frugal environment. I think you’re better off using another distro for a hard drive install if you’re unwilling to use DSL in a frugal install. If you’re willing to do a little work and deal with certain issues, it will do fine. I write that as someone with both hard drive and frugal/USB installs. YMMV.