qubes-core-agent-linux remove `Recommends:` `chrony` #1102

adrelanos · Aug 5, 2015

qubes-core-agent-linux Recommends: ntpdate and chrony. What's that good for? VMs are being synchronized by dom0 qubes.SyncNtpClock anyhow. Having ntpdate or chrony running in the VM would only interfere with it.

The simplest solution would just to remove these Recommends:. Can we do this?

This is also useful for Whonix. We don't want ntpdate and chrony installed there. Those only conflict with sdwdate. Those won't work by default because they are using UDP. Those would start working though as soon as the user sets up a VPN or similar capable of tunneling UDP.

On Wed, Aug 05, 2015 at 09:03:50AM -0700, Patrick Schleizer wrote:

qubes-core-agent-linux Recommends: ntpdate and chrony. What's that good for? VMs are being synchronized by dom0 qubes.SyncNtpClock anyhow. Having ntpdate or chrony running in the VM would only interfere with it.

It is required in some VM (selected as "ClockVM"). This applies to
ntpdate (tool called on demand by qubes.SyncNtpClock, not a daemon
process). chrony can (and probably should) be removed.

The simplest solution would just to remove these Recommends:. Can we do this?

This is also useful for Whonix. We don't want ntpdate and chrony installed there. Those only conflict with sdwdate. Those won't work by default because they are using UDP. Those would start working though as soon as the user sets up a VPN or similar capable of tunneling UDP.

Perhaps Whonix should provide its own version of qubes.SyncNtpClock
service, which uses sdwdate. Then the user could point ClockVM to
Whonix-based VM to have it as a time source for the whole system. I
think it was already discussed somewhere.

BTW qvm-sync-clock is rather inaccurate time synchronization tool, so if
you want to prevent having exactly the same time across all the VMs, I
think you can not worry about it. The workflow is:

Synchronize time in selected "ClockVM", by calling qubes.SyncNtpClock
Retrieve time from there, by calling date through qrexec
Set dom0 time to just received value
Iterate over all the VMs and call qubes.SetDateTime the with output of
dom0 date at stdin (new date call for each VM).

Steps 2-3 and 4 have some latency, in normal case it would be about
~50ms, but it depends on system load.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Aug 5, 2015

On Wed, Aug 05, 2015 at 09:03:50AM -0700, Patrick Schleizer wrote:

qubes-core-agent-linux Recommends: ntpdate and chrony. What's that good for? VMs are being synchronized by dom0 qubes.SyncNtpClock anyhow. Having ntpdate or chrony running in the VM would only interfere with it.

It is required in some VM (selected as "ClockVM"). This applies to
ntpdate (tool called on demand by qubes.SyncNtpClock, not a daemon
process). chrony can (and probably should) be removed.

The simplest solution would just to remove these Recommends:. Can we do this?

This is also useful for Whonix. We don't want ntpdate and chrony installed there. Those only conflict with sdwdate. Those won't work by default because they are using UDP. Those would start working though as soon as the user sets up a VPN or similar capable of tunneling UDP.

Perhaps Whonix should provide its own version of qubes.SyncNtpClock
service, which uses sdwdate. Then the user could point ClockVM to
Whonix-based VM to have it as a time source for the whole system. I
think it was already discussed somewhere.

BTW qvm-sync-clock is rather inaccurate time synchronization tool, so if
you want to prevent having exactly the same time across all the VMs, I
think you can not worry about it. The workflow is:

Synchronize time in selected "ClockVM", by calling qubes.SyncNtpClock
Retrieve time from there, by calling date through qrexec
Set dom0 time to just received value
Iterate over all the VMs and call qubes.SetDateTime the with output of
dom0 date at stdin (new date call for each VM).

Steps 2-3 and 4 have some latency, in normal case it would be about
~50ms, but it depends on system load.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Perhaps Whonix should provide its own version of qubes.SyncNtpClock service, which uses sdwdate. Then the user could point ClockVM to Whonix-based VM to have it as a time source for the whole system. I think it was already discussed somewhere.

"directly": not good, explained here: https://phabricator.whonix.org/T387
"indirectly": long term, good idea tracked here: https://phabricator.whonix.org/T387

It [ntpdate] is required in some VM (selected as "ClockVM").

Alright.

