Alex Howells
5cd265ae52
* feat(network): add custom NTP/HTTP time sync configuration UI Closes #516, #645, #59 The backend supports custom NTP servers, HTTP URLs, source ordering, parallel queries, and fallback control for time synchronization, but the frontend only exposes three presets (NTP only, NTP and HTTP, HTTP only). Users who need to specify their own NTP server — the core ask in all three linked issues — have no way to do so through the UI. Add a "Custom" option to the time sync dropdown. When selected, a card appears with input fields for NTP servers and HTTP URLs, following the same list-with-add/remove pattern used by the static IPv4 DNS fields. This is a simplified alternative to #1102 which exposed every backend field (source ordering, parallel queries, disable fallback) as direct UI controls. That PR stalled for 3 months due to complexity concerns and UX debate. This PR ships the functionality users actually requested — custom NTP servers — with a minimal UI surface: #1102: 753 additions, 15 files, new Combobox modifications This: ~120 additions, 18 files (13 are localization) The advanced fields (TimeSyncOrdering, TimeSyncParallel, TimeSyncDisableFallback) retain their backend defaults and can be surfaced in a follow-up if there is demand. Backend changes: confparser.go — add hostname_or_ipv4_or_ipv6 validation type so NTP server fields accept hostnames like pool.ntp.org, not just raw IPs. config.go — change TimeSyncNTPServers validation from ipv4_or_ipv6 to hostname_or_ipv4_or_ipv6. Frontend changes: CustomTimeSyncCard.tsx — new component with NTP server list and HTTP URL list, field validation, add/remove controls. stores.ts — add optional time_sync_ordering, time_sync_ntp_servers, time_sync_http_urls, time_sync_disable_fallback, time_sync_parallel to NetworkSettings interface. network settings page — uncomment Custom option, render card when time_sync_mode is custom. Translations added for all 13 supported languages. * fix(timesync): address review feedback on custom NTP UI 1. filterNTPServers: pass hostnames through instead of dropping them. net.ParseIP() returns nil for hostnames like pool.ntp.org, causing them to be silently skipped. The NTP library handles DNS resolution itself, so hostnames are valid entries. 2. getSyncMode: when TimeSyncMode is "custom", default the ordering to [ntp_user_provided, http_user_provided, ntp_dhcp, ntp, http] so user-provided servers are actually queried. The previous hardcoded default never included *_user_provided entries, rendering custom servers unreachable. 3. Stale config pointer: add SetNetworkConfig() on TimeSync and call it from rpcSetNetworkSettings after config.NetworkConfig is replaced. Without this, TimeSync holds a stale pointer and ignores runtime config changes until restart. 4. DNS vacuous truth: guard .every() calls on ipv4/ipv6 DNS dirty arrays with .length > 0 checks. [].every() returns true in JS, causing empty DNS arrays to falsely appear in the confirmation dialog. Signed-off-by: Alex Howells <alex@howells.me> * fix(timesync): ensure custom mode uses user-provided servers and re-syncs on settings change Move TimeSyncOrdering override before the mode switch so "custom" mode always sets the correct ordering with ntp_user_provided first, preventing stale ordering values from overriding it. Trigger an immediate time sync when network settings are saved so users don't have to wait for the hourly cycle or reboot. --------- Signed-off-by: Alex Howells <alex@howells.me> Co-authored-by: Adam Shiervani <adam@jetkvm.com>
JetKVM is a high-performance, open-source KVM over IP (Keyboard, Video, Mouse) solution designed for efficient remote management of computers, servers, and workstations. Whether you're dealing with boot failures, installing a new operating system, adjusting BIOS settings, or simply taking control of a machine from afar, JetKVM provides the tools to get it done effectively.
Features
- Ultra-low Latency - 1080p@60FPS video with 30-60ms latency using H.264 encoding. Smooth mouse and keyboard interaction for responsive remote control.
- Free & Optional Remote Access - Remote management via JetKVM Cloud using WebRTC.
- Optional Tailscale Networking - Built-in Tailscale status and control-server configuration, including custom Headscale-compatible endpoints.
- Open-source software - Written in Golang on Linux. Easily customizable through SSH access to the JetKVM device.
Contributing
We welcome contributions from the community! Whether it's improving the firmware, adding new features, or enhancing documentation, your input is valuable. We also have some rules and taboos here, so please read this page and our Code of Conduct carefully.
I need help
The best place to search for answers is our Documentation. If you can't find the answer there, check our Discord Server.
I want to report an issue
If you've found an issue and want to report it, please check our Issues page. Make sure the description contains information about the firmware version you're using, your platform, and a clear explanation of the steps to reproduce the issue.
Development
JetKVM is written in Go & TypeScript. with some bits and pieces written in C. An intermediate level of Go & TypeScript knowledge is recommended for comfortable programming.
The project contains two main parts, the backend software that runs on the KVM device and the frontend software that is served by the KVM device, and also the cloud.
For comprehensive development information, including setup, testing, debugging, and contribution guidelines, see DEVELOPMENT.md.
For quick device development, use the ./dev_deploy.sh script. It will build the frontend and backend and deploy them to the local KVM device. Run ./dev_deploy.sh --help for more information.
Backend
The backend is written in Go and is responsible for the KVM device management, the cloud API and the cloud web.
Frontend
The frontend is written in React and TypeScript and is served by the KVM device. It has three build targets: device, development and production. Development is used for development of the cloud version on your local machine, device is used for building the frontend for the KVM device and production is used for building the frontend for the cloud.