Ah yes silly me, that server doesn’t have IPv6! That worked!
Alright first one is up and running, I’ll get a few more up here shortly now that is sorted out.
1 Like
How can I modify a test monitor? (Alternatively, delete it and readd with different parameters.)
I have the test monitor frlys1-355n9ds, but the airport name should be rather GVA, to get something like frgva1-355n9ds. (In fact, the distance of the GVA airport is about 2 km from my monitor.)
What will cause a test ntppool-agent to stay in status testing? It has been like that for a day, unlike the other one that changed to status active pretty quickly.
1 Like
@ask do you have an idea why or how i can debug it?
1 Like
Hi John!
Thanks for adding it. It stayed in testing because currently Andreas or I have to toggle the status manually!
The intention was to have a way to “review” a monitor before it gets important; but … I don’t if it makes sense anymore.
In the old system this was more necessary, and I got burned by adding monitors from someone unfamiliar who then went on to write a research paper about how the pool could be manipulated. 
So – the new system has a bunch of automated controls to make it harder for someone to meaningfully manipulate the system; and one of the mechanisms is to have lots of monitors and for the system to slowly phase new monitors in as it makes sense.
I’m happy to hear questions and suggestions around this; but I think I’ll change it so new monitors automatically are “active”.
Sometimes having a human in the loop is not a bad thing. 
I was just wondering if it was something I did or did not do. For this one I build a local FreeBSD port / package and installed that. (The port does not compile it from source. It uses your binary tar files and create a ntpmon user and install a rc.d startup script.)
2 Likes
I tend to agree in general, especially given the somewhat sensitive role that the monitors play. I just fear a bit that when there aren’t enough resources available to actually deal with that, and proactively accept (or reject) new monitors, this might become a similarly stagnant area of the project as the full processing of vendor zones as per vendor needs (i.e., get a zone established in the first place, and including IPv6-enabled subzones while IPv6 isn’t available in the default zones), or reported errors in detected server geolocation not being processed.
And automation, not only in the form of AI/ML, helps free human resources to do something more worthwhile, e.g., progress actual pool functionality, vs. burning resources on low-level administrative chores.
2 Likes
My plan is to have monitors automatically migrate from testing to active after they’ve been running for a week or maybe two. (They’ll need some time to go into “testing state” on a number of servers anyway).
4 Likes
I just upgraded the test monitors, and I got this as version string:
v4.0.0-beta.7-538/9aa4d39 (2025-08-02T17:33:52Z, go1.24.5)
The date inside the version string looks a bit weird (it is in the future), as the time of writing this message is 2025-08-01T06:30Z.
May be some time synchronization configuration is missing from the build environment?
Yeah, I was preparing a release to production this weekend (still debating with myself if it’s time) and the build system was making up a date based on made up git information. I fixed it so it’ll be the actual time it was built on the build server.
2 Likes
@ask Is there a reason that one cannot run a production and test ntppool-agent simultaneously on the same host? I see that the test agent uses ~user/.config/ntppool-agent/test/ to store its configuration and certificates, so I assume the production one will use ~user/.config/ntppool-agent/production/. So if I make a second FreeBSD ntppool-agent port adding a -devel suffix that install the binary and startup script also with a -devel suffix, they should be able to live simultaneously on the same host? Or will it cause confusion on the other side?
The slug for the production variant is “prod”.
I believe that is possible. At least as in “two instances of the same binary running simultaneously but connecting to different back ends”.
What I have started to wonder about: How to run different types of binaries at the same time, when both the package names and the binary names/paths are identical for both the “test” and “prod” variants of the service, and the differentiation is made only via the env parameter passed to the binary, as selected via the systemd templating system?
I.e., in a way, something like what @john1 contemplates for his FreeBSD port might be needed also for the different types of Linux systems, i.e., different names and/or paths for both the packages and the binaries.
Why chrony is a dependency for the ntppool-agent package?
Loaded plugins: fastestmirror
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check
---> Package ntppool-agent.x86_64 0:4.0.1-1 will be installed
--> Processing Dependency: chrony for package: ntppool-agent-4.0.1-1.x86_64
--> Running transaction check
---> Package chrony.x86_64 0:3.4-1.el7 will be installed
--> Processing Dependency: libseccomp.so.2()(64bit) for package: chrony-3.4-1.el7.x86_64
--> Running transaction check
---> Package libseccomp.x86_64 0:2.3.1-4.el7 will be installed
--> Finished Dependency Resolution
I am running classic ntpd, and I do not like additional packages brought in that way.
I guess it’s related to this issue for rpm packages.
For deb packages, ntpd classic and others are accepted as well.
That must be it. The package name for the classic ntpd is ntp on these fedora (rpm) flavor systems, at least on CentOS.
EDIT: By the way why do you need any of these packages? If it is for the local time accuracy, there are other services, like sntp, systemd-timesyncd.
Just a thought but maybe those are keeping the clock better sync and compensate the drift more finer.
1 Like
Sure. But I can have my own time synchronization daemon that is listed nowhere.
Sure, but how is it ensured then that it meets the quality criteria? Not to say it doesn’t, but how to prove that? For the listed implementations, I think it is commonly agreed they meet the criteria.
I guess that would be the responsibility of the ntppool-agent to regularly crosscheck the required local time quality with some external references. Even let’s say the package chrony is installed, it is not guaranteed that it is running or providing proper time synchronization.