But since qubes-core-agent-linux gets installed in Whonix, how does Whonix get rid of ntpdate? apt-file list ntpdate reveals that it comes with quite a few hooks that autostart ntpdate. The cleanest way would be not having the package installed. Another option would be moving these files away in Whonix [using config-package-dev]. Or have the package removed during Whonix's build process. I'll create a whonixcheck test checking for the absence of such packages.

Ideally, Qubes's default ClockVM should come with a package clockvm [only installed in ClockVM] that depends [simpler] or recommends [easier customize] on ntpdate.

adrelanos · Aug 5, 2015

Perhaps Whonix should provide its own version of qubes.SyncNtpClock service, which uses sdwdate. Then the user could point ClockVM to Whonix-based VM to have it as a time source for the whole system. I think it was already discussed somewhere.

"directly": not good, explained here: https://phabricator.whonix.org/T387
"indirectly": long term, good idea tracked here: https://phabricator.whonix.org/T387

It [ntpdate] is required in some VM (selected as "ClockVM").

Alright.

But since qubes-core-agent-linux gets installed in Whonix, how does Whonix get rid of ntpdate? apt-file list ntpdate reveals that it comes with quite a few hooks that autostart ntpdate. The cleanest way would be not having the package installed. Another option would be moving these files away in Whonix [using config-package-dev]. Or have the package removed during Whonix's build process. I'll create a whonixcheck test checking for the absence of such packages.

Ideally, Qubes's default ClockVM should come with a package clockvm [only installed in ClockVM] that depends [simpler] or recommends [easier customize] on ntpdate.

On Wed, Aug 05, 2015 at 09:58:25AM -0700, Patrick Schleizer wrote:

Perhaps Whonix should provide its own version of qubes.SyncNtpClock service, which uses sdwdate. Then the user could point ClockVM to Whonix-based VM to have it as a time source for the whole system. I think it was already discussed somewhere.

"directly": not good, explained here: https://phabricator.whonix.org/T387

"indirectly": long term, good idea tracked here: https://phabricator.whonix.org/T387

It [ntpdate] is required in some VM (selected as "ClockVM").

Alright.

Ok. So maybe just remove ntpdate as part of Whonix template creation?
As it is only in Recommends:, it should just work, right? Maybe even
some bold action like Conflicts: ntpdate in some Whonix package? I'm
not sure how that would behave on Debian...

Ideally, Qubes's default ClockVM should come with a package clockvm [only installed in ClockVM] that depends [simpler] or recommends [easier customize] on ntpdate.

Qubes default ClockVM is based on some template. Since many (most?)
Qubes users uses only single, default template, it should be installed
there. But indeed we could split it into separate package to be easier
to customize. Later we could introduce two packages providing this
functionality: one based on ntpdate, the other based on sdwdate.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Aug 5, 2015

On Wed, Aug 05, 2015 at 09:58:25AM -0700, Patrick Schleizer wrote:

Perhaps Whonix should provide its own version of qubes.SyncNtpClock service, which uses sdwdate. Then the user could point ClockVM to Whonix-based VM to have it as a time source for the whole system. I think it was already discussed somewhere.

"directly": not good, explained here: https://phabricator.whonix.org/T387

"indirectly": long term, good idea tracked here: https://phabricator.whonix.org/T387

It [ntpdate] is required in some VM (selected as "ClockVM").

Alright.

Ok. So maybe just remove ntpdate as part of Whonix template creation?
As it is only in Recommends:, it should just work, right? Maybe even
some bold action like Conflicts: ntpdate in some Whonix package? I'm
not sure how that would behave on Debian...

Ideally, Qubes's default ClockVM should come with a package clockvm [only installed in ClockVM] that depends [simpler] or recommends [easier customize] on ntpdate.

Qubes default ClockVM is based on some template. Since many (most?)
Qubes users uses only single, default template, it should be installed
there. But indeed we could split it into separate package to be easier
to customize. Later we could introduce two packages providing this
functionality: one based on ntpdate, the other based on sdwdate.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

TODO for this ticket: remove chrony from Recommends:
wait for marmarek/qubes-core-agent-linux@master...nrgaway:r3-notifications being merged (nrgaway/qubes-core-agent-linux@00d168b reformatted recommends. Would conflict if I created a pull request now.)

So maybe just remove ntpdate as part of Whonix template creation?

Yes. Where we do that best? In Whonix's code or during Qubes builder? @nrgaway any idea?

Maybe even some bold action like Conflicts: ntpdate in some Whonix package? I'm not sure how that would behave on Debian...

