Description of problem: It seems that, because rdate uses the old Time Protocol [0], the check in pyanaconda/ntp.py with retc = os.system("rdate -p %s &>/dev/null" % server) always fails for the preset fedora NTP servers (as they apparently don't support the old protocol). As a result, they all show up as not working in the list, and anaconda shows the warning at the bottom of the spoke. [0] http://en.wikipedia.org/wiki/Rdate Version-Release number of selected component (if applicable): 19.16-1
(In reply to comment #0) > Description of problem: > It seems that, because rdate uses the old Time Protocol [0], the check in > pyanaconda/ntp.py with > > retc = os.system("rdate -p %s &>/dev/null" % server) > > always fails for the preset fedora NTP servers (as they apparently don't > support the old protocol). As a result, they all show up as not working in > the list, and anaconda shows the warning at the bottom of the spoke. > > [0] http://en.wikipedia.org/wiki/Rdate > > Version-Release number of selected component (if applicable): > 19.16-1 It's not true that it *always* fails. But I will for sure have a look at this. Thanks for the report and additional information.
*** Bug 960716 has been marked as a duplicate of this bug. ***
FWIW, I just came across this too (dan408 pointed it out). Volker is right, rdate is definitely the wrong thing to use here. It is a utility for the very old 'Time Protocol' format - RFC 868 - which predated NTP. We're talking early 1980s here. It seems that many NTP servers used to take the trouble to be compatible with the old protocol, so this check 'worked', even though it's never been correct. But these days, they're not bothering to do so any more, so rdate fails on many working NTP servers. As per my dupe bug I'm not sure what to suggest instead of rdate, but rdate is *clearly* the wrong thing to be using.
[root@adam rdate (master)]# ntpdate 0.fedora.pool.ntp.org 7 May 11:26:37 ntpdate[10599]: adjust time server 209.167.68.100 offset -0.000787 sec [root@adam rdate (master)]# rdate -p 0.fedora.pool.ntp.org rdate: timeout for 0.fedora.pool.ntp.org [root@adam isos]# ntpdate clock.redhat.com 7 May 11:01:20 ntpdate[8377]: adjust time server 66.187.233.4 offset 0.001674 sec [root@adam isos]# rdate -p clock.redhat.com rdate: timeout for clock.redhat.com [root@adam isos]# ntpdate time.nist.gov 7 May 11:05:24 ntpdate[8673]: adjust time server 131.107.13.100 offset 0.012735 sec [root@adam isos]# rdate -p time.nist.gov rdate: couldn't connect to host time.nist.gov: Connection refused
Patch for using nptdate instead of rdate posted to anaconda-patches. I think that at least for F19 we could use ntpdate.
You'll need to make sure it's in anaconda's environment, then - I think there's a comps group to add it to.
(In reply to comment #6) > You'll need to make sure it's in anaconda's environment, then - I think > there's a comps group to add it to. Changing the "Requires: rdate" to "Requires: ntpdate" in the anaconda.spec should be enough.
anaconda-19.25-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/anaconda-19.25-1.fc19
Package anaconda-19.25-1.fc19, python-blivet-0.13-1.fc19, pykickstart-1.99.30-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-19.25-1.fc19 python-blivet-0.13-1.fc19 pykickstart-1.99.30-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-7834/python-blivet-0.13-1.fc19,pykickstart-1.99.30-1.fc19,anaconda-19.25-1.fc19 then log in and leave karma (feedback).
Tested with TC4, confirmed fixed: servers that work show up as green, servers that fail and servers that don't exist show up as red. Thanks.
anaconda-19.25-1.fc19, python-blivet-0.13-1.fc19, pykickstart-1.99.30-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.