[Bayonne-devel] Re: Bayonne logging not happening in /var/log/bayonne

[Erik Enge]

Tusarkanti Nayak <address@hidden> writes:

> I am trying to log the events from a bayonne script (ccscript).

I am assuming you are using slog.

> It seems the files I have defined in bayonne.conf is not getting
> updated. (I have checked with the permissions).

I am assuming you are talking about `logpath'.

> Also I would like to know if i can log separately in to a file (that
> means the slog file output to a separate file) ?

This is not likely as slog just sends a message to syslog and you can't
easily filter it out from all the other syslog messages.  You can,
however, parse them out later by grepping for "bayonne" or something
equally unique and redirecting that output to a bayonne-specific log
file.

This is what David replied when I asked him (you should search the
archives) whether he thought having access.log and error.log (Apache
style) would be a nice feature:

  From: David Sugar <address@hidden>
  Subject: Re: Re: What does `logpath' do?
  Newsgroups: gmane.comp.gnu.bayonne.devel
  Date: Wed, 23 Jul 2003 05:52:56 -0400

  The "cdr" log would in effect be the "access" log, so the real
  question is one of "error" log.  But I think it's a good idea, as it
  would make Bayonne again more obvious to administer.  If you have a
  patch to do something like this, I would like to see it.  In 1.3 the
  cdr access log is by nodename in case multiple nodes are logging to a
  network mounted filesystem.

This is my current setup: I have /var/log/messages logging everything
(Bayonne is lodged firmly and permanently in --debug mode since I need
to have all my slog.debug messages) via slog.debug, slog.info, etc.  In
addition to this, I post to the audit log (specified by `logpath') which
I have in /share/sys/bayonne/bayonne/var/log/bayonne.audit.  I post to
it using the `audit' function (check the Scripting Manual).  This
provides me with all the information I need: if I need to know what a
user is up to, I parse his data out of the audit log (I have several
shell scripts to do this and I also make sure to post the userid and
sessionid to the audit log) and can see what trail he took through my
application.  If something goes wrong, I figure out what trail he took
and then I consult in /var/log/messages to figure out the details of
what went wrong (what variables contained, what my TGI returned, etc).

Erik.