Re: [qubes-users] NTP and/or clock issue

[Ivan Mitev]

Hi Matthew,

On 04/28/2018 03:47 PM, Matthew Wyenandt wrote:
> On Friday, April 27, 2018 at 10:28:04 PM UTC-5, Ivan Mitev wrote:
>> On 04/27/2018 11:20 PM, Matthew Wyenandt wrote:
>>> On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote:
 On 04/27/2018 09:34 PM, Matthew Wyenandt wrote:
> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote:
>> Hey,
>>
>> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote:
>>> Hi all, 
>>>
>>> I'm new to Qubes 4.0 and loving it.  I'm having an odd situation where 
>>> the time on my clock is showing -5 from my current timezone, rather 
>>> than -5 from UTC.  For instance, I'm physically located in 
>>> America/Chicago timezone, which is -5 UTC.  My Qubes OS clock is set 
>>> for America/Chicago timezone, which also says -5 UTC; however, the 
>>> clock is now showing -10 UTC.  I've tried to figure out a way to 
>>> manipulate the clock within dom0, but I'm not finding anyway to do so.
>>
>> your hw clock is likely set to local time instead of UTC ; this usually
>> happens because you use(d) MS Windows.
>>
>> `hwclock` allows you to tweak the hardware clock; you can manually set
>> the time and then run `hwclock --systohc --utc`, that should fix your
>> problem.
>>
>> Note that `qvm-sync-clock` is run every hour in dom0 and should fix the
>> offset automatically: it first syncs dom0's time with the time in
>> "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and
>> it then runs `hwclock --systohc`.
>>
>> If you still have issues, check that the timezone and time are OK in
>> sys-net (or whatever clockvm you have defined).
>
> Thanks for this info, Ivan.  I followed these steps.  Should my sys-net 
> clock be set for UTC?  When I run hwclock --show, it's still showing EDT 
> as the current time.  Do I need to set this manually?  I would prefer 
> that it get updated via ntp.

 The clockVM's clock is synchronized with NTP, you don't need to set
 anything manually...

 Clock synchronization works like that (if I'm not mistaken):

 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh`
 script sets the VM's timezone (the script gets the timezone from dom0
 with `qubesdb-read /qubes-timezone`).

 2a- if the VM is defined as the clockVM (sys-net by default) then the
 `systemd-timesyncd` service synchronizes the VM's clock with NTP.

 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd
 timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with
 the time in clockVM (sys-net).


 So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should
 point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago).
 Then the easiest way is to perform a *full* reboot and everything should
 be fine.


 If it isn't, you'll have to debug a bit further:

 - make sure the timezone is OK in VMs too (again with `ls -l
 /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone`
 returns: it should be the same as dom0's timezone.

 - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl
 status systemd-timesyncd` should output a line like

 Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)."

 the clock in sys-net should show the right time (both `date` and `sudo
 hwclock` should show the same time, with the EDT format).

 - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time
 should then be OK.


 Hope this helps !
>>>
>>> Okay, so something doesn't seem to be configured correctly.  During further 
>>> debugging, i was able to get the correct timezone using 'timedatectl 
>>> set-timezone Americas/Chicago'.  However, when running 'systemctl status 
>>> systemd-timesyncd' I get the following output:
>>>
>>> systemd-timesyncd.service - Network Time Synchronization
>>>Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; 
>>> enabled; v
>>>   Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
>>>└─30_qubes.conf
>>>Active: inactive (dead)
>>> Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago
>>>└─ ConditionPathExists=/var/run/qubes-service/clocksync was not 
>>> met
>>>  Docs: man:systemd-timesyncd.service(8)
>>>
>>> It seems the clocksync file is missing from /var/run/qubes-service/ 
>>> directory.
>>
>>
>> If the output above is for your clockVM (sys-net) then something isn't
>> right. Otherwise that's the standard output for other VMs:
>> /var/run/qubes-service/clocksync is set only in the clockVM
>>
>> I'm afraid I can't help more than that - maybe someone more experienced
>> will chime in, otherwise you should file an issue.
>>
>> just in case, please 

Re: [qubes-users] NTP and/or clock issue

[Matthew Wyenandt]

