[Freeipa-users] ipa-client-install: done remotely, DNS discovery and multiple servers
Hi Since EL 6.4, executing ipa-client-install over SSH i.e. 'ssh client ipa-client-install params', results in an issue with the host certificate. The output returns the following error during the: 'ipa-getcert request -d /etc/pki/nssdb' stage: TLS: could not close certdb slot - error -8018:Unknown PKCS #11 error. TLS: could not shutdown NSS - error -8053:NSS could not shutdown The host certificate remains in state: 'status: NEED_CSR' when checking with ipa-getcert list In EL6.2 and EL6.3 this was not an issue. Perhaps you may reproduce this and advise. In order to work around this, I end up having to run ipa-client-install locally on the client. Also, with 6.4, thanks to the --fixed-primary switch we can now statically set specific IPA servers to use for a given client, instead of rely on DNS (SRV records) discovery. Before this feature we would need to patch the sssd.conf manually and restart SSSD, as ipa-client-install would remain stuck since the given client via SRV discovery would attempt using an IPA server it does not have access to. Now we longer have this issue, however ipa-client-install still picks the NTP server with which it should synchronize time during the enrolment process via DNS discovery. In the past ipa-client-install would 'give up' after 3 attempts or so, but now it keeps attempting until it encounters a reachable IPA NTP server. In an environment where there is a significant amount of IPA servers installed and distributed in different places where access is restricted by location, it can take some time until the reachable IPA/NTP server for a given client/location is found. A suggestion would be that if one goes for the --fixed-primary + --server options, then the omission of DNS discovery should not only apply to the IPA service but also for time synchronization. In most cases chances are that if one opts to use specific servers for IPA, one probably also wants to use specific servers for NTP. Or for added flexibility, provide another switch to select a specifc server to synchronize time with during the enrolment process. FYI, use of the --ntp-server switch does not prevent the enrolment process from using DNS discovery to synchronize the time. I suppose that switch is only used for setting the NTP server to use if one wishes to configure NTPD. (Besides not everyone opts to use NTPD on clients - some use an ntpdate job - so fixed-server time synchronization during enrolment should also be possible when using -N/--no-ntp) One last thing is that when using the --server option multiple times, it seems the order in sssd.conf is reversed. Example if I specify --server node1 --server node2, in sssd.conf I will end up with: ipa_server = node2, node1 Therefore I specify the servers to begin with in reverse order, in order to have them configured in the desired order. Regards John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed
Hi We found out recently that an IPA server which we upgraded some time ago from EL6.2/IPA 2.1 to EL6.3/IPA 2.2, reported the following errors: ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed ERROR Upgrade failed with attribute idnsAllowQuery not allowed The latter error we resolved by applying the patch found @ https://fedorahosted.org/freeipa/ticket/2440 (in fact we used this fix on another server in the past). Unfortunately we do not have a solution for the first error (related to ipaSELinuxUserMapOrder). Any ideas? We do have plans to upgrade the mentioned server to EL 6.4 / IPA 3.0, but I doubt this would be safe to do before we resolve the above error first. Regards John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install: done remotely, DNS discovery and multiple servers
Hi Many thanks for the feedback and bringing those tickets to my attention. I tried the 'ipa-getcert resubmit' before posting this, but it did not help. The status remained NEED_CSR. I'll try a few other things which come to mind. Regards John On Tue, May 7, 2013 at 10:50 PM, Rob Crittenden rcrit...@redhat.com wrote: John Blaut wrote: Hi Since EL 6.4, executing ipa-client-install over SSH i.e. 'ssh client ipa-client-install params', results in an issue with the host certificate. The output returns the following error during the: 'ipa-getcert request -d /etc/pki/nssdb' stage: TLS: could not close certdb slot - error -8018:Unknown PKCS #11 error. TLS: could not shutdown NSS - error -8053:NSS could not shutdown The host certificate remains in state: 'status: NEED_CSR' when checking with ipa-getcert list I'm not able to reproduce this. You might try: ipa-getcert resubmit -i requestid post-install to see if it goes out of NEED_CSR. In EL6.2 and EL6.3 this was not an issue. Perhaps you may reproduce this and advise. In order to work around this, I end up having to run ipa-client-install locally on the client. Also, with 6.4, thanks to the --fixed-primary switch we can now statically set specific IPA servers to use for a given client, instead of rely on DNS (SRV records) discovery. Before this feature we would need to patch the sssd.conf manually and restart SSSD, as ipa-client-install would remain stuck since the given client via SRV discovery would attempt using an IPA server it does not have access to. Now we longer have this issue, however ipa-client-install still picks the NTP server with which it should synchronize time during the enrolment process via DNS discovery. In the past ipa-client-install would 'give up' after 3 attempts or so, but now it keeps attempting until it encounters a reachable IPA NTP server. In an environment where there is a significant amount of IPA servers installed and distributed in different places where access is restricted by location, it can take some time until the reachable IPA/NTP server for a given client/location is found. A suggestion would be that if one goes for the --fixed-primary + --server options, then the omission of DNS discovery should not only apply to the IPA service but also for time synchronization. In most cases chances are that if one opts to use specific servers for IPA, one probably also wants to use specific servers for NTP. Or for added flexibility, provide another switch to select a specifc server to synchronize time with during the enrolment process. FYI, use of the --ntp-server switch does not prevent the enrolment process from using DNS discovery to synchronize the time. I suppose that switch is only used for setting the NTP server to use if one wishes to configure NTPD. (Besides not everyone opts to use NTPD on clients - some use an ntpdate job - so fixed-server time synchronization during enrolment should also be possible when using -N/--no-ntp) We have a number of tickets against NTP. There is some amount of overlap, but it doesn't seem to cove everything. Specifically tickets https://fedorahosted.org/**freeipa/ticket/3092https://fedorahosted.org/freeipa/ticket/3092, https://fedorahosted.org/**freeipa/ticket/2992https://fedorahosted.org/freeipa/ticket/2992and https://fedorahosted.org/**freeipa/ticket/1954https://fedorahosted.org/freeipa/ticket/1954 If we've missed anything any chance you can open a ticket (or tickets) for the new features? One last thing is that when using the --server option multiple times, it seems the order in sssd.conf is reversed. Example if I specify --server node1 --server node2, in sssd.conf I will end up with: ipa_server = node2, node1 Therefore I specify the servers to begin with in reverse order, in order to have them configured in the desired order. Fixed upstream https://fedorahosted.org/**freeipa/ticket/3418https://fedorahosted.org/freeipa/ticket/3418 regards rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed
Hi Thanks for the feedback. It seems the attributeType was already there. Nevertheless I tried your suggested fix but I did not help. ipa config-show and likewise the UI does not show SELinux related settings. Regards John On Tue, May 7, 2013 at 11:51 PM, Rob Crittenden rcrit...@redhat.com wrote: John Blaut wrote: Hi We found out recently that an IPA server which we upgraded some time ago from EL6.2/IPA 2.1 to EL6.3/IPA 2.2, reported the following errors: ERROR Update failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed ERROR Upgrade failed with attribute idnsAllowQuery not allowed The latter error we resolved by applying the patch found @ https://fedorahosted.org/**freeipa/ticket/2440https://fedorahosted.org/freeipa/ticket/2440(in fact we used this fix on another server in the past). Unfortunately we do not have a solution for the first error (related to ipaSELinuxUserMapOrder). Any ideas? We do have plans to upgrade the mentioned server to EL 6.4 / IPA 3.0, but I doubt this would be safe to do before we resolve the above error first. Updating might be fine, but it shouldn't be too hard to fix first. I'd start by getting the current schema: ldapsearch -x -b cn=schema objectclasses attributetypes /path/to/some/file See if ipaSELinuxUserMapOrder is defined as an attributeType. It looks like there is an error in the update file that adds this attribute, so it may not be there. Look in /usr/share/ipa/updates/10-**selinuxusermap.update and you'll see this line duplicated: X-ORIGIN 'IPA v3') If so, I'd try to remove the extra line and run: ipa-ldap-updater /usr/share/ipa/updates/10-**selinuxusermap.update That should fix it. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Error 4205 attribute idnsAllowTransfer not allowed
Hi I am following the same issue with Robert. In /etc/dirsrv/slapd-DOMAIN/schema/99user.ldif we can see that these new attributes have been added. Unfortunately I couldn't verify using ldapsearch on 'cn=schema' to see if this is indeed the case as well within the LDAP data. However if I browse other pre-existing DNS zones using ldapsearch I see that these already have the two attributes in place, so I guess the update procedure managed to insert them somehow: idnsAllowQuery: any; idnsAllowTransfer: none; So we are a bit confused that when trying to add a new zone, we get errors due to these attributes. This is also preventing us to add new replicas (which require new reverse zones). Regards John On Mon, Jul 30, 2012 at 2:57 PM, Simo Sorce s...@redhat.com wrote: On Mon, 2012-07-30 at 12:11 +0200, Robert Bowell wrote: Hi Simo, Thanks for your reply. Yes the IPA server has been updated from 2.1 to 2.2. Prior to the update, DNS zones could be created without any issues. I have also noticed that the command 'ipa ping' is displaying the incorrect IPA server version (IPA server version 2.1.90.rc1. API version 2.34) when infact the IPA server version 2.2.x should be displayed. This is odd, have you restarted httpd since the update ? The symptom below seem to suggest somethinhg went wrong in updating the DNS schema where we added a few attributes to allow zone transfers. Can you check the ipaserver-upgrade.log file and see if there are any errors in there ? Simo. Regards, Robert.. On 27 July 2012 17:29, Simo Sorce s...@redhat.com wrote: On Thu, 2012-07-26 at 09:47 +0200, Robert Bowell wrote: Hi, I'm encountering a strange problem.. upon trying to add a new DNS zone the following message is being displayed attribute idnsAllowTransfer not allowed and the DNS entry is not created. Has any one ever encountered such a problem if so what needs to be done to resolve it ? IPA server version 2.1.3. API version 2.13 Was this server upgraded from a 2.0.x one ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Simo Sorce * Red Hat, Inc * New York ___ 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 Error 4205 attribute idnsAllowTransfer not allowed
Hi Martin Thanks a lot for you reply. We applied the LDIF patch and now we managed to add new zones. Many thanks!! Yes, you understood well that the DNS zones already had these attributes defined. However using the ldapsearch query from the ticket, these attributes did not show up in the current schema (which is why we then proceeded with the patch which fixed the problem). It is strange how the attributes managed to make their way in the existing DNS zones when they were not supported in the schema. If it helps, after applying the patch what we also noticed is that in UI, the allow query and transfer options now show up as editable form elements. Before they were not editable but just printed values. Thanks again. Regards John On Mon, Jul 30, 2012 at 5:26 PM, Martin Kosek mko...@redhat.com wrote: On 07/30/2012 03:21 PM, John Blaut wrote: Hi I am following the same issue with Robert. In /etc/dirsrv/slapd-DOMAIN/schema/99user.ldif we can see that these new attributes have been added. Hello John, I assume that the new attributes were not added to the MAY list in idnsZone objectclass due to an issue with IPA upgrade which is already described in the following ticket: https://fedorahosted.org/freeipa/ticket/2440 The ticket should contain more information about the issue and also an LDIF that should workaround it until a fix is released. Unfortunately I couldn't verify using ldapsearch on 'cn=schema' to see if this is indeed the case as well within the LDAP data. However if I browse other pre-existing DNS zones using ldapsearch I see that these already have the two attributes in place, so I guess the update procedure managed to insert them somehow: idnsAllowQuery: any; idnsAllowTransfer: none; If I understand it correctly, you have existing DNS zones with there attributes defined? I assume this would mean that idnsZone objectclass has the attribute list updated. But then it is quite strange that you get the 'idnsAllowTransfer not allowed' error. Martin So we are a bit confused that when trying to add a new zone, we get errors due to these attributes. This is also preventing us to add new replicas (which require new reverse zones). Regards John On Mon, Jul 30, 2012 at 2:57 PM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Mon, 2012-07-30 at 12:11 +0200, Robert Bowell wrote: Hi Simo, Thanks for your reply. Yes the IPA server has been updated from 2.1 to 2.2. Prior to the update, DNS zones could be created without any issues. I have also noticed that the command 'ipa ping' is displaying the incorrect IPA server version (IPA server version 2.1.90.rc1. API version 2.34) when infact the IPA server version 2.2.x should be displayed. This is odd, have you restarted httpd since the update ? The symptom below seem to suggest somethinhg went wrong in updating the DNS schema where we added a few attributes to allow zone transfers. Can you check the ipaserver-upgrade.log file and see if there are any errors in there ? Simo. Regards, Robert.. On 27 July 2012 17:29, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Thu, 2012-07-26 at 09:47 +0200, Robert Bowell wrote: Hi, I'm encountering a strange problem.. upon trying to add a new DNS zone the following message is being displayed attribute idnsAllowTransfer not allowed and the DNS entry is not created. Has any one ever encountered such a problem if so what needs to be done to resolve it ? IPA server version 2.1.3. API version 2.13 Was this server upgraded from a 2.0.x one ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto: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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