In worst case this breaks the build. Not fun. I guess a whonixcheck test is enough.

Qubes default ClockVM is based on some template. Since many (most?) Qubes users uses only single, default template, it should be installed there. But indeed we could split it into separate package to be easier to customize. Later we could introduce two packages providing this functionality: one based on ntpdate, the other based on sdwdate.

Hm. I see. Sounds like a lot work and extra complexity. And higher disk space. Better keep it as is. At least short term.

adrelanos · Aug 5, 2015

TODO for this ticket: remove chrony from Recommends:
wait for marmarek/qubes-core-agent-linux@master...nrgaway:r3-notifications being merged (nrgaway/qubes-core-agent-linux@00d168b reformatted recommends. Would conflict if I created a pull request now.)

So maybe just remove ntpdate as part of Whonix template creation?

Yes. Where we do that best? In Whonix's code or during Qubes builder? @nrgaway any idea?

Maybe even some bold action like Conflicts: ntpdate in some Whonix package? I'm not sure how that would behave on Debian...

In worst case this breaks the build. Not fun. I guess a whonixcheck test is enough.

Qubes default ClockVM is based on some template. Since many (most?) Qubes users uses only single, default template, it should be installed there. But indeed we could split it into separate package to be easier to customize. Later we could introduce two packages providing this functionality: one based on ntpdate, the other based on sdwdate.

Hm. I see. Sounds like a lot work and extra complexity. And higher disk space. Better keep it as is. At least short term.

On 08/05/2015 01:29 PM, Patrick Schleizer wrote:

TODO for this ticket: remove chrony from Recommends:
wait for marmarek/qubes-core-agent-linux@master...nrgaway:r3-notifications being merged (nrgaway/qubes-core-agent-linux@00d168b reformatted recommends. Would conflict if I created a pull request now.)

So maybe just remove ntpdate as part of Whonix template creation?

I would suggest at this point to either 'a' remove it during whonix
install; I already remove apt-list-changes or whatever its called --or--
install the whonix-gw+minimal template which does not install
recommends; would need to just add the additional packages we want
within template depends --or-- a drop-in to disable it

If you do add some type of check in Whonix to see if chrony is
installed, I prefer you don't make that cause an error; there have been
many hours spent on work-arounds. Maybe yu can add a build option to
attempt auto removal of such packages, or like I said up top, just
include a drop-in since it does not matter if its installed if dropin
prevents it from activating.

Yes. Where we do that best? In Whonix's code or during Qubes builder? @nrgaway any idea?

Maybe even some bold action like Conflicts: ntpdate in some Whonix package? I'm not sure how that would behave on Debian...
In worst case this breaks the build. Not fun. I guess a whonixcheck test is enough.

Qubes default ClockVM is based on some template. Since many (most?) Qubes users uses only single, default template, it should be installed there. But indeed we could split it into separate package to be easier to customize. Later we could introduce two packages providing this functionality: one based on ntpdate, the other based on sdwdate.
Hm. I see. Sounds like a lot work and extra complexity. And higher disk space. Better keep it as is. At least short term.

Reply to this email directly or view it on GitHub:
#1102 (comment)

nrgaway · Aug 5, 2015

On 08/05/2015 01:29 PM, Patrick Schleizer wrote:

TODO for this ticket: remove chrony from Recommends:
wait for marmarek/qubes-core-agent-linux@master...nrgaway:r3-notifications being merged (nrgaway/qubes-core-agent-linux@00d168b reformatted recommends. Would conflict if I created a pull request now.)

So maybe just remove ntpdate as part of Whonix template creation?

I would suggest at this point to either 'a' remove it during whonix
install; I already remove apt-list-changes or whatever its called --or--
install the whonix-gw+minimal template which does not install
recommends; would need to just add the additional packages we want
within template depends --or-- a drop-in to disable it

If you do add some type of check in Whonix to see if chrony is
installed, I prefer you don't make that cause an error; there have been
many hours spent on work-arounds. Maybe yu can add a build option to
attempt auto removal of such packages, or like I said up top, just
include a drop-in since it does not matter if its installed if dropin
prevents it from activating.

Yes. Where we do that best? In Whonix's code or during Qubes builder? @nrgaway any idea?

Maybe even some bold action like Conflicts: ntpdate in some Whonix package? I'm not sure how that would behave on Debian...
In worst case this breaks the build. Not fun. I guess a whonixcheck test is enough.

