Ticket #12085 (new defect)

Opened 2 years ago

Last modified 2 years ago

Time/date sync on unsecured laptops

Reported by: cscott Owned by: cscott
Priority: normal Milestone: Future Release
Component: distro Version: not specified
Keywords: Cc: martin.langhoff
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description

In bug 3359, we added code to have laptops sync with ntpdate when they connected to the internet. That code has regressed at some time since then; currently Sugar users have no way to set the time and date on their machines without resorting to a root commandline.

There is a separate bug for adding date/time setting to the Sugar control panel. This bug is just for restoring the automatic date-setting-via-ntp so that connected users need not worry about having the correct time.

http://dev.laptop.org/git/users/cscott/pilgrim/commit/?id=068d1f5eae1fbf5d15635f8f8b81a5b5bc611ff8 is the patch which originally fixed bug 3359. I believe this NetworkManager dispatcher.d script would still work, although some deployments wish to suppress automatic time/date settings on unsecured laptop. Another line could be added to the script looking at manufacturing tags to implement this restriction. The ntpdate package also needs to be re-added to the builds. We also probably need to add a line to sync the hardware clock (using hwclock) after ntpdate runs, if ntpdate itself has not already been patched to do so (see http://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html). (jnettlet suggests using this systemd service: http://fpaste.org/hnvN/ )

The original script tried to sync with 'time', which was a local DNS address advertised by the schoolserver before falling back to the fedora pool. Two changes are possible here: 1) does the schoolserver still advertise 'time'? 2) we could use olpc.pool.ntp.org instead of using fedora's pool.

Cerlyn suggests using Chrony instead of ntp: https://fedoraproject.org/wiki/Features/ChronyDefaultNTP

Change History

Changed 2 years ago by dsd

  • owner changed from pbrobinson to cscott

Thanks for bringing this up. Indeed, this was dropped earlier due to concerns about the security system. It could certainly go back when turned off by default and/or only affecting unsecured laptops.

But if you're proposing this for 13.1.0 it needs someone to do the work - I think you are the most likely candidate for this (it won't be me or Peter). Looks like the tasks you mention are:

# Figure out ntpdate vs hwclock situation, update script accordingly # Update script for not running by default and/or not running on secured laptops # Check XS setup for 'time' hostname availability # Check olpc.pool.ntp.org # Test the new script

If you post a script here as above, I can put it in olpc-utils and add the ntpdate package back to the build.

I think Chrony is not interesting since the proposal is to add ntpdate, not ntp (right?), and chrony doesn't seem to provide a ntpdate equivalent.

Changed 2 years ago by greenfeld

Chrony does not provide an ntpdate equivalent because chrony really doesn't care. It was designed for use with intermittent/dialup links.

How it interacts with aggressive suspend would have to be determined.

You can ask Chrony to "burst" if you want via chronyc to force a synchronization cycle. Also see http://chrony.tuxfamily.org/manual.html#Advising-chronyd-of-internet-availability , which lets us tell Chrony Ad-hoc networks have no NTP servers.

Ntpdate is depreciated as equivalent functionality is now provided in other utilities within the core ntp suite (http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate), and ntpd does not require another utility to presync the clock anymore. Ntpdate is available for F18 though, and may make a reasonable choice for a near-term fix.

Changed 2 years ago by martin.langhoff

  • cc martin.langhoff added

Surprise! ntpdate has a param to DTRT. See https://bugzilla.redhat.com/show_bug.cgi?id=816752 - SYNC_HWCLOCK in /etc/sysconfig/ntpdate

Changed 2 years ago by dsd

  • milestone changed from 13.1.0 to Future Release
Note: See TracTickets for help on using tickets.