[Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
On Fri, January 27, 2012 15:17, Stephen Gallagher wrote: On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. ___ The defaultNamingContext is not available, and I'm unable to add it. Object class violation. This is a Sun DS 7.0. Is there a way to manually specify what base_dn to import from? Rgds, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
Stephen Gallagher wrote: On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Not currently. I noticed this earlier in the week and opened a ticket on it, https://fedorahosted.org/freeipa/ticket/2314 Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. I'll update the 2314 to ensure we don't forget about this. 389-ds just added support for defaultNamingContext. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
On Fri, January 27, 2012 15:37, Rob Crittenden wrote: Stephen Gallagher wrote: On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Not currently. I noticed this earlier in the week and opened a ticket on it, https://fedorahosted.org/freeipa/ticket/2314 Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. I'll update the 2314 to ensure we don't forget about this. 389-ds just added support for defaultNamingContext. Ok, thank you. Anything I can do to work around this issue today? I suppose there is just a file that need to be hacked to set a set a value instead of the auto-detected value... ? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
Sigbjorn Lie wrote: On Fri, January 27, 2012 15:37, Rob Crittenden wrote: Stephen Gallagher wrote: On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Not currently. I noticed this earlier in the week and opened a ticket on it, https://fedorahosted.org/freeipa/ticket/2314 Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. I'll update the 2314 to ensure we don't forget about this. 389-ds just added support for defaultNamingContext. Ok, thank you. Anything I can do to work around this issue today? I suppose there is just a file that need to be hacked to set a set a value instead of the auto-detected value... ? /usr/lib/python*/site-packages/ipalib/plugins/migration.py ~line 620 you'll see a block starting with the comment retrieve DS base DN. Comment out the next 8 lines by prefixing them with # (these query to get the namingContext then pull the first value out). Add: ds_base_dn = 'dc=yourbasedn,dc=com' Alternatively you could always just add the above line to override what is detected. Commenting out just saves an LDAP lookup. Restart Apache. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 client not getting group names
On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: Hi, I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. When I run, e.g. id djscott, I do not get the names of the groups: -bash-4.2$ id djscott uid=768(djscott) gid=1002(legacy-group) groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129, Is this because they have low GIDs? (These were migrated over from my old FreeIPA 1 installation and I'd rather not re-number them all). Can someone help me to figure out how to retrieve the group names? This is working fine on the Fedora 15 clients (sssd-1.5.x). This looks to me like you didn't migrate all of the groups. GIF 1002 and 78961 are both reporting the names correctly, so clearly the client is able to access the FreeIPA server and retrieve groups. Please try the following and report the results: getent group 1134 and also getent group groupname where groupname is the name that is SUPPOSED to match GID 1134. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 16 client not getting group names
On Fri, Jan 27, 2012 at 11:47:01AM -0500, Dan Scott wrote: Hi, On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher sgall...@redhat.com wrote: On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: Hi, I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. When I run, e.g. id djscott, I do not get the names of the groups: -bash-4.2$ id djscott uid=768(djscott) gid=1002(legacy-group) groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129, Is this because they have low GIDs? (These were migrated over from my old FreeIPA 1 installation and I'd rather not re-number them all). Can someone help me to figure out how to retrieve the group names? This is working fine on the Fedora 15 clients (sssd-1.5.x). This looks to me like you didn't migrate all of the groups. GIF 1002 and 78961 are both reporting the names correctly, so clearly the client is able to access the FreeIPA server and retrieve groups. It's working fine with Fedora 15 clients, so I think that the groups were migrated OK. Please try the following and report the results: getent group 1134 and also getent group groupname where groupname is the name that is SUPPOSED to match GID 1134. I've just realised that once I've manually looked up the group using the name, the id command is 'fixed': [root@newton ~]# getent group 1134 [root@newton ~]# getent group svn-wfdb-swig-matlab svn-wfdb-swig-matlab:*:1134:ikaro,djscott [root@newton ~]# getent group 1134 svn-wfdb-swig-matlab:*:1134:ikaro,djscott [root@newton ~]# id djscott uid=768(djscott) gid=1002(legacy-group) groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129, The initial getent returned no data. But the group info seems OK once I've done one lookup. That's weird, id runs getgrgid() on each of the returned group GIDs Maybe the sssd cache is corrupt/out-of-date? How can I refresh it? WARNING: removing the cache would remove the cached passwords service sssd stop rm -f /var/lib/sss/db/cache*.ldb service sssd start If the group names still wouldn't show up, can you post logs when performing the id command? SSSD 1.7 contains a much more user-friendly way to just mark the entries in cache as expired using the sss_cache command. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
On 01/27/2012 03:55 PM, Rob Crittenden wrote: Sigbjorn Lie wrote: On Fri, January 27, 2012 15:37, Rob Crittenden wrote: Stephen Gallagher wrote: On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Not currently. I noticed this earlier in the week and opened a ticket on it, https://fedorahosted.org/freeipa/ticket/2314 Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. I'll update the 2314 to ensure we don't forget about this. 389-ds just added support for defaultNamingContext. Ok, thank you. Anything I can do to work around this issue today? I suppose there is just a file that need to be hacked to set a set a value instead of the auto-detected value... ? /usr/lib/python*/site-packages/ipalib/plugins/migration.py ~line 620 you'll see a block starting with the comment retrieve DS base DN. Comment out the next 8 lines by prefixing them with # (these query to get the namingContext then pull the first value out). Add: ds_base_dn = 'dc=yourbasedn,dc=com' Alternatively you could always just add the above line to override what is detected. Commenting out just saves an LDAP lookup. Restart Apache. I already found that file and did that earlier today, however I was restarting tomcat6, not httpd... my bad. :) I have to specify --group-objectclass=posixGroup to get groups imported, that's fine. But I only get a few users imported. I see that by default it seem to be looking for objectclass=person. Only a few user accounts have that objectclass associated, so I add --user-objectclass=posixAccount as all users have this objectclass associated with their account. $ ipa migrate-ds --user-container='ou=people' --group-container='ou=group' --bind-dn='cn=directory manager' --user-objectclass=account --group-objectclass=posixGroup --schema=RFC2307 --continue ldap://ldapserver:399 ipa: ERROR: an internal error has occurred Not good. I look in the /var/log/httpd/error_log file, and I find: [Fri Jan 27 18:12:51 2012] [error] ipa: INFO: admin@NONE: ping(): SUCCESS [Fri Jan 27 18:12:52 2012] [error] ipa: ERROR: non-public: UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: invalid continuation byte [Fri Jan 27 18:12:52 2012] [error] Traceback (most recent call last): [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipaserver/rpcserver.py, line 228, in wsgi_execute [Fri Jan 27 18:12:52 2012] [error] result = self.Command[name](*args, **options) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 432, in __call__ [Fri Jan 27 18:12:52 2012] [error] ret = self.run(*args, **options) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 738, in run [Fri Jan 27 18:12:52 2012] [error] return self.execute(*args, **options) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/plugins/migration.py, line 634, in execute [Fri Jan 27 18:12:52 2012] [error] ldap, config, ds_ldap, ds_base_dn, options [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/plugins/migration.py, line 513, in migrate [Fri Jan 27 18:12:52 2012] [error] search_refs=True# migrated DS may contain search references [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 188, in new_f [Fri Jan 27 18:12:52 2012] [error] return f(*new_args, **kwargs) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 199, in new_f [Fri Jan 27 18:12:52 2012] [error] return args[0].decode(f(*args, **kwargs)) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 139, in decode [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 139, in genexpr [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 137, in decode [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 139, in decode [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012]
Re: [Freeipa-users] Fedora 16 client not getting group names
On Fri, 2012-01-27 at 17:57 +0100, Jakub Hrozek wrote: On Fri, Jan 27, 2012 at 11:47:01AM -0500, Dan Scott wrote: Hi, On Fri, Jan 27, 2012 at 10:48, Stephen Gallagher sgall...@redhat.com wrote: On Fri, 2012-01-27 at 10:36 -0500, Dan Scott wrote: Hi, I have a Fedora 16 client running sssd-client-1.6.4-1.fc16.x86_64. When I run, e.g. id djscott, I do not get the names of the groups: -bash-4.2$ id djscott uid=768(djscott) gid=1002(legacy-group) groups=1002(legacy-group),1134,1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129, Is this because they have low GIDs? (These were migrated over from my old FreeIPA 1 installation and I'd rather not re-number them all). Can someone help me to figure out how to retrieve the group names? This is working fine on the Fedora 15 clients (sssd-1.5.x). This looks to me like you didn't migrate all of the groups. GIF 1002 and 78961 are both reporting the names correctly, so clearly the client is able to access the FreeIPA server and retrieve groups. It's working fine with Fedora 15 clients, so I think that the groups were migrated OK. Please try the following and report the results: getent group 1134 and also getent group groupname where groupname is the name that is SUPPOSED to match GID 1134. I've just realised that once I've manually looked up the group using the name, the id command is 'fixed': [root@newton ~]# getent group 1134 [root@newton ~]# getent group svn-wfdb-swig-matlab svn-wfdb-swig-matlab:*:1134:ikaro,djscott [root@newton ~]# getent group 1134 svn-wfdb-swig-matlab:*:1134:ikaro,djscott [root@newton ~]# id djscott uid=768(djscott) gid=1002(legacy-group) groups=1002(legacy-group),1134(svn-wfdb-swig-matlab),1130,1118,1103,1108,1113,78961(ipausers),1102,1109,1129, The initial getent returned no data. But the group info seems OK once I've done one lookup. That's weird, id runs getgrgid() on each of the returned group GIDs I know what's going on here. It was a stupid glibc screw-up in Fedora 16. Remove the line starting with initgroups: from your /etc/nsswitch.conf file. See https://bugzilla.redhat.com/show_bug.cgi?id=751450 for more details. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
On Fri, 2012-01-27 at 13:42 -0500, Rob Crittenden wrote: This came up yesterday internally too. I don't believe a bug or ticket has been filed yet. My best guess on what is happening, based on what I saw with our own case, is this: A migrated attribute is coming in that IPA doesn't know about. We default to treating all attributes that don't require special treatment (like binary values) as utf-8. I'm guessing that an unknown binary attribute is being migrated, we try to utf-8 encode it and kablooey. There is no easy workaround for the above problem right now because that happens before the --ignore* options are considered. Why don't we just base64-encode unknown attributes instead of treating them like UTF-8? The LDAP server is *supposed* to be able to handle this implicitly. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available
On 01/27/2012 07:42 PM, Rob Crittenden wrote: Sigbjorn Lie wrote: On 01/27/2012 06:15 PM, Sigbjorn Lie wrote: On 01/27/2012 03:55 PM, Rob Crittenden wrote: Sigbjorn Lie wrote: On Fri, January 27, 2012 15:37, Rob Crittenden wrote: Stephen Gallagher wrote: On Fri, 2012-01-27 at 15:11 +0100, Sigbjorn Lie wrote: Hi The first naming context returned from the LDAP server is always chosen when using migrate-ds. This makes my import fail when I attempt to import users and groups from a previous LDAP server having more than 1 naming contexts available. The migrate-ds script should accept an option to specify what base_dn I would like to import from. Is there such an option today? I cannot find it... Not currently. I noticed this earlier in the week and opened a ticket on it, https://fedorahosted.org/freeipa/ticket/2314 Just to add to this request, if the original LDAP server has a defaultNamingContext attribute, it should be honored for auto-detecting which base to migrate. I'll update the 2314 to ensure we don't forget about this. 389-ds just added support for defaultNamingContext. Ok, thank you. Anything I can do to work around this issue today? I suppose there is just a file that need to be hacked to set a set a value instead of the auto-detected value... ? /usr/lib/python*/site-packages/ipalib/plugins/migration.py ~line 620 you'll see a block starting with the comment retrieve DS base DN. Comment out the next 8 lines by prefixing them with # (these query to get the namingContext then pull the first value out). Add: ds_base_dn = 'dc=yourbasedn,dc=com' Alternatively you could always just add the above line to override what is detected. Commenting out just saves an LDAP lookup. Restart Apache. I already found that file and did that earlier today, however I was restarting tomcat6, not httpd... my bad. :) I have to specify --group-objectclass=posixGroup to get groups imported, that's fine. But I only get a few users imported. I see that by default it seem to be looking for objectclass=person. Only a few user accounts have that objectclass associated, so I add --user-objectclass=posixAccount as all users have this objectclass associated with their account. $ ipa migrate-ds --user-container='ou=people' --group-container='ou=group' --bind-dn='cn=directory manager' --user-objectclass=account --group-objectclass=posixGroup --schema=RFC2307 --continue ldap://ldapserver:399 ipa: ERROR: an internal error has occurred Not good. I look in the /var/log/httpd/error_log file, and I find: [Fri Jan 27 18:12:51 2012] [error] ipa: INFO: admin@NONE: ping(): SUCCESS [Fri Jan 27 18:12:52 2012] [error] ipa: ERROR: non-public: UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 1: invalid continuation byte [Fri Jan 27 18:12:52 2012] [error] Traceback (most recent call last): [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipaserver/rpcserver.py, line 228, in wsgi_execute [Fri Jan 27 18:12:52 2012] [error] result = self.Command[name](*args, **options) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 432, in __call__ [Fri Jan 27 18:12:52 2012] [error] ret = self.run(*args, **options) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 738, in run [Fri Jan 27 18:12:52 2012] [error] return self.execute(*args, **options) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/plugins/migration.py, line 634, in execute [Fri Jan 27 18:12:52 2012] [error] ldap, config, ds_ldap, ds_base_dn, options [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/plugins/migration.py, line 513, in migrate [Fri Jan 27 18:12:52 2012] [error] search_refs=True # migrated DS may contain search references [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 188, in new_f [Fri Jan 27 18:12:52 2012] [error] return f(*new_args, **kwargs) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 199, in new_f [Fri Jan 27 18:12:52 2012] [error] return args[0].decode(f(*args, **kwargs)) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 139, in decode [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 139, in genexpr [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 137, in decode [Fri Jan 27 18:12:52 2012] [error] return [self.decode(m) for m in var] [Fri Jan 27 18:12:52 2012] [error] File /usr/lib/python2.6/site-packages/ipalib/encoder.py, line 139, in decode [Fri Jan 27 18:12:52 2012] [error] return tuple(self.decode(m) for m in var) [Fri Jan 27 18:12:52
Re: [Freeipa-users] Using DHCPD with IPA
On 01/27/2012 02:28 PM, Simo Sorce wrote:
On Fri, 2012-01-27 at 14:21 -0500, Dmitri Pal wrote:
On 01/25/2012 07:38 PM, ~Stack~ wrote:
On 01/25/2012 05:18 PM, Sigbjorn Lie wrote:
On 01/25/2012 02:30 AM, ~Stack~ wrote:
2) How do I get dhcpd to update DNS?
Since I can't find the place to add rndc-keys to BIND, right now I have
to add every host manually in the web interface because dhcpd isn't
updating named. This is time consuming and a pain when dealing with
large amounts of systems. If I could figure out where the named zones
are stored in IPA I should be able to add my rndc-key and be OK, but
that gets back into question 1.
My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients
have host entries to match their MAC with the group that allows PXE
booting (ex: host pxe001.project.local{hardware ethernet
00:16:17:AB:E9:88; fixed-address 172.31.203.1}). Unless I mange both
this file and the IPA interface, the nodes have issues figuring out
their name. One or the other and the node has issues; both and it works.
I would really prefer not to manage two locations for all these nodes.
The normal way for dhcpd to talk to BIND(named) is by having a rndc-key.
However, me fighting with named.conf was the big part of my problems
before so I am hoping there is a simple way of doing this inside IPA.
Any ideas?
This is what I have done to work around issues similar to yours.
Over a few years I have developed a pxe boot toolbox called
OneClickKick. OCK manages DHCPD by generating config files based upon
information looked up from naming sources such as Mysql, NIS, or LDAP
(IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and
serves kickstart files when PXE booting clients.
I have integrated OCK with IPA to make IPA keep records of the MAC
address, and base my DHCP config upon the information I get from IPA.
For your configuration, the steps for adding a new client would be the
following:
1. Add the host to IPA, specify an IP address so that forward and
reverse DNS records are created for the host
2. The host will appear in OneClickKick, select modify, add the MAC
address (this is being written to the host object in IPA), and select it
for PXE boot / kickstart. This will generate the DHCP config file,
reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg
directory (if you enabled it for PXE booting).
3. PXE boot the client.
By doing this you eliminate the need for dhcpd to update the DNS server,
because the records are already there.
The MAC addresses stored in IPA can also be used by normal Linux and
Solaris (Jumpstart) clients by utilizing their ethers table in
nsswitch.conf.
Have a look at the link below to read more and download if you think
OneClickKick could suit your environment.
http://sourceforge.net/projects/oneclickkick/
Thank you! I will take a look at it tomorrow.
~Stack~
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
What Adam was trying to say is that if you want a little bit more
security to this enrollment process you need when you register host
with IPA ask IPA for generated OTP (or provide your own). This OTP
needs then to be seeded into the kickstart file. As the Kickstart file
is processed the ipa-client-install command will be called with this
OTP as one of the parameters. The ipa-client will authenticate to IPA
server and finish the configuration of the system provisioning the
keys.
When the machine is rebooted you need to do the same sequence except
you need to delete and re add the host or clean its keytab and status
(both options would work).
The OTP capability was specifically added to address automatic
provisioning like this in a secure way.
Would it work for you?
This needs some more explanation.
Recycling the keytab very often can lead to connection errors (users may
have valid tickets for the machine, and the machine will not longer
recognize them).
Keeping around the keytab for these host would be safer, even if you end
up refreshing the keytab using the OTP method, although if you keep
around the keytab then using the OTP seem more burden than anything.
Simo.
This depends on the assumption about the infrastructure.
If the reboot means that it is a completely new entity may be the
tickets should actually not be valid any more. But then the name should
probably be different too and reboot would be = provisioning. With the
stateless systems it is really hard to draw the line between the two.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] WebUI With Windows, Firefox, and MIT Kerberos
Has anyone successfully gotten firefox in windows with firefox and mit kerberos? I've followed several how to's, but i cant get firefox to take/pass my tgt. -Jr ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
