> > Which brings up another question that's been nagging > > at me ever since I installed ramdisk.lrp to put > > /var/log on it's own: why do I need ramdisk.lrp, > > anyway? The whole LRP-thing is operating out of a ram > > drive! Can't a second ramdrive be specified in > > /etc/fstab mounted at /var/log? Is it a different kind > > of ramdrive? Anybody know? > > If your logs go crazy and expand they can consume the entire filesystem > on which they reside. If you have only ram0, that is the filesystem > that will fill up. If ram0 fills up, then the operating system *cannot* > operate, because to do something new, it needs memory in which to do it. > > Placing /var/log on ram1 gives your logfiles limited space in which to > expand. Even if ram1 fills up, the operating system can continue to > operate . . .
Continuing, the reason you need ramdisk.lrp (or ramlog.lrp) is because otherwise there is no provision for creating and formatting additional ramdisks. You could put mount entries in fstab, but without formatting them first, the ramdisks are pretty much useless. There are something like 16 available ramdisks...try mounting one: mount -t minix /dev/ram7 /mnt ramdisk.lrp provides the mkfs.minix binary, for formatting the additional ramdisks, and an init script to create the new ramdisks from a configuration file. Ramlog.lrp also provides a script that uncompresses any files found in /etc/ramdisk/ (they're assumed to be tar.gz files), so it can populate things like the /var/log filesystem after it's been created and mounted. It would be better to create yet another packge...something like "loadmore.lrp", which would load LRP packages *after* extra ramdisks have been created/formatted/mounted, avoiding the problems encountered when trying to get several packages to use an additional ramdisk...I would have done this already, but there are only so many hours in the day <sigh> Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) P.S. Nifty solution to the weblet logs issue coming as soon as I come up with one and can test it. I'll probably just fix the viewlogs cgi script, which is intentionally paranoid about which files it allows to be accessed (weblet logs should also be rotated and added as links to the main weblet page). It can be real easy to create gaping security holes (from simple ../../ expansions to shell meta-character expansion vunerabilities) in conventional web-servers, much less one written in shell-script...I've tried to close as many holes as possible, although I'm sure there are still a number of potential vunerabilities if anyone cares enough to try and find them, but that can make some things a bit harder than it seems like they should be at first glance... _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
