How to install Ubuntu Linux on the decTOP SFF computer
I recently bought a decTOP small form factor (SFF) computer. My goal was to build a cheap, fanless, quiet, and low power consumption Linux server. For $99 plus the cheapest available shipping, $40, my machine arrived 11 days after I placed the order.
This is a tiny computer, about the size of a Mac Mini. But, because it has no fan, it runs a bit quieter and, with the help of a 1-watt, 366 MHz CPU, consumes only 8 watts. For comparison, the G4 Mac Mini consumes about 20-30 watts, depending on load.
The decTOP comes with 128 MB of RAM in its sole SO-DIMM slot and a 10 GB 3.5 inch hard drive. I understand that it's a simple matter to replace the drive and to upgrade the memory to a maximum of 512MB.
It also comes with no operating system and the ability to boot only from a USB drive. This article details the steps I used to build the USB boot/installation drive and install Ubuntu 6.06 on the decTOP.
There is another article -- with additional decTOP links -- here on installing Ubuntu 6.06 on the decTOP with the aid of a Windows system. Fortunately ;), I run Mac OS X and Linux (Ubuntu 7.04), so that article didn't work for me. I did the installation of the Ubuntu 6.06 LTS Server Edition using my Ubuntu Linux box and a 1 GB USB flash drive -- although a 512 MB USB drive should work as well.
- Download the Ubuntu 6.06 server ISO image from the Ubuntu download page. Depending on your plans for the decTOP, you might want to choose the desktop version. Unless you have already upgraded your decTOP's memory, however, you'll want to stick with the 6.06 releases.
- Install the mbr, mtools, and syslinux packages on the Linux system you'll be using to prepare the USB drive. If you run Ubuntu or some other Debian-derived system, the following commands may do the work for you.
apt-get install mbr
apt-get install mtools
apt-get install syslinux
- Partition the USB drive with a single FAT-16 partition. I used the fdisk 'n' command to make the new primary partition 1. The fdisk 't' command can be used to change the partition type to FAT-16. My device name was /dev/sda.
- Make the FAT-16 partition the active partition. I used the fdisk 'a' command.
- Install a master boot record on the USB drive.
- Install syslinux on the USB drive. Note that the USB drive should not be mounted when you do this.
syslinux -s /dev/sda1
- Create a mountpoint and mount the ubuntu ISO image using the loopback device.
mount -o loop -t iso9660 ubuntu.iso /iso
- Create a mountpoint and mount the USB flash drive.
mount /dev/sda1 /usb
- Copy the contents of the ISO image to the USB drive. This will take some time.
cp -r . /usb/
- Copy the /usb/dists/dapper directory into a new /usb/dists/stable directory.
cp -r dapper/* stable
- Copy several files from /usb/install to the /usb root directory.
cp /usb/install/vmlinuz /usb/
cp /usb/install/mt86plus /usb/
cp /usb/install/initrd.gz /usb/
- Install the following text into a file named syslinux.cfg in the /usb root directory.
append initrd=initrd.gz ramdisk_size=24000 root=/dev/ram rw
- Flush all writes, unmount, and remove the USB drive. After the sync step, wait for all of the data to be written to the USB drive.
- Connect the ethernet adapter to the decTOP and connect it to your network to allow automatic configuration of the network interface.
- Insert the USB drive into the decTOP and power it up. The decTOP should automatically boot from the USB drive and start the Ubuntu installation.
- Answer only the first two questions concerning language selection and go to the next step, below.
- Press Alt-F2 (hold down the Alt key and press the F2 function key) to open a shell. Then press enter to start the shell.
- Create a /cdrom and a /dev/cdroms directory in the installation ramdisk
mkdir /cdrom /dev/cdroms
- Go to the /dev/cdroms directory and build a symlink from /dev/sda1 (that is likely the device name of your USB boot partition) to /dev/cdroms/cdrom0.
ln -s ../sda1/cdrom0
- While still in the shell, mount the USB drive to mimic an installation CD-ROM.
mount -t vfat /dev/cdroms/cdrom0 /cdrom
- Return to the installation program with Alt-F1 and continue the installation.
From this point, the process should be identical to a routine CD-ROM installation.
For a grand total of $140 and 8 watts of power consumption, I now have a near-silent Linux server running 24/7. You can telnet to it here and marvel at its blinding speed running a 250,000-sector Space Tyrant game.
|mail this link | permapage | score:9602 | -Ray, August 16, 2007 (Updated: April 26, 2011)|
Beneficial Computer Viruses
|An article on last week's front page of SecurityPortal entitled Reflections on the Strange, Perplexing, Interminable, and Most Lamentable Phenomenon Known as the Viral Wars contains an alarming suggestion. |
It proposes that we..."Develop antiviral viruses (antibodies) that are polymorphic and mobile. Roaming the Internet they would seek out and destroy new viral strains. (SARC is doing some interesting work in this area. More needs to be done though.)". There are several problems with this idea.
First, it ignores the basic problem with viruses -- that they run on other people's computers without authorization. Presumably, a "beneficial" virus would propagate by similarly illegitimate means, but carry a "good" payload rather than a destructive one. For that reason, I believe that anyone who releases such a "good" virus should be charged with the same offense as one releasing a "bad" virus, although with reduced penalties for its perhaps lesser damage and less deliberately destructive intent.
Note that the good virus would not only propagate and execute without permission, but would also consume network bandwidth, processor cycles, memory, and disk space. Resulting, inevitably, in the denial of the system owner from using those resources. That is what is commonly called a "denial of service" attack, or DoS.
Next, there is the non-trivial problem of identifying malicious programs. Identifying a known, existing virus is easy in comparison to programmatically distinguishing between unknown good and bad code. Since many legitimate programs contain several ways to damage or remove files, the simple ability to delete and modify files cannot alone identify a program as bad. So, perhaps the good virus would limit itself to wiping out only programs that it could (somehow) identify as capable of replication by combining its own code with that of another program. That would surely be inconvenient for the makers of self-extracting archive software. But, assuming that that obstacle could be overcome, how would a good virus tell another good virus from a bad one? Both behave similarly, including the practice of damaging or destroying other files. Imagine the resources wasted in unintentional global wars between various strains of good viruses! We can only hope that all creators of such good viruses carefully write their code to recognize every other species of good virus -- a task made difficult or impossible by the fact that the good viruses would be cleverly polymorphic.
Note that, for liability reasons, good viruses would have to be very nearly perfect. To have them mistakenly delete a recently patched copy of Microsoft Word could be very inconvenient.
And, of course, let's not overlook the possibility of mutant evil strains of the so-called good virus -- strains created by shady programmers who would not otherwise be capable of writing such sophisticated code. The new evil -- and polymorphic -- strains would likely be mis-identified as good by unmodified good viruses yet carry a very destructive payload. A payload which could include the killing of all the unsuspecting good viruses that it can so easily identify.
Then, some time in the future, we will pause for a moment of silence while we remember the deceased good viruses that first invaded our computers, escalated the virus wars, then gave their very essence to improving the breed of their sworn enemies before being themselves ruthlessly destroyed by derivatives of their own code.
|mail this link | permapage | score:9537 | -Ray, June 26, 2000 (Updated: January 1, 2003)|
Librenix T-Shirts and Coffee Mugs!
|For today's example of my (semi)elite C programming skilz, I submit for your inspection the Librenix T-Shirts! Yes, I created the images on these shirts and coffee mugs entirely with C code. While the code isn't up to the standards *cough* of my open source Space Tyrant project, at least the output is colorful and not entirely textual!|
click either image to see the T-Shirts, Coffee Mugs, etc.
(If you like the images but don't care for 'librenix' on your shirt, these same styles are available for all 50 US state names as well as with the signs of the zodiac here)
(and here are some modern prints)
|mail this link | permapage | score:9515 | -Ray, June 6, 2010 (Updated: May 13, 2014)|
Scripting: A parallel Linux backup script
|This example bash shell script demonstrates a simple method of creating backups of multiple filesystems to multiple tape devices simultaneously. While the script presented writes to four tape drives in parallel, it can easily be modified to write to other device types and to create a different number of backup streams. The script is set up for the bash shell under Linux, but modifying it for another variety of Unix should simply be a matter of changing the locations of utility files such as tar, echo, cp, and sleep. |
The script can be downloaded from http://librenix.com/scripts/par.tar.sh. Download the file now and load it into an editor as this article will refer to it frequently. Also, you may want to modify bits of it to match your filesystem names and your devices.
The first line of the script looks like this:
#!/bin/bashIf the bash shell isn’t in the /bin directory on your system, you’ll need to modify this line. Enter the command which bash now to verify the location of bash. My Fedora Linux system and my Mac OS X system both have bash in /bin, but my FreeBSD system does not. If you have a non-Linux flavor of Unix, you’ll probably need to use the ‘which’ command to verify the locations of each command used in the script. The commands used are:
bashNote that ‘wait’ and ‘cd’ are usually implemented as internal shell commands and may not have external commands associated with them. If that is true for your system, leave ‘cd’ and ‘wait’ with no directory prefix just as they are in the original script.
Now, the first command in the script resets the current working directory to ‘/’:
cd /Since the script precedes each directory to be backed up with a ‘.’ to represent the current working directory, starting out at ‘/’ is necessary. The reason for this precaution is that some implementations of the tar command will only load files from a tar archive into the exact directory that was specified when the file was backed up. By prefixing the names with a ‘.’ we preserve the ability to recover the files into any subdirectory we want, without overwriting the original files.
Immediately after the ‘cd /’ command is where you would put any commands to shut down all services that must be quieted prior to a backup. The example script has a (commented out) command to initiate an Oracle database shutdown followed by a ‘sleep’ command to allow time for the shutdown to complete. The example database shutdown and the following delay probably don’t apply to your system. Obviously, you’ll have to add commands yourself to stop any applications that might interfere with the backup.
Next, we use the ‘date’ command to create two sets of four tiny files to stick at the start and end of each tape. Note that the presence of a ‘date.#’ file at the beginning of each tape lets you quickly find out when a tape was created and on which drive. The ‘zzzz.#’ files, appended to the end of each tape, only serve to let you easily verify that a backup completed without overrunning the end of the tape.
Next, we start the four actual ‘tar’ backup commands, each with sample directories named ‘./dir1’, ‘./dir2’, etc. Of course, you’ll need to modify the list of directories to match the actual directories you wish to back up. Note that you’ll probably want to balance the directory sizes so that all of the largest directores aren’t on the same tape. Also, note that each ‘tar’ command is run in the background and logs to a tar.#.log file in the /tmp directory. Obviously, you might want to put the logfiles somewhere else.
After each ‘tar’ command there is an entry like this: ‘TASK=$0’, or ‘TASK=$1’. These arbitrarily-named ‘TASK’ variables are used to store the process ID of each ‘tar’ command so that the script can wait for them with the four ‘wait’ commands that follow in the next block of code. There, we have the four ‘wait’ commands waiting on the $TASK0, etc, variables. (The addition of the ‘$’ to each TASK# shell variable is not a typo -- it’s necessary to read back the contents of the variable.)
Next, after the script has waited for the completion of each of the four ‘tar’ commands, it appends some information to a history file for later reference. It stores the date of the backup, the filesize of the logfile, and the number of files backed up on each tape to each of four history files. While the script will overwrite the logfiles (tar.#.log) each time it is run, it will append these three lines to each of the four history files (tar.#.history).
The final steps in the script are commented out. Those are the commands necessary to restart any applications that were brought down for the backup. Again, in the example we assume an Oracle database needs to be restarted. You’ll need to add the commands necessary to start any applications that were stopped at the beginning of the script.
|mail this link | permapage | score:9487 | -Ray, April 10, 2005||