> Would it be acceptable to move ntpdate to the desktop-common seed or something?
Could we just switch everything over to ntp? Is their a downside to this I'm missing? Thanks, Bryan On Wed, Oct 22, 2014 at 9:51 AM, Robie Basak <[email protected]> wrote: > I'd like to seed ntp in both server and cloud-image in Vivid. Servers > should maintain the correct time by default. Please make any objections > now. > > Right now, ntpdate is seeded in minimal. It makes little sense to have > both ntpdate and ntp installed. > > So is there some mechanism I can use to have ntpdate not appear in > server and cloud images? I think we need to move ntpdate out of minimal > for this. Would it be acceptable to move ntpdate to the desktop-common > seed or something? > > To try and confirm that this is sensible for all use cases, here's a > brainstromed list. It seems to me that the only downside is a little > extra used space in the LXC case. > > * "Traditional" bare metal server installation from server ISO > > It makes sense to be running ntp here. > > * MAAS-deployed server using d-i > > It makes sense to be running ntp here. Additionally, MAAS can choose to > configure the system to point at a MAAS-managed NTP server. > > * MAAS-deployed server using curtin > > It makes sense to be running ntp here. Additionally, MAAS can choose to > configure the system to point at a MAAS-managed NTP server. > > * Hand (or other tool) -deployed VM using a cloud image > > It makes sense to be running ntp here[3]. > > * Hand (or other tool) -deployed VM using d-i or a debootstrapped image > > It makes sense to be running ntp here[3]. > > * Juju-deployed VM using a cloud image > > It makes sense to be running ntp here[3]. There may be some interference > with existing charms. When these charms are updated to Vivid (or to X), > then they can start assuming that ntp is already available. A > hypothetical "ntp" subordinate charm could be used in cases where some > other NTP server should be used and the deployer wants to manage it more > directly via a relation; in this case, the subordinate charm could just > rewrite /etc/ntp.conf to change the default accordingtly. > > * Hand (or other tool) -deployed LXC using a cloud image > > It probably doesn't make sense to run ntp here. We could amend the ntp > init script to skip startup when in a container by default. > > * Hand (or other tool) -deployed LXC using a debootstrapped image > > It probably doesn't make sense to run ntp here. We could amend the ntp > init script to skip startup when in a container by default. > > * Juju-deployed LXC using a cloud image > > It probably doesn't make sense to run ntp here. We could amend the ntp > init script to skip startup when in a container by default. > > Are there any use cases I've missed here? > > Previous discussions: > > [1] https://lists.ubuntu.com/archives/ubuntu-server/2013-April/006556.html > [2] https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037874.html > [3] > https://help.ubuntu.com/community/KVM/FAQ#Should_NTP_be_used_for_time_synchronisation.3F > > -- > ubuntu-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
