RE: [Leaf-devel] Re: Standards and due process :-)
Adding water to a boiling and already full kettle... 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. I am perfectly aware of the problems this solution brings along, but hey, at least it's one more opinion/idea! Take care -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 :-) On 2/28/02 at 4:24 PM, Serge Caron [EMAIL PROTECTED] wrote: For example, LEAF/LRP has in its unwritten feature set that users must log in. I have on occasions removed tinylogin and replaced the getty lines in /etc/inittab with /bin/ash /dev/ttyn /dev/ttyn 21. This is similar to what Trinux does - no login. Don't want to commit to gnu's sed? Use busybox sed during the load sequence and let the user supply whatever he wants. Oxygen doesn't use sed during boot. I want the user to float the baseline any way she sees fit for her situation. I don't WANT to provide packages for everything that she MAY want! When she finds a sed she likes, she decides how and where it will be packaged. As long the tools to do so are available, who cares what is running in system xyz? With the maximal fragmentation in Oxygen, one can strip out GNU sed for minised (or whatever) if it is desired - just rm sed.lrp and put in the desired msed.lrp... 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. It sounds like ANSI FORTH (did I say this before?). ANSI FORTH has a CORE Word Set, and a FLOAT Word Set, etc. An ANSI compliant FORTH may have a minimal number of Sets, but if they are compliant then it is ANSI Compliant with the CORE, [...etc...] Word Sets. Is this what you have in mind? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Adding water to a boiling and already full kettle... 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. I am perfectly aware of the problems this solution brings along, but hey, at least it's one more opinion/idea! I'm strongly considering something like this if I ever get back to working on the packaging system again (currently stuck in boot-strap development environment issues), although I'd probably do something like: pppd-2.1.4.leaf pppd-2.1.4.conf There's also the issue of using a single default store package, which could possibly also be supported by the same package system. The user could then choose how they wanted to backup...by individual package, or en masse. 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
Re: [Leaf-devel] Re: Standards and due process :-)
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. 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... 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? There are *LOTS* of tiny linux distributions, and a rapidly growing number of embedded linux distributions...what makes LEAF different from any of these? 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 a complete environment on their high-powered development machine, then burn a static filesystem image into their ROM, flash, or whatever storage media they're using, and that's pretty much the end of it. You may not even be able to write to a file, much less be able to install a package for new functionality. The tiny linux distribution folks are also substantially different from LEAF. Virtually all of these distributions are based on running from a hard-disk, and are essentially slimmed down versions of various full releases. Typically, if you don't have a hard-drive (or a good aproximation of one), you can't effictively run one of these distributions. LEAF, LRP, and a few other micro-distributions are designed to run without a 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 characteristics like the linuxrc script, and the 2.2 series kernel patches, exist due to the requirements of having a packaging system and dynamically constructing the run-time environment at boot. We've inherited a set of packaging and boot-strap conventions from LRP. It's already been shown that the boot-strap conventions are not required to make a LEAF system...this is evidence that while essential to a system actually working, the specific boot methodology is *NOT* a critically core part of LEAF. So...who wants to start playing with the packaging system and re-defining LEAF? Once the packaging system is smart enough to know which files are configuration files (and maybe even able to tell which files have changed), it becomes much easier to support a variety of potentially complex issues, allowing users, developers, or the in-between tinkerers to setup backups and the loading of configuration data the way they want. Lots of nifty ideas about this, but not enough time to jot everything down, and I don't want David getting mad at me again ;-) Seriously, I hope to have some time next week to begin to get some of the ideas bouncing around in my head out into the open, where they can grow and develop from everyone's input (or maybe they'll shrink back and be killed by the light). 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
Re: [Leaf-devel] Re: Standards and due process :-)
Charles Steinkuehler wrote: 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. 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. Yes -- the bounds to which are the objects of my lines of questioning . . . [ snip ] Once the packaging system is smart enough to know which files are configuration files (and maybe even able to tell which files have changed), it becomes much easier to support a variety of potentially complex issues, allowing users, developers, or the in-between tinkerers to setup backups and the loading of configuration data the way they want. Believe it or not, this is the end to all of my lines of questioning. Once we know this and know what can be expected -- and, corrallarily, what cannot be known -- then, and only then, can that system be ``in control'' and we can say that we are managing that system. Until that time, there is simply too little known about that system to quantify the degree of certainty that we can claim. Perhaps, this is where David parts company, since he is not interested in building firewalls; rather, his interest -- imho -- lies more in pushing various limits of these creatively designed systems. Yes, that is admirable creativity and inventiveness -- kudos, David! However, my primary interest in LEAF is management, monitoring and security based. I, for one, do *not* see these priorities as mutually exclusive; rather, I believe that these, and others equally different, views can coexist and grow and flourish together under the aegis of LEAF . . . Lots of nifty ideas about this, but not enough time to jot everything down, and I don't want David getting mad at me again ;-) Seriously, I hope to have some time next week to begin to get some of the ideas bouncing around in my head out into the open, where they can grow and develop from everyone's input (or maybe they'll shrink back and be killed by the light). I look forward to new ideas . . . -- 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
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/28/02 at 4:24 PM, Serge Caron [EMAIL PROTECTED] wrote: For example, LEAF/LRP has in its unwritten feature set that users must log in. I have on occasions removed tinylogin and replaced the getty lines in /etc/inittab with /bin/ash /dev/ttyn /dev/ttyn 21. This is similar to what Trinux does - no login. Don't want to commit to gnu's sed? Use busybox sed during the load sequence and let the user supply whatever he wants. Oxygen doesn't use sed during boot. I want the user to float the baseline any way she sees fit for her situation. I don't WANT to provide packages for everything that she MAY want! When she finds a sed she likes, she decides how and where it will be packaged. As long the tools to do so are available, who cares what is running in system xyz? With the maximal fragmentation in Oxygen, one can strip out GNU sed for minised (or whatever) if it is desired - just rm sed.lrp and put in the desired msed.lrp... 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. It sounds like ANSI FORTH (did I say this before?). ANSI FORTH has a CORE Word Set, and a FLOAT Word Set, etc. An ANSI compliant FORTH may have a minimal number of Sets, but if they are compliant then it is ANSI Compliant with the CORE, [...etc...] Word Sets. Is this what you have in mind? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
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
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/23/02 at 11:52 AM, Serge Caron [EMAIL PROTECTED] wrote: 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. 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 At least with ./ not in the root package the default.lrp or whatever will be quite small. Are you giving an example where files are dynamically stored in a package other than their package of origin? Yes. 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. 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. Oxygen uses ssmtpd, a minimalist SMTP daemon that recognizes a bare minimal set of sendmail options... No nc... my problem with nc is I don't want a space conflict with the full implementation of nc (which I have in a package). 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 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 quite a bit larger too. Nobody owns anything and the load order determine which contents stays on top. In Dachstein the load order is explicitly stated; in Oxygen the load order is indeterminate (since all packages are loaded automatically). This includes deleted files and it is possible, for example, to compute an MD5 digest taking into account these deleted files which means that it would be IMPOSSIBLE to reproduce this digest once the machine is running. So, if you build a system in a secure area and compute this digest, simply computing it again at boot time and displaying the signature will tell you right away if the system has been tampered with. I'm not sure if I followed all that - but Oxygen apkg already supports md5 digests ( /var/lib/lrpkg/pkg.md5 ) and verifies the md5sums during the boot process. Think of it this way: there can be a miniature sed during the time packages are loaded and a full blown gawkish monster available by the time the startup script for you package is started. Unlike the present situation, the monster does not have to be part of the enclosure: you can have a measure of redundancy that allows the enclosure to use busybox sed, for example, until such a time that the real thing is loaded whithout having the enclosure claim to be the exclusive residence of sed. The Oxygen boot process does not use sed, and instead has GNU sed 3.0 in a package on the disk (sed.lrp). v5.0.4 innovates in detecting the shell under which it is running. It is a lttle bit more pro-active. We are still mostly talking ash and busybox ash. I mentioned already that busybox ash comes directly from ash sources. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
At 2002-02-18 23:31 -0600, David Douthitt wrote: Well, that's not quite what I had in mind. For me, I was thinking more along the lines of: A distribution developer perhaps runs a script, writes some shell code, etc. - and creates a package (or shell script, really) which tests for various things. The script (or scripts) would work within the LEAF environment... Then a package creator (or software developer) would run a compilation of these scripts (which would have some overlap... and which overlap would be removed...) and it would tell him if his code was compatible with the environment or not. These scripts would be available to run in the LEAF environment, or any environment... David, This would be great. We definitely need a way to test packages against current releases/branches. Will redirection to file of output created by the package test run be possible? I'd like to see this information included in, or distributed with our packages. I'd prefer to see the information distributed with our packages in a separate parseable file. This will allow creation of a phpWS module, that is able to index our packages by release/branch compatibility OT: regexp question BTW, is it possible to use a not bracket expression against a string? Here is an example that doesn't work. :-( 'Content-Type: .*[^\(plain\|signed\)]' -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
I apolologize for leaving in the middle of an important conversation. Unfortunately, this will happen from time to time. Life gets in the way :-) Leaving in the middle? I never even got involved : Hopefully it's not too late to start jumping in... My personal experience is that you ride change, much like a horse, sometimes just for fun, sometimes to get from point A to point B. It's the falling off and turning into Christopher Reeve part that I'm worried about :-) In this case, I have submitted an idea supported by a bunch of definitions. The idea is that the contents of our initial RAM disks be unambiguously enumerated which imply that root (/) be moved to any other package (your choice!) which I call the default store. This does not require any adherence to any foreign code, programs or the like. In fact I can implement the entire concept in Oxygen 1.9 by editing two DATA files. The first one is root.list which contains the single entry ./ and which I replace with the unambiguous enumeration of the contents of root.gz (see the appendix below). The second one is any other file I choose as my default store: my personnal preference is home.lrp and I edit home.list to contain the single entry ./. 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... The code that I have submitted to support these ideas also promotes ease of deployment, ease of documentation, extensibility, and support for run of the mill appliances. The fact is, much of the code that runs once init receives control is the same in LRP, *stein, Bering and a number of other derivatives. Once he has a grasp that everything else can be enumerated, Michael can take the root 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 :). Packaging enhancements! Lowering the baseline! All good to me! :-) Actually, while I haven't been real involved in the disucssions here lately, I have been doing a bit of LEAF oriented work. I've been investigating the Gentoo ebuild process, and checking out some potential scripting languages (mainly Forth derivations and Lua). I think I'm ready to lower the bar 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 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 extend the scripting language once the system is booted, enabling more normal functionality, including honoring of local setting and similar. The Gentoo portage system also looks like it's tailor-made to create a compile environment for LEAF. I've successfully installed Gentoo into a directory on a RedHat system. While I currently cannot (and don't want to) boot directly into Gentoo (that wasn't the point), I *CAN* boot into RedHat, chroot to the Gentoo system, and ebuild to my hearts content. With the portage system already setup to handle system-wide user preferences for things like target CPU, optimization levels, etc, it should be fairly easy to make a LEAF system specification, and allow developers to both compile the entire system from source (very hard to do at the moment), as well as customize their systems. A plus is the ebuild files are pretty tiny, and perfectly suited for CVS archiving/versioning. The one (potential) drawback to the portage system is it seems to be restricted to x86 platforms at the moment, and I'd like to see support for other architectures. I have yet to crawl through the guts of the portage system and see if the Gentoo folks have thought this far ahead (srpms *DO* support keeping info for
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
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote: I apolologize for leaving in the middle of an important conversation. Unfortunately, this will happen from time to time. Life gets in the way :-) I, too, have been erstwhile distracted and now is not the best time to take on all detractors. It is disconcerting when one's words are taken other than literally and totally out of context. Never let it be said that that, alone, stopped me ; Nevertheless, now that Serge is back online, a few comments are in line: [ snip ] It is emotions and feelings that will drive Mike to discount his opinion because he is not producing code and it is emotions and feelings that prompt Charles to put value where value is due. I entirely support the expression of these emotions and feelings (which includes humor: I guarantee that if you can laugh at yourself, you will NEVER cease to be amused :). My personal experience is that you ride change, much like a horse, sometimes just for fun, sometimes to get from point A to point B. Sometimes, I ride the horse, because I am a horseman and horsemanship (change management) is a job at which I excel. In this case, I have submitted an idea supported by a bunch of definitions. The idea is that the contents of our initial RAM disks be unambiguously enumerated which imply that root (/) be moved to any other package (your choice!) which I call the default store. ``Unambiguous enumeration'' sounds precipitously close to defining convention, since convention, by definition, is ``General agreement or concurrence; arbitrary custom; usage; conventionality.'' When you distill a process down to its basic steps, then you have discovered that process's standard mode of operation. O, my! There is that dangerous word: standard. Nowhere in this process of discovery have I mentioned stricture, restriction, preclusion, obstruction, commandment, law, edict -- nor any other synonym for boundary, imposition nor limitation. That, dear readers, is intentional. [ snip ] I have seen this idea mocked and the discussion go all over the map from intents of imposing a de facto standard to attempts of restricting the expression of individuality of developers. Yet, given the fact that Oxygen 1.9+ may be compatible with tar.gz and plain gz ramdisks, and given the fact that the default store always retain the standard LRP format, I can only see benefits from this idea for Oxygen. Because it is an idea, it can be implemented by anybody in the form of their choice and does not have to BE part of a product offering. It can be documented and left at that. In my case, I wanted to use the product NOW and I choose to edit the two files. Further, when Oxygen 1.9+ becomes available, I will drop my home.lrp on the new kit and reboot with all my stuff intact. Instant upgrades are always interesting :). And, they are *possible*, because you have discovered the conventions and standards inherent in Oxygen 1.9+. If that is all that you have accomplished, that would be enough to illustrate my point. However, your theses are far more extensible than that, which prompts me to pursue this further . . . Not only do I think that David Douthitt is wright when he says there is no baseline, I aim to write my code for a minimalist implementation of everything (including sed :). My baseline is lower than his. However, Michael Schleif is also wright when he says 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. To distill a set of foreign processes into a common set of shared conventions and standards *IS* a baseline! If there is nothing in common between any two LEAF distributions, then there could not be such camaraderie as evidenced by this List Service. Fact is, there is more in common between these several distributions than there is between any two developers themselves. The fact that this genre, if you will, ``a class of artistic endeavor having a characteristic form or technique'', otherwise known as Linux Embedded Appliance Firewall, has a future and is moving from the status quo toward mainstream 2.4x kerneldom, tells me that this dialectic is a process in motion. What longterm purpose does it serve to keep these specifications arcane? I believe that it is possible to have these specifications without a baseline. When told that it was impossible to abstract something that would be common to 2.2 and 2.4 kernels, I actually produced a floppy on which people can comment. To quote from my February 11 post: You CAN voice your opinion and submit suggestions WITHOUT spending long hours in quality control. And so can anyone else. There is a disk at http://leaf.sourceforge.net/devel/scaron/discussion.img. It contains one boot loader, two kernels, four
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote: [ snip ] 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. Yes. Again, that a system successfully boots up is great! That I know what to expect in a system long after bootup is quite another thing ; 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. 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 :-) Building on your notion of ``unambiguous enumeration'', let it be said that the more that we know about a running system, the more that we understand the processes in motion that comprise that system, the more secure we can be. What is security? Part of it is knowing that a system is performing according to a specific set of specifications. Knowing which files, in what state and allowable contents, c. we should expect on the running system is, itself, a specification. As such, that specification is also a standard by which we can measure such interesting Events as system load, performance, intrusion, c. [ snip ] I am less excited by the building of the LEAF components themselves at this point (No! I do NOT like Red Hat 5.2 :-). I am certain that we can come up with an unambiguous way of specifying the whole system, even if we have to point out all the gotchas one by one. Then I will be excited for anything else I can put in there :-) Once we arrive at this ``unambiguous way of specifying the whole system'', then we have blown the lid off of previous limitations. Developers can concentrate on creating packages even better suited to the LEAF environment. As it is, we grab some off-the-shelf source, compile it on our slink over there in the corner and figure out how to shoehorn it into an LRP file. There is much more that many more people can do to contribute to the greater good of this project, once the system is understandable to outsiders . . . What do you think? -- 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
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/19/02 at 6:25 AM, Mike Noyes [EMAIL PROTECTED]
wrote:
At 2002-02-18 23:31 -0600, David Douthitt wrote:
David,
This would be great. We definitely need a way to test
packages against current releases/branches. Will
redirection to file of output created by the package test
run be possible? I'd like to see this information included
in, or distributed with our packages.
I'd prefer to see the information distributed with our
packages in a separate parseable file. This will allow
creation of a phpWS module, that is able to index our
packages by release/branch compatibility
Gak! I was just thinking that someone (like an rcf developer or a
Shorewall developer, etc.) would test their software against the
current versions - and that would be that.
You're going in way over my head - seems like overkill. I'd just say
the following: Compatable with: DistroX versionZ; DistroY versionQ
etc...
Or very possibly, a script that would run and test it. So thus, not
only the developer could use it, but a general user. The script would
run, and then it would say one of two things:
This software will not
run on your system. Check
the messages above for the
reason.
...or...
Compatability verified!
OT: regexp question
BTW, is it possible to use a not bracket expression
against a string?
Here is an example that doesn't work. :-(
'Content-Type: .*[^\(plain\|signed\)]'
The (...|...) construct is not recognized by much - I know egrep
(grep -e) recognizes it, but grep does not.
If you have UNIX in a Nutshell (worth getting!) look up the regexp
section - in mine, that's one of the most commonly used parts. Not
every regexp function is available everywhere there's regexps to be
had (like vi, grep, egrep, sed...)
Also, the way you've got it there, you are looking for anything that
starts with:
Content-Type:
...followed by any characters, then followed by one of the characters
NOT in the set of: ( a e i d g l n p ) |
If you are using a compatable egrep, you want:
egrep Content-Type: .*(plain|signed)
You could do the same thing with sed this way:
sed -n '/Content-Type: / {
/plain/p
/signed/p
}'
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
I was thinking... If you make root.list contain specific files, and move the specification of ./ to another package, that raises some interesting things 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 grow without bound if something is messed up. On 2/19/02 at 5:23 PM, Serge Caron [EMAIL PROTECTED] wrote: 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. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/19/02 at 2:25 PM, Charles Steinkuehler [EMAIL PROTECTED] wrote: Actually, while I haven't been real involved in the disucssions here lately, I have been doing a bit of LEAF oriented work. I've been investigating the Gentoo ebuild process, and checking out some potential scripting languages (mainly Forth derivations and Lua). I think I'm ready to lower the bar 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 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 extend the scripting language once the system is booted, enabling more normal functionality, including honoring of local setting and similar. Actually, this sounds like a ForthOS to me... The idea of running FORTH under Linux, or UNIX, or DOS, or Windows is actually new and against the grain.. FORTH was designed as its own environment, the way Smalltalk was - except FORTH is small :) A Forth system can include things like assembler, editor, multitasking in less than 64k - or even less. And the way Forth is, you EXTEND the language when you program in it. I've not heard of a FORTH router, but why not? Would be fun to get back into FORTH again... The Gentoo portage system also looks like it's tailor-made to create a compile environment for LEAF. I've successfully installed Gentoo into a directory on a RedHat system. While I currently cannot (and don't want to) boot directly into Gentoo (that wasn't the point), I *CAN* boot into RedHat, chroot to the Gentoo system, and ebuild to my hearts content. One of these days I'll install GenToo somewhere. However, first I've got to get my learning caught up on this OpenBSD/mac68k and Solaris/i86 I've just installed within the last week :) With the portage system already setup to handle system-wide user preferences for things like target CPU, optimization levels, etc, it should be fairly easy to make a LEAF system specification, and allow developers to both compile the entire system from source (very hard to do at the moment), I'm starting to get something together myself that will do this. I'm using the FreeBSD ports tree as my model, which is where GenToo took its inspiration from. I'm trying to write everything in sh (in makefiles) - which is much more powerful than people usually think :-) I'm nearly done doing this for root.gz in Oxygen; right now I've been doing binaries, one at a time. Next will be to gather all of the binaries together, create a filesystem, populate it, and then compress it to create root.gz... I'll also be upgrading all of the binaries in 1.8 and 1.9 since these new binaries all use glibc 2.1 - I think some of the root binaries still use glibc 2.0 calls, since I was also creating packages at the same time and wanted to use glibc 2.0 wherever possible. Now that packages and the base (root.gz) system trees are separate no problem. I expect I'll upload the entire tree in one of the coming weeks. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/17/02 at 5:52 AM, Mike Noyes [EMAIL PROTECTED] wrote: At 2002-02-16 21:31 -0600, David Douthitt wrote: I was thinking one would run this script in a LEAF environment - and it would be set up by a developer, who defines what is needed. Then you could boot Oxygen (or PacketFilter, or...) and run this script which tests the environment. David, Exactly. Then I thought we could take this output, and use it to check new packages for release/branch compatibility. The output could be placed in a text file, and parsed by another script that is designed to test packages. This new script wouldn't run from a LEAF environment. Instead, it would use a development environment. A release/branch lead developer runs the environment test script on his/her release/branch. He then places the output files on our site. A package developer downloads the environment test script output files to a machine with the package test script. The package developer then tests his/her new package. Well, that's not quite what I had in mind. For me, I was thinking more along the lines of: A distribution developer perhaps runs a script, writes some shell code, etc. - and creates a package (or shell script, really) which tests for various things. The script (or scripts) would work within the LEAF environment... Then a package creator (or software developer) would run a compilation of these scripts (which would have some overlap... and which overlap would be removed...) and it would tell him if his code was compatible with the environment or not. These scripts would be available to run in the LEAF environment, or any environment... $ lrp_pkg_tst.pl foo.lrp Testing foo.lrp ... file structure: OK program name: foo program version: 1.00 libc version: 2.1.3 Checking compatibility with Oxygen... Parsing 1.9 output: yes Parsing 1.8 output: yes Parsing Dec.2000 output: no Checking compatibility with Dachstein... Parsing 1.0.2 1680: no Parsing 1.0.2 CD: no I was thinking more like: # lrp_pkg_tst.sh requirements.txt Testing for test -z option... yes Testing for test -n option... yes Testing for NFS mount... no Testing for root.lrp... no Testing for 1.68M disk... no Testing for vfat support... no Testing for iso9660 support... no Testing for ide support... no [...etc...] Summary: Oxygen support: Ok Dachstein support: Ok Bering support: No # -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
At 2002-02-16 21:31 -0600, David Douthitt wrote: I was thinking one would run this script in a LEAF environment - and it would be set up by a developer, who defines what is needed. Then you could boot Oxygen (or PacketFilter, or...) and run this script which tests the environment. David, Exactly. Then I thought we could take this output, and use it to check new packages for release/branch compatibility. The output could be placed in a text file, and parsed by another script that is designed to test packages. This new script wouldn't run from a LEAF environment. Instead, it would use a development environment. A release/branch lead developer runs the environment test script on his/her release/branch. He then places the output files on our site. A package developer downloads the environment test script output files to a machine with the package test script. The package developer then tests his/her new package. $ lrp_pkg_tst.pl foo.lrp Testing foo.lrp ... file structure: OK program name: foo program version: 1.00 libc version: 2.1.3 Checking compatibility with Oxygen... Parsing 1.9 output: yes Parsing 1.8 output: yes Parsing Dec.2000 output: no Checking compatibility with Dachstein... Parsing 1.0.2 1680: no Parsing 1.0.2 CD: no I thought it was possible to determine the libc version used for compiling a package. The program name and version may require package developer intervention. After the new package is tested by the script, a text file is generated that can be included with the package, or kept separate. The output would provide information similar to your package repository .desc file. Now if you could just generate this set of (command) requirements (and option requirements) on the fly from a script That would be nice. :-) However, I don't think we'll see it any time soon, if ever. :-( -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
At 2002-02-16 07:25 -0600, David Douthitt wrote: On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... David, Would it be possible to apply something like this to package testing. e.g. Checking for program name: foo.bar Checking for program version: 1.00 Checking for libc version: 2.1.3 Checking compatibility with Bering: no Checking compatibility with Dachstein: no Checking compatibility with Oxygen: yes Checking compatibility with PacketFilter: no Checking compatibility with WRP: no -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
David, I should know better than to post this early in the morning. I didn't express myself well. See in-line comments below for an explanation. Sorry. :-( At 2002-02-16 05:42 -0800, Mike Noyes wrote: At 2002-02-16 07:25 -0600, David Douthitt wrote: On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... David, Would it be possible to apply something like this to package testing. Scratch the question above and replace it with: Would it be possible to parse the autoconf output above for package testing? e.g. Checking package file structure: OK Checking for program name: foo.bar Checking for program version: 1.00 Checking for libc version: 2.1.3 Checking compatibility with Bering... Parsing Bering autoconf output: no Checking compatibility with Dachstein... Parsing Dachstein autoconf output: no Checking compatibility with Oxygen... Parsing Oxygen autoconf output: yes Checking compatibility with PacketFilter: no Parsing PacketFilter autoconf output: no Checking compatibility with WRP: no Parsing WRP autoconf output: no -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/16/02 at 6:20 AM, Mike Noyes [EMAIL PROTECTED] wrote: At 2002-02-16 05:42 -0800, Mike Noyes wrote: At 2002-02-16 07:25 -0600, David Douthitt wrote: On 2/15/02 at 10:15 PM, David Douthitt [EMAIL PROTECTED] wrote: Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... Like this: Checking for busybox date no Checking for busybox install no Checking for ip... yes Checking for netstat... no Checking for route... no Checking for ifconfig... no ...etc... David, Would it be possible to apply something like this to package testing. Scratch the question above and replace it with: Would it be possible to parse the autoconf output above for package testing? I wasn't talking about actually USING autoconf... e.g. Checking package file structure: OK Anyway, apkg -v already does this... Checking for program name: foo.bar Checking for program version: 1.00 Checking for libc version: 2.1.3 Checking for program version requires a way to find it out. Not only that, it implies that if you need 1.00 but have 2.01a_Beta3 then you're alright - but try to program that... Finding the libc version is probably limited to checking the filename in /lib - but is limited again in the comparison values... Checking compatibility with Bering... Parsing Bering autoconf output: no Checking compatibility with Dachstein... Parsing Dachstein autoconf output: no Checking compatibility with Oxygen... Parsing Oxygen autoconf output: yes Checking compatibility with PacketFilter: no Parsing PacketFilter autoconf output: no Checking compatibility with WRP: no Parsing WRP autoconf output: no I was thinking one would run this script in a LEAF environment - and it would be set up by a developer, who defines what is needed. Then you could boot Oxygen (or PacketFilter, or...) and run this script which tests the environment. Now if you could just generate this set of (command) requirements (and option requirements) on the fly from a script -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
I would just like to thank everyone for this discussion. Due to limited examples and precise wording designed to be clear (but somehow let most of the information vague), I am finally coming into a more complete understanding of what was originally proposed, and what direction some developers would like to go. In a very basic sense, what is proposed is that the developers fully document _how_ and _what_ something is loaded, not to mention _what_ exactly is being used. A repository or port system would be used for each developers system, so users should not be confused to what will and will not work will this particular system and a clear direction to take when they need something that is not necessarily provided or capable or being done with the said existing system. I don't think anyone would argue that something clearly along these lines would best be implemented at _this_ point in time. I am most likely the common denominator to the general public among the developers ... I am not a professional programmer by any means, I just know enough to generally get done _what_ I am aiming for within my limited skills. I look forward to seeing the process and result of the vast and broad knowledge that exists within this group. It should be interesting and educational for me! Meanwhile, I'll be off doing docs, packaging, maybe a custom image, and the list (I really should think a little more before responding ... I make some real un-intelligent posts on a regular basis). Thx all! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Correction: my bad . . .
Michael D. Schleif wrote:
Voilà!
Serge Caron wrote:
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.
[ snip ]
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
This should read: LOCAL
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 ;
--
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
Re: [Leaf-devel] Re: Standards and due process :-)
Correction #2: my bad . . .
Michael D. Schleif wrote:
Voilà!
Serge Caron wrote:
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.
[ snip ]
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
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 ;
Perhaps, this is a calling for creation of this file:
/var/lib/lrpkg/*.list
This should be `local'
--
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
Re: [Leaf-devel] Re: Standards and due process :-)
David Douthitt wrote: On 2/14/02 at 8:05 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: 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 ; As far as I know, both Oxygen and Dachstein use GNU sed; Oxygen just happens to use sed 3.0 and Dachstein something older I think. Sorry, I was running off at the keyboard and forgot to check this: # /bin/sed -V GNU sed version 2.05 mawk.lrp is available, as is diff.lrp. I think busybox comes with sort - 0.60.2 anyway, in Oxygen... The point is, it is one thing to get a basic system to boot and initialize -- it is quite another to manage the running system. I agree that [mn]*awk is a luxury that may not be warranted in a base system. However, to manage the running system, it may be prudent to monitor changes to that running system, especially since one of the primary reasons for that system is to guard and protect the rest of the network on which it resides. In that spirit, I believe that real sort, cmp and possibly diff are warranted. But cmp? Who needs that? Besides the it's size? # uname -a Linux Loki 2.2.19 #1 Sat Oct 20 18:09:49 EST 2001 i686 unknown # ls -l /usr/bin/cmp /usr/bin/diff -rwxr-xr-x1 root root 9336 Aug 23 05:58 /usr/bin/cmp -rwxr-xr-x1 root root62076 Aug 23 05:58 /usr/bin/diff -- 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
Re: [Leaf-devel] Re: Standards and due process :-)
David Douthitt wrote: On 2/14/02 at 4:36 PM, Michael D. Schleif [EMAIL PROTECTED] wrote: For example, /var/log is the standard residence of logfiles. Is it? Only in Linux apparently; my Unixware and HP-UX systems use /var/adm/syslog. I am sorry that you always miss my point. We are on the LEAD List Service and happen to be discussing LEAF issues. However interesting it maybe to discuss AIX, HP-UX, Irix, c., these are non sequitur to this particular discussion. For example, the root directory (/) should be residence to directories *only* or, at least, *no* ordinary nor executable files -- or, should it? Many UNIXes (most?) use / as root's home directory. In your opinion, is that a `good' choice? For example, /etc should house, among else, configuration files, including a system of symbolic links facilitating system initialization, c. -- but, then, what about /var or /usr/local or /opt? ...and what about /var/state and /var/spool/cache? Precisely my point! Not only is standardization impossible, but the little variances are what makes a distribution individual and perhaps better than others. Nothing is impossible. In fact, your dependent clause, again, is my point! We have something in LEAF that is unique and worth defining better. I could list variance after variance - both within Linux distributions and out: * ip vs. ifconfig/netstat/route * /etc/init.d ; /etc/rc.d/init.d ; /sbin/init.d ... * /var/log ; /var/adm/syslog * apkg v. lrpkg * /usr/local/bin ; /opt * / vs. /root (home dir) * BSD /etc/rc vs. SysV /etc/rc.d/S000script ... * Some system binaries were commonly put into /etc... * System administration tools: linuxconf, webadmin, sysadm, sadm, smit, sam * vi vs. anything else (emacs?) * Package management: pkgadd; swinstall; rpm; debpkg; etc.. * Compression: compress; gzip; bzip2; zip... Again, what is your point in context of LEAF? I don't think we can force standardization - it's this sort of thing that makes the djbtools license so offensive... How many times need I state: ``NO, I am not advocating any system of commandments and laws, transgression of which invokes the ire of the greater community; rather, I believe that it is important -- no, critical -- that I, as LEAF user and, especially, as LEAF developer -- know what I can expect from a small set of system constructs.'' To take statements out of context does not make your arguments stronger. What do you think? -- 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
Re: [Leaf-devel] Re: Standards and due process :-)
At 2002-02-15 09:58 -0600, Michael D. Schleif wrote: How many times need I state: ``NO, I am not advocating any system of commandments and laws, transgression of which invokes the ire of the greater community; rather, I believe that it is important -- no, critical -- that I, as LEAF user and, especially, as LEAF developer -- know what I can expect from a small set of system constructs.'' Everyone, I have a few comments. Please remember I'm not a programmer. One of the reasons we started this project was to include diverse ideas/implementations of the original LRP. To facilitate this we have never forced any developers to follow specific standards. Ideas that are seen as good by the community will prosper, while ideas that are found to be impractical/undesirable will wane. You never know where the next great idea will come from, and this model allows new ideas to prosper. Naturally groups of developers will agree on specific proposals/ideas. This doesn't mean that they have the right to impose those proposals/ideas on others. We don't want the fragmentation of the past to repeat in the present. Michael, Please write up your proposal for the file structure. Post it on our site, and let each developer decide if it's useful. Note: I am in no way saying, that you should stop advocating your idea. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote: [ snip ] I am waiting for a plane and cannot do that right now. I suggest you visit http://leaf.sourceforge.net/devel/scaron/leaf.htm with a fresh eye and mess around with the discussion.img floppy. Please take apart root.lrp before you start (just for fun!). If I remember correctly, the floppy is designed to loose klogd if you backup root before you edit /bin/busybox.links to remove the line /sbin/klogd. So you can experiment either way. Don't flame me if it's too simple :-) I didn't realize that you had a webpage and formal presentation of your theses. Clearly, I entered this discussion through some later portal ; Where is this `discussion.img floppy'? I cannot find it referenced on your site . . . -- 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
Re: [Leaf-devel] Re: Standards and due process :-)
Michael D. Schleif wrote: David Douthitt wrote: [snip] Not only is standardization impossible, but the little variances are what makes a distribution individual and perhaps better than others. Nothing is impossible. In fact, your dependent clause, again, is my point! We have something in LEAF that is unique and worth defining better. And I think that's where some people miss the point. LEAF is not one thing, nor one project. It's an place for people who build Linux Embedded Appliances to gather and develop their whosymawhatchits. I never was under the impression that any two LEAF projects had to have anything in common at all. Dave is expressing that the individuality of one person's project that happens to be developed on leaf.sf.net, when compared to another developed on the same leaf.sf.net, is what makes them unique, special, stand on their own merit. What other seem to want to do is compare a non-existent sort of semi-official because it follows a standard LEAF distro with some other persons floppy OS project, perhaps freesco or something. That doesn't work. This place is just a central location for people to congregate. I don't think it's a top down, standards producing enumeration of anything. But that's just what I took from Mike Noyes's explanation of what LEAF was when I joined. Regards ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
At 2002-02-15 15:34 -0800, Matt Schalit wrote: That doesn't work. This place is just a central location for people to congregate. I don't think it's a top down, standards producing enumeration of anything. But that's just what I took from Mike Noyes's explanation of what LEAF was when I joined. Everyone, I'll take Matt's explanation a little further. This is a single project, but it's not monolithic. It's more of an evolutionary model, where various releases/branches are allowed to develop. Over time they may diverge, merge, and borrow from each other. Releases/branches survive on their merits, and the willingness of their lead developer(s) to continue working on them. Developers are free to help with any release/branch they wish. Releases/branches that are popular will likely receive more developer attention than ones that aren't. If a developer has an idea that a release/branch lead developer doesn't wish to use, he/she can always create another release/branch. This prevents fragmentation to multiple sites/locations on the Internet, and promotes survival of the fittest (evloution). It's a sort of controlled chaos that benefits all. Developers are able to share and propose ideas. Look at each others code. Lead developers no longer have to write all of their documentation, maintain web sites, or answer all of their own support requests. Users are able browse a single site and chose a release/branch that fits their needs. Of corse, the people that write the code may change this model if they wish. I haven't contributed any code to our project, so my opinion isn't worth much. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote: 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. No problem, my feelings weren't hurt. I was stating a fact. You called this list ho-hum, and that's an opinion devoid of any basis in fact. You contrasted this ho-humness with the passion reflected in MDS's posts. We don't deserve to be on the opposite side of that contrast, despite your limited analysis to the contrary. You're apparent willingness to describe your credentials is contrasted by your lack of doing your homework concerning the depth of commitment of the other users and the list's current state in history. May I suggest you backtrack a couple of years and read the Linux Router Project mailing list archive on Geocrawler, following the development and disposition of that group to here. You'll find peaks and valleys, great posts and tragic happenings. The history is rich and colorful, and the current group dynamic has never been better. What some people may not see is that we're functioning at a less than obvious level due mainly to the fact that so many people have already done such a fantastic job and and find they need to multitask more clocks to the rest of their life -- seeing that many LEAF parts work well, for all intents and purposes. So Joe User comes along wants this option or that option? bam. They got it. Someone updates ssh?bam it's done. That's 97X.. bam.. the future of rock and roll. 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! Roger that. I've been bad lately, though. Must follow golden rule more. Did you catch my essay on Basic PC Architecture in the 802.11/pcmcia/ide thread on leaf-user? 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. Affirmative. It was the tone that I made note of by quoting your very words, the snippets of which, though taken out of context, make for interesting reading. 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. Mmmm, I don't know. That last part sounds like you found an opinion in my post about PacketFilter, its application, its packaging, or what you want to do with it. What I did was bring up the question of it's originality and the veracity of creating something less than original while promoting that everyone adhere to it, even if it has some basis in fact. I tried to collect your words for examination rather than pass judgment on them. 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. Yes I quoted those out of context, and I think I got it right. If I wanted to be more thorough, I could have included more context and been fair enough to quote your showing respect for others. You took jabs at things in this project and in ways that others do not. That sticks out. I've been on enough lists with enough classic unixers to have met up with this style of communication. Though spicy, I have to yet to learn its benefit. Others enjoy discussing things with you due to your technical skill and fresh view. And I like reading some of it, but not when you offer up your analysis of us in the tone I mentioned. Regards, Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/15/02 at 9:58 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: David Douthitt wrote: On 2/14/02 at 4:36 PM, Michael D. Schleif [EMAIL PROTECTED] wrote: For example, /var/log is the standard residence of logfiles. Is it? Only in Linux apparently; my Unixware and HP-UX systems use /var/adm/syslog. I am sorry that you always miss my point. We are on the LEAF List Service and happen to be discussing LEAF issues. However interesting it maybe to discuss AIX, HP-UX, Irix, c., these are non sequitur to this particular discussion. Not entirely. One of the things I wanted to do with LEAF was a form of the standardization you were mentioning - except my attempt was towards a UNIX-like system. That was one of the reasons I absolutely hated giving up on ifconfig, netstat, and route powerful or not, 'ip' ONLY exists in Linux (can you say non-standard?) That's also one of the reasons that e3 starts in vi mode in Oxygen - that and the fact that I LIKE vi :-) For example, the root directory (/) should be residence to directories *only* or, at least, *no* ordinary nor executable files -- or, should it? Many UNIXes (most?) use / as root's home directory. In your opinion, is that a `good' choice? But that's not the point :P I hate seeing .ssh .mail etc all spread about in / but anyway... Not only is standardization impossible, but the little variances are what makes a distribution individual and perhaps better than others. Nothing is impossible. Getting three people to agree is :-) In fact, your dependent clause, again, is my point! We have something in LEAF that is unique and worth defining better. I think I see your point. I could list variance after variance - both within Linux distributions and out: Again, what is your point in context of LEAF? What about all the differences IN LEAF projects... one's I've listed already? * glibc 2.1 vs 2.0 - and soon may include 2.2 besides. * apkg vs. lrpkg * automatic loading of packages vs. having to enter *EVERY SINGLE ONE* into lrp.conf * GNU sed 2.x vs GNU sed 3.x * ipchains vs ipfwadm vs iptables * Linux 2.2 vs 2.4 vs. 2.0 * Multivolume support (during boot) vs. NO multivolume support * busybox contents - I suspect Dachstein busybox is about 120k or less; Oxygen busybox is now hovering about 320k or somewhere around there - and is statically linked * Unpatched Linux kernels vs. specialized LRP patched kernels... Can every LEAF developer agree on each of these? I suspect not... How many times need I state: ``NO, I am not advocating any system of commandments and laws, transgression of which invokes the ire of the greater community; rather, I believe that it is important -- no, critical -- that I, as LEAF user and, especially, as LEAF developer -- know what I can expect from a small set of system constructs.'' You almost sound like you are advocating something like the last ANSI FORTH standard. The ANSI FORTH standard defined a number of word sets. Words are like functions in C, but then any new programs are indistinguishable from the base Anyway, the ANSI committee defined word sets like CORE (the very minimalist most basic words) FLOAT (floating point, normally not included in FORTH environments...) EXTENDED and others (names escape me). What if we had a LEAF core set which meant things like: * these commands will be included * these commands will act this way and an extended set which may or may not be present, but if they are, they must act the proper way and they must all be present. That's how the ANSI FORTH standard works; a compliant FORTH system can say they include the CORE set, the EXTENSION set, or whatever... To take statements out of context does not make your arguments stronger. You seem to have very strong feelings about this and other things. Persuasive argument must be level-headed. I still feel like one can't get three people to agree on anything. The ANSI FORTH committee was hogbound for YEARS. Alternately, the new standard often doesn't look like anything which is available! The ANSI FORTH and ANSI COBOL (object oriented!) went this way. Perhaps what we NEED is a test suite - a sort of minimalist autoconf which details what works and what doesn't... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ 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 :-)
Serge Caron wrote:
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.
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?
By-the-by, this is considerably faster:
sed -e /^[./]*etc/d ${pkg} ${pkg}.light
[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?
[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 . . .
[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.
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 ;
What do you think?
--
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
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
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote:
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 :)
[ 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 . . .
--
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
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 :-)
Serge Caron wrote:
[ snip ]
mds said:
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 :).
Nevertheless, since all backup operations are performed from root (/) --
a very sound *convention* and *standard*, yes? -- what is the actual
difference between our regex's, other than doing everything in one (1)
call to shell?
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
If you must:
sed -e /^etc[[:space:]]*$/d
/^[/]etc[[:space:]]*$/d
/^[.][/]etc[[:space:]]*$/d
/^etc[/]/d
/^[/]etc[/]/d
/^[.][/]etc[/]/d ${pkg} ${pkg}.light
Or:
sed -e /^[.]\{0,1\}[/]\{0,1\}etc[[:space:]]*$/d
/^[.]\{0,1\}[/]\{0,1\}etc[/]/d ${pkg} \
${pkg}.light
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 ;
[ 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 . . .
[ 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.
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.
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!
Let us take what has been learned from years of LRP, take what has
worked best, discard what has proven most costly -- however many or few
those specifications might be -- and make a clean break with the past.
Draw a line in the sand -- this side is the new land of LEAF and that
other side is the past and LRP. Again, these clear demarcations --
devised solely in the spirit of the lean and mean and embeddedness that
we admire most in LEAF -- can only contribute to the greater good.
NO, I am not advocating any system of commandments and laws,
transgression of which invokes the ire of the greater community; rather,
I believe that it is important -- no, critical -- that I, as LEAF user
and, especially, as LEAF developer -- know what I can expect from a
small set of system constructs.
For example, /var/log is the standard residence of logfiles. Looking
under that directory, I should never find executable files -- or, should
I?
For example, the root directory (/) should be residence to directories
*only* or, at least, *no* ordinary nor executable files -- or, should
it?
For example, /etc should house, among else, configuration files,
including a system of symbolic links facilitating
Re: [Leaf-devel] Re: Standards and due process :-)
Voilà!
Serge Caron wrote:
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.
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?
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?
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
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 ;
Perhaps, this is a calling for creation of this file:
/var/lib/lrpkg/*.list
[2] Now, I must ask, again, how do you account for configuration files
that reside elsewhere, say /usr/share/snmp/snmpd.conf? 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''
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.
Yes, good point. Nevertheless, this is, perhaps, the most pernicious
flaw in the current system.
Did anybody say that the current system is perfect? Notwithstanding,
the convention-al, standard-ness to its essence? No, I am not flaming
the current system, nor any part thereof; rather, it is this learning
process that begs for elucidation, regardless whether or not you like
the terms 'convention' and 'standards'! If the current system changes
-- I guarantee that it will -- the convention is to publish those
changes to the user community, such that users of the system can use the
system in the proscribed manner.
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.
[1] If they reside in root.lrp -- *always* the FIRST package loaded! --
then, your laziness in not creating bindc.list bites you in the a**,
because bindc.lrp just over-wrote your precious configuration files!
[2] If you are going to ``create a configuration package'', then why
bother with this kludge at all? Why not build a better mousetrap and be
done with it?
What I want is the entire contents of etc (and other stuff) as if I was
working with persistent storage without affecting each package.
Yes, we all do -- at minimum cost.
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
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 8:05 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: 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 ; As far as I know, both Oxygen and Dachstein use GNU sed; Oxygen just happens to use sed 3.0 and Dachstein something older I think. mawk.lrp is available, as is diff.lrp. I think busybox comes with sort - 0.60.2 anyway, in Oxygen... But cmp? Who needs that? -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 4:28 PM, Serge Caron [EMAIL PROTECTED] wrote: 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). The Oxygen config.lrp is the same exact thing - except instead of pulling from /etc and /var, it pulls all configuration files. Just like yours, it is loaded LAST. That's what makes it a configuration file; it doesn't matter where in the boot process it is found; it is still loaded last (saved in /tmp and loaded from there...) 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? Neither. This would be general purpose script to be used this way: # cd /tmp # apkg -c root # mkfs.image root | gzip -c - /mnt/floppy/root.gz ...or some variation. The script I'm refering to is here called mkfs.image. 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 file I mentioned would be included in nistnet.lrp, and would be similar to: Name: nistnet Version: 2.0.10 URL: http://www.antd.nist.gov/itg/nistnet/nistnet-2.0.10.tar.gz Description: A Network Emulator from the US NIST Group: Network/Diagnostics ...and so forth. I'm going from memory; check http://leaf.sf.net/pub/oxygen/development/ for more information. As I said, it needs work. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 3:34 PM, Serge Caron [EMAIL PROTECTED] wrote:
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
...I just LOVE a good sed challenge :-)
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
First, with GNU sed:
sed -e '..' -e '..' -e '...'
can be written as:
sed '; .; .'
...also, it would appear that your matches are overlapping... why
not:
sed '/\.*\/*etc/{
/^etc[ ^I]*$/d
/^\.\/etc[ ^I]*$/d
/^\/etc[ ^I]*$/d
/^etc\//d
/^\.\/etc\//d
/^\/etc\//d
}' $pkg $pkg.light
The first line matches only those things that contain etc with any
number of periods and slashes (in that order) - which means you've
just ruled out a TON of things. Should be faster - only one match...
Using \. instead of [.] will save you one '.' - and it is probably
faster to use a single character instead of a set.
You don't need curly brackets ${} unless it is unclear where the name
starts and ends so ${pkg} is unnecessary, as is ${pkg}.light
(period stops the name) - but ${pkg}light and ${pkg}2 are necessary
if you want pkglight and pkg2 for names...
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.
netstat was also removed from Oxygen a while back; I think Linux in
general has made plain that netstat / route / ifconfig are to be
considered old and one is to use ip instead.
Oxygen dumped all three when space got tight; they are available as
packages.
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 4:36 PM, Michael D. Schleif [EMAIL PROTECTED] wrote: For example, /var/log is the standard residence of logfiles. Is it? Only in Linux apparently; my Unixware and HP-UX systems use /var/adm/syslog. For example, the root directory (/) should be residence to directories *only* or, at least, *no* ordinary nor executable files -- or, should it? Many UNIXes (most?) use / as root's home directory. For example, /etc should house, among else, configuration files, including a system of symbolic links facilitating system initialization, c. -- but, then, what about /var or /usr/local or /opt? ...and what about /var/state and /var/spool/cache? Not only is standardization impossible, but the little variances are what makes a distribution individual and perhaps better than others. I could list variance after variance - both within Linux distributions and out: * ip vs. ifconfig/netstat/route * /etc/init.d ; /etc/rc.d/init.d ; /sbin/init.d ... * /var/log ; /var/adm/syslog * apkg v. lrpkg * /usr/local/bin ; /opt * / vs. /root (home dir) * BSD /etc/rc vs. SysV /etc/rc.d/S000script ... * Some system binaries were commonly put into /etc... * System administration tools: linuxconf, webadmin, sysadm, sadm, smit, sam * vi vs. anything else (emacs?) * Package management: pkgadd; swinstall; rpm; debpkg; etc.. * Compression: compress; gzip; bzip2; zip... I don't think we can force standardization - it's this sort of thing that makes the djbtools license so offensive... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote: 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 Hey Serge, 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 learn from a variety of people considering all their experiences. Over the course of your posts you've taken the opportunity to try to stir up the nest with a certain tone set by your words that I've collected here out of context: hum-drum list passion social responsibility attained a critical mass we are old enough to see will make LEAF grow effortlessly All LEAF/LRP releases are only scripts the proposal is painfully clear provide an unambiguous enumeration I find mildly amusing is that people are confused You do the math. Having spent several million dollars of my own money Up until 3 weeks ago, LEAF was a quaint little space It follows that best practice would be an obvious waste that is not acceptable Common sense dictates This library is obviously not used in the appliance This is the type of stupid political decision that is made to save face You and I have no time or desire left for stupidity as long as these gentlemen continue to maintain their present offering Freedom is something I value more than grown up games. I'm not sure where you got the idea that this list, this project, or any of us lacked passion. That's kind of insulting. And what 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 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. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote:
[ snip ]
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
[ snip ]
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
[2] How do you account for ${pkg}.exclude.list?
[3] How do you account for CONF files that do not reside under /etc?
[4] Where do you get `cmp'?
--
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
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/13/02 at 8:16 PM, Serge Caron [EMAIL PROTECTED] wrote:
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:
Yeah! CODE! :)
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
How about this:
for pkg in /var/lib/lrpkg/*.list ; do
if grep -q [./]*etc ; then
sed '/[^\/]*etc/d' $pkg $pkg.2
mv $pkg.2 $pkg
echo $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.
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
And I DON'T have to rewrite all of the packages...
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?
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.
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?
One of the ways I felt I could help LEAF (or LRP) was to package up
everything I wanted - or everything in sight, which was about the same
thing :-)
The repository is one of two things. I've tried to make a repository
in that I've been gathering a lot of packages together, too. However,
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
This information is then read by the Lua script and converted to
HTML
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
