[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Best practice to allow a program to write its logs



	Hi.

On Sun, Apr 12, 2020 at 05:00:09PM +0200, l0f4r0@tuta.io wrote:
> Hi,
> 
> Oops, I didn't answer to that, sorry...

No big deal. This is a maillist, we have nothing to hurry here :)


> > It all works - conventional POSIX permissions, ACLs, xattrs, SELinux
> > Labels, etc. Until you try to restore from a backup :)
> >
> What do you mean please? Why does the backup would pose a problem when restored?

Both cpio and tar do not save xattrs and SELinux labels. The very
archive format does not allow it.
There were some experimental RedHat patches for that, but they never
made it to the upstream.
There are also similar deficiencies in rsync (although it is better in
this regard).

And these three (cpio, tar, rsync) are the cornerstones of just
about any backup tools that Debian main provides.

Of course, there's dump(8) which *does* account for all these filesystem
oddities, but it's ext4-specific by definition and is not that popular.

All this applies to the backups of / and /var, mainly. Your typical
$HOME is usually free from all these advanced attributes.


> >> You mean for this use case writing into /var/log/msmtp?
> >> Actually, I don't really know why but I've decided to write user
> >> specific configuration with appropriate logs.  So my conf is not in
> >> /etc/msmtprc but in ~/.msmtprc and logging is in the same vein inside
> >> ~/.msmtp.log.
> >
> > My advice to you then - don't do this.
> > Best are not the logs that are written often or are verbose, and even
> > not those are written in a convenient filesystem locations.
> > Best are the logs which contain the problem, but do not contain assorted
> > junk (implies logs filtering), 
> >
> How to you filter your logs? Directly by tweaking severities in (r)syslog(-ng).conf?

Personally I prefer rsyslog configuration files for this.
If you prefer syslog-ng - it should have similar filtering capabilities.


> > are small (implies periodic rotation)
> >
> logrotate I presume?

Yep. There's no need to reinvent the wheel here.


> > and, the most importantly, are stored not only on your host, but
> > elsewhere, preferrably in a centralized and indexed way.
> >
> Via (r)syslog(-ng)?

Yup. A single setting like this (rsyslog style):

*.info  @rsyslog.home

Implies running syslog daemon that's listening udp:514 at rsyslog.home.


> > A false dichotomy. Why reinventing a wheel with custom logging if they
> > given you that "--syslog=on" option?
> >
> I didn't notice that, thanks! :)
> So you recommend not specifying any logfile in /etc/msmtprc but just use switch "--syslog=on" everytime msmtp is used? Maybe this can be viewed as a constraint as one should remember to use that option... (except by using some trick as an alias)

Yes, I do.


> > Ah, that's not a real MTA. My mistake.
> > A quick look at postinst script gives me:
> >
> > chgrp msmtp /usr/bin/msmtp
> > chmod 2755 /usr/bin/msmtp
> >
> In a nutshell, an application triggers actions under the identity of who launched it initially, except if the application makes use of a specific technical account, right?
> If so what is the best way to know if an application operates under a specific account?

Reading postinst (possibly preinst) from the package never failed me so
far.

Reco


Reply to: