Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/16/2012 05:41 AM, Ade Lee wrote: > On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: .. 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install /home/mkosek/replica-info-vm-114.idm.lab.bos.redhat.com.gpg ... Configuring certificate server: Estimated time 3 minutes 30 seconds [1/14]: creating certificate server user [2/14]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' Root cause: ... File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 625, in __spawn_instance "/root/cacert.p12") ... >>> I need to look into this. I had fixed ipa-replica-install, rather than >>> ipa-ca-install to create replicas. I didn't know ipa-ca-install >>> existed! Should not be too bad to fix though - most likely just need to >>> move files to the right place. >> >> Ok, thanks! Btw. CA on replica can be either installed during >> ipa-replica-install time (when --setup-ca option is passed, you probably used >> that one) and the aforementioned ipa-ca-install run after >> ipa-replica-install. >> > I will be testing this out again. As ipa-ca-install uses the same code > as ipa-replica-install, I would have expected it to work. Did you try > it with selinux in permissive mode? I had SELinux en enforcing mode. ipa-server-install with SELinux worked fine, so I thought that replica installation will work fine too. I will re-test with SELinux turned off. ... >> 7) pki-deploy package does not require any other pki-* package, this does not >> look ok. This way I was able to have pki-ca-9.* and pki-deploy-10.* installed >> at one time. I doubt it would work that way. >> > We have opened a dogtag ticket to address this. Some kind of dependency > will be added so that pki-deploy and pki-common-10 are co-dependencies. > >> 8) Did you test upgrade from installed IPA+dogtag9 to patchedIPA+dogtag10? I >> did that on Fedora 17 and pki-ca did not start after upgrade. Attaching logs >> my >> VM after I tried to (re)start pki-ca. >> > I did test this. From the logs though, this looks very much like it is > not starting because of selinux. Can you try to restart with selinux > permissive? I fully expect there to be selinux issues here as some > changes are required in the base policy where the default ports are > defined. > Ok then. I will test it with permissive SELinux as well. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: > On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > > On 08/15/2012 03:54 PM, Ade Lee wrote: > > > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > > >> On 08/08/2012 10:05 PM, Ade Lee wrote: > > >>> Hi, > > >>> > > >>> Dogtag 10 is being released on f18, and has a number of changes that > > >>> will affect IPA. In particular, the following changes will affect > > >>> current IPA code. > > >>> > > >>> * The directory layout of the dogtag instance has changed. Instead of > > >>> using separate tomcat instances to host different subsystems, the > > >>> standard dogtag installation will allow one to install a CA. KRA, OCSP > > >>> and TKS within the same instance. There have been corresponding changes > > >>> in the directory layout, as well as the default instance name > > >>> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > > >>> of pki-cad, pki-krad etc.) > > >>> > > >>> * The default instance will use only four ports (HTTPS, HTTP, AJP and > > >>> tomcat shutdown port) rather than the 6 previously used. The default > > >>> ports will be changed to the standard tomcat ports. As these ports are > > >>> local to the ipa server machine, this should not cause too much > > >>> disruption. > > >>> > > >>> * There is a new single step installer written in python. > > >>> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > >>> > > >>> * Dogtag 10 runs on tomcat7 - with a new corresponding version of > > >>> tomcatjss. > > >>> > > >>> The attached patch integrates all the above changes in IPA installation > > >>> and maintenance code. Once the patch is applied, users will be able to: > > >>> > > >>> 1. run ipa-server-install to completion on f18 with dogtag 10. > > >>> 2. install a new replica on f18 on dogtag 10. > > >>> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > > >>> 10 - and have that old-style dogtag instance continue to run correctly. > > >>> This will require the installation of the latest version of tomcatjss as > > >>> well as the installation of tomcat6. The old-style instance will > > >>> continue to use tomcat6. > > >>> 4. in addition, the new cert renewal code has been patched and should > > >>> continue to work. > > >>> > > >>> What is not yet completed / supported: > > >>> > > >>> 1. Installation with an external CA is not yet completed in the new > > >>> installer. We plan to complete this soon. > > >>> > > >>> 2. There is some IPA upgrade code that has not yet been touched > > >>> (install/tools/ipa-upgradeconfig). > > >>> > > >>> 3. A script needs to be written to allow admins to convert their > > >>> old-style dogtag instances to new style instances, as well as code to > > >>> periodically prompt admins to do this. > > >>> > > >>> 4. Installation of old-style instances using pkicreate/pkisilent on > > >>> dogtag 10 will no longer be supported, and will be disabled soon. > > >>> > > >>> 5. The pki-selinux policy has been updated to reflect these changes, > > >>> but is still in flux. In fact, it is our intention to place the dogtag > > >>> selinux policy in the base selinux policy for f18. In the meantime, it > > >>> may be necessary to run installs in permissive mode. > > >>> > > >>> The dogtag 10 code will be released shortly into f18. Prior to that > > >>> though, we have placed the new dogtag 10 and tomcatjss code in a > > >>> developer repo that is located at > > >>> http://nkinder.fedorapeople.org/dogtag-devel/ > > >>> > > >>> Testing can be done on both f18 and f17 - although the target platform - > > >>> and the only platform for which official builds will be created is f18. > > >>> > > >>> Thanks, > > >>> Ade > > >>> > > >> > > >> Hi Ade, > > >> > > >> Thanks for the patch, I started with review and integration tests > > >> (currently > > >> running on Fedora 17 with Nathan's repo). > > >> > > >> Installation on single master was smooth, it worked just fine, even with > > >> enforced SELinux, without any error - kudos to you and the whole dogtag > > >> team. > > >> The resulting logs and the structure of your log directory seems > > >> improved. I > > >> believe that the brand new Python installers will make it easier to debug > > >> issues with dogtag installation when they come. When I tried our unit > > >> tests or > > >> some simple cert operation, it worked fine as well. > > >> > > >> Now the bad news, or rather few issues and suggestions I found: > > >> > > >> 1) As we already discussed on IRC, tomcat 7 was not pulled automatically > > >> on > > >> Fedora 17 when I updated pki-ca, you somewhere miss a Requires. > > >> > > > We have a dogtag patch that is currently in review that will address > > > this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, > > > rather than f18+ > > > > > >> 2) I had installed IPA with dogtag10 on master. However, CA installation > > >> on a > > >> replica (ipa-ca-install) with dogtag9 faile
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: > On 08/15/2012 03:54 PM, Ade Lee wrote: > > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > >> On 08/08/2012 10:05 PM, Ade Lee wrote: > >>> Hi, > >>> > >>> Dogtag 10 is being released on f18, and has a number of changes that > >>> will affect IPA. In particular, the following changes will affect > >>> current IPA code. > >>> > >>> * The directory layout of the dogtag instance has changed. Instead of > >>> using separate tomcat instances to host different subsystems, the > >>> standard dogtag installation will allow one to install a CA. KRA, OCSP > >>> and TKS within the same instance. There have been corresponding changes > >>> in the directory layout, as well as the default instance name > >>> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > >>> of pki-cad, pki-krad etc.) > >>> > >>> * The default instance will use only four ports (HTTPS, HTTP, AJP and > >>> tomcat shutdown port) rather than the 6 previously used. The default > >>> ports will be changed to the standard tomcat ports. As these ports are > >>> local to the ipa server machine, this should not cause too much > >>> disruption. > >>> > >>> * There is a new single step installer written in python. > >>> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > >>> > >>> * Dogtag 10 runs on tomcat7 - with a new corresponding version of > >>> tomcatjss. > >>> > >>> The attached patch integrates all the above changes in IPA installation > >>> and maintenance code. Once the patch is applied, users will be able to: > >>> > >>> 1. run ipa-server-install to completion on f18 with dogtag 10. > >>> 2. install a new replica on f18 on dogtag 10. > >>> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > >>> 10 - and have that old-style dogtag instance continue to run correctly. > >>> This will require the installation of the latest version of tomcatjss as > >>> well as the installation of tomcat6. The old-style instance will > >>> continue to use tomcat6. > >>> 4. in addition, the new cert renewal code has been patched and should > >>> continue to work. > >>> > >>> What is not yet completed / supported: > >>> > >>> 1. Installation with an external CA is not yet completed in the new > >>> installer. We plan to complete this soon. > >>> > >>> 2. There is some IPA upgrade code that has not yet been touched > >>> (install/tools/ipa-upgradeconfig). > >>> > >>> 3. A script needs to be written to allow admins to convert their > >>> old-style dogtag instances to new style instances, as well as code to > >>> periodically prompt admins to do this. > >>> > >>> 4. Installation of old-style instances using pkicreate/pkisilent on > >>> dogtag 10 will no longer be supported, and will be disabled soon. > >>> > >>> 5. The pki-selinux policy has been updated to reflect these changes, > >>> but is still in flux. In fact, it is our intention to place the dogtag > >>> selinux policy in the base selinux policy for f18. In the meantime, it > >>> may be necessary to run installs in permissive mode. > >>> > >>> The dogtag 10 code will be released shortly into f18. Prior to that > >>> though, we have placed the new dogtag 10 and tomcatjss code in a > >>> developer repo that is located at > >>> http://nkinder.fedorapeople.org/dogtag-devel/ > >>> > >>> Testing can be done on both f18 and f17 - although the target platform - > >>> and the only platform for which official builds will be created is f18. > >>> > >>> Thanks, > >>> Ade > >>> > >> > >> Hi Ade, > >> > >> Thanks for the patch, I started with review and integration tests > >> (currently > >> running on Fedora 17 with Nathan's repo). > >> > >> Installation on single master was smooth, it worked just fine, even with > >> enforced SELinux, without any error - kudos to you and the whole dogtag > >> team. > >> The resulting logs and the structure of your log directory seems improved. > >> I > >> believe that the brand new Python installers will make it easier to debug > >> issues with dogtag installation when they come. When I tried our unit > >> tests or > >> some simple cert operation, it worked fine as well. > >> > >> Now the bad news, or rather few issues and suggestions I found: > >> > >> 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on > >> Fedora 17 when I updated pki-ca, you somewhere miss a Requires. > >> > > We have a dogtag patch that is currently in review that will address > > this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, > > rather than f18+ > > > >> 2) I had installed IPA with dogtag10 on master. However, CA installation > >> on a > >> replica (ipa-ca-install) with dogtag9 failed - is this expectable? > >> > > Yes. The current IPA patch is designed to work with dogtag 10 only, > > which will be officially available on f18+. So if you update to dogtag > > 10, you must have this patch and visa versa. We probably need to add > > the rele
[Freeipa-devel] [PATCH 77] Ticket #2584 - Installation fails when CN is set in, certificate subject base
--
John Dennis
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
>From 32cf59ac8963982d2de59562f3f1570e67e92a3e Mon Sep 17 00:00:00 2001
From: John Dennis
Date: Wed, 15 Aug 2012 21:33:15 -0400
Subject: [PATCH 77] Ticket #2584 - Installation fails when CN is set in
certificate subject base
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
It is illegal to have more than one CN attribute in a certificate
subject. The subject command line arg is actually inserting a dn
between a leading RDN with a CN attribute and a suffix. The final
subject must have only CN attribute therefore the subject command line
arg must not contain CN. The patch modifies the subject validation to
prohibit CN. It also improves the error messages to clearly indicate
which command line parameter caused the failure and why.
While fixing the above it discovered the logic used for subject
validation with an external CA was flawed. DN objects were not being
used when they should be (certificate subject and issuer fields are dn
syntax). That code was also fixed so that the comparisions between
subjects and issuers were performed with DN objects. While fixing this
it was noted the object type relationship between IPA DN objects and
x509 DN objects was awkward, ticket 3003 was opened to address this.
---
install/tools/ipa-server-install | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index d9682bb..16a9e33 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -70,7 +70,7 @@ pw_name = None
uninstalling = False
installation_cleanup = True
-VALID_SUBJECT_ATTRS = ['cn', 'st', 'o', 'ou', 'dnqualifier', 'c',
+VALID_SUBJECT_ATTRS = ['st', 'o', 'ou', 'dnqualifier', 'c',
'serialnumber', 'l', 'title', 'sn', 'givenname',
'initials', 'generationqualifier', 'dc', 'mail',
'uid', 'postaladdress', 'postalcode', 'postofficebox',
@@ -82,7 +82,6 @@ def subject_callback(option, opt_str, value, parser):
"""
Make sure the certificate subject base is a valid DN
"""
-name = opt_str.replace('--','')
v = unicode(value, 'utf-8')
if any(ord(c) < 0x20 for c in v):
raise OptionValueError("Subject base must not contain control characters")
@@ -92,10 +91,10 @@ def subject_callback(option, opt_str, value, parser):
dn = DN(v)
for rdn in dn:
if rdn.attr.lower() not in VALID_SUBJECT_ATTRS:
-raise OptionValueError('invalid attribute: %s' % rdn.attr)
+raise OptionValueError('%s=%s has invalid attribute: "%s"' % (opt_str, value, rdn.attr))
except ValueError, e:
-raise OptionValueError('Invalid subject base format: %s' % str(e))
-parser.values.subject = str(dn) # may as well normalize it
+raise OptionValueError('%s=%s has invalid subject base format: %s' % (opt_str, value, e))
+parser.values.subject = dn
def validate_dm_password(password):
if len(password) < 8:
@@ -638,9 +637,9 @@ def main():
print "'%s' is not a valid PEM-encoded certificate." % options.external_cert_file
sys.exit(1)
-certsubject = unicode(extcert.subject)
-wantsubject = unicode(DN(('CN','Certificate Authority'), options.subject))
-if certsubject.lower() != wantsubject.lower():
+certsubject = DN(str(extcert.subject))
+wantsubject = DN(('CN','Certificate Authority'), options.subject)
+if certsubject != wantsubject:
print "Subject of the PKCS#10 certificate is not correct (got %s, expected %s)." % (certsubject, wantsubject)
sys.exit(1)
@@ -653,19 +652,19 @@ def main():
print "'%s' is not a valid PEM-encoded certificate chain." % options.external_ca_file
sys.exit(1)
-certdict = dict((unicode(cert.subject).lower(), cert) for cert in extchain)
-certissuer = unicode(extcert.issuer)
-if certissuer.lower() not in certdict:
+certdict = dict((DN(str(cert.subject)), cert) for cert in extchain)
+certissuer = DN(str(extcert.issuer))
+if certissuer not in certdict:
print "The PKCS#10 certificate is not signed by the external CA (unknown issuer %s)." % certissuer
sys.exit(1)
cert = extcert
while cert.issuer != cert.subject:
-certissuer = unicode(cert.issuer)
-if certissuer.lower() not in certdict:
+certissuer = DN(str(cert.issuer))
+if certissuer not in certdict:
print "The external CA chain is incomplete (%s is missing from the chain)." % certissuer
sys.exit(1)
-cert = certdict[certissuer.lower()]
+cert = certdict[certissuer]
print "==
[Freeipa-devel] [PATCH] 1045 selinuxusermap fixes
Fix setting the user in a rule using setattr. We weren't verifying that
it was in the ordered list.
I also noticed that no mls was allowed when it shouldn't be. Made that
required.
rob
>From 4fa293408f3605ef52bf2aec42305562414f7bae Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Wed, 15 Aug 2012 17:21:19 -0400
Subject: [PATCH] Validate default user in ordered list when using setattr,
require MLS
The MLS was optional in the format, it should be required.
https://fedorahosted.org/freeipa/ticket/2984
---
ipalib/plugins/selinuxusermap.py| 21 -
tests/test_xmlrpc/test_selinuxusermap_plugin.py | 14 --
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/ipalib/plugins/selinuxusermap.py b/ipalib/plugins/selinuxusermap.py
index 2d689cd748c7e4128919279cd553ec31bca0e162..e4cebc1e41bc315e285899e4279bcac26143ab2e 100644
--- a/ipalib/plugins/selinuxusermap.py
+++ b/ipalib/plugins/selinuxusermap.py
@@ -72,10 +72,13 @@ notboth_err = _('HBAC rule and local members cannot both be set')
def validate_selinuxuser(ugettext, user):
"""
-An SELinux user has 3 components: user:MLS:MCS
-user traditionally ends with _u but this is not mandatory. Regex is ^[a-zA-Z][a-zA-Z_]*
-The MLS part can only be
-Level: s[0-15](-s[0-15])
+An SELinux user has 3 components: user:MLS:MCS. user and MLS are required.
+user traditionally ends with _u but this is not mandatory.
+ The regex is ^[a-zA-Z][a-zA-Z_]*
+
+The MLS part can only be:
+ Level: s[0-15](-s[0-15])
+
Then MCS could be c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123]
Meaning
s0 s0-s1 s0-s15:c0.c1023 s0-s1:c0,c2,c15.c26 s0-s0:c0.c1023
@@ -92,7 +95,7 @@ def validate_selinuxuser(ugettext, user):
if not regex_name.match(name):
return _('Invalid SELinux user name, only a-Z and _ are allowed')
-if mls and not regex_mls.match(mls):
+if not mls or not regex_mls.match(mls):
return _('Invalid MLS value, must match s[0-15](-s[0-15])')
if mcs and not regex_mcs.match(mcs):
return _('Invalid MCS value, must match c[0-1023].c[0-1023] and/or c[0-1023]-c[0-c0123]')
@@ -283,11 +286,11 @@ class selinuxusermap_mod(LDAPUpdate):
if is_all(options, 'hostcategory') and 'memberhost' in entry_attrs:
raise errors.MutuallyExclusiveError(reason="host category cannot be set to 'all' while there are allowed hosts")
-if 'ipaselinuxuser' in options:
-validate_selinuxuser_inlist(ldap, options['ipaselinuxuser'])
+if 'ipaselinuxuser' in entry_attrs:
+validate_selinuxuser_inlist(ldap, entry_attrs['ipaselinuxuser'])
-if 'seealso' in options:
-entry_attrs['seealso'] = self.obj._normalize_seealso(options['seealso'])
+if 'seealso' in entry_attrs:
+entry_attrs['seealso'] = self.obj._normalize_seealso(entry_attrs['seealso'])
return dn
def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
diff --git a/tests/test_xmlrpc/test_selinuxusermap_plugin.py b/tests/test_xmlrpc/test_selinuxusermap_plugin.py
index fef9aa1cc9c841c33c07bbd01452ce1d01f1bce2..83260e8ab982da59343d84eba63c21e135ce61d4 100644
--- a/tests/test_xmlrpc/test_selinuxusermap_plugin.py
+++ b/tests/test_xmlrpc/test_selinuxusermap_plugin.py
@@ -606,9 +606,9 @@ class test_selinuxusermap(Declarative):
dict(
desc='Create rule with unknown user %r' % rule1,
command=(
-'selinuxusermap_add', [rule1], dict(ipaselinuxuser=u'notfound')
+'selinuxusermap_add', [rule1], dict(ipaselinuxuser=u'notfound:s0:c0')
),
-expected=errors.NotFound(reason=u'SELinux user notfound not ' +
+expected=errors.NotFound(reason=u'SELinux user notfound:s0:c0 not ' +
u'found in ordering list (in config)'),
),
@@ -643,4 +643,14 @@ class test_selinuxusermap(Declarative):
u'and/or c[0-1023]-c[0-c0123]'),
),
+
+dict(
+desc='Create rule with invalid user via setattr',
+command=(
+'selinuxusermap_mod', [rule1], dict(setattr=u'ipaselinuxuser=deny')
+),
+expected=errors.ValidationError(name='ipaselinuxuser',
+error=u'Invalid MLS value, must match s[0-15](-s[0-15])'),
+),
+
]
--
1.7.10.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 1044 DN ldap syntax exception
Raise the proper IPA exception when a value isn't a valid DN. rob >From 916f1e9b80c0f8bc88da2651a44d0d33ad3bec30 Mon Sep 17 00:00:00 2001 From: Rob Crittenden Date: Wed, 15 Aug 2012 16:30:24 -0400 Subject: [PATCH] Raise proper exception when given a bad DN attribute. --- ipalib/plugins/baseldap.py |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index e05f59ff4224bbfaf1c57989e1a3616c87b6996e..011d626291b797406c63c249e6d315429f260ad7 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -809,7 +809,10 @@ last, after all sets and adds."""), value = None if ldap.has_dn_syntax(attr): -value = DN(value) +try: +value = DN(value) +except ValueError: +raise errors.InvalidSyntax(attr=attr) if attr in newdict: if type(value) in (tuple,): -- 1.7.10.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 1043 fix ipa-replica-manage connect
A dn needed to be converted to a DN object.
rob
>From f242875811f887d80328eb84c96efdfd0ad5fa72 Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Wed, 15 Aug 2012 13:56:04 -0400
Subject: [PATCH] Use DN object for Directory Manager in ipa-replica-manage
connect command
---
install/tools/ipa-replica-manage |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index a4b8e8274c33e210297c8cfa069bc85e7c0fefb7..a135183334341d5cdecb5383c306e6deb2d1954f 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -502,7 +502,7 @@ def add_link(realm, replica1, replica2, dirman_passwd, options):
except errors.NotFound:
sys.exit("You cannot connect to a previously deleted master")
-repl1.setup_gssapi_replication(replica2, "cn=Directory Manager", dirman_passwd)
+repl1.setup_gssapi_replication(replica2, DN(('cn', 'Directory Manager')), dirman_passwd)
print "Connected '%s' to '%s'" % (replica1, replica2)
def re_initialize(realm, thishost, fromhost, dirman_passwd):
--
1.7.10.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/15/2012 03:54 PM, Ade Lee wrote: > On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: >> On 08/08/2012 10:05 PM, Ade Lee wrote: >>> Hi, >>> >>> Dogtag 10 is being released on f18, and has a number of changes that >>> will affect IPA. In particular, the following changes will affect >>> current IPA code. >>> >>> * The directory layout of the dogtag instance has changed. Instead of >>> using separate tomcat instances to host different subsystems, the >>> standard dogtag installation will allow one to install a CA. KRA, OCSP >>> and TKS within the same instance. There have been corresponding changes >>> in the directory layout, as well as the default instance name >>> (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead >>> of pki-cad, pki-krad etc.) >>> >>> * The default instance will use only four ports (HTTPS, HTTP, AJP and >>> tomcat shutdown port) rather than the 6 previously used. The default >>> ports will be changed to the standard tomcat ports. As these ports are >>> local to the ipa server machine, this should not cause too much >>> disruption. >>> >>> * There is a new single step installer written in python. >>> (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. >>> >>> * Dogtag 10 runs on tomcat7 - with a new corresponding version of >>> tomcatjss. >>> >>> The attached patch integrates all the above changes in IPA installation >>> and maintenance code. Once the patch is applied, users will be able to: >>> >>> 1. run ipa-server-install to completion on f18 with dogtag 10. >>> 2. install a new replica on f18 on dogtag 10. >>> 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag >>> 10 - and have that old-style dogtag instance continue to run correctly. >>> This will require the installation of the latest version of tomcatjss as >>> well as the installation of tomcat6. The old-style instance will >>> continue to use tomcat6. >>> 4. in addition, the new cert renewal code has been patched and should >>> continue to work. >>> >>> What is not yet completed / supported: >>> >>> 1. Installation with an external CA is not yet completed in the new >>> installer. We plan to complete this soon. >>> >>> 2. There is some IPA upgrade code that has not yet been touched >>> (install/tools/ipa-upgradeconfig). >>> >>> 3. A script needs to be written to allow admins to convert their >>> old-style dogtag instances to new style instances, as well as code to >>> periodically prompt admins to do this. >>> >>> 4. Installation of old-style instances using pkicreate/pkisilent on >>> dogtag 10 will no longer be supported, and will be disabled soon. >>> >>> 5. The pki-selinux policy has been updated to reflect these changes, >>> but is still in flux. In fact, it is our intention to place the dogtag >>> selinux policy in the base selinux policy for f18. In the meantime, it >>> may be necessary to run installs in permissive mode. >>> >>> The dogtag 10 code will be released shortly into f18. Prior to that >>> though, we have placed the new dogtag 10 and tomcatjss code in a >>> developer repo that is located at >>> http://nkinder.fedorapeople.org/dogtag-devel/ >>> >>> Testing can be done on both f18 and f17 - although the target platform - >>> and the only platform for which official builds will be created is f18. >>> >>> Thanks, >>> Ade >>> >> >> Hi Ade, >> >> Thanks for the patch, I started with review and integration tests (currently >> running on Fedora 17 with Nathan's repo). >> >> Installation on single master was smooth, it worked just fine, even with >> enforced SELinux, without any error - kudos to you and the whole dogtag team. >> The resulting logs and the structure of your log directory seems improved. I >> believe that the brand new Python installers will make it easier to debug >> issues with dogtag installation when they come. When I tried our unit tests >> or >> some simple cert operation, it worked fine as well. >> >> Now the bad news, or rather few issues and suggestions I found: >> >> 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on >> Fedora 17 when I updated pki-ca, you somewhere miss a Requires. >> > We have a dogtag patch that is currently in review that will address > this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, > rather than f18+ > >> 2) I had installed IPA with dogtag10 on master. However, CA installation on a >> replica (ipa-ca-install) with dogtag9 failed - is this expectable? >> > Yes. The current IPA patch is designed to work with dogtag 10 only, > which will be officially available on f18+. So if you update to dogtag > 10, you must have this patch and visa versa. We probably need to add > the relevant requires to IPA to enforce this. > > If you have an existing dogtag 9 instance, and you upgrade to the new > dogtag 10 and patched IPA, then that instance will continue to work. > But any new instances would be created using dogtag 10. > >> 3) I had installed IPA with dogtag10
Re: [Freeipa-devel] [PATCH 0046] Separate RR data parsing from LDAP connections
On 08/15/2012 03:31 PM, Adam Tkac wrote:
On Wed, Aug 01, 2012 at 04:19:11PM +0200, Petr Spacek wrote:
Hello,
this patch finishes LDAP connection vs. LDAP result separation.
It is first step necessary for:
https://fedorahosted.org/bind-dyndb-ldap/ticket/68
Avoid manual connection management outside ldap_query()
It should prevent deadlocks in future.
Petr^2 Spacek
Thanks for the patch, please check one comment below.
Regards, Adam
From 4ba44be9e9bb7ef5abc9e077d6620de496ae7c0d Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Tue, 31 Jul 2012 14:33:53 +0200
Subject: [PATCH] Separate RR data parsing from LDAP connections.
Signed-off-by: Petr Spacek
---
src/ldap_helper.c | 76 ++-
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index
cc7003a6cdcd2d27404fec936623ed8a3e8fa7f8..af0ec092d29bce170d5c2dfa8836a728440116a3
100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -196,11 +196,6 @@ struct ldap_connection {
LDAPControl *serverctrls[2]; /* psearch/NULL or NULL/NULL */
int msgid;
- /* Parsing. */
- isc_lex_t *lex;
- isc_buffer_trdata_target;
- unsigned char *rdata_target_mem;
-
/* For reconnection logic. */
isc_time_t next_reconnect;
unsigned inttries;
@@ -214,6 +209,11 @@ struct ldap_qresult {
ld_string_t *query_string;
LDAPMessage *result;
ldap_entrylist_tldap_entries;
+
+ /* Parsing. */
+ isc_lex_t *lex;
+ isc_buffer_trdata_target;
+ unsigned char *rdata_target_mem;
};
/*
@@ -256,15 +256,15 @@ static void destroy_ldap_connection(ldap_pool_t *pool,
static isc_result_t findrdatatype_or_create(isc_mem_t *mctx,
ldapdb_rdatalist_t *rdatalist, dns_rdataclass_t rdclass,
dns_rdatatype_t rdtype, dns_ttl_t ttl, dns_rdatalist_t
**rdlistp);
-static isc_result_t add_soa_record(isc_mem_t *mctx, ldap_connection_t
*ldap_conn,
+static isc_result_t add_soa_record(isc_mem_t *mctx, ldap_qresult_t *qresult,
dns_name_t *origin, ldap_entry_t *entry,
ldapdb_rdatalist_t *rdatalist, const ld_string_t *fake_mname);
-static isc_result_t parse_rdata(isc_mem_t *mctx, ldap_connection_t *ldap_conn,
+static isc_result_t parse_rdata(isc_mem_t *mctx, ldap_qresult_t *qresult,
dns_rdataclass_t rdclass, dns_rdatatype_t rdtype,
dns_name_t *origin, const char *rdata_text,
dns_rdata_t **rdatap);
static isc_result_t ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry,
- ldap_connection_t *conn, dns_name_t *origin,
+ ldap_qresult_t *qresult, dns_name_t *origin,
const ld_string_t *fake_mname, ld_string_t *buf,
ldapdb_rdatalist_t *rdatalist);
static inline isc_result_t ldap_get_zone_serial(ldap_instance_t *inst,
@@ -637,8 +637,6 @@ new_ldap_connection(ldap_pool_t *pool, ldap_connection_t
**ldap_connp)
isc_mem_attach(pool->mctx, &ldap_conn->mctx);
- CHECK(isc_lex_create(ldap_conn->mctx, TOKENSIZ, &ldap_conn->lex));
- CHECKED_MEM_GET(ldap_conn->mctx, ldap_conn->rdata_target_mem, MINTSIZ);
CHECK(ldap_pscontrol_create(ldap_conn->mctx,
&ldap_conn->serverctrls[0]));
@@ -667,12 +665,6 @@ destroy_ldap_connection(ldap_pool_t *pool,
ldap_connection_t **ldap_connp)
if (ldap_conn->handle != NULL)
ldap_unbind_ext_s(ldap_conn->handle, NULL, NULL);
- if (ldap_conn->lex != NULL)
- isc_lex_destroy(&ldap_conn->lex);
- if (ldap_conn->rdata_target_mem != NULL) {
- isc_mem_put(ldap_conn->mctx,
- ldap_conn->rdata_target_mem, MINTSIZ);
- }
if (ldap_conn->serverctrls[0] != NULL) {
ldap_pscontrol_destroy(ldap_conn->mctx,
&ldap_conn->serverctrls[0]);
@@ -1431,7 +1423,7 @@ free_rdatalist(isc_mem_t *mctx, dns_rdatalist_t *rdlist)
static isc_result_t
ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry,
- ldap_connection_t *conn, dns_name_t *origin,
+ ldap_qresult_t *qresult, dns_name_t *origin,
const ld_string_t *fake_mname, ld_string_t *buf,
ldapdb_rdatalist_t *rdatalist)
{
@@ -1443,7 +1435,7 @@ ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry,
dns_rdatalist_t *rdlist = NULL;
ldap_attribute_t *attr;
- result = add_soa_record(mctx, conn, origin, entry,
+ result = add_soa_record(mctx, qresult, origin, entry,
rdatalist, fake_mname);
if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND)
goto cleanup;
@
Re: [Freeipa-devel] [PATCH 0042] Flush zones and RRs cache when handling persistent search reconnection
On 08/15/2012 03:11 PM, Adam Tkac wrote:
On Fri, Jul 27, 2012 at 12:16:07PM +0200, Petr Spacek wrote:
Hello,
this patch implements "Flush zones and RRs cache when handling
persistent search reconnection" behaviour as requested
in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/44 .
Petr^2 Spacek
+isc_result_t
+flush_ldap_cache(ldap_cache_t *cache)
+{
+ isc_result_t result;
+
+ REQUIRE(cache != NULL);
+
+ LOCK(&cache->mutex);
+ if (!ldap_cache_enabled(cache)) {
+ result = ISC_R_SUCCESS;
+ } else {
+ dns_rbt_destroy(&cache->rbt);
+ CHECK(dns_rbt_create(cache->mctx, cache_node_deleter, NULL,
+ &cache->rbt));
In my opinion usage of dns_rbt_deletename(cache->rbt, dns_rootname, ISC_TRUE) is
better, isn't it?
I looked into implementation of both functions. dns_rbt_deletenode() does
horribly complicated magic for simple task as "delete whole tree" is.
For this reason I called dns_rbt_destroy() - it is much simpler and should be
faster (it doesn't try to maintain RBT invariants during whole process).
Petr^2 Spacek
Otherwise OK.
+ }
+
+cleanup:
+ if (result != ISC_R_SUCCESS)
+ log_error_r("cache flush failed");
+ UNLOCK(&cache->mutex);
+ return result;
+}
Regards, Adam
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: > On 08/08/2012 10:05 PM, Ade Lee wrote: > > Hi, > > > > Dogtag 10 is being released on f18, and has a number of changes that > > will affect IPA. In particular, the following changes will affect > > current IPA code. > > > > * The directory layout of the dogtag instance has changed. Instead of > > using separate tomcat instances to host different subsystems, the > > standard dogtag installation will allow one to install a CA. KRA, OCSP > > and TKS within the same instance. There have been corresponding changes > > in the directory layout, as well as the default instance name > > (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > > of pki-cad, pki-krad etc.) > > > > * The default instance will use only four ports (HTTPS, HTTP, AJP and > > tomcat shutdown port) rather than the 6 previously used. The default > > ports will be changed to the standard tomcat ports. As these ports are > > local to the ipa server machine, this should not cause too much > > disruption. > > > > * There is a new single step installer written in python. > > (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > > > * Dogtag 10 runs on tomcat7 - with a new corresponding version of > > tomcatjss. > > > > The attached patch integrates all the above changes in IPA installation > > and maintenance code. Once the patch is applied, users will be able to: > > > > 1. run ipa-server-install to completion on f18 with dogtag 10. > > 2. install a new replica on f18 on dogtag 10. > > 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > > 10 - and have that old-style dogtag instance continue to run correctly. > > This will require the installation of the latest version of tomcatjss as > > well as the installation of tomcat6. The old-style instance will > > continue to use tomcat6. > > 4. in addition, the new cert renewal code has been patched and should > > continue to work. > > > > What is not yet completed / supported: > > > > 1. Installation with an external CA is not yet completed in the new > > installer. We plan to complete this soon. > > > > 2. There is some IPA upgrade code that has not yet been touched > > (install/tools/ipa-upgradeconfig). > > > > 3. A script needs to be written to allow admins to convert their > > old-style dogtag instances to new style instances, as well as code to > > periodically prompt admins to do this. > > > > 4. Installation of old-style instances using pkicreate/pkisilent on > > dogtag 10 will no longer be supported, and will be disabled soon. > > > > 5. The pki-selinux policy has been updated to reflect these changes, > > but is still in flux. In fact, it is our intention to place the dogtag > > selinux policy in the base selinux policy for f18. In the meantime, it > > may be necessary to run installs in permissive mode. > > > > The dogtag 10 code will be released shortly into f18. Prior to that > > though, we have placed the new dogtag 10 and tomcatjss code in a > > developer repo that is located at > > http://nkinder.fedorapeople.org/dogtag-devel/ > > > > Testing can be done on both f18 and f17 - although the target platform - > > and the only platform for which official builds will be created is f18. > > > > Thanks, > > Ade > > > > Hi Ade, > > Thanks for the patch, I started with review and integration tests (currently > running on Fedora 17 with Nathan's repo). > > Installation on single master was smooth, it worked just fine, even with > enforced SELinux, without any error - kudos to you and the whole dogtag team. > The resulting logs and the structure of your log directory seems improved. I > believe that the brand new Python installers will make it easier to debug > issues with dogtag installation when they come. When I tried our unit tests > or > some simple cert operation, it worked fine as well. > > Now the bad news, or rather few issues and suggestions I found: > > 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on > Fedora 17 when I updated pki-ca, you somewhere miss a Requires. > We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss >=7.0.0 will be required for f17+, rather than f18+ > 2) I had installed IPA with dogtag10 on master. However, CA installation on a > replica (ipa-ca-install) with dogtag9 failed - is this expectable? > Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new dogtag 10 and patched IPA, then that instance will continue to work. But any new instances would be created using dogtag 10. > 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well > and I got the following e
Re: [Freeipa-devel] [PATCH 0044] Fix and comment ispersistent() call in LDAP driver interface
On 08/15/2012 03:13 PM, Adam Tkac wrote: On Fri, Jul 27, 2012 at 03:06:05PM +0200, Petr Spacek wrote: Hello, this patch fixes ispersistent() call in LDAP driver interface. We were lucky, because ISC_R_NOTIMPLEMENTED is evaluated as ISC_TRUE every time, but I want to be sure. Petr^2 Spacek Ack Pushed to master: https://fedorahosted.org/bind-dyndb-ldap/changeset/b2b5fc80b0ae472be40d4c5096aa9adcd8222922 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0043] Extend API to be compatible with libdns interface >= 90
On 08/15/2012 03:11 PM, Adam Tkac wrote: On Fri, Jul 27, 2012 at 02:23:49PM +0200, Petr Spacek wrote: Hello, this patch prevents compiler warning on systems with libdns interface version >= 90. This libdns version comes with BIND 9.0.0. Both new methods are not obligatory, see in bind/lib/dns/db.c, functions dns_db_findext() and dns_db_findnodeext(). Petr^2 Spacek Ack Pushed to master: https://fedorahosted.org/bind-dyndb-ldap/changeset/815f075d3dd36fa44c59300361e02e5a61caaa51 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0046] Separate RR data parsing from LDAP connections
On Wed, Aug 01, 2012 at 04:19:11PM +0200, Petr Spacek wrote:
> Hello,
>
> this patch finishes LDAP connection vs. LDAP result separation.
>
> It is first step necessary for:
> https://fedorahosted.org/bind-dyndb-ldap/ticket/68
> Avoid manual connection management outside ldap_query()
>
> It should prevent deadlocks in future.
>
> Petr^2 Spacek
Thanks for the patch, please check one comment below.
Regards, Adam
> From 4ba44be9e9bb7ef5abc9e077d6620de496ae7c0d Mon Sep 17 00:00:00 2001
> From: Petr Spacek
> Date: Tue, 31 Jul 2012 14:33:53 +0200
> Subject: [PATCH] Separate RR data parsing from LDAP connections.
>
> Signed-off-by: Petr Spacek
> ---
> src/ldap_helper.c | 76
> ++-
> 1 file changed, 42 insertions(+), 34 deletions(-)
>
> diff --git a/src/ldap_helper.c b/src/ldap_helper.c
> index
> cc7003a6cdcd2d27404fec936623ed8a3e8fa7f8..af0ec092d29bce170d5c2dfa8836a728440116a3
> 100644
> --- a/src/ldap_helper.c
> +++ b/src/ldap_helper.c
> @@ -196,11 +196,6 @@ struct ldap_connection {
> LDAPControl *serverctrls[2]; /* psearch/NULL or NULL/NULL */
> int msgid;
>
> - /* Parsing. */
> - isc_lex_t *lex;
> - isc_buffer_trdata_target;
> - unsigned char *rdata_target_mem;
> -
> /* For reconnection logic. */
> isc_time_t next_reconnect;
> unsigned inttries;
> @@ -214,6 +209,11 @@ struct ldap_qresult {
> ld_string_t *query_string;
> LDAPMessage *result;
> ldap_entrylist_tldap_entries;
> +
> + /* Parsing. */
> + isc_lex_t *lex;
> + isc_buffer_trdata_target;
> + unsigned char *rdata_target_mem;
> };
>
> /*
> @@ -256,15 +256,15 @@ static void destroy_ldap_connection(ldap_pool_t *pool,
> static isc_result_t findrdatatype_or_create(isc_mem_t *mctx,
> ldapdb_rdatalist_t *rdatalist, dns_rdataclass_t rdclass,
> dns_rdatatype_t rdtype, dns_ttl_t ttl, dns_rdatalist_t
> **rdlistp);
> -static isc_result_t add_soa_record(isc_mem_t *mctx, ldap_connection_t
> *ldap_conn,
> +static isc_result_t add_soa_record(isc_mem_t *mctx, ldap_qresult_t *qresult,
> dns_name_t *origin, ldap_entry_t *entry,
> ldapdb_rdatalist_t *rdatalist, const ld_string_t *fake_mname);
> -static isc_result_t parse_rdata(isc_mem_t *mctx, ldap_connection_t
> *ldap_conn,
> +static isc_result_t parse_rdata(isc_mem_t *mctx, ldap_qresult_t *qresult,
> dns_rdataclass_t rdclass, dns_rdatatype_t rdtype,
> dns_name_t *origin, const char *rdata_text,
> dns_rdata_t **rdatap);
> static isc_result_t ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry,
> - ldap_connection_t *conn, dns_name_t *origin,
> + ldap_qresult_t *qresult, dns_name_t *origin,
> const ld_string_t *fake_mname, ld_string_t *buf,
> ldapdb_rdatalist_t *rdatalist);
> static inline isc_result_t ldap_get_zone_serial(ldap_instance_t *inst,
> @@ -637,8 +637,6 @@ new_ldap_connection(ldap_pool_t *pool, ldap_connection_t
> **ldap_connp)
>
> isc_mem_attach(pool->mctx, &ldap_conn->mctx);
>
> - CHECK(isc_lex_create(ldap_conn->mctx, TOKENSIZ, &ldap_conn->lex));
> - CHECKED_MEM_GET(ldap_conn->mctx, ldap_conn->rdata_target_mem, MINTSIZ);
> CHECK(ldap_pscontrol_create(ldap_conn->mctx,
> &ldap_conn->serverctrls[0]));
>
> @@ -667,12 +665,6 @@ destroy_ldap_connection(ldap_pool_t *pool,
> ldap_connection_t **ldap_connp)
> if (ldap_conn->handle != NULL)
> ldap_unbind_ext_s(ldap_conn->handle, NULL, NULL);
>
> - if (ldap_conn->lex != NULL)
> - isc_lex_destroy(&ldap_conn->lex);
> - if (ldap_conn->rdata_target_mem != NULL) {
> - isc_mem_put(ldap_conn->mctx,
> - ldap_conn->rdata_target_mem, MINTSIZ);
> - }
> if (ldap_conn->serverctrls[0] != NULL) {
> ldap_pscontrol_destroy(ldap_conn->mctx,
> &ldap_conn->serverctrls[0]);
> @@ -1431,7 +1423,7 @@ free_rdatalist(isc_mem_t *mctx, dns_rdatalist_t *rdlist)
>
> static isc_result_t
> ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry,
> -ldap_connection_t *conn, dns_name_t *origin,
> +ldap_qresult_t *qresult, dns_name_t *origin,
> const ld_string_t *fake_mname, ld_string_t *buf,
> ldapdb_rdatalist_t *rdatalist)
> {
> @@ -1443,7 +1435,7 @@ ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry,
> dns_rdatalist_t *rdlist = NULL;
> ldap_attribute_t *attr;
>
> - result = add_soa_record(mctx, conn, origin, entry,
> + result = add_soa_record(mctx, qresult, origin, entry,
> rdatalist, fake_mname);
> if (result
Re: [Freeipa-devel] [PATCH 0044] Fix and comment ispersistent() call in LDAP driver interface
On Fri, Jul 27, 2012 at 03:06:05PM +0200, Petr Spacek wrote:
> Hello,
>
> this patch fixes ispersistent() call in LDAP driver interface.
>
> We were lucky, because ISC_R_NOTIMPLEMENTED is evaluated as ISC_TRUE
> every time, but I want to be sure.
>
> Petr^2 Spacek
Ack
> From bfa32f2fa7d880a5c137cf1705202e939f1928e5 Mon Sep 17 00:00:00 2001
> From: Petr Spacek
> Date: Fri, 27 Jul 2012 14:58:22 +0200
> Subject: [PATCH] Fix and comment ispersistent() call in LDAP driver
> interface.
>
> Signed-off-by: Petr Spacek
> ---
> src/ldap_driver.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/ldap_driver.c b/src/ldap_driver.c
> index
> 51d618c5a2395c58b362a047096b1cf1fc40fbfd..470b6f315f0f4483eb60703b369891892368548a
> 100644
> --- a/src/ldap_driver.c
> +++ b/src/ldap_driver.c
> @@ -309,6 +309,11 @@ free_ldapdb(ldapdb_t *ldapdb)
> isc_mem_putanddetach(&ldapdb->common.mctx, ldapdb, sizeof(*ldapdb));
> }
>
> +
> +/**
> + * This method should never be called, because LDAP DB is "persistent".
> + * See ispersistent() function.
> + */
> static isc_result_t
> beginload(dns_db_t *db, dns_addrdatasetfunc_t *addp, dns_dbload_t **dbloadp)
> {
> @@ -323,6 +328,10 @@ beginload(dns_db_t *db, dns_addrdatasetfunc_t *addp,
> dns_dbload_t **dbloadp)
> return ISC_R_SUCCESS;
> }
>
> +/**
> + * This method should never be called, because LDAP DB is "persistent".
> + * See ispersistent() function.
> + */
> static isc_result_t
> endload(dns_db_t *db, dns_dbload_t **dbloadp)
> {
> @@ -1114,12 +1123,16 @@ nodecount(dns_db_t *db)
> return ISC_R_NOTIMPLEMENTED;
> }
>
> +/**
> + * Return TRUE, because database does not need to be loaded from disk
> + * or written to disk.
> + */
> static isc_boolean_t
> ispersistent(dns_db_t *db)
> {
> UNUSED(db);
>
> - return ISC_R_NOTIMPLEMENTED;
> + return ISC_TRUE;
> }
>
> static void
> --
> 1.7.11.2
>
--
Adam Tkac, Red Hat, Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0042] Flush zones and RRs cache when handling persistent search reconnection
On Fri, Jul 27, 2012 at 12:16:07PM +0200, Petr Spacek wrote:
> Hello,
>
> this patch implements "Flush zones and RRs cache when handling
> persistent search reconnection" behaviour as requested
> in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/44 .
>
> Petr^2 Spacek
> +isc_result_t
> +flush_ldap_cache(ldap_cache_t *cache)
> +{
> + isc_result_t result;
> +
> + REQUIRE(cache != NULL);
> +
> + LOCK(&cache->mutex);
> + if (!ldap_cache_enabled(cache)) {
> + result = ISC_R_SUCCESS;
> + } else {
> + dns_rbt_destroy(&cache->rbt);
> + CHECK(dns_rbt_create(cache->mctx, cache_node_deleter, NULL,
> + &cache->rbt));
In my opinion usage of dns_rbt_deletename(cache->rbt, dns_rootname, ISC_TRUE) is
better, isn't it?
Otherwise OK.
> + }
> +
> +cleanup:
> + if (result != ISC_R_SUCCESS)
> + log_error_r("cache flush failed");
> + UNLOCK(&cache->mutex);
> + return result;
> +}
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0043] Extend API to be compatible with libdns interface >= 90
On Fri, Jul 27, 2012 at 02:23:49PM +0200, Petr Spacek wrote:
> Hello,
>
> this patch prevents compiler warning on systems with libdns
> interface version >= 90. This libdns version comes with BIND 9.0.0.
>
> Both new methods are not obligatory, see in bind/lib/dns/db.c,
> functions dns_db_findext() and dns_db_findnodeext().
>
> Petr^2 Spacek
Ack
> From 9481fc6f6032f236d7e5e48f651906b25fd49b61 Mon Sep 17 00:00:00 2001
> From: Petr Spacek
> Date: Fri, 27 Jul 2012 14:18:15 +0200
> Subject: [PATCH] Extend API to be compatible with libdns interface >= 90.
>
> Signed-off-by: Petr Spacek
> ---
> src/ldap_driver.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/ldap_driver.c b/src/ldap_driver.c
> index
> cae45d4f6cc1f201c40ca3413d1f626e03a0318e..51d618c5a2395c58b362a047096b1cf1fc40fbfd
> 100644
> --- a/src/ldap_driver.c
> +++ b/src/ldap_driver.c
> @@ -1213,8 +1213,12 @@ static dns_dbmethods_t ldapdb_methods = {
> #endif /* LIBDNS_VERSION_MAJOR >= 45 */
> #if LIBDNS_VERSION_MAJOR >= 82
> NULL, /* rpz_enabled */
> - NULL/* rpz_findips */
> + NULL, /* rpz_findips */
> #endif /* LIBDNS_VERSION_MAJOR >= 82 */
> +#if LIBDNS_VERSION_MAJOR >= 90
> + NULL, /* findnodeext */
> + NULL/* findext */
> +#endif /* LIBDNS_VERSION_MAJOR >= 90 */
> };
>
> static isc_result_t
> --
> 1.7.11.2
>
--
Adam Tkac, Red Hat, Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On 08/08/2012 10:05 PM, Ade Lee wrote: > Hi, > > Dogtag 10 is being released on f18, and has a number of changes that > will affect IPA. In particular, the following changes will affect > current IPA code. > > * The directory layout of the dogtag instance has changed. Instead of > using separate tomcat instances to host different subsystems, the > standard dogtag installation will allow one to install a CA. KRA, OCSP > and TKS within the same instance. There have been corresponding changes > in the directory layout, as well as the default instance name > (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead > of pki-cad, pki-krad etc.) > > * The default instance will use only four ports (HTTPS, HTTP, AJP and > tomcat shutdown port) rather than the 6 previously used. The default > ports will be changed to the standard tomcat ports. As these ports are > local to the ipa server machine, this should not cause too much > disruption. > > * There is a new single step installer written in python. > (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. > > * Dogtag 10 runs on tomcat7 - with a new corresponding version of > tomcatjss. > > The attached patch integrates all the above changes in IPA installation > and maintenance code. Once the patch is applied, users will be able to: > > 1. run ipa-server-install to completion on f18 with dogtag 10. > 2. install a new replica on f18 on dogtag 10. > 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag > 10 - and have that old-style dogtag instance continue to run correctly. > This will require the installation of the latest version of tomcatjss as > well as the installation of tomcat6. The old-style instance will > continue to use tomcat6. > 4. in addition, the new cert renewal code has been patched and should > continue to work. > > What is not yet completed / supported: > > 1. Installation with an external CA is not yet completed in the new > installer. We plan to complete this soon. > > 2. There is some IPA upgrade code that has not yet been touched > (install/tools/ipa-upgradeconfig). > > 3. A script needs to be written to allow admins to convert their > old-style dogtag instances to new style instances, as well as code to > periodically prompt admins to do this. > > 4. Installation of old-style instances using pkicreate/pkisilent on > dogtag 10 will no longer be supported, and will be disabled soon. > > 5. The pki-selinux policy has been updated to reflect these changes, > but is still in flux. In fact, it is our intention to place the dogtag > selinux policy in the base selinux policy for f18. In the meantime, it > may be necessary to run installs in permissive mode. > > The dogtag 10 code will be released shortly into f18. Prior to that > though, we have placed the new dogtag 10 and tomcatjss code in a > developer repo that is located at > http://nkinder.fedorapeople.org/dogtag-devel/ > > Testing can be done on both f18 and f17 - although the target platform - > and the only platform for which official builds will be created is f18. > > Thanks, > Ade > Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install /home/mkosek/replica-info-vm-114.idm.lab.bos.redhat.com.gpg ... Configuring certificate server: Estimated time 3 minutes 30 seconds [1/14]: creating certificate server user [2/14]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' Root cause: ... File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 625, in __spawn_instance "/root/cacert.p12") ... 4) What ports does replica need to be open on the master when installing a CA? Currently, ipa-replica-conncheck does a port check and checks only for 7389, i.e. a port of backend LDAP instan
[Freeipa-devel] [PATCH 0053] Use richer set of return codes for LDAP connection error handling code
Hello,
current code return very generic ISC_R_FAILURE code in nearly all (error) cases.
This patch distinguishes between different LDAP errors and returns richer set
of return codes from LDAP connection error handling code.
It should lead to clearer log messages.
Petr^2 Spacek
From 15d6b38c9eda5b05d799c145ede8341f359e8633 Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Wed, 15 Aug 2012 13:01:48 +0200
Subject: [PATCH] Use richer set of return codes for LDAP connection error
handling code.
It should lead to clear log messages.
Signed-off-by: Petr Spacek
---
src/ldap_helper.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 798aeadfef27d7071a1dd4133b7f08a21918ef78..da083d2e65032e650cfbbeb863262e0141403407 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -1971,7 +1971,7 @@ ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn,
result = isc_time_now(&now);
time_cmp = isc_time_compare(&now, &ldap_conn->next_reconnect);
if (result == ISC_R_SUCCESS && time_cmp < 0)
- return ISC_R_FAILURE;
+ return ISC_R_SOFTQUOTA;
}
/* If either bind_dn or the password is not set, we will use
@@ -2050,6 +2050,8 @@ force_reconnect:
return ISC_R_NOPERM;
case LDAP_SERVER_DOWN:
return ISC_R_NOTCONNECTED;
+ case LDAP_TIMEOUT:
+ return ISC_R_TIMEDOUT;
default:
return ISC_R_FAILURE;
}
@@ -2085,13 +2087,16 @@ handle_connection_error(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn
switch (err_code) {
case LDAP_NO_SUCH_OBJECT:
ldap_conn->tries = 0;
- return ISC_R_SUCCESS;
+ result = ISC_R_SUCCESS;
+ break;
case LDAP_TIMEOUT:
log_error("LDAP query timed out. Try to adjust \"timeout\" parameter");
+ result = ISC_R_TIMEDOUT;
break;
case LDAP_INVALID_DN_SYNTAX:
case LDAP_INVALID_SYNTAX:
log_bug("Invalid syntax in handle_connection_error indicates a bug");
+ result = ISC_R_UNEXPECTEDTOKEN;
break;
default:
/* Try to reconnect on other errors. */
--
1.7.11.2
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0051-0052] Log successful reconnection to LDAP server
Hello,
this two patches solves upstream ticket
https://fedorahosted.org/bind-dyndb-ldap/ticket/71
"Log successful reconnect"
Patch 51:
Adds log_info(): logging facility with log level INFO.
Patch 52:
Logs successful reconnection to LDAP server.
LDAP connection error handling was modified:
Errors are handled exclusively by handle_connection_error() now.
Direct calls to ldap_connect() and ldap_reconnect() should be avoided.
--
Petr^2 Spacek
From 15286f0793d3666845e6b03b565d49f135b115ff Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Wed, 15 Aug 2012 12:05:56 +0200
Subject: [PATCH] Add log_info(): logging facility with log level INFO.
Signed-off-by: Petr Spacek
---
src/log.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/log.h b/src/log.h
index 898639be144dbf6049a1440493c3358e01a5c2dd..9062a4e80786b5bab806d6c9ceba1d1a9917a3e2 100644
--- a/src/log.h
+++ b/src/log.h
@@ -43,6 +43,9 @@
#define log_error(format, ...) \
log_write(GET_LOG_LEVEL(ISC_LOG_ERROR), format, ##__VA_ARGS__)
+#define log_info(format, ...) \
+ log_write(GET_LOG_LEVEL(ISC_LOG_INFO), format, ##__VA_ARGS__)
+
#define log_debug(level, format, ...) \
log_write(GET_LOG_LEVEL(level), format, ##__VA_ARGS__)
--
1.7.11.2
From 06f03d8b602656dc9581abc675c943d6fa6a6db2 Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Wed, 15 Aug 2012 12:57:32 +0200
Subject: [PATCH] Log successful reconnection to LDAP server.
LDAP connection error handling was modified:
Errors are handled exclusively by handle_connection_error() now.
Direct calls to ldap_connect() and ldap_reconnect() should be avoided.
https://fedorahosted.org/bind-dyndb-ldap/ticket/71
Signed-off-by: Petr Spacek
---
src/ldap_helper.c | 37 -
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index cc7003a6cdcd2d27404fec936623ed8a3e8fa7f8..798aeadfef27d7071a1dd4133b7f08a21918ef78 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -1734,7 +1734,7 @@ ldap_query(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn,
* successful
* TODO: handle this case inside ldap_pool_getconnection()?
*/
- CHECK(ldap_connect(ldap_inst, ldap_conn, ISC_FALSE));
+ CHECK(handle_connection_error(ldap_inst, ldap_conn, ISC_FALSE));
}
retry:
@@ -1903,14 +1903,16 @@ ldap_connect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn,
int ret;
int version;
struct timeval timeout;
+ isc_result_t result;
+ REQUIRE(ldap_inst != NULL);
REQUIRE(ldap_conn != NULL);
ret = ldap_initialize(&ld, str_buf(ldap_inst->uri));
if (ret != LDAP_SUCCESS) {
log_error("LDAP initialization failed: %s",
ldap_err2string(ret));
- goto cleanup;
+ CHECK(ISC_R_FAILURE);
}
version = LDAP_VERSION3;
@@ -1932,21 +1934,22 @@ ldap_connect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn,
if (ldap_conn->handle != NULL)
ldap_unbind_ext_s(ldap_conn->handle, NULL, NULL);
ldap_conn->handle = ld;
+ ld = NULL; /* prevent double-unbind from ldap_reconnect() and cleanup: */
- return ldap_reconnect(ldap_inst, ldap_conn, force);
+ CHECK(ldap_reconnect(ldap_inst, ldap_conn, force));
+ return result;
cleanup:
-
if (ld != NULL)
ldap_unbind_ext_s(ld, NULL, NULL);
/* Make sure handle is NULL. */
if (ldap_conn->handle != NULL) {
ldap_unbind_ext_s(ldap_conn->handle, NULL, NULL);
ldap_conn->handle = NULL;
}
- return ISC_R_FAILURE;
+ return result;
}
static isc_result_t
@@ -2064,12 +2067,18 @@ handle_connection_error(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn
{
int ret;
int err_code;
+ isc_result_t result = ISC_R_FAILURE;
- ret = ldap_get_option(ldap_conn->handle, LDAP_OPT_RESULT_CODE,
- (void *)&err_code);
+ REQUIRE(ldap_conn != NULL);
- if (ret != LDAP_OPT_SUCCESS) {
- log_error("handle_connection_error failed to obtain ldap error code");
+ if (ldap_conn->handle != NULL) {
+ ret = ldap_get_option(ldap_conn->handle, LDAP_OPT_RESULT_CODE,
+ (void *)&err_code);
+ if (ret != LDAP_OPT_SUCCESS) {
+ log_error("handle_connection_error failed to obtain ldap error code");
+ }
+ }
+ if (ldap_conn->handle == NULL || ret != LDAP_OPT_SUCCESS) {
goto reconnect;
}
@@ -2090,11 +2099,13 @@ handle_connection_error(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn
reconnect:
if (ldap_conn->tries == 0)
log_error("connection to the LDAP server was lost");
- return ldap_connect(ldap_inst, ldap_conn, force);
-
+ result = ldap_connect(ldap_inst, ldap_conn, force);
+ if (result == ISC_R_SUCCESS)
+ log_info("successfully reconnected to LDAP server");
+ break;
}
- return ISC_R_FAILURE;
+ return result;
}
/* FIXME: Handle the case where the LDAP handle is NULL -> try to reconnect. */
@@ -3476,7 +3487,7 @@ ldap_psearch_watcher(isc_threadarg_t arg)
"Next try in %ds", inst->reconnect_interval);
if (!sane_sleep(inst, inst->reconnect_interval))
goto cleanup;
- ld
Re: [Freeipa-devel] [PATCH 0042] Flush zones and RRs cache when handling persistent search reconnection
- Original Message - > On 08/14/2012 08:25 PM, Simo Sorce wrote: > > See man ldap_result, the entries return with type > > LDAP_RES_SEARCH_ENTRY, the last message is instead > > LDAP_RES_SEARCH_RESULT which tells you the searc is complete. > > > > This last message is never sent for a persistent search of course > > (IIRC :-). > > Right, it is what I tried to say with "there is no SearchResultDone > LDAP message". I see. > http://tools.ietf.org/html/draft-smith-psearch-ldap-01#page-3 > section 4 paragraph b). > > This patch deals with persistent search only. Non-persistent search > scenarios > have cache records with limited TTL value. > > > > > But in case of a persistent search you should never need to flush > > as entries are valid until you see a change. > Unfortunately, cache flush is necessary after persistent search > reconnection. > Records can change in meanwhile... > > Example: > 1. BIND started, cache was populated. > 2. Persistent search connection was lost > 3. Record was deleted (but Entry Change Notification wasn't > delivered) > 4. Persistent search connection was re-established - there is no > information > about deleted record/zone, BIND still sees old data in the cache. > > For this reason https://fedorahosted.org/bind-dyndb-ldap/ticket/44 > was filled. > > What I missed? You missed nothing, I did. Howeve I have an idea to handle this situation smartly. We can issue 2 searches on 2 separate connections. The first search will be a persistent search, however it will be started with a filter that has an additional element. Before the persistent search we do a rootdse search and find either the higher modifyTimestamp or the higher entryUSN or equivalent, depending on what is available in the server. Worst case we do a ase search of the DNS tree and pick that modifyTimestamp. Then we start the persistent search with (&(entryUSN>%d)) or (&(modifyTimestamp>=%d) (note modifyTimestamp requires >= due to low resolution). On the other connection we start instead a nornmal search. This normal search will terminate with a 'done' result, so you know that once that search is finished you can flush any cache that has not been re-validated. While you get any changes that are occurring live on the persistent search connection. This way we should be able to not loose any update and still know when we got all results and drop unvalidated caches. HTH, Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0042] Flush zones and RRs cache when handling persistent search reconnection
On 08/14/2012 08:25 PM, Simo Sorce wrote: On 08/12/2012 11:59 AM, Simo Sorce wrote: On 07/27/2012 12:15 PM, Petr Spacek wrote: Hello, this patch implements "Flush zones and RRs cache when handling persistent search reconnection" behaviour as requested in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/44 . Petr^2 Spacek Self-NACK :-) This second version has cache flush postponed a bit: Cache is flushed after receiving first result from LDAP. It should prevent unwanted cache flush in case of timeout or similar problems. Simo, are you ok with this approach? Sounds better. Ideally you do not flush until you get all results and no errors, but if that's difficult, waiting until the first results come in maybe be a decent first step. Simo. AFAIK there is no SearchResultDone LDAP message, so it is a bit problematic. See man ldap_result, the entries return with type LDAP_RES_SEARCH_ENTRY, the last message is instead LDAP_RES_SEARCH_RESULT which tells you the searc is complete. This last message is never sent for a persistent search of course (IIRC :-). Right, it is what I tried to say with "there is no SearchResultDone LDAP message". http://tools.ietf.org/html/draft-smith-psearch-ldap-01#page-3 section 4 paragraph b). This patch deals with persistent search only. Non-persistent search scenarios have cache records with limited TTL value. But in case of a persistent search you should never need to flush as entries are valid until you see a change. Unfortunately, cache flush is necessary after persistent search reconnection. Records can change in meanwhile... Example: 1. BIND started, cache was populated. 2. Persistent search connection was lost 3. Record was deleted (but Entry Change Notification wasn't delivered) 4. Persistent search connection was re-established - there is no information about deleted record/zone, BIND still sees old data in the cache. For this reason https://fedorahosted.org/bind-dyndb-ldap/ticket/44 was filled. What I missed? Thanks for your time! Petr^2 Spacek I created ticket for further improvements: https://fedorahosted.org/bind-dyndb-ldap/ticket/86 Ideas from ticket: We can measure time between ldap_result() calls and say "done" if interval between two received results is greater than x seconds... but it is not very reliable. There is problem with high modification rates (10/sec as mentioned on freeipa-users list), because inter-result interval can be too long for those cases. This "wait interval" can be shortened if result with Entry Change Notification is received ... but it can lead to problem with result interleaving and so on. Further investigation is needed. Indeed. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