Qubes default ClockVM is based on some template. Since many (most?) Qubes users uses only single, default template, it should be installed there. But indeed we could split it into separate package to be easier to customize. Later we could introduce two packages providing this functionality: one based on ntpdate, the other based on sdwdate.
Hm. I see. Sounds like a lot work and extra complexity. And higher disk space. Better keep it as is. At least short term.

Reply to this email directly or view it on GitHub:
#1102 (comment)

I would suggest at this point to either 'a' remove it during whonix
install; I already remove apt-list-changes or whatever its called --or--
install the whonix-gw+minimal template which does not install
recommends; would need to just add the additional packages we want
within template depends --or-- a drop-in to disable it

drop-in isn't an option - it will not disable all the hooks introduced
by ntpdate package.

I think the option is to remove it during whonix install ('a'), as
switching to minimal template would be probably much more work (needs to
add back some packages actually used on whonix-gw template).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Aug 5, 2015

I would suggest at this point to either 'a' remove it during whonix
install; I already remove apt-list-changes or whatever its called --or--
install the whonix-gw+minimal template which does not install
recommends; would need to just add the additional packages we want
within template depends --or-- a drop-in to disable it

drop-in isn't an option - it will not disable all the hooks introduced
by ntpdate package.

I think the option is to remove it during whonix install ('a'), as
switching to minimal template would be probably much more work (needs to
add back some packages actually used on whonix-gw template).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

On 08/05/2015 05:30 PM, Marek Marczykowski-Górecki wrote:

I would suggest at this point to either 'a' remove it during whonix
install; I already remove apt-list-changes or whatever its called --or--
install the whonix-gw+minimal template which does not install
recommends; would need to just add the additional packages we want
within template depends --or-- a drop-in to disable it

I agree. Using a minimal template would require keeping recommends in
sync with qubes-agent, which would be a PITA.

drop-in isn't an option - it will not disable all the hooks introduced
by ntpdate package.

I think the option is to remove it during whonix install ('a'), as
switching to minimal template would be probably much more work (needs to
add back some packages actually used on whonix-gw template).

nrgaway · Aug 5, 2015

On 08/05/2015 05:30 PM, Marek Marczykowski-Górecki wrote:

I would suggest at this point to either 'a' remove it during whonix
install; I already remove apt-list-changes or whatever its called --or--
install the whonix-gw+minimal template which does not install
recommends; would need to just add the additional packages we want
within template depends --or-- a drop-in to disable it

I agree. Using a minimal template would require keeping recommends in
sync with qubes-agent, which would be a PITA.

drop-in isn't an option - it will not disable all the hooks introduced
by ntpdate package.

I think the option is to remove it during whonix install ('a'), as
switching to minimal template would be probably much more work (needs to
add back some packages actually used on whonix-gw template).

Yes, remove ntpdate together with apt-listchanges. (FYI: not that apt-listchanges would cause any issues anymore, that was fixed.) But ideally it would be preferable if apt-listchanges would not even get installed. I wonder why does it get installed in the first place?

If you do add some type of check in Whonix to see if chrony is installed, I prefer you don't make that cause an error; there have been many hours spent on work-arounds.

No build error. No advantage by that. But I plan on a whonixcheck error message. Checking against a list for unwanted packages that will be configureable. In case chrony or ntpdate ends up in Whonix, don't work around this. It is a real issue. The only fix is to get rid of it.

Does that sound alright?

adrelanos · Aug 6, 2015

Yes, remove ntpdate together with apt-listchanges. (FYI: not that apt-listchanges would cause any issues anymore, that was fixed.) But ideally it would be preferable if apt-listchanges would not even get installed. I wonder why does it get installed in the first place?

If you do add some type of check in Whonix to see if chrony is installed, I prefer you don't make that cause an error; there have been many hours spent on work-arounds.

No build error. No advantage by that. But I plan on a whonixcheck error message. Checking against a list for unwanted packages that will be configureable. In case chrony or ntpdate ends up in Whonix, don't work around this. It is a real issue. The only fix is to get rid of it.

Does that sound alright?

whonixcheck should test for unwanted packages such as chrony, ntp, ntpdate and other anon-banned-packages:
https://phabricator.whonix.org/T390

adrelanos · Aug 6, 2015

whonixcheck should test for unwanted packages such as chrony, ntp, ntpdate and other anon-banned-packages:
https://phabricator.whonix.org/T390

