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
