[Freeipa-devel] [PATCH] 0020..0022 pki-related upgrade fixes
The attached patches fix upgrade issues when pki is also updated
from pre 10.2.4.
pki dependency is bumped to 10.2.5 - the official builds should be
done Friday (US time) but it is available from my copr[1]. If
someone wants to add to official freeipa COPR in meantime the SRPM
is here[2].
[1] https://copr.fedoraproject.org/coprs/ftweedal/freeipa/
[2] https://ftweedal.fedorapeople.org/pki-core-10.2.5-0.2.fc21.src.rpm
Thanks,
Fraser
From 00848315ad19a9acdc132904c143c8951e028e67 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale ftwee...@redhat.com
Date: Fri, 19 Jun 2015 01:37:26 -0400
Subject: [PATCH 20/22] Upgrade: disconnect ldap2 after adding CA DNS records
Non-disconnection of ldap2 backend in 'add_ca_dns_records' seems to
be causing problems with later uses. Avoid the problem by
disconnecting it before returning.
---
ipaserver/install/server/upgrade.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ipaserver/install/server/upgrade.py
b/ipaserver/install/server/upgrade.py
index
a9dac59e009f5646630b7a8dd0e92f39b5a44a86..a949af58ff3f0b1df03e23fed6575e669f97cb15
100644
--- a/ipaserver/install/server/upgrade.py
+++ b/ipaserver/install/server/upgrade.py
@@ -1038,6 +1038,7 @@ def add_ca_dns_records():
if not ret['result']:
root_logger.info('DNS is not configured')
sysupgrade.set_upgrade_state('dns', 'ipa_ca_records', True)
+api.Backend.ldap2.disconnect()
return
bind = bindinstance.BindInstance()
@@ -1050,6 +1051,7 @@ def add_ca_dns_records():
ca_configured=None)
sysupgrade.set_upgrade_state('dns', 'ipa_ca_records', True)
+api.Backend.ldap2.disconnect()
def find_subject_base():
--
2.1.0
From 56c95d52582c4364910994a05017498df204 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale fr...@frase.id.au
Date: Tue, 16 Jun 2015 07:40:36 -0400
Subject: [PATCH 21/22] Upgrade CA schema during upgrade
New schema (for LDAP-based profiles) was introduced in Dogtag, but
Dogtag does not yet have a reliable method for upgrading its schema.
Use FreeIPA's schema update machinery to add the new attributeTypes
and objectClasses defined by Dogtag.
Also update the pki dependencies to 10.2.5, which provides the
schema update file.
---
freeipa.spec.in | 6 +++---
ipaserver/install/server/upgrade.py | 26 ++
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index
809ac1e5bb877c85e29c082ecfb9ad91aa97b4f5..a8c70f8a414855bb00bf4048ad788e455d0b94e2
100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -92,7 +92,7 @@ BuildRequires: python-backports-ssl_match_hostname
BuildRequires: softhsm-devel = 2.0.0rc1-1
BuildRequires: openssl-devel
BuildRequires: p11-kit-devel
-BuildRequires: pki-base = 10.2.4-1
+BuildRequires: pki-base = 10.2.5
BuildRequires: python-pytest-multihost = 0.5
BuildRequires: python-pytest-sourceorder
@@ -135,8 +135,8 @@ Requires(post): systemd-units
Requires: selinux-policy = %{selinux_policy_version}
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.54.2-1
-Requires: pki-ca = 10.2.4-1
-Requires: pki-kra = 10.2.4-1
+Requires: pki-ca = 10.2.5
+Requires: pki-kra = 10.2.5
Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: python-dns = 1.11.1
diff --git a/ipaserver/install/server/upgrade.py
b/ipaserver/install/server/upgrade.py
index
a949af58ff3f0b1df03e23fed6575e669f97cb15..78a4ace82f35193652cc535423309c67bca09df4
100644
--- a/ipaserver/install/server/upgrade.py
+++ b/ipaserver/install/server/upgrade.py
@@ -1256,6 +1256,31 @@ def update_mod_nss_protocol(http):
sysupgrade.set_upgrade_state('nss.conf', 'protocol_updated_tls12', True)
+def ca_upgrade_schema(ca):
+root_logger.info('[Upgrading CA schema]')
+if not ca.is_configured():
+root_logger.info('CA is not configured')
+return False
+
+realm = krbV.default_context().default_realm
+upgrade = IPAUpgrade(realm,
+schema_files=['/usr/share/pki/server/conf/schema-certProfile.ldif'])
+try:
+upgrade.create_instance()
+except BadSyntax:
+raise RuntimeError(
+'Bad syntax detected in CA schema file(s).', 1)
+except RuntimeError:
+raise RuntimeError('CA schema upgrade failed.', 1)
+else:
+if upgrade.modified:
+root_logger.info('CA schema update complete')
+return True
+else:
+root_logger.info('CA schema update complete (no changes)')
+return False
+
+
def add_default_caacl(ca):
root_logger.info('[Add default CA ACL]')
@@ -1443,6 +1468,7 @@ def upgrade_configuration():
ca_restart = any([
ca_restart,
+ca_upgrade_schema(ca),
upgrade_ca_audit_cert_validity(ca),
certificate_renewal_update(ca),
ca_enable_pkix(ca),
--
2.1.0
From c29e538ce269f31a6ac417c5288172accd2bdb11 Mon Sep 17 00:00:00 2001
From:
Re: [Freeipa-devel] Need to figure out how to make a schema change
On 06/19/2015 04:51 AM, Nathan Kinder wrote: On 06/18/2015 07:08 PM, Endi Sukma Dewata wrote: On 6/18/2015 8:19 PM, Fraser Tweedale wrote: In order for IPA to use some new functionality in Profile Management and Sub CAs, we need to add some additional schema to the Dogtag LDAP instance. Fraser has written a Dogtag upgrade script to do this upgrade, but this script expects the DM password to be in password.conf. Some discussion on this script can be found here .. https://www.redhat.com/archives/pki-devel/2015-June/msg00054.html In general, I think that while Dogtag will provide a database upgrade framework and/or upgrade LDIF scripts, we will not - in general - know how to connect to the DB with a user that has credentials to make schema changes. Fortunately, these types of changes are rare. Note that in all the years Dogtag has been part of IPA, this is the first time this situation has arisen. The question now though is - how can we co-ordinate with IPA to make this change? This question may have both a short term (for this particular change) and long term answer. What about using LDAPI and autobind functionality? If the upgrade script is run locally as root, then it can autobind to cn=Directory Manager without requiring a password. I like this idea, but I'm not sure how to accurately locate the socket, because the name depends on the domain, e.g. `/var/run/slapd-EXAMPLE-COM.socket'. I think the socket name would have to be provided by IPA via PKI deployment configuration. That would work. The other alternative is that we could advertise it in the root DSE. That would make upgrades harder, if IPA would have to pass this setting to PKI before PKI could upgrade. PKI should be aware of the realm/suffix/database name it runs on already, right? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0020..0022 pki-related upgrade fixes
On 06/19/2015 09:44 AM, Fraser Tweedale wrote: On Fri, Jun 19, 2015 at 09:38:01AM +0200, Martin Kosek wrote: On 06/19/2015 09:28 AM, Fraser Tweedale wrote: The attached patches fix upgrade issues when pki is also updated from pre 10.2.4. pki dependency is bumped to 10.2.5 - the official builds should be done Friday (US time) but it is available from my copr[1]. If someone wants to add to official freeipa COPR in meantime the SRPM is here[2]. [1] https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ [2] https://ftweedal.fedorapeople.org/pki-core-10.2.5-0.2.fc21.src.rpm Thanks, Fraser This may work, it would be of course cleaner to do this via context manager, in lines with: @contextmanager def ldap_connect_autobind(): if not api.Backend.ldap2.isconnected(): api.Backend.ldap2.connect(autobind=True) try: yield finally: if api.Backend.ldap2.isconnected(): api.Backend.ldap2.disconnect() ... try: with ldap_connect_autobind(): # do API stuff except PublicError, e: ... as that would also unbind it if exception is raised for example. Unless you or others feel strongly about this, let us do it as a cleanup later, as there are several places in upgrade.py that do this sort of thing. Alternatively (or in addition) we need to make ldap2 be able to attempt to reconnect on failure, as Simo (I think it was Simo) suggested recently in another thread. Cheers, Fraser Sure. Whatever is more systematic approach to this solution. We need to have as less hacks in the code as possible. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0020..0022 pki-related upgrade fixes
On Fri, Jun 19, 2015 at 09:38:01AM +0200, Martin Kosek wrote: On 06/19/2015 09:28 AM, Fraser Tweedale wrote: The attached patches fix upgrade issues when pki is also updated from pre 10.2.4. pki dependency is bumped to 10.2.5 - the official builds should be done Friday (US time) but it is available from my copr[1]. If someone wants to add to official freeipa COPR in meantime the SRPM is here[2]. [1] https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ [2] https://ftweedal.fedorapeople.org/pki-core-10.2.5-0.2.fc21.src.rpm Thanks, Fraser This may work, it would be of course cleaner to do this via context manager, in lines with: @contextmanager def ldap_connect_autobind(): if not api.Backend.ldap2.isconnected(): api.Backend.ldap2.connect(autobind=True) try: yield finally: if api.Backend.ldap2.isconnected(): api.Backend.ldap2.disconnect() ... try: with ldap_connect_autobind(): # do API stuff except PublicError, e: ... as that would also unbind it if exception is raised for example. Unless you or others feel strongly about this, let us do it as a cleanup later, as there are several places in upgrade.py that do this sort of thing. Alternatively (or in addition) we need to make ldap2 be able to attempt to reconnect on failure, as Simo (I think it was Simo) suggested recently in another thread. Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0003] Fix for a typo in certprofile mod command.
Patch attached.
Milan
From e8f08c2f5a567701e7991b1db8e796a0b5db0512 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?= mku...@redhat.com
Date: Fri, 19 Jun 2015 11:57:21 +0200
Subject: [PATCH] Fix for a typo in certprofile mod command.
---
ipalib/plugins/certprofile.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py
index 1a2d143882469858f225b37ba4ff2dd368fb8853..5158bf0bb994451eecb55451b944687e74c95ee8 100644
--- a/ipalib/plugins/certprofile.py
+++ b/ipalib/plugins/certprofile.py
@@ -246,7 +246,7 @@ class certprofile_del(LDAPDelete):
@register()
class certprofile_mod(LDAPUpdate):
__doc__ = _(Modify Certificate Profile configuration.)
-msg_summary = _('Modified Certificate Profile %(value)s')
+msg_summary = _('Modified Certificate Profile %(value)s')
def execute(self, *args, **kwargs):
ca_enabled_check()
--
1.9.3
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
On 06/18/2015 03:42 PM, David Kupka wrote: Dne 18.6.2015 v 13:22 Petr Vobornik napsal(a): On 06/18/2015 12:52 PM, Jan Cholasta wrote: Dne 18.6.2015 v 09:30 Jan Cholasta napsal(a): Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve rather than --permanently. There is plenty of commands (rm, cp, ...) which
[Freeipa-devel] [PATCH] 881 add python-setuptools to requires
Commit 9f049ca14403f3696d54d186e6b1b15181f055df introduced dependency on
python-setuptools on line:
from pkg_resources import parse_version
This dependency is missing on *minimal* installation and then
ipa-server-upgrade fails on rpm install/upgrade.
With:
Installing : freeipa-server-4.2.0.alpha1-0.fc22.x86_64 213/213
Traceback (most recent call last):
File /usr/sbin/ipa-server-upgrade, line 10, in module
from ipaserver.install.ipa_server_upgrade import ServerUpgrade
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py,
line 10, in module
from ipaserver.install import installutils
File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 42, in module
from ipapython import ipautil, sysrestore, admintool, dogtag, version
File /usr/lib/python2.7/site-packages/ipapython/sysrestore.py, line
35, in module
from ipaplatform.tasks import tasks
File /usr/lib/python2.7/site-packages/ipaplatform/tasks.py, line
26, in module
from ipaplatform.redhat.tasks import RedHatTaskNamespace
File /usr/lib/python2.7/site-packages/ipaplatform/redhat/tasks.py,
line 46, in module
from ipaplatform.base.tasks import BaseTaskNamespace
File /usr/lib/python2.7/site-packages/ipaplatform/base/tasks.py,
line 28, in module
from pkg_resources import parse_version
ImportError: No module named pkg_resources
--
Petr Vobornik
From ceaa69ad4ae68f4a55e6d3a2a6ebe5287edcbabe Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 19 Jun 2015 14:01:50 +0200
Subject: [PATCH] add python-setuptools to requires
Commit 9f049ca14403f3696d54d186e6b1b15181f055df introduced dependency on
python-setuptools on line:
from pkg_resources import parse_version
This dependency is missing on minimal installation and then ipa-server-upgrade
fails on rpm install/upgrade.
---
freeipa.spec.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 809ac1e5bb877c85e29c082ecfb9ad91aa97b4f5..b795c14a560977c7df307672e6c2b83e8aa5d35d 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -298,6 +298,7 @@ Requires: python-sss-murmur
%endif
Requires: wget
Requires: dbus-python
+Requires: python-setuptools
Conflicts: %{alt_name}-python
Obsoletes: %{alt_name}-python %{version}
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0020..0022 pki-related upgrade fixes
On 06/19/2015 09:28 AM, Fraser Tweedale wrote: The attached patches fix upgrade issues when pki is also updated from pre 10.2.4. pki dependency is bumped to 10.2.5 - the official builds should be done Friday (US time) but it is available from my copr[1]. If someone wants to add to official freeipa COPR in meantime the SRPM is here[2]. [1] https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ [2] https://ftweedal.fedorapeople.org/pki-core-10.2.5-0.2.fc21.src.rpm Thanks, Fraser This may work, it would be of course cleaner to do this via context manager, in lines with: @contextmanager def ldap_connect_autobind(): if not api.Backend.ldap2.isconnected(): api.Backend.ldap2.connect(autobind=True) try: yield finally: if api.Backend.ldap2.isconnected(): api.Backend.ldap2.disconnect() ... try: with ldap_connect_autobind(): # do API stuff except PublicError, e: ... as that would also unbind it if exception is raised for example. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0003] Fix for a typo in certprofile mod command.
On Fri, Jun 19, 2015 at 12:04:43PM +0200, Milan Kubik wrote: Patch attached. Milan ACK -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] LDAP errors in the dirsrv logs during replica preparation
On 06/19/2015 04:27 PM, Oleg Fayans wrote: Hi everybody, While preparing the replica files on the latest IPA master I've noticed the following error messages in the dirsrv error log: [19/Jun/2015:15:26:10 +0200] NSMMReplicationPlugin - agmt=cn=masterAgreement1-vm-244.idm.lab.eng.brq.redhat.com-pki-tomcat (vm-244:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [19/Jun/2015:15:26:10 +0200] - Entry uid=admin,ou=people,o=ipaca -- attribute krbExtraData not allowed Hi Oleg, Here this message is about a problem of schema. 'krbPrincipalAux' is needed objectclass to get 'krbExtraData', but the uid=admin,ou=people,o=ipaca has not this oc ldapsearch -LLL -D cn=directory manager -w Secret123 -b o=ipaca uid=admin objectclass dn: uid=admin,ou=people,o=ipaca objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: cmsuser Should ipaca admin be a kerberosed entry ? thanks thierry [19/Jun/2015:15:26:13 +0200] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success) Though the stdout of the replica preparation reports success, when I later use the resulting gpg file to actually setup a replica the setup process fails with the following output: Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds [1/8]: adding sasl mappings to the directory [2/8]: configuring KDC [3/8]: creating a keytab for the directory [4/8]: creating a keytab for the machine [5/8]: adding the password extension to the directory [6/8]: enable GSSAPI for replication [error] RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: No such object Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROROne of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: No such object The corresponding part of the ipareplica-install.log is attached I've encountered this already twice. The strangest part is that I prepared 3 replicas simultaneously: 2 of them installed successfully and one - failed. All three replicas were launched from the same vm-template -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] LDAP errors in the dirsrv logs during replica preparation
On 06/19/2015 04:27 PM, Oleg Fayans wrote: Hi everybody, While preparing the replica files on the latest IPA master I've noticed the following error messages in the dirsrv error log: [19/Jun/2015:15:26:10 +0200] NSMMReplicationPlugin - agmt=cn=masterAgreement1-vm-244.idm.lab.eng.brq.redhat.com-pki-tomcat (vm-244:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () Probably a leftover CA replication agreement with some removed master. Can be removed with ipa-csreplica-manage del --force. [19/Jun/2015:15:26:10 +0200] - Entry uid=admin,ou=people,o=ipaca -- attribute krbExtraData not allowed [19/Jun/2015:15:26:13 +0200] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success) Though the stdout of the replica preparation reports success, when I later use the resulting gpg file to actually setup a replica the setup process fails with the following output: Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds [1/8]: adding sasl mappings to the directory [2/8]: configuring KDC [3/8]: creating a keytab for the directory [4/8]: creating a keytab for the machine [5/8]: adding the password extension to the directory [6/8]: enable GSSAPI for replication [error] RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: No such object Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROROne of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: No such object The corresponding part of the ipareplica-install.log is attached I've encountered this already twice. The strangest part is that I prepared 3 replicas simultaneously: 2 of them installed successfully and one - failed. All three replicas were launched from the same vm-template Could this be the cause? It would be safer to run it sequentially. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] LDAP errors in the dirsrv logs during replica preparation
Hi everybody, While preparing the replica files on the latest IPA master I've noticed the following error messages in the dirsrv error log: [19/Jun/2015:15:26:10 +0200] NSMMReplicationPlugin - agmt=cn=masterAgreement1-vm-244.idm.lab.eng.brq.redhat.com-pki-tomcat (vm-244:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [19/Jun/2015:15:26:10 +0200] - Entry uid=admin,ou=people,o=ipaca -- attribute krbExtraData not allowed [19/Jun/2015:15:26:13 +0200] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success) Though the stdout of the replica preparation reports success, when I later use the resulting gpg file to actually setup a replica the setup process fails with the following output: Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds [1/8]: adding sasl mappings to the directory [2/8]: configuring KDC [3/8]: creating a keytab for the directory [4/8]: creating a keytab for the machine [5/8]: adding the password extension to the directory [6/8]: enable GSSAPI for replication [error] RuntimeError: One of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: No such object Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROROne of the ldap service principals is missing. Replication agreement cannot be converted. Replication error message: Unable to acquire replicaLDAP error: No such object The corresponding part of the ipareplica-install.log is attached I've encountered this already twice. The strangest part is that I prepared 3 replicas simultaneously: 2 of them installed successfully and one - failed. All three replicas were launched from the same vm-template -- Oleg Fayans Quality Engineer FreeIPA team RedHat. 2015-06-19T13:01:36Z INFO Setting agreement cn=meTovm-069.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2015-06-19T13:01:37Z INFO Deleting schedule 2358-2359 0 from agreement cn=meTovm-069.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config 2015-06-19T13:01:38Z INFO Replication Update in progress: FALSE: status: 32 Unable to acquire replicaLDAP error: No such object: start: 0: end: 0 2015-06-19T13:01:38Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/vm-244.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) and (krbprincipalname=ldap/vm-069.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) 2015-06-19T13:01:38Z DEBUG Unable to find entry for (krbprincipalname=ldap/vm-244.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) on vm-069.idm.lab.eng.brq.redhat.com:636 2015-06-19T13:01:38Z INFO Setting agreement cn=meTovm-069.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2015-06-19T13:01:39Z INFO Deleting schedule 2358-2359 0 from agreement cn=meTovm-069.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config 2015-06-19T13:01:40Z INFO Replication Update in progress: FALSE: status: 32 Unable to acquire replicaLDAP error: No such object: start: 0: end: 0 2015-06-19T13:01:40Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/vm-244.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) and (krbprincipalname=ldap/vm-069.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) 2015-06-19T13:01:40Z DEBUG Unable to find entry for (krbprincipalname=ldap/vm-244.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) on vm-069.idm.lab.eng.brq.redhat.com:636 2015-06-19T13:01:40Z INFO Setting agreement cn=meTovm-069.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2015-06-19T13:01:41Z INFO Deleting schedule 2358-2359 0 from agreement cn=meTovm-069.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping tree,cn=config 2015-06-19T13:01:42Z INFO Replication Update in progress: FALSE: status: 32 Unable to acquire replicaLDAP error: No such object: start: 0: end: 0 2015-06-19T13:01:42Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/vm-244.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) and (krbprincipalname=ldap/vm-069.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) 2015-06-19T13:01:42Z DEBUG Unable to find entry for (krbprincipalname=ldap/vm-244.idm.lab.eng.brq.redhat@idm.lab.eng.brq.redhat.com) on vm-069.idm.lab.eng.brq.redhat.com:636
