DSL Hard Drive Tweaks
BIG FREAKING SERIOUSLY IMPORTANT NOTE (IOW, YOU SHOULD READ THIS): DSL’s development appears to either have come to an end or is at a standstill. However you choose to view it (I say it’s dead), this means anything with security issues will only be updated if and when you do it yourself. Using DSL as it’s intended to be run — frugal installation, live CD, USB install — offers some degree of protection you lose by installing it more traditionally. I’ve decided against updating this page or offering a more comprehensive guide (via PDF) because the kernels available in DSL ISOs are unpatched for recent (24 Aug 2009) vulnerabilities, making traditional “hard drive” installs of DSL a risky proposition unless you patch and compile your own kernel. If you need to use something in a standard/traditional manner, I recommend using distros and the BSDs under active development and actively patched for security-related issues. If you want to use DSL, I recommend only doing frugal installs so that your base system is read-only and using UCI extensions where possible. Without an active developer or anyone to manage new extensions, you’re on your own.
lucky13: DSL hard drive page
Table of Contents
- 1 Introduction
- 1.1 New introduction and foreword
- 1.2 Original introduction
- 2 About DSL on Hard Drive
- 2.1 DSL Is Nomadic
- 2.2 DSL hard drive installation requires reversing CD-specific hacks
- 2.3 DSL extensions
- 2.3.1 .dsl
- 2.3.2 .tar.gz
- 2.3.3 .uci
- 2.3.4 .unc
- 3 Updating the base
- 3.1 Security
- 3.1.1 Fix sudo to suit your needs on a hard drive
- 3.1.2 sudo privileges
- 3.1.3 Fix ssh/sshd configurations
- 3.2 Adding full-featured GNU (and/or BSD) tools
- 3.3 Adding gcc
- 3.1 Security
- 4 Essential security updates
- 4.1 zlib
- 4.2 OpenSSL
- 4.3 OpenSSH
- 5 Compile a custom kernel
- 5.1 Compile other things you need or want
- 6 Remove things you don’t want or need (caution!)
- 6.1 Follow security advisories
- 7 Persistent partitions
- 8 Set up your own hostname and username
- 8.1 Add additional users with limited system privileges
- 9 Final thoughts
- 9.1 It takes a little effort but it’s worth it
- 9.2 These aren’t shortcomings
- 9.3 There are, and may be, other issues
- 9.4 Just remember what it is
1.1 New introduction and foreword
This is an update of my previous DSL hard drive install page with better organization and a few edits. I’ve rearranged some of the information, I’ve tried to clarify a few more things, and hopefully this makes it better organized for anyone who needs it.
1.2 Original introduction
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.
2 About DSL on Hard Drive
DSL can help breathe new life into old hardware. It’s important, though, to remember that it was “hacked” to run off a CD. Some of these “hacks” need to be undone to make it function as a normal hard drive operating system. Some of these things are easy to change, some are a little more difficult.
You should consider using DSL as it was intended to be installed. One of the options presented in the menu is the frugal install. What this does is install the image of the CD on its own partition. You then need a swap and at least another partition – for /home and /opt – to install it in such a way that your own settings carry over between boots. This guide isn’t for frugal installs. The DSL site has documentation for that. My own recommendation is that you use it as it’s intended. So you’re on your own with what follows.
If it’s so much work, and if the “hard drive” install needs updating as described above, why do a frugal install? The base of DSL in a frugal install is read-only. If something bad happens, you can reboot and you’re in a fresh state. The only areas you need to worry about messing things up are what you mount as writable: persistent /home and /opt partitions. The whole system is writable in a traditional hard drive install. Mess up something in the system, it takes more than a reboot to refresh the system.
2.1 DSL Is Nomadic
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.
2.2 DSL hard drive installation requires reversing CD-specific hacks
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. It won’t exactly be “damn small” like that, but it will suit your own needs without excessive stuff. More or less.
2.3 DSL extensions
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.
There are four kinds of extensions, three of which are suitable for hard drive installation.
The .dsl extensions are probably best for standard hard drive installs because they’re standard tarballs that untar across the traditional directory structure as packages for other distros do.
Don’t confuse the .tar.gz extensions in MyDSL for standard tarballs. They’re self-contained applications that will load with the standard “mydsl-load” command; they install in /opt, either in their own directory or, in the case of single binary files, in /opt/bin. Your menu may need to be edited manually after installing these.
These are like .tar.gz extensions except they’re mountable rather than archives. These require a little more work to make persistent. In a nutshell, you need to load it, copy the whole structure temporarily, un-load it, then move it back to its original name.
So the first thing you need to do is load it. Use “mydsl-load” or any of the alternatives (MyDSL browser has an option as does emelfm): mydsl-load foo.uci
This will create /opt/foo or something like it.
Next, you need to make a temporary copy: cp -r /opt/foo /opt/foo-temp
Then un-mount the original. This will remove the mount point in /opt: mydsl-load foo.uci
Now move the temporary directory to its original name. Be careful about this because you probably won’t be able to rename or mix case for characters (especially for things that have their own libraries and assorted files with coded paths during compile): mv /opt/foo-new /opt/foo
You will no doubt have some clean up work to do with your menu. I make persistent entries in mine; I get rid of the include tags contained in the jwmrc file. You can do what you need to, just remember DSL wasn’t intended for hard drive use so there may be some inconveniences due to using apps intended for non-hard drive use. That’s more true for .uci extensions than for the previous two types.
You shouldn’t use .unc extensions for hard drive installation. These are for use with unionfs, which was implemented in DSL for use as a filesystem overlay for use in nomadic systems. Most of the .unc extensions have .dsl counterparts.
3 Updating the base
This is something I think is very necessary. DSL was derived from Knoppix 3.4, which was based on Debian Woody. Debian no longer supports Woody, and DSL has morphed into its own species. Don’t expect seamless integration with Debian whether Woody or anything else. Some things can and will work. Some things won’t, and you can screw things up bad enough that you’ll either have a lot of backtracking to “fix” or you’ll end up reinstalling (which is a loathsome process, IMO).
There are other issues beyond the age. The versions of various things in DSL are quite old and one of the concerns should be security. Another is utility; DSL comes with a single binary replacement of GNU utilities called busybox, which functions quite well but doesn’t have the full function of the real utilities.
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.
3.1.1 Fix sudo to suit your needs on a hard drive
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
- Setting up visudo
DSL comes with beaver and nano and vi. 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!
3.1.2 sudo privileges
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.
3.1.3 Fix ssh/sshd configurations
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.
3.2 Adding full-featured GNU (and/or BSD) 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.
3.3 Adding gcc
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.
4 Essential 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: OpenSSH5.0p1, OpenSSL 0.9.8g 19 Oct 2007
I have the latest and most secure shell from OpenSSH. How recent and secure is yours?
5 Compile a custom kernel
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):
5.1 Compile other things you need or want
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.
6 Remove things you don’t want or need (caution!)
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.
6.1 Follow security advisories
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.)
7 Persistent partitions
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).
8 Set up your own hostname and username
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).
8.1 Add additional users with limited system privileges
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).
9 Final thoughts
9.1 It takes a little effort but it’s worth it
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.
9.2 These aren’t shortcomings
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.
9.3 There are, and may be, other issues
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.
9.4 Just remember what it is
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.
Created with: org-mode, Emacs 22.3.1
Using OpenBSD 4.3
Date: 2008/10/23 11:08:34 US/Central
Updated: 2009 08/24 18:15 US/Central