Closed nuxwin closed 7 years ago
Using apt-get w/o being root is absolutely valid (as it is installed in /usr/bin
rather than /usr/sbin
). You might consider to use an alias, some script in /usr/local/bin or bind your SSH key to a wrapper scriped on the target host to wrap the apt-dater-host command by sudo.
Good morning,
It seems that
sudo
is not called in some contexts when it is expected to be. If one file from the/etc/apt/apt.conf.d
directory on a target host has permissions such as0640
(umask 027 due to permissions policy hardening),apt-dater
fails due to an access permissions error. The workaround to solve that issue is to call theapt-dater-host
commands throughsudo
on the updater host and to add theapt-dater-host
command in list of allowed commands in the/etc/sudoers.d/apt-dater-host
file of target hosts.To summarize, the workaround is as follows:
On updater host ($HOME/.config/apt-dater/apt-dater.conf
this, even if we have already
$GETROOT="sudo";
in the/etc/apt-dater-host.conf
conffile of target hosts.On target hosts (/etc/sudoers.d/apt-dater-host)
It is easy to reproduce the problem on target hosts directly:
but
The problem is in the
do_status()
routine. In the piped command, you should call$DPKGTOOL
throughsudo
too when that is expected. For instance:instead of
From my point of view, external commands that are generally sysadmin commands and which are called through the
apt-dater-host
Perl script should be executed throughsudo
(when$GETROOT
equal tosudo
), and of course, each of them should be added in the/etc/sudoers.d/apt-dater-host
file. There areAPT-GET(8)
,APTITUDE(8)
but alsodpkg-query(1)
and maybe some others... Don't forget thatUMASK(2) 022
is not the default policy on all systems.Info about my environment:
See also APT-DATER -- File permission problems