On Thu, Mar 8, 2018 at 6:09 PM, Miroslav Lichvar
wrote:
> On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote:
> > 1. the option would not be default on, so "normal" users/installations
> > would not be affected
> > 2. cases that want the fallback behavior, but are unable to probe/
On Fri, Mar 09, 2018 at 08:36:36AM +0100, Christian Ehrhardt wrote:
> On Fri, Mar 9, 2018 at 8:18 AM, Miroslav Lichvar
> wrote:
> > I still don't see the use case for the fallback. If applications
> > running in the container are ok with chronyd not controlling the
> > clock, why not always use -x
On Fri, Mar 9, 2018 at 8:18 AM, Miroslav Lichvar
wrote:
> On Thu, Mar 08, 2018 at 06:09:00PM +0100, Miroslav Lichvar wrote:
> > On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote:
> > > 1. the option would not be default on, so "normal" users/installations
> > > would not be affec
On Thu, Mar 08, 2018 at 06:09:00PM +0100, Miroslav Lichvar wrote:
> On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote:
> > 1. the option would not be default on, so "normal" users/installations
> > would not be affected
> > 2. cases that want the fallback behavior, but are unable t
On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote:
> 1. the option would not be default on, so "normal" users/installations
> would not be affected
> 2. cases that want the fallback behavior, but are unable to probe/detect at
> the time:
>- so they can not decide to use normal
...
concept of a time namespace in the future. For most non-namespaced
resources applications that are expected to run in user namespaces
(systemd, lxc, etc.) follow the concept of "seek forgiveness, not
permission" meaning one should usually check whether an operation is
That, for a program,
On Thu, Mar 08, 2018 at 05:15:44PM +0100, Christian Brauner wrote:
> Now, I think it would make sense for chrony to be a "seek
> forgiveness, not permission" application since a) it is expected to be
> run in user namespaces and
I think chronyd is already doing that, except there is no other way t
On Thu, Mar 08, 2018 at 03:59:30PM +0100, Christian Ehrhardt wrote:
> On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar
> wrote:
>
> > On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote:
> > > On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar
> > > > But this is what users expect i
On Thu, Mar 8, 2018 at 4:34 PM, Miroslav Lichvar
wrote:
> On Thu, Mar 08, 2018 at 04:20:48PM +0100, Christian Ehrhardt wrote:
> > On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar
> > wrote:
> > > I'd rather keep it simple and avoid implementing an automatic fallback
> > > in chrony.
> > >
> >
>
On Thu, Mar 08, 2018 at 04:20:48PM +0100, Christian Ehrhardt wrote:
> On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar
> wrote:
> > I'd rather keep it simple and avoid implementing an automatic fallback
> > in chrony.
> >
>
> I understand the POV, but without even a default-off function for it I'
On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar
wrote:
> On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote:
> > On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar
> > > But this is what users expect in most cases, right? If an NTP
> > > client/server is installed and enabled in a
On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar
wrote:
> On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote:
> > On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar
> > > But this is what users expect in most cases, right? If an NTP
> > > client/server is installed and enabled in a
On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote:
> On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar
> > But this is what users expect in most cases, right? If an NTP
> > client/server is installed and enabled in a container, it's usually
> > not intended, e.g. it was installed a
On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar
wrote:
> On Thu, Mar 08, 2018 at 12:21:16PM +0100, Christian Ehrhardt wrote:
> > 1. if you are in a container you very likely can't set the time.
> > Installing chrony there would silently not start the chrony service
> for
> > lacking CAP_SYS_
On Thu, Mar 08, 2018 at 12:21:16PM +0100, Christian Ehrhardt wrote:
> 1. if you are in a container you very likely can't set the time.
> Installing chrony there would silently not start the chrony service for
> lacking CAP_SYS_TIME.
> - You now installed chrony got no error/warning, but it
On Thu, Mar 8, 2018 at 10:14 AM, Miroslav Lichvar
wrote:
> On Wed, Mar 07, 2018 at 04:43:20PM +0100, Christian Ehrhardt wrote:
> > I thought that having the server portion work by default would be very
> nice
> > to user.
>
> Are there any users that want to run an NTP server knowing that the
> c
On Wed, Mar 07, 2018 at 04:43:20PM +0100, Christian Ehrhardt wrote:
> I thought that having the server portion work by default would be very nice
> to user.
Are there any users that want to run an NTP server knowing that the
clock is not synchronized by something else, but not care if it will
be s
On Wed, Mar 7, 2018 at 6:40 PM, Stephen Satchell wrote:
> On 03/07/2018 07:43 AM, Christian Ehrhardt wrote:
>
>> 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 outwe
On 03/07/2018 07:43 AM, Christian Ehrhardt wrote:
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.
Doing a fallback without some kind of notice is just p
On Wed, Mar 7, 2018 at 3:43 PM, Miroslav Lichvar
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
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.
>
> Usual
21 matches
Mail list logo