On Friday, April 27, 2018 at 10:28:04 PM UTC-5, Ivan Mitev wrote:
> On 04/27/2018 11:20 PM, Matthew Wyenandt wrote:
> > On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote:
> >> On 04/27/2018 09:34 PM, Matthew Wyenandt wrote:
> >>> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote:
>  Hey,
> 
>  On 04/27/2018 06:12 PM, Matthew Wyenandt wrote:
> > Hi all, 
> >
> > I'm new to Qubes 4.0 and loving it.  I'm having an odd situation where 
> > the time on my clock is showing -5 from my current timezone, rather 
> > than -5 from UTC.  For instance, I'm physically located in 
> > America/Chicago timezone, which is -5 UTC.  My Qubes OS clock is set 
> > for America/Chicago timezone, which also says -5 UTC; however, the 
> > clock is now showing -10 UTC.  I've tried to figure out a way to 
> > manipulate the clock within dom0, but I'm not finding anyway to do so.
> 
>  your hw clock is likely set to local time instead of UTC ; this usually
>  happens because you use(d) MS Windows.
> 
>  `hwclock` allows you to tweak the hardware clock; you can manually set
>  the time and then run `hwclock --systohc --utc`, that should fix your
>  problem.
> 
>  Note that `qvm-sync-clock` is run every hour in dom0 and should fix the
>  offset automatically: it first syncs dom0's time with the time in
>  "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and
>  it then runs `hwclock --systohc`.
> 
>  If you still have issues, check that the timezone and time are OK in
>  sys-net (or whatever clockvm you have defined).
> >>>
> >>> Thanks for this info, Ivan.  I followed these steps.  Should my sys-net 
> >>> clock be set for UTC?  When I run hwclock --show, it's still showing EDT 
> >>> as the current time.  Do I need to set this manually?  I would prefer 
> >>> that it get updated via ntp.
> >>
> >> The clockVM's clock is synchronized with NTP, you don't need to set
> >> anything manually...
> >>
> >> Clock synchronization works like that (if I'm not mistaken):
> >>
> >> 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh`
> >> script sets the VM's timezone (the script gets the timezone from dom0
> >> with `qubesdb-read /qubes-timezone`).
> >>
> >> 2a- if the VM is defined as the clockVM (sys-net by default) then the
> >> `systemd-timesyncd` service synchronizes the VM's clock with NTP.
> >>
> >> 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd
> >> timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with
> >> the time in clockVM (sys-net).
> >>
> >>
> >> So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should
> >> point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago).
> >> Then the easiest way is to perform a *full* reboot and everything should
> >> be fine.
> >>
> >>
> >> If it isn't, you'll have to debug a bit further:
> >>
> >> - make sure the timezone is OK in VMs too (again with `ls -l
> >> /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone`
> >> returns: it should be the same as dom0's timezone.
> >>
> >> - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl
> >> status systemd-timesyncd` should output a line like
> >>
> >> Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)."
> >>
> >> the clock in sys-net should show the right time (both `date` and `sudo
> >> hwclock` should show the same time, with the EDT format).
> >>
> >> - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time
> >> should then be OK.
> >>
> >>
> >> Hope this helps !
> > 
> > Okay, so something doesn't seem to be configured correctly.  During further 
> > debugging, i was able to get the correct timezone using 'timedatectl 
> > set-timezone Americas/Chicago'.  However, when running 'systemctl status 
> > systemd-timesyncd' I get the following output:
> > 
> > systemd-timesyncd.service - Network Time Synchronization
> >Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; 
> > enabled; v
> >   Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
> >└─30_qubes.conf
> >Active: inactive (dead)
> > Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago
> >└─ ConditionPathExists=/var/run/qubes-service/clocksync was not 
> > met
> >  Docs: man:systemd-timesyncd.service(8)
> > 
> > It seems the clocksync file is missing from /var/run/qubes-service/ 
> > directory.
> 
> 
> If the output above is for your clockVM (sys-net) then something isn't
> right. Otherwise that's the standard output for other VMs:
> /var/run/qubes-service/clocksync is set only in the clockVM
> 
> I'm afraid I can't help more than that - maybe someone more experienced
> will chime in, otherwise you should file an issue.
> 
> just in case, please paste the output of the following commands:
> 
> in dom0:
> - 

Re: [qubes-users] NTP and/or clock issue

[Ivan Mitev]

On 04/27/2018 11:20 PM, Matthew Wyenandt wrote:
> On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote:
>> On 04/27/2018 09:34 PM, Matthew Wyenandt wrote:
>>> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote:
 Hey,

 On 04/27/2018 06:12 PM, Matthew Wyenandt wrote:
> Hi all, 
>
> I'm new to Qubes 4.0 and loving it.  I'm having an odd situation where 
> the time on my clock is showing -5 from my current timezone, rather than 
> -5 from UTC.  For instance, I'm physically located in America/Chicago 
> timezone, which is -5 UTC.  My Qubes OS clock is set for America/Chicago 
> timezone, which also says -5 UTC; however, the clock is now showing -10 
> UTC.  I've tried to figure out a way to manipulate the clock within dom0, 
> but I'm not finding anyway to do so.

 your hw clock is likely set to local time instead of UTC ; this usually
 happens because you use(d) MS Windows.

 `hwclock` allows you to tweak the hardware clock; you can manually set
 the time and then run `hwclock --systohc --utc`, that should fix your
 problem.

 Note that `qvm-sync-clock` is run every hour in dom0 and should fix the
 offset automatically: it first syncs dom0's time with the time in
 "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and
 it then runs `hwclock --systohc`.

 If you still have issues, check that the timezone and time are OK in
 sys-net (or whatever clockvm you have defined).
>>>
>>> Thanks for this info, Ivan.  I followed these steps.  Should my sys-net 
>>> clock be set for UTC?  When I run hwclock --show, it's still showing EDT as 
>>> the current time.  Do I need to set this manually?  I would prefer that it 
>>> get updated via ntp.
>>
>> The clockVM's clock is synchronized with NTP, you don't need to set
>> anything manually...
>>
>> Clock synchronization works like that (if I'm not mistaken):
>>
>> 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh`
>> script sets the VM's timezone (the script gets the timezone from dom0
>> with `qubesdb-read /qubes-timezone`).
>>
>> 2a- if the VM is defined as the clockVM (sys-net by default) then the
>> `systemd-timesyncd` service synchronizes the VM's clock with NTP.
>>
>> 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd
>> timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with
>> the time in clockVM (sys-net).
>>
>>
>> So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should
>> point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago).
>> Then the easiest way is to perform a *full* reboot and everything should
>> be fine.
>>
>>
>> If it isn't, you'll have to debug a bit further:
>>
>> - make sure the timezone is OK in VMs too (again with `ls -l
>> /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone`
>> returns: it should be the same as dom0's timezone.
>>
>> - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl
>> status systemd-timesyncd` should output a line like
>>
>> Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)."
>>
>> the clock in sys-net should show the right time (both `date` and `sudo
>> hwclock` should show the same time, with the EDT format).
>>
>> - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time
>> should then be OK.
>>
>>
>> Hope this helps !
> 
> Okay, so something doesn't seem to be configured correctly.  During further 
> debugging, i was able to get the correct timezone using 'timedatectl 
> set-timezone Americas/Chicago'.  However, when running 'systemctl status 
> systemd-timesyncd' I get the following output:
> 
> systemd-timesyncd.service - Network Time Synchronization
>Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; 
> enabled; v
>   Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
>└─30_qubes.conf
>Active: inactive (dead)
> Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago
>└─ ConditionPathExists=/var/run/qubes-service/clocksync was not met
>  Docs: man:systemd-timesyncd.service(8)
> 
> It seems the clocksync file is missing from /var/run/qubes-service/ directory.


If the output above is for your clockVM (sys-net) then something isn't
right. Otherwise that's the standard output for other VMs:
/var/run/qubes-service/clocksync is set only in the clockVM

I'm afraid I can't help more than that - maybe someone more experienced
will chime in, otherwise you should file an issue.

just in case, please paste the output of the following commands:

in dom0:
- `timedatectl`
- `ls -l /etc/localtime`

in sys-net:
- `systemctl restart systemd-timesyncd` followed by `systemctl status
systemd-timesyncd`
- `timedatectl`
- `qubesdb-read /qubes-timezone`

