Re: [Freeipa-devel] [PATCH] 854 git ignore ipaplatform/__init__.py
On 05/20/2015 03:57 PM, Petr Vobornik wrote: This file is generated in `make version-update` added in 9f049ca14403f3696d54d186e6b1b15181f055df Yay no more warnings about untracked file! ACK -- Martin^3 Babinsky -- 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 428] client-install: Fix kinits with non-default Kerberos config file
Dne 20.5.2015 v 17:54 Martin Babinsky napsal(a): On 05/20/2015 04:28 PM, Jan Cholasta wrote: Hi, the attached patch fixes a bug introduced in the fix for https://fedorahosted.org/freeipa/ticket/4808 (reopened). Honza Works for me, ACK. Thanks. Pushed to: master: 454e8691cf7d64696fb8602d6e1ce5241f00f328 ipa-4-1: f6f94aec890bc48fd6268a054c0f6416aa8ee7d4 -- Jan Cholasta -- 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 0036] merge KRA installation machinery to a single module
On 05/19/2015 08:23 PM, Martin Babinsky wrote: This patch is required for the installer ref@#$%ing work (https://fedorahosted.org/freeipa/ticket/4468). It required quite a bit of hacking to get it work as expected, but I hope that it's not so bad. Requires PATCH 0035 do not check for directory manager password during KRA uninstall to apply. Attaching rebased patch that should apply cleanly on current master without prerequisites. -- Martin^3 Babinsky From ae002f2b86eaccb5219322de2ae23e42eb713166 Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Fri, 15 May 2015 19:02:22 +0200 Subject: [PATCH] merge KRA installation machinery to a single module This is a prerequisite to further refactoring of KRA install/uninstall functionality in all IPA install scripts. https://fedorahosted.org/freeipa/ticket/4468 --- install/tools/ipa-replica-install| 21 +++ install/tools/ipa-server-install | 26 +++- ipaserver/install/ipa_kra_install.py | 108 ++-- ipaserver/install/kra.py | 116 +++ 4 files changed, 153 insertions(+), 118 deletions(-) create mode 100644 ipaserver/install/kra.py diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index f68cc8cf4722264ecea2f1f50de3aa245be24ef9..d0c4a28fcf0bf0a2693ffef10626a8f99a69c8bc 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -37,10 +37,10 @@ from ipaserver.install import memcacheinstance, dnskeysyncinstance from ipaserver.install import otpdinstance from ipaserver.install.replication import replica_conn_check, ReplicationManager from ipaserver.install.installutils import ( -create_replica_config, read_replica_info_kra_enabled, private_ccache) +create_replica_config, private_ccache) from ipaserver.plugins.ldap2 import ldap2 from ipaserver.install import cainstance -from ipaserver.install import krainstance +from ipaserver.install import kra from ipaserver.install import dns as dns_installer from ipalib import api, create_api, errors, util, certstore, x509 from ipalib.constants import CACERT @@ -473,12 +473,12 @@ def main(): config.setup_kra = options.setup_kra if config.setup_kra: -if not config.setup_ca: -print CA must be installed with the KRA -sys.exit(1) -if not read_replica_info_kra_enabled(config.dir): -print KRA is not installed on the master system -sys.exit(1) +try: +kra.check_install(options, dirman_password, + config.setup_ca, filename) +except RuntimeError as e: +print str(e) +exit(1) installutils.verify_fqdn(config.master_host_name, options.no_host_dns) @@ -660,10 +660,7 @@ def main(): ds.apply_updates() if options.setup_kra: -kra = krainstance.install_replica_kra(config) -service.print_msg(Restarting the directory server) -ds.restart() -kra.enable_client_auth_to_db(kra.dogtag_constants.KRA_CS_CFG_PATH) +kra.install(options, dirman_password, replica_file=filename) else: service.print_msg(Restarting the directory server) ds.restart() diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install index cb6e1abe2016c0f8cefc35b1d685373f05b3ef89..f4ef71d84d30d79f70f164c30f274d8769b3e319 100755 --- a/install/tools/ipa-server-install +++ b/install/tools/ipa-server-install @@ -53,13 +53,13 @@ from ipaserver.install import httpinstance from ipaserver.install import ntpinstance from ipaserver.install import certs from ipaserver.install import cainstance -from ipaserver.install import krainstance from ipaserver.install import memcacheinstance from ipaserver.install import otpdinstance from ipaserver.install import sysupgrade from ipaserver.install import replication from ipaserver.install import dns as dns_installer from ipaserver.install import service, installutils +from ipaserver.install import kra from ipapython import version from ipapython import certmonger from ipapython import ipaldap @@ -577,11 +577,12 @@ def uninstall(): if cads_instance.is_configured(): cads_instance.uninstall() -kra_instance = krainstance.KRAInstance( -api.env.realm, dogtag_constants=dogtag_constants) -kra_instance.stop_tracking_certificates() -if kra_instance.is_installed(): -kra_instance.uninstall() +try: +kra.check_uninstall() +except RuntimeError: +pass +else: +kra.uninstall() ca_instance = cainstance.CAInstance( api.env.realm, certs.NSS_DIR, dogtag_constants=dogtag_constants) @@ -1290,18 +1291,7 @@ def main(): http.restart() if setup_kra: -kra = krainstance.KRAInstance(realm_name, -dogtag_constants=dogtag.install_constants) -kra.configure_instance(host_name, domain_name,
Re: [Freeipa-devel] [PATCH 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin
On 05/20/2015 03:03 PM, Martin Basti wrote: Enforcing uniqueness for uid attribute prevent to move users to delete users subtree. Patch attached. Hello Martin, The fix looks good. Don't we need to do the same in install/share/unique-attributes.ldif for fresh install ? thanks thierry -- 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 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin
On 05/21/2015 11:06 AM, Martin Basti wrote: On 21/05/15 10:59, thierry bordaz wrote: On 05/21/2015 10:53 AM, Martin Basti wrote: On 21/05/15 10:14, thierry bordaz wrote: On 05/20/2015 03:03 PM, Martin Basti wrote: Enforcing uniqueness for uid attribute prevent to move users to delete users subtree. Patch attached. Hello Martin, The fix looks good. Don't we need to do the same in install/share/unique-attributes.ldif for fresh install ? thanks thierry Thanks for review. I don think so. In 10-uniqueness.update files, there are specified default values, which will be used for new installations. I would like to keep configuration of plugin just at one place. Yes that is a good idea. Does that mean that eventually files like unique-attributes.ldif will disappear ? Maybe in future. So is this patch ACKed? Sorry, yes the fix is good. ACK thanks thierry Martin^2 -- Martin Basti -- Martin Basti -- 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 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin
On 21/05/15 10:59, thierry bordaz wrote: On 05/21/2015 10:53 AM, Martin Basti wrote: On 21/05/15 10:14, thierry bordaz wrote: On 05/20/2015 03:03 PM, Martin Basti wrote: Enforcing uniqueness for uid attribute prevent to move users to delete users subtree. Patch attached. Hello Martin, The fix looks good. Don't we need to do the same in install/share/unique-attributes.ldif for fresh install ? thanks thierry Thanks for review. I don think so. In 10-uniqueness.update files, there are specified default values, which will be used for new installations. I would like to keep configuration of plugin just at one place. Yes that is a good idea. Does that mean that eventually files like unique-attributes.ldif will disappear ? Maybe in future. So is this patch ACKed? thanks thierry Martin^2 -- Martin Basti -- Martin Basti -- 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 0251] Fix uniqueness: exclude compat tree from uid uniquness plugin
On 05/21/2015 10:53 AM, Martin Basti wrote: On 21/05/15 10:14, thierry bordaz wrote: On 05/20/2015 03:03 PM, Martin Basti wrote: Enforcing uniqueness for uid attribute prevent to move users to delete users subtree. Patch attached. Hello Martin, The fix looks good. Don't we need to do the same in install/share/unique-attributes.ldif for fresh install ? thanks thierry Thanks for review. I don think so. In 10-uniqueness.update files, there are specified default values, which will be used for new installations. I would like to keep configuration of plugin just at one place. Yes that is a good idea. Does that mean that eventually files like unique-attributes.ldif will disappear ? thanks thierry Martin^2 -- Martin Basti -- 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] [PATCHES 0001-0011 v3] Profile management
On 21/05/15 14:31, Martin Basti wrote: On 21/05/15 14:16, Martin Basti wrote: On 20/05/15 16:41, Fraser Tweedale wrote: Hi Honza, Martin et al, Latest patches attached. On top of previous patches (most review matters addressed**) patches 0008..0011 add support for profiles and user certificates to `ipa cert-request'. ** those that were not are being tracked at [1]; please add anything I missed. Some points to note: - usercertificate is not yet a multi-valued attribute for users, hosts and services. QUESTION - we do want to allow multiple certificates for all principal types, not just users? Or have I got that wrong. - DN and SAN match principal checks are not implemented for users yet. - ACL was added to allow user principals to request their own certificates, however, this will be further subject to CA/profile ACLs which are to come. - Pursuant to [2] revocation logic was removed from `cert-request' [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates Thanks, Fraser I tried upgrade and: Updating managed permissions for certprofile Upgrade failed with targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [error] RuntimeError: targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [cleanup]: stopping directory server [cleanup]: restoring configuration I cannot find the ipacertprofilestoreissued in any IPA schema file. Did I miss something? Sorry, I found it, stupid me. I will investigate why upgrade failed then. Bug in ipa-server-upgrade, thank you to find this issue :-) -- Martin Basti -- 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] certprofiles -- problem with delete
On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote: Hi Fraser and list, I ran into this when I was tinkering with the commands. The ipa certprofile plugin[s] does not take the backend result into the picture right now. When I tried to delete the *default profile*, the entry from ipa suffix got deleted. However the command failed and the profile is still in the dogtag managed suffix. After I've done this to the installed instance, subsequent uninstall operation failed on some step involving dogtag. I suspect it is related. I haven't been able to reproduce this for now as at the moment there was no package with dogtag in the copr repo. Reproducer for this is attached. (This reproducer requires patches at least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) It may be more complicated issue than it seems, though. If we delete the ipa managed entry before the dogtag operation and this one fails, it leaves us in an inconsistent state. If on the other hand we delete the ipa managed entry after dogtag call, it opens an possibility of failing to delete the entry in ipa, leading to inconsistency again. The solution to this would be a transaction. The problem here is that the transaction here would span through two integrated components (three actually, ipa, 389 and dogtag, in this context). Not an easy thing to do I assume. TL;DR: * certprofile-del deletes ipa managed entry and dogtag doesn't * how do we approach possibly irreversible changes in LDAPObject plugins when integrated component doesn't behave? Your thoughts on this? Thanks for the report - certprofile-del was working at an earlier stage so I will track down the issue and fix. I have pondered the transaction requirements: I am managing it for certprofile-import by deleting the entry if the dogtag import fails. I suppose I can do a similar thing for certprofile del - keep a copy of the entry and re-add it if delete fails. Sound OK to you? Cheers, Fraser Thanks, Milan -- 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] certprofiles -- problem with delete
On 05/21/2015 03:10 PM, Fraser Tweedale wrote: On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote: Hi Fraser and list, I ran into this when I was tinkering with the commands. The ipa certprofile plugin[s] does not take the backend result into the picture right now. When I tried to delete the *default profile*, the entry from ipa suffix got deleted. However the command failed and the profile is still in the dogtag managed suffix. After I've done this to the installed instance, subsequent uninstall operation failed on some step involving dogtag. I suspect it is related. I haven't been able to reproduce this for now as at the moment there was no package with dogtag in the copr repo. Reproducer for this is attached. (This reproducer requires patches at least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) It may be more complicated issue than it seems, though. If we delete the ipa managed entry before the dogtag operation and this one fails, it leaves us in an inconsistent state. If on the other hand we delete the ipa managed entry after dogtag call, it opens an possibility of failing to delete the entry in ipa, leading to inconsistency again. The solution to this would be a transaction. The problem here is that the transaction here would span through two integrated components (three actually, ipa, 389 and dogtag, in this context). Not an easy thing to do I assume. TL;DR: * certprofile-del deletes ipa managed entry and dogtag doesn't * how do we approach possibly irreversible changes in LDAPObject plugins when integrated component doesn't behave? Your thoughts on this? Thanks for the report - certprofile-del was working at an earlier stage so I will track down the issue and fix. I have pondered the transaction requirements: I am managing it for certprofile-import by deleting the entry if the dogtag import fails. I suppose I can do a similar thing for certprofile del - keep a copy of the entry and re-add it if delete fails. Sound OK to you? Yeah, this is what we do in permission-mod post_callback for example. Cheers, Fraser Thanks, Milan -- 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 0255] Server Upgrade: Fix: executed schema upgrade
Accidentaly , schema upgrade hasn't beed executed by ipa-server-upgrade. https://fedorahosted.org/freeipa/ticket/4904 Patch attached. -- Martin Basti From d6b1107aa9f952bf61dbdbaabdbab822d0dc69b5 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Thu, 21 May 2015 14:40:22 +0200 Subject: [PATCH] Server Upgrade: Fix: execute schema update Accidentaly schema upgrade has not been executed. https://fedorahosted.org/freeipa/ticket/4904 --- ipaserver/install/ipa_server_upgrade.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ipaserver/install/ipa_server_upgrade.py b/ipaserver/install/ipa_server_upgrade.py index 7e85c0dca042614b3e591d87f8687314ae3981cb..6236e2ed033708189ad10c184fd8e57a0b34953b 100644 --- a/ipaserver/install/ipa_server_upgrade.py +++ b/ipaserver/install/ipa_server_upgrade.py @@ -2,6 +2,7 @@ # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # +import os import sys import krbV @@ -9,6 +10,7 @@ import krbV from ipalib import api from ipaplatform.paths import paths from ipapython import admintool, ipautil +from ipaserver.install import dsinstance from ipaserver.install import installutils from ipaserver.install.upgradeinstance import IPAUpgrade from ipaserver.install.ldapupdate import BadSyntax @@ -73,7 +75,9 @@ class ServerUpgrade(admintool.AdminTool): system) realm = krbV.default_context().default_realm -data_upgrade = IPAUpgrade(realm) +schema_files = [os.path.join(ipautil.SHARE_DIR, f) for f +in dsinstance.ALL_SCHEMA_FILES] +data_upgrade = IPAUpgrade(realm, schema_files=schema_files) try: data_upgrade.create_instance() -- 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
[Freeipa-devel] [PATCH 0254] Server Upgrade: Wait until DS is ready after restart
This patch should fix following traceback.
2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to
'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket':
2015-05-20T03:50:41Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py,
line 304, in __upgrade
ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True)
File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line
314, in __init__
self.create_connection()
File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line
862, in create_connection
autobind=self.ldapi)
File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 66, in connect
conn = self.create_connection(*args, **kw)
File /usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py, line 188,
in create_connection
client_controls=clientctrls)
File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1074, in
external_bind
'', auth_tokens, server_controls, client_controls)
File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__
self.gen.throw(type, value, traceback)
File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 976, in
error_handler
error=info)
NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket':
2015-05-20T03:50:41Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
388, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
378, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py,
line 315, in __upgrade
raise RuntimeError(e)
RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket':
Reason was the ipa-server-install tried to connect before DS was ready.
The patch adds waiting until DS is ready.
Patch attached.
Fraser can you please check if this fix works? I can't reproduce it.
Thank you, Martin^2.
From 3183fc490d9615fada1dcc9069eb1303e9e61be8 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Thu, 21 May 2015 13:25:10 +0200
Subject: [PATCH] Server Upgrade: wait until DS is ready
During server upgrade we should wait until DS is ready after restart, otherwise
connection error is raised.
Instead of 389 port, the DS socket is checked.
https://fedorahosted.org/freeipa/ticket/4904
---
ipaplatform/redhat/services.py | 14 ++
ipaserver/install/upgradeinstance.py | 8 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py
index d6fa080add35cb5aafb2b347dc5fb6e84cc3e4e8..565bf1fdef27e9a780ad2e2638b5051a95782bd2 100644
--- a/ipaplatform/redhat/services.py
+++ b/ipaplatform/redhat/services.py
@@ -153,6 +153,20 @@ class RedHatDirectoryService(RedHatService):
super(RedHatDirectoryService, self).restart(instance_name,
capture_output=capture_output, wait=wait)
+def wait_for_open_ports(self, instance_name=):
+if instance_name.endswith('.service'):
+instance_name = instance_name[:-8]
+if instance_name.startswith('dirsrv@'):
+instance_name = instance_name[7:]
+
+if instance_name:
+
+ipautil.wait_for_open_socket(
+paths.SLAPD_INSTANCE_SOCKET_TEMPLATE % instance_name,
+self.api.env.startup_timeout)
+else:
+super(RedHatDirectoryService, self).wait_for_open_ports()
+
class RedHatIPAService(RedHatService):
# Enforce restart of IPA services when we do enable it
diff --git a/ipaserver/install/upgradeinstance.py b/ipaserver/install/upgradeinstance.py
index 2540df60f1c14b99dbd5b9cdd12d7590edc1bd32..d58c934bc1bd926c0c0c068086c746ac28e8c737 100644
--- a/ipaserver/install/upgradeinstance.py
+++ b/ipaserver/install/upgradeinstance.py
@@ -171,10 +171,8 @@ class IPAUpgrade(service.Service):
self.schema_files = schema_files
self.realm = realm_name
-def __start_nowait(self):
-# Don't wait here because we've turned off port 389. The connection
-# we make will wait for the socket.
-super(IPAUpgrade, self).start(wait=False)
+def __start(self):
+super(IPAUpgrade, self).start()
def __stop_instance(self):
Stop only the main DS instance
@@ -187,7 +185,7 @@ class IPAUpgrade(service.Service):
self.step(saving configuration, self.__save_config)
self.step(disabling listeners, self.__disable_listeners)
self.step(enabling DS global lock, self.__enable_ds_global_write_lock)
-self.step(starting directory server, self.__start_nowait)
+self.step(starting directory server, self.__start)
if self.schema_files:
self.step(updating schema, self.__update_schema)
self.step(upgrading server, self.__upgrade)
--
2.1.0
Re: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management
On 20/05/15 16:41, Fraser Tweedale wrote: Hi Honza, Martin et al, Latest patches attached. On top of previous patches (most review matters addressed**) patches 0008..0011 add support for profiles and user certificates to `ipa cert-request'. ** those that were not are being tracked at [1]; please add anything I missed. Some points to note: - usercertificate is not yet a multi-valued attribute for users, hosts and services. QUESTION - we do want to allow multiple certificates for all principal types, not just users? Or have I got that wrong. - DN and SAN match principal checks are not implemented for users yet. - ACL was added to allow user principals to request their own certificates, however, this will be further subject to CA/profile ACLs which are to come. - Pursuant to [2] revocation logic was removed from `cert-request' [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates Thanks, Fraser I tried upgrade and: Updating managed permissions for certprofile Upgrade failed with targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [error] RuntimeError: targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [cleanup]: stopping directory server [cleanup]: restoring configuration I cannot find the ipacertprofilestoreissued in any IPA schema file. Did I miss something? -- Martin Basti -- 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] certprofiles -- problem with delete
Hi Fraser and list, I ran into this when I was tinkering with the commands. The ipa certprofile plugin[s] does not take the backend result into the picture right now. When I tried to delete the *default profile*, the entry from ipa suffix got deleted. However the command failed and the profile is still in the dogtag managed suffix. After I've done this to the installed instance, subsequent uninstall operation failed on some step involving dogtag. I suspect it is related. I haven't been able to reproduce this for now as at the moment there was no package with dogtag in the copr repo. Reproducer for this is attached. (This reproducer requires patches at least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) It may be more complicated issue than it seems, though. If we delete the ipa managed entry before the dogtag operation and this one fails, it leaves us in an inconsistent state. If on the other hand we delete the ipa managed entry after dogtag call, it opens an possibility of failing to delete the entry in ipa, leading to inconsistency again. The solution to this would be a transaction. The problem here is that the transaction here would span through two integrated components (three actually, ipa, 389 and dogtag, in this context). Not an easy thing to do I assume. TL;DR: * certprofile-del deletes ipa managed entry and dogtag doesn't * how do we approach possibly irreversible changes in LDAPObject plugins when integrated component doesn't behave? Your thoughts on this? Thanks, Milan delete_default_profile.sh Description: application/shellscript -- 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 0254] Server Upgrade: Wait until DS is ready after restart
On Thu, May 21, 2015 at 01:38:43PM +0200, Martin Basti wrote: This patch should fix following traceback. 2015-05-20T03:50:41Z ERROR Upgrade failed with cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 304, in __upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 314, in __init__ self.create_connection() File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 862, in create_connection autobind=self.ldapi) File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 66, in connect conn = self.create_connection(*args, **kw) File /usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py, line 188, in create_connection client_controls=clientctrls) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1074, in external_bind '', auth_tokens, server_controls, client_controls) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 976, in error_handler error=info) NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': 2015-05-20T03:50:41Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 388, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 378, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 315, in __upgrade raise RuntimeError(e) RuntimeError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket': Reason was the ipa-server-install tried to connect before DS was ready. The patch adds waiting until DS is ready. Patch attached. Fraser can you please check if this fix works? I can't reproduce it. Thank you, Martin^2. ACK; fixes the issue for me. One minor comment: +def __start(self): +super(IPAUpgrade, self).start() def __stop_instance(self): Stop only the main DS instance @@ -187,7 +185,7 @@ class IPAUpgrade(service.Service): self.step(saving configuration, self.__save_config) self.step(disabling listeners, self.__disable_listeners) self.step(enabling DS global lock, self.__enable_ds_global_write_lock) -self.step(starting directory server, self.__start_nowait) +self.step(starting directory server, self.__start) I think you can just say `self.start' and remove `__start' function. 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
Re: [Freeipa-devel] [PATCHES 0001-0011 v3] Profile management
On 21/05/15 14:16, Martin Basti wrote: On 20/05/15 16:41, Fraser Tweedale wrote: Hi Honza, Martin et al, Latest patches attached. On top of previous patches (most review matters addressed**) patches 0008..0011 add support for profiles and user certificates to `ipa cert-request'. ** those that were not are being tracked at [1]; please add anything I missed. Some points to note: - usercertificate is not yet a multi-valued attribute for users, hosts and services. QUESTION - we do want to allow multiple certificates for all principal types, not just users? Or have I got that wrong. - DN and SAN match principal checks are not implemented for users yet. - ACL was added to allow user principals to request their own certificates, however, this will be further subject to CA/profile ACLs which are to come. - Pursuant to [2] revocation logic was removed from `cert-request' [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates Thanks, Fraser I tried upgrade and: Updating managed permissions for certprofile Upgrade failed with targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [error] RuntimeError: targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [cleanup]: stopping directory server [cleanup]: restoring configuration I cannot find the ipacertprofilestoreissued in any IPA schema file. Did I miss something? Sorry, I found it, stupid me. I will investigate why upgrade failed then. -- Martin Basti -- 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] manage replication topology in the shared tree
On 05/20/2015 05:40 PM, Ludwig Krispenz wrote: please find new versions of patches 0003 and 0005 for the topology plugin. the ds plugin patch includes - changes to match domain level patch - remove trailing white spaces - use proper oids for topology schema the install patch - has the 70topology.ldif removed Hello Ludwig, I failed to do 'git am patch-0003', it returned a strange Patch format detection failed.. However I was able to do 'git apply' and to review it. I focus on the points discussed during previous reviews. The patch is looking good to me. ACK thanks thierry both patches can now be applied On 05/20/2015 03:40 PM, Ludwig Krispenz wrote: On 05/20/2015 03:07 PM, Petr Vobornik wrote: On 05/20/2015 02:58 PM, Ludwig Krispenz wrote: On 05/20/2015 02:52 PM, Oleg Fayans wrote: Is this patch to be applied on top of the vanilla upstream tree, or does it require your previous patches applied before? it requires the install (0005) and ipa-command (0006) patch as well, submitted on 05/12 Patch 0005 can't be applied on top of the new patch 3. Both patches contains adding of 70topology.ldif. ok, this was my mistake when splitting the original patch, it should only be in the plugin part the trailing spaces in most cases are leftovers from the request to make lines shorter, I will fix it for a new version Also please clear all trailing whitespaces from patch 3. $ git am freeipa-lkrispen-0003-plugin-part-manage-replication-topology-in-the-shaer.patch Applying: plugin part - manage replication topology in the shaerd tree /home/somebody/freeipa/.git/rebase-apply/patch:607: trailing whitespace. /home/somebody/freeipa/.git/rebase-apply/patch:740: trailing whitespace. * find the attrtype and return the corresponding /home/somebody/freeipa/.git/rebase-apply/patch:742: trailing whitespace. */ /home/somebody/freeipa/.git/rebase-apply/patch:745: trailing whitespace. /* attr is handling specific direction, /home/somebody/freeipa/.git/rebase-apply/patch:772: trailing whitespace. /* two static data structures to hold the warning: squelched 125 whitespace errors warning: 130 lines add whitespace errors. On 05/19/2015 02:16 PM, Ludwig Krispenz wrote: Hi, here is the latest patch for the plugin part, trying to address all problems found in the review Regards, Ludwig PS if you want you can get a separate diff top the last version On 05/12/2015 08:33 AM, Ludwig Krispenz wrote: Hi, I did split the patches, for easier review and to share work on it. The attachment contains 4 patches: - the ds plugin part as submitted for review - the changes to the ds plugin part done after review (not complete yet) - the ipa framework part (including Petr's improvements) - the install related part Regards, Ludwig On 04/21/2015 01:09 PM, Petr Vobornik wrote: On 04/21/2015 12:53 PM, Petr Vobornik wrote: On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: Hi, in the attachment you find the latest state of the topology plugin, it implements what is defined in the design page: http://www.freeipa.org/page/V4/Manage_replication_topology (which is also waiting for a reviewer) It contains the plugin itself and a core of ipa commands to manage a topology. to be really applicable, some work outside is required, eg the management of the domain level and a decision where the binddn group should be maintained. Thanks, Ludwig I've looked at the python part, mostly because I want to start with POC of Web UI for topology. topology.py is clearly still a work in progress. I've reflected following comments into a patch to speed things up. What's in the patch: 1. git am complains about trailing whitespaces 2. pep8 check produces quite a lot of issues. New code should be almost with any (`E501 line too long` is not a hard rule) `git diff HEAD~1 -U0 | pep8 --diff` 3. some typos 4. A lot of unused imports 5. Option name --sname for 'Segment identifier' is not very friendly. I don't see any examples of command options in the design notes. 6. NO_UPG_MAGIC - leftover from other plugin? 7. suffix object has labels from segment 8. IPA framework has a support for nested object. Key is setting `parent_object = 'topologysuffix'` in topologysegment object. 9. repl_agmt_attrs could be in topologysegment takes_params. 10. missing various CRUD commands like topologysuffix-find and topologysuffix-show commands. Whats missing, not fixed: 1. last 2 lines of VERSION file are not updated 2. Mixed terminology. Somewhere is used suffix and somewhere replication area or just area. 3. Validation - suffix should check for dn - existence of both ends of a segment 4. print of segments in suffix-show needs to be improved or removed To discuss: a) Do params in topologysegment have to have a maxlength set? b) Terminology has to be united. Segments are nested in suffix but sometimes are called areas and suffix is 'the suffix'. User might be confused. E.g. shouldn't the object be
[Freeipa-devel] [PATCH 0372-0375] Fix doc/schema to be compatible with OpenLDAP
Hello,
I need to use the schema with OpenLDAP server and apparently OpenLDAP can't
handle the original line ordering.
Pushed to master:
2a65d0b2962bbeec4f769e9724d0d22879e24193 Turn doc/schema into a valid LDIF file.
e86c94b63e62fefef96fbec6377bf43a0e246d84 Add COSINE schema attributes to
doc/schema.
e16a59471c5e9c88d4baee225c38c7dcd8159573 Fix doc/schema ordering to be
compatible with OpenLDAP.
e8444906881f4ba5d707fa2a611f1a8187142d00 Rename doc/schema to doc/schema.ldif.
--
Petr^2 Spacek
From 2a65d0b2962bbeec4f769e9724d0d22879e24193 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Thu, 21 May 2015 09:13:45 +0200
Subject: [PATCH] Turn doc/schema into a valid LDIF file.
Trailing whitespaces are there on purpose to make 389 DS schema parser happy.
---
doc/schema | 676 ++---
1 file changed, 336 insertions(+), 340 deletions(-)
rewrite doc/schema (86%)
diff --git a/doc/schema b/doc/schema
dissimilarity index 86%
index 5ed9e6f5d6ef11ebcf90e63d5b1e3492b7cc95d1..cf2c24e31929807414233d043ae0005d1f7fdd2c 100644
--- a/doc/schema
+++ b/doc/schema
@@ -1,340 +1,336 @@
-# This schema contains OIDs from Uninett and FreeIPA.
-#
-# Unninet: http://drift.uninett.no/nett/ip-nett/dnsattributes.schema
-# Base OID for DNS records is 1.3.6.1.4.1.2428.20.1,
-# see http://drift.uninett.no/nett/ip-nett/oids.html
-#
-# FreeIPA: http://freeipa.org/
-# Base OID for DNS records is 2.16.840.1.113730.3.8.5
-# Base OID for DNS objectClasses is 2.16.840.1.113730.3.8.6
-#
-# If you want to add some record types that are defined by IANA,
-# please define it similar to what is done for the existing ones. The
-# name should be {TYPE}Record, and OID should be
-# 1.3.6.1.4.1.2428.20.1.value. For instance the RR type LOC has value
-# 29, so attribute name should be LocRecord (casing shouldn't matter),
-# and the OID is 1.3.6.1.4.1.2428.20.1.29. If you follow this, you
-# know that it will be compatible with what others use, and one is
-# guaranteed that the OIDs are unique.
-# The IANA DNS record type values are available from
-# URL: http://www.iana.org/assignments/dns-parameters .
-#
-# If you define new attributes, please report them to dr...@uninett.no
-# to get them added of this schema.
-#
-# The basic record types like A, CNAME etc are defined in the cosine
-# schema and not in this schema. This means that your LDAP server
-# must use both the cosine schema and this one to get all the DNS
-# attributes defined.
-
-attributetype ( 1.3.6.1.4.1.2428.20.0.0
- NAME 'dNSTTL'
- DESC 'An integer denoting time to live'
- EQUALITY integerMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.0.1
- NAME 'dNSClass'
- DESC 'The class of a resource record'
- EQUALITY caseIgnoreIA5Match
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.12
- NAME 'pTRRecord'
- DESC 'domain name pointer, RFC 1035'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.13
- NAME 'hInfoRecord'
- DESC 'host information, RFC 1035'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.14
- NAME 'mInfoRecord'
- DESC 'mailbox or mail list information, RFC 1035'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.16
- NAME 'tXTRecord'
- DESC 'text string, RFC 1035'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.18
- NAME 'aFSDBRecord'
- DESC 'for AFS Data Base location, RFC 1183'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.28
- NAME 'aAAARecord'
- DESC 'IPv6 address, RFC 1886'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.29
- NAME 'LocRecord'
- DESC 'Location, RFC 1876'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.30
- NAME 'nXTRecord'
- DESC 'non-existant, RFC 2535'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.33
- NAME 'sRVRecord'
- DESC 'service location, RFC 2782'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-attributetype ( 1.3.6.1.4.1.2428.20.1.35
- NAME 'nAPTRRecord'
- DESC 'Naming Authority Pointer, RFC 2915'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
[Freeipa-devel] [PATCH 0376] Add schema for unknown record types
Hello, Add schema for unknown record types. This patch complements my previous patch 367. The change was pushed to https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. -- Petr^2 Spacek From 4880ac7743c1dad0133754a9bc87dbbd28b89591 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Thu, 21 May 2015 12:35:13 +0200 Subject: [PATCH] Add schema for unknown record types. --- doc/schema.ldif | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/doc/schema.ldif b/doc/schema.ldif index 872d505348e94e946d676b1178690f18cf2c8bac..a1fcac50d647cbed74e8688a6289beb6ae4bd048 100644 --- a/doc/schema.ldif +++ b/doc/schema.ldif @@ -219,6 +219,14 @@ attributeTypes: ( 1.3.6.1.4.1.2428.20.1.32769 EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch ) # +# See https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/UnknownRecord +attributeTypes: ( 1.3.6.1.4.1.2428.20.4 + NAME 'UnknownRecord' + DESC 'unknown DNS record, RFC 3597' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 + EQUALITY caseIgnoreIA5Match + SUBSTR caseIgnoreIA5SubstringsMatch ) +# attributeTypes: ( 2.16.840.1.113730.3.8.5.0 NAME 'idnsName' DESC 'DNS FQDN' @@ -354,7 +362,7 @@ objectClasses: ( 2.16.840.1.113730.3.8.6.0 SRVRecord $ TXTRecord $ MXRecord $ MDRecord $ HINFORecord $ MINFORecord $ AFSDBRecord $ LOCRecord $ NXTRecord $ NAPTRRecord $ KXRecord $ CERTRecord $ DNAMERecord $ - DSRecord $ SSHFPRecord $ DLVRecord $ TLSARecord + DSRecord $ SSHFPRecord $ DLVRecord $ TLSARecord $ UnknownRecord ) ) # objectClasses: ( 2.16.840.1.113730.3.8.6.1 -- 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] proposal: new API command to list IPA servers
Petr Vobornik wrote: Hi all, proposal is to create following two commands: ipa server-find ipa server-show FQDN These commands will display a list of IPA servers stored in cn=masters,cn=ipa,cn=etc,$SUFFIX No mod and add commands atm. They could be added when needed. Installed service won't be shown as well.; Main reasons for adding them are: 1. let people know what they could enter in: ipa topologysegment-add SUFFIX --leftnode=NODE --rightnode=NODE 2. web ui needs this info to offer a list of IPA servers for the same task as in #1 3. it's convenient In Brno, we had an offline discussion about the object name and 'server' was a winner. Other discussed candidates were: topologynode, node, master, replica, topologyserver, managedserver. Server was chosen because: - IPA server is commonly used - works well with other terminology/commands, e.g. ipa-server-install - is not bound to topology (in comparison to replica or master) - is short - works well with future installation of server parts like CA through API Adding Rob and Simo to CC explicitly so they could object if they wish ;) Kudos for including the reasoning. I still lean more towards master but don't object too much to server given the reasoning. My only hesitation to server is that it is a rather generic term but it seems like a CLI user will quickly learn the difference between host and server so it should be ok. +1 rob -- 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 0255] Server Upgrade: Fix: executed schema upgrade
On Thu, May 21, 2015 at 02:49:03PM +0200, Martin Basti wrote: Accidentaly , schema upgrade hasn't beed executed by ipa-server-upgrade. https://fedorahosted.org/freeipa/ticket/4904 Patch attached. -- Martin Basti ACK; the schema changes once again are applied during upgrade. Thanks, Fraser From d6b1107aa9f952bf61dbdbaabdbab822d0dc69b5 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Thu, 21 May 2015 14:40:22 +0200 Subject: [PATCH] Server Upgrade: Fix: execute schema update Accidentaly schema upgrade has not been executed. https://fedorahosted.org/freeipa/ticket/4904 --- ipaserver/install/ipa_server_upgrade.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ipaserver/install/ipa_server_upgrade.py b/ipaserver/install/ipa_server_upgrade.py index 7e85c0dca042614b3e591d87f8687314ae3981cb..6236e2ed033708189ad10c184fd8e57a0b34953b 100644 --- a/ipaserver/install/ipa_server_upgrade.py +++ b/ipaserver/install/ipa_server_upgrade.py @@ -2,6 +2,7 @@ # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # +import os import sys import krbV @@ -9,6 +10,7 @@ import krbV from ipalib import api from ipaplatform.paths import paths from ipapython import admintool, ipautil +from ipaserver.install import dsinstance from ipaserver.install import installutils from ipaserver.install.upgradeinstance import IPAUpgrade from ipaserver.install.ldapupdate import BadSyntax @@ -73,7 +75,9 @@ class ServerUpgrade(admintool.AdminTool): system) realm = krbV.default_context().default_realm -data_upgrade = IPAUpgrade(realm) +schema_files = [os.path.join(ipautil.SHARE_DIR, f) for f +in dsinstance.ALL_SCHEMA_FILES] +data_upgrade = IPAUpgrade(realm, schema_files=schema_files) try: data_upgrade.create_instance() -- 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 -- 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] [PATCHES 0001-0011 v3] Profile management
On Thu, May 21, 2015 at 02:46:20PM +0200, Martin Basti wrote: On 21/05/15 14:31, Martin Basti wrote: On 21/05/15 14:16, Martin Basti wrote: On 20/05/15 16:41, Fraser Tweedale wrote: Hi Honza, Martin et al, Latest patches attached. On top of previous patches (most review matters addressed**) patches 0008..0011 add support for profiles and user certificates to `ipa cert-request'. ** those that were not are being tracked at [1]; please add anything I missed. Some points to note: - usercertificate is not yet a multi-valued attribute for users, hosts and services. QUESTION - we do want to allow multiple certificates for all principal types, not just users? Or have I got that wrong. - DN and SAN match principal checks are not implemented for users yet. - ACL was added to allow user principals to request their own certificates, however, this will be further subject to CA/profile ACLs which are to come. - Pursuant to [2] revocation logic was removed from `cert-request' [1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress [2] http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates Thanks, Fraser I tried upgrade and: Updating managed permissions for certprofile Upgrade failed with targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [error] RuntimeError: targetattr ipacertprofilestoreissued does not exist in schema. Please add attributeTypes ipacertprofilestoreissued to schema if necessary. ACL Syntax Error(-5):(targetattr = \22cn || description || ipacertprofilestoreissued\22)(targetfilter = \22(objectclass=ipacertprofile)\22)(version 3.0;acl \22permission:System: Modify Certificate Profile\22;allow (write) groupdn = \22ldap:///cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com\22;): Invalid syntax. [cleanup]: stopping directory server [cleanup]: restoring configuration I cannot find the ipacertprofilestoreissued in any IPA schema file. Did I miss something? Sorry, I found it, stupid me. I will investigate why upgrade failed then. Bug in ipa-server-upgrade, thank you to find this issue :-) And thanks for the fix! There are still some issues with upgrade; I will address in next patch set. -- Martin Basti -- 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] certprofiles -- problem with delete
On Thu, May 21, 2015 at 03:20:30PM +0200, Martin Kosek wrote: On 05/21/2015 03:10 PM, Fraser Tweedale wrote: On Thu, May 21, 2015 at 02:36:14PM +0200, Milan Kubik wrote: Hi Fraser and list, I ran into this when I was tinkering with the commands. The ipa certprofile plugin[s] does not take the backend result into the picture right now. When I tried to delete the *default profile*, the entry from ipa suffix got deleted. However the command failed and the profile is still in the dogtag managed suffix. After I've done this to the installed instance, subsequent uninstall operation failed on some step involving dogtag. I suspect it is related. I haven't been able to reproduce this for now as at the moment there was no package with dogtag in the copr repo. Reproducer for this is attached. (This reproducer requires patches at least up to freeipa-ftweedal-0005-3-Add-certprofile-plugin.patch) It may be more complicated issue than it seems, though. If we delete the ipa managed entry before the dogtag operation and this one fails, it leaves us in an inconsistent state. If on the other hand we delete the ipa managed entry after dogtag call, it opens an possibility of failing to delete the entry in ipa, leading to inconsistency again. The solution to this would be a transaction. The problem here is that the transaction here would span through two integrated components (three actually, ipa, 389 and dogtag, in this context). Not an easy thing to do I assume. TL;DR: * certprofile-del deletes ipa managed entry and dogtag doesn't * how do we approach possibly irreversible changes in LDAPObject plugins when integrated component doesn't behave? Your thoughts on this? Thanks for the report - certprofile-del was working at an earlier stage so I will track down the issue and fix. I have pondered the transaction requirements: I am managing it for certprofile-import by deleting the entry if the dogtag import fails. I suppose I can do a similar thing for certprofile del - keep a copy of the entry and re-add it if delete fails. Sound OK to you? Yeah, this is what we do in permission-mod post_callback for example. OK, it is settled; will address in next patchset. Thanks Martin. Cheers, Fraser Thanks, Milan -- 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 0368-0371] Support LDAP MODRDN for ordinary DNS records
Hello, patches seem to work all right. Thus ACK. Matúš Honěk - Original Message - From: Petr Spacek pspa...@redhat.com To: tho...@redhat.com, Matus Honek mho...@redhat.com Cc: freeipa-devel@redhat.com Sent: Wednesday, May 20, 2015 9:06:47 AM Subject: [PATCH 0368-0371] Support LDAP MODRDN for ordinary DNS records Hello, this patchset implements support for MODRDN for ordinary records. As noted in ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/123, we agreed yesterday that renaming zones is out of scope and seems unnecessarily complex. This patch set depends on 'metadb' branch. It is also available from: https://github.com/pspacek/bind-dyndb-ldap/tree/modrdn Thank you for your time! -- Petr^2 Spacek -- 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] proposal: new API command to list IPA servers
Hi all, proposal is to create following two commands: ipa server-find ipa server-show FQDN These commands will display a list of IPA servers stored in cn=masters,cn=ipa,cn=etc,$SUFFIX No mod and add commands atm. They could be added when needed. Installed service won't be shown as well.; Main reasons for adding them are: 1. let people know what they could enter in: ipa topologysegment-add SUFFIX --leftnode=NODE --rightnode=NODE 2. web ui needs this info to offer a list of IPA servers for the same task as in #1 3. it's convenient In Brno, we had an offline discussion about the object name and 'server' was a winner. Other discussed candidates were: topologynode, node, master, replica, topologyserver, managedserver. Server was chosen because: - IPA server is commonly used - works well with other terminology/commands, e.g. ipa-server-install - is not bound to topology (in comparison to replica or master) - is short - works well with future installation of server parts like CA through API Adding Rob and Simo to CC explicitly so they could object if they wish ;) -- 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
Re: [Freeipa-devel] [PATCH 0325] Add Domain Level feature
Dne 21.5.2015 v 18:18 Tomas Babej napsal(a): On 05/19/2015 04:07 PM, Tomas Babej wrote: On 05/19/2015 03:59 PM, Martin Kosek wrote: On 05/19/2015 03:56 PM, Tomas Babej wrote: On 05/19/2015 03:51 PM, Martin Kosek wrote: On 05/19/2015 03:49 PM, Ludwig Krispenz wrote: On 05/19/2015 03:36 PM, Martin Kosek wrote: On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. I don't mind using cn=Domain Level , but where does the entry live, here you say cn=Domain Level,cn=ipa,cn=etc,SUFFIX and in the design page it is: cn=DomainLevel,cn=etc,SUFFIX The current version of the topology plugin is looking for cn=DomainLevel,cn=ipa,cn=etc,SUFFIX but I want to change it to do a search on objectclass=ipaDomainLevelConfig I see - we all need to unify the location apparently. I updated the design page to use cn=Domain Level,cn=ipa,cn=etc,SUFFIX. Tomas, please send the updated patch set, it should be an extremely simple change :-) I prefer the ipa parent and the space in the name, so I'm glad we could agree on this without much bikeshedding. Updated patch attaced. Tomas I still see +# Create default Domain Level entry if it does not exist +dn: cn=DomainLevel,cn=ipa,cn=etc,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaDomainLevelConfig +default: ipaDomainLevel: 0 ... Right, the space eluded me there, thanks for the catch. Tomas A new iteration of the patch, including the server-side checks for the installers. Tomas 1) https://www.redhat.com/archives/freeipa-devel/2015-May/msg00228.html - I still don't agree that the plugin should be based on LDAPObject. 2) Use api domainlevel-show call to get the current domain level in ipa-replica-install instead of duplicating the code. 3) Set the domain level in DSInstance.create_instance instead of a separate call in ipa-server-install. It should be done about the same time as the master entry is added. 4) I think the option should be named --domain-level (with a dash), for consistency. -- Jan Cholasta -- 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] [PATCHES 0001-0011 v3] Profile management
On 20/05/15 16:41, Fraser Tweedale wrote:
Hi Honza, Martin et al,
Latest patches attached. On top of previous patches (most review
matters addressed**) patches 0008..0011 add support for profiles and
user certificates to `ipa cert-request'.
** those that were not are being tracked at [1]; please add anything
I missed.
Some points to note:
- usercertificate is not yet a multi-valued attribute for users,
hosts and services.
QUESTION - we do want to allow multiple certificates for all
principal types, not just users? Or have I got that wrong.
Changing schema can cause issues in future, we already burn ourselves
several times.
If you plan to have multi valued attribute in close future, could be
better to have mutltivalued schema now, instead of make this change in
future?
- DN and SAN match principal checks are not implemented for users
yet.
- ACL was added to allow user principals to request their own
certificates, however, this will be further subject to CA/profile
ACLs which are to come.
- Pursuant to [2] revocation logic was removed from `cert-request'
[1] http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress
[2]
http://www.freeipa.org/page/V4/User_Certificates#Revocation_of_the_Certificates
Thanks,
Fraser
Thanks for updated patches:
Please update required pki version in freeipa.spec.in
Patch 0001:
Again, will be this change done after upgrade, instead of new installation?
config.set(CA, pki_profiles_in_ldap, True)
I blame method 'ca_enable_ldap_profile_subsystem' in upgrade to do this,
but I'm not sure.
Patch 0005:
1)
just nitpick:
profile_id_pattern = re.compile('^[a-zA-Z]\w*$')
PROFILE_ID_PATTERN = re.compile('^profileId=(\w+)', re.MULTILINE)
In PROFILE_ID_PATTERN should be '^profileId=([a-zA-Z]\w*)' to be consistent
Patch 0007:
There are still modifications in ipa-server-isntall
Patch 0010:
1)
+aci: (targetattr = usercertificate)(version 3.0;acl
selfservice:Users can manage their own X.509 certificates;allow
(write) userdn = ldap:///self;;)
This is not in any upgrade file
2)
+# User certificates
+dn: $SUFFIX
+add:aci:(targetattr = ipasshpubkey)(version 3.0;acl
selfservice:Users can manage their own X.509 certificates;allow
(write) userdn = ldap:///self;;)
Is this right? (ipasshpubkey) This ACI with different name is already there.
3)
IMO this should not be there.
'replaces': [
-'(targetattr = givenname || sn || cn || displayname ||
title || initials || loginshell || gecos || homephone || mobile || pager
|| facsimiletelephonenumber || telephonenumber || street || roomnumber
|| l || st || postalcode || manager || secretary || description ||
carlicense || labeleduri || inetuserhttpurl || seealso || employeetype
|| businesscategory || ou || mepmanagedentry || objectclass)(target =
ldap:///uid=*,cn=users,cn=accounts,$SUFFIX;)(version 3.0;acl
permission:Modify Users;allow (write) groupdn = ldap:///cn=Modify
Users,cn=permissions,cn=pbac,$SUFFIX;)',
+'(targetattr = givenname || sn || cn || displayname ||
title || initials || loginshell || gecos || homephone || mobile || pager
|| facsimiletelephonenumber || telephonenumber || street || roomnumber
|| l || st || postalcode || manager || secretary || description ||
carlicense || labeleduri || inetuserhttpurl || seealso || employeetype
|| businesscategory || usercertificate || ou || mepmanagedentry ||
objectclass)(target =
ldap:///uid=*,cn=users,cn=accounts,$SUFFIX;)(version 3.0;acl
permission:Modify Users;allow (write) groupdn = ldap:///cn=Modify
Users,cn=permissions,cn=pbac,$SUFFIX;)',
],
this replace replaces permissions written in old style. New permission
are updated automaticaly (AFAIK)
PAtch 0011:
Please dont use '_' in code, this is for ugettext and may cause an
issue in future
+bind_service, _, _ = bind_principal
Martin^2
--
Martin Basti
--
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 0325] Add Domain Level feature
On 05/19/2015 04:07 PM, Tomas Babej wrote: On 05/19/2015 03:59 PM, Martin Kosek wrote: On 05/19/2015 03:56 PM, Tomas Babej wrote: On 05/19/2015 03:51 PM, Martin Kosek wrote: On 05/19/2015 03:49 PM, Ludwig Krispenz wrote: On 05/19/2015 03:36 PM, Martin Kosek wrote: On 05/19/2015 03:22 PM, Tomas Babej wrote: ... 3) Domain level is just a single integer and it should be treated as such, there's no need for an LDAPObject plugin and other unnecessary complexities. The implemetation could be as simple as (from top of my head, untested): That's right, I also considered this approach, but as far as I know you do not get the permission handling for the global DomainLevel entry otherwise. Ludwig, I changed the path for the global entry to cn=DomainLevel. I know this particular DN was added to the design by Simo, but why do we want to use CamelCase with LDAP object? Wouldn't cn=Domain Level,cn=ipa,cn=etc,SUFFIX be a better place for it? This is the last time we can change it, so I am asking now. Then, we will be stuck with this DN forever. I don't mind using cn=Domain Level , but where does the entry live, here you say cn=Domain Level,cn=ipa,cn=etc,SUFFIX and in the design page it is: cn=DomainLevel,cn=etc,SUFFIX The current version of the topology plugin is looking for cn=DomainLevel,cn=ipa,cn=etc,SUFFIX but I want to change it to do a search on objectclass=ipaDomainLevelConfig I see - we all need to unify the location apparently. I updated the design page to use cn=Domain Level,cn=ipa,cn=etc,SUFFIX. Tomas, please send the updated patch set, it should be an extremely simple change :-) I prefer the ipa parent and the space in the name, so I'm glad we could agree on this without much bikeshedding. Updated patch attaced. Tomas I still see +# Create default Domain Level entry if it does not exist +dn: cn=DomainLevel,cn=ipa,cn=etc,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaDomainLevelConfig +default: ipaDomainLevel: 0 ... Right, the space eluded me there, thanks for the catch. Tomas A new iteration of the patch, including the server-side checks for the installers. Tomas From f5bfc5256aecd78001904d77a3741d30c51c6207 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Thu, 14 May 2015 10:49:55 +0200 Subject: [PATCH] Add Domain Level feature https://fedorahosted.org/freeipa/ticket/5018 --- ACI.txt| 2 + API.txt| 22 ++ install/share/72domainlevels.ldif | 6 ++ install/share/Makefile.am | 1 + install/tools/ipa-replica-install | 39 +- install/tools/ipa-server-install | 14 +++- install/updates/72-domainlevels.update | 14 install/updates/Makefile.am| 1 + ipalib/constants.py| 3 + ipalib/errors.py | 16 ipalib/plugins/domainlevel.py | 137 + ipaserver/install/dsinstance.py| 14 ipaserver/install/ldapupdate.py| 5 ++ 13 files changed, 269 insertions(+), 5 deletions(-) create mode 100644 install/share/72domainlevels.ldif create mode 100644 install/updates/72-domainlevels.update create mode 100644 ipalib/plugins/domainlevel.py diff --git a/ACI.txt b/ACI.txt index bf539892910f14ebc3fbee88a72d2b57c0d1327b..d38d1c6f5e7f3095704e2c205a52316b4f39f469 100644 --- a/ACI.txt +++ b/ACI.txt @@ -50,6 +50,8 @@ dn: dc=ipa,dc=example aci: (target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Remove DNS Entries;allow (delete) groupdn = ldap:///cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: dc=ipa,dc=example aci: (targetattr = a6record || record || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord)(target = ldap:///idnsname=*,cn=dns,dc=ipa,dc=example;)(version 3.0;acl permission:System: Update DNS Entries;allow (write) groupdn = ldap:///cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=ipa,dc=example;) +dn: dc=ipa,dc=example +aci: (targetattr = createtimestamp || entryusn || ipadomainlevel || modifytimestamp || objectclass)(targetfilter = (objectclass=ipadomainlevelconfig))(version 3.0;acl permission:System: Read Domain Level;allow
