Terry Gray
Previous chapters in my "Quest for Quiet" series have focused on building silent, or at least, very quiet, PC hardware. But software, especially Operating System software and configuration, can also have a big impact on one's acoustic computing experience.
For some time I used my IKEA "wooden-box" silent PC (See "Experiment #6, here) as a small file/print server. It worked OK, but the hard drive (situated about three feet from my ears) hardly ever stayed spun down for extended periods, even when I was not accessing any files. While not particularly loud, the drive seemed to have a particularly annoying whine, accentuated when spinning up frequently, so I came to resent this OS-induced drive noise. (I had a quieter drive available, but if operating constantly without any forced air cooling, it would run hotter than I'd like.)
Most operating systems have a genetic predisposition toward accessing their hard drive very frequently. At the time I was using Windows 2000 on this box, but I've noticed the same thing on Linux installs. (With Linux one can tweak things to reduce the amount of HD access, but it's not always obvious how or which accesses can be safely disabled.) As a consequence, I've long thought the ideal small server installation would involve running the OS out of RAM-disk, with Read-Only persistent storage for the OS components (either compact flash or a "use-rarely" HD or CDROM). It occurred to me that Knoppix might be an ideal platform for such a server, since this "live CD" Linux distribution does indeed run out of RAM-disk. However, Knoppix did not at the time come with some of the things I thought would be needed, and did not come with Samba file service configured by default, and I didn't have time to research it. Still, the idea of having a home server based on a self-contained OS running from read-only storage, with all local configs neatly separated onto a compact flash drive, was an idea that wouldn't go away.
When upgrading one of my desktop systems last December, one that was destined to stay on most all the time anyway, and would have been the primary client of the file server, I decided to dispense with the HD noise behind my head and use a small Hawking print server gizmo for handling the printer located near where the old server used to live. That worked OK for a while (modulo an occasional document that had trouble getting through the Hawking print server), but the situation changed a couple of weeks ago when the Hawking gizmo failed with persistent flash memory errors. I wondered how hard it would be to take the latest (06 June 03) edition of Knoppix and turn it into a network print server. Turns out it was pretty easy (and more trouble-free than the device it replaced). So the IKEA wooden-box server lived again, but this time with no hard drive attached!
That success inspired me to look into using the same box as a Samba file server. With a bit of research/education on smb.conf files and use of some nifty recent additions to Knoppix (for a "persistent home" and saving configurations to USB flash drives), I was able to get things going to my liking. Naturally I used hdparm to aggressively spin down the data drive, since it is accessed relatively infrequently. Result: a compact, low-power-consumption file/print server that is *totally* silent most of the time, and that only has a bit of HD noise when accessing the data drive, but (a lot of) occasional CDROM noise if/when I actually used the system for more than just file/print sharing, since Knoppix fetches executables off of the CDROM on an on-demand basis.
The only real problem I encountered was figuring out the best way to have the Samba server started automatically at boot time. I'm not sure I found the best way, but I found *a* way... see below for details.
I was hoping to use external Firewire or USB2 drives for data storage, but Linux 2.4 kernel support still seems to be a bit dodgy in this area. Additionally, some apps don't work with them. For example, a number of hdparm options work only on IDE drives (e.g. spindown timer) and do not work on SCSI-emulation devices such as external USB and firewire drives. Consequently I decided to stick to regular internal IDE drives for the time being.
In spite of these limitations, I was pretty happy with the result. But then something happened that proves I am incapable of leaving well-enough alone...
While wandering thru the docs section at www.knoppix.net, I stumbled on the beginnings of a HOW-TO guide for running Knoppix from a hard drive without actually installing it on the hard drive. That is, how to use a hard drive as a read-only boot and program cache, just like the CDROM. This allows the CDROM to be used for other things, and avoiding the noise and delay of the CDROM spinning up when accessing code that is not cached in the RAM-disk (but replacing the CDROM noise and startup delay with the noise and possible spin-up delay of the HD :). It also paves the way for putting the CDROM contents on a compact flash drive, and dispensing with all the rotating machinery --long a goal of us silent-computing enthusiasts.
The original knoppix.net document that inspired my efforts to eliminate the CDROM dependency from my Knoppix server project is here. Unfortunately, the original instructions had a couple of bugs and/or incompatibilities with the environment I was working in. Accordingly, I developed a revised guide, which can be found here. This provides a step-by-step HOWTO on booting Knoppix from a CF card.
Initially I implemented this approach on an existing hard drive, but seeing that the price of 1GB CF cards was now below $200, I decided to push further toward truly solid-state/no-moving-part systems. (Perhaps in another year, USB Flash Drives will become an additional viable option.)
I actually don't recall exactly what I did to get the print server set up. I think the key was discovering that there is a printer config option under the KNOPPIX menu (under Configuration), which invokes the KDE Control Center "Printing Manager" in administrator mode, which is essential. I chose to select the CUPS service. The printer in question was USB-attached and auto-detected, so no worries there.
Subsequently, I've seen a couple of suggestions on the knoppix.net forum that relate to configuring print services. One contributor suggests running the script "/usr/sbin/cupsconfig", and another advises "sudo cupsd" from a terminal window, after which he says you can successfully use the KDE print manager.
I found that once set up, the Knoppix save-configuration routines successfully preserve the state such that printing services are automatically started at boot time. And that's a Good Thing.
In contrast, I have not figured out how to have Knoppix start up the Samba server automatically at boot time, except by the hack described below. But starting the server is not the only task.
There are four steps to Samba server success:
I took a very simplistic approach to the smb.conf file, adding the following to the end of it:
[export] comment = data share path = /mnt/hdc1 writeable = yes browseable = yes
This Samba configuration emphasizes convenient/open access over security, but it's OK for a small and open (and hopefully trustworthy) network behind a NAT/firewall. I wouldn't store any national secrets in this config, however!
As for getting drives mounted appropriately at startup, note that Knoppix mounts drives in read-only mode for safety, and only on-demand. Accordingly, I needed to create a script (startup.sh) that took care of this, and cause it to be executed automatically at boot time. My script includes commands such as:
sudo mount -t ext3 -o defaults /dev/hdc1 /mnt/hdc1 sudo hdparm -S 40 /dev/hdc1The hdparm command sets the spin-down timer to a few minutes, which is what I like, since the server is accessed relatively infrequently.
While the standard Knoppix save-configuration script preserves the print server setup, I did not see any obvious way to have Knoppix automatically start the Samba server. Hence, I added to my startup.sh script the following command:
sudo /etc/init.d/samba start
Finally I had to figure out how to get my commands executed automatically at boot time. I'm certain there is a simple, elegant solution to this dilemma, but I have not discovered it yet. As a work-around, I decided to add a line to the end of the knoppix.sh script that is executed via the "myconf=" startup parameter. (I use "myconf=scan" as part of my boot options string, so I don't need to worry about changing the exact path if I use a different location for config storage later on.)
When using the Knoppix save-config function, a "knoppix.sh" startup script is generated. My workaround is to append one line to that script:
/mnt/sda1/startup.shOf course, I need to remember to do that each time I run the Knoppix save-config routine.
I tried adding my own commands to the /etc/init.d/bootmisc.sh script to avoid having to modify the generated knoppix.sh script after each save-config. I verified that my mods to bootmisc.sh are preserved by save-config, but it is apparently not executed at a point in the startup sequence where starting the Samba daemon or referencing my hard drives to execute mount and hdparm commands was possible. Hence the workaround, which seems to work fine. (Alternative suggestions welcome.)
In this section I'll note a few things I've learned about persistent homes, saving configurations, and local/personal mods to the boot sequence. A key for me was to understand the sequence of events in the knoppix-autoconfig script. Here is a rough outline of relevant processing in the autoconfig script:
One of my goals for this project was to find a way to add my own additions to the bootup process without having to change files on the boot partition every time I want to make a change. Originally I wrote a simple script to append a command to the standard knoppix.sh script in the MYCONF partition, but I would need to remember to do this every time I ran the Knoppix SaveConfig script.
In a www.knoppix.net forum posting, I found:
"To start a service on boot add a script to /etc/init.d and do:
sudo update-rc.d
Alas, the above didn't work for me... the Knoppix "save config" script evidentally doesn't save the resulting /etc/ links from update-rc.d so that method only applies to a "conventionally installed" Linux system.
Another note on the knoppix.net forum observed that inserting a modified "knoppix.sh" earlier in the search path that the knoppix config script uses might do the trick, but if you then want to invoke the real knoppix.sh then you have to be mindful that it assumes the config.tbz file is in the same place as the knoppix.sh and that directory path is passed as an argument.
I got close to success with this strategy, by putting a knoppix.sh file containing my local additions into /mnt/hda1 --but knoppix-autoconfig complained about something, and while examining the autoconfig script, I noticed that there is already provision for executing an "extra" knoppix.sh, if it is located in /cdrom/knoppix/knoppix.sh so I just needed to move my "local script invoker" routine from /mnt/hda1/knoppix.sh to /mnt/hda1/knoppix/knoppix.sh (Note that /mnt/hda1 becomes linked to /cdrom during booting.)
My local-script-invoker in /mnt/hda1/knoppix/knoppix.sh currently consists of:
#!/bin/sh echo "------------------------------------------" echo In /cdrom/knoppix/knoppix.sh... Trying /etc/init.d/knoppix-local.sh /etc/init.d/knoppix-local.sh echo "------------------------------------------" echo Now trying /home/knoppix/knoppix-local.sh /home/knoppix/knoppix-local.sh echo "------------------------------------------"
This redirection script gives me two places where I can add local customizations without having to modify the boot partition (which is hard to do while running from that partition). Only one choice is needed; I wasn't sure which would work better (the relevant filesystem has to be successfully mounted by the time the autoconfig script gets to this point). However, both locations seem to work fine, and it is more convenient to directly manipulate a file in the persistent home than to edit a file in /etc/init.d and have to remember to re-save the Knoppix config. So I may delete the first part and just use the invocation of /home/knoppix/knoppix-local.sh
This approach allows me to easily customize the script in my persistent home directory partition at /mnt/hda2. In contrast, if I want to change the modified script I put in /mnt/hda1/knoppix , aka /cdrom/knoppix , I need to actually boot from cdrom, not from /dev/hda1 , because the boot partition is not writeable while knoppix is running.
Customization Summary
I make three classes of personal customizations:
Finally, I'll note that the
key to setting your persistent home as an entire partition is the
following command done by the
knoppix-autoconfig script:
mount --bind /mnt/hda2 /home/knoppix
The --bind construct makes the two points in the namespace to
appear/behave identically, which is a very convenient mechanism... but sub
directories below the --bind mount point are not necessarily
equally visible from either root path; their visibility depends on the
paths used to create and view them, so be careful!
I hope this information is useful to others, and I would welcome feedback. (Follow the TEG HOME link below for contact info.)
This is one of a series of articles describing my silent computing
adventures. This
link will take you to the beginning of the story.