lr-20001216: ported to Solaris 7 (was: Re: lr-20001211 on FreeBSD 4.1-STABLE?)

[Joost van Baal]

Hi,

I just uploaded a new tar ball, which I've got running on my Solaris machine
now. (yes, I got the machine going :) . Porting to that beast is done for now.

On Fri, Dec 15, 2000 at 05:56:39PM +0100, Brad Knowles wrote:
> At 3:02 PM +0100 2000/12/15, Joost van Baal wrote:
> 
> >  I believe I fixed this. The scripts in cvs should work on solaris. (Didn't
> >  yet get the sparc station up, so haven't yet tested it there.) I'll package
> >  latest version this weekend.
> 
> 	Okay, well I'm going to be out of the office for the next couple 
> of weeks, so I'll try to take a look at this when I get back.

A, that's a pity. Well, have a nice time then.
 
> >  I'm thinking about this. What I'd like is having an "identifier" of the
> >  logfile. This makes parsing the huge amount of debug output more convenient,
> >  when running the system as a responder. Don't know what's the nicest solution
> >  yet. (In fact, the last argument can be anything now: it's used only in
> >  the stuff you get on stderr, and in the subject of the email 
> >message you get.)
> 
> 	Well, all the various versions of syslog always put the hostname 
> (long or short form) in the same place, right?  So can't we do this 
> in a positional manner, as opposed to explicitly tagging it?
> 
> 	As for the fourth argument as a "tag", what I like to see in the 
> reports I get today are three things -- the host name (preferably the 
> short version), the time period which the report covers (usually just 
> the date in YYYY/MM/DD format), and some idea as to which program 
> generated the output (i.e., "pflogsumm", "syslog_stats", "logreport", 
> etc...).  It seems to me that all of these are things that we could 
> either extract from the data itself, or from the program itself.

You're right. The identifier, used to parse the debug output, should
be unique though. I'll work on this.

> >  Nice idea! I'll work on that. The point is, lr_log2mail gets called by
> >  lr_spool, when the system runs as an online responder, autoreplying
> >  to logfiles, received by email (see doc/overview.txt). But of course,
> >  a default email address would be nice.
> 
> 	In that case, lr_spool could fill in a different e-mail address 
> (presumably the one supplied by the sender of the log data to be 
> analyzed), and otherwise lr_log2email could supply an appropriate 
> default, right?

That's right.
 
> >  Is this what happens when running lr_log2report as a bash script?
> 
> 	Blargh.  I thought I had already made that fix.  Now that I have, I get:
> 
> export LR_HOME=/usr/local; lr_log2mail email postfix blk at skynet.be 
> fatbert.skynet.be < /var/log/mail.debug
> all all none lr_log2mail info started with email postfix 
> blk at skynet.be fatbert.skynet.be
> unknown all none lr_log2report info started with email postfix
> /usr/local/bin/lr_log2report: 
> /usr/local/lib/logreport/email/postfix/postfix2dlf: No such file or 
> directory
> email postfix none lr_log2report fatal postfix2dlf failed, exiting
> email postfix none lr_log2mail error lr_log2report failed

The 'no such file or directory' could be caused by a nonstandard
installation of the logreport software, so that there is no
file /usr/local/lib/logreport/email/postfix/postfix2dlf (could
wrongly be in /usr/local/lib/email/postfix/postfix2dlf) or because
you haven't got a /usr/bin/perl.
 
> 	Now, we're calling this "log2mail" because it mails out the 
> report, and not because it's processing input data from an MTA, 
> right?  If this program was used exclusively to process input from an 
> MTA, we could leave off the initial "email" argument, because that 
> would be obvious from the program name.

Exactly.
 
> 	In fact, I submit that we can probably leave off the second 
> argument, too -- we should be able to determine adaptively which 
> program needs to be run on the input file, based on the program name 
> provided in the input, right?

Hmm hmmm. I doubt that. I'd like to be able to react sanely when
a bogus logfile is supplied. It might very well happen logs for
different services end up in one file, in case of an interesting
syslog.conf, for example. In such a case, I'd like to be able
to decide which lines I'm supposed to parse, and which to skip.
I think splitting the file, and feeding stuff for different services
to different converters will be something for (much) later. 
 
> >  Well, that worked for me.
> 
> 	Yes, FreeBSD works.  Based on that output, I've got a lot more 
> feedback for you.  ;-)

OK, go ahead :)
 
> >  Thanks for your feedback! You're making me work hard ;-)
> 
> 	Well, I'm perfectly happy to make you work hard, because I want a 
> single tool that I can use to replace pflogsumm for postfix, and the 
> sendmail syslog parsing programs syslog_stats, ssl, smtpstats, etc....

That's where we eventually should be, indeed.
 
> 	However, I'm not sure how much you'll continue to thank me for 
> making you work so hard.  ;-)

hehehe...

-- 
Joost



-- 
To UNSUBSCRIBE, email to questions-request at logreport.org with a subject of 
"unsubscribe". Trouble? Send an email with subject "help" to 
questions-request at logreport.org