in another VM:
- `sudo qvm-sync-clock`
- `timedatectl`
- `qubesdb-read /qubes-timezone`

-- 
You received 

Re: [qubes-users] NTP and/or clock issue

[Matthew Wyenandt]

On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote:
> On 04/27/2018 09:34 PM, Matthew Wyenandt wrote:
> > On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote:
> >> Hey,
> >>
> >> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote:
> >>> Hi all, 
> >>>
> >>> I'm new to Qubes 4.0 and loving it.  I'm having an odd situation where 
> >>> the time on my clock is showing -5 from my current timezone, rather than 
> >>> -5 from UTC.  For instance, I'm physically located in America/Chicago 
> >>> timezone, which is -5 UTC.  My Qubes OS clock is set for America/Chicago 
> >>> timezone, which also says -5 UTC; however, the clock is now showing -10 
> >>> UTC.  I've tried to figure out a way to manipulate the clock within dom0, 
> >>> but I'm not finding anyway to do so.
> >>
> >> your hw clock is likely set to local time instead of UTC ; this usually
> >> happens because you use(d) MS Windows.
> >>
> >> `hwclock` allows you to tweak the hardware clock; you can manually set
> >> the time and then run `hwclock --systohc --utc`, that should fix your
> >> problem.
> >>
> >> Note that `qvm-sync-clock` is run every hour in dom0 and should fix the
> >> offset automatically: it first syncs dom0's time with the time in
> >> "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and
> >> it then runs `hwclock --systohc`.
> >>
> >> If you still have issues, check that the timezone and time are OK in
> >> sys-net (or whatever clockvm you have defined).
> > 
> > Thanks for this info, Ivan.  I followed these steps.  Should my sys-net 
> > clock be set for UTC?  When I run hwclock --show, it's still showing EDT as 
> > the current time.  Do I need to set this manually?  I would prefer that it 
> > get updated via ntp.
> 
> The clockVM's clock is synchronized with NTP, you don't need to set
> anything manually...
> 
> Clock synchronization works like that (if I'm not mistaken):
> 
> 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh`
> script sets the VM's timezone (the script gets the timezone from dom0
> with `qubesdb-read /qubes-timezone`).
> 
> 2a- if the VM is defined as the clockVM (sys-net by default) then the
> `systemd-timesyncd` service synchronizes the VM's clock with NTP.
> 
> 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd
> timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with
> the time in clockVM (sys-net).
> 
> 
> So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should
> point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago).
> Then the easiest way is to perform a *full* reboot and everything should
> be fine.
> 
> 
> If it isn't, you'll have to debug a bit further:
> 
> - make sure the timezone is OK in VMs too (again with `ls -l
> /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone`
> returns: it should be the same as dom0's timezone.
> 
> - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl
> status systemd-timesyncd` should output a line like
> 
> Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)."
> 
> the clock in sys-net should show the right time (both `date` and `sudo
> hwclock` should show the same time, with the EDT format).
> 
> - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time
> should then be OK.
> 
> 
> Hope this helps !

Okay, so something doesn't seem to be configured correctly.  During further 
debugging, i was able to get the correct timezone using 'timedatectl 
set-timezone Americas/Chicago'.  However, when running 'systemctl status 
systemd-timesyncd' I get the following output:

systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; v
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
   └─30_qubes.conf
   Active: inactive (dead)
Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago
   └─ ConditionPathExists=/var/run/qubes-service/clocksync was not met
 Docs: man:systemd-timesyncd.service(8)

It seems the clocksync file is missing from /var/run/qubes-service/ directory.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3da0d854-ee68-4534-b575-8e082d5b8f67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP and/or clock issue

[Ivan Mitev]

On 04/27/2018 09:34 PM, Matthew Wyenandt wrote:
> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote:
>> Hey,
>>
>> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote:
>>> Hi all, 
>>>
>>> I'm new to Qubes 4.0 and loving it.  I'm having an odd situation where the 
>>> time on my clock is showing -5 from my current timezone, rather than -5 
>>> from UTC.  For instance, I'm physically located in America/Chicago 
>>> timezone, which is -5 UTC.  My Qubes OS clock is set for America/Chicago 
>>> timezone, which also says -5 UTC; however, the clock is now showing -10 
>>> UTC.  I've tried to figure out a way to manipulate the clock within dom0, 
>>> but I'm not finding anyway to do so.
>>
>> your hw clock is likely set to local time instead of UTC ; this usually
>> happens because you use(d) MS Windows.
>>
>> `hwclock` allows you to tweak the hardware clock; you can manually set
>> the time and then run `hwclock --systohc --utc`, that should fix your
>> problem.
>>
>> Note that `qvm-sync-clock` is run every hour in dom0 and should fix the
>> offset automatically: it first syncs dom0's time with the time in
>> "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and
>> it then runs `hwclock --systohc`.
>>
>> If you still have issues, check that the timezone and time are OK in
>> sys-net (or whatever clockvm you have defined).
> 
> Thanks for this info, Ivan.  I followed these steps.  Should my sys-net clock 
> be set for UTC?  When I run hwclock --show, it's still showing EDT as the 
> current time.  Do I need to set this manually?  I would prefer that it get 
> updated via ntp.

The clockVM's clock is synchronized with NTP, you don't need to set
anything manually...

Clock synchronization works like that (if I'm not mistaken):

1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh`
script sets the VM's timezone (the script gets the timezone from dom0
with `qubesdb-read /qubes-timezone`).

2a- if the VM is defined as the clockVM (sys-net by default) then the
`systemd-timesyncd` service synchronizes the VM's clock with NTP.

2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd
timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with
the time in clockVM (sys-net).


So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should
point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago).
Then the easiest way is to perform a *full* reboot and everything should
be fine.


If it isn't, you'll have to debug a bit further:

- make sure the timezone is OK in VMs too (again with `ls -l
/etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone`
returns: it should be the same as dom0's timezone.

- in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl
status systemd-timesyncd` should output a line like

Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)."

the clock in sys-net should show the right time (both `date` and `sudo
hwclock` should show the same time, with the EDT format).

- in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time
should then be OK.


Hope this helps !

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ce64581a-8d69-1cd0-8fcf-2bceaf0c21db%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP and/or clock issue

