Re: [Freeipa-devel] [PATCH] Schema caching for thin client
On 06/15/2016 08:15 PM, Petr Vobornik wrote: On 06/15/2016 02:36 PM, David Kupka wrote: Hello! Schema caching for thin client is available here: https://github.com/dkupka/freeipa/commits/schema_cache Comments and reviews welcome. Enjoy! Not doing proper review. I'll test by using it. But: 1. lint fails Pylint is running, please wait ... * Module ipaclient.remote_plugins.schema_cache ipaclient/remote_plugins/schema_cache.py:283: [W1612(unicode-builtin), _refresh_schema] unicode built-in referenced) Makefile:137: recipe for target 'lint' failed make: *** [lint] Error 1 I.e, you miss: import six if six.PY3: unicode = str Thanks for the catch, fixed version force-pushed. -- David Kupka -- 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 0413-0416] Support fake_mname option in per-server configuration in LDAP
On 13.6.2016 09:56, Petr Spacek wrote: > On 11.6.2016 20:36, Petr Spacek wrote: >> Hello, >> >> Support fake_mname option in per-server configuration in LDAP. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/162 >> >> >> Patch set contains necessary infrastructure changes so the configuration is >> read before zone loading starts. > > This version fixes crash which could be triggered by failure in second > syncrepl session. > > (I.e. config sync succeeded but data sync failed.) This version fixes another crash triggered by empty set of zones in LDAP. I've force-pushed this version to branch https://github.com/pspacek/bind-dyndb-ldap/tree/server_config_in_ldap4 . -- 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
Re: [Freeipa-devel] [PATCH 0413-0416] Support fake_mname option in per-server configuration in LDAP
On 16.6.2016 09:19, Petr Spacek wrote: > On 13.6.2016 09:56, Petr Spacek wrote: >> On 11.6.2016 20:36, Petr Spacek wrote: >>> Hello, >>> >>> Support fake_mname option in per-server configuration in LDAP. >>> >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/162 >>> >>> >>> Patch set contains necessary infrastructure changes so the configuration is >>> read before zone loading starts. >> >> This version fixes crash which could be triggered by failure in second >> syncrepl session. >> >> (I.e. config sync succeeded but data sync failed.) > > This version fixes another crash triggered by empty set of zones in LDAP. > > I've force-pushed this version to branch > https://github.com/pspacek/bind-dyndb-ldap/tree/server_config_in_ldap4 . And here are the patches :-D -- Petr^2 Spacek From d1c67a763f1d84599cfae8b222fd90e575bd1d87 Mon Sep 17 00:00:00 2001 From: Petr Spacek Date: Fri, 10 Jun 2016 12:57:48 +0200 Subject: [PATCH] Do not log "connection to the LDAP server was lost" on forced reconnects. This is a cosmetic change which will be used in code which opens and closes multiple SyncRepl connections. https://fedorahosted.org/bind-dyndb-ldap/ticket/162 --- src/ldap_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ldap_helper.c b/src/ldap_helper.c index af7f5c40500c7843dbf5e4533b83982b52088ced..b922371ae2392ca8bd1069df738d69617bb81905 100644 --- a/src/ldap_helper.c +++ b/src/ldap_helper.c @@ -2726,7 +2726,7 @@ handle_connection_error(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn /* Try to reconnect on other errors. */ log_ldap_error(ldap_conn->handle, "connection error"); reconnect: - if (ldap_conn->handle == NULL) + if (ldap_conn->handle == NULL && force == ISC_FALSE) log_error("connection to the LDAP server was lost"); result = ldap_connect(ldap_inst, ldap_conn, force); if (result == ISC_R_SUCCESS) -- 2.5.5 From 78acc6cff0b506e8a1baf348ac8eca5ffc79a7d9 Mon Sep 17 00:00:00 2001 From: Petr Spacek Date: Fri, 10 Jun 2016 13:59:26 +0200 Subject: [PATCH] Refactor LDAP SyncRepl connection handling to make it reusable. Now it is easy to sequentially run more SyncRepl sessions with different parameters. It will be handy for per-server config. https://fedorahosted.org/bind-dyndb-ldap/ticket/126 --- src/ldap_helper.c | 190 ++ 1 file changed, 121 insertions(+), 69 deletions(-) diff --git a/src/ldap_helper.c b/src/ldap_helper.c index b922371ae2392ca8bd1069df738d69617bb81905..ef810de74094da0d3cbb6db1c52151f5c38f 100644 --- a/src/ldap_helper.c +++ b/src/ldap_helper.c @@ -4274,44 +4274,29 @@ ldap_sync_cleanup(ldap_sync_t **ldap_syncp) { *ldap_syncp = NULL; } - +/** + * Initialize ldap_sync_t structure. Is has to be freed by ldap_sync_cleanup(). + * In case of failure, the conn parameter may be invalid and LDAP connection + * needs to be re-established. + * + * @param[in] filter LDAP filter to be used in SyncRepl session + */ static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT ldap_sync_prepare(ldap_instance_t *inst, settings_set_t *settings, - ldap_connection_t *conn, ldap_sync_t **ldap_syncp) { + const char *filter, ldap_connection_t *conn, + ldap_sync_t **ldap_syncp) { isc_result_t result; const char *base = NULL; - isc_uint32_t reconnect_interval; ldap_sync_t *ldap_sync = NULL; - const char *server_id = NULL; - char filter[1024]; - const char filter_template[] = - "(|(objectClass=idnsConfigObject)" - " (objectClass=idnsZone)" - " (objectClass=idnsForwardZone)" - " (objectClass=idnsRecord)" - " %s%s%s" - ")"; REQUIRE(inst != NULL); REQUIRE(ldap_syncp != NULL && *ldap_syncp == NULL); /* Remove stale zone & journal files. */ CHECK(cleanup_files(inst)); - /* Try to connect. */ - while (conn->handle == NULL) { - result = ISC_R_SHUTTINGDOWN; - CHECK_EXIT; - CHECK(setting_get_uint("reconnect_interval", settings, - &reconnect_interval)); - - log_error("ldap_syncrepl will reconnect in %d second%s", - reconnect_interval, - reconnect_interval == 1 ? "": "s"); - if (!sane_sleep(inst, reconnect_interval)) - CLEANUP_WITH(ISC_R_SHUTTINGDOWN); - handle_connection_error(inst, conn, ISC_TRUE); - } + if(conn->handle == NULL) + CLEANUP_WITH(ISC_R_NOTCONNECTED); ldap_sync = ldap_sync_initialize(NULL); if (ldap_sync == NULL) { @@ -4325,20 +4310,10 @@ ldap_sync_prepare(ldap_instance_t *inst, settings_set_t *settings, if (ldap_sync->ls_base == NULL) CLEANUP_WITH(ISC_R_NOMEMORY); ldap_sync->ls_scope = LDAP_SCOPE_SUBTREE; - - /* request idnsServerConfig object only if server_id is specified */ - CHECK(setting_get_str("server_id", settings, &server_id)); - if (strlen(server_id) == 0) - CHECK(isc_string_printf(filter, sizeof(filter), filter_template, -"", "", "")); - else - CHECK(isc_string_printf(filter, sizeof(filter), filter_template, -" (&(objectClass=idnsServerConfigObject)" -"(idnsSe
[Freeipa-devel] [PATCH 0047] Fix uninitialized variables in replicainstall
Hello, There was a possible use of uninitialized variables in replicainstall. From 1b26d42e00506b007e087c74cafc0327090aec40 Mon Sep 17 00:00:00 2001 From: Stanislav Laznicka Date: Thu, 16 Jun 2016 10:05:34 +0200 Subject: [PATCH] Fix unitialized variables in replicainstall ipaconf and target_fname variables would have been used uninitialized in finally block should an exception occur in the try block before their initialization. --- ipaserver/install/server/replicainstall.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py index f597880471eb3710ebc7163f771d4e6dc9f1e3d6..8864944d814239eec82c8c5d862f0f9ca04b23d2 100644 --- a/ipaserver/install/server/replicainstall.py +++ b/ipaserver/install/server/replicainstall.py @@ -1304,10 +1304,12 @@ def promote(installer): http_pkcs12_info = installer._http_pkcs12_info pkinit_pkcs12_file = installer._pkinit_pkcs12_file pkinit_pkcs12_info = installer._pkinit_pkcs12_info +target_fname = paths.IPA_DEFAULT_CONF ccache = os.environ['KRB5CCNAME'] remote_api = installer._remote_api conn = remote_api.Backend.ldap2 +ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Replica Promote") try: conn.connect(ccache=installer._ccache) @@ -1318,9 +1320,7 @@ def promote(installer): ) # Save client file and merge in server directives -target_fname = paths.IPA_DEFAULT_CONF fstore.backup_file(target_fname) -ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Replica Promote") ipaconf.setOptionAssignment(" = ") ipaconf.setSectionNameDelimiters(("[", "]")) -- 2.5.5 -- 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-0046] Increased certmonger timeout to address ticket N 5758
With this change the certmonger timeout issue is no longer observed in abcd lab. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From 2063d59f3d8303abf056d38a68ac75f9f2d9cd24 Mon Sep 17 00:00:00 2001 From: Oleg Fayans Date: Thu, 16 Jun 2016 10:25:59 +0200 Subject: [PATCH] Increased certmonger timeout https://fedorahosted.org/freeipa/ticket/5758 --- ipaserver/install/certs.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index 76f62751db8abbb27ca5849bcb09c5b5540e2cda..b3d273ff107f0493516845745c4f14242fc518ca 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -654,7 +654,7 @@ class CertDB(object): subject=host, passwd_fname=self.passwd_fname) # Now wait for the cert to appear. Check three times then abort -certmonger.wait_for_request(reqid, timeout=15) +certmonger.wait_for_request(reqid, timeout=60) class _CrossProcessLock(object): -- 1.8.3.1 -- 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] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 06/16/2016 06:55 AM, Petr Spacek wrote: Hello, TL;DR version: Upgrade to 389-ds-base-1.3.5.6-1.fc24. I was facing weird filter/ACI evaluation with 389 DS 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I realized that DS is old one ...): Test First, let's try LDAP search with OR filter consisting of 5 components: [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 It returns 1 entry - the idnsServerConfigObject object. Hi Petr, In fact it is difficult to justify and identify which fix fixes this issue (I suspect https://fedorahosted.org/389/ticket/48275 but not clear why it participates). in 1.3.5.6-1, it returns 11 entries. How many of them are idnsServerConfigObject ? thanks theirry Now let us re-try shortened filter containing only 4 OR components. I would expect to get less entries but that is not the case: [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 nentries=11 etime=0 Huh? Now we got 11 entries. When I do the first search as Directory Manager it returns all 12 matching entries (which is expected number, at least according to my match-by-eye algorithm :-)). Schema == idnsServerId attribute definition contains an equality specification: ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) Indices === The attribute itself is not indexed but that should not hurt I guess. Mere addition of equality index to the attribute did not help. Reindexing using https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks did not help either. ACI === Relevant ACIs are: (targetattr = "createtimestamp || entryusn || idnsforwarders || idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable || modifytimestamp || objectclass")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Read DNS Servers Configuration";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || idnssubstitutionvariable")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System: Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) BIND DN krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel is member of cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel which is member of cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel so we should be all good. Now was totally confused and was looking for a bug in bind-dyndb-ldap until I realized that DS is returning weird results... Upgrade to 389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that.
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 16.6.2016 10:47, thierry bordaz wrote: > On 06/16/2016 06:55 AM, Petr Spacek wrote: >> Hello, >> >> TL;DR version: >> Upgrade to 389-ds-base-1.3.5.6-1.fc24. >> >> I was facing weird filter/ACI evaluation with 389 DS >> 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I >> realized that DS is old one ...): >> >> >> Test >> >> First, let's try LDAP search with OR filter consisting of 5 components: >> >> [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 >> nentries=0 etime=0 >> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" >> >> [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH >> base="cn=dns,dc=toplevel" scope=2 >> filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" >> >> attrs="objectClass" >> [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND >> [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 >> >> It returns 1 entry - the idnsServerConfigObject object. > Hi Petr, > > In fact it is difficult to justify and identify which fix fixes this issue (I > suspect https://fedorahosted.org/389/ticket/48275 but not clear why it > participates). > > in 1.3.5.6-1, it returns 11 entries. How many of them are > idnsServerConfigObject ? thanks theirry Exactly one. Petr^2 Spacek >> Now let us re-try shortened filter containing only 4 OR components. I would >> expect to get less entries but that is not the case: >> >> [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL >> connection >> from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 >> [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES >> [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 >> nentries=0 etime=0, SASL bind in progress >> [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl >> version=3 mech=GSSAPI >> [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 >> nentries=0 etime=0 >> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" >> >> [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH >> base="cn=dns,dc=toplevel" scope=2 >> filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" >> >> attrs="objectClass" >> [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 >> nentries=11 etime=0 >> >> Huh? Now we got 11 entries. >> >> >> When I do the first search as Directory Manager it returns all 12 matching >> entries (which is expected number, at least according to my match-by-eye >> algorithm :-)). >> >> >> Schema >> == >> idnsServerId attribute definition contains an equality specification: >> ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier' >> EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE >> X-ORIGIN 'IPA v4.4' ) >> >> >> Indices >> === >> The attribute itself is not indexed but that should not hurt I guess. >> >> Mere addition of equality index to the attribute did not help. >> >> Reindexing using >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks >> >> did not help either. >> >> >> >> ACI >> === >> Relevant ACIs are: >> (targetattr = "createtimestamp || entryusn || idnsforwarders || >> idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable >> || modifytimestamp || objectclass")(targetfilter = >> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: >> Read DNS Servers Configuration";allow (compare,read,search) groupdn = >> "ldap:///cn=System: Read DNS Servers >> Configuration,cn=permissions,cn=pbac,dc=toplevel";) >> >> (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || >> idnssubstitutionvariable")(targetfilter = >> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: >> Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System: >> Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) >> >> >> BIND DN >> krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=topl
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 06/16/2016 06:55 AM, Petr Spacek wrote: Hello, TL;DR version: Upgrade to 389-ds-base-1.3.5.6-1.fc24. I was facing weird filter/ACI evaluation with 389 DS 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I realized that DS is old one ...): Test First, let's try LDAP search with OR filter consisting of 5 components: [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" you don't have 5 OR components, you have only 2, the second one is an AND with 4 components, attrs="objectClass" [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 It returns 1 entry - the idnsServerConfigObject object. Now let us re-try shortened filter containing only 4 OR components. I would expect to get less entries but that is not the case: [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 nentries=11 etime=0 Huh? Now we got 11 entries. When I do the first search as Directory Manager it returns all 12 matching entries (which is expected number, at least according to my match-by-eye algorithm :-)). Schema == idnsServerId attribute definition contains an equality specification: ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) Indices === The attribute itself is not indexed but that should not hurt I guess. Mere addition of equality index to the attribute did not help. Reindexing using https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks did not help either. ACI === Relevant ACIs are: (targetattr = "createtimestamp || entryusn || idnsforwarders || idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable || modifytimestamp || objectclass")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Read DNS Servers Configuration";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || idnssubstitutionvariable")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System: Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) BIND DN krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel is member of cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel which is member of cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel so we should be all good. Now was totally confused and was looking for a bug in bind-dyndb-ldap until I realized that DS is returning weird results... Upgrade to 389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that. This would be a blocker for FreeIPA 4.4 because the old version totally breaks bind-dyndb-ldap. -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial regi
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 06/16/2016 10:50 AM, Petr Spacek wrote: On 16.6.2016 10:47, thierry bordaz wrote: On 06/16/2016 06:55 AM, Petr Spacek wrote: Hello, TL;DR version: Upgrade to 389-ds-base-1.3.5.6-1.fc24. I was facing weird filter/ACI evaluation with 389 DS 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I realized that DS is old one ...): Test First, let's try LDAP search with OR filter consisting of 5 components: [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 It returns 1 entry - the idnsServerConfigObject object. Hi Petr, In fact it is difficult to justify and identify which fix fixes this issue (I suspect https://fedorahosted.org/389/ticket/48275 but not clear why it participates). in 1.3.5.6-1, it returns 11 entries. How many of them are idnsServerConfigObject ? thanks theirry Exactly one. So "permission:System:Read DNS Servers Configuration" should grant read/search rights only for this one. There should be others ACI that grant you the access to the 10 others. You may turn on ACI logging ("nsslapd-errorlog-level: 262272") to identify which ACIs granted you this read/search access. thanks thierry Petr^2 Spacek Now let us re-try shortened filter containing only 4 OR components. I would expect to get less entries but that is not the case: [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 nentries=11 etime=0 Huh? Now we got 11 entries. When I do the first search as Directory Manager it returns all 12 matching entries (which is expected number, at least according to my match-by-eye algorithm :-)). Schema == idnsServerId attribute definition contains an equality specification: ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) Indices === The attribute itself is not indexed but that should not hurt I guess. Mere addition of equality index to the attribute did not help. Reindexing using https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks did not help either. ACI === Relevant ACIs are: (targetattr = "createtimestamp || entryusn || idnsforwarders || idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable || modifytimestamp || objectclass")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Read DNS Servers Configuration";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || idnssubstitutionvariable")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System: Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) BIND DN krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 06/16/2016 06:55 AM, Petr Spacek wrote: Hello, TL;DR version: Upgrade to 389-ds-base-1.3.5.6-1.fc24. I was facing weird filter/ACI evaluation with 389 DS 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I realized that DS is old one ...): Test First, let's try LDAP search with OR filter consisting of 5 components: [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 It returns 1 entry - the idnsServerConfigObject object. Now let us re-try shortened filter containing only 4 OR components. I would expect to get less entries but that is not the case: [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 nentries=11 etime=0 Huh? Now we got 11 entries. When I do the first search as Directory Manager it returns all 12 matching entries (which is expected number, at least according to my match-by-eye algorithm :-)). Schema == idnsServerId attribute definition contains an equality specification: ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) Indices === The attribute itself is not indexed but that should not hurt I guess. Mere addition of equality index to the attribute did not help. Reindexing using https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks did not help either. ACI === Relevant ACIs are: (targetattr = "createtimestamp || entryusn || idnsforwarders || idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable || modifytimestamp || objectclass")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Read DNS Servers Configuration";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || idnssubstitutionvariable")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System: Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) BIND DN krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel is member of cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel which is member of cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel so we should be all good. Now was totally confused and was looking for a bug in bind-dyndb-ldap until I realized that DS is returning weird results... Upgrade to 389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that. I'm still not sure that I get your 5 and 4 OR filter searches, as in the example you provided there was also an AND involved, but there is a fix in 1.3.5.6. which makes a difference: 48275 Before we requested that in an OR filter the user has to have access to ALL attributes m
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 06/16/2016 11:23 AM, Ludwig Krispenz wrote: On 06/16/2016 06:55 AM, Petr Spacek wrote: Hello, TL;DR version: Upgrade to 389-ds-base-1.3.5.6-1.fc24. I was facing weird filter/ACI evaluation with 389 DS 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I realized that DS is old one ...): Test First, let's try LDAP search with OR filter consisting of 5 components: [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 It returns 1 entry - the idnsServerConfigObject object. Now let us re-try shortened filter containing only 4 OR components. I would expect to get less entries but that is not the case: [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 nentries=11 etime=0 Huh? Now we got 11 entries. When I do the first search as Directory Manager it returns all 12 matching entries (which is expected number, at least according to my match-by-eye algorithm :-)). Schema == idnsServerId attribute definition contains an equality specification: ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) Indices === The attribute itself is not indexed but that should not hurt I guess. Mere addition of equality index to the attribute did not help. Reindexing using https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks did not help either. ACI === Relevant ACIs are: (targetattr = "createtimestamp || entryusn || idnsforwarders || idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable || modifytimestamp || objectclass")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Read DNS Servers Configuration";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || idnssubstitutionvariable")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System: Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) BIND DN krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel is member of cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel which is member of cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel so we should be all good. Now was totally confused and was looking for a bug in bind-dyndb-ldap until I realized that DS is returning weird results... Upgrade to 389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that. I'm still not sure that I get your 5 and 4 OR filter searches, as in the example you provided there was also an AND involved, but there is a fix in 1.3.5.6. which makes a differe
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 16.6.2016 11:34, Ludwig Krispenz wrote: > > On 06/16/2016 11:23 AM, Ludwig Krispenz wrote: >> >> On 06/16/2016 06:55 AM, Petr Spacek wrote: >>> Hello, >>> >>> TL;DR version: >>> Upgrade to 389-ds-base-1.3.5.6-1.fc24. >>> >>> I was facing weird filter/ACI evaluation with 389 DS >>> 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I >>> realized that DS is old one ...): >>> >>> >>> Test >>> >>> First, let's try LDAP search with OR filter consisting of 5 components: >>> >>> [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 >>> nentries=0 etime=0 >>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" >>> >>> [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH >>> base="cn=dns,dc=toplevel" scope=2 >>> filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" >>> >>> attrs="objectClass" >>> [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND >>> [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 >>> >>> It returns 1 entry - the idnsServerConfigObject object. >>> >>> >>> >>> Now let us re-try shortened filter containing only 4 OR components. I would >>> expect to get less entries but that is not the case: >>> >>> [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL >>> connection >>> from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 >>> [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES >>> [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 >>> nentries=0 etime=0, SASL bind in progress >>> [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl >>> version=3 mech=GSSAPI >>> [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 >>> nentries=0 etime=0 >>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" >>> >>> [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH >>> base="cn=dns,dc=toplevel" scope=2 >>> filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" >>> >>> attrs="objectClass" >>> [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 >>> nentries=11 etime=0 >>> >>> Huh? Now we got 11 entries. >>> >>> >>> When I do the first search as Directory Manager it returns all 12 matching >>> entries (which is expected number, at least according to my match-by-eye >>> algorithm :-)). >>> >>> >>> Schema >>> == >>> idnsServerId attribute definition contains an equality specification: >>> ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server >>> identifier' >>> EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE >>> X-ORIGIN 'IPA v4.4' ) >>> >>> >>> Indices >>> === >>> The attribute itself is not indexed but that should not hurt I guess. >>> >>> Mere addition of equality index to the attribute did not help. >>> >>> Reindexing using >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks >>> >>> did not help either. >>> >>> >>> >>> ACI >>> === >>> Relevant ACIs are: >>> (targetattr = "createtimestamp || entryusn || idnsforwarders || >>> idnsforwardpolicy || idnsserverid || idnssoamname || >>> idnssubstitutionvariable >>> || modifytimestamp || objectclass")(targetfilter = >>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: >>> Read DNS Servers Configuration";allow (compare,read,search) groupdn = >>> "ldap:///cn=System: Read DNS Servers >>> Configuration,cn=permissions,cn=pbac,dc=toplevel";) >>> >>> (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || >>> idnssubstitutionvariable")(targetfilter = >>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: >>> Modify DNS Servers Configuration";allow (write) groupdn = >>> "ldap:///cn=System: >>> Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) >>> >>> >>> BIND DN >>> krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel >>> >>> is member of >>> cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel >>> which is member of >>> cn=System: Read DNS Se
[Freeipa-devel] [PATCH 0133] Require 389-ds-base >= 1.3.5.6
Hello, Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 -- Petr^2 Spacek From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001 From: Petr Spacek Date: Thu, 16 Jun 2016 11:58:56 +0200 Subject: [PATCH] Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 --- freeipa.spec.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %if ! %{ONLY_CLIENT} -BuildRequires: 389-ds-base-devel >= 1.3.5 +BuildRequires: 389-ds-base-devel >= 1.3.5.6 BuildRequires: svrcore-devel BuildRequires: policycoreutils >= 2.1.12-5 BuildRequires: systemd-units @@ -131,7 +131,7 @@ Requires: %{name}-client = %{version}-%{release} Requires: %{name}-admintools = %{version}-%{release} Requires: %{name}-common = %{version}-%{release} Requires: python2-ipaserver = %{version}-%{release} -Requires: 389-ds-base >= 1.3.5 +Requires: 389-ds-base >= 1.3.5.6 Requires: openldap-clients > 2.4.35-4 Requires: nss >= 3.14.3-12.0 Requires: nss-tools >= 3.14.3-12.0 @@ -163,7 +163,7 @@ Requires: zip Requires: policycoreutils >= 2.1.12-5 Requires: tar Requires(pre): certmonger >= 0.78 -Requires(pre): 389-ds-base >= 1.3.5 +Requires(pre): 389-ds-base >= 1.3.5.6 Requires: fontawesome-fonts Requires: open-sans-fonts Requires: openssl -- 2.5.5 -- 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] 0056 webui: Counterpart of dnsserver-{find, show, mod}
Hello, please review attached patch. https://fedorahosted.org/freeipa/ticket/5905 -- Pavel^3 Vomacka From 16270e37ce76796e76513270f5833241d4f5c892 Mon Sep 17 00:00:00 2001 From: Pavel Vomacka Date: Thu, 16 Jun 2016 10:09:36 +0200 Subject: [PATCH] DNS Servers: Web UI part Adds new page with DNS Servers and details page about each server. There is also new adder dialog for adding new DNS Server. In summary it is counterpart of dnsserver-{find,show,mod} CLI commands. Part of: https://fedorahosted.org/freeipa/ticket/5905 --- install/ui/src/freeipa/dns.js | 54 ++ install/ui/src/freeipa/navigation/menu_spec.js | 1 + 2 files changed, 55 insertions(+) diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js index 8573e653770867210bb31066021e5b78809b1573..a441b56026aa1510d5c7357c156a12e2eb46325b 100644 --- a/install/ui/src/freeipa/dns.js +++ b/install/ui/src/freeipa/dns.js @@ -492,6 +492,58 @@ return { };}; +var make_dnsserver_spec = function() { +var spec = { +name: 'dnsserver', +enable_test: function() { +return IPA.dns_enabled; +}, +facets: [ +{ +$type: 'search', +no_update: true, +columns: [ +'idnsserverid' +] +}, +{ +$type: 'details', +disable_facet_tabs: true, +fields: [ +'idnssoamname', +'idnsserverid', +{ +$type: 'multivalued', +name: 'idnsforwarders', +validators: ['dnsforwarder'] +}, +{ +$type: 'radio', +name: 'idnsforwardpolicy', +options: [ +{ +value: 'first', +label: '@i18n:objects.dnsconfig.forward_first' +}, +{ +value: 'only', +label: '@i18n:objects.dnsconfig.forward_only' +}, +{ +value: 'none', +label: '@i18n:objects.dnsconfig.forward_none' +} +] +} +] +} +] +}; + +return spec; +}; + + IPA.dnszone_details_facet = function(spec, no_init) { spec = spec || {}; @@ -2521,6 +2573,7 @@ exp.config_spec = make_config_spec(); exp.zone_spec = make_zone_spec(); exp.record_spec = make_record_spec(); exp.forwardzone_spec = make_forwardzone_spec(); +exp.dnsserver_spec = make_dnsserver_spec(); exp.register = function() { var e = reg.entity; var w = reg.widget; @@ -2532,6 +2585,7 @@ exp.register = function() { e.register({type: 'dnszone', spec: exp.zone_spec}); e.register({type: 'dnsrecord', spec: exp.record_spec}); e.register({type: 'dnsforwardzone', spec: exp.forwardzone_spec}); +e.register({type: 'dnsserver', spec: exp.dnsserver_spec}); w.register('dnszone_name', IPA.dnszone_name_widget); w.register('force_dnszone_add_checkbox', IPA.force_dnszone_add_checkbox_widget); diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js index 2e47761ce3f17289d0a0a914896ee31209ace290..108f4577f7e1326b9c9bc495c54f6e1f12a0cce6 100644 --- a/install/ui/src/freeipa/navigation/menu_spec.js +++ b/install/ui/src/freeipa/navigation/menu_spec.js @@ -179,6 +179,7 @@ var nav = {}; ] }, { entity: 'dnsforwardzone' }, +{ entity: 'dnsserver' }, { entity: 'dnsconfig' } ] } -- 2.5.5 -- 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] 0056 webui: Counterpart of dnsserver-{find, show, mod}
On 06/16/2016 12:06 PM, Pavel Vomacka wrote: Hello, please review attached patch. https://fedorahosted.org/freeipa/ticket/5905 Fixed commit message -- Pavel^3 Vomacka From c61e0dd9190be2537ecd8da0a4fa5c0ace81a81e Mon Sep 17 00:00:00 2001 From: Pavel Vomacka Date: Thu, 16 Jun 2016 10:09:36 +0200 Subject: [PATCH] DNS Servers: Web UI part Adds new page with DNS Servers and details page about each server. It is counterpart of dnsserver-{find,show,mod} CLI commands. Part of: https://fedorahosted.org/freeipa/ticket/5905 --- install/ui/src/freeipa/dns.js | 54 ++ install/ui/src/freeipa/navigation/menu_spec.js | 1 + 2 files changed, 55 insertions(+) diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js index 8573e653770867210bb31066021e5b78809b1573..a441b56026aa1510d5c7357c156a12e2eb46325b 100644 --- a/install/ui/src/freeipa/dns.js +++ b/install/ui/src/freeipa/dns.js @@ -492,6 +492,58 @@ return { };}; +var make_dnsserver_spec = function() { +var spec = { +name: 'dnsserver', +enable_test: function() { +return IPA.dns_enabled; +}, +facets: [ +{ +$type: 'search', +no_update: true, +columns: [ +'idnsserverid' +] +}, +{ +$type: 'details', +disable_facet_tabs: true, +fields: [ +'idnssoamname', +'idnsserverid', +{ +$type: 'multivalued', +name: 'idnsforwarders', +validators: ['dnsforwarder'] +}, +{ +$type: 'radio', +name: 'idnsforwardpolicy', +options: [ +{ +value: 'first', +label: '@i18n:objects.dnsconfig.forward_first' +}, +{ +value: 'only', +label: '@i18n:objects.dnsconfig.forward_only' +}, +{ +value: 'none', +label: '@i18n:objects.dnsconfig.forward_none' +} +] +} +] +} +] +}; + +return spec; +}; + + IPA.dnszone_details_facet = function(spec, no_init) { spec = spec || {}; @@ -2521,6 +2573,7 @@ exp.config_spec = make_config_spec(); exp.zone_spec = make_zone_spec(); exp.record_spec = make_record_spec(); exp.forwardzone_spec = make_forwardzone_spec(); +exp.dnsserver_spec = make_dnsserver_spec(); exp.register = function() { var e = reg.entity; var w = reg.widget; @@ -2532,6 +2585,7 @@ exp.register = function() { e.register({type: 'dnszone', spec: exp.zone_spec}); e.register({type: 'dnsrecord', spec: exp.record_spec}); e.register({type: 'dnsforwardzone', spec: exp.forwardzone_spec}); +e.register({type: 'dnsserver', spec: exp.dnsserver_spec}); w.register('dnszone_name', IPA.dnszone_name_widget); w.register('force_dnszone_add_checkbox', IPA.force_dnszone_add_checkbox_widget); diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js index 2e47761ce3f17289d0a0a914896ee31209ace290..108f4577f7e1326b9c9bc495c54f6e1f12a0cce6 100644 --- a/install/ui/src/freeipa/navigation/menu_spec.js +++ b/install/ui/src/freeipa/navigation/menu_spec.js @@ -179,6 +179,7 @@ var nav = {}; ] }, { entity: 'dnsforwardzone' }, +{ entity: 'dnsserver' }, { entity: 'dnsconfig' } ] } -- 2.5.5 -- 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 0503-0513, 0515-0519] DNS locations
On 15.6.2016 17:24, Petr Spacek wrote: > On 15.6.2016 15:45, Martin Basti wrote: >> >> >> On 15.06.2016 14:52, Martin Basti wrote: >>> >>> Hydra patching: Updated patches attached + new patches for dnsserver-* >>> commands attached >>> Updated+rebased patches after Honza's interactive review >>> >>> >> Minor nitpick fixed >> >> >> > freeipa-mbasti-0503.3-DNS-Locations-add-index-for-ipalocation-attribute.patch > ACK > > freeipa-mbasti-0505.3-DNS-Locations-add-idnsTemplateObject-objectclass.patch > ACK > > > I will get to the rest later on. Problems I found (could be solved in separate patches if you wish): 1. NACK # ipa dns-update-system-records --dry-run ipa: ERROR: an internal error has occurred ValueError: dns_update_system_records.validate_output(): unexpected keys ['summary'] in { ... 2. NACK Command ipa dns-update-system-records does not work with DNS Administrators privilege when some record is missing: ipa: WARNING: Update of system record '_kpasswd._tcp.dom-046.abc.idm.lab.eng.brq.redhat.com. 86400 IN SRV 0 100 464 vm-046.abc.idm.lab.eng.brq.redhat.com.' failed with error: Insufficient access: Insufficient 'write' privilege to the 'objectClass' attribute of entry 'idnsname=_kpasswd._tcp,idnsname=dom-046.abc.idm.lab.eng.brq.redhat.com.,cn=dns,dc=suffix'. 3. NACK IPA server upgrade does not create idnsServerConfigObjects in cn=dns In fact the upgrade does not even add the object class into schema. These needs to be fixed before we can proceed. -- 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
Re: [Freeipa-devel] [PATCH 0133] Require 389-ds-base >= 1.3.5.6
On 06/16/2016 12:00 PM, Petr Spacek wrote: Hello, Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly no. Old DS handles filters strictly as documented in the admin guide, requiring access rights to each attribute used in the search filter. This was known and applications had to adapt, in your case there would have had to be two searches one with the (&()()) filter and one with (|()()()()). This was improved in the latest version and componets withou access are ignored in filter evaluation to avoid the problems you did run into. otherwise your fix is ok Ludwig and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -- 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 0133] Require 389-ds-base >= 1.3.5.6
On 16.6.2016 12:12, Ludwig Krispenz wrote: > > On 06/16/2016 12:00 PM, Petr Spacek wrote: >> Hello, >> >> Require 389-ds-base >= 1.3.5.6 >> >> Old DS handles LDAP filters incorrectly > no. Old DS handles filters strictly as documented in the admin guide, > requiring access rights to each attribute used in the search filter. This was > known and applications had to adapt, in your case there would have had to be > two searches one with the (&()()) filter and one with (|()()()()). You know, it is quite hard to adapt when your application rely on one SyncRepl session ... Anyway, feel free to send patch with rephrased commit message if you wish, I'm okay with superseding my patch with yours. Petr^2 Spacek > This was improved in the latest version and componets withou access are > ignored in filter evaluation to avoid the problems you did run into. > > otherwise your fix is ok > > Ludwig >> and breaks bind-dyndb-ldap. >> See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html >> >> https://fedorahosted.org/freeipa/ticket/2008 -- 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 0133] Require 389-ds-base >= 1.3.5.6
On 06/16/2016 12:14 PM, Petr Spacek wrote: On 16.6.2016 12:12, Ludwig Krispenz wrote: On 06/16/2016 12:00 PM, Petr Spacek wrote: Hello, Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly no. Old DS handles filters strictly as documented in the admin guide, requiring access rights to each attribute used in the search filter. This was known and applications had to adapt, in your case there would have had to be two searches one with the (&()()) filter and one with (|()()()()). You know, it is quite hard to adapt when your application rely on one SyncRepl session ... Anyway, feel free to send patch with rephrased commit message if you wish, I'm okay with superseding my patch with yours. Note that https://fedorahosted.org/freeipa/ticket/5944 (patch 0019 still under review) has the same requirement on DS >=1.3.5.5. So the requirement >=1.3.5.6 makes me happy. thanks thierry Petr^2 Spacek This was improved in the latest version and componets withou access are ignored in filter evaluation to avoid the problems you did run into. otherwise your fix is ok Ludwig and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 -- 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 0133] Require 389-ds-base >= 1.3.5.6
On 06/16/2016 12:14 PM, Petr Spacek wrote: On 16.6.2016 12:12, Ludwig Krispenz wrote: On 06/16/2016 12:00 PM, Petr Spacek wrote: Hello, Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly no. Old DS handles filters strictly as documented in the admin guide, requiring access rights to each attribute used in the search filter. This was known and applications had to adapt, in your case there would have had to be two searches one with the (&()()) filter and one with (|()()()()). You know, it is quite hard to adapt when your application rely on one SyncRepl session ... Anyway, feel free to send patch with rephrased commit message if you wish, I'm okay with superseding my patch with yours. no, it's fine, only sometimes I need to defend DS a bit Petr^2 Spacek This was improved in the latest version and componets withou access are ignored in filter evaluation to avoid the problems you did run into. otherwise your fix is ok Ludwig and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -- 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 0153-0158] move ipa-replica-manage del functionality into server-del
On 15.06.2016 15:29, Martin Babinsky wrote: On 06/15/2016 10:30 AM, Jan Cholasta wrote: Hi, On 12.6.2016 17:31, Martin Babinsky wrote: On 06/09/2016 08:12 PM, Martin Babinsky wrote: These patches expand `server_del` to a full fledged IPA master killer in domain level 1. Due to 'server uninstallation removed master from topology' use case, the individual steps are not in the same order as in the original code to facilitate self-removal from topology without introducing an array of permissions for master to remove itself. I had no opportunity to test out the CI test suite because of technical problems so it would be nice if our upstream QE could give it a spin and report errors. http://www.freeipa.org/page/V4/Manage_replication_topology_4_4 https://fedorahosted.org/freeipa/ticket/5181 Attaching rebased patches and bumping for review. Please note that they depend on 'Server Roles v2' patchset. Patch 0153: Should be an ipaserver module, unless it is required on clients as well, in which case it should be an ipalib module. Patch 0154: LGTM Patch 0155: In LDAPDelete subclasses, the primary key argument is multivalue, so I'm guessing your post_callback won't work correctly. Also, since this is *server*-del, s/master/server/ where applicable. Patch 0156: LGTM Patch 0157: This looks suspicious: +result = server_del_cmd(hostname, version=api_version, **options) Version is automatically filled in in Command.__call__(), why do you add it manually here? Patch 0158: LGTM Honza Attaching updated patches. Hello, I have a few comments: 1) you reused ID numbers for the your messages +class ServerRemovalInfo(PublicMessage): ... +errno = 13020 +class ServerRemovalWarning(PublicMessage): ... +errno = 13021 class FailedToRemoveHostDNSRecords(PublicMessage): ... errno = 13020 class DNSForwardPolicyConflictWithEmptyZone(PublicMessage): ... errno = 13021 2) +def _check_topology_connectivity(self, topology_connectivity, master_cn): +try: +topology_connectivity.check_current_state() +except ValueError as e: +raise errors.ServerRemovalError(reason=_(str(e))) + +try: + topology_connectivity.check_state_after_removal(master_cn) +except ValueError as e: +raise errors.ServerRemovalError(reason=_(str(e))) * _(str(e)): gettext cannot be used by this way * str(e): you dont need to convert exception to string, this is done automatically in exception 3) gettext again +self.add_message( +messages.ServerRemovalWarning( +message=_(msg) +) +) 4) +messages.ServerRemovalWarning( +message=_("Failed to clean memberPrincipal {principal}" + " from s4u2proxy entry {dn}: {err}".format( + principal=member_principal, + dn=dn, + err=e +messages.ServerRemovalWarning( +message=_("Failed to clean up DNA hostname entries for " + "{master}: {err}".format( + master=master, err=e several more times I'm not sure if this will work, for safety I would prefer to change it to dictionary substitution https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668226 It looks like it was fixed in gettext 18.3, some distributions still have the older one I have to test more how gettext works with the new python format strings 5) +def interactive_prompt_callback(self, kw): +self.api.Backend.textui.print_plain( +_("Removing {server} from replication topology, " + "please wait...".format(server=', '.join(kw['cn'] Will this work? IMO this should be on client side -- 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] 0056 webui: Counterpart of dnsserver-{find, show, mod}
On 16.6.2016 12:09, Pavel Vomacka wrote: > > > On 06/16/2016 12:06 PM, Pavel Vomacka wrote: >> Hello, >> >> please review attached patch. >> >> https://fedorahosted.org/freeipa/ticket/5905 >> > Fixed commit message LGTM from user's perspective but I did not review the code. -- 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
Re: [Freeipa-devel] [PATCH 0133] Require 389-ds-base >= 1.3.5.6
On 16.06.2016 12:21, Ludwig Krispenz wrote: On 06/16/2016 12:14 PM, Petr Spacek wrote: On 16.6.2016 12:12, Ludwig Krispenz wrote: On 06/16/2016 12:00 PM, Petr Spacek wrote: Hello, Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly no. Old DS handles filters strictly as documented in the admin guide, requiring access rights to each attribute used in the search filter. This was known and applications had to adapt, in your case there would have had to be two searches one with the (&()()) filter and one with (|()()()()). You know, it is quite hard to adapt when your application rely on one SyncRepl session ... Anyway, feel free to send patch with rephrased commit message if you wish, I'm okay with superseding my patch with yours. no, it's fine, only sometimes I need to defend DS a bit Petr^2 Spacek This was improved in the latest version and componets withou access are ignored in filter evaluation to avoid the problems you did run into. otherwise your fix is ok Ludwig and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 ACK Pushed to master: 85d083c36651b15457af75e009f83bc6bb8114b0 -- 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 0014-0016][Tests] Authentication indicators
Hi, attached are tests for authentication indicators. Please note: 1. newly created service tracker is not exactly complete, list of unimplemented methods is in doc. These methods can be filled in when existing declarative tests are refactored. 2. patch 0015 depends on 0014, so it should not be pushed without it. Lenka From 2dfcc81b979a345dbed2449a5c30ba19fd2025ee Mon Sep 17 00:00:00 2001 From: Lenka Doudova Date: Wed, 15 Jun 2016 13:40:00 +0200 Subject: [PATCH] Tests: Tracker class for services Provides basic service tracker, so far for purposes of [1]. Tracker is not complete, some methods will need to be added in case of service test refactoring. [1] https://fedorahosted.org/freeipa/ticket/433 --- ipatests/test_xmlrpc/tracker/service_plugin.py | 173 + 1 file changed, 173 insertions(+) create mode 100644 ipatests/test_xmlrpc/tracker/service_plugin.py diff --git a/ipatests/test_xmlrpc/tracker/service_plugin.py b/ipatests/test_xmlrpc/tracker/service_plugin.py new file mode 100644 index ..3fdf17ddf9cd7fee7b5af71347b32c41f61cd355 --- /dev/null +++ b/ipatests/test_xmlrpc/tracker/service_plugin.py @@ -0,0 +1,173 @@ +# -*- coding: utf-8 -*- +# +# Copyright (C) 2016 FreeIPA Contributors see COPYING for license +# + +import six + +from ipalib import api +from ipatests.test_xmlrpc.tracker.base import Tracker +from ipatests.test_xmlrpc.xmlrpc_test import fuzzy_uuid +from ipatests.test_xmlrpc import objectclasses +from ipatests.util import assert_deepequal +from ipapython.dn import DN + +if six.PY3: +unicode = str + + +class ServiceTracker(Tracker): +""" +Tracker class for service plugin + +So far does not include methods for these commands: +service-add-host +service-remove-host +service-allow-retrieve-keytab +service-disallow-retrieve-keytab +service-allow-create-keytab +service-disallow-create-keytab +service-disable +service-add-cert +service-remove-cert +""" + +retrieve_keys = { +u'dn', u'krbprincipalname', u'usercertificate', u'has_keytab', +u'ipakrbauthzdata', u'ipaallowedtoperform', u'subject', +u'managedby', u'serial_number', u'serial_number_hex', u'issuer', +u'valid_not_before', u'valid_not_after', u'md5_fingerprint', +u'sha1_fingerprint', u'krbprincipalauthind', u'managedby_host'} +retrieve_all_keys = retrieve_keys | { +u'ipaKrbPrincipalAlias', u'ipaUniqueID', u'krbExtraData', +u'krbLastPwdChange', u'krbLoginFailedCount', u'memberof', +u'objectClass', u'ipakrbrequirespreauth', +u'ipakrbokasdelegate'} + +create_keys = (retrieve_keys | {u'objectclass', u'ipauniqueid'}) - { +u'usercertificate', u'has_keytab'} +update_keys = retrieve_keys - {u'dn'} + +def __init__(self, name, host_fqdn, options): +super(ServiceTracker, self).__init__(default_version=None) +self._name = "{0}/{1}@{2}".format(name, host_fqdn, api.env.realm) +self.dn = DN( +('krbprincipalname', self.name), api.env.container_service, +api.env.basedn) +self.host_fqdn = host_fqdn +self.options = options + +@property +def name(self): +return self._name + +def make_create_command(self, force=True): +""" Make function that creates a service """ +return self.make_command('service_add', self.name, + force=force, **self.options) + +def make_delete_command(self): +""" Make function that deletes a service """ +return self.make_command('service_del', self.name) + +def make_retrieve_command(self, all=False, raw=False): +""" Make function that retrieves a service """ +return self.make_command('service_show', self.name, all=all) + +def make_find_command(self, *args, **kwargs): +""" Make function that searches for a service""" +return self.make_command('service_find', *args, **kwargs) + +def make_update_command(self, updates): +""" Make function that updates a service """ + +return self.make_command('service_mod', self.name, **updates) + +def track_create(self, **options): +""" Update expected state for service creation """ +self.attrs = { +u'dn': self.dn, +u'krbprincipalname': [u'{0}'.format(self.name)], +u'objectclass': objectclasses.service, +u'ipauniqueid': [fuzzy_uuid], +u'managedby_host': [self.host_fqdn], +} + +for key in self.options: +self.attrs[key] = [self.options[key]] + +def check_create(self, result): +""" Check service-add command result """ +assert_deepequal({ +u'value': u'{0}'.format(self.name), +u'summary': u'Added service "{0}"'.format(self.name), +u'result': self.filter_attrs(self.create_keys) +
Re: [Freeipa-devel] [PATCH 0133] Require 389-ds-base >= 1.3.5.6
On (16/06/16 12:00), Petr Spacek wrote: >Hello, > >Require 389-ds-base >= 1.3.5.6 > >Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. >See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html > >https://fedorahosted.org/freeipa/ticket/2008 > >-- >Petr^2 Spacek >From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Thu, 16 Jun 2016 11:58:56 +0200 >Subject: [PATCH] Require 389-ds-base >= 1.3.5.6 > >Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. >See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html > >https://fedorahosted.org/freeipa/ticket/2008 >--- > freeipa.spec.in | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index >d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f > 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > > %if ! %{ONLY_CLIENT} >-BuildRequires: 389-ds-base-devel >= 1.3.5 >+BuildRequires: 389-ds-base-devel >= 1.3.5.6 I know that patch was pushed and it fixed your problem. but I am little bit curious why did you need to change version in BuildRequires? If I understand correctly FreeIPA complies well with 1.3.5. The only problem was at runtime. LS -- 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 0503-0513, 0515-0519] DNS locations
On 16.6.2016 13:57, Martin Basti wrote: > > > On 16.06.2016 12:09, Petr Spacek wrote: >> On 15.6.2016 17:24, Petr Spacek wrote: >>> On 15.6.2016 15:45, Martin Basti wrote: On 15.06.2016 14:52, Martin Basti wrote: > > Hydra patching: Updated patches attached + new patches for dnsserver-* > commands attached >> > Updated+rebased patches after Honza's interactive review > > Minor nitpick fixed >>> freeipa-mbasti-0503.3-DNS-Locations-add-index-for-ipalocation-attribute.patch >>> ACK >>> >>> freeipa-mbasti-0505.3-DNS-Locations-add-idnsTemplateObject-objectclass.patch >>> ACK >>> >>> >>> I will get to the rest later on. >> >> Problems I found (could be solved in separate patches if you wish): >> >> 1. NACK >> # ipa dns-update-system-records --dry-run >> ipa: ERROR: an internal error has occurred >> ValueError: dns_update_system_records.validate_output(): unexpected keys >> ['summary'] in { ... > Fixed >> >> 2. NACK >> Command ipa dns-update-system-records does not work with DNS Administrators >> privilege when some record is missing: >> >> ipa: WARNING: Update of system record >> '_kpasswd._tcp.dom-046.abc.idm.lab.eng.brq.redhat.com. 86400 IN SRV 0 100 464 >> vm-046.abc.idm.lab.eng.brq.redhat.com.' failed with error: Insufficient >> access: Insufficient 'write' privilege to the 'objectClass' attribute of >> entry >> 'idnsname=_kpasswd._tcp,idnsname=dom-046.abc.idm.lab.eng.brq.redhat.com.,cn=dns,dc=suffix'. >> > Fixed (I hope) >> 3. NACK >> IPA server upgrade does not create idnsServerConfigObjects in cn=dns >> In fact the upgrade does not even add the object class into schema. >> > Fixed >> These needs to be fixed before we can proceed. >> > Updated patches attached 4. NACK ipa-ca-install does not add A/ records for the new CA. 5. NACK ipa-replica-manage del does not delete SRV records from the remaining master # ipa-replica-manage del vm-046.abc.idm.lab.eng.brq.redhat.com WARNING: yacc table file version is out of date Checking connectivity in topology suffix 'domain' Checking connectivity in topology suffix 'ca' Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com entries: invalid 'idnsserverid': must be Unicode text You may need to manually remove them from the tree Checking for deleted segments in suffix 'domain' Agreements deleted Checking for deleted segments in suffix 'ca' Agreements deleted Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com DNS entries: abc.idm.lab.eng.brq.redhat.com.: DNS zone not found You may need to manually remove them from the tree Manual execution of ipa dns-update-system-records fixes that. Besides NACKs above one more thing is missing: Following config options are not migrated from named.conf to LDAP object: https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/PerServerConfigInLDAP#Upgrade This can go to a separate patch set if you wish (at the very end). -- 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
Re: [Freeipa-devel] [PATCH 0133] Require 389-ds-base >= 1.3.5.6
On 16.6.2016 15:58, Lukas Slebodnik wrote: > On (16/06/16 12:00), Petr Spacek wrote: >> Hello, >> >> Require 389-ds-base >= 1.3.5.6 >> >> Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. >> See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html >> >> https://fedorahosted.org/freeipa/ticket/2008 >> >> -- >> Petr^2 Spacek > >>From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Thu, 16 Jun 2016 11:58:56 +0200 >> Subject: [PATCH] Require 389-ds-base >= 1.3.5.6 >> >> Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. >> See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html >> >> https://fedorahosted.org/freeipa/ticket/2008 >> --- >> freeipa.spec.in | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index >> d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f >> 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz >> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} >> -n) >> >> %if ! %{ONLY_CLIENT} >> -BuildRequires: 389-ds-base-devel >= 1.3.5 >> +BuildRequires: 389-ds-base-devel >= 1.3.5.6 > I know that patch was pushed and it fixed your problem. > but I am little bit curious why did you need to change > version in BuildRequires? > > If I understand correctly FreeIPA complies well with 1.3.5. > The only problem was at runtime. Right, I did not bother to test it. Feel free to submit correcting patch. -- 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] [PATCH] 497 Update Developers in Contributors.txt
Since we are close to 4.4 release, let's add the latest contributors. (master branch should be enough). -- Martin Kosek Manager, Software Engineering - Identity Management Team Red Hat, Inc. From 2f3b4706fbdf4319a54ef679042cdf1b156787b5 Mon Sep 17 00:00:00 2001 From: Martin Kosek Date: Thu, 16 Jun 2016 15:49:16 +0200 Subject: [PATCH] Update Developers in Contributors.txt Add the most recent development contributors to FreeIPA. --- Contributors.txt | 8 1 file changed, 8 insertions(+) diff --git a/Contributors.txt b/Contributors.txt index 8858724fab4febf01e19d8660786c10ddcc7a3b6..71be27da5ab415deb11589d5bf82d684b2d85f9a 100644 --- a/Contributors.txt +++ b/Contributors.txt @@ -12,6 +12,7 @@ Developers: Kyle Baker Martin BaÅ¡ti Sylvain Baubeau + Florence Blanc-Renaud Alexander Bokovoy Thierry Bordaz Sumit Bose @@ -30,9 +31,12 @@ Developers: Endi Sukma Dewata Lenka Doudova Benjamin Drung + Patrice Duc-Jacquet Drew Erny Oleg Fayans + Jérôme Fenal Stephen Gallagher + James Groffen OndÅej Hamada Nick Hatch Christian Heimes @@ -48,6 +52,7 @@ Developers: Ian Kumlien David Kupka Robert Kuska + Peter Lacko Stanislav Laznicka Ade Lee Karl MacMillan @@ -70,12 +75,14 @@ Developers: W. Michael Petullo Gowrishankar Rajaiyan LubomÃr Rintel + Matt Rogers Lynn Root Pete Rowley Lenka Ryznarova Thorsten Scherf Michael Simacek Lars Sjostrom + Filip Skola Lukáš SlebodnÃk Simo Sorce Petr Å paÄek @@ -84,6 +91,7 @@ Developers: Fraser Tweedale Petr Viktorin Petr VobornÃk + Pavel Vomacka Andrew Wnuk Jason Woods Adam Young -- 2.5.5 -- 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] 0019 - 2 ipapwd_extop should take precedence over default DS plugin
The version DS 1.3.5.6 is now available. Here is the second version of the patch taking into account lower precedence for Schema Compat On 06/13/2016 06:01 PM, Alexander Bokovoy wrote: On Mon, 13 Jun 2016, thierry bordaz wrote: On 06/13/2016 04:57 PM, Alexander Bokovoy wrote: On Mon, 13 Jun 2016, thierry bordaz wrote: This is the fix for https://fedorahosted.org/freeipa/ticket/5944 From 2838fbfc7a22b9bc0c1c4dfaf3660d1ac7099461 Mon Sep 17 00:00:00 2001 From: Thierry Bordaz Date: Wed, 8 Jun 2016 14:03:42 +0200 Subject: [PATCH] Make sure ipapwd_extop takes precedence over passwd_modify_extop DS core server provides a default plugin (passwd_modify_extop) to handle 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) IPA delivers ipa_pwd_extop plugin that should take precedence over the default DS plugin (passwd_modify_extop) --- install/updates/10-ipapwd.update | 9 + 1 file changed, 9 insertions(+) create mode 100644 install/updates/10-ipapwd.update diff --git a/install/updates/10-ipapwd.update b/install/updates/10-ipapwd.update new file mode 100644 index 000..d9bffa2 --- /dev/null +++ b/install/updates/10-ipapwd.update @@ -0,0 +1,9 @@ +dn: cn=ipa_pwd_extop,cn=plugins,cn=config +# DS core server provides a default plugin (passwd_modify_extop) to handle +# 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) +# the pluginprecedence of the passwd_modify_extop is 50 (default value) +# +# IPA delivers ipa_pwd_extop plugin to handle that extended op +# we need to make sure ipa_pwd_extop is called and so to set a lower +# precedence value +add:nsslapd-pluginprecedence: 49 Here is the problem: slapi-nis is 49 as well and it should be before ipa_pwd_extop. You need to update install/share/schema_compat.uldif and install/updates/10-schema_compat.update to get slapi-nis before ipa_pwd_extop. ipapwd_plugin registers extendedop callback but slapi-nis does not. So I do not think they will "fight" for precedence. Even if slapi-nis register perextendedop they will be on different lists and it should not create any issue. Now I understand that slapi-nis must run with a precedence that should be lower than most of the others plugins. Currently it is 49, are you ok with a value like 40 ? I'm OK with 40, yes. The precedence applies to all callbacks, not just to preextendedop, so a BIND callback would be affected too. You also need to make sure we depend on the updated 389-ds-base package version. Good ! Now with this dependency we should wait for 389-ds 1.3.5.5 to be available, I will resend the review when it will be available. Yep, thanks. >From 81af4f17deca1814851429a054804b5bc9f63491 Mon Sep 17 00:00:00 2001 From: Thierry Bordaz Date: Thu, 16 Jun 2016 16:28:03 +0200 Subject: [PATCH] Make sure ipapwd_extop takes precedence over passwd_modify_extop DS core server provides a default plugin (passwd_modify_extop) to handle 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) IPA delivers ipa_pwd_extop plugin that should take precedence over the default DS plugin (passwd_modify_extop) In addition make sure that slapi-nis has a low precedence --- install/share/schema_compat.uldif | 2 +- install/updates/10-ipapwd.update| 9 + install/updates/10-schema_compat.update | 2 +- 3 files changed, 11 insertions(+), 2 deletions(-) create mode 100644 install/updates/10-ipapwd.update diff --git a/install/share/schema_compat.uldif b/install/share/schema_compat.uldif index a3d412f..66f8ea1 100644 --- a/install/share/schema_compat.uldif +++ b/install/share/schema_compat.uldif @@ -16,7 +16,7 @@ default:nsslapd-pluginid: schema-compat-plugin # We need to run schema-compat pre-bind callback before # other IPA pre-bind callbacks to make sure bind DN is # rewritten to the original entry if needed -default:nsslapd-pluginprecedence: 49 +default:nsslapd-pluginprecedence: 40 default:nsslapd-pluginversion: 0.8 default:nsslapd-pluginbetxn: on default:nsslapd-pluginvendor: redhat.com diff --git a/install/updates/10-ipapwd.update b/install/updates/10-ipapwd.update new file mode 100644 index 000..d9bffa2 --- /dev/null +++ b/install/updates/10-ipapwd.update @@ -0,0 +1,9 @@ +dn: cn=ipa_pwd_extop,cn=plugins,cn=config +# DS core server provides a default plugin (passwd_modify_extop) to handle +# 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) +# the pluginprecedence of the passwd_modify_extop is 50 (default value) +# +# IPA delivers ipa_pwd_extop plugin to handle that extended op +# we need to make sure ipa_pwd_extop is called and so to set a lower +# precedence value +add:nsslapd-pluginprecedence: 49 diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index 2d257a3..e4c257d 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -74,7 +74,7 @@ dn: cn=Schema Compatibility,cn=plugins,cn=co
[Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964
-- Oleg Fayans Quality Engineer FreeIPA team RedHat. From debac0cf5cb24e1c2072d10373f4d9f72cb875a7 Mon Sep 17 00:00:00 2001 From: Oleg Fayans Date: Thu, 16 Jun 2016 16:45:03 +0200 Subject: [PATCH] Automated clean-ruv subcommand test https://fedorahosted.org/freeipa/ticket/5964 --- ipatests/test_integration/test_topology.py | 51 ++ 1 file changed, 51 insertions(+) diff --git a/ipatests/test_integration/test_topology.py b/ipatests/test_integration/test_topology.py index e956563c27eafd84deed5786274a73d0d3594642..849ee12267b2f0412dee189440c2fe7bd0cdec85 100644 --- a/ipatests/test_integration/test_topology.py +++ b/ipatests/test_integration/test_topology.py @@ -159,3 +159,54 @@ class TestTopologyOptions(IntegrationTest): assert err == "", err returncode, error = tasks.destroy_segment(self.master, "%s-to-%s" % replicas) assert returncode == 0, error + + +@pytest.mark.skipif(config.domain_level == 0, reason=reasoning) +class TestCASpecificRUVs(IntegrationTest): +num_replicas = 1 +topology = 'star' +username = 'testuser' +user_firstname = 'test' +user_lastname = 'user' + +def test_ca_specific_ruvs(self): +""" +http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan +#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended +_to_handle_CA-specific_RUVs +""" +replica = self.replicas[0] +master = self.master +result1 = master.run_command(['ipa-replica-manage', 'list-ruv', + '-p', master.config.dirman_password]) +assert(result1.stdout_text.count(replica.hostname) == 2 and + "Certificate Server Replica Update Vectors" in result1.stdout_text), ( +"CA-specific RUVs are not displayed") +ruvid_re = re.compile(".*%s:389: (\d+).*" % replica) +replica_ruv_ids = ruvid_re.findall(result1.stdout_text) +result2 = master.run_command(['ipa-replica-manage', 'clean-ruv', + replica_ruv_ids[1], '-p', + master.config.dirman_password, '-f']) +assert(replica.hostname in result2.stdout_text), ( +"The wrong RUV was deleted") +result3 = master.run_command(['ipa-replica-manage', 'list-ruv', + '-p', master.config.dirman_password]) +assert(result3.stdout_text.count(replica.hostname) == 1), ( +"CA RUV of the replica is still displayed") +result4 = master.run_command(['ipa-replica-manage', 'clean-ruv', + replica_ruv_ids[0], '-p', + master.config.dirman_password, '-f']) +assert(replica.hostname in result4.stdout_text), ( +"The wrong RUV was deleted") +result5 = master.run_command(['ipa-replica-manage', 'list-ruv', + '-p', master.config.dirman_password]) +assert(replica.hostname not in result5.stdout_text), ( +"replica's RUV is still displayed") +tasks.kinit_admin(master) +master.run_command(['ipa', 'user-add', self.username, +"--first=%s" % self.user_firstname, +"--last=%s" % self.user_lastname]) +result6 = replica.run_command(['ipa', 'user-show', self.username], + raiseonerr=False) +assert(result6.returncode > 0), ( +'Replication still works after all RUVs were deleted') -- 1.8.3.1 -- 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 0048] Remove sys.exit() from installer modules
Hello, This patch removes most sys.exits() from installer modules and scripts and replaces them with ScriptError. I only left sys.exits at places where the user decides yes/no on continuation of the script. From 7968f068141e53f7bf111221b38c40cac432 Mon Sep 17 00:00:00 2001 From: Stanislav Laznicka Date: Thu, 16 Jun 2016 17:12:24 +0200 Subject: [PATCH] Remove sys.exit from install modules and scripts sys.exit() calls sometimes make it hard to find bugs and mask code that does not always work properly. https://fedorahosted.org/freeipa/ticket/5750 --- install/tools/ipa-adtrust-install | 17 +++--- install/tools/ipa-ca-install | 23 install/tools/ipa-compat-manage| 11 ++-- install/tools/ipa-dns-install | 3 +- ipaserver/install/bindinstance.py | 2 +- ipaserver/install/ca.py| 19 +++--- ipaserver/install/cainstance.py| 5 +- ipaserver/install/dns.py | 5 +- ipaserver/install/dsinstance.py| 3 +- ipaserver/install/installutils.py | 16 +++--- ipaserver/install/ipa_ldap_updater.py | 2 +- ipaserver/install/krainstance.py | 3 +- ipaserver/install/replication.py | 10 ++-- ipaserver/install/server/install.py| 64 +++-- ipaserver/install/server/replicainstall.py | 92 -- 15 files changed, 147 insertions(+), 128 deletions(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 36caa5c2d429c6cf107df03e82aa80e15d8efe01..da635cb02c3c8affb234515dd64f2cb06e9ea872 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -37,6 +37,7 @@ from ipaserver.install.installutils import ( from ipaserver.install import service from ipapython import version from ipapython import ipautil, sysrestore, ipaldap +from ipapython.admintool import ScriptError from ipalib import api, errors, krb_utils from ipapython.config import IPAOptionParser from ipaplatform.paths import paths @@ -192,7 +193,7 @@ def set_and_check_netbios_name(netbios_name, unattended): if not adtrustinstance.check_netbios_name(netbios_name): if unattended and not gen_netbios_name: netbios_name_error(netbios_name) -sys.exit("Aborting installation.") +raise ScriptError("Aborting installation.") else: if netbios_name: netbios_name_error(netbios_name) @@ -227,7 +228,7 @@ def main(): safe_options, options = parse_options() if os.getegid() != 0: -sys.exit("Must be root to setup AD trusts on server") +raise ScriptError("Must be root to setup AD trusts on server") standard_logging_setup(log_file_name, debug=options.debug, filemode='a') print("\nThe log file for this installation can be found in %s" % log_file_name) @@ -255,7 +256,7 @@ def main(): # Check if samba packages are installed if not adtrustinstance.check_inst(): -sys.exit("Aborting installation.") +raise ScriptError("Aborting installation.") # Initialize the ipalib api cfg = dict( @@ -318,14 +319,14 @@ def main(): try: principal = krb_utils.get_principal() except errors.CCacheError as e: -sys.exit("Must have Kerberos credentials to setup AD trusts on server: %s" % e.message) +raise ScriptError("Must have Kerberos credentials to setup AD trusts on server: %s" % e.message) try: api.Backend.ldap2.connect() except errors.ACIError as e: -sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") +raise ScriptError("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket") except errors.DatabaseError as e: -sys.exit("Cannot connect to the LDAP database. Please check if IPA is running") +raise ScriptError("Cannot connect to the LDAP database. Please check if IPA is running") try: user = api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result'] @@ -334,9 +335,9 @@ def main(): group['cn'][0] in user['memberof_group']): raise errors.RequirementError(name='admins group membership') except errors.RequirementError as e: -sys.exit("Must have administrative privileges to setup AD trusts on server") +raise ScriptError("Must have administrative privileges to setup AD trusts on server") except Exception as e: -sys.exit("Unrecognized error during check of admin rights: %s" % (str(e))) +raise ScriptError("Unrecognized error during check of admin rights: %s" % (str(e))) (netbios_name, reset_netbios_name) = \ set_and_check_netbios_name(options.netbios_name, diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install index 1bc5def03bf687a1e4f9fb38a54363b5429c8fc4..3a863
Re: [Freeipa-devel] [PATCH] 0019 - 2 ipapwd_extop should take precedence over default DS plugin
On Thu, 16 Jun 2016, thierry bordaz wrote: The version DS 1.3.5.6 is now available. Here is the second version of the patch taking into account lower precedence for Schema Compat On 06/13/2016 06:01 PM, Alexander Bokovoy wrote: On Mon, 13 Jun 2016, thierry bordaz wrote: On 06/13/2016 04:57 PM, Alexander Bokovoy wrote: On Mon, 13 Jun 2016, thierry bordaz wrote: This is the fix for https://fedorahosted.org/freeipa/ticket/5944 From 2838fbfc7a22b9bc0c1c4dfaf3660d1ac7099461 Mon Sep 17 00:00:00 2001 From: Thierry Bordaz Date: Wed, 8 Jun 2016 14:03:42 +0200 Subject: [PATCH] Make sure ipapwd_extop takes precedence over passwd_modify_extop DS core server provides a default plugin (passwd_modify_extop) to handle 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) IPA delivers ipa_pwd_extop plugin that should take precedence over the default DS plugin (passwd_modify_extop) --- install/updates/10-ipapwd.update | 9 + 1 file changed, 9 insertions(+) create mode 100644 install/updates/10-ipapwd.update diff --git a/install/updates/10-ipapwd.update b/install/updates/10-ipapwd.update new file mode 100644 index 000..d9bffa2 --- /dev/null +++ b/install/updates/10-ipapwd.update @@ -0,0 +1,9 @@ +dn: cn=ipa_pwd_extop,cn=plugins,cn=config +# DS core server provides a default plugin (passwd_modify_extop) to handle +# 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) +# the pluginprecedence of the passwd_modify_extop is 50 (default value) +# +# IPA delivers ipa_pwd_extop plugin to handle that extended op +# we need to make sure ipa_pwd_extop is called and so to set a lower +# precedence value +add:nsslapd-pluginprecedence: 49 Here is the problem: slapi-nis is 49 as well and it should be before ipa_pwd_extop. You need to update install/share/schema_compat.uldif and install/updates/10-schema_compat.update to get slapi-nis before ipa_pwd_extop. ipapwd_plugin registers extendedop callback but slapi-nis does not. So I do not think they will "fight" for precedence. Even if slapi-nis register perextendedop they will be on different lists and it should not create any issue. Now I understand that slapi-nis must run with a precedence that should be lower than most of the others plugins. Currently it is 49, are you ok with a value like 40 ? I'm OK with 40, yes. The precedence applies to all callbacks, not just to preextendedop, so a BIND callback would be affected too. You also need to make sure we depend on the updated 389-ds-base package version. Good ! Now with this dependency we should wait for 389-ds 1.3.5.5 to be available, I will resend the review when it will be available. Yep, thanks. From 81af4f17deca1814851429a054804b5bc9f63491 Mon Sep 17 00:00:00 2001 From: Thierry Bordaz Date: Thu, 16 Jun 2016 16:28:03 +0200 Subject: [PATCH] Make sure ipapwd_extop takes precedence over passwd_modify_extop DS core server provides a default plugin (passwd_modify_extop) to handle 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) IPA delivers ipa_pwd_extop plugin that should take precedence over the default DS plugin (passwd_modify_extop) In addition make sure that slapi-nis has a low precedence --- install/share/schema_compat.uldif | 2 +- install/updates/10-ipapwd.update| 9 + install/updates/10-schema_compat.update | 2 +- 3 files changed, 11 insertions(+), 2 deletions(-) create mode 100644 install/updates/10-ipapwd.update diff --git a/install/share/schema_compat.uldif b/install/share/schema_compat.uldif index a3d412f..66f8ea1 100644 --- a/install/share/schema_compat.uldif +++ b/install/share/schema_compat.uldif @@ -16,7 +16,7 @@ default:nsslapd-pluginid: schema-compat-plugin # We need to run schema-compat pre-bind callback before # other IPA pre-bind callbacks to make sure bind DN is # rewritten to the original entry if needed -default:nsslapd-pluginprecedence: 49 +default:nsslapd-pluginprecedence: 40 default:nsslapd-pluginversion: 0.8 default:nsslapd-pluginbetxn: on default:nsslapd-pluginvendor: redhat.com diff --git a/install/updates/10-ipapwd.update b/install/updates/10-ipapwd.update new file mode 100644 index 000..d9bffa2 --- /dev/null +++ b/install/updates/10-ipapwd.update @@ -0,0 +1,9 @@ +dn: cn=ipa_pwd_extop,cn=plugins,cn=config +# DS core server provides a default plugin (passwd_modify_extop) to handle +# 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt) +# the pluginprecedence of the passwd_modify_extop is 50 (default value) +# +# IPA delivers ipa_pwd_extop plugin to handle that extended op +# we need to make sure ipa_pwd_extop is called and so to set a lower +# precedence value +add:nsslapd-pluginprecedence: 49 diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index 2d257a3..e4c257d 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -74,7 +74,7 @@ dn: cn=S
Re: [Freeipa-devel] [PATCH 0133] Require 389-ds-base >= 1.3.5.6
On Thu, 16 Jun 2016, Lukas Slebodnik wrote: On (16/06/16 12:00), Petr Spacek wrote: Hello, Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 -- Petr^2 Spacek From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001 From: Petr Spacek Date: Thu, 16 Jun 2016 11:58:56 +0200 Subject: [PATCH] Require 389-ds-base >= 1.3.5.6 Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap. See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html https://fedorahosted.org/freeipa/ticket/2008 --- freeipa.spec.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %if ! %{ONLY_CLIENT} -BuildRequires: 389-ds-base-devel >= 1.3.5 +BuildRequires: 389-ds-base-devel >= 1.3.5.6 I know that patch was pushed and it fixed your problem. but I am little bit curious why did you need to change version in BuildRequires? If I understand correctly FreeIPA complies well with 1.3.5. The only problem was at runtime. We actually need 1.3.5.6 for slapi-nis and pwd extop plugins to build as we are using all new pre-extop operation callback. -- / Alexander Bokovoy -- 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] [Design Review Request] V4/Automatic_Certificate_Request_Generation
On 06/14/2016 08:27 AM, Ben Lipton wrote: Hello all, I have written up a design proposal for making certificate requests easier to generate when using alternate certificate profiles: http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. The use case for this is described in https://fedorahosted.org/freeipa/ticket/4899. I will be working on implementing this design over the next couple of months. If you have the time and interest, please take a look and share any comments or concerns that you have. Thanks! Ben Just a quick update to say that I've created a new document that covers the proposed schema additions in a more descriptive way (with diagrams!) I'm very new to developing with LDAP, so some more experienced eyes on the proposal would be very helpful, even if you don't have time to absorb the full design. Please take a look at http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema if you have a chance. Thanks, Ben -- 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] 0069 renew_ca_cert: bootstrap api with in_server=True
Attached patch fixes https://fedorahosted.org/freeipa/ticket/5968 Thanks, Fraser From 47ddd811f37fc026c296dd6c2fd44be606ba5a75 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 17 Jun 2016 14:18:05 +1000 Subject: [PATCH] renew_ca_cert: bootstrap api with in_server=True renew_ca_cert is failing because it cannot access the 'config' plugin. Bootstrap with in_server=True to remedy. Fixes: https://fedorahosted.org/freeipa/ticket/5968 --- install/restart_scripts/renew_ca_cert | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/restart_scripts/renew_ca_cert b/install/restart_scripts/renew_ca_cert index bfb726cddf1b747f01512a85408fd479427ced44..dc0f1117b366e3fdcf6d00f0e6d928e2e32b8f2b 100644 --- a/install/restart_scripts/renew_ca_cert +++ b/install/restart_scripts/renew_ca_cert @@ -38,7 +38,7 @@ from ipaplatform.paths import paths def _main(): nickname = sys.argv[1] -api.bootstrap(context='restart') +api.bootstrap(in_server=True, context='restart') api.finalize() dogtag_service = services.knownservices['pki_tomcatd'] -- 2.5.5 -- 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 0048] Remove sys.exit() from installer modules
On 16.6.2016 17:33, Stanislav Laznicka wrote: > Hello, > > This patch removes most sys.exits() from installer modules and scripts and > replaces them with ScriptError. I only left sys.exits at places where the user > decides yes/no on continuation of the script. I wonder if yes/no should be replaced with KeyboardInterrupt or some other exception, too... -- 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
Re: [Freeipa-devel] [PATCH] 0069 renew_ca_cert: bootstrap api with in_server=True
Hi, On 17.6.2016 06:55, Fraser Tweedale wrote: Attached patch fixes https://fedorahosted.org/freeipa/ticket/5968 This should be fixed for all the restart scripts, not just renew_ca_cert. Thanks, Fraser Honza -- 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 0048] Remove sys.exit() from installer modules
On 06/17/2016 07:45 AM, Petr Spacek wrote: On 16.6.2016 17:33, Stanislav Laznicka wrote: Hello, This patch removes most sys.exits() from installer modules and scripts and replaces them with ScriptError. I only left sys.exits at places where the user decides yes/no on continuation of the script. I wonder if yes/no should be replaced with KeyboardInterrupt or some other exception, too... I'm not sure, it seems more clear to just really exit if the user desires it and it's what we say we'll do (with possible cleanup beforehand). Do you think we could benefit somehow by raising an exception here? -- 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 0503-0513, 0515-0519, 0520-0528] DNS locations
On 16.6.2016 22:14, Martin Basti wrote: > > > On 16.06.2016 15:59, Petr Spacek wrote: >> On 16.6.2016 13:57, Martin Basti wrote: >>> >>> On 16.06.2016 12:09, Petr Spacek wrote: On 15.6.2016 17:24, Petr Spacek wrote: > On 15.6.2016 15:45, Martin Basti wrote: >> On 15.06.2016 14:52, Martin Basti wrote: >>> >>> Hydra patching: Updated patches attached + new patches for dnsserver-* >>> commands attached >>> Updated+rebased patches after Honza's interactive review >>> >>> >> Minor nitpick fixed >> >> >> > freeipa-mbasti-0503.3-DNS-Locations-add-index-for-ipalocation-attribute.patch > > ACK > > freeipa-mbasti-0505.3-DNS-Locations-add-idnsTemplateObject-objectclass.patch > ACK > > > I will get to the rest later on. Problems I found (could be solved in separate patches if you wish): 1. NACK # ipa dns-update-system-records --dry-run ipa: ERROR: an internal error has occurred ValueError: dns_update_system_records.validate_output(): unexpected keys ['summary'] in { ... >>> Fixed 2. NACK Command ipa dns-update-system-records does not work with DNS Administrators privilege when some record is missing: ipa: WARNING: Update of system record '_kpasswd._tcp.dom-046.abc.idm.lab.eng.brq.redhat.com. 86400 IN SRV 0 100 464 vm-046.abc.idm.lab.eng.brq.redhat.com.' failed with error: Insufficient access: Insufficient 'write' privilege to the 'objectClass' attribute of entry 'idnsname=_kpasswd._tcp,idnsname=dom-046.abc.idm.lab.eng.brq.redhat.com.,cn=dns,dc=suffix'. >>> Fixed (I hope) 3. NACK IPA server upgrade does not create idnsServerConfigObjects in cn=dns In fact the upgrade does not even add the object class into schema. >>> Fixed These needs to be fixed before we can proceed. >>> Updated patches attached >> 4. NACK >> ipa-ca-install does not add A/ records for the new CA. > This should work, code is on the right place. Maybe it is a race condition. > > ... 2 hours later ... > > I found that this is broken since 4.3.0, I will fix it separately > https://fedorahosted.org/freeipa/ticket/5966 > > Anyway I found bug in replicainstall (fixed) because copy&paste everywhere > >> >> 5. NACK >> ipa-replica-manage del does not delete SRV records from the >> remaining master >> >> # ipa-replica-manage del vm-046.abc.idm.lab.eng.brq.redhat.com >> WARNING: yacc table file version is out of date >> Checking connectivity in topology suffix 'domain' >> Checking connectivity in topology suffix 'ca' >> Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com entries: invalid >> 'idnsserverid': must be Unicode text >> You may need to manually remove them from the tree >> Checking for deleted segments in suffix 'domain' >> Agreements deleted >> Checking for deleted segments in suffix 'ca' >> Agreements deleted >> Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com DNS entries: >> abc.idm.lab.eng.brq.redhat.com.: DNS zone not found >> You may need to manually remove them from the tree > Fixed >> >> Manual execution of ipa dns-update-system-records fixes that. >> >> >> >> Besides NACKs above one more thing is missing: >> Following config options are not migrated from named.conf to LDAP object: >> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/PerServerConfigInLDAP#Upgrade >> >> >> This can go to a separate patch set if you wish (at the very end). > I will leave this for later, bind-dyndb-ldap will continue working with local > configuration as before, patches are of course welcome. > > Updated patches attached, + hydra patching 6. NACK # ipa server-show $(hostname) Managed suffixes: domain, ca Min domain level: 0 Max domain level: 1 Location: l1 Enabled server roles: CA server, DNS server, NTP server Server name: vm-046.abc.idm.lab.eng.brq.redhat.com [root@vm-046 review]# ipa server-mod $(hostname) --location=l2 ipa: ERROR: no modifications to be performed -- 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
Re: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules
On 17.6.2016 08:43, Stanislav Laznicka wrote: > On 06/17/2016 07:45 AM, Petr Spacek wrote: >> On 16.6.2016 17:33, Stanislav Laznicka wrote: >>> Hello, >>> >>> This patch removes most sys.exits() from installer modules and scripts and >>> replaces them with ScriptError. I only left sys.exits at places where the >>> user >>> decides yes/no on continuation of the script. >> I wonder if yes/no should be replaced with KeyboardInterrupt or some other >> exception, too... >> > I'm not sure, it seems more clear to just really exit if the user desires it > and it's what we say we'll do (with possible cleanup beforehand). Do you think > we could benefit somehow by raising an exception here? I'm just thinking out loud. It seemed to me that it is easier to share cleanup on one except block instead of having if (interrupt): cleanup; if (interrupt2): same_cleanup; etc. Again, just wondering out loud. -- 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
Re: [Freeipa-devel] [PATCH] 0069 renew_ca_cert: bootstrap api with in_server=True
On Fri, Jun 17, 2016 at 08:35:45AM +0200, Jan Cholasta wrote: > Hi, > > On 17.6.2016 06:55, Fraser Tweedale wrote: > > Attached patch fixes https://fedorahosted.org/freeipa/ticket/5968 > > This should be fixed for all the restart scripts, not just renew_ca_cert. > Updated patch attached. From dac1e3e748fc5b9b3d48aa1dc2050d5f9a505773 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 17 Jun 2016 14:18:05 +1000 Subject: [PATCH] restart scripts: bootstrap api with in_server=True renew_ca_cert fails because it cannot access the 'config' plugin. Bootstrap all the restart scripts to avoid such issues. Fixes: https://fedorahosted.org/freeipa/ticket/5968 --- install/restart_scripts/renew_ca_cert | 2 +- install/restart_scripts/renew_ra_cert | 2 +- install/restart_scripts/restart_dirsrv | 2 +- install/restart_scripts/stop_pkicad| 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/install/restart_scripts/renew_ca_cert b/install/restart_scripts/renew_ca_cert index bfb726cddf1b747f01512a85408fd479427ced44..dc0f1117b366e3fdcf6d00f0e6d928e2e32b8f2b 100644 --- a/install/restart_scripts/renew_ca_cert +++ b/install/restart_scripts/renew_ca_cert @@ -38,7 +38,7 @@ from ipaplatform.paths import paths def _main(): nickname = sys.argv[1] -api.bootstrap(context='restart') +api.bootstrap(in_server=True, context='restart') api.finalize() dogtag_service = services.knownservices['pki_tomcatd'] diff --git a/install/restart_scripts/renew_ra_cert b/install/restart_scripts/renew_ra_cert index 9b5e231b526432bec3e6d187a674042a27b94b57..17a7af9b079ea6d91fc60fac2bcc65d8ec7d8bc0 100644 --- a/install/restart_scripts/renew_ra_cert +++ b/install/restart_scripts/renew_ra_cert @@ -37,7 +37,7 @@ from ipaplatform.paths import paths def _main(): nickname = 'ipaCert' -api.bootstrap(context='restart') +api.bootstrap(in_server=True, context='restart') api.finalize() tmpdir = tempfile.mkdtemp(prefix="tmp-") diff --git a/install/restart_scripts/restart_dirsrv b/install/restart_scripts/restart_dirsrv index 856729b5cd8dcfe7885a6ccf64aa847e6379102c..a8e78184f9a6f595a11440fbddae3c41933bb29b 100644 --- a/install/restart_scripts/restart_dirsrv +++ b/install/restart_scripts/restart_dirsrv @@ -33,7 +33,7 @@ def _main(): except IndexError: instance = "" -api.bootstrap(context='restart') +api.bootstrap(in_server=True, context='restart') api.finalize() syslog.syslog(syslog.LOG_NOTICE, "certmonger restarted dirsrv instance '%s'" % instance) diff --git a/install/restart_scripts/stop_pkicad b/install/restart_scripts/stop_pkicad index 30b99eeff80b42aedbada583df37f9fddb076aec..ae07dcd588a54bbb1328b289c9218d2053f32c0b 100644 --- a/install/restart_scripts/stop_pkicad +++ b/install/restart_scripts/stop_pkicad @@ -27,7 +27,7 @@ from ipaserver.install import certs def main(): -api.bootstrap(context='restart') +api.bootstrap(in_server=True, context='restart') api.finalize() dogtag_service = services.knownservices['pki_tomcatd'] -- 2.5.5 -- 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