On 8/13/19, Gene Heskett <ghesk...@shentel.net> wrote: > On Tuesday 13 August 2019 02:24:34 deloptes wrote: > >> Gene Heskett wrote: >> > Its good that we can fix it, BUT IF you are going to restrict where >> > we keep logfiles like this then FIX the /var/log perms so that >> > fetchmail, procmail, spamassassin, clamav and its ilk, running as >> > the user can access /var/log to keep its logs. Debian's legendary >> > paranoia about who can write a log in /var/log has long since forced >> > most of us that want that log, into moving it to /home/username/log >> > and reprogramming logrotate to maintain it there years ago. >> >> So why should user be able to write in /var/log? It is the systems log >> directory not the users. > > I don't have a beef with that. My beef is that there has been no effort > to make it easy for the user to take care of his own logs, and now > systemd wants to disable housekeeping the only sensible place for a user > to keep his logs in. And I totally fail to see how that level of > paranoia can be justified. > >> I am not aware of any program I've been using >> for the past 15y that would have a problem writing in /var/log > > Then tell me how fetchmail, procmail, clamav or spamd running as me, can > keep their logs in /var/log, the permissions just aren't there after a > reboot.
I had the same problem with /var/log file permissions being reset so, for bind, I made a /var/log/bind, set the permissions on the directory & changed bind to log to /var/log/bind/named.log ^shrug^ probably not The Right Way To Do It, but it works & I'm happy. If you make a /var/log/mail & configure fetchmail, procmail, etc. to log there it'll probably work Regards, Lee
