Ruminations on realmd

Stephen Gallagher sgallagh at redhat.com
Fri Jun 13 15:17:21 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/13/2014 11:03 AM, Russell Doty wrote:
> On Fri, 2014-06-13 at 10:01 -0400, Stephen Gallagher wrote:
>> Today I spent some time playing around with the realmd provider
>> in OpenLMI. My specific intent was to see what it might take to
>> be able to configure the FreeIPA Domain Controller to be able to
>> enroll clients into the domain from the central server (assuming
>> that they know an appropriate Pegasus username).
>> 
>> I put together a RHEL 7 kickstart (attached[1]) containing the
>> minimum set of software necessary to use OpenLMI.
>> 
>> From there, I proceeded to try to use the realmd provider to join
>> a domain of a FreeIPA server I had previously set up.
>> 
>> The following steps proved necessary:
>> 
>> 1) Use the OpenLMI Software Provider to install the
>> 'openlmi-realmd' package, since it's not included as a dependency
>> of the 'openlmi' meta-package
>> 
>> 2) Use the OpenLMI Networking provider to change the DNS server
>> to be the one provided by FreeIPA. (Unless already handled by
>> DHCP, which it was not in my case).
>> 
>> 3) Use the OpenLMI Software Provider to install the 'ipa-client' 
>> package and its dependencies, because the realmd JoinDomain()
>> method reports "CIM_ERR_FAILED: LMI: dbus_join_call() failed: 
>> (RDCP_ERROR_DBUS(4)) dbus error
>> (org.freedesktop.realmd.Error.Failed): Necessary packages are not
>> installed: ipa-client, oddjob, oddjob-mkhomedir, sssd:
>> 'JoinDomain'"
>> 
>> 4) Call the realmd JoinDomain() command with the appropriate
>> privileges.
>> 
>> After this, the client was correctly registered as a member of
>> the FreeIPA domain.
>> 
>> 
>> 
>> I think there are several things that we can improve in this
>> flow.
>> 
>> First of all, I think that if JoinDomain() reports that packages
>> need to be installed, it should implicitly invoke the Software
>> provider and install them; thus only returning a failure to the
>> caller if the packages are unavailable for installation.
> Nice!
>> 
>> Secondly, I think we should consider including 'openlmi-realmd'
>> as one of the packages pulled in by the 'openlmi' meta-package.
> Do we really want to include realmd in the base install? This would
> mean that it is installed on systems that are not joined into a
> domain.

Well, what it means is that "all systems with OpenLMI on it are ready
to be joined to a domain". I think that's a fairly reasonable
statement to make, particularly if we're going to be advising people
in OpenLMI 1.1 to prefer the use of GSSAPI/Kerberos.


>> 
>> It would also be useful for the JoinDomain() method to accept an 
>> optional argument to provide the DNS server address, so a client
>> could indicate that the standard DHCP-assigned DNS addresses are
>> not correct for this domain.
> I'm lost. I can follow giving the JoinDomain the name and/or
> address of the Domain Controller. Are you proposing that the
> registration process should have the ability to change the DNS
> address of the system being registered? This is the only dhcp
> assigned address I can see.

Right, I should have been more clear here about how realmd works. The
way that it detects appropriate settings for a domain is by querying
DNS for LDAP and Kerberos SRV records. If the DNS server assigned by
DHCP does not provide those records, then the domain join will fail.
(It's hard to say whether this is likely to be common in deployment,
but it's *definitely* common in development).

So what I'm saying is that the domain join operation should be capable
of pointing the /etc/resolv.conf at a different DNS server than the
one that's currently in there, so it could properly detect the domain
properties.

I could be convinced to just not do this and advise people to call the
Networking provider manually first (like I did) in order to change it
if needed in their environment.


>> 
>> 
>> 
>> Additionally, I think we should explore the possibility of
>> enhancing our OpenSLP attributes such that it would be possible
>> to query SLP for "all machines on the network that have the
>> openlmi-realmd provider installed and are not currently on a
>> domain (or are currently joined to domain X, etc.). This would
>> make it possible for FreeIPA's GUI or CLI to present the domain
>> administrator with a list of machines that could be joined to the
>> domain.
> If realmd is included in the base install of OpenLMI, then every
> system responding to SLP would have the realmd provider installed.
> 

Right, I wasn't asking for that, I was asking for the intersection of
"has realmd and is not in any domain". In other words, list all the
machines I could choose to add to the domain.


> I initially thought the ability to filter by domain would be useful
> - but how many of our customers have more than one domain
> installed?
> 

Somewhere between 95% and 100%, by my calculation. Most companies have
multiple domains in an Active Directory forest; I expect that to be
fairly common as FreeIPA grows as well. Note: despite my including
this in an email largely focused on FreeIPA, I think this would still
be a useful query for Active Directory domains as well.


> Being able to query which machines are registered in a domain - and
> the opposite, which machines are not registered in a domain - does
> sound useful.

Yes, and can be used to write a meaningful UI as well.


>> 
>> 
>> 
>> [1] This kickstart is likely incomplete, as it will need to be 
>> tailored for your environment to be able to access the
>> appropriate RPM installation channels. I omitted those from the
>> included kickstart because I was using a local mirror. 
>> _______________________________________________ openlmi-devel
>> mailing list openlmi-devel at lists.fedorahosted.org 
>> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
> 
> 
> _______________________________________________ openlmi-devel
> mailing list openlmi-devel at lists.fedorahosted.org 
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlObFgEACgkQeiVVYja6o6NUmACfXzzxx+JAlFg10XioEjmxpUad
KSoAnRF3rddv5t0cnO6oQUVjzATQQlj2
=RZns
-----END PGP SIGNATURE-----


More information about the openlmi-devel mailing list