On Wed, Mar 7, 2018 at 3:43 PM, Miroslav Lichvar <[email protected]> wrote:
> On Wed, Mar 07, 2018 at 01:51:31PM +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. > > > > Usually users want services to "just work" which in a non-CAP_SYS_TIME > > environment means that chrony will fulfil just the NTP serving task but > > not the local time control. > > > > Therefore imply -x in those environments. > > I'm not sure about this. > > I can see that it would be convenient in some cases to have a service > that automatically falls back to -x, but in the vast majority of cases > I think chronyd is expected to control the clock and if that is not > possible, it should fail. > > For example, if I had a docker image with chronyd configured as an NTP > client and I forgot to give it the CAP_SYS_TIME capability, it would > be much likely for me to miss the problem if it fell back to -x. > > There are some considerations that should be made before enabling -x. > In order for chronyd to be a good NTP server, the system clock either > needs to be free running (and all applications running on the system > happy with an unsynchronized system clock), or it needs to be > synchronized by another process and chronyd with -x is just serving > the local time (chrony.conf includes the local directive, but no time > sources are specified). > > There are other issues with running an NTP client/server in a > container, e.g. network interfaces don't support SW/HW timestamping, > which has an impact on accuracy. > I thought that having the server portion work by default would be very nice to user. But I agree that if time there is like "really bad" then it has to be an explicit opt in by user/tool that sets it up. So the question is, is this "so bad" that we should not fall back by default. Or is this a minor degradation and the comfort for the NTP server component to just work outweighs the concern. > What do others think? > Absolutely, me as well. P.S. if this will be a tradeoff we can't decide (but really only then) - how about adding a new cmdline option to enable (or disable) this new behavior. That would allow downstreams to decide if they want either or the other behavior. -- > Miroslav Lichvar > > -- > To unsubscribe email [email protected] with > "unsubscribe" in the subject. > For help email [email protected] with "help" in the > subject. > Trouble? Email [email protected]. > > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltdh
