Martin Kosek wrote:
On 03/13/2013 02:58 PM, Martin Kosek wrote:
On 03/11/2013 12:40 PM, Martin Kosek wrote:
On 03/07/2013 03:07 PM, Petr Viktorin wrote:
On 03/07/2013 02:00 PM, Martin Kosek wrote:
When multiple servers are passed via --server option, ipadiscovery
module changed its order. Make sure that we preserve it.

Also make sure that user is always warned when a tested server is
not available as then the server will be excluded from the fixed
server list.

The message doesn't actually say that the server will be removed. It would be
nice if it did.

Otherwise, ACK.

Sending a patch with improved logging. User should now be more clear what
server is failing to verify (and why).


------

When working on this ticket I was thinking - do we make the right thing we
deliberately remove a server from user-provided server list just because we
cannot connect to it at the moment if discovery? It may just be temporarily
down or something.

Maybe we should preserve the original --server list in this case and use this
list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other
active configuration commands we would have to use only the valid servers so
that the we do not hit the server that is currently down.

Martin

Good point, this deserves a ticket.


Rob, do you think this deserves to be changed? Or is this behavior indeed
intended?

Martin


Sending a rebased patch 381, logging was also improved. Client discovery
logging now looks like that:

# ipa-client-install
Skip vm-024.idm.lab.bos.redhat.com: not an IPA server
Skip doesnotexist.test: cannot verify if this is an IPA server
Discovery was successful!
Hostname: vm-148.idm.lab.bos.redhat.com
Realm: IDM.LAB.BOS.REDHAT.COM
DNS Domain: idm.lab.bos.redhat.com
IPA Server: vm-037.idm.lab.bos.redhat.com
BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com

Continue to configure the system with these values? [no]:
...

I also attached a related fix for redundant discoveries with fixed server list
(found that when testing logging), details are in the patch description.

Martin


I just creating a conflict in my patch numbering, renaming 386 to 387...

Martin


ACK.

I think we probably want this in the 3-1 branch too but some merging is needed, so I'll leave that up to you Martin :-)

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to