Description of problem: During client install with the --no-ntp option, I see the following messages: Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Version-Release number of selected component (if applicable): 2.2 How reproducible: Every time I install the client with --no-ntp Steps to Reproduce: 1. ipa-client-install --domain=blah --mkhomedir -w blah --realm=BLAH --no-ntp --server=ipaserver.blah --unattended 2. 3. Actual results: Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Expected results: Not sure - but something along these lines: "Time configuration skipped." Additional info: Might be worth putting in an `ntpq -p` type check if the user has requested to skip NTP configuration. If no synced time servers can be found, warn the user that time sync is unavailable on this client.
I think this overloads the meaning of--no-ntp. It was originally a flag to skip the local NTP configuration. The syncing of time during kinit was done later and is probably still valuable even if the NTP configuration isn't overwritten.
Yes, I kept wondering about that when I was entering the details. It's just that the messages then come out as misleading, bordering on disconcerting. Our IPA servers are on virutal guests, where it is suggested that you explicitly do not run NTP services. As a result, all our IPA clients sync to various hardware NTP servers around the network (still trying to get funding to get a proper GPS/radio synched clock on the network). As I'm explicitly opting out of time synching with the IPA servers, I was just unsure that messages such as the above during installation were a good idea. By all estimates, my IPA clients and IPA servers should be synching to the same NTP servers at each point on the network, so I don't want any secondary time synching done. If the client time is outwith the Kerberos tollerance with the IPA server, it's my fault and something that needs fixing by me.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/3092
I agree that we have some room in making --no-ntp more understandable. It grew a bit organically and not always in the clearest way. For example, if you say --no-ntp chances are you have a local NTP configuration you'd like to preserve. In this case, you suggest, we should check to see if there are any peers and if so, go ahead and try to sync the time. No peers == no sync attempt. And currently we pass in the IPA server to the NTP sync regardless of the current NTP configuration, that is not right in this case either. I'm a little reluctant to add another option, --no-ntp-sync, or something. Too many knobs can be a bad thing as they atrophy over time if not used.
I'm not actually certain about checking for NTP peers to be honest. That part was tagged on the end of the initial text without much thought. There'd be an argument to say that if I'm using --no-ntp, I know what I'm doing and you don't need to check. Don't look at my NTP peers, don't attempt a time sync. If, on the other hand, it's relatively simple to look up the NTP peers, check that at least one of them is synched as the time source, then fine. Agree about not creating too many options.
I have my FreeIPA-server running as a virtual server, and as suggested by the documentation I do not use it as a NTP-server. I do however have a NTP-server running on another system. My laptops are using Fedora 17, 18 and rawhide. And chrony syncing time against my NTP-server if available, just as my freeipa-server. So ipa-client-install does not configure NTP for me, however it always tries to sync against the KDC instead of my NTP-server. So I ask the following: Is it possible to get "--no-ntp --ntp-server=<my ntp-server>" to not overwrite the NTP-configuration but at least try to sync against the specified NTP-server?
We have an RFE for that in https://fedorahosted.org/freeipa/ticket/1954
(In reply to comment #7) > We have an RFE for that in https://fedorahosted.org/freeipa/ticket/1954 Not really the same. From the RFE: "It should be possible to configure IPA server to sync time from external NTP servers _while still providing NTP server functionality for IPA clients._" (underscores added to prove the main difference) The docs for FreeIPA in Fedora 17 [1] states that: 2.1.4.5. NTP If a server is being installed on a virtual machine, that server should not run an NTP server. To disable NTP for FreeIPA, use the --no-ntp option. I followed this advice and thus run _NO_ NTP server on the IPA-server _at all_! So if I run: "ipa-client-install --no-ntp --ntp-server=ntp.example.com --server=ipa.example.com" Then I STILL have to wait for a timeout while ipa-client-install tries to sync the time against ipa.example.com, while I KNOW that everything except syncing against ntp.example.com will fail on my network! Also, as ipa-client-install will not touch the default NTP-client (chrony), this means that every default Fedora installation working against a default virtual FreeIPA-server will have to wait for a timeout. And there is no way around it, even if you try to force it to use a server that actually answers on the correct port. [1] http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/installing-ipa.html#prerequisites
Yes but taken together with 3092 I think between the two it will do what you request. The timekeeping in VMs was quite bad, particularly prior to F-16, which is why we have recommended to not run them. You may have better luck with NTP in F-18.
(In reply to comment #9) > Yes but taken together with 3092 I think between the two it will do what you > request. > > The timekeeping in VMs was quite bad, particularly prior to F-16, which is > why we have recommended to not run them. > > You may have better luck with NTP in F-18. I can still see use-cases where you do not want NTP on the same server as the KDC, or at install time override your ntpd/chrony-defaults. So I still think it would be valid to have "ipa-client-install --ntp-server=<my nameserver>" try to sync against <my nameserver> instead of KDC.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Moved this to Fedora 19. Not because I know it's still a problem in F19, but because it doesn't appear resolved and I don't want it closed as WONTFIX.
Moving to the right component for FreeIPA in Fedora - "freeipa". "ipa" component is only used in RHEL product.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Moved this to Fedora 21. Not because I know it's still a problem in F21, but because it doesn't appear resolved and I don't want it closed as EOL.
See * https://fedorahosted.org/freeipa/ticket/4842 * https://fedorahosted.org/freeipa/ticket/3092 master: https://fedorahosted.org/freeipa/changeset/f0c1daf7a2a8c88f6d84d81d66c7e39f571e0894 https://fedorahosted.org/freeipa/changeset/e537fd202e23a507dd0c43d2dfdf88fd6921e183 ipa-4-1: https://fedorahosted.org/freeipa/changeset/b5969c1d1ae6eb1e392e0420fcbf094ae7b34102
freeipa-4.2.2-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update freeipa' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-4abcc8b937
freeipa-4.2.2-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.