Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 858302 - NTP Sync during client install
Summary: NTP Sync during client install
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-18 15:35 UTC by Duncan Innes
Modified: 2015-10-11 16:02 UTC (History)
10 users (show)

Fixed In Version: freeipa-4.2.2-1.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-11 16:02:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Duncan Innes 2012-09-18 15:35:45 UTC
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.

Comment 1 Rob Crittenden 2012-09-18 15:41:50 UTC
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.

Comment 2 Duncan Innes 2012-09-18 15:57:55 UTC
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.

Comment 3 Rob Crittenden 2012-09-19 01:49:26 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3092

Comment 4 Rob Crittenden 2012-09-19 01:54:20 UTC
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.

Comment 5 Duncan Innes 2012-09-20 08:38:12 UTC
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.

Comment 6 Peter Hjalmarsson 2013-02-14 13:53:17 UTC
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?

Comment 7 Rob Crittenden 2013-02-14 14:14:08 UTC
We have an RFE for that in https://fedorahosted.org/freeipa/ticket/1954

Comment 8 Peter Hjalmarsson 2013-02-14 14:51:16 UTC
(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

Comment 9 Rob Crittenden 2013-02-14 15:00:13 UTC
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.

Comment 10 Peter Hjalmarsson 2013-02-17 18:15:27 UTC
(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.

Comment 11 Fedora End Of Life 2013-07-04 06:28:54 UTC
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.

Comment 12 Duncan Innes 2013-07-04 09:37:24 UTC
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.

Comment 13 Martin Kosek 2014-01-23 13:11:14 UTC
Moving to the right component for FreeIPA in Fedora - "freeipa". "ipa" component is only used in RHEL product.

Comment 14 Fedora End Of Life 2015-01-09 22:00:38 UTC
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.

Comment 15 Fedora End Of Life 2015-02-18 13:45:50 UTC
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.

Comment 16 Duncan Innes 2015-02-18 16:10:02 UTC
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.

Comment 18 Fedora Update System 2015-10-09 13:55:36 UTC
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

Comment 19 Fedora Update System 2015-10-11 16:02:34 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.