[Leaf-devel] Developer account
Hello all, I would like a developer account with LEAF. My sourceforge user id is 'scaron' (don't know the digital id yet). My contribution is twofold: 1) PacketFilter, a tool used to transform a PC into a custom made networking device. There is an abstract at the end of this message. 2) I would like to innovate in the packaging of these Linux appliances. PacketFilter is nothing more than a network setup script written for the LRP environment. However, it is packaged separately of the traditional root.lrp, etc.lrp, blah.lrp, ... :). By separating the enclosure from the appliance, you get the benefits of a robust base that can be maintained independantly of the application which receives control from init just as in the actual arrangement. This separation allows for the reuse of the application with updated versions of the enclosure and reuse of the enclosure with updated versions of any and all appliances. Regards, Serge Caron 2. Abstract This document presents a tool, PacketFilter, which you use to configure a dedicated PC system into a custom made networking device, the MultiPurpose Gateway (MPG). The primary focus of the project is the rapid deployment of a robust solution for which the building blocks are bridging, routing, and Network Address Translation (NAT). Typical deployment of a solution is 5 to 10 minutes once all the hardware is assembled. At the IP level, the standard MPG configuration handles the ICMP, UDP, and TCP protocols as well as the payload for the PPTP and L2TP/IPSec AH and ESP protocols. By design, the MPG does not participate in the authentication/encryption mechanisms of these protocols. If you do not provide an IPSEC server, you must route (or NAT, if applicable) to the appropriate server the key exchange required by any of the secure protocols. As its name implies, PacketFilter sets up filtering rules to drop unwanted IP traffic. These rules are applied to every network segment and PacketFilter does not assume a networking model where most of your IP traffic is outward bound to the Internet. PacketFilter can setup for the MPG a DHCP server and/or a DNS server/forwarder and/or a (small) PPP server. If you elect to use one, the MPG can use a DHCP client, a PPPoE client, a PPP client, and/or static allocation to setup a default route. By allowing more than one of these methods, you have an automatic fallback configuration for your MPG. Designed as a framework for your custom solution, you can edit all aspects of PacketFilter to extend the software to satisfy your own needs. This facility is available from the first boot. before the software even ran once, and is menu driven to ease the operation. PacketFilter is packaged for the Linux Router Project (LRP), an environment that is designed to operate from a RAM disk. A Linux kernel and all of the above software can be loaded from a single bootable diskette, which can be operated read-only to enhance the security of your installation. No hard disk installation is required. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Introduction
Greetings, All Mike Noyes has a charming way of getting newbies to introduce themselves to the group. Who would think that such an innocent request is just as loaded as ... well you know what I mean. When I first laid eyes on a computer, I was seventeen years old. I know, I know it's kind of late but you have to understand: the year was 1970. The fact that I am still programming all kinds of things makes me a living dinosaur! I still have the same girlfriend, which must make me a lovable beast, but I did pick up four kids that somewhat slowed down my coding :-) . My contribution to LEAF, for now, is PacketFilter, available at http://leaf.sourceforge.net/devel/scaron. PacketFilter innovates in its packaging by referencing a base LEAF (LRP) distribution that should be loosely common to appliances such as PacketFilter. For now, the bootdisk contains a verbatim copy of Charles's Dachstein 1.02 root,etc,log,local files. By reusing a common enclosure for several appliances you get a faster development cycle. In this instance, PacketFilter is packaged as an appliance on top of an appliance. PacketFilter itself is not bad :-). If you use it as is, you can manage as many NICs as you can fit in the box in a combo bridge/router/NATer of your choice. So the next time you say the router will be up in 15 minutes, it will only be TWICE that time :-)... However, the software is designed to be transformed into something custom made and allows various facilities expected a development environment. It is still LEAF and it can and should use all the LRP packages out there. This was my primary motivation for writing it in the first place. As you can see by how this introduction shifted from me to the product, I am a project oriented person. I look forward to all your comments. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Ticker script
Actually, I DID try it! (ROTL) The lrcfg.back.script that comes with standard Dachstein has 5 references to ticker (2 invocations and 3 killall). Obviously, the 2 invocations do not contain the blessed that will fork the new ticker script. Implicitly, the killall will not work either. I don't mind changing these or any other script but this solution is not *entirely compatible* with the old one :-). I do welcome the savings and I will go with the paranoid solution. Serge Caron -Original Message- From: Charles Steinkuehler [EMAIL PROTECTED] To: Serge Caron [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: January 24, 2002 9:44 AM Subject: Re: [Leaf-devel] Ticker script 1) How do you fork this thing so that, for example, you can do a backup? Just like always from a shell script: ticker 2) Using the shell will creat a job (typically sh /usr/sbin/ticker) that will not be recognized by the killall ticker command. Actually, it does work (try it and see), but if you want to be paranoid, and not trust killall, a simple: ticker PID=$! ...more stuff here... kill $PID Will work as well... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] A new look on LEAF components
Hello everyone, It is always best to put your money where your mouth is :-). PacketFilter v1.71 was released over the weekend promoting a new packaging concept explained at http://leaf.sourceforge.net/devel/scaron/leaf.htm This is a maintenance release for PacketFilter wich was piggybacking (?) Charles's Dachstein floppy release. In fact, PacketFilter itself is unaware of the change, except for the display of the string Linux Embedded Appliance Firewall in the menu. Please note that this is an existing trend: Jacques Nilo is already distributing Shorewall independantly of his Bering distribution. The page above formalize a way to package an appliance such that it is possible to substitute one LEAF environment for another without touching the appliance. The page provide start-up kits and define how Mike, Arne and Ewald could create a replacement kit that would not break the appliance. If such were the case, a developer would now have a choice of kits, each abstracting different kernel versions. This is an interesthing growth path, especially when evaluating competing proposals. From reading this page, it becomes obvious that the LEAF project needs a librarian, a package repository, and a distribution point for prebuilt kernels. Hint, hint, hint anyone? My personnal developer page also points to this page, just to see if I will get some comments from the general public. The teaser is a LEAF workstation, an appliance that should generate some interest in what else this project can offer. I do hope that Charles, David, and Jacques will comment on this proposal. I have experimented at length with both Dachstein and Shorewall to make sure that this implementation did not impact either project in any way. It has been my experience that lrp files are communicating vases and, in fact, each of these project ends up with exactly the same files packaged a different way. For those of you that want to experiment with different libraries, the PacketFilter lrp package contains no binaries. Between the PacketFilter bootdisk and the LEAF workstation, the following packages are used: ipchains, dhcpcd, ppp, pppoe, libz, ssh, bindc, dhcpd, brctl, rrlogind, and whois. Therefore, if your move to different C libraries is equivalent or better, you won't even have to edit anything on the boot disk: just replace the file LEAF.lrp and go! It will be interesting to see the impact of moving away from glibc 2.0.7 will have on the LEAF project. This proposal benefits everyone without limiting what any individual may do, user or developer. Regards to all, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Program sources for ticker, watchdog, ipfwd
Someone (Richard Doyle?) asked about 10 days ago for the sources of the
ticker program.
The archive 2.9.4-sourcesnapshot.tar.gz, dated May 29, 1999 at
ftp://ftp.linuxrouter.org/linux-router/old/2.9.4/source/
contains the sources for ticker, watchdog, an ipfwd as well as the original
of the binaries found in Dachstein, Shorewall, etc.
I believe ipfwd is now obsolete. I may be wrong :-))
The watchdog code is almost identical to the busybox watchdog code.
Which gave me this silly idea: follow the sequence. If anybody is interested
in this new busybox ticker applet, I will post the diff on my page. However,
this may end up in the next official release of busybox. :-))
Cheers!!!
From: Serge Caron [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: LEAF and ticker
Date: Sun, 3 Feb 2002 15:51:12 -0500
Dear busybox :-),
The Linux Embedded Appliance Firewall project at http://leaf.sourceforge.com
is actively using busybox for all current releases.
It is with tongue in cheek that I submit this busybox applet, ticker, for
which we have been budgeting 3Kb since the early release of the Linux Router
Project. It is about time this ticker got a lick.
Ticker is just a warm fuzzy feeling that just won't die and I thought I'd
pass it along.
Cheers,
Serge Caron
Return-Path: [EMAIL PROTECTED]
Received: from dsl-212-23-14-12.zen.co.uk ([212.23.14.12])
by tomts14-srv.bellnexxia.net
(InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP
id
[EMAIL PROTECTED]
.uk
for [EMAIL PROTECTED]; Sun, 3 Feb 2002 19:07:51 -0500
Received: (qmail 8508 invoked by uid 0); 4 Feb 2002 00:07:46 -
Received: from hyperspace (HELO linuxhacker.org) (192.168.0.1)
by alexholden.net with SMTP; 4 Feb 2002 00:07:46 -
Message-ID: [EMAIL PROTECTED]
Date: Mon, 04 Feb 2002 00:07:46 +
From: Alex Holden [EMAIL PROTECTED]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226
X-Accept-Language: en-us
MIME-Version: 1.0
To: Serge Caron [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: [BusyBox] LEAF and ticker
References: 000b01c1acf4$8557b540$840a@piglet
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Serge Caron wrote:
It is with tongue in cheek that I submit this busybox applet, ticker, for
which we have been budgeting 3Kb since the early release of the Linux
Router
Project. It is about time this ticker got a lick.
With tongue also held firmly in cheek I humbly submit a version which I
found to be 96 bytes smaller :)
#include stdio.h
#include unistd.h
int main(void)
{
int i;
char c[] = {'.', 'o', ':', 'O', ':', 'o'};
switch(fork()) {
case -1:
return -1;
case 0:
setbuf(stdout, 0);
putchar(' ');
while(1) {
for(i = 0; i sizeof(c); i++) {
putchar('\b');
putchar(c[i]);
sleep(1);
}
}
}
return 0;
}
[cue frantic attempts to beat me by another 100 bytes]
--
Alex Holden - http://www.linuxhacker.org
If it doesn't work, you're not hitting it with a big enough hammer
From: Serge Caron [EMAIL PROTECTED]
To: Alex Holden [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [BusyBox] LEAF and ticker
Date: Sun, 3 Feb 2002 19:35:35 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Dear Alex,
Lester B Pearson once said Diplomacy is the art of letting other people
have it your way. :-))
I am glad to see that the busybox community has the greatest sense of humor.
I will report to the LEAF project that their flagship product, ticker, is
now mainstream busysbox and has found a champion in the person of Alex
Holden.
Best regards,
Serge Caron
PS: You can keep the 96 bytes :-)) ROTFL
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] 2 useful comments from Matt and Dave
I find the following comments useful: Message: 9 Date: Sun, 03 Feb 2002 23:51:01 -0800 From: Matt Schalit [EMAIL PROTECTED] Subject: Re: [Leaf-devel] A new look on LEAF components To: [EMAIL PROTECTED] [snip] Are all LEAF's now and in the future packet filters? Message: 10 Date: Mon, 4 Feb 2002 06:32:53 -0600 From: David Douthitt [EMAIL PROTECTED] Subject: Re: [Leaf-devel] A new look on LEAF components To: LEAF Development [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] [snip] It's a shame that you didn't try Oxygen 1.8.0. You would have found quite a few differences that were not in the packaging. Matt's quite right; Oxygen is probably the furthest away from its LRP base. Some quick examples of the most dramatic changes (as defined by current development): [snip] I'm not sure I understand how your project is supposed to work. -- Without presuming on what I did (or did not) try, the concept of an enclosure does not favor any particular design, developer choice, or look and feel. What it does promote is a facility for moving from environment A to environment B, be it Oxygen or Dachstein or whatever. You are quick in making a distinction between Dachstein and Shorewall, the later being a commodity in the context of your sentence, if I understand correctly. There is no guarantee to Joe User that happens to like Shorewall enough to build on it for his own needs that he will be able to move his stuff to a cool new environment like Oxygen. On the other hand, the ordinary sysadmin that can write a script without feeling the urgency to rewrite the entire LEAF effort will find the concept of an enclosure usefull. After all, HER stuff is protected and she is one quick cp -a root.lrp ... away from moving to something else. Further, you can replace the ENTIRE set of files in the enclosure without loosing the base concept. Finally, it does promote some social responsibility. If LEAF provide a package repository, it creates a pull effect, that is a center of attention were everybody can go to find something. If it also provides reference kits (bootdisk, kernels, modules, whatever) it suddently has a broad offering as well as sharing the experience of working with these different environment, be it glibc 2.1.x or MacIntosh processors. If Charles, Jacques, or David create a distribution, it creates a push effort that lacks the LEAF project synergy. I believe there is room in this project for people who will take a base kit and come up with something that has nothing to do with the LEAF internals. Maybe Lynn has a redundant router project to share or somebody else has Dead Gateway Detection. There is no easy way for them to create this appliance unless they conquer the difficulty of providing their own boot disk, startup code and the like. In contrast, the person making a nmap.lrp package, for example, has a rather simple and well defined task. I do hope that somebody will provide alternate enclosures. That is the purpose of the effort. Better libraries, better menus, better support for typical embedded devices like flash disks, etc. Not only do I agree that POSIXness and silly kernel patches must go, I expect people creating enclosures to document each aspect of building of boot image in the comfort of their user's computer. This is Linux and people are also expected to work from source. PacketFilter is just a network setup script designed to drop IP traffic. Yet it is usefull enough to build a small workstation, an unforeseen benefit. 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. I am sure other people with something worthwhile to contribute will appreciate the support of the LEAF project. Let's make it easy for them to do so. Regards Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Magic recipe
Someone asked me for instructions on how to convert their existing installation to this enclosure concept. Here are instructions for 1680Kb floppy disks based on *stein, LRP, Bering, etc. It does not work for derivatives like Coyote Linux and others that changed the lrp extension into tgz. It does *not* apply to Oxygen releases. Please adjust the following instructions for your own boot medium. These are mechanical instructions that do not take into account potential differences in the actual binaries in use before and after the move. It does not alter you kernel, modules, or other packages on the disk. They simply give you your old disk back in the new packaging. Please exercise your best judgment before flaming me :-)) 1. Download the startup kit from http://leaf.sourceforge.net/devel/scaron/leaf.htm appropriate for your kernel. (2.2 or 2.4 depending on whether you have Cinege's kernel patches or not) The busybox in the 2.2 enclosure has a lot MORE applets than the one for 2.4 kernels. Such is life. 2. Boot this disk, log in as root, and take the disk out of the drive. Exit the menu system, edit /var/lib/lrpkg/backdisk and delete the line for the root package (it should be the second line). 3. If you don'thave a backup for your LEAF/LRP disk, now is the time to make one (use lrcfg to make one). 4. Type the following commands to install your old root and etc packages: mount -t msdos /dev/boot /mnt cd /mnt lrpkg -i root lrpkg -i etc cd /var/lib/lrpkg touch root.conf cat root.net.conf root.conf cat root.sys.conf root.conf cd /root umount /mnt 5. Use lrcfg to backup root and etc to your disk. root will probably shrink to less than 10% of its initial size. 6. Place the startup kit in the drive and type the following (notice the capitalization of the word LEAF :) mount -t msdos -r /dev/boot /mnt cp -a /mnt/LEAF.lrp ./ umount /mnt 7. Place the target disk in the drive and type mount -t msdos /dev/boot /mnt cp -a LEAF.lrp /mnt sync edit /mnt/syslinux.cfg 8. replace the initrd=root.lrp with initrd=LEAF.lrp and make sure the LRP parameter reads LRP=root,etc,... There may be more than one occurence of initrd and LEAF if your disk support multiple configurations. Save the file. 9. Type sync umount /mnt 10. Hit the reset button and watch the results. The old menu is now available under the Packages menu, option root. This is *not* perfect but it gives you a proper idea of the actual change. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Useful comments from Dave
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
[Leaf-devel] Re: Useful comments from Dave
analysis with Bering, for example, and come up with similar results. Automatic loading of packages was proposed in 1995 why doesn't Dachstein do this? Please take this up with Charles. I believe we are old enough to see that Dachstein and Bering (and other derivatives) provide standard services. Still sounds like a Base System Standard - that is, standardizing on what binaries are available after the smallest possible number of packages are loaded - and where they are. How does your proposal compare to the Linux Filesystem Standard (LFS) and the licensing used by the author of djbtools and qmail? If you are trying to specify exactly what root.lrp (root.gz) includes - Oxygen is a good example of why that can't work. Oxygen includes in root.gz: [snip] As a matter of fact, the proposal is painfully clear that the contents of an enclosure is *NOT* specified. However, whatever the designer places in it *MUST* be explicitly enumerated. Design your RAM disk as you see fit! Just provide an unambiguous enumeration of its contents. If I had to guess, I would say that it will probably be a good while before Dachstein or Bering remove these from their root archives. As you can see from the transition from LEAF v5.0.0 to v5.0.1, things are being deleted without touching anything in either of these two distributions. It is up to these authors to try the concept or not. One thing that I find mildly amusing is that people are confused because the feature set is never specified. The busybox in the v5.0.0 tar.gz version (2.2 kernel) had much more applets than the one in the v5.0.0 gz version (2.4 kernels). So in v5.0.1, the feature set is the same in both versions (but still unspecified :). What I WOULD like to see (maybe I can do this...) would be a script analyzer or testbed that would pull out all commands that were needed by a script and analyze them against a running LEAF to see if the LEAF provided everything that was necessary. Testing options would be nice too, to see that a script would work in a LEAF environment.. -- That will be a positive contribution to which I look forward to. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Preferred package/filesystem location ???
Message: 7
Date: Thu, 07 Feb 2002 19:32:40 -0600
From: Michael D. Schleif [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Organization: mds resource
To: LEAF-dev [EMAIL PROTECTED]
Subject: [Leaf-devel] Preferred package/filesystem location ???
Is there some kind of standard whereby, when building a new LEAF
package, we know *where* particular files belong?
[snip]
If there isn't a standard, there *SHOULD BE* -- no?
What do you think?
busybox tar uses (usually GNU's) fnmatch with FNM_PATHNAME | FNM_LEADING_DIR
flags
and the exclusion list as a PATTERN, not a node name. This tar uses the
exclusion list in a peculiar way for relative paths by matching the tail end
of the file name (that is etc/modules matches boot/etc/modules).
Fortunately, all LEAF backups are done relative to root and all package
lists are concatenated in a single list. It is easy to force relative paths
for everything on both sides (inclusion and exclusion lists) and therefore
ensure a proper comparison. This takes into account Charles partial backup
lists where files from a package are excluded for a partial backup and
included for a full backup.
We are left with two cases:
1) the user is doing a backup for some other package than yours and your
package .list has an entry that reads some/dir without trailing / or /*.
busybox tar will not back up anything from some/dir regardless how the other
package is speced.
2) the user is doing a backup for your package and you are at the mercy of
evil.lrp :-) such is life.
The small diff below applies to every package including the initial RAM disk
and then processes the RAM disk separately. This later idea is from Jacques
Nilo's Bering code and works very well also.
If you don't process the RAM disk separately, then you must use ctar which
normalize node names relative to /. Dachstein 1.02 always uses ctar, for
example. Bering beta 3 uses ctar for everything and busybox tar to extract
to the RAM disk. ctar is an optional package in Oxygen 1.8. Unfortunately,
busybox tar is used if ctar is not installed and node names are not
normalized before being passed to busybox tar: You will get strange results
if some other package has a filename that matches the end of one of yours.
Also, when ctar is not installed, you will also destroy root.lrp because
nothing will match ./* and the resulting tgz file will contain all of your
filesystem.
I think the need for the standard you are seeking becomes less urgent once
you enumerate explicitly the files in your package and you enumerate
explicitly the directories that you claim for this package.
The rest belongs to the backup code. YMMV. I no longer uses ctar and make
sure everything I specify is as explicit as possible. Dropping ctar changes
the way the backup is done for the initial RAM disk if using LRP kernel
patches.
Regards,
Serge Caron
___BEGIN DIFF__
diff -urN before/lrcfg.back.script sbin/lrcfg.back.script
--- before/lrcfg.back.script Fri Jan 25 11:02:22 2002
+++ sbin/lrcfg.back.script Wed Feb 6 10:40:16 2002
@@ -4,6 +4,7 @@
#Linux Router Project
#
# Seriously hacked by Charles Steinkuehler
+# Mildly hacked by Serge Caron (Feb 2002): ctar is gone...
if [ $# -lt 3 ]; then
echo Bad call to $(basename $0)
@@ -24,6 +25,12 @@
EXCLUDE=/tmp/EXCLUDE
INITRD=`sed 's/.*initrd=//;s/.lrp.*//' /proc/cmdline`
+# Force relative paths for every node in the list
+filter () {
+sed -e s/^[[:space:]]*//g -e s/[[:space:]]*$//g \
+ -e /^[^./]/s/^./.\//1 -e /^[/]/s/^././1 $1
+}
+
mk_inc_part () {
if [ -r $LOCAL ] ; then
sed -n '/^[iI]/{
@@ -79,11 +86,18 @@
mv $PKGSAVE $PKGLIST /dev/null 21
echo -n Creating $PACKAGE.lrp Please wait:
+# busybox tar uses fnmatch with FNM_PATHNAME | FNM_LEADING_DIR flags
+# and the exclusion list as a PATTERN, not a node name.
+# Therefore, a package can take exclusive control of a directory
+# by specifying only the node name in the package list.
+# This is probably OK for everything except /etc :-)
+# so I force a trailing / to make sure that only dir names match.
+filter $EXCLUDE | sed -e s/^[.][\/]etc$/\//1 ${EXCLUDE}.tmp
+
ticker
cd /
- #tar cf - -T $INCLUDE -X $EXCLUDE| gzip $DIR/$PACKAGE.lrp
- ctar `cat $INCLUDE` -X `cat $EXCLUDE` | gzip $DIR/$PACKAGE.lrp
+ tar -c -X ${EXCLUDE}.tmp `filter $INCLUDE` | gzip $DIR/$PACKAGE.lrp
[ $PACKAGE = $INITRD ] /usr/sbin/lrcfg.back.initrd $DIR $PACKAGE
/dev/null 21
@@ -92,6 +106,7 @@
rm $INCLUDE
rm $EXCLUDE
+rm ${EXCLUDE}.tmp
if [ $WTMP = ON ]; then
___END DIFF
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Standards and due process :-)
crossed my mind to submit it directly to David or Charles. My reflex was to inform Mike and I was saddened to learn that LEAF does not have an official package repository. What do you think? [snip] Dare to fix things before they break . . . Well, Michael, if you really want to humor me, I am sure that you will share your thougths. However, you are NOT under the spotlight here and I will understand if you don't have the interest (let alone the time) to do so. Freedom is something I value more than grown up games. Respectfully yours, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Toys for the dreamers in all of us!
Hardware kits galore with a _real_time_ operating sustem: http://www.zworld.com/ Check out DeviceGate Development kits ! Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
Hello Michael, God! its good to see words like passion in this otherwise hum-drum list. Not only am I not crititical of your position (I entirely support it!!!), I will repeat that you are free to answer (or not) at your convenience and on your terms. And I will respectfully read whatever you publish with interest and passion. Regards, Serge Caron -Original Message- From: Michael D. Schleif [EMAIL PROTECTED] To: Serge Caron [EMAIL PROTECTED] Cc: Jacques Nilo [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: February 13, 2002 12:49 AM Subject: Re: Standards and due process :-) Serge = Serge Caron wrote: I got my first paycheck from a computer center (as they were called then :) in September 1970. You do the math. It is obvious that your message below was heathfelt and the product of a long experience. I respectfully request that you humor me into reading this message to the end. [ snip ] Please, trust that I am not ignoring you and that my passion is, indeed, genuine. I have read your post a couple times and, although I first thought that you are critical of my position, I am interested in pursuing this dialectic. Nevertheless, I am in a bit of a crunch right now and ask that you grant me a brief reprieve until later this week . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
Message: 1
Date: Mon, 11 Feb 2002 23:06:06 -0600
From: David Douthitt [EMAIL PROTECTED]
Subject: Re: [Leaf-devel] Standards and due process :-)
To: LEAF Development [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
On 2/11/02 at 11:31 PM, Serge Caron [EMAIL PROTECTED] wrote:
Here is a sequence of definitions that correspond to what
we actually _do_:
VERY useful!
Thank you. Michael and I enjoy this sort of stuff :-).
[snip]
Translation: root.lrp or root.gz.
[snip]
Translation: etc.lrp also, /sbin/init is configured by
[snip]
Translation: root.gz or root.lrp ...
In answer to a reporter question, Henry Ford said You can have it in any
color you want, as long as it's black. Boy, was he wrong on this one! If
you ignore history, you are condemned to repeat it. Cinege associated a
directory to a package for his needs. This association is _not_ cast in
stone and is in fact harmful in some situations.
You may think it is silly to put kernel and packages in ROM, for example.
Charles, Lynn, Mike and the gang are working very hard to come up with a
write-protect switch because there is a need for storage capacities larger
than a floppy AND physical protection that CANNOT be tampered with over the
wire. This is a simple situation and it is easy to understand that failure
is not an option.
By formulating the concept of a default store and that of an exclusion list,
here is _what_I_do_today_ : I boot from a CD which gives me all the storage
I need for the job at hand. I define my default store to be on the _floppy_.
So far, so good? Then I have this code snippet as part of the boot sequence:
for pkg in /var/lib/lrpkg/*.list; do
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
cmp -s ${pkg} ${pkg}.light
if [ $? = 0 ]; then
rm ${pkg}.light
else
echo ${pkg}
mv ${pkg}.light ${pkg}
fi
done
Yes! Every package list that claimed anything in /etc is rewritten! When I
want to backup, I simply remove the write protect tab on the floppy. I can
assure you that it takes a lot of config data to fill 1.6Mb of compressed
space. Further, if the floppy is lost or if something BAD happens, the
machine still boots from the CD: removing the floppy is akin to a master
reset on the memory, not the software. The entire experience is almost
identical to running from ROM. Sharing it will only improve the process. For
example, the enclosure can CREATE on the fly an empty package if the default
store is not specified. See the discussion.img floppy that is idling
somewhere.
I can do this today because the definitions for the default store and the
implicit inclusion list stems from elementary set theory. Understanding
these definitions allow Michael to package his persistent data in
/var/ucd-snmp/snmpd.conf (which is a GOOD choice) and allows me to backup
/etc and /var according to my needs. Neither of us is wright or wrong: we
simply agree on a definition and we can go on about our business.
[snip]
...The process fails because root.lrp is
not a replacement for root.tgz and there is not enough
space on the disk for both.
This is something I need to work on yet. However, you can:
[snip]
...and this gives you root.lrp. Then just create a new RAM disk of
the right size, mkfs.minix it, and unarchive the root.lrp into it -
then compress it and save to disk...
I understand completely. The process of changing the way something is stored
is usually referred to as a conversion and you will provide at a later
date the conversion procedure for your RAM disk. Will you still be
supporting the old LRP patches, eg, will Oxygen 1.9+ support both the old
tar.gz RAM disk and the new gz only RAM disk?
[snip]
reflex was to inform Mike and I was saddened to learn that
LEAF does not have an official package repository.
My CDROMs are partially designed to put everything into one place, but
I keep thinking people will think _I_ packaged everything when I
didn't...
I also put together a package extension to provide detailed
information about a package - with shell and luna scripts to read the
data and create web pages.
Guess I should revisit that, then convert my packages to it.
I am not certain I understand everything you wrote there, but I understand
that you would be happy to include additional packages in your repository. I
am correct?
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello Michael,
Glad to be of service!
I am confused ;
[1] Shouldn't your sed process:
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
actually be this?
sed -n /^[./]*etc/p ${pkg} ${pkg}.light
I am only concerned with deleting lines that start with etc..., /etc..., and
./etc... (Note that this will match a directory like /etcold but I don't
care). So the first attempt is to produce a new file list that does not have
any of those lines.
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore gets
included in the for loop.
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
[4] Where do you get `cmp'?
cmp is a busybox applet. If don't have Andersen kit at hand, there is a
rather plump busybox on the discussion.img disk that I referred to earlier
this week. O'Reilly Linux in a nutshell has proper documentation for it.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello again,
This is where I get lost. When you said:
``When I want to backup, I simply remove the write protect tab on the
floppy. I can assure you that it takes a lot of config data to fill
1.6Mb of compressed space.''
I thought that you were backing up *only* config data. How does your
sed process facilitate this quoted intent of yours?
Actually, the process is more like *I don't backup program binaries* :-).
Because of the subset of programs I work with, taking care of /etc and
/var - /var/log - /var/adm - /var/lib/lrpkg - /var/run - /var/lock -
/var/spool -/var/tmp } gives me what I want. YMMV :)
By-the-by, this is considerably faster:
sed -e /^[./]*etc/d ${pkg} ${pkg}.light
Linux people are usually more intelligent than I am. Your sed mask allows
for stuff like ...etc and ../../../etc and all kinds of ganes that I prefer
not to play :). Following your intervention, the original sed command now
reads
sed -e /^etc[[:space:]]*$/d -e /^[/]etc[[:space:]]*$/d \
-e /^[.][/]etc[[:space:]]*$/d \
-e /^etc[/]/d -e /^[/]etc[/]/d -e /^[.][/]etc[/]/d \
${pkg} ${pkg}.light
This is part of a startup script that runs a few times a year. I am more
concerned with exactness than speed of execution. Your method is
_definitely_ faster but does not gives me exactly what I want.
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore
gets
included in the for loop.
Yes, I know; but, how does including excluded data facilitate your
needs?
Sorry for taking your question litterally :). I will presume that you
understand that the set of files destined for the default store is the set
of all files on the machine minus the set of all the files enumerated in
each of all other packages and minus the set of files excluded for the
default store.
Suppose the default store is named gizmo and some other package exclude
/etc/thisthat. The backup code in LRP, Dachstein, Oxygen, etc concatenate
all the file lists for all packages other than gizmo in a single exclusion
list. Therefore, if something is excluded from one package, it is also
excluded from all other packages.
When I want a snapshot of my machines, I want _everything_ in etc. Life is
like that :-)
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
Yes, or similarly . . .
Like I said above, I do not handle /var the same way as I handle etc. The
programs I use store their data in /etc or /var or both. It can be extended
to anything else. Eventually, the need to run write-protected will change.
However, this solution works today.
[4] Where do you get `cmp'?
[snip]
I know that it is available; but, it is *not* included in DCD -- is it
included in Oxygen? I do not argue against its usage; rather, I am
often frustrated by lack of real awk, sed and sort -- not to mention cmp
and diff ;
Gee, I really had a push-button mind when I answered you. Michael, bear with
me for a few more seconds.
For one of his shows, Ed Sullivan had invited a lion tamer who usually put
his entire head in the lion's mouth at the end of his act. It was explained
to him, in writing, that the act took 10 minutes. By showtime, due to
overbooking and delays, Sullivan tells the lion tamer that once the curtain
rises, he has two minutes for his act. OK, says the lion tamer, but YOU
explain it to the lion. :-)
Now, to answer your question: you are looking for a baseline specification
:-). David Douthitt is *RIGHT* when he says that there should not be a
baseline specification, either explicitly specified for LEAF or indirectly
specified by refering to a distribution. We are dealing with unspecidied
hardware constraint, some of which are not obvious as in the case of the
write-protect switch. As a case in point, Bering does not have netstat, a
fixture in this environment since the early LRP days. In the confined space
of a floppy, Jacques Nilo decided something that made sense for his project
and he can revisit his decision at any time. In the meanwhile, you have
Bering to play with.
The difficulty here is formalizing your ability to repackage your baseline
and go on with your life (or your LEAF :). I think we can overcome this
difficulty but I will wait for your comments on the process.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
Message: 1 Date: Wed, 13 Feb 2002 13:54:34 -0800 From: Matt Schalit [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) To: [EMAIL PROTECTED] Hey Serge, Hello Matt, First, the important stuff: or any of us lacked passion. That's kind of insulting. And what Please accept a direct apology from me to you for no other reason than the fact that your feelings were hurt. It's plenty interesting to read your threads and see the breadth of your opinions. I've said before that it's always refreshing to Thank you. Please DO NOT PUT your flame thrower away! exactly happened three weeks ago? You showed up? And you tore the low level guts out of Dachstein and want to call that PacketFilter? And My posts are polite and as factually true as I can make them. PacketFilter is a 60kb file that cannot contain Dachstein. If you read the manual, Charles is directly credited for allowing this 60kb file to be distributed with his stuff. Further, as pointed out to David elsewhere, I do not intend to make a distribution just for the purpose of providing an environment in wich to run PacketFilter. This leaves you with very little material to support your opinion that I want to promote a dumb filtering device to the level of Dachstein. you don't like our file structure and our documentation? You think we make stupid decisions in our quaint little space and that comlicates your life? Indeed. As you acknowledged in the beginning of your message, you have collected things out of context. The onus is on you to support your comments. Regards Serge Caron --__--__-- Message: 9 Date: Wed, 13 Feb 2002 22:34:18 -0600 From: David Douthitt [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) To: LEAF Development [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] On 2/13/02 at 8:16 PM, Serge Caron [EMAIL PROTECTED] wrote: How's this different from Oxygen and Dachstein and how they read their configuration data from the floppy? I can create a package which contains nothing but configuration files, put it onto a floppy disk, and boot the Oxygen Bootable CDROM using that configuration The point is that this default store is loaded last, overwriting anything loaded from ANY package. It is not package specific and it is all inclusive (as far as /etc and /var go). And I DON'T have to rewrite all of the packages... Neither do I. As a matter of fact, I cannot rewrite stuff on CD when the package writer did not provide a partial backup list for Charles partial backup code. I also do not want to load binaries frow write-enabled media, as much as I can avoid it :-). Last, but not least, I will retain SOME system functionality when the default store goes belly up or missing. For booting purposes the use of root.lrp is dead; however, a script to convert root.lrp to a root.gz is practically a neccessity. The LRP patches can't be used on any kernel newer than 2.4.5 last I heard; so this kills the use of a *.tar.gz file for booting. Am I to understand that this will be a ONE-TIME script, run as part of an installation procedure, or is this a viable option that users sticking with 2.2 kernels will have in the long run? a real Repository would be with hyperlinks, descriptions, home pages, etc and requires a new package extension. I've not done as much as I ought, but it mainly uses a new file /var/lib/lrpkg/pkg.desc which contains all of the information Grrreat! Here is the dope for http://leaf.sourceforge.net/devel/scaron/nistnet.lrp The second one is nistnet 2.0.10, the National Institute of Standards and Technology network emulator and here's the dope from their homepage at http://www.antd.nist.gov/itg/nistnet/ The NIST Net network emulator is a general-purpose tool for emulating performance dynamics in IP networks. The tool is designed to allow controlled, reproducible experiments with network performance sensitive/adaptive applications and control protocols in a simple laboratory setting. By operating at the IP level, NIST Net can emulate the critical end-to-end performance characteristics imposed by various wide area network situations (e.g., congestion loss) or by various underlying subnetwork technologies (e.g., asymmetric bandwidth situations of xDSL and cable modems). Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: SF changes TOS
Message: 2 From: guitarlynn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Leaf-devel] SF changes TOS Date: Wed, 13 Feb 2002 15:48:07 -0600 Canadian would be great, but legally you can't contribute from the US to their projects as I understand it. As a Canadian citizen, I do not know what you are taking about. We have NO restrictions on cryptography and our copyright laws are pretty much in sync with the international community. ISPs all over the world are seeking the protection granted to carriers such as telcos rather than the burden of being the publisher. The former are immune from what you say on the line: they lease wires... The later are responsible for everything YOU do, unless they can prove that you deceived them. Easier said than done. Usually, people are looking for venture capital from ANY source :-) and I don't see why an open source project based in Canada would not be able to accept contributions from the US or anywhere else. Theo de Raadt has a lot of success with OpenBSD, distributed from Calgary, Canada. Here is some dope on the Canadian Export Control List (http://axion.physics.ubc.ca/ECL.html). However, if you have specifics, I will have a lawyer research this. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello Michael,
[ snip ]
Let me reduce my confusion to its firstmost problem: How does your sed
process facilitate ``*I don't backup program binaries*''?
AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files -- define
which files comprise the ${pkg} package -- correct?
Once you eliminate all files under etc, /etc and ./etc from ${pkg}.list
files, what you have left is ``a bunch of binaries'' -- am I wrong?
Wouldn't you reach this same end if all files under etc, /etc and ./etc
were only listed in ${pkg}.exclude.list files?
Until I fully understand this premise of yours, I do not know how to
proceed . . .
OK, so lets process this from the start. Here is the contents of
/var/lib/lrpkg/bindc.list, an old BIND 8.something package:
etc/init.d/bind
etc/named.conf
usr/sbin/named
usr/sbin/ndc
var/lib/lrpkg/bindc.*
var/named
Only concentrate on those two etc entries. The package author did not define
a .local file to backup just part of the package. The package is running off
CD and I can't rewrite it there :-). Finally, even if I could, I DO NOT WANT
to. I want to keep this package in whatever form it was delivered for the
entire duration of its useful life.
Once the package is LOADED, I delete the two etc lines from the list. This
means that any other package can now claim these two files. If these files
were enumerated in, say, /var/lib/lrpkg/bindc.exclude.list, they would be
excluded from every other package AND bindc.lrp. This is important, please
stop here if it is not clear.
Now, by removing these lines, I can either backup these files in the default
store (root.lrp if you are using Dachstein) or I could create a
configuration package. If I did this, I could be missing out on other stuff.
If I were to run on a hard disk, the persistent nature of the storage medium
hides the problem: eveything you left will be there when you power the
machine up again.
What I want is the entire contents of etc (and other stuff) as if I was
working with persistent storage without affecting each package.
Dachstein loads the default store BEFORE anything else and this is not
helping your understanding. If etc/named.conf is in both root.lrp and
bindc.lrp, the later MUST overwrite the former because the package loading
code is in root.lrp. By separating the default store from the boot loading
code, you can load the default store in the order YOU chose :-) Cool!
I suggest you try the discussion.img floppy which has a default store
separate from root. Perhaps by experimenting with this disk, it will become
clearer? If you get confused by the alternating kernels, I can package
something more obvious.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello again,
-Original Message-
From: Michael D. Schleif [EMAIL PROTECTED]
To: Serge Caron [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: February 14, 2002 5:34 PM
Subject: Re: [Leaf-devel] Re: Standards and due process :-)
Nevertheless, since all backup operations are performed from root (/) --
a very sound *convention* and *standard*, yes? -- what is the actual
AFAIK, it is sound.
Or:
sed -e /^[.]\{0,1\}[/]\{0,1\}etc[/[:space:]]*$/d ${pkg} \
${pkg}.light
I really don't like to see repeated calls to same executable in
production code -- just part of my process ;
Your code is more than likely correct. However, the metacharacters { and }
are not used in sed according to O'Reilly's Linux in a nutshell (3rd
edition, chapter 9). I have seen different sed implementations in LRP and I
must say I am very conservetive :-). I do not understand your last comment
as sed is loaded only once either way. Perhaps you know something that I
don't.
[ snip ]
When I want a snapshot of my machines, I want _everything_ in etc. Life
is
like that :-)
Didn't you just *exclude* these same files in your sed process? How do
you get everything that you just excluded _after_ explicitly excluding
it?
Clearly, I am missing something profound here . . .
I do not exclude these files from any package. I merely delete their
inclusion in specific packages. This is not the same.
[ snip ]
Now, to answer your question: you are looking for a baseline
specification
:-). David Douthitt is *RIGHT* when he says that there should not be a
baseline specification, either explicitly specified for LEAF or
indirectly
specified by refering to a distribution. We are dealing with
unspecidied
hardware constraint, some of which are not obvious as in the case of the
write-protect switch. As a case in point, Bering does not have netstat, a
fixture in this environment since the early LRP days. In the confined
space
of a floppy, Jacques Nilo decided something that made sense for his
project
and he can revisit his decision at any time. In the meanwhile, you have
Bering to play with.
This is where I believe that we really part company. Since you insist
on this choice of words, I have no choice, but to take you literally:
``there should not be a baseline specification''
If this is the case and it is *explicitly* enforced, then it follows --
absolutely -- that nobody can build any package for leaf/lrp and expect
that it will perform according to any given specification! Period.
Thank you. Not only do we not part company, we agree that it is _absolutely_
required to enumerate the exact feature set of this and that distribution.
However, the environment IS confined. So just saying load busybox, for
example, is not sufficient. It is required to say, in fill in your
distribution name the binaries available are fill in the list and the
exact feature set is one more enumeration. So, if this distribution is
using the busybox sed instead of the full flavor Debian sed, YMMV. Is this
unreasonable to ask? And don't you want to know it before you assemble
everything in place?
In fact, a system, such as leaf and lrp, is and always has been founded
on a -- confusing -- myriad of tacit specifications. It is this implied
set of conventions that I am addressing -- the fact that these
specifications are largely unwritten and, therefore, understood by a
very small minority. I maintain that, without any specification, there
would be no lrp and no leaf and no List Service on which to debate these
arcane issues.
You are correct again. For example, the fact that I decide to store files
elsewhere than in their original package is definitely going against the
grain. Step 1 in what you say is to identify that the usual practice or
implied convention or tacit specification is to store the file in its
original package. Step 2, is to face reality: you can't do that if you run
from a CD or ROM or write-protected media. Step 3, is to come up with a
reasonable alternative to the problem.
It is another fact that I cannot, nor can anybody else, willy-nilly
construct any haphazard package, load it into a running leaf/lrp
environment and expect that that system will continue to run with its
baseline integrity; much less, that my package will perform as I
expect. We are dealing with systems predicated on baseline security and
integrity -- are we not?
Therefore, I insist that *NOW* is the time to publish an explicit set of
baseline conventions and standards for leaf -- prior to landing squarely
in the midst of 2.4.x land!
You have my support. However, it is one thing to say thou shall have
busybox with these xyz applets and to insist that a distribution has this
or that tool. For example, as Charles notes on his site, ip sadly' does
not have a command to place a card in promiscuous mode. The question is not
whether I use busybox ifconfig or the full flavor ifconfig just to place a
card in promiscuous mode. The question
Re: [Leaf-devel] Re: Standards and due process :-)
-Original Message-
From: Michael D. Schleif [EMAIL PROTECTED]
To: Serge Caron [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: February 14, 2002 6:20 PM
Subject: Re: [Leaf-devel] Re: Standards and due process :-)
Voilà!
[snip]
Only concentrate on those two etc entries. The package author did not
define
a .local file to backup just part of the package. The package is running
off
CD and I can't rewrite it there :-). Finally, even if I could, I DO NOT
WANT
to. I want to keep this package in whatever form it was delivered for the
entire duration of its useful life.
OK, now I see! Somehow, if you explicitly stated this before, I cannot
find it in your previous posts. Dear me, I am too literal, again ;
Actually, I faced this same dilemma many months ago; but, I conquered it
in quite a different manner -- I keep my own DCD development tree and
have finely tuned *ALL* LIST and LOCAL files to my particular needs. In
fact, now that I have successfully attained a leaf developer site, I
have been thinking about publishing what I believe to be the correct
LIST and LOCAL files for those packages included in DCD and those else
that I use. Is this a case for convention and standards, or is
willy-nilly construction of these files adequate to the task?
OK. You build /var/lib/lrpkg/xyz.local files with your choice of files that
have dynamic contents and should be included in a partial backup and your
choice of files that have static contents (tables, binaries, ...) and should
only be included in a full backup. Then you use lrcfg (or some other tool)
to specify for each package wheter you want a partial or a full backup.
Finally, you also specify, per package, the destination device.
So, if you run 10 packages on CD, you may end up with 7 partial packages on
floppy. This is Charles design and there is NOTHING wrong with it.
Your process has the added benefit of placing *ALL* LIST elements in one
(1) file -- something I have on my todo list; but, have not taken time
to achieve, especially in light of Charles' musings on redoing the
entire package thingy anyway. O, that is what we are discussing, huh?
My process, as you put it, is simply to dis-associate some files with the
original package they came from. One of the difficulty in LRP is that you
CANNOT have exact same file name in two different packages. Both packages
will load, the last one overwritting the first one. If you backup either
package, the file is dropped because the filelist of one package is the
exclusion list of the second one.
Breaking this association removes the difficulty entirely. I can then, if I
want to, backup to whole lot in package gizmo.lrp if that is what I fancy.
Two (2) questions, at this point:
[1] The *only* way to make your ${pkg}.list modifications stick is to
perform a backup -- right? Since your example, bindc.lrp, includes *NO*
LIST file and you have no time to create one, then you need to backup
Oops! Did I go wrong somewhere? Here is what I sent you: Here is the
contents of
/var/lib/lrpkg/bindc.list, an old BIND 8.something package:
etc/init.d/bind
etc/named.conf
usr/sbin/named
usr/sbin/ndc
var/lib/lrpkg/bindc.*
var/named
Since the contents of /var/lib/lrpkg/bindc.list is explicitly listed, there
is a LIST file.
the *entire* package, just to enforce persistence of this modification
-- right? If so, what do you gain? Hopefully, it is not a large
package, nor that you have only that floppy on which to store it ;
If I modify the contents of the list file and I were to do a backup, then I
would loose some contents of the original package. However, I am explicit in
giving the example that I run from a CD (I would prefer ROM :) and that,
regardless of the storage media, I do NOT want to modify the original
package. In other words, there are packages for which I will never backup.
Perhaps, this is a calling for creation of this file:
/var/lib/lrpkg/*.list
The file is already there, per above.
[2] Now, I must ask, again, how do you account for configuration files
that reside elsewhere, say ? It seems to me
that exceptions -- remember, the more the merrier! -- are quite costly
and speak loudly in support of those issues that I take with your
previous statement:
``there should not be a baseline specification''
I gave as an example a code snippet for /etc from a rather specific machine
down the hall for which we wanted write-protection at all times. Again, my
personnal experience with LEAF/LRP is that there will be new dynamic
contents every time you introduce a new package in a configuration. Your
package likes /usr/share/snmp/snmpd.conf and BIND likes /var/named. /etc is
easier to do than /usr.
To be specific, if a package maintains dynamic contents in /usr/sbin then I
HAVE to backup the original package (full or partial). However, I currently
do not run such packages and, I my experience, most package developers have
behaved. Do you have a different
[Leaf-devel] Re: SF changes TOS
Message: 5 From: guitarlynn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: SF changes TOS Date: Thu, 14 Feb 2002 15:41:38 -0600 [snip] OK, thanks for that info. Around six months ago I was looking into helping a couple of Canadian-based projects and they implictely stated that due to the US laws on cryt., they appreciated the offer but wished to decline due to the possible conflict. Things may not be true for any other projects and they may have changed their minds, but since some of these laws have passed within the US I have to respect their concerns :) Ha! Now I understand. If, for example, you pickup an Intel PRO/100S nic with 168-bit encryption (Made in Malaysia if my memory serves me right) you should read on the label Unlawful to export outside US or Canada except under an approved US Dept of commerce export or applicable license exception. You will find the exact same warning on a Microsoft high encryption pack and on different encryption products. You, as a US citizen will break the law if you do export it to Europe, for example. I, as a Canadian citizen, am under license not to re-export this product. It cannot even go back to the US. (No refund policy :) Trust me, the terms of the license are basically a direct contract between me and the US government. As I stated before, we have no restrictions on cypher strengh, algorithms and the like. Since you, as a US citizen, implicitly have access to technology that cannot be exported, these people protected themselves. It used to be the same thing with France, up until 2 years ago I believe (Jacques could tell us). There, you could not even 40-bit encrypt a dial-in connection. Importing the stuff was a crime against the state and I dare not think what they did to suppliers. On older Microsoft development CDs, for example, you have French NT Server and then France NT Server. The former for Canada, Africa, etc. The later for France and its territories. So I guess some of these people mean business. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
appliance in the above floppy and document its tacit specifications. Again, this can be done from the appliance point of view without being reflected in code. In the meantime, I haved continued to lower this baseline. The page http://leaf.sourceforge.net/devel/scaron/leaf.htm has been updated to reflect release of v5.0.3 as well as introduce v5.1.0 and v5.3.0. This documents (alas poorly) the process of creating enclosures and shifting the baseline anyway the end user sees fit. Doing this made me realize how I can change the backup code to avoid loosing files enumerated in the xxx.links package lists, which happens, for example, when a busybox applet is replaced with the real thing. v5.0.3 also drops the POSIXness stuff, without breaking *stein and Bering, AFAIK: see the caveat below :). v5.3.0 is my standard busybox ash experiment: I have tested on many occasions the compatibility of busybox ash to the Debian ash. In this case, I simply replaced the busybox in the original enclosure with the busybox found in Oxygen 1.9. busybox ash is not a drop in replacement for ash, but it is getting better all the time. In this case, there is a Segmentation fault in the following construct: # Modules required to complete the boot process if [ -r $BOOTDIR/etc/modules ] ; then # (Do not process comments and white space.) (blind cat $BOOTDIR/etc/modules; echo) | sed -e s/#.*$//1 -e /^[[:space:]]*$/d | while read module args; do blind insmod $BOOTDIR/lib/modules/$module.o $args done fi There is nothing wrong with this construct and it will run perfectly if it is moved around in the script (the segmentation faults happens in the pipe between sed and the while clause). In the problem at hand, the file is empty and the startup continues correctly. It is the ONLY thing to report for the scripts in this enclosure when using a 2.2 kernel. There is about a dozen Segmentation faults when using a 2.4 kernel, none of them fatal. The availability of these concepts and tools makes the experiment and discussions possible. Please note that the floppy has been upgraded to http://leaf.sourceforge.net/devel/scaron/discussion2.img. This particular code is designed to reflects the concepts introduced left and right in this post and on the formal presentation page. It can be used with other libraries as well: there are only 19 binaries involved, all of them standard Debian or busybox fare. 14 of these binaries are used ONLY by the root appliance above. AFAIK, e3 is used only by us, humans. This leaves ash, busybox, tinylogin, and sed for the best experiments :o). Those interested to comment on the ideas are more than welcomed to do so, emotions and all. I also need a replacement script for Charles mail script which happens to use netcat, a utility that I do not want in production equipment. Which smtp _output_only_ program should I use and is there a script compatible to Charles's syntax? Regards, Serge Caron Appendix: contents of root.list in my Oxygen 1.9 setup: linuxrc bin/ash bin/bash bin/busybox bin/dnsdomainname bin/help bin/lf bin/ll bin/logrotate bin/lx bin/netlock bin/pwd bin/run-parts bin/sh bin/sleep bin/snarf bin/strip_comments bin/timeread lib/modules/boot/3c509.o lib/modules/boot/3c59x.o lib/modules/boot/8390.o lib/modules/boot/cdrom.o lib/modules/boot/eepro100.o lib/modules/boot/ide-cd.o lib/modules/boot/ide-disk.o lib/modules/boot/ide-mod.o lib/modules/boot/ide-probe.o lib/modules/boot/isofs.o lib/modules/boot/modules.conf lib/modules/boot/ne.o lib/modules/boot/rtl8139.o lib/modules/boot/smc-ultra.o lib/modules/boot/tulip.o lib/modules/boot/wd.o sbin/chroot sbin/ip sbin/lsmod sbin/mkram sbin/sysctl var/boot/modules var/boot/config/README var/boot/config/big.vol var/boot/config/cdrom.cfg var/boot/config/config.cfg var/boot/config/develop.cfg var/boot/config/dos.cfg var/boot/config/firewall.cfg var/boot/config/floppy.cfg var/boot/config/large.cfg var/boot/config/largenet.cfg var/boot/config/misc.cfg var/boot/config/net.cfg var/boot/config/oxygen.cfg var/boot/config/rescue.cfg var/boot/config/setup.cfg var/boot/config/smallnet.cfg var/boot/config/std.vol var/boot/config/test.cfg var/boot/config/testcd.cfg var/boot/config/tiny.cfg var/boot/linuxrc/find.cdrom var/boot/linuxrc/functions.cdrom var/boot/linuxrc/functions.dhcp var/boot/linuxrc/functions.general var/boot/linuxrc/linuxrc var/boot/linuxrc/main.load var/boot/linuxrc/mkdevices var/boot/linuxrc/mkfloppies var/boot/linuxrc/new.load var/boot/linuxrc/old.load var/boot/linuxrc/sysconf var/lib/random-seed var/lib/lrpkg/config.md5 var/lib/lrpkg/root.busybox.list var/lib/lrpkg/root.conf var/lib/lrpkg/root.exclude.list var/lib/lrpkg/root.help var/lib/lrpkg/root.list var/lib/lrpkg/root.mount var/lib/lrpkg/root.posix.list var/lib/lrpkg/root.version var/lib/lrpkg/sys.packages var/lib/dialer/* var/spool/* ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo
Re: [Leaf-devel] Re: Standards and due process :-)
-Original Message- From: Charles Steinkuehler [EMAIL PROTECTED] To: Serge Caron [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: February 19, 2002 3:28 PM Subject: Re: [Leaf-devel] Re: Standards and due process :-) It's the falling off and turning into Christopher Reeve part that I'm worried about :-) I think you chose a perfect example. The courage of that man makes you forget the horse altogether. This is perhaps the clearest example of what you're after you have provided to date...thinking about this more, I'm not even sure a default store of any sort is necessarily a great idea. On one hand, the default package means there are no orphaned files, but the overlapping nature of the existing package list format leads to lots of problems in it's own right. I need to think about this some more... Now we're talking! If these were sets, the union of all the xyz.list files is not equal to the universe of files available on the system (represented by /) because some files are created by running programs, operators, intruders :). So the set of orphaned files contains interresting stuff in its own right. However, this is only the obvious part of the iceberg. In the long term, I want to be able to run from secure media. In the short term, I use CD for write protected storage and floppy for write-enabled storage (wich I write-protect between sessions :). Suppose a package designer stores something in /etc/mypackage (which is either a file or directory, your choice). This designer has many choices: 1- claim /etc/mypackage as part of this package 2- rely on an unwritten standard or tacit convention that /etc belongs to another package (presumably etc.lrp) 3- rely on the user's knowledge of the LEAF standard that his file will end up in the default store. If /etc/mypackage is also a directory, the package designer can optimize the backup operation by omitting certain temporary files (enumerated in xyz.anything.list). Suppose that the system of partial backups is finely tuned so that modified files always end up in write-enabled storage. Suppose also that packages from read-only storage are always loaded before packages from write-enabled storage, eg, you don't loose modifications. Finaly, presume the goodwill of the package developer, eg, package xyz claims nothing out of its immediate territory. This above set of conventions places the entire burden of protecting this package in the hands of the package designer with no support from the LEAF appliance it is supporting or the user operating the machine. This is precisely Michael's line of questioning. If there is a standard, then the user knows what is going on and backup is one of the user's many responsibilities. However, we all know that history has been written before us and that pppd uses /etc/ppp and dhcpd uses /var/state, etc: addressing the problem from this angle IS next to impossible, especially if we try to make a sysadmin out of the user. This user is also subject to constraints of his own. The readme file in / stating that trespassers will be prosecuted to the maximum extent of the law is a real life example. The file belongs to the user and even he can't choose the location. Another example is dropped files. You and I may find that dropping /var/run/xyz.pid files is OK. Unfortunately, it does not match many audit policies, including those of my organization. None of these things are issues if the filesystem is persistent storage such as hard disk. When it is not, you have to expect that somebody else than LEAF will select which files goes to write-enabled storage. As of now, I am doing OK by rewriting most lists (on the fly!) and saving the default store. This system is far from perfect and this is why I am supporting Michael's quest :-) Packaging enhancements! Lowering the baseline! All good to me! :-) Actually, the baseline goes lower every release :-) even more: *NO* glibc, *NO* shell, and a *VERY SMALL* initial ramdisk that bootstraps the rest of the distribution. This should all be possible using Precisely! This is why the appliance boundary is set to start with /sbin/init. Anything before that should be abstracted as turn it on and it works. The term enclosure was coined because it is not a box and you can't throw it away. On the other hand, the component must ship with the appliance (red paint, anyone? :). a self-contained scripting lanugage that has the capability to do kernel calls. Very much like e3, which talks to the kernel directly rather than using a c library, the bootstrap code can be made very small. By using tiny interpreted language like Forth, the boot process can still be made flexible. The key part I'm still checking into is being able to dynamically flexible is a nightmare until you explicitly specify the side effects of the load order. The bootstrap loader loads THE ramdisk before the kernel and you can be certain that things are what they look like when linuxrc gets control
[Leaf-devel] Re: Standards and due process :-)
Hello all, Message: 4 Date: Tue, 19 Feb 2002 23:20:07 -0600 From: David Douthitt [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) To: LEAF Development [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] I was thinking... If you make root.list contain specific files, and move the specification of ./ to another package, that raises some interesting things I think you are beginning to see the benefits. What if instead of gloming onto home.lrp, you create overflow.lrp or default.lrp? One nice benefit would be that if that package grows, one would KNOW it and the root.lrp package in systems that still use it would not In all kindness, please use the setup that is most confortable for you. As soon as you move ./ out of the RAM disk, you get all kinds of benefits. Suppose that the system of partial backups is finely tuned so that modified files always end up in write-enabled storage. Suppose also that packages from read-only storage are always loaded before packages from write-enabled storage, eg, you don't loose modifications. Finaly, presume the goodwill of the package developer, eg, package xyz claims nothing out of its immediate territory. Oxygen already supports the use of config.lrp, which is a package containing ALL files listed in *.conf files and saved in package format - and this package is loaded *LAST* after all other packages. This means that you can update the conf files and then save them to a floppy which is used during a CDROM boot - in which case your configuration is used and the system is configured just how you want it. As a scientist, curiosity often gets the better of me :-). The text you are quoting from my post to Charles is an hypothesis formulated in three parts. It does not offer any factual information and it does not contain any value judgment on anything. Are you giving an example where files are dynamically stored in a package other than their package of origin? Is the intent of your post to demonstrate that Oxygen already has a default store, albeit one reserved to *.conf files? Message: 3 Date: Tue, 19 Feb 2002 22:57:13 -0600 From: David Douthitt [EMAIL PROTECTED] To: LEAF Development [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: [Leaf-devel] Default Stores, ash, etc. [snip] Adding a NEW package with the entry ./ in the new Oxygen environment (which uses root.gz) would be interesting. It basically means you can extend the base without having to create packages or other things. Correct. This can be done in any arbitrary way you see fit. For example, the code in the discussion floppy can mount up to 10 arbitrary directories, which means that you can replace /sbin on the fly, among other things. For another example, the user can drop files in your enclosure and reuse the ramdisk for something else. I am sure you can come up with examples of your own. [snip] There is a number of other mail scripts (including the LRP original, and one by Mike Sensney) - but all of the scripts use that minature nc. Thank you. To answer one of Michael's question, that miniature nc has enough power to create havoc on a network if an intruder gets in the box. At one point in time, netcat was the utility of choice for hackers and sysadmins alike. I will create a small script to replace the subset of Charles's mail command that is used by multicron-d. Message: 5 Date: Tue, 19 Feb 2002 17:56:04 -0600 From: Michael D. Schleif [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: mds resource To: Serge Caron [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) [snip] Isn't an exhaustive list of required files a de facto standard? Message: 6 Date: Tue, 19 Feb 2002 18:20:38 -0600 From: Michael D. Schleif [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: mds resource To: Serge Caron [EMAIL PROTECTED] CC: Charles Steinkuehler [EMAIL PROTECTED], [EMAIL PROTECTED] [snip] Perhaps, once we understand how the system works, it might be possible to agree on silly little things like location of configuration files. If it contributes to better system performance, better system security, c., perhaps it may not be out of line to suggest that /var/state/dhcp be a symbolic link to /etc/dhcp? Such a thing is trivial to a package developer; but, no such step will likely be taken, unless there is some convention that lends credence and bestows value to this decision. To reduce two great posts to these two small quotes is really a shame. In all fairness, on this show you get all the time in the world to tame your lions :-). Delivering a predictable system does not require to go to such extents as to redefine what amounts to a way of life for millions of people. We want to offer a system based on a model in which components are distributed from a variety of sources (LEAF, developers, repositories, clients, etc). We also want this system to be somewhat predictable, if not completely
Re: [Leaf-devel] Re: Standards and due process :-)
Hello David, Sorry for the pause :-) There is a picture that is becoming clearer and clearer from your posts. I will quote your post slightly out of sequence to bring some focus to this: -Original Message- From: David Douthitt [EMAIL PROTECTED] To: Serge Caron [EMAIL PROTECTED]; LEAF Development [EMAIL PROTECTED] Date: February 23, 2002 10:14 PM Subject: Re: [Leaf-devel] Re: Standards and due process :-) [out of sequence :)] Clearly, LEAF is designed to allow packages to overwite each other's files. Not designed to. It's just that the more capabilities you put into You are working under the premise that a file has one and only one package of residence. Please note that this is an observation and not a value judgment of any kind: AFAIK, there is nothing wrong with this premise. The natural consequence of this premise is that packages can be loaded in an indeterminate order since, under this premise, there is no name space conflict between packages. Hence [out of sequence :)] In Dachstein the load order is explicitly stated; in Oxygen the load order is indeterminate (since all packages are loaded automatically). You do not enforce this premise: [out of sequence :)] the packaging, the more space it takes up. Bullet-proofing, dependency checking, space checking, menu interfaces - it all takes up space. apkg is more powerful than lrpkg (I'd say) and I suspect it's Some files are duplicated in config.lrp... [out of sequence :)] Is the intent of your post to demonstrate that Oxygen already has a default store, albeit one reserved to *.conf files? I don't know if you'd call it a default store - it's a way of configuring the system so you can boot from CDROM. ...as you noted elsewhere, this single package is loaded last and is therefore excluded from possible name space conflicts since it is processed differently than any other package. This does not impact your premise. However even with the original idea, root.lrp was NOT supposed to change. So the only things that will show up in any package defined by ./ will be files that SHOULD be in another package This is a not a natural consequence of your premise. You are implictly claiming that there is a mapping of the entire file system into LEAF/LRP packages for everybody to consult. You are also claiming that it is an error to store in root.lrp any contents other than what you designed in. The former claim is Michael's quest: if there is such a mapping, where can we consult it and where is the body that will manage such a beast? If there is no such mapping, where are the guidelines in designing a package? The later claim means that the base system is not extensible. Is my understanding correct? Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Announcing leaf-project.org site name
Message: 1 From: Steven Peck [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 24 Feb 2002 23:06:57 -0800 Subject: [Leaf-devel] Announcing leaf-project.org site name. Well folks, After Mike Sensney's suggestion and talking to Mike Noyes and Charles I decided to get the domain name leaf-project.org. Better late than never: Thank you for such a generous gesture. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Emotions et al
Message: 11 From: guitarlynn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Leaf-devel] q regarding an ftp site for leaf-project.org Date: Thu, 28 Feb 2002 10:51:28 -0600 Disclaimer: The following opinions are made by a dumb, unemployed electrican that really ought to keep his mouth shut in such matters. As you will be able to tell in the next few minutes, controlling his opinion is _not_ something I am good at sometimes! Regardless, I for one do not believe that your employment or professionnal status should have an impact on your self-esteem. I am certain that you want other people to value your opinion and your (and everybody else on this lists) emotions are a reflect of a living and caring person. I can say the same of Mike Noyes who his willing to put forward and defend the concept that this group has intrinsic value. My point . all paths lead to the same destination. Does my opinion matter? Not really, I'm not a lead developer or a project admin. Your opinion AND your emotions matter, if only for the fact that you freely expressed them. Do NOT think of a BLUE horse. There are no blue horses...well maybe in the twilight That old grey mare, she ain't what she used to be, ain'twhat she used to be... Just to prove that I can put images and music in your head (if you're old enough to remember the melody... :) Communication is a wonderful thing and to pretend that anybody will make it in life on logic alone is suicidal. Emotions are 110% of reality, a fact that most of us should understand. Unless you are going out of your way to advertise the fact that you agree in advance with anybody that will discount your opinion, I do not see the necessity for being shy about what you are thinking. A word from our sponsor: this statement is NOT an endorsement of any of the opinions expressed by anyone on the subject. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
Message: 3
Date: Wed, 27 Feb 2002 22:55:22 -0600
From: David Douthitt [EMAIL PROTECTED]
Subject: Re: [Leaf-devel] Re: Standards and due process :-)
To: LEAF Development [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
On 2/27/02 at 4:28 PM, Serge Caron [EMAIL PROTECTED] wrote:
You are working under the premise that a file has one and
only one package of residence. Please note that this is an
observation and not a value judgment of any kind: AFAIK,
there is nothing wrong with this premise.
Understood - and true.
[snip]
I don't think you CAN standardize on a mapping. After all, in Oxygen,
so many things are packages that are part of root.lrp in Dachstein or
Bering...
The later claim means that the base system is not extensible.
Don't give up; show us how to be more flexible
I will do no such thing :-) I will however share my premises.
I view LEAF/LRP as a rich environment to which many people have contributed
over the years and to which many more will contribute. The basis for this
continued success is the notion of the data interchange format commonly
known as a package.
This is unique amongst all small Linux distribution. A package is a tar
gzipped file that contains a manifest under the name
var/lib/lrpkg/package.list. The manifest is a simple enumeration of the
package contents. Anybody can create a package and everybody is WELCOMED to
do so.
I work under the premise that there can be name space conflicts between two
arbitrary packages. I also work under the premise that these conflicts are
not for me to solve: they are the responsability of the person assembling
the final product.
Before I go on, consider the following images. Under your premise, you are
contemplating a puzzle where everything has a proper place, and rightly so.
Under my premises, I am contemplating a quilt, with every overlap adding a
layer of warmth, and rightly so.
I do not have to enforce anything but the proper construction of a package.
My loading code implements only two rules: a) if a package intends to store
anything in var/lib/lrpkg, the file must be named
var/lib/lrpkg/package.{anything.goes} b) file names of the form
var/lib/lrpkg/package.{anything.goes.}links are restricted.
The user is responsible for name space conflicts because the final
configuration is always the user's choice, not mine. If the user does not
want to backup either package, he has nothing else to do. If the user WANTS
to solve a name space conflict, he simply edit and saves the package whose
files should be dropped and reboot, at which time the name space conflict is
resolved. My user is a living participant in the system and if he is curious
enough to download software from the NET, pick and choose LEAF/LRP packages,
it is my opinion that he is a willing partner.
As you can see, educating this user into thinking that there are no other
limits than these is easy. Why did I bother with the concepts of enclosure
and appliance?
The *nix startup sequence is relatively well documented and it is easy to
understand the concept of a package that dictates the startup sequence by
supplying its own copy of /etc/inittab. An appliance is simply a package
that (probably) contains scripts that have little to do with the standard
boot sequence found in Linux systems. PacketFilter runs on top of anything
because it takes control from /sbin/init. The other appliance that I have
created, root (which you will find on the discussion3.img floppy), IS the
standard startup sequence found in LRP, *stein, Bering. So everybody SHOULD
(even if intuitively :) understand that there is nothing new here.
So our user can clearly see that an appliance and selected packages will do
the job he has in mind. Good. He can also easily understand that he needs a
Linux kernel and a boot loader. Good. Where is the component that will make
it possible for Linux to start /sbin/init which in turn will start this
appliance?
In the context of persistent storage, our user would have untarred each
package onto this storage and that would be the end of it: the persistent
storage IS the missing component.
We want more than this. Our storage is unspecified: we use RAM, CD, floppy,
flash, etc. Persistence is unspecified. So we need an ACTIVE component that
understand the format of a package and can present to the appliance the look
and feel of a Linux system. Further, we want the appliance to be able to use
the contents of this component as if it were from any other package. The
word enclosure carries the semantics of container and carries the semantics
of being the object of the communication. It encompasses what is required of
the user to think he is running off a regular system.
Because it reuse the concept of the package manifest, the enclosure is just
as easily extensible as any other package. Further it stresses out that
there is NO baseline.
For example, LEAF/LRP has in its unwritten feature set that users must log
in. I have on occasions removed tinylogin and replaced
[Leaf-devel] Re: Standards and due process :-)
-Original Message-
From: David Douthitt [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 01, 2002 3:39 AM
To: LEAF Development
Subject: Re: [Leaf-devel] Re: Standards and due process :-)
[snip]
It sounds almost like you want a minimal set of enumerated binaries and
functions, and then Oxygen would add set X and Dachstein would add set Y.
Nope. No. Nein. Niet. Non. :-)
There is NO baseline.
There is one standard: the formation of a package.
The final decision on a configuration always rest with the user and she
expects the tools to do her job.
I have given specific and realistic examples of how and why the user may
want to float the baseline of a specific distribution, be it Oxygen or
anything else. If somebody else is already implementing these examples then
we should understand that our users will want to be able to do the same.
Last but not least, I have used persistent storage as an example where NO
code from the distribution runs before /sbin/init, the point where I
assume the user or some other package will take control. This is the absence
of a feature set and you can't possibly get any lower than this. Again, in
the example of persistent storage, the user will use from the distribution
whatever has value to her, be it the menu system or the package management
software apkg.
The existence of this one standard does in no way reflect on anybody's
premises. It does reflect on the user's ability to use arbitrary packages
with arbitraty distributions.
My loading code implements only two rules: a) if a package intends to store
anything in var/lib/lrpkg, the file must be named
var/lib/lrpkg/package.{anything.goes} b) file names of the form
var/lib/lrpkg/package.{anything.goes.}links are restricted.
If a package does not satisfy these two rules, the package is skipped. Let
the user sort out the issue.
The exact feature set of a distribution is obtained by the unambiguous
enumeration of its packaging. In the example that I have given, the contents
of the initial ramdisk has a feature set (whatever that is) that is
augmented by the feature set of other packages.
If you choose to split this feature set across multiple packages, you still
have the same feature set with the added feature of being able to delete
or replace some components in the form of other packages. Spliting the
feature set in 3, 10 or 27 packages does not change the attributes of the
package concept.
Please note that the unambiguous enumeration of the packaging answers
significant parts of questions like Which distribution should I use? and
Will this fill in package name work with fill in distribution name?.
This is the basis of LEAF: uneducated users and gurus alike should find
something of value here.
I also note that you gave more importance to packaging than to the
fundamental difference between our respective set of promises. However, here
lies a richness that should be exploited. In particular, it addresses
Michael's quest by explicitly stating that name space conflicts are to be
solved by the user. As long as he follows sound practices (like reflecting
installations in full blown systems), Michael's packages should work with
ANY distribution. In case of doubt, the user decides.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Leaf-devel digest, Vol 1 #599 - 7 msgs
It seems my day is being rearranged for me :-) Message: 7 From: Luis.F.Correia [EMAIL PROTECTED] To: LEAF Development [EMAIL PROTECTED] Subject: RE: [Leaf-devel] Re: Standards and due process :-) Date: Fri, 1 Mar 2002 11:36:13 - Adding water to a boiling and already full kettle... Unless you are aware of something specific, all I see here are adults having a conversation and agreeing on having different point of views. Yours is welcomed as well. Why can't we use a concept similar to this: assume vfat is used /assume Package name: pppd-2.1.4 Package files: pppd-2.1.4-bin.lrp, pppd-2.1.4-conf.lrp pppd-bin.lrp contains all necessary binaries and 'non-editable' scripts, pppd-conf.lrp contains all configurable files. All we will need then is to backup only the ???-conf.lrp files. You are squarely putting pressure on the packaging without having agreed that there is a packaging standard to begin with. At this point in time we have a de facto packaging standard, the tar gziped file with manifest in var/lib/lrpkg/file.list. In theory, there are no sacred cows and this could be revisited as well. However, this is not my purpose. I want to document the existing standard and its natural consequences on our global LEAF packaging. David is expressing a point of view that can be understood as a puzzle where everything fits neatly in a grand plan. I am expressing a point of view that can be understood as a quilt where the user builds a motif of his choice. The natural consequence of David's point of view is that users and packagers alike must follow a grand plan and it can be argued that this creates a framework in which these people can work. Michael's quest is to obtain an understanding of this grand plan so that his packaging remains correct. The natural consequence of my point of view is that there is no grand plan. Once a user has selected a number of packages which he intends to configure into an appliance of some sort, the onus is on the user to solve name space conflicts, if there are any. In this framework, ordinary users decide if Machael's packaging is right for them and he onlly has to deal with common sense in building his packages. I do not see why both point of views cannot coexist. From a strictly mathematical point of view, one is a subset of the other and therefore, both are valid. From a strictly human point of view, a controlled environment may be better for uneducated users and a loose environment may be better for more creative types. I don't know, I am no psychologist :-) In either points of view there are substantial benefits obtained by unambiguously enumerating the contents of components. One such benefit is that the feature set of a distribution becomes a lot more obvious. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Standards and due process :-)
Thank you all for following this thread. We are hosting something this week for a bunch of kids from Yellowknife, 5500Km north-west from here and I it kind of has an impact on my schedule :-) Message: 1 From: Luis.F.Correia [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 1 Mar 2002 19:56:35 - Subject: [Leaf-devel] Re: Standards and due process :-) LC :) I'm only aware of a 'almost' religion-like discussion. Of course reading your conversation makes me aware of how little I do know about different several standards and processes exist. So my 'adding water' phrase was meant to be a joke. I agree with you that there is a tangible emotional content on this list. I will respect other's people emotions while at the same time continue the drive to get a better understanding of our de-facto standards and processes. My point was only: In order to 'simplify' the simple act of packaging, from the user's point of view, we should split what does not need to be backed up from what does! I read almost every day that user X using distro Y backed up root.lrp and destroyed her/his boot floppy! Since that, with my idea, root.lrp would not even appear in the backup script screen, the user would be protected from her/himself! In my mind, the end-user is an active participant in LEAF. Fisrt, he chooses us rather than anybody else. Second, he can be protected from himself by providing backup code that implements all the premises of the underlying distribution. Third, he may contribute to his own configuration other files than OUR configuration data: we are not always in a position to choose ALL the files. I am confident that we can meet these requirements by implementing very few changes in what we already do. I will most certainly benefit from this discussion. Things tend to improve when people discuss a lot :) Indeed, they do :-) Regards, Serge Caron Message: 3 From: Charles Steinkuehler [EMAIL PROTECTED] To: Serge Caron [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) Date: Fri, 1 Mar 2002 17:19:10 -0600 [snip] There actually *IS* a baseline implicit in the above. *SOMETHING* has to get linux booted, create/mount a root filesystem, and load the proverbial package. This implies some sort of boot-strapping code, as well as some sort of package format. Allow me to wander off on a slight philosophical tangent... OK. However I would like for you to reread my post of Feb 23: We want to offer a system based on a model in which components are distributed from a variety of sources (LEAF, developers, repositories, clients, etc). We also want this system to be somewhat predictable, if not completely predictable. Finaly, significant standards are out of our grasp: the Linux kernel will stay the way it is and so will the various boot loaders. We can start managing things with the initial RAM disk. The convention that [snip] There are NO required files. Ergo, there is no baseline. It is unimportant how the designer of this RAM disk will manage the bring the system up and load the other packages. Nobody else than LEAF will bother to load these packages and create a running system. So, our base component is this RAM disk, a life support system that I call an enclosure. Considering the total number of words written for what amounts to be a rather simple set of questions, we are saying the same thing. David's line of reasoning is along what goes were or is this program/file/whatever a valid choice in the context of this distribution. So the valid question is will this design introduce name space conflicts?. Everybody agrees that we have a de-facto standard for packages. However, the code that loads these packages need not put pressure on this name space. Therefore the *SOMETHING* you are referring to does not have to be a requirement as David puts it. More on this later. Back to your philosophical tangent I think the core question is what makes LEAF LEAF? What are the consistent features between all the distributions we think of as being part of the LEAF family? [snip] Many things come to mind, but I think the core feature is the dynamic generation of a linux run-time environment on boot. The embedded guys build [snip] The tiny linux distribution folks are also substantially different from LEAF. Virtually all of these distributions are based on running from a [snip] hard-disk, yet be extensible via a packaging system. IMHO, this is the single most unique and identifying feature of LEAF's many distributions, and what sets us apart from the broader linux community in general. Additional [out of sequence] So...who wants to start playing with the packaging system and re-defining LEAF? I do not think that clearly (and even formally) defining some of LEAF's attributes is an attempt on re-definnig LEAF. I state the obvious when I write We want to offer offer a system based on a model in which components are distributed from a variety of sources I
[Leaf-devel] Small SMTP send-only MTA
Hello all, Here is a small (5277 bytes, 5.5kb on floppy) send only MTA http://leaf.sourceforge.net/devel/scaron/smtpclnt.lrp (and here is the v1.0.1 source http://leaf.sourceforge.net/devel/scaron/smtpclnt.tgz ). smtpclient is Copyright (c) 1997 Ralf S. Engelschall, All rights reserved. and has been under GNU GPL since its publication. This is SMTPclient Version 1.0.1 (17-03-2002): I had to fix a (very) small issue with MIME quote-printables for us poor souls who need more than 127 characters in their daily alphabet :) The program has a nice feature set and is very compatible with Charles's mail command. Errors can be syslogged and there is debugging information when talking to the mail host. smtpclient reads the message from stdin and has the following command line arguments: Usage: smtp [options] recipients ... Message Header Options: -s, --subject=STR subject line of message -f, --from=ADDRaddress of the sender -r, --reply-to=ADDRaddress of the sender for replies -e, --errors-to=ADDR address to send delivery errors to -c, --carbon-copy=ADDR address to send copy of message to Processing Options: -S, --smtp-host=HOST host where MTA can be contacted via SMTP -P, --smtp-port=NUMport where MTA can be contacted via SMTP -M, --mime-encode use MIME-style translation to quoted-printable -L, --use-syslog log errors to syslog facility instead of stderr Giving Feedback: -v, --verbose enable verbose logging messages -V, --version display version string -h, --help display this page Here is a sample verbose output: 10.4.5.6 -- 220 piggies-blanket.pcevolution.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.2096 ready at Mon, 18 Mar 2002 11:12:37 -0500 10.4.5.6 -- HELO localhost 10.4.5.6 -- 250 piggies-blanket.pcevolution.com Hello [10.0.0.28] 10.4.5.6 -- MAIL FROM: root@localhost 10.4.5.6 -- 250 2.1.0 [EMAIL PROTECTED] OK 10.4.5.6 -- RCPT TO: [EMAIL PROTECTED] 10.4.5.6 -- 250 2.1.5 [EMAIL PROTECTED] 10.4.5.6 -- DATA 10.4.5.6 -- 354 Start mail input; end with CRLF.CRLF 10.4.5.6 -- . 10.4.5.6 -- 250 2.6.0 [EMAIL PROTECTED] Queued mail for delivery 10.4.5.6 -- QUIT 10.4.5.6 -- 221 2.0.0 piggies-blanket.pcevolution.com Service closing transmission channel Enjoy! Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
