First developers-only public MOAM-CD release

---

OK, since I am able to use MOAM-CD to upload the file and post this blog, I will make my first public developers-only release of MOAM-CD. The system is still buggy; I needed to try about five or six different computers in this cyber cafe to get this system to work. And, things are still quite buggy. For example:

1. I have to type in HOME=/root; export HOME; PATH=$PATH:/usr/X11R6/bin; export $PATH before I can configure and use X.
2. I have to configure, at boot time, the location of the CD-ROM drive
3. /etc is not writable, and there is no /etc/resolv.conf
4. On one system, it hangs after loading the kernel. This may be because I'm using a CD-RW instead of a CD-R (one way to test this: See if I can browse the CD and what not in Windows)
5. I need to move over the probe script from MOOF in order to make probing for a network card easier
6. modprobe doesn't work, probably because RedHat added some proprietary stuff to change the modules.dep format
7. Since we don't have modprobe add the script to insert the USB modules, find the USB flash drive, and mount it (MOOF has this)
8. Make it easier to get Spanish keyboard support; I often need accents when writing to my Spanish-speaking friends.

Problems 2 and 3 can be solved by seeting up an initrd to look for the CD (look for a given file that will only be there if the CD is a MOAM CD), and to make the core root system re-writable, extracting dev and etc from tarballs and what not.

I am not distributing a working boot MINI-CD. What I am distributing are scripts that, when run on my system, make the mini-cd ISO image. These scripts are hardcore; while there are tarballs for the programs not included with CentOS (Ace of Penguins, FVWM1, RXVT), the script expects you to have installed Opera on your system.

I prefer Firefox as a browser over Opera, but to make Firefox fit in the same 20 megs that Opera uses requires one to use the unmaintained, insecure 1.0 release of Firefox.

Anyway, the scripts and programs used by MOAM-CD can be downloaded at http://www.samiam.org/moof/moam-cd-0.0.tar.bz2

I will release a release with initrd support and more suitable for installing with a stock CentOS 3 system in a few days.

MOAM-CD update; !"·$ RedHat!

---

The reason why X wasn't starting in MOAM-CD was because RedHat added some stuff to X to make it unable to start up--unless you use RedHat's own customized kernel. Basically, RedHat is a walled garden which is often times well separated from mainstream Linux. So, there is sometimes weirdness like this. The advantage is that RedHat maintains code far longer than mainstream open source writers; once a piece of code enters RHEL, it stays there supported for seven years.

The problem now is that I can't use cloop with the 2.4.21 kernel RHEL 3 uses; while Cloop 2.05 is compatible with Linux 2.4.34.2, it's not compatible with 2.4.21. So, I either have to find an older Cloop that works, or, better yet, just use cramfs instead, which, in fact, is fully supported in 2.4.21. Its limitations--16 megs per file, 256 megs for the filesystem--are within the space limits of a 185 meg mini-cd. It also doesn't compress as well as cloop; cloop compressed about 4% better. Howevere, this is offset by the fact that cramfs is fully supported in RH's kernel.

Once change I made was giving tmpfs support in the core kernel; this is better than a RAM file system because it expands or shrinks depending on how many file are there, and I don't have to figure out how much memory is in the system before making the temporary file system.

Right now, I have a system that I can boot from cdrom, with a script that automatically comfigures X. I can then enter X--this is a little buggy, my mouse does not always work--which starts up fvwm. From fvwm, I can start up rxvt. I can also start up and run Opera. All of this takes about 95 megs uncompressed, 42 megs compressed with cramfs, and 40 megs compressed with cloop.

The next step is to set up initrd to set up up a writable root filesystem, find the cd drive (trying IDE secondary master, primary slave, secondary slave, and finally primary master), and ask the user if they want X. Another issue I haven't dealt with yet are USB mice and keyboards.

I also have two MaraDNS bug reports that I will look at tonight.

- Sam

MaraDNS 1.2 stable snapsot released; MOAM-CD update

---

I have release a stable snapsot of MaraDNS 1.2 today. This is a backport of some bugfixes in the 1.3 branch. Unless an urgent bug comes up, I will release MaraDNS 1.2.12.06 in mid-May 2007. With the stable branch, unless there is an urgent security issue, I will only issue update once every three months, so system administrators have minimum downtime updating MaraDNS.

The snapshot is here:

MaraDNS 1.2 snapshots

---

