Preseedable Network Time Synchronization Support Needed in Debian-Installer

Bug #184101 reported by Matt T. Proud
8
Affects Status Importance Assigned to Milestone
rdate (Ubuntu)
Invalid
Wishlist
Matt T. Proud

Bug Description

Binary package hint: rdate

Hi,

I have a compelling use case that requires automated time synchronization support in the Debian-Installer for the initial part of an install. This is mainly due to having remote hardware that can lose its internal clock values and having other installer services depend upon the to-be-installed machine's clock being within a reasonable ballpark of one another. This is markedly different from having the clocks being synchronized after the installation has occurred and the normal machine is up and running.

Instead of taking a messy approach of writing in support in an early or late command, I have written a patch that adds this support to Debian-Installer.

Attached to this bug is a debdiff patch to the rdate source package that adds preseedable time synchronization support to the Debian-Installer.

If rdate-udeb is included in the Debian-Installer initrd, not a requirement for this patch's inclusion, it will create a menu item shortly after the network has been configured and ask for some basic rdate time synchronization information. Optionally, if no timezone data exists during the install, it will provide a means of fetching skeletal tzinfo data from a remote host. Conceivably this can be some sort of an intelligent http dispatch agent that determines the proper tzinfo by means of mac or ip address or any other means. The debconf question priorities are medium to low, so little interference is to be expected; and again, this will only affect installers that have explicitly included the rdate-udeb in Debian-Installer, which means only people who have explicitly rebuilt Debian-Installer.

This is probably most useful to systems administrators and engineers who are engaging in mass- and remote-deployment applications of Ubuntu server and workstation.

I have tested this out with the latest Debian-Installer, and everything appears to work as expected. I plan on submitting this upstream into Debian within the next few weeks. Since the code freeze for the Hardy Heron release is fast I approaching, I am submitting this patch to Ubuntu first in hopes that it can be ushered in very quickly. I will be working with my friends involved with Debian project to get this included in the near future to keep the amount of delta between the two projects low.

I have even included internationalization support in the new things that I have added.

Let me know if you have any questions. Let's do what we can to get this incorporated relatively quickly.

Cheers,

Matt

Revision history for this message
Matt T. Proud (matttproud-google) wrote :
Revision history for this message
Daniel Hahler (blueyed) wrote :

Thank you for your contribution.
Please change your debdiff to match the https://wiki.ubuntu.com/DebianMaintainerField spec. You can just run "update-maintainer" in the source directory and then rebuild the source package.

Changed in rdate:
assignee: nobody → matttproud-google
importance: Undecided → Wishlist
status: New → In Progress
Revision history for this message
Matt T. Proud (matttproud-google) wrote :

Daniel,

Thanks for your prompt response to this bug. Attached is an updated debdiff.

I made the following changes to the patch in addition to the ones you've asked for:

The rdate-udeb already had support for SNTP (RFC 2030) synchronization in addition to Time (RFC 868), so I added
the ability to choose which synchronization protocol to use in debconf.

The patch is internationalized and has been localized for en_US.

Also, is there anything else that I can do to help expedite this patch's incorporation into Hardy?

Thanks,

Matt

Revision history for this message
Colin Watson (cjwatson) wrote :

I think this is the wrong place to do this. rdate-udeb exists to be used by clock-setup, which already has a menu item, deals with running rdate, etc. Shouldn't clock-setup be the place for these changes instead?

Revision history for this message
Matt T. Proud (matttproud-google) wrote :

Nice! I'm glad to know that clock-setup takes care of this. From looking at debian-installer, it appears that clock-setup is not included by default; no wonder I didn't think of it. ;-)

I'm curious: clock-setup's post-installation script starts at 2600. This seems a little late. Would there be an easy way to start this automatically, say before the early_command is run? Sure---running the synchronization could be put in the early_command, but that might be a little messy.

The postinst script appears to be sufficient, so we can close this bug.

Thanks for the help.

Revision history for this message
Colin Watson (cjwatson) wrote :

clock-setup is definitely included by default; it's just not in the initrd. (Note that it is Priority: standard, which is one of the other ways to get included by default.)

It could probably be brought back to 1800, but it's worth bearing in mind that that would break preseed files that set clock-setup/utc; that would have to be done on the kernel command line instead. This is not necessarily a showstopper.

Could you elaborate on your use case? Does HTTP access from your installing machines depend on a sane clock? I wouldn't ordinarily have expected it to do so - in the absence of things like If-Modified-Since, which surely aren't relevant here, basic HTTP shouldn't depend on time synchronisation. However, I might be missing something.

Are there any of your changes from your proposed rdate-udeb that are still needed in clock-setup?

Revision history for this message
Liam Bedford (lbedford-deactivatedaccount) wrote :

My version of the use case is that gpgv fails if the time is incorrect (by enough).

So when debian-installer comes to use apt-get fully and authenticating the Release file,
it fails.

Revision history for this message
Cesare Tirabassi (norsetto) wrote :

Unsubscribing u-u-s since it seems there is nothing required from them.

Revision history for this message
Matt T. Proud (matttproud-google) wrote :

Closing since clock-setup mediates this functionality.

Changed in rdate:
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.