Le 10/02/20 à 23:00, Eduard Bloch a écrit :
Hallo,
* Laurent Bigonville [Mon, Feb 10 2020, 01:25:28PM]:
Package: apt-cacher-ng
Version: 3.3.1-2
Severity: wishlist
Hi,
It would be nice if a systemd time could be added to replace the daily
cronjob for the maintenance task.
And why so?
In general, .timer/.service are natively run by systemd (no need of
extra cron deamon), are also scheduled on people machines that are not
running all the time (without requiring extra packages like anacron),
one place to look at if you are using systemd instead of multiple places...
Getting rid of crond/anacron/at might also become a goal for some people
in the future as they are dead/unmaintained upstream and/or in debian.
Would be nice as well if the task was not running as apt-cacher-ng user
(with a User= in the .service file).
And why exactly?
Long story, I'm writing a SELinux policy[0] for apt-cacher-ng, the fact
that acngtool is running as root and the fact that the socket
(/run/apt-cacher-ng/socket) is owned by apt-cacher-ng user/group and
that root has no direct r/w permission on it, requires me to give a too
broad permission (dac_override) to the domain. Not running it as root
might solve this for me.
So if you can ensure that the cronjob (or at least the call to acngtool
maint) is run as apt-cacher-ng user, I might also be happy. I tried with
setpriv(1) to drop the call to the acng user, that works to remove the
dac_override privilege but requires two other (less problematic)
permissions.
You seem to have a mission. Please show a Debian wiki page or something
similar to motivate me. At the moment I see no benefits, all that sounds
like just enforcing a systemd specific solution without need.
To be clear, I was more talking about adding a .timer and make the
existing cronjob exit if systemd is used.
The actual plan of mine was to get rid of the cron jobs whatsoever. Run
the required tasks not based on a dumb time plan but purely based on the
collected information.
That might be indeed be better, see above.
That also applies to the access logs, they would
be migrated to a database (systemd fans might also try to advocate here
but I still have not seen the benefits of its log storage).
Not too sure why using a database here would be better, access logs are
already rotated by logrotate apparently which is still quite commonly
used and they look already machine readable.
Not sure anybody is advocating to move apache accesslogs to journald
[0] https://github.com/SELinuxProject/refpolicy/pull/137/files