[Ivan Mitev]

Hey,

On 04/27/2018 06:12 PM, Matthew Wyenandt wrote:
> Hi all, 
> 
> I'm new to Qubes 4.0 and loving it.  I'm having an odd situation where the 
> time on my clock is showing -5 from my current timezone, rather than -5 from 
> UTC.  For instance, I'm physically located in America/Chicago timezone, which 
> is -5 UTC.  My Qubes OS clock is set for America/Chicago timezone, which also 
> says -5 UTC; however, the clock is now showing -10 UTC.  I've tried to figure 
> out a way to manipulate the clock within dom0, but I'm not finding anyway to 
> do so.

your hw clock is likely set to local time instead of UTC ; this usually
happens because you use(d) MS Windows.

`hwclock` allows you to tweak the hardware clock; you can manually set
the time and then run `hwclock --systohc --utc`, that should fix your
problem.

Note that `qvm-sync-clock` is run every hour in dom0 and should fix the
offset automatically: it first syncs dom0's time with the time in
"clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and
it then runs `hwclock --systohc`.

If you still have issues, check that the timezone and time are OK in
sys-net (or whatever clockvm you have defined).

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/224371b5-528d-c40a-8b09-375a73940441%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] NTP and/or clock issue

[Matthew Wyenandt]

Hi all, 

I'm new to Qubes 4.0 and loving it.  I'm having an odd situation where the time 
on my clock is showing -5 from my current timezone, rather than -5 from UTC.  
For instance, I'm physically located in America/Chicago timezone, which is -5 
UTC.  My Qubes OS clock is set for America/Chicago timezone, which also says -5 
UTC; however, the clock is now showing -10 UTC.  I've tried to figure out a way 
to manipulate the clock within dom0, but I'm not finding anyway to do so.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2cd75d44-d4ca-404a-8336-5342e933ba8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ntp in debain-VMs

[haaber]

>> Dear qubes-community,  my debian-based VM's all have almost random
>> date/time settings. I tried to tackle this by setting up ntp correctly
>> in the template VM, but this does simply have no effect to the derived
>> appVMs. Culd someone help me with that?  Thank you, Bernhard
>>
> 
> I'm getting consistent time in my Debian 9 VMs. Do you have your
> 'ClockVM' setting populated in your Qubes Manager Global Settings? Its
> normally set to sys-net.
Aha. Indeed, my sys-net died in Jan and I created a new one, called
sys-NET. So clockVM got setting lost at this moment. My sys-NET is based
on f24-minimal. Do I have to add extra packages in that VM to make ntp
work? I guess so ... thank you for further helpBernhard

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a01f4472-ad64-fb2e-4c83-ea7840dd5ac3%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ntp in debain-VMs

[Chris Laprise]

On 07/04/2017 07:45 AM, haaber wrote:

Dear qubes-community,  my debian-based VM's all have almost random
date/time settings. I tried to tackle this by setting up ntp correctly
in the template VM, but this does simply have no effect to the derived
appVMs. Culd someone help me with that?  Thank you, Bernhard



I'm getting consistent time in my Debian 9 VMs. Do you have your 
'ClockVM' setting populated in your Qubes Manager Global Settings? Its 
normally set to sys-net.


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b6c89f1f-8f01-ef8d-0eb9-ffe9b76b85c5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ntp in debain-VMs

[haaber]

Dear qubes-community,  my debian-based VM's all have almost random
date/time settings. I tried to tackle this by setting up ntp correctly
in the template VM, but this does simply have no effect to the derived
appVMs. Culd someone help me with that?  Thank you, Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/35bb2212-b6f8-7ae8-8685-cd7788fa9523%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Saturday, 18 March 2017 05:09:59 UTC+11, cooloutac  wrote:
> On Thursday, March 16, 2017 at 11:26:48 PM UTC-4, Drew White wrote:
> > On Friday, 17 March 2017 11:36:25 UTC+11, Jean-Philippe Ouellet  wrote:
> > > As for changing the NTP server used, feel free to submit patches.
> > 
> > If I was to submit patches, they wouldn't be in Python Code. So I can't 
> > submit any changes because my applications aren't written in Python.
> 
> the amount of times qubes contacts the dns servers is same on baremetal 
> systems.  I always eyeball etherape from sys-net.

Actually, it's a lot more often.
I run many things like that, but I just mainly watch the DNS server.. I got too 
many requests for the machines to be even doing it once every 10 mins. how to 
fix?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/efc2d18f-c9d8-4898-b769-c0cee6720566%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Friday, 17 March 2017 11:36:25 UTC+11, Jean-Philippe Ouellet  wrote:
> Qubes only runs an NTP client in the ClockVM (sys-net) and syncs all
> other domains via qrexec services, so your claim about NTP traffic
> coming from multiple VMs on a default system is false.
> 
> As for changing the NTP server used, feel free to submit patches.

ClockVM (ClockVM) [Not necessarily sys-net]

Okay, so you are telling me that the data coming from each guest connecting 
through the monitor, connecting to pool.ntp.org to get the time is not the way 
it works even though that is the way it worked since it was initially installed?

I monitored, I checked, I verified, I checked the DNS server... I checked it 
all BEFORE I posted here.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/472e286d-1558-4c48-98b8-86e964fecaec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Friday, 17 March 2017 11:36:25 UTC+11, Jean-Philippe Ouellet  wrote:
> As for changing the NTP server used, feel free to submit patches.

If I was to submit patches, they wouldn't be in Python Code. So I can't submit 
any changes because my applications aren't written in Python.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fa7d9ecc-ad4b-42ae-89f5-aecd7feffcf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Friday, 17 March 2017 11:36:25 UTC+11, Jean-Philippe Ouellet  wrote:
> Qubes only runs an NTP client in the ClockVM (sys-net) and syncs all
> other domains via qrexec services, so your claim about NTP traffic
> coming from multiple VMs on a default system is false.
> 
> As for changing the NTP server used, feel free to submit patches.

Then can you tell me why changing it in all VMS that aren't the clock VM allows 
the requests to decrease by 1 for every one that I changed?

Can you tell me why changing the template altered all Guests and also altered 
the clockVM it stopped looking at pool.ntp.org and looked where I told it to?

IF I commented out the manual setting to request from pool.ntp.org in a 
specific guest, that guest didn't get the time updated in that guest.

