Running ntppool-agent on the same host as my pool server - conflict?

Monitoring Operators
1

I’m considering running the ntppool-agent monitor on the same host as my pool server (smolnut - stratum 1 GPS PPS). Before I do, I wanted to check whether this causes any issues.

My concern: if the monitor probes pool servers and my own server’s IP is in the rotation, it would be probing itself over the local network rather than from a real external perspective, potentially reporting artificially good results.

Does the monitoring system automatically exclude a monitor from probing servers registered to the same IP? Or is it better to run the monitor on a separate host?

2

The monitor does not monitor servers of the same account as itself.

3

Yes, in addition to what @ebahapo wrote. At least as long as the NTP server has the same IP address as the one registered for the monitor. (Unlike an NTP server which is no longer reachable via the pool if its IP address changes from what is registered, a monitor will keep working fine even if the actual IP address changes from the one at registration time.)

Servers are always probed, regardless of whether they are in the rotation or not. Even servers in monitoring-only mode, or scheduled for upcoming deletion get probed.

4

Thanks both! That’s exactly what I needed to know. Going to run the monitor on smolnut alongside my pool server. I’m ready to install. When I try to access builds.ntppool.dev/repo/ I get an S3 AccessDenied error. Do I need to be approved before I can access the repository? If so, how do I request access?

5

No, this is a general issue that @ask needs to look into.

6

I guess I’ll have to wait for @ask to fix it - thank you for letting me know!

7

Would running a Docker container be an option for you?

The thread suggests that might not go entirely without a hitch (file permissions are a pain), but maybe with support from someone who has successfully run a monitor off that container, it is doable.

E.g., I think it would be useful to mount a directory from the host in the container, or otherwise ensure the credentials generated during registration survive destruction of the container, e.g., when upgrading the container, or switching to the native implementation once it is accessible again.

Maybe relevant to note: Running a monitor is currently reserved for accounts with a least one server verified at least 18 months ago. This is because of the prominent and somewhat critical role the monitors play in the system. It allows a prospective monitor host to gain a certain level of experience running a stable NTP service before running a monitor.

8

Thanks for the heads up! I didn’t realize there was an 18 month requirement - looks like I have a while to wait anyway. I’ll revisit this once I’m eligible at September 2027. Appreciate the help!