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
[Leaf-devel] ppp demand dial on Dachstein
Larry, I moved this to the devel list. At 2002-02-19 09:10 -0800, Larry Platzek wrote: Mike just thought would tell you that Kenneth's PPPd pages are AWOL. They are still available. Kenneth disabled the ppp link from his /devel/khadley/index.html page during the beta test period. http://leaf.sourceforge.net/devel/khadley/old_ppp.html http://leaf.sourceforge.net/devel/khadley/ppp.html http://leaf.sourceforge.net/devel/khadley/ppp-cd.html Did you find any other problems with Kenneth's new pppd image? Known problem: lrcfg ppp menu items are missing. I do have Bering running doing demand dialing. My workstation has a 192.168.xxx.xxx type address and my firewall (Bering computer) also has same address range and dial my isp just fine. Thanks for the information. :-) -- 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
[Leaf-devel] Re: ppp demand dial on Dachstein
Mike I never could get his PPPd image to dial even if I editted the files directly. Will try again if someone can tell me what to try. I do have Kenneth's earlier version (EigersteinBETA2) working, but idle would never timeout my isp multicast every 30 seconds. Glad his images/pages are still directly available. I am willing to try images that dial serial modems. Larry Platzek [EMAIL PROTECTED] On Tue, 19 Feb 2002, Mike Noyes wrote: Date: Tue, 19 Feb 2002 09:32:53 -0800 From: Mike Noyes [EMAIL PROTECTED] To: Larry Platzek [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: ppp demand dial on Dachstein Larry, I moved this to the devel list. At 2002-02-19 09:10 -0800, Larry Platzek wrote: Mike just thought would tell you that Kenneth's PPPd pages are AWOL. They are still available. Kenneth disabled the ppp link from his /devel/khadley/index.html page during the beta test period. http://leaf.sourceforge.net/devel/khadley/old_ppp.html http://leaf.sourceforge.net/devel/khadley/ppp.html http://leaf.sourceforge.net/devel/khadley/ppp-cd.html Did you find any other problems with Kenneth's new pppd image? Known problem: lrcfg ppp menu items are missing. I do have Bering running doing demand dialing. My workstation has a 192.168.xxx.xxx type address and my firewall (Bering computer) also has same address range and dial my isp just fine. Thanks for the information. :-) -- 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
[Leaf-devel] Re: Standards and due process :-)
Hello all, I apolologize for leaving in the middle of an important conversation. Unfortunately, this will happen from time to time. Life gets in the way :-) Message: 4 Date: Fri, 15 Feb 2002 18:26:00 -0800 From: Matt Schalit [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) To: [EMAIL PROTECTED] No problem, my feelings weren't hurt. I was stating a fact. You Good. We are in the business of change and it is a business of emotions and feelings, not one of logic and certainly not one of wright or wrong. 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. 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 ./. I can use Oxygen 1.9 right now, even without the backup code that will be part of a later update. I obviously use it in ways that its author has not envisionned. Further, root.gz with the edited root.list satisfies in every way the definition I have put forward for the concept of an enclosure. 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 :). 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. 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 packages, one enclosure, and one appliance. This appliance is the ENTIRE startup code from Bering beta3 and which I made compatible to Linux 2.2 kernels by changing 5 lines. Two packages are ne2k-pci cards modules for 2.2 and 2.4 kernels: they are mutually incompatible :-). The last two packages are ipchains and iptables (how did you guess?). There is about 10kb left to play with. Now, a FLOPPY that contains TWO kernels and compatible modules should at least generate some interest in the process, especialy one that loads ip filtering code according to kernel version. So far, I must report NO mail. 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
Re: [Leaf-devel] ppp demand dial on Dachstein
I will attempt to get this fixed tonight(the ppp menu) one thing to remember is the ppp.lrp package on the dachstein cd's are not mine.therefore this error should in ppp.lrp exists on ALL dachstein v.1.02 cd's I will confirm this and if so probably replace the floppy ppp.lrp package (that came from the dachstein CD) with my ppp.lrp package as to going AWOL ;-) I suppose that's a accurate term since I've been so busy starting a WISP and have barley had the time to do anything. -Kenneth Hadley - Original Message - From: Mike Noyes [EMAIL PROTECTED] To: Larry Platzek [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 19, 2002 9:32 AM Subject: [Leaf-devel] ppp demand dial on Dachstein Larry, I moved this to the devel list. At 2002-02-19 09:10 -0800, Larry Platzek wrote: Mike just thought would tell you that Kenneth's PPPd pages are AWOL. They are still available. Kenneth disabled the ppp link from his /devel/khadley/index.html page during the beta test period. http://leaf.sourceforge.net/devel/khadley/old_ppp.html http://leaf.sourceforge.net/devel/khadley/ppp.html http://leaf.sourceforge.net/devel/khadley/ppp-cd.html Did you find any other problems with Kenneth's new pppd image? Known problem: lrcfg ppp menu items are missing. I do have Bering running doing demand dialing. My workstation has a 192.168.xxx.xxx type address and my firewall (Bering computer) also has same address range and dial my isp just fine. Thanks for the information. :-) -- 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 ___ 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] Replacement mail command
BTW, do you have a replacement script for the POSIXness.mail mail command? And which smtp _output_only_ is preferred out there? IIRC, David D. has some tiny SMTP mailers as part of Oxygen. I think there are maybe some messages from him about this in the list archives, or maybe he'll chip in again with some info... 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 :-)
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
[Leaf-devel] Default Stores, ash, etc.
On 2/19/02 at 2:01 PM, Serge Caron [EMAIL PROTECTED] wrote: 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 paragraph explains a *LOT* more than those terms you were using - I never was able to understand it, until you said what you did... With the new use of root.gz, this is almost what is happening - since root.gz is a compressed filesystem, the contents of root.gz will not change under normal use - or even erroneous use - as happens sometimes when using a root.list of ./ ... Adding a NEW package with the entry ./ in the new Oxygen environment (which uses root.gz) would be interesting. It basically means you can extend the base without having to create packages or other things. But then, would this capability be useful? I can use Oxygen 1.9 right now, even without the backup code that will be part of a later update. I obviously use it in ways that its author has not envisioned. Further, root.gz with the edited root.list satisfies in every way the definition I have put forward for the concept of an enclosure. It's alright by me - I'm glad you used Oxygen, and it's nice to see people hacking away and trying things. Don't get discouraged. 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. It should be documented; please do. Write up a text file (HOWTO) and explain things. One note: explain everything without using the words default store unambiguous enumeration appliance and others even once. These terms only serve to confuse. 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 :). I thought that's what config.lrp was for. If you use home.lrp as you've said, with ./ in home.list - isn't that new package going to be obliterated with a NEW home.lrp? 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. That says something. I would have looked at it, but I've been very busy recently. Like you said: Life gets in the way :) 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. What really separates one LEAF distribution from another was what happens BEFORE init takes control - once control is given to init, then it's normally in the hands of /etc/rc 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. Huh? v5.3.0 is my standard busybox ash experiment: I have tested on many occasions the compatibility of busybox ash to the Debian ash. In this case, I simply replaced the busybox in the original enclosure with the busybox found in Oxygen 1.9. busybox ash is not a drop in replacement for ash, but it is getting better all the time. Actually, it *IS* a drop-in replacement - after all, busybox ash comes from debian ash directly. It's the same code, massaged a little more. In this case, there is a Segmentation fault in the following construct: # Modules required to complete the boot process if [ -r $BOOTDIR/etc/modules ] ; then # (Do not process comments and white space.) (blind cat $BOOTDIR/etc/modules; echo) | sed -e s/#.*$//1 -e /^[[:space:]]*$/d | while read module args; do blind insmod $BOOTDIR/lib/modules/$module.o $args done fi There is nothing wrong with this construct and it will run perfectly if it is moved around in the script (the segmentation faults happens in the pipe between sed and the while clause). In the problem at hand, the file is empty and the startup continues correctly. It is the ONLY thing to report for the scripts in this enclosure when using a 2.2 kernel. There is about a dozen Segmentation faults when using a 2.4 kernel, none of them fatal. What
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
