A not-so-brief general status update, and list of things I intend to tackle
by the end of the month. Please read if you want input on the general
structure of the leaf site, as I intend to begin creating CVS directories
for various LRP/Leaf related stuff.
Current work:
I am currently working on re-building my web-server using mirrored SCSI
drives. Towards this end, I am updating my HDD-HOWTO to include details on
booting from devices not supported directly by the kernel (initially
implemented for my LRP-CD project), I have created a new kernel branch which
includes the current RAID code (and have compiled the raidtools V0.90).
Details on setting up LRP to boot on SCSI and creating/mounting RAID
partitions will be added to the HDD-HOWTO.
Upcoming projects:
I plan to migrate the following scripts into CVS repositories on the Leaf
Source-Forge site:
linuxrc
lrcfg and related scripts
POSIXness (/bin/grep in 'mountain' releases)
weblet
network config scripts
Others?
I intend to fold all existing versions of these scripts into CVS, starting
with LRP 2.9.4, and including the 'mountain' releases, and my customized
static/dynamic/eigerstein versions as branches to the 'main' 2.9.4-8
timeline.
I currently plan on making each of the items listed above separate CVS
modules. If someone has a better and/or different suggestion, please let me
know. The location of these directories is also subject to debate. Current
options for the top level directory that seem to make sense: LRP, Leaf,
cstein, eigerstein. I am leaning towards leaf or lrp as the top level
directory.
At this point, I don't know if leaf development to any of these scripts
would be continued in the same CVS tree, or as a separate project entirely.
It seems to make sense to keep development in the same tree, either as a
mainline update or as a branch. If anyone has a preference here, let me
know.
Once I get the historical information in CVS, I plan on migrating some
updates into the codebase that could be considered preliminary leaf
development. Several of these updates already exist, between work David D.
and I have done, but I would like things 'cleaned up' somewhat, and the code
merged into CVS. At this point, I would like to have a clearer
understanding than I do now about exactly how we would like to organize
development of leaf (or the many flavors of it, if that's what's going to
happen).
Other upcoming tasks include updating/creating some new LRP packages based
on the work I did while at corporate HQ in San-Antonio last month. This
also brings up the issue of how best to deal with hosting package
development on the SF site. Generally, you simply have to compile the
latest code (dhcp, bind, et-al) on the proper platform (debian slink or libc
equivalent), but there are often several 'tweaks' required to
startup-scripts, stripping of binaries, and other such things that might be
appropriate to archive on SF. I would welcome any suggestions about how
best to do this...perhaps a makefile or similar that would create the LRP
package from the compile directory?
Finally, I would like to move away from the use of eigerstein as a top-level
name/definition. The use of the EigerStein name stops making sense as I
migrate historical Materhorn content into CVS and migrate parallel Eiger
versions (static & dynamic) to SourceForge alongside the existing EigerStein
versions already there. The immediately obvious alternative is to use
cstein, but this does not properly relate the concept that other developers
are welcome to contribute. Perhaps I need a name like David D's Oxygen
(maybe Fluorine...I'll see your 3.44 electro-negativity and raise to
3.98...or is that 9 electrons to your 8? :) Any thoughts on this are
welcome, as I would like to begin work on a leaf distribution based on a
combination of 2.9.8, Eiger, and quite possibly some of the latest stuff
David D's been compiling for Oxygen.
My goals for constructing a leaf distribution would be:
- Support for booting from any media supported by linux w/o kernel
re-compiles
- Support for root on a ramdisk, hardisk, or other media
- Support for Read-Only boot media, with configuration information stored on
an alternate writeable media (ie floppy, flash disk/array, etc).
- Inclusion of default firewall scripts allowing easy configuration of a
'typical' firewall, without interfering with the ability of advanced users
to configure complex setups. Either a modified 'Materhorn/Eiger'
script-set, or perhaps the sea-wall package would work here.
I will have more specific questions & updates as I actually get around to
creating the CVS trees, and updating scripts to add some advanced 'leaf'
functionality.
If you got this far, thanks for your time! :)
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
