This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 136725 - Overcomplex NTP configuration
Overcomplex NTP configuration
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-21 18:09 EDT by Owen Taylor
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-12 08:24:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Owen Taylor 2004-10-21 18:09:35 EDT
[ This actually is most important for the firstboot screen,
   but I think that shares the code with s-c-d ]

NTP configuration in system-config-date has been made 
unusably complex.

 - There are multiple checkboxes that didn't make sense
   to *me* (and I've read the ntpd documentation in the
   distant past)

   "Use Local Time Source"
   "Enable NTP Broadcast"

    In firstboot, there isn't even a help page to help
    the user out! (And the help page hasn't been updated
    anyways, so wouldn't help.)

 - The server configuration has been changed to allow
   multiple servers with a confusing Add/Delete combined
   with a dropdown.

   If you have to do add-delete from a list, it should
   look like the keyboard layouts in 
   gnome-keyboard-properties, but I don't think the
   advantages of configuring multiple servers come
   even remotely close to being worth this complexity.

In FC2,there was a checkbox to enable
NTP, and there was a dropdown to select the server, with
a default that was obviously correct to leave as was.

If we need a GUI for configuring the public NTP server with 
multiple upstream sources at all, it *CANNOT* be something 
the user is forcedto deal with at firstboot.
Comment 1 Nils Philippsen 2004-10-22 03:48:08 EDT
[ ACK, the code is from s-c-date ]

NTP configuration _is_ overly complex ;-).

- "Use Local Time Source": this is if you have a locally attached
authoritative time source (a "reference clock" in NTP documentation
jargon), like an RF time receiver, and you want to use that. It puts
"server 127.127.1.0" into ntp.conf

- "Enable NTP broadcast": Broadcast for an NTP server on the local
subnet(s), puts "broadcastclient" into ntp.conf

I agree that these options warrant tooltips/help/some mor guidance for
the user not knowing about NTP. I could also hide these behind some
"Show advanced options" though you probably don't want that as well
;-). The problem is that when we disallow access to these options
completely, people start to ask questions why it's in s-c-date and not
in firstboot.

Regarding multiple servers and how they're configured: Trust me, the
code is less complex (and buggy, hopefully) than it was when you could
only configure one and it had to deal with e.g. admins configuring
multiple servers manually in ntp.conf. Doing it like in
gnome-keyboard-properties isn't quite feasible because the user needs
to be able to add his local NTP server to the list. Having an extra
entry line to add these would be even more complex than what we have
now. If youhave an idea how to do this differently without losing
functionality, I'd like to know. Perhaps putting the first entry into
the list when the user enables NTP would be a starter?

Comment 2 Owen Taylor 2004-10-22 10:18:47 EDT
If NTP configuration really was overly complex, it wouldn't belong
in firstboot. But the reason it does belong there is:

 - Simple configurations work for most users. If I recall correctly,
   XP enables it by default pointed to a MS server. I've been
   told that OS X, it's off by default by default but one click
   to configure.

 - It really is a big win for the user.

But you are saying that "NTP configuration is complex" because:

 - Users might have a locally attached authoritative time
   source. (0.1%, 0.01%?)

 - The user might have a NTP broadcasting server on the network
   (if they have a sysadmin to set that up, they probably
   have a sysadmin to kickstart their box...)

 - The user might want to set up multiple upstream servers
   (for better robustness? to improve accuracy by a couple
   of milliseconds)

I'm not happy about having this complexity in s-c-d, but it
basically doesn't hurt a lot, because the user running s-c-d
says "I care about my date/time". But in firstboot the user
basically is being asked to figure out what a authoritative
time source is before they can log into their shiny new
OS the first time.

I don't see any reason to worry about questions people ask 
why things are in s-c-date and not in firstboot. The answer
is simple:

 "The purpose of firstboot is to set up a machine to be
  usable; putting every possible option in it isn't possible"
Comment 3 Owen Taylor 2004-10-22 10:31:21 EDT
About the multiple servers questions - generally we've found that

 [ Controls configuring item ] + [ list of items ] + Add

is a confusing combination of controls. What we've traditionally
done in GNOME is to have Add fire up a separate dialog. 

Really, probably the best way forward here for FC4 to RHEL5 is to
work with the UI folks to come up with designs for the firstboot
and s-c-d.
Comment 4 Nils Philippsen 2004-10-22 10:49:19 EDT
Hmm, what about:

Don't show these options in firstboot or hide them behind "Show
more/advanced/complex configuration options". Should be doable and the
backend code is ready for this, as if it is already configured, it
leaves the option in place. If the corresponding UI widget is hidden,
it should still leave an option set in place.

I'm a bit confused about "What we've traditionally done in GNOME is to
have Add fire up a separate dialog" -- how does that fit within your
former example of gnome-keyboard-properties, i.e.:


Selected options:             Available options:
Option 1              Add     Option 3
Option 2              Remove
Option 4

(I've left out Up and Down buttons, I don't think they're needed in
the context of NTP).

One idea would be to have a New button which inserts a new line in
"Selected Options", similar to adding a new folder in Nautilus or the
new file selector. What do you think?
Comment 5 Nils Philippsen 2004-10-25 11:16:03 EDT
I've added tooltips for the options in CVS so users have at least an
idea what they mean: BTW I'm still waiting on feedback on hiding the
more esoteric options as well as the redesign of the NTP server
list/interface.
Comment 6 Owen Taylor 2004-10-25 15:59:55 EDT
My tendency for firstboot would not be to show them at all.
Though the multiple server bit is likely harder to deal with that
way. What I'd probably do for that would be to allow only a single
server in firstboot, unless the ntp.conf *already* has multiple
servers in it. (Which is a weird edge case.)

I was making an alternate suggestion for the server selection
based on the feedback that the keyboard-properties style didn't
work. For infrenquently used controls (and how often do people
configure ntp?) clarity is a lot more important than speed.
So, that's basically why I'm suggesting the separate-dialog 
style. There is no ambiguity in how you interact with it - 
it's immediately obvious. 
Comment 7 Nils Philippsen 2005-08-12 06:04:49 EDT
Owen and Seth, please take a look at current system-config-date (1.7.99.0).
While this doesn't address your problem with multiple NTP servers, I think the
interface is more in line with what we have elsewhere, i.e. instead of text
entry -> add button -> list gets extended we have only the add button which
doesn't pop up dialog but inserts a new entry labeled "New NTP server" which
gets selected to be subsequently edited by the user (very much like the file
chooser or nautilus IMO).

Please let me know what you think.
Comment 8 Nils Philippsen 2005-10-12 08:24:06 EDT
No answer is still an answer ;-). Closing due to inactivity.

Note You need to log in before you can comment on or make changes to this bug.