>Message: 13 >Date: Mon, 4 Feb 2002 21:15:11 -0600 >From: David Douthitt <[EMAIL PROTECTED]> >Subject: Re: [Leaf-devel] 2 useful comments from Matt and Dave >To: LEAF Development <[EMAIL PROTECTED]> > >> Further, you can replace the ENTIRE set of files in the >> enclosure without loosing the base concept. > >Note that Oxygen (now) uses root.gz - which is NOT a tar.gz file, but >a gzipped filesystem image, just like the Linux kernel wants... >
And so does Jacques's Bering. As noted everywhere, the binary format of the initial RAM disk is an attribute of the Linux kernel. In early 1997, Cinege was working with 2.0.x kernels and came up with this tar.gz scheme for specific reasons. This made it into 2.2 and early 2.4 LEAF efforts as evidenced by http://leaf.sourceforge.net/content.php?menu=90002&page_id=8 In the concept of an enclosure, I abstract the binary format of the initial RAM disk. The same enclosure is offered in tar.gz and initrd.gz formats, with references to 2.2 and 2.4 kernels respectively. There is nothing preventing cross usage of these files if the user builds the appropriate support in his Linux kernel, a fact that extends beyond the scope of this project as I understand it. Therefore, I believe this is a sane decision and I will stick by it. > >Forgive me - you lost me there. Pull? Push effort? Project synergy? >Reference kits? What? > Mankind is full of talented people and marketers are some of them. When you go to the shopping mall to do your groceries, have your dog groomed, and sip a beer you are attracted to the convenience of having all these shops under the same roof. They pull you in. The traveling salesman ringing every door on your street with a sales pitch for vacuum cleaners is obviously push. LEAF has attained a critical mass and people are naturally stopping by to see what we have to offer. Synergy is the simple observation that sometimes the whole is greater than the sum of its parts. A reference kit is something people go away with (like the data disks you are offering at http://leaf.sourceforge.net/content.php?menu=90000&page_id=6) >> As I plainy wrote in the >> documentation: "I do not intend to maintain an LRP >> distribution just for the purpose of providing an >> environment in which to run PacketFilter." I believe this >> is clear enough. > >True. But one doesn't need to create a distribution to utilize shell >script and create your own firewall scripts. That is how Seawall, >Shorewall, and rcf came to be. All work without a specific >distribution. > Seawall and rcf are products that have a wide exposure to many other environments than LEAF/lrp. They rely on their users to provide everything on their requirements list. As far as I can tell by the attention to details (I may be wrong :), Shorewall is homegrown, with the obvious intent to push LEAF onto the 2.4 bandwagon. Each of these three products needs extremely specific distributions. >It almost sounds as if you are suggesting that a distribution have a >standard set of applications included and a standard set of functions >and scripts so that script writers can depend on certain programs >being there and not worry these same programs will turn up missing. Actually, I am explicitly proposing that the contents of the initial RAM disk be enumerated in an unambiguous way and that the project default store (usually root) be separated from the RAM disk. I am also explictly proposing that the person designing an enclosure be absolutely free to put anything they want in their enclosure and do whatever they want before /sbin/init receives control. Potential users will decide what is useful and not, just as consumers decide which product lives and which dies. Finally, I am explicitly proposing that the person designing yet another way to stick a RAM disk in a kernel be responsible for providing the conversion code from an existing scheme to their new one. It seems to me that I am proposing a lot of freedom for people to try different ideas without having to redo the work all of the time. The word distribution keeps coming back with slightly different meanings, or so I understand. Following my post regarding the conversion of an existing disk, here are the forensics on Charles's Dachstein 1.0.2 floppy: 1) if the instructions were followed exactly, the new root.lrp would contain ipchains 1.3.10, the bridge configuration utility (brcfg), a symlink to /etc/init.d/network (/sbin/net) and the seed for the random number generator (/var/lib/random-seed). root.lrp would also contain /lib/libss.so.2 a library used for system specific ext2 filesystem functions that is not referenced by any of the 43 packages on Charles CD; /usr/sbin/ipfwd, an obsolete (?) utility for routing incoming pptp traffic, /usr/sbin/traceroute which has a (lame) busybox equivalent, and /usr/sbin/icmpinfo. That's it! 2) I decided to modify my own instructions to add the ipchains package separately and to add /sbin/brcfg, /sbin/net and /var/lib/random-seed to the etc package (the file is available here http://leaf.sourceforge.net/devel/scaron/etc.lrp ) syslinux.cfg was modified to read LRP=ipchains,etc,... In plain words, root.lrp is gone for the purpose of this test. 3) Obviously, booting this mechanically converted file still gives me the Dachstein I started with. There are three bugs I am aware of - the enclosure provides a dummy log package if it does not detect log in the LRP= parameter and Charles uses ramlog - in procedure ramdisk.mk, busybox cut complains that the delimiter must be a single character while the author uses both space and tab in his cut command - in procedure /etc/init.d/umountfs, the parameter -n in the umount command is not supported in the busybox 0.60.2 since I did not specify mtab support. Stuff like this will be taken care of in the next maintenance release. However the real question is this: since everything that is Dachstein_1.0.2_floppy_version can be reduced to this single 40Kb file, what is a LEAF distribution and what is a LEAF appliance? I believe we are old enough to see that Dachstein and Bering (and other derivatives) provide "standard" services. Changing the packaging does not alter that. Offering a way to exist out of these "standards" will make LEAF grow. That is what I am proposing. Regards, Serge Caron _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
