Op 24/02/2012 om 12:32:51 +0100, schreef Miroslav Lichvar:
> On Fri, Feb 24, 2012 at 12:12:10PM +0100, Leo Baltus wrote:
> > Op 24/02/2012 om 11:43:01 +0100, schreef Miroslav Lichvar:
> > > I think that will create a positive feedback loop and will not work
> > > well, if at all. The instance
Op 24/02/2012 om 11:43:01 +0100, schreef Miroslav Lichvar:
> On Fri, Feb 24, 2012 at 11:02:55AM +0100, Leo Baltus wrote:
> > I am not saying that multiple processes should serve a single clock.
> >
> > Let me try some good old ascii art:
> >
> > uplink local nets
> >
On Fri, Feb 24, 2012 at 11:02:55AM +0100, Leo Baltus wrote:
> I am not saying that multiple processes should serve a single clock.
>
> Let me try some good old ascii art:
>
> uplink local nets
>pool --- ntp-only-server1 --- ntp-client
>
Op 23/02/2012 om 12:34:50 +, schreef Ed W:
> On 23/02/2012 08:24, Leo Baltus wrote:
> >Op 22/02/2012 om 23:07:51 +, schreef Ed W:
> >>>In our setup we do not like to pin a service to a specific piece of
> >>>hardware. If, for some reason, a service should run elsewhere we just
> >>>stop it
On Fri, 24 Feb 2012, Leo Baltus wrote:
I am not saying that multiple processes should serve a single clock.
Let me try some good old ascii art:
uplink local nets
pool --- ntp-only-server1 --- ntp-client
ntp-only-server2 ---
On Thu, 23 Feb 2012, Ed W wrote:
On 23/02/2012 08:24, Leo Baltus wrote:
Op 22/02/2012 om 23:07:51 +, schreef Ed W:
In our setup we do not like to pin a service to a specific piece of
hardware. If, for some reason, a service should run elsewhere we
just
stop it en start it elsewhere.
Hi
In our setup we do not like to pin a service to a specific piece of
hardware. If, for some reason, a service should run elsewhere we just
stop it en start it elsewhere. bind() make is invisible for the outside
to see and firewalls do not need to know about it either. This is what
we do for
On Tue, Feb 21, 2012 at 05:39:54PM +0100, Leo Baltus wrote:
> It would be quite nice if we could separate the network service from the
> sync-to-system-clock service. In that case we could a) run a local chronyd
> which bind()'s to an unusual port and acts as a ntpclient syncing the
> system
Hi,
We would like to use chrony in our environment to replace ntpd.
What we really like in chrony is the ability to bind() to an interface
so we can make really tight firewall rules.
In our setup we do not like to pin a service to a specific piece of
hardware. If, for some reason, a service