using lire-20010629 on RedHat Linux 7.0

[Wytze van der Raay]

"Francis J. Lacoste" wrote:

> Oops. I override find.requires and find.provides with one that gives
> more granular dependencies. I'm the only doing that, even perl(MODULE)
> is supposed to be a RPM conventions. I rebuild the rpm without that
> custom automatic dependencies computation.
>
> (Joost, I don't have write access to /pub/rpm, the new rpms are
> in /pub. Can you move them under /pub/rpm)
>
> The RPM was also updated to 20010629.1. You might want to check
> it another time.

OK, I downloaded lire-20010629.1-1.noarch.rpm, and this one installed
without problems on my RedHat 7.0 system.

> I suggest that we change add the following to the error message :
>
> If you need root access to read the logs, you may use su to
> pipe the log to Lire like that :
>
> su -e 'cat /var/log/messages' | lr_run lr_log2report ...

This won't work very well from cron jobs (the typical lire environment)
since there is nobody around to enter the root password.

> Alternatively, if you don't care about somebody compromising
> your system, you may set I_DONT_CARE_ABOUT_SECURITY='yes' in
> $HOME/.lirerc to turn off this security check.

In general I do care about somebody compromising my systems,
but on the other hand I am not convinced that running lire as
root will necessarily compromise my system (I do have some trust
in you logreport developers :-)). So the variable name you're
suggesting is a bit strong for my taste ... how about
ALLOW_LIRE_RUNNING_AS_ROOT='yes' ?


Joost van Baal wrote:

> > su -e 'cat /var/log/messages' | lr_run lr_log2report ...
>
> Which assumes the user running this can su without giving a password,
> if this is being run from cron.  (This can be done using pam.)
> Another alternative is using sudo.

If you set up su or sudo to allow a process to gain root privileges
without explicitly having to enter a password, I do not believe that
you have gained much security. Perhaps I'm a little old-fashioned
in that.

> My favourite solution, however, is changing the syslog and logrotate
> configuration, so that the logs are groupreadable, and adding
> lire to the owning group.  I don't know the details of the way Redhat
> handles this, unfortunately.  I believe Erik Troan's logrotate(8) is
> used?

Yes, RedHat uses logrotate(8) for logfile rotation. However, logrotate
does not influence the owner/group/permission by which the logfiles
are created, it simply renames them. The original owner/group/permission
is set by the process creating the file, which varies:
    sendmail    uses syslog, so it's syslogd
    httpd       writes its logs directly
    named       depends on /etc/named.conf, typically writes its logs
                directly, but may also be configured to use syslog

The one that is usually causing trouble on my sites is sendmail.
RedHat starts up syslogd from /etc/rc.d/init.d/syslog after setting
the umask to 077. Thus maillog files will be created as root/root,
permission rw-------. So, just adding lire to the owning group (root)
isn't enough, one must also change the startup script to loosen up
the umask to 037. While this is all trivial to the seasoned sysadmin,
it is not for the average RH administrator I think, who is used to
dropping in new rpm's as they are released by RedHat and not so much
to maintaining deviations from RH's defaults.
Basically what I am trying to say: if we want to gain some popularity
under the most wide-spread Linux distribution, we should make it easy
to integrate lire with it ... (i.e. provide hooks at the lire side,
and don't require changes to the base system).

> The su pipe is nice indeed, however.
>
> We could work out some scenarios, and document them in the Lire User
> Manual.  I don't think automating these kinda things is sane.

I tend to agree with that, but the install/configure scripts could
at least suggest that something like setting ALLOW_LIRE_RUNNING_AS_ROOT
to yes needs to be done when a RH system is suspected.


"Francis J. Lacoste" wrote:

> > Ideally, one should not see any difference between the xalan and
> > noxalan versions I think (this may require adjustments on both
> > sides though).
> >
>
> This output looks exactly like the one of xsltproc (versions that
> don't crash) and Sablotron.
>
> This probably means that the error is the XSL that only works with
> Xalan-C (which is nicely broken if that is the case). I'll look into
> that (and add support for xsltproc and sablotron by the way).

OK. Yes, I am using xalan-j_2_0_0, org.apache.xalan.xslt.Process,
as you are saying (I think).

-- wytze


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