On Wed, Feb 24, 2016 at 04:08:14PM +0100, David Kupka wrote:
> On 24/02/16 15:55, Sumit Bose wrote:
> >On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote:
> >>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.
> >
> >realmd has the --dbus-peer option. So I guess it might be possible that
> >realmd can be started by ipa-client-install directly in this case and
> >allow communication over a socket pair. I'm not sure how hard or easy
> >this would be in python.
> >
> >Stef, do you have some pointers how to use dbus-peer from python?
> >
> >bye,
> >Sumit
> >
> We have already done something similar with certmonger. You can look into
> ipapython/certmonger.py

Great, so it should be possible to use realmd in the same way in a
kickstart environment.


> >>
> >>>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
> >
> -- 
> David Kupka

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to