Custom NTP Configuration UI

[DigitalDJ]

Closes #516, #645, #59

Summary

• There's no web user interface for the custom NTP settings that are implemented in the back-end Go application
• This is a first-cut implementation of a "Custom" Time Synchronization option
• The options are mapped directly to the back-end configuration options
• An effort has been made to validate all fields. i.e. NTP servers must be specified when the ordering includes user-specified NTP servers

Checklist

• [ X ] Ran make test_e2e locally and passed
• [ X ] Linked to issue(s) above by issue number (e.g. Closes #<issue-number>)
• [ X ] One problem per PR (no unrelated changes)
• [ X ] Lints pass; CI green
• [ X ] Tricky parts are commented in code

[adamshiervani]

Thanks for implementing the time sync configuration and also all your other PRs!!

The functionality is solid, but I think the UI needs a remodel. The current design reflects our internal data model rather than what users actually need.

Usually there are two groups with a 95/5 ratio:

1. "Just work" - Automatic time sync, don't care how
2. "Use my servers" - Enterprise/air-gapped environments with specific NTP servers

Proposed Simplification

Two modes: Automatic | Custom

Time Synchronization
└─ [Automatic ▼]

When "Custom":

┌────────────────────────────────────────────────────────┐
│ Your NTP Servers                                       │
│ [ntp.internal.corp.com                     ] [×]       │
│ [+ Add Server]                                         │
│                                                        │
│ Your HTTP URLs (optional)                              │
│ [http://time.internal.corp.com             ] [×]       │
│ [+ Add URL]                                            │
│                                                        │
│ ☑ Fall back to built-in servers if yours fail         │
│ ☐ Also try NTP servers from DHCP (for isolated networks)│
└────────────────────────────────────────────────────────┘

Backend Mapping

UI State	Backend Values
Automatic	time_sync_mode: "ntp_and_http", default ordering
Custom + fallback	mode: "custom", ordering: [user_ntp, user_http, ntp, http], disable_fallback: false
Custom + fallback + DHCP	Same but ordering includes ntp_dhcp after user sources
Custom, no fallback	ordering: [user_ntp, user_http], disable_fallback: true

[DigitalDJ]

Hi there! I agree with your comments, and that's what I thought of doing. I implemented this as a first-pass.... just to basically understand what the model was behind the scenes. At least this gives power-users access to the advanced features.

From here, yeah, I agree. Things like "Disable Fallback" shouldn't be possible with no specified NTP/HTTP URLs.... A lot of the things should be "automatic" unless specified. Then even the "specified" things should only be the servers / URLs. As long as things behind the scenes only hit the servers specified, I think offline users / air-gaped users would be satisfied.

I might get around to simplifying this over the next couple of weeks....but not being a React / TS dev...this makes it a bit of a struggle :P

[IDisposable]

Custom + fallback + DHCP Same but ordering includes ntp_dhcp after user sources

As a network engineer, I would expect DHCP to be honored first