freeipa-client hard depends on chrony

[hboetes]

That freeipa-client needs accurate time to work is obvious. But there are various ways to go about this:
1) install a timeserver like chrony or ntp
2) Not at all, because the system is an lxc client and thus the time is synced externally.

Currently chrony is installed, and another package requires ntp. Furthermore puppet is running on the host and installs chrony on one run and in the next run ntp etc etc. And that on a host which requires neither.

There are many ways to solve this problem with various levels of being accurate. Please think the problem through in such a way that all possible scenarios are covered.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: chrony 3.2-4ubuntu4.1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Wed Jun 27 14:40:03 2018
SourcePackage: chrony
UpgradeStatus: No upgrade log present (probably fresh install)

[Christian Ehrhardt  (paelzer)]

I agree that in a world of systemd-timesyncd by default packages could stop depending on time-servers in most of the cases. But that is not a bug in chrony but in freeipa.

Also it is not clear yet why your puppet would install one and then the other, I'd ask you to file an extra bug with a bit more details about that aspect.

[Christian Ehrhardt  (paelzer)]

Currently we have these:
Reverse-Recommends
==================
* ceph-base (for chrony)

This is the same case as with Freeipa.

* radioclk (for chrony)

This is meant to provide DCF77 input to chrony, so ok

Reverse-Depends
===============
* freeipa-client (for chrony)
* freeipa-server (for chrony)

This is how this bug was reported.
I think it is a common and working resolution to depend on the current timeserver.
I'd vote for the Depends becoming recommends so that admins can remove the package if wanted.

* gce-compute-image-packages (for chrony)

That is an intentional "there you should sync with that" AFAIK. keeping as-is IMHO

* maas-rack-controller (for chrony)
* maas-region-api (for chrony)

I know for MAAS that they really want this, even on a Container, so considering them ok'ish.
They even modify chrony.conf and such, so there a depends is correct.

In general I think the Ceph approach is good, keeping it as a recommends allows to remove it if needed. BTW Chrony on Containers will by default only serve the local time as syncing it would not work (CAP_SYS_TIME) anyway - so not much lost.

systemd-timesyncd is "only" SNTP which has to be considered inferior to full ntp syncing.

For Ceph and Freeipa once being a recommends, I'd wish there would be a dependency that says "but not in containers", but there is none.

[hboetes (hboetes)]

I need a time daemon with server capabilities so we can easily monitor clock skew.

Setting the dependency as recommends sounds like a great solution indeed. Thanks for taking it into consideration.

[J0J0 (joj0)]

Hi,
we are using ntp as a standard service, and it's deployed and configured by puppet. So using chrony instead of ntp client is not really an option.

I just wanted to mention a dirty but possible quickfix to get around this bug:

apt install freeipa-client # let it correctly solve all dependencies and uninstall ntp for now
dpkg --ignore-depends=freeipa-client -r chrony
vi /var/lib/dpkg/status # remove chrony from dependencies list of freeipa-client package
apt install ntp

As you probably can imagine this should only be a temporary solution. Therefore we already repackaged the freeipa-client package, removed the chrony dependency and put it in our local Ubuntu mirror.

I also think changing the chrony dependency to be a "recommends" instead of a "depends" is an essential change to the package.

Unfortunately I am not really aware of how the voting and contribution to changes in Ubuntu packaging works. Please point me in the right direction!

Thanks a lot and all the best!
Jojo

[Robie Basak (racb)]

Looks like this was fixed in 4.7.1-1 in Debian, so this is fixed >= Cosmic in Ubuntu.

If you need a fix for an existing stable release, please comment with a justification against https://wiki.ubuntu.com/StableReleaseUpdates#When and complete steps 1 through 4 in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure - and go ahead with all the steps if you can. Note that that SRU team would need to make a final decision.