[Users] NTP Server in einer virtuellen Umgebung - SOLVED

lst_hoe02 at kwsoft.de lst_hoe02 at kwsoft.de
Tue Dec 13 03:44:48 EST 2011


Zitat von Daniel Bauer <mlist at dsb-gmbh.de>:

> From: <lst_hoe02 at kwsoft.de>
>> Zitat von Daniel Bauer <mlist at dsb-gmbh.de>:
>>
>>> From: <lst_hoe02 at kwsoft.de>
>>>> Zitat von Daniel Pittman <daniel at rimspace.net>:
>>>>
>>>>> On Sun, Dec 11, 2011 at 07:09, Daniel Bauer <mlist at dsb-gmbh.de>
>>>>> wrote:
>>>>>
>>>>>> I've a VPS for my internal LAN, which should also be used as a NTP
>>>>>> server.
>>>>>> The HN has already syncronized the time by de.pool.ntp.org, so the
>>>>>> time is
>>>>>> also ok inside the VPS.
>>>>>> The NTP server inside the VPS stalled, ntpq -p shows:
>>>>>
>>>>> You don't need NTP inside the container, just on the HN.  The VE
>>>>> can't
>>>>> set the time anyhow.
>>>>
>>>> Not really true. You need special capabilities assigned to the VE to
>>>> let it manage your system clock. So if you need ntp inside the VE you
>>>> should do something like "vzctl set <VEID> --capability sys_time:on",
>>>> install ntp inside the VE and deinstall it on the HN.
>>>
>>> But that's not what I want.
>>>
>>> I want the HN to be a NTP client, so that all (HN + VE) have a valid
>>> time.
>>> This works already.
>>>
>>> I want the VE to be a NTP server for the local LAN, without beeing a
>>> NTP Client.
>>> That doesn't work.
>>
>> NTP by default only works as server if it has a valid timesource. By
>> default it does not use the "local clock" because its unreliable. On
>> the other hand NTP always try to adjust the local clock if it has a
>> valid timesource. This does not work in a VE if you don't set the
>> capability to adjust the clock, NTP will even run as "root" if it is
>> not able to adjust the local clock with the intended user.
>>
>> If you insist on your network design your options are:
>> - Let the VE NTP get the time from the HN and let it run as root on the
>> VE
>> - Try to hack NTP use the local clock as timesource and not try to
>> update
>
> the solution was not to take localhost, but
>> server 127.127.1.0
>> fudge 127.127.1.0 stratum 12
> now it works.

But be aware that NTP inside the VE is running as "root" in this case.  
Don't every expose it to untrusted networks this way.

Regards

Andreas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://openvz.org/pipermail/users/attachments/20111213/0dfd1a6a/smime.bin


More information about the Users mailing list