Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2

2002-01-20 Thread Jacques Nilo

Jack Coates wrote:

 gods are always good firewall names, what with the whole gateway between
 dead and living, heaven/hell thing. Thoth, Janus, Pluto, etc. Of course
 if one's tastes are more mundane there's always St. Louis (Gateway to
 the West), Panama (Gateway to the Pacific), or Vickie (Guardian of the
 Lobby).

Was not it CERBERE (I am not sure of the English spelling) the dog who was
keeping the entry of Hell ?
Jacques



___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



Re: [Leaf-devel] Site Update 2002-01-16

2002-01-20 Thread Mike Noyes

At 2002-01-19 15:11 -0600, guitarlynn wrote:
On Saturday 19 January 2002 13:45, Matt Schalit wrote:
   Option 3:
   Create a page in our phpWebSite for this purpose. Example:
   http://leaf.sourceforge.net/content.php?menu=1000page_id=4
 
  Now that I like.  I was hoping for something really simple.
 
   Will everyone still want me to post updates to this list too?
 
  I think that's the idea.  Then it's well searchable.
 
  Does that make any sense?

It sounds clean, simple, and informative to me w/o any click throughs.

Matt  Lynn,
Take a look at the link above now, and let me know if this is what you had 
in mind.

Matt,
Thanks for the idea. :-)

--
Mike Noyes [EMAIL PROTECTED]
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2

2002-01-20 Thread guitarlynn


On Sunday 20 January 2002 11:13, Jacques Nilo wrote:
 Was not it CERBERE (I am not sure of the English spelling) the dog
 who was keeping the entry of Hell ?
 Jacques

hehe, maybe the Dante series..
--

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!

---

-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



Re: [Leaf-devel] Site Update 2002-01-16

2002-01-20 Thread guitarlynn

On Sunday 20 January 2002 10:41, Mike Noyes wrote:
 Matt  Lynn,
 Take a look at the link above now, and let me know if this is what
 you had in mind.

   http://leaf.sourceforge.net/content.php?menu=1000page_id=4

Looks great to me, ty!

--

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!

---

-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2

2002-01-20 Thread arne @ loopback . org

On Sun, Jan 20, 2002 at 06:13:01PM +0100, Jacques Nilo wrote:
 Jack Coates wrote:
 
 
 Was not it CERBERE (I am not sure of the English spelling) the dog who was
 keeping the entry of Hell ?

Well i know it as cerberus (the latin name ??), but please have a look at:
http://www.mythweb.com/hercules/herc17.html 

 Jacques
 
 
 
 ___
 Leaf-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/leaf-devel

--arne 

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



Re: [Leaf-devel] Site Update 2002-01-16

2002-01-20 Thread Matt Schalit

Mike Noyes wrote:
 
 At 2002-01-19 15:11 -0600, guitarlynn wrote:
 On Saturday 19 January 2002 13:45, Matt Schalit wrote:
Option 3:
Create a page in our phpWebSite for this purpose. Example:
http://leaf.sourceforge.net/content.php?menu=1000page_id=4
  
   Now that I like.  I was hoping for something really simple.
  
Will everyone still want me to post updates to this list too?
  
   I think that's the idea.  Then it's well searchable.
  
   Does that make any sense?
 
 It sounds clean, simple, and informative to me w/o any click throughs.
 
 Matt  Lynn,
 Take a look at the link above now, and let me know if this is what you had
 in mind.


Looks great to me too.

When you say you disabled user logins, do you mean that you 
took the Login via SSL link off the home page?   Just wondering
becuase I was hunting around for that a bit myself.

Thanks,
Matthew

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem

2002-01-20 Thread Michael D. Schleif



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] Site Update 2002-01-16

2002-01-20 Thread Mike Noyes

At 2002-01-20 12:10 -0800, Matt Schalit wrote:
When you say you disabled user logins, do you mean that you
took the Login via SSL link off the home page?   Just wondering
becuase I was hunting around for that a bit myself.

Matt,
This seems to be a common misunderstanding. Our phpWebSite and SourceForge 
do not share authentication.

The user/admin logins for our phpWebSite are done with php session ids and 
cookies. They are md5 hashed and stored in our MySQL database. They only 
authenticate logins for our phpWebSite. I disabled the user login from our 
home page.
http://leaf.sourceforge.net/

User authentication for SourceForge is handled site wide by an LDAP server. 
It authenticates logins for cvs, ssh shell, compile farm, and web site 
access. The web login for SourceForge is here:
https://sourceforge.net/account/login.php

--
Mike Noyes [EMAIL PROTECTED]
http://leaf.sourceforge.net/


___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel



[Leaf-devel] [RFC] DCD checkfreespace() vs. multiple filesystems

2002-01-20 Thread Michael D. Schleif


[RFC] DCD checkfreespace() vs. multiple filesystems

There has been some debate regarding /etc/cron.daily/multicron-d and one
of its functions, checkfreespace(), the default configuration for which
does *not* recognize nor act on multiple filesystems.

What follows is my proposed modification to that one function and a
change in the purge list paradigm for /etc/lrp.conf, which completely
resolves this challenge.

First, currently, /etc/lrp.conf contains this, by default:

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

I propose *replacing* those with the likes of these:

purge_ram0_L1=/tmp/*
purge_ram0_L2=/var/cache/*[1-9].gz
purge_ram0_L3=/var/cache/*.gz
purge_ram0_L4=/var/cache/*.0
purge_ram0_L5=/var/cache/*

purge_ram1_L1=/var/log/*[4-9].gz
purge_ram1_L2=/var/log/*[1-3].gz
purge_ram1_L3=/var/log/*.gz
purge_ram1_L4=/var/log/*.0
purge_ram1_L5=/var/log/wtmp

Notice, each ramdisk now *must* be configured separately for the five
(5) purge levels.

The new checkfreespace() automatically checks *ALL* filesystems known to
`df'.  Currently, in DCD, all of these must take the following form:

/dev/ramX

where X is some number from 0 to an unidentified upper limit.  Need we
account for mounted cdrom and floppy?

/etc/cron.daily/multicron-d -- proposed modification to function [Beware
of inadvertent line wrap!]:

checkfreespace () {

ckfree () {
[ $bfree -le ${lrp_SC_MINKB:--1} ]  return 1
[ $pfree -le ${lrp_SC_MINPER:-101} ]  return 1
return 0
}

cleanlevel () {
eval F=\$purge_$@_L$cklevel
for f in $F
do
[ ! -f $f ]  continue   # Bug in expansion?
:  $f
done
}

mailspacelow () {
{
echo
echo date: $(date)
echo src : $HOSTNAME
echo filesystem: /dev/$@
echo level: $cklevel   freeKB: $bfree   free%: $pfree
echo
} | mailadmin Freespace Low!
}

updatefree () {
IFS=$SP$TAB%
set -- $(df /dev/$@ | sed -n 2p)
IFS=$OIFS

bfree=$4
pfree=$((100 - $5))
}

[ $lrp_SPACECHECK != YES ]  return 0

# NOTE: *BOTH* character classes contain *both* space and tab !?!?
fslist=`df | sed '1d;s!^/dev/\([^   ]*\)[   ]*.*$!\1!'`
for fs in $fslist
do
cklevel=0
while [ $cklevel -lt 5 ]
do
updatefree $fs
ckfree  break
cklevel=$(($cklevel + 1))
cleanlevel $fs
done
[ $cklevel -ge ${lrp_SC_MAIL_LEVEL:-1} ]  mailspacelow $fs
done

log 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