Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On 09/11/2014 10:24 PM, Martin Kosek wrote: On 09/11/2014 08:49 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: On 09/11/2014 05:37 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: Hello, We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings cause older SSSD clients to fail as they get returned an LDAP deref call results without objectclass attribute and just with entryusn attribute. Details in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be more tolerant in this case, it still breaks old clients which we should prevent. There are 2 ways how to fix I currently see: 1) Return objectclass for any entry, just like we do with operational attributes This would include adding objectclass to System: Read Timestamp and USN Operational Attributes. However, I am rather cautious about this approach as even though objectclass does not usually carry a secret information, we could still leak some information about our DIT to unprivileged user. Our DIT is public and known, I see no problem. I rather meant the LDAP tree and it's contents (custom groups, sudo rules, roles, ...). I did one more test and found out we cannot do this as it would undermine the ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch returns every object even if no other attribute is returned: # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # User Administrators, privileges, pbac, mkosek-fedora20.test dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test objectClass: top objectClass: groupofnames objectClass: nestedgroup ... It would not show any more info before that, but even the list of permissions, privileges and roles along with it's names is a leaked information. 2) Show objectclass+operational attributes in our Read ACIs Other way I see is to update *all* our Read permissions allowing reading objectclass attribute and also allow the chosen LDAP operational attribute. This would let the LDAP caller to always get either all these discussed attributes but none at all. Do we want to do this? Any other (better) idea how to approach it? I honestly am not sure I understand the distinction between 1 and 2, can you provide the actual ACIs or a behavior example ? Simo. Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) running LDAP deref call gets entryusn from object it does not have a read access to: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # memberof: entryusn=845;cn=replication administrators,cn=privileges,cn=pba c,dc=mkosek-fedora20,dc=test # memberof: entryusn=75;cn=add replication agreements,cn=permissions,cn=pba c,dc=mkosek-fedora20,dc=test ... This confuses SSSD (sees entryusn but does not see objectclass attribute) + may give out some information we do not want to give out. Fortunately, bare ldapsearch does not show anything: # ldapsearch -h `hostname` -Y GSSAPI -b cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test entryusn SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: entryusn # # search result search: 4 result: 0 Success # numResponses: 1 The idea behind Option 1 was to add ACI to allow reading objectclass attribute globally, for our entire tree. (as noted above, not an option). The idea behind Option 2 was to: - remove global ACI allowing reading entryusn (System: Read Timestamp and USN Operational Attributes) Removing a default ACI is difficult (read: new code that could go wrong) if we want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always add it back. Perhaps we should just say in the release notes that people should remove it manually if they're upgrading from 4.0.2? - update all our Read permissions to allow entryusn Then for example, if user (SSSD) is allowed to read RBAC role objects, he would not be able to read either objectclass or entryusn attributes. This means users would be only allowed to read entryusn for objects that they can really read (i.e. for objects where they can read at least objectclass). Did that clarify the options? Of course, there is still option 3) to close as wontfix and let older SSSDs be incompatible with FreeIPA 4.0+. No, 3
Re: [Freeipa-devel] FreeIPA 4.0.3?
On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: On 09/11/2014 04:31 PM, Petr Viktorin wrote: On 09/11/2014 04:26 PM, Martin Kosek wrote: ... Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. what do you mean by no such issues ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute allowweakciphers not allowed I think you simply use a wrong config name - have extra s in the end. It is defined as allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off] Also, do we really need to put it to off in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to on (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On 09/12/2014 09:35 AM, Petr Viktorin wrote: On 09/11/2014 10:24 PM, Martin Kosek wrote: On 09/11/2014 08:49 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: On 09/11/2014 05:37 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: Hello, We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings cause older SSSD clients to fail as they get returned an LDAP deref call results without objectclass attribute and just with entryusn attribute. Details in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be more tolerant in this case, it still breaks old clients which we should prevent. There are 2 ways how to fix I currently see: 1) Return objectclass for any entry, just like we do with operational attributes This would include adding objectclass to System: Read Timestamp and USN Operational Attributes. However, I am rather cautious about this approach as even though objectclass does not usually carry a secret information, we could still leak some information about our DIT to unprivileged user. Our DIT is public and known, I see no problem. I rather meant the LDAP tree and it's contents (custom groups, sudo rules, roles, ...). I did one more test and found out we cannot do this as it would undermine the ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch returns every object even if no other attribute is returned: # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # User Administrators, privileges, pbac, mkosek-fedora20.test dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test objectClass: top objectClass: groupofnames objectClass: nestedgroup ... It would not show any more info before that, but even the list of permissions, privileges and roles along with it's names is a leaked information. 2) Show objectclass+operational attributes in our Read ACIs Other way I see is to update *all* our Read permissions allowing reading objectclass attribute and also allow the chosen LDAP operational attribute. This would let the LDAP caller to always get either all these discussed attributes but none at all. Do we want to do this? Any other (better) idea how to approach it? I honestly am not sure I understand the distinction between 1 and 2, can you provide the actual ACIs or a behavior example ? Simo. Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) running LDAP deref call gets entryusn from object it does not have a read access to: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # memberof: entryusn=845;cn=replication administrators,cn=privileges,cn=pba c,dc=mkosek-fedora20,dc=test # memberof: entryusn=75;cn=add replication agreements,cn=permissions,cn=pba c,dc=mkosek-fedora20,dc=test ... This confuses SSSD (sees entryusn but does not see objectclass attribute) + may give out some information we do not want to give out. Fortunately, bare ldapsearch does not show anything: # ldapsearch -h `hostname` -Y GSSAPI -b cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test entryusn SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: entryusn # # search result search: 4 result: 0 Success # numResponses: 1 The idea behind Option 1 was to add ACI to allow reading objectclass attribute globally, for our entire tree. (as noted above, not an option). The idea behind Option 2 was to: - remove global ACI allowing reading entryusn (System: Read Timestamp and USN Operational Attributes) Removing a default ACI is difficult (read: new code that could go wrong) if we want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always add it back. Perhaps we should just say in the release notes that people should remove it manually if they're upgrading from 4.0.2? Well, I am not convinced that everyone reads the release notes, so I would rather delete this permission in 4.0.3. Hopefully, there won't be many 4.0.2 users. It seems as a lesser evil to me than having SSSD clients broken. - update all our Read permissions to allow entryusn Then for example, if user (SSSD) is allowed to read RBAC role objects, he would not be able to read either objectclass or entryusn attributes. This means users would be only
Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On Fri, 12 Sep 2014, Martin Kosek wrote: Operational Attributes) Removing a default ACI is difficult (read: new code that could go wrong) if we want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always add it back. Perhaps we should just say in the release notes that people should remove it manually if they're upgrading from 4.0.2? Well, I am not convinced that everyone reads the release notes, so I would rather delete this permission in 4.0.3. Hopefully, there won't be many 4.0.2 users. It seems as a lesser evil to me than having SSSD clients broken. If we are going to replace other ACIs by adding to them a right to read these attributes, then removing a separate default ACI is not a problem, isn't it? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On 09/12/2014 09:48 AM, Alexander Bokovoy wrote: On Fri, 12 Sep 2014, Martin Kosek wrote: Operational Attributes) Removing a default ACI is difficult (read: new code that could go wrong) if we want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always add it back. Perhaps we should just say in the release notes that people should remove it manually if they're upgrading from 4.0.2? Well, I am not convinced that everyone reads the release notes, so I would rather delete this permission in 4.0.3. Hopefully, there won't be many 4.0.2 users. It seems as a lesser evil to me than having SSSD clients broken. If we are going to replace other ACIs by adding to them a right to read these attributes, then removing a separate default ACI is not a problem, isn't it? It's not much of a policy problem, it's just adding new code this late in the cycle: The permission updater doesn't yet have a mechanism to remove a permission, so I'm writing it now. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA 4.0.3?
On 09/12/2014 09:37 AM, Martin Kosek wrote: On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: On 09/11/2014 04:31 PM, Petr Viktorin wrote: On 09/11/2014 04:26 PM, Martin Kosek wrote: ... Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. what do you mean by no such issues ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute allowweakciphers not allowed I think you simply use a wrong config name - have extra s in the end. It is defined as that typo was already in my first draft of the patch, sorry allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off] Also, do we really need to put it to off in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to on (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. could there be an upgrade from a install not yet using that params. should only:allowWeakCipher be replaced by addifnew ? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA 4.0.3?
On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: On 09/12/2014 09:37 AM, Martin Kosek wrote: On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: On 09/11/2014 04:31 PM, Petr Viktorin wrote: On 09/11/2014 04:26 PM, Martin Kosek wrote: ... Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. what do you mean by no such issues ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute allowweakciphers not allowed I think you simply use a wrong config name - have extra s in the end. It is defined as that typo was already in my first draft of the patch, sorry allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off] Also, do we really need to put it to off in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to on (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. could there be an upgrade from a install not yet using that params. should only:allowWeakCipher be replaced by addifnew ? You can try default:allowWeakCiphers: off - it would set the attribute to off if it was not there before. Given you are probably working on updated version, I would also recommend following http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 as I saw couple nitpicks with your patch - ticket number in patch description and not in it's body - bad From field - I would rather expect it to be Ludwig Krispenz lkris...@redhat.com than lkrispen lkris...@redhat.com Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On 09/11/2014 10:24 PM, Martin Kosek wrote: On 09/11/2014 08:49 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: On 09/11/2014 05:37 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: Hello, We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings cause older SSSD clients to fail as they get returned an LDAP deref call results without objectclass attribute and just with entryusn attribute. Details in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be more tolerant in this case, it still breaks old clients which we should prevent. There are 2 ways how to fix I currently see: 1) Return objectclass for any entry, just like we do with operational attributes This would include adding objectclass to System: Read Timestamp and USN Operational Attributes. However, I am rather cautious about this approach as even though objectclass does not usually carry a secret information, we could still leak some information about our DIT to unprivileged user. Our DIT is public and known, I see no problem. I rather meant the LDAP tree and it's contents (custom groups, sudo rules, roles, ...). I did one more test and found out we cannot do this as it would undermine the ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch returns every object even if no other attribute is returned: # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # User Administrators, privileges, pbac, mkosek-fedora20.test dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test objectClass: top objectClass: groupofnames objectClass: nestedgroup ... It would not show any more info before that, but even the list of permissions, privileges and roles along with it's names is a leaked information. 2) Show objectclass+operational attributes in our Read ACIs Other way I see is to update *all* our Read permissions allowing reading objectclass attribute and also allow the chosen LDAP operational attribute. This would let the LDAP caller to always get either all these discussed attributes but none at all. Do we want to do this? Any other (better) idea how to approach it? I honestly am not sure I understand the distinction between 1 and 2, can you provide the actual ACIs or a behavior example ? Simo. Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) running LDAP deref call gets entryusn from object it does not have a read access to: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # memberof: entryusn=845;cn=replication administrators,cn=privileges,cn=pba c,dc=mkosek-fedora20,dc=test # memberof: entryusn=75;cn=add replication agreements,cn=permissions,cn=pba c,dc=mkosek-fedora20,dc=test ... This confuses SSSD (sees entryusn but does not see objectclass attribute) + may give out some information we do not want to give out. Fortunately, bare ldapsearch does not show anything: # ldapsearch -h `hostname` -Y GSSAPI -b cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test entryusn SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: entryusn # # search result search: 4 result: 0 Success # numResponses: 1 The idea behind Option 1 was to add ACI to allow reading objectclass attribute globally, for our entire tree. (as noted above, not an option). The idea behind Option 2 was to: - remove global ACI allowing reading entryusn (System: Read Timestamp and USN Operational Attributes) - update all our Read permissions to allow entryusn Then for example, if user (SSSD) is allowed to read RBAC role objects, he would not be able to read either objectclass or entryusn attributes. This means users would be only allowed to read entryusn for objects that they can really read (i.e. for objects where they can read at least objectclass). Did that clarify the options? Of course, there is still option 3) to close as wontfix and let older SSSDs be incompatible with FreeIPA 4.0+. No, 3 is definitely not on the table, I would rather do 1, but I guess 2 is the only good way for now ? Simo. Yeah - 1) would be easy to implement, but it would be a step back in our ACI model (global allowing ACI again...). Something based on 2)
Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On 09/12/2014 10:27 AM, thierry bordaz wrote: On 09/11/2014 10:24 PM, Martin Kosek wrote: On 09/11/2014 08:49 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: On 09/11/2014 05:37 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: Hello, We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings cause older SSSD clients to fail as they get returned an LDAP deref call results without objectclass attribute and just with entryusn attribute. Details in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be more tolerant in this case, it still breaks old clients which we should prevent. There are 2 ways how to fix I currently see: 1) Return objectclass for any entry, just like we do with operational attributes This would include adding objectclass to System: Read Timestamp and USN Operational Attributes. However, I am rather cautious about this approach as even though objectclass does not usually carry a secret information, we could still leak some information about our DIT to unprivileged user. Our DIT is public and known, I see no problem. I rather meant the LDAP tree and it's contents (custom groups, sudo rules, roles, ...). I did one more test and found out we cannot do this as it would undermine the ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch returns every object even if no other attribute is returned: # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # User Administrators, privileges, pbac, mkosek-fedora20.test dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test objectClass: top objectClass: groupofnames objectClass: nestedgroup ... It would not show any more info before that, but even the list of permissions, privileges and roles along with it's names is a leaked information. 2) Show objectclass+operational attributes in our Read ACIs Other way I see is to update *all* our Read permissions allowing reading objectclass attribute and also allow the chosen LDAP operational attribute. This would let the LDAP caller to always get either all these discussed attributes but none at all. Do we want to do this? Any other (better) idea how to approach it? I honestly am not sure I understand the distinction between 1 and 2, can you provide the actual ACIs or a behavior example ? Simo. Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) running LDAP deref call gets entryusn from object it does not have a read access to: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # memberof: entryusn=845;cn=replication administrators,cn=privileges,cn=pba c,dc=mkosek-fedora20,dc=test # memberof: entryusn=75;cn=add replication agreements,cn=permissions,cn=pba c,dc=mkosek-fedora20,dc=test ... This confuses SSSD (sees entryusn but does not see objectclass attribute) + may give out some information we do not want to give out. Fortunately, bare ldapsearch does not show anything: # ldapsearch -h `hostname` -Y GSSAPI -b cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test entryusn SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: entryusn # # search result search: 4 result: 0 Success # numResponses: 1 The idea behind Option 1 was to add ACI to allow reading objectclass attribute globally, for our entire tree. (as noted above, not an option). The idea behind Option 2 was to: - remove global ACI allowing reading entryusn (System: Read Timestamp and USN Operational Attributes) - update all our Read permissions to allow entryusn Then for example, if user (SSSD) is allowed to read RBAC role objects, he would not be able to read either objectclass or entryusn attributes. This means users would be only allowed to read entryusn for objects that they can really read (i.e. for objects where they can read at least objectclass). Did that clarify the options? Of course, there is still option 3) to close as wontfix and let older SSSDs be incompatible with FreeIPA 4.0+. No, 3 is definitely not on the table, I would rather do 1, but I guess 2 is the only good way for now ? Simo. Yeah - 1) would be easy to implement, but it would be a step back in our ACI model (global allowing ACI again...). Something based on 2) is the
Re: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses.
On 09/08/2014 05:56 PM, Martin Basti wrote: On 02/09/14 16:55, David Kupka wrote: The patch now depends on freeipa-dkupka-0012 as both modifies the same part of code. freeipa-dkupka-0012 is now accepted and merged upstream so there is no need to take this dependency into account. On 09/02/2014 10:29 AM, David Kupka wrote: Forget to add str() conversion to some places when removing map(). Now it should be working again. On 08/27/2014 02:24 PM, David Kupka wrote: Patch modified according to jcholast's personally-delivered feedback: 1) use action='append' instead of that ugly parsing 2) do not use map(), FreeIPA doesn't like it On 08/25/2014 05:04 PM, David Kupka wrote: https://fedorahosted.org/freeipa/ticket/3575 Also should fix https://bugzilla.redhat.com/show_bug.cgi?id=1128380 as installation is no longer interrupted when multiple IPs are resolved. But it does not add the option to change the IP address during second run. I haven't tested it yet, I only take a look because there may be conflict with 'dns root zone support' refactoring 1) +for ns_ip_address in nameserver_ip_address: +add_zone(self.domain, self.zonemgr, dns_backup=self.dns_backup, +ns_hostname=api.env.host, ns_ip_address=ns_ip_address, +force=True) Are you sure this will work? Domain name is the same, so no new zone will be created (DuplicateEntry exception is handled inside add_zone function). IMO you should call add_zone only once. Fixed, thanks. BTW: I will change the add_zone function in refactoring , ns_hostname wil be remove, and ns_ip_address will take an p+ipv6 address 2) +resolv_txt = '' +for ip_address in self.ip_address: +resolv_txt += search +self.domain+\nnameserver +str(ip_address)+\n There is multiple search statements. search example.com nameserver 192.168.1.1 search example.com nameserver 2001:db8::1 ... and also there si a limit of namesevers which can be in resolv.conf, but I dont know if we care, statements over limit should be just ignored. http://linux.die.net/man/5/resolv.conf Since now, only localhost addresses (::1, 127.0.0.1) are placed inside this file when DNS server is part of the installation. 3) self.ip_address is confusing for me, I'm expecting only one address. Could it be ip_addresses or ip_address_list? Ask the framework gurus :-) Changed to plural as there are other variables named this way. -- David Kupka From 7c5bc742b08403a1a6d878b21dc725a2f71f48da Mon Sep 17 00:00:00 2001 From: David Kupka dku...@redhat.com Date: Wed, 27 Aug 2014 13:50:21 +0200 Subject: [PATCH] Detect and configure all usable IP addresses. Find, verify and configure all IP addresses that can be used to reach the server FreeIPA is being installed on. Ignore some IP address only if user specifies subset of detected addresses using --ip-address option. This change simplyfies FreeIPA installation on multihomed and dual-stacked servers. https://fedorahosted.org/freeipa/ticket/3575 --- install/tools/ipa-replica-install| 69 ++- install/tools/ipa-server-install | 63 - ipaserver/install/bindinstance.py| 74 +++-- ipaserver/install/installutils.py| 94 ipaserver/install/ipa_replica_prepare.py | 66 -- 5 files changed, 207 insertions(+), 159 deletions(-) diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index 7c9e27e2b9d248653681c85236d3541ec9ab0ec7..6ca78a9c60d61d811ab09eb898966fb55bb3daf6 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -67,8 +67,8 @@ def parse_options(): default=False, help=configure a dogtag CA) basic_group.add_option(--setup-kra, dest=setup_kra, action=store_true, default=False, help=configure a dogtag KRA) -basic_group.add_option(--ip-address, dest=ip_address, - type=ip, ip_local=True, +basic_group.add_option(--ip-address, dest=ip_addresses, + type=ip, ip_local=True, action=append, default=[], help=Replica server IP Address) basic_group.add_option(-p, --password, dest=password, sensitive=True, help=Directory Manager (existing master) password) @@ -112,7 +112,8 @@ def parse_options(): type=ip, help=Add a DNS forwarder) dns_group.add_option(--no-forwarders, dest=no_forwarders, action=store_true, default=False, help=Do not add any DNS forwarders, use root servers instead) -dns_group.add_option(--reverse-zone, dest=reverse_zone, help=The reverse DNS zone to use) +dns_group.add_option(--reverse-zone, dest=reverse_zones, default=[], + action=append, help=The reverse DNS zone to use) dns_group.add_option(--no-reverse, dest=no_reverse,
Re: [Freeipa-devel] FreeIPA 4.0.3?
On 09/12/2014 10:25 AM, Martin Kosek wrote: On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: On 09/12/2014 09:37 AM, Martin Kosek wrote: On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: On 09/11/2014 04:31 PM, Petr Viktorin wrote: On 09/11/2014 04:26 PM, Martin Kosek wrote: ... Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. what do you mean by no such issues ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute allowweakciphers not allowed I think you simply use a wrong config name - have extra s in the end. It is defined as that typo was already in my first draft of the patch, sorry allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off] Also, do we really need to put it to off in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to on (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. could there be an upgrade from a install not yet using that params. should only:allowWeakCipher be replaced by addifnew ? You can try default:allowWeakCiphers: off - it would set the attribute to off if it was not there before. Given you are probably working on updated version, I would also recommend following http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 as I saw couple nitpicks with your patch - ticket number in patch description and not in it's body - bad From field - I would rather expect it to be Ludwig Krispenz lkris...@redhat.com than lkrispen lkris...@redhat.com Thanks, Martin Hello, any update on this front? Are you or Nathaniel updating the patch? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base
please review attached patch for ticket:
https://fedorahosted.org/freeipa/ticket/4395
use new options in 389-ds to configure enabled ciphers
From e3ab55b01c7d800ffe9f4a43f328087d97e328db Mon Sep 17 00:00:00 2001
From: Ludwig Krispenz lkris...@redhat.com
Date: Fri, 12 Sep 2014 12:43:31 +0200
Subject: [PATCH] Update SSL ciphers configured in 389-ds-base
use configuration parameters to enable ciphers provided by NSS
and not considered weak.
This requires 389-ds version 1.3.3.2 or later
https://fedorahosted.org/freeipa/ticket/4395
---
freeipa.spec.in | 6 +++---
install/updates/20-sslciphers.update | 6 ++
install/updates/Makefile.am | 1 +
ipaserver/install/dsinstance.py | 7 ++-
4 files changed, 12 insertions(+), 8 deletions(-)
create mode 100644 install/updates/20-sslciphers.update
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 0e43ee755e5ada38b8c9260d133d3d8434591470..8d66bdc3cf221d025ecea19c131f075a54dc32d9 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -18,7 +18,7 @@ Source0:freeipa-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%if ! %{ONLY_CLIENT}
-BuildRequires: 389-ds-base-devel = 1.3.2.16
+BuildRequires: 389-ds-base-devel = 1.3.3.2
BuildRequires: svrcore-devel
BuildRequires: policycoreutils = %{POLICYCOREUTILSVER}
BuildRequires: systemd-units
@@ -87,7 +87,7 @@ Group: System Environment/Base
Requires: %{name}-python = %{version}-%{release}
Requires: %{name}-client = %{version}-%{release}
Requires: %{name}-admintools = %{version}-%{release}
-Requires: 389-ds-base = 1.3.2.20
+Requires: 389-ds-base = 1.3.3.2
Requires: openldap-clients 2.4.35-4
Requires: nss = 3.14.3-12.0
Requires: nss-tools = 3.14.3-12.0
@@ -124,7 +124,7 @@ Requires: zip
Requires: policycoreutils = %{POLICYCOREUTILSVER}
Requires: tar
Requires(pre): certmonger = 0.75.13
-Requires(pre): 389-ds-base = 1.3.2.20
+Requires(pre): 389-ds-base = 1.3.3.2
Requires: fontawesome-fonts
Requires: open-sans-fonts
diff --git a/install/updates/20-sslciphers.update b/install/updates/20-sslciphers.update
new file mode 100644
index ..b0c952f498bc89568029f1d01eaded4db1371c76
--- /dev/null
+++ b/install/updates/20-sslciphers.update
@@ -0,0 +1,6 @@
+# change configured ciphers
+# the result of this update will be that all ciphers
+# provided by NSS which ar not weak will be enabled
+dn: cn=encryption,cn=config
+only:nsSSL3Ciphers: +all
+addifnew:allowWeakCipher: off
diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am
index a6d24b94f040293ab76866f9651079d08d4ac297..b137ffedcaf1278478a2da0cac99f5850e8efd56 100644
--- a/install/updates/Makefile.am
+++ b/install/updates/Makefile.am
@@ -14,6 +14,7 @@ app_DATA =\
20-indices.update \
20-nss_ldap.update \
20-replication.update \
+ 20-sslciphers.update \
20-syncrepl.update \
20-user_private_groups.update \
20-winsync_index.update \
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index 61ea52a6bbdfc1b0d5fbc2baa87af92895541069..c15ef2ceb10b5f8815039e07e95d6fbac5a081c4 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -655,11 +655,8 @@ class DsInstance(service.Service):
conn.do_simple_bind(DN(('cn', 'directory manager')), self.dm_password)
mod = [(ldap.MOD_REPLACE, nsSSLClientAuth, allowed),
- (ldap.MOD_REPLACE, nsSSL3Ciphers,
--rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,\
-+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,\
-+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,\
-+tls_rsa_export1024_with_des_cbc_sha)]
+ (ldap.MOD_REPLACE, nsSSL3Ciphers, +all),
+ (ldap.MOD_REPLACE, allowWeakCipher, off)]
conn.modify_s(DN(('cn', 'encryption'), ('cn', 'config')), mod)
mod = [(ldap.MOD_ADD, nsslapd-security, on)]
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn timestamp entries to individual permissions
https://fedorahosted.org/freeipa/ticket/4534 The entryusn and timestamp operational attributes are now automatically added to every read permission that targets objectclass, whether managed or user-created. The 'System: Read Timestamp and USN Operational Attributes', which was added for 4.0.2, is removed on upgrade. -- Petr³ From f794853264041cac730855c12ba96ab9cc564762 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Fri, 12 Sep 2014 09:59:52 +0200 Subject: [PATCH] permission plugin: Auto-add operational atttributes to read permissions The attributes entryusn, createtimestamp, and modifytimestamp should be readable whenever thir entry is, i.e. when we allow reading the objectclass. Automatically add them to every read permission that includes objectclass. https://fedorahosted.org/freeipa/ticket/4534 --- ACI.txt | 82 ipalib/plugins/permission.py | 8 +++ ipatests/test_xmlrpc/test_permission_plugin.py | 44 + ipatests/test_xmlrpc/test_realmdomains_plugin.py | 3 +- 4 files changed, 95 insertions(+), 42 deletions(-) diff --git a/ACI.txt b/ACI.txt index 2a3f582765b1ff1de9669f187adb9a57b19f938f..9a161a1839057198930c6e0f31a9bc3d491320ee 100644 --- a/ACI.txt +++ b/ACI.txt @@ -1,7 +1,7 @@ dn: cn=automember,cn=etc,dc=ipa,dc=example -aci: (targetattr = automemberdefaultgroup || automemberdisabled || automemberfilter || automembergroupingattr || automemberscope || cn || objectclass)(targetfilter = (objectclass=automemberdefinition))(version 3.0;acl permission:System: Read Automember Definitions;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Definitions,cn=permissions,cn=pbac,dc=ipa,dc=example;) +aci: (targetattr = automemberdefaultgroup || automemberdisabled || automemberfilter || automembergroupingattr || automemberscope || cn || createtimestamp || entryusn || modifytimestamp || objectclass)(targetfilter = (objectclass=automemberdefinition))(version 3.0;acl permission:System: Read Automember Definitions;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Definitions,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=automember,cn=etc,dc=ipa,dc=example -aci: (targetattr = automemberexclusiveregex || automemberinclusiveregex || automembertargetgroup || cn || description || objectclass)(targetfilter = (objectclass=automemberregexrule))(version 3.0;acl permission:System: Read Automember Rules;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Rules,cn=permissions,cn=pbac,dc=ipa,dc=example;) +aci: (targetattr = automemberexclusiveregex || automemberinclusiveregex || automembertargetgroup || cn || createtimestamp || description || entryusn || modifytimestamp || objectclass)(targetfilter = (objectclass=automemberregexrule))(version 3.0;acl permission:System: Read Automember Rules;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Rules,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=tasks,cn=config aci: (targetattr = *)(target = ldap:///cn=*,cn=automember rebuild membership,cn=tasks,cn=config)(version 3.0;acl permission:System: Read Automember Tasks;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Tasks,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=automount,dc=ipa,dc=example @@ -13,7 +13,7 @@ aci: (targetfilter = (objectclass=automount))(version 3.0;acl permission:Syst dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = (objectclass=nscontainer))(version 3.0;acl permission:System: Add Automount Locations;allow (add) groupdn = ldap:///cn=System: Add Automount Locations,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=automount,dc=ipa,dc=example -aci: (targetattr = automountinformation || automountkey || automountmapname || cn || description || objectclass)(version 3.0;acl permission:System: Read Automount Configuration;allow (compare,read,search) userdn = ldap:///anyone;;) +aci: (targetattr = automountinformation || automountkey || automountmapname || cn || createtimestamp || description || entryusn || modifytimestamp || objectclass)(version 3.0;acl permission:System: Read Automount Configuration;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = (objectclass=nscontainer))(version 3.0;acl permission:System: Remove Automount Locations;allow (delete) groupdn = ldap:///cn=System: Remove Automount Locations,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=automount,dc=ipa,dc=example @@ -23,7 +23,7 @@ aci: (targetattr = automountmapname || description)(targetfilter = (objectcla dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = (objectclass=automountmap))(version 3.0;acl permission:System: Remove Automount Maps;allow (delete) groupdn = ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=ipaconfig,cn=etc,dc=ipa,dc=example -aci: (targetattr = cn ||
Re: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks
On 11/09/14 21:58, Petr Spacek wrote: On 11.9.2014 18:34, Martin Basti wrote: On 11/09/14 15:57, Martin Basti wrote: On 11/09/14 11:59, Petr Spacek wrote: Hello, I was fighting with random crashes for couple of days ... and discovered that run_exclusive_enter()/isc_task_beginexclusive() usage was completely incorrect and didn't actually lock anything. This series of patches reworks internal locking (and related event system) to work around limitations of isc_task_beginexclusive() mechanism. It would be better to get rid of isc_task_beginexclusive() completely but IMHO it is not possible because of BIND's dns_view*() functions have to be guarded with it. Testing is going to be interesting because we are speaking about race conditions. I used ~ 100 DNS zones, each zone had ~ 100 random domain names inside with random A//TXT RRs. My LDIF is here: http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz I was able to randomly reproduce various crashes when BIND was running with more threads than usually. You can try to run BIND with this command (as root) and play games with -n parameter: $ export KRB5_KTNAME=/etc/named.keytab $ named -4 -g -u named -m record -n 10 Please test also the case where BIND receives SIGINT during start-up. It is possible to run BIND with commands above and wait for message: 11-Sep-2014 11:54:58.092 running At this point send SIGINT (CTRL+C) to BIND and see what happens. It could crash or deadlock. It is necessary to send the signal before BIND prints this message: 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 Let me know if you need any assistance. I need your assistance, I haven't been able to reproduce it. Martin I applied the patchset, and NACK I don't understand how I could possibly miss this. I was convinced that the patch set was thoroughly tested ... Anyway, attached patch should fix the problem you were facing. Please re-test it. Thank you! Petr^2 Spacek #1 If named is running and I randomly choose few zones and delete them, it causes named failure dig @localhost A r1.z12.test ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 @localhost A r1.z12.test ; (2 servers found) ;; global options: +cmd ;; connection timed out; no servers could be reached * SIGINT doesn't work * rndc doesn't work * DS worksSIGINT signal stops working. Output: snip 11-Sep-2014 11:26:37.495 client 127.0.0.1#62615: received notify for zone 'z99.test' ^C^C^C^C^C^C^C^C Process: named29125 1.1 2.9 789972 45976 pts/0Sl+ 11:26 0:02 named -4 -g -u named -m record -n 10 I have to kill it with kill -9 #2 same as #1 If new zone is added, #3 same as #1 If new record is added #4 same as #1 If record is deleted Functional ACK -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0291-0294] Fix locking to prevent crashes and deadlocks
On 12.9.2014 14:45, Martin Basti wrote: On 11/09/14 21:58, Petr Spacek wrote: On 11.9.2014 18:34, Martin Basti wrote: On 11/09/14 15:57, Martin Basti wrote: On 11/09/14 11:59, Petr Spacek wrote: Hello, I was fighting with random crashes for couple of days ... and discovered that run_exclusive_enter()/isc_task_beginexclusive() usage was completely incorrect and didn't actually lock anything. This series of patches reworks internal locking (and related event system) to work around limitations of isc_task_beginexclusive() mechanism. It would be better to get rid of isc_task_beginexclusive() completely but IMHO it is not possible because of BIND's dns_view*() functions have to be guarded with it. Testing is going to be interesting because we are speaking about race conditions. I used ~ 100 DNS zones, each zone had ~ 100 random domain names inside with random A//TXT RRs. My LDIF is here: http://people.redhat.com/~pspacek/a/2014/09/11/dns-test.ldif.xz I was able to randomly reproduce various crashes when BIND was running with more threads than usually. You can try to run BIND with this command (as root) and play games with -n parameter: $ export KRB5_KTNAME=/etc/named.keytab $ named -4 -g -u named -m record -n 10 Please test also the case where BIND receives SIGINT during start-up. It is possible to run BIND with commands above and wait for message: 11-Sep-2014 11:54:58.092 running At this point send SIGINT (CTRL+C) to BIND and see what happens. It could crash or deadlock. It is necessary to send the signal before BIND prints this message: 11-Sep-2014 11:55:11.707 zone z1.test/IN: loaded serial 1410429304 Let me know if you need any assistance. I need your assistance, I haven't been able to reproduce it. Martin ... Functional ACK Pushed to master: 1d23e27e0198cacdbbb14ac13ff039c33546d9af 09386eb446ac8d9c12110d21f2d4da36c1b792bf e7d8f6f175eae795c603eee00d06d5799b2d6c39 17a29e20406ad9db0b28fcb6ec4b02394385fe53 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0295-0296] Release 5.3
Hello,
Update NEWS for upcoming 5.3 release.
Pushed to master: b1a176d0b71127b428db3a901f736d1ca2ed6a65
Bump NVR to 5.3.
Pushed to master: 9886db5772a6635bdc33f718685b7df0ea1a3ea1
--
Petr^2 Spacek
From b1a176d0b71127b428db3a901f736d1ca2ed6a65 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 12 Sep 2014 15:10:48 +0200
Subject: [PATCH] Update NEWS for upcoming 5.3 release.
Signed-off-by: Petr Spacek pspa...@redhat.com
---
NEWS | 4
1 file changed, 4 insertions(+)
diff --git a/NEWS b/NEWS
index e5117116286dd61441b950073bfe8672012e278d..f9869ba447ff34bed0d42d514846f8a47e5be496 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,7 @@
+5.3
+
+[1] Internal locking was reworked to prevent crashes and deadlocks.
+
5.2
[1] Kerberos ticket expiration is now handled correctly.
--
1.9.3
From 9886db5772a6635bdc33f718685b7df0ea1a3ea1 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Fri, 12 Sep 2014 15:11:20 +0200
Subject: [PATCH] Bump NVR to 5.3.
Signed-off-by: Petr Spacek pspa...@redhat.com
---
configure.ac | 2 +-
contrib/bind-dyndb-ldap.spec | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2604819c399f3fe3fa547dd90fef61dea77f5b61..adb3b549e13f243d3f18adc91ddf766d036c4686 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.59])
-AC_INIT([bind-dyndb-ldap], [5.2], [freeipa-devel@redhat.com])
+AC_INIT([bind-dyndb-ldap], [5.3], [freeipa-devel@redhat.com])
AM_INIT_AUTOMAKE([-Wall foreign dist-bzip2])
diff --git a/contrib/bind-dyndb-ldap.spec b/contrib/bind-dyndb-ldap.spec
index bb23bcc27257af70c4c588bd4e5b4799b2089abb..70796e62e349a94fb97047d00e4f2b145576412d 100644
--- a/contrib/bind-dyndb-ldap.spec
+++ b/contrib/bind-dyndb-ldap.spec
@@ -1,7 +1,7 @@
%define VERSION %{version}
Name: bind-dyndb-ldap
-Version:5.2
+Version:5.3
Release:0%{?dist}
Summary:LDAP back-end plug-in for BIND
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0114-0115, 0120-0121] DNS: allow to add root zone '.'
On 03/09/14 12:45, Martin Basti wrote:
On 03/09/14 12:27, Martin Kosek wrote:
On 09/02/2014 05:46 PM, Petr Spacek wrote:
On 25.8.2014 14:52, Martin Basti wrote:
Patches attached.
Ticket: https://fedorahosted.org/freeipa/ticket/4149
There is a bug in bind-dyndb-ldap (or worse in dirsrv), which cause
the named
service is stopped after deleting zone.
Bug ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/138
Functional ACK, it works for me. It can be pushed if Python gurus
are okay with
the code.
Is it safe to commit the change given that bind-dyndb-ldap still
crash when .
is removed? Wouldn't it break our CI tests?
Maybe we should wait until fixed bind-dydnb-ldap is released.
Hopefully it
would be soon.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
It will broke tests, don't push it until bind-dyndb-ldap is fixed.
Currently I'm testing bind-dyndb-ldap related patch.
Added patches 120 and 121, which are required by DNS to work correctly.
Patches 120 and 121 add all DNS replicas to zone apex as NS,
--name-server option doesn't add NS record, only changes the SOA MNAME
attribute
Original and new patches attached.
--
Martin Basti
From 9ed12420bf52a2d2dab1f8cc4f1f6b1b5f86a801 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 22 Aug 2014 17:11:22 +0200
Subject: [PATCH 1/2] Fix DNS plugin to allow to add root zone
Ticket: https://fedorahosted.org/freeipa/ticket/4149
---
ipalib/plugins/dns.py | 53 ++-
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index 24b303d8405aa3b4a6e0474e75d0e46e6949860d..9c8d09856a57f12b0ff1a52c8f0277f7abb29cdd 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -1783,17 +1783,21 @@ class DNSZoneBase(LDAPObject):
zone = keys[-1]
assert isinstance(zone, DNSName)
assert zone.is_absolute()
-zone = zone.ToASCII()
+zone_a = zone.ToASCII()
+
+# special case when zone is the root zone ('.')
+if zone == DNSName.root:
+return super(DNSZoneBase, self).get_dn(zone_a, **options)
# try first relative name, a new zone has to be added as absolute
# otherwise ObjectViolation is raised
-zone = zone[:-1]
-dn = super(DNSZoneBase, self).get_dn(zone, **options)
+zone_a = zone_a[:-1]
+dn = super(DNSZoneBase, self).get_dn(zone_a, **options)
try:
self.backend.get_entry(dn, [''])
except errors.NotFound:
-zone = u%s. % zone
-dn = super(DNSZoneBase, self).get_dn(zone, **options)
+zone_a = u%s. % zone_a
+dn = super(DNSZoneBase, self).get_dn(zone_a, **options)
return dn
@@ -1825,6 +1829,8 @@ class DNSZoneBase(LDAPObject):
try:
api.Command['permission_del'](permission_name, force=True)
except errors.NotFound, e:
+if zone == DNSName.root: # special case root zone
+raise
# compatibility, older IPA versions which allows to create zone
# without absolute zone name
permission_name_rel = self.permission_name(
@@ -1988,20 +1994,21 @@ class DNSZoneBase_add_permission(LDAPQuery):
permission_name = self.obj.permission_name(keys[-1])
# compatibility with older IPA versions which allows relative zonenames
-permission_name_rel = self.obj.permission_name(
-keys[-1].relativize(DNSName.root)
-)
-try:
-api.Object['permission'].get_dn_if_exists(permission_name_rel)
-except errors.NotFound:
-pass
-else:
-# permission exists without absolute domain name
-raise errors.DuplicateEntry(
-message=_('permission %(value)s already exists') % {
-'value': permission_name
-}
+if keys[-1] != DNSName.root: # special case root zone
+permission_name_rel = self.obj.permission_name(
+keys[-1].relativize(DNSName.root)
)
+try:
+api.Object['permission'].get_dn_if_exists(permission_name_rel)
+except errors.NotFound:
+pass
+else:
+# permission exists without absolute domain name
+raise errors.DuplicateEntry(
+message=_('permission %(value)s already exists') % {
+'value': permission_name
+}
+)
permission = api.Command['permission_add_noaci'](permission_name,
ipapermissiontype=u'SYSTEM'
@@ -2417,12 +2424,14 @@ class dnszone_add(DNSZoneBase_add):
nameserver_ip_address)
# Add entry to
[Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile
I always forgot to install dogtag 10.2, so here is updated specfile.
COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/
Patch atached. ipa-4-1
--
Martin Basti
From 36de55fd8edc63c50cb6494a1a432eb1eb21fb44 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 12 Sep 2014 13:19:40 +0200
Subject: [PATCH] dogtag to spec.file
---
freeipa.spec.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 2e19733e5c1638896ca82b50463f35dd49fed6e5..b288405bb94ff25c53e762c7f727225323470733 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -115,8 +115,8 @@ Requires(post): systemd-units
Requires: selinux-policy = 3.12.1-179
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.47.7
-Requires: pki-ca = 10.1.1
-Requires: pki-kra = 10.1.1
+Requires: pki-ca = 10.2.0
+Requires: pki-kra = 10.2.0
%if 0%{?rhel}
Requires: subscription-manager
%endif
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile
On Fri, 12 Sep 2014, Martin Basti wrote: I always forgot to install dogtag 10.2, so here is updated specfile. COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ ACK if you fix the commit message (see below), NACK for the link, as dogtag 10.2 is going to Rawhide and F21. https://admin.fedoraproject.org/updates/FEDORA-2014-10296/dogtag-pki-10.2.0-2.fc21 https://admin.fedoraproject.org/updates/FEDORA-2014-10309/dogtag-pki-theme-10.2.0-1.fc21 https://admin.fedoraproject.org/updates/FEDORA-2014-10300/pki-core-10.2.0-1.fc21 https://admin.fedoraproject.org/updates/FEDORA-2014-10297/pki-console-10.2.0-1.fc21 They should have been pushed in the same update, though. Martin, can you please add a small blurb in the commit message that Dogtag 10.2 is required due to support of a Vault feature? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA 4.0.3?
On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote:
On 09/12/2014 10:25 AM, Martin Kosek wrote:
On 09/12/2014 10:13 AM, Ludwig Krispenz wrote:
On 09/12/2014 09:37 AM, Martin Kosek wrote:
On 09/12/2014 03:21 AM, Nathaniel McCallum wrote:
On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote:
On 09/11/2014 04:43 PM, Nathaniel McCallum wrote:
On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote:
On 09/11/2014 04:38 PM, Ludwig Krispenz wrote:
On 09/11/2014 04:31 PM, Petr Viktorin wrote:
On 09/11/2014 04:26 PM, Martin Kosek wrote:
...
Also, we will need to add the F21 389-ds-base build to FreeIPA
Copr:
http://copr.fedoraproject.org/coprs/mkosek/freeipa/
so that F20 users can upgrade to the newest FreeIPA. Are there any
known issues
in the F21 389-ds-base build that would prevent upstream FreeIPA
4.0.x to be
based on it?
If yes, we may need to include the patch in Fedora 21 downstream
only
after all..
We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we
couldn't include the patch even there.
There better be no such issues.
what do you mean by no such issues ? I don't think that 389/F21
will
be the first bug free software. At the moment Thierry is
investigating a
crash in dna-plugin and Noriko a memory leak, which could be in F21 -
any known issues in the F21 389-ds-base build that would prevent
upstream FreeIPA 4.0.x to be based on it
Yes. 389 will not start if weak ciphers are specified. Currently,
FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't
work at all because the DS will never start.
We need this patch merged: https://fedorahosted.org/389/ticket/47838
Done: thanks everyone on the DS side!
Then, we need an F21 build of 389-ds-base.
Done: thanks nhosoi!
Then we need to merge Ludwig's IPA patch from this thread with a
versioned dependency on the new 389-ds-base build.
New patch attached which includes a versioned dep on the new DS.
ipa-server-install still fails for me, even when I use
389-ds-base-1.3.3.2-1.fc20.x86_64:
# ipa-server-install
...
[12/13]: restarting httpd
[13/13]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Unexpected error - see /var/log/ipaserver-install.log for details:
ObjectclassViolation: attribute allowweakciphers not allowed
I think you simply use a wrong config name - have extra s in the end.
It is
defined as
that typo was already in my first draft of the patch, sorry
allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off]
Also, do we really need to put it to off in the updates? AFAIU, it is
off
by default in our config and with current setting, users could not put it
to
on (for whatever reason) without the value being overwritten with every
run
of FreeIPA upgrade.
could there be an upgrade from a install not yet using that params. should
only:allowWeakCipher be replaced by addifnew ?
You can try default:allowWeakCiphers: off - it would set the attribute to
off
if it was not there before.
Given you are probably working on updated version, I would also recommend
following
http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2
as I saw couple nitpicks with your patch
- ticket number in patch description and not in it's body
- bad From field - I would rather expect it to be Ludwig Krispenz
lkris...@redhat.com than lkrispen lkris...@redhat.com
Thanks,
Martin
Hello, any update on this front? Are you or Nathaniel updating the patch?
Attached.
From d4d24366c6392a1cd0c3d7c8513e20d0f9520766 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Fri, 12 Sep 2014 10:02:00 -0400
Subject: [PATCH] Update 389 SSL cipher config
We allow 389 to choose its own ciphers, but we default to
disabling weak ciphers. This offloads the choice to the
proper place so that we don't have to manage it in FreeIPA
anymore.
Thanks to Ludwig Krispenz lkris...@redhat.com for the
first version of this patch.
https://fedorahosted.org/freeipa/ticket/4395
---
freeipa.spec.in | 6 +++---
install/updates/20-sslciphers.update | 6 ++
install/updates/Makefile.am | 1 +
ipaserver/install/dsinstance.py | 7 ++-
4 files changed, 12 insertions(+), 8 deletions(-)
create mode 100644 install/updates/20-sslciphers.update
diff --git a/freeipa.spec.in b/freeipa.spec.in
index b672ecb03bdd73c1a911a6a982ccd894bebcbce4..685b345fedb9d157c8deedc66f8712da32c5963b 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -18,7 +18,7 @@ Source0:freeipa-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%if ! %{ONLY_CLIENT}
-BuildRequires: 389-ds-base-devel = 1.3.2.16
+BuildRequires: 389-ds-base-devel = 1.3.3.2
BuildRequires: svrcore-devel
BuildRequires: policycoreutils =
Re: [Freeipa-devel] FreeIPA 4.0.3?
Hi, I alread had sent a patch for review, It is exactly like yours with one exception: 65c61 +default:allowWeakCipher: off --- +addifnew:allowWeakCipher: off I tested with default, but it was ignored - is default only used for new entries ? On 09/12/2014 04:08 PM, Nathaniel McCallum wrote: On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote: On 09/12/2014 10:25 AM, Martin Kosek wrote: On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: On 09/12/2014 09:37 AM, Martin Kosek wrote: On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: On 09/11/2014 04:31 PM, Petr Viktorin wrote: On 09/11/2014 04:26 PM, Martin Kosek wrote: ... Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. what do you mean by no such issues ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute allowweakciphers not allowed I think you simply use a wrong config name - have extra s in the end. It is defined as that typo was already in my first draft of the patch, sorry allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off] Also, do we really need to put it to off in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to on (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. could there be an upgrade from a install not yet using that params. should only:allowWeakCipher be replaced by addifnew ? You can try default:allowWeakCiphers: off - it would set the attribute to off if it was not there before. Given you are probably working on updated version, I would also recommend following http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 as I saw couple nitpicks with your patch - ticket number in patch description and not in it's body - bad From field - I would rather expect it to be Ludwig Krispenz lkris...@redhat.com than lkrispen lkris...@redhat.com Thanks, Martin Hello, any update on this front? Are you or Nathaniel updating the patch? Attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile
On 12/09/14 16:02, Martin Basti wrote: I always forgot to install dogtag 10.2, so here is updated specfile. COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ Patch atached. ipa-4-1 I'm not sure if dogtag 10.2 is required in 4.1 -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA 4.0.3?
Sorry, I missed that. Let's take your patch. On Fri, 2014-09-12 at 16:16 +0200, Ludwig Krispenz wrote: Hi, I alread had sent a patch for review, It is exactly like yours with one exception: 65c61 +default:allowWeakCipher: off --- +addifnew:allowWeakCipher: off I tested with default, but it was ignored - is default only used for new entries ? On 09/12/2014 04:08 PM, Nathaniel McCallum wrote: On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote: On 09/12/2014 10:25 AM, Martin Kosek wrote: On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: On 09/12/2014 09:37 AM, Martin Kosek wrote: On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: On 09/11/2014 04:31 PM, Petr Viktorin wrote: On 09/11/2014 04:26 PM, Martin Kosek wrote: ... Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. what do you mean by no such issues ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute allowweakciphers not allowed I think you simply use a wrong config name - have extra s in the end. It is defined as that typo was already in my first draft of the patch, sorry allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off] Also, do we really need to put it to off in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to on (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. could there be an upgrade from a install not yet using that params. should only:allowWeakCipher be replaced by addifnew ? You can try default:allowWeakCiphers: off - it would set the attribute to off if it was not there before. Given you are probably working on updated version, I would also recommend following http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 as I saw couple nitpicks with your patch - ticket number in patch description and not in it's body - bad From field - I would rather expect it to be Ludwig Krispenz lkris...@redhat.com than lkrispen lkris...@redhat.com Thanks, Martin Hello, any update on this front? Are you or Nathaniel updating the patch? Attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base
On Fri, 2014-09-12 at 13:21 +0200, Ludwig Krispenz wrote: please review attached patch for ticket: https://fedorahosted.org/freeipa/ticket/4395 use new options in 389-ds to configure enabled ciphers ACK. Let's get 4.0.3 out the door! :) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn timestamp entries to individual permissions
On 09/12/2014 01:53 PM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4534 The entryusn and timestamp operational attributes are now automatically added to every read permission that targets objectclass, whether managed or user-created. The 'System: Read Timestamp and USN Operational Attributes', which was added for 4.0.2, is removed on upgrade. This looks good to me. deref search now return expected results: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: ALL # with dereference control # # admin, users, accounts, mkosek-fedora20.test dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test control: 1.3.6.1.4.1.4203.666.5.16 false ... # memberof: objectclass=top;objectclass=groupofnames;objectclass=posixgr oup;objectclass=ipausergroup;objectclass=ipaobject;objectclass=nestedG roup;entryusn=16719;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc =test # memberof: objectclass=top;objectclass=ipaobject;objectclass=groupofnam es;objectclass=ipausergroup;objectclass=nestedgroup;entryusn=375;cn=t rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: top objectClass: person ... I.e. only the memberof objects that the host has access to are dereferenced. Updated permissions also look OK. Thus ACK from me of there are no other objections. What should we do about remaining Operational permission? 1 permission matched Permission name: System: Read Creator and Modifier Operational Attributes Granted rights: read, compare, search Effective attributes: creatorsname, modifiersname Default attributes: modifiersname, creatorsname Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test Extra target filter: (objectclass=*) Number of entries returned 1 ? Any host can still use deref to for example find creatorsname or modifiersname of memberof entries. I would personally rather delete the permission and keep the attributes only for DM (and admin) or make it permission-based as SSSD does not use it anyway, AFAIK. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [Freeipa-interest] Announcing bind-dyndb-ldap version 5.3
The FreeIPA team is proud to announce bind-dyndb-ldap version 5.3. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 21+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-5.3-1.fc21 This version is also available from FreeIPA COPR repo: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ 5.3 [1] Internal locking was reworked to prevent crashes and deadlocks. 5.2 [1] Kerberos ticket expiration is now handled correctly. https://fedorahosted.org/bind-dyndb-ldap/ticket/131 [2] BIND no longer crashes after removing root zone from LDAP. https://fedorahosted.org/bind-dyndb-ldap/ticket/138 [3] Root zone handling was fixed to prevent accidental child zone removal. https://fedorahosted.org/bind-dyndb-ldap/ticket/122 [4] Temporary files for idnsZone objects are now inside master/ subdirectory. [5] Temporary directories are created with ug=rwx,o= permissions to enable POSIX ACL usage. [6] Naming rules for working directories have changed: See README section 6. [7] Documentation clearly states that idnsZoneActive attribute is not supported. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. !!! CAUTION !!! idnsZone object class changed it's semantics in version 5.0. Please read https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README and update idnsForwarders and idnsForward policy attributes in your DNS zones accordingly. Transition from idnsZone to idnsForwardZone object class can be made seamless if you change data in LDAP before you upgrade to version 5.x. All bind-dyndb-ldap versions = 3.0 support the idnsForwardZone object class. Users of FreeIPA 4.0 should be careful when upgrading bind-dyndb-ldap to version = 5.0 (if they do not upgrade to FreeIPA 4.x at the same time). Configuration semantics related to conditional (per-zone) forwarding has changed and FreeIPA 4.0 doesn't have appropriate user interface and API. It is safe to upgrade if you use *only* global forwarders (shown by 'ipa dnsconfig-show') and *do not* use per-zone forwarders (shown by 'ipa dnszone-show'). Don't hesitate to ask freeipa-users mailing list if you need help with upgrade. !!! CAUTION !!! Downgrading back to any 4.x version is supported. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On Fri, 2014-09-12 at 09:42 +0200, Martin Kosek wrote: Well, I am not convinced that everyone reads the release notes, so I would rather delete this permission in 4.0.3. Hopefully, there won't be many 4.0.2 users. It seems as a lesser evil to me than having SSSD clients broken. +1 such fundamental issues *must* be handle automatically if we can. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't
On Fri, 2014-09-12 at 10:27 +0200, thierry bordaz wrote: On 09/11/2014 10:24 PM, Martin Kosek wrote: On 09/11/2014 08:49 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote: On 09/11/2014 05:37 PM, Simo Sorce wrote: On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote: Hello, We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings cause older SSSD clients to fail as they get returned an LDAP deref call results without objectclass attribute and just with entryusn attribute. Details in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be more tolerant in this case, it still breaks old clients which we should prevent. There are 2 ways how to fix I currently see: 1) Return objectclass for any entry, just like we do with operational attributes This would include adding objectclass to System: Read Timestamp and USN Operational Attributes. However, I am rather cautious about this approach as even though objectclass does not usually carry a secret information, we could still leak some information about our DIT to unprivileged user. Our DIT is public and known, I see no problem. I rather meant the LDAP tree and it's contents (custom groups, sudo rules, roles, ...). I did one more test and found out we cannot do this as it would undermine the ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch returns every object even if no other attribute is returned: # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # User Administrators, privileges, pbac, mkosek-fedora20.test dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test objectClass: top objectClass: groupofnames objectClass: nestedgroup ... It would not show any more info before that, but even the list of permissions, privileges and roles along with it's names is a leaked information. 2) Show objectclass+operational attributes in our Read ACIs Other way I see is to update *all* our Read permissions allowing reading objectclass attribute and also allow the chosen LDAP operational attribute. This would let the LDAP caller to always get either all these discussed attributes but none at all. Do we want to do this? Any other (better) idea how to approach it? I honestly am not sure I understand the distinction between 1 and 2, can you provide the actual ACIs or a behavior example ? Simo. Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) running LDAP deref call gets entryusn from object it does not have a read access to: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. ... # memberof: entryusn=845;cn=replication administrators,cn=privileges,cn=pba c,dc=mkosek-fedora20,dc=test # memberof: entryusn=75;cn=add replication agreements,cn=permissions,cn=pba c,dc=mkosek-fedora20,dc=test ... This confuses SSSD (sees entryusn but does not see objectclass attribute) + may give out some information we do not want to give out. Fortunately, bare ldapsearch does not show anything: # ldapsearch -h `hostname` -Y GSSAPI -b cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test entryusn SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base cn=replication administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: entryusn # # search result search: 4 result: 0 Success # numResponses: 1 The idea behind Option 1 was to add ACI to allow reading objectclass attribute globally, for our entire tree. (as noted above, not an option). The idea behind Option 2 was to: - remove global ACI allowing reading entryusn (System: Read Timestamp and USN Operational Attributes) - update all our Read permissions to allow entryusn Then for example, if user (SSSD) is allowed to read RBAC role objects, he would not be able to read either objectclass or entryusn attributes. This means users would be only allowed to read entryusn for objects that they can really read (i.e. for objects where they can read at least objectclass). Did that clarify the options? Of course, there is still option 3) to close as wontfix and
Re: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile
On 09/12/2014 04:14 PM, Martin Basti wrote: On 12/09/14 16:02, Martin Basti wrote: I always forgot to install dogtag 10.2, so here is updated specfile. COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ Patch atached. ipa-4-1 I'm not sure if dogtag 10.2 is required in 4.1 It is not. It is only required for the DRM feature, i.e. FreeIPA 4.2, i.e. master branch. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn timestamp entries to individual permissions
On Fri, 2014-09-12 at 13:53 +0200, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4534 The entryusn and timestamp operational attributes are now automatically added to every read permission that targets objectclass, whether managed or user-created. The 'System: Read Timestamp and USN Operational Attributes', which was added for 4.0.2, is removed on upgrade. Not tested but LGTM. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA 4.0.3?
Ludwig Krispenz wrote: Hi, I alread had sent a patch for review, It is exactly like yours with one exception: 65c61 +default:allowWeakCipher: off --- +addifnew:allowWeakCipher: off I tested with default, but it was ignored - is default only used for new entries ? Correct. A value for default is only added when creating an entirely new entry. addifnew adds the value to the entry only if it doesn't already exist. rob On 09/12/2014 04:08 PM, Nathaniel McCallum wrote: On Fri, 2014-09-12 at 13:17 +0200, Martin Kosek wrote: On 09/12/2014 10:25 AM, Martin Kosek wrote: On 09/12/2014 10:13 AM, Ludwig Krispenz wrote: On 09/12/2014 09:37 AM, Martin Kosek wrote: On 09/12/2014 03:21 AM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:48 +0200, Petr Viktorin wrote: On 09/11/2014 04:43 PM, Nathaniel McCallum wrote: On Thu, 2014-09-11 at 16:39 +0200, Petr Viktorin wrote: On 09/11/2014 04:38 PM, Ludwig Krispenz wrote: On 09/11/2014 04:31 PM, Petr Viktorin wrote: On 09/11/2014 04:26 PM, Martin Kosek wrote: ... Also, we will need to add the F21 389-ds-base build to FreeIPA Copr: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ so that F20 users can upgrade to the newest FreeIPA. Are there any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it? If yes, we may need to include the patch in Fedora 21 downstream only after all.. We're basing the Fedora 21 Alpha downstream on FreeIPA 4.0.3, so we couldn't include the patch even there. There better be no such issues. what do you mean by no such issues ? I don't think that 389/F21 will be the first bug free software. At the moment Thierry is investigating a crash in dna-plugin and Noriko a memory leak, which could be in F21 - any known issues in the F21 389-ds-base build that would prevent upstream FreeIPA 4.0.x to be based on it Yes. 389 will not start if weak ciphers are specified. Currently, FreeIPA specifies weak ciphers. This means that FreeIPA in F21 doesn't work at all because the DS will never start. We need this patch merged: https://fedorahosted.org/389/ticket/47838 Done: thanks everyone on the DS side! Then, we need an F21 build of 389-ds-base. Done: thanks nhosoi! Then we need to merge Ludwig's IPA patch from this thread with a versioned dependency on the new 389-ds-base build. New patch attached which includes a versioned dep on the new DS. ipa-server-install still fails for me, even when I use 389-ds-base-1.3.3.2-1.fc20.x86_64: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Unexpected error - see /var/log/ipaserver-install.log for details: ObjectclassViolation: attribute allowweakciphers not allowed I think you simply use a wrong config name - have extra s in the end. It is defined as that typo was already in my first draft of the patch, sorry allowWeakCipher in cn=encryption,cn=config. allowWeakCipher: [on | off] Also, do we really need to put it to off in the updates? AFAIU, it is off by default in our config and with current setting, users could not put it to on (for whatever reason) without the value being overwritten with every run of FreeIPA upgrade. could there be an upgrade from a install not yet using that params. should only:allowWeakCipher be replaced by addifnew ? You can try default:allowWeakCiphers: off - it would set the attribute to off if it was not there before. Given you are probably working on updated version, I would also recommend following http://www.freeipa.org/page/Contribute/Patch_Format#Patch_format_2 as I saw couple nitpicks with your patch - ticket number in patch description and not in it's body - bad From field - I would rather expect it to be Ludwig Krispenz lkris...@redhat.com than lkrispen lkris...@redhat.com Thanks, Martin Hello, any update on this front? Are you or Nathaniel updating the patch? Attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0122] Add dogtag 10.2 to specfile
On 12/09/14 16:38, Martin Kosek wrote:
On 09/12/2014 04:14 PM, Martin Basti wrote:
On 12/09/14 16:02, Martin Basti wrote:
I always forgot to install dogtag 10.2, so here is updated specfile.
COPR: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/
Patch atached. ipa-4-1
I'm not sure if dogtag 10.2 is required in 4.1
It is not. It is only required for the DRM feature, i.e. FreeIPA 4.2,
i.e. master branch.
Martin
Thank you.
Updated patch attached.
push only to master branch then
--
Martin Basti
From 516eeb18971a86de27ce8c86ebb00105f6d3d9e6 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 12 Sep 2014 13:19:40 +0200
Subject: [PATCH] Dogtag 10.2 to spec.file
Dogtag 10.2 is required due to support a Vault feature
---
freeipa.spec.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 2e19733e5c1638896ca82b50463f35dd49fed6e5..b288405bb94ff25c53e762c7f727225323470733 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -115,8 +115,8 @@ Requires(post): systemd-units
Requires: selinux-policy = 3.12.1-179
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.47.7
-Requires: pki-ca = 10.1.1
-Requires: pki-kra = 10.1.1
+Requires: pki-ca = 10.2.0
+Requires: pki-kra = 10.2.0
%if 0%{?rhel}
Requires: subscription-manager
%endif
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn timestamp entries to individual permissions
On 09/12/2014 04:25 PM, Martin Kosek wrote: On 09/12/2014 01:53 PM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4534 The entryusn and timestamp operational attributes are now automatically added to every read permission that targets objectclass, whether managed or user-created. The 'System: Read Timestamp and USN Operational Attributes', which was added for 4.0.2, is removed on upgrade. This looks good to me. deref search now return expected results: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: ALL # with dereference control # # admin, users, accounts, mkosek-fedora20.test dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test control: 1.3.6.1.4.1.4203.666.5.16 false ... # memberof: objectclass=top;objectclass=groupofnames;objectclass=posixgr oup;objectclass=ipausergroup;objectclass=ipaobject;objectclass=nestedG roup;entryusn=16719;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc =test # memberof: objectclass=top;objectclass=ipaobject;objectclass=groupofnam es;objectclass=ipausergroup;objectclass=nestedgroup;entryusn=375;cn=t rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: top objectClass: person ... I.e. only the memberof objects that the host has access to are dereferenced. Updated permissions also look OK. Thus ACK from me of there are no other objections. What should we do about remaining Operational permission? 1 permission matched Permission name: System: Read Creator and Modifier Operational Attributes Granted rights: read, compare, search Effective attributes: creatorsname, modifiersname Default attributes: modifiersname, creatorsname Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test Extra target filter: (objectclass=*) Number of entries returned 1 ? Any host can still use deref to for example find creatorsname or modifiersname of memberof entries. I would personally rather delete the permission and keep the attributes only for DM (and admin) or make it permission-based as SSSD does not use it anyway, AFAIK. Martin This version removes 'System: Read Creator and Modifier Operational Attributes' as well. -- Petr³ From f794853264041cac730855c12ba96ab9cc564762 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Fri, 12 Sep 2014 09:59:52 +0200 Subject: [PATCH] permission plugin: Auto-add operational atttributes to read permissions The attributes entryusn, createtimestamp, and modifytimestamp should be readable whenever thir entry is, i.e. when we allow reading the objectclass. Automatically add them to every read permission that includes objectclass. https://fedorahosted.org/freeipa/ticket/4534 --- ACI.txt | 82 ipalib/plugins/permission.py | 8 +++ ipatests/test_xmlrpc/test_permission_plugin.py | 44 + ipatests/test_xmlrpc/test_realmdomains_plugin.py | 3 +- 4 files changed, 95 insertions(+), 42 deletions(-) diff --git a/ACI.txt b/ACI.txt index 2a3f582765b1ff1de9669f187adb9a57b19f938f..9a161a1839057198930c6e0f31a9bc3d491320ee 100644 --- a/ACI.txt +++ b/ACI.txt @@ -1,7 +1,7 @@ dn: cn=automember,cn=etc,dc=ipa,dc=example -aci: (targetattr = automemberdefaultgroup || automemberdisabled || automemberfilter || automembergroupingattr || automemberscope || cn || objectclass)(targetfilter = (objectclass=automemberdefinition))(version 3.0;acl permission:System: Read Automember Definitions;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Definitions,cn=permissions,cn=pbac,dc=ipa,dc=example;) +aci: (targetattr = automemberdefaultgroup || automemberdisabled || automemberfilter || automembergroupingattr || automemberscope || cn || createtimestamp || entryusn || modifytimestamp || objectclass)(targetfilter = (objectclass=automemberdefinition))(version 3.0;acl permission:System: Read Automember Definitions;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Definitions,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=automember,cn=etc,dc=ipa,dc=example -aci: (targetattr = automemberexclusiveregex || automemberinclusiveregex || automembertargetgroup || cn || description || objectclass)(targetfilter = (objectclass=automemberregexrule))(version 3.0;acl permission:System: Read Automember Rules;allow (compare,read,search) groupdn = ldap:///cn=System: Read Automember Rules,cn=permissions,cn=pbac,dc=ipa,dc=example;) +aci: (targetattr =
Re: [Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base
On 09/12/2014 04:18 PM, Nathaniel McCallum wrote: On Fri, 2014-09-12 at 13:21 +0200, Ludwig Krispenz wrote: please review attached patch for ticket: https://fedorahosted.org/freeipa/ticket/4395 use new options in 389-ds to configure enabled ciphers ACK. Let's get 4.0.3 out the door! :) Thanks! Works for me as well. Pushed to: master: ab196220fdd886fc2b19980f8e9a4b384845 ipa-4-1: 90e87310c6c8cb0bf88917afd0793a2a2ec1d5b6 ipa-4-0: 93b9d029ce147eb6b4c4ad36ce3c75e5fad37214 As we now depend on F21 version of 389-ds-base, I fired a build of the latest DS to the mkosek/freeipa Copr to not break the dependencies. I hope 389-ds-base will fix the install crash + the RI problems ASAP. I would not start a 4.0.3 release right now though, I would like to have fixes for ticket 4534 included too (patches on review, partially acked by me). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn timestamp entries to individual permissions
On 09/12/2014 04:46 PM, Petr Viktorin wrote: On 09/12/2014 04:25 PM, Martin Kosek wrote: On 09/12/2014 01:53 PM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4534 The entryusn and timestamp operational attributes are now automatically added to every read permission that targets objectclass, whether managed or user-created. The 'System: Read Timestamp and USN Operational Attributes', which was added for 4.0.2, is removed on upgrade. This looks good to me. deref search now return expected results: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: ALL # with dereference control # # admin, users, accounts, mkosek-fedora20.test dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test control: 1.3.6.1.4.1.4203.666.5.16 false ... # memberof: objectclass=top;objectclass=groupofnames;objectclass=posixgr oup;objectclass=ipausergroup;objectclass=ipaobject;objectclass=nestedG roup;entryusn=16719;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc =test # memberof: objectclass=top;objectclass=ipaobject;objectclass=groupofnam es;objectclass=ipausergroup;objectclass=nestedgroup;entryusn=375;cn=t rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: top objectClass: person ... I.e. only the memberof objects that the host has access to are dereferenced. Updated permissions also look OK. Thus ACK from me of there are no other objections. What should we do about remaining Operational permission? 1 permission matched Permission name: System: Read Creator and Modifier Operational Attributes Granted rights: read, compare, search Effective attributes: creatorsname, modifiersname Default attributes: modifiersname, creatorsname Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test Extra target filter: (objectclass=*) Number of entries returned 1 ? Any host can still use deref to for example find creatorsname or modifiersname of memberof entries. I would personally rather delete the permission and keep the attributes only for DM (and admin) or make it permission-based as SSSD does not use it anyway, AFAIK. Martin This version removes 'System: Read Creator and Modifier Operational Attributes' as well. Works fine. ACK. (You will need to regenerate ACI.txt for each merged branch as there are conflicts). Thanks! Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0001 Update-SSL-ciphers-configured-in-389-ds-base
On 09/12/2014 04:47 PM, Martin Kosek wrote: On 09/12/2014 04:18 PM, Nathaniel McCallum wrote: On Fri, 2014-09-12 at 13:21 +0200, Ludwig Krispenz wrote: please review attached patch for ticket: https://fedorahosted.org/freeipa/ticket/4395 use new options in 389-ds to configure enabled ciphers ACK. Let's get 4.0.3 out the door! :) Thanks! Works for me as well. Pushed to: master: ab196220fdd886fc2b19980f8e9a4b384845 ipa-4-1: 90e87310c6c8cb0bf88917afd0793a2a2ec1d5b6 ipa-4-0: 93b9d029ce147eb6b4c4ad36ce3c75e5fad37214 As we now depend on F21 version of 389-ds-base, I fired a build of the latest DS to the mkosek/freeipa Copr to not break the dependencies. I hope 389-ds-base will fix the install crash + the RI problems ASAP. I would not start a 4.0.3 release right now though, I would like to have fixes for ticket 4534 included too (patches on review, partially acked by me). ... aand https://fedorahosted.org/freeipa/ticket/4537 which also needs to be included in 4.0.3. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3
https://fedorahosted.org/freeipa/ticket/4537 See commit message for the story behind this one. -- Petr³ From e36ecfee32a331bfd031a48df2abe7e0ce8ec987 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Fri, 12 Sep 2014 17:14:14 +0200 Subject: [PATCH] Update referential integrity config for DS 1.3.3 Hisorically DS provided defaults for the referential integrity plugin in nsslapd-pluginArg*: nsslapd-pluginarg3: member nsslapd-pluginarg4: uniquemember nsslapd-pluginarg5: owner nsslapd-pluginarg6: seeAlso In 389-ds 1.3.3, the multi-valued referint-membership-attr is used instead. The old way still works, but it requires that the values are numbered consecutively, so IPA's defaults that started with 7 were not taken into account. Convert IPA defaults to use referint-membership-attr. https://fedorahosted.org/freeipa/ticket/4537 --- install/share/referint-conf.ldif | 33 - install/updates/25-referint.update | 34 -- 2 files changed, 24 insertions(+), 43 deletions(-) diff --git a/install/share/referint-conf.ldif b/install/share/referint-conf.ldif index 408f7598a2127a33373ec26d4f4ea1ab7ed73734..7c36395828580b677b8acef33625847609362eca 100644 --- a/install/share/referint-conf.ldif +++ b/install/share/referint-conf.ldif @@ -2,36 +2,3 @@ dn: cn=referential integrity postoperation,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginenabled nsslapd-pluginenabled: on -- -add: nsslapd-pluginArg7 -nsslapd-pluginArg7: manager -- -add: nsslapd-pluginArg8 -nsslapd-pluginArg8: secretary -- -add: nsslapd-pluginArg9 -nsslapd-pluginArg9: memberuser -- -add: nsslapd-pluginArg10 -nsslapd-pluginArg10: memberhost -- -add: nsslapd-pluginArg11 -nsslapd-pluginArg11: sourcehost -- -add: nsslapd-pluginArg12 -nsslapd-pluginArg12: memberservice -- -add: nsslapd-pluginArg13 -nsslapd-pluginArg13: managedby -- -add: nsslapd-pluginArg14 -nsslapd-pluginArg14: memberallowcmd -- -add: nsslapd-pluginArg15 -nsslapd-pluginArg15: memberdenycmd -- -add: nsslapd-pluginArg16 -nsslapd-pluginArg16: ipasudorunas -- -add: nsslapd-pluginArg17 -nsslapd-pluginArg17: ipasudorunasgroup diff --git a/install/updates/25-referint.update b/install/updates/25-referint.update index 65af05128e433d683d61272cad6145fa8f084b04..c4bff5dac4956eb0ef4b132a2ce5dafdb53e286e 100644 --- a/install/updates/25-referint.update +++ b/install/updates/25-referint.update @@ -2,13 +2,27 @@ # pres and eq indexes defined in 20-indices.update must be set for all these # attributes dn: cn=referential integrity postoperation,cn=plugins,cn=config -add: nsslapd-pluginArg9: memberuser -add: nsslapd-pluginArg10: memberhost -add: nsslapd-pluginArg11: sourcehost -add: nsslapd-pluginArg12: memberservice -add: nsslapd-pluginArg13: managedby -add: nsslapd-pluginArg14: memberallowcmd -add: nsslapd-pluginArg15: memberdenycmd -add: nsslapd-pluginArg16: ipasudorunas -add: nsslapd-pluginArg17: ipasudorunasgroup -add: nsslapd-pluginArg18: ipatokenradiusconfiglink +remove: nsslapd-pluginArg7: manager +remove: nsslapd-pluginArg8: secretary +remove: nsslapd-pluginArg9: memberuser +remove: nsslapd-pluginArg10: memberhost +remove: nsslapd-pluginArg11: sourcehost +remove: nsslapd-pluginArg12: memberservice +remove: nsslapd-pluginArg13: managedby +remove: nsslapd-pluginArg14: memberallowcmd +remove: nsslapd-pluginArg15: memberdenycmd +remove: nsslapd-pluginArg16: ipasudorunas +remove: nsslapd-pluginArg17: ipasudorunasgroup +remove: nsslapd-pluginArg18: ipatokenradiusconfiglink +add: referint-membership-attr: manager +add: referint-membership-attr: secretary +add: referint-membership-attr: memberuser +add: referint-membership-attr: memberhost +add: referint-membership-attr: sourcehost +add: referint-membership-attr: memberservice +add: referint-membership-attr: managedby +add: referint-membership-attr: memberallowcmd +add: referint-membership-attr: memberdenycmd +add: referint-membership-attr: ipasudorunas +add: referint-membership-attr: ipasudorunasgroup +add: referint-membership-attr: ipatokenradiusconfiglink -- 1.9.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3
On 09/12/2014 05:35 PM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4537 See commit message for the story behind this one. Thanks. Works as a charm, so ACK. Pushed to: master: d61fb40542abb0aa66c49d987813099fda356adf ipa-4-1: f8771db202bcca4419be847c00f167362311e28e ipa-4-0: c6baecec1ec866d77f9a476d01c7931fce6d95da Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3
On 09/12/2014 05:43 PM, Martin Kosek wrote: On 09/12/2014 05:35 PM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4537 See commit message for the story behind this one. Thanks. Works as a charm, so ACK. just for my understanding. what was install/share/referint-conf.ldif good for, why isn't adding the membership attrs needed there ? Pushed to: master: d61fb40542abb0aa66c49d987813099fda356adf ipa-4-1: f8771db202bcca4419be847c00f167362311e28e ipa-4-0: c6baecec1ec866d77f9a476d01c7931fce6d95da Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0644 Update referential integrity config for DS 1.3.3
On 09/12/2014 05:47 PM, Ludwig Krispenz wrote: On 09/12/2014 05:43 PM, Martin Kosek wrote: On 09/12/2014 05:35 PM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4537 See commit message for the story behind this one. Thanks. Works as a charm, so ACK. just for my understanding. what was install/share/referint-conf.ldif good for, why isn't adding the membership attrs needed there ? The ldif files are put in place on initial install only. The update files are applied both on initial install and on upgrades, and allow greater control over what gets done on update. At one point the policy was to put everything in both places, so ther would be a LDIF representation of what IPA puts in the directory. But that goal doesn't play well with updater plugins, and also the copies inevitably got out of sync. Now we prefer the update files for all new changes. One day we might get rid of the ldifs altogether. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0642-0643 Move granting read access to entryusn timestamp entries to individual permissions
On 09/12/2014 05:02 PM, Martin Kosek wrote: On 09/12/2014 04:46 PM, Petr Viktorin wrote: On 09/12/2014 04:25 PM, Martin Kosek wrote: On 09/12/2014 01:53 PM, Petr Viktorin wrote: https://fedorahosted.org/freeipa/ticket/4534 The entryusn and timestamp operational attributes are now automatically added to every read permission that targets objectclass, whether managed or user-created. The 'System: Read Timestamp and USN Operational Attributes', which was added for 4.0.2, is removed on upgrade. This looks good to me. deref search now return expected results: # ldapsearch -h `hostname` -Y GSSAPI -b uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 'deref=memberof:objectclass,entryusn' SASL/GSSAPI authentication started SASL username: host/ipa.mkosek-fedora20.t...@mkosek-fedora20.test SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test with scope subtree # filter: (objectclass=*) # requesting: ALL # with dereference control # # admin, users, accounts, mkosek-fedora20.test dn: uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test control: 1.3.6.1.4.1.4203.666.5.16 false ... # memberof: objectclass=top;objectclass=groupofnames;objectclass=posixgr oup;objectclass=ipausergroup;objectclass=ipaobject;objectclass=nestedG roup;entryusn=16719;cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc =test # memberof: objectclass=top;objectclass=ipaobject;objectclass=groupofnam es;objectclass=ipausergroup;objectclass=nestedgroup;entryusn=375;cn=t rust admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test objectClass: top objectClass: person ... I.e. only the memberof objects that the host has access to are dereferenced. Updated permissions also look OK. Thus ACK from me of there are no other objections. What should we do about remaining Operational permission? 1 permission matched Permission name: System: Read Creator and Modifier Operational Attributes Granted rights: read, compare, search Effective attributes: creatorsname, modifiersname Default attributes: modifiersname, creatorsname Bind rule type: all Subtree: dc=mkosek-fedora20,dc=test Extra target filter: (objectclass=*) Number of entries returned 1 ? Any host can still use deref to for example find creatorsname or modifiersname of memberof entries. I would personally rather delete the permission and keep the attributes only for DM (and admin) or make it permission-based as SSSD does not use it anyway, AFAIK. Martin This version removes 'System: Read Creator and Modifier Operational Attributes' as well. Works fine. ACK. Thanks! Pushed to: ipa-4-0: f47da6a761a97134668cf674c78f5f9271c98e8b ipa-4-1: a0e23ce210506be84716343982ef43099841177b master: 4fac4f4cf65b54bc0b194928341b31e3c67d63a5 (You will need to regenerate ACI.txt for each merged branch as there are conflicts). (Yeah, whoever invented this ACI.txt thing, I need to have a talk with him) -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] FreeIPA 4.0.3 ?
There were some critical issues in 4.0.2, mainly with integration: https://fedorahosted.org/freeipa/ticket/4529 - broken upgrades https://fedorahosted.org/freeipa/ticket/4430 - python-qrcode packaging fix https://fedorahosted.org/freeipa/ticket/4395 - update of SSL ciphers https://fedorahosted.org/freeipa/ticket/4534 - operational attribute ACIs https://fedorahosted.org/freeipa/ticket/4537 - referential integrity configuration All the fixes are pushed now. Please test! If nothing else shows up, I will release 4.0.3 today. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA 4.0.3 ?
On 09/12/2014 06:36 PM, Petr Viktorin wrote: There were some critical issues in 4.0.2, mainly with integration: https://fedorahosted.org/freeipa/ticket/4529 - broken upgrades https://fedorahosted.org/freeipa/ticket/4430 - python-qrcode packaging fix https://fedorahosted.org/freeipa/ticket/4395 - update of SSL ciphers https://fedorahosted.org/freeipa/ticket/4534 - operational attribute ACIs https://fedorahosted.org/freeipa/ticket/4537 - referential integrity configuration All the fixes are pushed now. Please test! +1. If nothing else shows up, I will release 4.0.3 today. I also sent fixed 389-ds-base-1.3.3.2-2.fc21.src.rpm to our Copr to have it ready for F20. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0009 Detect and configure all usable IP addresses.
snip / Be careful, reviewed on friday! :-) 1) whitespace error + pep8 error patch:76: trailing whitespace. # there is reverse zone for every ip address warning: 1 line adds whitespace errors. ./ipaserver/install/bindinstance.py:640:9: E265 block comment should start with '# ' 2) (server install) +for ip in ip_addresses: +for rev_zone in reverse_zones: +if bindinstance.verify_reverse_zone(rev_zone, str(ip)): +break +else: +sys.exit(1) Please add there error message instead 1 to exit function 3) (server install) Code above, bindinstance.verify_reverse_zone(rev_zone, str(ip)): IMHO this will cause errors (not tested) try: rev-zones: [10.10.10.in-addr.arpa., 16.172.in-addr.arpa.] ip_addreses: [10.10.10.1, 172.16.0.1] it should be any() of zone can handle ip 4) (replica-install) I'm not sure about behavior of combination ip addresses, and reverse zones, In original code, if user specify reverse zone, the ip address must match. In patched version, you just add new zones for ip-addresses which doesn't math the user zones. IMO we should check if all addresses belongs to user specified zones, otherwise raise an error. But I'm open to suggestions. 5) Code for ipa-replica-install, and ipa-server-install, differs in parts where we expecting same behavior - ip addresses and reverse zones 6) https://engineering.redhat.com/irc-services.txt+# there is at least one ip address in every zone +if options.reverse_zones: +for reverse_zone in options.reverse_zones: +for ip in config.ips: -- A +if bindinstance.verify_reverse_zone(reverse_zone, ip): + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) +break +else: +sys.exit(1) * +# there is reverse zone for every ip address +for ip in config.ips: +for reverse_zone in options.reverse_zones: --- B +if bindinstance.verify_reverse_zone(reverse_zone, ip): +if reverse_zone not in reverse_zones: + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) +break +else: C +reverse_zone = bindinstance.find_reverse_zone(ip) +if reverse_zone is None and not options.no_reverse: +reverse_zone = util.get_reverse_zone_default(ip) - D1 +if not options.unattended and bindinstance.create_reverse(): - D +reverse_zone = bindinstance.read_reverse_zone(reverse_zone, ip) + reverse_zones.append(bindinstance.normalize_zone(reverse_zone)) - D2 You added all possible zones in step A, B step is not needed. If user doesn't specify reverse_zones you can just jump to C step *add error message C: elif not options.no_reverse D: you asked user if wants to create zone, but you don't care about answer, and in step D2 append zone from D1 note: --no-reverse and --reverse-zones cant be used together, you can use it in new code, test it before cycle 7) # Always use force=True as named is not set up yet add_zone(self.domain, self.zonemgr, dns_backup=self.dns_backup, -ns_hostname=api.env.host, ns_ip_address=nameserver_ip_address, -force=True) + ns_hostname=api.env.host, ns_ip_address=None, force=True) +#for ns_ip_address in nameserver_ip_address: +#add_zone(self.domain, self.zonemgr, dns_backup=self.dns_backup, +#ns_hostname=api.env.host, ns_ip_address=ns_ip_address, +#force=True) Please remove commented section You can remove 'ns_ip_address=None' from function 8) +if set(options.ip_addresses) = set(ips): +ips = options.ip_addresses +else: +print sys.stderr, Error: the hostname resolves to an IP address that is different +print sys.stderr, from the one provided on the command line. Please fix your DNS +print sys.stderr, or /etc/hosts file and restart the installation. +sys.exit(1) Could you write those extra addresses to output? We need to improve usability of our error messages -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Announcing FreeIPA 4.0.3
The FreeIPA team would like to announce FreeIPA v4.0.3 bugfix release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21 Beta. Builds for Fedora 20 are available in the official [https://copr.fedoraproject.org/coprs/mkosek/freeipa/ COPR repository]. == Bug fixes in 4.0.3 == * Several issues concerning integration with 389 Directory Server 1.3.3 were fixed. * An upgrade crash was fixed. == Known Issues == * On Fedora 21 Alpha, FreeIPA server configuration should be done after upgrading packages from updates-testing. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.2 == === David Kupka (1) === * Fix typo causing ipa-upgradeconfig to fail. === Ludwig Krispenz (1) === * Update SSL ciphers configured in 389-ds-base === Nathaniel McCallum (1) === * Update qrcode support for newer python-qrcode === Petr Viktorin (4) === * Update referential integrity config for DS 1.3.3 * permission plugin: Auto-add operational atttributes to read permissions * Allow deleting obsolete permissions; remove operational attribute permissions * Become IPA 4.0.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
