On Mon, 11 Dec 2000, Charles Steinkuehler wrote:
> 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.
Occasional comments; at this point anyone may feel free to step up and
smack me around to remind me that I Don't Do Coding Because I'm A Network
Gunky(tm) and I'm making silly assumptions.
> 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.
Ambitious. I take it we're looking to go the route of allowing simple
setup of some serious horsepower server stuff?
> 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?
dnscache might not be a bad idea if we can get around the whole licensing
thing with it...
> 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.
In the case of LRP 2.9.x, why go back as far as 2.9.4? Admittedly, I still
run it, even with all the tinkering I do with other releases on an
occasional basis, but while 2.9.4 was a plateau, I got the impression that
the network.conf and such from 2.9.7/8 is fairly unchanged, or only
minorly changed. Same with the other scripts. (This is one of those "smack
me" points...) Unless I'm being blind, there's not too much reason to go
that far back... I don't object per se, I'm more curious as to why.
> 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.
I recommend LEAF, mostly because it's the name of the project, and any
other necessary subdividing can be done below it. All other things being
equal, we won't need to worry about confusion over whose tree it is. =)
> 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.
I have a thought or two, but not knowing how difficult they'd be to work
with inside the CVS system, I'll refrain.
> 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?
This might better be done with a patch rather than JUST a makefile; that
way we can keep package docs and *.lrp package formats available and
updated without worrying too much; all it would take is a quick
run-through of new package source to make sure that everything can be
patched cleanly still. Then all anyone would have to do is download the
source, 'patch -p0 <./some-LRP-package.patch', and do a ./configure
--enable-lrp && make && make lrp_install and boom they've got the newest
package available, from source, for their LRP/LEAF distro. If LEAF package
maintainers can keep up, it should at most require pulling updates from
the particular package's CVS tree and making sure the patch works; if you
want to get touchy and the patch has a bunch of offsets, run a quick diff
on the base and the patched latest version, and post the new patch. And
that's only if you wanna work hard. =)
> 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.
Erm. Well, personally, I see no reason to do so, as the name rather
accurately states what it is - Eiger with Some serious Frankenstein mods
(just kidding) - and it has the added benefit of name recognition. Things
could get a little odd if someone comes out of the blue with a mod for the
EigerStein Extended Scripts v1.1 or weblet, and we're all sitting there
saying, "Oh, that's Fluorine..." The morass that is the LRP Distro line is
messy enough.
Going forward, I could definitely see renaming it, but keeping a
link/cname/whatever it is under CVS between the two would be most
beneficial. As to a name, how about something nice and viking-like? If I
had even a whiff of artistic talent outside of writing, I'd've already
submitted a logo of Tux in a viking helmet with a floppy-disk or fireman's
badge for a shield...
> 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.
That'd be nice. Your extended scripts are totally bang-up, but there's a
lot of stuff in there that flies RIGHT over my head. Need to start
learning shell-scripting I guess. I believe it's been recommended before,
but I'll point it out again; if there were a way to set things up so that
- using your DHCP code as an example - the only reference to DHCPD and
DHClient in the network.conf scripts consisted of USE_DHClient=[yes/no]
and USE_DHCPD=[yes/no], that would rock. I think it'd lead to a lot less
confusion for people trying to configure things.
> 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! :)
Hey, gotta do something so I don't feel like a lump. =)
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel
