> > 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?
I don't know if I'd go that far. My SCSI RAID system is using 2 gig IBM
narrow SCSI drives in a 486DX2-66 VLB system with an Adaptec VLB SCSI card.
Not exactly a screaming machine by today's standards. I do, however, think
LRP is very useful as a 'thin' application specific server platform, and I
would like to see more flexability when trying to set up thin servers.
IMHO, for any sort of server machine you want high uptime from, you should
run at least RAID1 (mirroring) to prevent a drive failure from taking you
offline for a day or two while you rebuild the machine from backups
(assuming you even HAVE current backup tapes :)
> > Upcoming projects:
<snip>
>
> dnscache might not be a bad idea if we can get around the whole licensing
> thing with it...
IMHO, there is no licensing problem with dnscache. The binaries I
distribute are EXACTLY as created by compiling the dnscache code w/o
modification. The only changes are the creation of a custom startup script
to avoid the requirement of running daemontools. I also believe any
possible question about the appropriateness of the dnscache package would be
cleared up by packaging all of djbdns and daemontools as several LRP
packages. I may do this eventually, if I have enough time. IIRC, someone
was working on this, but I never heard if they finished or not...
> > 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.
The main reason to include 2.9.4 IMHO is for historical reasons. Enough
people are familiar with 2.9.4 (and still run it), that being able to do
things like diff current stuff against the 2.9.4 scripts should come in
handy. Also, as far as I know, 2.9.4 is the starting point for the
'Mountain' branches, which is perhaps the single biggest argument for it's
inclusion.
> > 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. =)
Hmm...that's a pretty decent idea, although it makes the initial creation of
an LRP package harder. I may look at doing this for some of the packages I
maintain, and see how it works.
> > 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.
<sigh> The pitfalls of coming up with a good name :) I don't mind keeping
the EigerStein name, I'm just concerned about placing ALL my work under the
EigerStein label, as EigerStein is really just one distribution. I'll defer
any decisions about this for a while...
> 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...
I like a lot of the viking names...they tend to get used quite frequently
when naming machines/networks (at least with some of the folks I know).
I recently thought of an idea for a logo. Tux would be in the center of a
split image. One side would be a nice pretty forest/meadow/whatever, while
the other side was a raging inferno (forest fire, volcano, whatever). Tux
would be approprately clad with a fireman's helmet, leaf floppy disk, or
something with the leaf logo. If I had any graphics talent whatsoever, I'd
make up an image like this, but my area of expertise is more restricted to
the programming/hardware side of things...
> > - 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.
One of the big reasons my site and distributions are popular, is they are
easy to use. It took me a week to figure out how to get a Materhorn based
firewall running, when all I really had to do was configure network.conf and
load a module for my network card. I figured if I had that much trouble,
there were lots of folks who would use LRP if they could just get it setup.
I would like to see a leaf distribution with more flexible, yet easier to
setup (at least for standard SOHO use) firewall rules / networking
configuration.
Thanks for the feedback,
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