How do you explain all that?


Sorry if anything I'm saying is coming across in a seemingly wrong way, it is 
not meant as such, I'm just trying to understand why it's not working the way 
that you said it's supposed to work when standard works the way that you say it 
doesn't.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b132454e-33af-4996-b9d1-79d2861ee0da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Jean-Philippe Ouellet]

Qubes only runs an NTP client in the ClockVM (sys-net) and syncs all
other domains via qrexec services, so your claim about NTP traffic
coming from multiple VMs on a default system is false.

As for changing the NTP server used, feel free to submit patches.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_Bsn6hgvfsBABE20uXfUcUPWoG7%2Bdo%3DDEZWdsSKVcLgeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Friday, 17 March 2017 11:03:13 UTC+11, Drew White  wrote:
> On Monday, 13 March 2017 19:48:19 UTC+11, Jean-Philippe Ouellet  wrote:
> > On Mon, Mar 13, 2017 at 12:54 AM, Drew White  wrote:
> > > On Monday, 13 March 2017 15:02:42 UTC+11, Jean-Philippe Ouellet  wrote:
> > >> From my quick reading of the source and observations of my systems,
> > >> that appears to be exactly how it is implemented right now.
> > >
> > > In other words, the way it is right now is in a form in which it is yet 
> > > to be complete because they have not instantiated the way that it's meant 
> > > to work?
> > 
> > No, in other words nothing needs to be done (except perhaps reverting
> > your system to how it was before) because a default system already
> > behaves in the correct manner.
>  
> So having it as standard works the way I said it does, and you are telling me 
> it doesn't when it does?
> 
> Unfortunately, what you are informing me is wrong.
> 

As I stated earlier, the ntp is always retrieved from pool.ntp.org, the site 
that is DEFINED in the file. IF the file did NOT have that set, then it would 
look on the network to get the ntp settings that are defined by the network.

Thus, you saying that it should do that, when the pool.ntp.org domain is 
defined as the target, conveys that you are in fact incorrect.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1648ea0e-c7f6-472a-8c33-581fb0bd9ad7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Monday, 13 March 2017 19:48:19 UTC+11, Jean-Philippe Ouellet  wrote:
> On Mon, Mar 13, 2017 at 12:54 AM, Drew White  wrote:
> > On Monday, 13 March 2017 15:02:42 UTC+11, Jean-Philippe Ouellet  wrote:
> >> From my quick reading of the source and observations of my systems,
> >> that appears to be exactly how it is implemented right now.
> >
> > In other words, the way it is right now is in a form in which it is yet to 
> > be complete because they have not instantiated the way that it's meant to 
> > work?
> 
> No, in other words nothing needs to be done (except perhaps reverting
> your system to how it was before) because a default system already
> behaves in the correct manner.
 
So having it as standard works the way I said it does, and you are telling me 
it doesn't when it does?

Unfortunately, what you are informing me is wrong.


> >> Note also that this is not what you initially described in your first 
> >> email.
> >
> > It is not what I initially described because I was making an enquiry not 
> > providing details on what I had to do to change it per guest and not on a 
> > global level in such a way to reduce the impact on the system and the NTP 
> > server and DNS server.
> >
> > I posted on the forums, not sent an email, but I understand that you may 
> > think so because it's a forum that has a mailing list on it available.
> 
> /me stops feeding the troll now

No troll here, sorry.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/54ef2679-ac66-4f94-b1e4-b4f32abd14f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Jean-Philippe Ouellet]

On Mon, Mar 13, 2017 at 12:54 AM, Drew White  wrote:
> On Monday, 13 March 2017 15:02:42 UTC+11, Jean-Philippe Ouellet  wrote:
>> From my quick reading of the source and observations of my systems,
>> that appears to be exactly how it is implemented right now.
>
> In other words, the way it is right now is in a form in which it is yet to be 
> complete because they have not instantiated the way that it's meant to work?

No, in other words nothing needs to be done (except perhaps reverting
your system to how it was before) because a default system already
behaves in the correct manner.

>> Note also that this is not what you initially described in your first email.
>
> It is not what I initially described because I was making an enquiry not 
> providing details on what I had to do to change it per guest and not on a 
> global level in such a way to reduce the impact on the system and the NTP 
> server and DNS server.
>
> I posted on the forums, not sent an email, but I understand that you may 
> think so because it's a forum that has a mailing list on it available.

/me stops feeding the troll now

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_D-4%3DL2sEPmA0-Z2C7OBYfsCDKUEtTcp6FS6oZeM5DyeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Monday, 13 March 2017 15:02:42 UTC+11, Jean-Philippe Ouellet  wrote:
> On Sun, Mar 12, 2017 at 10:59 PM, Drew White  wrote:
> > Question: Why does it not work properly then?
> 
> Answer: Must be because of something you changed on your system.
> 
> It *does* appear to work properly by default, confirmed by not seeing
> the NTP traffic you describe on two Qubes machines, one of which is
> literally a perfectly unmodified default install of 3.2 I have just
> for testing things.
> 
> > Thus, it kept running /usr/sbin/ntpdate pool.ntp.org
> >
> > Until I changed that, it was futile.
> 
> Feel free to send patches to allow users to easily specify an ntp server(s).
 
Well, at this time, it's easiest to change it in the templates, and let it be 
populated downwards. Until a better functionality is implemented, it's not 
going to be more useful.

If I myself provided applications/services to enable this, then that would take 
me a bit of time to achieve properly due to the fact that it would have to work 
in version 4 as well.

> >> >> > The "ClockVM" does not seem to be operating the way I would have 
> >> >> > thought a "ClockVM" would.
> >> >>
> >> >> Only the ClockVM to uses NTP at all, and it sends the time back to
> >> >> dom0. The rest of the VMs get their time set by dom0 via
> >> >> qubes.SetDateTime service.
> >> >
> >> > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a 
> >> > good addition to allow it to update each Guest.
> >>
> >> No. That would be a bad design for several reasons. Dom0 already does
> >> this periodically. This is better than what I assume you suggest
> >> (ClockVM directly invoking qubes.setDateTime in each guest) because
> >> the service invocations are implicitly rate-limited and contents
> >> filtered by dom0. It is also not desired for the ClockVM VM to even
> >> know which other VMs exist, let alone know which ones are running and
> >> need their clock set.
> >
> > I was more thinking the ClockVM (CVM) gets the time, then Dom0 gets the 
> > time, then Dom0 updates everything, it would all be via Dom0, but the CVM 
> > gets the time initially, and if it has a difference in the NTP compared to 
> > the time set in the CVM it then proceeds to update each guests time without 
> > calling an external NTP server, and keeps it all inside the Guest regime.
> 
> Exactly.
> 
> From my quick reading of the source and observations of my systems,
> that appears to be exactly how it is implemented right now.

