lr-20001211 on FreeBSD 4.1-STABLE?

[Joost van Baal]

On Wed, Dec 13, 2000 at 10:01:02AM +0100, Brad Knowles wrote:
> At 11:53 PM +0100 2000/12/12, Joost van Baal wrote:
> 
> >  A! Sounds excellent. I am planning to upload a new package this week.
> >  Install procedure won't change this week, however. I am working on
> >  bugfixes in the sendmail part now.
> 
> 	Okay, I think I've got something that is at least making an 
> attempt to execute on FreeBSD.
> 
> 	First off, I have to say that I really object to having to modify 
> my path 

If you configure the package as

./configure --prefix=/usr/local \ 
   --sysconfdir=/usr/local/etc/logreport \
   --libexecdir=/usr/local/lib/logreport

, and /usr/local/bin is in your PATH, than you don't have to modify
your PATH.

> and my manpath to suit logreport.  

When installing as in the above example, manpages will be installed
under /usr/local/man. If this is in you manpath, you don't have to
modify that.

> All this stuff should be 
> able to be dumped into /usr/local/bin, or the top-level programs 
> should be able to be dumped there with knowledge of where to find all 
> the other parts.

Stuff gets installed in 

PREFIX/etc/logreport          - configuration files
PREFIX/man/man1               - manpages
PREFIX/man/man3               - manpages
PREFIX/lib/perl5/LogReport    - perl modules
PREFIX/lib/logreport          - scripts, not to be run manually 
PREFIX/bin                    - scripts
PREFIX/tmp                    - tmp files
 
> 	Likewise, all the man pages should be able to be dumped into 
> /usr/local/man.

See above.

> 
> 	I think things still aren't quite right on my system, because in 
> order to get postfix2dlf to work at all, I have to symlink it into 
> /usr/local/logreport/bin, instead of letting lr_log2mail find the 
> program where it would expect it to be.

I think you should have run configure in a different way. If I understand
you correctly 


./configure --prefix=/usr/local \     
   --sysconfdir=/usr/local/etc/logreport \
   --libexecdir=/usr/local/lib/logreport

achieves what you want. Symlinks are not needed. Please don't make these.

Please note that, when using --prefix=foo, --sysconfdir should be 
foo/etc/logreport, and libexecdir should be foo/lib/logreport. I am
working on a more flexible scheme.

> 
> 	Secondly, when it comes to postfix, some of us don't use the 
> standard "qmgr" process, but are instead trying out the experimental 
> "nqmgr" process.  Therefore, around line 132 of postfix2dlf, we need 
> something more like this:
> 
>      } elsif ($type eq "qmgr" || $type eq "nqmgr") {
>          for my $k ('size', 'from') {
>              defined $log->{$k} or warn "$tag error expected to find " .
>                  "'$k'= field, substituting default for queueid '$qid', " .
>                  "type '$type'\n" and $log->{$k} = '-';
>          }

That's great! Thanks a lot for your patch. It's in the code now.
It'll be in this weeks release.

> 	In addition, lines like the following are not "errors" per se, 
> and should not be treated as such:
> 
> 		Dec 13 07:49:35 huntley postfix/smtpd[79046]:
> 		connect from scorpius.skynet.be[195.238.3.14]
> 
> 		Dec 13 07:49:36 huntley postfix/smtpd[79046]:
> 		disconnect from scorpius.skynet.be[195.238.3.14]
> 
> 		Dec 13 01:00:59 huntley postfix/smtpd[51938]:
> 		timeout after DATA from ck.egroups.com[208.50.144.69]
> 
> 		Dec 13 05:35:17 huntley postfix/trivial-rewrite[71146]:
> 		table has changed -- exiting
> 
> 		Dec 13 09:38:34 huntley postfix/smtpd[89568]: lost
> 		connection after RCPT from m097.centtel.com[209.5.245.127]
> 
> 		Dec 13 09:05:10 huntley postfix/smtpd[84541]: lookup
> 		table has changed -- exiting
> 
> 	If you wanted to consider these (and many other things) to be 
> warnings and to summarize them separately, that would be one thing. 
> But these should not be considered errors.

You're absolutely right. The massive load of debug output needs
more tweaking than what you point out. I'll fix this today.

> 	Finally, not everyone has "mutt" installed.  Your program should 
> not be dependant on it.  Either use the standard "sendmail -t" 
> interface, or try transmitting your message directly via SMTP to the 
> appropriate MTA.

lr_log2mail uses mutt. We use this because of the easy setting of
>From and Reply-To address. Indeed, not using mutt gains a lot in 
portability. I'll think about it. (As a quick and dirty workaround,
one can run lr_log2report and pipe it's output to mail or sendmail.)

Thanks a lot for your very valuable feedback,

Bye,

-- 
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