Re: init system policy
On Tue, 18 Nov 2014, Matthias Urlichs wrote:
> > trying to convert minidlna sysv init file to systemd, managed to have
> > a working unit file but failed to split the configuration mimicing
> > the ../default/minidlna content with the hability to make USER and
> > GROUP configurable.
>
> You _can_ do
>
> > ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
>
> but that's not the optimal solution here.
>
> It's better IMHO to use a fixed user in your packaging -- why should that
> user be configurable in the first place? If the sysadmin _really_ needs to
> use a different user+group, they can add an overriding unit file to
> /etc/systemd/system/ (files get merged, so no need to copy the whole thing).
Failing to address this would be a severe regression, of the kind that
introduces a security hole. You'd need to abort package configuration on
upgrades if you cannot handle it automatically.
Several packages will need to address this same issue. We should try to
find a really good answer for this scenario.
A first option would be a way to load config data from a VAR=VALUE text file
in systemd units, and pass some of those vars as the value for User= /
Group= (from systemd.exec(5)). Is that possible in jessie's systemd ?
A second option is to migrate on upgrade the uid/gid information into an
override in /etc/systemd/system. Requires dealing with a dynamically
generated config file in preinst/postinst, though, which means the tools
that help proper config file handling in maintainer scripts (ucf, and
sometimes dpkg-maintscript-helper) will be of limited help.
There's also the "sudo" solution described above, which has its own
problems, but which is likely to be workable in most of the cases.
Any other ideas?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: