Cowell Computer Consulting

If your an administer for an OS X network, you probably know how much time can be saved by creating a package (.pkg) installation versus manually installing the software on each workstation. Many pieces of software use old or proprietary installers vs. packages, so building a package can take a little patience. That was the wind up, here's the pitch.

Building packages just got a lot easier with the snapshot feature in the newest version of packagemaker. Start the snapshot recording by choosing 'Add Snapshot Package...', run your installation procedure of whatever software you want to make into a package, and when you stop it will show you what files have changed.

How is this magic done ? Spotlight keeps track of which files to reindex by adding hooks to all the low level write functions on the disk. You update or create a file and the OS knows that it needs to be reindexed. There's now a public framework called fsvents that keeps track of all file operations. So, all packagemaker needs to do is hook into that for the duration of the install.

(This is also how timemachine knows which files to back up on your computer without scanning your whole disk)

Check outArs technica for a more detailed explanation about how fseventsd. http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7

Once the snapshot is generated you have a chance to choose which files you want to include in the snapshot. Remember that files besides the installer will change during the period of the install. For example logs will be updated, but you definitely don't want to include those.

That's it. Much easier than manually collecting those files.

Posted by Luke Cowell on December 14, 2007 at 09:17 AM

Previously, I had written about what you can do with a soekris. I did get everything working as it should and it was pretty interesting. I'd unplug the unit and watch that it would flawlessly start up again. This is important because there's no screen hooked up to these and if the filesystem were to become dirty, login requires a null modem cable, which not everyone keeps handy.

Goals:

• can be safely unplugged at any time
• can receive commands from web or sshd

I thought that I had achieved my goals and all I had to do was put a web server on there. Lighttp seemed like the best bet, being pretty compact, but I was quickly realizing that 64MB wasn't going to be enough space to fit everything into.

What I've opted to do is have the / filesystem still load up with the kernel into memory in rw mode and have /usr mount off the card in ro mode. Lock and temp files are written to /tmp + /var under /.

The only pain in the butt about this is that if you want to make a change to the system you must connect a null modem cable and do the following.

shutdown -t now
umount /dev/wd0a
mount -rw /dev/wd0a

This isn't a major problem as there are rarely going to be changes that need to be made. I the next iteration of this project I am going to divide the card up into several partitions.

wd0a rw   /         25MB    kernel is read of this partition. Completely volatile.
wd0e ro   /usr     200MB    all our userland stuff
wd0f rw   /data     10MB    special

/data would be mounted after startup by an rc script. This is important because /data could be dirty and could impede startup of basic services. /data would also have a rc.local script on it that would be called on startup that would copy files or config, restart services etc.

I've also been working a little with Axis cameras and have noticed that they use an embedded Linux system. I think they use uClinux.

Posted by Luke Cowell on April 22, 2007 at 02:05 PM

What do you call a 486 with 64MB of RAM that’s roughly the size of a small book ? A Soekris 4501. These units are equipped with 3 ethernet ports, a mini PCI slot, a full size PCI slot, a Compact Flash slot and 2 serial ports. The second serial port would need to be wired up manually.

It’s been interesting figuring out the best way to configure this. The simplest route is to just treat the CF card as a HDD. This works well with a couple of exceptions:

1. Powering the machine off without properly shutting it down can lead to a dirty disk, which could mean that you’d need to intervene with a console the next time it starts up.
2. I haven’t read anything conclusive, but it’s been said that continuous use of a CF card will drastically shorten its life.
3. Not fast.

The other method is to have the system boot into a ram disk. There are actually 2 ram disks that are created. One is part of the kernel and we would equip it to have a basic set of tools to prepare the second ram disk. The second ram disk is mounted at /usr – nothing too interesting there.

I’ve used FreeBSD for years, but this is the first time I’ve spend any serious amount of time using OpenBSD. I’m really impressed with OpenBSD. It’s so minimalistic, which makes it a perfect candidate for an embedded system, such as this.

The documentation here was very helpful and I’ll let it cover most of the details:
http://256.com/gray/docs/soekris_openbsd_diskless/

The boot process is this:

1. Kernel is read in off the CF card and basic ram disk is created. At this point we are still independent of the CF card, but we can’t really do anything yet.
2. The rc.diskless script creates the second ram disk (/usr), mounts the CF card and copies /mnt/usr off the CF into /usr (on the ram disk).
3. Unmounts the CF card.

This means that if I were to unplug the soekris, unless it’s booting up, it will never be a dirty disk.

I used OpenBSD 4 (vs 3.x), so I had to do some minor adaptations. I also really sped up the development process by using a couple of VMs to be the host/build OpenBSD system and one to be the ‘soekris’.

Posted by Luke Cowell on April 10, 2007 at 10:24 PM