On 02/24/2016 03:20 PM, Sumit Bose wrote:
On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote:
On 02/16/2016 02:23 PM, Martin Babinsky wrote:
Hi list,
WARNING: huge brain dump ahead.
During investigation of https://fedorahosted.org/freeipa/ticket/4305 me
and Petr Spaced (CC'ed) came to a conclusion that the IPA realm
autodiscovery code used by ipa-client-install is so convoluted, complex
and hard to understand that the cost of fixing a bug/adding a behavioral
change (there are some other tickets dealing with ipadiscovery, e.g. see
https://fedorahosted.org/freeipa/ticket/5270
https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher
that a more large-scale rewrite of the module and related codebase.
Since we plan to do some general refactoring work anyway, I would like
to discuss the possible course of action we may take to tackle this
issue. I would like to present the following options we have been
discussing so far:
1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py")
We may take the existing IPADiscovery class and try rewrite it in order
to get a more concise and deterministic code, which will:
* rely more on python-dns and answers provided by resolver (e.g. we are
directly parsing resolv.conf for available domains when we can ask the
resolver to get domains for us)
* be more pythonic (replace error codes with thrown exceptions, clean up
numerous C-isms etc.)
* not try to outsmart user when server/realm/domain is specified
beforehand. Currently, even if you specify all three options, there is
still some DNS discovery performed, hence bug #4305. I think that one
you specify server(s), not magic should be performed and the discovery
process should be reduced to checking whether they are IPA servers and
pull all other info (like realm) from them.
This may be a considerable effort requiring some time to implement and
get right, but IMHO still comparable to the time spent iteratively
placing 'if' statements into the existing code and hoping to not break
anything. I would even argue it is not worth the effort because we can
2.) Use realmd dbus interface to do DNS discovery
I have attached aquick and dirty script I have slapped together to
leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm
discovery for us. This has a lot of appeal to me since we are leveraging
existing codebase for DNS discovery and will have to handle only cases
when the user manually specifies a list of IPA servers for the client.
This however pulls in realmd as a (potentially circular) dependency for
ipa client, and when we find bug in the discovery code, we will have to
poke upstream (Stef or Sumit I think) to fix it.
So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to:
3.) Split out IPA discovery portion of realmd to a separate C library
shared between IPA and realmd
may be best. Both projects will have shared codebase (maintained either
by us or realmd devs), which can be reused also by other people to
create their own discovery/enrollment solution. This would however
require sustained and concerted efforts of both teams to create the
library and possibly rewrite realmd to accommodate this change.
There may be some other options viable for us, if so please mention them
in a reply. Also please correct any piece of information I got wrong.
TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix
it.
#3 sounds good from long term perspective.
In short term, i.e., #4305, we should skip discovery when --on-master is
used.
I would prefer #2. Because as seen from the patch it is already working
and can easily be used from python. I think this was also one of the
reasons why Stef used a DBus service for this instead of a C library
which then needs various bindings for python, Java, ruby, Go you name
it.
This approach is also my favorite. However, my (and several of my
colleagues) concern is that
https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in
kickstart environment. I don't know how much of an issue is this, I
guess it completely precludes automatic enrollment during machine
provisioning.
About the concerns. rpm-wise realmd has no dependencies on its
underlying tools, it will tell which packages must be installed to do
the join or will use packagekit to install them on its own. So it is
safe to add a realmd dependency to the ipa-client package. And as long
as you only use the Discover method realmd would not try to call
ipa-client-install, so there is no logical circle either. To avoid an
un-needed second discovery when ipa-client-install is not run from the
command line but from realmd directly ipa-client-install can skip the
realmd call if domain and realm are already given on the command line
because realmd will set both options when calling ipa-client-install.
And if there is a bug you have to poke the maintainer of the library or
realmd either way.
bye,
Sumit
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
--
Martin^3 Babinsky
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
