Chrony client on host with server running in LXC on same host

Hi,

Stumbled upon the recent discussion about running multiple layers of ntp =
services[1], and also an older discussion[2] regarding feedback loops eve=
n when running with the -x flag.

I have a scenario where I have multiple physical Linux hosts (10+ for the=
 sake of this discussion), which I was planning to run chrony in =E2=80=9C=
client mode=E2=80=9D syncing with =E2=80=9Cntp1.foo.bar=E2=80=9D and =E2=80=
=9Cntp2.foo.bar=E2=80=9D. These two ntp-servers (ntp1+2) will be running =
inside an LXC-container on two out of the 10+ hosts, and source their tim=
e from external NTP-servers.

My interpretation of how the -x flag worked, was that it basically ignore=
d the system time, and only used the virtual software clock (=E2=80=9CNTP=
 clock=E2=80=9D) to serve NTP clients with. Based on the two aforemention=
ed discussions, that doesn=E2=80=99t seem to be the case (i.e. it still r=
elies on the system clock, even if the server doesn=E2=80=99t attempt to =
set it).

I also noticed that the 4.7 changelog mentions =E2=80=9CDetect clock inte=
rference from other processes=E2=80=9D. Is this something that would solv=
e these feedback loops in the scenario I=E2=80=99m describing?

If not, what should the chrony-config look like on the client (hosts) and=
 server (ntp1+2)? Would it be possible to have equal config on all hosts =
(regardless if ntp1+2 is running as LXC container on said host or not), t=
o ease config-deployment of chrony on the hosts? Preferably a setup where=
 only ntp1+2 has access to the external NTP-servers (i.e. hosts will not)=
=2E


[1] <https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users/2=
026/01/msg00003.html>
[2] <https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users/2=
024/10/msg00002.html>

-- =

Joachim

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]