Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients
On 12/04/2014 07:17 PM, Nathaniel McCallum wrote: On Tue, 2014-12-02 at 11:55 -0500, Nathaniel McCallum wrote: On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote: On 12/02/2014 05:49 PM, Nathaniel McCallum wrote: On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: On 12/02/2014 05:36 PM, Simo Sorce wrote: On Tue, 02 Dec 2014 11:12:11 -0500 Nathaniel McCallum npmccal...@redhat.com wrote: On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: - Original Message - On 3.10.2013 23:43, Nathaniel McCallum wrote: Patch attached. I'm curious - what is the purpose of this patch? To prevent 1 second timeouts and re-transmits when OTP is in place? What is the expected performance impact? Could it be configured for OTP separately - somehow? (I guess that it is not possible now ...) It benefits also communication of large packets (when large MS-PAC or CAMMAC AD Data are attached), so it is a better choice for IPA in general. Especially given we have multiple KDC processes configured we do not want clients wasting KDC resources by making multiple processes do the same operation. So apparently this patch never got reviewed over a year ago. It was related to a bug which was opened in SSSD. However, when it became clear we wanted to solve this in FreeIPA, the SSSD bug was closed but no corresponding FreeIPA bug was opened. The patch then fell through the cracks. Without this patch, if OTP validation runs long we get retransmits and failures. One question I have is how to handle this for upgrades since (I think) this patch only handles new installs. Anyway, this patch is somewhat urgent now. So help is appreciated. I have attached a rebased version which has no other changes. I still need a review on this. Any takers? The patch looks good to me Simo. This fixes the new installations. Can you please refresh the memory what is the decision regarding the upgrades? The need to fix upgrades will be documented. In the future, we will get /etc/krb.conf.d and we will ship a file there. Nathaniel Nobody reads the documentation :-) What is the implication for users doing client update (majority of them) and using OTP feature? They will get spurious failures. Most will think it is a bug or a network issue. If the failures happen consistently enough, users might get locked out. So what is the plan with this patch? We need to get it sorted. :) Ok, I am fine with your original approach then and only fix the new installations. You just need to rebase your patch, it does not apply to ipa-4-1 or master. Also, I am not convinced we should touch contrib/RHEL4/ipa-client-setup, did you try the script and are you confident this option is available on RHEL4? :-) If not, I would only update current installers. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 3] ipa-client-install shouldn't be eager in specifying zone when doing nsupdate
On 12/04/2014 12:47 PM, Martin Basti wrote:
On 04/12/14 10:03, Jan Pazdziora wrote:
On Wed, Dec 03, 2014 at 05:16:23PM +0100, Martin Basti wrote:
On 02/12/14 13:00, Jan Pazdziora wrote:
Hello,
presumably explicitly specifying zone is not needed and can be
harmful.
This should be fixed in template for uploading SSHFP keys as well.
I have zone bububu.test.
2014-12-03T04:00:36Z DEBUG debug
zone client.bububu.test.
update delete test.client.bububu.test. IN SSHFP
show
send
update add test.client.bububu.test. 1200 IN SSHFP 1 1
8FD003E98D818E4E2813672234410835AB5844AC
update add test.client.bububu.test. 1200 IN SSHFP 1 2
37BF6366A44B67F6CA8FF8A8313B7C964CEA971CCB3E092D775FDF082170AAA4
update add test.client.bububu.test. 1200 IN SSHFP 3 1
3651173F6737DF24EB6494434AC5968B3C90B749
update add test.client.bububu.test. 1200 IN SSHFP 3 2
97EF4030A9DD471A3D4730A819B3A662E11994BB20AFC56FC3875AB1662260BF
show
send
Updated patch attached.
ACK
I just removed unused dict value.
@@ -1590,8 +1590,7 @@ def update_dns(server, hostname):
sub_dict = dict(HOSTNAME=hostname,
IPADDRESS=ip,
-TTL=1200,
-ZONE='.'.join(hostname.split('.')[1:])
+TTL=1200
)
if af == socket.AF_INET:
Patch with this update attached.
Pushed to:
master: bea417828d61777015785c716c4225bb48dcf037
ipa-4-1: 8b4301473233afdf0ae3c72ad33bcd04182e63c6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0162] Upgrade fix: masking named service should be executed only once
On 11/12/2014 01:43 PM, Martin Basti wrote: Hello, masking named service is executed more than once, following patch fixes it. Patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works as expected but: 0) mask_named_regular() returns True, False and None. None evaluates as False so why not use False directly? 1) missing link to ticket in commit message. -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 384 Do not renew the IPA CA cert by serial number in dogtag-ipa-ca-renew-agent
Hi,
the attached patch fixes https://fedorahosted.org/freeipa/ticket/4784.
Honza
--
Jan Cholasta
From 1e268143669621c01973859590af0a22d80255bf Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Thu, 4 Dec 2014 15:34:55 +
Subject: [PATCH] Do not renew the IPA CA cert by serial number in
dogtag-ipa-ca-renew-agent
Always use the full CSR when renewing the IPA CA certificate with Dogtag. The
IPA CA certificate may be issued by an external CA, in which case renewal by
serial number does not make sense and will fail if the IPA CA was initially
installed as a subordinate of an external CA.
https://fedorahosted.org/freeipa/ticket/4784
---
install/certmonger/dogtag-ipa-ca-renew-agent-submit | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/install/certmonger/dogtag-ipa-ca-renew-agent-submit b/install/certmonger/dogtag-ipa-ca-renew-agent-submit
index 0a2cff1..2500313 100755
--- a/install/certmonger/dogtag-ipa-ca-renew-agent-submit
+++ b/install/certmonger/dogtag-ipa-ca-renew-agent-submit
@@ -147,7 +147,7 @@ def request_cert():
path = paths.DOGTAG_IPA_RENEW_AGENT_SUBMIT
args = [path] + sys.argv[1:]
if os.environ.get('CERTMONGER_CA_PROFILE') == 'caCACert':
-args += ['-O', 'bypassCAnotafter=true']
+args += ['-N', '-O', 'bypassCAnotafter=true']
stdout, stderr, rc = ipautil.run(args, raiseonerr=False, env=os.environ)
sys.stderr.write(stderr)
sys.stderr.flush()
--
2.1.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. Anyway, I have created http://www.freeipa.org/page/Troubleshooting#External_CA_renewal_with_ipa-cacert-manage_fails. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
On 12/05/2014 11:34 AM, Jan Cholasta wrote: Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. I saw several reasons: - Certificateinstallation error are more common than the others and users are usually quite lost in what to do with them. - In this case, we know by 90% probability what is the root cause - It will block one of the main use cases for the new CA renewal tool and people will likely hit it as MS CAs is one of the most common CAs and this is it's default behavior. Giving more details in this case will not hurt us, but benefit users. So I still do not see the harm. Anyway, I have created http://www.freeipa.org/page/Troubleshooting#External_CA_renewal_with_ipa-cacert-manage_fails. Good. Do you plan to reference the section or enhance the error message? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew
Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): On 12/05/2014 11:34 AM, Jan Cholasta wrote: Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): On 12/04/2014 09:36 AM, Jan Cholasta wrote: +if x509.get_der_subject(cert, x509.DER) != der_subject: +raise admintool.ScriptError(Subject name encoding mismatch) I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. I saw several reasons: - Certificateinstallation error are more common than the others and users are usually quite lost in what to do with them. - In this case, we know by 90% probability what is the root cause - It will block one of the main use cases for the new CA renewal tool and people will likely hit it as MS CAs is one of the most common CAs and this is it's default behavior. Giving more details in this case will not hurt us, but benefit users. So I still do not see the harm. I do not see a harm either, my point is that we should probably point the user to documentation when *anything* in *any* script goes wrong, not just when some arbitrarily cherry-picked error occurs. Anyway, I have created http://www.freeipa.org/page/Troubleshooting#External_CA_renewal_with_ipa-cacert-manage_fails. Good. Do you plan to reference the section or enhance the error message? I plan to reference http://www.freeipa.org/page/Troubleshooting. Martin -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0162] Upgrade fix: masking named service should be executed only once
On 05/12/14 10:23, David Kupka wrote:
On 11/12/2014 01:43 PM, Martin Basti wrote:
Hello,
masking named service is executed more than once, following patch
fixes it.
Patch attached.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Works as expected but:
0) mask_named_regular() returns True, False and None. None evaluates
as False so why not use False directly?
1) missing link to ticket in commit message.
Updated patch attached
--
Martin Basti
From 79ca4ffdabd59814311c9f0db81018bfeb984044 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 12 Nov 2014 12:09:27 +0100
Subject: [PATCH] Upgrade fix: masking named should be executed only once
There was error in code, masking was executed more times, even it was
succesful
https://fedorahosted.org/freeipa/ticket/4755
---
install/tools/ipa-upgradeconfig | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index 815fe0465348e175a4e54b6898409ee4f963a56d..44b58d2aca640daf2f7640ce58687549d98978c5 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -1141,23 +1141,25 @@ def uninstall_selfsign(ds, http):
def mask_named_regular():
Disable named, we need to run only named-pkcs11, running both named and
named-pkcs can cause unexpected errors
-if not sysupgrade.get_upgrade_state('dns', 'regular_named_masked'):
-if bindinstance.named_conf_exists():
-root_logger.info('[Masking named]')
-named = services.service('named-regular')
-try:
-named.stop()
-except Exception as e:
-root_logger.warning('Unable to stop named service (%s)', e)
+if sysupgrade.get_upgrade_state('dns', 'regular_named_masked'):
+return False
-try:
-named.mask()
-except Exception as e:
-root_logger.warning('Unable to mask named service (%s)', e)
+sysupgrade.set_upgrade_state('dns', 'regular_named_masked', True)
-return True
+if bindinstance.named_conf_exists():
+root_logger.info('[Masking named]')
+named = services.service('named-regular')
+try:
+named.stop()
+except Exception as e:
+root_logger.warning('Unable to stop named service (%s)', e)
-sysupgrade.set_upgrade_state('dns', 'regular_named_masked', True)
+try:
+named.mask()
+except Exception as e:
+root_logger.warning('Unable to mask named service (%s)', e)
+
+return True
return False
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable
On 12/04/2014 07:15 PM, Nathaniel McCallum wrote: On Thu, 2014-12-04 at 14:56 +0100, Petr Vobornik wrote: On 2.12.2014 20:57, Nathaniel McCallum wrote: Works fine. python part of 0004: ACK, but VERSION needs to be updated before push 0005: ACK Fixed and rebased. Patch numbers have changed: 0004 = 0001 0005 = 0002 One question before push: For per-token configuration, do you intent to extend each token, regardless of type, by 'ipatokenOTPConfig' object class? I.e. to have config attributes for both types? Or do you plan to have special object classes for each token type as we now have for tokens? I would probably just add the TOTP options to the ipatokenTOTP object class as MAY. Same for HOTP. The attributes were designed to look like the other token-type-specific attributes. I think we are just waiting on Thierry's review of the C code. :) Thierry already wrote: regarding the DS plugin part of 0004, the patch is good to me. For the ipa plugins part I am too novice. Therefore: 0001 Pushed to: master: 9baa93da1cbf56c2a6f7e82e099bc3ff3f19e2e4 ipa-4-1: 3013385ca4a28a4f203fae6dbef34321720d8879 0002 Pushed to: ipa-4-1: f5ae902eb5c391bd6150c99d5b3316be937aa459 master: b01767c69d69806b3c701242d617b6fa08e7d882 Nathaniel -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable
On 12/05/2014 01:46 PM, Petr Vobornik wrote: On 12/04/2014 07:15 PM, Nathaniel McCallum wrote: On Thu, 2014-12-04 at 14:56 +0100, Petr Vobornik wrote: On 2.12.2014 20:57, Nathaniel McCallum wrote: Works fine. python part of 0004: ACK, but VERSION needs to be updated before push 0005: ACK Fixed and rebased. Patch numbers have changed: 0004 = 0001 0005 = 0002 One question before push: For per-token configuration, do you intent to extend each token, regardless of type, by 'ipatokenOTPConfig' object class? I.e. to have config attributes for both types? Or do you plan to have special object classes for each token type as we now have for tokens? I would probably just add the TOTP options to the ipatokenTOTP object class as MAY. Same for HOTP. The attributes were designed to look like the other token-type-specific attributes. I think we are just waiting on Thierry's review of the C code. :) Thierry already wrote: regarding the DS plugin part of 0004, the patch is good to me. For the ipa plugins part I am too novice. Therefore: 0001 Pushed to: master: 9baa93da1cbf56c2a6f7e82e099bc3ff3f19e2e4 ipa-4-1: 3013385ca4a28a4f203fae6dbef34321720d8879 0002 Pushed to: ipa-4-1: f5ae902eb5c391bd6150c99d5b3316be937aa459 master: b01767c69d69806b3c701242d617b6fa08e7d882 Thanks to all for resolving this RFE and this thread. It started to be little bit tangled :-) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 793-794 Fix schema related replication issues between IPA-3-0 and IPA-4-1
Hello, I've transformed Thierry's and Ludwig's findings of bz 1167964 [1] and ticket 4794 [2] into patches. I wonder if the mgrpRFC822MailMember and nsViewFilter issue(patch 794) should be solved on 389's side rather than on FreeIPA's? Also is the increase of nsslapd-sasl-max-buffer-size necessary? With these two patches, replication appears to work fine for me. Tested with F21 FreeIPA 4.1.x-GIT-something and ipa-server-3.0.0-42.el6.x86_64 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1167964 [2] https://fedorahosted.org/freeipa/ticket/4794 -- Petr Vobornik From d9a7ba3ea575127bd9caefb72db3236f1a25544b Mon Sep 17 00:00:00 2001 From: Petr Vobornik pvobo...@redhat.com Date: Thu, 4 Dec 2014 18:23:34 +0100 Subject: [PATCH] add schema control exceptions for mgrpRFC822MailMember and nsViewFilter to allow repliacation between IPA 3.0 and IPA 4.1 https://fedorahosted.org/freeipa/ticket/4794 --- install/updates/10-config.update | 8 1 file changed, 8 insertions(+) diff --git a/install/updates/10-config.update b/install/updates/10-config.update index 30fafbf9e93279633cc5760104fb68456720d2b3..a1d10214983d6f048f6327cc4449cef26d83f894 100644 --- a/install/updates/10-config.update +++ b/install/updates/10-config.update @@ -68,3 +68,11 @@ only:nsslapd-sasl-max-buffer-size:2097152 # setting, password migration fails dn: cn=config only:nsslapd-allow-hashed-passwords:on + +# Fix replication from old(IPA 3.1) servers +dn: cn=supplierUpdatePolicy,cn=replSchema,cn=config +default:objectClass:top +default:objectClass:nsSchemaPolicy +default:cn: supplierUpdatePolicy +add:schemaUpdateAttributeAccept: mgrpRFC822MailMember +add:schemaUpdateAttributeAccept: nsViewFilter -- 1.9.3 From f16a67f1749f7d6a53531aa8481ba8f42d44ea5e Mon Sep 17 00:00:00 2001 From: Petr Vobornik pvobo...@redhat.com Date: Thu, 4 Dec 2014 17:30:20 +0100 Subject: [PATCH] revert removal of cn attribute from idnsRecord The removal, which was done in IPA-3.2, causes replication issues between IPA 3.2 and IPA 4.1. Because IPA 4.1 adds two more attributes. https://fedorahosted.org/freeipa/ticket/4794 --- install/share/60ipadns.ldif | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif index 678a5b483f7abbd0df2907513577573109297943..8fd0bb9e7c10f56c1d1c45b6ec9e8f1f9f7e7cef 100644 --- a/install/share/60ipadns.ldif +++ b/install/share/60ipadns.ldif @@ -63,7 +63,7 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME 'idnsSecKeyRevoke' DESC 'DNSKE attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v4.1' ) attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' ) -objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ TLSARecord ) ) +objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 'idnsRecord' DESC 'dns Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( cn $ idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord $ a6Record $ nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ mXRecord $ mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord $ KeyRecord $ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord $ dNameRecord $ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $ TLSARecord ) ) objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $ idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders $ idnsSecInlineSigning $ nSEC3PARAMRecord ) ) objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC 'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $ idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $ idnsPersistentSearch ) ) objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' ) -- 1.9.3
Re: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show
On 12/04/2014 04:22 PM, Tomas Babej wrote: Updated patch with fixed WebUI bits. ACK Pushed to: master: d0a781b9c6911f1875df4b0c7da5e6ae030d36de ipa-4-1: b986eb281d038e871cd613bf5a7a21a1456370cc -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] topology management question
Ludwig Krispenz wrote: hi, I just have another (hopefully this will end soon) issue I want to get your input. (please read to teh end first) To recapture the conditions: - the topology plugin manages the connections between servers as segments in the shared tree - it is authoritative for managed servers, eg it controls all connections between servers listed under cn=masters, it is permissive for connection to other servers - it rejects any removal of a segment, which would disconnect the topology. - a change in topology can be applied to any server in the topology, it will reach the respective servers and the plugin will act upon it Now there is a special case, causing a bit of trouble. If a replica is to be removed from the topology, this means that the replication agreements from and to this replica should be removed, the server should be removed from the manages servers. The problem is that: - if you remove the server first, the server becomes unmanaged and removal of the segment will not trigger a removal of the replication agreement - if you remove the segments first, one segment will be the last one connecting this replica to the topology and removal will be rejected Now, with some effort this can be resolved, eg if the server is removed, keep it internally as removed server and for segments connecting this server trigger removal of replication agreements or mark a the last segment, when tried to remove, as pending and once the server is removed also remove the corresponding repl agreements But there is a problem, which I think is much harder and I am not sure how much effort I should put in resolving it. If we want to have the replication agreements cleaned up after removal of a replica without direct modification of cn=config, we need to follow the path above, but this also means that the last change needs to reach both the removed replica (R) and the last server(S) it is connected to. The bad thing is that if this change triggers a removal of the replication agreement on S it could be that the change is not replicated to R before the agreement is removed and is lost. There is no way (or no easy) way to know for teh plugin if a change was received by an other server, I was also thinking about some kind of acknowledge mechanism by doing a ping pong of changes, but the problem always is the same that one server does not know if the other has received it. And even if this would theoretically work, we cannot be sure that R is not shutdown and only the remaining topology is tried to be cleaned up, so S would wait forever. My suggestion to resolve this (in most cases) is to define a wait interval, after the final combination of removal of a server and its connecting segment is received, wait for some time and then remove the corresponding replication agreements. So I'm asking you if this would be acceptable or if you have a better solution. As I understood the proposal, you receive change requests which are validated and applied on the server that received them. This is going to cause changes to be replicated. On servers that get these replicated changes they simply apply the changes w/o applying the associated logic. Blindly, in other words. Doesn't that make this problem go away? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 795 webui: increase duration of notification messages
increase duration of notification messages by 66%
https://fedorahosted.org/freeipa/ticket/4792
--
Petr Vobornik
From 275974a7021a606d89789ee146d8f710d3ed93df Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 5 Dec 2014 16:21:19 +0100
Subject: [PATCH] webui: increase duration of notification messages
by 66%
https://fedorahosted.org/freeipa/ticket/4792
---
install/ui/src/freeipa/ipa.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/install/ui/src/freeipa/ipa.js b/install/ui/src/freeipa/ipa.js
index 137f11e832ff8d0b6dd1b50060f8537c7b117616..a78d1f0638ec5d750b5aee52197c5b04feae3f94 100644
--- a/install/ui/src/freeipa/ipa.js
+++ b/install/ui/src/freeipa/ipa.js
@@ -1198,7 +1198,7 @@ IPA.get_succeeded = function(data) {
*/
IPA.config = {
default_priority: 500,
-message_timeout: 3000, // [ms]
+message_timeout: 5000, // [ms]
message_timeout_length: 50 // [chars]
};
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients
On Fri, 2014-12-05 at 09:19 +0100, Martin Kosek wrote:
On 12/04/2014 07:17 PM, Nathaniel McCallum wrote:
On Tue, 2014-12-02 at 11:55 -0500, Nathaniel McCallum wrote:
On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote:
On 12/02/2014 05:49 PM, Nathaniel McCallum wrote:
On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote:
On 12/02/2014 05:36 PM, Simo Sorce wrote:
On Tue, 02 Dec 2014 11:12:11 -0500
Nathaniel McCallum npmccal...@redhat.com wrote:
On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote:
On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote:
- Original Message -
On 3.10.2013 23:43, Nathaniel McCallum wrote:
Patch attached.
I'm curious - what is the purpose of this patch? To prevent 1
second timeouts and re-transmits when OTP is in place?
What is the expected performance impact? Could it be configured
for OTP separately - somehow? (I guess that it is not possible
now ...)
It benefits also communication of large packets (when large
MS-PAC or CAMMAC AD Data are attached), so it is a better choice
for IPA in general. Especially given we have multiple KDC
processes configured we do not want clients wasting KDC resources
by making multiple processes do the same operation.
So apparently this patch never got reviewed over a year ago.
It was related to a bug which was opened in SSSD. However, when it
became clear we wanted to solve this in FreeIPA, the SSSD bug was
closed but no corresponding FreeIPA bug was opened. The patch then
fell through the cracks.
Without this patch, if OTP validation runs long we get retransmits
and failures.
One question I have is how to handle this for upgrades since (I
think) this patch only handles new installs.
Anyway, this patch is somewhat urgent now. So help is appreciated.
I have attached a rebased version which has no other changes.
I still need a review on this. Any takers?
The patch looks good to me
Simo.
This fixes the new installations. Can you please refresh the memory
what is the
decision regarding the upgrades?
The need to fix upgrades will be documented. In the future, we will
get /etc/krb.conf.d and we will ship a file there.
Nathaniel
Nobody reads the documentation :-) What is the implication for users doing
client update (majority of them) and using OTP feature?
They will get spurious failures. Most will think it is a bug or a
network issue. If the failures happen consistently enough, users might
get locked out.
So what is the plan with this patch? We need to get it sorted. :)
Ok, I am fine with your original approach then and only fix the new
installations. You just need to rebase your patch, it does not apply to
ipa-4-1
or master.
Fixed.
Also, I am not convinced we should touch contrib/RHEL4/ipa-client-setup, did
you try the script and are you confident this option is available on RHEL4?
:-)
If not, I would only update current installers.
Agreed. Fixed.
Also, I updated the commit message to be more thorough.
Nathaniel
From 274f963f43def2cf0524b86477e51dfe725fc241 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Fri, 5 Dec 2014 11:18:55 -0500
Subject: [PATCH] Prefer TCP connections to UDP in krb5 clients
In general, TCP is a better fit for FreeIPA due to large packet sizes.
However, there is also a specific need for TCP when using OTP. If a UDP
packet is delivered to the server and the server takes longer to process
it than the client timeout (likely), the OTP value will be resent.
Unfortunately, this will cause failures or even lockouts. Switching to
TCP avoids this problem altogether.
https://fedorahosted.org/sssd/ticket/914
---
install/share/krb5.conf.template | 1 +
install/tools/ipa-replica-conncheck | 1 +
ipa-client/ipa-install/ipa-client-install | 1 +
3 files changed, 3 insertions(+)
diff --git a/install/share/krb5.conf.template b/install/share/krb5.conf.template
index 7c82083e3331cfa1995cd9dfa6ddd88edd1f..6cb5ee34704cd6158e882bfa89fc597f3ff1bb0f 100644
--- a/install/share/krb5.conf.template
+++ b/install/share/krb5.conf.template
@@ -12,6 +12,7 @@ includedir /var/lib/sss/pubconf/krb5.include.d/
rdns = false
ticket_lifetime = 24h
forwardable = yes
+ udp_preference_limit = 0
$OTHER_LIBDEFAULTS
[realms]
$REALM = {
diff --git a/install/tools/ipa-replica-conncheck b/install/tools/ipa-replica-conncheck
index 88e42bafbc600fb7c36b7727c770e75edccd2196..22348fc2158e59afc2e1aa51e3d3f51e90b99e39 100755
--- a/install/tools/ipa-replica-conncheck
+++ b/install/tools/ipa-replica-conncheck
@@ -208,6 +208,7 @@ def configure_krb5_conf(realm, kdc, filename):
libdefaults.append({'name':'rdns', 'type':'option', 'value':'false'})
libdefaults.append({'name':'ticket_lifetime', 'type':'option', 'value':'24h'})
libdefaults.append({'name':'forwardable', 'type':'option', 'value':'yes'})
+
Re: [Freeipa-devel] [Freeipa-interest] Announcing FreeIPA 4.1.2 - NEED HELP WITH 2FA/OTP!!!
Hello,
WE NEED HELP!
The biggest and the most interesting feature of FreeIPA 4.1.2 is support for
the two factor authentication using HOTP/TOTP compatible software tokens like
FreeOTP (open source compatible alternative to Google Authenticator) and
hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of
a FreeIPA server to authenticate using the normal account password as the first
factor and an OTP token as a second factor. For those environments where a 2FA
solution is already in place, FreeIPA can act as a proxy via RADIUS. More about
this feature can be read here.
http://www.freeipa.org/page/V4/OTP
If you want to see this feature in downstream distros sooner rather than later
we need your help!
Please give it a try and provide feedback. We really, really need it!
Thank you,
FreeIPA development team
- Original Message -
From: Petr Vobornik pvobo...@redhat.com
To: freeipa-devel freeipa-devel@redhat.com, freeipa-users
freeipa-us...@redhat.com, freeipa-inter...@redhat.com
Sent: Thursday, November 27, 2014 11:59:35 AM
Subject: [Freeipa-interest] Announcing FreeIPA 4.1.2
The FreeIPA team would like to announce FreeIPA v4.1.2 security release!
It can be downloaded from http://www.freeipa.org/page/Downloads. The
builds will be available for Fedora 21. Builds for Fedora 20 are
available in the official COPR repository
[https://copr.fedoraproject.org/coprs/mkosek/freeipa/].
== Highlights in 4.1.2 ==
=== Bug fixes ===
* CVE-2014-7850: ensure that user input is properly escaped to prevent
XSS attacks [https://fedorahosted.org/freeipa/ticket/4742]
[http://www.freeipa.org/page/CVE-2014-7850]
* harden mod_nss config on update to use TLSv1.0, TLSv1.1, TLSv1.2
* fixed getkeytab operation
[https://fedorahosted.org/freeipa/ticket/4718]
[https://fedorahosted.org/freeipa/ticket/4728]
* backup and restore fixes related to certificates restore and SELinux
context
* static code analysis fixes
* various small fixes
== 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.1.1 ==
=== Alexander Bokovoy (2) ===
* Update slapi-nis dependency to pull 0.54.1
* AD trust: improve trust validation
=== David Kupka (6) ===
* Remove unneeded internal methods. Move code to public methods.
* Remove service file even if it isn't link.
* Produce better error in group-add command.
* Fix --{user,group}-ignore-attribute in migration plugin.
* ipa-restore: Check if directory is provided + better errors.
* Fix error message for nonexistent members and add tests.
=== Gabe Alford (1) ===
* ipa-server-install Directory Manager help incorrect
=== Jan Cholasta (15) ===
* Fix CA certificate backup and restore
* Update Requires on pki-ca to 10.2.1-0.1
* Fix wrong expiration date on renewed IPA CA certificates
* Restore file extended attributes and SELinux context in ipa-restore
* Use correct service name in cainstance.backup_config
* Stop tracking certificates before restoring them in ipa-restore
* Remove redefinition of LOG from ipa-otp-lasttoken
* Unload P11_Helper object's library when it is finalized in ipap11helper
* Fix Kerberos error handling in ipa-sam
* Fix unchecked return value in ipa-kdb
* Fix unchecked return values in ipa-winsync
* Fix unchecked return value in ipa-join
* Fix unchecked return value in krb5 common utils
* Fix memory leak in GetKeytabControl asn1 code
* Add TLS 1.2 to the protocol list in mod_nss config
=== Martin Bašti (12) ===
* Fix: DNS
[Freeipa-devel] [RANT] pytest fixture scope is braindead
So I've been working this week on porting the OTP tests that were
manually coded to the new pytest framework. Now, I'm the first to want
better tooling to make our job easier. But, pytest? Meh. I'm having to
write just as much code (or more) to get my tests on par with pytest,
and they are riddled with subtle bugs.
Most painful, is pytest.fixture(). It is a cool idea, but the scoping
and lifecycle is horribly broken. Here is an example:
Here is an example. I want to create a user, enable otp in two different
ways, test with two different types of tokens under two different
authentication scenarios. This is a total of 8 tests.
@pytest.fixture(scope=function) # This scope is default.
def user(request):
user = create_user('tuser1')
request.addfinalizer(lambda: delete_user('tuser1'))
return user
@pytest.fixture(params=[per-user, global])
def enablement(request, user):
output = enable(user, request.param)
request.addfinalizer(lambda: disable(user))
return output
@pytest.fixture(params=[{'type': 'HOTP'}, {'disabled': True}])
def token(request, user, enablement):
output = create_token(request.param)
request.addfinalizer(lambda: delete_token(output.id))
return output
@pytest.mark.parametrize(opts, [foo, bar])
def test_authentication(user, token, opts):
return auth(user.uid, token.code(), opts)
Because the default scope is function, a new user is created for every
single run of token. This is *way* more work than necessary, and leads
to slow runtimes. Fortunately, we can fix this by changing the scope of
the user fixture to module. In this case, only one user will be
created per module. So far so good.
The enablement scope is still function, so it will still be called
eight times (#tokens * #enablements * #opts). Now, this is a problem
because (let's say) enablement takes a long time to switch tests. Here
is problem #1 with pytest: it presumes that all variants of fixtures
should be grouped by test parameters. This is a bad assumption. It may
make sense in some cases, but there is no way to change it.
Now, we can work around this problem just like with the user fixture:
change the scope to module. Unfortunately, we've just caused a second
bug. Now, enablement() will only be run twice; but the finalizer will
not be called until all tests are run. This means that per-user
enablement will still be active when global enablement runs; both will
be torn down simultaneously.
This same problem arises for the token fixture: eight tokens will be
created and destroyed when only four are necessary. You guessed it, we
can fix this by changing the scope. But by doing this all four tokens
will be deleted simultaneously. This means we cannot test the state
where only a disabled token exists.
Any attempt to use a fixture to create long-lived states (precisely what
fixtures are designed for) with mutually exclusive parameters is
extremely error prone as it is not clear which items are alive in the
LDAP db at any point. This leads to both long runtimes *and* extremely
subtle bugs in the tests that are multiplied by every layer of fixtures.
Call me nonplussed.
Now, let's look at how this same test can be implemented without pytest:
user = create_user('tuser1')
try:
for enablement in ('per-user', 'global'):
enable(user, enablement)
try:
for token in [{'type': 'HOTP'}, {'disabled': True}]:
object = create_token(token)
try:
for opt in [foo, bar]:
auth(user.uid, object.code(), opt)
finally:
delete_token(object.id)
finally:
disable(user)
finally:
delete_user('tuser1')
Comparing the non-pytest implementation to the pytest one we can see a
few things. First, the pytest code has some nice separation of roles.
This is the big benefit of pytest. Second, the non-pytest implementation
is less code. Third, the non-pytest implementation has no subtle scoping
bugs: we know exactly when each database record is created and
destroyed.
I *want* to like pytest. Honestly I do. But this scoping idiocy has
already cost me roughly two days tracking down subtle bugs in the tests
(while not finding any bugs in the OTP code itself). And I can't think
that OTP tests written using pytest will be maintainable in any regard;
not when such small changes can cause such hard to find bugs.
Now, it may be possible that I have just missed something obvious. If I
have, forgive me this rant. But I've spent a lot of time reading docs
and I haven't seen any obvious solutions to these problems.
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
