On 6/26/22 02:18, Klaus Ethgen wrote:
When package ntp is installed (from long history), the ntp daemon is
started by this /etc/init.d/ntp which uses user ntp:ntp. So all
auxiliary directories and files are owned by ntp:ntp.

I agree this is the expected "before" state.

When ntpsec starts to start the same daemon with ntpsec:ntpsec (which is
counter expected) the ntp daemon is not running properly and more over,
it is creating/changing some file rights so neither daemon is running
properly afterwards.

The expected transition behavior is:
- /etc/default/ntp is copied to /etc/default/ntpsec if and only if it was modified. - /etc/ntp.conf is copied to /etc/ntpsec/ntp.conf, with ntp.drift and ntpstats paths updated. - /etc/init.d/ntp should be renamed too, though that uses dpkg-maintscript-helper mv_conffile, which means I might be missing something (vs custom code that I can easily see what it is doing). Also, I can't recall if I've even tested this. Debian's default is systemd.

You'll have to be more specific about what's broken. A reproducible test case would be ideal.

If the problem is specific to sysvinit, your best bet is to submit a patch (to the ntpsec package).

Even better would be to drop that ntpsec:ntpsec user fully and use
ntp:ntp as this would be the expected user a ntp is running under.

And please, don't conflict for ntp package as usually ntp is managed by
configuration management which is depending on ntp init script named
ntp. Nobody would expect init script ntpsec!

The ntpsec package uses "ntpsec" all over the place because that was the decision made at the time that it was introduced to Debian, when both packages existed. I actually tried to use /etc/init.d/ntp for ntpsec. That turns out to not work, even in some cases contrary to documented behavior. Ultimately, other developers said that was a bad idea, and said I should namespace things separately. So that's what I did, for better and worse (and yes, it's some of each).

Even if the long term plan were to eliminate the "ntpsec" namespacing (e.g. match upstream ntpsec more closely)*, I don't think it's a good idea to attempt that now. That increases the number of transitions.

* I'm not even sure that we have a consensus that it is a good idea to do this rename at all, at least while the upstream "ntp" project still exists.

--
--
Richard

Reply via email to