In other words, the way it is right now is in a form in which it is yet to be 
complete because they have not instantiated the way that it's meant to work?

 
> Note also that this is not what you initially described in your first email.

It is not what I initially described because I was making an enquiry not 
providing details on what I had to do to change it per guest and not on a 
global level in such a way to reduce the impact on the system and the NTP 
server and DNS server.

I posted on the forums, not sent an email, but I understand that you may think 
so because it's a forum that has a mailing list on it available.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2e4348d2-8d4d-41be-a56f-33fa2925454f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Jean-Philippe Ouellet]

On Sun, Mar 12, 2017 at 10:59 PM, Drew White  wrote:
> Question: Why does it not work properly then?

Answer: Must be because of something you changed on your system.

It *does* appear to work properly by default, confirmed by not seeing
the NTP traffic you describe on two Qubes machines, one of which is
literally a perfectly unmodified default install of 3.2 I have just
for testing things.

> Thus, it kept running /usr/sbin/ntpdate pool.ntp.org
>
> Until I changed that, it was futile.

Feel free to send patches to allow users to easily specify an ntp server(s).

>> >> > The "ClockVM" does not seem to be operating the way I would have 
>> >> > thought a "ClockVM" would.
>> >>
>> >> Only the ClockVM to uses NTP at all, and it sends the time back to
>> >> dom0. The rest of the VMs get their time set by dom0 via
>> >> qubes.SetDateTime service.
>> >
>> > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a 
>> > good addition to allow it to update each Guest.
>>
>> No. That would be a bad design for several reasons. Dom0 already does
>> this periodically. This is better than what I assume you suggest
>> (ClockVM directly invoking qubes.setDateTime in each guest) because
>> the service invocations are implicitly rate-limited and contents
>> filtered by dom0. It is also not desired for the ClockVM VM to even
>> know which other VMs exist, let alone know which ones are running and
>> need their clock set.
>
> I was more thinking the ClockVM (CVM) gets the time, then Dom0 gets the time, 
> then Dom0 updates everything, it would all be via Dom0, but the CVM gets the 
> time initially, and if it has a difference in the NTP compared to the time 
> set in the CVM it then proceeds to update each guests time without calling an 
> external NTP server, and keeps it all inside the Guest regime.

Exactly.

>From my quick reading of the source and observations of my systems,
that appears to be exactly how it is implemented right now.

Note also that this is not what you initially described in your first email.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_Ar6OEp2_Ar0fxW265mjVBEYmdM5_hC%2B5u7hH%2Bt3bXRww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP Global alteration.

[Drew White]

On Monday, 13 March 2017 13:44:17 UTC+11, Jean-Philippe Ouellet  wrote:
> On Sun, Mar 12, 2017 at 10:24 PM, Drew White  wrote:
> > On Monday, 13 March 2017 12:36:55 UTC+11, Jean-Philippe Ouellet  wrote:
> >> On Sun, Mar 12, 2017 at 9:19 PM, Drew White  wrote:
> >> > I want to set the NTP protocol to target the parent VM and on the NetVM 
> >> > or Sys-Firewall have that as the NTP server that feeds everything under 
> >> > it.
> >>
> >> No, you don't want that.
> >
> > Why don't I want what I want?
> 
> For the reasons I already stated, and that you appear to already
> understand. Only the ClockVM is intended to generate any NTP traffic
> which leaves your machine.
> 
> The rest of the VMs are synchronized not via NTP, but via a qrexec
> service. This works even when the VMs are not networked, whereas NTP
> to a proxy NTP server in sys-net (or somewhere) would not.
 
Question: Why does it not work properly then?


> >> > Thus only one VM calls the external source at a lesser interval to do 
> >> > the requests.
> >>
> >> That is already how it works.
> >
> > Then why does EVERY GUEST call pool.ntp.org? (unless I change it in the 
> > template for every VM)
> 
> That is not the behavior I observe on my system, confirmed by lack of
> output from:
> 
> [user@sys-firewall ~]$ sudo tcpdump -ni eth0 'udp port ntp'
> 
> Have you changed every guest on your system to do that or something?
 
Nope, I altered the sync-ntp-clock file. I changed it from pool.ntp.org to the 
local server in each guest.

Then every guest I changed stopped trying to get the time via ntp from 
pool.ntp.org. 

Until I changed that in each guest, it kept doing it EVERY 10 MINUTES from 
EVERY Guest that was running.

So that was about 15 requests every 10 minutes. Sometimes more.

One request for every guest. 

Thus, it kept running /usr/sbin/ntpdate pool.ntp.org

Until I changed that, it was futile.

> >> > How, in this system, do I perform this to get that to work please?
> >>
> >> Well, one would start by reading and understanding the relevant source:
> >>
> >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime
> >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock
> >> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock
> >
> > I read all that, that's why I found out how to change it in the first 
> > place, but every time I do something like add a NewGuest and install, with 
> > it's defaults to pool.ntp.org, it goes off and gets the NTP from an outside 
> > source. (not very secure), so I have to keep changing it to be the local 
> > server. I want to capture it all so only the NetVM performs that action.
> 
> I get the impression that maybe you are just changing config files of
> services which are not running?
 
Actually, it all came back to sync-ntp-clock file, as I said in previous.

I looked for other config files first, and nothing changed no matter what I 
changed. the system wasn't getting the NTP from the server or the router, or 
discovering the NTP server on it's own, I found it hard-coded there.


