Librenix
Headlines | Linux | Apps | Coding | BSD | Admin | News
Information for Linux System Administration 

How to install Ubuntu Linux on the decTOP SFF computer

Up
vote
Down

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.

  1. 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.

  2. 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
  3. 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.
    fdisk /dev/sda
  4. Make the FAT-16 partition the active partition. I used the fdisk 'a' command.

  5. Install a master boot record on the USB drive.
    install-mbr /dev/sda
  6. Install syslinux on the USB drive. Note that the USB drive should not be mounted when you do this.
    syslinux -s /dev/sda1
  7. Create a mountpoint and mount the ubuntu ISO image using the loopback device.
    mkdir /iso
    mount -o loop -t iso9660 ubuntu.iso /iso
  8. Create a mountpoint and mount the USB flash drive.
    mkdir /usb
    mount /dev/sda1 /usb
  9. Copy the contents of the ISO image to the USB drive. This will take some time.
    cd /iso
    cp -r . /usb/
  10. Copy the /usb/dists/dapper directory into a new /usb/dists/stable directory.
    cd /usb/dists/
    cp -r dapper/* stable
  11. 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/
  12. Install the following text into a file named syslinux.cfg in the /usb root directory.
    default vmlinuz
    append initrd=initrd.gz ramdisk_size=24000 root=/dev/ram rw
  13. 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.
    sync;sync
    umount /usb
  14. Connect the ethernet adapter to the decTOP and connect it to your network to allow automatic configuration of the network interface.

  15. 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.

  16. Answer only the first two questions concerning language selection and go to the next step, below.

  17. 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.

  18. Create a /cdrom and a /dev/cdroms directory in the installation ramdisk
    mkdir /cdrom /dev/cdroms
  19. 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.
    cd /dev/cdroms
    ln -s ../sda1/cdrom0
  20. While still in the shell, mount the USB drive to mimic an installation CD-ROM.
    mount -t vfat /dev/cdroms/cdrom0 /cdrom
  21. 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

Up
vote
Down

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!

Up
vote
Down

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

Up
vote
Down

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/bash
If 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:
 bash
cd
sleep
echo
date
tar
wait
ls
wc
Note 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
More articles...
Abstract Art on Acrylic Panels

More features

Microsoft to push unlicensed users to Linux

Graffiti Server Download Page

Tutorial: Introduction to Linux files

Hacker Haiku

MiniLesson: An introduction to Linux in ten commands

Linux vs. Windows: Why Linux will win

Closed Source Linux Distribution Launched

The life cycle of a programmer

The Network Computer: An opportunity for Linux

Writing syslog messages to MySQL

Space Tyrant: A threaded game server project in C

Space Tyrant: Multithreading lessons learned on SMP hardware

No, RMS, Linux is not GNU/Linux

The short life and hard times of a Linux virus

The Real Microsoft Monopoly

Why Programmers are not Software Engineers

Mono-culture and the .NETwork effect

Missing the point of the Mac Mini

Download: Linux 3D Client for Starship Traders

Space Tyrant: A threaded C game project: First Code

Why software sucks

Space Tyrant: A multiplayer network game for Linux

The Supreme Court is wrong on Copyright Case

Tutorial: How to Block Ads With Adzap

Shadow.sh: A simple directory shadowing script for Linux

Programming Language Tradeoffs: 3GL vs 4GL

The BSD License and the GPL: Why we need both

Apple to Intel move no threat to Linux

Review: DevelopGo: A Linux Live CD for Programmers

Opinion: Seeing Linux for the first time...

Install a Mail Server with Antivirus and Antispam in minutes

Create mobile Web apps with HTML5

SSL Encrypting Syslog via Stunnel

SquirrelMail and AXIGEN WebMail

Be an Engineer AND an Artist

Retrofit with JTip tooltips and GreyBox lightboxes

myServer: How to build up a personal web server

Opinion: What Linux Needs (or doesnt need)

Put our headlines on your site using RSS files

Librenix Sitemap

News Websites

Apps Websites

Monthly Visitors to Librenix.com

Sysadmin Websites

Monthly Visitors to Librenix.com

About Librenix.com: Privacy Policy, Contact Info, etc.

Call for Linux software review articles

Posting Guidelines

Coding Websites

 

Firefox sidebar

Site map

Site info

News feed

Features

Login
(to post)

Search

 
Articles are owned by their authors.   © 2000-2012 Ray Yeargin