-----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. Anything else must be specified by LEAF. [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 :-) BTW, do you have a replacement script for the POSIXness.mail mail command? And which smtp _output_only_ is preferred out there? Regards, Serge Caron _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