I have hit a snag with MOAM-CD. It seems that X doesn't like the kernel I have compiled. I can not find documentation telling me exactly what I must enable in the kernel to get X to work, and looking at the seetings and in the documentation did not help either. Strace didn't help either. So, I've downloaded the source to the most recently updated kernel for CentOS 3, and will look at those settings. Worst case, MOAM-CD will use the kernel CentOS 3 uses.

I also see X has been updated, but I don't have space on my flash drive to download it. Maybe tomorrow.

Once I get X working, I will release MOAM-CD. I was up late last night working on MOAM-CD, and ended up so tired today that I forgot to turn off the water heater after showering. Which is a bad idea, since out cheap heater does not have a thermostat.

OK, I'm getting closer to making my own Live CD Linux distribution

---

I'm one step closer to having my own Linux live CD distribution.

Last night, I figured out how to have X autoprobe for the type of video card you have. Basically, by running X -configure, X will probe your system to see which video card you have, and write a basic XF86Config file. I presume newer versions of X will make this an Xorg.conf file. I then run the generated file through an Awk script to make an XF86Config file that generates an 800x600 screen refreshed at 72hz.

I have also downloaded and compiled Linux 2.4.34.4, and added a script to cloop 2.05 so that it compiles without problem in Linux 2.4. Cloop is a program that allows me to compress the filesystem. cloop 2.06 won't compile without modification in Linux 2.4; cloop 2.05 is the last version of Linux 2.4 that can compie as is, using only a small script to
make the actual module.

Right now, I don't need Cloop. The complete working self-contained system, with X, Opera, Fvwm 1, kernel drivers, Busybox, MaraDNS, and rxvt, is about 70 megabytes in size. Cloop is a "nice to have" thing.

One nice thing about the cyber cafe I am in right now is that it is a good place to test Linux. DSL has not been tested throughly on the kind of hardware I try to run DSL on. On one system in this cafe, the USB doesn't work. On another, DHCP doesn't work. On another, the mouse doesn't work. On another, it seems to hang at kernel bootup time. Since the DSL designer decided the Kernel bootup messages were not pretty, I can't figure out why--there's a reason the Linux kernel is so verbose at startup. Without these messages, I can't figure out if a given piece of dodgy hardware is hanging or if there is some really long autoprobe process.