> >> > The "ClockVM" does not seem to be operating the way I would have thought 
> >> > a "ClockVM" would.
> >>
> >> Only the ClockVM to uses NTP at all, and it sends the time back to
> >> dom0. The rest of the VMs get their time set by dom0 via
> >> qubes.SetDateTime service.
> >
> > So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a 
> > good addition to allow it to update each Guest.
> 
> No. That would be a bad design for several reasons. Dom0 already does
> this periodically. This is better than what I assume you suggest
> (ClockVM directly invoking qubes.setDateTime in each guest) because
> the service invocations are implicitly rate-limited and contents
> filtered by dom0. It is also not desired for the ClockVM VM to even
> know which other VMs exist, let alone know which ones are running and
> need their clock set.
 
I was more thinking the ClockVM (CVM) gets the time, then Dom0 gets the time, 
then Dom0 updates everything, it would all be via Dom0, but the CVM gets the 
time initially, and if it has a difference in the NTP compared to the time set 
in the CVM it then proceeds to update each guests time without calling an 
external NTP server, and keeps it all inside the Guest regime.


> >> There are many reasons for this, including eliminating redundant
> >> network traffic, and the fact that it is desirable for time to be
> >> correct in all VMs (including those intentionally without any network
> >> access).
> >
> > redundant network traffic... so every 10 minute PER GUEST, it contacts 
> > pool.ntp.org and gets the time. That isn't redundant network traffic.
> 
> Again. I do not observe this. Have you verified with an unmodified template?
 
Yes, brand new installation.


> >> > Is there a bug in it?
> >>
> >> Lets see...
> >>
> >> 

Re: [qubes-users] NTP Global alteration.

[Jean-Philippe Ouellet]

On Sun, Mar 12, 2017 at 10:24 PM, Drew White  wrote:
> On Monday, 13 March 2017 12:36:55 UTC+11, Jean-Philippe Ouellet  wrote:
>> On Sun, Mar 12, 2017 at 9:19 PM, Drew White  wrote:
>> > I want to set the NTP protocol to target the parent VM and on the NetVM or 
>> > Sys-Firewall have that as the NTP server that feeds everything under it.
>>
>> No, you don't want that.
>
> Why don't I want what I want?

For the reasons I already stated, and that you appear to already
understand. Only the ClockVM is intended to generate any NTP traffic
which leaves your machine.

The rest of the VMs are synchronized not via NTP, but via a qrexec
service. This works even when the VMs are not networked, whereas NTP
to a proxy NTP server in sys-net (or somewhere) would not.

>> > Thus only one VM calls the external source at a lesser interval to do the 
>> > requests.
>>
>> That is already how it works.
>
> Then why does EVERY GUEST call pool.ntp.org? (unless I change it in the 
> template for every VM)

That is not the behavior I observe on my system, confirmed by lack of
output from:

[user@sys-firewall ~]$ sudo tcpdump -ni eth0 'udp port ntp'

Have you changed every guest on your system to do that or something?

>> > How, in this system, do I perform this to get that to work please?
>>
>> Well, one would start by reading and understanding the relevant source:
>>
>> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime
>> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock
>> https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock
>
> I read all that, that's why I found out how to change it in the first place, 
> but every time I do something like add a NewGuest and install, with it's 
> defaults to pool.ntp.org, it goes off and gets the NTP from an outside 
> source. (not very secure), so I have to keep changing it to be the local 
> server. I want to capture it all so only the NetVM performs that action.

I get the impression that maybe you are just changing config files of
services which are not running?

>> > The "ClockVM" does not seem to be operating the way I would have thought a 
>> > "ClockVM" would.
>>
>> Only the ClockVM to uses NTP at all, and it sends the time back to
>> dom0. The rest of the VMs get their time set by dom0 via
>> qubes.SetDateTime service.
>
> So the ClockVM ONLY interacts with Dom0. Fair enough. Then it would be a good 
> addition to allow it to update each Guest.

No. That would be a bad design for several reasons. Dom0 already does
this periodically. This is better than what I assume you suggest
(ClockVM directly invoking qubes.setDateTime in each guest) because
the service invocations are implicitly rate-limited and contents
filtered by dom0. It is also not desired for the ClockVM VM to even
know which other VMs exist, let alone know which ones are running and
need their clock set.

>> There are many reasons for this, including eliminating redundant
>> network traffic, and the fact that it is desirable for time to be
>> correct in all VMs (including those intentionally without any network
>> access).
>
> redundant network traffic... so every 10 minute PER GUEST, it contacts 
> pool.ntp.org and gets the time. That isn't redundant network traffic.

Again. I do not observe this. Have you verified with an unmodified template?

>> > Is there a bug in it?
>>
>> Lets see...
>>
>> https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20ntp
>> https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20clockvm
>>
>> doesn't look like it!
>
> Well, none that have been reported by anyone other than myself when asking 
> questions in the first place about it. But none opened a bug about it because 
> it's "not a bug" even though it is, (in my personal opinion) a very big bug 
> to have EVERY GUEST contact pool.ntp.org every 10 minutes. wether it's a 
> guest that's behind a proxy, or the proxy itself, or the net vm.

Things do not work as you claim they do.

> This is a security concern, and a big one at that.

Nope.

> for all unix types, the clock VM should contact the NTP server once every 6 
> hours (or on boot and then every 6 hours), and every guest should be updated 
> by that guest for time, unless set to otherwise update from elsewhere.

Where do you get this 6 hours figure from? Neither the RFC [1] or the
pool recommendations [2] suggest this.

[1]: https://tools.ietf.org/html/rfc1305
[2]: http://www.pool.ntp.org/tos.html

> I have my own NTP server, and yet I install things, and I just want to 
> capture all NTP from everything behind the NetVM and make it all get the NTP 
> from the NetVM. Unless it's requesting to the designated Network NTP server.

So... perhaps by "I have my own NTP server" do you mean "I installed
and enabled an ntp client in my default template"? That might explain
some of your confusion.

Re: [qubes-users] NTP Global alteration.

[Jean-Philippe Ouellet]

On Sun, Mar 12, 2017 at 9:19 PM, Drew White  wrote:
> Hi folks,

Hi,

> I want to set the NTP protocol to target the parent VM and on the NetVM or 
> Sys-Firewall have that as the NTP server that feeds everything under it.

No, you don't want that.

> Thus only one VM calls the external source at a lesser interval to do the 
> requests.

That is already how it works.

> How, in this system, do I perform this to get that to work please?

