-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Secondly, I think we should consider including 'openlmi-realmd' as one of the packages pulled in by the 'openlmi' meta-package.
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.
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.
[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.
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:
- Use the OpenLMI Software Provider to install the 'openlmi-realmd'
package, since it's not included as a dependency of the 'openlmi' meta-package
- 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).
- 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'"
- 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.
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.
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.
I initially thought the ability to filter by domain would be useful - but how many of our customers have more than one domain installed?
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.
[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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
-----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:
- Use the OpenLMI Software Provider to install the
'openlmi-realmd' package, since it's not included as a dependency of the 'openlmi' meta-package
- 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).
- 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'"
- 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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
_______________________________________________ openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
On 06/13/2014 04:01 PM, Stephen Gallagher wrote:
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.
Automatic installation of any packages is dangerous and should be IMO explicitly requested by system admin. I'd rather solve this on client side, where a script could ask 'Do you want to install following packages: ipa-client, oddjob, oddjob-mkhomedir [Y/n]?'
The same for DNS setting.
Jan.
On Jun 16, 2014, at 3:50 AM, Jan Safranek jsafrane@redhat.com wrote:
On 06/13/2014 04:01 PM, Stephen Gallagher wrote: 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.
Automatic installation of any packages is dangerous and should be IMO explicitly requested by system admin.
I agree, however I would also assert that when issuing a call to join a domain, I'm making an implicit statement that the necessary software to perform this action is present on the system.
I'd rather solve this on client side, where a script could ask 'Do you want to install following packages: ipa-client, oddjob, oddjob-mkhomedir [Y/n]?'
I strongly dislike any API that forces every client to perform the same patterns, particularly if (as in this case) there's only one choice they can possibly make.
The same for DNS setting.
The more I think about it, the less I believe this should be baked into the realmd provider. Too many edge-cases.
Jan. _______________________________________________ openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
On Fri, 13 Jun 2014 10:01:23 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Thanks!
<...>
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.
I second Jan in this -- silently installing packages is IMO not a good idea. This may be eventually a goal for a realmd script that could do it. Not the provider though.
Secondly, I think we should consider including 'openlmi-realmd' as one of the packages pulled in by the 'openlmi' meta-package.
I have no opinion here. I admit that I have no idea how usual is it to have a KRB/AD domain set in the environments OpenLMI is aiming at.
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.
Again -- isn't this somewhat working around broken network setup? DHCP should take care of telling its clients what DNS server to use.
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.
Hmm... Who should be responsible for telling SLP the machine is not a domain member? Realmd or OpenLMI?
[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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlObBDIACgkQeiVVYja6o6NQfgCeIFONeKTBD65OWwWC+czOvxaz lKYAoI63bYA7O9waEC0AQ3P9XPN45+JV =14Px -----END PGP SIGNATURE-----
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/17/2014 02:58 AM, Tomáš Smetana wrote:
On Fri, 13 Jun 2014 10:01:23 -0400 Stephen Gallagher sgallagh@redhat.com 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.
Thanks!
<...>
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.
I second Jan in this -- silently installing packages is IMO not a good idea. This may be eventually a goal for a realmd script that could do it. Not the provider though.
realmd already has this capability. There was a long discussion about this in the past[2]. The final decision was that it is acceptable for us to auto-install packages to meet a clear request from an administrator (in this case, someone with root-level privileges is trying to join a machine to a domain, that to me states clearly that the admin is aware that she is going to be starting up a set of appropriate system services). The strong recommendation in this case would be for the UI to indicate to the user which packages were installed. We can return this as part of our response data.
Secondly, I think we should consider including 'openlmi-realmd' as one of the packages pulled in by the 'openlmi' meta-package.
I have no opinion here. I admit that I have no idea how usual is it to have a KRB/AD domain set in the environments OpenLMI is aiming at.
We're aiming for this to be the 90%+ case. That's why we're pushing so hard on the GSSAPI support. Nearly all real-world environments have a domain (AD, FreeIPA or custom). This is a situation we really *prefer*, as it means that we're moving towards a more uniform setup which makes support simpler.
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.
Again -- isn't this somewhat working around broken network setup? DHCP should take care of telling its clients what DNS server to use.
Well, not necessarily. In a cloud environment, DHCP is likely to just hand out the default DNS entries (for example, in EC2 it'll get Amazon's DNS servers). We will need to point them to the right place. We can do that now - manually - with the networking provider. Doing this in realmd would be a convenience, but not a strict necessity. I'd certainly stick this on the "patches welcome" pile of RFEs.
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.
Hmm... Who should be responsible for telling SLP the machine is not a domain member? Realmd or OpenLMI?
I'd probably recommend we do so in OpenLMI, if only because we already have the infrastructure for it.
[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.
Regards,
[2] https://bugzilla.redhat.com/show_bug.cgi?id=984960
openlmi-devel@lists.fedorahosted.org
-
Jan Safranek -
Russell Doty -
Stephen Gallagher -
Tomáš Smetana