On Tue, Mar 13, 2018 at 11:29 AM, Miroslav Lichvar <mlich...@redhat.com>

> On Tue, Mar 13, 2018 at 10:45:56AM +0100, Christian Ehrhardt wrote:
> > In unprivileged containers even after e8096330 "sys_linux: don't keep
> > CAP_SYS_TIME with -x option" default installations
> > will still run without an explicit -x being set and therefore fail by
> > missing CAP_SYS_TIME.
> >
> > In some use cases users want the NTP server service to "just work" which
> > in a non-CAP_SYS_TIME environment means that chrony has to fall back.
> As I said in the previous mail, they can use -x to have an NTP server
> that always "works". We seem to agree that neither -x or -X should be
> a default. In what configuration it would be useful to enable -X but
> not -x?

The important part is the lack of knowledge of the target systems
They are:
- not detectable by some install paths, for example
  - install in VM with behavior A onto phys disk but reboot host into said
  - installing on a remote disk mounted chroot, which might be totally
different when this runs.
  - ...
- Several tools/configs might add/remove capabilities from a system later
on in the lifecycle
- Some move machines between places with different capabilities
- ...
The TL;DR of the "motivation" is: the inability to decide if using "-x" is
right or not (at any time).

With just "-x" available this leads to one of the following:
A) So if one sets "-x" it will NEVER sync the clock even if the system
would be capable to do so.
B) if one does not set "-x" it will fail to start (even the server portion
of chronyd) in some environments

The addition of the new "-X" provides a new case
C) set -X which will sync the clock if it runs (currently) in an
environment able to do so

BTW - in case it might be better to discuss interactive - I'm "cpaelzer" on
freednode IRC.
If there is a common place chrony matters are usually discussed (other than
the ML) that would be nice to know - I haven't found a hint about it on the
web page.

I appreciate the effort you put into the patch, but without a use case
> it seems to me like an unnecessary complication of the code and
> another trap for the user to fall in.
> > By that a user will get an NTP server working independent to the
> > environment, that will control the local time if it is able to do so.
> >
> > This is not set as default as the fallback is considered a loss of time
> > control that users should opt-in, but the new config allows an admin and
> > setup tools to opt into -x like behavior without loosing the feature to
> > control time when running in an environment that is able to do so.
> They either need the clock to be controlled by chronyd or they don't.
> If they don't, I think they can always use -x.
> I have some comments about the patch, but I think we should make this
> clear first.
> --
> Miroslav Lichvar
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Reply via email to