Something was forgotten. Attached a another pull request:
marmarek/qubes-builder-debian#17

adrelanos · Aug 11, 2015

Something was forgotten. Attached a another pull request:
marmarek/qubes-builder-debian#17

@adrelanos
Just noticed this.
The removal of ntpdate will break any other debian minimal template with no-recommends. For those templates ntpdate should be included in the packages_qubes.list.
Some other solution is needed for whonix.

unman · Aug 23, 2015

@adrelanos
Just noticed this.
The removal of ntpdate will break any other debian minimal template with no-recommends. For those templates ntpdate should be included in the packages_qubes.list.
Some other solution is needed for whonix.

Attached updated pull request that only removes chrony:
marmarek/qubes-builder-debian#18

adrelanos · Aug 26, 2015

Attached updated pull request that only removes chrony:
marmarek/qubes-builder-debian#18

adrelanos changed the title from qubes-core-agent-linux remove `Recommends:` `ntpdate` and `chrony` to qubes-core-agent-linux remove `Recommends:` `chrony` Aug 5, 2015

marmarek added C: core P: minor C: Debian labels Aug 6, 2015

marmarek added this to the Release 3.0 milestone Aug 6, 2015

marmarek closed this in marmarek/old-qubes-core-agent-linux@af03300 Aug 8, 2015

adrelanos referenced this issue in marmarek/qubes-builder-debian Aug 11, 2015
Closed
removed chrony and ntpdate from template_debian/packages_qubes.list #17

adrelanos referenced this issue Aug 11, 2015
Closed
Debian Templates: /usr/bin/qubes-desktop-file-install - ImportError: No module named xdg.DesktopEntry #1113

adrelanos added a commit to adrelanos/qubes-builder-debian that referenced this issue Aug 26, 2015

Removed superfluous/problematic package chrony from template_debian/p…
…ackages_qubes.list. As per QubesOS/qubes-issues#1102.

5b0fdf6

adrelanos referenced this issue in marmarek/qubes-builder-debian Aug 26, 2015
Merged
Removed superfluous/problematic package chrony from template_debian/packages_qubes.list. #18

QubesOS/qubes-issues

Join GitHub today

qubes-core-agent-linux remove `Recommends:` `chrony` #1102

Comments

adrelanos commented Aug 5, 2015

This comment has been minimized.

marmarek commented Aug 5, 2015

This comment has been minimized.

adrelanos commented Aug 5, 2015

This comment has been minimized.

marmarek commented Aug 5, 2015

This comment has been minimized.

adrelanos commented Aug 5, 2015

adrelanos changed the title from qubes-core-agent-linux remove `Recommends:` `ntpdate` and `chrony` to qubes-core-agent-linux remove `Recommends:` `chrony` Aug 5, 2015

This comment has been minimized.

nrgaway commented Aug 5, 2015

This comment has been minimized.

marmarek commented Aug 5, 2015

This comment has been minimized.

nrgaway commented Aug 5, 2015

This comment has been minimized.

adrelanos commented Aug 6, 2015

marmarek added C: core P: minor C: Debian labels Aug 6, 2015

marmarek added this to the Release 3.0 milestone Aug 6, 2015

This comment has been minimized.

adrelanos commented Aug 6, 2015

marmarek closed this in marmarek/old-qubes-core-agent-linux@af03300 Aug 8, 2015

adrelanos added a commit to adrelanos/qubes-builder-debian that referenced this issue Aug 11, 2015

adrelanos referenced this issue in marmarek/qubes-builder-debian Aug 11, 2015

This comment has been minimized.

adrelanos commented Aug 11, 2015

adrelanos referenced this issue Aug 11, 2015

This comment has been minimized.

unman commented Aug 23, 2015

adrelanos added a commit to adrelanos/qubes-builder-debian that referenced this issue Aug 26, 2015

adrelanos referenced this issue in marmarek/qubes-builder-debian Aug 26, 2015

This comment has been minimized.

adrelanos commented Aug 26, 2015

adrelanos added a commit to adrelanos/qubes-template-whonix that referenced this issue Aug 27, 2015

marmarek added a commit to marmarek/old-qubes-core-agent-linux that referenced this issue Sep 29, 2015

marmarek added a commit to marmarek/qubes-builder-debian that referenced this issue Oct 7, 2015

marmarek closed this in `marmarek/old-qubes-core-agent-linux@af03300` Aug 8, 2015