Well, one would start by reading and understanding the relevant source:

https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SetDateTime
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/qubes.SyncNtpClock
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/qubes-rpc/sync-ntp-clock

> The "ClockVM" does not seem to be operating the way I would have thought a 
> "ClockVM" would.

Only the ClockVM to uses NTP at all, and it sends the time back to
dom0. The rest of the VMs get their time set by dom0 via
qubes.SetDateTime service.

There are many reasons for this, including eliminating redundant
network traffic, and the fact that it is desirable for time to be
correct in all VMs (including those intentionally without any network
access).

> Is there a bug in it?

Lets see...

https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20ntp
https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue%20is%3Aopen%20clockvm

doesn't look like it!

> Sincerely,
> Drew.

Sincerely,
Jean-Philippe.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_Cv3QtRY9fXTp6nLZi5WdX7rc4BdvzmOaip-TmZyO6yTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] NTP Global alteration.

[Drew White]

Hi folks,

I want to set the NTP protocol to target the parent VM and on the NetVM or 
Sys-Firewall have that as the NTP server that feeds everything under it.

Thus only one VM calls the external source at a lesser interval to do the 
requests.

How, in this system, do I perform this to get that to work please?

The "ClockVM" does not seem to be operating the way I would have thought a 
"ClockVM" would.

Is there a bug in it?

Sincerely,
Drew.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3e20f522-fb27-4fa9-99ec-c65c82459a39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP?

[Niels Kobschätzki]

Andrew David Wong writes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-07-16 14:06, Niels Kobschätzki wrote:
>> 
>> I booted my computer tonight and the time was off by 2 hours. Then I
>> figured out that ntp is not running. So I installed ntpdate and of course
>> it cannot use any pre-configured time-servers. Are there any time servers
>> that dom0 can use?  Or which documentation would I need to read to give
>> dom0 access to a couple of time servers? Or is ntp problematic enough that
>> dom0 shouldn't use it at all cost?
>> 
> The time should be synced automatically by this cron job (in dom0):
>
> /etc/cron.d/qubes-sync-clock.cron
>
> ...which uses the qvm-sync-clock command.
>
> Check your cron log to see if it's been running:
>
> $ cat /var/log/cron

But systemctl status crond shows that it apparently runs.
Did anyone think about switching from cron to systemd-timers for QubesOS? If yes
but didn't do the switch, I'd be interested in hearing why. Personally I really 
prefer them

Niels

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/87zipgyhlm.fsf%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP?

[Niels Kobschätzki]

Andrew David Wong writes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-07-16 14:06, Niels Kobschätzki wrote:
>> 
>> I booted my computer tonight and the time was off by 2 hours. Then I
>> figured out that ntp is not running. So I installed ntpdate and of course
>> it cannot use any pre-configured time-servers. Are there any time servers
>> that dom0 can use?  Or which documentation would I need to read to give
>> dom0 access to a couple of time servers? Or is ntp problematic enough that
>> dom0 shouldn't use it at all cost?
>> 
>> Niels
>> 
>
> The time should be synced automatically by this cron job (in dom0):
>
> /etc/cron.d/qubes-sync-clock.cron
>
> ...which uses the qvm-sync-clock command.

Ah, good to know. Thanks.

> Check your cron log to see if it's been running:
>
> $ cat /var/log/cron

That file doesn't exist.

Niels

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/871t2szwge.fsf%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] NTP?

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-16 14:06, Niels Kobschätzki wrote:
> 
> I booted my computer tonight and the time was off by 2 hours. Then I
> figured out that ntp is not running. So I installed ntpdate and of course
> it cannot use any pre-configured time-servers. Are there any time servers
> that dom0 can use?  Or which documentation would I need to read to give
> dom0 access to a couple of time servers? Or is ntp problematic enough that
> dom0 shouldn't use it at all cost?
> 
> Niels
> 

The time should be synced automatically by this cron job (in dom0):

/etc/cron.d/qubes-sync-clock.cron

...which uses the qvm-sync-clock command.

Check your cron log to see if it's been running:

$ cat /var/log/cron

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXitymAAoJENtN07w5UDAwwdoP/1+dovvJPZhG2ZeIhZ1vFfYj
8ZgBvFKGA/0HG0EIo9yApTnPFXUaV4K4IxXy/FyjCcii8854zhqIWhH6YuZ0Cr2L
I4ToA/1VgMSYOXdwMxNwvds/i6+4kd8oA7LCRUlktqQq0swtAMNqwle2PDEhf5p8
rGB2gzadh8ckPSrDDi0FR7oxraz+dq1kE27KO/iKfmG0eFMWinVG+ifSl+1Y3qwB
b+qbMZiomR5caHD/I0+ph/WSQC2UAUJvkUkceomjIVHNZVgKMqd+PUMr9jisJjfi
1QbI1beja0nHuv9e0f7KAsgMej8491jPZHZ9RgEK00G/cejd0VC3XFRV53P6F0T+
W0O4J9eP9vbni4bN/Lin8oH4kFQuIXV4kIiLIU7hfSgnBdIeecItU9qxmKzh5dd1
mOXisvW6rVyE1LsIu8ZhvC55QqpEKWlrjQNKnBK/cWodDAfDtwGvVLr30Vj8ARfW
LFMBcwwfp1pW2HZqhIfh80B4xOJUTBP8IAVgTC19goN998XRmFIMiazNeVVkvNf6
OmncECqKpOWeO7SwADmbRPDifU5FPoOfER54y4F+VwaXUT7cZZh174UMMyK18nWV
Dkh7uHNOUSikh3+iIt92ntRzLgHtJmg8N4c2Pu4xQDRS7zvXC0W6uwKQpoO4p7AC
cMo5+8QZbBwHlRP821t+
=SaFk
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2bad8ade-8726-f56a-a25e-4add7dfa4984%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] NTP?

[Niels Kobschätzki]

I booted my computer tonight and the time was off by 2 hours. Then I figured out
that ntp is not running. So I installed ntpdate and of course it cannot use any
pre-configured time-servers. Are there any time servers that dom0 can use?  Or
which documentation would I need to read to give dom0 access to a couple of time
servers?
Or is ntp problematic enough that dom0 shouldn't use it at all cost?

Niels

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8737n9z413.fsf%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.