DSL has different priorities than I do. I want a simple system with a usable *NIX environment (can you say Busybox), X, a simple window manager (fvwm1 works just fine), SSH, a terminal program (such as the small RXVT), MaraDNS, a web browser that can access the modern internet, and possibly an IM client that works with MSN. DSL has all that (except for a DNS server), but DSL also has a Spreadsheet, a Word Processor, a VNC thingy, three different editors (I can live with just vi but will probably add Nano), a graphical FTP client (that's what SSH and a web browser are for), the XMMS mp3 player (This is "nice to have" but not essential, especially since most computers at cyber cafes don't have speakers), xpaint, an image viewer (again, just use the web browser), a graphical email client (again, the web browser or SSH in to the *NIX box and use MUTT there), a fancy colorful boot sequence (No, I don't need this), an old version of XPDF that doesn't work with my English lessons (Nice to have if it worked, but...), far too many really ugly fonts, etc. On the other hand, DSL is lacking pretty fonts (except for the excellent misc-fixed), tools to handle 70hz refresh (much easier on my eyes; CRTs are alive and well down here), dodgy USB controllers (don't try autoscanning; just let the user insert and remove the USB kernel modules themselves after inserting and before removing a USB keychain); dodgy DNS servers (That's why I include MaraDNS), dodgy hardware (It would help if I could actually see where the kernel is hanging), dodgy CD-ROM drives that have a hard time reading the live CD (I wonder if some kind of RAID mirroring is possible, where there are two copies of each file), etc.

The next hurdle I need to jump in my own Live CD distribution is to set things up so the root filesystem is one that is usable. Right now, the Xsetup script I wrote doesn't work because the root filesystem needs to be a ramdisk with symlinks to the various read-only parts of the actual system. So, I will look at the KNOPPIX initrd and see what magic it does to make the ramdisk filesystem when I get some free time again.

- Sam

OK, I figured out how to customize DSL

---

OK, I figured out how to customize D.S.L. so that it has the DSA host keys and the software I need on the same mini-CD that DSL is on.

Basically, the DSL distribution is a simple ISO formatted CD with Rock Ridge extensions. The KNOPPIX compressed root filesystem is a single file that takes up the majority of the space in the DSL image.

The boot information is stored in files in boot/isolinux off of the root of the CDROM filesystem. The isolinux documentation gave me the exact incantation to give mkisofs in order to make an ISO image that can use isolinux to boot. Once I verified that it worked by burning a CD-RW (my laptop is about seven years old, but the built-in CDROM drive thankfullys read CD-RWs without problem), I then added some stuff to the DSL root:

• An encrypted copy of my "portable media" ssh key
  
• Bitmap versions of the "Vorpal" font I mentioned in my last blog, complete with a script to install this font (DSL doesn't have mkfontdir)
  
• MaraDNS with a basic resolve-on-loopback mararc
  
• A lot of my English lessons
  
• All of my favorite music by Jonn Serrie and a song I did myself
  
• The memtest x86+ utility, since one of my students has been having problems with her system rebooting at random times. And, yes, the problem was indeed her memory.
  

The music took up over 100 megs of space. Despite this, the CD has a working version of the Firefox browser (albeit the older and undoubtably insecure 1.0.6 release), a working mp3 player, a simple word processor (Ted) and Spreadsheet program (siag), and numerous other goodies.

It's a very good system for uploading or downloading files without me neeing to lug my laptop everywhere. I'm using this setup right now to type this in.

The system is not perfect. For example, since the X server simply uses VESA, it isn't very fast, and, more annoyingly, only has a refresh rate of 60hz which is a little hard on my eyes when using a CRT. Also, I wish DSL used a more recent version of Firefox, or, even better, a version of Konqueror embedded for the browser.

But, the DSL setup saved me a lot of time and effort setting up my own bootable CD for taking to cyber cafes.

- Sam

Moof 0.4.2 released (bugfix release)

---

Since MOOF 0.4.1 could not work as a DHCP client, I have release MOOF 0.4.2. This is a bugfix release; in order to make room for af_packet.o, which the DHCP client needs to do its DHCP magic, I removed an older ISA driver. Since there was a little room left over after removing this driver, the md5sum applet is now part of MOOF.

I've basically accomplished all of my goals with MOOF at this point. MOOF 0.4.2 does everything I need in a one-floppy system: It runs MaraDNS, it can save and load configuration files (SSH IDs, bootup commands) from the last three sectors of the floppy, it has support and autodetection for a large number of wired ethernet cards, and it allows me to upload files to my web server and chack my email without needing to tote my laptop everywhere. All of this on but one floppy.

Now, as it turns out, it is possible to put a complete graphical system on a single floppy. The old Amigas had a complete desktop environment that fit on all of two 720k floppies; more recently, QNX made a demo disk that included network support, a graphical environment, and even an HTML browser as good as or better than Dillo...all on a single floppy!

Alas, X is far too bloated to make a Linux version of this possible. What is far more practical is to place a full Linux system, with a full blown Busybox, the real glibc (so I don't have to recompile everything), Opera (Opera is smaller than Firefox, more secure and bug free than Firefox, and I can't figure out what the absolute minimum set of files Firefox needs to run correctly in a mini Linux system), X with a minimum set of fonts (I like Verdana so much that I have made bitmap versions of Verdana at various sizes), Fvwm, SSH, and Rxvt. All of this can easily fit on a single bootable 200 meg mini CD without resorting to a compressed image; right now I have a working chroot() environment with X, Opera, Fvwm, and Rxvt, all of which takes up less than 60 megs.

Note that is some non-free software here. In particular, Opera and the Verdana font. Basically, Firefox sucks compared to Opera from a security and embedded standpoint. In a recent report on Linux security vulnerabilities, Firefox/Mozilla generated the lion's share of security updates. It is the new BIND8: A piece of software with more security holes than swiss cheese that we have to put up with. Just as the proprietary (but free) djbdns was the only option for a secure DNS system in the late 1990s, the proprietary (but free) Opera is the only really secure option for a web browser usable with modern web sites in the 2000s. I don't want something as insecure as Firefox on a disc I will burn once and will be unable to reburn.

The reason why I include Verdana is that nothing beats Verdana in terms of being a readbale font on older non-true color displays. I tried to make a font as readable as Verdana but it's a lot harder than you might think. Since I'm only using bitmap renderings of Verdana and not the font itself, I'm legally OK because of a loophole in USA copyright law that makes a bitmap rendering of a font not subject to copyright protection.

I've changed the name of the font to Vorpal and removed all references to Microsoft in order to avoid trademark issues. That said, I will probably not distribute the actual "Vorpal" font (and, of course, I won't distribute Opera) when I get the Mini-CD system to work and distribute it.

The updated MOOF is available at http://www.samiam.org/moof.

MOOF 0.4.1 released; many more drivers but DHCP broken

---

I havr released MOOF (MaraDNS on one Floppy) today. It has many more drivers, but, alas, I disabled raw sockets when trying to make the kernel as small as possible, which breaks DHCP. My workaround is to just use what ifconfig gives me when using a Windows manchine to upload my files with MOOF.

This release can also save configuration information to the floppy containing MOOF, and read configuration from the floppy.

I need to make room for the raw socket support in the kernel; I am literally against the wall. The root image is to the byte big enough to fill up the floppy until the end of the fourth-to-last sector (there's about 48 bytes free between the end of the kernel and the beginning of the root image). The last three sectors (1536 bytes) are reserved for storing configuration information. The information is stored as a standard gzip compressed tarball; tar has enough per-file overhead that 1024 bytes is not enough space to fit two compressed files (one for configuration, one for a SSH private key that someone may have).

I could not test DHCP this weekend because my laptop doesn't have an ethernet card compatible with MOOF's drivers (it's a PCMCIA NIC). I will fix things probably on Wednesday (I'm working really hard both Monday and Tuesday).

- Sam

MOOF (MaraDNS on one Floppy) update

---

After finding some fairly serious bugs testing MaraDNS on one Floppy yesterday, I stayed up until 2am workong and MOOF, and released MOOF 0.3 today. First of all, the Linux kernel has been updated from 2.4.33.3 to 2.4.34.2. This is a minor security-only update.

I also tried updating Dropbear from 0.48.1 to 0.49, but about 45 minutes before I had to leave for work, I discovered that Dropbear 0.49 uses large (> 2GB) file support. So, I quickly regressed Dropbear back to 0.48.1 and repackaged MOOF 0.3. It was the fastest release I think I've ever done.

I managed to make the kernel smaller by using advancedcomp to shrink the compressed kernel image. I also removed support for the /proc/bus/usb; the 30k or so of space this code uses is not needed for basic USB "keychain" storage device support. Since I had quite of free space at this point, I added some Busybox goodies, such as awk, traceroute, and du.

I also wrote a tiny little 4-function calculator in C that uses floating point numbers and does basic left-to-right parsing. The stripped binary is under 3 kilobytes in size.

Anyway, I it's interesting how a number of blogs are proclaiming that the floppy disk is dead. With new developments in the open source world--Busybox, for example, there is still some life left in the floppy disk. Indeed, I can fit all the code needed for me to upload new software releases on a single floppy today--indeed, this is exactly how I uploaded MOOF 0.3 today.

Anyway, I have to go. MOOF is at http://www.samiam.org/moof

- Sam

MaraDNS on one Floppy

---

In order to give MaraDNS some more publicity, and to generate more interest in this program, I have made a special customized embedded distribution of Linux designed to show how small MaraDNS is. The entire distribution, including MaraDNS, drivers for most common ethernet card and boards, a SSH and SCP client, and support for USB flash devices, fits on a single floppy. The distribution consists of Linux 2.4.33.3, Busybox (for most of the *NIX environment), Dropbear (for the SSH and SCP client), and, of course, MaraDNS.

This distribution barely fits on a single floppy; I had to use the AdvancedComp tool to make the root image small enough on a single floppy with the kernel, with only a little over a kilobyte to spare. There's only about a kilobyte between the kernel and the root image, and very little between the end of the image and the end of the floppy--I want to reserve the last 512 bytes on the floppy for storing and loading configuration information, so people with static IPs don't have to retype their IP every time they boot from this floppy.

MaraDNS is, to the extent of my knowledge, the only open source full-fledged DNS server small enough to be part of a one-floppy self-contained system.

Check it out here:

http://www.samiam.org/moof/

- Sam

MaraDNS update: TTLs are messy

---

TTLs are very messy in BIND zone files. Sunday afternoon, I worked on the bind2csv2 script to handle BIND's somewhat unusual handling of TTLs when the SOA record has a TTL (see previous blog entires for the gory details). Well, when I was doing TTL testing Sunday, I realized BIND has another wrinkle with TTL setting:

• All NS records have the same TTL
• This TTL is determined by the TTL of the last record in the zone

So now I have to kludge in some code to set all of the TTLs for NS records to have but one TTL: The TTL of the last record. Now, why BIND uses the TTL of the last record in the zone file instead of the first record is a mystery to me, but it makes writing the script more difficult.

I'll probably have to kludge the TTLs when people put delegation TTLs in BIND zone files.

Come to think of it, I see no reason to implement this for the moment. People should use the same TTL for all NS records; if they don't, well, they should fix their zones.

So, yes, this is a known "bug", but I think it's more important to handle BIND's handling of backslashes in TXT records. Another issue: I should add support for the NAPTR record type (someone asked for this late last year)

Anyway, the snapshot has been updated. Check it out
- Sam

Update on BIND zone file format

---

Well, it would seem that BIND acts a little unusual with its zone file format. In more detail, here is how BIND sets the TTL for a record without a TTL:

• If the SOA record has a TTL, use the TTL of the last record with a TTL
• If the SOA record does not have a TTL, use the "SOA minimum" TTL

The bind2csv2.py script correctly uses the Minimum TTL as a default TTL when the SOA record doesn't have a TTL, but doesn't correctly handle the case when the SOA record does have a TTL.

Also, the backslash handling in BIND TXT records is somewhat bizarre; \\ in a TXT record becomes two backslashes, not one backslash. So, I have to do some more backslash testing.

One very positive experience that I have been having while working on this is how nice Python is to work with. Python makes is very easy to make clean, maintainable code. I have been able to make fundamental changes to this script without too much effort, and still keep the code very clean.

---

OK, I have one uncnfirmed report that the 1.0 branch of MaraDNS may have a round robin rotation bug. The person who sent me the bug report is unwilling to give me his real mararc file and zone file that supposibly has this bug, so I am unable to reproduce this bug or even look at the zone file to see what may be causing the bug.

The reporter claims that MaraDNS 1.0.39 will incorrectly rotate a CNAME record from looking like this:

cname.domain.foo. CNAME a.domain.foo.
a.domain.foo. A 10.1.2.3
cname.domain.foo. NS ns1.domain.foo.
cname.domain.foo. NS ns2.domain.foo.
cname.domain.foo. NS ns3.domain.foo.

To looking like this:

cname.domain.foo. NS ns1.domain.foo.
cname.domain.foo. CNAME a.domain.foo.
a.domain.foo. A 10.1.2.3
cname.domain.foo. NS ns2.domain.foo.
cname.domain.foo. NS ns3.domain.foo.

Now, I've looked at the relevant part of the udpsuccess() routine in MaraDNS.c, and, well, this can't happen. Not the way the reporter described it. So, I can't fix this bug without more information.

So, I'm asking the MaraDNS community for some help here. If this is a problem you have seen, please send me a copy of your mararc file and a copy of your zone files via private email. Then I may be able to reproduce and address this possible bug.

In the meantime, the workaround is to disable round robin rotation by adding the following line to one's mararc file:

max_ar_chain = 2

- Sam

MaraDNS snapshot update: bind2csv2.py finished

---

OK, I've released a new snapshot of MaraDNS 1.3 today, a 2007.04.02 snapshot.

I have finally finished the bind2csv2.py script. My plan was to finish this script Sunday morning, then spend the afternoon enjoying the town. Alas, adding $ORIGIN and $TTL support was harder than I thought. The problem is this: Since bind2csv2 needs to rearrange the records, what happens when the default TTL or origin changes for a record we put elsewhere in the zonefile. Well, what needs to be done is to have the code add the explicit new TTL information to a record placed elsewhere in the file. I needed to rework a good deal of the design of the class in bind2csv2 to handle this change.

Once I did that, I was finally able to have it so rearranged records will have the correct origin or TTL information.

The next thing I had to do was add support for the last few record types, LOC, WKS, NSAP, and PX. I took the easy way out: The bind2csv2 parser does not check the syntax of these records. Records of this nature that have syntax errors will not have the errors caught until parsed by the csv2 parser.

I figured out how BIND parses backslashes in TXT records, and modified the bind2csv2 script to convert BIND-style backslash sequences in to csv2 backslash sequences. This code works, but I really need to polish it up a bit to make cleaner converted zone files in certain corner cases.

After doing all that, I set up BIND and started work comparing the zone file generated by the native BIND zone file and how MaraDNS parses a converted zone file. When doing this testing, I discovered a bug in the csv2 parsing code. So I worked on fixing that bug. Finally, past midnight, the csv2 parsing bug was fixed and I was able to continue.

Looks like there may be differences between the converted and native BIND zone file. At this point, I realized I had to go to bed in order to prepare for work the next day.

So, it looks like the bind2csv2 script is finished. Now I need to do some more bug testing with it.