Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
> Build a single sed command to delete any un-desired file specs, and strip > off the purge-level...start with /^1/!d (where one is the desired purge > level), add delete commands for each sub-mount point (ie \:var/log/httpd:d), > and end with a substute command to strip the leading field ( s/^[0-9 > ]*// ) and run it on all the purge-able file lists (for FILE in `sed > $sedcmd /etc/purge.d/*` ; do rm $FILE ; done) Oops! You also need to delete any files that don't reside on the over-full partition before the final substitute command... 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] [dachstein] lrp.conf/multicron Spacecheck problem
> > I think ideally, checkfreespace would have to determine which filesystem the > > purge-able files reside on. One of my major goals for a new distribution is > > to gracefully support flexible mount-points. While the purge-able files may > > not change, and so could be included as part of the package itself, there's > > no way for a package to know ahead of time exactly which file-system the > > files will reside on. > > I didn't want to assume; but, that direction makes sense if packages are > to contain purgeable file definitions. > > Is it fair to say that *all* applicable filesystems are ramdisks and, > therefore, can be identified according to form: /dev/ramX ? No. Even in existing systems, some folks have hard-disks, or will leave the floppy or CD-ROM drive mounted. The CD-ROM causes problems, as it's always 100% full. Systems may also be using flash disks (MTD), Disk-on-Chip (M-systems or MTD driver), and other devices for storage. > The tools available are busybox grep and sort, and real sed? Plus ash (the built-in string handling is quite powerful, once you get the hang of it...see the sh-httpd script for some examples). In general, I'd say anything that's on Dachstein right now would be usable, but stick with the ash subset of available bash commands. > Once I define the requirements, then I can build it . . . I'm envisioning something like: df indicates a partition is past is usage limit...mount points saved for use later /proc/mounts checked to verify partition is RW purgable file list built from "/etc/purge.d" directory or similar. Remember, sed can be very powerful for things like this... Assume a directory of files, with each file containing entries (one per line), consisting of two fields, a number (the purge-level), and a file-spec (wildcards OK). Check the list of mount-points for any with a leading portion that matches the over-full mount point (ie /var/log is full, but /var/log/httpd, a seperate mount point, isn't). Add any matching mount points to an exclude list. Build a single sed command to delete any un-desired file specs, and strip off the purge-level...start with /^1/!d (where one is the desired purge level), add delete commands for each sub-mount point (ie \:var/log/httpd:d), and end with a substute command to strip the leading field ( s/^[0-9 ]*// ) and run it on all the purge-able file lists (for FILE in `sed $sedcmd /etc/purge.d/*` ; do rm $FILE ; done) Verify enough space has been made available on file-system...if not, increase purge-level and repeat... 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] [dachstein] lrp.conf/multicron Spacecheck problem
Charles Steinkuehler wrote: > > > > I will at least apply the one line fix in the next release. For the > future, > > > I'd like to see support for a configuration directory. There would be > some > > > default entries, while add-on packages could drop entries into the > > > "/etc/purge.d" (or whatever) directory, with customizations for any > large > > > temporary files the particular package generates. > > > > Do you anticipate that the program (e.g., checkfreespace()) must decide > > on which filesystem purge-able files reside, or do you see this as a > > manual, pre-configuration issue for the system administrator? > > Hmm... > > I think ideally, checkfreespace would have to determine which filesystem the > purge-able files reside on. One of my major goals for a new distribution is > to gracefully support flexible mount-points. While the purge-able files may > not change, and so could be included as part of the package itself, there's > no way for a package to know ahead of time exactly which file-system the > files will reside on. I didn't want to assume; but, that direction makes sense if packages are to contain purgeable file definitions. Is it fair to say that *all* applicable filesystems are ramdisks and, therefore, can be identified according to form: /dev/ramX ? The tools available are busybox grep and sort, and real sed? Once I define the requirements, then I can build 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] [dachstein] lrp.conf/multicron Spacecheck problem
Am Dienstag, 22. Januar 2002 19:39 schrieb Michael D. Schleif: > KP Kirchdörfer wrote: > > Am Dienstag, 22. Januar 2002 19:21 schrieben Sie: > > > KP Kirchdörfer wrote: > > > > Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler: > > > > > I will at least apply the one line fix in the next release. > > > > > For > > > > > > > > I've done the "one line" fix, which is indeed a two-line fix > > > > in lrp.conf and multicron. > > > > > > [ snip ] > > > > > > What is the second line? What do you change in /etc/lrp.conf? > > > My initial proposal requires only one (1) line modification and > > > only in multicron . . . > > > > I've added > > lrp_CHK_PART=/ > > > > to lrp.conf and used this variable in multicron, for the reasons > > I've explained in the mail you're referring to. > > As you know, this does nothing to address the issues regarding > *which* files to purge. Ok, you're right - due to private circumstances I'm not that concentrated I wish I am... Sorry for confusion and starting at the beginning of the discussion. > What do you make of my most recent proposal that completely > resolves both your mailspacelow() issue, as well as the file purge > issues? I've saved it in my mailfolder and thought, it might be worth for testing. kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
> > I will at least apply the one line fix in the next release. For the future, > > I'd like to see support for a configuration directory. There would be some > > default entries, while add-on packages could drop entries into the > > "/etc/purge.d" (or whatever) directory, with customizations for any large > > temporary files the particular package generates. > > Do you anticipate that the program (e.g., checkfreespace()) must decide > on which filesystem purge-able files reside, or do you see this as a > manual, pre-configuration issue for the system administrator? Hmm... I think ideally, checkfreespace would have to determine which filesystem the purge-able files reside on. One of my major goals for a new distribution is to gracefully support flexible mount-points. While the purge-able files may not change, and so could be included as part of the package itself, there's no way for a package to know ahead of time exactly which file-system the files will reside on. 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] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: > > Am Dienstag, 22. Januar 2002 19:21 schrieben Sie: > > KP Kirchdörfer wrote: > > > Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler: > > > > I will at least apply the one line fix in the next release. > > > > For > > > > > > I've done the "one line" fix, which is indeed a two-line fix in > > > lrp.conf and multicron. > > > > [ snip ] > > > > What is the second line? What do you change in /etc/lrp.conf? My > > initial proposal requires only one (1) line modification and only > > in multicron . . . > > I've added > lrp_CHK_PART=/ > > to lrp.conf and used this variable in multicron, for the reasons I've > explained in the mail you're referring to. As you know, this does nothing to address the issues regarding *which* files to purge. Besides, Charles was replying to my one-line proposal . . . What do you make of my most recent proposal that completely resolves both your mailspacelow() issue, as well as the file purge issues? -- 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] [dachstein] lrp.conf/multicron Spacecheck problem
Charles Steinkuehler wrote: > > > For instance, just because your /var/cache maybe full, do you want to > > arbitrarily purge /var/log files? > > > > Not for an instant do I suggest that such complexity is insurmountable; > > rather, it should be clear that this is far more involved and requires a > > new paradigm, other than: > > > > lrp_SC_DEL_L1="/var/log/*[4-9].gz" > > lrp_SC_DEL_L2="/var/log/*[1-3].gz" > > lrp_SC_DEL_L3="/var/log/*.gz" > > lrp_SC_DEL_L4="/var/log/*.0" > > lrp_SC_DEL_L5="/var/log/wtmp" > > > > Also, do not forget, I do not recommend my solution for its > > completeness; rather, I recommend it because it more accurately > > addresses the *default* DCD distribution, can be done by changing one > > (1) line in the current distribution and does *not* require considerable > > development and testing time. > > I will at least apply the one line fix in the next release. For the future, > I'd like to see support for a configuration directory. There would be some > default entries, while add-on packages could drop entries into the > "/etc/purge.d" (or whatever) directory, with customizations for any large > temporary files the particular package generates. Do you anticipate that the program (e.g., checkfreespace()) must decide on which filesystem purge-able files reside, or do you see this as a manual, pre-configuration issue for the system administrator? > Long Term: > I'd also like to see the configuration directory approach taken to logrotate > (similar to my RedHat distributions, which already do this), and even inetd > (switch to xinetd?). Using files in a configuration directory makes the > seperation of configuration information into packages much easier, ideally > avoiding any pre/post package install/remove configuration required (or at > least limiting it as much as possible). Yes, this appears reasonable. I do not know these features of Redhat -- is there anything similar on Debian? Anyway this goes, as you know from my latest proposal, I have already done the work to get checkfreespace() to df *all* filesystems. That was very simple. Now, we need to decide on the the management system for purge-able files. Once the line is drawn in the sand, I can develop the infrastructure to make appropriate data available to checkfreespace(). 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] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: > > Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler: > > > I will at least apply the one line fix in the next release. For > > I've done the "one line" fix, which is indeed a two-line fix in > lrp.conf and multicron. [ snip ] What is the second line? What do you change in /etc/lrp.conf? My initial proposal requires only one (1) line modification and only in multicron . . . -- 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] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: >>Long Term: >>I'd also like to see the configuration directory approach taken to >>logrotate (similar to my RedHat distributions, which already do >>this), and even inetd (switch to xinetd?). Using files in a >>configuration directory makes the seperation of configuration >>information into packages much easier, ideally avoiding any >>pre/post package install/remove configuration required (or at least >>limiting it as much as possible). >> > >Good ideas; unfortunately xinetd seems to be tree times bigger than >inetd and tcpd. > Tcpserver from Dan Bernstein's ucspi-tcp package isn't too big, and has per-service configuration files iirc. Of course it only handles tcp streams. But for the bandwidth monitor and sh-httpd it should work. The micro_inetd from http://www.acme.com/ is smaller of course, and only handles one tcp service at a time. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler: > > I will at least apply the one line fix in the next release. For I've done the "one line" fix, which is indeed a two-line fix in lrp.conf and multicron. I prefer this approach for two reasons: lrp.conf is part of lrcfg, whereas multicron is hidden to average user. I may choose /var/logs as clean - up dir instead of /var/log. In my case /var/logs is filled by squid, /var/log shouldn't be a problem, once i use a special syslog server instead syslogging on the router - which is btw a better and useful approach, if you think about hackers running against your firewall/router and after a reboot/crash no logs are available for investigation... or deleted by checkfreespace()... > the future, I'd like to see support for a configuration directory. > There would be some default entries, while add-on packages could > drop entries into the "/etc/purge.d" (or whatever) directory, with > customizations for any large temporary files the particular package > generates. > > Long Term: > I'd also like to see the configuration directory approach taken to > logrotate (similar to my RedHat distributions, which already do > this), and even inetd (switch to xinetd?). Using files in a > configuration directory makes the seperation of configuration > information into packages much easier, ideally avoiding any > pre/post package install/remove configuration required (or at least > limiting it as much as possible). Good ideas; unfortunately xinetd seems to be tree times bigger than inetd and tcpd. kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
> For instance, just because your /var/cache maybe full, do you want to > arbitrarily purge /var/log files? > > Not for an instant do I suggest that such complexity is insurmountable; > rather, it should be clear that this is far more involved and requires a > new paradigm, other than: > > lrp_SC_DEL_L1="/var/log/*[4-9].gz" > lrp_SC_DEL_L2="/var/log/*[1-3].gz" > lrp_SC_DEL_L3="/var/log/*.gz" > lrp_SC_DEL_L4="/var/log/*.0" > lrp_SC_DEL_L5="/var/log/wtmp" > > Also, do not forget, I do not recommend my solution for its > completeness; rather, I recommend it because it more accurately > addresses the *default* DCD distribution, can be done by changing one > (1) line in the current distribution and does *not* require considerable > development and testing time. I will at least apply the one line fix in the next release. For the future, I'd like to see support for a configuration directory. There would be some default entries, while add-on packages could drop entries into the "/etc/purge.d" (or whatever) directory, with customizations for any large temporary files the particular package generates. Long Term: I'd also like to see the configuration directory approach taken to logrotate (similar to my RedHat distributions, which already do this), and even inetd (switch to xinetd?). Using files in a configuration directory makes the seperation of configuration information into packages much easier, ideally avoiding any pre/post package install/remove configuration required (or at least limiting it as much as possible). 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] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: > > Am Sonntag, 20. Januar 2002 03:18 schrieb Michael D. Schleif: > > KP Kirchdörfer wrote: > > > Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif: > > > > > > > > > > I'll probably try to get the script to check *ALL* currently > > > > > mounted, writable file-systems...maybe with an exclude > > > > > variable in lrp.conf. If this doesn't work, I can fallback > > > > > to the Enhanced solution, above. > > > > > > > > /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, > > > > then -- and, only then -- /etc/cron.daily/multicron-d and its > > > > links can run checkfreespace(), which calls updatefree(), &c. > > > > > > There is also mailadmin(), so if /var/something is on the list > > > and checked, it will send a mail to mailadmin. > > > > > > > Suppose, updatefree() returns a value for which ckfree() > > > > returns 0, then -- and, only then -- cleanlevel() runs and > > > > prunes applicable files that match the filter: > > > > $lrp_SC_DEL_L$cklevel > > > > > > > > But, *what* files can these be? In /etc/lrp.conf -- by default > > > > -- we see exclusively this: > > > > > > > > lrp_SC_DEL_L1="/var/log/*[4-9].gz" > > > > lrp_SC_DEL_L2="/var/log/*[1-3].gz" > > > > lrp_SC_DEL_L3="/var/log/*.gz" > > > > lrp_SC_DEL_L4="/var/log/*.0" > > > > lrp_SC_DEL_L5="/var/log/wtmp" > > > > > > > > Notice, *ALL* of these files -- by default -- reside in > > > > /var/log !!! > > > > > > > > Since *only* files under /var/log can be pruned -- by default > > > > -- then, why not modify updatefree() to say this: > > > > > > > > set -- $(df /var/log | sed -n 2p) > > > > > > lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well. > > > > > > updatefree() isn't the place to determine the dir's, that's what > > > I think. > > > > Agreed, this is not the ultimate solution. However, it does > > completely address DCD defaults! > > > > Nevertheless, `df /path/to/dir' *always* returns _only_ that > > information particular to that filesystem on which /path/to/dir > > resides; therefore, it would be a simple matter to test any variety > > of applicable dir/filesystem combinations. > > > > The truly hard part is, what to do with the information returned? > > Email somebody is straightforward; but, the complexities in > > deciding which files to purge becomes exceedingly complex !?!? > > > > Besides logfiles, what else on DCD can grow out-of-hand? > > On a common DCD I don't know. On my own /var/logs and /var/cache for > squid. > It's easy to decide that a cache can be flushed. Yes, of course, in and of itself, it is easy to decide whether or not to purge files in /var/cache. It is also easy enough to put several df's in a loop in order to analyze several filesystems. However, it is not as easy, once a filesystem is found that requires purging, for the dumb shell script to decide *which* files to purge ;< For instance, just because your /var/cache maybe full, do you want to arbitrarily purge /var/log files? Not for an instant do I suggest that such complexity is insurmountable; rather, it should be clear that this is far more involved and requires a new paradigm, other than: lrp_SC_DEL_L1="/var/log/*[4-9].gz" lrp_SC_DEL_L2="/var/log/*[1-3].gz" lrp_SC_DEL_L3="/var/log/*.gz" lrp_SC_DEL_L4="/var/log/*.0" lrp_SC_DEL_L5="/var/log/wtmp" Also, do not forget, I do not recommend my solution for its completeness; rather, I recommend it because it more accurately addresses the *default* DCD distribution, can be done by changing one (1) line in the current distribution and does *not* require considerable development and testing time. Enough said . . . -- 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] [dachstein] lrp.conf/multicron Spacecheck problem
Am Sonntag, 20. Januar 2002 03:18 schrieb Michael D. Schleif: > KP Kirchdörfer wrote: > > Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif: > > > > > > > > I'll probably try to get the script to check *ALL* currently > > > > mounted, writable file-systems...maybe with an exclude > > > > variable in lrp.conf. If this doesn't work, I can fallback > > > > to the Enhanced solution, above. > > > > > > Correct me, if I'm wrong -- it won't be the first time today ;> > > > > > > /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, > > > then -- and, only then -- /etc/cron.daily/multicron-d and its > > > links can run checkfreespace(), which calls updatefree(), &c. > > > > There is also mailadmin(), so if /var/something is on the list > > and checked, it will send a mail to mailadmin. > > > > > Suppose, updatefree() returns a value for which ckfree() > > > returns 0, then -- and, only then -- cleanlevel() runs and > > > prunes applicable files that match the filter: > > > $lrp_SC_DEL_L$cklevel > > > > > > But, *what* files can these be? In /etc/lrp.conf -- by default > > > -- we see exclusively this: > > > > > > lrp_SC_DEL_L1="/var/log/*[4-9].gz" > > > lrp_SC_DEL_L2="/var/log/*[1-3].gz" > > > lrp_SC_DEL_L3="/var/log/*.gz" > > > lrp_SC_DEL_L4="/var/log/*.0" > > > lrp_SC_DEL_L5="/var/log/wtmp" > > > > > > Notice, *ALL* of these files -- by default -- reside in > > > /var/log !!! > > > > > > Since *only* files under /var/log can be pruned -- by default > > > -- then, why not modify updatefree() to say this: > > > > > > set -- $(df /var/log | sed -n 2p) > > > > > > What do you think? > > > > lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well. > > > > updatefree() isn't the place to determine the dir's, that's what > > I think. > > > > sorry kp > > Agreed, this is not the ultimate solution. However, it does > completely address DCD defaults! > > Nevertheless, `df /path/to/dir' *always* returns _only_ that > information particular to that filesystem on which /path/to/dir > resides; therefore, it would be a simple matter to test any variety > of applicable dir/filesystem combinations. > > The truly hard part is, what to do with the information returned? > Email somebody is straightforward; but, the complexities in > deciding which files to purge becomes exceedingly complex !?!? > > Besides logfiles, what else on DCD can grow out-of-hand? On a common DCD I don't know. On my own /var/logs and /var/cache for squid. It's easy to decide that a cache can be flushed. kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: > > Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif: > > Charles Steinkuehler wrote: > > > > Following problem: > > > > Using Dachstein and creating a separate ramdisk /dev/ram1 for > > > > /var/log malfunctions lrp.conf spacecheck. > > > > I think the spacecheck intention is to monitor /var/log, cause > > > > there are the most changes in file size during the routers > > > > lifetime and running out of space in /var/log causes several > > > > errors - sshd won't start, pppoe connections won't be > > > > established after disconnection etc. - all leading to router > > > > which can't be controlled remotely. > > > > > > > > Further investigation showed that multicron-p only looks for / > > > > when checking free space - which is useless, once you have a > > > > separate ramdisk for /var/log. > > > > > > > > Dummy solution, and this is what I did: > > > > add a parameter lrp_CHK_PART to lrp.conf and change multicron-p > > > > to use $lrp_CHK_PART in lrp.conf updatefree() > > > > > > > > Enhanced solution: > > > > lrp_CHK_PART should allow several partitions which will be > > > > checked and free'ed or at least a sending a mail with > > > > mailadmin(). > > > > > > Added to the list of things to fix for Dachstein 1.0.3 > > > > > > I'll probably try to get the script to check *ALL* currently > > > mounted, writable file-systems...maybe with an exclude variable > > > in lrp.conf. If this doesn't work, I can fallback to the > > > Enhanced solution, above. > > > > Correct me, if I'm wrong -- it won't be the first time today ;> > > > > /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, then > > -- and, only then -- /etc/cron.daily/multicron-d and its links can > > run checkfreespace(), which calls updatefree(), &c. > > There is also mailadmin(), so if /var/something is on the list and > checked, it will send a mail to mailadmin. > > > > > Suppose, updatefree() returns a value for which ckfree() returns 0, > > then -- and, only then -- cleanlevel() runs and prunes applicable > > files that match the filter: $lrp_SC_DEL_L$cklevel > > > > But, *what* files can these be? In /etc/lrp.conf -- by default -- > > we see exclusively this: > > > > lrp_SC_DEL_L1="/var/log/*[4-9].gz" > > lrp_SC_DEL_L2="/var/log/*[1-3].gz" > > lrp_SC_DEL_L3="/var/log/*.gz" > > lrp_SC_DEL_L4="/var/log/*.0" > > lrp_SC_DEL_L5="/var/log/wtmp" > > > > Notice, *ALL* of these files -- by default -- reside in /var/log > > !!! > > > > Since *only* files under /var/log can be pruned -- by default -- > > then, why not modify updatefree() to say this: > > > > set -- $(df /var/log | sed -n 2p) > > > > What do you think? > > lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well. > > updatefree() isn't the place to determine the dir's, that's what I > think. > > sorry kp Agreed, this is not the ultimate solution. However, it does completely address DCD defaults! Nevertheless, `df /path/to/dir' *always* returns _only_ that information particular to that filesystem on which /path/to/dir resides; therefore, it would be a simple matter to test any variety of applicable dir/filesystem combinations. The truly hard part is, what to do with the information returned? Email somebody is straightforward; but, the complexities in deciding which files to purge becomes exceedingly complex !?!? Besides logfiles, what else on DCD can grow out-of-hand? -- 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] [dachstein] lrp.conf/multicron Spacecheck problem
Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif: > Charles Steinkuehler wrote: > > > Following problem: > > > Using Dachstein and creating a separate ramdisk /dev/ram1 for > > > /var/log malfunctions lrp.conf spacecheck. > > > I think the spacecheck intention is to monitor /var/log, cause > > > there are the most changes in file size during the routers > > > lifetime and running out of space in /var/log causes several > > > errors - sshd won't start, pppoe connections won't be > > > established after disconnection etc. - all leading to router > > > which can't be controlled remotely. > > > > > > Further investigation showed that multicron-p only looks for / > > > when checking free space - which is useless, once you have a > > > separate ramdisk for /var/log. > > > > > > Dummy solution, and this is what I did: > > > add a parameter lrp_CHK_PART to lrp.conf and change multicron-p > > > to use $lrp_CHK_PART in lrp.conf updatefree() > > > > > > Enhanced solution: > > > lrp_CHK_PART should allow several partitions which will be > > > checked and free'ed or at least a sending a mail with > > > mailadmin(). > > > > Added to the list of things to fix for Dachstein 1.0.3 > > > > I'll probably try to get the script to check *ALL* currently > > mounted, writable file-systems...maybe with an exclude variable > > in lrp.conf. If this doesn't work, I can fallback to the > > Enhanced solution, above. > > Correct me, if I'm wrong -- it won't be the first time today ;> > > /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, then > -- and, only then -- /etc/cron.daily/multicron-d and its links can > run checkfreespace(), which calls updatefree(), &c. There is also mailadmin(), so if /var/something is on the list and checked, it will send a mail to mailadmin. > > Suppose, updatefree() returns a value for which ckfree() returns 0, > then -- and, only then -- cleanlevel() runs and prunes applicable > files that match the filter: $lrp_SC_DEL_L$cklevel > > But, *what* files can these be? In /etc/lrp.conf -- by default -- > we see exclusively this: > > lrp_SC_DEL_L1="/var/log/*[4-9].gz" > lrp_SC_DEL_L2="/var/log/*[1-3].gz" > lrp_SC_DEL_L3="/var/log/*.gz" > lrp_SC_DEL_L4="/var/log/*.0" > lrp_SC_DEL_L5="/var/log/wtmp" > > Notice, *ALL* of these files -- by default -- reside in /var/log > !!! > > Since *only* files under /var/log can be pruned -- by default -- > then, why not modify updatefree() to say this: > > set -- $(df /var/log | sed -n 2p) > > What do you think? lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well. updatefree() isn't the place to determine the dir's, that's what I think. sorry kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
Charles Steinkuehler wrote: > > > Following problem: > > Using Dachstein and creating a separate ramdisk /dev/ram1 for > > /var/log malfunctions lrp.conf spacecheck. > > I think the spacecheck intention is to monitor /var/log, cause there > > are the most changes in file size during the routers lifetime and > > running out of space in /var/log causes several errors - sshd won't > > start, pppoe connections won't be established after disconnection > > etc. - all leading to router which can't be controlled remotely. > > > > Further investigation showed that multicron-p only looks for / when > > checking free space - which is useless, once you have a separate > > ramdisk for /var/log. > > > > Dummy solution, and this is what I did: > > add a parameter lrp_CHK_PART to lrp.conf and change multicron-p to > > use $lrp_CHK_PART in lrp.conf updatefree() > > > > Enhanced solution: > > lrp_CHK_PART should allow several partitions which will be checked > > and free'ed or at least a sending a mail with mailadmin(). > > Added to the list of things to fix for Dachstein 1.0.3 > > I'll probably try to get the script to check *ALL* currently mounted, > writable file-systems...maybe with an exclude variable in lrp.conf. If this > doesn't work, I can fallback to the Enhanced solution, above. Correct me, if I'm wrong -- it won't be the first time today ;> /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, then -- and, only then -- /etc/cron.daily/multicron-d and its links can run checkfreespace(), which calls updatefree(), &c. Suppose, updatefree() returns a value for which ckfree() returns 0, then -- and, only then -- cleanlevel() runs and prunes applicable files that match the filter: $lrp_SC_DEL_L$cklevel But, *what* files can these be? In /etc/lrp.conf -- by default -- we see exclusively this: lrp_SC_DEL_L1="/var/log/*[4-9].gz" lrp_SC_DEL_L2="/var/log/*[1-3].gz" lrp_SC_DEL_L3="/var/log/*.gz" lrp_SC_DEL_L4="/var/log/*.0" lrp_SC_DEL_L5="/var/log/wtmp" Notice, *ALL* of these files -- by default -- reside in /var/log !!! Since *only* files under /var/log can be pruned -- by default -- then, why not modify updatefree() to say this: set -- $(df /var/log | sed -n 2p) 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] [dachstein] lrp.conf/multicron Spacecheck problem
> Following problem: > Using Dachstein and creating a separate ramdisk /dev/ram1 for > /var/log malfunctions lrp.conf spacecheck. > I think the spacecheck intention is to monitor /var/log, cause there > are the most changes in file size during the routers lifetime and > running out of space in /var/log causes several errors - sshd won't > start, pppoe connections won't be established after disconnection > etc. - all leading to router which can't be controlled remotely. > > Further investigation showed that multicron-p only looks for / when > checking free space - which is useless, once you have a separate > ramdisk for /var/log. > > Dummy solution, and this is what I did: > add a parameter lrp_CHK_PART to lrp.conf and change multicron-p to > use $lrp_CHK_PART in lrp.conf updatefree() > > Enhanced solution: > lrp_CHK_PART should allow several partitions which will be checked > and free'ed or at least a sending a mail with mailadmin(). Added to the list of things to fix for Dachstein 1.0.3 I'll probably try to get the script to check *ALL* currently mounted, writable file-systems...maybe with an exclude variable in lrp.conf. If this doesn't work, I can fallback to the Enhanced solution, above. Thanks for spotting the problem! 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
