[Zope-Coders] new zLOG

[Guido van Rossum]

[Toby]
> > 1. Give the 'stupid log file' its proper name back. This is another
> > > reason why writing to a file is a stupid way to do event logging.

[Guido]
> > Yes please.  There are way too many places that currently have to look
> > for two envvars where one would be enough.

[Chris]
> I'm not sure what Toby means by this.  I don't think it's the envvar
> thing (which is another topic entirely ;-)
> 
> Assuming he means the event logger is still "stupid", that's not true
> anymore.  Due entirely to Vinay Sajip, it can log to a file, syslog,
> http, nt event log, mail, and so on.  It can log to them simultaneously
> to difference places as necessary and has lots of other knobs and
> dials.  The ZLogger package, which previously handled syslog logging,
> has been removed from the Zope trunk as a result, and that duty has been
> moved into the event logger.
> 
> The only "stupid" thing about the event logger now is its need to use
> environment variables for configuration.  In Zope 2.7, we will not be
> using environment variables for its configuration anymore, so as far as
> I can tell it will be entirely unstupified when used by Zope.  To what
> degree we can make this a reality under ZEO and ZRS is still an open
> question.

This sounds like a good reason to not introduce two new envvars
(EVENT_LOG_FILE and EVENT_LOG_SEVERITY) and only support the old ones
for backwards compatibility (STUPID_LOG_FILE and STUPID_LOG_SEVERITY),
if (as you say) using the files in a production setting is stupid.

> Toby wrote:
> 
> > > 2. Accept that Zope currently gives up root privelidges far too
> > > late. This is a bug with the privelidge dropping, not with the
> > > logging. Even worse, Zope currently writes a few ZODB transactions
> > > as root too.
> 
> I'll share some of my pain about this.  Last night I was at work with
> Ken until about 9pm helping a customer discover (via
> remote-control-of-a-human) that they shouldn't be starting their ZEO
> server as root in their configuration.
> 
> It needs to be fixed, and, for Zope, it even *has* been fixed on a
> branch.  I hope to convince folks to see a need for it in ZEO as well.

The new zdaemon.py script calls setuid() before even forking the
server subprocess.  Currently it only does this if you explicitly
specify -u, but it's easy to do change this to call setuid() by
default when invoked by root.

> On Tue, 2002-11-26 at 08:59, Toby Dickenson wrote:
> > On Tuesday 26 November 2002 1:41 pm, Guido van Rossum wrote:
> > 
> > > I propose that there be some interface where Zope (or any setuid
> > > program) can call e.g. zLOG.initialize_later() immediately after
> > > importing zLOG, and if this hasn't been called by the time LOG() is
> > > called for the first time, the first LOG() call calls initialize().
> > 
> > I dispute the need for this interface.
> > 
> > It should be easy to find potential calls to LOG before such a program drops 
> > root. If so, it should also be easy to disable those calls in the 
> > application, rather than at ZLOG level.
> > 
> > If it is not easy to find out exactly what your program does before dropping 
> > root privelidges then you already have bigger problems.
> 
> Guido later said in response:
> 
> > I don't disagree.  I was just throwing Chris a bone, since he cares
> > much about this issue.  I also note that calling initialize() from the
> > first LOG() call requires having a global variable whose value
> > indicates whether this is the first LOG() call; all my proposed
> > interface would add is a defined API to set this variable to pretend
> > the first LOG() call has already happened. :-)
> 
> This is fine with me (API or no API). As long as "import zLOG" does not
> potentially write a file, I can work around the rest of the issues.

OK, I'll check a change to zLOG in soon (without API, let's call it a
YAGNI).

--Guido van Rossum (home page: http://www.python.org/~guido/)