Building CUWiNware From Source

You can build your own CUWiNware images from the CUWiN sources with your local modifications included. Local modifications that you can make include setting up a default config file, changing the default root password and adding default local users, adding public key authentication for login to the nodes. You can also build against newer NetBSD sources to update the available kernel drivers and if you are a programmer you can freely modify the code as you see fit.

In order to build the software you will need a working NetBSD build environment. Once you have that you will need both the CUWiN sources and an appropriate NetBSD source snapshot.

You can get NetBSD sources either from sourceforge by downloading the cuwin-x.y.z-src-netbsd.tar.gz file or by going to NetBSD's anonymous CVS server and grabbing the CURRENT sources.

You can get the CUWiN sources via SVN from http://svn.cuwireless.net/svn/cuw/trunk/ or from anonymous CVS at sourceforge or by downloading cuwin-x.y.z-src-main.tar.gz from sourceforge. You will also need the src-extern file from sourceforge. The source forge downloads are source snapshots used to make our releases whereas the SVN and CVS repositories have the bleeding edge code.

Once you have unpacked all the sources you should have a trunk/src/boot-image directory. Parallel to the "trunk" directory you can create a "private-trunk/image-data" directory. In that directory you can put in local customization files that will be used instead of the defaults during the build process:

authorized_keys/: This directory contains files named after usernames. The contents of the file are put in the user's .ssh/authorized_keys file within the built image.
cuw_config: This file will be installed at /etc/cuw_config instead of the default.
known_hosts/: This directory contains files named after usernames. The contents of the file are put in the user's .ssh/known_hosts file within the built image.
pwds: This file has /etc/passwd style entries for each user that should be added to the built image. This overwrites the default root password.

When the tree is configured for build as you'd like it, you can call the mkstaboot script to build the sources into an image. The build script is a helper that makes calling mkstaboot easier. The Perl script nightly-test.pl calls build for several different targets and provides a good example for how it is called. Read over the comments in these scripts before attempting to build.

If you need help building CUWiNware please contact cu-wireless-info@cuwireless.net

Anonymous CVS and SVN access

Posted to the mailing list on October 1st, 2004 by Zach Miller.

Please note that anonymous CVS and SVN access are now both available.

Anonymous CVS has been available for some time but until recently updates have been broken.

Anonymous CVS is hosted by Source Forge:

Information: http://sourceforge.net/cvs/?group_id=89823
Web CVS Viewer: http://cvs.sourceforge.net/viewcvs.py/wireless

To checkout use these commands:
cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/wireless login
cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/wireless co cuw-trunk

Don't forget that you should use "cvs update -dP" when updating to make sure you get the right directories in your tree.

Anonymous SVN is hosted on cuwireless.net:
Browseable URL: http://svn.cuwireless.net/svn/cuw
svn checkout http://svn.cuwireless.net/svn/cuw/trunk

Both repositories are READ-ONLY. Please submit patches to this email list for discussion and eventual inclusion by the core developers.

mkstaboot

Posted to the developer's mailing list on January 28th, 2005 by David Young.

I got fed up with waiting 10+ minutes for mkstaboot to run, even with -u -o, so I broke mkstaboot into several stages. Now I can do routine rebuilds---after I modify, say, hslsd---in just 10 seconds.

The new mkstaboot and, by extension, build{,upgrade,iso,flash}, take two new options:

% mkstaboot -h usage: mkstaboot [ ... ] [ -L ] [ stage ] -L List the mkstaboot stages and quit. stage Restart mkstaboot at this build stage.

Here are the build stages, in the order they will be built:

% ./buildupgrade -s ~/radix-nbsd/src/ -L tools toolenv makewrapperenv iso-kernel flash-kernel distrib metalog patch makewrapper mv-root-home extras users modules cuwinize-metalog install postinstallenv flash upgrade floppy iso

For example, if I run "./buildupgrade -s ~/radix-nbsd/src -f disk.img install", mkstaboot will restart at the 'install' stage of the build, skipping all of the preceding stages on the -L list, UNLESS

the stage ends in an 'env' suffix

the stage did not run to completion during the last build

some prior stage did not run to completion

If I do not tell mkstaboot to restart at any stage, then it starts at the beginning.

A few caveats:

I've tried hard to make stages idempotent, but at least one of them ('patch') is not.

I do not (yet) leave out any build stage based on the options. That is, the 'iso' stage will run (although it will be a null operation) even if I don't use an '-i' option.

It is still a good idea to use -u and, if you know what you're doing, -o, as they are indicated, to speed up your build.

Just a few bullets about the architecture of the staged builds:

In steps.d/ are the build stages. They get "sourced" (with '.') by mkstaboot. They are derived from the old mkstaboot sources.

steps.d/deps is a two-column list of stage dependencies: for every row, the stage on the left-hand side cannot be run until the stage on the right-hand side has completed. If you add new stages, be sure to add them to steps.d/deps !

In $BUILDDIR/, mkstaboot touch(1)es .<STAGE-NAME>.begin when a stage begins; it touches .<STAGE-NAME>.end if and when the stage finishes successfully. Next time you run a build, if .<STAGE-NAME>.end is newer than .<STAGE-NAME>.begin, then the stage ran successfully.

POSIX touch(1) has a time resolution of 1 second. Therefore, the shell command "touch a ; touch b ; test b -nt a && echo yes" does not necessarily yield the string "yes". Sometimes it's necessary to sleep for a second before touching .<STAGE-NAME>.end. Sleeping synchronously will slow the build by a lot. So mkstaboot sleeps in the background. Hence the "joining pid xxx" messages at the end of a build.

step.subr contains most of the logic for deciding which build stages to run, when.