From tscherf at redhat.com Sat Jan 3 20:53:29 2015 From: tscherf at redhat.com (Thorsten Scherf) Date: Sat, 3 Jan 2015 21:53:29 +0100 Subject: [Freeipa-devel] [PATCH 0007] Changed in-tree development setup instructions Message-ID: <20150103205329.GA27759@tscherf.redhat.com> Changed in-tree development setup instructions Instructions on how to setup an in-tree development server were not were clear in the existing BUILD.txt. Setup procedure has been extended and corrected. -------------- next part -------------- From aa5e269c78636fb9aab3ceffdd3a54a9e939db28 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Sat, 3 Jan 2015 21:43:39 +0100 Subject: [PATCH] Changed in-tree development setup instructions Instructions on how to setup an in-tree development server were not were clear in the existing BUILD.txt. Setup procedure has been extended and corrected. --- BUILD.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/BUILD.txt b/BUILD.txt index 62cbbd95b123128e978ad25907ba4d67ded1ffd4..95d40f8e8b8dd084130683aa016ba75c1ea662a9 100644 --- a/BUILD.txt +++ b/BUILD.txt @@ -47,8 +47,10 @@ install the rpms and then configure IPA using ipa-server-install. Get a TGT for the admin user with: kinit admin Next you'll need 2 sessions in the source tree. In the first session run -python lite-server.py. In the second session you can run the ./ipa -tool and it will make requests to the lite-server listening on 127.0.0.1:8080. +python lite-server.py. In the second session copy /etc/ipa/default.conf into +~/.ipa/default.conf and replace xmlrpc_uri with http://127.0.0.1:8888/ipa/xml. +Finally run the ./ipa tool and it will make requests to the lite-server +listening on 127.0.0.1:8888. This makes developing plugins much faster and you can also make use of the Python pdb debugger on the server side. -- 2.1.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From sbose at redhat.com Mon Jan 5 08:41:03 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 5 Jan 2015 09:41:03 +0100 Subject: [Freeipa-devel] Modifying ID Range In-Reply-To: References: Message-ID: <20150105084103.GC23112@localhost.localdomain> On Wed, Dec 24, 2014 at 08:50:29AM +0530, Prashant Bapat wrote: > Hi, > > What I'm trying to do is to modify the Range FreeIPA uses. I removed the > random Range Id created during install, added a new range that I wanted. > But problem is when I try to add a new user or a group now its still using > the old range that was created during installation. > > I tried restarting the ipa service but still no help. > > Any pointers to this will be appreciated. sorry, ID ranges changes at runtime are currently not supported because of the implications on the running system, e.g. users might not be able to access their home directory anymore. To use the new range the easiest way is to remove the SSSD cache on all systems, i.e. systemctl stop sssd.server; rm /var/lib/sssd/db/cache_* ; systemctl start sssd.service. Please note that with this scheme you will loose the cached password, i.e. offline authentication might fail if the given users hasn't logged in successfully after the cache was removed. HTH bye, Sumit > > Thanks. > --Prashant > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From prashant at apigee.com Mon Jan 5 09:15:56 2015 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 5 Jan 2015 14:45:56 +0530 Subject: [Freeipa-devel] SSH Public Key - Centralized Solution In-Reply-To: References: <54997906.9000507@redhat.com> Message-ID: Ping! Any pointers for doing this would be appreciated. On 30 December 2014 at 06:27, Prashant Bapat wrote: > Hi Again, > > For enforcing SSH key rotation every N days, I'm thinking the following. > Please let me know if this makes sense. > > 1. Limit the number of keys per user to 2. Control this via the webUI > during they public key upload. > 2. Append the current timestamp to the key during the upload. This gets > stores in LDAP under "ipaSshPubKey" attribute. > 3. Store all the key fingerprints permanently. Need to define a new > attribute for this. Idea is that a ssh key never gets reused. During the > upload verify that the key being uploaded is not already present in the > historical store. > 4. On the clients, use a ForcedCommand in SSH server and verify the > timestamp from #2 above is older than N days. Deny user with a error > message if true, allow if false. On similar lines of > http://www.sshark.org/ > > Please let me know your thoughts around this. This is the limiting feature > for us to implement FreeIPA in our org right now. > > Thanks in advance. > > --Prashant > > On 23 December 2014 at 21:39, Prashant Bapat wrote: > >> Adam, >> >> Thanks much for the reply. I will take a look at the code. >> >> For the expiration part, do you think it would be a good idea to modify >> the LDAP schema to include the SSH Pubkey upload date and have a external >> script to scan the keys for their age and alert/remove the keys ? If yes >> could you please give me some pointers on how this can be done ? >> >> Thanks again. >> --Prashant >> >> On 23 December 2014 at 19:45, Adam Young wrote: >>> >>> On 12/22/2014 08:40 PM, Prashant Bapat wrote: >>> >>> Hi, >>> >>> We are planning to roll out FreeIPA for our AWS infrastructure to be >>> the central authentication service. Initially we plan to use the SSH publi >>> keys, user and group management by FreeIPA. We are looking at rolling out >>> the SSS on clients a little later. >>> >>> Two questions. >>> >>> 1. We need to be able to ensure that a user is limited only 2-3 SSH >>> keys. >>> >>> SSH keys are a string attribute with a validator. In order to limit the >>> number, you would need to modify the plugin here: >>> >>> >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/util.py#n310 >>> >>> >>> >>> 2. We need some way of forcing these key rotation once in say 90 days. >>> >>> In our existing setup we use a SSH CA based authentication. It has its >>> own issues. But the rotation is handled by cert expiry every 90 days. >>> >>> >>> This is going to be harder. With password you can validate on login, >>> but there is caching involved with the public key, and I think you would >>> need to take that into account to force invalidation. This is why certs >>> are probably a better idea. >>> >>> Assuming you can flush the public keys fairly regularly, you would want >>> to put the expiration checking on the accessor for the key. This is a >>> direct ldap fetch and not managed by the IPA plugins. >>> >>> >>> Any suggestions/help would be appreciated. >>> >>> Thanks in advance. >>> >>> --Prashant >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Jan 5 09:47:54 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 05 Jan 2015 10:47:54 +0100 Subject: [Freeipa-devel] SSH Public Key - Centralized Solution In-Reply-To: References: <54997906.9000507@redhat.com> Message-ID: <54AA5DCA.5030503@redhat.com> On 12/30/2014 01:57 AM, Prashant Bapat wrote: > Hi Again, > > For enforcing SSH key rotation every N days, I'm thinking the following. > Please let me know if this makes sense. > > 1. Limit the number of keys per user to 2. Control this via the webUI > during they public key upload. > 2. Append the current timestamp to the key during the upload. This gets > stores in LDAP under "ipaSshPubKey" attribute. > 3. Store all the key fingerprints permanently. Need to define a new > attribute for this. Idea is that a ssh key never gets reused. During the > upload verify that the key being uploaded is not already present in the > historical store. > 4. On the clients, use a ForcedCommand in SSH server and verify the > timestamp from #2 above is older than N days. Deny user with a error > message if true, allow if false. On similar lines of http://www.sshark.org/ > > Please let me know your thoughts around this. This is the limiting feature > for us to implement FreeIPA in our org right now. With this design user can simple circumvent the restrictions by performing simple LDAP mod, i.e., avoid Web UI or CLI and therefore any check done by IPA framework. IPA framework is fine for data consistency but not for authentication restrictions. Example: user could have a script which would directly update the timestamp or upload additional SSH Key. Enforcing these restrictions could be solved by a 389 plugin but that requires more work (from my POV). > > Thanks in advance. > > --Prashant > > On 23 December 2014 at 21:39, Prashant Bapat wrote: > >> Adam, >> >> Thanks much for the reply. I will take a look at the code. >> >> For the expiration part, do you think it would be a good idea to modify >> the LDAP schema to include the SSH Pubkey upload date and have a external >> script to scan the keys for their age and alert/remove the keys ? If yes >> could you please give me some pointers on how this can be done ? >> >> Thanks again. >> --Prashant >> >> On 23 December 2014 at 19:45, Adam Young wrote: >>> >>> On 12/22/2014 08:40 PM, Prashant Bapat wrote: >>> >>> Hi, >>> >>> We are planning to roll out FreeIPA for our AWS infrastructure to be >>> the central authentication service. Initially we plan to use the SSH publi >>> keys, user and group management by FreeIPA. We are looking at rolling out >>> the SSS on clients a little later. >>> >>> Two questions. >>> >>> 1. We need to be able to ensure that a user is limited only 2-3 SSH >>> keys. >>> >>> SSH keys are a string attribute with a validator. In order to limit the >>> number, you would need to modify the plugin here: >>> >>> >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/util.py#n310 >>> >>> >>> >>> 2. We need some way of forcing these key rotation once in say 90 days. >>> >>> In our existing setup we use a SSH CA based authentication. It has its >>> own issues. But the rotation is handled by cert expiry every 90 days. >>> >>> >>> This is going to be harder. With password you can validate on login, but >>> there is caching involved with the public key, and I think you would need >>> to take that into account to force invalidation. This is why certs are >>> probably a better idea. >>> >>> Assuming you can flush the public keys fairly regularly, you would want >>> to put the expiration checking on the accessor for the key. This is a >>> direct ldap fetch and not managed by the IPA plugins. >>> >>> >>> Any suggestions/help would be appreciated. >>> >>> Thanks in advance. >>> >>> --Prashant >>> -- Petr Vobornik From mbasti at redhat.com Mon Jan 5 13:15:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 05 Jan 2015 14:15:17 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141215170150.00437756@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> Message-ID: <54AA8E65.7080500@redhat.com> On 15/12/14 23:01, Simo Sorce wrote: > Hello fellow developers, I added this new design: > http://www.freeipa.org/page/V4/Domain_Levels > > It is a prerequisite for both the Replica Promotion design: > http://www.freeipa.org/page/V4/Replica_Promotion > and the Topology plugins design: > http://www.freeipa.org/page/V4/Manage_replication_topology > (Ludwig will change this to include the changes we have discussed in a > previous phone call, and which involve mostly Domain Level/Domain > Upgrades/migrations issues) > > As usual feel free to add as needed or comments and ask questions. > > Simo. > I have a question, how domain levels are related to IPA Upgrade? Will we able to run LDAP update after increasing domain level, if new feature requires some LDAP data modification? Or we just do upgrade as we do now, and new code has to be able to handle data in both new and old way. For example: Forwardzone feature, old "forwardzones" and new forwardzones are not compatible. It requires to change LDAP data, move fake "forwardzones" to new objectclass. This should happen after increasing domain level. Are we able to do that? (In current upgrade, forwardzones are hidden in old replicas, user should use only new replica to add/del/mod forwardzones) Martin^2 -- Martin Basti From simo at redhat.com Mon Jan 5 13:52:38 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 5 Jan 2015 08:52:38 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <54AA8E65.7080500@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54AA8E65.7080500@redhat.com> Message-ID: <20150105085238.3dc8524b@willson.usersys.redhat.com> On Mon, 05 Jan 2015 14:15:17 +0100 Martin Basti wrote: > On 15/12/14 23:01, Simo Sorce wrote: > > Hello fellow developers, I added this new design: > > http://www.freeipa.org/page/V4/Domain_Levels > > > > It is a prerequisite for both the Replica Promotion design: > > http://www.freeipa.org/page/V4/Replica_Promotion > > and the Topology plugins design: > > http://www.freeipa.org/page/V4/Manage_replication_topology > > (Ludwig will change this to include the changes we have discussed > > in a previous phone call, and which involve mostly Domain > > Level/Domain Upgrades/migrations issues) > > > > As usual feel free to add as needed or comments and ask questions. > > > > Simo. > > > I have a question, how domain levels are related to IPA Upgrade? > > Will we able to run LDAP update after increasing domain level, if new > feature requires some LDAP data modification? > > Or we just do upgrade as we do now, and new code has to be able to > handle data in both new and old way. We'll have to be able to work on a range of levels. This means some updates may need to be conditional to the domain level. This also means the tool to raise the level may need to run some updates. I think we may want to start adding a level option at some point in updates, but we'll work it out when we get there I guess. > For example: > Forwardzone feature, old "forwardzones" and new forwardzones are not > compatible. It requires to change LDAP data, move fake "forwardzones" > to new objectclass. We will simply not accept incompatible changes, at least not on mere upgrades, we simply can't. The fact we have in the past has been a team communication failure in my view. > This should happen after increasing domain > level. Are we able to do that? (In current upgrade, forwardzones are > hidden in old replicas, user should use only new replica to > add/del/mod forwardzones) The challenge is in planning changes so that upgrades are not difficult to implement. Every developer MUST (int the RFC sense :-) think what are the consequences of the changes they are proposing/implementing on upgrades. FreeIPA is a distributed system, and people must think in that sense in general. If we corner ourselves in a situation where it is very hard to perform an upgrade that is our own failure. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Jan 5 15:18:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 05 Jan 2015 16:18:49 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <5491900B.8060209@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> <54905A55.5060209@redhat.com> <5491900B.8060209@redhat.com> Message-ID: <54AAAB59.6030101@redhat.com> On 17/12/14 15:15, Martin Basti wrote: > On 16/12/14 17:14, Martin Basti wrote: >> On 15/12/14 20:15, Martin Basti wrote: >>> On 15/12/14 19:18, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/4750 >>>> >>>> Patches need rebase and minor pytest modification to apply on >>>> master, I will do that after review. >>>> >>>> Patches for ipa-4-1 attached. >>>> >>>> >>> I forgot to fix copy paste error. >>> >>> Updated patches attached >>> >> Removed unneeded nsrecord validation in 2 tests >> >> updated patches attached >> > Added: > > * find forward zone with --forward-policy=none (no fwzone exists) > * find forward zone with --forward-policy=only (no fwzone exists) > * find forward zone with --forward-policy=first (no fwzone exists) > * enable enabled zone > * disable disabled zone > > Patches attached. > > Hi Scott, could you ack or nack the patchset, other test tickets are waiting, and we want to avoid huge rebases/merging -- Martin Basti From ayoung at redhat.com Mon Jan 5 15:54:40 2015 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Jan 2015 10:54:40 -0500 Subject: [Freeipa-devel] SSH Public Key - Centralized Solution In-Reply-To: <54AA5DCA.5030503@redhat.com> References: <54997906.9000507@redhat.com> <54AA5DCA.5030503@redhat.com> Message-ID: <54AAB3C0.8090902@redhat.com> On 01/05/2015 04:47 AM, Petr Vobornik wrote: > Enforcing these restrictions could be solved by a 389 plugin but that > requires more work (from my POV). Agreed. I don't think it can be properly done without the 389 plugin. From pspacek at redhat.com Mon Jan 5 16:18:30 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 Jan 2015 17:18:30 +0100 Subject: [Freeipa-devel] DNS forward zone upgrade problem: post-mortem Message-ID: <54AAB956.8000108@redhat.com> Hello, as you may now, me and Martin^2 Basti screwed upgrades from RHEL 6.x to RHEL 7.1+. Cause ===== RHEL 7.1/bind-dyndb-ldap 6.x supports new object class idnsForwardZone and has modified idnsZone object class semantics . This new semantics match what is called "master zones" in BIND terminology. Motivation ========== We have two main reasons for the change: 1) Clearly define (and un-obscure) idnsZone semantics to make implementation of master root zones & global forwarding possible at the same time. 2) Match BIND semantics for master and forward zones, i.e. make all the BIND docs and how-tos applicable to FreeIPA. We had many user-reported problems with forward zone configuration in the past just because the semantics was obscure and ill-defined. Upgrade ======= To make upgrade possible we decided to add support for new idnsForwardZone object class to RHEL 7.0/bind-dyndb-ldap 3.5. This version serves as 'transitional' element between old and new semantics because it supports new object class idnsForwardZone but still expects old semantics on the old object class idnsZone. RHEL 7.1/bind-dyndb-ldap 6.x/FreeIPA 4.x supports new object class and at the same time expects new semantics of the idnsZone object class. FreeIPA upgrade automatically transforms existing data to the new format which is understood by RHEL 7.0. After upgrade, the new idnsZone semantics will stay be unused until user decides to use it so this is covered by "new features will not be available on old servers" clause in our release notes. For some reason nobody realized that RHEL 6.x replicas will never have bind-dyndb-ldap 3.5, i.e. the hybrid version/'transitional' element which helps with upgrade. Solution (for now) ======== I have patched bind-dyndb-ldap 2.x in RHEL 6.x to add support for new idnsForwardZone object class to it: https://bugzilla.redhat.com/show_bug.cgi?id=1175318 Upgrade will work as expected if users install this patched version before introducing RHEL 7.1 to their topology. All the gory details are in the design document: http://www.freeipa.org/page/V4/Forward_zones (Clearly, domain levels would help ...) -- Petr^2 Spacek From mbasti at redhat.com Mon Jan 5 16:35:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 05 Jan 2015 17:35:49 +0100 Subject: [Freeipa-devel] DNS forward zone upgrade problem: post-mortem In-Reply-To: <54AAB956.8000108@redhat.com> References: <54AAB956.8000108@redhat.com> Message-ID: <54AABD65.1040308@redhat.com> On 05/01/15 17:18, Petr Spacek wrote: > Hello, > > as you may now, me and Martin^2 Basti screwed upgrades from RHEL 6.x to RHEL 7.1+. > > Cause > ===== > RHEL 7.1/bind-dyndb-ldap 6.x supports new object class idnsForwardZone and has > modified idnsZone object class semantics . This new semantics match what is > called "master zones" in BIND terminology. > > Motivation > ========== > We have two main reasons for the change: > 1) Clearly define (and un-obscure) idnsZone semantics to make implementation > of master root zones & global forwarding possible at the same time. > > 2) Match BIND semantics for master and forward zones, i.e. make all the BIND > docs and how-tos applicable to FreeIPA. We had many user-reported problems > with forward zone configuration in the past just because the semantics was > obscure and ill-defined. > > Upgrade > ======= > To make upgrade possible we decided to add support for new idnsForwardZone > object class to RHEL 7.0/bind-dyndb-ldap 3.5. This version serves as > 'transitional' element between old and new semantics because it supports new > object class idnsForwardZone but still expects old semantics on the old object > class idnsZone. > > RHEL 7.1/bind-dyndb-ldap 6.x/FreeIPA 4.x supports new object class and at the > same time expects new semantics of the idnsZone object class. > FreeIPA upgrade automatically transforms existing data to the new format which > is understood by RHEL 7.0. > > After upgrade, the new idnsZone semantics will stay be unused until user > decides to use it so this is covered by "new features will not be available on > old servers" clause in our release notes. > > For some reason nobody realized that RHEL 6.x replicas will never have > bind-dyndb-ldap 3.5, i.e. the hybrid version/'transitional' element which > helps with upgrade. > > Solution (for now) > ======== > I have patched bind-dyndb-ldap 2.x in RHEL 6.x to add support for new > idnsForwardZone object class to it: > https://bugzilla.redhat.com/show_bug.cgi?id=1175318 > > Upgrade will work as expected if users install this patched version before > introducing RHEL 7.1 to their topology. > > > All the gory details are in the design document: > http://www.freeipa.org/page/V4/Forward_zones > > (Clearly, domain levels would help ...) > Also this ticket causes troubles https://fedorahosted.org/freeipa/ticket/4818 Current solution doesn't work because new schema was added, before upgrade was executed on replica. For now we need to store flag in LDAP, when forward zones was already migrated. Simo, where is the right place to store this information, DNS container? Or should we use something from domain levels? -- Martin Basti From simo at redhat.com Mon Jan 5 18:01:38 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 5 Jan 2015 13:01:38 -0500 Subject: [Freeipa-devel] DNS forward zone upgrade problem: post-mortem In-Reply-To: <54AABD65.1040308@redhat.com> References: <54AAB956.8000108@redhat.com> <54AABD65.1040308@redhat.com> Message-ID: <20150105130138.51f331f2@willson.usersys.redhat.com> On Mon, 05 Jan 2015 17:35:49 +0100 Martin Basti wrote: > On 05/01/15 17:18, Petr Spacek wrote: > > Hello, > > > > as you may now, me and Martin^2 Basti screwed upgrades from RHEL > > 6.x to RHEL 7.1+. > > > > Cause > > ===== > > RHEL 7.1/bind-dyndb-ldap 6.x supports new object class > > idnsForwardZone and has modified idnsZone object class semantics . > > This new semantics match what is called "master zones" in BIND > > terminology. > > > > Motivation > > ========== > > We have two main reasons for the change: > > 1) Clearly define (and un-obscure) idnsZone semantics to make > > implementation of master root zones & global forwarding possible at > > the same time. > > > > 2) Match BIND semantics for master and forward zones, i.e. make all > > the BIND docs and how-tos applicable to FreeIPA. We had many > > user-reported problems with forward zone configuration in the past > > just because the semantics was obscure and ill-defined. > > > > Upgrade > > ======= > > To make upgrade possible we decided to add support for new > > idnsForwardZone object class to RHEL 7.0/bind-dyndb-ldap 3.5. This > > version serves as 'transitional' element between old and new > > semantics because it supports new object class idnsForwardZone but > > still expects old semantics on the old object class idnsZone. > > > > RHEL 7.1/bind-dyndb-ldap 6.x/FreeIPA 4.x supports new object class > > and at the same time expects new semantics of the idnsZone object > > class. FreeIPA upgrade automatically transforms existing data to > > the new format which is understood by RHEL 7.0. > > > > After upgrade, the new idnsZone semantics will stay be unused until > > user decides to use it so this is covered by "new features will not > > be available on old servers" clause in our release notes. > > > > For some reason nobody realized that RHEL 6.x replicas will never > > have bind-dyndb-ldap 3.5, i.e. the hybrid version/'transitional' > > element which helps with upgrade. > > > > Solution (for now) > > ======== > > I have patched bind-dyndb-ldap 2.x in RHEL 6.x to add support for > > new idnsForwardZone object class to it: > > https://bugzilla.redhat.com/show_bug.cgi?id=1175318 > > > > Upgrade will work as expected if users install this patched version > > before introducing RHEL 7.1 to their topology. > > > > > > All the gory details are in the design document: > > http://www.freeipa.org/page/V4/Forward_zones > > > > (Clearly, domain levels would help ...) > > > > Also this ticket causes troubles > https://fedorahosted.org/freeipa/ticket/4818 > > Current solution doesn't work because new schema was added, before > upgrade was executed on replica. > For now we need to store flag in LDAP, when forward zones was already > migrated. > > Simo, where is the right place to store this information, DNS > container? Or should we use something from domain levels? A ipaConfigString option is probably fine for this. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue Jan 6 02:26:59 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 05 Jan 2015 21:26:59 -0500 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <1416499988.2902.11.camel@redhat.com> References: <1416499988.2902.11.camel@redhat.com> Message-ID: <1420511219.3049.11.camel@redhat.com> On Thu, 2014-11-20 at 11:13 -0500, Nathaniel McCallum wrote: > This tests the general workflow for OTP including most possible > token combinations. This includes 5872 tests. Further optimization > is possible to reduce the number of duplicate tests run. > > Things not yet tested: > * ipa-kdb > * ipa-otpd > * otptoken-sync > * RADIUS proxy > * token self-management > * type specific attributes Attached is the latest iteration of the OTP test work. This now includes all major cases except token self-management and RADIUS proxy (which will come in its own patch). Token self-management is held up by the fact that I can't get alternate ccaches to work with the API. I have tried kinit-ing to an independent ccache and exporting KRB5CCNAME, but this doesn't work for some reason I can't figure out. I ended up creating my own fixture mechanism. I'm not in love with it, but it is simple and at least gets the scoping correct. It also generates individual tests for each parameterized state, so the output is both correct and obvious. I also implemented OTP myself. This isn't much code, but pyotp has a major bug and is dead upstream. I'd like to migrate to python-cryptography when it lands as a dependency of FreeIPA. But due to timing issues, we can't land it now. This will be a small patch in the future. Even with the caveats above, I feel like the test coverage provided by this test is worth review/merge. As a rough estimate, I think this is about 70% code coverage. Of the remaining coverage, I see: * RADIUS proxy - 10% * token self-management - 10% * misc testable - 5% * misc untestable - 5% All tests in this patch succeed on 4.1.2. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0081.1-Add-initial-tests-for-OTP.patch Type: text/x-patch Size: 18299 bytes Desc: not available URL: From mbasti at redhat.com Tue Jan 6 07:54:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 06 Jan 2015 08:54:19 +0100 Subject: [Freeipa-devel] DNS forward zone upgrade problem: post-mortem In-Reply-To: <20150105130138.51f331f2@willson.usersys.redhat.com> References: <54AAB956.8000108@redhat.com> <54AABD65.1040308@redhat.com> <20150105130138.51f331f2@willson.usersys.redhat.com> Message-ID: <54AB94AB.6020704@redhat.com> On 05/01/15 19:01, Simo Sorce wrote: > On Mon, 05 Jan 2015 17:35:49 +0100 > Martin Basti wrote: > >> On 05/01/15 17:18, Petr Spacek wrote: >>> Hello, >>> >>> as you may now, me and Martin^2 Basti screwed upgrades from RHEL >>> 6.x to RHEL 7.1+. >>> >>> Cause >>> ===== >>> RHEL 7.1/bind-dyndb-ldap 6.x supports new object class >>> idnsForwardZone and has modified idnsZone object class semantics . >>> This new semantics match what is called "master zones" in BIND >>> terminology. >>> >>> Motivation >>> ========== >>> We have two main reasons for the change: >>> 1) Clearly define (and un-obscure) idnsZone semantics to make >>> implementation of master root zones & global forwarding possible at >>> the same time. >>> >>> 2) Match BIND semantics for master and forward zones, i.e. make all >>> the BIND docs and how-tos applicable to FreeIPA. We had many >>> user-reported problems with forward zone configuration in the past >>> just because the semantics was obscure and ill-defined. >>> >>> Upgrade >>> ======= >>> To make upgrade possible we decided to add support for new >>> idnsForwardZone object class to RHEL 7.0/bind-dyndb-ldap 3.5. This >>> version serves as 'transitional' element between old and new >>> semantics because it supports new object class idnsForwardZone but >>> still expects old semantics on the old object class idnsZone. >>> >>> RHEL 7.1/bind-dyndb-ldap 6.x/FreeIPA 4.x supports new object class >>> and at the same time expects new semantics of the idnsZone object >>> class. FreeIPA upgrade automatically transforms existing data to >>> the new format which is understood by RHEL 7.0. >>> >>> After upgrade, the new idnsZone semantics will stay be unused until >>> user decides to use it so this is covered by "new features will not >>> be available on old servers" clause in our release notes. >>> >>> For some reason nobody realized that RHEL 6.x replicas will never >>> have bind-dyndb-ldap 3.5, i.e. the hybrid version/'transitional' >>> element which helps with upgrade. >>> >>> Solution (for now) >>> ======== >>> I have patched bind-dyndb-ldap 2.x in RHEL 6.x to add support for >>> new idnsForwardZone object class to it: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1175318 >>> >>> Upgrade will work as expected if users install this patched version >>> before introducing RHEL 7.1 to their topology. >>> >>> >>> All the gory details are in the design document: >>> http://www.freeipa.org/page/V4/Forward_zones >>> >>> (Clearly, domain levels would help ...) >>> >> Also this ticket causes troubles >> https://fedorahosted.org/freeipa/ticket/4818 >> >> Current solution doesn't work because new schema was added, before >> upgrade was executed on replica. >> For now we need to store flag in LDAP, when forward zones was already >> migrated. >> >> Simo, where is the right place to store this information, DNS >> container? Or should we use something from domain levels? > A ipaConfigString option is probably fine for this. > > Simo. > Thanks. -- Martin Basti From pvoborni at redhat.com Tue Jan 6 12:17:03 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Jan 2015 13:17:03 +0100 Subject: [Freeipa-devel] Modifying ID Range In-Reply-To: <20150105084103.GC23112@localhost.localdomain> References: <20150105084103.GC23112@localhost.localdomain> Message-ID: <54ABD23F.8000608@redhat.com> On 01/05/2015 09:41 AM, Sumit Bose wrote: > On Wed, Dec 24, 2014 at 08:50:29AM +0530, Prashant Bapat wrote: >> Hi, >> >> What I'm trying to do is to modify the Range FreeIPA uses. I removed the >> random Range Id created during install, added a new range that I wanted. >> But problem is when I try to add a new user or a group now its still using >> the old range that was created during installation. >> >> I tried restarting the ipa service but still no help. >> >> Any pointers to this will be appreciated. > > sorry, ID ranges changes at runtime are currently not supported because > of the implications on the running system, e.g. users might not be able > to access their home directory anymore. > > To use the new range the easiest way is to remove the SSSD cache on all > systems, i.e. systemctl stop sssd.server; rm /var/lib/sssd/db/cache_* ; > systemctl start sssd.service. Please note that with this scheme you will > loose the cached password, i.e. offline authentication might fail if the > given users hasn't logged in successfully after the cache was removed. > > HTH > I think a confusion comes from a fact that IPA has "ID range" objects which look like that they could be used for configuration of DNA plugin[1]. IIUC that's not the case - ID range object are for managining rids for trusts [2]. The only way how to change UID allocation is to manually modify DNA plugin configuration - 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' entry + related object defined in dnaSharedCfgDN. CLI's `ipa help idrange` contains this information. Maybe we should also consider adding this info to idrange-mod --help command and also to Web UI to prevent future confusions. Another approach is to raise "This change does not affect UID allocation. It has to be done in DNA plugin configuration." warning when modifying base id or a size of a local IPA range. Such warning would be visible in both CLI and Web UI. [1] http://directory.fedoraproject.org/docs/389ds/design/dna-plugin.html [2] http://www.freeipa.org/page/V3/ID_Ranges -- Petr Vobornik From pviktori at redhat.com Tue Jan 6 14:49:24 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 06 Jan 2015 15:49:24 +0100 Subject: [Freeipa-devel] [PATCHES] 0684-0687 Use tracker fixture in host plugin tests Message-ID: <54ABF5F4.3060506@redhat.com> The first patch enables pylint to run on tests. Some of the exceptions I've added are pretty heavy-handed, but the main thing I wanted to enable is checking for duplicate test function/method names, since in that case the earlier test is silently dropped. I dropped support for old pylint while I was at it. The other three patches show how one might go around modernizing one of our Declarative test suites. There are some dead ends in the first patch that are removed subsequently; if you squash the patches together they might be easier to review. See the commit messages for what the patches do. The HostTracker should generalize well to other objects. With Service or DNS trackers some of the host tests can be simplified even more. To check that tests are independent, you can use the order-randomizing plugin for pytest (which is not in Fedora yet): pip install --user pytest-random ./make-test ipatests/test_xmlrpc/test_host_plugin.py -v --random (Note that this takes a lot of time as fixtures are created and re-created ? independent tests are mainly useful for selecting *subsets* of tests.) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0684-Run-pylint-on-tests.patch Type: text/x-patch Size: 19653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0685-test_host_plugin-Convert-tests-to-imperative-style.patch Type: text/x-patch Size: 116600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0686-test_host_plugin-Split-tests-into-independent-classe.patch Type: text/x-patch Size: 17385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0687-test_host_plugin-Use-HostTracker-fixtures.patch Type: text/x-patch Size: 95296 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 6 17:14:17 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Jan 2015 18:14:17 +0100 Subject: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type In-Reply-To: <1418928747.5774.24.camel@redhat.com> References: <1415898295.9116.12.camel@redhat.com> <547F37D3.6040701@redhat.com> <1417717539.3111.6.camel@redhat.com> <5480AE4D.2000800@redhat.com> <1418928747.5774.24.camel@redhat.com> Message-ID: <54AC17E9.3080803@redhat.com> On 12/18/2014 07:52 PM, Nathaniel McCallum wrote: > On Thu, 2014-12-04 at 19:56 +0100, Petr Vobornik wrote: >> On 12/04/2014 07:25 PM, Nathaniel McCallum wrote: >>> On Wed, 2014-12-03 at 17:18 +0100, Petr Vobornik wrote: >>>> On 13.11.2014 18:04, Nathaniel McCallum wrote: >>>>> Additionally, fix a small bug in ipa-kdb so that the disabled User >>>>> Auth Type is properly handled. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4720 >>>>> >>>> >>>> The patch itself looks good to me, VERSION needs to be updated though. >>>> >>>> But I don't think it works. Don't know why. In my setup, user's config >>>> was not ignored. >>>> >>>> When I tested login in Web UI with: >>>> >>>> - global config: disabled, otp >>>> - user fbar's config: password >>>> - fbar had an hotp token assigned >>>> >>>> I could still login with password and not with otp. If I added 'otp' to >>>> fbar's config, I could also login with otp. >>> >>> How are you logging in? krb5 or LDAP bind? >>> >> >> Forms-based in Web UI. It uses kinit internally. > > Alright, I was able to reproduce this problem via a bisect. I think you > hit a bug that was introduced in > 953c6846b7cb8d75253538ab92a1360fceee0c3c and fixed by > 9baa93da1cbf56c2a6f7e82e099bc3ff3f19e2e4. Those patches existed in my > local branch as one patchset, but was merged in two sections. > Unfortunately, though I had discovered and fixed the bug, the fix went > in the wrong patch in the series. So you just happened to hit the narrow > window where the bug existed in master (but not my local tree). On > current master, everything works. > > I also tested on 4.1.2. A similar bug exists there on the old > ipa-pwd-extop code. So if we want to land this patch on 4.1.x, we will > need a fix for that code to avoid creating a security hole. > > Attached is a rebased patch. It has no changes except the VERSION > update. > > Nathaniel > tested on both master and ipa-4-1. I no longer see the issue. What is the issue which exists on 4-1 branch? The fix [1] which should have fixed master was also pushed to 4-1... [1] https://fedorahosted.org/freeipa/ticket/4511#comment:11 -- Petr Vobornik From pspacek at redhat.com Wed Jan 7 09:34:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 07 Jan 2015 10:34:59 +0100 Subject: [Freeipa-devel] Reviewed-By for design pages? Message-ID: <54ACFDC3.5080001@redhat.com> Hello, I wonder if we should add something like Reviewed-by tag to newly created design pages. It would serve as reminder and check that page was really reviewed by someone. (And that we should not spend much time on implementation before the tag is present on the page.) It will also add 'psychological pressure' to the reviewer because his name will be on the design page forever :-) -- Petr^2 Spacek From dkupka at redhat.com Wed Jan 7 11:27:41 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 07 Jan 2015 12:27:41 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. Message-ID: <54AD182D.2050803@redhat.com> https://fedorahosted.org/freeipa/ticket/4249 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0035-client-Update-DNS-with-all-available-local-IP-addres.patch Type: text/x-patch Size: 5215 bytes Desc: not available URL: From mbasti at redhat.com Wed Jan 7 12:56:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 07 Jan 2015 13:56:12 +0100 Subject: [Freeipa-devel] [PATCHES 180-181] Fix forwardzone update Message-ID: <54AD2CEC.6040906@redhat.com> https://fedorahosted.org/freeipa/ticket/4818 Patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0180-Fix-Upgrade-forwardzones-zones-after-adding-newer-re.patch Type: text/x-patch Size: 7278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0181-Fix-zone-find-during-forwardzone-upgrade.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 7 14:12:19 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Jan 2015 09:12:19 -0500 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54AD182D.2050803@redhat.com> References: <54AD182D.2050803@redhat.com> Message-ID: <54AD3EC3.8030207@redhat.com> David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4249 > Rather than scraping the output of ip is the python-netifaces package a viable alternative? Yes it adds another dep, and I'm not sure it is available for all platforms, but it makes the client less dependent upon output format changes in a cli utility. rob From dkupka at redhat.com Wed Jan 7 14:20:38 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 07 Jan 2015 15:20:38 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54AD3EC3.8030207@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD3EC3.8030207@redhat.com> Message-ID: <54AD40B6.2090606@redhat.com> On 01/07/2015 03:12 PM, Rob Crittenden wrote: > David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4249 >> > > Rather than scraping the output of ip is the python-netifaces package a > viable alternative? Yes it adds another dep, and I'm not sure it is > available for all platforms, but it makes the client less dependent upon > output format changes in a cli utility. > > rob > Yes, it would be much better and I originally wanted to use it. But it isn't available on all platforms that FreeIPA runs on. -- David Kupka From mbasti at redhat.com Wed Jan 7 15:15:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 07 Jan 2015 16:15:29 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54AD182D.2050803@redhat.com> References: <54AD182D.2050803@redhat.com> Message-ID: <54AD4D91.3020101@redhat.com> On 07/01/15 12:27, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4249 Thank you for patch: 1) - root_logger.error("Cannot update DNS records! " - "Failed to connect to server '%s'.", server) + ips = get_local_ipaddresses() + except CalledProcessError as e: + root_logger.error("Cannot update DNS records. %s" % e) IMO the error message should be more specific, add there something like "Unable to get local IP addresses". at least in log.debug() 2) + lines = ipresult[0].replace('\\', '').split('\n') .replace() is not needed 3) + if len(ips) == 0: if not ips: is more pythonic by PEP8 -- Martin Basti From simo at redhat.com Wed Jan 7 15:38:51 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 7 Jan 2015 10:38:51 -0500 Subject: [Freeipa-devel] Reviewed-By for design pages? In-Reply-To: <54ACFDC3.5080001@redhat.com> References: <54ACFDC3.5080001@redhat.com> Message-ID: <20150107103851.2dfa2fe1@willson.usersys.redhat.com> On Wed, 07 Jan 2015 10:34:59 +0100 Petr Spacek wrote: > Hello, > > I wonder if we should add something like Reviewed-by tag to newly > created design pages. It would serve as reminder and check that page > was really reviewed by someone. (And that we should not spend much > time on implementation before the tag is present on the page.) > > It will also add 'psychological pressure' to the reviewer because his > name will be on the design page forever :-) > +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Wed Jan 7 16:11:53 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 07 Jan 2015 17:11:53 +0100 Subject: [Freeipa-devel] topology management question In-Reply-To: <20141211092024.5449a932@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> Message-ID: <54AD5AC9.5040103@redhat.com> >>>> Now, with some effort this can be resolved, eg >>>> if the server is removed, keep it internally as removed server and >>>> for segments connecting this server trigger removal of replication >>>> agreements or mark a the last segment, when tried to remove, as >>>> pending and once the server is removed also remove the >>>> corresponding repl agreements >>> Why should we "keep it internally" ? >>> If you mark the agreements as managed by setting an attribute on >>> them, then you will never have any issue recognizing a "managed" >>> agreement in cn=config, and you will also immediately find out it >>> is "old" as it is not backed by a segment so you will safely remove >>> it. >> I didn't want to add new flags/fields to the replication agreements >> as long as anything can be handled by the data in the shared tree. > We have too. I think it is a must or we will find numerous corner cases. > Is there a specific reason why you do not want to add flags to > replication agreements in cn=config ? Simo and I had a discussion on this and had agreed that the "marking" of a replication agreement as controlled by the plugin could be done by a naming convention on the replication agreements. They are originally created as "cn=meTo,..." and would be renamed to something like "cn=-to-,....." avoiding to add a new attribute to the repl agreement schema. Unfortunately this does not work out of the box. I only discovered afetr implementing and testing (was not aware of before :-) that DS does not implement modrdn operation for internal backends, It just returns unwilling_to_perform. And if it will be implemented the replication plugin will have to be changed as well to catch the mordrdn to update the in memory objects with the new name (which is used in logging). So, if there is no objection, I will go back to the "flag" solution. > > From simo at redhat.com Wed Jan 7 16:13:28 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 7 Jan 2015 11:13:28 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54AD5AC9.5040103@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> Message-ID: <20150107111328.2d8ba9ca@willson.usersys.redhat.com> On Wed, 07 Jan 2015 17:11:53 +0100 Ludwig Krispenz wrote: > > >>>> Now, with some effort this can be resolved, eg > >>>> if the server is removed, keep it internally as removed server > >>>> and for segments connecting this server trigger removal of > >>>> replication agreements or mark a the last segment, when tried to > >>>> remove, as pending and once the server is removed also remove the > >>>> corresponding repl agreements > >>> Why should we "keep it internally" ? > >>> If you mark the agreements as managed by setting an attribute on > >>> them, then you will never have any issue recognizing a "managed" > >>> agreement in cn=config, and you will also immediately find out it > >>> is "old" as it is not backed by a segment so you will safely > >>> remove it. > >> I didn't want to add new flags/fields to the replication agreements > >> as long as anything can be handled by the data in the shared tree. > > We have too. I think it is a must or we will find numerous corner > > cases. Is there a specific reason why you do not want to add flags > > to replication agreements in cn=config ? > Simo and I had a discussion on this and had agreed that the "marking" > of a replication agreement > as controlled by the plugin could be done by a naming convention on > the replication agreements. > They are originally created as "cn=meTo,..." and would > be renamed to something like > "cn=-to-,....." avoiding to add a new > attribute to the repl agreement schema. > > Unfortunately this does not work out of the box. I only discovered > afetr implementing and testing (was not aware of before :-) > that DS does not implement modrdn operation for internal backends, It > just returns unwilling_to_perform. > And if it will be implemented the replication plugin will have to be > changed as well to catch the mordrdn to update the in memory > objects with the new name (which is used in logging). > > So, if there is no objection, I will go back to the "flag" solution. What about simply deleting the agreement and adding it back with the new name ? This way you avoid having to deal with modrdn. Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Wed Jan 7 16:23:08 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 07 Jan 2015 17:23:08 +0100 Subject: [Freeipa-devel] topology management question In-Reply-To: <20150107111328.2d8ba9ca@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> <20150107111328.2d8ba9ca@willson.usersys.redhat.com> Message-ID: <54AD5D6C.1090909@redhat.com> On 01/07/2015 05:13 PM, Simo Sorce wrote: > On Wed, 07 Jan 2015 17:11:53 +0100 > Ludwig Krispenz wrote: > >>>>>> Now, with some effort this can be resolved, eg >>>>>> if the server is removed, keep it internally as removed server >>>>>> and for segments connecting this server trigger removal of >>>>>> replication agreements or mark a the last segment, when tried to >>>>>> remove, as pending and once the server is removed also remove the >>>>>> corresponding repl agreements >>>>> Why should we "keep it internally" ? >>>>> If you mark the agreements as managed by setting an attribute on >>>>> them, then you will never have any issue recognizing a "managed" >>>>> agreement in cn=config, and you will also immediately find out it >>>>> is "old" as it is not backed by a segment so you will safely >>>>> remove it. >>>> I didn't want to add new flags/fields to the replication agreements >>>> as long as anything can be handled by the data in the shared tree. >>> We have too. I think it is a must or we will find numerous corner >>> cases. Is there a specific reason why you do not want to add flags >>> to replication agreements in cn=config ? >> Simo and I had a discussion on this and had agreed that the "marking" >> of a replication agreement >> as controlled by the plugin could be done by a naming convention on >> the replication agreements. >> They are originally created as "cn=meTo,..." and would >> be renamed to something like >> "cn=-to-,....." avoiding to add a new >> attribute to the repl agreement schema. >> >> Unfortunately this does not work out of the box. I only discovered >> afetr implementing and testing (was not aware of before :-) >> that DS does not implement modrdn operation for internal backends, It >> just returns unwilling_to_perform. >> And if it will be implemented the replication plugin will have to be >> changed as well to catch the mordrdn to update the in memory >> objects with the new name (which is used in logging). >> >> So, if there is no objection, I will go back to the "flag" solution. > What about simply deleting the agreement and adding it back with the > new name ? it will stop replication and the restart it again, unnecessary interrupting replication for some time. Assume you have a working topology and then raise the domain level and the plugin becomes active, creates segments and "marks" agreements as controlled. This should happen as smooth as possible. > > This way you avoid having to deal with modrdn. > > Simo. > From simo at redhat.com Wed Jan 7 16:35:07 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 7 Jan 2015 11:35:07 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54AD5D6C.1090909@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> <20150107111328.2d8ba9ca@willson.usersys.redhat.com> <54AD5D6C.1090909@redhat.com> Message-ID: <20150107113507.1db2283f@willson.usersys.redhat.com> On Wed, 07 Jan 2015 17:23:08 +0100 Ludwig Krispenz wrote: > > On 01/07/2015 05:13 PM, Simo Sorce wrote: > > On Wed, 07 Jan 2015 17:11:53 +0100 > > Ludwig Krispenz wrote: > > > >>>>>> Now, with some effort this can be resolved, eg > >>>>>> if the server is removed, keep it internally as removed server > >>>>>> and for segments connecting this server trigger removal of > >>>>>> replication agreements or mark a the last segment, when tried > >>>>>> to remove, as pending and once the server is removed also > >>>>>> remove the corresponding repl agreements > >>>>> Why should we "keep it internally" ? > >>>>> If you mark the agreements as managed by setting an attribute on > >>>>> them, then you will never have any issue recognizing a "managed" > >>>>> agreement in cn=config, and you will also immediately find out > >>>>> it is "old" as it is not backed by a segment so you will safely > >>>>> remove it. > >>>> I didn't want to add new flags/fields to the replication > >>>> agreements as long as anything can be handled by the data in the > >>>> shared tree. > >>> We have too. I think it is a must or we will find numerous corner > >>> cases. Is there a specific reason why you do not want to add flags > >>> to replication agreements in cn=config ? > >> Simo and I had a discussion on this and had agreed that the > >> "marking" of a replication agreement > >> as controlled by the plugin could be done by a naming convention on > >> the replication agreements. > >> They are originally created as "cn=meTo,..." and would > >> be renamed to something like > >> "cn=-to-,....." avoiding to add a new > >> attribute to the repl agreement schema. > >> > >> Unfortunately this does not work out of the box. I only discovered > >> afetr implementing and testing (was not aware of before :-) > >> that DS does not implement modrdn operation for internal backends, > >> It just returns unwilling_to_perform. > >> And if it will be implemented the replication plugin will have to > >> be changed as well to catch the mordrdn to update the in memory > >> objects with the new name (which is used in logging). > >> > >> So, if there is no objection, I will go back to the "flag" > >> solution. > > What about simply deleting the agreement and adding it back with the > > new name ? > it will stop replication and the restart it again, unnecessary > interrupting replication for some time. > Assume you have a working topology and then raise the domain level > and the plugin becomes active, > creates segments and "marks" agreements as controlled. This should > happen as smooth as > possible. While this is true, it is also a rare operation. I do not see it as a big deal to be honest. However if you prefer to add a flag attribute that is fine by me too. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Jan 7 16:41:21 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 7 Jan 2015 18:41:21 +0200 Subject: [Freeipa-devel] Reviewed-By for design pages? In-Reply-To: <20150107103851.2dfa2fe1@willson.usersys.redhat.com> References: <54ACFDC3.5080001@redhat.com> <20150107103851.2dfa2fe1@willson.usersys.redhat.com> Message-ID: <20150107164121.GL16288@redhat.com> On Wed, 07 Jan 2015, Simo Sorce wrote: >On Wed, 07 Jan 2015 10:34:59 +0100 >Petr Spacek wrote: > >> Hello, >> >> I wonder if we should add something like Reviewed-by tag to newly >> created design pages. It would serve as reminder and check that page >> was really reviewed by someone. (And that we should not spend much >> time on implementation before the tag is present on the page.) >> >> It will also add 'psychological pressure' to the reviewer because his >> name will be on the design page forever :-) >> > >+1 +1 too. -- / Alexander Bokovoy From simo at redhat.com Wed Jan 7 20:17:57 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 7 Jan 2015 15:17:57 -0500 Subject: [Freeipa-devel] [PATCH] Fix potential segfault in kdb driver Message-ID: <20150107151757.1aa61cb5@willson.usersys.redhat.com> This patch should fix ticket #4810 I've not been able to reproduce the issue and therefore reliably test this was the only issue, but the backtrace in the original bugzilla was clear enough to point at the fix in this patch. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-518-1-Avoid-calling-ldap-functions-without-a-context.patch Type: text/x-patch Size: 1930 bytes Desc: not available URL: From mbasti at redhat.com Thu Jan 8 08:43:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 08 Jan 2015 09:43:35 +0100 Subject: [Freeipa-devel] [PATCH 0177] Fix adding (warning) messages on client side In-Reply-To: <54901FB7.40900@redhat.com> References: <5487102F.10806@redhat.com> <54896FBF.7010204@redhat.com> <54897C72.90401@redhat.com> <549017D5.30909@redhat.com> <54901EDA.3060601@redhat.com> <54901FB7.40900@redhat.com> Message-ID: <54AE4337.2040804@redhat.com> On 16/12/14 13:04, Martin Basti wrote: > On 16/12/14 13:00, Martin Kosek wrote: >> On 12/16/2014 12:30 PM, Martin Basti wrote: >>> On 11/12/14 12:13, Martin Basti wrote: >>>> On 11/12/14 11:19, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 9.12.2014 v 16:07 Martin Basti napsal(a): >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4793 >>>>>> >>>>>> I'm able to reproduce it only in one nose test. >>>>> Which test? >>>> If you apply my patch 170 and add a random forwardzone, then DNS >>>> root zone >>>> tests failed. >>>>>> Patch attached. >>>>> What about: >>>>> >>>>> result['messages'] = result.get('messages', ()) + >>>>> (message.to_dict(),) >>>>> >>>>> (My point is, don't support both lists and tuples, pick just one.) >>>>> >>>>> Honza >>>>> >>>> This is question for framework guru (you?), I tried to preserve format >>>> unchanged. >>>> Shouldn't be all values in lists in server part? >>>> >>>> Martin^2 >>>> >>> As was requested, I convert tuple to list instead handling both types. >>> >>> Updated patch attached. >> I assume you do not want to track the .idea/ files in FreeIPA git :-) >> > Oh, thanks. My IDE was too smart again and add those files there itself. > > updated patch attached > Please review this patch. -- Martin Basti From mkosek at redhat.com Thu Jan 8 10:57:26 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Jan 2015 11:57:26 +0100 Subject: [Freeipa-devel] [PATCH] Fix potential segfault in kdb driver In-Reply-To: <20150107151757.1aa61cb5@willson.usersys.redhat.com> References: <20150107151757.1aa61cb5@willson.usersys.redhat.com> Message-ID: <54AE6296.6070804@redhat.com> On 01/07/2015 09:17 PM, Simo Sorce wrote: > > This patch should fix ticket #4810 > I've not been able to reproduce the issue and therefore reliably test > this was the only issue, but the backtrace in the original bugzilla was > clear enough to point at the fix in this patch. > > HTH, > Simo. Yup, this patch was also verified by RHEL downstream QE that the issue no longer occurs. So ACK from me. Pushed to: master: 730b472db123e97a0c158b626e9f7c3f0b13e2ca ipa-4-1: 7a901060d3e9a23e44cb4b5c84ad436e4db49ea2 Martin From simo at redhat.com Thu Jan 8 14:19:30 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 8 Jan 2015 09:19:30 -0500 Subject: [Freeipa-devel] [PATCH] 519 - Fix SELinux issue with upgrades Message-ID: <20150108091930.0275b12d@willson.usersys.redhat.com> Attached patch fixes an upgrade issue with mismatched SELinux labels (see commit comment). Fixes ticket #4815 Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-519-1-Remove-the-removal-of-the-ccache.patch Type: text/x-patch Size: 1322 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jan 8 14:39:28 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 08 Jan 2015 15:39:28 +0100 Subject: [Freeipa-devel] ipalib as RPC client in Web UI CI tests, forms-based auth in ipalib Message-ID: <54AE96A0.5090508@redhat.com> Hello, tl;dr; I want to add forms based auth in ipalib's rpc client and use method 2.e) for API configuration. Will be used in otp tests (ipa-4-1 upstream). Want to know if you are OK with it. PoC implementation attached. == Background == I want to call FreeIPA API from our Web UI CI tests. Uses case are: * speed up data preparation (the biggest time consumer in Web UI tests) * prepare data or do stuff which could not be done in Web UI (little bit part of https://fedorahosted.org/freeipa/ticket/4772) For this task I want to reuse ipalib's rpcclient to avoid yet another RPC client implementation. Plan is to use it in OTP web ui tests. == ipalib limitations == Please note that web ui tests could be run as a normal user on a machine which is not a FreeIPA client, i.e. on developers machine with local browser to observe the progress. === 1 Forms based authentication === ipalib doesn't support forms-based auth and kerberos might not be available. I have investigated the option to add forms auth and managed to write a PoC patch(attached) which enables it. Question is whether we want to allow it in ipalib even for non-test uses cases. I think it could be beneficial for some users. === 2 API/environment finalization in ipalib/__init__.py for tests === Tests which are run by make-test are initialized with os.environ['IPA_UNIT_TEST_MODE'] = 'cli_test' in such case, ipalib automatically finalizes API. Unfortunately the default configuration is unusable if run on a machine without IPA configuration files (~/.ipa/default.conf, /etc/ipa/default.conf, ...). We can't even supply the values afterwards because api.env is 'set-once' object. There are several approaches which could be taken: Proper fixes: a) Finish the idea, mentioned in Registry, of storing plugin registrations to allow multiple API creation with all plugins and therefore custom instances of API. Would be probably quite a lot of work because of wide use of global api object. I.e., various test can use their own instance of api. b) Remove the API initialization in ipalib/__init__.py. Initialize API only in tests which use it. Without a) It might suffer from the same issue as d) c) Remove 'set-once' constraint from Env object to allow config change after API initialization Workarounds: d) Change the os.env variable to a different than 'cli_test' value before api import in uidriver.py to prevent the automatic initialization. Init api in Web UI tests. Might cause issues if other tests were run and initialized api before Web ui tests. e) override values in Env object by a hack: object.__setattr__(api.env, key, val) api.env._Env__d[key] = val Advantage is that it's self-contained in Web UI tests. Must be changed back at the end of test not to interfere with other tests. f) require IPA configuration file even on non-ipa client machines. Easy, but not very pleasant for user - all required configuration values are already present in webui test config file or in env variables -> multiple files has to be changed when switching between testing instances(frequent use case). g) other From longer perspective I would like to see a) and b), maybe c). But I would like to use this feature in otptests which should land in 4.1 -> a) is not an option because of its complexity. Therefore, atm, I would like to go with e) or c) Thanks -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0739-webui-tests-support-direct-IPA-API-calls.patch Type: text/x-patch Size: 5523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0738-rpc-client-add-forms-based-auth-support.patch Type: text/x-patch Size: 17972 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 8 14:55:22 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Jan 2015 15:55:22 +0100 Subject: [Freeipa-devel] [PATCH] 519 - Fix SELinux issue with upgrades In-Reply-To: <20150108091930.0275b12d@willson.usersys.redhat.com> References: <20150108091930.0275b12d@willson.usersys.redhat.com> Message-ID: <54AE9A5A.2060308@redhat.com> On 01/08/2015 03:19 PM, Simo Sorce wrote: > > Attached patch fixes an upgrade issue with mismatched SELinux labels > (see commit comment). > > Fixes ticket #4815 > > Simo. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me. I tested this change myself, it was also confirmed by RHEL downstream testing as well. I know Alexander did not like this change very much (https://bugzilla.redhat.com/show_bug.cgi?id=1164896#c55), but it is the best option we have so far and which we can use to fix these upgrade issues. So ACK from me. Pushed to: master: 4f1fdc8f70c1efdb6c6074181d3ecbcb45df001e ipa-4-1: 2d2230e56bff1ca8f863aa07bff2c891fca6dab4 ipa-4-0: 30a0203442f3ebbb638fab19820dc3274f82ae7d Martin From pspacek at redhat.com Thu Jan 8 15:42:55 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Jan 2015 16:42:55 +0100 Subject: [Freeipa-devel] [PATCHES 180-181] Fix forwardzone update In-Reply-To: <54AD2CEC.6040906@redhat.com> References: <54AD2CEC.6040906@redhat.com> Message-ID: <54AEA57F.2070106@redhat.com> On 7.1.2015 13:56, Martin Basti wrote: > + for config_option in container_entry.get("ipaConfigString", []): > + matched = re.match(r"^DNSVersion\s+(?P%d)$", %d is C-ishm which does not work > + config_option, flags=re.I) > + if matched and matched.group("version") >= 1: group("version") should be converted to int before comparison Otherwise it seems that zone update itself works flawlessly for me. HUGE NACK :-D -- Petr^2 Spacek From mbasti at redhat.com Thu Jan 8 15:53:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 08 Jan 2015 16:53:08 +0100 Subject: [Freeipa-devel] [PATCHES 180-181] Fix forwardzone update In-Reply-To: <54AEA57F.2070106@redhat.com> References: <54AD2CEC.6040906@redhat.com> <54AEA57F.2070106@redhat.com> Message-ID: <54AEA7E4.6050204@redhat.com> On 08/01/15 16:42, Petr Spacek wrote: > On 7.1.2015 13:56, Martin Basti wrote: >> + for config_option in container_entry.get("ipaConfigString", []): >> + matched = re.match(r"^DNSVersion\s+(?P%d)$", > %d is C-ishm which does not work > >> + config_option, flags=re.I) >> + if matched and matched.group("version") >= 1: > group("version") should be converted to int before comparison > > Otherwise it seems that zone update itself works flawlessly for me. > > HUGE NACK :-D > Stupid me. Updated patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0180.2-Fix-Upgrade-forwardzones-zones-after-adding-newer-re.patch Type: text/x-patch Size: 7283 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0181.2-Fix-zone-find-during-forwardzone-upgrade.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From jcholast at redhat.com Thu Jan 8 16:04:51 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 08 Jan 2015 17:04:51 +0100 Subject: [Freeipa-devel] [PATCH] 386 Fix CA certificate renewal syslog alert Message-ID: <54AEAAA3.5010506@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-386-Fix-CA-certificate-renewal-syslog-alert.patch Type: text/x-patch Size: 1060 bytes Desc: not available URL: From pspacek at redhat.com Fri Jan 9 08:32:24 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 09 Jan 2015 09:32:24 +0100 Subject: [Freeipa-devel] automatic backup before FreeIPA upgrade? Message-ID: <54AF9218.6070304@redhat.com> Hello, I wonder if it is feasible to automatically run backup before FreeIPA upgrade ... How big the backup file is (I'm asking about X in expression X + database size)? Is there any reason not to do auto-backup? -- Petr^2 Spacek From pspacek at redhat.com Fri Jan 9 12:17:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 09 Jan 2015 13:17:52 +0100 Subject: [Freeipa-devel] [PATCHES 180-181] Fix forwardzone update In-Reply-To: <54AEA7E4.6050204@redhat.com> References: <54AD2CEC.6040906@redhat.com> <54AEA57F.2070106@redhat.com> <54AEA7E4.6050204@redhat.com> Message-ID: <54AFC6F0.8050105@redhat.com> On 8.1.2015 16:53, Martin Basti wrote: > On 08/01/15 16:42, Petr Spacek wrote: >> On 7.1.2015 13:56, Martin Basti wrote: >>> + for config_option in container_entry.get("ipaConfigString", []): >>> + matched = re.match(r"^DNSVersion\s+(?P%d)$", >> %d is C-ishm which does not work >> >>> + config_option, flags=re.I) >>> + if matched and matched.group("version") >= 1: >> group("version") should be converted to int before comparison >> >> Otherwise it seems that zone update itself works flawlessly for me. >> >> HUGE NACK :-D >> > Stupid me. > Updated patches attached. ACK -- Petr^2 Spacek From mkosek at redhat.com Fri Jan 9 12:42:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Jan 2015 13:42:25 +0100 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: <54AF2EBE.1010005@redhat.com> References: <54AF2EBE.1010005@redhat.com> Message-ID: <54AFCCB1.9010808@redhat.com> I am forwarding my conversation with the Noriko from Fedora localization team to the devel list, see below. What do you guys think? Any concerns with moving FreeIPA translations from Transifex to Zanata? SSSD project is moving there as well. The move has +1 from me, the Zanata platform looks great, many projects are migrating to it AND it is open source (unlike Transifex). The actual migration should be pretty straightforward. Tomas Babej already volunteered to take care of the localization process. The Fedora localization team will help with any Zanata specifics, so it should be pretty smooth move. Thanks, Martin -------- Forwarded Message -------- Subject: Re: ShRe: zanata: freeipa-guide is migrated to fedora.zanata.org Date: Fri, 09 Jan 2015 11:28:30 +1000 From: Noriko Mizumoto Reply-To: noriko at redhat.com Organization: Red Hat To: Martin Kosek , Ding Yi Chen CC: Carlos Munoz , Patrick Huang , Alex Eng (2015?01?08? 21:07), Martin Kosek wrote: > On 01/08/2015 01:22 AM, Ding Yi Chen wrote: >> ----- Original Message ----- >>> On 01/06/2015 08:14 AM, Ding Yi Chen wrote: >>>> Hi, >>>> >>>> The migration of the "freeipa-guide" project translations to Zanata is now >>>> complete. >>>> Translators can start working now at >>>> https://fedora.zanata.org/project/view/freeipa-guide >>>> >>>> To use Zanata, you need to >>>> 1. Register in https://fedora.zanata.org >>>> 2. If you are not the maintainer of your project yet, contact the admin to >>>> add you as maintainer. >>>> 3. Follow the instruction http://zanata.org/help/cli/cli-configuration/ to >>>> set up client. >>>> 4. Place the attached zanata.xml, in the root directory of repository >>>> 5. (Optional) Integrate "zanata push" and "zanata pull" to your buildscript >>>> >>>> >>>> If you have any questions or need us to provide patches, feel free to >>>> contact the Zanata dev team. >>>> >>>> >>>> Regards, >>>> >>> Hello Ding Yi, >>> >>> Personally, I do not think we should have these translation projects enabled >>> either in Transifex, nor in Zanata to avoid contributions to an orphaned, >>> dead >>> guide. >>> >>> The history and reasoning around orphaning FreeIPA upstream guide can be >>> found >>> here: >>> >>> http://www.freeipa.org/page/Upstream_User_Guide >>> >>> Martin >> Dear Martin, >> >> Just wondering should we migrate the FreeIPA as well? >> >> It seems freeipa-python is still an active package. >> >> >> Regards, > Hello, > > I was already thinking about it too. I am not sure what you mean by > freeipa-python, it is just one subpackage of the FreeIPA project. The FreeIPA > Transifex translation project is: > > https://fedora.transifex.com/projects/p/freeipa/ > > And yes, the FreeIPA project is quite active :-) > > Just like FESCo, I am personally open to migrating it to Zanata. But I would > like to have this proposal also agreed on the FreeIPA upstream development list > so that it is not decided behind developers' backs. Can you (or whoever will > help with transition) please ask on the freeipa-devel mailing list with this > proposal? Or do you use different process? > > Thank you, > Martin Hi Martin I am Noriko Mizumoto, FLSCo member. We, FLP (Fedora Localization Project), decided to move our interface from Transifex to Zanata. I have had the meetings with the leaders from Docs team, Web team as well FESCo [1] in 2014, and our decision has been supported by them. This means that All translators move to Zanata to work on Fedora related translation. All Fedora projects including Software, Documentation and Websites are requested to move to Zanata. I understand that FreeIPA is Upstream and is not bound by this. But I like to encourage your project team to consider the move, since all Fedora projects as well many of Upstream projects will move to Zanata from Transifex. The detailed background can be found in the FESCo ticket [1]. The migration schedule can be found in the wiki page [2]. The announcement has been made at devel-announce ML in Nov 2014, asking the developers' to take an action [3]. It is much appreciated that if you can coordinate the discussion with the freeipa-devel team. Once the decision is made, could you please advise me so that I will make sure to inform your project's decision to all Fedora translators. We are looking at to complete entire projects migration by February 2015, minimizing the impact to F22. Any question, please feel free to ask. [1]:https://fedorahosted.org/fesco/ticket/1334 [2]:https://fedoraproject.org/wiki/L10N_Move_To_Zanata [3]:https://lists.fedoraproject.org/pipermail/devel-announce/2014-November/001467.html Thanks noriko FLSCo member Fedora Localization Project From jhrozek at redhat.com Fri Jan 9 12:53:03 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 9 Jan 2015 13:53:03 +0100 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: <54AFCCB1.9010808@redhat.com> References: <54AF2EBE.1010005@redhat.com> <54AFCCB1.9010808@redhat.com> Message-ID: <20150109125303.GH824@hendrix.brq.redhat.com> On Fri, Jan 09, 2015 at 01:42:25PM +0100, Martin Kosek wrote: > I am forwarding my conversation with the Noriko from Fedora localization > team to the devel list, see below. What do you guys think? Any concerns with > moving FreeIPA translations from Transifex to Zanata? SSSD project is moving > there as well. s/is moving/has moved/ :-) The 1.12.3 release we did yesterday already contains translations fetched from Zanata. > > The move has +1 from me, the Zanata platform looks great, many projects are > migrating to it AND it is open source (unlike Transifex). > > The actual migration should be pretty straightforward. Tomas Babej already > volunteered to take care of the localization process. The Fedora > localization team will help with any Zanata specifics, so it should be > pretty smooth move. For SSSD it was pretty straighforward thanks to some help we received from the Fedora team. My only negative-ish impression of Zanata so far is that I liked the Transifex tooling better. I hope the zanata-cli tools will improve over time as well. From dkupka at redhat.com Fri Jan 9 13:07:46 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 09 Jan 2015 14:07:46 +0100 Subject: [Freeipa-devel] [PATCH 0179] Fix traceback if zonemgr error message contains unicode characters In-Reply-To: <548AED1E.2020308@redhat.com> References: <548AED1E.2020308@redhat.com> Message-ID: <54AFD2A2.9070204@redhat.com> On 12/12/2014 02:26 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4805 > > Patch attached. > > Does not work properly. $ locale LANG=cs_CZ.iso88592 LC_CTYPE="cs_CZ.iso88592" LC_NUMERIC="cs_CZ.iso88592" LC_TIME="cs_CZ.iso88592" LC_COLLATE="cs_CZ.iso88592" LC_MONETARY="cs_CZ.iso88592" LC_MESSAGES="cs_CZ.iso88592" LC_PAPER="cs_CZ.iso88592" LC_NAME="cs_CZ.iso88592" LC_ADDRESS="cs_CZ.iso88592" LC_TELEPHONE="cs_CZ.iso88592" LC_MEASUREMENT="cs_CZ.iso88592" LC_IDENTIFICATION="cs_CZ.iso88592" LC_ALL=cs_CZ.iso88592 $ sudo ipa-server-install --setup-dns --forwarder=10.65.201.89 -r TESTRELM.TEST -p xxxxxxxx -P xxxxxxxx -a xxxxxxxx --zonemg=?a?ko at redhat.com -U > /tmp/ipaserverinstall_invalidzonemgr.out 2>&1 $ cat /tmp/ipaserverinstall_invalidzonemgr.out Usage: ipa-server-install [options] ipa-server-install: error: invalid zonemgr: domain name '??a??ko.redhat.com' should be normalized to: ??a??ko.redhat.com The provided value isn't right and must be normalized but the one displayed in error message doesn't match. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- David Kupka From mkosek at redhat.com Fri Jan 9 13:26:29 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Jan 2015 14:26:29 +0100 Subject: [Freeipa-devel] Reviewed-By for design pages? In-Reply-To: <20150107164121.GL16288@redhat.com> References: <54ACFDC3.5080001@redhat.com> <20150107103851.2dfa2fe1@willson.usersys.redhat.com> <20150107164121.GL16288@redhat.com> Message-ID: <54AFD705.3080907@redhat.com> On 01/07/2015 05:41 PM, Alexander Bokovoy wrote: > On Wed, 07 Jan 2015, Simo Sorce wrote: >> On Wed, 07 Jan 2015 10:34:59 +0100 >> Petr Spacek wrote: >> >>> Hello, >>> >>> I wonder if we should add something like Reviewed-by tag to newly >>> created design pages. It would serve as reminder and check that page >>> was really reviewed by someone. (And that we should not spend much >>> time on implementation before the tag is present on the page.) >>> >>> It will also add 'psychological pressure' to the reviewer because his >>> name will be on the design page forever :-) >>> >> >> +1 > +1 too. Maybe we could move "author" and "reviewer" to the Feature info box with feature page metadata? (see box e.g. in http://www.freeipa.org/page/V4/OTP) I just wonder that, given that authorship and review is often collaborative work, multiple people may be interested to be listed in these fields in the info box or the page itself. Martin From mkosek at redhat.com Fri Jan 9 13:29:08 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Jan 2015 14:29:08 +0100 Subject: [Freeipa-devel] [PATCHES 180-181] Fix forwardzone update In-Reply-To: <54AFC6F0.8050105@redhat.com> References: <54AD2CEC.6040906@redhat.com> <54AEA57F.2070106@redhat.com> <54AEA7E4.6050204@redhat.com> <54AFC6F0.8050105@redhat.com> Message-ID: <54AFD7A4.1030107@redhat.com> On 01/09/2015 01:17 PM, Petr Spacek wrote: > On 8.1.2015 16:53, Martin Basti wrote: >> On 08/01/15 16:42, Petr Spacek wrote: >>> On 7.1.2015 13:56, Martin Basti wrote: >>>> + for config_option in container_entry.get("ipaConfigString", []): >>>> + matched = re.match(r"^DNSVersion\s+(?P%d)$", >>> %d is C-ishm which does not work >>> >>>> + config_option, flags=re.I) >>>> + if matched and matched.group("version") >= 1: >>> group("version") should be converted to int before comparison >>> >>> Otherwise it seems that zone update itself works flawlessly for me. >>> >>> HUGE NACK :-D >>> >> Stupid me. >> Updated patches attached. > > ACK > Pushed to: master: af6aece39b4804b9974098d5688a969d053548bc ipa-4-1: 39a4f683fc441165c3154481f1a6b174ff3b8271 ipa-4-0: 7c70bac3afe663d11ce274759571db6d96f8eb14 Martin From dkupka at redhat.com Fri Jan 9 13:43:32 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 09 Jan 2015 14:43:32 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54AD4D91.3020101@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> Message-ID: <54AFDB04.7000902@redhat.com> On 01/07/2015 04:15 PM, Martin Basti wrote: > On 07/01/15 12:27, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4249 > > Thank you for patch: > > 1) > - root_logger.error("Cannot update DNS records! " > - "Failed to connect to server '%s'.", server) > + ips = get_local_ipaddresses() > + except CalledProcessError as e: > + root_logger.error("Cannot update DNS records. %s" % e) > > IMO the error message should be more specific, add there something like > "Unable to get local IP addresses". at least in log.debug() > > 2) > + lines = ipresult[0].replace('\\', '').split('\n') > > .replace() is not needed > > 3) > + if len(ips) == 0: > > if not ips: > > is more pythonic by PEP8 > > Thanks for catching these. Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0035-2-client-Update-DNS-with-all-available-local-IP-addres.patch Type: text/x-patch Size: 5255 bytes Desc: not available URL: From jdennis at redhat.com Fri Jan 9 14:00:27 2015 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Jan 2015 09:00:27 -0500 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: <54AFCCB1.9010808@redhat.com> References: <54AF2EBE.1010005@redhat.com> <54AFCCB1.9010808@redhat.com> Message-ID: <54AFDEFB.2020606@redhat.com> On 01/09/2015 07:42 AM, Martin Kosek wrote: > I am forwarding my conversation with the Noriko from Fedora localization team > to the devel list, see below. What do you guys think? Any concerns with moving > FreeIPA translations from Transifex to Zanata? SSSD project is moving there as > well. I have no personal experience with Zanata so my comment is worth what you paid for it :-) Just following the online discussions it does seem like Zanata is the future, so probably better to be using the tool everyone else is using instead of a lone hold out. Anecdotal reports suggest migrations are relatively smooth. YMMV. -- John From pvoborni at redhat.com Fri Jan 9 14:13:49 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Jan 2015 15:13:49 +0100 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: <54AFDEFB.2020606@redhat.com> References: <54AF2EBE.1010005@redhat.com> <54AFCCB1.9010808@redhat.com> <54AFDEFB.2020606@redhat.com> Message-ID: <54AFE21D.3060907@redhat.com> On 01/09/2015 03:00 PM, John Dennis wrote: > On 01/09/2015 07:42 AM, Martin Kosek wrote: >> I am forwarding my conversation with the Noriko from Fedora localization team >> to the devel list, see below. What do you guys think? Any concerns with moving >> FreeIPA translations from Transifex to Zanata? SSSD project is moving there as >> well. > > I have no personal experience with Zanata so my comment is worth what > you paid for it :-) +1 > > Just following the online discussions it does seem like Zanata is the > future, so probably better to be using the tool everyone else is using > instead of a lone hold out. Anecdotal reports suggest migrations are > relatively smooth. YMMV. +1 -- Petr Vobornik From lkrispen at redhat.com Fri Jan 9 14:29:02 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 09 Jan 2015 15:29:02 +0100 Subject: [Freeipa-devel] topology management question In-Reply-To: <20150107113507.1db2283f@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> <20150107111328.2d8ba9ca@willson.usersys.redhat.com> <54AD5D6C.1090909@redhat.com> <20150107113507.1db2283f@willson.usersys.redhat.com> Message-ID: <54AFE5AE.6030905@redhat.com> On 01/07/2015 05:35 PM, Simo Sorce wrote: > On Wed, 07 Jan 2015 17:23:08 +0100 > Ludwig Krispenz wrote: > >> On 01/07/2015 05:13 PM, Simo Sorce wrote: >>> On Wed, 07 Jan 2015 17:11:53 +0100 >>> Ludwig Krispenz wrote: >>> >>>>>>>> Now, with some effort this can be resolved, eg >>>>>>>> if the server is removed, keep it internally as removed server >>>>>>>> and for segments connecting this server trigger removal of >>>>>>>> replication agreements or mark a the last segment, when tried >>>>>>>> to remove, as pending and once the server is removed also >>>>>>>> remove the corresponding repl agreements >>>>>>> Why should we "keep it internally" ? >>>>>>> If you mark the agreements as managed by setting an attribute on >>>>>>> them, then you will never have any issue recognizing a "managed" >>>>>>> agreement in cn=config, and you will also immediately find out >>>>>>> it is "old" as it is not backed by a segment so you will safely >>>>>>> remove it. >>>>>> I didn't want to add new flags/fields to the replication >>>>>> agreements as long as anything can be handled by the data in the >>>>>> shared tree. >>>>> We have too. I think it is a must or we will find numerous corner >>>>> cases. Is there a specific reason why you do not want to add flags >>>>> to replication agreements in cn=config ? >>>> Simo and I had a discussion on this and had agreed that the >>>> "marking" of a replication agreement >>>> as controlled by the plugin could be done by a naming convention on >>>> the replication agreements. >>>> They are originally created as "cn=meTo,..." and would >>>> be renamed to something like >>>> "cn=-to-,....." avoiding to add a new >>>> attribute to the repl agreement schema. >>>> >>>> Unfortunately this does not work out of the box. I only discovered >>>> afetr implementing and testing (was not aware of before :-) >>>> that DS does not implement modrdn operation for internal backends, >>>> It just returns unwilling_to_perform. >>>> And if it will be implemented the replication plugin will have to >>>> be changed as well to catch the mordrdn to update the in memory >>>> objects with the new name (which is used in logging). >>>> >>>> So, if there is no objection, I will go back to the "flag" >>>> solution. >>> What about simply deleting the agreement and adding it back with the >>> new name ? >> it will stop replication and the restart it again, unnecessary >> interrupting replication for some time. >> Assume you have a working topology and then raise the domain level >> and the plugin becomes active, >> creates segments and "marks" agreements as controlled. This should >> happen as smooth as >> possible. > While this is true, it is also a rare operation. I do not see it as a > big deal to be honest. > However if you prefer to add a flag attribute that is fine by me too. after thinking a bit more about it, I don't think we need the mark at all. The agreement would have been marked in two scenarios - the agreement exists and the dom level is raised, so that a segment is created from the agreement - the dom level is set, the plugin active and a segment is addded to the shared tree so that a replication agreement is generated. In all cases where an agreement is marked, there is a 1:1 corresponding segment, so the existence of a segment should be marking enough. I will make the mark_agreement and check_mark as noops, so if we really run into a scenario where a mark would be required, it can be added in one of the methods discussed so far. > > Simo. > From jfenal at gmail.com Fri Jan 9 14:34:15 2015 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 9 Jan 2015 15:34:15 +0100 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: <54AFE21D.3060907@redhat.com> References: <54AF2EBE.1010005@redhat.com> <54AFCCB1.9010808@redhat.com> <54AFDEFB.2020606@redhat.com> <54AFE21D.3060907@redhat.com> Message-ID: 2015-01-09 15:13 GMT+01:00 Petr Vobornik : > On 01/09/2015 03:00 PM, John Dennis wrote: >> >> On 01/09/2015 07:42 AM, Martin Kosek wrote: >>> >>> I am forwarding my conversation with the Noriko from Fedora localization >>> team >>> to the devel list, see below. What do you guys think? Any concerns with >>> moving >>> FreeIPA translations from Transifex to Zanata? SSSD project is moving >>> there as >>> well. >> >> >> I have no personal experience with Zanata so my comment is worth what >> you paid for it :-) > > > +1 +1 >> Just following the online discussions it does seem like Zanata is the >> future, so probably better to be using the tool everyone else is using >> instead of a lone hold out. Anecdotal reports suggest migrations are >> relatively smooth. YMMV. > > > +1 +1 -- J?r?me Fenal From ssorce at redhat.com Fri Jan 9 14:37:58 2015 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 9 Jan 2015 09:37:58 -0500 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: <54AFCCB1.9010808@redhat.com> References: <54AF2EBE.1010005@redhat.com> <54AFCCB1.9010808@redhat.com> Message-ID: <20150109093758.7ca78634@willson.usersys.redhat.com> On Fri, 09 Jan 2015 13:42:25 +0100 Martin Kosek wrote: > I am forwarding my conversation with the Noriko from Fedora > localization team to the devel list, see below. What do you guys > think? Any concerns with moving FreeIPA translations from Transifex > to Zanata? SSSD project is moving there as well. > > The move has +1 from me, the Zanata platform looks great, many > projects are migrating to it AND it is open source (unlike Transifex). > > The actual migration should be pretty straightforward. Tomas Babej > already volunteered to take care of the localization process. The > Fedora localization team will help with any Zanata specifics, so it > should be pretty smooth move. I see no problem moving to Zanata. Simo. > Thanks, > Martin > > -------- Forwarded Message -------- > Subject: Re: ShRe: zanata: freeipa-guide is migrated to > fedora.zanata.org Date: Fri, 09 Jan 2015 11:28:30 +1000 > From: Noriko Mizumoto > Reply-To: noriko at redhat.com > Organization: Red Hat > To: Martin Kosek , Ding Yi Chen > CC: Carlos Munoz , Patrick Huang > , Alex Eng > > (2015?01?08? 21:07), Martin Kosek wrote: > > On 01/08/2015 01:22 AM, Ding Yi Chen wrote: > >> ----- Original Message ----- > >>> On 01/06/2015 08:14 AM, Ding Yi Chen wrote: > >>>> Hi, > >>>> > >>>> The migration of the "freeipa-guide" project translations to > >>>> Zanata is now complete. > >>>> Translators can start working now at > >>>> https://fedora.zanata.org/project/view/freeipa-guide > >>>> > >>>> To use Zanata, you need to > >>>> 1. Register in https://fedora.zanata.org > >>>> 2. If you are not the maintainer of your project yet, contact > >>>> the admin to add you as maintainer. > >>>> 3. Follow the instruction > >>>> http://zanata.org/help/cli/cli-configuration/ to set up client. > >>>> 4. Place the attached zanata.xml, in the root directory of > >>>> repository 5. (Optional) Integrate "zanata push" and "zanata > >>>> pull" to your buildscript > >>>> > >>>> > >>>> If you have any questions or need us to provide patches, feel > >>>> free to contact the Zanata dev team. > >>>> > >>>> > >>>> Regards, > >>>> > >>> Hello Ding Yi, > >>> > >>> Personally, I do not think we should have these translation > >>> projects enabled either in Transifex, nor in Zanata to avoid > >>> contributions to an orphaned, dead > >>> guide. > >>> > >>> The history and reasoning around orphaning FreeIPA upstream guide > >>> can be found > >>> here: > >>> > >>> http://www.freeipa.org/page/Upstream_User_Guide > >>> > >>> Martin > >> Dear Martin, > >> > >> Just wondering should we migrate the FreeIPA as well? > >> > >> It seems freeipa-python is still an active package. > >> > >> > >> Regards, > > Hello, > > > > I was already thinking about it too. I am not sure what you mean by > > freeipa-python, it is just one subpackage of the FreeIPA project. > > The FreeIPA Transifex translation project is: > > > > https://fedora.transifex.com/projects/p/freeipa/ > > > > And yes, the FreeIPA project is quite active :-) > > > > Just like FESCo, I am personally open to migrating it to Zanata. > > But I would like to have this proposal also agreed on the FreeIPA > > upstream development list so that it is not decided behind > > developers' backs. Can you (or whoever will help with transition) > > please ask on the freeipa-devel mailing list with this proposal? Or > > do you use different process? > > > > Thank you, > > Martin > > Hi Martin > > I am Noriko Mizumoto, FLSCo member. > We, FLP (Fedora Localization Project), decided to move our interface > from Transifex to Zanata. > I have had the meetings with the leaders from Docs team, Web team as > well FESCo [1] in 2014, and our decision has been supported by them. > This means that All translators move to Zanata to work on Fedora > related translation. All Fedora projects including Software, > Documentation and Websites are requested to move to Zanata. > > I understand that FreeIPA is Upstream and is not bound by this. But I > like to encourage your project team to consider the move, since all > Fedora projects as well many of Upstream projects will move to Zanata > from Transifex. The detailed background can be found in the FESCo > ticket [1]. The migration schedule can be found in the wiki page [2]. > The announcement has been made at devel-announce ML in Nov 2014, > asking the developers' to take an action [3]. > > It is much appreciated that if you can coordinate the discussion with > the freeipa-devel team. > Once the decision is made, could you please advise me so that I will > make sure to inform your project's decision to all Fedora translators. > We are looking at to complete entire projects migration by February > 2015, minimizing the impact to F22. > > Any question, please feel free to ask. > > [1]:https://fedorahosted.org/fesco/ticket/1334 > [2]:https://fedoraproject.org/wiki/L10N_Move_To_Zanata > [3]:https://lists.fedoraproject.org/pipermail/devel-announce/2014-November/001467.html > > Thanks > > noriko > FLSCo member > Fedora Localization Project -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jan 9 14:50:47 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 9 Jan 2015 09:50:47 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54AFE5AE.6030905@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> <20150107111328.2d8ba9ca@willson.usersys.redhat.com> <54AD5D6C.1090909@redhat.com> <20150107113507.1db2283f@willson.usersys.redhat.com> <54AFE5AE.6030905@redhat.com> Message-ID: <20150109095047.04ea0763@willson.usersys.redhat.com> On Fri, 09 Jan 2015 15:29:02 +0100 Ludwig Krispenz wrote: > > On 01/07/2015 05:35 PM, Simo Sorce wrote: > > On Wed, 07 Jan 2015 17:23:08 +0100 > > Ludwig Krispenz wrote: > > > >> On 01/07/2015 05:13 PM, Simo Sorce wrote: > >>> On Wed, 07 Jan 2015 17:11:53 +0100 > >>> Ludwig Krispenz wrote: > >>> > >>>>>>>> Now, with some effort this can be resolved, eg > >>>>>>>> if the server is removed, keep it internally as removed > >>>>>>>> server and for segments connecting this server trigger > >>>>>>>> removal of replication agreements or mark a the last > >>>>>>>> segment, when tried to remove, as pending and once the > >>>>>>>> server is removed also remove the corresponding repl > >>>>>>>> agreements > >>>>>>> Why should we "keep it internally" ? > >>>>>>> If you mark the agreements as managed by setting an attribute > >>>>>>> on them, then you will never have any issue recognizing a > >>>>>>> "managed" agreement in cn=config, and you will also > >>>>>>> immediately find out it is "old" as it is not backed by a > >>>>>>> segment so you will safely remove it. > >>>>>> I didn't want to add new flags/fields to the replication > >>>>>> agreements as long as anything can be handled by the data in > >>>>>> the shared tree. > >>>>> We have too. I think it is a must or we will find numerous > >>>>> corner cases. Is there a specific reason why you do not want to > >>>>> add flags to replication agreements in cn=config ? > >>>> Simo and I had a discussion on this and had agreed that the > >>>> "marking" of a replication agreement > >>>> as controlled by the plugin could be done by a naming convention > >>>> on the replication agreements. > >>>> They are originally created as "cn=meTo,..." and > >>>> would be renamed to something like > >>>> "cn=-to-,....." avoiding to add a new > >>>> attribute to the repl agreement schema. > >>>> > >>>> Unfortunately this does not work out of the box. I only > >>>> discovered afetr implementing and testing (was not aware of > >>>> before :-) that DS does not implement modrdn operation for > >>>> internal backends, It just returns unwilling_to_perform. > >>>> And if it will be implemented the replication plugin will have to > >>>> be changed as well to catch the mordrdn to update the in memory > >>>> objects with the new name (which is used in logging). > >>>> > >>>> So, if there is no objection, I will go back to the "flag" > >>>> solution. > >>> What about simply deleting the agreement and adding it back with > >>> the new name ? > >> it will stop replication and the restart it again, unnecessary > >> interrupting replication for some time. > >> Assume you have a working topology and then raise the domain level > >> and the plugin becomes active, > >> creates segments and "marks" agreements as controlled. This should > >> happen as smooth as > >> possible. > > While this is true, it is also a rare operation. I do not see it as > > a big deal to be honest. > > However if you prefer to add a flag attribute that is fine by me > > too. > after thinking a bit more about it, I don't think we need the mark at > all. We discussed this already and we came to the conclusion we need it :) > The agreement would have been marked in two scenarios > - the agreement exists and the dom level is raised, so that a segment > is created from the agreement > - the dom level is set, the plugin active and a segment is addded to > the shared tree so that a replication agreement is generated. > In all cases where an agreement is marked, there is a 1:1 > corresponding segment, so the existence of a segment should be > marking enough. I will make the mark_agreement and check_mark as > noops, so if we really run into a > scenario where a mark would be required, it can be added in one of > the methods discussed > so far. I recall the problems came in corner cases. Like when a replica starts and finds an agreement. If it is marked and a segment does not exist, we simply delete it. However if it not marked and a segment does not exist, what do you do ? Without markings you can only import it, and this way you may end up reviving deleted agreements by mistake. The reason this may happen is that cn=config and the main database are separate, and a backup dse.ldif may be use upon start even though the shared database had been already updated, so we cannot count on the replica starting and finding the segment-to-be-deleted-via-replication still there. The marking was needed to make sure that once an agreement was imported we wouldn't do it again later on. I still maintain that marking it is safer and will lead to less issues with phantom segments coming back to life. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Jan 9 15:01:57 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Jan 2015 16:01:57 +0100 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: References: <54AF2EBE.1010005@redhat.com> <54AFCCB1.9010808@redhat.com> <54AFDEFB.2020606@redhat.com> <54AFE21D.3060907@redhat.com> Message-ID: <54AFED65.7040607@redhat.com> On 01/09/2015 03:34 PM, J?r?me Fenal wrote: > 2015-01-09 15:13 GMT+01:00 Petr Vobornik : >> On 01/09/2015 03:00 PM, John Dennis wrote: >>> >>> On 01/09/2015 07:42 AM, Martin Kosek wrote: >>>> >>>> I am forwarding my conversation with the Noriko from Fedora localization >>>> team >>>> to the devel list, see below. What do you guys think? Any concerns with >>>> moving >>>> FreeIPA translations from Transifex to Zanata? SSSD project is moving >>>> there as >>>> well. >>> >>> >>> I have no personal experience with Zanata so my comment is worth what >>> you paid for it :-) >> >> >> +1 > > +1 > >>> Just following the online discussions it does seem like Zanata is the >>> future, so probably better to be using the tool everyone else is using >>> instead of a lone hold out. Anecdotal reports suggest migrations are >>> relatively smooth. YMMV. >> >> >> +1 > > +1 > Thanks to all! I did not see any disagreement, I think the request already hit the critical mass of agreement to move on. I will connect Tomas with the Fedora localization team, to co-work on the technical move from Transifex to Zanata. My only requirement is that the uploading/downloading process and Localization process overall is well documented and/or scripted in our git. We should also add it as a step to our Release wiki page (to make sure translations are updated). Martin From lkrispen at redhat.com Fri Jan 9 15:07:21 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 09 Jan 2015 16:07:21 +0100 Subject: [Freeipa-devel] topology management question In-Reply-To: <20150109095047.04ea0763@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> <20150107111328.2d8ba9ca@willson.usersys.redhat.com> <54AD5D6C.1090909@redhat.com> <20150107113507.1db2283f@willson.usersys.redhat.com> <54AFE5AE.6030905@redhat.com> <20150109095047.04ea0763@willson.usersys.redhat.com> Message-ID: <54AFEEA9.70503@redhat.com> On 01/09/2015 03:50 PM, Simo Sorce wrote: > On Fri, 09 Jan 2015 15:29:02 +0100 > Ludwig Krispenz wrote: > >> On 01/07/2015 05:35 PM, Simo Sorce wrote: >>> On Wed, 07 Jan 2015 17:23:08 +0100 >>> Ludwig Krispenz wrote: >>> >>>> On 01/07/2015 05:13 PM, Simo Sorce wrote: >>>>> On Wed, 07 Jan 2015 17:11:53 +0100 >>>>> Ludwig Krispenz wrote: >>>>> >>>>>>>>>> Now, with some effort this can be resolved, eg >>>>>>>>>> if the server is removed, keep it internally as removed >>>>>>>>>> server and for segments connecting this server trigger >>>>>>>>>> removal of replication agreements or mark a the last >>>>>>>>>> segment, when tried to remove, as pending and once the >>>>>>>>>> server is removed also remove the corresponding repl >>>>>>>>>> agreements >>>>>>>>> Why should we "keep it internally" ? >>>>>>>>> If you mark the agreements as managed by setting an attribute >>>>>>>>> on them, then you will never have any issue recognizing a >>>>>>>>> "managed" agreement in cn=config, and you will also >>>>>>>>> immediately find out it is "old" as it is not backed by a >>>>>>>>> segment so you will safely remove it. >>>>>>>> I didn't want to add new flags/fields to the replication >>>>>>>> agreements as long as anything can be handled by the data in >>>>>>>> the shared tree. >>>>>>> We have too. I think it is a must or we will find numerous >>>>>>> corner cases. Is there a specific reason why you do not want to >>>>>>> add flags to replication agreements in cn=config ? >>>>>> Simo and I had a discussion on this and had agreed that the >>>>>> "marking" of a replication agreement >>>>>> as controlled by the plugin could be done by a naming convention >>>>>> on the replication agreements. >>>>>> They are originally created as "cn=meTo,..." and >>>>>> would be renamed to something like >>>>>> "cn=-to-,....." avoiding to add a new >>>>>> attribute to the repl agreement schema. >>>>>> >>>>>> Unfortunately this does not work out of the box. I only >>>>>> discovered afetr implementing and testing (was not aware of >>>>>> before :-) that DS does not implement modrdn operation for >>>>>> internal backends, It just returns unwilling_to_perform. >>>>>> And if it will be implemented the replication plugin will have to >>>>>> be changed as well to catch the mordrdn to update the in memory >>>>>> objects with the new name (which is used in logging). >>>>>> >>>>>> So, if there is no objection, I will go back to the "flag" >>>>>> solution. >>>>> What about simply deleting the agreement and adding it back with >>>>> the new name ? >>>> it will stop replication and the restart it again, unnecessary >>>> interrupting replication for some time. >>>> Assume you have a working topology and then raise the domain level >>>> and the plugin becomes active, >>>> creates segments and "marks" agreements as controlled. This should >>>> happen as smooth as >>>> possible. >>> While this is true, it is also a rare operation. I do not see it as >>> a big deal to be honest. >>> However if you prefer to add a flag attribute that is fine by me >>> too. >> after thinking a bit more about it, I don't think we need the mark at >> all. > We discussed this already and we came to the conclusion we need it :) ok, I think in the discussion we came up with the mark was with my concerns about removing a replica, and you more or less destroyed my concerns. I agree there could be some corner cases like the ones you sketch below. But it will still be difficult to do the right thing in all cases. Take your example of a marked agreement and no segment. we could arrive at this state in two different scenarios: 1] - take a backup of the shared database - add a segment, a RA will be created and marked - the database gets corrupted and you restore the backup - the agmt is marked and no segment exists - should we really delete the agmt ? 2] - have a segment and a marked agreement - take a backup of the dse.ldif - delete the segment, agmt is removed - restore the dse.ldif, - the agmt is marked, no segment exists > >> The agreement would have been marked in two scenarios >> - the agreement exists and the dom level is raised, so that a segment >> is created from the agreement >> - the dom level is set, the plugin active and a segment is addded to >> the shared tree so that a replication agreement is generated. >> In all cases where an agreement is marked, there is a 1:1 >> corresponding segment, so the existence of a segment should be >> marking enough. I will make the mark_agreement and check_mark as >> noops, so if we really run into a >> scenario where a mark would be required, it can be added in one of >> the methods discussed >> so far. > I recall the problems came in corner cases. Like when a replica starts > and finds an agreement. > If it is marked and a segment does not exist, we simply delete it. > However if it not marked and a segment does not exist, what do you do ? > Without markings you can only import it, and this way you may end up > reviving deleted agreements by mistake. > > The reason this may happen is that cn=config and the main database are > separate, and a backup dse.ldif may be use upon start even though the > shared database had been already updated, so we cannot count on the > replica starting and finding the segment-to-be-deleted-via-replication > still there. > > The marking was needed to make sure that once an agreement was imported > we wouldn't do it again later on. > I still maintain that marking it is safer and will lead to less issues > with phantom segments coming back to life. > > Simo. > > From jhrozek at redhat.com Fri Jan 9 15:08:13 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 9 Jan 2015 16:08:13 +0100 Subject: [Freeipa-devel] Move FreeIPA translations to Zanata? In-Reply-To: <54AFED65.7040607@redhat.com> References: <54AF2EBE.1010005@redhat.com> <54AFCCB1.9010808@redhat.com> <54AFDEFB.2020606@redhat.com> <54AFE21D.3060907@redhat.com> <54AFED65.7040607@redhat.com> Message-ID: <20150109150813.GO824@hendrix.brq.redhat.com> On Fri, Jan 09, 2015 at 04:01:57PM +0100, Martin Kosek wrote: > My only requirement is that the uploading/downloading process and > Localization process overall is well documented and/or scripted in our git. > We should also add it as a step to our Release wiki page (to make sure > translations are updated). You pretty much need: http://zanata.org/help/cli/cli-configuration/ Currently zanata-cli seems to suffer from a bug where the -s and -t options are required to be specified on the command line despite being defined in zanata.xml From simo at redhat.com Fri Jan 9 15:14:13 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 9 Jan 2015 10:14:13 -0500 Subject: [Freeipa-devel] automatic backup before FreeIPA upgrade? In-Reply-To: <54AF9218.6070304@redhat.com> References: <54AF9218.6070304@redhat.com> Message-ID: <20150109101413.412ae602@willson.usersys.redhat.com> On Fri, 09 Jan 2015 09:32:24 +0100 Petr Spacek wrote: > Hello, > > I wonder if it is feasible to automatically run backup before FreeIPA > upgrade ... > > How big the backup file is (I'm asking about X in expression X + > database size)? Is there any reason not to do auto-backup? May take a long time if you have a huge directory. Maybe annoying to deal with space issues and similar from within an RPM scriptlet... Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jan 9 15:18:47 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 9 Jan 2015 10:18:47 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54AFEEA9.70503@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> <20150107111328.2d8ba9ca@willson.usersys.redhat.com> <54AD5D6C.1090909@redhat.com> <20150107113507.1db2283f@willson.usersys.redhat.com> <54AFE5AE.6030905@redhat.com> <20150109095047.04ea0763@willson.usersys.redhat.com> <54AFEEA9.70503@redhat.com> Message-ID: <20150109101847.290064b4@willson.usersys.redhat.com> On Fri, 09 Jan 2015 16:07:21 +0100 Ludwig Krispenz wrote: > > On 01/09/2015 03:50 PM, Simo Sorce wrote: > > On Fri, 09 Jan 2015 15:29:02 +0100 > > Ludwig Krispenz wrote: > > > >> On 01/07/2015 05:35 PM, Simo Sorce wrote: > >>> On Wed, 07 Jan 2015 17:23:08 +0100 > >>> Ludwig Krispenz wrote: > >>> > >>>> On 01/07/2015 05:13 PM, Simo Sorce wrote: > >>>>> On Wed, 07 Jan 2015 17:11:53 +0100 > >>>>> Ludwig Krispenz wrote: > >>>>> > >>>>>>>>>> Now, with some effort this can be resolved, eg > >>>>>>>>>> if the server is removed, keep it internally as removed > >>>>>>>>>> server and for segments connecting this server trigger > >>>>>>>>>> removal of replication agreements or mark a the last > >>>>>>>>>> segment, when tried to remove, as pending and once the > >>>>>>>>>> server is removed also remove the corresponding repl > >>>>>>>>>> agreements > >>>>>>>>> Why should we "keep it internally" ? > >>>>>>>>> If you mark the agreements as managed by setting an > >>>>>>>>> attribute on them, then you will never have any issue > >>>>>>>>> recognizing a "managed" agreement in cn=config, and you > >>>>>>>>> will also immediately find out it is "old" as it is not > >>>>>>>>> backed by a segment so you will safely remove it. > >>>>>>>> I didn't want to add new flags/fields to the replication > >>>>>>>> agreements as long as anything can be handled by the data in > >>>>>>>> the shared tree. > >>>>>>> We have too. I think it is a must or we will find numerous > >>>>>>> corner cases. Is there a specific reason why you do not want > >>>>>>> to add flags to replication agreements in cn=config ? > >>>>>> Simo and I had a discussion on this and had agreed that the > >>>>>> "marking" of a replication agreement > >>>>>> as controlled by the plugin could be done by a naming > >>>>>> convention on the replication agreements. > >>>>>> They are originally created as "cn=meTo,..." and > >>>>>> would be renamed to something like > >>>>>> "cn=-to-,....." avoiding to add a new > >>>>>> attribute to the repl agreement schema. > >>>>>> > >>>>>> Unfortunately this does not work out of the box. I only > >>>>>> discovered afetr implementing and testing (was not aware of > >>>>>> before :-) that DS does not implement modrdn operation for > >>>>>> internal backends, It just returns unwilling_to_perform. > >>>>>> And if it will be implemented the replication plugin will have > >>>>>> to be changed as well to catch the mordrdn to update the in > >>>>>> memory objects with the new name (which is used in logging). > >>>>>> > >>>>>> So, if there is no objection, I will go back to the "flag" > >>>>>> solution. > >>>>> What about simply deleting the agreement and adding it back with > >>>>> the new name ? > >>>> it will stop replication and the restart it again, unnecessary > >>>> interrupting replication for some time. > >>>> Assume you have a working topology and then raise the domain > >>>> level and the plugin becomes active, > >>>> creates segments and "marks" agreements as controlled. This > >>>> should happen as smooth as > >>>> possible. > >>> While this is true, it is also a rare operation. I do not see it > >>> as a big deal to be honest. > >>> However if you prefer to add a flag attribute that is fine by me > >>> too. > >> after thinking a bit more about it, I don't think we need the mark > >> at all. > > We discussed this already and we came to the conclusion we need > > it :) > ok, I think in the discussion we came up with the mark was with my > concerns about > removing a replica, and you more or less destroyed my concerns. > I agree there could be some corner cases like the ones you sketch > below. But it will still be difficult to do the right thing in all > cases. Take your example of a marked agreement and no segment. we > could arrive at this state > in two different scenarios: > 1] > - take a backup of the shared database > - add a segment, a RA will be created and marked > - the database gets corrupted and you restore the backup > - the agmt is marked and no segment exists - should we really delete > the agmt ? Yes. The shared tree is the authoritative repository. If you restore you are required to do due diligence and check what was lost and restore that too. > 2] > - have a segment and a marked agreement > - take a backup of the dse.ldif > - delete the segment, agmt is removed > - restore the dse.ldif, > - the agmt is marked, no segment exists Yes, this is the scenario I was hinting at, it the agreement is marked we know it is not something we need to import (it was already imported) so we just go on and delete it. > >> The agreement would have been marked in two scenarios > >> - the agreement exists and the dom level is raised, so that a > >> segment is created from the agreement > >> - the dom level is set, the plugin active and a segment is addded > >> to the shared tree so that a replication agreement is generated. > >> In all cases where an agreement is marked, there is a 1:1 > >> corresponding segment, so the existence of a segment should be > >> marking enough. I will make the mark_agreement and check_mark as > >> noops, so if we really run into a > >> scenario where a mark would be required, it can be added in one of > >> the methods discussed > >> so far. > > I recall the problems came in corner cases. Like when a replica > > starts and finds an agreement. > > If it is marked and a segment does not exist, we simply delete it. > > However if it not marked and a segment does not exist, what do you > > do ? Without markings you can only import it, and this way you may > > end up reviving deleted agreements by mistake. > > > > The reason this may happen is that cn=config and the main database > > are separate, and a backup dse.ldif may be use upon start even > > though the shared database had been already updated, so we cannot > > count on the replica starting and finding the > > segment-to-be-deleted-via-replication still there. > > > > The marking was needed to make sure that once an agreement was > > imported we wouldn't do it again later on. > > I still maintain that marking it is safer and will lead to less > > issues with phantom segments coming back to life. > > > > Simo. > > > > > -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Fri Jan 9 15:28:15 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 09 Jan 2015 16:28:15 +0100 Subject: [Freeipa-devel] [PATCH 0179] Fix traceback if zonemgr error message contains unicode characters In-Reply-To: <54AFD2A2.9070204@redhat.com> References: <548AED1E.2020308@redhat.com> <54AFD2A2.9070204@redhat.com> Message-ID: <54AFF38F.6040402@redhat.com> Dne 9.1.2015 v 14:07 David Kupka napsal(a): > On 12/12/2014 02:26 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4805 >> >> Patch attached. >> >> > Does not work properly. > > $ locale > LANG=cs_CZ.iso88592 > LC_CTYPE="cs_CZ.iso88592" > LC_NUMERIC="cs_CZ.iso88592" > LC_TIME="cs_CZ.iso88592" > LC_COLLATE="cs_CZ.iso88592" > LC_MONETARY="cs_CZ.iso88592" > LC_MESSAGES="cs_CZ.iso88592" > LC_PAPER="cs_CZ.iso88592" > LC_NAME="cs_CZ.iso88592" > LC_ADDRESS="cs_CZ.iso88592" > LC_TELEPHONE="cs_CZ.iso88592" > LC_MEASUREMENT="cs_CZ.iso88592" > LC_IDENTIFICATION="cs_CZ.iso88592" > LC_ALL=cs_CZ.iso88592 > > $ sudo ipa-server-install --setup-dns --forwarder=10.65.201.89 -r > TESTRELM.TEST -p xxxxxxxx -P xxxxxxxx -a xxxxxxxx > --zonemg=?a?ko at redhat.com -U > /tmp/ipaserverinstall_invalidzonemgr.out > 2>&1 > > $ cat /tmp/ipaserverinstall_invalidzonemgr.out > Usage: ipa-server-install [options] > > ipa-server-install: error: invalid zonemgr: domain name > '??a??ko.redhat.com' should be normalized to: ??a??ko.redhat.com > > The provided value isn't right and must be normalized but the one > displayed in error message doesn't match. That's because your terminal encoded it in utf-8 instead of iso-8859-2. It may be because you set the LC_* environment variables from within the terminal? -- Jan Cholasta From lkrispen at redhat.com Fri Jan 9 15:32:50 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 09 Jan 2015 16:32:50 +0100 Subject: [Freeipa-devel] topology management question In-Reply-To: <20150109101847.290064b4@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <54AD5AC9.5040103@redhat.com> <20150107111328.2d8ba9ca@willson.usersys.redhat.com> <54AD5D6C.1090909@redhat.com> <20150107113507.1db2283f@willson.usersys.redhat.com> <54AFE5AE.6030905@redhat.com> <20150109095047.04ea0763@willson.usersys.redhat.com> <54AFEEA9.70503@redhat.com> <20150109101847.290064b4@willson.usersys.redhat.com> Message-ID: <54AFF4A2.7070001@redhat.com> On 01/09/2015 04:18 PM, Simo Sorce wrote: > On Fri, 09 Jan 2015 16:07:21 +0100 > Ludwig Krispenz wrote: > >> On 01/09/2015 03:50 PM, Simo Sorce wrote: >>> On Fri, 09 Jan 2015 15:29:02 +0100 >>> Ludwig Krispenz wrote: >>> >>>> On 01/07/2015 05:35 PM, Simo Sorce wrote: >>>>> On Wed, 07 Jan 2015 17:23:08 +0100 >>>>> Ludwig Krispenz wrote: >>>>> >>>>>> On 01/07/2015 05:13 PM, Simo Sorce wrote: >>>>>>> On Wed, 07 Jan 2015 17:11:53 +0100 >>>>>>> Ludwig Krispenz wrote: >>>>>>> >>>>>>>>>>>> Now, with some effort this can be resolved, eg >>>>>>>>>>>> if the server is removed, keep it internally as removed >>>>>>>>>>>> server and for segments connecting this server trigger >>>>>>>>>>>> removal of replication agreements or mark a the last >>>>>>>>>>>> segment, when tried to remove, as pending and once the >>>>>>>>>>>> server is removed also remove the corresponding repl >>>>>>>>>>>> agreements >>>>>>>>>>> Why should we "keep it internally" ? >>>>>>>>>>> If you mark the agreements as managed by setting an >>>>>>>>>>> attribute on them, then you will never have any issue >>>>>>>>>>> recognizing a "managed" agreement in cn=config, and you >>>>>>>>>>> will also immediately find out it is "old" as it is not >>>>>>>>>>> backed by a segment so you will safely remove it. >>>>>>>>>> I didn't want to add new flags/fields to the replication >>>>>>>>>> agreements as long as anything can be handled by the data in >>>>>>>>>> the shared tree. >>>>>>>>> We have too. I think it is a must or we will find numerous >>>>>>>>> corner cases. Is there a specific reason why you do not want >>>>>>>>> to add flags to replication agreements in cn=config ? >>>>>>>> Simo and I had a discussion on this and had agreed that the >>>>>>>> "marking" of a replication agreement >>>>>>>> as controlled by the plugin could be done by a naming >>>>>>>> convention on the replication agreements. >>>>>>>> They are originally created as "cn=meTo,..." and >>>>>>>> would be renamed to something like >>>>>>>> "cn=-to-,....." avoiding to add a new >>>>>>>> attribute to the repl agreement schema. >>>>>>>> >>>>>>>> Unfortunately this does not work out of the box. I only >>>>>>>> discovered afetr implementing and testing (was not aware of >>>>>>>> before :-) that DS does not implement modrdn operation for >>>>>>>> internal backends, It just returns unwilling_to_perform. >>>>>>>> And if it will be implemented the replication plugin will have >>>>>>>> to be changed as well to catch the mordrdn to update the in >>>>>>>> memory objects with the new name (which is used in logging). >>>>>>>> >>>>>>>> So, if there is no objection, I will go back to the "flag" >>>>>>>> solution. >>>>>>> What about simply deleting the agreement and adding it back with >>>>>>> the new name ? >>>>>> it will stop replication and the restart it again, unnecessary >>>>>> interrupting replication for some time. >>>>>> Assume you have a working topology and then raise the domain >>>>>> level and the plugin becomes active, >>>>>> creates segments and "marks" agreements as controlled. This >>>>>> should happen as smooth as >>>>>> possible. >>>>> While this is true, it is also a rare operation. I do not see it >>>>> as a big deal to be honest. >>>>> However if you prefer to add a flag attribute that is fine by me >>>>> too. >>>> after thinking a bit more about it, I don't think we need the mark >>>> at all. >>> We discussed this already and we came to the conclusion we need >>> it :) >> ok, I think in the discussion we came up with the mark was with my >> concerns about >> removing a replica, and you more or less destroyed my concerns. >> I agree there could be some corner cases like the ones you sketch >> below. But it will still be difficult to do the right thing in all >> cases. Take your example of a marked agreement and no segment. we >> could arrive at this state >> in two different scenarios: >> 1] >> - take a backup of the shared database >> - add a segment, a RA will be created and marked >> - the database gets corrupted and you restore the backup >> - the agmt is marked and no segment exists - should we really delete >> the agmt ? > Yes. > The shared tree is the authoritative repository. If you restore you > are required to do due diligence and check what was lost and restore > that too. ok, if we agree on this, we need the mark , convinced again:-) > >> 2] >> - have a segment and a marked agreement >> - take a backup of the dse.ldif >> - delete the segment, agmt is removed >> - restore the dse.ldif, >> - the agmt is marked, no segment exists > Yes, this is the scenario I was hinting at, it the agreement is marked > we know it is not something we need to import (it was already imported) > so we just go on and delete it. > >>>> The agreement would have been marked in two scenarios >>>> - the agreement exists and the dom level is raised, so that a >>>> segment is created from the agreement >>>> - the dom level is set, the plugin active and a segment is addded >>>> to the shared tree so that a replication agreement is generated. >>>> In all cases where an agreement is marked, there is a 1:1 >>>> corresponding segment, so the existence of a segment should be >>>> marking enough. I will make the mark_agreement and check_mark as >>>> noops, so if we really run into a >>>> scenario where a mark would be required, it can be added in one of >>>> the methods discussed >>>> so far. >>> I recall the problems came in corner cases. Like when a replica >>> starts and finds an agreement. >>> If it is marked and a segment does not exist, we simply delete it. >>> However if it not marked and a segment does not exist, what do you >>> do ? Without markings you can only import it, and this way you may >>> end up reviving deleted agreements by mistake. >>> >>> The reason this may happen is that cn=config and the main database >>> are separate, and a backup dse.ldif may be use upon start even >>> though the shared database had been already updated, so we cannot >>> count on the replica starting and finding the >>> segment-to-be-deleted-via-replication still there. >>> >>> The marking was needed to make sure that once an agreement was >>> imported we wouldn't do it again later on. >>> I still maintain that marking it is safer and will lead to less >>> issues with phantom segments coming back to life. >>> >>> Simo. >>> >>> > > From thozza at redhat.com Fri Jan 9 15:34:45 2015 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 09 Jan 2015 16:34:45 +0100 Subject: [Freeipa-devel] [PATCH 0315] Support BIND 9.10 In-Reply-To: <54808612.6040309@redhat.com> References: <54808612.6040309@redhat.com> Message-ID: <54AFF515.1010704@redhat.com> On 12/04/2014 05:04 PM, Petr Spacek wrote: > Hello, > > Support BIND 9.10. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/139 > > > This patch definitely needs more testing but ...: > - It compiles with BIND 9.9 and BIND 9.10. > - It seems that it is able to load master and forward zones. > - Basic dynamic updates work. > > I did not test other features yet. > ACK. The driver compiles with BIND 9.10 and works with IPA. I tested basic usage. BTW available in COPR: http://copr-fe.cloud.fedoraproject.org/coprs/thozza/bind-9.10/ Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From pspacek at redhat.com Mon Jan 12 08:29:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Jan 2015 09:29:21 +0100 Subject: [Freeipa-devel] Reviewed-By for design pages? In-Reply-To: <54AFD705.3080907@redhat.com> References: <54ACFDC3.5080001@redhat.com> <20150107103851.2dfa2fe1@willson.usersys.redhat.com> <20150107164121.GL16288@redhat.com> <54AFD705.3080907@redhat.com> Message-ID: <54B385E1.3060307@redhat.com> On 9.1.2015 14:26, Martin Kosek wrote: > On 01/07/2015 05:41 PM, Alexander Bokovoy wrote: >> On Wed, 07 Jan 2015, Simo Sorce wrote: >>> On Wed, 07 Jan 2015 10:34:59 +0100 >>> Petr Spacek wrote: >>> >>>> Hello, >>>> >>>> I wonder if we should add something like Reviewed-by tag to newly >>>> created design pages. It would serve as reminder and check that page >>>> was really reviewed by someone. (And that we should not spend much >>>> time on implementation before the tag is present on the page.) >>>> >>>> It will also add 'psychological pressure' to the reviewer because his >>>> name will be on the design page forever :-) >>>> >>> >>> +1 >> +1 too. > > Maybe we could move "author" and "reviewer" to the Feature info box with > feature page metadata? (see box e.g. in http://www.freeipa.org/page/V4/OTP) > > I just wonder that, given that authorship and review is often collaborative > work, multiple people may be interested to be listed in these fields in the > info box or the page itself. Feature box is IMHO a nice idea. I was also wondering about templates like {{review_pending}} and {{review_done}} with some nice icons - to make obvious if the design is ready for implementation or not (yet). Review-done icon: http://commons.wikimedia.org/wiki/File:Green_tick.svg Review-pending icon: http://commons.wikimedia.org/wiki/File:Incomplete.svg (Both icons are in public domain.) -- Petr^2 Spacek From mkosek at redhat.com Mon Jan 12 11:19:52 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Jan 2015 12:19:52 +0100 Subject: [Freeipa-devel] Reviewed-By for design pages? In-Reply-To: <54B385E1.3060307@redhat.com> References: <54ACFDC3.5080001@redhat.com> <20150107103851.2dfa2fe1@willson.usersys.redhat.com> <20150107164121.GL16288@redhat.com> <54AFD705.3080907@redhat.com> <54B385E1.3060307@redhat.com> Message-ID: <54B3ADD8.8090502@redhat.com> On 01/12/2015 09:29 AM, Petr Spacek wrote: > On 9.1.2015 14:26, Martin Kosek wrote: >> On 01/07/2015 05:41 PM, Alexander Bokovoy wrote: >>> On Wed, 07 Jan 2015, Simo Sorce wrote: >>>> On Wed, 07 Jan 2015 10:34:59 +0100 >>>> Petr Spacek wrote: >>>> >>>>> Hello, >>>>> >>>>> I wonder if we should add something like Reviewed-by tag to newly >>>>> created design pages. It would serve as reminder and check that page >>>>> was really reviewed by someone. (And that we should not spend much >>>>> time on implementation before the tag is present on the page.) >>>>> >>>>> It will also add 'psychological pressure' to the reviewer because his >>>>> name will be on the design page forever :-) >>>>> >>>> >>>> +1 >>> +1 too. >> >> Maybe we could move "author" and "reviewer" to the Feature info box with >> feature page metadata? (see box e.g. in http://www.freeipa.org/page/V4/OTP) >> >> I just wonder that, given that authorship and review is often collaborative >> work, multiple people may be interested to be listed in these fields in the >> info box or the page itself. > > Feature box is IMHO a nice idea. > > I was also wondering about templates like {{review_pending}} and > {{review_done}} with some nice icons - to make obvious if the design is ready > for implementation or not (yet). > > Review-done icon: > http://commons.wikimedia.org/wiki/File:Green_tick.svg > > Review-pending icon: > http://commons.wikimedia.org/wiki/File:Incomplete.svg > > (Both icons are in public domain.) > Thanks for this tip, makes sense. I incorporated the author and reviewer fields in the Feature box (no additional template needed). See the result: Missing review box: http://www.freeipa.org/page/V4/Manage_replication_topology Completed review: https://www.freeipa.org/page/V4/Replica_Promotion The logic is that when "reviewer" field is missing (the default), "missing reviewer" text appears. When reviewer is added, his name is there. I am not completely satisfied with the formatting/links of the names though, currently the code is: {{Feature|version=TODO|ticket=TODO|author=[[User:SimoSorce|Simo Sorce]], [[User:MKosek|Martin Kosek]]|reviewer=[[User:MKosek|Martin Kosek]]}} But it may be better to just use wiki user names and let the template generate the User page links itself. I.e.: {{Feature|version=TODO|ticket=TODO|author=SimoSorce, MKosek|reviewer=Mkosek}} From pviktori at redhat.com Mon Jan 12 11:38:49 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Jan 2015 12:38:49 +0100 Subject: [Freeipa-devel] ipalib as RPC client in Web UI CI tests, forms-based auth in ipalib In-Reply-To: <54AE96A0.5090508@redhat.com> References: <54AE96A0.5090508@redhat.com> Message-ID: <54B3B249.9070902@redhat.com> On 01/08/2015 03:39 PM, Petr Vobornik wrote: > Hello, > > tl;dr; I want to add forms based auth in ipalib's rpc client and use > method 2.e) for API configuration. Will be used in otp tests (ipa-4-1 > upstream). Want to know if you are OK with it. PoC implementation attached. > > == Background == > I want to call FreeIPA API from our Web UI CI tests. > > Uses case are: > * speed up data preparation (the biggest time consumer in Web UI tests) > * prepare data or do stuff which could not be done in Web UI (little bit > part of https://fedorahosted.org/freeipa/ticket/4772) > > For this task I want to reuse ipalib's rpcclient to avoid yet another > RPC client implementation. > > Plan is to use it in OTP web ui tests. > > == ipalib limitations == > Please note that web ui tests could be run as a normal user on a machine > which is not a FreeIPA client, i.e. on developers machine with local > browser to observe the progress. > > === 1 Forms based authentication === > ipalib doesn't support forms-based auth and kerberos might not be > available. I have investigated the option to add forms auth and managed > to write a PoC patch(attached) which enables it. Question is whether we > want to allow it in ipalib even for non-test uses cases. I think it > could be beneficial for some users. > > === 2 API/environment finalization in ipalib/__init__.py for tests === > Tests which are run by make-test are initialized with > os.environ['IPA_UNIT_TEST_MODE'] = 'cli_test' > > in such case, ipalib automatically finalizes API. Unfortunately the > default configuration is unusable if run on a machine without IPA > configuration files (~/.ipa/default.conf, /etc/ipa/default.conf, ...). > We can't even supply the values afterwards because api.env is 'set-once' > object. > > There are several approaches which could be taken: > Proper fixes: > a) Finish the idea, mentioned in Registry, of storing plugin > registrations to allow multiple API creation with all plugins and > therefore custom instances of API. Would be probably quite a lot of work > because of wide use of global api object. I.e., various test can use > their own instance of api. > > b) Remove the API initialization in ipalib/__init__.py. Initialize API > only in tests which use it. Without a) It might suffer from the same > issue as d) > > c) Remove 'set-once' constraint from Env object to allow config change > after API initialization > > Workarounds: > d) Change the os.env variable to a different than 'cli_test' value > before api import in uidriver.py to prevent the automatic > initialization. Init api in Web UI tests. Might cause issues if other > tests were run and initialized api before Web ui tests. > > e) override values in Env object by a hack: > object.__setattr__(api.env, key, val) > api.env._Env__d[key] = val > Advantage is that it's self-contained in Web UI tests. Must be changed > back at the end of test not to interfere with other tests. > > f) require IPA configuration file even on non-ipa client machines. Easy, > but not very pleasant for user - all required configuration values are > already present in webui test config file or in env variables -> > multiple files has to be changed when switching between testing > instances(frequent use case). > > g) other > > From longer perspective I would like to see a) and b), maybe c). But I > would like to use this feature in otptests which should land in 4.1 -> > a) is not an option because of its complexity. Therefore, atm, I would > like to go with e) or c) Yes, a) is the proper solution, and when it's done b) can be started gradually, in tests that need a different API. If there's no time to do that, go with e), which is a localized change. For c) you'd want to think through carefully ? and at that point you could just do a) first. -- Petr? From dkupka at redhat.com Mon Jan 12 11:53:42 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 12 Jan 2015 12:53:42 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. Message-ID: <54B3B5C6.7000802@redhat.com> https://fedorahosted.org/freeipa/ticket/4823 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0036-Abort-full-backup-restoration-on-not-matching-host.patch Type: text/x-patch Size: 1303 bytes Desc: not available URL: From mkosek at redhat.com Mon Jan 12 12:08:43 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Jan 2015 13:08:43 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3B5C6.7000802@redhat.com> References: <54B3B5C6.7000802@redhat.com> Message-ID: <54B3B94B.4040902@redhat.com> On 01/12/2015 12:53 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4823 Looking at this patch, are data-only backups supposed to work properly then? Wouldn't for example Directory Server fail to start when cn=config contain some hostname-bound values? Just checking... From mbasti at redhat.com Mon Jan 12 12:11:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Jan 2015 13:11:19 +0100 Subject: [Freeipa-devel] [PATCH 0182] Fix pkcs11 python extension reference counting Message-ID: <54B3B9E7.501@redhat.com> Part of DNSSEC (https://fedorahosted.org/freeipa/ticket/4657) Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0182-Fix-reference-counting-in-pkcs11-extension.patch Type: text/x-patch Size: 7015 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 12 12:14:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Jan 2015 13:14:37 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3B94B.4040902@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> Message-ID: <54B3BAAD.4080406@redhat.com> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): > On 01/12/2015 12:53 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4823 > > Looking at this patch, are data-only backups supposed to work properly then? > Wouldn't for example Directory Server fail to start when cn=config contain some > hostname-bound values? > > Just checking... > IMO the error should be raised in both data-only and full restore, if in unattended mode or the user wishes not to continue. -- Jan Cholasta From mbasti at redhat.com Mon Jan 12 12:25:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Jan 2015 13:25:10 +0100 Subject: [Freeipa-devel] [PATCH 0179] Fix traceback if zonemgr error message contains unicode characters In-Reply-To: <54AFD2A2.9070204@redhat.com> References: <548AED1E.2020308@redhat.com> <54AFD2A2.9070204@redhat.com> Message-ID: <54B3BD26.4060405@redhat.com> On 09/01/15 14:07, David Kupka wrote: > On 12/12/2014 02:26 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4805 >> >> Patch attached. >> >> > Does not work properly. > > $ locale > LANG=cs_CZ.iso88592 > LC_CTYPE="cs_CZ.iso88592" > LC_NUMERIC="cs_CZ.iso88592" > LC_TIME="cs_CZ.iso88592" > LC_COLLATE="cs_CZ.iso88592" > LC_MONETARY="cs_CZ.iso88592" > LC_MESSAGES="cs_CZ.iso88592" > LC_PAPER="cs_CZ.iso88592" > LC_NAME="cs_CZ.iso88592" > LC_ADDRESS="cs_CZ.iso88592" > LC_TELEPHONE="cs_CZ.iso88592" > LC_MEASUREMENT="cs_CZ.iso88592" > LC_IDENTIFICATION="cs_CZ.iso88592" > LC_ALL=cs_CZ.iso88592 > > $ sudo ipa-server-install --setup-dns --forwarder=10.65.201.89 -r > TESTRELM.TEST -p xxxxxxxx -P xxxxxxxx -a xxxxxxxx > --zonemg=?a?ko at redhat.com -U > > /tmp/ipaserverinstall_invalidzonemgr.out 2>&1 > > $ cat /tmp/ipaserverinstall_invalidzonemgr.out > Usage: ipa-server-install [options] > > ipa-server-install: error: invalid zonemgr: domain name > '??a??ko.redhat.com' should be normalized to: ??a??ko.redhat.com > > The provided value isn't right and must be normalized but the one > displayed in error message doesn't match. > >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Sorry, but it works for me. I tested it with LC_ALL=sk_SK.ISO-8859-2 -- Martin Basti From dkupka at redhat.com Mon Jan 12 12:37:01 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 12 Jan 2015 13:37:01 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3BAAD.4080406@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> Message-ID: <54B3BFED.2070201@redhat.com> On 01/12/2015 01:14 PM, Jan Cholasta wrote: > Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >> On 01/12/2015 12:53 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4823 >> >> Looking at this patch, are data-only backups supposed to work properly >> then? >> Wouldn't for example Directory Server fail to start when cn=config >> contain some >> hostname-bound values? >> >> Just checking... >> > > IMO the error should be raised in both data-only and full restore, if in > unattended mode or the user wishes not to continue. > Description of the problem in ticket states: "I tried to run ipa-restore (full kind) on replica from full backup taken on master and was expecting an error message that restore can not proceed and only data restore possible." I created the patch based on this request. Is it wrong and should ipa-restore fail every time when hostnames does not match? Does it make sense to allow user to force the restoration in this case? Thanks for clarification. -- David Kupka From mkosek at redhat.com Mon Jan 12 12:40:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Jan 2015 13:40:18 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3BFED.2070201@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> Message-ID: <54B3C0B2.9060400@redhat.com> On 01/12/2015 01:37 PM, David Kupka wrote: > On 01/12/2015 01:14 PM, Jan Cholasta wrote: >> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4823 >>> >>> Looking at this patch, are data-only backups supposed to work properly >>> then? >>> Wouldn't for example Directory Server fail to start when cn=config >>> contain some >>> hostname-bound values? >>> >>> Just checking... >>> >> >> IMO the error should be raised in both data-only and full restore, if in >> unattended mode or the user wishes not to continue. >> > Description of the problem in ticket states: "I tried to run ipa-restore (full > kind) on replica from full backup taken on master and was expecting an error > message that restore can not proceed and only data restore possible." That report does not discuss data-only backups at all. That does not mean they do not need to be taken care of. > I created the patch based on this request. Is it wrong and should ipa-restore > fail every time when hostnames does not match? Does it make sense to allow user > to force the restoration in this case? Thanks for clarification. I think the behavior that Jan proposed is fine, i.e. warn and ask in attended mode, fail in unattended mode. Martin From jcholast at redhat.com Mon Jan 12 12:41:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Jan 2015 13:41:35 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3BFED.2070201@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> Message-ID: <54B3C0FF.7030809@redhat.com> Dne 12.1.2015 v 13:37 David Kupka napsal(a): > On 01/12/2015 01:14 PM, Jan Cholasta wrote: >> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4823 >>> >>> Looking at this patch, are data-only backups supposed to work properly >>> then? >>> Wouldn't for example Directory Server fail to start when cn=config >>> contain some >>> hostname-bound values? >>> >>> Just checking... >>> >> >> IMO the error should be raised in both data-only and full restore, if in >> unattended mode or the user wishes not to continue. >> > Description of the problem in ticket states: "I tried to run ipa-restore > (full kind) on replica from full backup taken on master and was > expecting an error message that restore can not proceed and only data > restore possible." > > I created the patch based on this request. Is it wrong and should > ipa-restore fail every time when hostnames does not match? Yes, as Martin pointed out, the data may contain references to the hostname. > Does it make > sense to allow user to force the restoration in this case? Yes, if the users wish, they should be allowed to continue. > Thanks for > clarification. > -- Jan Cholasta From mkosek at redhat.com Mon Jan 12 12:48:19 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Jan 2015 13:48:19 +0100 Subject: [Freeipa-devel] [PATCH] 487 Bump SSSD Requires to 1.12.3 Message-ID: <54B3C293.5030209@redhat.com> The new SSSD Requires contains support for following features: - FreeIPA user ID View overrides (not just AD users) - User SSH public keys in ID Views - krb5.conf localauth plugin https://fedorahosted.org/freeipa/ticket/4685 https://fedorahosted.org/freeipa/ticket/4509 https://fedorahosted.org/freeipa/ticket/4514 ----- SSSD build is in koji and our Copr repo as well. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-487-bump-sssd-requires-to-1.12.3.patch Type: text/x-patch Size: 1028 bytes Desc: not available URL: From dkupka at redhat.com Mon Jan 12 12:56:05 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 12 Jan 2015 13:56:05 +0100 Subject: [Freeipa-devel] [PATCH 0179] Fix traceback if zonemgr error message contains unicode characters In-Reply-To: <54B3BD26.4060405@redhat.com> References: <548AED1E.2020308@redhat.com> <54AFD2A2.9070204@redhat.com> <54B3BD26.4060405@redhat.com> Message-ID: <54B3C465.3030603@redhat.com> On 01/12/2015 01:25 PM, Martin Basti wrote: > On 09/01/15 14:07, David Kupka wrote: >> On 12/12/2014 02:26 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/4805 >>> >>> Patch attached. >>> >>> >> Does not work properly. >> >> $ locale >> LANG=cs_CZ.iso88592 >> LC_CTYPE="cs_CZ.iso88592" >> LC_NUMERIC="cs_CZ.iso88592" >> LC_TIME="cs_CZ.iso88592" >> LC_COLLATE="cs_CZ.iso88592" >> LC_MONETARY="cs_CZ.iso88592" >> LC_MESSAGES="cs_CZ.iso88592" >> LC_PAPER="cs_CZ.iso88592" >> LC_NAME="cs_CZ.iso88592" >> LC_ADDRESS="cs_CZ.iso88592" >> LC_TELEPHONE="cs_CZ.iso88592" >> LC_MEASUREMENT="cs_CZ.iso88592" >> LC_IDENTIFICATION="cs_CZ.iso88592" >> LC_ALL=cs_CZ.iso88592 >> >> $ sudo ipa-server-install --setup-dns --forwarder=10.65.201.89 -r >> TESTRELM.TEST -p xxxxxxxx -P xxxxxxxx -a xxxxxxxx >> --zonemg=?a?ko at redhat.com -U > >> /tmp/ipaserverinstall_invalidzonemgr.out 2>&1 >> >> $ cat /tmp/ipaserverinstall_invalidzonemgr.out >> Usage: ipa-server-install [options] >> >> ipa-server-install: error: invalid zonemgr: domain name >> '??a??ko.redhat.com' should be normalized to: ??a??ko.redhat.com >> >> The provided value isn't right and must be normalized but the one >> displayed in error message doesn't match. >> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> > Sorry, but it works for me. I tested it with > LC_ALL=sk_SK.ISO-8859-2 > You're right I probably miss-configured the encoding in Konsole. Now I've tried it again and it works, ACK. -- David Kupka P.S.: Sorry for unjustified NACK. From jcholast at redhat.com Mon Jan 12 13:28:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Jan 2015 14:28:17 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options Message-ID: <54B3CBF1.602@redhat.com> Hi, the attached patch fixes . Note that --data with data-only backup and --logs-only with data-only restore are deliberately ignored and considered no-op. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-387-Fix-validation-of-ipa-restore-options.patch Type: text/x-patch Size: 12274 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jan 12 13:31:18 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 Jan 2015 14:31:18 +0100 Subject: [Freeipa-devel] [PATCH] 796 migrate-ds: fix compat plugin check Message-ID: <54B3CCA6.1@redhat.com> [PATCH] migrate-ds: fix compat plugin check After ACI refactoring, admin cannot read Schema Compatibility plugin configuration and therefore migrade-ds won't find if compat plugin is enabled. Now the check si done by looking if cn=compat subtree is present. https://fedorahosted.org/freeipa/ticket/4825 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0796-migrate-ds-fix-compat-plugin-check.patch Type: text/x-patch Size: 1782 bytes Desc: not available URL: From dkupka at redhat.com Mon Jan 12 13:49:45 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 12 Jan 2015 14:49:45 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3C0FF.7030809@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> Message-ID: <54B3D0F9.9000107@redhat.com> On 01/12/2015 01:41 PM, Jan Cholasta wrote: > Dne 12.1.2015 v 13:37 David Kupka napsal(a): >> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>> >>>> Looking at this patch, are data-only backups supposed to work properly >>>> then? >>>> Wouldn't for example Directory Server fail to start when cn=config >>>> contain some >>>> hostname-bound values? >>>> >>>> Just checking... >>>> >>> >>> IMO the error should be raised in both data-only and full restore, if in >>> unattended mode or the user wishes not to continue. >>> >> Description of the problem in ticket states: "I tried to run ipa-restore >> (full kind) on replica from full backup taken on master and was >> expecting an error message that restore can not proceed and only data >> restore possible." >> >> I created the patch based on this request. Is it wrong and should >> ipa-restore fail every time when hostnames does not match? > > Yes, as Martin pointed out, the data may contain references to the > hostname. > >> Does it make >> sense to allow user to force the restoration in this case? > > Yes, if the users wish, they should be allowed to continue. > >> Thanks for >> clarification. >> > Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0036-2-Abort-backup-restoration-on-not-matching-host-in-una.patch Type: text/x-patch Size: 1353 bytes Desc: not available URL: From pspacek at redhat.com Mon Jan 12 14:28:34 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Jan 2015 15:28:34 +0100 Subject: [Freeipa-devel] [PATCH 0315] Support BIND 9.10 In-Reply-To: <54AFF515.1010704@redhat.com> References: <54808612.6040309@redhat.com> <54AFF515.1010704@redhat.com> Message-ID: <54B3DA12.8080706@redhat.com> On 9.1.2015 16:34, Tomas Hozza wrote: > On 12/04/2014 05:04 PM, Petr Spacek wrote: >> Hello, >> >> Support BIND 9.10. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/139 >> >> >> This patch definitely needs more testing but ...: >> - It compiles with BIND 9.9 and BIND 9.10. >> - It seems that it is able to load master and forward zones. >> - Basic dynamic updates work. >> >> I did not test other features yet. >> > ACK. Thank you! I have branched v6 before push so v6 stays at 5adca1bbfc2c19c53ecda649b94960f6abe73cf6 ... and pushed this patch to master (to-be-v7): 7101194d6bcf99c8cc5c8fec405ee716cd6e7b07 -- Petr^2 Spacek From pspacek at redhat.com Mon Jan 12 14:29:20 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Jan 2015 15:29:20 +0100 Subject: [Freeipa-devel] [PATCH 0317-0318] Preparation for 7.0 release Message-ID: <54B3DA40.4070108@redhat.com> Hello, I'm going to release v7.0 with BIND 9.10 support. Following patches were pushed to master: Bump NVR to 7.0. 257618e618a27b3c818f75faf5762130df0701eb Update NEWS for upcoming 7.0 release. c125f23501f8c53047375e45b72e73690fe791a3 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0317-Update-NEWS-for-upcoming-7.0-release.patch Type: text/x-patch Size: 624 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0318-Bump-NVR-to-7.0.patch Type: text/x-patch Size: 1146 bytes Desc: not available URL: From pviktori at redhat.com Mon Jan 12 14:53:18 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Jan 2015 15:53:18 +0100 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <1420511219.3049.11.camel@redhat.com> References: <1416499988.2902.11.camel@redhat.com> <1420511219.3049.11.camel@redhat.com> Message-ID: <54B3DFDE.9090608@redhat.com> On 01/06/2015 03:26 AM, Nathaniel McCallum wrote: > On Thu, 2014-11-20 at 11:13 -0500, Nathaniel McCallum wrote: >> >This tests the general workflow for OTP including most possible >> >token combinations. This includes 5872 tests. Further optimization >> >is possible to reduce the number of duplicate tests run. >> > >> >Things not yet tested: >> >* ipa-kdb >> >* ipa-otpd >> >* otptoken-sync >> >* RADIUS proxy >> >* token self-management >> >* type specific attributes > Attached is the latest iteration of the OTP test work. This now includes > all major cases except token self-management and RADIUS proxy (which > will come in its own patch). Token self-management is held up by the > fact that I can't get alternate ccaches to work with the API. I have > tried kinit-ing to an independent ccache and exporting KRB5CCNAME, but > this doesn't work for some reason I can't figure out. > > I ended up creating my own fixture mechanism. I'm not in love with it, > but it is simple and at least gets the scoping correct. It also > generates individual tests for each parameterized state, so the output > is both correct and obvious. > > I also implemented OTP myself. This isn't much code, but pyotp has a > major bug and is dead upstream. I'd like to migrate to > python-cryptography when it lands as a dependency of FreeIPA. But due to > timing issues, we can't land it now. This will be a small patch in the > future. > > Even with the caveats above, I feel like the test coverage provided by > this test is worth review/merge. As a rough estimate, I think this is > about 70% code coverage. Of the remaining coverage, I see: > * RADIUS proxy - 10% > * token self-management - 10% > * misc testable - 5% > * misc untestable - 5% > > All tests in this patch succeed on 4.1.2. It doesn't work for me on the 4.2 branch, see the attached errors. Not sure what I'm doing wrong. See some comments andnitpicks inline. > > freeipa-npmccallum-0081.1-Add-initial-tests-for-OTP.patch > > > From c7b01ea4415db3847110ffe51a9bb5193072d1a8 Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Thu, 20 Nov 2014 11:02:00 -0500 > Subject: [PATCH] Add initial tests for OTP > > This tests the general workflow for OTP including most possible > token combinations. It includes tests for all token options, > enablement scenarios and token synchronization. > --- > ipatests/test_xmlrpc/test_otptoken_plugin.py | 536 +++++++++++++++++++++++++++ > 1 file changed, 536 insertions(+) > create mode 100644 ipatests/test_xmlrpc/test_otptoken_plugin.py > > diff --git a/ipatests/test_xmlrpc/test_otptoken_plugin.py b/ipatests/test_xmlrpc/test_otptoken_plugin.py > new file mode 100644 > index 0000000000000000000000000000000000000000..7a27d720cb9789c648e45aece1ebd0b6b751e3d8 > --- /dev/null > +++ b/ipatests/test_xmlrpc/test_otptoken_plugin.py > @@ -0,0 +1,536 @@ > +# Authors: > +# Nathaniel McCallum > +# > +# Copyright (C) 2014 Red Hat > +# see file 'COPYING' for use and warranty information > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation, either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see. > + > +""" > +Test the `ipalib/plugins/otptoken.py` module. > +""" > + > +import abc > +import base64 > +import hashlib > +import hmac > +import os > +import unittest > +import urlparse > +import uuid > +import random > +import string > +import struct > +import subprocess > +import time > +import types > + > +from datetime import datetime, timedelta > + > +from ipalib import api > +from xmlrpc_test import XMLRPC_test, Declarative ^ unused > +from ipatests.util import assert_deepequal, raises I recommend nose.tools.assert_raises rather than ipatests.util.raises -- it's easier to debug if an unexpected error occurs. > +from ipapython.version import API_VERSION > +from ipapython.dn import DN > +import ldap > + > + > +class Fixture(object): > + __metaclass__ = abc.ABCMeta > + > + @property > + def context(self): > + try: > + return self.__fixtures > + except AttributeError: > + return tuple() > + > + @context.setter > + def context(self, value): > + self.__fixtures = value > + > + @abc.abstractmethod > + def __enter__(self): > + raise NotImplementedError() > + > + @abc.abstractmethod > + def __exit__(self, type, value, traceback): > + raise NotImplementedError() > + > + def __repr__(self): > + return '%s()' % self.__class__.__name__ It seems that this class could be written as: class Fixture(object): context = () and all the rest except __repr__ is unnecessary. For documenting what subclasses should add/override, a mention in a docstring might be more helpful than ABC stubs. > +def fixturize(*args): > + def outer(func): > + def inner(s, fixtures=args, ctx=()): > + try: > + fixture = fixtures[0] > + except IndexError: > + yield (lambda *a: func(s, *a),) + ctx > + else: > + for f in fixture if type(fixture) is tuple else (fixture,): > + if isinstance(f, Fixture): > + f.context = ctx > + > + if hasattr(f, "__enter__"): > + with f as tmp: > + for test in inner(s, fixtures[1:], ctx + (tmp,)): > + yield test > + else: > + for test in inner(s, fixtures[1:], ctx + (f,)): > + yield test > + > + inner.__name__ = func.__name__ > + return inner > + return outer Well, that works. A docstring would be really nice though. > +def cmd(cmd, *args, **kwargs): > + return api.Command[cmd](*args, version=API_VERSION, **kwargs) This requires rpcclient to be connected. See the XMLRPC_test class for the necessary setup. > +class AuthenticationError(Exception): > + pass > + > + > +class Login(object): > + def __repr__(self): > + return '%s()' % self.__class__.__name__ > + > + def __init__(self): > + self.__fails = 0 > + > + def __call__(self, uid, pwd): > + try: > + self.login(uid, pwd) > + self.__fails = 0 > + except: > + self.__fails += 1 > + if self.__fails > 2: > + cmd('user_unlock', uid) > + self.__fails = 0 > + raise I'm not sure what you're doing here. > + > + def login(self, uid, pwd): > + raise NotImplementedError() > + > + > +class LDAPLogin(Login): > + def __init__(self): > + super(LDAPLogin, self).__init__() > + > + self.__conn = ldap.initialize('ldap://' + api.env.host) > + > + def login(self, uid, pwd): > + dn = DN(('uid', uid), api.env.container_user, api.env.basedn) > + try: > + self.__conn.simple_bind_s(str(dn), pwd) > + except ldap.INVALID_CREDENTIALS as e: > + raise AuthenticationError(e.message) > + > + > +class Krb5Login(Login): > + def __init__(self): > + super(Krb5Login, self).__init__() > + > + self.__fast = subprocess.Popen( > + ['/usr/bin/klist'], > + stdout=subprocess.PIPE > + ).communicate()[0].split('\n')[0].split(': ')[1] > + > + def kinit(self, uid, pwd, newpwd=None, ccache="FILE:/dev/null"): > + data = pwd + '\n' > + if newpwd is not None: > + data += newpwd + '\n' + newpwd + '\n' > + > + p = subprocess.Popen( > + ['/usr/bin/kinit', > + '-T', self.__fast, > + '-c', ccache, > + uid + '@' + api.env.realm], > + stdin=subprocess.PIPE, > + stdout=subprocess.PIPE, > + stderr=subprocess.PIPE > + ) > + out, err = p.communicate(data) Can you use ipautil.run here? > + if p.returncode != 0: > + raise AuthenticationError(out, err) > + > + def login(self, uid, pwd): > + self.kinit(uid, pwd) > + > + > +class User(Fixture): > + def __init__(self, **kwargs): > + self.username = u''.join(random.sample(string.lowercase, 20)) > + self.password = u''.join(random.sample(string.letters, 20)) Could you prefix the test user with `test`, so it's identifiable when it doesn't get deleted for some reason? > + self.__kwargs = kwargs > + > + def __enter__(self): > + cmd('user_add', self.username, > + userpassword=self.password, > + givenname=self.username[:len(self.username) / 2], > + sn=self.username[len(self.username) / 2:], > + **self.__kwargs) > + > + # Change password > + Krb5Login().kinit(self.username, self.password, self.password) > + return self > + > + def __exit__(self, type, value, traceback): > + cmd('user_del', self.username) > + > + > +class Enablement(Fixture): > + def __repr__(self): > + return "Enablement(%s)" % ("user" if self.user else "global") > + > + def __set_authtype(self, authtype): > + if self.user: > + for fixture in self.context: > + if isinstance(fixture, User): > + cmd('user_mod', fixture.username, ipauserauthtype=authtype) > + return > + assert False > + else: > + cmd('config_mod', ipauserauthtype=authtype) > + time.sleep(60) # Work around cfg update hack in ipa-kdb The config_mod might raise EmptyModList which you should ignore. > + > + def __init__(self, user=True): > + self.user = user > + > + def __enter__(self): > + self.__set_authtype((u'otp',)) > + return self > + > + def __exit__(self, type, value, traceback): > + self.__set_authtype(()) > + > + > +class Token(dict, Fixture): Why is Token a dict, as opposed to having a "params" dict? > + @property > + def type(self): > + return self[u'type'].upper() > + > + @property > + def active(self): > + if self.get(u'ipatokendisabled', False): > + return False > + > + nb = self.get(u'ipatokennotbefore', None) > + if nb is not None and datetime.now() < nb: > + return False > + > + na = self.get(u'ipatokennotafter', None) > + if na is not None and datetime.now() > na: > + return False > + > + return True > + > + def __repr__(self): > + prefixes = ['ipatoken' + x for x in ('totp', 'hotp', 'otp', '')] > + > + args = {} > + for k, v in self.items(): > + for prefix in prefixes: > + if k.startswith(prefix): > + k = k[len(prefix):] > + break > + > + if k in ('key', 'uniqueid', 'owner'): > + continue > + > + if isinstance(v, datetime): > + v = v.strftime("%Y%m%d%H%M%SZ") > + > + args[k] = v > + > + return "%s(%s:%d|%d%s%s%r)" % ( > + args.pop('type').upper(), > + args.pop('algorithm'), > + args.pop('digits'), > + args.pop('counter', args.pop('timestep', 0)), > + ':' if self.type == 'TOTP' else '', > + str(args.pop('clockoffset', '')), > + args > + ) > + > + def otp(self, at=0): > + # I first attempted implementing this with pyotp. However, pyotp has > + # a critical bug which appeared in testing. I fixed this bug and > + # submitted it upstream:https://github.com/nathforge/pyotp/pull/9 > + # > + # However, upstream pyotp appears to be dead. For now, I have > + # implemented the algorithm myself. In the future, it would be nice > + # to use python-cryptography here. > + > + # If the token is time-based, calculate the counter from the time. > + if self.type == u"TOTP": > + intrvl = self[u'ipatokentotptimestep'] > + offset = self.get(u'ipatokentotpclockoffset', 0) > + at = (time.time() + offset + intrvl * at) / intrvl > + > + # Otherwise, just account for the specified counter offset. > + elif self.type == u"HOTP": > + if at < 0: # Skip invalid test offsets. > + raise unittest.SkipTest() > + at += self.get(u'ipatokenhotpcounter', 0) > + > + # Create the HMAC of the current counter > + countr = struct.pack("!Q", at) > + hasher = getattr(hashlib, self[u'ipatokenotpalgorithm']) hashlib.new(self[u'ipatokenotpalgorithm']) should work > + digest = hmac.HMAC(self[u'ipatokenotpkey'], countr, hasher).digest() > + > + # Get the number of digits > + digits = self[u'ipatokenotpdigits'] > + > + # Truncate the digest > + offset = ord(digest[-1]) & 0xf > + binary = (ord(digest[offset+0]) & 0x7f) << 0x18 > + binary |= (ord(digest[offset+1]) & 0xff) << 0x10 > + binary |= (ord(digest[offset+2]) & 0xff) << 0x08 > + binary |= (ord(digest[offset+3]) & 0xff) << 0x00 > + binary = binary % (10 ** digits) > + > + return "0" * (digits - len(str(binary))) + str(binary) str(binary).rjust(digits, '0') > + def __init__(self, **kwargs): > + super(Token, self).__init__(**kwargs) > + > + # Add in default values. > + self.setdefault(u'ipatokenuniqueid', unicode(uuid.uuid4())) > + self.setdefault(u'ipatokenotpkey', os.urandom(20)) > + for i in range(len(api.Object['otptoken'].params)): > + param = api.Object['otptoken'].params[i] > + if param.default is not None and param.name: > + self.setdefault(param.name, param.default) > + > + # Remove defaults that don't apply. > + types = { > + "HOTP": (u'ipatokenhotpcounter',), > + "TOTP": (u'ipatokentotptimestep', u'ipatokentotpclockoffset'), > + } > + for k, names in types.items(): > + if k != self.type: > + for name in names: > + del self[name] > + > + def __enter__(self): > + kwargs = {} > + kwargs.update(self) kwargs = dict(self) > + # Get the owner from the user fixture. > + for fixture in self.context: > + if isinstance(fixture, User): > + kwargs[u'ipatokenowner'] = fixture.username > + break > + > + # Add the token. > + result = cmd('otptoken_add', **kwargs) > + > + try: > + # Remove the URI and validate the rest of the return value. > + uri = result.get('result', {}).pop('uri', None) > + expected = {} > + for k, v in kwargs.items(): > + if k == 'setattr': > + continue > + > + if isinstance(v, bool): > + expected[k] = (unicode(v).upper(),) > + elif isinstance(v, int): > + expected[k] = (unicode(v),) > + else: > + expected[k] = (v,) > + expected[u'type'] = expected[u'type'][0].upper() > + expected[u'dn'] = u'ipatokenuniqueid=%s,cn=otp,dc=example,dc=com' > + expected[u'dn'] %= self[u'ipatokenuniqueid'] That only works for dc=example,dc=com; use: DN(('ipatokenuniqueid', self[u'ipatokenuniqueid']), 'cn=otp', api.env.basedn) > + assert_deepequal({ > + u'summary': u'Added OTP token "%s"' % self[u'ipatokenuniqueid'], > + u'result': expected, > + u'value': self[u'ipatokenuniqueid'], > + }, result) > + > + # Validate the URI. > + split = urlparse.urlsplit(uri) > + assert split.scheme == u'otpauth' > + assert split.netloc.upper() == self.type > + assert split.path == '/%s@%s:%s' % ( > + kwargs[u'ipatokenowner'], > + api.env.realm, > + self[u'ipatokenuniqueid'] > + ) > + > + # Validate the query. > + types = { > + "HOTP": {u'counter': self.get(u'ipatokenhotpcounter')}, > + "TOTP": {u'period': self.get(u'ipatokentotptimestep')}, > + } > + query = { > + u'algorithm': self.get(u'ipatokenotpalgorithm'), > + u'issuer': u'%s@%s' % (kwargs[u'ipatokenowner'], api.env.realm), > + u'digits': self.get(u'ipatokenotpdigits'), > + u'secret': base64.b32encode(self[u'ipatokenotpkey']), > + } > + query.update(types.get(self.type, {})) > + assert_deepequal( > + {k: (unicode(v),) for k, v in query.items()}, > + urlparse.parse_qs(split.query) > + ) > + except: > + cmd('otptoken_del', self[u'ipatokenuniqueid']) > + raise > + > + return self > + > + def __exit__(self, type, value, traceback): > + cmd('otptoken_del', self[u'ipatokenuniqueid']) > + > + > +def auth(success, login, user, token, pwd=None, at=0): > + if pwd is None: > + pwd = user.password > + > + if isinstance(at, basestring): > + code = at > + > + else: > + code = token.otp(at) if token else '123456' > + if code is None: # Skip invalid test offsets. > + raise unittest.SkipTest() > + > + if success: > + login(user.username, pwd + code) > + else: > + raises(AuthenticationError, login, user.username, pwd + code) > + > + > +class TestEnablement: Classes should derive from object. (Same for TestTokens, TestSync) > + # This describes the success conditions for authentication. > + # 1. If user-auth-type does not include otp: password-only. > + # 2. Otherwise, if no token exists: password-only. > + # 3. Otherwise: password AND code. > + # > + # All states not accounted for here MUST fail. > + # > + # Format: (enabled, token created, pwd given, token given): success > + EXPECTATIONS = { > + (False, False, True, False): True, # Condition 1 > + (False, True, True, False): True, # Condition 1 > + (True, False, True, False): True, # Condition 2 > + (True, True, True, True): True, # Condition 3 > + } > + > + @fixturize(Krb5Login(), User(), ( > + None, > + Enablement(True), > + Enablement(False) > + ), ( > + None, > + Token() > + ), ( > + (True, None, ''), # Password-only > + (True, None, 0), # Both > + (False, '', 1), # Code-only > + (False, '', ''), # Neither > + (False, 'xxx', 2), # Bad password > + (False, None, '123456'), # Bad code > + ) > + ) > + def test(self, login, user, enablement, token, params): > + success, pwd, at = params > + > + if success: > + success = self.EXPECTATIONS.get(( > + enablement is not None, > + token is not None, > + pwd is None, > + isinstance(at, int) > + ), False) > + > + auth(success, login, user, token, pwd, at) > + > + > +class TestTokens: > + TODAY = datetime.now().replace(microsecond=0) > + TOMORROW = TODAY + timedelta(1) > + YESTERDAY = TODAY - timedelta(1) > + > + @fixturize( > + Krb5Login(), > + User(ipauserauthtype=(u'otp')), ( > + Token(type=u'hotp'), > + Token(type=u'HOTP'), > + Token(type=u'HOTP', ipatokenhotpcounter=1000), > + > + Token(type=u'totp'), > + Token(type=u'TOTP'), > + Token(type=u'TOTP', ipatokentotptimestep=60), > + Token(type=u'TOTP', ipatokentotpclockoffset=30000), > + > + Token(ipatokenotpalgorithm=u'sha1'), > + Token(ipatokenotpalgorithm=u'sha256'), > + Token(ipatokenotpalgorithm=u'sha384'), > + Token(ipatokenotpalgorithm=u'sha512'), > + > + Token(ipatokenotpdigits=6), > + Token(ipatokenotpdigits=8), > + > + Token(ipatokendisabled=False), > + Token(ipatokennotbefore=YESTERDAY), > + Token(ipatokennotafter=TOMORROW), > + > + Token(ipatokendisabled=True), > + Token(ipatokennotbefore=TOMORROW), > + Token(ipatokennotafter=YESTERDAY), > + ), ( > + (False, -1000), # Check distant past OTP > + (True, -2), # Check past OTP > + (True, 0), # Check current OTP > + (False, 0), # Check duplicate OTP > + (True, 1), # Check next OTP > + (True, 3), # Check future OTP > + (False, 1000), # Check distant future OTP > + ) > + ) > + def test(self, login, user, token, params): > + auth(params[0] and token.active, login, user, token, None, params[1]) > + > + > +class TestSync: > + """NOTE: this test requires ca.crt in your confdir so that the client can > +validate the server's certificate.""" > + > + @fixturize(Krb5Login(), User(ipauserauthtype=(u'otp')), ( > + Token(type=u'hotp'), > + Token(type=u'totp') > + ), ( > + (False, True, 0), # Normal token operation > + (False, False, 7), # Skip-ahead failure > + (True, True, 7), # Skip-ahead success after sync > + ) > + ) > + def test(self, login, user, token, params): > + sync, success, at = params > + > + if sync: > + cmd('otptoken_sync', > + user=user.username, > + password=user.password, > + first_code=unicode(token.otp(at)), > + second_code=unicode(token.otp(at + 1))) > + at += 2 > + > + auth(success, login, user, token, None, at) > -- 2.1.0 > > -- Petr? -------------- next part -------------- ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestSync.test(Krb5Login(), , HOTP(sha1:6|0{}), (False, False, 7)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 513, in test auth(success, login, user, token, None, at) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 394, in auth raises(AuthenticationError, login, user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/util.py", line 367, in raises raise ExceptionNotRaised(exception) ExceptionNotRaised: expected AuthenticationError ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestSync.test(Krb5Login(), , HOTP(sha1:6|0{}), (True, True, 7)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 510, in test second_code=unicode(token.otp(at + 1))) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 79, in cmd return api.Command[cmd](*args, version=API_VERSION, **kwargs) File "/home/pviktori/freeipa/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/home/pviktori/freeipa/ipalib/frontend.py", line 1118, in run return self.forward(*args, **options) File "/home/pviktori/freeipa/ipalib/plugins/otptoken.py", line 540, in forward rsp = urllib2.build_opener(handler).open(sync_uri, query) File "/usr/lib64/python2.7/urllib2.py", line 404, in open response = self._open(req, data) File "/usr/lib64/python2.7/urllib2.py", line 422, in _open '_open', req) File "/usr/lib64/python2.7/urllib2.py", line 382, in _call_chain result = func(*args) File "/home/pviktori/freeipa/ipalib/plugins/otptoken.py", line 499, in https_open return self.do_open(self.__inner, req) File "/usr/lib64/python2.7/urllib2.py", line 1186, in do_open raise URLError(err) URLError: ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestSync.test(Krb5Login(), , TOTP(sha1:6|30:0{}), (False, False, 7)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 513, in test auth(success, login, user, token, None, at) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 394, in auth raises(AuthenticationError, login, user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/util.py", line 367, in raises raise ExceptionNotRaised(exception) ExceptionNotRaised: expected AuthenticationError ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestSync.test(Krb5Login(), , TOTP(sha1:6|30:0{}), (True, True, 7)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 510, in test second_code=unicode(token.otp(at + 1))) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 79, in cmd return api.Command[cmd](*args, version=API_VERSION, **kwargs) File "/home/pviktori/freeipa/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/home/pviktori/freeipa/ipalib/frontend.py", line 1118, in run return self.forward(*args, **options) File "/home/pviktori/freeipa/ipalib/plugins/otptoken.py", line 540, in forward rsp = urllib2.build_opener(handler).open(sync_uri, query) File "/usr/lib64/python2.7/urllib2.py", line 404, in open response = self._open(req, data) File "/usr/lib64/python2.7/urllib2.py", line 422, in _open '_open', req) File "/usr/lib64/python2.7/urllib2.py", line 382, in _call_chain result = func(*args) File "/home/pviktori/freeipa/ipalib/plugins/otptoken.py", line 499, in https_open return self.do_open(self.__inner, req) File "/usr/lib64/python2.7/urllib2.py", line 1186, in do_open raise URLError(err) URLError: ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|60:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:30000{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha256:6|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha384:6|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha512:6|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:8|30:0{}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:0{'disabled': False}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:0{'notbefore': '20150111151851Z'}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ====================================================================== ERROR: ipatests.test_xmlrpc.test_otptoken_plugin.TestTokens.test(Krb5Login(), , TOTP(sha1:6|30:0{'notafter': '20150113151851Z'}), (True, -2)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 59, in yield (lambda *a: func(s, *a),) + ctx File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 486, in test auth(params[0] and token.active, login, user, token, None, params[1]) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 392, in auth login(user.username, pwd + code) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 95, in __call__ self.login(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 150, in login self.kinit(uid, pwd) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/test_otptoken_plugin.py", line 147, in kinit raise AuthenticationError(out, err) AuthenticationError: ('Enter OTP Token Value: \n', 'kinit: Preauthentication failed while getting initial credentials\n') ---------------------------------------------------------------------- Ran 175 tests in 174.086s FAILED (SKIP=6, errors=17) ====================================================================== FAILED under '/usr/bin/python2.7' ** FAIL ** From abokovoy at redhat.com Mon Jan 12 14:55:33 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Jan 2015 16:55:33 +0200 Subject: [Freeipa-devel] [PATCH] 0172 Support Samba PASSDB 0.2.0 aka interface version 24 Message-ID: <20150112145533.GP16288@redhat.com> Hi, Samba project renamed libpdb library we use in ipa-sam module to libsamba-passdb due to naming clash with some other library popular in academic circles (details are in https://bugzilla.samba.org/show_bug.cgi?id=10355) The change will become visible with Samba 4.2.0 release and is actually already visible in Rawhide as it packages Samba 4.2 pre-releases. Attached fix is introducing support for both Samba <4.2 and 4.2+. I've tested that it builds properly against Samba 4.2 in Rawhide and against Samba 4.1 in Fedora 21, and proper symbols exposed (disassembled the code in pdb_init_ipasam to see if address of ipasam_id_to_sid is assigned to the struct member) but I haven't deployed Rawhide to actually test FreeIPA with trusts yet. https://fedorahosted.org/freeipa/ticket/4778 -- / Alexander Bokovoy -------------- next part -------------- From 8f9a26e11b8a7f023de85cf4069f7ab72b2c92f7 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 12 Jan 2015 13:36:36 +0200 Subject: [PATCH] Support Samba PASSDB 0.2.0 aka interface version 24 1. Samba project renamed libpdb to libsamba-passdb https://bugzilla.samba.org/show_bug.cgi?id=10355 2. With interface version 24, Samba removed uid_to_sid()/gid_to_sid() from the PASSDB interface and united them as id_to_sid(). Make sure FreeIPA ipa_sam code supports new and old versions of the PASSDB API. https://fedorahosted.org/freeipa/ticket/4778 --- daemons/configure.ac | 20 ++++++++++++++++---- daemons/ipa-sam/Makefile.am | 3 ++- daemons/ipa-sam/ipa_sam.c | 21 +++++++++++++++++++++ 3 files changed, 39 insertions(+), 5 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index e81aa60..a62897e 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -170,12 +170,24 @@ PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba -Wl,-rpath=`$PKG_CONFIG --variable=libdir samba-util`/samba" AC_SUBST(SAMBA40EXTRA_LIBPATH) -AC_CHECK_LIB([pdb], +LIBPDB_NAME="" +AC_CHECK_LIB([samba-passdb], [make_pdb_method], - [HAVE_LIBPDB=1], - [AC_MSG_ERROR([libpdb does not have make_pdb_method])], + [LIBPDB_NAME="samba-passdb"; HAVE_LIBPDB=1], + [LIBPDB_NAME="pdb"], [$SAMBA40EXTRA_LIBPATH]) -AC_CHECK_LIB([pdb],[pdb_enum_upn_suffixes], + +if test "x$LIB_PDB_NAME" = "xpdb" ; then + AC_CHECK_LIB([$LIBPDB_NAME], + [make_pdb_method], + [HAVE_LIBPDB=1], + [AC_MSG_ERROR([Neither libpdb nor libsamba-passdb does have make_pdb_method])], + [$SAMBA40EXTRA_LIBPATH]) +fi + +AC_SUBST(LIBPDB_NAME) + +AC_CHECK_LIB([$LIBPDB_NAME],[pdb_enum_upn_suffixes], [AC_DEFINE([HAVE_PDB_ENUM_UPN_SUFFIXES], [1], [Ability to enumerate UPN suffixes])], [AC_MSG_WARN([libpdb does not have pdb_enum_upn_suffixes, no support for realm domains in ipasam])], [$SAMBA40EXTRA_LIBPATH]) diff --git a/daemons/ipa-sam/Makefile.am b/daemons/ipa-sam/Makefile.am index d55a187..46c813a 100644 --- a/daemons/ipa-sam/Makefile.am +++ b/daemons/ipa-sam/Makefile.am @@ -1,7 +1,8 @@ NULL = +LIBPDB_NAME = @LIBPDB_NAME@ SAMBA40EXTRA_LIBS = $(SAMBA40EXTRA_LIBPATH) \ -lsmbldap \ - -lpdb \ + -l$(LIBPDB_NAME) \ -lsmbconf \ $(NULL) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index e711299..07249fd 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -1007,6 +1007,22 @@ done: return ret; } +#if PASSDB_INTERFACE_VERSION >= 24 +/* Since version 24, uid_to_sid() and gid_to_sid() were removed in favor of id_to_sid() */ +static bool ipasam_id_to_sid(struct pdb_methods *methods, struct unixid *id, struct dom_sid *sid) +{ + bool result = false; + + if (id->type != ID_TYPE_GID) { + result = ldapsam_uid_to_sid(methods, id->id, sid); + } + if (!result && id->type != ID_TYPE_UID) { + result = ldapsam_gid_to_sid(methods, id->id, sid); + } + + return result; +} +#endif static char *get_ldap_filter(TALLOC_CTX *mem_ctx, const char *username) { @@ -4579,8 +4595,13 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, (*pdb_method)->search_aliases = ldapsam_search_aliases; (*pdb_method)->lookup_rids = ldapsam_lookup_rids; (*pdb_method)->sid_to_id = ldapsam_sid_to_id; +#if PASSDB_INTERFACE_VERSION >= 24 +/* Since version 24, uid_to_sid() and gid_to_sid() were removed in favor of id_to_sid() */ + (*pdb_method)->id_to_sid = ipasam_id_to_sid; +#else (*pdb_method)->uid_to_sid = ldapsam_uid_to_sid; (*pdb_method)->gid_to_sid = ldapsam_gid_to_sid; +#endif (*pdb_method)->capabilities = pdb_ipasam_capabilities; (*pdb_method)->get_domain_info = pdb_ipasam_get_domain_info; -- 2.1.0 From abokovoy at redhat.com Mon Jan 12 14:57:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Jan 2015 16:57:22 +0200 Subject: [Freeipa-devel] [PATCH] 487 Bump SSSD Requires to 1.12.3 In-Reply-To: <54B3C293.5030209@redhat.com> References: <54B3C293.5030209@redhat.com> Message-ID: <20150112145722.GQ16288@redhat.com> On Mon, 12 Jan 2015, Martin Kosek wrote: >The new SSSD Requires contains support for following features: >- FreeIPA user ID View overrides (not just AD users) >- User SSH public keys in ID Views >- krb5.conf localauth plugin > >https://fedorahosted.org/freeipa/ticket/4685 >https://fedorahosted.org/freeipa/ticket/4509 >https://fedorahosted.org/freeipa/ticket/4514 > >----- > >SSSD build is in koji and our Copr repo as well. > ACK -- / Alexander Bokovoy From mkosek at redhat.com Mon Jan 12 15:06:32 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Jan 2015 16:06:32 +0100 Subject: [Freeipa-devel] [PATCH] 487 Bump SSSD Requires to 1.12.3 In-Reply-To: <20150112145722.GQ16288@redhat.com> References: <54B3C293.5030209@redhat.com> <20150112145722.GQ16288@redhat.com> Message-ID: <54B3E2F8.3010304@redhat.com> On 01/12/2015 03:57 PM, Alexander Bokovoy wrote: > On Mon, 12 Jan 2015, Martin Kosek wrote: >> The new SSSD Requires contains support for following features: >> - FreeIPA user ID View overrides (not just AD users) >> - User SSH public keys in ID Views >> - krb5.conf localauth plugin >> >> https://fedorahosted.org/freeipa/ticket/4685 >> https://fedorahosted.org/freeipa/ticket/4509 >> https://fedorahosted.org/freeipa/ticket/4514 >> >> ----- >> >> SSSD build is in koji and our Copr repo as well. >> > ACK > Fixed upstream master: https://fedorahosted.org/freeipa/changeset/9225624fd8f61f57a530e6bd696024e9c58e9579 ipa-4-1: https://fedorahosted.org/freeipa/changeset/30dae37d92add85a3fa3ae9ca1b503182a2e6f1b Martin From pvoborni at redhat.com Mon Jan 12 15:29:11 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 Jan 2015 16:29:11 +0100 Subject: [Freeipa-devel] [PATCH] 797 rpcclient: use json_encode_binary for verbose output Message-ID: <54B3E847.8030707@redhat.com> `json.dumps` is not able to process some IPA's object types and therefore requires to preprocess it with `json_encode_binary` call. This step was not used in rpcclient's verbose output. https://fedorahosted.org/freeipa/ticket/4773 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0797-rpcclient-use-json_encode_binary-for-verbose-output.patch Type: text/x-patch Size: 1925 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 12 15:30:05 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Jan 2015 10:30:05 -0500 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3C0FF.7030809@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> Message-ID: <54B3E87D.9020307@redhat.com> Jan Cholasta wrote: > Dne 12.1.2015 v 13:37 David Kupka napsal(a): >> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>> >>>> Looking at this patch, are data-only backups supposed to work properly >>>> then? >>>> Wouldn't for example Directory Server fail to start when cn=config >>>> contain some >>>> hostname-bound values? >>>> >>>> Just checking... >>>> >>> >>> IMO the error should be raised in both data-only and full restore, if in >>> unattended mode or the user wishes not to continue. >>> >> Description of the problem in ticket states: "I tried to run ipa-restore >> (full kind) on replica from full backup taken on master and was >> expecting an error message that restore can not proceed and only data >> restore possible." >> >> I created the patch based on this request. Is it wrong and should >> ipa-restore fail every time when hostnames does not match? > > Yes, as Martin pointed out, the data may contain references to the > hostname. > >> Does it make >> sense to allow user to force the restoration in this case? > > Yes, if the users wish, they should be allowed to continue. IIRC a data restore is just the data from the replicated tree so there is nothing hostname-specific. It is probably worth investigating so we don't go too far one way or the other. A full restore definitely shouldn't be done on the wrong host as it will restore certificates and keytabs that are definitely host-specific. rob From jcholast at redhat.com Mon Jan 12 15:32:05 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Jan 2015 16:32:05 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3E87D.9020307@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> <54B3E87D.9020307@redhat.com> Message-ID: <54B3E8F5.9030503@redhat.com> Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 12.1.2015 v 13:37 David Kupka napsal(a): >>> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>>> >>>>> Looking at this patch, are data-only backups supposed to work properly >>>>> then? >>>>> Wouldn't for example Directory Server fail to start when cn=config >>>>> contain some >>>>> hostname-bound values? >>>>> >>>>> Just checking... >>>>> >>>> >>>> IMO the error should be raised in both data-only and full restore, if in >>>> unattended mode or the user wishes not to continue. >>>> >>> Description of the problem in ticket states: "I tried to run ipa-restore >>> (full kind) on replica from full backup taken on master and was >>> expecting an error message that restore can not proceed and only data >>> restore possible." >>> >>> I created the patch based on this request. Is it wrong and should >>> ipa-restore fail every time when hostnames does not match? >> >> Yes, as Martin pointed out, the data may contain references to the >> hostname. >> >>> Does it make >>> sense to allow user to force the restoration in this case? >> >> Yes, if the users wish, they should be allowed to continue. > > IIRC a data restore is just the data from the replicated tree so there > is nothing hostname-specific. It is probably worth investigating so we > don't go too far one way or the other. There's at least cn=,cn=masters,cn=etc,. > > A full restore definitely shouldn't be done on the wrong host as it will > restore certificates and keytabs that are definitely host-specific. Should the continue prompt be removed then? > > rob > -- Jan Cholasta From rcritten at redhat.com Mon Jan 12 15:50:12 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Jan 2015 10:50:12 -0500 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3E8F5.9030503@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> <54B3E87D.9020307@redhat.com> <54B3E8F5.9030503@redhat.com> Message-ID: <54B3ED34.6030500@redhat.com> Jan Cholasta wrote: > Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 12.1.2015 v 13:37 David Kupka napsal(a): >>>> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>>>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>>>> >>>>>> Looking at this patch, are data-only backups supposed to work >>>>>> properly >>>>>> then? >>>>>> Wouldn't for example Directory Server fail to start when cn=config >>>>>> contain some >>>>>> hostname-bound values? >>>>>> >>>>>> Just checking... >>>>>> >>>>> >>>>> IMO the error should be raised in both data-only and full restore, >>>>> if in >>>>> unattended mode or the user wishes not to continue. >>>>> >>>> Description of the problem in ticket states: "I tried to run >>>> ipa-restore >>>> (full kind) on replica from full backup taken on master and was >>>> expecting an error message that restore can not proceed and only data >>>> restore possible." >>>> >>>> I created the patch based on this request. Is it wrong and should >>>> ipa-restore fail every time when hostnames does not match? >>> >>> Yes, as Martin pointed out, the data may contain references to the >>> hostname. >>> >>>> Does it make >>>> sense to allow user to force the restoration in this case? >>> >>> Yes, if the users wish, they should be allowed to continue. >> >> IIRC a data restore is just the data from the replicated tree so there >> is nothing hostname-specific. It is probably worth investigating so we >> don't go too far one way or the other. > > There's at least cn=,cn=masters,cn=etc,. That's part of the replicated tree, but it does raise a question: What would it mean if you did a data restore to a server that doesn't exist as a master in the realm? Geez, I don't know, but it likely wouldn't go well. Checking for that would be quite an issue and it would surely exercise the python-ldap ldif module. Is it illegal though? I don't know. Any keytabs would be bad b/c the Kerberos master key is different. In all likelihood things would just go south. I imagine someone might try this in an attempt to setup a test/integration environment. It just wouldn't work. In a replicated environment though, with hosts A and B, restoring the data from B on A is probably not a big deal, though it does raise the question of "why the heck would you do this?" It could be that you only did backups on B and don't want to do a full re-init on A due to size/time/moon phase. > >> >> A full restore definitely shouldn't be done on the wrong host as it will >> restore certificates and keytabs that are definitely host-specific. > > Should the continue prompt be removed then? Well, you've just about got me convinced we shouldn't allow it, at least not without several "do you really want to do this?" prompts. This seems to fall in the range of "yeah, it will work if you know what you're doing, but why would you ever want to?" I think until that question is answered it is safer to disallow it. I'd be ok with a ticket into the deferred to investigate this later to see if it can be relaxed. rob From mkosek at redhat.com Mon Jan 12 16:11:19 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Jan 2015 17:11:19 +0100 Subject: [Freeipa-devel] [PATCH 0179] Fix traceback if zonemgr error message contains unicode characters In-Reply-To: <54B3C465.3030603@redhat.com> References: <548AED1E.2020308@redhat.com> <54AFD2A2.9070204@redhat.com> <54B3BD26.4060405@redhat.com> <54B3C465.3030603@redhat.com> Message-ID: <54B3F227.2050507@redhat.com> On 01/12/2015 01:56 PM, David Kupka wrote: > On 01/12/2015 01:25 PM, Martin Basti wrote: >> On 09/01/15 14:07, David Kupka wrote: >>> On 12/12/2014 02:26 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/4805 >>>> >>>> Patch attached. >>>> >>>> >>> Does not work properly. >>> >>> $ locale >>> LANG=cs_CZ.iso88592 >>> LC_CTYPE="cs_CZ.iso88592" >>> LC_NUMERIC="cs_CZ.iso88592" >>> LC_TIME="cs_CZ.iso88592" >>> LC_COLLATE="cs_CZ.iso88592" >>> LC_MONETARY="cs_CZ.iso88592" >>> LC_MESSAGES="cs_CZ.iso88592" >>> LC_PAPER="cs_CZ.iso88592" >>> LC_NAME="cs_CZ.iso88592" >>> LC_ADDRESS="cs_CZ.iso88592" >>> LC_TELEPHONE="cs_CZ.iso88592" >>> LC_MEASUREMENT="cs_CZ.iso88592" >>> LC_IDENTIFICATION="cs_CZ.iso88592" >>> LC_ALL=cs_CZ.iso88592 >>> >>> $ sudo ipa-server-install --setup-dns --forwarder=10.65.201.89 -r >>> TESTRELM.TEST -p xxxxxxxx -P xxxxxxxx -a xxxxxxxx >>> --zonemg=?a?ko at redhat.com -U > >>> /tmp/ipaserverinstall_invalidzonemgr.out 2>&1 >>> >>> $ cat /tmp/ipaserverinstall_invalidzonemgr.out >>> Usage: ipa-server-install [options] >>> >>> ipa-server-install: error: invalid zonemgr: domain name >>> '??a??ko.redhat.com' should be normalized to: ??a??ko.redhat.com >>> >>> The provided value isn't right and must be normalized but the one >>> displayed in error message doesn't match. >>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >> Sorry, but it works for me. I tested it with >> LC_ALL=sk_SK.ISO-8859-2 >> > You're right I probably miss-configured the encoding in Konsole. Now I've tried > it again and it works, ACK. Pushed to: master: 727f8099af9ace4a7a8e4489b34aa2db440336b2 ipa-4-1: fb1d848b490606846c14d764fabac5186a60fe4e From mbabinsk at redhat.com Mon Jan 12 16:45:13 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 12 Jan 2015 17:45:13 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation Message-ID: <54B3FA19.6000903@redhat.com> related to ticket https://fedorahosted.org/freeipa/ticket/4808 Patch attached. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0001-ipa-client-install-added-new-option.patch Type: text/x-patch Size: 4348 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 12 16:46:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Jan 2015 17:46:29 +0100 Subject: [Freeipa-devel] [PATCH] 388 Remove RUV from LDIF files before using them in ipa-restore Message-ID: <54B3FA65.4070404@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-388-Remove-RUV-from-LDIF-files-before-using-them-in-ipa-.patch Type: text/x-patch Size: 2546 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 12 17:07:52 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Jan 2015 18:07:52 +0100 Subject: [Freeipa-devel] [PATCH] 389 Fix ipa-restore on systems without IPA installed Message-ID: <54B3FF68.3040806@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-389-Fix-ipa-restore-on-systems-without-IPA-installed.patch Type: text/x-patch Size: 957 bytes Desc: not available URL: From mbasti at redhat.com Mon Jan 12 17:34:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Jan 2015 18:34:53 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54AFDB04.7000902@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> Message-ID: <54B405BD.30100@redhat.com> On 09/01/15 14:43, David Kupka wrote: > On 01/07/2015 04:15 PM, Martin Basti wrote: >> On 07/01/15 12:27, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4249 >> >> Thank you for patch: >> >> 1) >> - root_logger.error("Cannot update DNS records! " >> - "Failed to connect to server '%s'.", server) >> + ips = get_local_ipaddresses() >> + except CalledProcessError as e: >> + root_logger.error("Cannot update DNS records. %s" % e) >> >> IMO the error message should be more specific, add there something like >> "Unable to get local IP addresses". at least in log.debug() >> >> 2) >> + lines = ipresult[0].replace('\\', '').split('\n') >> >> .replace() is not needed >> >> 3) >> + if len(ips) == 0: >> >> if not ips: >> >> is more pythonic by PEP8 >> >> > Thanks for catching these. Updated patch attached. > merciful NACK Thank you for the patch, unfortunately I hit one issue which needs to be resolved. If "sync PTR" is activated in zone settings, and reverse zone doesn't exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print Error message, 'DNS update failed'. In fact, all A/AAAA records was succesfully updated, only PTR records failed. Bind log: named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at 'vm-101.example.com' AAAA named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA 'vm-101.example.com.' refused: unable to find active reverse zone for IP address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found With IPv6 we have several addresses from different reverse zones and this situation may happen often. I suggest following: 1) Print list of addresses which will be updated. (Now if update fails, user needs to read log, which addresses installer tried to update) 2) Split nsupdates per A/AAAA record. 3a) If failed, check with DNS query if A/AAAA and PTR record are there and print proper error message 3b) Just print A/AAAA (or PTR) record may not be updated for particular IP address. Any other suggestions are welcome. -- Martin Basti From mbasti at redhat.com Mon Jan 12 17:43:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Jan 2015 18:43:16 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <54AAAB59.6030101@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> <54905A55.5060209@redhat.com> <5491900B.8060209@redhat.com> <54AAAB59.6030101@redhat.com> Message-ID: <54B407B4.6010805@redhat.com> On 05/01/15 16:18, Martin Basti wrote: > On 17/12/14 15:15, Martin Basti wrote: >> On 16/12/14 17:14, Martin Basti wrote: >>> On 15/12/14 20:15, Martin Basti wrote: >>>> On 15/12/14 19:18, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4750 >>>>> >>>>> Patches need rebase and minor pytest modification to apply on >>>>> master, I will do that after review. >>>>> >>>>> Patches for ipa-4-1 attached. >>>>> >>>>> >>>> I forgot to fix copy paste error. >>>> >>>> Updated patches attached >>>> >>> Removed unneeded nsrecord validation in 2 tests >>> >>> updated patches attached >>> >> Added: >> >> * find forward zone with --forward-policy=none (no fwzone exists) >> * find forward zone with --forward-policy=only (no fwzone exists) >> * find forward zone with --forward-policy=first (no fwzone exists) >> * enable enabled zone >> * disable disabled zone >> >> Patches attached. >> >> > Hi Scott, could you ack or nack the patchset, other test tickets are > waiting, and we want to avoid huge rebases/merging > From QA point of view, tests are OK. Can somebody do code review please? -- Martin Basti From jcholast at redhat.com Mon Jan 12 17:44:46 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Jan 2015 18:44:46 +0100 Subject: [Freeipa-devel] [PATCH] 796 migrate-ds: fix compat plugin check In-Reply-To: <54B3CCA6.1@redhat.com> References: <54B3CCA6.1@redhat.com> Message-ID: <54B4080E.9060208@redhat.com> Hi, Dne 12.1.2015 v 14:31 Petr Vobornik napsal(a): > [PATCH] migrate-ds: fix compat plugin check > > After ACI refactoring, admin cannot read Schema Compatibility plugin > configuration and therefore migrade-ds won't find if compat plugin is > enabled. > > Now the check si done by looking if cn=compat subtree is present. > > https://fedorahosted.org/freeipa/ticket/4825 Works for me, ACK. Pushed to: master: e6beaaccceb01a3ce56cfa3edfc8ab0191d51bb1 ipa-4-1: 63ba17049e77dff33b9e2bc98f69976c1c8c24ee Honza -- Jan Cholasta From mbasti at redhat.com Mon Jan 12 18:15:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 12 Jan 2015 19:15:45 +0100 Subject: [Freeipa-devel] [PATCH] 797 rpcclient: use json_encode_binary for verbose output In-Reply-To: <54B3E847.8030707@redhat.com> References: <54B3E847.8030707@redhat.com> Message-ID: <54B40F51.1040809@redhat.com> On 12/01/15 16:29, Petr Vobornik wrote: > `json.dumps` is not able to process some IPA's object types and > therefore requires to preprocess it with `json_encode_binary` call. > This step was not used in rpcclient's verbose output. > > https://fedorahosted.org/freeipa/ticket/4773 > Works for me. ACK -- Martin Basti From mkosek at redhat.com Tue Jan 13 08:22:12 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Jan 2015 09:22:12 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation In-Reply-To: <54B3FA19.6000903@redhat.com> References: <54B3FA19.6000903@redhat.com> Message-ID: <54B4D5B4.3050301@redhat.com> On 01/12/2015 05:45 PM, Martin Babinsky wrote: > related to ticket https://fedorahosted.org/freeipa/ticket/4808 > > Patch attached. > > Martin^3 I think the --tgt-kinit-attempts approach is good one. Couple comments I have when reading the patch: 1) Function +def get_host_tgt(options, keytab, host, realm, env): should be made more general purpose and instead of whole "options", it should rather accept just "kinit_attemps". It will then enable future generations to reuse the function for something else. Just a generally good practice, nothing critical. 2) I think + if returncode == 0: + root_logger.info("Attempt %d succeeded." % n_attempts) + break can be just DEBUG level. People do not need to know we will try multiple attempts. 3) It may be even better to print "Attempt %d/%d failed." instead of just number. But this is up to you. 4) I see several C-isms in the code, as a programming practice, let us remove them :-) In Python, the OK/notOK status is generally passed via exceptions, not return codes unless you really need them for anything meaningful. So, you can omit "raiseonerr=False" and have the handling code in an Except clause. When max number of attempts is breached, you then just raise the exception further (use bare "raise", to re-raise to keep the original stack). Martin From jcholast at redhat.com Tue Jan 13 08:46:50 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 09:46:50 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation In-Reply-To: <54B4D5B4.3050301@redhat.com> References: <54B3FA19.6000903@redhat.com> <54B4D5B4.3050301@redhat.com> Message-ID: <54B4DB7A.4080307@redhat.com> Dne 13.1.2015 v 09:22 Martin Kosek napsal(a): > On 01/12/2015 05:45 PM, Martin Babinsky wrote: >> related to ticket https://fedorahosted.org/freeipa/ticket/4808 >> >> Patch attached. >> >> Martin^3 > > I think the --tgt-kinit-attempts approach is good one. Couple comments I have > when reading the patch: > > 1) Function > +def get_host_tgt(options, keytab, host, realm, env): > should be made more general purpose and instead of whole "options", it should > rather accept just "kinit_attemps". It will then enable future generations to > reuse the function for something else. Just a generally good practice, nothing > critical. > > 2) I think > + if returncode == 0: > + root_logger.info("Attempt %d succeeded." % n_attempts) > + break > > can be just DEBUG level. People do not need to know we will try multiple attempts. > > 3) It may be even better to print > "Attempt %d/%d failed." instead of just number. But this is up to you. > > 4) I see several C-isms in the code, as a programming practice, let us remove > them :-) In Python, the OK/notOK status is generally passed via exceptions, not > return codes unless you really need them for anything meaningful. > > So, you can omit "raiseonerr=False" and have the handling code in an Except > clause. When max number of attempts is breached, you then just raise the > exception further (use bare "raise", to re-raise to keep the original stack). +1 Additionally: 5) I would prefer if the option was named --kinit-attempts instead of --tgt-kinit-attempts (the "tgt" seems redundant). 6) Please do not use backslashes for line wrapping, unless it is absolutely necessary. Instead, enclose the expression in parens for implicit continuation: + help=("number of attempts to obtain host TGT" + "if the first one fails (defaults to %default).")) 7) Please follow PEP8 in new code: ipa-client/ipa-install/ipa-client-install:151:80: E501 line too long (93 > 79 characters) ipa-client/ipa-install/ipa-client-install:1100:1: E302 expected 2 blank lines, found 1 ipa-client/ipa-install/ipa-client-install:1107:29: E126 continuation line over-indented for hanging indent ipa-client/ipa-install/ipa-client-install:1107:41: E231 missing whitespace after ',' ipa-client/ipa-install/ipa-client-install:1108:29: E128 continuation line under-indented for visual indent ipa-client/ipa-install/ipa-client-install:1116:51: E225 missing whitespace around operator ipa-client/ipa-install/ipa-client-install:2453:80: E501 line too long (88 > 79 characters) ipa-client/ipa-install/ipa-client-install:2454:80: E501 line too long (89 > 79 characters) ipa-client/ipa-install/ipa-client-install:2531:80: E501 line too long (83 > 79 characters) ipa-client/ipa-install/ipa-client-install:2532:80: E501 line too long (81 > 79 characters) Honza -- Jan Cholasta From mkosek at redhat.com Tue Jan 13 09:04:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Jan 2015 10:04:53 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <54B407B4.6010805@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> <54905A55.5060209@redhat.com> <5491900B.8060209@redhat.com> <54AAAB59.6030101@redhat.com> <54B407B4.6010805@redhat.com> Message-ID: <54B4DFB5.4010803@redhat.com> On 01/12/2015 06:43 PM, Martin Basti wrote: > On 05/01/15 16:18, Martin Basti wrote: >> On 17/12/14 15:15, Martin Basti wrote: >>> On 16/12/14 17:14, Martin Basti wrote: >>>> On 15/12/14 20:15, Martin Basti wrote: >>>>> On 15/12/14 19:18, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4750 >>>>>> >>>>>> Patches need rebase and minor pytest modification to apply on master, I >>>>>> will do that after review. >>>>>> >>>>>> Patches for ipa-4-1 attached. >>>>>> >>>>>> >>>>> I forgot to fix copy paste error. >>>>> >>>>> Updated patches attached >>>>> >>>> Removed unneeded nsrecord validation in 2 tests >>>> >>>> updated patches attached >>>> >>> Added: >>> >>> * find forward zone with --forward-policy=none (no fwzone exists) >>> * find forward zone with --forward-policy=only (no fwzone exists) >>> * find forward zone with --forward-policy=first (no fwzone exists) >>> * enable enabled zone >>> * disable disabled zone >>> >>> Patches attached. >>> >>> >> Hi Scott, could you ack or nack the patchset, other test tickets are waiting, >> and we want to avoid huge rebases/merging >> > From QA point of view, tests are OK. Can somebody do code review please? Code looks OK, runs cleanly (except that I thought that wait_for_dns is boolean value and not an integer :-/) So ACK from me. After you prepare a version for master branch, we can push them. Martin From pspacek at redhat.com Tue Jan 13 09:16:47 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Jan 2015 10:16:47 +0100 Subject: [Freeipa-devel] [PATCH 0022] Fix default value type for wait_for_dns optio Message-ID: <54B4E27F.5000401@redhat.com> Hello, Fix default value type for wait_for_dns option wait_for_dns value should be an integer so default value was changed from False to 0. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0022-Fix-default-value-type-for-wait_for_dns-option.patch Type: text/x-patch Size: 850 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 13 09:20:09 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 10:20:09 +0100 Subject: [Freeipa-devel] [PATCH] 797 rpcclient: use json_encode_binary for verbose output In-Reply-To: <54B40F51.1040809@redhat.com> References: <54B3E847.8030707@redhat.com> <54B40F51.1040809@redhat.com> Message-ID: <54B4E349.7040409@redhat.com> On 01/12/2015 07:15 PM, Martin Basti wrote: > On 12/01/15 16:29, Petr Vobornik wrote: >> `json.dumps` is not able to process some IPA's object types and >> therefore requires to preprocess it with `json_encode_binary` call. >> This step was not used in rpcclient's verbose output. >> >> https://fedorahosted.org/freeipa/ticket/4773 >> > Works for me. ACK > Pushed to: master: a18ef90284f627bdde1e264e5e3db3a52031feec ipa-4-1: 872ba41c3b8ccc7beaaaf19e8a30f0caa8a1fa36 -- Petr Vobornik From pvoborni at redhat.com Tue Jan 13 09:46:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 10:46:26 +0100 Subject: [Freeipa-devel] [PATCH] 389 Fix ipa-restore on systems without IPA installed In-Reply-To: <54B3FF68.3040806@redhat.com> References: <54B3FF68.3040806@redhat.com> Message-ID: <54B4E972.5020804@redhat.com> On 01/12/2015 06:07 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > Is there a reason why `installutils.check_server_configuration() ` is called in `cert_restore_prepare`, ie., method which is not really connected with it, and not in `run` as for DATA backup? -- Petr Vobornik From mkosek at redhat.com Tue Jan 13 09:57:37 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Jan 2015 10:57:37 +0100 Subject: [Freeipa-devel] [PATCH 0022] Fix default value type for wait_for_dns optio In-Reply-To: <54B4E27F.5000401@redhat.com> References: <54B4E27F.5000401@redhat.com> Message-ID: <54B4EC11.9070704@redhat.com> On 01/13/2015 10:16 AM, Petr Spacek wrote: > Hello, > > Fix default value type for wait_for_dns option > > wait_for_dns value should be an integer so default value was changed from > False to 0. > Thanks. I stumbled on this value this morning, when setting it to True did not work. IMO, it would make sense to even rename the option to something that does not indicate boolean semantics, like "dns_wait_retry_attempts" or similar. But it may be too disruptive as at least our CI scripts would have to be updated. Up to you. Martin From pspacek at redhat.com Tue Jan 13 10:11:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Jan 2015 11:11:09 +0100 Subject: [Freeipa-devel] [PATCH 0022] Fix default value type for wait_for_dns optio In-Reply-To: <54B4EC11.9070704@redhat.com> References: <54B4E27F.5000401@redhat.com> <54B4EC11.9070704@redhat.com> Message-ID: <54B4EF3D.90003@redhat.com> On 13.1.2015 10:57, Martin Kosek wrote: > On 01/13/2015 10:16 AM, Petr Spacek wrote: >> Hello, >> >> Fix default value type for wait_for_dns option >> >> wait_for_dns value should be an integer so default value was changed from >> False to 0. >> > > Thanks. I stumbled on this value this morning, when setting it to True did not > work. > > IMO, it would make sense to even rename the option to something that does not > indicate boolean semantics, like "dns_wait_retry_attempts" or similar. But it > may be too disruptive as at least our CI scripts would have to be updated. > > Up to you. Well, open a ticket for option rename :-) Anyway, this change can be pushed as-is (after review) even if we decide to rename it later. -- Petr^2 Spacek From jcholast at redhat.com Tue Jan 13 10:54:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 11:54:17 +0100 Subject: [Freeipa-devel] [PATCH] 389 Fix ipa-restore on systems without IPA installed In-Reply-To: <54B4E972.5020804@redhat.com> References: <54B3FF68.3040806@redhat.com> <54B4E972.5020804@redhat.com> Message-ID: <54B4F959.90201@redhat.com> Dne 13.1.2015 v 10:46 Petr Vobornik napsal(a): > On 01/12/2015 06:07 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > Is there a reason why `installutils.check_server_configuration() > ` is called in `cert_restore_prepare`, ie., method which is not really > connected with it, and not in `run` as for DATA backup? Full restore may be done when IPA is not installed, but cert_restore_prepare crashes when IPA is not installed, the check prevents that. Anyway, see the attached patch for an alternative, possibly better approach. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-389.1-Fix-ipa-restore-on-systems-without-IPA-installed.patch Type: text/x-patch Size: 1275 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 13 10:54:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Jan 2015 11:54:53 +0100 Subject: [Freeipa-devel] [PATCH 0022] Fix default value type for wait_for_dns optio In-Reply-To: <54B4EF3D.90003@redhat.com> References: <54B4E27F.5000401@redhat.com> <54B4EC11.9070704@redhat.com> <54B4EF3D.90003@redhat.com> Message-ID: <54B4F97D.4070702@redhat.com> On 01/13/2015 11:11 AM, Petr Spacek wrote: > On 13.1.2015 10:57, Martin Kosek wrote: >> On 01/13/2015 10:16 AM, Petr Spacek wrote: >>> Hello, >>> >>> Fix default value type for wait_for_dns option >>> >>> wait_for_dns value should be an integer so default value was changed from >>> False to 0. >>> >> >> Thanks. I stumbled on this value this morning, when setting it to True did not >> work. >> >> IMO, it would make sense to even rename the option to something that does not >> indicate boolean semantics, like "dns_wait_retry_attempts" or similar. But it >> may be too disruptive as at least our CI scripts would have to be updated. >> >> Up to you. > > Well, open a ticket for option rename :-) I am not bothered by the name that much :-) > Anyway, this change can be pushed as-is (after review) even if we decide to > rename it later. Ok, works for me. ACK. Pushed to master: 2ff8ced5175f8def1b07786d20b64c1450be0567 Martin From jcholast at redhat.com Tue Jan 13 11:12:00 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 12:12:00 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service Message-ID: <54B4FD80.8090008@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-390-Do-not-crash-on-unknown-services-in-installutils.sto.patch Type: text/x-patch Size: 1589 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 13 11:17:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 12:17:14 +0100 Subject: [Freeipa-devel] [PATCHES] 391-392 Make certificate renewal process synchronized Message-ID: <54B4FEBA.3000900@redhat.com> Hi, the attached patches fix . Note that if you want to test upgrades on CA-less, you need to apply my patch 390 as well: . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-391-Restart-dogtag-when-its-server-certificate-is-renewe.patch Type: text/x-patch Size: 2258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-392-Make-certificate-renewal-process-synchronized.patch Type: text/x-patch Size: 19725 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 13 11:20:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Jan 2015 12:20:21 +0100 Subject: [Freeipa-devel] FYI: LANGSEC: Sane protocol design and input parsing Message-ID: <54B4FF75.4040007@redhat.com> Hello, FYI, I came across an interesting article/idea: "LANGSEC: Language-theoretic Security" The Language-theoretic approach (LANGSEC) regards the Internet insecurity epidemic as a consequence of ad hoc programming of input handling at all layers of network stacks, and in other kinds of software stacks. IMHO it is worth few minutes of your time: http://www.cs.dartmouth.edu/~sergey/langsec/ TL;DR version in pictures: http://www.cs.dartmouth.edu/~sergey/langsec/occupy/ Enjoy :-) -- Petr^2 Spacek From pvoborni at redhat.com Tue Jan 13 12:01:45 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 13:01:45 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B3CBF1.602@redhat.com> References: <54B3CBF1.602@redhat.com> Message-ID: <54B50929.20306@redhat.com> On 01/12/2015 02:28 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Note that --data with data-only backup and --logs-only with data-only > restore are deliberately ignored and considered no-op. > > Honza > 1. I'm not sure how relative path to backup dir should work: I have a backup: /var/lib/ipa/backup/ipa-data-2015-01-13-10-53-06/ Absolute path works great. But: - ipa-data-2015-01-13-10-53-06 fails with `ipa-restore: error: must provide path to backup directory` Ugly hybrid (I was in home dir): ../../var/lib/ipa/backup/ipa-data-2015-01-13-10-53-06/ fails with: /var/lib/ipa/backup/../../var/lib/ipa/backup/ipa-data-2015-01-13-10-53-06/header I.e., dir name won't pass if not os.path.isdir(self.args[0]): and the second concatenation is weird. 2. Data backup cannot be done because the first 'for' never breaks + for instance in instances: + for backend in backends: + db_dir = (paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE % + (instance, backend)) + if os.path.exists(db_dir): + break + else: + raise admintool.ScriptError( + "Cannot restore a data backup into an empty system") 3. When #2 fixed, data backup with --no-logs doesn't raise warning as requested in ticket. 4. Since backup type is detected automatically(--data doesn't have to be specified for data restore), I guess that the ticket requirement: `Here expecting an error message that --online option can only provided along with --data option. ` is invalid, right? Man page states that --online requires --data option, which is not true. 5. Nitpick: imho option validation should be done before temp dir creation. 6. pep8, fixing them is up to you: ./ipaserver/install/ipa_restore.py:150:5: E129 visually indented line with same indent as next logical line ./ipaserver/install/ipa_restore.py:184:13: E128 continuation line under-indented for visual indent -- Petr Vobornik From dkupka at redhat.com Tue Jan 13 12:33:36 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 13:33:36 +0100 Subject: [Freeipa-devel] [PATCH] 0037 Remove ipanttrustauthincoming/ipanttrustauthoutgoing from ipa trust-add output. Message-ID: <54B510A0.4010504@redhat.com> https://fedorahosted.org/freeipa/ticket/4787 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0037-Remove-ipanttrustauthincoming-ipanttrustauthoutgoing.patch Type: text/x-patch Size: 1006 bytes Desc: not available URL: From mbasti at redhat.com Tue Jan 13 12:36:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Jan 2015 13:36:53 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <54B4DFB5.4010803@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> <54905A55.5060209@redhat.com> <5491900B.8060209@redhat.com> <54AAAB59.6030101@redhat.com> <54B407B4.6010805@redhat.com> <54B4DFB5.4010803@redhat.com> Message-ID: <54B51165.3020808@redhat.com> On 13/01/15 10:04, Martin Kosek wrote: > On 01/12/2015 06:43 PM, Martin Basti wrote: >> On 05/01/15 16:18, Martin Basti wrote: >>> On 17/12/14 15:15, Martin Basti wrote: >>>> On 16/12/14 17:14, Martin Basti wrote: >>>>> On 15/12/14 20:15, Martin Basti wrote: >>>>>> On 15/12/14 19:18, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4750 >>>>>>> >>>>>>> Patches need rebase and minor pytest modification to apply on master, I >>>>>>> will do that after review. >>>>>>> >>>>>>> Patches for ipa-4-1 attached. >>>>>>> >>>>>>> >>>>>> I forgot to fix copy paste error. >>>>>> >>>>>> Updated patches attached >>>>>> >>>>> Removed unneeded nsrecord validation in 2 tests >>>>> >>>>> updated patches attached >>>>> >>>> Added: >>>> >>>> * find forward zone with --forward-policy=none (no fwzone exists) >>>> * find forward zone with --forward-policy=only (no fwzone exists) >>>> * find forward zone with --forward-policy=first (no fwzone exists) >>>> * enable enabled zone >>>> * disable disabled zone >>>> >>>> Patches attached. >>>> >>>> >>> Hi Scott, could you ack or nack the patchset, other test tickets are waiting, >>> and we want to avoid huge rebases/merging >>> >> From QA point of view, tests are OK. Can somebody do code review please? > Code looks OK, runs cleanly (except that I thought that wait_for_dns is boolean > value and not an integer :-/) > > So ACK from me. After you prepare a version for master branch, we can push them. > > Martin Rebased patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-mbasti-0176.4-New-test-cases-for-Forward_zones.patch Type: text/x-patch Size: 39230 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-mbasti-0175.4-DNS-tests-separate-current-forward-zone-tests.patch Type: text/x-patch Size: 32158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.1-mbasti-0176.4-New-test-cases-for-Forward_zones.patch Type: text/x-patch Size: 39232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.1-mbasti-0175.4-DNS-tests-separate-current-forward-zone-tests.patch Type: text/x-patch Size: 32152 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 13 12:39:54 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 13:39:54 +0100 Subject: [Freeipa-devel] [PATCH] 0037 Remove ipanttrustauthincoming/ipanttrustauthoutgoing from ipa trust-add output. In-Reply-To: <54B510A0.4010504@redhat.com> References: <54B510A0.4010504@redhat.com> Message-ID: <54B5121A.6070705@redhat.com> On 01/13/2015 01:33 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4787 > Haven't try it, but: have you considered: result['result'].pop('ipanttrustauthincoming', None) ? -- Petr Vobornik From dkupka at redhat.com Tue Jan 13 12:51:29 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 13:51:29 +0100 Subject: [Freeipa-devel] [PATCH] 0037 Remove ipanttrustauthincoming/ipanttrustauthoutgoing from ipa trust-add output. In-Reply-To: <54B5121A.6070705@redhat.com> References: <54B510A0.4010504@redhat.com> <54B5121A.6070705@redhat.com> Message-ID: <54B514D1.4040608@redhat.com> On 01/13/2015 01:39 PM, Petr Vobornik wrote: > On 01/13/2015 01:33 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4787 >> > > > Haven't try it, but: > > have you considered: > result['result'].pop('ipanttrustauthincoming', None) > ? I haven't and it looks better, thanks. Fixed patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0037-2-Remove-ipanttrustauthincoming-ipanttrustauthoutgoing.patch Type: text/x-patch Size: 837 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 13 13:16:23 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Jan 2015 14:16:23 +0100 Subject: [Freeipa-devel] [PATCH 0319] Fix crash caused by race condition during resolver cache flushing Message-ID: <54B51AA7.7070801@redhat.com> Hello, This patch should be applied to v2 branch. Fix crash caused by race condition during resolver cache flushing. dns_view_flushcache() call has to be always done in single-thread mode. Locking around the call was missing in forwarder reconfiguration and zone deletion which could cause crash. https://fedorahosted.org/bind-dyndb-ldap/ticket/142 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0319-Fix-crash-caused-by-race-condition-during-resolver-c.patch Type: text/x-patch Size: 2447 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 13 13:26:46 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 14:26:46 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B50929.20306@redhat.com> References: <54B3CBF1.602@redhat.com> <54B50929.20306@redhat.com> Message-ID: <54B51D16.7020709@redhat.com> Dne 13.1.2015 v 13:01 Petr Vobornik napsal(a): > On 01/12/2015 02:28 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Note that --data with data-only backup and --logs-only with data-only >> restore are deliberately ignored and considered no-op. >> >> Honza >> > > 1. I'm not sure how relative path to backup dir should work: > > I have a backup: /var/lib/ipa/backup/ipa-data-2015-01-13-10-53-06/ > > Absolute path works great. But: > - ipa-data-2015-01-13-10-53-06 > fails with `ipa-restore: error: must provide path to backup directory` > > Ugly hybrid (I was in home dir): > ../../var/lib/ipa/backup/ipa-data-2015-01-13-10-53-06/ > fails with: > > /var/lib/ipa/backup/../../var/lib/ipa/backup/ipa-data-2015-01-13-10-53-06/header > > > I.e., dir name won't pass > if not os.path.isdir(self.args[0]): > and the second concatenation is weird. man ipa-restore says: Only the name of the backup needs to be passed in, not the full path. Backups are stored in a subdirectory in /var/lib/ipa/backup. If a backup is in another location then the full path must be provided. This was validated wrong, fixed. > > 2. Data backup cannot be done because the first 'for' never breaks > > + for instance in instances: > + for backend in backends: > + db_dir = (paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE % > + (instance, backend)) > + if os.path.exists(db_dir): > + break > + else: > + raise admintool.ScriptError( > + "Cannot restore a data backup into an empty > system") Oops, fixed. > > 3. When #2 fixed, data backup with --no-logs doesn't raise warning as > requested in ticket. IMO such a warning does not make sense. You request no logs, you get no logs, I don't see anything worth warning about here. > > 4. Since backup type is detected automatically(--data doesn't have to be > specified for data restore), I guess that the ticket requirement: `Here > expecting an error message that --online option can only provided along > with --data option. ` is invalid, right? > > Man page states that --online requires --data option, which is not true. Fixed in man page. > > 5. Nitpick: imho option validation should be done before temp dir creation. Fixed. > > 6. pep8, fixing them is up to you: > > ./ipaserver/install/ipa_restore.py:150:5: E129 visually indented line > with same indent as next logical line > ./ipaserver/install/ipa_restore.py:184:13: E128 continuation line > under-indented for visual indent Fixed. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-387.1-Fix-validation-of-ipa-restore-options.patch Type: text/x-patch Size: 13591 bytes Desc: not available URL: From tbabej at redhat.com Tue Jan 13 13:36:32 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Jan 2015 14:36:32 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <54B51165.3020808@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> <54905A55.5060209@redhat.com> <5491900B.8060209@redhat.com> <54AAAB59.6030101@redhat.com> <54B407B4.6010805@redhat.com> <54B4DFB5.4010803@redhat.com> <54B51165.3020808@redhat.com> Message-ID: <54B51F60.5090201@redhat.com> On 01/13/2015 01:36 PM, Martin Basti wrote: > On 13/01/15 10:04, Martin Kosek wrote: >> On 01/12/2015 06:43 PM, Martin Basti wrote: >>> On 05/01/15 16:18, Martin Basti wrote: >>>> On 17/12/14 15:15, Martin Basti wrote: >>>>> On 16/12/14 17:14, Martin Basti wrote: >>>>>> On 15/12/14 20:15, Martin Basti wrote: >>>>>>> On 15/12/14 19:18, Martin Basti wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4750 >>>>>>>> >>>>>>>> Patches need rebase and minor pytest modification to apply on >>>>>>>> master, I >>>>>>>> will do that after review. >>>>>>>> >>>>>>>> Patches for ipa-4-1 attached. >>>>>>>> >>>>>>>> >>>>>>> I forgot to fix copy paste error. >>>>>>> >>>>>>> Updated patches attached >>>>>>> >>>>>> Removed unneeded nsrecord validation in 2 tests >>>>>> >>>>>> updated patches attached >>>>>> >>>>> Added: >>>>> >>>>> * find forward zone with --forward-policy=none (no fwzone exists) >>>>> * find forward zone with --forward-policy=only (no fwzone exists) >>>>> * find forward zone with --forward-policy=first (no fwzone exists) >>>>> * enable enabled zone >>>>> * disable disabled zone >>>>> >>>>> Patches attached. >>>>> >>>>> >>>> Hi Scott, could you ack or nack the patchset, other test tickets >>>> are waiting, >>>> and we want to avoid huge rebases/merging >>>> >>> From QA point of view, tests are OK. Can somebody do code review >>> please? >> Code looks OK, runs cleanly (except that I thought that wait_for_dns >> is boolean >> value and not an integer :-/) >> >> So ACK from me. After you prepare a version for master branch, we can >> push them. >> >> Martin > Rebased patches attached > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master: 92feba2223575856820c2b95beab88a5229b4f6e -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Jan 13 13:39:29 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Jan 2015 14:39:29 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <54B51F60.5090201@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> <54905A55.5060209@redhat.com> <5491900B.8060209@redhat.com> <54AAAB59.6030101@redhat.com> <54B407B4.6010805@redhat.com> <54B4DFB5.4010803@redhat.com> <54B51165.3020808@redhat.com> <54B51F60.5090201@redhat.com> Message-ID: <54B52011.1060205@redhat.com> On 01/13/2015 02:36 PM, Tomas Babej wrote: > > On 01/13/2015 01:36 PM, Martin Basti wrote: >> On 13/01/15 10:04, Martin Kosek wrote: >>> On 01/12/2015 06:43 PM, Martin Basti wrote: >>>> On 05/01/15 16:18, Martin Basti wrote: >>>>> On 17/12/14 15:15, Martin Basti wrote: >>>>>> On 16/12/14 17:14, Martin Basti wrote: >>>>>>> On 15/12/14 20:15, Martin Basti wrote: >>>>>>>> On 15/12/14 19:18, Martin Basti wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4750 >>>>>>>>> >>>>>>>>> Patches need rebase and minor pytest modification to apply on >>>>>>>>> master, I >>>>>>>>> will do that after review. >>>>>>>>> >>>>>>>>> Patches for ipa-4-1 attached. >>>>>>>>> >>>>>>>>> >>>>>>>> I forgot to fix copy paste error. >>>>>>>> >>>>>>>> Updated patches attached >>>>>>>> >>>>>>> Removed unneeded nsrecord validation in 2 tests >>>>>>> >>>>>>> updated patches attached >>>>>>> >>>>>> Added: >>>>>> >>>>>> * find forward zone with --forward-policy=none (no fwzone exists) >>>>>> * find forward zone with --forward-policy=only (no fwzone exists) >>>>>> * find forward zone with --forward-policy=first (no fwzone exists) >>>>>> * enable enabled zone >>>>>> * disable disabled zone >>>>>> >>>>>> Patches attached. >>>>>> >>>>>> >>>>> Hi Scott, could you ack or nack the patchset, other test tickets >>>>> are waiting, >>>>> and we want to avoid huge rebases/merging >>>>> >>>> From QA point of view, tests are OK. Can somebody do code review >>>> please? >>> Code looks OK, runs cleanly (except that I thought that wait_for_dns >>> is boolean >>> value and not an integer :-/) >>> >>> So ACK from me. After you prepare a version for master branch, we >>> can push them. >>> >>> Martin >> Rebased patches attached >> >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Pushed to master: 92feba2223575856820c2b95beab88a5229b4f6e > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org Also pushed the 4.1 version: Pushed to ipa-4-1: 9f3b445ed39f4c1ecc3007136223d869fe9cf37b -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Tue Jan 13 13:44:24 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 14:44:24 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B3ED34.6030500@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> <54B3E87D.9020307@redhat.com> <54B3E8F5.9030503@redhat.com> <54B3ED34.6030500@redhat.com> Message-ID: <54B52138.1010403@redhat.com> On 01/12/2015 04:50 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Dne 12.1.2015 v 13:37 David Kupka napsal(a): >>>>> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>>>>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>>>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>>>>> >>>>>>> Looking at this patch, are data-only backups supposed to work >>>>>>> properly >>>>>>> then? >>>>>>> Wouldn't for example Directory Server fail to start when cn=config >>>>>>> contain some >>>>>>> hostname-bound values? >>>>>>> >>>>>>> Just checking... >>>>>>> >>>>>> >>>>>> IMO the error should be raised in both data-only and full restore, >>>>>> if in >>>>>> unattended mode or the user wishes not to continue. >>>>>> >>>>> Description of the problem in ticket states: "I tried to run >>>>> ipa-restore >>>>> (full kind) on replica from full backup taken on master and was >>>>> expecting an error message that restore can not proceed and only data >>>>> restore possible." >>>>> >>>>> I created the patch based on this request. Is it wrong and should >>>>> ipa-restore fail every time when hostnames does not match? >>>> >>>> Yes, as Martin pointed out, the data may contain references to the >>>> hostname. >>>> >>>>> Does it make >>>>> sense to allow user to force the restoration in this case? >>>> >>>> Yes, if the users wish, they should be allowed to continue. >>> >>> IIRC a data restore is just the data from the replicated tree so there >>> is nothing hostname-specific. It is probably worth investigating so we >>> don't go too far one way or the other. >> >> There's at least cn=,cn=masters,cn=etc,. > > That's part of the replicated tree, but it does raise a question: > > What would it mean if you did a data restore to a server that doesn't > exist as a master in the realm? Geez, I don't know, but it likely > wouldn't go well. Checking for that would be quite an issue and it would > surely exercise the python-ldap ldif module. > > Is it illegal though? I don't know. Any keytabs would be bad b/c the > Kerberos master key is different. In all likelihood things would just go > south. I imagine someone might try this in an attempt to setup a > test/integration environment. It just wouldn't work. > > In a replicated environment though, with hosts A and B, restoring the > data from B on A is probably not a big deal, though it does raise the > question of "why the heck would you do this?" It could be that you only > did backups on B and don't want to do a full re-init on A due to > size/time/moon phase. > >> >>> >>> A full restore definitely shouldn't be done on the wrong host as it will >>> restore certificates and keytabs that are definitely host-specific. >> >> Should the continue prompt be removed then? > > Well, you've just about got me convinced we shouldn't allow it, at least > not without several "do you really want to do this?" prompts. > > This seems to fall in the range of "yeah, it will work if you know what > you're doing, but why would you ever want to?" I think until that > question is answered it is safer to disallow it. I'd be ok with a ticket > into the deferred to investigate this later to see if it can be relaxed. > > rob > Ok, changed to remove the prompt and raise error. We can bring it back once some user comes with convincing reason. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0036-3-Abort-backup-restoration-on-not-matching-host.patch Type: text/x-patch Size: 1706 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 13 13:57:19 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 14:57:19 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B52138.1010403@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> <54B3E87D.9020307@redhat.com> <54B3E8F5.9030503@redhat.com> <54B3ED34.6030500@redhat.com> <54B52138.1010403@redhat.com> Message-ID: <54B5243F.6090802@redhat.com> Dne 13.1.2015 v 14:44 David Kupka napsal(a): > On 01/12/2015 04:50 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 12.1.2015 v 13:37 David Kupka napsal(a): >>>>>> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>>>>>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>>>>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>>>>>> >>>>>>>> Looking at this patch, are data-only backups supposed to work >>>>>>>> properly >>>>>>>> then? >>>>>>>> Wouldn't for example Directory Server fail to start when cn=config >>>>>>>> contain some >>>>>>>> hostname-bound values? >>>>>>>> >>>>>>>> Just checking... >>>>>>>> >>>>>>> >>>>>>> IMO the error should be raised in both data-only and full restore, >>>>>>> if in >>>>>>> unattended mode or the user wishes not to continue. >>>>>>> >>>>>> Description of the problem in ticket states: "I tried to run >>>>>> ipa-restore >>>>>> (full kind) on replica from full backup taken on master and was >>>>>> expecting an error message that restore can not proceed and only data >>>>>> restore possible." >>>>>> >>>>>> I created the patch based on this request. Is it wrong and should >>>>>> ipa-restore fail every time when hostnames does not match? >>>>> >>>>> Yes, as Martin pointed out, the data may contain references to the >>>>> hostname. >>>>> >>>>>> Does it make >>>>>> sense to allow user to force the restoration in this case? >>>>> >>>>> Yes, if the users wish, they should be allowed to continue. >>>> >>>> IIRC a data restore is just the data from the replicated tree so there >>>> is nothing hostname-specific. It is probably worth investigating so we >>>> don't go too far one way or the other. >>> >>> There's at least cn=,cn=masters,cn=etc,. >> >> That's part of the replicated tree, but it does raise a question: >> >> What would it mean if you did a data restore to a server that doesn't >> exist as a master in the realm? Geez, I don't know, but it likely >> wouldn't go well. Checking for that would be quite an issue and it would >> surely exercise the python-ldap ldif module. >> >> Is it illegal though? I don't know. Any keytabs would be bad b/c the >> Kerberos master key is different. In all likelihood things would just go >> south. I imagine someone might try this in an attempt to setup a >> test/integration environment. It just wouldn't work. >> >> In a replicated environment though, with hosts A and B, restoring the >> data from B on A is probably not a big deal, though it does raise the >> question of "why the heck would you do this?" It could be that you only >> did backups on B and don't want to do a full re-init on A due to >> size/time/moon phase. >> >>> >>>> >>>> A full restore definitely shouldn't be done on the wrong host as it >>>> will >>>> restore certificates and keytabs that are definitely host-specific. >>> >>> Should the continue prompt be removed then? >> >> Well, you've just about got me convinced we shouldn't allow it, at least >> not without several "do you really want to do this?" prompts. >> >> This seems to fall in the range of "yeah, it will work if you know what >> you're doing, but why would you ever want to?" I think until that >> question is answered it is safer to disallow it. I'd be ok with a ticket >> into the deferred to investigate this later to see if it can be relaxed. >> >> rob >> > Ok, changed to remove the prompt and raise error. We can bring it back > once some user comes with convincing reason. > The error doesn't need to be logged, raising a ScriptError is perfectly sufficient (please use the message that includes both of the hostnames). -- Jan Cholasta From dkupka at redhat.com Tue Jan 13 14:07:05 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 15:07:05 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B5243F.6090802@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> <54B3E87D.9020307@redhat.com> <54B3E8F5.9030503@redhat.com> <54B3ED34.6030500@redhat.com> <54B52138.1010403@redhat.com> <54B5243F.6090802@redhat.com> Message-ID: <54B52689.4090101@redhat.com> On 01/13/2015 02:57 PM, Jan Cholasta wrote: > Dne 13.1.2015 v 14:44 David Kupka napsal(a): >> On 01/12/2015 04:50 PM, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a): >>>>> Jan Cholasta wrote: >>>>>> Dne 12.1.2015 v 13:37 David Kupka napsal(a): >>>>>>> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>>>>>>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>>>>>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>>>>>>> >>>>>>>>> Looking at this patch, are data-only backups supposed to work >>>>>>>>> properly >>>>>>>>> then? >>>>>>>>> Wouldn't for example Directory Server fail to start when cn=config >>>>>>>>> contain some >>>>>>>>> hostname-bound values? >>>>>>>>> >>>>>>>>> Just checking... >>>>>>>>> >>>>>>>> >>>>>>>> IMO the error should be raised in both data-only and full restore, >>>>>>>> if in >>>>>>>> unattended mode or the user wishes not to continue. >>>>>>>> >>>>>>> Description of the problem in ticket states: "I tried to run >>>>>>> ipa-restore >>>>>>> (full kind) on replica from full backup taken on master and was >>>>>>> expecting an error message that restore can not proceed and only >>>>>>> data >>>>>>> restore possible." >>>>>>> >>>>>>> I created the patch based on this request. Is it wrong and should >>>>>>> ipa-restore fail every time when hostnames does not match? >>>>>> >>>>>> Yes, as Martin pointed out, the data may contain references to the >>>>>> hostname. >>>>>> >>>>>>> Does it make >>>>>>> sense to allow user to force the restoration in this case? >>>>>> >>>>>> Yes, if the users wish, they should be allowed to continue. >>>>> >>>>> IIRC a data restore is just the data from the replicated tree so there >>>>> is nothing hostname-specific. It is probably worth investigating so we >>>>> don't go too far one way or the other. >>>> >>>> There's at least cn=,cn=masters,cn=etc,. >>> >>> That's part of the replicated tree, but it does raise a question: >>> >>> What would it mean if you did a data restore to a server that doesn't >>> exist as a master in the realm? Geez, I don't know, but it likely >>> wouldn't go well. Checking for that would be quite an issue and it would >>> surely exercise the python-ldap ldif module. >>> >>> Is it illegal though? I don't know. Any keytabs would be bad b/c the >>> Kerberos master key is different. In all likelihood things would just go >>> south. I imagine someone might try this in an attempt to setup a >>> test/integration environment. It just wouldn't work. >>> >>> In a replicated environment though, with hosts A and B, restoring the >>> data from B on A is probably not a big deal, though it does raise the >>> question of "why the heck would you do this?" It could be that you only >>> did backups on B and don't want to do a full re-init on A due to >>> size/time/moon phase. >>> >>>> >>>>> >>>>> A full restore definitely shouldn't be done on the wrong host as it >>>>> will >>>>> restore certificates and keytabs that are definitely host-specific. >>>> >>>> Should the continue prompt be removed then? >>> >>> Well, you've just about got me convinced we shouldn't allow it, at least >>> not without several "do you really want to do this?" prompts. >>> >>> This seems to fall in the range of "yeah, it will work if you know what >>> you're doing, but why would you ever want to?" I think until that >>> question is answered it is safer to disallow it. I'd be ok with a ticket >>> into the deferred to investigate this later to see if it can be relaxed. >>> >>> rob >>> >> Ok, changed to remove the prompt and raise error. We can bring it back >> once some user comes with convincing reason. >> > > The error doesn't need to be logged, raising a ScriptError is perfectly > sufficient (please use the message that includes both of the hostnames). > Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0036-4-Abort-backup-restoration-on-not-matching-host.patch Type: text/x-patch Size: 1675 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 13 14:07:35 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Jan 2015 15:07:35 +0100 Subject: [Freeipa-devel] [PATCH 0319] Fix crash caused by race condition during resolver cache flushing In-Reply-To: <54B51AA7.7070801@redhat.com> References: <54B51AA7.7070801@redhat.com> Message-ID: <54B526A7.2030502@redhat.com> On 13.1.2015 14:16, Petr Spacek wrote: > Hello, > > This patch should be applied to v2 branch. > > Fix crash caused by race condition during resolver cache flushing. > > dns_view_flushcache() call has to be always done in single-thread mode. > Locking around the call was missing in forwarder reconfiguration and > zone deletion which could cause crash. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/142 Note: master branch should not be affected, this patch is relevant only to versions < 5.3. -- Petr^2 Spacek From pvoborni at redhat.com Tue Jan 13 14:34:58 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 15:34:58 +0100 Subject: [Freeipa-devel] [PATCH] 0037 Remove ipanttrustauthincoming/ipanttrustauthoutgoing from ipa trust-add output. In-Reply-To: <54B514D1.4040608@redhat.com> References: <54B510A0.4010504@redhat.com> <54B5121A.6070705@redhat.com> <54B514D1.4040608@redhat.com> Message-ID: <54B52D12.2050501@redhat.com> On 01/13/2015 01:51 PM, David Kupka wrote: > On 01/13/2015 01:39 PM, Petr Vobornik wrote: >> On 01/13/2015 01:33 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4787 >>> >> >> >> Haven't try it, but: >> >> have you considered: >> result['result'].pop('ipanttrustauthincoming', None) >> ? > I haven't and it looks better, thanks. > Fixed patch attached. > ACK Pushed to: master: b0f412177fd36e81e71bea63b8923825c7ab28dd ipa-4-1: 333b899770762936372116ba472e42cabaaaecda -- Petr Vobornik From dkupka at redhat.com Tue Jan 13 14:54:35 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 15:54:35 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B52689.4090101@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> <54B3E87D.9020307@redhat.com> <54B3E8F5.9030503@redhat.com> <54B3ED34.6030500@redhat.com> <54B52138.1010403@redhat.com> <54B5243F.6090802@redhat.com> <54B52689.4090101@redhat.com> Message-ID: <54B531AB.9050503@redhat.com> On 01/13/2015 03:07 PM, David Kupka wrote: > On 01/13/2015 02:57 PM, Jan Cholasta wrote: >> Dne 13.1.2015 v 14:44 David Kupka napsal(a): >>> On 01/12/2015 04:50 PM, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Dne 12.1.2015 v 13:37 David Kupka napsal(a): >>>>>>>> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>>>>>>>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>>>>>>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>>>>>>>> >>>>>>>>>> Looking at this patch, are data-only backups supposed to work >>>>>>>>>> properly >>>>>>>>>> then? >>>>>>>>>> Wouldn't for example Directory Server fail to start when >>>>>>>>>> cn=config >>>>>>>>>> contain some >>>>>>>>>> hostname-bound values? >>>>>>>>>> >>>>>>>>>> Just checking... >>>>>>>>>> >>>>>>>>> >>>>>>>>> IMO the error should be raised in both data-only and full restore, >>>>>>>>> if in >>>>>>>>> unattended mode or the user wishes not to continue. >>>>>>>>> >>>>>>>> Description of the problem in ticket states: "I tried to run >>>>>>>> ipa-restore >>>>>>>> (full kind) on replica from full backup taken on master and was >>>>>>>> expecting an error message that restore can not proceed and only >>>>>>>> data >>>>>>>> restore possible." >>>>>>>> >>>>>>>> I created the patch based on this request. Is it wrong and should >>>>>>>> ipa-restore fail every time when hostnames does not match? >>>>>>> >>>>>>> Yes, as Martin pointed out, the data may contain references to the >>>>>>> hostname. >>>>>>> >>>>>>>> Does it make >>>>>>>> sense to allow user to force the restoration in this case? >>>>>>> >>>>>>> Yes, if the users wish, they should be allowed to continue. >>>>>> >>>>>> IIRC a data restore is just the data from the replicated tree so >>>>>> there >>>>>> is nothing hostname-specific. It is probably worth investigating >>>>>> so we >>>>>> don't go too far one way or the other. >>>>> >>>>> There's at least cn=,cn=masters,cn=etc,. >>>> >>>> That's part of the replicated tree, but it does raise a question: >>>> >>>> What would it mean if you did a data restore to a server that doesn't >>>> exist as a master in the realm? Geez, I don't know, but it likely >>>> wouldn't go well. Checking for that would be quite an issue and it >>>> would >>>> surely exercise the python-ldap ldif module. >>>> >>>> Is it illegal though? I don't know. Any keytabs would be bad b/c the >>>> Kerberos master key is different. In all likelihood things would >>>> just go >>>> south. I imagine someone might try this in an attempt to setup a >>>> test/integration environment. It just wouldn't work. >>>> >>>> In a replicated environment though, with hosts A and B, restoring the >>>> data from B on A is probably not a big deal, though it does raise the >>>> question of "why the heck would you do this?" It could be that you only >>>> did backups on B and don't want to do a full re-init on A due to >>>> size/time/moon phase. >>>> >>>>> >>>>>> >>>>>> A full restore definitely shouldn't be done on the wrong host as it >>>>>> will >>>>>> restore certificates and keytabs that are definitely host-specific. >>>>> >>>>> Should the continue prompt be removed then? >>>> >>>> Well, you've just about got me convinced we shouldn't allow it, at >>>> least >>>> not without several "do you really want to do this?" prompts. >>>> >>>> This seems to fall in the range of "yeah, it will work if you know what >>>> you're doing, but why would you ever want to?" I think until that >>>> question is answered it is safer to disallow it. I'd be ok with a >>>> ticket >>>> into the deferred to investigate this later to see if it can be >>>> relaxed. >>>> >>>> rob >>>> >>> Ok, changed to remove the prompt and raise error. We can bring it back >>> once some user comes with convincing reason. >>> >> >> The error doesn't need to be logged, raising a ScriptError is perfectly >> sufficient (please use the message that includes both of the hostnames). >> > Updated patch attached. > Fixed indentation. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0036-5-Abort-backup-restoration-on-not-matching-host.patch Type: text/x-patch Size: 1656 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 13 15:02:00 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 16:02:00 +0100 Subject: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host. In-Reply-To: <54B531AB.9050503@redhat.com> References: <54B3B5C6.7000802@redhat.com> <54B3B94B.4040902@redhat.com> <54B3BAAD.4080406@redhat.com> <54B3BFED.2070201@redhat.com> <54B3C0FF.7030809@redhat.com> <54B3E87D.9020307@redhat.com> <54B3E8F5.9030503@redhat.com> <54B3ED34.6030500@redhat.com> <54B52138.1010403@redhat.com> <54B5243F.6090802@redhat.com> <54B52689.4090101@redhat.com> <54B531AB.9050503@redhat.com> Message-ID: <54B53368.9030807@redhat.com> Dne 13.1.2015 v 15:54 David Kupka napsal(a): > On 01/13/2015 03:07 PM, David Kupka wrote: >> On 01/13/2015 02:57 PM, Jan Cholasta wrote: >>> Dne 13.1.2015 v 14:44 David Kupka napsal(a): >>>> On 01/12/2015 04:50 PM, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a): >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 12.1.2015 v 13:37 David Kupka napsal(a): >>>>>>>>> On 01/12/2015 01:14 PM, Jan Cholasta wrote: >>>>>>>>>> Dne 12.1.2015 v 13:08 Martin Kosek napsal(a): >>>>>>>>>>> On 01/12/2015 12:53 PM, David Kupka wrote: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4823 >>>>>>>>>>> >>>>>>>>>>> Looking at this patch, are data-only backups supposed to work >>>>>>>>>>> properly >>>>>>>>>>> then? >>>>>>>>>>> Wouldn't for example Directory Server fail to start when >>>>>>>>>>> cn=config >>>>>>>>>>> contain some >>>>>>>>>>> hostname-bound values? >>>>>>>>>>> >>>>>>>>>>> Just checking... >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> IMO the error should be raised in both data-only and full >>>>>>>>>> restore, >>>>>>>>>> if in >>>>>>>>>> unattended mode or the user wishes not to continue. >>>>>>>>>> >>>>>>>>> Description of the problem in ticket states: "I tried to run >>>>>>>>> ipa-restore >>>>>>>>> (full kind) on replica from full backup taken on master and was >>>>>>>>> expecting an error message that restore can not proceed and only >>>>>>>>> data >>>>>>>>> restore possible." >>>>>>>>> >>>>>>>>> I created the patch based on this request. Is it wrong and should >>>>>>>>> ipa-restore fail every time when hostnames does not match? >>>>>>>> >>>>>>>> Yes, as Martin pointed out, the data may contain references to the >>>>>>>> hostname. >>>>>>>> >>>>>>>>> Does it make >>>>>>>>> sense to allow user to force the restoration in this case? >>>>>>>> >>>>>>>> Yes, if the users wish, they should be allowed to continue. >>>>>>> >>>>>>> IIRC a data restore is just the data from the replicated tree so >>>>>>> there >>>>>>> is nothing hostname-specific. It is probably worth investigating >>>>>>> so we >>>>>>> don't go too far one way or the other. >>>>>> >>>>>> There's at least cn=,cn=masters,cn=etc,. >>>>> >>>>> That's part of the replicated tree, but it does raise a question: >>>>> >>>>> What would it mean if you did a data restore to a server that doesn't >>>>> exist as a master in the realm? Geez, I don't know, but it likely >>>>> wouldn't go well. Checking for that would be quite an issue and it >>>>> would >>>>> surely exercise the python-ldap ldif module. >>>>> >>>>> Is it illegal though? I don't know. Any keytabs would be bad b/c the >>>>> Kerberos master key is different. In all likelihood things would >>>>> just go >>>>> south. I imagine someone might try this in an attempt to setup a >>>>> test/integration environment. It just wouldn't work. >>>>> >>>>> In a replicated environment though, with hosts A and B, restoring the >>>>> data from B on A is probably not a big deal, though it does raise the >>>>> question of "why the heck would you do this?" It could be that you >>>>> only >>>>> did backups on B and don't want to do a full re-init on A due to >>>>> size/time/moon phase. >>>>> >>>>>> >>>>>>> >>>>>>> A full restore definitely shouldn't be done on the wrong host as it >>>>>>> will >>>>>>> restore certificates and keytabs that are definitely host-specific. >>>>>> >>>>>> Should the continue prompt be removed then? >>>>> >>>>> Well, you've just about got me convinced we shouldn't allow it, at >>>>> least >>>>> not without several "do you really want to do this?" prompts. >>>>> >>>>> This seems to fall in the range of "yeah, it will work if you know >>>>> what >>>>> you're doing, but why would you ever want to?" I think until that >>>>> question is answered it is safer to disallow it. I'd be ok with a >>>>> ticket >>>>> into the deferred to investigate this later to see if it can be >>>>> relaxed. >>>>> >>>>> rob >>>>> >>>> Ok, changed to remove the prompt and raise error. We can bring it back >>>> once some user comes with convincing reason. >>>> >>> >>> The error doesn't need to be logged, raising a ScriptError is perfectly >>> sufficient (please use the message that includes both of the hostnames). >>> >> Updated patch attached. >> > Fixed indentation. > Thanks, ACK. Pushed to: master: b6c58ff238eb335dcb2a80fc98ecfe8bce5e2422 ipa-4-1: 640a4b30c2475d7b62cc2407af358a8951c34121 -- Jan Cholasta From rcritten at redhat.com Tue Jan 13 15:03:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Jan 2015 10:03:33 -0500 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation In-Reply-To: <54B4DB7A.4080307@redhat.com> References: <54B3FA19.6000903@redhat.com> <54B4D5B4.3050301@redhat.com> <54B4DB7A.4080307@redhat.com> Message-ID: <54B533C5.60402@redhat.com> Jan Cholasta wrote: > Dne 13.1.2015 v 09:22 Martin Kosek napsal(a): >> On 01/12/2015 05:45 PM, Martin Babinsky wrote: >>> related to ticket https://fedorahosted.org/freeipa/ticket/4808 >>> >>> Patch attached. >>> >>> Martin^3 >> >> I think the --tgt-kinit-attempts approach is good one. Couple comments >> I have >> when reading the patch: >> >> 1) Function >> +def get_host_tgt(options, keytab, host, realm, env): >> should be made more general purpose and instead of whole "options", it >> should >> rather accept just "kinit_attemps". It will then enable future >> generations to >> reuse the function for something else. Just a generally good practice, >> nothing >> critical. >> >> 2) I think >> + if returncode == 0: >> + root_logger.info("Attempt %d succeeded." % n_attempts) >> + break >> >> can be just DEBUG level. People do not need to know we will try >> multiple attempts. >> >> 3) It may be even better to print >> "Attempt %d/%d failed." instead of just number. But this is up to you. >> >> 4) I see several C-isms in the code, as a programming practice, let us >> remove >> them :-) In Python, the OK/notOK status is generally passed via >> exceptions, not >> return codes unless you really need them for anything meaningful. >> >> So, you can omit "raiseonerr=False" and have the handling code in an >> Except >> clause. When max number of attempts is breached, you then just raise the >> exception further (use bare "raise", to re-raise to keep the original >> stack). > > +1 > > Additionally: > > 5) I would prefer if the option was named --kinit-attempts instead of > --tgt-kinit-attempts (the "tgt" seems redundant). > > 6) Please do not use backslashes for line wrapping, unless it is > absolutely necessary. Instead, enclose the expression in parens for > implicit continuation: > > + help=("number of attempts to obtain host TGT" > + "if the first one fails (defaults to > %default).")) > > 7) Please follow PEP8 in new code: > > ipa-client/ipa-install/ipa-client-install:151:80: E501 line too long (93 >> 79 characters) > ipa-client/ipa-install/ipa-client-install:1100:1: E302 expected 2 blank > lines, found 1 > ipa-client/ipa-install/ipa-client-install:1107:29: E126 continuation > line over-indented for hanging indent > ipa-client/ipa-install/ipa-client-install:1107:41: E231 missing > whitespace after ',' > ipa-client/ipa-install/ipa-client-install:1108:29: E128 continuation > line under-indented for visual indent > ipa-client/ipa-install/ipa-client-install:1116:51: E225 missing > whitespace around operator > ipa-client/ipa-install/ipa-client-install:2453:80: E501 line too long > (88 > 79 characters) > ipa-client/ipa-install/ipa-client-install:2454:80: E501 line too long > (89 > 79 characters) > ipa-client/ipa-install/ipa-client-install:2531:80: E501 line too long > (83 > 79 characters) > ipa-client/ipa-install/ipa-client-install:2532:80: E501 line too long > (81 > 79 characters) > > Honza > I'd recommend a min/max validator too. Min 1 because 0 makes no sense, and max, I dunno, MAXINT if nothing else. Otherwise guaranteed to get kicked back by QE at some point. rob From tbabej at redhat.com Tue Jan 13 15:04:21 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 13 Jan 2015 16:04:21 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <546F340D.7090104@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> <546C9514.1080904@redhat.com> <546CA539.2050005@redhat.com> <546E0250.5000401@redhat.com> <546F13CD.9020803@redhat.com> <546F340D.7090104@redhat.com> Message-ID: <54B533F5.2060807@redhat.com> On 11/21/2014 01:46 PM, Jan Cholasta wrote: > Dne 21.11.2014 v 11:28 Tomas Babej napsal(a): >> >> On 11/20/2014 04:01 PM, Jan Cholasta wrote: >>> Dne 19.11.2014 v 15:12 Tomas Babej napsal(a): >>>> >>>> On 11/19/2014 02:03 PM, Jan Cholasta wrote: >>>>> Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): >>>>>> >>>>>> On 11/19/2014 12:51 PM, Martin Kosek wrote: >>>>>>> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>>>>>>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>>>>>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> When constructing a parent DN in LDAPSearch, we should always >>>>>>>>>> check that the parent object exists (hence use >>>>>>>>>> get_dn_if_exists), >>>>>>>>>> rather than search on unexistant containers (which can happen >>>>>>>>>> with get_dn). >>>>>>>>>> >>>>>>>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>>>>>>> and makes sure proper error message is raised. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>>>>>>> Doesn't it produce extra LDAP search thus making all our search >>>>>>>>> commands >>>>>>>>> slower? Is that what we want? >>>>>>>> No it does not make all of our LDAP search slower. It only >>>>>>>> happens for >>>>>>>> the objects that have parent objects, such as idoverrides or >>>>>>>> dnsrecords. >>>>>>> ... and makes them slower. >>>>>> >>>>>> What I was pointing out here is that this is not a issue for ALL >>>>>> *-find >>>>>> commands (e.g user-find, group-find will not suffer from it), as you >>>>>> incorrectly stated. >>>>>> >>>>>>> >>>>>>>>> Wouldn't it be better to distinguish between LDAP >>>>>>>>> search with no results and LDAP search with missing parent DN? >>>>>>>>> The >>>>>>>>> reply looks >>>>>>>>> different, at least in CLI: >>>>>>>> Up to discussion. We would probably need to introduce a new >>>>>>>> exception, >>>>>>>> like ParentObjectNotFound. >>>>>>>> >>>>>>>>> # search result >>>>>>>>> search: 4 >>>>>>>>> result: 0 Success >>>>>>>>> >>>>>>>>> # search result >>>>>>>>> search: 4 >>>>>>>>> result: 32 No such object >>>>>>>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>>>>>>> >>>>>>>>> Also, I do not think you can just stop using get_dn(), some >>>>>>>>> commands override >>>>>>>>> this call to get more complex searches (like host-find searching >>>>>>>>> for shortname). >>>>>>>> Look into the get_dn_if_exists, it just wraps around get_dn, so no >>>>>>>> issue >>>>>>>> here. Any custom behaviour is preserved. >>>>>>> Ah, ok, thanks for info. >>>>>>> >>>>>>>> To sum up, I think this is worth changing this behaviour by >>>>>>>> default, >>>>>>>> ignoring a non-matching value of the parent object is not a >>>>>>>> correct >>>>>>>> general approach in my opinion. >>>>>>> Well, that's the question. Whether we would leave DS to validate >>>>>>> the >>>>>>> search >>>>>>> itself or do all the pre-check ourselves. To me, doing just one >>>>>>> LDAP >>>>>>> search and >>>>>>> processing the error correctly looks better. But I can live even >>>>>>> with your >>>>>>> version then, I will leave the framework guardians like Honza or >>>>>>> Petr3 to decide. >>>>> >>>>> +1 on single LDAP search and proper error processing. >>>>> >>>>>> >>>>>> I see now what you're trying to suggest. However, the reason boils >>>>>> down to ipaldap.find_entries method not differentiating between a >>>>>> LDAP search that returns error code 32 (No such object) and LDAP >>>>>> search returning error code 0 (Success), but returning no results. >>>>>> >>>>>> In both cases errors.NotFound is raised. >>>>>> >>>>>> The reason I did not go this way is that changing the find_entries >>>>>> method >>>>>> is quite more invasive as this is the method subsenqently called by >>>>>> almost >>>>>> any command. >>>>> >>>>> You can always derive the new error (ParentNotFound or whatever) on >>>>> NotFound, so old code won't break. >>>>> >>>> >>>> Thanks for the suggestsions. >>>> >>>> Attached is a new patch which hooks into find_entries method and >>>> differentiates between the cases. >>>> >>> >>> Why are you special casing base scope search? >>> >> >> Since base search is performed only on the entry specified by the DN, >> there is no need to differentiate between ContainerNotFound and >> NotFound. >> >> So the logic is as follows: >> >> subtree search - ContainerNotFound is raised when container does not >> exist, NotFound if search provided no results >> onelevel search - the same >> base search - NotFound is raised if the specified DN does not exist >> > > There is a difference between a search on a non-existent entry and a > search on an existent entry with a non-matching filter. This > difference exists on LDAP level and applies to all search scopes, not > just the base scope. > > I don't think hiding this difference is useful at all. Remember that > this bug exists because we were hiding the difference in the first place. > > Also, after giving this some thought, I think it would be better to > create a new error for the case where there is no match instead of the > case where the entry does not exist. NotFound pretty much corresponds > to LDAP's NO_SUCH_OBJECT, something like NoMatchingEntry or > EmptyResult would fit the no-match result better. > Sorry for the delay, I thought this was on review. Attaching the updated patch. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0286-3-baseldap-Handle-missing-parent-objects-properly-in-f.patch Type: text/x-patch Size: 3147 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 13 15:37:32 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 16:37:32 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B51D16.7020709@redhat.com> References: <54B3CBF1.602@redhat.com> <54B50929.20306@redhat.com> <54B51D16.7020709@redhat.com> Message-ID: <54B53BBC.5050301@redhat.com> On 01/13/2015 02:26 PM, Jan Cholasta wrote: > Dne 13.1.2015 v 13:01 Petr Vobornik napsal(a): >> On 01/12/2015 02:28 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Note that --data with data-only backup and --logs-only with data-only >>> restore are deliberately ignored and considered no-op. >>> >>> Honza >>> >> >> 3. When #2 fixed, data backup with --no-logs doesn't raise warning as >> requested in ticket. > > IMO such a warning does not make sense. You request no logs, you get no > logs, I don't see anything worth warning about here. ok, makes sense > >> >> 5. Nitpick: imho option validation should be done before temp dir >> creation. > > Fixed. You've also moved self.header = os.path.join(self.backup_dir, 'header') below self.read_header() --> restore fails everytime > > Updated patch attached. > -- Petr Vobornik From pvoborni at redhat.com Tue Jan 13 15:47:07 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 16:47:07 +0100 Subject: [Freeipa-devel] [PATCH] 389 Fix ipa-restore on systems without IPA installed In-Reply-To: <54B4F959.90201@redhat.com> References: <54B3FF68.3040806@redhat.com> <54B4E972.5020804@redhat.com> <54B4F959.90201@redhat.com> Message-ID: <54B53DFB.8050709@redhat.com> On 01/13/2015 11:54 AM, Jan Cholasta wrote: > Dne 13.1.2015 v 10:46 Petr Vobornik napsal(a): >> On 01/12/2015 06:07 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes >>> . >>> >>> Honza >>> >> >> Is there a reason why `installutils.check_server_configuration() ` >> is called in `cert_restore_prepare`, ie., method which is not >> really connected with it, and not in `run` as for DATA backup? > > Full restore may be done when IPA is not installed, but > cert_restore_prepare crashes when IPA is not installed, the check > prevents that. > > Anyway, see the attached patch for an alternative, possibly better > approach. > Works, but with full restore I got: ... Disabling all replication. Unable to get connection, skipping disabling agreements: Unable to bind to LDAP server: [Errno 2] No such file or directory Stopping IPA services Restoring files ... I wonder if it needs a better error message, it may be confusing for users. Btw what is the use case for fullrestore without IPA? Is it somewhere documented or mentioned? -- Petr Vobornik From mbabinsk at redhat.com Tue Jan 13 15:48:56 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Jan 2015 16:48:56 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation In-Reply-To: <54B4DB7A.4080307@redhat.com> References: <54B3FA19.6000903@redhat.com> <54B4D5B4.3050301@redhat.com> <54B4DB7A.4080307@redhat.com> Message-ID: <54B53E68.60000@redhat.com> On 01/13/2015 09:46 AM, Jan Cholasta wrote: > Dne 13.1.2015 v 09:22 Martin Kosek napsal(a): >> On 01/12/2015 05:45 PM, Martin Babinsky wrote: >>> related to ticket https://fedorahosted.org/freeipa/ticket/4808 >>> >>> Patch attached. >>> >>> Martin^3 >> >> I think the --tgt-kinit-attempts approach is good one. Couple comments >> I have >> when reading the patch: >> >> 1) Function >> +def get_host_tgt(options, keytab, host, realm, env): >> should be made more general purpose and instead of whole "options", it >> should >> rather accept just "kinit_attemps". It will then enable future >> generations to >> reuse the function for something else. Just a generally good practice, >> nothing >> critical. >> >> 2) I think >> + if returncode == 0: >> + root_logger.info("Attempt %d succeeded." % n_attempts) >> + break >> >> can be just DEBUG level. People do not need to know we will try >> multiple attempts. >> >> 3) It may be even better to print >> "Attempt %d/%d failed." instead of just number. But this is up to you. >> >> 4) I see several C-isms in the code, as a programming practice, let us >> remove >> them :-) In Python, the OK/notOK status is generally passed via >> exceptions, not >> return codes unless you really need them for anything meaningful. >> >> So, you can omit "raiseonerr=False" and have the handling code in an >> Except >> clause. When max number of attempts is breached, you then just raise the >> exception further (use bare "raise", to re-raise to keep the original >> stack). > > +1 > > Additionally: > > 5) I would prefer if the option was named --kinit-attempts instead of > --tgt-kinit-attempts (the "tgt" seems redundant). > > 6) Please do not use backslashes for line wrapping, unless it is > absolutely necessary. Instead, enclose the expression in parens for > implicit continuation: > > + help=("number of attempts to obtain host TGT" > + "if the first one fails (defaults to > %default).")) > > 7) Please follow PEP8 in new code: > > ipa-client/ipa-install/ipa-client-install:151:80: E501 line too long (93 > > 79 characters) > ipa-client/ipa-install/ipa-client-install:1100:1: E302 expected 2 blank > lines, found 1 > ipa-client/ipa-install/ipa-client-install:1107:29: E126 continuation > line over-indented for hanging indent > ipa-client/ipa-install/ipa-client-install:1107:41: E231 missing > whitespace after ',' > ipa-client/ipa-install/ipa-client-install:1108:29: E128 continuation > line under-indented for visual indent > ipa-client/ipa-install/ipa-client-install:1116:51: E225 missing > whitespace around operator > ipa-client/ipa-install/ipa-client-install:2453:80: E501 line too long > (88 > 79 characters) > ipa-client/ipa-install/ipa-client-install:2454:80: E501 line too long > (89 > 79 characters) > ipa-client/ipa-install/ipa-client-install:2531:80: E501 line too long > (83 > 79 characters) > ipa-client/ipa-install/ipa-client-install:2532:80: E501 line too long > (81 > 79 characters) > > Honza > Thank you for your comments. Attaching the updated patch (I have sent the message much earlier, but only to Jan because I messed up the reply addresses in Thunderbird. Sorry for that). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0001-2-ipa-client-install-added-new-option.patch Type: text/x-patch Size: 4718 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Jan 13 16:01:13 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 13 Jan 2015 17:01:13 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation In-Reply-To: <54B533C5.60402@redhat.com> References: <54B3FA19.6000903@redhat.com> <54B4D5B4.3050301@redhat.com> <54B4DB7A.4080307@redhat.com> <54B533C5.60402@redhat.com> Message-ID: <54B54149.6020905@redhat.com> On 01/13/2015 04:03 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> Dne 13.1.2015 v 09:22 Martin Kosek napsal(a): >>> On 01/12/2015 05:45 PM, Martin Babinsky wrote: >>>> related to ticket https://fedorahosted.org/freeipa/ticket/4808 >>>> >>>> Patch attached. >>>> >>>> Martin^3 >>> >>> I think the --tgt-kinit-attempts approach is good one. Couple comments >>> I have >>> when reading the patch: >>> >>> 1) Function >>> +def get_host_tgt(options, keytab, host, realm, env): >>> should be made more general purpose and instead of whole "options", it >>> should >>> rather accept just "kinit_attemps". It will then enable future >>> generations to >>> reuse the function for something else. Just a generally good practice, >>> nothing >>> critical. >>> >>> 2) I think >>> + if returncode == 0: >>> + root_logger.info("Attempt %d succeeded." % n_attempts) >>> + break >>> >>> can be just DEBUG level. People do not need to know we will try >>> multiple attempts. >>> >>> 3) It may be even better to print >>> "Attempt %d/%d failed." instead of just number. But this is up to you. >>> >>> 4) I see several C-isms in the code, as a programming practice, let us >>> remove >>> them :-) In Python, the OK/notOK status is generally passed via >>> exceptions, not >>> return codes unless you really need them for anything meaningful. >>> >>> So, you can omit "raiseonerr=False" and have the handling code in an >>> Except >>> clause. When max number of attempts is breached, you then just raise the >>> exception further (use bare "raise", to re-raise to keep the original >>> stack). >> >> +1 >> >> Additionally: >> >> 5) I would prefer if the option was named --kinit-attempts instead of >> --tgt-kinit-attempts (the "tgt" seems redundant). >> >> 6) Please do not use backslashes for line wrapping, unless it is >> absolutely necessary. Instead, enclose the expression in parens for >> implicit continuation: >> >> + help=("number of attempts to obtain host TGT" >> + "if the first one fails (defaults to >> %default).")) >> >> 7) Please follow PEP8 in new code: >> >> ipa-client/ipa-install/ipa-client-install:151:80: E501 line too long (93 >>> 79 characters) >> ipa-client/ipa-install/ipa-client-install:1100:1: E302 expected 2 blank >> lines, found 1 >> ipa-client/ipa-install/ipa-client-install:1107:29: E126 continuation >> line over-indented for hanging indent >> ipa-client/ipa-install/ipa-client-install:1107:41: E231 missing >> whitespace after ',' >> ipa-client/ipa-install/ipa-client-install:1108:29: E128 continuation >> line under-indented for visual indent >> ipa-client/ipa-install/ipa-client-install:1116:51: E225 missing >> whitespace around operator >> ipa-client/ipa-install/ipa-client-install:2453:80: E501 line too long >> (88 > 79 characters) >> ipa-client/ipa-install/ipa-client-install:2454:80: E501 line too long >> (89 > 79 characters) >> ipa-client/ipa-install/ipa-client-install:2531:80: E501 line too long >> (83 > 79 characters) >> ipa-client/ipa-install/ipa-client-install:2532:80: E501 line too long >> (81 > 79 characters) >> >> Honza >> > > I'd recommend a min/max validator too. Min 1 because 0 makes no sense, > and max, I dunno, MAXINT if nothing else. Otherwise guaranteed to get > kicked back by QE at some point. > > rob > Yes I was also thinking about that. The code kinda works even with negative values (makes at least one pass of TGT kinit), but I guess that's really not how it should behave. I will update the patch accordingly. There is also a question of semantics: should this option mean "Perform N additional attempts to get TGT if the first one fails" (this is the current implementation and N=0 then means "no additional attempts except the first one"), or should the meaning be "Perform N TGT attempts in total" (then N=0 would mean "do not do any TGT kinit calls" and thus makes no sense)? I hope I made the distinction clear enough. Martin^3 From jcholast at redhat.com Tue Jan 13 16:06:50 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 17:06:50 +0100 Subject: [Freeipa-devel] [PATCH] 389 Fix ipa-restore on systems without IPA installed In-Reply-To: <54B53DFB.8050709@redhat.com> References: <54B3FF68.3040806@redhat.com> <54B4E972.5020804@redhat.com> <54B4F959.90201@redhat.com> <54B53DFB.8050709@redhat.com> Message-ID: <54B5429A.9000108@redhat.com> Dne 13.1.2015 v 16:47 Petr Vobornik napsal(a): > On 01/13/2015 11:54 AM, Jan Cholasta wrote: >> Dne 13.1.2015 v 10:46 Petr Vobornik napsal(a): >>> On 01/12/2015 06:07 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>>> >>> >>> Is there a reason why `installutils.check_server_configuration() ` >>> is called in `cert_restore_prepare`, ie., method which is not >>> really connected with it, and not in `run` as for DATA backup? >> >> Full restore may be done when IPA is not installed, but >> cert_restore_prepare crashes when IPA is not installed, the check >> prevents that. >> >> Anyway, see the attached patch for an alternative, possibly better >> approach. >> > > Works, but with full restore I got: > > ... > Disabling all replication. > Unable to get connection, skipping disabling agreements: Unable to > bind to LDAP server: [Errno 2] No such file or directory > Stopping IPA services > Restoring files > ... > > I wonder if it needs a better error message, it may be confusing for users. Can you open a ticket for this? I would rather not deal with this right now in this patch... > > Btw what is the use case for fullrestore without IPA? Is it somewhere > documented or mentioned? > http://www.freeipa.org/page/V3/Backup_and_Restore#Catastrophic_hardware_failure_on_a_machine. -- Jan Cholasta From jcholast at redhat.com Tue Jan 13 16:16:45 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 17:16:45 +0100 Subject: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find In-Reply-To: <54B533F5.2060807@redhat.com> References: <546C78FB.8080008@redhat.com> <546C7DF9.3040001@redhat.com> <546C81F3.8070407@redhat.com> <546C8441.3090407@redhat.com> <546C90A6.2000408@redhat.com> <546C9514.1080904@redhat.com> <546CA539.2050005@redhat.com> <546E0250.5000401@redhat.com> <546F13CD.9020803@redhat.com> <546F340D.7090104@redhat.com> <54B533F5.2060807@redhat.com> Message-ID: <54B544ED.5040107@redhat.com> Dne 13.1.2015 v 16:04 Tomas Babej napsal(a): > > On 11/21/2014 01:46 PM, Jan Cholasta wrote: >> Dne 21.11.2014 v 11:28 Tomas Babej napsal(a): >>> >>> On 11/20/2014 04:01 PM, Jan Cholasta wrote: >>>> Dne 19.11.2014 v 15:12 Tomas Babej napsal(a): >>>>> >>>>> On 11/19/2014 02:03 PM, Jan Cholasta wrote: >>>>>> Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): >>>>>>> >>>>>>> On 11/19/2014 12:51 PM, Martin Kosek wrote: >>>>>>>> On 11/19/2014 12:41 PM, Tomas Babej wrote: >>>>>>>>> On 11/19/2014 12:24 PM, Martin Kosek wrote: >>>>>>>>>> On 11/19/2014 12:03 PM, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> When constructing a parent DN in LDAPSearch, we should always >>>>>>>>>>> check that the parent object exists (hence use >>>>>>>>>>> get_dn_if_exists), >>>>>>>>>>> rather than search on unexistant containers (which can happen >>>>>>>>>>> with get_dn). >>>>>>>>>>> >>>>>>>>>>> Replaces get_dn calls with get_dn_if_exists in *-find commands >>>>>>>>>>> and makes sure proper error message is raised. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4659 >>>>>>>>>> Doesn't it produce extra LDAP search thus making all our search >>>>>>>>>> commands >>>>>>>>>> slower? Is that what we want? >>>>>>>>> No it does not make all of our LDAP search slower. It only >>>>>>>>> happens for >>>>>>>>> the objects that have parent objects, such as idoverrides or >>>>>>>>> dnsrecords. >>>>>>>> ... and makes them slower. >>>>>>> >>>>>>> What I was pointing out here is that this is not a issue for ALL >>>>>>> *-find >>>>>>> commands (e.g user-find, group-find will not suffer from it), as you >>>>>>> incorrectly stated. >>>>>>> >>>>>>>> >>>>>>>>>> Wouldn't it be better to distinguish between LDAP >>>>>>>>>> search with no results and LDAP search with missing parent DN? >>>>>>>>>> The >>>>>>>>>> reply looks >>>>>>>>>> different, at least in CLI: >>>>>>>>> Up to discussion. We would probably need to introduce a new >>>>>>>>> exception, >>>>>>>>> like ParentObjectNotFound. >>>>>>>>> >>>>>>>>>> # search result >>>>>>>>>> search: 4 >>>>>>>>>> result: 0 Success >>>>>>>>>> >>>>>>>>>> # search result >>>>>>>>>> search: 4 >>>>>>>>>> result: 32 No such object >>>>>>>>>> matchedDN: cn=accounts,dc=mkosek-f20,dc=test >>>>>>>>>> >>>>>>>>>> Also, I do not think you can just stop using get_dn(), some >>>>>>>>>> commands override >>>>>>>>>> this call to get more complex searches (like host-find searching >>>>>>>>>> for shortname). >>>>>>>>> Look into the get_dn_if_exists, it just wraps around get_dn, so no >>>>>>>>> issue >>>>>>>>> here. Any custom behaviour is preserved. >>>>>>>> Ah, ok, thanks for info. >>>>>>>> >>>>>>>>> To sum up, I think this is worth changing this behaviour by >>>>>>>>> default, >>>>>>>>> ignoring a non-matching value of the parent object is not a >>>>>>>>> correct >>>>>>>>> general approach in my opinion. >>>>>>>> Well, that's the question. Whether we would leave DS to validate >>>>>>>> the >>>>>>>> search >>>>>>>> itself or do all the pre-check ourselves. To me, doing just one >>>>>>>> LDAP >>>>>>>> search and >>>>>>>> processing the error correctly looks better. But I can live even >>>>>>>> with your >>>>>>>> version then, I will leave the framework guardians like Honza or >>>>>>>> Petr3 to decide. >>>>>> >>>>>> +1 on single LDAP search and proper error processing. >>>>>> >>>>>>> >>>>>>> I see now what you're trying to suggest. However, the reason boils >>>>>>> down to ipaldap.find_entries method not differentiating between a >>>>>>> LDAP search that returns error code 32 (No such object) and LDAP >>>>>>> search returning error code 0 (Success), but returning no results. >>>>>>> >>>>>>> In both cases errors.NotFound is raised. >>>>>>> >>>>>>> The reason I did not go this way is that changing the find_entries >>>>>>> method >>>>>>> is quite more invasive as this is the method subsenqently called by >>>>>>> almost >>>>>>> any command. >>>>>> >>>>>> You can always derive the new error (ParentNotFound or whatever) on >>>>>> NotFound, so old code won't break. >>>>>> >>>>> >>>>> Thanks for the suggestsions. >>>>> >>>>> Attached is a new patch which hooks into find_entries method and >>>>> differentiates between the cases. >>>>> >>>> >>>> Why are you special casing base scope search? >>>> >>> >>> Since base search is performed only on the entry specified by the DN, >>> there is no need to differentiate between ContainerNotFound and >>> NotFound. >>> >>> So the logic is as follows: >>> >>> subtree search - ContainerNotFound is raised when container does not >>> exist, NotFound if search provided no results >>> onelevel search - the same >>> base search - NotFound is raised if the specified DN does not exist >>> >> >> There is a difference between a search on a non-existent entry and a >> search on an existent entry with a non-matching filter. This >> difference exists on LDAP level and applies to all search scopes, not >> just the base scope. >> >> I don't think hiding this difference is useful at all. Remember that >> this bug exists because we were hiding the difference in the first place. >> >> Also, after giving this some thought, I think it would be better to >> create a new error for the case where there is no match instead of the >> case where the entry does not exist. NotFound pretty much corresponds >> to LDAP's NO_SUCH_OBJECT, something like NoMatchingEntry or >> EmptyResult would fit the no-match result better. >> > > Sorry for the delay, I thought this was on review. Attaching the updated > patch. Thanks, ACK. Pushed to: master: e11e8235ac9af09a587262368ef795cddbdd0e4e ipa-4-1: 44134460b6545b51a17884ce353e556bd8cd753f -- Jan Cholasta From pvoborni at redhat.com Tue Jan 13 16:20:35 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 17:20:35 +0100 Subject: [Freeipa-devel] [PATCH] 389 Fix ipa-restore on systems without IPA installed In-Reply-To: <54B5429A.9000108@redhat.com> References: <54B3FF68.3040806@redhat.com> <54B4E972.5020804@redhat.com> <54B4F959.90201@redhat.com> <54B53DFB.8050709@redhat.com> <54B5429A.9000108@redhat.com> Message-ID: <54B545D3.10708@redhat.com> On 01/13/2015 05:06 PM, Jan Cholasta wrote: > Dne 13.1.2015 v 16:47 Petr Vobornik napsal(a): >> On 01/13/2015 11:54 AM, Jan Cholasta wrote: >>> Dne 13.1.2015 v 10:46 Petr Vobornik napsal(a): >>>> On 01/12/2015 06:07 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>>> >>>> >>>> Is there a reason why `installutils.check_server_configuration() ` >>>> is called in `cert_restore_prepare`, ie., method which is not >>>> really connected with it, and not in `run` as for DATA backup? >>> >>> Full restore may be done when IPA is not installed, but >>> cert_restore_prepare crashes when IPA is not installed, the check >>> prevents that. >>> >>> Anyway, see the attached patch for an alternative, possibly better >>> approach. >>> >> >> Works, but with full restore I got: >> >> ... >> Disabling all replication. >> Unable to get connection, skipping disabling agreements: Unable to >> bind to LDAP server: [Errno 2] No such file or directory >> Stopping IPA services >> Restoring files >> ... >> >> I wonder if it needs a better error message, it may be confusing for >> users. > > Can you open a ticket for this? I would rather not deal with this right > now in this patch... opened: https://fedorahosted.org/freeipa/ticket/4838 ACK, I'll leave push and rebase order of backup patches up to you > >> >> Btw what is the use case for fullrestore without IPA? Is it somewhere >> documented or mentioned? >> > > http://www.freeipa.org/page/V3/Backup_and_Restore#Catastrophic_hardware_failure_on_a_machine. > Thanks -- Petr Vobornik From jcholast at redhat.com Tue Jan 13 16:29:13 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 17:29:13 +0100 Subject: [Freeipa-devel] [PATCH] 389 Fix ipa-restore on systems without IPA installed In-Reply-To: <54B545D3.10708@redhat.com> References: <54B3FF68.3040806@redhat.com> <54B4E972.5020804@redhat.com> <54B4F959.90201@redhat.com> <54B53DFB.8050709@redhat.com> <54B5429A.9000108@redhat.com> <54B545D3.10708@redhat.com> Message-ID: <54B547D9.9050901@redhat.com> Dne 13.1.2015 v 17:20 Petr Vobornik napsal(a): > On 01/13/2015 05:06 PM, Jan Cholasta wrote: >> Dne 13.1.2015 v 16:47 Petr Vobornik napsal(a): >>> On 01/13/2015 11:54 AM, Jan Cholasta wrote: >>>> Dne 13.1.2015 v 10:46 Petr Vobornik napsal(a): >>>>> On 01/12/2015 06:07 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes >>>>>> . >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Is there a reason why `installutils.check_server_configuration() ` >>>>> is called in `cert_restore_prepare`, ie., method which is not >>>>> really connected with it, and not in `run` as for DATA backup? >>>> >>>> Full restore may be done when IPA is not installed, but >>>> cert_restore_prepare crashes when IPA is not installed, the check >>>> prevents that. >>>> >>>> Anyway, see the attached patch for an alternative, possibly better >>>> approach. >>>> >>> >>> Works, but with full restore I got: >>> >>> ... >>> Disabling all replication. >>> Unable to get connection, skipping disabling agreements: Unable to >>> bind to LDAP server: [Errno 2] No such file or directory >>> Stopping IPA services >>> Restoring files >>> ... >>> >>> I wonder if it needs a better error message, it may be confusing for >>> users. >> >> Can you open a ticket for this? I would rather not deal with this right >> now in this patch... > > opened: https://fedorahosted.org/freeipa/ticket/4838 > > ACK, I'll leave push and rebase order of backup patches up to you Thanks, rebased and pushed to: master: abcbe271d5e022ac805b448c85ebe4790bae7fb1 ipa-4-1: a98bc2381b7152c7076223e6bd36a1411fa850eb -- Jan Cholasta From pvoborni at redhat.com Tue Jan 13 16:44:08 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Jan 2015 17:44:08 +0100 Subject: [Freeipa-devel] [PATCH] 388 Remove RUV from LDIF files before using them in ipa-restore In-Reply-To: <54B3FA65.4070404@redhat.com> References: <54B3FA65.4070404@redhat.com> Message-ID: <54B54B58.8050708@redhat.com> On 01/12/2015 05:46 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > works for me, ACK -- Petr Vobornik From jcholast at redhat.com Tue Jan 13 16:45:48 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 17:45:48 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B53BBC.5050301@redhat.com> References: <54B3CBF1.602@redhat.com> <54B50929.20306@redhat.com> <54B51D16.7020709@redhat.com> <54B53BBC.5050301@redhat.com> Message-ID: <54B54BBC.1050600@redhat.com> Dne 13.1.2015 v 16:37 Petr Vobornik napsal(a): > On 01/13/2015 02:26 PM, Jan Cholasta wrote: >> Dne 13.1.2015 v 13:01 Petr Vobornik napsal(a): >>> On 01/12/2015 02:28 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Note that --data with data-only backup and --logs-only with data-only >>>> restore are deliberately ignored and considered no-op. >>>> >>>> Honza >>>> > >>> >>> 3. When #2 fixed, data backup with --no-logs doesn't raise warning as >>> requested in ticket. >> >> IMO such a warning does not make sense. You request no logs, you get no >> logs, I don't see anything worth warning about here. > > ok, makes sense > >> >>> >>> 5. Nitpick: imho option validation should be done before temp dir >>> creation. >> >> Fixed. > > You've also moved > self.header = os.path.join(self.backup_dir, 'header') > below > self.read_header() > > --> restore fails everytime Silly me. Sorry. Fixed. Rebased updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-387.2-Fix-validation-of-ipa-restore-options.patch Type: text/x-patch Size: 13504 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 13 16:55:52 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 17:55:52 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54B4FD80.8090008@redhat.com> References: <54B4FD80.8090008@redhat.com> Message-ID: <54B54E18.1050702@redhat.com> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): > Hi, > > the attached patch fixes . > > Honza Modified the fix to create only one service object in stopped_service. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-390.1-Do-not-crash-on-unknown-services-in-installutils.sto.patch Type: text/x-patch Size: 1675 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 13 16:58:59 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 17:58:59 +0100 Subject: [Freeipa-devel] [PATCH] 388 Remove RUV from LDIF files before using them in ipa-restore In-Reply-To: <54B54B58.8050708@redhat.com> References: <54B3FA65.4070404@redhat.com> <54B54B58.8050708@redhat.com> Message-ID: <54B54ED3.3050402@redhat.com> Dne 13.1.2015 v 17:44 Petr Vobornik napsal(a): > On 01/12/2015 05:46 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > works for me, ACK Thanks, pushed to: master: 05e6adecb51b93e9b9d2326df4eabee90c3dfe72 ipa-4-1: eb7917026d418a6d6a1e7a24a19097065df10497 -- Jan Cholasta From jcholast at redhat.com Tue Jan 13 17:02:25 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 18:02:25 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B54BBC.1050600@redhat.com> References: <54B3CBF1.602@redhat.com> <54B50929.20306@redhat.com> <54B51D16.7020709@redhat.com> <54B53BBC.5050301@redhat.com> <54B54BBC.1050600@redhat.com> Message-ID: <54B54FA1.6060908@redhat.com> Dne 13.1.2015 v 17:45 Jan Cholasta napsal(a): > Dne 13.1.2015 v 16:37 Petr Vobornik napsal(a): >> On 01/13/2015 02:26 PM, Jan Cholasta wrote: >>> Dne 13.1.2015 v 13:01 Petr Vobornik napsal(a): >>>> On 01/12/2015 02:28 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Note that --data with data-only backup and --logs-only with data-only >>>>> restore are deliberately ignored and considered no-op. >>>>> >>>>> Honza >>>>> >> >>>> >>>> 3. When #2 fixed, data backup with --no-logs doesn't raise warning as >>>> requested in ticket. >>> >>> IMO such a warning does not make sense. You request no logs, you get no >>> logs, I don't see anything worth warning about here. >> >> ok, makes sense >> >>> >>>> >>>> 5. Nitpick: imho option validation should be done before temp dir >>>> creation. >>> >>> Fixed. >> >> You've also moved >> self.header = os.path.join(self.backup_dir, 'header') >> below >> self.read_header() >> >> --> restore fails everytime > > Silly me. Sorry. Fixed. > > Rebased updated patch attached. Rebased again, patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-387.3-Fix-validation-of-ipa-restore-options.patch Type: text/x-patch Size: 13500 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 13 17:16:11 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Jan 2015 18:16:11 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes Message-ID: <54B552DB.7090309@redhat.com> This is crude first version of the (working) fixes to fix Winsync/Passsync problems caused by the PermissionV2 refactoring. Simo/Petr3 or others, any concerns? -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-488-allow-passsync-user-to-locate-and-update-nt-users.patch Type: text/x-patch Size: 6084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-489-allow-replication-administrators-to-manipulate-winsy.patch Type: text/x-patch Size: 2815 bytes Desc: not available URL: From dkupka at redhat.com Tue Jan 13 17:46:32 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 18:46:32 +0100 Subject: [Freeipa-devel] [PATCH] 386 Fix CA certificate renewal syslog alert In-Reply-To: <54AEAAA3.5010506@redhat.com> References: <54AEAAA3.5010506@redhat.com> Message-ID: <54B559F8.5020509@redhat.com> On 01/08/2015 05:04 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi! Thanks for the patch. Works for me, ACK. -- David Kupka From dkupka at redhat.com Tue Jan 13 17:46:48 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 18:46:48 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54B54E18.1050702@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> Message-ID: <54B55A08.50402@redhat.com> On 01/13/2015 05:55 PM, Jan Cholasta wrote: > Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >> Hi, >> >> the attached patch fixes . >> >> Honza > > Modified the fix to create only one service object in stopped_service. > > Updated patch attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi! Thanks for the patch. Works for me, ACK. -- David Kupka From dkupka at redhat.com Tue Jan 13 17:47:30 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Jan 2015 18:47:30 +0100 Subject: [Freeipa-devel] [PATCHES] 391-392 Make certificate renewal process synchronized In-Reply-To: <54B4FEBA.3000900@redhat.com> References: <54B4FEBA.3000900@redhat.com> Message-ID: <54B55A32.8000904@redhat.com> On 01/13/2015 12:17 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Note that if you want to test upgrades on CA-less, you need to apply my > patch 390 as well: > . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi! Thanks for the patch. It works as expected. I would prefer refactoring the certmonger-interacting code but since we're out time and needs this fix ASAP I'll cope with it. ACK. -- David Kupka From jcholast at redhat.com Tue Jan 13 17:49:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 18:49:42 +0100 Subject: [Freeipa-devel] [PATCH] 386 Fix CA certificate renewal syslog alert In-Reply-To: <54B559F8.5020509@redhat.com> References: <54AEAAA3.5010506@redhat.com> <54B559F8.5020509@redhat.com> Message-ID: <54B55AB6.4010500@redhat.com> Dne 13.1.2015 v 18:46 David Kupka napsal(a): > On 01/08/2015 05:04 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Hi! > Thanks for the patch. Works for me, ACK. > Thanks, pushed to: master: a63df8f3091992e227fe4654977bb91386ce0491 ipa-4-1: 818136bab14d5b137943349564a8cc3b31af5afa -- Jan Cholasta From jcholast at redhat.com Tue Jan 13 17:55:48 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 18:55:48 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54B55A08.50402@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> <54B55A08.50402@redhat.com> Message-ID: <54B55C24.1080407@redhat.com> Dne 13.1.2015 v 18:46 David Kupka napsal(a): > On 01/13/2015 05:55 PM, Jan Cholasta wrote: >> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Modified the fix to create only one service object in stopped_service. >> >> Updated patch attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Hi! > Thanks for the patch. Works for me, ACK. > Thanks, pushed to: master: 5bf1c9a6f7d734c296c8eb987cfc4f7e2a345130 ipa-4-1: 065e2bbc9f2260d8c60c55f92a386513727576da -- Jan Cholasta From jcholast at redhat.com Tue Jan 13 18:43:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 13 Jan 2015 19:43:17 +0100 Subject: [Freeipa-devel] [PATCHES] 391-392 Make certificate renewal process synchronized In-Reply-To: <54B55A32.8000904@redhat.com> References: <54B4FEBA.3000900@redhat.com> <54B55A32.8000904@redhat.com> Message-ID: <54B56745.503@redhat.com> Dne 13.1.2015 v 18:47 David Kupka napsal(a): > On 01/13/2015 12:17 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Note that if you want to test upgrades on CA-less, you need to apply my >> patch 390 as well: >> . >> >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Hi! > Thanks for the patch. It works as expected. I would prefer refactoring > the certmonger-interacting code but since we're out time and needs this > fix ASAP I'll cope with it. ACK. Thanks for the review. I would prefer that too, but I wanted to keep the changes minimal. It can be refactored in 4.2. Pushed to: master: b9ae7690489368ead9f4983d386fa210dc265dfa ipa-4-1: 760ebaa6852b12f1d58032b33ef538d9894dc3ef -- Jan Cholasta From ssorce at redhat.com Tue Jan 13 20:55:29 2015 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Jan 2015 15:55:29 -0500 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B552DB.7090309@redhat.com> References: <54B552DB.7090309@redhat.com> Message-ID: <20150113155529.60f19e65@willson.usersys.redhat.com> On Tue, 13 Jan 2015 18:16:11 +0100 Martin Kosek wrote: > This is crude first version of the (working) fixes to fix > Winsync/Passsync problems caused by the PermissionV2 refactoring. > > Simo/Petr3 or others, any concerns? > The first patch looks good the second looks .. broad ? Shouldn't you explicitly allow specific attributes ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Jan 13 21:52:05 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Jan 2015 22:52:05 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <20150113155529.60f19e65@willson.usersys.redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> Message-ID: <54B59385.2070206@redhat.com> On 01/13/2015 09:55 PM, Simo Sorce wrote: > On Tue, 13 Jan 2015 18:16:11 +0100 > Martin Kosek wrote: > >> This is crude first version of the (working) fixes to fix >> Winsync/Passsync problems caused by the PermissionV2 refactoring. >> >> Simo/Petr3 or others, any concerns? >> > > The first patch looks good > the second looks .. broad ? > > Shouldn't you explicitly allow specific attributes ? You mean for: + 'System: Read LDBM database config': { + 'ipapermlocation': DN('cn=config'), + 'ipapermtarget': DN('cn=config,cn=ldbm database,cn=plugins,cn=config'), + 'ipapermbindruletype': 'permission', + 'ipapermright': {'read', 'search', 'compare'}, + 'default_privileges': {'Replication Administrators'}, + 'ipapermdefaultattr': {'*'}, + }, ? I did that as my first try, but then the ACI was not accepted as the attribute I was looking for (nsslapd-changelogdir) is not in the schema as the config is just an extensibleObject. But as I was going through the attributes, I did not see anything super-secret. Petr, is there any way to make permission plugin accept unknown attribute in the permission attribute list, or do we need to use "*" in this case? From mkosek at redhat.com Wed Jan 14 08:14:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 09:14:42 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B54FA1.6060908@redhat.com> References: <54B3CBF1.602@redhat.com> <54B50929.20306@redhat.com> <54B51D16.7020709@redhat.com> <54B53BBC.5050301@redhat.com> <54B54BBC.1050600@redhat.com> <54B54FA1.6060908@redhat.com> Message-ID: <54B62572.1030509@redhat.com> On 01/13/2015 06:02 PM, Jan Cholasta wrote: > Dne 13.1.2015 v 17:45 Jan Cholasta napsal(a): >> Dne 13.1.2015 v 16:37 Petr Vobornik napsal(a): >>> On 01/13/2015 02:26 PM, Jan Cholasta wrote: >>>> Dne 13.1.2015 v 13:01 Petr Vobornik napsal(a): >>>>> On 01/12/2015 02:28 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes >>>>>> . >>>>>> >>>>>> Note that --data with data-only backup and --logs-only with data-only >>>>>> restore are deliberately ignored and considered no-op. >>>>>> >>>>>> Honza >>>>>> >>> >>>>> >>>>> 3. When #2 fixed, data backup with --no-logs doesn't raise warning as >>>>> requested in ticket. >>>> >>>> IMO such a warning does not make sense. You request no logs, you get no >>>> logs, I don't see anything worth warning about here. >>> >>> ok, makes sense >>> >>>> >>>>> >>>>> 5. Nitpick: imho option validation should be done before temp dir >>>>> creation. >>>> >>>> Fixed. >>> >>> You've also moved >>> self.header = os.path.join(self.backup_dir, 'header') >>> below >>> self.read_header() >>> >>> --> restore fails everytime >> >> Silly me. Sorry. Fixed. >> >> Rebased updated patch attached. > > Rebased again, patch attached. Given that Petr is not there today, I finished the review for him. I did not find any other issues, all issues except (2) are fixed. ACK. Pushed to master (rebased) and ipa-4-1. Martin From pviktori at redhat.com Wed Jan 14 09:15:17 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 Jan 2015 10:15:17 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B59385.2070206@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> Message-ID: <54B633A5.2020904@redhat.com> On 01/13/2015 10:52 PM, Martin Kosek wrote: > On 01/13/2015 09:55 PM, Simo Sorce wrote: >> On Tue, 13 Jan 2015 18:16:11 +0100 >> Martin Kosek wrote: >> >>> This is crude first version of the (working) fixes to fix >>> Winsync/Passsync problems caused by the PermissionV2 refactoring. >>> >>> Simo/Petr3 or others, any concerns? >>> >> >> The first patch looks good >> the second looks .. broad ? >> >> Shouldn't you explicitly allow specific attributes ? > > You mean for: > > + 'System: Read LDBM database config': { > + 'ipapermlocation': DN('cn=config'), > + 'ipapermtarget': DN('cn=config,cn=ldbm > database,cn=plugins,cn=config'), > + 'ipapermbindruletype': 'permission', > + 'ipapermright': {'read', 'search', 'compare'}, > + 'default_privileges': {'Replication Administrators'}, > + 'ipapermdefaultattr': {'*'}, > + }, > > ? I did that as my first try, but then the ACI was not accepted as the > attribute I was looking for (nsslapd-changelogdir) is not in the schema > as the config is just an extensibleObject. But as I was going through > the attributes, I did not see anything super-secret. > > Petr, is there any way to make permission plugin accept unknown > attribute in the permission attribute list, or do we need to use "*" in > this case? The ACL Syntax Error comes straight from the DS, so there's not much IPA can do. The error suggests adding nsslapd-changelogdir to the schema, but I'm not sure that's the right solution here. Thierry, any comments? See the attached LDIF. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: add-changelogdir-aci.ldif Type: text/x-ldif Size: 178 bytes Desc: not available URL: From tbordaz at redhat.com Wed Jan 14 09:37:22 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 14 Jan 2015 10:37:22 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B633A5.2020904@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> Message-ID: <54B638D2.7010001@redhat.com> On 01/14/2015 10:15 AM, Petr Viktorin wrote: > On 01/13/2015 10:52 PM, Martin Kosek wrote: >> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>> On Tue, 13 Jan 2015 18:16:11 +0100 >>> Martin Kosek wrote: >>> >>>> This is crude first version of the (working) fixes to fix >>>> Winsync/Passsync problems caused by the PermissionV2 refactoring. >>>> >>>> Simo/Petr3 or others, any concerns? >>>> >>> >>> The first patch looks good >>> the second looks .. broad ? >>> >>> Shouldn't you explicitly allow specific attributes ? >> >> You mean for: >> >> + 'System: Read LDBM database config': { >> + 'ipapermlocation': DN('cn=config'), >> + 'ipapermtarget': DN('cn=config,cn=ldbm >> database,cn=plugins,cn=config'), >> + 'ipapermbindruletype': 'permission', >> + 'ipapermright': {'read', 'search', 'compare'}, >> + 'default_privileges': {'Replication Administrators'}, >> + 'ipapermdefaultattr': {'*'}, >> + }, >> >> ? I did that as my first try, but then the ACI was not accepted as the >> attribute I was looking for (nsslapd-changelogdir) is not in the schema >> as the config is just an extensibleObject. But as I was going through >> the attributes, I did not see anything super-secret. >> >> Petr, is there any way to make permission plugin accept unknown >> attribute in the permission attribute list, or do we need to use "*" in >> this case? > > The ACL Syntax Error comes straight from the DS, so there's not much > IPA can do. The error suggests adding nsslapd-changelogdir to the > schema, but I'm not sure that's the right solution here. > Thierry, any comments? See the attached LDIF. > Yes DS acl plugin checks that the named attribute is in the schema. I do not see the benefit of this limitation I need to dig further. Now you may define the 'targetattr' with a '*'. Would it be possible to use an aci syntax like : aci: (targetattr = "nsslapd-changelogdir*")(version 3.0;acl "test-aci";allow (compare,read,search) groupdn = "ldap:///all";) thanks theirry From tbordaz at redhat.com Wed Jan 14 09:58:11 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 14 Jan 2015 10:58:11 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B633A5.2020904@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> Message-ID: <54B63DB3.9070107@redhat.com> On 01/14/2015 10:15 AM, Petr Viktorin wrote: > On 01/13/2015 10:52 PM, Martin Kosek wrote: >> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>> On Tue, 13 Jan 2015 18:16:11 +0100 >>> Martin Kosek wrote: >>> >>>> This is crude first version of the (working) fixes to fix >>>> Winsync/Passsync problems caused by the PermissionV2 refactoring. >>>> >>>> Simo/Petr3 or others, any concerns? >>>> >>> >>> The first patch looks good >>> the second looks .. broad ? >>> >>> Shouldn't you explicitly allow specific attributes ? >> >> You mean for: >> >> + 'System: Read LDBM database config': { >> + 'ipapermlocation': DN('cn=config'), >> + 'ipapermtarget': DN('cn=config,cn=ldbm >> database,cn=plugins,cn=config'), >> + 'ipapermbindruletype': 'permission', >> + 'ipapermright': {'read', 'search', 'compare'}, >> + 'default_privileges': {'Replication Administrators'}, >> + 'ipapermdefaultattr': {'*'}, >> + }, >> >> ? I did that as my first try, but then the ACI was not accepted as the >> attribute I was looking for (nsslapd-changelogdir) is not in the schema >> as the config is just an extensibleObject. But as I was going through >> the attributes, I did not see anything super-secret. >> >> Petr, is there any way to make permission plugin accept unknown >> attribute in the permission attribute list, or do we need to use "*" in >> this case? > > The ACL Syntax Error comes straight from the DS, so there's not much > IPA can do. The error suggests adding nsslapd-changelogdir to the > schema, but I'm not sure that's the right solution here. > Thierry, any comments? See the attached LDIF. > Actually this limitation was added with the bug https://bugzilla.redhat.com/show_bug.cgi?id=244229. I do not see in the bug, if the ability to define non schema attribute was creating a problem for IPA thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Jan 14 10:07:20 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 11:07:20 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B638D2.7010001@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B638D2.7010001@redhat.com> Message-ID: <54B63FD8.1000500@redhat.com> On 01/14/2015 10:37 AM, thierry bordaz wrote: > On 01/14/2015 10:15 AM, Petr Viktorin wrote: >> On 01/13/2015 10:52 PM, Martin Kosek wrote: >>> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>>> On Tue, 13 Jan 2015 18:16:11 +0100 >>>> Martin Kosek wrote: >>>> >>>>> This is crude first version of the (working) fixes to fix >>>>> Winsync/Passsync problems caused by the PermissionV2 refactoring. >>>>> >>>>> Simo/Petr3 or others, any concerns? >>>>> >>>> >>>> The first patch looks good >>>> the second looks .. broad ? >>>> >>>> Shouldn't you explicitly allow specific attributes ? >>> >>> You mean for: >>> >>> + 'System: Read LDBM database config': { >>> + 'ipapermlocation': DN('cn=config'), >>> + 'ipapermtarget': DN('cn=config,cn=ldbm >>> database,cn=plugins,cn=config'), >>> + 'ipapermbindruletype': 'permission', >>> + 'ipapermright': {'read', 'search', 'compare'}, >>> + 'default_privileges': {'Replication Administrators'}, >>> + 'ipapermdefaultattr': {'*'}, >>> + }, >>> >>> ? I did that as my first try, but then the ACI was not accepted as the >>> attribute I was looking for (nsslapd-changelogdir) is not in the schema >>> as the config is just an extensibleObject. But as I was going through >>> the attributes, I did not see anything super-secret. >>> >>> Petr, is there any way to make permission plugin accept unknown >>> attribute in the permission attribute list, or do we need to use "*" in >>> this case? >> >> The ACL Syntax Error comes straight from the DS, so there's not much IPA can >> do. The error suggests adding nsslapd-changelogdir to the schema, but I'm not >> sure that's the right solution here. >> Thierry, any comments? See the attached LDIF. >> > > > Yes DS acl plugin checks that the named attribute is in the schema. I do not > see the benefit of this limitation I need to dig further. > Now you may define the 'targetattr' with a '*'. Would it be possible to use an > aci syntax like : > > aci: (targetattr = "nsslapd-changelogdir*")(version 3.0;acl "test-aci";allow > (compare,read,search) groupdn = "ldap:///all";) > > thanks > theirry Maybe, although it looks bit ugly. So far, I just used "*" given the ACIs were quite focused and only for "Replication Administrators" privilege members. Martin From pviktori at redhat.com Wed Jan 14 10:53:23 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 Jan 2015 11:53:23 +0100 Subject: [Freeipa-devel] [PATCH 0296] ipatests: Make descriptions of declarative tests sorted according to their order In-Reply-To: <5494309F.9080505@redhat.com> References: <5494309F.9080505@redhat.com> Message-ID: <54B64AA3.3040108@redhat.com> On 12/19/2014 03:05 PM, Tomas Babej wrote: > Hi, > > this allows us to sort the descriptions and preserve the test order. > ACK -- Petr? From mkosek at redhat.com Wed Jan 14 11:03:05 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 12:03:05 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B63DB3.9070107@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> Message-ID: <54B64CE9.7030204@redhat.com> On 01/14/2015 10:58 AM, thierry bordaz wrote: > On 01/14/2015 10:15 AM, Petr Viktorin wrote: >> On 01/13/2015 10:52 PM, Martin Kosek wrote: >>> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>>> On Tue, 13 Jan 2015 18:16:11 +0100 >>>> Martin Kosek wrote: >>>> >>>>> This is crude first version of the (working) fixes to fix >>>>> Winsync/Passsync problems caused by the PermissionV2 refactoring. >>>>> >>>>> Simo/Petr3 or others, any concerns? >>>>> >>>> >>>> The first patch looks good >>>> the second looks .. broad ? >>>> >>>> Shouldn't you explicitly allow specific attributes ? >>> >>> You mean for: >>> >>> + 'System: Read LDBM database config': { >>> + 'ipapermlocation': DN('cn=config'), >>> + 'ipapermtarget': DN('cn=config,cn=ldbm >>> database,cn=plugins,cn=config'), >>> + 'ipapermbindruletype': 'permission', >>> + 'ipapermright': {'read', 'search', 'compare'}, >>> + 'default_privileges': {'Replication Administrators'}, >>> + 'ipapermdefaultattr': {'*'}, >>> + }, >>> >>> ? I did that as my first try, but then the ACI was not accepted as the >>> attribute I was looking for (nsslapd-changelogdir) is not in the schema >>> as the config is just an extensibleObject. But as I was going through >>> the attributes, I did not see anything super-secret. >>> >>> Petr, is there any way to make permission plugin accept unknown >>> attribute in the permission attribute list, or do we need to use "*" in >>> this case? >> >> The ACL Syntax Error comes straight from the DS, so there's not much IPA can >> do. The error suggests adding nsslapd-changelogdir to the schema, but I'm not >> sure that's the right solution here. >> Thierry, any comments? See the attached LDIF. >> > Actually this limitation was added with the bug > https://bugzilla.redhat.com/show_bug.cgi?id=244229. > I do not see in the bug, if the ability to define non schema attribute was > creating a problem for IPA Not before, but with PermissionV2 and especially these patches, we may need to control access to unknown attributes in extensibleObject objects. From pviktori at redhat.com Wed Jan 14 11:35:21 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 Jan 2015 12:35:21 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B62572.1030509@redhat.com> References: <54B3CBF1.602@redhat.com> <54B50929.20306@redhat.com> <54B51D16.7020709@redhat.com> <54B53BBC.5050301@redhat.com> <54B54BBC.1050600@redhat.com> <54B54FA1.6060908@redhat.com> <54B62572.1030509@redhat.com> Message-ID: <54B65479.7040406@redhat.com> On 01/14/2015 09:14 AM, Martin Kosek wrote: > On 01/13/2015 06:02 PM, Jan Cholasta wrote: >> Rebased again, patch attached. > > Given that Petr is not there today, I finished the review for him. I did not > find any other issues, all issues except (2) are fixed. > > ACK. Pushed to master (rebased) and ipa-4-1. This broke master. ************* Module ipaserver.install.ipa_restore ipaserver/install/ipa_restore.py:175: [E0602(undefined-variable), Restore.validate_options] Undefined variable 'BACKUP_DIR') ipaserver/install/ipa_restore.py:210: [E0602(undefined-variable), Restore.run] Undefined variable 'BACKUP_DIR') -- Petr? From mkosek at redhat.com Wed Jan 14 12:10:09 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 13:10:09 +0100 Subject: [Freeipa-devel] [PATCH] 387 Fix validation of ipa-restore options In-Reply-To: <54B65479.7040406@redhat.com> References: <54B3CBF1.602@redhat.com> <54B50929.20306@redhat.com> <54B51D16.7020709@redhat.com> <54B53BBC.5050301@redhat.com> <54B54BBC.1050600@redhat.com> <54B54FA1.6060908@redhat.com> <54B62572.1030509@redhat.com> <54B65479.7040406@redhat.com> Message-ID: <54B65CA1.40103@redhat.com> On 01/14/2015 12:35 PM, Petr Viktorin wrote: > On 01/14/2015 09:14 AM, Martin Kosek wrote: >> On 01/13/2015 06:02 PM, Jan Cholasta wrote: > >>> Rebased again, patch attached. >> >> Given that Petr is not there today, I finished the review for him. I did not >> find any other issues, all issues except (2) are fixed. >> >> ACK. Pushed to master (rebased) and ipa-4-1. > > This broke master. > > ************* Module ipaserver.install.ipa_restore > ipaserver/install/ipa_restore.py:175: [E0602(undefined-variable), > Restore.validate_options] Undefined variable 'BACKUP_DIR') > ipaserver/install/ipa_restore.py:210: [E0602(undefined-variable), Restore.run] > Undefined variable 'BACKUP_DIR') > Grr... Sorry for the hickup, I fixed it with the attached patch and pushed it to master as a one liner. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-490-fix-ipa_backup_dir-path-name.patch Type: text/x-patch Size: 1401 bytes Desc: not available URL: From tbabej at redhat.com Wed Jan 14 12:11:57 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Jan 2015 13:11:57 +0100 Subject: [Freeipa-devel] [PATCH 0296] ipatests: Make descriptions of declarative tests sorted according to their order In-Reply-To: <54B64AA3.3040108@redhat.com> References: <5494309F.9080505@redhat.com> <54B64AA3.3040108@redhat.com> Message-ID: <54B65D0D.50602@redhat.com> On 01/14/2015 11:53 AM, Petr Viktorin wrote: > On 12/19/2014 03:05 PM, Tomas Babej wrote: >> Hi, >> >> this allows us to sort the descriptions and preserve the test order. >> > > ACK > Pushed to master: 5416652f6f15de4cc2140a58466facdf07c70965 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tbabej at redhat.com Wed Jan 14 12:13:28 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Jan 2015 13:13:28 +0100 Subject: [Freeipa-devel] [PATCHES] 0684-0687 Use tracker fixture in host plugin tests In-Reply-To: <54ABF5F4.3060506@redhat.com> References: <54ABF5F4.3060506@redhat.com> Message-ID: <54B65D68.9030706@redhat.com> On 01/06/2015 03:49 PM, Petr Viktorin wrote: > The first patch enables pylint to run on tests. > Some of the exceptions I've added are pretty heavy-handed, but the > main thing I wanted to enable is checking for duplicate test > function/method names, since in that case the earlier test is silently > dropped. > > I dropped support for old pylint while I was at it. > > > The other three patches show how one might go around modernizing one > of our Declarative test suites. There are some dead ends in the first > patch that are removed subsequently; if you squash the patches > together they might be easier to review. > See the commit messages for what the patches do. > The HostTracker should generalize well to other objects. With Service > or DNS trackers some of the host tests can be simplified even more. > > > To check that tests are independent, you can use the order-randomizing > plugin for pytest (which is not in Fedora yet): > > pip install --user pytest-random > ./make-test ipatests/test_xmlrpc/test_host_plugin.py -v --random > > (Note that this takes a lot of time as fixtures are created and > re-created ? independent tests are mainly useful for selecting > *subsets* of tests.) > ACK, nice work! Pushed to master: 07545569ecbdfdb1aeef6aa1878d827a7e5ddb38 Note: There was a build issue a fixed with attached patch, also pushed. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0297-spec-Add-BuildRequires-for-python-pytest-plugins.patch Type: text/x-patch Size: 1114 bytes Desc: not available URL: From tbordaz at redhat.com Wed Jan 14 12:41:54 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 14 Jan 2015 13:41:54 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B64CE9.7030204@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> Message-ID: <54B66412.3050607@redhat.com> On 01/14/2015 12:03 PM, Martin Kosek wrote: > On 01/14/2015 10:58 AM, thierry bordaz wrote: >> On 01/14/2015 10:15 AM, Petr Viktorin wrote: >>> On 01/13/2015 10:52 PM, Martin Kosek wrote: >>>> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>>>> On Tue, 13 Jan 2015 18:16:11 +0100 >>>>> Martin Kosek wrote: >>>>> >>>>>> This is crude first version of the (working) fixes to fix >>>>>> Winsync/Passsync problems caused by the PermissionV2 refactoring. >>>>>> >>>>>> Simo/Petr3 or others, any concerns? >>>>>> >>>>> The first patch looks good >>>>> the second looks .. broad ? >>>>> >>>>> Shouldn't you explicitly allow specific attributes ? >>>> You mean for: >>>> >>>> + 'System: Read LDBM database config': { >>>> + 'ipapermlocation': DN('cn=config'), >>>> + 'ipapermtarget': DN('cn=config,cn=ldbm >>>> database,cn=plugins,cn=config'), >>>> + 'ipapermbindruletype': 'permission', >>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>> + 'default_privileges': {'Replication Administrators'}, >>>> + 'ipapermdefaultattr': {'*'}, >>>> + }, >>>> >>>> ? I did that as my first try, but then the ACI was not accepted as the >>>> attribute I was looking for (nsslapd-changelogdir) is not in the schema >>>> as the config is just an extensibleObject. But as I was going through >>>> the attributes, I did not see anything super-secret. >>>> >>>> Petr, is there any way to make permission plugin accept unknown >>>> attribute in the permission attribute list, or do we need to use "*" in >>>> this case? >>> The ACL Syntax Error comes straight from the DS, so there's not much IPA can >>> do. The error suggests adding nsslapd-changelogdir to the schema, but I'm not >>> sure that's the right solution here. >>> Thierry, any comments? See the attached LDIF. >>> >> Actually this limitation was added with the bug >> https://bugzilla.redhat.com/show_bug.cgi?id=244229. >> I do not see in the bug, if the ability to define non schema attribute was >> creating a problem for IPA > Not before, but with PermissionV2 and especially these patches, we may need to > control access to unknown attributes in extensibleObject objects. One possibility is to revert that fix (with or without configuration toggle). But then in a topology with mixed versions of DS, old DS will skipped those aci. Using '*' char is not nice but will guaranty a same evaluation on all servers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed Jan 14 13:55:14 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 14 Jan 2015 06:55:14 -0700 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise In-Reply-To: References: Message-ID: Hello, In looking into https://fedorahosted.org/freeipa/ticket/4029 I am wondering if there should be separate ipa-advise test, Yes/No? Could be handy in the future to test more ipa-advise output? Or should this test be added to the test_legacy_clients.py? Thanks, Gabe On Tue, Dec 2, 2014 at 9:21 PM, Gabe Alford wrote: > Hello, > > I was going to try my hand at attempting a patch for ipa-tests. However in > wanting to test my patch, I am not sure how to run ipa-tests to check if it > works or not. Documentation is not really clear on what needs to be done to > start a test and run a test. This is for > https://fedorahosted.org/freeipa/ticket/4029 > > I have attached the patch that I have yet to really test with ipa-test. > Any help on how to test the patch running ipa-tests would be great. Of > course, if one of the reviewers looks at the patch and looks good, then I > would be happy with that as well. > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Wed Jan 14 14:34:52 2015 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Jan 2015 09:34:52 -0500 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B66412.3050607@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> <54B66412.3050607@redhat.com> Message-ID: <20150114093452.14b0c665@willson.usersys.redhat.com> On Wed, 14 Jan 2015 13:41:54 +0100 thierry bordaz wrote: > On 01/14/2015 12:03 PM, Martin Kosek wrote: > > On 01/14/2015 10:58 AM, thierry bordaz wrote: > >> On 01/14/2015 10:15 AM, Petr Viktorin wrote: > >>> On 01/13/2015 10:52 PM, Martin Kosek wrote: > >>>> On 01/13/2015 09:55 PM, Simo Sorce wrote: > >>>>> On Tue, 13 Jan 2015 18:16:11 +0100 > >>>>> Martin Kosek wrote: > >>>>> > >>>>>> This is crude first version of the (working) fixes to fix > >>>>>> Winsync/Passsync problems caused by the PermissionV2 > >>>>>> refactoring. > >>>>>> > >>>>>> Simo/Petr3 or others, any concerns? > >>>>>> > >>>>> The first patch looks good > >>>>> the second looks .. broad ? > >>>>> > >>>>> Shouldn't you explicitly allow specific attributes ? > >>>> You mean for: > >>>> > >>>> + 'System: Read LDBM database config': { > >>>> + 'ipapermlocation': DN('cn=config'), > >>>> + 'ipapermtarget': DN('cn=config,cn=ldbm > >>>> database,cn=plugins,cn=config'), > >>>> + 'ipapermbindruletype': 'permission', > >>>> + 'ipapermright': {'read', 'search', 'compare'}, > >>>> + 'default_privileges': {'Replication Administrators'}, > >>>> + 'ipapermdefaultattr': {'*'}, > >>>> + }, > >>>> > >>>> ? I did that as my first try, but then the ACI was not accepted > >>>> as the attribute I was looking for (nsslapd-changelogdir) is not > >>>> in the schema as the config is just an extensibleObject. But as > >>>> I was going through the attributes, I did not see anything > >>>> super-secret. > >>>> > >>>> Petr, is there any way to make permission plugin accept unknown > >>>> attribute in the permission attribute list, or do we need to use > >>>> "*" in this case? > >>> The ACL Syntax Error comes straight from the DS, so there's not > >>> much IPA can do. The error suggests adding nsslapd-changelogdir > >>> to the schema, but I'm not sure that's the right solution here. > >>> Thierry, any comments? See the attached LDIF. > >>> > >> Actually this limitation was added with the bug > >> https://bugzilla.redhat.com/show_bug.cgi?id=244229. > >> I do not see in the bug, if the ability to define non schema > >> attribute was creating a problem for IPA > > Not before, but with PermissionV2 and especially these patches, we > > may need to control access to unknown attributes in > > extensibleObject objects. > One possibility is to revert that fix (with or without configuration > toggle). But then in a topology with mixed versions of DS, old DS > will skipped those aci. > > Using '*' char is not nice but will guaranty a same evaluation on all > servers. We requested attribute validation when adding ACIs, w/o it it was very simple to make typos, which would be fatal for DENY ACIs. The problem here is in using extensibleObject and not defining a schema IMO. That said I am ok with the targetattr with appended asterisk to the undefined attribute name. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Jan 14 14:42:20 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 14 Jan 2015 16:42:20 +0200 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <20150114093452.14b0c665@willson.usersys.redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> <54B66412.3050607@redhat.com> <20150114093452.14b0c665@willson.usersys.redhat.com> Message-ID: <20150114144220.GS16288@redhat.com> On Wed, 14 Jan 2015, Simo Sorce wrote: >On Wed, 14 Jan 2015 13:41:54 +0100 >thierry bordaz wrote: > >> On 01/14/2015 12:03 PM, Martin Kosek wrote: >> > On 01/14/2015 10:58 AM, thierry bordaz wrote: >> >> On 01/14/2015 10:15 AM, Petr Viktorin wrote: >> >>> On 01/13/2015 10:52 PM, Martin Kosek wrote: >> >>>> On 01/13/2015 09:55 PM, Simo Sorce wrote: >> >>>>> On Tue, 13 Jan 2015 18:16:11 +0100 >> >>>>> Martin Kosek wrote: >> >>>>> >> >>>>>> This is crude first version of the (working) fixes to fix >> >>>>>> Winsync/Passsync problems caused by the PermissionV2 >> >>>>>> refactoring. >> >>>>>> >> >>>>>> Simo/Petr3 or others, any concerns? >> >>>>>> >> >>>>> The first patch looks good >> >>>>> the second looks .. broad ? >> >>>>> >> >>>>> Shouldn't you explicitly allow specific attributes ? >> >>>> You mean for: >> >>>> >> >>>> + 'System: Read LDBM database config': { >> >>>> + 'ipapermlocation': DN('cn=config'), >> >>>> + 'ipapermtarget': DN('cn=config,cn=ldbm >> >>>> database,cn=plugins,cn=config'), >> >>>> + 'ipapermbindruletype': 'permission', >> >>>> + 'ipapermright': {'read', 'search', 'compare'}, >> >>>> + 'default_privileges': {'Replication Administrators'}, >> >>>> + 'ipapermdefaultattr': {'*'}, >> >>>> + }, >> >>>> >> >>>> ? I did that as my first try, but then the ACI was not accepted >> >>>> as the attribute I was looking for (nsslapd-changelogdir) is not >> >>>> in the schema as the config is just an extensibleObject. But as >> >>>> I was going through the attributes, I did not see anything >> >>>> super-secret. >> >>>> >> >>>> Petr, is there any way to make permission plugin accept unknown >> >>>> attribute in the permission attribute list, or do we need to use >> >>>> "*" in this case? >> >>> The ACL Syntax Error comes straight from the DS, so there's not >> >>> much IPA can do. The error suggests adding nsslapd-changelogdir >> >>> to the schema, but I'm not sure that's the right solution here. >> >>> Thierry, any comments? See the attached LDIF. >> >>> >> >> Actually this limitation was added with the bug >> >> https://bugzilla.redhat.com/show_bug.cgi?id=244229. >> >> I do not see in the bug, if the ability to define non schema >> >> attribute was creating a problem for IPA >> > Not before, but with PermissionV2 and especially these patches, we >> > may need to control access to unknown attributes in >> > extensibleObject objects. >> One possibility is to revert that fix (with or without configuration >> toggle). But then in a topology with mixed versions of DS, old DS >> will skipped those aci. >> >> Using '*' char is not nice but will guaranty a same evaluation on all >> servers. > >We requested attribute validation when adding ACIs, w/o it it was very >simple to make typos, which would be fatal for DENY ACIs. > >The problem here is in using extensibleObject and not defining a >schema IMO. > >That said I am ok with the targetattr with appended asterisk to the >undefined attribute name. +1. Another alternative is to use some symbol that could not be present in the attribute name at the beginning of the targetattr to switch off the schema checks, e.g. targetattr=">nssldapd-changelogdir". -- / Alexander Bokovoy From mkosek at redhat.com Wed Jan 14 14:58:38 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 15:58:38 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <20150114093452.14b0c665@willson.usersys.redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> <54B66412.3050607@redhat.com> <20150114093452.14b0c665@willson.usersys.redhat.com> Message-ID: <54B6841E.4040306@redhat.com> On 01/14/2015 03:34 PM, Simo Sorce wrote: > On Wed, 14 Jan 2015 13:41:54 +0100 > thierry bordaz wrote: > >> On 01/14/2015 12:03 PM, Martin Kosek wrote: >>> On 01/14/2015 10:58 AM, thierry bordaz wrote: >>>> On 01/14/2015 10:15 AM, Petr Viktorin wrote: >>>>> On 01/13/2015 10:52 PM, Martin Kosek wrote: >>>>>> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>>>>>> On Tue, 13 Jan 2015 18:16:11 +0100 >>>>>>> Martin Kosek wrote: >>>>>>> >>>>>>>> This is crude first version of the (working) fixes to fix >>>>>>>> Winsync/Passsync problems caused by the PermissionV2 >>>>>>>> refactoring. >>>>>>>> >>>>>>>> Simo/Petr3 or others, any concerns? >>>>>>>> >>>>>>> The first patch looks good >>>>>>> the second looks .. broad ? >>>>>>> >>>>>>> Shouldn't you explicitly allow specific attributes ? >>>>>> You mean for: >>>>>> >>>>>> + 'System: Read LDBM database config': { >>>>>> + 'ipapermlocation': DN('cn=config'), >>>>>> + 'ipapermtarget': DN('cn=config,cn=ldbm >>>>>> database,cn=plugins,cn=config'), >>>>>> + 'ipapermbindruletype': 'permission', >>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>> + 'default_privileges': {'Replication Administrators'}, >>>>>> + 'ipapermdefaultattr': {'*'}, >>>>>> + }, >>>>>> >>>>>> ? I did that as my first try, but then the ACI was not accepted >>>>>> as the attribute I was looking for (nsslapd-changelogdir) is not >>>>>> in the schema as the config is just an extensibleObject. But as >>>>>> I was going through the attributes, I did not see anything >>>>>> super-secret. >>>>>> >>>>>> Petr, is there any way to make permission plugin accept unknown >>>>>> attribute in the permission attribute list, or do we need to use >>>>>> "*" in this case? >>>>> The ACL Syntax Error comes straight from the DS, so there's not >>>>> much IPA can do. The error suggests adding nsslapd-changelogdir >>>>> to the schema, but I'm not sure that's the right solution here. >>>>> Thierry, any comments? See the attached LDIF. >>>>> >>>> Actually this limitation was added with the bug >>>> https://bugzilla.redhat.com/show_bug.cgi?id=244229. >>>> I do not see in the bug, if the ability to define non schema >>>> attribute was creating a problem for IPA >>> Not before, but with PermissionV2 and especially these patches, we >>> may need to control access to unknown attributes in >>> extensibleObject objects. >> One possibility is to revert that fix (with or without configuration >> toggle). But then in a topology with mixed versions of DS, old DS >> will skipped those aci. >> >> Using '*' char is not nice but will guaranty a same evaluation on all >> servers. > > We requested attribute validation when adding ACIs, w/o it it was very > simple to make typos, which would be fatal for DENY ACIs. > > The problem here is in using extensibleObject and not defining a > schema IMO. > > That said I am ok with the targetattr with appended asterisk to the > undefined attribute name. > > Simo. After some thoughts, I agree with this path also. I will soon send the revised patches, with this and other improvements. Martin From mbabinsk at redhat.com Wed Jan 14 15:49:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Jan 2015 16:49:33 +0100 Subject: [Freeipa-devel] [PATCH 0002] Changing the token owner also changes its manager Message-ID: <54B6900D.8070303@redhat.com> Changing the owner of a token also implicitly sets the new owner as its manager if following conditions are met: 1.) The original token owner was also its manager 2.) The new manager is not set explicitly via CLI interface. If the owner is unset and the above conditions are met, then the manager of the token will also be unset. https://fedorahosted.org/freeipa/ticket/4681 Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0002-1-changing-the-token-owner-changes-also-the-manager.patch Type: text/x-patch Size: 1902 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Jan 14 15:53:18 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Jan 2015 16:53:18 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation In-Reply-To: <54B53E68.60000@redhat.com> References: <54B3FA19.6000903@redhat.com> <54B4D5B4.3050301@redhat.com> <54B4DB7A.4080307@redhat.com> <54B53E68.60000@redhat.com> Message-ID: <54B690EE.3070604@redhat.com> On 01/13/2015 04:48 PM, Martin Babinsky wrote: > On 01/13/2015 09:46 AM, Jan Cholasta wrote: >> Dne 13.1.2015 v 09:22 Martin Kosek napsal(a): >>> On 01/12/2015 05:45 PM, Martin Babinsky wrote: >>>> related to ticket https://fedorahosted.org/freeipa/ticket/4808 >>>> >>>> Patch attached. >>>> >>>> Martin^3 >>> >>> I think the --tgt-kinit-attempts approach is good one. Couple comments >>> I have >>> when reading the patch: >>> >>> 1) Function >>> +def get_host_tgt(options, keytab, host, realm, env): >>> should be made more general purpose and instead of whole "options", it >>> should >>> rather accept just "kinit_attemps". It will then enable future >>> generations to >>> reuse the function for something else. Just a generally good practice, >>> nothing >>> critical. >>> >>> 2) I think >>> + if returncode == 0: >>> + root_logger.info("Attempt %d succeeded." % n_attempts) >>> + break >>> >>> can be just DEBUG level. People do not need to know we will try >>> multiple attempts. >>> >>> 3) It may be even better to print >>> "Attempt %d/%d failed." instead of just number. But this is up to you. >>> >>> 4) I see several C-isms in the code, as a programming practice, let us >>> remove >>> them :-) In Python, the OK/notOK status is generally passed via >>> exceptions, not >>> return codes unless you really need them for anything meaningful. >>> >>> So, you can omit "raiseonerr=False" and have the handling code in an >>> Except >>> clause. When max number of attempts is breached, you then just raise the >>> exception further (use bare "raise", to re-raise to keep the original >>> stack). >> >> +1 >> >> Additionally: >> >> 5) I would prefer if the option was named --kinit-attempts instead of >> --tgt-kinit-attempts (the "tgt" seems redundant). >> >> 6) Please do not use backslashes for line wrapping, unless it is >> absolutely necessary. Instead, enclose the expression in parens for >> implicit continuation: >> >> + help=("number of attempts to obtain host TGT" >> + "if the first one fails (defaults to >> %default).")) >> >> 7) Please follow PEP8 in new code: >> >> ipa-client/ipa-install/ipa-client-install:151:80: E501 line too long (93 >> > 79 characters) >> ipa-client/ipa-install/ipa-client-install:1100:1: E302 expected 2 blank >> lines, found 1 >> ipa-client/ipa-install/ipa-client-install:1107:29: E126 continuation >> line over-indented for hanging indent >> ipa-client/ipa-install/ipa-client-install:1107:41: E231 missing >> whitespace after ',' >> ipa-client/ipa-install/ipa-client-install:1108:29: E128 continuation >> line under-indented for visual indent >> ipa-client/ipa-install/ipa-client-install:1116:51: E225 missing >> whitespace around operator >> ipa-client/ipa-install/ipa-client-install:2453:80: E501 line too long >> (88 > 79 characters) >> ipa-client/ipa-install/ipa-client-install:2454:80: E501 line too long >> (89 > 79 characters) >> ipa-client/ipa-install/ipa-client-install:2531:80: E501 line too long >> (83 > 79 characters) >> ipa-client/ipa-install/ipa-client-install:2532:80: E501 line too long >> (81 > 79 characters) >> >> Honza >> > Thank you for your comments. Attaching the updated patch (I have sent > the message much earlier, but only to Jan because I messed up the reply > addresses in Thunderbird. Sorry for that). > > Martin > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Attaching updated patch. https://fedorahosted.org/freeipa/ticket/4808 Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0001-3-ipa-client-install-added-new-option.patch Type: text/x-patch Size: 5221 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 14 15:55:41 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 16:55:41 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <20150114144220.GS16288@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> <54B66412.3050607@redhat.com> <20150114093452.14b0c665@willson.usersys.redhat.com> <20150114144220.GS16288@redhat.com> Message-ID: <54B6917D.7010002@redhat.com> On 01/14/2015 03:42 PM, Alexander Bokovoy wrote: > On Wed, 14 Jan 2015, Simo Sorce wrote: >> On Wed, 14 Jan 2015 13:41:54 +0100 >> thierry bordaz wrote: >> >>> On 01/14/2015 12:03 PM, Martin Kosek wrote: >>> > On 01/14/2015 10:58 AM, thierry bordaz wrote: >>> >> On 01/14/2015 10:15 AM, Petr Viktorin wrote: >>> >>> On 01/13/2015 10:52 PM, Martin Kosek wrote: >>> >>>> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>> >>>>> On Tue, 13 Jan 2015 18:16:11 +0100 >>> >>>>> Martin Kosek wrote: >>> >>>>> >>> >>>>>> This is crude first version of the (working) fixes to fix >>> >>>>>> Winsync/Passsync problems caused by the PermissionV2 >>> >>>>>> refactoring. >>> >>>>>> >>> >>>>>> Simo/Petr3 or others, any concerns? >>> >>>>>> >>> >>>>> The first patch looks good >>> >>>>> the second looks .. broad ? >>> >>>>> >>> >>>>> Shouldn't you explicitly allow specific attributes ? >>> >>>> You mean for: >>> >>>> >>> >>>> + 'System: Read LDBM database config': { >>> >>>> + 'ipapermlocation': DN('cn=config'), >>> >>>> + 'ipapermtarget': DN('cn=config,cn=ldbm >>> >>>> database,cn=plugins,cn=config'), >>> >>>> + 'ipapermbindruletype': 'permission', >>> >>>> + 'ipapermright': {'read', 'search', 'compare'}, >>> >>>> + 'default_privileges': {'Replication Administrators'}, >>> >>>> + 'ipapermdefaultattr': {'*'}, >>> >>>> + }, >>> >>>> >>> >>>> ? I did that as my first try, but then the ACI was not accepted >>> >>>> as the attribute I was looking for (nsslapd-changelogdir) is not >>> >>>> in the schema as the config is just an extensibleObject. But as >>> >>>> I was going through the attributes, I did not see anything >>> >>>> super-secret. >>> >>>> >>> >>>> Petr, is there any way to make permission plugin accept unknown >>> >>>> attribute in the permission attribute list, or do we need to use >>> >>>> "*" in this case? >>> >>> The ACL Syntax Error comes straight from the DS, so there's not >>> >>> much IPA can do. The error suggests adding nsslapd-changelogdir >>> >>> to the schema, but I'm not sure that's the right solution here. >>> >>> Thierry, any comments? See the attached LDIF. >>> >>> >>> >> Actually this limitation was added with the bug >>> >> https://bugzilla.redhat.com/show_bug.cgi?id=244229. >>> >> I do not see in the bug, if the ability to define non schema >>> >> attribute was creating a problem for IPA >>> > Not before, but with PermissionV2 and especially these patches, we >>> > may need to control access to unknown attributes in >>> > extensibleObject objects. >>> One possibility is to revert that fix (with or without configuration >>> toggle). But then in a topology with mixed versions of DS, old DS >>> will skipped those aci. >>> >>> Using '*' char is not nice but will guaranty a same evaluation on all >>> servers. >> >> We requested attribute validation when adding ACIs, w/o it it was very >> simple to make typos, which would be fatal for DENY ACIs. >> >> The problem here is in using extensibleObject and not defining a >> schema IMO. >> >> That said I am ok with the targetattr with appended asterisk to the >> undefined attribute name. > +1. Another alternative is to use some symbol that could not be present > in the attribute name at the beginning of the targetattr to switch off > the schema checks, e.g. targetattr=">nssldapd-changelogdir". Right, but the disadvantage is that ACIs following that approach would only work on new servers... Martin From mbasti at redhat.com Wed Jan 14 16:20:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 14 Jan 2015 17:20:13 +0100 Subject: [Freeipa-devel] [PATCH 0170, 0183] Detect and warn about invalid forwardzone configuration In-Reply-To: <548AE516.9020906@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> <5489B810.60801@redhat.com> <5489BD60.8000100@redhat.com> <5489C9D9.3070302@redhat.com> <548AE490.7060003@redhat.com> <548AE516.9020906@redhat.com> Message-ID: <54B6973D.30205@redhat.com> On 12/12/14 13:52, Martin Basti wrote: > On 12/12/14 13:50, Martin Kosek wrote: >> On 12/11/2014 05:44 PM, Petr Spacek wrote: >>> On 11.12.2014 16:50, Martin Basti wrote: >>>> Updated aptch attached: >>> >>> Nice work, ACK! >>> >> >> Can we also add some tests? This is a lot of new code that could >> break stuff. > > We can, in week maybe or after christmas, currently I do some work > with tests and adding new tests required by QE, I will add forwardzone > warnings tests when finish this. > Added tests (required patch 0170). Original and new patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4.1-mbasti-0183-DNS-tests-warning-if-forward-zone-is-inactive.patch Type: text/x-patch Size: 20241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-mbasti-0183-DNS-tests-warning-if-forward-zone-is-inactive.patch Type: text/x-patch Size: 20243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0170.5-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch Type: text/x-patch Size: 17035 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jan 14 16:23:14 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 14 Jan 2015 11:23:14 -0500 Subject: [Freeipa-devel] [PATCH 0002] Changing the token owner also changes its manager In-Reply-To: <54B6900D.8070303@redhat.com> References: <54B6900D.8070303@redhat.com> Message-ID: <1421252594.2477.39.camel@redhat.com> On Wed, 2015-01-14 at 16:49 +0100, Martin Babinsky wrote: > Changing the owner of a token also implicitly sets the new owner as its > manager if following conditions are met: > > 1.) The original token owner was also its manager > > 2.) The new manager is not set explicitly via CLI interface. > > If the owner is unset and the above conditions are met, then the manager > of the token will also be unset. > > https://fedorahosted.org/freeipa/ticket/4681 Nitpicks: 1. The commit message summary line should not have a '.' 2. The commit message is not properly wrapped. 3. The newline before _normalize_owner() is undesirable. 4. Shouldn't prev_managed_by be prev_managedby? The main body of the change looks good to me. Nathaniel From tbabej at redhat.com Wed Jan 14 16:37:21 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Jan 2015 17:37:21 +0100 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise In-Reply-To: References: Message-ID: <54B69B41.9070404@redhat.com> On 01/14/2015 02:55 PM, Gabe Alford wrote: > Hello, > > In looking into https://fedorahosted.org/freeipa/ticket/4029 I > am wondering if there should be separate ipa-advise test, Yes/No? > Could be handy in the future to test more ipa-advise output? Or should > this test be added to the test_legacy_clients.py? > > Thanks, > > Gabe > > On Tue, Dec 2, 2014 at 9:21 PM, Gabe Alford > wrote: > > Hello, > > I was going to try my hand at attempting a patch for ipa-tests. > However in wanting to test my patch, I am not sure how to run > ipa-tests to check if it works or not. Documentation is not really > clear on what needs to be done to start a test and run a test. > This is for https://fedorahosted.org/freeipa/ticket/4029 > > I have attached the patch that I have yet to really test with > ipa-test. Any help on how to test the patch running ipa-tests > would be great. Of course, if one of the reviewers looks at the > patch and looks good, then I would be happy with that as well. > > Thanks, > > Gabe > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, TL;DR: feel free to create a separate ipa-advise test file. Test requested in this ticket really does not belong to the legacy clients feature test. As for the any new tests that might come: I think tests for ipa-advise that are specific to that particular feature should be tested with that feature, more so, if they contain parts that are supposed to work copy-pasted. If a tests, however, tests a general behaviour of ipa-advise, it should live in the ipa-advise namespace, hence separate test file. HTH, -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Jan 14 16:47:51 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 17:47:51 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B6841E.4040306@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> <54B66412.3050607@redhat.com> <20150114093452.14b0c665@willson.usersys.redhat.com> <54B6841E.4040306@redhat.com> Message-ID: <54B69DB7.7030901@redhat.com> On 01/14/2015 03:58 PM, Martin Kosek wrote: > On 01/14/2015 03:34 PM, Simo Sorce wrote: >> On Wed, 14 Jan 2015 13:41:54 +0100 >> thierry bordaz wrote: >> >>> On 01/14/2015 12:03 PM, Martin Kosek wrote: >>>> On 01/14/2015 10:58 AM, thierry bordaz wrote: >>>>> On 01/14/2015 10:15 AM, Petr Viktorin wrote: >>>>>> On 01/13/2015 10:52 PM, Martin Kosek wrote: >>>>>>> On 01/13/2015 09:55 PM, Simo Sorce wrote: >>>>>>>> On Tue, 13 Jan 2015 18:16:11 +0100 >>>>>>>> Martin Kosek wrote: >>>>>>>> >>>>>>>>> This is crude first version of the (working) fixes to fix >>>>>>>>> Winsync/Passsync problems caused by the PermissionV2 >>>>>>>>> refactoring. >>>>>>>>> >>>>>>>>> Simo/Petr3 or others, any concerns? >>>>>>>>> >>>>>>>> The first patch looks good >>>>>>>> the second looks .. broad ? >>>>>>>> >>>>>>>> Shouldn't you explicitly allow specific attributes ? >>>>>>> You mean for: >>>>>>> >>>>>>> + 'System: Read LDBM database config': { >>>>>>> + 'ipapermlocation': DN('cn=config'), >>>>>>> + 'ipapermtarget': DN('cn=config,cn=ldbm >>>>>>> database,cn=plugins,cn=config'), >>>>>>> + 'ipapermbindruletype': 'permission', >>>>>>> + 'ipapermright': {'read', 'search', 'compare'}, >>>>>>> + 'default_privileges': {'Replication Administrators'}, >>>>>>> + 'ipapermdefaultattr': {'*'}, >>>>>>> + }, >>>>>>> >>>>>>> ? I did that as my first try, but then the ACI was not accepted >>>>>>> as the attribute I was looking for (nsslapd-changelogdir) is not >>>>>>> in the schema as the config is just an extensibleObject. But as >>>>>>> I was going through the attributes, I did not see anything >>>>>>> super-secret. >>>>>>> >>>>>>> Petr, is there any way to make permission plugin accept unknown >>>>>>> attribute in the permission attribute list, or do we need to use >>>>>>> "*" in this case? >>>>>> The ACL Syntax Error comes straight from the DS, so there's not >>>>>> much IPA can do. The error suggests adding nsslapd-changelogdir >>>>>> to the schema, but I'm not sure that's the right solution here. >>>>>> Thierry, any comments? See the attached LDIF. >>>>>> >>>>> Actually this limitation was added with the bug >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=244229. >>>>> I do not see in the bug, if the ability to define non schema >>>>> attribute was creating a problem for IPA >>>> Not before, but with PermissionV2 and especially these patches, we >>>> may need to control access to unknown attributes in >>>> extensibleObject objects. >>> One possibility is to revert that fix (with or without configuration >>> toggle). But then in a topology with mixed versions of DS, old DS >>> will skipped those aci. >>> >>> Using '*' char is not nice but will guaranty a same evaluation on all >>> servers. >> >> We requested attribute validation when adding ACIs, w/o it it was very >> simple to make typos, which would be fatal for DENY ACIs. >> >> The problem here is in using extensibleObject and not defining a >> schema IMO. >> >> That said I am ok with the targetattr with appended asterisk to the >> undefined attribute name. >> >> Simo. > > After some thoughts, I agree with this path also. I will soon send the revised > patches, with this and other improvements. Attaching new, clean version of the patches, following this path. The ACIs are now not as broad as before. Originally, I added all new ACIs as V2 permissions, but then I realized it would not work on replicas, as cn=config is not replicas and the ACIs stored there would not be created as PermissionV2 object would already exist, when the replica is being installed. With attached patch set, "admin" user or "Replication Administrators" privilege members should be able to create a winsync connection and PassSync user, e.g.: [root at ipa ~]# ipa-replica-manage connect --winsync --cacert=/home/mkosek/mkad2012.crt --binddn='cn=Administrator,cn=users,dc=mkad2012,dc=test' --bindpw=Secret123 mkdc2012.mkad2012.test --passsync Secret123 -v ... The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=mkosek-f21,dc=test Adding Windows PassSync system account ... Connected 'ipa.mkosek-f21.test' to 'mkdc2012.mkad2012.test' This should just complete and not crash. admin user should then also able to list the winsync replica with # ipa-replica-manage list This fixes one bug. For testing the second ticket, PassSync one, either test with PassSync software directly or verify that passsync system user can see NT attribute and change user passwords: # ldapsearch -D "uid=passsync,cn=sysaccounts,cn=etc,dc=mkosek-f21,dc=test" -x -w Secret123 -b cn=users,cn=accounts,dc=mkosek-f21,dc=test "(ntuserdomainid=testuser)" ntuserdomainid # extended LDIF # # LDAPv3 # base with scope subtree # filter: (ntuserdomainid=testuser) # requesting: ntuserdomainid # # testuser, users, accounts, mkosek-f21.test dn: uid=testuser,cn=users,cn=accounts,dc=mkosek-f21,dc=test ntuserdomainid: testuser # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # ldappasswd -D "uid=passsync,cn=sysaccounts,cn=etc,dc=mkosek-f21,dc=test" -x -w Secret123 uid=testuser,cn=users,cn=accounts,dc=mkosek-f21,dc=test -s newPassword [root at ipa ~]# echo $? 0 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-488.2-allow-passsync-user-to-locate-and-update-nt-users.patch Type: text/x-patch Size: 14719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-489.2-allow-replication-administrators-to-manipulate-winsy.patch Type: text/x-patch Size: 3651 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Jan 14 16:49:05 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Jan 2015 17:49:05 +0100 Subject: [Freeipa-devel] [PATCH 0002] Changing the token owner also changes its manager In-Reply-To: <1421252594.2477.39.camel@redhat.com> References: <54B6900D.8070303@redhat.com> <1421252594.2477.39.camel@redhat.com> Message-ID: <54B69E01.4070208@redhat.com> On 01/14/2015 05:23 PM, Nathaniel McCallum wrote: > On Wed, 2015-01-14 at 16:49 +0100, Martin Babinsky wrote: >> Changing the owner of a token also implicitly sets the new owner as its >> manager if following conditions are met: >> >> 1.) The original token owner was also its manager >> >> 2.) The new manager is not set explicitly via CLI interface. >> >> If the owner is unset and the above conditions are met, then the manager >> of the token will also be unset. >> >> https://fedorahosted.org/freeipa/ticket/4681 > > Nitpicks: > 1. The commit message summary line should not have a '.' > 2. The commit message is not properly wrapped. > 3. The newline before _normalize_owner() is undesirable. > 4. Shouldn't prev_managed_by be prev_managedby? > > The main body of the change looks good to me. > > Nathaniel > > > Attaching updated patch. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0002-2-changing-the-token-owner-changes-also-the-manager.patch Type: text/x-patch Size: 1818 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Jan 14 16:52:45 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Jan 2015 17:52:45 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: attempt to get host TGT several times before aborting client installation In-Reply-To: <54B690EE.3070604@redhat.com> References: <54B3FA19.6000903@redhat.com> <54B4D5B4.3050301@redhat.com> <54B4DB7A.4080307@redhat.com> <54B53E68.60000@redhat.com> <54B690EE.3070604@redhat.com> Message-ID: <54B69EDD.2000800@redhat.com> On 01/14/2015 04:53 PM, Martin Babinsky wrote: > On 01/13/2015 04:48 PM, Martin Babinsky wrote: >> On 01/13/2015 09:46 AM, Jan Cholasta wrote: >>> Dne 13.1.2015 v 09:22 Martin Kosek napsal(a): >>>> On 01/12/2015 05:45 PM, Martin Babinsky wrote: >>>>> related to ticket https://fedorahosted.org/freeipa/ticket/4808 >>>>> >>>>> Patch attached. >>>>> >>>>> Martin^3 >>>> >>>> I think the --tgt-kinit-attempts approach is good one. Couple comments >>>> I have >>>> when reading the patch: >>>> >>>> 1) Function >>>> +def get_host_tgt(options, keytab, host, realm, env): >>>> should be made more general purpose and instead of whole "options", it >>>> should >>>> rather accept just "kinit_attemps". It will then enable future >>>> generations to >>>> reuse the function for something else. Just a generally good practice, >>>> nothing >>>> critical. >>>> >>>> 2) I think >>>> + if returncode == 0: >>>> + root_logger.info("Attempt %d succeeded." % n_attempts) >>>> + break >>>> >>>> can be just DEBUG level. People do not need to know we will try >>>> multiple attempts. >>>> >>>> 3) It may be even better to print >>>> "Attempt %d/%d failed." instead of just number. But this is up to you. >>>> >>>> 4) I see several C-isms in the code, as a programming practice, let us >>>> remove >>>> them :-) In Python, the OK/notOK status is generally passed via >>>> exceptions, not >>>> return codes unless you really need them for anything meaningful. >>>> >>>> So, you can omit "raiseonerr=False" and have the handling code in an >>>> Except >>>> clause. When max number of attempts is breached, you then just raise >>>> the >>>> exception further (use bare "raise", to re-raise to keep the original >>>> stack). >>> >>> +1 >>> >>> Additionally: >>> >>> 5) I would prefer if the option was named --kinit-attempts instead of >>> --tgt-kinit-attempts (the "tgt" seems redundant). >>> >>> 6) Please do not use backslashes for line wrapping, unless it is >>> absolutely necessary. Instead, enclose the expression in parens for >>> implicit continuation: >>> >>> + help=("number of attempts to obtain host >>> TGT" >>> + "if the first one fails (defaults to >>> %default).")) >>> >>> 7) Please follow PEP8 in new code: >>> >>> ipa-client/ipa-install/ipa-client-install:151:80: E501 line too long (93 >>> > 79 characters) >>> ipa-client/ipa-install/ipa-client-install:1100:1: E302 expected 2 blank >>> lines, found 1 >>> ipa-client/ipa-install/ipa-client-install:1107:29: E126 continuation >>> line over-indented for hanging indent >>> ipa-client/ipa-install/ipa-client-install:1107:41: E231 missing >>> whitespace after ',' >>> ipa-client/ipa-install/ipa-client-install:1108:29: E128 continuation >>> line under-indented for visual indent >>> ipa-client/ipa-install/ipa-client-install:1116:51: E225 missing >>> whitespace around operator >>> ipa-client/ipa-install/ipa-client-install:2453:80: E501 line too long >>> (88 > 79 characters) >>> ipa-client/ipa-install/ipa-client-install:2454:80: E501 line too long >>> (89 > 79 characters) >>> ipa-client/ipa-install/ipa-client-install:2531:80: E501 line too long >>> (83 > 79 characters) >>> ipa-client/ipa-install/ipa-client-install:2532:80: E501 line too long >>> (81 > 79 characters) >>> >>> Honza >>> >> Thank you for your comments. Attaching the updated patch (I have sent >> the message much earlier, but only to Jan because I messed up the reply >> addresses in Thunderbird. Sorry for that). >> >> Martin >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Attaching updated patch. > > https://fedorahosted.org/freeipa/ticket/4808 > > Martin^3 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Forgot to update 'ipa-client-install' man page. The updated patch fixes this. Thanks to Rob for pointing it out. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0001-4-ipa-client-install-added-new-option.patch Type: text/x-patch Size: 6010 bytes Desc: not available URL: From tbabej at redhat.com Wed Jan 14 17:00:07 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Jan 2015 18:00:07 +0100 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise In-Reply-To: <54B69B41.9070404@redhat.com> References: <54B69B41.9070404@redhat.com> Message-ID: <54B6A097.9020601@redhat.com> On 01/14/2015 05:37 PM, Tomas Babej wrote: > > On 01/14/2015 02:55 PM, Gabe Alford wrote: >> Hello, >> >> In looking into https://fedorahosted.org/freeipa/ticket/4029 I >> am wondering if there should be separate ipa-advise test, Yes/No? >> Could be handy in the future to test more ipa-advise output? Or >> should this test be added to the test_legacy_clients.py? >> >> Thanks, >> >> Gabe >> >> On Tue, Dec 2, 2014 at 9:21 PM, Gabe Alford > > wrote: >> >> Hello, >> >> I was going to try my hand at attempting a patch for ipa-tests. >> However in wanting to test my patch, I am not sure how to run >> ipa-tests to check if it works or not. Documentation is not >> really clear on what needs to be done to start a test and run a >> test. This is for https://fedorahosted.org/freeipa/ticket/4029 >> >> I have attached the patch that I have yet to really test with >> ipa-test. Any help on how to test the patch running ipa-tests >> would be great. Of course, if one of the reviewers looks at the >> patch and looks good, then I would be happy with that as well. >> >> Thanks, >> >> Gabe >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Hello, > > TL;DR: feel free to create a separate ipa-advise test file. Test > requested in this ticket really does not belong to the legacy clients > feature test. > > As for the any new tests that might come: I think tests for ipa-advise > that are specific to that particular feature should be tested with > that feature, more so, if they contain parts that are supposed to work > copy-pasted. If a tests, however, tests a general behaviour of > ipa-advise, it should live in the ipa-advise namespace, hence separate > test file. > > HTH, > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org The attached patch looks fine, although, please also test for a non-zero return code number. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Wed Jan 14 17:05:56 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Jan 2015 18:05:56 +0100 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise In-Reply-To: <54B6A097.9020601@redhat.com> References: <54B69B41.9070404@redhat.com> <54B6A097.9020601@redhat.com> Message-ID: <54B6A1F4.8000807@redhat.com> On 01/14/2015 06:00 PM, Tomas Babej wrote: > > On 01/14/2015 05:37 PM, Tomas Babej wrote: >> >> On 01/14/2015 02:55 PM, Gabe Alford wrote: >>> Hello, >>> >>> In looking into https://fedorahosted.org/freeipa/ticket/4029 >>> I am wondering if there should be separate ipa-advise test, Yes/No? >>> Could be handy in the future to test more ipa-advise output? Or >>> should this test be added to the test_legacy_clients.py? >>> >>> Thanks, >>> >>> Gabe >>> >>> On Tue, Dec 2, 2014 at 9:21 PM, Gabe Alford >> > wrote: >>> >>> Hello, >>> >>> I was going to try my hand at attempting a patch for ipa-tests. >>> However in wanting to test my patch, I am not sure how to run >>> ipa-tests to check if it works or not. Documentation is not >>> really clear on what needs to be done to start a test and run a >>> test. This is for https://fedorahosted.org/freeipa/ticket/4029 >>> >>> I have attached the patch that I have yet to really test with >>> ipa-test. Any help on how to test the patch running ipa-tests >>> would be great. Of course, if one of the reviewers looks at the >>> patch and looks good, then I would be happy with that as well. >>> >>> Thanks, >>> >>> Gabe >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Hello, >> >> TL;DR: feel free to create a separate ipa-advise test file. Test >> requested in this ticket really does not belong to the legacy clients >> feature test. >> >> As for the any new tests that might come: I think tests for >> ipa-advise that are specific to that particular feature should be >> tested with that feature, more so, if they contain parts that are >> supposed to work copy-pasted. If a tests, however, tests a general >> behaviour of ipa-advise, it should live in the ipa-advise namespace, >> hence separate test file. >> >> HTH, >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org > > The attached patch looks fine, although, please also test for a > non-zero return code number. > Upon hitting send I noticed you did not include raiseonerr=False into the run_command call. You need to do that, otherwise a exception will be raised, since ipa-advise exited with non-zero return code. > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed Jan 14 17:13:41 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 14 Jan 2015 10:13:41 -0700 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise In-Reply-To: <54B6A1F4.8000807@redhat.com> References: <54B69B41.9070404@redhat.com> <54B6A097.9020601@redhat.com> <54B6A1F4.8000807@redhat.com> Message-ID: On Wed, Jan 14, 2015 at 10:05 AM, Tomas Babej wrote: > > On 01/14/2015 06:00 PM, Tomas Babej wrote: > > > On 01/14/2015 05:37 PM, Tomas Babej wrote: > > > On 01/14/2015 02:55 PM, Gabe Alford wrote: > > Hello, > > In looking into https://fedorahosted.org/freeipa/ticket/4029 I am > wondering if there should be separate ipa-advise test, Yes/No? Could be > handy in the future to test more ipa-advise output? Or should this test be > added to the test_legacy_clients.py? > > Thanks, > > Gabe > > On Tue, Dec 2, 2014 at 9:21 PM, Gabe Alford wrote: > >> Hello, >> >> I was going to try my hand at attempting a patch for ipa-tests. However >> in wanting to test my patch, I am not sure how to run ipa-tests to check if >> it works or not. Documentation is not really clear on what needs to be done >> to start a test and run a test. This is for >> https://fedorahosted.org/freeipa/ticket/4029 >> >> I have attached the patch that I have yet to really test with ipa-test. >> Any help on how to test the patch running ipa-tests would be great. Of >> course, if one of the reviewers looks at the patch and looks good, then I >> would be happy with that as well. >> >> Thanks, >> >> Gabe >> > > > > _______________________________________________ > Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel > > > Hello, > > TL;DR: feel free to create a separate ipa-advise test file. Test requested > in this ticket really does not belong to the legacy clients feature test. > > As for the any new tests that might come: I think tests for ipa-advise > that are specific to that particular feature should be tested with that > feature, more so, if they contain parts that are supposed to work > copy-pasted. If a tests, however, tests a general behaviour of ipa-advise, > it should live in the ipa-advise namespace, hence separate test file. > > HTH, > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > > The attached patch looks fine, although, please also test for a non-zero > return code number. > > > Upon hitting send I noticed you did not include raiseonerr=False into the > run_command call. You need to do that, otherwise a exception will be > raised, since ipa-advise exited with non-zero return code. > Thanks Tomas. Which do you prefer: a test_advise.py or an update to the existing patch? > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Wed Jan 14 17:23:14 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 14 Jan 2015 18:23:14 +0100 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise In-Reply-To: References: <54B69B41.9070404@redhat.com> <54B6A097.9020601@redhat.com> <54B6A1F4.8000807@redhat.com> Message-ID: <54B6A602.9060101@redhat.com> On 01/14/2015 06:13 PM, Gabe Alford wrote: > On Wed, Jan 14, 2015 at 10:05 AM, Tomas Babej > wrote: > > > On 01/14/2015 06:00 PM, Tomas Babej wrote: >> >> On 01/14/2015 05:37 PM, Tomas Babej wrote: >>> >>> On 01/14/2015 02:55 PM, Gabe Alford wrote: >>>> Hello, >>>> >>>> In looking into >>>> https://fedorahosted.org/freeipa/ticket/4029 I am wondering if >>>> there should be separate ipa-advise test, Yes/No? Could be >>>> handy in the future to test more ipa-advise output? Or should >>>> this test be added to the test_legacy_clients.py? >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>>> On Tue, Dec 2, 2014 at 9:21 PM, Gabe Alford >>>> > wrote: >>>> >>>> Hello, >>>> >>>> I was going to try my hand at attempting a patch for >>>> ipa-tests. However in wanting to test my patch, I am not >>>> sure how to run ipa-tests to check if it works or not. >>>> Documentation is not really clear on what needs to be done >>>> to start a test and run a test. This is for >>>> https://fedorahosted.org/freeipa/ticket/4029 >>>> >>>> I have attached the patch that I have yet to really test >>>> with ipa-test. Any help on how to test the patch running >>>> ipa-tests would be great. Of course, if one of the >>>> reviewers looks at the patch and looks good, then I would >>>> be happy with that as well. >>>> >>>> Thanks, >>>> >>>> Gabe >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Hello, >>> >>> TL;DR: feel free to create a separate ipa-advise test file. Test >>> requested in this ticket really does not belong to the legacy >>> clients feature test. >>> >>> As for the any new tests that might come: I think tests for >>> ipa-advise that are specific to that particular feature should >>> be tested with that feature, more so, if they contain parts that >>> are supposed to work copy-pasted. If a tests, however, tests a >>> general behaviour of ipa-advise, it should live in the >>> ipa-advise namespace, hence separate test file. >>> >>> HTH, >>> >>> -- >>> Tomas Babej >>> Associate Software Engineer | Red Hat | Identity Management >>> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> The attached patch looks fine, although, please also test for a >> non-zero return code number. >> > > Upon hitting send I noticed you did not include raiseonerr=False > into the run_command call. You need to do that, otherwise a > exception will be raised, since ipa-advise exited with non-zero > return code. > > Thanks Tomas. > > Which do you prefer: a test_advise.py or an update to the existing patch? A new test file, as I pointed out in the second email :) sorry for splitting. However, it would be the best if you could spin up a positive test as well (maybe listing out available advices), not just this negative one, to justify the overhead reinstalling IPA for testing this feature. >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Wed Jan 14 19:02:38 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 14 Jan 2015 14:02:38 -0500 Subject: [Freeipa-devel] [PATCH 0002] Changing the token owner also changes its manager In-Reply-To: <54B69E01.4070208@redhat.com> References: <54B6900D.8070303@redhat.com> <1421252594.2477.39.camel@redhat.com> <54B69E01.4070208@redhat.com> Message-ID: <1421262158.2477.67.camel@redhat.com> On Wed, 2015-01-14 at 17:49 +0100, Martin Babinsky wrote: > On 01/14/2015 05:23 PM, Nathaniel McCallum wrote: > > On Wed, 2015-01-14 at 16:49 +0100, Martin Babinsky wrote: > >> Changing the owner of a token also implicitly sets the new owner as its > >> manager if following conditions are met: > >> > >> 1.) The original token owner was also its manager > >> > >> 2.) The new manager is not set explicitly via CLI interface. > >> > >> If the owner is unset and the above conditions are met, then the manager > >> of the token will also be unset. > >> > >> https://fedorahosted.org/freeipa/ticket/4681 > > > > Nitpicks: > > 1. The commit message summary line should not have a '.' > > 2. The commit message is not properly wrapped. > > 3. The newline before _normalize_owner() is undesirable. > > 4. Shouldn't prev_managed_by be prev_managedby? > > > > The main body of the change looks good to me. > > > > Nathaniel > > > > > > > > Attaching updated patch. ACK From mkosek at redhat.com Wed Jan 14 21:27:09 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Jan 2015 22:27:09 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <20150114115838.747ff066@willson.usersys.redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> <54B66412.3050607@redhat.com> <20150114093452.14b0c665@willson.usersys.redhat.com> <54B6841E.4040306@redhat.com> <54B69DB7.7030901@redhat.com> <20150114115838.747ff066@willson.usersys.redhat.com> Message-ID: <54B6DF2D.8020907@redhat.com> Adding freeipa-devel back. On 01/14/2015 05:58 PM, Simo Sorce wrote: > On Wed, 14 Jan 2015 17:47:51 +0100 > Martin Kosek wrote: > >> -add:aci:'(targetfilter="(objectclass=nsContainer)")(version 3.0; acl >> "Deny read access to replica configuration"; deny(read, search, >> compare) userdn = "ldap:///anyone";)' >> +remove:aci:'(targetfilter="(objectclass=nsContainer)")(version 3.0; >> acl "Deny read access to replica configuration"; deny(read, search, >> compare) userdn = "ldap:///anyone";)' > > Why this removal ? It is in the patch description. This container stores winsync "replicas". With this deny ACI, admin or anyone else besides Directory Manager can see the replicas as deny rules take precedence and this one is scoped for ldap://anyone. My thinking was that this container is not too secret anyway, the only information that user get is name of the winsync'ed AD. >> +dn: cn=config >> +add:aci: '(version 3.0;acl "permission:Add Configuration >> Sub-Entries";allow (add) groupdn = "ldap:///cn=Add Configuration >> Sub-Entries,cn=permissions,cn=pbac,$SUFFIX";)' > > Doesn't this allow REplication admin to add any object anywhere in > cn=config ? > This would be too broad. It does. I wanted to narrow it with targetfilter '(targetfilter = "(cn=changelog5)")' but, it did not work for me, ADD was rejected. Not sure why though, when I used '(targetfilter = "(objectclass=extensibleobject)")', it worked fine. I fear this is some problem in DS targetfilter evaluation during ADD operation, CCing Ludwig for reference. Martin From mkosek at redhat.com Thu Jan 15 08:24:09 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Jan 2015 09:24:09 +0100 Subject: [Freeipa-devel] Process update - design page review Message-ID: <54B77929.6050409@redhat.com> Hello, Please note that following the discussion and Petr's proposal in http://www.redhat.com/archives/freeipa-devel/2015-January/msg00016.html which was accepted on this list, I updated our design pages for new fields related to design page author and reviewer. Following changes were implemented: * Design author was moved from design page to info box under tag "author". If there are more author, they can be specified as "author2", "author3", ... Wiki login should be used, as the login name is then converted to link to user page under the template hood. * Design page info box now has new field "reviewer", with a person that ACKs the design (there can be multiple of them as well). If page has no reviewer, there is the "review missing" icon. Example page with filled reviewer: https://www.freeipa.org/page/V4/Replica_Promotion Code: {{Feature|version=TODO|ticket=TODO|author=SimoSorce|author2=MKosek|reviewer=Mkosek}} Example page with missing review: http://www.freeipa.org/page/V4/Manage_replication_topology Code: {{Feature|version=4.2.0|ticket=4302|author=LKrispen}} If there are any concerns with this design page process update, please tell me. If not, let us use it! As FreeIPA gets more and more complex, careful design review is required. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From dkupka at redhat.com Thu Jan 15 11:43:43 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 15 Jan 2015 12:43:43 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54B405BD.30100@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> Message-ID: <54B7A7EF.2020100@redhat.com> On 01/12/2015 06:34 PM, Martin Basti wrote: > On 09/01/15 14:43, David Kupka wrote: >> On 01/07/2015 04:15 PM, Martin Basti wrote: >>> On 07/01/15 12:27, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4249 >>> >>> Thank you for patch: >>> >>> 1) >>> - root_logger.error("Cannot update DNS records! " >>> - "Failed to connect to server '%s'.", server) >>> + ips = get_local_ipaddresses() >>> + except CalledProcessError as e: >>> + root_logger.error("Cannot update DNS records. %s" % e) >>> >>> IMO the error message should be more specific, add there something like >>> "Unable to get local IP addresses". at least in log.debug() >>> >>> 2) >>> + lines = ipresult[0].replace('\\', '').split('\n') >>> >>> .replace() is not needed >>> >>> 3) >>> + if len(ips) == 0: >>> >>> if not ips: >>> >>> is more pythonic by PEP8 >>> >>> >> Thanks for catching these. Updated patch attached. >> > merciful NACK > > Thank you for the patch, unfortunately I hit one issue which needs to be > resolved. > > If "sync PTR" is activated in zone settings, and reverse zone doesn't > exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print > Error message, 'DNS update failed'. In fact, all A/AAAA records was > succesfully updated, only PTR records failed. > > Bind log: > named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at > 'vm-101.example.com' AAAA > > named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA > 'vm-101.example.com.' refused: unable to find active reverse zone for IP > address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found > > With IPv6 we have several addresses from different reverse zones and > this situation may happen often. > I suggest following: > 1) Print list of addresses which will be updated. (Now if update fails, > user needs to read log, which addresses installer tried to update) > 2) Split nsupdates per A/AAAA record. > 3a) If failed, check with DNS query if A/AAAA and PTR record are there > and print proper error message > 3b) Just print A/AAAA (or PTR) record may not be updated for particular > IP address. > > Any other suggestions are welcome. > After long discussion with DNS and UX guru I've implemented it this way: 1. Call nsupdate only once with all updates. 2. Verify that the expected records are resolvable. 3. If no print list of missing A/AAAA, list of missing PTR records and list to mismatched PTR record. As this is running inside client we can't much more and it's up to user to check what's rotten in his DNS setup. Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0035-3-client-Update-DNS-with-all-available-local-IP-addres.patch Type: text/x-patch Size: 8172 bytes Desc: not available URL: From pspacek at redhat.com Thu Jan 15 12:15:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 15 Jan 2015 13:15:59 +0100 Subject: [Freeipa-devel] [PATCH 0170, 0183] Detect and warn about invalid forwardzone configuration In-Reply-To: <54B6973D.30205@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> <5489B810.60801@redhat.com> <5489BD60.8000100@redhat.com> <5489C9D9.3070302@redhat.com> <548AE490.7060003@redhat.com> <548AE516.9020906@redhat.com> <54B6973D.30205@redhat.com> Message-ID: <54B7AF7F.2080206@redhat.com> On 14.1.2015 17:20, Martin Basti wrote: > On 12/12/14 13:52, Martin Basti wrote: >> On 12/12/14 13:50, Martin Kosek wrote: >>> On 12/11/2014 05:44 PM, Petr Spacek wrote: >>>> On 11.12.2014 16:50, Martin Basti wrote: >>>>> Updated aptch attached: >>>> >>>> Nice work, ACK! >>>> >>> >>> Can we also add some tests? This is a lot of new code that could break stuff. >> >> We can, in week maybe or after christmas, currently I do some work with >> tests and adding new tests required by QE, I will add forwardzone warnings >> tests when finish this. >> > > Added tests (required patch 0170). > Original and new patch attached. Well done! ACK. -- Petr^2 Spacek From mbasti at redhat.com Thu Jan 15 12:17:28 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Jan 2015 13:17:28 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands Message-ID: <54B7AFD8.1050303@redhat.com> https://fedorahosted.org/freeipa/ticket/4722 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0184-Always-return-absolute-idnsname-in-dnszone-commands.patch Type: text/x-patch Size: 2131 bytes Desc: not available URL: From tbabej at redhat.com Thu Jan 15 12:25:44 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Jan 2015 13:25:44 +0100 Subject: [Freeipa-devel] [PATCH 0170, 0183] Detect and warn about invalid forwardzone configuration In-Reply-To: <54B7AF7F.2080206@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> <5489B810.60801@redhat.com> <5489BD60.8000100@redhat.com> <5489C9D9.3070302@redhat.com> <548AE490.7060003@redhat.com> <548AE516.9020906@redhat.com> <54B6973D.30205@redhat.com> <54B7AF7F.2080206@redhat.com> Message-ID: <54B7B1C8.7010402@redhat.com> On 01/15/2015 01:15 PM, Petr Spacek wrote: > On 14.1.2015 17:20, Martin Basti wrote: >> On 12/12/14 13:52, Martin Basti wrote: >>> On 12/12/14 13:50, Martin Kosek wrote: >>>> On 12/11/2014 05:44 PM, Petr Spacek wrote: >>>>> On 11.12.2014 16:50, Martin Basti wrote: >>>>>> Updated aptch attached: >>>>> Nice work, ACK! >>>>> >>>> Can we also add some tests? This is a lot of new code that could break stuff. >>> We can, in week maybe or after christmas, currently I do some work with >>> tests and adding new tests required by QE, I will add forwardzone warnings >>> tests when finish this. >>> >> Added tests (required patch 0170). >> Original and new patch attached. > Well done! ACK. > Pushed to master: c75c0e14f495ea2de96936b02219cb17a874df24 Pushed to ipa-4-1: 3952035b9e23bbb59454e48518151739b4d743e4 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mbasti at redhat.com Thu Jan 15 12:27:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Jan 2015 13:27:36 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54B7AFD8.1050303@redhat.com> References: <54B7AFD8.1050303@redhat.com> Message-ID: <54B7B238.8080206@redhat.com> On 15/01/15 13:17, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4722 > > Patch attached. > Fast fix. Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0184.2-Always-return-absolute-idnsname-in-dnszone-commands.patch Type: text/x-patch Size: 2133 bytes Desc: not available URL: From jcholast at redhat.com Thu Jan 15 13:25:58 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Jan 2015 14:25:58 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54B7B238.8080206@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> Message-ID: <54B7BFE6.8060503@redhat.com> Hi, Dne 15.1.2015 v 13:27 Martin Basti napsal(a): > On 15/01/15 13:17, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4722 >> >> Patch attached. >> > Fast fix. > > Updated patch attached. 1) Forward zone commands are not fixed. 2) It seems that the primary key returned by -mod, -del and -show (.result.value) is made absolute somewhere else in the code. Would it be possible to do it in one place? 3) Attribute values returned from LDAP are never None, so the if should be "if 'idnsname' in entry_attrs:". 4) If idnsname always has only single value, use "entry_attrs.single_value['idnsname'] = entry_attrs.single_value['idnsname'].make_absolute()" Honza -- Jan Cholasta From mbasti at redhat.com Thu Jan 15 13:58:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Jan 2015 14:58:25 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54B7BFE6.8060503@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> Message-ID: <54B7C781.5090007@redhat.com> On 15/01/15 14:25, Jan Cholasta wrote: > Hi, > > Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >> On 15/01/15 13:17, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/4722 >>> >>> Patch attached. >>> >> Fast fix. >> >> Updated patch attached. > > 1) Forward zone commands are not fixed. FWzones are new and always normalized to absolute name in ldap > > 2) It seems that the primary key returned by -mod, -del and -show > (.result.value) is made absolute somewhere else in the code. Would it > be possible to do it in one place? IMO it is not possible. Value is generated from key, and key is normalized to absolute zone before calling execute. LDAPUpdate: ... if self.obj.primary_key: pkey = keys[-1] else: pkey = None return dict(result=entry_attrs, value=pkey_to_value(pkey, options)) The idnsname attribute is just taken from LDAP without any normalization > > 3) Attribute values returned from LDAP are never None, so the if > should be "if 'idnsname' in entry_attrs:". Ok I will revert the change I made. > > 4) If idnsname always has only single value, use > "entry_attrs.single_value['idnsname'] = > entry_attrs.single_value['idnsname'].make_absolute()" Thanks > > Honza > Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0184.3-Always-return-absolute-idnsname-in-dnszone-commands.patch Type: text/x-patch Size: 2153 bytes Desc: not available URL: From jcholast at redhat.com Thu Jan 15 14:07:36 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Jan 2015 15:07:36 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54B7C781.5090007@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> <54B7C781.5090007@redhat.com> Message-ID: <54B7C9A8.8070309@redhat.com> Dne 15.1.2015 v 14:58 Martin Basti napsal(a): > On 15/01/15 14:25, Jan Cholasta wrote: >> Hi, >> >> Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >>> On 15/01/15 13:17, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/4722 >>>> >>>> Patch attached. >>>> >>> Fast fix. >>> >>> Updated patch attached. >> >> 1) Forward zone commands are not fixed. > FWzones are new and always normalized to absolute name in ldap Would you bet your money on that? Better be safe than sorry, especially when it's just a matter of moving the code around (right?) >> >> 2) It seems that the primary key returned by -mod, -del and -show >> (.result.value) is made absolute somewhere else in the code. Would it >> be possible to do it in one place? > IMO it is not possible. > > Value is generated from key, and key is normalized to absolute zone > before calling execute. > > LDAPUpdate: > ... > if self.obj.primary_key: > pkey = keys[-1] > else: > pkey = None > > return dict(result=entry_attrs, value=pkey_to_value(pkey, > options)) > > The idnsname attribute is just taken from LDAP without any normalization Right. > > >> >> 3) Attribute values returned from LDAP are never None, so the if >> should be "if 'idnsname' in entry_attrs:". > Ok I will revert the change I made. >> >> 4) If idnsname always has only single value, use >> "entry_attrs.single_value['idnsname'] = >> entry_attrs.single_value['idnsname'].make_absolute()" > Thanks >> >> Honza >> > > Updated patch attached. > -- Jan Cholasta From dkupka at redhat.com Thu Jan 15 14:22:03 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 15 Jan 2015 15:22:03 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54B7A7EF.2020100@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> Message-ID: <54B7CD0B.7080008@redhat.com> On 01/15/2015 12:43 PM, David Kupka wrote: > On 01/12/2015 06:34 PM, Martin Basti wrote: >> On 09/01/15 14:43, David Kupka wrote: >>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>> On 07/01/15 12:27, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>> >>>> Thank you for patch: >>>> >>>> 1) >>>> - root_logger.error("Cannot update DNS records! " >>>> - "Failed to connect to server '%s'.", server) >>>> + ips = get_local_ipaddresses() >>>> + except CalledProcessError as e: >>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>> >>>> IMO the error message should be more specific, add there something >>>> like >>>> "Unable to get local IP addresses". at least in log.debug() >>>> >>>> 2) >>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>> >>>> .replace() is not needed >>>> >>>> 3) >>>> + if len(ips) == 0: >>>> >>>> if not ips: >>>> >>>> is more pythonic by PEP8 >>>> >>>> >>> Thanks for catching these. Updated patch attached. >>> >> merciful NACK >> >> Thank you for the patch, unfortunately I hit one issue which needs to be >> resolved. >> >> If "sync PTR" is activated in zone settings, and reverse zone doesn't >> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >> Error message, 'DNS update failed'. In fact, all A/AAAA records was >> succesfully updated, only PTR records failed. >> >> Bind log: >> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >> 'vm-101.example.com' AAAA >> >> named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >> 'vm-101.example.com.' refused: unable to find active reverse zone for IP >> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >> >> With IPv6 we have several addresses from different reverse zones and >> this situation may happen often. >> I suggest following: >> 1) Print list of addresses which will be updated. (Now if update fails, >> user needs to read log, which addresses installer tried to update) >> 2) Split nsupdates per A/AAAA record. >> 3a) If failed, check with DNS query if A/AAAA and PTR record are there >> and print proper error message >> 3b) Just print A/AAAA (or PTR) record may not be updated for particular >> IP address. >> >> Any other suggestions are welcome. >> > > After long discussion with DNS and UX guru I've implemented it this way: > 1. Call nsupdate only once with all updates. > 2. Verify that the expected records are resolvable. > 3. If no print list of missing A/AAAA, list of missing PTR records and > list to mismatched PTR record. > > As this is running inside client we can't much more and it's up to user > to check what's rotten in his DNS setup. > > Updated patch attached. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > One more change to behave well in -crazy- exotic environments that resolves more PTR records for single IP. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0035-4-client-Update-DNS-with-all-available-local-IP-addres.patch Type: text/x-patch Size: 8256 bytes Desc: not available URL: From mbasti at redhat.com Thu Jan 15 14:39:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Jan 2015 15:39:47 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54B7C9A8.8070309@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> <54B7C781.5090007@redhat.com> <54B7C9A8.8070309@redhat.com> Message-ID: <54B7D133.9020400@redhat.com> On 15/01/15 15:07, Jan Cholasta wrote: > Dne 15.1.2015 v 14:58 Martin Basti napsal(a): >> On 15/01/15 14:25, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >>>> On 15/01/15 13:17, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4722 >>>>> >>>>> Patch attached. >>>>> >>>> Fast fix. >>>> >>>> Updated patch attached. >>> >>> 1) Forward zone commands are not fixed. >> FWzones are new and always normalized to absolute name in ldap > > Would you bet your money on that? Better be safe than sorry, > especially when it's just a matter of moving the code around (right?) > >>> >>> 2) It seems that the primary key returned by -mod, -del and -show >>> (.result.value) is made absolute somewhere else in the code. Would it >>> be possible to do it in one place? >> IMO it is not possible. >> >> Value is generated from key, and key is normalized to absolute zone >> before calling execute. >> >> LDAPUpdate: >> ... >> if self.obj.primary_key: >> pkey = keys[-1] >> else: >> pkey = None >> >> return dict(result=entry_attrs, value=pkey_to_value(pkey, >> options)) >> >> The idnsname attribute is just taken from LDAP without any normalization > > Right. > >> >> >>> >>> 3) Attribute values returned from LDAP are never None, so the if >>> should be "if 'idnsname' in entry_attrs:". >> Ok I will revert the change I made. >>> >>> 4) If idnsname always has only single value, use >>> "entry_attrs.single_value['idnsname'] = >>> entry_attrs.single_value['idnsname'].make_absolute()" >> Thanks >>> >>> Honza >>> >> >> Updated patch attached. >> > > Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0184.4-Always-return-absolute-idnsname-in-dnszone-commands.patch Type: text/x-patch Size: 3120 bytes Desc: not available URL: From jcholast at redhat.com Thu Jan 15 15:07:02 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Jan 2015 16:07:02 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54B7D133.9020400@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> <54B7C781.5090007@redhat.com> <54B7C9A8.8070309@redhat.com> <54B7D133.9020400@redhat.com> Message-ID: <54B7D796.70803@redhat.com> Dne 15.1.2015 v 15:39 Martin Basti napsal(a): > On 15/01/15 15:07, Jan Cholasta wrote: >> Dne 15.1.2015 v 14:58 Martin Basti napsal(a): >>> On 15/01/15 14:25, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >>>>> On 15/01/15 13:17, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4722 >>>>>> >>>>>> Patch attached. >>>>>> >>>>> Fast fix. >>>>> >>>>> Updated patch attached. >>>> >>>> 1) Forward zone commands are not fixed. >>> FWzones are new and always normalized to absolute name in ldap >> >> Would you bet your money on that? Better be safe than sorry, >> especially when it's just a matter of moving the code around (right?) >> >>>> >>>> 2) It seems that the primary key returned by -mod, -del and -show >>>> (.result.value) is made absolute somewhere else in the code. Would it >>>> be possible to do it in one place? >>> IMO it is not possible. >>> >>> Value is generated from key, and key is normalized to absolute zone >>> before calling execute. >>> >>> LDAPUpdate: >>> ... >>> if self.obj.primary_key: >>> pkey = keys[-1] >>> else: >>> pkey = None >>> >>> return dict(result=entry_attrs, value=pkey_to_value(pkey, >>> options)) >>> >>> The idnsname attribute is just taken from LDAP without any normalization >> >> Right. >> >>> >>> >>>> >>>> 3) Attribute values returned from LDAP are never None, so the if >>>> should be "if 'idnsname' in entry_attrs:". >>> Ok I will revert the change I made. >>>> >>>> 4) If idnsname always has only single value, use >>>> "entry_attrs.single_value['idnsname'] = >>>> entry_attrs.single_value['idnsname'].make_absolute()" >>> Thanks >>>> >>>> Honza >>>> >>> >>> Updated patch attached. >>> >> >> > Updated patch attached. > Thanks. Is there a reason why you put the _make_zone_absolute calls in dnszone_* and dnsforwardzone_* instead of DNSZoneBase_*? -- Jan Cholasta From dkupka at redhat.com Thu Jan 15 16:13:54 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 15 Jan 2015 17:13:54 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54B7CD0B.7080008@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> Message-ID: <54B7E742.4060602@redhat.com> On 01/15/2015 03:22 PM, David Kupka wrote: > On 01/15/2015 12:43 PM, David Kupka wrote: >> On 01/12/2015 06:34 PM, Martin Basti wrote: >>> On 09/01/15 14:43, David Kupka wrote: >>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>> >>>>> Thank you for patch: >>>>> >>>>> 1) >>>>> - root_logger.error("Cannot update DNS records! " >>>>> - "Failed to connect to server '%s'.", >>>>> server) >>>>> + ips = get_local_ipaddresses() >>>>> + except CalledProcessError as e: >>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>> >>>>> IMO the error message should be more specific, add there something >>>>> like >>>>> "Unable to get local IP addresses". at least in log.debug() >>>>> >>>>> 2) >>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>> >>>>> .replace() is not needed >>>>> >>>>> 3) >>>>> + if len(ips) == 0: >>>>> >>>>> if not ips: >>>>> >>>>> is more pythonic by PEP8 >>>>> >>>>> >>>> Thanks for catching these. Updated patch attached. >>>> >>> merciful NACK >>> >>> Thank you for the patch, unfortunately I hit one issue which needs to be >>> resolved. >>> >>> If "sync PTR" is activated in zone settings, and reverse zone doesn't >>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>> Error message, 'DNS update failed'. In fact, all A/AAAA records was >>> succesfully updated, only PTR records failed. >>> >>> Bind log: >>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>> 'vm-101.example.com' AAAA >>> >>> named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >>> 'vm-101.example.com.' refused: unable to find active reverse zone for IP >>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>> >>> With IPv6 we have several addresses from different reverse zones and >>> this situation may happen often. >>> I suggest following: >>> 1) Print list of addresses which will be updated. (Now if update fails, >>> user needs to read log, which addresses installer tried to update) >>> 2) Split nsupdates per A/AAAA record. >>> 3a) If failed, check with DNS query if A/AAAA and PTR record are there >>> and print proper error message >>> 3b) Just print A/AAAA (or PTR) record may not be updated for particular >>> IP address. >>> >>> Any other suggestions are welcome. >>> >> >> After long discussion with DNS and UX guru I've implemented it this way: >> 1. Call nsupdate only once with all updates. >> 2. Verify that the expected records are resolvable. >> 3. If no print list of missing A/AAAA, list of missing PTR records and >> list to mismatched PTR record. >> >> As this is running inside client we can't much more and it's up to user >> to check what's rotten in his DNS setup. >> >> Updated patch attached. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > > One more change to behave well in -crazy- exotic environments that > resolves more PTR records for single IP. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Yet another change to make language nerds and our UX guru happy :-) -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0035-5-client-Update-DNS-with-all-available-local-IP-addres.patch Type: text/x-patch Size: 8249 bytes Desc: not available URL: From mbasti at redhat.com Thu Jan 15 19:24:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Jan 2015 20:24:01 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54B7E742.4060602@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> Message-ID: <54B813D1.5090205@redhat.com> On 15/01/15 17:13, David Kupka wrote: > On 01/15/2015 03:22 PM, David Kupka wrote: >> On 01/15/2015 12:43 PM, David Kupka wrote: >>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>> On 09/01/15 14:43, David Kupka wrote: >>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>> >>>>>> Thank you for patch: >>>>>> >>>>>> 1) >>>>>> - root_logger.error("Cannot update DNS records! " >>>>>> - "Failed to connect to server '%s'.", >>>>>> server) >>>>>> + ips = get_local_ipaddresses() >>>>>> + except CalledProcessError as e: >>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>> >>>>>> IMO the error message should be more specific, add there something >>>>>> like >>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>> >>>>>> 2) >>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>> >>>>>> .replace() is not needed >>>>>> >>>>>> 3) >>>>>> + if len(ips) == 0: >>>>>> >>>>>> if not ips: >>>>>> >>>>>> is more pythonic by PEP8 >>>>>> >>>>>> >>>>> Thanks for catching these. Updated patch attached. >>>>> >>>> merciful NACK >>>> >>>> Thank you for the patch, unfortunately I hit one issue which needs >>>> to be >>>> resolved. >>>> >>>> If "sync PTR" is activated in zone settings, and reverse zone doesn't >>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>>> Error message, 'DNS update failed'. In fact, all A/AAAA records was >>>> succesfully updated, only PTR records failed. >>>> >>>> Bind log: >>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>>> 'vm-101.example.com' AAAA >>>> >>>> named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>> for IP >>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>> >>>> With IPv6 we have several addresses from different reverse zones and >>>> this situation may happen often. >>>> I suggest following: >>>> 1) Print list of addresses which will be updated. (Now if update >>>> fails, >>>> user needs to read log, which addresses installer tried to update) >>>> 2) Split nsupdates per A/AAAA record. >>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are there >>>> and print proper error message >>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>> particular >>>> IP address. >>>> >>>> Any other suggestions are welcome. >>>> >>> >>> After long discussion with DNS and UX guru I've implemented it this >>> way: >>> 1. Call nsupdate only once with all updates. >>> 2. Verify that the expected records are resolvable. >>> 3. If no print list of missing A/AAAA, list of missing PTR records and >>> list to mismatched PTR record. >>> >>> As this is running inside client we can't much more and it's up to user >>> to check what's rotten in his DNS setup. >>> >>> Updated patch attached. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> >> One more change to behave well in -crazy- exotic environments that >> resolves more PTR records for single IP. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Yet another change to make language nerds and our UX guru happy :-) Sorry, but NACK. 1) BIND/dyndb-ldap bug? (if sync_ptr is enabled) + try: + answers = dns.resolver.query(fqdn, record_type) + except dns.resolver.NoAnswer: + if record_type == dns.rdatatype.A: + root_logger.debug('No A record for %s' % fqdn) + elif record_type == dns.rdatatype.AAAA: + root_logger.debug('No AAAA record for %s' % fqdn) + except dns.exception.DNSException as e: + root_logger.debug('DNS resolver error: ' % e) + else: + for rdata in answers: + try: + missing_ips.remove(rdata.address) + except ValueError: + extra_ips.append(rdata.address) This somehow doesn't work, for missing A/AAAA records (4 A/AAAA records expected) $host `hostname` vm-024.example.com has address 10.16.78.24 vm-024.example.com has IPv6 address fed0:babe:baab:0:21a:4aff:fe10:4e37 But I get *no warning*. == Why == Probably bug in BIND, all AAAA/A records *exists for several seconds*, then bind remove all A/AAAA records without PTR record. (Needs more investigation, maybe it is dependent on bind version, in previous testing, the A/AAAA records stay untouched ) This it the older journal from the *same machine* with same packages, where record without PTR haven't been deleted after few seconds EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at 'vm-101.example.com' A EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at 'vm-101.example.com' AAAA EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at 'vm-101.example.com' A EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at 'vm-101.example.com' AAAA vm-101.example.com.' refused: unable to find active reverse zone for IP address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found EXAMPLE.COM: updating zone 'idm.example.com/IN': adding an RR at 'vm-101.example.com' AAAA vm-101.example.com.' refused: unable to find active reverse zone for IP address 'fed0:babe:baab:0:21a:4aff:fe10:4eaa': not found EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at 'vm-101.example.com' AAAA vm-101.example.com.' refused: unable to find active reverse zone for IP address 'fec0:0:a10:4c00:21a:4aff:fe10:4eaa': not found * There is no additional lines related with records above* Current journal continues with removing records. The only one change it the new script is checking status of records with DNS query. IMO expected behavior is, the A/AAAA records should stay untouched. We can't test if records are there with this BIND behavior. bind-9.9.6-6.P1.fc21.x86_64 bind-dyndb-ldap-6.1-1.fc21.x86_64 2) You should also catch NXDOMAIN - the query name does not exist exception instead of NoAnswer, to have proper debug results. NoAnswer means that the resolver doesnt respond. Can you also print to debug log, which addresses you test? 3) + except dns.exception.DNSException as e: + root_logger.debug('DNS resolver error: ' % e) This will not work, dns python exceptions doesn't contain any text Log: 2015-01-15T17:42:44Z DEBUG DNS resolver error: 2015-01-15T17:42:46Z DEBUG DNS resolver error: 2015-01-15T17:42:46Z DEBUG DNS resolver error: -- Martin Basti From mbasti at redhat.com Thu Jan 15 19:38:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Jan 2015 20:38:22 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54B813D1.5090205@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <54B813D1.5090205@redhat.com> Message-ID: <54B8172E.5080208@redhat.com> On 15/01/15 20:24, Martin Basti wrote: > On 15/01/15 17:13, David Kupka wrote: >> On 01/15/2015 03:22 PM, David Kupka wrote: >>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>> >>>>>>> Thank you for patch: >>>>>>> >>>>>>> 1) >>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>> - "Failed to connect to server '%s'.", >>>>>>> server) >>>>>>> + ips = get_local_ipaddresses() >>>>>>> + except CalledProcessError as e: >>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>> >>>>>>> IMO the error message should be more specific, add there something >>>>>>> like >>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>> >>>>>>> 2) >>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>> >>>>>>> .replace() is not needed >>>>>>> >>>>>>> 3) >>>>>>> + if len(ips) == 0: >>>>>>> >>>>>>> if not ips: >>>>>>> >>>>>>> is more pythonic by PEP8 >>>>>>> >>>>>>> >>>>>> Thanks for catching these. Updated patch attached. >>>>>> >>>>> merciful NACK >>>>> >>>>> Thank you for the patch, unfortunately I hit one issue which needs >>>>> to be >>>>> resolved. >>>>> >>>>> If "sync PTR" is activated in zone settings, and reverse zone doesn't >>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>>>> Error message, 'DNS update failed'. In fact, all A/AAAA records was >>>>> succesfully updated, only PTR records failed. >>>>> >>>>> Bind log: >>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>>>> 'vm-101.example.com' AAAA >>>>> >>>>> named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>> for IP >>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>> >>>>> With IPv6 we have several addresses from different reverse zones and >>>>> this situation may happen often. >>>>> I suggest following: >>>>> 1) Print list of addresses which will be updated. (Now if update >>>>> fails, >>>>> user needs to read log, which addresses installer tried to update) >>>>> 2) Split nsupdates per A/AAAA record. >>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>> there >>>>> and print proper error message >>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>> particular >>>>> IP address. >>>>> >>>>> Any other suggestions are welcome. >>>>> >>>> >>>> After long discussion with DNS and UX guru I've implemented it this >>>> way: >>>> 1. Call nsupdate only once with all updates. >>>> 2. Verify that the expected records are resolvable. >>>> 3. If no print list of missing A/AAAA, list of missing PTR records and >>>> list to mismatched PTR record. >>>> >>>> As this is running inside client we can't much more and it's up to >>>> user >>>> to check what's rotten in his DNS setup. >>>> >>>> Updated patch attached. >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>> >>> One more change to behave well in -crazy- exotic environments that >>> resolves more PTR records for single IP. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Yet another change to make language nerds and our UX guru happy :-) > Sorry, but NACK. > > 1) BIND/dyndb-ldap bug? (if sync_ptr is enabled) > + try: > + answers = dns.resolver.query(fqdn, record_type) > + except dns.resolver.NoAnswer: > + if record_type == dns.rdatatype.A: > + root_logger.debug('No A record for %s' % fqdn) > + elif record_type == dns.rdatatype.AAAA: > + root_logger.debug('No AAAA record for %s' % fqdn) > + except dns.exception.DNSException as e: > + root_logger.debug('DNS resolver error: ' % e) > + else: > + for rdata in answers: > + try: > + missing_ips.remove(rdata.address) > + except ValueError: > + extra_ips.append(rdata.address) > > This somehow doesn't work, for missing A/AAAA records (4 A/AAAA > records expected) > $host `hostname` > vm-024.example.com has address 10.16.78.24 > vm-024.example.com has IPv6 address fed0:babe:baab:0:21a:4aff:fe10:4e37 > But I get *no warning*. > > == Why == > Probably bug in BIND, all AAAA/A records *exists for several seconds*, > then bind remove all A/AAAA records without PTR record. > (Needs more investigation, maybe it is dependent on bind version, in > previous testing, the A/AAAA records stay untouched ) > > This it the older journal from the *same machine* with same packages, > where record without PTR haven't been deleted after few seconds > EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at > 'vm-101.example.com' A > EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at > 'vm-101.example.com' AAAA > EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at > 'vm-101.example.com' A > EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at > 'vm-101.example.com' AAAA > vm-101.example.com.' refused: unable to find active reverse zone for > IP address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found > EXAMPLE.COM: updating zone 'idm.example.com/IN': adding an RR at > 'vm-101.example.com' AAAA > vm-101.example.com.' refused: unable to find active reverse zone for > IP address 'fed0:babe:baab:0:21a:4aff:fe10:4eaa': not found > EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at > 'vm-101.example.com' AAAA > vm-101.example.com.' refused: unable to find active reverse zone for > IP address 'fec0:0:a10:4c00:21a:4aff:fe10:4eaa': not found > * There is no additional lines related with records above* > > Current journal continues with removing records. > > The only one change it the new script is checking status of records > with DNS query. > > IMO expected behavior is, the A/AAAA records should stay untouched. > > We can't test if records are there with this BIND behavior. > > bind-9.9.6-6.P1.fc21.x86_64 > bind-dyndb-ldap-6.1-1.fc21.x86_64 I investigated deeper, this issue is somehow related with option --enable-dns-update (and enabled PTR SYNC). With this option, only A/AAAA records with PTR are updated. Without this option all A/AAAA records are updated (with or without PTR) Is this caused by SSSD? > > 2) > You should also catch > NXDOMAIN - the query name does not exist > exception instead of NoAnswer, to have proper debug results. NoAnswer > means that the resolver doesnt respond. > > Can you also print to debug log, which addresses you test? > > 3) > + except dns.exception.DNSException as e: > + root_logger.debug('DNS resolver error: ' % e) > > This will not work, dns python exceptions doesn't contain any text > > Log: > 2015-01-15T17:42:44Z DEBUG DNS resolver error: > 2015-01-15T17:42:46Z DEBUG DNS resolver error: > 2015-01-15T17:42:46Z DEBUG DNS resolver error: > -- Martin Basti From mbasti at redhat.com Thu Jan 15 19:42:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 15 Jan 2015 20:42:02 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54B813D1.5090205@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <54B813D1.5090205@redhat.com> Message-ID: <54B8180A.1050900@redhat.com> On 15/01/15 20:24, Martin Basti wrote: > On 15/01/15 17:13, David Kupka wrote: >> On 01/15/2015 03:22 PM, David Kupka wrote: >>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>> >>>>>>> Thank you for patch: >>>>>>> >>>>>>> 1) >>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>> - "Failed to connect to server '%s'.", >>>>>>> server) >>>>>>> + ips = get_local_ipaddresses() >>>>>>> + except CalledProcessError as e: >>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>> >>>>>>> IMO the error message should be more specific, add there something >>>>>>> like >>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>> >>>>>>> 2) >>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>> >>>>>>> .replace() is not needed >>>>>>> >>>>>>> 3) >>>>>>> + if len(ips) == 0: >>>>>>> >>>>>>> if not ips: >>>>>>> >>>>>>> is more pythonic by PEP8 >>>>>>> >>>>>>> >>>>>> Thanks for catching these. Updated patch attached. >>>>>> >>>>> merciful NACK >>>>> >>>>> Thank you for the patch, unfortunately I hit one issue which needs >>>>> to be >>>>> resolved. >>>>> >>>>> If "sync PTR" is activated in zone settings, and reverse zone doesn't >>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>>>> Error message, 'DNS update failed'. In fact, all A/AAAA records was >>>>> succesfully updated, only PTR records failed. >>>>> >>>>> Bind log: >>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>>>> 'vm-101.example.com' AAAA >>>>> >>>>> named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>> for IP >>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>> >>>>> With IPv6 we have several addresses from different reverse zones and >>>>> this situation may happen often. >>>>> I suggest following: >>>>> 1) Print list of addresses which will be updated. (Now if update >>>>> fails, >>>>> user needs to read log, which addresses installer tried to update) >>>>> 2) Split nsupdates per A/AAAA record. >>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>> there >>>>> and print proper error message >>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>> particular >>>>> IP address. >>>>> >>>>> Any other suggestions are welcome. >>>>> >>>> >>>> After long discussion with DNS and UX guru I've implemented it this >>>> way: >>>> 1. Call nsupdate only once with all updates. >>>> 2. Verify that the expected records are resolvable. >>>> 3. If no print list of missing A/AAAA, list of missing PTR records and >>>> list to mismatched PTR record. >>>> >>>> As this is running inside client we can't much more and it's up to >>>> user >>>> to check what's rotten in his DNS setup. >>>> >>>> Updated patch attached. >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>> >>> One more change to behave well in -crazy- exotic environments that >>> resolves more PTR records for single IP. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Yet another change to make language nerds and our UX guru happy :-) > Sorry, but NACK. > > 1) BIND/dyndb-ldap bug? (if sync_ptr is enabled) > + try: > + answers = dns.resolver.query(fqdn, record_type) > + except dns.resolver.NoAnswer: > + if record_type == dns.rdatatype.A: > + root_logger.debug('No A record for %s' % fqdn) > + elif record_type == dns.rdatatype.AAAA: > + root_logger.debug('No AAAA record for %s' % fqdn) > + except dns.exception.DNSException as e: > + root_logger.debug('DNS resolver error: ' % e) > + else: > + for rdata in answers: > + try: > + missing_ips.remove(rdata.address) > + except ValueError: > + extra_ips.append(rdata.address) > > This somehow doesn't work, for missing A/AAAA records (4 A/AAAA > records expected) > $host `hostname` > vm-024.example.com has address 10.16.78.24 > vm-024.example.com has IPv6 address fed0:babe:baab:0:21a:4aff:fe10:4e37 > But I get *no warning*. > > == Why == > Probably bug in BIND, all AAAA/A records *exists for several seconds*, > then bind remove all A/AAAA records without PTR record. > (Needs more investigation, maybe it is dependent on bind version, in > previous testing, the A/AAAA records stay untouched ) > > This it the older journal from the *same machine* with same packages, > where record without PTR haven't been deleted after few seconds > EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at > 'vm-101.example.com' A > EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at > 'vm-101.example.com' AAAA > EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at > 'vm-101.example.com' A > EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at > 'vm-101.example.com' AAAA > vm-101.example.com.' refused: unable to find active reverse zone for > IP address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found > EXAMPLE.COM: updating zone 'idm.example.com/IN': adding an RR at > 'vm-101.example.com' AAAA > vm-101.example.com.' refused: unable to find active reverse zone for > IP address 'fed0:babe:baab:0:21a:4aff:fe10:4eaa': not found > EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at > 'vm-101.example.com' AAAA > vm-101.example.com.' refused: unable to find active reverse zone for > IP address 'fec0:0:a10:4c00:21a:4aff:fe10:4eaa': not found > * There is no additional lines related with records above* > > Current journal continues with removing records. > > The only one change it the new script is checking status of records > with DNS query. > > IMO expected behavior is, the A/AAAA records should stay untouched. > > We can't test if records are there with this BIND behavior. > > bind-9.9.6-6.P1.fc21.x86_64 > bind-dyndb-ldap-6.1-1.fc21.x86_64 > > 2) > You should also catch > NXDOMAIN - the query name does not exist > exception instead of NoAnswer, to have proper debug results. NoAnswer > means that the resolver doesnt respond. > > Can you also print to debug log, which addresses you test? > > 3) > + except dns.exception.DNSException as e: > + root_logger.debug('DNS resolver error: ' % e) > > This will not work, dns python exceptions doesn't contain any text > > Log: > 2015-01-15T17:42:44Z DEBUG DNS resolver error: > 2015-01-15T17:42:46Z DEBUG DNS resolver error: > 2015-01-15T17:42:46Z DEBUG DNS resolver error: > Sorry I forgot: 4) Traceback + except dns.exception.DNSException as e: + root_logger.debug('DNS resolver error: ' % e) File "/usr/sbin/ipa-client-install", line 1614, in verify_dns_update root_logger.debug('DNS resolver error: ' % e) TypeError: not all arguments converted during string formatting -- Martin Basti From lslebodn at redhat.com Thu Jan 15 19:49:39 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 15 Jan 2015 20:49:39 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <54B8172E.5080208@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <54B813D1.5090205@redhat.com> <54B8172E.5080208@redhat.com> Message-ID: <20150115194938.GA29191@mail.corp.redhat.com> On (15/01/15 20:38), Martin Basti wrote: >On 15/01/15 20:24, Martin Basti wrote: >>On 15/01/15 17:13, David Kupka wrote: >>>On 01/15/2015 03:22 PM, David Kupka wrote: >>>>On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>On 09/01/15 14:43, David Kupka wrote: >>>>>>>On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>> >>>>>>>>Thank you for patch: >>>>>>>> >>>>>>>>1) >>>>>>>>- root_logger.error("Cannot update DNS records! " >>>>>>>>- "Failed to connect to server '%s'.", >>>>>>>>server) >>>>>>>>+ ips = get_local_ipaddresses() >>>>>>>>+ except CalledProcessError as e: >>>>>>>>+ root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>> >>>>>>>>IMO the error message should be more specific, add there something >>>>>>>>like >>>>>>>>"Unable to get local IP addresses". at least in log.debug() >>>>>>>> >>>>>>>>2) >>>>>>>>+ lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>> >>>>>>>>.replace() is not needed >>>>>>>> >>>>>>>>3) >>>>>>>>+ if len(ips) == 0: >>>>>>>> >>>>>>>>if not ips: >>>>>>>> >>>>>>>>is more pythonic by PEP8 >>>>>>>> >>>>>>>> >>>>>>>Thanks for catching these. Updated patch attached. >>>>>>> >>>>>>merciful NACK >>>>>> >>>>>>Thank you for the patch, unfortunately I hit one issue which needs >>>>>>to be >>>>>>resolved. >>>>>> >>>>>>If "sync PTR" is activated in zone settings, and reverse zone doesn't >>>>>>exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>>>>>Error message, 'DNS update failed'. In fact, all A/AAAA records was >>>>>>succesfully updated, only PTR records failed. >>>>>> >>>>>>Bind log: >>>>>>named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>>>>>'vm-101.example.com' AAAA >>>>>> >>>>>>named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >>>>>>'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>for IP >>>>>>address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>> >>>>>>With IPv6 we have several addresses from different reverse zones and >>>>>>this situation may happen often. >>>>>>I suggest following: >>>>>>1) Print list of addresses which will be updated. (Now if update >>>>>>fails, >>>>>>user needs to read log, which addresses installer tried to update) >>>>>>2) Split nsupdates per A/AAAA record. >>>>>>3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>there >>>>>>and print proper error message >>>>>>3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>particular >>>>>>IP address. >>>>>> >>>>>>Any other suggestions are welcome. >>>>>> >>>>> >>>>>After long discussion with DNS and UX guru I've implemented it this >>>>>way: >>>>>1. Call nsupdate only once with all updates. >>>>>2. Verify that the expected records are resolvable. >>>>>3. If no print list of missing A/AAAA, list of missing PTR records and >>>>>list to mismatched PTR record. >>>>> >>>>>As this is running inside client we can't much more and it's up to >>>>>user >>>>>to check what's rotten in his DNS setup. >>>>> >>>>>Updated patch attached. >>>>> >>>>> >>>>>_______________________________________________ >>>>>Freeipa-devel mailing list >>>>>Freeipa-devel at redhat.com >>>>>https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> >>>>One more change to behave well in -crazy- exotic environments that >>>>resolves more PTR records for single IP. >>>> >>>> >>>> >>>>_______________________________________________ >>>>Freeipa-devel mailing list >>>>Freeipa-devel at redhat.com >>>>https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>>Yet another change to make language nerds and our UX guru happy :-) >>Sorry, but NACK. >> >>1) BIND/dyndb-ldap bug? (if sync_ptr is enabled) >>+ try: >>+ answers = dns.resolver.query(fqdn, record_type) >>+ except dns.resolver.NoAnswer: >>+ if record_type == dns.rdatatype.A: >>+ root_logger.debug('No A record for %s' % fqdn) >>+ elif record_type == dns.rdatatype.AAAA: >>+ root_logger.debug('No AAAA record for %s' % fqdn) >>+ except dns.exception.DNSException as e: >>+ root_logger.debug('DNS resolver error: ' % e) >>+ else: >>+ for rdata in answers: >>+ try: >>+ missing_ips.remove(rdata.address) >>+ except ValueError: >>+ extra_ips.append(rdata.address) >> >>This somehow doesn't work, for missing A/AAAA records (4 A/AAAA records >>expected) >>$host `hostname` >>vm-024.example.com has address 10.16.78.24 >>vm-024.example.com has IPv6 address fed0:babe:baab:0:21a:4aff:fe10:4e37 >>But I get *no warning*. >> >>== Why == >>Probably bug in BIND, all AAAA/A records *exists for several seconds*, then >>bind remove all A/AAAA records without PTR record. >>(Needs more investigation, maybe it is dependent on bind version, in >>previous testing, the A/AAAA records stay untouched ) >> >>This it the older journal from the *same machine* with same packages, where >>record without PTR haven't been deleted after few seconds >>EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at >>'vm-101.example.com' A >>EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at >>'vm-101.example.com' AAAA >>EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at >>'vm-101.example.com' A >>EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at >>'vm-101.example.com' AAAA >>vm-101.example.com.' refused: unable to find active reverse zone for IP >>address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>EXAMPLE.COM: updating zone 'idm.example.com/IN': adding an RR at >>'vm-101.example.com' AAAA >>vm-101.example.com.' refused: unable to find active reverse zone for IP >>address 'fed0:babe:baab:0:21a:4aff:fe10:4eaa': not found >>EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at >>'vm-101.example.com' AAAA >>vm-101.example.com.' refused: unable to find active reverse zone for IP >>address 'fec0:0:a10:4c00:21a:4aff:fe10:4eaa': not found >>* There is no additional lines related with records above* >> >>Current journal continues with removing records. >> >>The only one change it the new script is checking status of records with >>DNS query. >> >>IMO expected behavior is, the A/AAAA records should stay untouched. >> >>We can't test if records are there with this BIND behavior. >> >>bind-9.9.6-6.P1.fc21.x86_64 >>bind-dyndb-ldap-6.1-1.fc21.x86_64 > >I investigated deeper, this issue is somehow related with option >--enable-dns-update (and enabled PTR SYNC). >With this option, only A/AAAA records with PTR are updated. >Without this option all A/AAAA records are updated (with or without PTR) > >Is this caused by SSSD? I have no idea what the argument "--enable-dns-update" does. I would recomment to compare generated sssd.conf. There are 6 dynamic DNS related options in sssd. sh$ man sssd-ipa | grep "dyndns_" | grep "(" dyndns_update (boolean) dyndns_ttl (integer) dyndns_iface (string) dyndns_refresh_interval (integer) dyndns_update_ptr (bool) dyndns_force_tcp (bool) You can find default values in sssd-ipa man page. HTH LS From abokovoy at redhat.com Fri Jan 16 08:37:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 16 Jan 2015 10:37:36 +0200 Subject: [Freeipa-devel] [PATCH] 0173 Fix ipa-cldap plugin to follow Samba Netlogon response Message-ID: <20150116083736.GE4383@redhat.com> Hi, attached patch fixes https://fedorahosted.org/freeipa/ticket/4827 It is worth noting that MS-ADTS spec is wrong on this, I'm going to get Microsoft to fix the spec as Windows Server 2012 responds in the same way both on LDAP ping and mailslot ping while documentation insists on them being different. Thanks to Stephan Metzemacher (Samba Team) who noticed we are producing wrong output here. Details are in the patch and in the ticket. -- / Alexander Bokovoy -------------- next part -------------- From bc0a15e26b7a19e772453e6de831822fe9cbb40d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 15 Jan 2015 13:11:01 +0200 Subject: [PATCH 2/3] ipa-cldap: support NETLOGON_NT_VERSION_5EX_WITH_IP properly According to MS-ADTS 6.3.3.2, "Domain Controller Response to an LDAP Ping", if NETLOGON_NT_VERSION_5EX_WITH_IP is requested in NtVer, we should fill the socket address of the server and set the NtVer of the response accordingly. The behavior is a bit unclear from 6.3.3.2 but Samba expects LDAP ping to behave the same way as a mailslot ping, described in 6.3.5, where socket address of the server is included only if _WITH_IP variant was requested in NtVer. If NtVer only contains NETLOGON_NT_VERSION_5EX (without _WITH_IP bit), socket address should not be filled in. Additionally, this means we should use special variant of ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX helper named ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX_with_flags to properly handle optional existence of the socket address in the response. https://fedorahosted.org/freeipa/ticket/4827 --- .../ipa-cldap/ipa_cldap_netlogon.c | 24 ++++++++++++---------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c index 1d16de7..2f5b949 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c @@ -153,9 +153,6 @@ char *make_netbios_name(TALLOC_CTX *mem_ctx, const char *s) return nb_name; } -#define NETLOGON_SAM_LOGON_RESPONSE_EX_pusher \ - (ndr_push_flags_fn_t)ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX - static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, char *guid, char *sid, char *name, uint32_t ntver, struct berval *reply) @@ -164,13 +161,14 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, enum ndr_err_code ndr_err; DATA_BLOB blob; int ret; + ndr_push_flags_fn_t pusher = (ndr_push_flags_fn_t)ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX_with_flags; nlr = talloc_zero(NULL, struct NETLOGON_SAM_LOGON_RESPONSE_EX); if (!nlr) { return ENOMEM; } - if (!(ntver & NETLOGON_NT_VERSION_5EX)) { + if (!(ntver & (NETLOGON_NT_VERSION_5EX|NETLOGON_NT_VERSION_5EX_WITH_IP))) { ret = EINVAL; goto done; } @@ -197,17 +195,21 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, nlr->server_site = "Default-First-Site-Name"; nlr->client_site = "Default-First-Site-Name"; /* nlr->sockaddr_size (filled in by ndr_push) */ - nlr->sockaddr.sockaddr_family = 2; - nlr->sockaddr.pdc_ip = "127.0.0.1"; - nlr->sockaddr.remaining.length = 8; - nlr->sockaddr.remaining.data = talloc_zero_size(nlr, 8); - /* nlr->next_closest_site */ + nlr->nt_version = NETLOGON_NT_VERSION_5EX|NETLOGON_NT_VERSION_1; + if (ntver & NETLOGON_NT_VERSION_5EX_WITH_IP) { + nlr->nt_version |= NETLOGON_NT_VERSION_5EX_WITH_IP; + nlr->sockaddr.sockaddr_family = 2; + nlr->sockaddr.pdc_ip = "127.0.0.1"; + nlr->sockaddr.remaining.length = 8; + nlr->sockaddr.remaining.data = talloc_zero_size(nlr, 8); + } + + /* nlr->next_closest_site */ nlr->lmnt_token = 0xFFFF; nlr->lm20_token = 0xFFFF; - ndr_err = ndr_push_struct_blob(&blob, nlr, nlr, - NETLOGON_SAM_LOGON_RESPONSE_EX_pusher); + ndr_err = ndr_push_struct_blob(&blob, nlr, nlr, pusher); if (!NDR_ERR_CODE_IS_SUCCESS(ndr_err)) { ret = EFAULT; goto done; -- 2.1.0 From simo at redhat.com Fri Jan 16 15:29:33 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 16 Jan 2015 10:29:33 -0500 Subject: [Freeipa-devel] [PATCH] 0173 Fix ipa-cldap plugin to follow Samba Netlogon response In-Reply-To: <20150116083736.GE4383@redhat.com> References: <20150116083736.GE4383@redhat.com> Message-ID: <20150116102933.5c746f7a@willson.usersys.redhat.com> On Fri, 16 Jan 2015 10:37:36 +0200 Alexander Bokovoy wrote: > Hi, > > attached patch fixes https://fedorahosted.org/freeipa/ticket/4827 > > It is worth noting that MS-ADTS spec is wrong on this, I'm going to > get Microsoft to fix the spec as Windows Server 2012 responds in the > same way both on LDAP ping and mailslot ping while documentation > insists on them being different. > > Thanks to Stephan Metzemacher (Samba Team) who noticed we are > producing wrong output here. > > Details are in the patch and in the ticket. > I would prefer to keep the define rather than the new 'pusher' variable, other than that it looks good to me. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Fri Jan 16 15:44:12 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 16 Jan 2015 17:44:12 +0200 Subject: [Freeipa-devel] [PATCH] 0173 Fix ipa-cldap plugin to follow Samba Netlogon response In-Reply-To: <20150116102933.5c746f7a@willson.usersys.redhat.com> References: <20150116083736.GE4383@redhat.com> <20150116102933.5c746f7a@willson.usersys.redhat.com> Message-ID: <20150116154412.GF4383@redhat.com> On Fri, 16 Jan 2015, Simo Sorce wrote: >On Fri, 16 Jan 2015 10:37:36 +0200 >Alexander Bokovoy wrote: > >> Hi, >> >> attached patch fixes https://fedorahosted.org/freeipa/ticket/4827 >> >> It is worth noting that MS-ADTS spec is wrong on this, I'm going to >> get Microsoft to fix the spec as Windows Server 2012 responds in the >> same way both on LDAP ping and mailslot ping while documentation >> insists on them being different. >> >> Thanks to Stephan Metzemacher (Samba Team) who noticed we are >> producing wrong output here. >> >> Details are in the patch and in the ticket. >> > >I would prefer to keep the define rather than the new 'pusher' >variable, other than that it looks good to me. Updated patch attached. -- / Alexander Bokovoy -------------- next part -------------- From f21579f3ce38656e6fb9ffeb1d14c28967d202cf Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 15 Jan 2015 13:11:01 +0200 Subject: [PATCH 2/3] ipa-cldap: support NETLOGON_NT_VERSION_5EX_WITH_IP properly According to MS-ADTS 6.3.3.2, "Domain Controller Response to an LDAP Ping", if NETLOGON_NT_VERSION_5EX_WITH_IP is requested in NtVer, we should fill the socket address of the server and set the NtVer of the response accordingly. The behavior is a bit unclear from 6.3.3.2 but Samba expects LDAP ping to behave the same way as a mailslot ping, described in 6.3.5, where socket address of the server is included only if _WITH_IP variant was requested in NtVer. If NtVer only contains NETLOGON_NT_VERSION_5EX (without _WITH_IP bit), socket address should not be filled in. Additionally, this means we should use special variant of ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX helper named ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX_with_flags to properly handle optional existence of the socket address in the response. https://fedorahosted.org/freeipa/ticket/4827 --- .../ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c index 1d16de7..5863f66 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c @@ -154,7 +154,7 @@ char *make_netbios_name(TALLOC_CTX *mem_ctx, const char *s) } #define NETLOGON_SAM_LOGON_RESPONSE_EX_pusher \ - (ndr_push_flags_fn_t)ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX + (ndr_push_flags_fn_t)ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX_with_flags static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, char *guid, char *sid, char *name, @@ -170,7 +170,7 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, return ENOMEM; } - if (!(ntver & NETLOGON_NT_VERSION_5EX)) { + if (!(ntver & (NETLOGON_NT_VERSION_5EX|NETLOGON_NT_VERSION_5EX_WITH_IP))) { ret = EINVAL; goto done; } @@ -197,12 +197,17 @@ static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, nlr->server_site = "Default-First-Site-Name"; nlr->client_site = "Default-First-Site-Name"; /* nlr->sockaddr_size (filled in by ndr_push) */ - nlr->sockaddr.sockaddr_family = 2; - nlr->sockaddr.pdc_ip = "127.0.0.1"; - nlr->sockaddr.remaining.length = 8; - nlr->sockaddr.remaining.data = talloc_zero_size(nlr, 8); - /* nlr->next_closest_site */ + nlr->nt_version = NETLOGON_NT_VERSION_5EX|NETLOGON_NT_VERSION_1; + if (ntver & NETLOGON_NT_VERSION_5EX_WITH_IP) { + nlr->nt_version |= NETLOGON_NT_VERSION_5EX_WITH_IP; + nlr->sockaddr.sockaddr_family = 2; + nlr->sockaddr.pdc_ip = "127.0.0.1"; + nlr->sockaddr.remaining.length = 8; + nlr->sockaddr.remaining.data = talloc_zero_size(nlr, 8); + } + + /* nlr->next_closest_site */ nlr->lmnt_token = 0xFFFF; nlr->lm20_token = 0xFFFF; -- 2.1.0 From sbose at redhat.com Fri Jan 16 16:06:29 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 16 Jan 2015 17:06:29 +0100 Subject: [Freeipa-devel] [PATCH] 0172 Support Samba PASSDB 0.2.0 aka interface version 24 In-Reply-To: <20150112145533.GP16288@redhat.com> References: <20150112145533.GP16288@redhat.com> Message-ID: <20150116160629.GB7292@p.redhat.com> On Mon, Jan 12, 2015 at 04:55:33PM +0200, Alexander Bokovoy wrote: > Hi, > > Samba project renamed libpdb library we use in ipa-sam module to > libsamba-passdb due to naming clash with some other library popular in > academic circles (details are in https://bugzilla.samba.org/show_bug.cgi?id=10355) > > The change will become visible with Samba 4.2.0 release and is actually > already visible in Rawhide as it packages Samba 4.2 pre-releases. > > Attached fix is introducing support for both Samba <4.2 and 4.2+. > > I've tested that it builds properly against Samba 4.2 in Rawhide and > against Samba 4.1 in Fedora 21, and proper symbols exposed (disassembled > the code in pdb_init_ipasam to see if address of ipasam_id_to_sid is assigned > to the struct member) but I haven't deployed Rawhide to actually test > FreeIPA with trusts yet. > > https://fedorahosted.org/freeipa/ticket/4778 > > -- > / Alexander Bokovoy This patch does not break F21 in my testing and allows building FreeIPA on platforms with samba-4.2, ACK. bye, Sumit From simo at redhat.com Fri Jan 16 17:25:05 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 16 Jan 2015 12:25:05 -0500 Subject: [Freeipa-devel] [PATCH] 0173 Fix ipa-cldap plugin to follow Samba Netlogon response In-Reply-To: <20150116154412.GF4383@redhat.com> References: <20150116083736.GE4383@redhat.com> <20150116102933.5c746f7a@willson.usersys.redhat.com> <20150116154412.GF4383@redhat.com> Message-ID: <20150116122505.662b2a7d@willson.usersys.redhat.com> On Fri, 16 Jan 2015 17:44:12 +0200 Alexander Bokovoy wrote: > On Fri, 16 Jan 2015, Simo Sorce wrote: > >On Fri, 16 Jan 2015 10:37:36 +0200 > >Alexander Bokovoy wrote: > > > >> Hi, > >> > >> attached patch fixes https://fedorahosted.org/freeipa/ticket/4827 > >> > >> It is worth noting that MS-ADTS spec is wrong on this, I'm going to > >> get Microsoft to fix the spec as Windows Server 2012 responds in > >> the same way both on LDAP ping and mailslot ping while > >> documentation insists on them being different. > >> > >> Thanks to Stephan Metzemacher (Samba Team) who noticed we are > >> producing wrong output here. > >> > >> Details are in the patch and in the ticket. > >> > > > >I would prefer to keep the define rather than the new 'pusher' > >variable, other than that it looks good to me. > Updated patch attached. > LGTM! Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Jan 19 09:23:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Jan 2015 10:23:53 +0100 Subject: [Freeipa-devel] [PATCH] 0172 Support Samba PASSDB 0.2.0 aka interface version 24 In-Reply-To: <20150116160629.GB7292@p.redhat.com> References: <20150112145533.GP16288@redhat.com> <20150116160629.GB7292@p.redhat.com> Message-ID: <54BCCD29.3050207@redhat.com> On 01/16/2015 05:06 PM, Sumit Bose wrote: > On Mon, Jan 12, 2015 at 04:55:33PM +0200, Alexander Bokovoy wrote: >> Hi, >> >> Samba project renamed libpdb library we use in ipa-sam module to >> libsamba-passdb due to naming clash with some other library popular in >> academic circles (details are in https://bugzilla.samba.org/show_bug.cgi?id=10355) >> >> The change will become visible with Samba 4.2.0 release and is actually >> already visible in Rawhide as it packages Samba 4.2 pre-releases. >> >> Attached fix is introducing support for both Samba <4.2 and 4.2+. >> >> I've tested that it builds properly against Samba 4.2 in Rawhide and >> against Samba 4.1 in Fedora 21, and proper symbols exposed (disassembled >> the code in pdb_init_ipasam to see if address of ipasam_id_to_sid is assigned >> to the struct member) but I haven't deployed Rawhide to actually test >> FreeIPA with trusts yet. >> >> https://fedorahosted.org/freeipa/ticket/4778 >> >> -- >> / Alexander Bokovoy > > This patch does not break F21 in my testing and allows building FreeIPA > on platforms with samba-4.2, ACK. > > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Thanks to both! Pushed to master: d57efb74bb6ad91b029fffff39ed4e482c41f8ba If the patch is also needed in ipa-4-1 branch, we can backport it there as well. Martin From mkosek at redhat.com Mon Jan 19 09:25:34 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Jan 2015 10:25:34 +0100 Subject: [Freeipa-devel] [PATCH] 0173 Fix ipa-cldap plugin to follow Samba Netlogon response In-Reply-To: <20150116122505.662b2a7d@willson.usersys.redhat.com> References: <20150116083736.GE4383@redhat.com> <20150116102933.5c746f7a@willson.usersys.redhat.com> <20150116154412.GF4383@redhat.com> <20150116122505.662b2a7d@willson.usersys.redhat.com> Message-ID: <54BCCD8E.3050205@redhat.com> On 01/16/2015 06:25 PM, Simo Sorce wrote: > On Fri, 16 Jan 2015 17:44:12 +0200 > Alexander Bokovoy wrote: > >> On Fri, 16 Jan 2015, Simo Sorce wrote: >>> On Fri, 16 Jan 2015 10:37:36 +0200 >>> Alexander Bokovoy wrote: >>> >>>> Hi, >>>> >>>> attached patch fixes https://fedorahosted.org/freeipa/ticket/4827 >>>> >>>> It is worth noting that MS-ADTS spec is wrong on this, I'm going to >>>> get Microsoft to fix the spec as Windows Server 2012 responds in >>>> the same way both on LDAP ping and mailslot ping while >>>> documentation insists on them being different. >>>> >>>> Thanks to Stephan Metzemacher (Samba Team) who noticed we are >>>> producing wrong output here. >>>> >>>> Details are in the patch and in the ticket. >>>> >>> >>> I would prefer to keep the define rather than the new 'pusher' >>> variable, other than that it looks good to me. >> Updated patch attached. >> > > LGTM! Is that an ACK? :-) It Sumit or anyone else confirms it indeed works, we can push... Martin From abokovoy at redhat.com Mon Jan 19 09:31:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 19 Jan 2015 11:31:04 +0200 Subject: [Freeipa-devel] [PATCH] 0172 Support Samba PASSDB 0.2.0 aka interface version 24 In-Reply-To: <54BCCD29.3050207@redhat.com> References: <20150112145533.GP16288@redhat.com> <20150116160629.GB7292@p.redhat.com> <54BCCD29.3050207@redhat.com> Message-ID: <20150119093104.GG4383@redhat.com> On Mon, 19 Jan 2015, Martin Kosek wrote: >On 01/16/2015 05:06 PM, Sumit Bose wrote: >> On Mon, Jan 12, 2015 at 04:55:33PM +0200, Alexander Bokovoy wrote: >>> Hi, >>> >>> Samba project renamed libpdb library we use in ipa-sam module to >>> libsamba-passdb due to naming clash with some other library popular in >>> academic circles (details are in https://bugzilla.samba.org/show_bug.cgi?id=10355) >>> >>> The change will become visible with Samba 4.2.0 release and is actually >>> already visible in Rawhide as it packages Samba 4.2 pre-releases. >>> >>> Attached fix is introducing support for both Samba <4.2 and 4.2+. >>> >>> I've tested that it builds properly against Samba 4.2 in Rawhide and >>> against Samba 4.1 in Fedora 21, and proper symbols exposed (disassembled >>> the code in pdb_init_ipasam to see if address of ipasam_id_to_sid is assigned >>> to the struct member) but I haven't deployed Rawhide to actually test >>> FreeIPA with trusts yet. >>> >>> https://fedorahosted.org/freeipa/ticket/4778 >>> >>> -- >>> / Alexander Bokovoy >> >> This patch does not break F21 in my testing and allows building FreeIPA >> on platforms with samba-4.2, ACK. > >Thanks to both! > >Pushed to master: d57efb74bb6ad91b029fffff39ed4e482c41f8ba > >If the patch is also needed in ipa-4-1 branch, we can backport it there as well. Yes, you can safely add it to 4.1, I've tested that. The patch covers both libraries specifically to allow us to use the same code for Rawhide and older distros. -- / Alexander Bokovoy From mkosek at redhat.com Mon Jan 19 09:32:56 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Jan 2015 10:32:56 +0100 Subject: [Freeipa-devel] [PATCH] 0172 Support Samba PASSDB 0.2.0 aka interface version 24 In-Reply-To: <20150119093104.GG4383@redhat.com> References: <20150112145533.GP16288@redhat.com> <20150116160629.GB7292@p.redhat.com> <54BCCD29.3050207@redhat.com> <20150119093104.GG4383@redhat.com> Message-ID: <54BCCF48.4070502@redhat.com> On 01/19/2015 10:31 AM, Alexander Bokovoy wrote: > On Mon, 19 Jan 2015, Martin Kosek wrote: >> On 01/16/2015 05:06 PM, Sumit Bose wrote: >>> On Mon, Jan 12, 2015 at 04:55:33PM +0200, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> Samba project renamed libpdb library we use in ipa-sam module to >>>> libsamba-passdb due to naming clash with some other library popular in >>>> academic circles (details are in >>>> https://bugzilla.samba.org/show_bug.cgi?id=10355) >>>> >>>> The change will become visible with Samba 4.2.0 release and is actually >>>> already visible in Rawhide as it packages Samba 4.2 pre-releases. >>>> >>>> Attached fix is introducing support for both Samba <4.2 and 4.2+. >>>> >>>> I've tested that it builds properly against Samba 4.2 in Rawhide and >>>> against Samba 4.1 in Fedora 21, and proper symbols exposed (disassembled >>>> the code in pdb_init_ipasam to see if address of ipasam_id_to_sid is assigned >>>> to the struct member) but I haven't deployed Rawhide to actually test >>>> FreeIPA with trusts yet. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4778 >>>> >>>> -- >>>> / Alexander Bokovoy >>> >>> This patch does not break F21 in my testing and allows building FreeIPA >>> on platforms with samba-4.2, ACK. >> >> Thanks to both! >> >> Pushed to master: d57efb74bb6ad91b029fffff39ed4e482c41f8ba >> >> If the patch is also needed in ipa-4-1 branch, we can backport it there as well. > Yes, you can safely add it to 4.1, I've tested that. The patch covers > both libraries specifically to allow us to use the same code for Rawhide > and older distros. > Ok, makes sense. Pushed to ipa-4-1: ecd6896664115c933f2594020feaed6b41f19054 Martin From sbose at redhat.com Mon Jan 19 09:52:57 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 19 Jan 2015 10:52:57 +0100 Subject: [Freeipa-devel] [PATCH] 0173 Fix ipa-cldap plugin to follow Samba Netlogon response In-Reply-To: <54BCCD8E.3050205@redhat.com> References: <20150116083736.GE4383@redhat.com> <20150116102933.5c746f7a@willson.usersys.redhat.com> <20150116154412.GF4383@redhat.com> <20150116122505.662b2a7d@willson.usersys.redhat.com> <54BCCD8E.3050205@redhat.com> Message-ID: <20150119095257.GD7292@p.redhat.com> On Mon, Jan 19, 2015 at 10:25:34AM +0100, Martin Kosek wrote: > On 01/16/2015 06:25 PM, Simo Sorce wrote: > > On Fri, 16 Jan 2015 17:44:12 +0200 > > Alexander Bokovoy wrote: > > > >> On Fri, 16 Jan 2015, Simo Sorce wrote: > >>> On Fri, 16 Jan 2015 10:37:36 +0200 > >>> Alexander Bokovoy wrote: > >>> > >>>> Hi, > >>>> > >>>> attached patch fixes https://fedorahosted.org/freeipa/ticket/4827 > >>>> > >>>> It is worth noting that MS-ADTS spec is wrong on this, I'm going to > >>>> get Microsoft to fix the spec as Windows Server 2012 responds in > >>>> the same way both on LDAP ping and mailslot ping while > >>>> documentation insists on them being different. > >>>> > >>>> Thanks to Stephan Metzemacher (Samba Team) who noticed we are > >>>> producing wrong output here. > >>>> > >>>> Details are in the patch and in the ticket. > >>>> > >>> > >>> I would prefer to keep the define rather than the new 'pusher' > >>> variable, other than that it looks good to me. > >> Updated patch attached. > >> > > > > LGTM! > > Is that an ACK? :-) It Sumit or anyone else confirms it indeed works, we can > push... I thought it is :-) Nevertheless I had this patch in my tree while testing Alexander's other patch and didn't see any issues with AD. So, since Simo like to code and it passes my tests this is now an ACK. bye, Sumit > > Martin From mkosek at redhat.com Mon Jan 19 11:06:47 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Jan 2015 12:06:47 +0100 Subject: [Freeipa-devel] [PATCH] 0173 Fix ipa-cldap plugin to follow Samba Netlogon response In-Reply-To: <20150119095257.GD7292@p.redhat.com> References: <20150116083736.GE4383@redhat.com> <20150116102933.5c746f7a@willson.usersys.redhat.com> <20150116154412.GF4383@redhat.com> <20150116122505.662b2a7d@willson.usersys.redhat.com> <54BCCD8E.3050205@redhat.com> <20150119095257.GD7292@p.redhat.com> Message-ID: <54BCE547.6080400@redhat.com> On 01/19/2015 10:52 AM, Sumit Bose wrote: > On Mon, Jan 19, 2015 at 10:25:34AM +0100, Martin Kosek wrote: >> On 01/16/2015 06:25 PM, Simo Sorce wrote: >>> On Fri, 16 Jan 2015 17:44:12 +0200 >>> Alexander Bokovoy wrote: >>> >>>> On Fri, 16 Jan 2015, Simo Sorce wrote: >>>>> On Fri, 16 Jan 2015 10:37:36 +0200 >>>>> Alexander Bokovoy wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> attached patch fixes https://fedorahosted.org/freeipa/ticket/4827 >>>>>> >>>>>> It is worth noting that MS-ADTS spec is wrong on this, I'm going to >>>>>> get Microsoft to fix the spec as Windows Server 2012 responds in >>>>>> the same way both on LDAP ping and mailslot ping while >>>>>> documentation insists on them being different. >>>>>> >>>>>> Thanks to Stephan Metzemacher (Samba Team) who noticed we are >>>>>> producing wrong output here. >>>>>> >>>>>> Details are in the patch and in the ticket. >>>>>> >>>>> >>>>> I would prefer to keep the define rather than the new 'pusher' >>>>> variable, other than that it looks good to me. >>>> Updated patch attached. >>>> >>> >>> LGTM! >> >> Is that an ACK? :-) It Sumit or anyone else confirms it indeed works, we can >> push... > > I thought it is :-) Nevertheless I had this patch in my tree while > testing Alexander's other patch and didn't see any issues with AD. > > So, since Simo like to code and it passes my tests this is now an ACK. Ok then - pushed to: master: 5672eb14def7b2010f1d08825eec58ff1444073f ipa-4-1: 426759f47fbef2b902afd975c7bcffc178192ace Thanks, Martin From mkosek at redhat.com Mon Jan 19 11:45:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Jan 2015 12:45:42 +0100 Subject: [Freeipa-devel] [PATCH] 491 Replication Administrators cannot remove replication Message-ID: <54BCEE66.8000804@redhat.com> Replication agreement deletion requires read access to DNA range setting. The read access was accidently removed during PermissionV2 refactoring. Add the read ACI back as a special SYSTEM permission. https://fedorahosted.org/freeipa/ticket/4848 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-491-replication-administrators-cannot-remove-replication.patch Type: text/x-patch Size: 1818 bytes Desc: not available URL: From mbasti at redhat.com Mon Jan 19 12:03:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Jan 2015 13:03:12 +0100 Subject: [Freeipa-devel] [PATCH 0185] Use dyndns_update instead of deprecated ipa_dyndns_update in sssd.conf Message-ID: <54BCF280.8010407@redhat.com> ipa_dyndns_update option is deprecated in sssd. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0185-Use-dyndns_update-instead-of-deprecated-sssd-option.patch Type: text/x-patch Size: 1096 bytes Desc: not available URL: From mkosek at redhat.com Mon Jan 19 12:13:12 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Jan 2015 13:13:12 +0100 Subject: [Freeipa-devel] [PATCH 0185] Use dyndns_update instead of deprecated ipa_dyndns_update in sssd.conf In-Reply-To: <54BCF280.8010407@redhat.com> References: <54BCF280.8010407@redhat.com> Message-ID: <54BCF4D8.1060609@redhat.com> On 01/19/2015 01:03 PM, Martin Basti wrote: > ipa_dyndns_update option is deprecated in sssd. > > Patch attached. Can you please create a ticket? It is a non-trivial change. I am also wondering if somebody from SSSD could double check that the dyndns configuration added to sssd.conf by ipa-client-install is indeed sane and recommended. Martin From dkupka at redhat.com Mon Jan 19 12:20:48 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 19 Jan 2015 13:20:48 +0100 Subject: [Freeipa-devel] [PATCH] 488-489 PermissionsV2 related winsync fixes In-Reply-To: <54B6DF2D.8020907@redhat.com> References: <54B552DB.7090309@redhat.com> <20150113155529.60f19e65@willson.usersys.redhat.com> <54B59385.2070206@redhat.com> <54B633A5.2020904@redhat.com> <54B63DB3.9070107@redhat.com> <54B64CE9.7030204@redhat.com> <54B66412.3050607@redhat.com> <20150114093452.14b0c665@willson.usersys.redhat.com> <54B6841E.4040306@redhat.com> <54B69DB7.7030901@redhat.com> <20150114115838.747ff066@willson.usersys.redhat.com> <54B6DF2D.8020907@redhat.com> Message-ID: <54BCF6A0.9030809@redhat.com> On 01/14/2015 10:27 PM, Martin Kosek wrote: > Adding freeipa-devel back. > > On 01/14/2015 05:58 PM, Simo Sorce wrote: >> On Wed, 14 Jan 2015 17:47:51 +0100 >> Martin Kosek wrote: >> >>> -add:aci:'(targetfilter="(objectclass=nsContainer)")(version 3.0; acl >>> "Deny read access to replica configuration"; deny(read, search, >>> compare) userdn = "ldap:///anyone";)' >>> +remove:aci:'(targetfilter="(objectclass=nsContainer)")(version 3.0; >>> acl "Deny read access to replica configuration"; deny(read, search, >>> compare) userdn = "ldap:///anyone";)' >> >> Why this removal ? > > It is in the patch description. This container stores winsync > "replicas". With this deny ACI, admin or anyone else besides Directory > Manager can see the replicas as deny rules take precedence and this one > is scoped for ldap://anyone. > > My thinking was that this container is not too secret anyway, the only > information that user get is name of the winsync'ed AD. > >>> +dn: cn=config >>> +add:aci: '(version 3.0;acl "permission:Add Configuration >>> Sub-Entries";allow (add) groupdn = "ldap:///cn=Add Configuration >>> Sub-Entries,cn=permissions,cn=pbac,$SUFFIX";)' >> >> Doesn't this allow REplication admin to add any object anywhere in >> cn=config ? >> This would be too broad. > > It does. I wanted to narrow it with targetfilter '(targetfilter = > "(cn=changelog5)")' but, it did not work for me, ADD was rejected. Not > sure why though, when I used '(targetfilter = > "(objectclass=extensibleobject)")', it worked fine. > > I fear this is some problem in DS targetfilter evaluation during ADD > operation, CCing Ludwig for reference. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hi! This works for me. If all concerns regarding PermissionV2 and ACIs in general are resolved we can push. -- David Kupka From jhrozek at redhat.com Mon Jan 19 12:24:27 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 19 Jan 2015 13:24:27 +0100 Subject: [Freeipa-devel] [PATCH 0185] Use dyndns_update instead of deprecated ipa_dyndns_update in sssd.conf In-Reply-To: <54BCF4D8.1060609@redhat.com> References: <54BCF280.8010407@redhat.com> <54BCF4D8.1060609@redhat.com> Message-ID: <20150119122427.GC24278@hendrix.lan> On Mon, Jan 19, 2015 at 01:13:12PM +0100, Martin Kosek wrote: > On 01/19/2015 01:03 PM, Martin Basti wrote: > > ipa_dyndns_update option is deprecated in sssd. > > > > Patch attached. > > Can you please create a ticket? It is a non-trivial change. > > I am also wondering if somebody from SSSD could double check that the dyndns > configuration added to sssd.conf by ipa-client-install is indeed sane and > recommended. LGTM. From mbasti at redhat.com Mon Jan 19 13:08:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Jan 2015 14:08:25 +0100 Subject: [Freeipa-devel] [PATCH 0185] Use dyndns_update instead of deprecated ipa_dyndns_update in sssd.conf In-Reply-To: <20150119122427.GC24278@hendrix.lan> References: <54BCF280.8010407@redhat.com> <54BCF4D8.1060609@redhat.com> <20150119122427.GC24278@hendrix.lan> Message-ID: <54BD01C9.80503@redhat.com> On 19/01/15 13:24, Jakub Hrozek wrote: > On Mon, Jan 19, 2015 at 01:13:12PM +0100, Martin Kosek wrote: >> On 01/19/2015 01:03 PM, Martin Basti wrote: >>> ipa_dyndns_update option is deprecated in sssd. >>> >>> Patch attached. >> Can you please create a ticket? It is a non-trivial change. >> >> I am also wondering if somebody from SSSD could double check that the dyndns >> configuration added to sssd.conf by ipa-client-install is indeed sane and >> recommended. > LGTM. Ticket: https://fedorahosted.org/freeipa/ticket/4849 Patch with ticket attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0185-Use-dyndns_update-instead-of-deprecated-sssd-option.patch Type: text/x-patch Size: 1142 bytes Desc: not available URL: From mbasti at redhat.com Mon Jan 19 17:19:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Jan 2015 18:19:04 +0100 Subject: [Freeipa-devel] [PATCH] 491 Replication Administrators cannot remove replication In-Reply-To: <54BCEE66.8000804@redhat.com> References: <54BCEE66.8000804@redhat.com> Message-ID: <54BD3C88.1040504@redhat.com> On 19/01/15 12:45, Martin Kosek wrote: > Replication agreement deletion requires read access to DNA range > setting. The read access was accidently removed during PermissionV2 > refactoring. > > Add the read ACI back as a special SYSTEM permission. > > https://fedorahosted.org/freeipa/ticket/4848 > > Works for me. ACK -- Martin Basti From jcholast at redhat.com Tue Jan 20 09:49:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 20 Jan 2015 10:49:06 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54B55C24.1080407@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> <54B55A08.50402@redhat.com> <54B55C24.1080407@redhat.com> Message-ID: <54BE2492.1000608@redhat.com> Dne 13.1.2015 v 18:55 Jan Cholasta napsal(a): > Dne 13.1.2015 v 18:46 David Kupka napsal(a): >> On 01/13/2015 05:55 PM, Jan Cholasta wrote: >>> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>> >>> Modified the fix to create only one service object in stopped_service. >>> >>> Updated patch attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Hi! >> Thanks for the patch. Works for me, ACK. >> > > Thanks, pushed to: > master: 5bf1c9a6f7d734c296c8eb987cfc4f7e2a345130 > ipa-4-1: 065e2bbc9f2260d8c60c55f92a386513727576da > Posting additional patch 393 which is necessary to properly fix this. David, could you take a look please? -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-393-Do-not-assume-certmonger-is-running-in-httpinstance.patch Type: text/x-patch Size: 3576 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 20 11:07:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Jan 2015 12:07:49 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54BE2492.1000608@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> <54B55A08.50402@redhat.com> <54B55C24.1080407@redhat.com> <54BE2492.1000608@redhat.com> Message-ID: <54BE3705.1060101@redhat.com> On 01/20/2015 10:49 AM, Jan Cholasta wrote: > Dne 13.1.2015 v 18:55 Jan Cholasta napsal(a): >> Dne 13.1.2015 v 18:46 David Kupka napsal(a): >>> On 01/13/2015 05:55 PM, Jan Cholasta wrote: >>>> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>> >>>> Modified the fix to create only one service object in stopped_service. >>>> >>>> Updated patch attached. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Hi! >>> Thanks for the patch. Works for me, ACK. >>> >> >> Thanks, pushed to: >> master: 5bf1c9a6f7d734c296c8eb987cfc4f7e2a345130 >> ipa-4-1: 065e2bbc9f2260d8c60c55f92a386513727576da >> > > Posting additional patch 393 which is necessary to properly fix this. > > David, could you take a look please? Just looking at this patch, I am thinking it would be great to have @contextmanager also for "started_service" (we already have stopped_service) and use it (not required for this patch though). Martin From dkupka at redhat.com Tue Jan 20 11:19:14 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 20 Jan 2015 12:19:14 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54BE3705.1060101@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> <54B55A08.50402@redhat.com> <54B55C24.1080407@redhat.com> <54BE2492.1000608@redhat.com> <54BE3705.1060101@redhat.com> Message-ID: <54BE39B2.8000907@redhat.com> On 01/20/2015 12:07 PM, Martin Kosek wrote: > On 01/20/2015 10:49 AM, Jan Cholasta wrote: >> Dne 13.1.2015 v 18:55 Jan Cholasta napsal(a): >>> Dne 13.1.2015 v 18:46 David Kupka napsal(a): >>>> On 01/13/2015 05:55 PM, Jan Cholasta wrote: >>>>> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes >>>>>> . >>>>>> >>>>>> Honza >>>>> >>>>> Modified the fix to create only one service object in stopped_service. >>>>> >>>>> Updated patch attached. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> Hi! >>>> Thanks for the patch. Works for me, ACK. >>>> >>> >>> Thanks, pushed to: >>> master: 5bf1c9a6f7d734c296c8eb987cfc4f7e2a345130 >>> ipa-4-1: 065e2bbc9f2260d8c60c55f92a386513727576da >>> >> >> Posting additional patch 393 which is necessary to properly fix this. >> >> David, could you take a look please? > > Just looking at this patch, I am thinking it would be great to have > @contextmanager also for "started_service" (we already have stopped_service) > and use it (not required for this patch though). It would be handy. And there is an other solution for this specific case. Certmonger could be started with incoming DBus message. This will improve the usability not only with freeipa but also with command-line tools like getcert. I've filled a ticket for certmonger: https://fedorahosted.org/certmonger/ticket/38 > > Martin > -- David Kupka From mkosek at redhat.com Tue Jan 20 11:20:32 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Jan 2015 12:20:32 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54BE39B2.8000907@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> <54B55A08.50402@redhat.com> <54B55C24.1080407@redhat.com> <54BE2492.1000608@redhat.com> <54BE3705.1060101@redhat.com> <54BE39B2.8000907@redhat.com> Message-ID: <54BE3A00.50006@redhat.com> On 01/20/2015 12:19 PM, David Kupka wrote: > On 01/20/2015 12:07 PM, Martin Kosek wrote: >> On 01/20/2015 10:49 AM, Jan Cholasta wrote: >>> Dne 13.1.2015 v 18:55 Jan Cholasta napsal(a): >>>> Dne 13.1.2015 v 18:46 David Kupka napsal(a): >>>>> On 01/13/2015 05:55 PM, Jan Cholasta wrote: >>>>>> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch fixes >>>>>>> . >>>>>>> >>>>>>> Honza >>>>>> >>>>>> Modified the fix to create only one service object in stopped_service. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> Hi! >>>>> Thanks for the patch. Works for me, ACK. >>>>> >>>> >>>> Thanks, pushed to: >>>> master: 5bf1c9a6f7d734c296c8eb987cfc4f7e2a345130 >>>> ipa-4-1: 065e2bbc9f2260d8c60c55f92a386513727576da >>>> >>> >>> Posting additional patch 393 which is necessary to properly fix this. >>> >>> David, could you take a look please? >> >> Just looking at this patch, I am thinking it would be great to have >> @contextmanager also for "started_service" (we already have stopped_service) >> and use it (not required for this patch though). > > It would be handy. And there is an other solution for this specific case. > Certmonger could be started with incoming DBus message. This will improve the > usability not only with freeipa but also with command-line tools like getcert. > I've filled a ticket for certmonger: https://fedorahosted.org/certmonger/ticket/38 Right. But this needs more testing and care. Currently, we need to stabilize and fix a bug in FreeIPA that is also requested from downstream platform. Jan's patch/approach will be good for now. Martin From mbasti at redhat.com Tue Jan 20 11:49:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Jan 2015 12:49:14 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54B7D796.70803@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> <54B7C781.5090007@redhat.com> <54B7C9A8.8070309@redhat.com> <54B7D133.9020400@redhat.com> <54B7D796.70803@redhat.com> Message-ID: <54BE40BA.1050001@redhat.com> On 15/01/15 16:07, Jan Cholasta wrote: > Dne 15.1.2015 v 15:39 Martin Basti napsal(a): >> On 15/01/15 15:07, Jan Cholasta wrote: >>> Dne 15.1.2015 v 14:58 Martin Basti napsal(a): >>>> On 15/01/15 14:25, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >>>>>> On 15/01/15 13:17, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4722 >>>>>>> >>>>>>> Patch attached. >>>>>>> >>>>>> Fast fix. >>>>>> >>>>>> Updated patch attached. >>>>> >>>>> 1) Forward zone commands are not fixed. >>>> FWzones are new and always normalized to absolute name in ldap >>> >>> Would you bet your money on that? Better be safe than sorry, >>> especially when it's just a matter of moving the code around (right?) >>> >>>>> >>>>> 2) It seems that the primary key returned by -mod, -del and -show >>>>> (.result.value) is made absolute somewhere else in the code. Would it >>>>> be possible to do it in one place? >>>> IMO it is not possible. >>>> >>>> Value is generated from key, and key is normalized to absolute zone >>>> before calling execute. >>>> >>>> LDAPUpdate: >>>> ... >>>> if self.obj.primary_key: >>>> pkey = keys[-1] >>>> else: >>>> pkey = None >>>> >>>> return dict(result=entry_attrs, value=pkey_to_value(pkey, >>>> options)) >>>> >>>> The idnsname attribute is just taken from LDAP without any >>>> normalization >>> >>> Right. >>> >>>> >>>> >>>>> >>>>> 3) Attribute values returned from LDAP are never None, so the if >>>>> should be "if 'idnsname' in entry_attrs:". >>>> Ok I will revert the change I made. >>>>> >>>>> 4) If idnsname always has only single value, use >>>>> "entry_attrs.single_value['idnsname'] = >>>>> entry_attrs.single_value['idnsname'].make_absolute()" >>>> Thanks >>>>> >>>>> Honza >>>>> >>>> >>>> Updated patch attached. >>>> >>> >>> >> Updated patch attached. >> > > Thanks. > > Is there a reason why you put the _make_zone_absolute calls in > dnszone_* and dnsforwardzone_* instead of DNSZoneBase_*? > I moved callback into Base classes. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0184.5-Always-return-absolute-idnsname-in-dnszone-commands.patch Type: text/x-patch Size: 3797 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 20 11:59:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 20 Jan 2015 12:59:42 +0100 Subject: [Freeipa-devel] [PATCH] 388 Remove RUV from LDIF files before using them in ipa-restore In-Reply-To: <54B54ED3.3050402@redhat.com> References: <54B3FA65.4070404@redhat.com> <54B54B58.8050708@redhat.com> <54B54ED3.3050402@redhat.com> Message-ID: <54BE432E.3060500@redhat.com> Dne 13.1.2015 v 17:58 Jan Cholasta napsal(a): > Dne 13.1.2015 v 17:44 Petr Vobornik napsal(a): >> On 01/12/2015 05:46 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >> >> works for me, ACK > > Thanks, pushed to: > master: 05e6adecb51b93e9b9d2326df4eabee90c3dfe72 > ipa-4-1: eb7917026d418a6d6a1e7a24a19097065df10497 > Posting additional patch 394 which fixes a SELinux issue. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-394-Put-LDIF-files-to-their-original-location-in-ipa-res.patch Type: text/x-patch Size: 1482 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 20 12:45:45 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Jan 2015 13:45:45 +0100 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <20150115194938.GA29191@mail.corp.redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <54B813D1.5090205@redhat.com> <54B8172E.5080208@redhat.com> <20150115194938.GA29191@mail.corp.redhat.com> Message-ID: <54BE4DF9.9080101@redhat.com> On 15.1.2015 20:49, Lukas Slebodnik wrote: > On (15/01/15 20:38), Martin Basti wrote: >> On 15/01/15 20:24, Martin Basti wrote: >>> On 15/01/15 17:13, David Kupka wrote: >>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>> >>>>>>>>> Thank you for patch: >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>> - "Failed to connect to server '%s'.", >>>>>>>>> server) >>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>> + except CalledProcessError as e: >>>>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>>> >>>>>>>>> IMO the error message should be more specific, add there something >>>>>>>>> like >>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>> >>>>>>>>> .replace() is not needed >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> + if len(ips) == 0: >>>>>>>>> >>>>>>>>> if not ips: >>>>>>>>> >>>>>>>>> is more pythonic by PEP8 >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>> >>>>>>> merciful NACK >>>>>>> >>>>>>> Thank you for the patch, unfortunately I hit one issue which needs >>>>>>> to be >>>>>>> resolved. >>>>>>> >>>>>>> If "sync PTR" is activated in zone settings, and reverse zone doesn't >>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA records was >>>>>>> succesfully updated, only PTR records failed. >>>>>>> >>>>>>> Bind log: >>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>>>>>> 'vm-101.example.com' AAAA >>>>>>> >>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >>>>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>> for IP >>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>> >>>>>>> With IPv6 we have several addresses from different reverse zones and >>>>>>> this situation may happen often. >>>>>>> I suggest following: >>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>> fails, >>>>>>> user needs to read log, which addresses installer tried to update) >>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>> there >>>>>>> and print proper error message >>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>> particular >>>>>>> IP address. >>>>>>> >>>>>>> Any other suggestions are welcome. >>>>>>> >>>>>> >>>>>> After long discussion with DNS and UX guru I've implemented it this >>>>>> way: >>>>>> 1. Call nsupdate only once with all updates. >>>>>> 2. Verify that the expected records are resolvable. >>>>>> 3. If no print list of missing A/AAAA, list of missing PTR records and >>>>>> list to mismatched PTR record. >>>>>> >>>>>> As this is running inside client we can't much more and it's up to >>>>>> user >>>>>> to check what's rotten in his DNS setup. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> >>>>> One more change to behave well in -crazy- exotic environments that >>>>> resolves more PTR records for single IP. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> Yet another change to make language nerds and our UX guru happy :-) >>> Sorry, but NACK. >>> >>> 1) BIND/dyndb-ldap bug? (if sync_ptr is enabled) >>> + try: >>> + answers = dns.resolver.query(fqdn, record_type) >>> + except dns.resolver.NoAnswer: >>> + if record_type == dns.rdatatype.A: >>> + root_logger.debug('No A record for %s' % fqdn) >>> + elif record_type == dns.rdatatype.AAAA: >>> + root_logger.debug('No AAAA record for %s' % fqdn) >>> + except dns.exception.DNSException as e: >>> + root_logger.debug('DNS resolver error: ' % e) >>> + else: >>> + for rdata in answers: >>> + try: >>> + missing_ips.remove(rdata.address) >>> + except ValueError: >>> + extra_ips.append(rdata.address) >>> >>> This somehow doesn't work, for missing A/AAAA records (4 A/AAAA records >>> expected) >>> $host `hostname` >>> vm-024.example.com has address 10.16.78.24 >>> vm-024.example.com has IPv6 address fed0:babe:baab:0:21a:4aff:fe10:4e37 >>> But I get *no warning*. >>> >>> == Why == >>> Probably bug in BIND, all AAAA/A records *exists for several seconds*, then >>> bind remove all A/AAAA records without PTR record. >>> (Needs more investigation, maybe it is dependent on bind version, in >>> previous testing, the A/AAAA records stay untouched ) >>> >>> This it the older journal from the *same machine* with same packages, where >>> record without PTR haven't been deleted after few seconds >>> EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at >>> 'vm-101.example.com' A >>> EXAMPLE.COM: updating zone 'example.com/IN': deleting rrset at >>> 'vm-101.example.com' AAAA >>> EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at >>> 'vm-101.example.com' A >>> EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at >>> 'vm-101.example.com' AAAA >>> vm-101.example.com.' refused: unable to find active reverse zone for IP >>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>> EXAMPLE.COM: updating zone 'idm.example.com/IN': adding an RR at >>> 'vm-101.example.com' AAAA >>> vm-101.example.com.' refused: unable to find active reverse zone for IP >>> address 'fed0:babe:baab:0:21a:4aff:fe10:4eaa': not found >>> EXAMPLE.COM: updating zone 'example.com/IN': adding an RR at >>> 'vm-101.example.com' AAAA >>> vm-101.example.com.' refused: unable to find active reverse zone for IP >>> address 'fec0:0:a10:4c00:21a:4aff:fe10:4eaa': not found >>> * There is no additional lines related with records above* >>> >>> Current journal continues with removing records. >>> >>> The only one change it the new script is checking status of records with >>> DNS query. >>> >>> IMO expected behavior is, the A/AAAA records should stay untouched. >>> >>> We can't test if records are there with this BIND behavior. >>> >>> bind-9.9.6-6.P1.fc21.x86_64 >>> bind-dyndb-ldap-6.1-1.fc21.x86_64 >> >> I investigated deeper, this issue is somehow related with option >> --enable-dns-update (and enabled PTR SYNC). >> With this option, only A/AAAA records with PTR are updated. >> Without this option all A/AAAA records are updated (with or without PTR) >> >> Is this caused by SSSD? > I have no idea what the argument "--enable-dns-update" does. > I would recomment to compare generated sssd.conf. > > There are 6 dynamic DNS related options in sssd. > sh$ man sssd-ipa | grep "dyndns_" | grep "(" > dyndns_update (boolean) > dyndns_ttl (integer) > dyndns_iface (string) > dyndns_refresh_interval (integer) > dyndns_update_ptr (bool) > dyndns_force_tcp (bool) > > You can find default values in sssd-ipa man page. For the record: This patch uncovers bug https://fedorahosted.org/bind-dyndb-ldap/ticket/155 Also, this patch is meaningless without https://fedorahosted.org/sssd/ticket/2555 ... so all three should be fixed in the same time frame. -- Petr^2 Spacek From dkupka at redhat.com Tue Jan 20 13:48:49 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 20 Jan 2015 14:48:49 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54BE2492.1000608@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> <54B55A08.50402@redhat.com> <54B55C24.1080407@redhat.com> <54BE2492.1000608@redhat.com> Message-ID: <54BE5CC1.3030207@redhat.com> On 01/20/2015 10:49 AM, Jan Cholasta wrote: > Dne 13.1.2015 v 18:55 Jan Cholasta napsal(a): >> Dne 13.1.2015 v 18:46 David Kupka napsal(a): >>> On 01/13/2015 05:55 PM, Jan Cholasta wrote: >>>> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>> >>>> Modified the fix to create only one service object in stopped_service. >>>> >>>> Updated patch attached. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Hi! >>> Thanks for the patch. Works for me, ACK. >>> >> >> Thanks, pushed to: >> master: 5bf1c9a6f7d734c296c8eb987cfc4f7e2a345130 >> ipa-4-1: 065e2bbc9f2260d8c60c55f92a386513727576da >> > > Posting additional patch 393 which is necessary to properly fix this. > > David, could you take a look please? > Hi! Thanks for the patch. We know that there are better ways how to do it but this works as expected and we need the fix now, ACK. -- David Kupka From mkosek at redhat.com Tue Jan 20 14:37:27 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Jan 2015 15:37:27 +0100 Subject: [Freeipa-devel] [PATCH] 390 Do not crash on unknown services in installutils.stopped_service In-Reply-To: <54BE2492.1000608@redhat.com> References: <54B4FD80.8090008@redhat.com> <54B54E18.1050702@redhat.com> <54B55A08.50402@redhat.com> <54B55C24.1080407@redhat.com> <54BE2492.1000608@redhat.com> Message-ID: <54BE6827.6050702@redhat.com> On 01/20/2015 10:49 AM, Jan Cholasta wrote: > Dne 13.1.2015 v 18:55 Jan Cholasta napsal(a): >> Dne 13.1.2015 v 18:46 David Kupka napsal(a): >>> On 01/13/2015 05:55 PM, Jan Cholasta wrote: >>>> Dne 13.1.2015 v 12:12 Jan Cholasta napsal(a): >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>> >>>> Modified the fix to create only one service object in stopped_service. >>>> >>>> Updated patch attached. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Hi! >>> Thanks for the patch. Works for me, ACK. >>> >> >> Thanks, pushed to: >> master: 5bf1c9a6f7d734c296c8eb987cfc4f7e2a345130 >> ipa-4-1: 065e2bbc9f2260d8c60c55f92a386513727576da >> > > Posting additional patch 393 which is necessary to properly fix this. > > David, could you take a look please? Pushed to: master: 82ab0eabf8b963023611ceb42f87244f40651c05 ipa-4-1: f204b28da316f60d85c6a6a0578e78ac74397fac Martin From mkosek at redhat.com Tue Jan 20 16:58:33 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Jan 2015 17:58:33 +0100 Subject: [Freeipa-devel] [PATCH] 492 Add anonymous read ACI for DUA profile Message-ID: <54BE8939.9010407@redhat.com> DUA profile(s) are consumed by Solaris clients. https://fedorahosted.org/freeipa/ticket/4850 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-492-add-anonymous-read-aci-for-dua-profile.patch Type: text/x-patch Size: 3882 bytes Desc: not available URL: From mbasti at redhat.com Tue Jan 20 17:03:30 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Jan 2015 18:03:30 +0100 Subject: [Freeipa-devel] [PATCH 0186] Add debug messages into client realm autodetection Message-ID: <54BE8A62.4000805@redhat.com> It was hard to debug issue with client, when for several issues was raised only one error. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0186-Add-debug-messages-into-client-autodetection.patch Type: text/x-patch Size: 1502 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 20 17:05:35 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Jan 2015 18:05:35 +0100 Subject: [Freeipa-devel] [PATCH] 492 Add anonymous read ACI for DUA profile In-Reply-To: <54BE8939.9010407@redhat.com> References: <54BE8939.9010407@redhat.com> Message-ID: <54BE8ADF.40204@redhat.com> On 01/20/2015 05:58 PM, Martin Kosek wrote: > DUA profile(s) are consumed by Solaris clients. > > https://fedorahosted.org/freeipa/ticket/4850 I forgot to add CN to the list (I only coppied all the MAY attributes). Fix attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-492.2-add-anonymous-read-aci-for-dua-profile.patch Type: text/x-patch Size: 3971 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jan 20 17:44:46 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 20 Jan 2015 19:44:46 +0200 Subject: [Freeipa-devel] [PATCH 0186] Add debug messages into client realm autodetection In-Reply-To: <54BE8A62.4000805@redhat.com> References: <54BE8A62.4000805@redhat.com> Message-ID: <20150120174446.GQ4383@redhat.com> On Tue, 20 Jan 2015, Martin Basti wrote: >It was hard to debug issue with client, when for several issues was >raised only one error. > >Patch attached. > >-- >Martin Basti > >From 11d154d0df7cc208c168a69d05e232ac253a210b Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Tue, 20 Jan 2015 17:30:51 +0100 >Subject: [PATCH] Add debug messages into client autodetection > >Is hard to debug what the problem with REALM is without debug messages. >--- > ipa-client/ipaclient/ipadiscovery.py | 5 +++++ > 1 file changed, 5 insertions(+) > >diff --git a/ipa-client/ipaclient/ipadiscovery.py b/ipa-client/ipaclient/ipadiscovery.py >index 0d574825aa493a8d565afe30077b74aec03924a3..5e316837de7f10c1797198f881f58546e0ed3f43 100644 >--- a/ipa-client/ipaclient/ipadiscovery.py >+++ b/ipa-client/ipaclient/ipadiscovery.py >@@ -390,10 +390,15 @@ class IPADiscovery(object): > if trealm == r: > return [0, thost, trealm] > # must match or something is very wrong >+ root_logger.debug("Realm %s does not match any realm in LDAP " >+ "database", trealm) > return [REALM_NOT_FOUND] > else: > if len(lrealms) != 1: > #which one? we can't attach to a multi-realm server without DNS working >+ root_logger.debug("Multiple realms found, cannot decide " >+ "which realm is the right without " >+ "working DNS") > return [REALM_NOT_FOUND] > else: > return [0, thost, lrealms[0]] ACK -- / Alexander Bokovoy From mkosek at redhat.com Wed Jan 21 07:33:21 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Jan 2015 08:33:21 +0100 Subject: [Freeipa-devel] [PATCH] 388 Remove RUV from LDIF files before using them in ipa-restore In-Reply-To: <54BE432E.3060500@redhat.com> References: <54B3FA65.4070404@redhat.com> <54B54B58.8050708@redhat.com> <54B54ED3.3050402@redhat.com> <54BE432E.3060500@redhat.com> Message-ID: <54BF5641.8040005@redhat.com> On 01/20/2015 12:59 PM, Jan Cholasta wrote: > Dne 13.1.2015 v 17:58 Jan Cholasta napsal(a): >> Dne 13.1.2015 v 17:44 Petr Vobornik napsal(a): >>> On 01/12/2015 05:46 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes . >>>> >>>> Honza >>>> >>> >>> works for me, ACK >> >> Thanks, pushed to: >> master: 05e6adecb51b93e9b9d2326df4eabee90c3dfe72 >> ipa-4-1: eb7917026d418a6d6a1e7a24a19097065df10497 >> > > Posting additional patch 394 which fixes a SELinux issue. Works fine, thanks. ACK. Pushed to: master: 4994cd1d8dde69d94130894ca86aa8a11fb590bf ipa-4-1: 85599416ae4a0cc83b8e0669e686740dd2a10ea2 Martin From mkosek at redhat.com Wed Jan 21 07:35:04 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Jan 2015 08:35:04 +0100 Subject: [Freeipa-devel] [PATCH 0186] Add debug messages into client realm autodetection In-Reply-To: <20150120174446.GQ4383@redhat.com> References: <54BE8A62.4000805@redhat.com> <20150120174446.GQ4383@redhat.com> Message-ID: <54BF56A8.7050405@redhat.com> On 01/20/2015 06:44 PM, Alexander Bokovoy wrote: > On Tue, 20 Jan 2015, Martin Basti wrote: >> It was hard to debug issue with client, when for several issues was raised >> only one error. >> >> Patch attached. >> >> -- >> Martin Basti >> > >> From 11d154d0df7cc208c168a69d05e232ac253a210b Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Tue, 20 Jan 2015 17:30:51 +0100 >> Subject: [PATCH] Add debug messages into client autodetection >> >> Is hard to debug what the problem with REALM is without debug messages. >> --- >> ipa-client/ipaclient/ipadiscovery.py | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/ipa-client/ipaclient/ipadiscovery.py >> b/ipa-client/ipaclient/ipadiscovery.py >> index >> 0d574825aa493a8d565afe30077b74aec03924a3..5e316837de7f10c1797198f881f58546e0ed3f43 >> 100644 >> --- a/ipa-client/ipaclient/ipadiscovery.py >> +++ b/ipa-client/ipaclient/ipadiscovery.py >> @@ -390,10 +390,15 @@ class IPADiscovery(object): >> if trealm == r: >> return [0, thost, trealm] >> # must match or something is very wrong >> + root_logger.debug("Realm %s does not match any realm in LDAP " >> + "database", trealm) >> return [REALM_NOT_FOUND] >> else: >> if len(lrealms) != 1: >> #which one? we can't attach to a multi-realm server >> without DNS working >> + root_logger.debug("Multiple realms found, cannot decide " >> + "which realm is the right without " >> + "working DNS") >> return [REALM_NOT_FOUND] >> else: >> return [0, thost, lrealms[0]] > ACK > This is fine even for ipa-4-1 branch. Pushed to: master: af1f87a0346653532deeb04dc7f236d143c8b9a7 ipa-4-1: 1bde1b03ef24b83646bec7becd1b263c5835c5c5 Martin From jcholast at redhat.com Wed Jan 21 07:47:53 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 21 Jan 2015 08:47:53 +0100 Subject: [Freeipa-devel] [PATCH] 492 Add anonymous read ACI for DUA profile In-Reply-To: <54BE8ADF.40204@redhat.com> References: <54BE8939.9010407@redhat.com> <54BE8ADF.40204@redhat.com> Message-ID: <54BF59A9.7060409@redhat.com> Hi, Dne 20.1.2015 v 18:05 Martin Kosek napsal(a): > On 01/20/2015 05:58 PM, Martin Kosek wrote: >> DUA profile(s) are consumed by Solaris clients. >> >> https://fedorahosted.org/freeipa/ticket/4850 > > I forgot to add CN to the list (I only coppied all the MAY attributes). Fix > attached. > > Martin Works for me, ACK. Pushed to: master: 0a7a8d66040f7a5f0e55da4b01e614dd9b569a00 ipa-4-1: b54b740f7903a0722930cc281ccb5a2bece45aef Honza -- Jan Cholasta From jcholast at redhat.com Wed Jan 21 08:02:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 21 Jan 2015 09:02:29 +0100 Subject: [Freeipa-devel] [PATCH] 395 Revert "Make all ipatokenTOTP attributes mandatory" Message-ID: <54BF5D15.9090004@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-395-Revert-Make-all-ipatokenTOTP-attributes-mandatory.patch Type: text/x-patch Size: 2749 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 21 08:09:12 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Jan 2015 09:09:12 +0100 Subject: [Freeipa-devel] [PATCH] 395 Revert "Make all ipatokenTOTP attributes mandatory" In-Reply-To: <54BF5D15.9090004@redhat.com> References: <54BF5D15.9090004@redhat.com> Message-ID: <54BF5EA8.9010607@redhat.com> On 01/21/2015 09:02 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Please also add the reason why we are reverting the change (see details https://bugzilla.redhat.com/show_bug.cgi?id=1176995#c7) directly to commit description. When done, I will ACK. From jcholast at redhat.com Wed Jan 21 08:15:56 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 21 Jan 2015 09:15:56 +0100 Subject: [Freeipa-devel] [PATCH] 395 Revert "Make all ipatokenTOTP attributes mandatory" In-Reply-To: <54BF5EA8.9010607@redhat.com> References: <54BF5D15.9090004@redhat.com> <54BF5EA8.9010607@redhat.com> Message-ID: <54BF603C.2000309@redhat.com> Dne 21.1.2015 v 09:09 Martin Kosek napsal(a): > On 01/21/2015 09:02 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Please also add the reason why we are reverting the change (see details > https://bugzilla.redhat.com/show_bug.cgi?id=1176995#c7) directly to commit > description. > > When done, I will ACK. > Updated patch attached. (Feel free to amend the explanation.) -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-395.1-Revert-Make-all-ipatokenTOTP-attributes-mandatory.patch Type: text/x-patch Size: 2854 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 21 08:26:58 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Jan 2015 09:26:58 +0100 Subject: [Freeipa-devel] [PATCH] 395 Revert "Make all ipatokenTOTP attributes mandatory" In-Reply-To: <54BF603C.2000309@redhat.com> References: <54BF5D15.9090004@redhat.com> <54BF5EA8.9010607@redhat.com> <54BF603C.2000309@redhat.com> Message-ID: <54BF62D2.6020800@redhat.com> On 01/21/2015 09:15 AM, Jan Cholasta wrote: > Dne 21.1.2015 v 09:09 Martin Kosek napsal(a): >> On 01/21/2015 09:02 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Please also add the reason why we are reverting the change (see details >> https://bugzilla.redhat.com/show_bug.cgi?id=1176995#c7) directly to commit >> description. >> >> When done, I will ACK. >> > > Updated patch attached. (Feel free to amend the explanation.) > Ok, I just added direct link to the Bugzilla comment I referred. Pushed to master, ipa-4-1, ipa-4-0. Martin From abokovoy at redhat.com Wed Jan 21 10:03:48 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 21 Jan 2015 12:03:48 +0200 Subject: [Freeipa-devel] [PATCH] 0174-0175 ipa-kdb fixes Message-ID: <20150121100348.GR4383@redhat.com> Hi, couple patches to fix Kerberos DAL driver in relation to trusts. Patch 0174: Allow using CA paths defined in krb5.conf on top of what we define automatically for trusted domains. https://fedorahosted.org/freeipa/ticket/4791 Patch 0175: Change error code reported back to Kerberos client when a principal from a disabled trusted domain attempts to access resources we control. The error code will help older SSSD to properly reflect error message in the PAM stack. https://fedorahosted.org/freeipa/ticket/4788 -- / Alexander Bokovoy -------------- next part -------------- From 5539c7d29e185c4ee6489a9f93008e2b0c2670c9 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 5 Dec 2014 21:22:23 +0200 Subject: [PATCH 1/2] ipa-kdb: when processing transitions, hand over unknown ones to KDC When processing cross-realm trust transitions, let the KDC to handle those we don't know about. Admins might define the transitions as explicit [capaths] in krb5.conf. https://fedorahosted.org/freeipa/ticket/4791 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index a450007..0cbdd4c 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2688,7 +2688,8 @@ krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, } } - ret = KRB5KRB_AP_ERR_ILL_CR_TKT; + /* Tell to KDC that we don't handle this transition so that rules in krb5.conf could play its role */ + ret = KRB5_PLUGIN_NO_HANDLE; if (has_client_realm && has_transited_contents && has_server_realm) { ret = 0; } -- 2.1.0 -------------- next part -------------- From c3d2718b3f28fabfdfb29cd6d0ee87d848e32d2f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Dec 2014 14:59:38 +0200 Subject: [PATCH 2/2] ipa-kdb: reject principals from disabled domains as a KDC policy Fixes https://fedorahosted.org/freeipa/ticket/4788 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 0cbdd4c..5d7f892 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -1375,7 +1375,7 @@ static krb5_error_code filter_logon_info(krb5_context context, &domain->parent->sid_blacklist_incoming[k], true); if (result) { filter_logon_info_log_message(info->info->info3.base.domain_sid); - return EINVAL; + return KRB5KDC_ERR_POLICY; } } } -- 2.1.0 From mbasti at redhat.com Wed Jan 21 12:39:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 Jan 2015 13:39:56 +0100 Subject: [Freeipa-devel] [PATCHES 0187, 0188] DNSSEC ipa-dnskeysyncd fixes Message-ID: <54BF9E1C.6060705@redhat.com> Patch 188 catch ldap exceptions to prevent false positive abrt reports Patch 187 fixes issues with removing root zone Patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0187-DNSSEC-catch-ldap-exceptions-in-ipa-dnskeysyncd.patch Type: text/x-patch Size: 1046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0188-DNSSEC-fix-root-zone-dns-name-conversion.patch Type: text/x-patch Size: 1064 bytes Desc: not available URL: From pspacek at redhat.com Wed Jan 21 13:34:49 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Jan 2015 14:34:49 +0100 Subject: [Freeipa-devel] [PATCH 0320] Fix description of idnsAllowQuery attribute in README Message-ID: <54BFAAF9.8090007@redhat.com> Hello, Fix description of idnsAllowQuery attribute in README. https://fedorahosted.org/bind-dyndb-ldap/ticket/154 I got off-list ACK from Martin^2. Pushed to master: a4565b3ef843e4464d2e950f0716818e7c7ce09b -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0320-Fix-description-of-idnsAllowQuery-attribute-in-READM.patch Type: text/x-patch Size: 1988 bytes Desc: not available URL: From tbabej at redhat.com Wed Jan 21 15:51:59 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 21 Jan 2015 10:51:59 -0500 (EST) Subject: [Freeipa-devel] [PATCHES 297-299] Improvements for idviews xmlrpc tests In-Reply-To: <885559050.8517739.1421855418483.JavaMail.zimbra@redhat.com> Message-ID: <1507412522.8518274.1421855519719.JavaMail.zimbra@redhat.com> Hi, this couple of patches adds coverage for the scenario in https://fedorahosted.org/freeipa/ticket/4839 , plus fixes issues that caused ipa-run-tests to skip this test file. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0297-ipatests-Add-coverage-for-referential-integrity-plug.patch Type: text/x-patch Size: 4962 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0298-ipatests-Fix-old-command-references-in-the-ID-views-.patch Type: text/x-patch Size: 8955 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0299-ipatests-Fix-incorrect-assumptions-in-idviews-tests.patch Type: text/x-patch Size: 3488 bytes Desc: not available URL: From walters at verbum.org Wed Jan 21 22:04:52 2015 From: walters at verbum.org (Colin Walters) Date: Wed, 21 Jan 2015 17:04:52 -0500 Subject: [Freeipa-devel] [PATCH] Use curl instead of wget Message-ID: <1421877892.4015342.217094565.0A1E790D@webmail.messagingengine.com> [Note I didn't test this patch] Curl has a shared library, and so ends up being used by more components of the OS. It should be preferred over wget. The motivation for this patch is for Project Atomic hosts; we want to include ipa-client, but trim down its dependencies. If wget isn't installed on the host, it doesn't need to be updated for security errata. --- freeipa.spec.in | 4 ++-- ipa-client/ipa-install/ipa-client-install | 2 +- ipaplatform/base/paths.py | 1 - ipaplatform/redhat/services.py | 8 ++++---- ipaserver/advise/plugins/legacy_clients.py | 16 ++++++++-------- 5 files changed, 15 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-curl-instead-of-wget.patch Type: text/x-patch Size: 6538 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jan 22 05:23:57 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Jan 2015 07:23:57 +0200 Subject: [Freeipa-devel] [PATCH] Use curl instead of wget In-Reply-To: <1421877892.4015342.217094565.0A1E790D@webmail.messagingengine.com> References: <1421877892.4015342.217094565.0A1E790D@webmail.messagingengine.com> Message-ID: <20150122052357.GA12694@redhat.com> On Wed, 21 Jan 2015, Colin Walters wrote: >[Note I didn't test this patch] > >Curl has a shared library, and so ends up being used by more components >of the OS. It should be preferred over wget. > >The motivation for this patch is for Project Atomic hosts; we want to >include ipa-client, but trim down its dependencies. > >If wget isn't installed on the host, it doesn't need to be updated for >security errata. >--- > freeipa.spec.in | 4 ++-- > ipa-client/ipa-install/ipa-client-install | 2 +- > ipaplatform/base/paths.py | 1 - > ipaplatform/redhat/services.py | 8 ++++---- > ipaserver/advise/plugins/legacy_clients.py | 16 ++++++++-------- > 5 files changed, 15 insertions(+), 16 deletions(-) > In general, I'm not against trimming this dependency. However, please follow existing pattern by defining paths.BIN_CURL and using it instead of paths.BIN_WGET. FreeIPA client runs on Debian GNU/Linux-based platforms as well and we need to keep the abstraction. -- / Alexander Bokovoy From mbabinsk at redhat.com Thu Jan 22 10:04:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Jan 2015 11:04:39 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall Message-ID: <54C0CB37.3040605@redhat.com> The attached patch addresses https://fedorahosted.org/freeipa/ticket/4487. Using 'remove-ds.pl' script from 389-ds during server/replica uninstallation should allow for cleaner removal of DS instance with no leftovers (opened ports etc). Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0003-1-use-remove-ds.pl-to-remove-DS-instance.patch Type: text/x-patch Size: 3464 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Jan 22 10:58:24 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Jan 2015 11:58:24 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C0CB37.3040605@redhat.com> References: <54C0CB37.3040605@redhat.com> Message-ID: <54C0D7D0.8040109@redhat.com> On 01/22/2015 11:04 AM, Martin Babinsky wrote: > The attached patch addresses https://fedorahosted.org/freeipa/ticket/4487. > > Using 'remove-ds.pl' script from 389-ds during server/replica > uninstallation should allow for cleaner removal of DS instance with no > leftovers (opened ports etc). > > Martin^3 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Thanks to Martin^2 for explaining the rules governing the placement of new attributes into BasePathNamespace class. Attaching updated patch. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0003-2-use-remove-ds.pl-to-remove-DS-instance.patch Type: text/x-patch Size: 3462 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 22 11:19:08 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Jan 2015 12:19:08 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C0D7D0.8040109@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> Message-ID: <54C0DCAC.8050409@redhat.com> On 01/22/2015 11:58 AM, Martin Babinsky wrote: > On 01/22/2015 11:04 AM, Martin Babinsky wrote: >> The attached patch addresses https://fedorahosted.org/freeipa/ticket/4487. >> >> Using 'remove-ds.pl' script from 389-ds during server/replica >> uninstallation should allow for cleaner removal of DS instance with no >> leftovers (opened ports etc). >> >> Martin^3 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Thanks to Martin^2 for explaining the rules governing the placement of new > attributes into BasePathNamespace class. > > Attaching updated patch. > > Martin^3 I see you kept erase_ds_instance_data still in the dsinstance. What is the motivation? I thought that just like with PKI, with DS we will also have uninstall based solely only on the DS uninstall script and remove our custom removal. We can keep the manual removal somewhere in wiki, but I would personally not keep/maintain it in FreeIPA code. From mkosek at redhat.com Thu Jan 22 11:25:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Jan 2015 12:25:42 +0100 Subject: [Freeipa-devel] [PATCH] 493 Print PublicError traceback when in debug mode Message-ID: <54C0DE36.5000404@redhat.com> The framework only shows traceback for the internal/unknown errors, recognized PublicErrors are simply passed back to the FreeIPA clients. However, sometimes it would help to see a traceback of the PublicError to for example see exactly which line returns it. https://fedorahosted.org/freeipa/ticket/4847 ---- "if api.env.debug" may seem redundant in this case, my motivation was not to invoke exception trace formatting every time a public error is thrown even when debug is not enabled. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-493-print-publicerror-traceback-when-in-debug-mode.patch Type: text/x-patch Size: 1342 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Jan 22 11:38:41 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Jan 2015 12:38:41 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C0DCAC.8050409@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> <54C0DCAC.8050409@redhat.com> Message-ID: <54C0E141.5080700@redhat.com> On 01/22/2015 12:19 PM, Martin Kosek wrote: > On 01/22/2015 11:58 AM, Martin Babinsky wrote: >> On 01/22/2015 11:04 AM, Martin Babinsky wrote: >>> The attached patch addresses https://fedorahosted.org/freeipa/ticket/4487. >>> >>> Using 'remove-ds.pl' script from 389-ds during server/replica >>> uninstallation should allow for cleaner removal of DS instance with no >>> leftovers (opened ports etc). >>> >>> Martin^3 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Thanks to Martin^2 for explaining the rules governing the placement of new >> attributes into BasePathNamespace class. >> >> Attaching updated patch. >> >> Martin^3 > > I see you kept erase_ds_instance_data still in the dsinstance. What is the > motivation? I thought that just like with PKI, with DS we will also have > uninstall based solely only on the DS uninstall script and remove our custom > removal. > > We can keep the manual removal somewhere in wiki, but I would personally not > keep/maintain it in FreeIPA code. > I originally thought that I will keep erase_ds_instance-data as a failsafe method to clean up the dirsrv data in th case that remove-ds.pl fails. But I will remove the method altogether and change the code so that it prints out some warning about manual removal of DS data when remove-ds.pl fails. Martin^2 From tbabej at redhat.com Thu Jan 22 11:52:56 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 22 Jan 2015 06:52:56 -0500 (EST) Subject: [Freeipa-devel] [PATCH 300] Fix incorrect python shebang usage In-Reply-To: <1967617656.8928238.1421927546229.JavaMail.zimbra@redhat.com> Message-ID: <1319332196.8928270.1421927576992.JavaMail.zimbra@redhat.com> Hi, attached patch fixes few python2 non-explicit shebangs that lurked into the codebase. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0300-ipapython-Fix-incorrect-python-shebangs.patch Type: text/x-patch Size: 5596 bytes Desc: not available URL: From walters at verbum.org Thu Jan 22 13:37:19 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 22 Jan 2015 08:37:19 -0500 Subject: [Freeipa-devel] [PATCH] Use curl instead of wget In-Reply-To: <20150122052357.GA12694@redhat.com> References: <1421877892.4015342.217094565.0A1E790D@webmail.messagingengine.com> <20150122052357.GA12694@redhat.com> Message-ID: <1421933839.48030.217355185.52DD5292@webmail.messagingengine.com> On Thu, Jan 22, 2015, at 12:23 AM, Alexander Bokovoy wrote: > In general, I'm not against trimming this dependency. However, please > follow existing pattern by defining paths.BIN_CURL and using it instead > of paths.BIN_WGET. FreeIPA client runs on Debian GNU/Linux-based > platforms as well and we need to keep the abstraction. I understand this would be a separate patch...but I don't understand paths.py at all. First, why not just search $PATH? util.py already sets up a sanitized $PATH (although setting environment variables like this is not threadsafe, but that's another bug). Second, it's also in /usr/bin on Debian: https://packages.debian.org/wheezy/amd64/curl/filelist From abokovoy at redhat.com Thu Jan 22 13:45:39 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Jan 2015 15:45:39 +0200 Subject: [Freeipa-devel] [PATCH] Use curl instead of wget In-Reply-To: <1421933839.48030.217355185.52DD5292@webmail.messagingengine.com> References: <1421877892.4015342.217094565.0A1E790D@webmail.messagingengine.com> <20150122052357.GA12694@redhat.com> <1421933839.48030.217355185.52DD5292@webmail.messagingengine.com> Message-ID: <20150122134539.GX4383@redhat.com> On Thu, 22 Jan 2015, Colin Walters wrote: >On Thu, Jan 22, 2015, at 12:23 AM, Alexander Bokovoy wrote: > >> In general, I'm not against trimming this dependency. However, please >> follow existing pattern by defining paths.BIN_CURL and using it instead >> of paths.BIN_WGET. FreeIPA client runs on Debian GNU/Linux-based >> platforms as well and we need to keep the abstraction. > >I understand this would be a separate patch...but I don't understand paths.py >at all. > >First, why not just search $PATH? util.py already sets up a >sanitized $PATH (although setting environment variables >like this is not threadsafe, but that's another bug). > >Second, it's also in /usr/bin on Debian: >https://packages.debian.org/wheezy/amd64/curl/filelist We have abstraction layer to take care of different platforms on a wider scale than just this particular binary. We are gradually moving all code to use platform abstraction to allow other platforms to be supported (like FreeBSD or Illumos) and we in general cannot guarantee things will be there at the same locations. -- / Alexander Bokovoy From dkupka at redhat.com Thu Jan 22 13:51:50 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 22 Jan 2015 14:51:50 +0100 Subject: [Freeipa-devel] [PATCHES 297-299] Improvements for idviews xmlrpc tests In-Reply-To: <1507412522.8518274.1421855519719.JavaMail.zimbra@redhat.com> References: <1507412522.8518274.1421855519719.JavaMail.zimbra@redhat.com> Message-ID: <54C10076.8090805@redhat.com> On 01/21/2015 04:51 PM, Tomas Babej wrote: > Hi, > > this couple of patches adds coverage for the scenario in https://fedorahosted.org/freeipa/ticket/4839 , plus fixes issues that caused ipa-run-tests to skip this test file. > > Tomas > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi, thanks for patches. Works for me, ACK. -- David Kupka From mbabinsk at redhat.com Thu Jan 22 14:03:37 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Jan 2015 15:03:37 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C0E141.5080700@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> <54C0DCAC.8050409@redhat.com> <54C0E141.5080700@redhat.com> Message-ID: <54C10339.8080800@redhat.com> On 01/22/2015 12:38 PM, Martin Babinsky wrote: > On 01/22/2015 12:19 PM, Martin Kosek wrote: >> On 01/22/2015 11:58 AM, Martin Babinsky wrote: >>> On 01/22/2015 11:04 AM, Martin Babinsky wrote: >>>> The attached patch addresses >>>> https://fedorahosted.org/freeipa/ticket/4487. >>>> >>>> Using 'remove-ds.pl' script from 389-ds during server/replica >>>> uninstallation should allow for cleaner removal of DS instance with no >>>> leftovers (opened ports etc). >>>> >>>> Martin^3 >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> Thanks to Martin^2 for explaining the rules governing the placement >>> of new >>> attributes into BasePathNamespace class. >>> >>> Attaching updated patch. >>> >>> Martin^3 >> >> I see you kept erase_ds_instance_data still in the dsinstance. What is >> the >> motivation? I thought that just like with PKI, with DS we will also have >> uninstall based solely only on the DS uninstall script and remove our >> custom >> removal. >> >> We can keep the manual removal somewhere in wiki, but I would >> personally not >> keep/maintain it in FreeIPA code. >> > I originally thought that I will keep erase_ds_instance-data as a > failsafe method to clean up the dirsrv data in th case that remove-ds.pl > fails. > > But I will remove the method altogether and change the code so that it > prints out some warning about manual removal of DS data when > remove-ds.pl fails. > > Martin^2 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Updated patch attached Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0003-3-use-remove-ds.pl-to-remove-DS-instance.patch Type: text/x-patch Size: 6283 bytes Desc: not available URL: From walters at verbum.org Thu Jan 22 14:36:37 2015 From: walters at verbum.org (Colin Walters) Date: Thu, 22 Jan 2015 09:36:37 -0500 Subject: [Freeipa-devel] [PATCH] Use curl instead of wget In-Reply-To: <20150122134539.GX4383@redhat.com> References: <1421877892.4015342.217094565.0A1E790D@webmail.messagingengine.com> <20150122052357.GA12694@redhat.com> <1421933839.48030.217355185.52DD5292@webmail.messagingengine.com> <20150122134539.GX4383@redhat.com> Message-ID: <1421937397.65670.217380117.5B381874@webmail.messagingengine.com> On Thu, Jan 22, 2015, at 08:45 AM, Alexander Bokovoy wrote: > We have abstraction layer to take care of different platforms on a wider > scale than just this particular binary. We are gradually moving all code > to use platform abstraction to allow other platforms to be supported > (like FreeBSD or Illumos) and we in general cannot guarantee things will > be there at the same locations. That doesn't answer the "why not just use $PATH" part. Regardless, here's a new patch which adds a BIN_CURL. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-curl-instead-of-wget.patch Type: text/x-patch Size: 6587 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jan 22 15:01:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Jan 2015 17:01:56 +0200 Subject: [Freeipa-devel] [PATCH] Use curl instead of wget In-Reply-To: <1421937397.65670.217380117.5B381874@webmail.messagingengine.com> References: <1421877892.4015342.217094565.0A1E790D@webmail.messagingengine.com> <20150122052357.GA12694@redhat.com> <1421933839.48030.217355185.52DD5292@webmail.messagingengine.com> <20150122134539.GX4383@redhat.com> <1421937397.65670.217380117.5B381874@webmail.messagingengine.com> Message-ID: <20150122150156.GY4383@redhat.com> On Thu, 22 Jan 2015, Colin Walters wrote: > > >On Thu, Jan 22, 2015, at 08:45 AM, Alexander Bokovoy wrote: > >> We have abstraction layer to take care of different platforms on a wider >> scale than just this particular binary. We are gradually moving all code >> to use platform abstraction to allow other platforms to be supported >> (like FreeBSD or Illumos) and we in general cannot guarantee things will >> be there at the same locations. > >That doesn't answer the "why not just use $PATH" part. Regardless, >here's a new patch which adds a BIN_CURL. We had cases in past when a non-working from FreeIPA perspective utility was selected from $PATH due to a local misconfiguration. For something that is packaged as a complex combination of multiple packages, packaging requirements at least allow to establish the environment we expect and which was tested. Relying on $PATH doesn't improve this assumption. And some of cases are pretty subtle, like libxmlrpc-c uses cURL library and if cURL was built without GSSAPI support it will silently fail, leaving no traces at why this has happened. curl utility also doesn't check if SPNEGO support (GSSAPI in our case) was compiled in if you specify 'curl --negotiate' without any option value. >From 47701a454ba442f08cd05a77ff6a2dbba76b787a Mon Sep 17 00:00:00 2001 >From: Colin Walters >Date: Wed, 21 Jan 2015 16:59:52 -0500 >Subject: [PATCH] Use curl instead of wget > >Curl has a shared library, and so ends up being used by more components >of the OS. It should be preferred over wget. > >The motivation for this patch is for Project Atomic hosts; we want to >include ipa-client, but trim down its dependencies. > >If wget isn't installed on the host, it doesn't need to be updated for >security errata. Code-wise looks OK. We need to test it, I'll look at it next week. -- / Alexander Bokovoy From mbasti at redhat.com Thu Jan 22 15:09:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Jan 2015 16:09:42 +0100 Subject: [Freeipa-devel] [PATCH] 493 Print PublicError traceback when in debug mode In-Reply-To: <54C0DE36.5000404@redhat.com> References: <54C0DE36.5000404@redhat.com> Message-ID: <54C112B6.5070300@redhat.com> On 22/01/15 12:25, Martin Kosek wrote: > The framework only shows traceback for the internal/unknown errors, > recognized PublicErrors are simply passed back to the FreeIPA > clients. > > However, sometimes it would help to see a traceback of the > PublicError to for example see exactly which line returns it. > > https://fedorahosted.org/freeipa/ticket/4847 > > ---- > > "if api.env.debug" may seem redundant in this case, my motivation was not to > invoke exception trace formatting every time a public error is thrown even when > debug is not enabled. > > Martin > ACK, works as expected. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Jan 22 15:49:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Jan 2015 16:49:35 +0100 Subject: [Freeipa-devel] [PATCH 300] Fix incorrect python shebang usage In-Reply-To: <1319332196.8928270.1421927576992.JavaMail.zimbra@redhat.com> References: <1319332196.8928270.1421927576992.JavaMail.zimbra@redhat.com> Message-ID: <54C11C0F.60203@redhat.com> On 22/01/15 12:52, Tomas Babej wrote: > Hi, > > attached patch fixes few python2 non-explicit shebangs that lurked into the codebase. > > Tomas ACK -- Martin Basti From mbasti at redhat.com Thu Jan 22 16:19:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Jan 2015 17:19:03 +0100 Subject: [Freeipa-devel] [PATCH 0189] Prevent install scripts to fail silently if timeout exceeded Message-ID: <54C122F7.3040606@redhat.com> How to reproduce: 1. stop dirsrv 2. ipa-dns-install 3. insert password Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0189-Prevent-install-scripts-fail-silently-if-timeout-exc.patch Type: text/x-patch Size: 991 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 22 16:49:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Jan 2015 17:49:44 +0100 Subject: [Freeipa-devel] [PATCH] 493 Print PublicError traceback when in debug mode In-Reply-To: <54C112B6.5070300@redhat.com> References: <54C0DE36.5000404@redhat.com> <54C112B6.5070300@redhat.com> Message-ID: <54C12A28.7090809@redhat.com> On 01/22/2015 04:09 PM, Martin Basti wrote: > On 22/01/15 12:25, Martin Kosek wrote: >> The framework only shows traceback for the internal/unknown errors, >> recognized PublicErrors are simply passed back to the FreeIPA >> clients. >> >> However, sometimes it would help to see a traceback of the >> PublicError to for example see exactly which line returns it. >> >> https://fedorahosted.org/freeipa/ticket/4847 >> >> ---- >> >> "if api.env.debug" may seem redundant in this case, my motivation was not to >> invoke exception trace formatting every time a public error is thrown even when >> debug is not enabled. >> >> Martin >> > > ACK, works as expected. > Pushed to: master: 834c911f9603ae77ac2483f154d62a5f0670c297 ipa-4-1: 877321ec74f9fe1a583257de8cb9c8430f15cb45 Martin From jcholast at redhat.com Fri Jan 23 07:04:28 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 Jan 2015 08:04:28 +0100 Subject: [Freeipa-devel] [PATCHES 0187, 0188] DNSSEC ipa-dnskeysyncd fixes In-Reply-To: <54BF9E1C.6060705@redhat.com> References: <54BF9E1C.6060705@redhat.com> Message-ID: <54C1F27C.4070702@redhat.com> Hi, Dne 21.1.2015 v 13:39 Martin Basti napsal(a): > Patch 188 catch ldap exceptions to prevent false positive abrt reports > > Patch 187 fixes issues with removing root zone > > Patches attached. Patch 187: Is there a reason only SERVER_DOWN and CONNECT_ERROR are handled, instead of any LDAPError? Patch 188: IMO it would be slightly better to do it like this: - name = name.relativize(dns.name.root) + if name != dns.name.root: + name = name.relativize(dns.name.root) Honza -- Jan Cholasta From jcholast at redhat.com Fri Jan 23 07:22:31 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 Jan 2015 08:22:31 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54BE40BA.1050001@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> <54B7C781.5090007@redhat.com> <54B7C9A8.8070309@redhat.com> <54B7D133.9020400@redhat.com> <54B7D796.70803@redhat.com> <54BE40BA.1050001@redhat.com> Message-ID: <54C1F6B7.8020204@redhat.com> Dne 20.1.2015 v 12:49 Martin Basti napsal(a): > On 15/01/15 16:07, Jan Cholasta wrote: >> Dne 15.1.2015 v 15:39 Martin Basti napsal(a): >>> On 15/01/15 15:07, Jan Cholasta wrote: >>>> Dne 15.1.2015 v 14:58 Martin Basti napsal(a): >>>>> On 15/01/15 14:25, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >>>>>>> On 15/01/15 13:17, Martin Basti wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4722 >>>>>>>> >>>>>>>> Patch attached. >>>>>>>> >>>>>>> Fast fix. >>>>>>> >>>>>>> Updated patch attached. >>>>>> >>>>>> 1) Forward zone commands are not fixed. >>>>> FWzones are new and always normalized to absolute name in ldap >>>> >>>> Would you bet your money on that? Better be safe than sorry, >>>> especially when it's just a matter of moving the code around (right?) >>>> >>>>>> >>>>>> 2) It seems that the primary key returned by -mod, -del and -show >>>>>> (.result.value) is made absolute somewhere else in the code. Would it >>>>>> be possible to do it in one place? >>>>> IMO it is not possible. >>>>> >>>>> Value is generated from key, and key is normalized to absolute zone >>>>> before calling execute. >>>>> >>>>> LDAPUpdate: >>>>> ... >>>>> if self.obj.primary_key: >>>>> pkey = keys[-1] >>>>> else: >>>>> pkey = None >>>>> >>>>> return dict(result=entry_attrs, value=pkey_to_value(pkey, >>>>> options)) >>>>> >>>>> The idnsname attribute is just taken from LDAP without any >>>>> normalization >>>> >>>> Right. >>>> >>>>> >>>>> >>>>>> >>>>>> 3) Attribute values returned from LDAP are never None, so the if >>>>>> should be "if 'idnsname' in entry_attrs:". >>>>> Ok I will revert the change I made. >>>>>> >>>>>> 4) If idnsname always has only single value, use >>>>>> "entry_attrs.single_value['idnsname'] = >>>>>> entry_attrs.single_value['idnsname'].make_absolute()" >>>>> Thanks >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Updated patch attached. >>>>> >>>> >>>> >>> Updated patch attached. >>> >> >> Thanks. >> >> Is there a reason why you put the _make_zone_absolute calls in >> dnszone_* and dnsforwardzone_* instead of DNSZoneBase_*? >> > I moved callback into Base classes. > Patch attached. > 1) Multi-line statements should generally use parentheses for implicit line continuation rather than backslashes: + entry_attrs.single_value['idnsname'] = ( + entry_attrs.single_value['idnsname'].make_absolute()) 2) You can remove the DN asserts from dnszone_*, they are already asserted in DNSZoneBase_*. 3) Do not just ignore return values of super().post_callback(): def post_callback(self, something, ...): something = super(...).post_callback(something, ...) ... return something -- Jan Cholasta From mbasti at redhat.com Fri Jan 23 09:13:05 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Jan 2015 10:13:05 +0100 Subject: [Freeipa-devel] [PATCHES 0187, 0188] DNSSEC ipa-dnskeysyncd fixes In-Reply-To: <54C1F27C.4070702@redhat.com> References: <54BF9E1C.6060705@redhat.com> <54C1F27C.4070702@redhat.com> Message-ID: <54C210A1.6080004@redhat.com> On 23/01/15 08:04, Jan Cholasta wrote: > Hi, > > Dne 21.1.2015 v 13:39 Martin Basti napsal(a): >> Patch 188 catch ldap exceptions to prevent false positive abrt reports >> >> Patch 187 fixes issues with removing root zone >> >> Patches attached. > > Patch 187: > > Is there a reason only SERVER_DOWN and CONNECT_ERROR are handled, > instead of any LDAPError? > These are expected during IPA restart/start etc. Other ldap exceptions should not happen, so we can get abrt reports from users, if something is wrong. > Patch 188: > > IMO it would be slightly better to do it like this: > > - name = name.relativize(dns.name.root) > + if name != dns.name.root: > + name = name.relativize(dns.name.root) This will not work. There is relativization for some zones before this step. I will try to clean the mess I found now in a new patch. > > Honza > -- Martin Basti From jcholast at redhat.com Fri Jan 23 09:23:45 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 Jan 2015 10:23:45 +0100 Subject: [Freeipa-devel] [PATCHES 0187, 0188] DNSSEC ipa-dnskeysyncd fixes In-Reply-To: <54C210A1.6080004@redhat.com> References: <54BF9E1C.6060705@redhat.com> <54C1F27C.4070702@redhat.com> <54C210A1.6080004@redhat.com> Message-ID: <54C21321.2050601@redhat.com> Dne 23.1.2015 v 10:13 Martin Basti napsal(a): > On 23/01/15 08:04, Jan Cholasta wrote: >> Hi, >> >> Dne 21.1.2015 v 13:39 Martin Basti napsal(a): >>> Patch 188 catch ldap exceptions to prevent false positive abrt reports >>> >>> Patch 187 fixes issues with removing root zone >>> >>> Patches attached. >> >> Patch 187: >> >> Is there a reason only SERVER_DOWN and CONNECT_ERROR are handled, >> instead of any LDAPError? >> > These are expected during IPA restart/start etc. Other ldap exceptions > should not happen, so we can get abrt reports from users, if something > is wrong. Makes sense. >> Patch 188: >> >> IMO it would be slightly better to do it like this: >> >> - name = name.relativize(dns.name.root) >> + if name != dns.name.root: >> + name = name.relativize(dns.name.root) > This will not work. There is relativization for some zones before this > step. I will try to clean the mess I found now in a new patch. Please do. It's an ACK then. Is this supposed to go in ipa-4-1 too or is it master only? -- Jan Cholasta From mbasti at redhat.com Fri Jan 23 09:25:03 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Jan 2015 10:25:03 +0100 Subject: [Freeipa-devel] [PATCHES 0187, 0188] DNSSEC ipa-dnskeysyncd fixes In-Reply-To: <54C21321.2050601@redhat.com> References: <54BF9E1C.6060705@redhat.com> <54C1F27C.4070702@redhat.com> <54C210A1.6080004@redhat.com> <54C21321.2050601@redhat.com> Message-ID: <54C2136F.2020502@redhat.com> On 23/01/15 10:23, Jan Cholasta wrote: > Dne 23.1.2015 v 10:13 Martin Basti napsal(a): >> On 23/01/15 08:04, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 21.1.2015 v 13:39 Martin Basti napsal(a): >>>> Patch 188 catch ldap exceptions to prevent false positive abrt reports >>>> >>>> Patch 187 fixes issues with removing root zone >>>> >>>> Patches attached. >>> >>> Patch 187: >>> >>> Is there a reason only SERVER_DOWN and CONNECT_ERROR are handled, >>> instead of any LDAPError? >>> >> These are expected during IPA restart/start etc. Other ldap exceptions >> should not happen, so we can get abrt reports from users, if something >> is wrong. > > Makes sense. > >>> Patch 188: >>> >>> IMO it would be slightly better to do it like this: >>> >>> - name = name.relativize(dns.name.root) >>> + if name != dns.name.root: >>> + name = name.relativize(dns.name.root) >> This will not work. There is relativization for some zones before this >> step. I will try to clean the mess I found now in a new patch. > > Please do. > > It's an ACK then. Is this supposed to go in ipa-4-1 too or is it > master only? > Both please, thank you. -- Martin Basti From jcholast at redhat.com Fri Jan 23 09:27:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 Jan 2015 10:27:23 +0100 Subject: [Freeipa-devel] [PATCHES 0187, 0188] DNSSEC ipa-dnskeysyncd fixes In-Reply-To: <54C2136F.2020502@redhat.com> References: <54BF9E1C.6060705@redhat.com> <54C1F27C.4070702@redhat.com> <54C210A1.6080004@redhat.com> <54C21321.2050601@redhat.com> <54C2136F.2020502@redhat.com> Message-ID: <54C213FB.80508@redhat.com> Dne 23.1.2015 v 10:25 Martin Basti napsal(a): > On 23/01/15 10:23, Jan Cholasta wrote: >> Dne 23.1.2015 v 10:13 Martin Basti napsal(a): >>> On 23/01/15 08:04, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 21.1.2015 v 13:39 Martin Basti napsal(a): >>>>> Patch 188 catch ldap exceptions to prevent false positive abrt reports >>>>> >>>>> Patch 187 fixes issues with removing root zone >>>>> >>>>> Patches attached. >>>> >>>> Patch 187: >>>> >>>> Is there a reason only SERVER_DOWN and CONNECT_ERROR are handled, >>>> instead of any LDAPError? >>>> >>> These are expected during IPA restart/start etc. Other ldap exceptions >>> should not happen, so we can get abrt reports from users, if something >>> is wrong. >> >> Makes sense. >> >>>> Patch 188: >>>> >>>> IMO it would be slightly better to do it like this: >>>> >>>> - name = name.relativize(dns.name.root) >>>> + if name != dns.name.root: >>>> + name = name.relativize(dns.name.root) >>> This will not work. There is relativization for some zones before this >>> step. I will try to clean the mess I found now in a new patch. >> >> Please do. >> >> It's an ACK then. Is this supposed to go in ipa-4-1 too or is it >> master only? >> > Both please, thank you. > Pushed to: master: 46c12159e6c27082e7bc46e96d3738eea68dba91 ipa-4-1: 64cf3071ca908b22e5ad402585d9690c1a7fc518 -- Jan Cholasta From mbasti at redhat.com Fri Jan 23 14:51:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Jan 2015 15:51:51 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54C1F6B7.8020204@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> <54B7C781.5090007@redhat.com> <54B7C9A8.8070309@redhat.com> <54B7D133.9020400@redhat.com> <54B7D796.70803@redhat.com> <54BE40BA.1050001@redhat.com> <54C1F6B7.8020204@redhat.com> Message-ID: <54C26007.1080805@redhat.com> On 23/01/15 08:22, Jan Cholasta wrote: > Dne 20.1.2015 v 12:49 Martin Basti napsal(a): >> On 15/01/15 16:07, Jan Cholasta wrote: >>> Dne 15.1.2015 v 15:39 Martin Basti napsal(a): >>>> On 15/01/15 15:07, Jan Cholasta wrote: >>>>> Dne 15.1.2015 v 14:58 Martin Basti napsal(a): >>>>>> On 15/01/15 14:25, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >>>>>>>> On 15/01/15 13:17, Martin Basti wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4722 >>>>>>>>> >>>>>>>>> Patch attached. >>>>>>>>> >>>>>>>> Fast fix. >>>>>>>> >>>>>>>> Updated patch attached. >>>>>>> >>>>>>> 1) Forward zone commands are not fixed. >>>>>> FWzones are new and always normalized to absolute name in ldap >>>>> >>>>> Would you bet your money on that? Better be safe than sorry, >>>>> especially when it's just a matter of moving the code around (right?) >>>>> >>>>>>> >>>>>>> 2) It seems that the primary key returned by -mod, -del and -show >>>>>>> (.result.value) is made absolute somewhere else in the code. >>>>>>> Would it >>>>>>> be possible to do it in one place? >>>>>> IMO it is not possible. >>>>>> >>>>>> Value is generated from key, and key is normalized to absolute zone >>>>>> before calling execute. >>>>>> >>>>>> LDAPUpdate: >>>>>> ... >>>>>> if self.obj.primary_key: >>>>>> pkey = keys[-1] >>>>>> else: >>>>>> pkey = None >>>>>> >>>>>> return dict(result=entry_attrs, value=pkey_to_value(pkey, >>>>>> options)) >>>>>> >>>>>> The idnsname attribute is just taken from LDAP without any >>>>>> normalization >>>>> >>>>> Right. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> 3) Attribute values returned from LDAP are never None, so the if >>>>>>> should be "if 'idnsname' in entry_attrs:". >>>>>> Ok I will revert the change I made. >>>>>>> >>>>>>> 4) If idnsname always has only single value, use >>>>>>> "entry_attrs.single_value['idnsname'] = >>>>>>> entry_attrs.single_value['idnsname'].make_absolute()" >>>>>> Thanks >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>> >>>>> >>>> Updated patch attached. >>>> >>> >>> Thanks. >>> >>> Is there a reason why you put the _make_zone_absolute calls in >>> dnszone_* and dnsforwardzone_* instead of DNSZoneBase_*? >>> >> I moved callback into Base classes. >> Patch attached. >> > > 1) Multi-line statements should generally use parentheses for implicit > line continuation rather than backslashes: > > + entry_attrs.single_value['idnsname'] = ( > + entry_attrs.single_value['idnsname'].make_absolute()) > > 2) You can remove the DN asserts from dnszone_*, they are already > asserted in DNSZoneBase_*. > > 3) Do not just ignore return values of super().post_callback(): > > def post_callback(self, something, ...): > something = super(...).post_callback(something, ...) > ... > return something > Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0184.6-Always-return-absolute-idnsname-in-dnszone-commands.patch Type: text/x-patch Size: 3968 bytes Desc: not available URL: From mbasti at redhat.com Fri Jan 23 16:56:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 23 Jan 2015 17:56:12 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C10339.8080800@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> <54C0DCAC.8050409@redhat.com> <54C0E141.5080700@redhat.com> <54C10339.8080800@redhat.com> Message-ID: <54C27D2C.7000406@redhat.com> On 22/01/15 15:03, Martin Babinsky wrote: > On 01/22/2015 12:38 PM, Martin Babinsky wrote: >> On 01/22/2015 12:19 PM, Martin Kosek wrote: >>> On 01/22/2015 11:58 AM, Martin Babinsky wrote: >>>> On 01/22/2015 11:04 AM, Martin Babinsky wrote: >>>>> The attached patch addresses >>>>> https://fedorahosted.org/freeipa/ticket/4487. >>>>> >>>>> Using 'remove-ds.pl' script from 389-ds during server/replica >>>>> uninstallation should allow for cleaner removal of DS instance >>>>> with no >>>>> leftovers (opened ports etc). >>>>> >>>>> Martin^3 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> Thanks to Martin^2 for explaining the rules governing the placement >>>> of new >>>> attributes into BasePathNamespace class. >>>> >>>> Attaching updated patch. >>>> >>>> Martin^3 >>> >>> I see you kept erase_ds_instance_data still in the dsinstance. What is >>> the >>> motivation? I thought that just like with PKI, with DS we will also >>> have >>> uninstall based solely only on the DS uninstall script and remove our >>> custom >>> removal. >>> >>> We can keep the manual removal somewhere in wiki, but I would >>> personally not >>> keep/maintain it in FreeIPA code. >>> >> I originally thought that I will keep erase_ds_instance-data as a >> failsafe method to clean up the dirsrv data in th case that remove-ds.pl >> fails. >> >> But I will remove the method altogether and change the code so that it >> prints out some warning about manual removal of DS data when >> remove-ds.pl fails. >> >> Martin^2 >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Updated patch attached > > Martin^3 > Hi, thank you for patch, but I have a few nitpicks: 1) Extra parenthesis + root_logger.error(("Failed to remove CA DS instance. You may " + "need to remove instance data manually")) and (twice) + root_logger.error(("Failed to remove DS instance. You may " + "need to remove instance data manually")) and + root_logger.debug(("'%s' failed. " + "Attempting to force removal" % paths.REMOVE_DS_PL)) 2) Remove unused paths: USR_LIB_DIRSRV_SLAPD_INSTANCE_DIR_TEMPLATE SLAPD_INSTANCE_LOCK_TEMPLATE USR_LIB_SLAPD_INSTANCE_TEMPLATE Please do double check. 3) IMO we should avoid hardcoded value 'slapd' instance_name = '-'.join(['slapd', serverid]) you may create module variable DS_INSTANCE_PREFIX and use it. Dont forget to change it in following place as well. ipaserver/install/dsinstance.py:117: instance_prefix = 'slapd-' 4) DS keytab hasn't been removed, it is okay? It is created by IPA (krbinstance), not by DS install script. Martin^2 -- Martin Basti From jcholast at redhat.com Mon Jan 26 07:08:11 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 26 Jan 2015 08:08:11 +0100 Subject: [Freeipa-devel] [PATCH 0184] Always return absolute idnsname in dnszone commands In-Reply-To: <54C26007.1080805@redhat.com> References: <54B7AFD8.1050303@redhat.com> <54B7B238.8080206@redhat.com> <54B7BFE6.8060503@redhat.com> <54B7C781.5090007@redhat.com> <54B7C9A8.8070309@redhat.com> <54B7D133.9020400@redhat.com> <54B7D796.70803@redhat.com> <54BE40BA.1050001@redhat.com> <54C1F6B7.8020204@redhat.com> <54C26007.1080805@redhat.com> Message-ID: <54C5E7DB.4040100@redhat.com> Dne 23.1.2015 v 15:51 Martin Basti napsal(a): > On 23/01/15 08:22, Jan Cholasta wrote: >> Dne 20.1.2015 v 12:49 Martin Basti napsal(a): >>> On 15/01/15 16:07, Jan Cholasta wrote: >>>> Dne 15.1.2015 v 15:39 Martin Basti napsal(a): >>>>> On 15/01/15 15:07, Jan Cholasta wrote: >>>>>> Dne 15.1.2015 v 14:58 Martin Basti napsal(a): >>>>>>> On 15/01/15 14:25, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Dne 15.1.2015 v 13:27 Martin Basti napsal(a): >>>>>>>>> On 15/01/15 13:17, Martin Basti wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4722 >>>>>>>>>> >>>>>>>>>> Patch attached. >>>>>>>>>> >>>>>>>>> Fast fix. >>>>>>>>> >>>>>>>>> Updated patch attached. >>>>>>>> >>>>>>>> 1) Forward zone commands are not fixed. >>>>>>> FWzones are new and always normalized to absolute name in ldap >>>>>> >>>>>> Would you bet your money on that? Better be safe than sorry, >>>>>> especially when it's just a matter of moving the code around (right?) >>>>>> >>>>>>>> >>>>>>>> 2) It seems that the primary key returned by -mod, -del and -show >>>>>>>> (.result.value) is made absolute somewhere else in the code. >>>>>>>> Would it >>>>>>>> be possible to do it in one place? >>>>>>> IMO it is not possible. >>>>>>> >>>>>>> Value is generated from key, and key is normalized to absolute zone >>>>>>> before calling execute. >>>>>>> >>>>>>> LDAPUpdate: >>>>>>> ... >>>>>>> if self.obj.primary_key: >>>>>>> pkey = keys[-1] >>>>>>> else: >>>>>>> pkey = None >>>>>>> >>>>>>> return dict(result=entry_attrs, value=pkey_to_value(pkey, >>>>>>> options)) >>>>>>> >>>>>>> The idnsname attribute is just taken from LDAP without any >>>>>>> normalization >>>>>> >>>>>> Right. >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 3) Attribute values returned from LDAP are never None, so the if >>>>>>>> should be "if 'idnsname' in entry_attrs:". >>>>>>> Ok I will revert the change I made. >>>>>>>> >>>>>>>> 4) If idnsname always has only single value, use >>>>>>>> "entry_attrs.single_value['idnsname'] = >>>>>>>> entry_attrs.single_value['idnsname'].make_absolute()" >>>>>>> Thanks >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>> >>>>>> >>>>> Updated patch attached. >>>>> >>>> >>>> Thanks. >>>> >>>> Is there a reason why you put the _make_zone_absolute calls in >>>> dnszone_* and dnsforwardzone_* instead of DNSZoneBase_*? >>>> >>> I moved callback into Base classes. >>> Patch attached. >>> >> >> 1) Multi-line statements should generally use parentheses for implicit >> line continuation rather than backslashes: >> >> + entry_attrs.single_value['idnsname'] = ( >> + entry_attrs.single_value['idnsname'].make_absolute()) >> >> 2) You can remove the DN asserts from dnszone_*, they are already >> asserted in DNSZoneBase_*. >> >> 3) Do not just ignore return values of super().post_callback(): >> >> def post_callback(self, something, ...): >> something = super(...).post_callback(something, ...) >> ... >> return something >> > Updated patch attached. > > Thanks, ACK. Pushed to: master: af0a2409f92e2ef8b322628c0d0569f5e0dac902 ipa-4-1: 270253a999d6a59616634b307f9428e89d1fccb9 -- Jan Cholasta From jcholast at redhat.com Mon Jan 26 11:12:27 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 26 Jan 2015 12:12:27 +0100 Subject: [Freeipa-devel] [PATCH] 396 Create correct log directories during full restore in ipa-restore Message-ID: <54C6211B.8010903@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-396-Create-correct-log-directories-during-full-restore-i.patch Type: text/x-patch Size: 2131 bytes Desc: not available URL: From tbabej at redhat.com Mon Jan 26 12:02:28 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 26 Jan 2015 07:02:28 -0500 (EST) Subject: [Freeipa-devel] [PATCHES 297-299] Improvements for idviews xmlrpc tests In-Reply-To: <54C10076.8090805@redhat.com> References: <1507412522.8518274.1421855519719.JavaMail.zimbra@redhat.com> <54C10076.8090805@redhat.com> Message-ID: <185177859.184432.1422273748879.JavaMail.zimbra@redhat.com> ----- Original Message ----- From: "David Kupka" To: "Tomas Babej" , freeipa-devel at redhat.com Sent: Thursday, January 22, 2015 2:51:50 PM Subject: Re: [Freeipa-devel] [PATCHES 297-299] Improvements for idviews xmlrpc tests On 01/21/2015 04:51 PM, Tomas Babej wrote: > Hi, > > this couple of patches adds coverage for the scenario in https://fedorahosted.org/freeipa/ticket/4839 , plus fixes issues that caused ipa-run-tests to skip this test file. > > Tomas > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi, thanks for patches. Works for me, ACK. -- David Kupka Pushed to: master: f83b4fe3306071622ae6264f71843a2e20731262 ipa-4-1: 375ab7a303170cd46b77eb3ab11f0561f384ebe5 Tomas From mbabinsk at redhat.com Mon Jan 26 12:59:41 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 26 Jan 2015 13:59:41 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C27D2C.7000406@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> <54C0DCAC.8050409@redhat.com> <54C0E141.5080700@redhat.com> <54C10339.8080800@redhat.com> <54C27D2C.7000406@redhat.com> Message-ID: <54C63A3D.6040309@redhat.com> On 01/23/2015 05:56 PM, Martin Basti wrote: > On 22/01/15 15:03, Martin Babinsky wrote: >> On 01/22/2015 12:38 PM, Martin Babinsky wrote: >>> On 01/22/2015 12:19 PM, Martin Kosek wrote: >>>> On 01/22/2015 11:58 AM, Martin Babinsky wrote: >>>>> On 01/22/2015 11:04 AM, Martin Babinsky wrote: >>>>>> The attached patch addresses >>>>>> https://fedorahosted.org/freeipa/ticket/4487. >>>>>> >>>>>> Using 'remove-ds.pl' script from 389-ds during server/replica >>>>>> uninstallation should allow for cleaner removal of DS instance >>>>>> with no >>>>>> leftovers (opened ports etc). >>>>>> >>>>>> Martin^3 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> Thanks to Martin^2 for explaining the rules governing the placement >>>>> of new >>>>> attributes into BasePathNamespace class. >>>>> >>>>> Attaching updated patch. >>>>> >>>>> Martin^3 >>>> >>>> I see you kept erase_ds_instance_data still in the dsinstance. What is >>>> the >>>> motivation? I thought that just like with PKI, with DS we will also >>>> have >>>> uninstall based solely only on the DS uninstall script and remove our >>>> custom >>>> removal. >>>> >>>> We can keep the manual removal somewhere in wiki, but I would >>>> personally not >>>> keep/maintain it in FreeIPA code. >>>> >>> I originally thought that I will keep erase_ds_instance-data as a >>> failsafe method to clean up the dirsrv data in th case that remove-ds.pl >>> fails. >>> >>> But I will remove the method altogether and change the code so that it >>> prints out some warning about manual removal of DS data when >>> remove-ds.pl fails. >>> >>> Martin^2 >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Updated patch attached >> >> Martin^3 >> > > Hi, > > thank you for patch, but I have a few nitpicks: > > 1) Extra parenthesis > + root_logger.error(("Failed to remove CA DS instance. > You may " > + "need to remove instance data > manually")) > > and (twice) > > + root_logger.error(("Failed to remove DS instance. You > may " > + "need to remove instance data > manually")) > > and > > + root_logger.debug(("'%s' failed. " > + "Attempting to force removal" % > paths.REMOVE_DS_PL)) > > 2) Remove unused paths: > USR_LIB_DIRSRV_SLAPD_INSTANCE_DIR_TEMPLATE > SLAPD_INSTANCE_LOCK_TEMPLATE > USR_LIB_SLAPD_INSTANCE_TEMPLATE > > Please do double check. > > 3) IMO we should avoid hardcoded value 'slapd' > instance_name = '-'.join(['slapd', serverid]) > > you may create module variable DS_INSTANCE_PREFIX and use it. Dont > forget to change it in following place as well. > ipaserver/install/dsinstance.py:117: instance_prefix = 'slapd-' > > 4) > DS keytab hasn't been removed, it is okay? > It is created by IPA (krbinstance), not by DS install script. > > > Martin^2 > Thanks for suggestions, attaching updated patch Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0003-4-use-remove-ds.pl-to-remove-DS-instance.patch Type: text/x-patch Size: 8866 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Jan 26 13:05:54 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 26 Jan 2015 14:05:54 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C63A3D.6040309@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> <54C0DCAC.8050409@redhat.com> <54C0E141.5080700@redhat.com> <54C10339.8080800@redhat.com> <54C27D2C.7000406@redhat.com> <54C63A3D.6040309@redhat.com> Message-ID: <54C63BB2.9060602@redhat.com> On 01/26/2015 01:59 PM, Martin Babinsky wrote: > On 01/23/2015 05:56 PM, Martin Basti wrote: >> On 22/01/15 15:03, Martin Babinsky wrote: >>> On 01/22/2015 12:38 PM, Martin Babinsky wrote: >>>> On 01/22/2015 12:19 PM, Martin Kosek wrote: >>>>> On 01/22/2015 11:58 AM, Martin Babinsky wrote: >>>>>> On 01/22/2015 11:04 AM, Martin Babinsky wrote: >>>>>>> The attached patch addresses >>>>>>> https://fedorahosted.org/freeipa/ticket/4487. >>>>>>> >>>>>>> Using 'remove-ds.pl' script from 389-ds during server/replica >>>>>>> uninstallation should allow for cleaner removal of DS instance >>>>>>> with no >>>>>>> leftovers (opened ports etc). >>>>>>> >>>>>>> Martin^3 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> Thanks to Martin^2 for explaining the rules governing the placement >>>>>> of new >>>>>> attributes into BasePathNamespace class. >>>>>> >>>>>> Attaching updated patch. >>>>>> >>>>>> Martin^3 >>>>> >>>>> I see you kept erase_ds_instance_data still in the dsinstance. What is >>>>> the >>>>> motivation? I thought that just like with PKI, with DS we will also >>>>> have >>>>> uninstall based solely only on the DS uninstall script and remove our >>>>> custom >>>>> removal. >>>>> >>>>> We can keep the manual removal somewhere in wiki, but I would >>>>> personally not >>>>> keep/maintain it in FreeIPA code. >>>>> >>>> I originally thought that I will keep erase_ds_instance-data as a >>>> failsafe method to clean up the dirsrv data in th case that >>>> remove-ds.pl >>>> fails. >>>> >>>> But I will remove the method altogether and change the code so that it >>>> prints out some warning about manual removal of DS data when >>>> remove-ds.pl fails. >>>> >>>> Martin^2 >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Updated patch attached >>> >>> Martin^3 >>> >> >> Hi, >> >> thank you for patch, but I have a few nitpicks: >> >> 1) Extra parenthesis >> + root_logger.error(("Failed to remove CA DS instance. >> You may " >> + "need to remove instance data >> manually")) >> >> and (twice) >> >> + root_logger.error(("Failed to remove DS instance. You >> may " >> + "need to remove instance data >> manually")) >> >> and >> >> + root_logger.debug(("'%s' failed. " >> + "Attempting to force removal" % >> paths.REMOVE_DS_PL)) >> >> 2) Remove unused paths: >> USR_LIB_DIRSRV_SLAPD_INSTANCE_DIR_TEMPLATE >> SLAPD_INSTANCE_LOCK_TEMPLATE >> USR_LIB_SLAPD_INSTANCE_TEMPLATE >> >> Please do double check. >> >> 3) IMO we should avoid hardcoded value 'slapd' >> instance_name = '-'.join(['slapd', serverid]) >> >> you may create module variable DS_INSTANCE_PREFIX and use it. Dont >> forget to change it in following place as well. >> ipaserver/install/dsinstance.py:117: instance_prefix = 'slapd-' >> >> 4) >> DS keytab hasn't been removed, it is okay? >> It is created by IPA (krbinstance), not by DS install script. >> >> >> Martin^2 >> > Thanks for suggestions, attaching updated patch > > Martin^3 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Missed one little thing. Attaching updated patch. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0003-5-use-remove-ds.pl-to-remove-DS-instance.patch Type: text/x-patch Size: 8863 bytes Desc: not available URL: From tbabej at redhat.com Mon Jan 26 15:33:25 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 26 Jan 2015 10:33:25 -0500 (EST) Subject: [Freeipa-devel] [PATCHES 301-302] ID override sshpubkey handling In-Reply-To: <1594454815.276273.1422286383864.JavaMail.zimbra@redhat.com> Message-ID: <1508237010.276360.1422286405591.JavaMail.zimbra@redhat.com> Hi, the following two patches make sure that sshpubkeys work both with -mod and -add commands of ipaoverrideuser objects. Also covers the use cases with unit tests. https://fedorahosted.org/freeipa/ticket/4868 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0301-idviews-Make-sure-ssh-public-key-can-be-set-on-ipaus.patch Type: text/x-patch Size: 4364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0302-ipatests-Add-coverage-for-adding-and-removing-sshpub.patch Type: text/x-patch Size: 5033 bytes Desc: not available URL: From simo at redhat.com Mon Jan 26 15:44:09 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 26 Jan 2015 10:44:09 -0500 Subject: [Freeipa-devel] [PATCH] 0174-0175 ipa-kdb fixes In-Reply-To: <20150121100348.GR4383@redhat.com> References: <20150121100348.GR4383@redhat.com> Message-ID: <20150126104409.4dd9cb8a@willson.usersys.redhat.com> On Wed, 21 Jan 2015 12:03:48 +0200 Alexander Bokovoy wrote: > Hi, > > couple patches to fix Kerberos DAL driver in relation to trusts. > > Patch 0174: > Allow using CA paths defined in krb5.conf on top of what we define > automatically for trusted domains. > https://fedorahosted.org/freeipa/ticket/4791 > > Patch 0175: > Change error code reported back to Kerberos client when a principal > from a disabled trusted domain attempts to access resources we > control. > > The error code will help older SSSD to properly reflect error message > in the PAM stack. > https://fedorahosted.org/freeipa/ticket/4788 > They both LGTM. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Jan 26 16:22:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Jan 2015 17:22:03 +0100 Subject: [Freeipa-devel] [PATCH] 396 Create correct log directories during full restore in ipa-restore In-Reply-To: <54C6211B.8010903@redhat.com> References: <54C6211B.8010903@redhat.com> Message-ID: <54C669AB.9020209@redhat.com> On 01/26/2015 12:12 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza I tested the use case and log directories were properly created. So ACK, works for me. Martin From mbabinsk at redhat.com Mon Jan 26 16:36:28 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 26 Jan 2015 17:36:28 +0100 Subject: [Freeipa-devel] [PATCH 0004] added dbus-python dependency to freeipa-client Message-ID: <54C66D0C.4020300@redhat.com> See attached patch related to https://fedorahosted.org/freeipa/ticket/4863. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0004-1-added-dbus-python-as-dependency-for-freeipa-client.patch Type: text/x-patch Size: 849 bytes Desc: not available URL: From mbasti at redhat.com Mon Jan 26 16:46:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 26 Jan 2015 17:46:38 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C63BB2.9060602@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> <54C0DCAC.8050409@redhat.com> <54C0E141.5080700@redhat.com> <54C10339.8080800@redhat.com> <54C27D2C.7000406@redhat.com> <54C63A3D.6040309@redhat.com> <54C63BB2.9060602@redhat.com> Message-ID: <54C66F6E.2040608@redhat.com> On 26/01/15 14:05, Martin Babinsky wrote: > On 01/26/2015 01:59 PM, Martin Babinsky wrote: >> On 01/23/2015 05:56 PM, Martin Basti wrote: >>> On 22/01/15 15:03, Martin Babinsky wrote: >>>> On 01/22/2015 12:38 PM, Martin Babinsky wrote: >>>>> On 01/22/2015 12:19 PM, Martin Kosek wrote: >>>>>> On 01/22/2015 11:58 AM, Martin Babinsky wrote: >>>>>>> On 01/22/2015 11:04 AM, Martin Babinsky wrote: >>>>>>>> The attached patch addresses >>>>>>>> https://fedorahosted.org/freeipa/ticket/4487. >>>>>>>> >>>>>>>> Using 'remove-ds.pl' script from 389-ds during server/replica >>>>>>>> uninstallation should allow for cleaner removal of DS instance >>>>>>>> with no >>>>>>>> leftovers (opened ports etc). >>>>>>>> >>>>>>>> Martin^3 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> >>>>>>> Thanks to Martin^2 for explaining the rules governing the placement >>>>>>> of new >>>>>>> attributes into BasePathNamespace class. >>>>>>> >>>>>>> Attaching updated patch. >>>>>>> >>>>>>> Martin^3 >>>>>> >>>>>> I see you kept erase_ds_instance_data still in the dsinstance. >>>>>> What is >>>>>> the >>>>>> motivation? I thought that just like with PKI, with DS we will also >>>>>> have >>>>>> uninstall based solely only on the DS uninstall script and remove >>>>>> our >>>>>> custom >>>>>> removal. >>>>>> >>>>>> We can keep the manual removal somewhere in wiki, but I would >>>>>> personally not >>>>>> keep/maintain it in FreeIPA code. >>>>>> >>>>> I originally thought that I will keep erase_ds_instance-data as a >>>>> failsafe method to clean up the dirsrv data in th case that >>>>> remove-ds.pl >>>>> fails. >>>>> >>>>> But I will remove the method altogether and change the code so >>>>> that it >>>>> prints out some warning about manual removal of DS data when >>>>> remove-ds.pl fails. >>>>> >>>>> Martin^2 >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Updated patch attached >>>> >>>> Martin^3 >>>> >>> >>> Hi, >>> >>> thank you for patch, but I have a few nitpicks: >>> >>> 1) Extra parenthesis >>> + root_logger.error(("Failed to remove CA DS instance. >>> You may " >>> + "need to remove instance data >>> manually")) >>> >>> and (twice) >>> >>> + root_logger.error(("Failed to remove DS instance. You >>> may " >>> + "need to remove instance data >>> manually")) >>> >>> and >>> >>> + root_logger.debug(("'%s' failed. " >>> + "Attempting to force removal" % >>> paths.REMOVE_DS_PL)) >>> >>> 2) Remove unused paths: >>> USR_LIB_DIRSRV_SLAPD_INSTANCE_DIR_TEMPLATE >>> SLAPD_INSTANCE_LOCK_TEMPLATE >>> USR_LIB_SLAPD_INSTANCE_TEMPLATE >>> >>> Please do double check. >>> >>> 3) IMO we should avoid hardcoded value 'slapd' >>> instance_name = '-'.join(['slapd', serverid]) >>> >>> you may create module variable DS_INSTANCE_PREFIX and use it. Dont >>> forget to change it in following place as well. >>> ipaserver/install/dsinstance.py:117: instance_prefix = 'slapd-' >>> >>> 4) >>> DS keytab hasn't been removed, it is okay? >>> It is created by IPA (krbinstance), not by DS install script. >>> >>> >>> Martin^2 >>> >> Thanks for suggestions, attaching updated patch >> >> Martin^3 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Missed one little thing. Attaching updated patch. > > Martin^3 Thank you, ACK. -- Martin Basti From edewata at redhat.com Mon Jan 26 19:14:43 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 26 Jan 2015 13:14:43 -0600 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <5459F68C.20005@redhat.com> References: <543F429C.2040006@redhat.com> <544034B2.5010609@redhat.com> <54480DD5.10504@redhat.com> <54501A0F.30805@redhat.com> <545871D0.5070608@redhat.com> <54590EB1.1070203@redhat.com> <54596E3A.9060404@redhat.com> <5459F68C.20005@redhat.com> Message-ID: <54C69223.1070208@redhat.com> Sorry for the long delay. Attached is an updated patch addressing most of the concerns. I think the rest can be addressed in subsequent patches. On 11/5/2014 4:06 AM, Petr Viktorin wrote: >>> ipapython/dn.py: This change is not needed. If you have a sequence of >>> RNDs you can do `DN(*seq)`. >> >> This is actually needed to construct a parent DN from an existing DN: >> >> parent_dn = DN(dn[1:]) >> > Right, for that you can do > parent_dn = DN(*dn[1:]) > (note the asterisk) Fixed. >> All existing plugins are actually using LDAPObject directly, not >> baseldap.LDAPObject. Is there a concern doing that? I fixed the code to >> do the same thing. > > Your choice. > If there are many objects imported from a module I prefer importing the > module itself, but individual names work too. For now I'll keep it consistent with the other plugins. There aren't that many objects imported, and it's easier to copy codes between plugins. >>> The pattern and pattern_errmsg for the 'cn' param don't match. Which one >>> is right? Shouldn't a similar check be there for parent? >> >> This is actually copied verbatim from user's uid. Could you give some >> sample values that show the problem? > > These messages are misleading: > > $ ipa vaultcontainer-add '$$' > ipa: ERROR: invalid 'container_name': may only include letters, numbers, > _, -, . and $ > $ ipa vaultcontainer-add -- '-myvault-' > ipa: ERROR: invalid 'container_name': may only include letters, numbers, > _, -, . and $ > > (Note that in webUI you wouldn't need the awkward quoting and `--`) > >> I think ideally there should be a similar check for parent, but I >> haven't figured out the proper pattern yet. I think we can do this as a >> later enhancement. Or maybe we should remove the validation for cn for >> now. > > Well, what are the PKI limitations on ids? > Are there any best practices for the id names? I don't think KRA itself puts any restrictions on the ID, but see the problem with get_active_key_info() below. > I think we want to limit the names to avoid nasty surprises later; > '[a-zA-Z0-9_.-]+' seems like a good set. > For parent you also need the slash, otherwise use the same pattern. > > I think this is quite an important decision; weird names could lead to > security issues. OK, I changed the container name to use that pattern and added slash in the parent's pattern. >>> vaultcontainer.get_dn: Why put '/' at the end of container_id, if the >>> empty string is ignored later anyway? >> >> I'm still considering some options for container ID: >> a) use a slash at the end for all containers (e.g. /users/) >> b) don't use a trailing slash, except for root container (/) >> >> Maybe a better way is to use an array of names internally and the slash >> is only used during input/output. The problem is when calling another >> command the array has to be converted into string and parsed back into >> array, so it may even introduce more redundancies. I don't see a way to >> pass an object parameter to a command. Any suggestion? > > That would indeed be better. Hopefully you can avoid re-parsing and > re-validating by not calling nested Commands, see below. > >>> In vaultcontainer.get_id, what's the purpose of the len() check? Did you >>> want dn.endswith() instead? >> >> Yes, but my assumption is the DN will always be within the namespace >> because it's only used internally, and using len() will be faster than >> endswith(). The error case will never happen, but I was just making sure >> there won't be an infinite loop. Maybe instead of calling the method >> recursively I should just use a loop? That will avoid repetitive >> validations. > > Well, if you end up with representing the id as a list the problem will > largely go away, but: use an internal error (e.g. ValueError) for > internal sanity checking. The public errors are for user errors, they > are presented "nicely" which makes them much harder to debug. And > "Invalid container DN" with no indication of what the DN is isn't > helpful to the user either. I revised the code to use endswith() and a loop instead of recursion, but I'm keeping the string ID for now. I changed the exception to ValueError and included the DN value. We can improve this later. >>> I sugggest writing doctests for the id manipulation methods (get_id, >>> get_private_id, ...) ? it's not always obvious what exactly they do. >> >> Do you mean sample code in docs? Is it still necessary if we have some >> test code? > > Not strictly necessary, but it better explains what the method does. I'm not sure how to write doctests for plugin objects/commands. I don't see any example in other plugins. Do I need to write the API initialization code? What if the output depends on the authenticated user? I suppose we can add this later. I already added some unit tests. >>> vaultcontainer_add: You should use ldap backend directly. Calling >>> Commands is costly, most of the call is spent doing validation of what >>> here is already validated. You should add a function to recursively >>> create vault container using just the ldap client, and call that here >>> and in vault_add. >> >> Hmm.. I'm not sure if we should write a code that will duplicate >> everything done by the LDAPCreate class. Shouldn't server-side >> command-to-command invocation be relatively faster? > > But you don't everything done by LDAPCreate. Most of what it does is > parsing options, validating options, formatting output. You don't even > use the added entry, after LDAPCreate spends an additional LDAP call to > re-retreive it after adding. > > Commands are not really designed to be nested, and tend to have subtle > assumptions of "owning" the current thread. > > Not to mention that debugging nested Command calls is a nightmare. > Imagine calling your own vault_retrieve from an unrelated command, and > getting a "Data not found." error, formatted for user consumption (e.g. > no traceback). > > (Yes, some parts of IPA do currently call nested commands. This is > unfortunate and leads to hard-to-debug issues.) I've removed the server-side nested command invocations (see below), but on the client-side I don't think it's avoidable. Some of the commands (e.g. vault-show, vault-transport-cert) provide basic functionalities that are used by other commands. >> The recursion is mainly used to create the user's private container. >> Note that the private container is not created by default. We only >> provide /users top-level container. When a user creates a private vault >> the command will automatically create the /users/ private >> container on the user's behalf. This will only happen once for each >> user. In most other cases the parent would already exist. >> >> Another option is to require the user or the admin to create the private >> container manually, but that would be less user-friendly. >> >> Another option is to check the parent container using direct LDAP >> search, but still do the add using vaultcontainer_add. What do you think? > > Why? Is adding the entry via ldap that hard to do? > What functionality from LDAPCreate do you need? Maybe we can pull it out > into a function. OK, I added the LDAP code. It's not about the complexity, but it's kind of breaking the encapsulation. Fortunately for this particular case the entry is simple enough that it can be constructed manually. >>> You can delete a container with children; is that expected? >> >> This seems to be LDAPDelete's built-in functionality. Is there an option >> to disallow non-empty subtree removal? >> >> For vault purposes, when a user is removed from IPA the server will >> remove the user's entire private container, so the feature would >> actually be useful here. But probably in general we should warn the user >> if they are deleting a non-empty container. If there's an option in >> LDAPDelete we can let the user specify that option if necessary. > > A warning doesn't seem very useful. ("Yes sir, deleted your data! Oh, by > the way, did you really want to do that?") > I think requiring a --force or --recursive option for non-empty trees > could better prevent surprises. Right, that's what I meant, but the problem is the current LDAPDelete will always remove the whole subtree without any option to prevent it. If I change the LDAPDelete's behavior it may affect other plugins. So for now I just refactored the LDAPDelete to allow vaultcontainer_del to override delete_entry() and control the behavior using --force option. Later on we can move this option to the base class if necessary. >>> vault_add should complain if it does not get exactly one of >>> data/text/in. Fixed. >> Actually, no. The primary way to archive data is via vault_archive. The >> vault_add is for creating a vault, but optionally you can specify the >> initial data to be archived. If nothing is specified it will archive an >> empty string. Note that for symmetric vault the encrypted empty string >> can be used to enforce that the same password will be used on on >> subsequent archival operations. > > Then the command should complain if is gets more than one type of input. Fixed the vault_archive too. > It still seems redundant to me. > If I'm getting it correctly, to change a vault's attributes like > description, you need vault_mod, but to change the stored secret you do > vault_archive. Is that right? Why not do all modifications in vault_mod? It's because during archival the data is actually stored into KRA, not in the vault LDAP entry, so it's not an LDAP modify operation. Also, for symmetric & asymmetric vaults there will be additional encryption parameters required (e.g. password, private key) to archive/retrieve data. A regular vault attribute modification would not need those parameters. > And if you do end up needing separate commands, you can pull the > communication with KRA into a function and call that, rather than > calling the whole Command machinery. > >> I'm trying to change vault_archive to raise an error if it's missing the >> input data and change vault_add to archive empty string if nothing is >> specified, but it doesn't work since the framework seems to be >> converting the empty string into None, so vault_archive can't tell if >> it's archiving an empty string or missing the input data. Any suggestion? Due to this limitation, for now if there's no input data specified it will archive an empty string, no errors raised. >>> What's the difference between vault_add and vault_archive? I don't see >>> vault_archive in the design. >> >> Yes, that's due to a recent 'standard vault' addition. I have not added >> vault_archive yet to the design. The vault_archive is used to archive a >> generic blob of data. The vaultsecret_archive will later be used to add >> secrets into a JSON structure which will then be archived using the >> vault_archive. > > Okay. I'm not sure I get the details right, a design would help. I added the following sections: http://www.freeipa.org/page/V4/Password_Vault_Implementation#Archiving_data http://www.freeipa.org/page/V4/Password_Vault_Implementation#Retrieving_data http://www.freeipa.org/page/V4/Password_Vault_Implementation#vaultsecret_archive.28.29 http://www.freeipa.org/page/V4/Password_Vault_Implementation#vaultsecret_retrieve.28.29 >>> It seems '/' is equivalent to '-' as far as KRA is concerned; should we >>> disallow '-' in container/vault names? >> >> I think so, but as I mentioned earlier I haven't look very far on >> attribute validations. >> >> The slashes in vault ID is converted into dashes in KRA's client key ID. >> KRA actually accepts slashes, but the slashes will not look pretty in >> REST URL because they will be URL-encoded (in case it's needed for >> troubleshooting KRA via browser) so I changed them to dashes. It turns out there's a also problem with get_active_key_info() processing the slashes. This is a Dogtag issue. I've changed the code to use list_keys() which doesn't suffer from the same problem. > So it seems that these IDs would be equivalent for the KRA: > > /users/admin/private/secret > /users/admin-private/secret > > If this is just for troubleshooting purposes, please don't change to > dashes. After changing to list_keys() I can use the slashes without problems. >>> You can specify an absolute id by starting it with a slash, but only in >>> --parent and not in the name itself. I think this should be possible in >>> the name too. >> >> Right, but I'm not sure how it will work with the IPA framework. The >> first command parameter is the cn (vault name). If we specify a vault ID >> (with slashes) there it will be entered into cn. Should we parse the ID >> and insert the vault name and parent ID back into keys and options >> variables? Which value will eventually be stored into cn in LDAP? > > You're right, managing that would need some delicate coding. > > But I you could override args_options_2_params to adjust the options > before they're even validated, so the framework gets cn and parent as it > does currently. > >>> You can't include slashes in the name, so you always need to specify the >>> prefix with --parent. I don't think there's a technical reason for this >>> limitation. I think it can be confusing. If we define vault name to allow slashes, people might think slashes are valid characters of vault names when actually they are only delimiters. Maybe in a separate patch later we can try changing the argument from vault name to vault ID. >>> There are no tests. >> >> Right, I'll take a look at how to write tests. Is there a way to run >> tests without running the full build? > > Yes, see http://www.freeipa.org/page/Testing > (Though I usually just copy changed files to /usr/lib/ and restart Apache) OK. Added some tests. -- Endi S. Dewata -------------- next part -------------- >From 3290436d6bce38476519c354c0017b5cd1b81d3a Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added initial vault implementation. This patch provides the initial vault implementation which allows the admin to create a vault, archive data, and retrieve data using a standard vault. It also includes the initial LDAP schema. It currently has limitations including: - The vault only supports the standard vault type. - The vault can only be used by the admin user. - The transport certificate has to be installed manually. These limitations, other vault features, schema and ACL changes will be addressed in subsequent patches. The LDAPDelete has been refactored to allow overriding the subtree deletion behavior. A test script have been added as well. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 169 +++++ VERSION | 4 +- install/share/60basev3.ldif | 2 + install/updates/40-vault.update | 23 + install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/baseldap.py | 78 +-- ipalib/plugins/user.py | 9 + ipalib/plugins/vault.py | 1003 +++++++++++++++++++++++++++++ ipatests/test_xmlrpc/test_vault_plugin.py | 614 ++++++++++++++++++ 11 files changed, 1865 insertions(+), 40 deletions(-) create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py create mode 100644 ipatests/test_xmlrpc/test_vault_plugin.py diff --git a/API.txt b/API.txt index 08615c80476171695dac262575c4e20e72615c36..559f4b97fad334f037cb61bbb787f7dfcbd6e23c 100644 --- a/API.txt +++ b/API.txt @@ -4517,6 +4517,175 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('data?', cli_name='data') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('in?', cli_name='in') +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('text?', cli_name='text') +option: Str('vault_id', attribute=False, cli_name='vault_id', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_archive +args: 1,11,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('data?', cli_name='data') +option: Bytes('encrypted_data?', cli_name='encrypted_data') +option: Str('in?', cli_name='in') +option: Bytes('nonce?', cli_name='nonce') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('text?', cli_name='text') +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('vault_id', attribute=False, autofill=False, cli_name='vault_id', multivalue=False, query=True, required=False) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('vault_id', attribute=False, autofill=False, cli_name='vault_id', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_retrieve +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('out?', cli_name='out') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Flag('show_text?', autofill=True, default=False) +option: Flag('stdout?', autofill=True, default=False) +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_add +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('container_id', attribute=False, cli_name='container_id', multivalue=False, required=False) +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_del +args: 1,4,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Flag('force?', autofill=True, default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vaultcontainer_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) +option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vaultcontainer_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, required=False) +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index f587c65c8868a1693d2b19fb4dae97b7cdd4c65a..5acbd7bafee959b97ce2a6584646b5bfb58199d3 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=112 -# Last change: tbabej - change ipaassignedidview to Str +IPA_API_VERSION_MINOR=113 +# Last change: edewata - initial vault implementation diff --git a/install/share/60basev3.ldif b/install/share/60basev3.ldif index 4efb1fe8ba8a91d3a8b920d39d217124066728c0..e0bc4151d88fc394cea0d81a20d8da9537dd5cd3 100644 --- a/install/share/60basev3.ldif +++ b/install/share/60basev3.ldif @@ -77,3 +77,5 @@ objectClasses: (2.16.840.1.113730.3.8.12.24 NAME 'ipaPublicKeyObject' DESC 'Wrap objectClasses: (2.16.840.1.113730.3.8.12.25 NAME 'ipaPrivateKeyObject' DESC 'Wrapped private keys' SUP top AUXILIARY MUST ( ipaPrivateKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.26 NAME 'ipaSecretKeyObject' DESC 'Wrapped secret keys' SUP top AUXILIARY MUST ( ipaSecretKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect storage for encoded key material' SUP top AUXILIARY MUST ( ipaSecretKeyRef ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' DESC 'IPA vault' SUP top STRUCTURAL MUST ( cn ) MAY ( description ) X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' DESC 'IPA vault container' SUP top STRUCTURAL MUST ( cn ) MAY ( description ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..dac2f67112dc33f012c6d559285464fb7c944d1a --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,23 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: ipaVaultContainer +default: cn: vaults +default: description: Root vault container + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: ipaVaultContainer +default: cn: services +default: description: Services vault container + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: ipaVaultContainer +default: cn: shared +default: description: Shared vault container + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: ipaVaultContainer +default: cn: users +default: description: Users vault container diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 40de5635621071d34b6475d51ca598ed41a8ba09..34bb0981c44a3fcc3242401873769f332b95988b 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index 50a2b1f7aa7f0d447bacfd005b102c7451e670ce..baaf9be8d0329e89cb92a03de302095fe7acb847 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -97,6 +97,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index 4b1c701924d57919538e0c428ea181c2e898505e..d693709ac1ba7ddb3c559199c199039b6f8bd9ac 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -1498,48 +1498,50 @@ class LDAPDelete(LDAPMultiQuery): has_output_params = global_output_params - def execute(self, *keys, **options): + def delete_subtree(self, base_dn, *nkeys, **options): ldap = self.obj.backend - - def delete_entry(pkey): - nkeys = keys[:-1] + (pkey, ) - dn = self.obj.get_dn(*nkeys, **options) - assert isinstance(dn, DN) - - for callback in self.get_callbacks('pre'): - dn = callback(self, ldap, dn, *nkeys, **options) - assert isinstance(dn, DN) - - def delete_subtree(base_dn): - assert isinstance(base_dn, DN) - truncated = True - while truncated: - try: - (subentries, truncated) = ldap.find_entries( - None, [''], base_dn, ldap.SCOPE_ONELEVEL - ) - except errors.NotFound: - break - else: - for entry_attrs in subentries: - delete_subtree(entry_attrs.dn) - try: - self._exc_wrapper(nkeys, options, ldap.delete_entry)(base_dn) - except errors.NotFound: - self.obj.handle_not_found(*nkeys) - + assert isinstance(base_dn, DN) + truncated = True + while truncated: try: - self._exc_wrapper(nkeys, options, ldap.delete_entry)(dn) + (subentries, truncated) = ldap.find_entries( + None, [''], base_dn, ldap.SCOPE_ONELEVEL + ) except errors.NotFound: - self.obj.handle_not_found(*nkeys) - except errors.NotAllowedOnNonLeaf: - # this entry is not a leaf entry, delete all child nodes - delete_subtree(dn) + break + else: + for entry_attrs in subentries: + self.delete_subtree(entry_attrs.dn, *nkeys, **options) + try: + self._exc_wrapper(nkeys, options, ldap.delete_entry)(base_dn) + except errors.NotFound: + self.obj.handle_not_found(*nkeys) - for callback in self.get_callbacks('post'): - result = callback(self, ldap, dn, *nkeys, **options) + def delete_entry(self, pkey, *keys, **options): + ldap = self.obj.backend + nkeys = keys[:-1] + (pkey, ) + dn = self.obj.get_dn(*nkeys, **options) + assert isinstance(dn, DN) - return result + for callback in self.get_callbacks('pre'): + dn = callback(self, ldap, dn, *nkeys, **options) + assert isinstance(dn, DN) + + try: + self._exc_wrapper(nkeys, options, ldap.delete_entry)(dn) + except errors.NotFound: + self.obj.handle_not_found(*nkeys) + except errors.NotAllowedOnNonLeaf: + # this entry is not a leaf entry, delete all child nodes + self.delete_subtree(dn, *nkeys, **options) + + for callback in self.get_callbacks('post'): + result = callback(self, ldap, dn, *nkeys, **options) + + return result + + def execute(self, *keys, **options): + ldap = self.obj.backend if self.obj.primary_key and isinstance(keys[-1], (list, tuple)): pkeyiter = keys[-1] @@ -1552,7 +1554,7 @@ class LDAPDelete(LDAPMultiQuery): failed = [] for pkey in pkeyiter: try: - delete_entry(pkey) + self.delete_entry(pkey, *keys, **options) except errors.ExecutionError: if not options.get('continue', False): raise diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index 56585b9f86593c0c5879139103bc71707b88e15f..7322e2b69efbcc0a655caeb9e0863ad93dbf1ce9 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -901,6 +901,15 @@ class user_del(LDAPDelete): else: self.api.Command.otptoken_del(token) + # Delete user's private vault container. + vaultcontainer_id = self.api.Object.vaultcontainer.get_private_id(owner) + (vaultcontainer_name, vaultcontainer_parent_id) = self.api.Object.vaultcontainer.split_id(vaultcontainer_id) + + try: + self.api.Command.vaultcontainer_del(vaultcontainer_name, parent=vaultcontainer_parent_id) + except errors.NotFound: + pass + return dn diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..25372d0f02058fb5efd9f5dece96073ea1d78646 --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,1003 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +import base64 +import json +import os +import random +import shutil +import string +import tempfile + +import pki +import pki.account +import pki.crypto +import pki.key + +from ipalib import api, errors +from ipalib import Str, Bytes, Flag +from ipalib.frontend import Command +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete, LDAPSearch, LDAPUpdate, LDAPRetrieve +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipaplatform.paths import paths +from ipapython.dn import DN +import ipapython.nsslib + +__doc__ = _(""" +Vaults +""") + _(""" +Manage vaults and vault containers. +""") + _(""" +EXAMPLES: +""") + _(""" + List private vaults: + ipa vault-find +""") + _(""" + List shared vaults: + ipa vault-find --parent /shared +""") + _(""" + Add a standard vault: + ipa vault-add MyVault +""") + _(""" + Show a vault: + ipa vault-show MyVault +""") + _(""" + Modify a vault: + ipa vault-mod MyVault --desc "My vault" +""") + _(""" + Archive data into standard vault: + ipa vault-archive MyVault --in data.bin +""") + _(""" + Retrieve data from standard vault: + ipa vault-retrieve MyVault --out data.bin +""") + _(""" + Delete a vault: + ipa vault-del MyVault +""") + _(""" + List private vault containers: + ipa vaultcontainer-find +""") + _(""" + List top-level vault containers: + ipa vaultcontainer-find --parent / +""") + _(""" + Add a vault container: + ipa vaultcontainer-add MyContainer +""") + _(""" + Show a vault container: + ipa vaultcontainer-show MyContainer +""") + _(""" + Modify a vault container: + ipa vaultcontainer-mod MyContainer --desc "My container" +""") + _(""" + Delete a vault container: + ipa vaultcontainer-del MyContainer +""") + +register = Registry() +transport_cert_nickname = 'KRA Transport Certificate' + + at register() +class vaultcontainer(LDAPObject): + __doc__ = _(""" + Vault container object. + """) + + base_dn = DN(api.env.container_vault, api.env.basedn) + object_name = _('vault container') + object_name_plural = _('vault containers') + + object_class = ['ipaVaultContainer'] + default_attributes = [ + 'cn', + 'container_id', + 'description', + ] + search_display_attributes = [ + 'cn', + 'container_id', + 'description', + ] + + label = _('Vault Containers') + label_singular = _('Vault Container') + + takes_params = ( + Str('cn', + cli_name='container_name', + label=_('Container name'), + primary_key=True, + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + pattern='^[a-zA-Z0-9_.-/]+$', + pattern_errmsg='may only include letters, numbers, _, ., -, and /', + ), + Str('container_id?', + cli_name='container_id', + label=_('Container ID'), + doc=_('Container ID'), + flags=('virtual_attribute'), + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Container description'), + ), + ) + + def get_dn(self, *keys, **options): + __doc__ = _(""" + Generates vault container DN from container ID. + """) + + # get container ID from parameters + name = None + if keys: + name = keys[0] + + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + container_id = parent_id + if name: + container_id = parent_id + name + u'/' + + dn = self.base_dn + + # for each name in the ID, prepend the base DN + for name in container_id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + def get_id(self, dn): + __doc__ = _(""" + Generates container ID from container DN. + """) + + # make sure the DN is a container DN + if not dn.endswith(self.base_dn): + raise ValueError('Invalid container DN: %s' % dn) + + # construct container ID from the bottom up + id = u'/' + while len(dn) > len(self.base_dn): + + rdn = dn[0] + name = rdn['cn'] + id = u'/' + name + id + + dn = DN(*dn[1:]) + + return id + + def get_private_id(self, username=None): + __doc__ = _(""" + Returns user's private container ID (i.e. /users//). + """) + + if not username: + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + + return u'/users/' + username + u'/' + + def normalize_id(self, id): + __doc__ = _(""" + Normalizes container ID. + """) + + # if ID is empty, return user's private container ID + if not id: + return self.get_private_id() + + # make sure ID ends with slash + if not id.endswith(u'/'): + id += u'/' + + # if it's an absolute ID, do nothing + if id.startswith(u'/'): + return id + + # otherwise, prepend with user's private container ID + return self.get_private_id() + id + + def split_id(self, id): + __doc__ = _(""" + Splits a normalized container ID into (container name, parent ID) tuple. + """) + + # handle root ID + if id == u'/': + return (None, None) + + # split ID into parent ID, container name, and empty string + parts = id.rsplit(u'/', 2) + + # return container name and parent ID + return (parts[1], parts[0] + u'/') + + + at register() +class vaultcontainer_add(LDAPCreate): + __doc__ = _('Create a new vault container.') + + msg_summary = _('Added vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + assert isinstance(dn, DN) + + # add parent containers if they don't exist + try: + ldap = self.obj.backend + + while True: + parent_dn = DN(*dn[1:]) + parent_rdn = parent_dn[0] + + parent = ldap.make_entry( + parent_dn, + { + 'objectclass': api.Object.vaultcontainer.object_class, + 'cn': parent_rdn['cn'], + }) + + ldap.add_entry(parent) + + except errors.DuplicateEntry: + pass + + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vaultcontainer_del(LDAPDelete): + __doc__ = _('Delete a vault container.') + + msg_summary = _('Deleted vault container "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Flag('force?', + doc=_('Force deletion'), + autofill=False, + ), + ) + + def delete_entry(self, pkey, *keys, **options): + __doc__ = _(""" + Overwrites the base method to control deleting subtree with force option. + """) + + ldap = self.obj.backend + nkeys = keys[:-1] + (pkey, ) + dn = self.obj.get_dn(*nkeys, **options) + assert isinstance(dn, DN) + + for callback in self.get_callbacks('pre'): + dn = callback(self, ldap, dn, *nkeys, **options) + assert isinstance(dn, DN) + + try: + self._exc_wrapper(nkeys, options, ldap.delete_entry)(dn) + except errors.NotFound: + self.obj.handle_not_found(*nkeys) + except errors.NotAllowedOnNonLeaf: + # this entry is not a leaf entry + # if forced, delete all child nodes + if options.get('force'): + self.delete_subtree(dn, *nkeys, **options) + else: + raise + + for callback in self.get_callbacks('post'): + result = callback(self, ldap, dn, *nkeys, **options) + + return result + + + at register() +class vaultcontainer_find(LDAPSearch): + __doc__ = _('Search for vault containers.') + + msg_summary = ngettext( + '%(count)d vault container matched', '%(count)d vault containers matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + assert isinstance(base_dn, DN) + + parent_id = self.obj.normalize_id(options.get('parent')) + base_dn = self.obj.get_dn(parent=parent_id) + + return (filter, base_dn, scope) + + def post_callback(self, ldap, entries, truncated, *args, **options): + + for entry in entries: + entry['container_id'] = self.obj.get_id(entry.dn) + + return truncated + + + at register() +class vaultcontainer_mod(LDAPUpdate): + __doc__ = _('Modify a vault container.') + + msg_summary = _('Modified vault container "%(value)s"') + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vaultcontainer_show(LDAPRetrieve): + __doc__ = _('Display information about a vault container.') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault(LDAPObject): + __doc__ = _(""" + Vault object. + """) + + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', + 'vault_id', + 'description', + ] + search_display_attributes = [ + 'cn', + 'vault_id', + 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str('cn', + cli_name='vault_name', + label=_('Vault name'), + primary_key=True, + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + pattern='^[a-zA-Z0-9_.-/]+$', + pattern_errmsg='may only include letters, numbers, _, ., -, and /', + ), + Str('vault_id?', + cli_name='vault_id', + label=_('Vault ID'), + doc=_('Vault ID'), + flags=('virtual_attribute'), + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + ) + + def get_dn(self, *keys, **options): + __doc__ = _(""" + Generates vault DN from vault ID. + """) + + # get vault ID from parameters + name = None + if keys: + name = keys[0] + + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + vault_id = parent_id + if name: + vault_id = parent_id + name + + dn = api.Object.vaultcontainer.base_dn + + # for each name in the ID, prepend the base DN + for name in vault_id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + def get_id(self, dn): + __doc__ = _(""" + Generates vault ID from vault DN. + """) + + # make sure the DN is a vault DN + if not dn.endswith(api.Object.vaultcontainer.base_dn): + raise ValueError('Invalid vault DN: %s' % dn) + + # vault DN cannot be the container base DN + if len(dn) == len(api.Object.vaultcontainer.base_dn): + raise ValueError('Invalid vault DN: %s' % dn) + + # construct the vault ID from the bottom up + id = u'' + while len(dn) > len(api.Object.vaultcontainer.base_dn): + + rdn = dn[0] + name = rdn['cn'] + id = u'/' + name + id + + dn = DN(*dn[1:]) + + return id + + def split_id(self, id): + __doc__ = _(""" + Splits a vault ID into (vault name, parent ID) tuple. + """) + + # split ID into parent ID and vault name + parts = id.rsplit(u'/', 1) + + # return vault name and parent ID + return (parts[1], parts[0] + u'/') + + def get_kra_id(self, id): + __doc__ = _(""" + Generates a client key ID to store/retrieve data in KRA. + """) + return 'ipa' + id + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Bytes('data?', + cli_name='data', + doc=_('Base-64 encoded binary data to archive'), + ), + Str('text?', + cli_name='text', + doc=_('Text data to archive'), + ), + Str('in?', + cli_name='in', + doc=_('File containing data to archive'), + ), + ) + + msg_summary = _('Added vault "%(value)s"') + + def forward(self, *args, **options): + + vault_name = args[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + data = options.get('data') + text = options.get('text') + input_file = options.get('in') + + # don't send these parameters to server + if 'data' in options: + del options['data'] + if 'text' in options: + del options['text'] + if 'in' in options: + del options['in'] + + # get data + if data: + if text: + raise errors.ValidationError(name='text', + error=_('Input data already specified')) + + if input_file: + raise errors.ValidationError(name='input_file', + error=_('Input data already specified')) + + elif text: + if input_file: + raise errors.ValidationError(name='input_file', + error=_('Input data already specified')) + + data = text.encode('utf-8') + + elif input_file: + with open(input_file, 'rb') as f: + data = f.read() + + else: + data = '' + + # create the vault + response = super(vault_add, self).forward(*args, **options) + + # archive initial data + api.Command.vault_archive( + vault_name, + parent=parent_id, + data=data) + + return response + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + assert isinstance(dn, DN) + + # add parent containers if they don't exist + try: + ldap = self.obj.backend + + while True: + parent_dn = DN(*dn[1:]) + parent_rdn = parent_dn[0] + + parent = ldap.make_entry( + parent_dn, + { + 'objectclass': api.Object.vaultcontainer.object_class, + 'cn': parent_rdn['cn'], + }) + + ldap.add_entry(parent) + + except errors.DuplicateEntry: + pass + + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + msg_summary = _('Deleted vault "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, dn, *keys, **options): + assert isinstance(dn, DN) + + vault_id = self.obj.get_id(dn) + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = self.api.Object.vault.get_kra_id(vault_id) + + # deactivate vault record in KRA + response = kra_client.keys.list_keys(client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) + + for key_info in response.key_infos: + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + kra_account.logout() + + return True + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + msg_summary = ngettext( + '%(count)d vault matched', '%(count)d vaults matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + assert isinstance(base_dn, DN) + + parent_id = self.Object.vaultcontainer.normalize_id(options.get('parent')) + base_dn = self.Object.vaultcontainer.get_dn(parent=parent_id) + + return (filter, base_dn, scope) + + + def post_callback(self, ldap, entries, truncated, *args, **options): + + for entry in entries: + entry['vault_id'] = self.obj.get_id(entry.dn) + + return truncated + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + msg_summary = _('Modified vault "%(value)s"') + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return dn + + + at register() +class vault_archive(LDAPRetrieve): + __doc__ = _('Archive data into a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Bytes('data?', + cli_name='data', + doc=_('Base-64 encoded binary data to archive'), + ), + Str('text?', + cli_name='text', + doc=_('Text data to archive'), + ), + Str('in?', + cli_name='in', + doc=_('File containing data to archive'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + Bytes('encrypted_data?', + cli_name='encrypted_data', + doc=_('Data encrypted with session key and encoded in base-64'), + ), + Bytes('nonce?', + cli_name='nonce', + doc=_('Nonce encrypted encoded in base-64'), + ), + ) + + msg_summary = _('Archived data into vault "%(value)s"') + + def forward(self, *args, **options): + + vault_name = args[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + data = options.get('data') + text = options.get('text') + input_file = options.get('in') + + # don't send these parameters to server + if 'data' in options: + del options['data'] + if 'text' in options: + del options['text'] + if 'in' in options: + del options['in'] + + # get data + if data: + if text: + raise errors.ValidationError(name='text', + error=_('Input data already specified')) + + if input_file: + raise errors.ValidationError(name='input_file', + error=_('Input data already specified')) + + elif text: + if input_file: + raise errors.ValidationError(name='input_file', + error=_('Input data already specified')) + + data = text.encode('utf-8') + + elif input_file: + with open(input_file, 'rb') as f: + data = f.read() + + else: + data = '' + + # initialize NSS database + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + # generate session key + session_key = crypto.generate_session_key() + + # retrieve transport certificate + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + # wrap session key with transport certificate + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + # encrypt data with session key + nonce = crypto.generate_nonce_iv() + encrypted_data = crypto.symmetric_wrap( + data, + session_key, + nonce_iv=nonce + ) + + # send archival request to server + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + options['encrypted_data'] = base64.b64encode(encrypted_data) + options['nonce'] = base64.b64encode(nonce) + + return super(vault_archive, self).forward(*args, **options) + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + vault_id = self.obj.get_id(dn) + entry_attrs['vault_id'] = vault_id + + # connect to KRA + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = self.api.Object.vault.get_kra_id(vault_id) + + # deactivate existing vault record in KRA + response = kra_client.keys.list_keys(client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) + + for key_info in response.key_infos: + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + encrypted_data = base64.b64decode(options['encrypted_data']) + nonce = base64.b64decode(options['nonce']) + + # forward encrypted data to KRA + kra_client.keys.archive_encrypted_data( + client_key_id, + pki.key.KeyClient.PASS_PHRASE_TYPE, + encrypted_data, + wrapped_session_key, + None, + nonce, + ) + + kra_account.logout() + + return dn + + + at register() +class vault_retrieve(LDAPRetrieve): + __doc__ = _('Retrieve a data from a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Flag('show_text?', + doc=_('Show text data'), + autofill=False, + ), + Flag('stdout?', + doc=_('Show data on standard output'), + autofill=False, + ), + Str('out?', + cli_name='out', + doc=_('File to store retrieved data'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + ) + + has_output_params = ( + Bytes('data', + label=_('Data'), + ), + Bytes('text', + label=_('Text'), + ), + ) + + msg_summary = _('Retrieved data from vault "%(value)s"') + + def forward(self, *args, **options): + + vault_name = args[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + + show_text = options.get('show_text') + stdout = options.get('stdout') + output_file = options.get('out') + + # don't send these parameters to server + if 'show_text' in options: + del options['show_text'] + if 'stdout' in options: + del options['stdout'] + if 'out' in options: + del options['out'] + + # initialize NSS database + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + # generate session key + session_key = crypto.generate_session_key() + + # retrieve transport certificate + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + # wrap session key with transport certificate + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + # send retrieval request to server + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + + response = super(vault_retrieve, self).forward(*args, **options) + + encrypted_data = base64.b64decode(response['result']['encrypted_data']) + nonce = base64.b64decode(response['result']['nonce']) + + # decrypt encrypted data with session key + data = crypto.symmetric_unwrap( + encrypted_data, + session_key, + nonce_iv=nonce) + + if stdout: + print data + response['result'] = {} + response['summary'] = None + + elif output_file: + with open(output_file, 'w') as f: + f.write(data) + + elif show_text: + response['result']['text'] = unicode(data) + + else: + response['result']['data'] = data + + return response + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + vault_id = self.obj.get_id(dn) + entry_attrs['vault_id'] = vault_id + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + + # connect to KRA + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = self.api.Object.vault.get_kra_id(vault_id) + + # find vault record in KRA + response = kra_client.keys.list_keys(client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) + + if not len(response.key_infos): + raise errors.NotFound(reason=_('Missing archived data.')) + + key_info = response.key_infos[0] + + # retrieve encrypted data from KRA + key = kra_client.keys.retrieve_key( + key_info.get_key_id(), + wrapped_session_key) + + entry_attrs['encrypted_data'] = base64.b64encode(key.encrypted_data) + entry_attrs['nonce'] = base64.b64encode(key.nonce_data) + + kra_account.logout() + + return dn diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py new file mode 100644 index 0000000000000000000000000000000000000000..01896ce1811dd8b3829bc266ff288494fdb3746f --- /dev/null +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -0,0 +1,614 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +""" +Test the `ipalib/plugins/vault.py` module. +""" + +from ipalib import api, errors +from xmlrpc_test import Declarative, fuzzy_string + +private_container = u'private_container' +shared_container = u'shared_container' +service_container = u'service_container' + +base_container = u'base_container' +child_container = u'child_container' +grandchild_container = u'grandchild_container' + +private_vault = u'private_vault' + +class test_vault(Declarative): + + cleanup_commands = [ + ('vaultcontainer_del', [private_container], {'continue': True}), + ('vaultcontainer_del', [shared_container], {'parent': u'/shared/', 'continue': True}), + ('vaultcontainer_del', [service_container], {'parent': u'/services/', 'continue': True}), + ('vaultcontainer_del', [base_container], {'force': True, 'continue': True}), + ('vault_del', [private_vault], {'continue': True}), + ] + + tests = [ + + { + 'desc': 'Find top-level containers', + 'command': ( + 'vaultcontainer_find', + [], + { + 'parent': u'/', + }, + ), + 'expected': { + 'count': 3, + 'truncated': False, + 'summary': u'3 vault containers matched', + 'result': [ + { + 'dn': u'cn=services,cn=vaults,%s' % api.env.basedn, + 'cn': [u'services'], + 'container_id': u'/services/', + 'description': [u'Services vault container'], + }, + { + 'dn': u'cn=shared,cn=vaults,%s' % api.env.basedn, + 'cn': [u'shared'], + 'container_id': u'/shared/', + 'description': [u'Shared vault container'], + }, + { + 'dn': u'cn=users,cn=vaults,%s' % api.env.basedn, + 'cn': [u'users'], + 'container_id': u'/users/', + 'description': [u'Users vault container'], + }, + ], + }, + }, + + { + 'desc': 'Create private container', + 'command': ( + 'vaultcontainer_add', + [private_container], + {}, + ), + 'expected': { + 'value': private_container, + 'summary': 'Added vault container "%s"' % private_container, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_container, api.env.basedn), + 'objectclass': (u'ipaVaultContainer', u'top'), + 'cn': [private_container], + 'container_id': u'/users/admin/%s/' % private_container, + }, + }, + }, + + { + 'desc': 'Create duplicate container', + 'command': ( + 'vaultcontainer_add', + [private_container], + {}, + ), + 'expected': errors.DuplicateEntry(message=u'vault container with name "%s" already exists' % private_container), + }, + + { + 'desc': 'Find private containers', + 'command': ( + 'vaultcontainer_find', + [], + {}, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault container matched', + 'result': [ + { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_container, api.env.basedn), + 'cn': [private_container], + 'container_id': u'/users/admin/%s/' % private_container, + }, + ], + }, + }, + + { + 'desc': 'Show private container', + 'command': ( + 'vaultcontainer_show', + [private_container], + {}, + ), + 'expected': { + 'value': private_container, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_container, api.env.basedn), + 'cn': [private_container], + 'container_id': u'/users/admin/%s/' % private_container, + }, + }, + }, + + { + 'desc': 'Modify private container', + 'command': ( + 'vaultcontainer_mod', + [private_container], + { + 'description': u'Private container', + }, + ), + 'expected': { + 'value': private_container, + 'summary': 'Modified vault container "%s"' % private_container, + 'result': { + 'cn': [private_container], + 'container_id': u'/users/admin/%s/' % private_container, + 'description': [u'Private container'], + }, + }, + }, + + { + 'desc': 'Delete private container', + 'command': ( + 'vaultcontainer_del', + [private_container], + {}, + ), + 'expected': { + 'value': [private_container], + 'summary': u'Deleted vault container "%s"' % private_container, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Delete non-existent container', + 'command': ( + 'vaultcontainer_del', + [private_container], + {}, + ), + 'expected': errors.NotFound(reason=u'%s: vault container not found' % private_container), + }, + + { + 'desc': 'Create shared container', + 'command': ( + 'vaultcontainer_add', + [shared_container], + { + 'parent': u'/shared/', + }, + ), + 'expected': { + 'value': shared_container, + 'summary': 'Added vault container "%s"' % shared_container, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' % (shared_container, api.env.basedn), + 'objectclass': (u'ipaVaultContainer', u'top'), + 'cn': [shared_container], + 'container_id': u'/shared/%s/' % shared_container, + }, + }, + }, + + { + 'desc': 'Find shared containers', + 'command': ( + 'vaultcontainer_find', + [], + { + 'parent': u'/shared/', + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault container matched', + 'result': [ + { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' % (shared_container, api.env.basedn), + 'cn': [shared_container], + 'container_id': u'/shared/%s/' % shared_container, + }, + ], + }, + }, + + { + 'desc': 'Show shared container', + 'command': ( + 'vaultcontainer_show', + [shared_container], + { + 'parent': u'/shared/', + }, + ), + 'expected': { + 'value': shared_container, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,%s' % (shared_container, api.env.basedn), + 'cn': [shared_container], + 'container_id': u'/shared/%s/' % shared_container, + }, + }, + }, + + { + 'desc': 'Modify shared container', + 'command': ( + 'vaultcontainer_mod', + [shared_container], + { + 'parent': u'/shared/', + 'description': u'shared container', + }, + ), + 'expected': { + 'value': shared_container, + 'summary': 'Modified vault container "%s"' % shared_container, + 'result': { + 'cn': [shared_container], + 'container_id': u'/shared/%s/' % shared_container, + 'description': [u'shared container'], + }, + }, + }, + + { + 'desc': 'Delete shared container', + 'command': ( + 'vaultcontainer_del', + [shared_container], + { + 'parent': u'/shared/', + }, + ), + 'expected': { + 'value': [shared_container], + 'summary': u'Deleted vault container "%s"' % shared_container, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create service container', + 'command': ( + 'vaultcontainer_add', + [service_container], + { + 'parent': u'/services/', + }, + ), + 'expected': { + 'value': service_container, + 'summary': 'Added vault container "%s"' % service_container, + 'result': { + 'dn': u'cn=%s,cn=services,cn=vaults,%s' % (service_container, api.env.basedn), + 'objectclass': (u'ipaVaultContainer', u'top'), + 'cn': [service_container], + 'container_id': u'/services/%s/' % service_container, + }, + }, + }, + { + 'desc': 'Create base container', + 'command': ( + 'vaultcontainer_add', + [base_container], + {}, + ), + 'expected': { + 'value': base_container, + 'summary': 'Added vault container "%s"' % base_container, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (base_container, api.env.basedn), + 'objectclass': (u'ipaVaultContainer', u'top'), + 'cn': [base_container], + 'container_id': u'/users/admin/%s/' % base_container, + }, + }, + }, + + { + 'desc': 'Create child container', + 'command': ( + 'vaultcontainer_add', + [child_container], + { + 'parent': base_container, + }, + ), + 'expected': { + 'value': child_container, + 'summary': 'Added vault container "%s"' % child_container, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=admin,cn=users,cn=vaults,%s' % (child_container, base_container, api.env.basedn), + 'objectclass': (u'ipaVaultContainer', u'top'), + 'cn': [child_container], + 'container_id': u'/users/admin/%s/%s/' % (base_container, child_container), + }, + }, + }, + + { + 'desc': 'Create grandchild container', + 'command': ( + 'vaultcontainer_add', + [grandchild_container], + { + 'parent': base_container + u'/' + child_container, + }, + ), + 'expected': { + 'value': grandchild_container, + 'summary': 'Added vault container "%s"' % grandchild_container, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=%s,cn=admin,cn=users,cn=vaults,%s' + % (grandchild_container, child_container, base_container, api.env.basedn), + 'objectclass': (u'ipaVaultContainer', u'top'), + 'cn': [grandchild_container], + 'container_id': u'/users/admin/%s/%s/%s/' + % (base_container, child_container, grandchild_container), + }, + }, + }, + + { + 'desc': 'Delete base container', + 'command': ( + 'vaultcontainer_del', + [base_container], + {}, + ), + 'expected': errors.NotAllowedOnNonLeaf(error=u'Not allowed on non-leaf entry'), + }, + + { + 'desc': 'Delete base container with force', + 'command': ( + 'vaultcontainer_del', + [base_container], + { + 'force': True, + }, + ), + 'expected': { + 'value': [base_container], + 'summary': u'Deleted vault container "%s"' % base_container, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create private vault', + 'command': ( + 'vault_add', + [private_vault], + {}, + ), + 'expected': { + 'value': private_vault, + 'summary': 'Added vault "%s"' % private_vault, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), + 'objectclass': (u'ipaVault', u'top'), + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + }, + }, + }, + + { + 'desc': 'Create duplicate vault', + 'command': ( + 'vault_add', + [private_vault], + {}, + ), + 'expected': errors.DuplicateEntry(message=u'vault with name "%s" already exists' % private_vault), + }, + + { + 'desc': 'Find private vaults', + 'command': ( + 'vault_find', + [], + {}, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + }, + ], + }, + }, + + { + 'desc': 'Show private vault', + 'command': ( + 'vault_show', + [private_vault], + {}, + ), + 'expected': { + 'value': private_vault, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + }, + }, + }, + + { + 'desc': 'Modify private vault', + 'command': ( + 'vault_mod', + [private_vault], + { + 'description': u'Private vault', + }, + ), + 'expected': { + 'value': private_vault, + 'summary': u'Modified vault "%s"' % private_vault, + 'result': { + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + 'description': [u'Private vault'], + }, + }, + }, + + { + 'desc': 'Archive binary data', + 'command': ( + 'vault_archive', + [private_vault], + { + 'data': 'c2JVcmV0', + }, + ), + 'expected': { + 'value': private_vault, + 'summary': u'Archived data into vault "%s"' % private_vault, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + 'description': [u'Private vault'], + }, + }, + }, + + { + 'desc': 'Retrieve binary data', + 'command': ( + 'vault_retrieve', + [private_vault], + {}, + ), + 'expected': { + 'value': private_vault, + 'summary': u'Retrieved data from vault "%s"' % private_vault, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + 'description': [u'Private vault'], + 'nonce': fuzzy_string, + 'encrypted_data': fuzzy_string, + 'data': 'c2JVcmV0', + }, + }, + }, + + { + 'desc': 'Archive text data', + 'command': ( + 'vault_archive', + [private_vault], + { + 'text': u'secret', + }, + ), + 'expected': { + 'value': private_vault, + 'summary': u'Archived data into vault "%s"' % private_vault, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + 'description': [u'Private vault'], + }, + }, + }, + + { + 'desc': 'Retrieve text data', + 'command': ( + 'vault_retrieve', + [private_vault], + { + 'show_text': True, + }, + ), + 'expected': { + 'value': private_vault, + 'summary': u'Retrieved data from vault "%s"' % private_vault, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), + 'cn': [private_vault], + 'vault_id': u'/users/admin/%s' % private_vault, + 'description': [u'Private vault'], + 'nonce': fuzzy_string, + 'encrypted_data': fuzzy_string, + 'text': u'secret', + }, + }, + }, + + { + 'desc': 'Delete private vault', + 'command': ( + 'vault_del', + [private_vault], + {}, + ), + 'expected': { + 'value': [private_vault], + 'summary': u'Deleted vault "%s"' % private_vault, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Delete non-existent vault', + 'command': ( + 'vault_del', + [private_vault], + {}, + ), + 'expected': errors.NotFound(reason=u'%s: vault not found' % private_vault), + }, + ] -- 1.9.0 From edewata at redhat.com Mon Jan 26 19:14:52 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 26 Jan 2015 13:14:52 -0600 Subject: [Freeipa-devel] [PATCH] 355 Added vault access control. In-Reply-To: <54587226.7020502@redhat.com> References: <54480DE1.3070103@redhat.com> <54501A32.3080905@redhat.com> <54587226.7020502@redhat.com> Message-ID: <54C6922C.90507@redhat.com> On 11/4/2014 12:28 AM, Endi Sukma Dewata wrote: > On 10/28/2014 5:35 PM, Endi Sukma Dewata wrote: >> On 10/22/2014 3:04 PM, Endi Sukma Dewata wrote: >>> New LDAP ACIs have been added to allow users to create their own >>> private vault container, to allow owners to manage vaults and >>> containers, and to allow members to use the vaults. New CLIs have >>> been added to manage the owner and member list. For archive and >>> retrieve operations the access control has to be enforced by the >>> plugins because the operations only affects KRA. The LDAP schema >>> has been updated as well. >>> >>> Ticket #3872 >>> >>> This patch depends on #353-2. >> >> New patch attached to fix the ticket URL. It depends on #353-3. > > New patch attached for some cleanups. Rebased on top of #353-5 to include access control tests. -- Endi S. Dewata -------------- next part -------------- >From b4591d364a9e38de66536de596347dd08301173e Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 17 Oct 2014 12:05:34 -0400 Subject: [PATCH] Added vault access control. New LDAP ACIs have been added to allow users to create their own private vault container, to allow owners to manage vaults and containers, and to allow members to use the vaults. New CLIs have been added to manage the owner and member list. For archive and retrieve operations the access control has to be enforced by the plugins because the operations only affects KRA. The LDAP schema has been updated as well. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 134 +++++++++++++++-- VERSION | 4 +- install/share/60basev3.ldif | 4 +- install/updates/40-vault.update | 7 + ipalib/plugins/vault.py | 238 +++++++++++++++++++++++++++++- ipatests/test_xmlrpc/test_vault_plugin.py | 17 +++ 6 files changed, 389 insertions(+), 15 deletions(-) diff --git a/API.txt b/API.txt index 559f4b97fad334f037cb61bbb787f7dfcbd6e23c..f6fd2686a49dfabc053a772818904ca6c14f3b53 100644 --- a/API.txt +++ b/API.txt @@ -4518,12 +4518,13 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?', cli_name='data') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4533,13 +4534,40 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,11,3 +args: 1,12,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?', cli_name='data') option: Bytes('encrypted_data?', cli_name='encrypted_data') option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Bytes('nonce?', cli_name='nonce') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4560,11 +4588,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vault_find -args: 1,10,4 +args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4577,12 +4606,13 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4592,10 +4622,37 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_retrieve -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('out?', cli_name='out') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4608,9 +4665,10 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4619,12 +4677,13 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vaultcontainer_add -args: 1,8,3 +args: 1,9,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('container_id', attribute=False, cli_name='container_id', multivalue=False, required=False) option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') @@ -4632,6 +4691,32 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_del args: 1,4,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) @@ -4643,12 +4728,13 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vaultcontainer_find -args: 1,10,4 +args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4660,13 +4746,14 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vaultcontainer_mod -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('container_id', attribute=False, autofill=False, cli_name='container_id', multivalue=False, required=False) option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, pattern='^[a-zA-Z0-9_.-/]+$', required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4675,11 +4762,38 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('version?', exclude='webui') diff --git a/VERSION b/VERSION index 5acbd7bafee959b97ce2a6584646b5bfb58199d3..b0250045145d17e40df3828d0c50be1db8867625 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=113 -# Last change: edewata - initial vault implementation +IPA_API_VERSION_MINOR=114 +# Last change: edewata - added vault access control diff --git a/install/share/60basev3.ldif b/install/share/60basev3.ldif index e0bc4151d88fc394cea0d81a20d8da9537dd5cd3..4883132f1627e16a16b6e7effed2af4be287e251 100644 --- a/install/share/60basev3.ldif +++ b/install/share/60basev3.ldif @@ -77,5 +77,5 @@ objectClasses: (2.16.840.1.113730.3.8.12.24 NAME 'ipaPublicKeyObject' DESC 'Wrap objectClasses: (2.16.840.1.113730.3.8.12.25 NAME 'ipaPrivateKeyObject' DESC 'Wrapped private keys' SUP top AUXILIARY MUST ( ipaPrivateKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.26 NAME 'ipaSecretKeyObject' DESC 'Wrapped secret keys' SUP top AUXILIARY MUST ( ipaSecretKey $ ipaWrappingKey $ ipaWrappingMech ) X-ORIGIN 'IPA v4.1' ) objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect storage for encoded key material' SUP top AUXILIARY MUST ( ipaSecretKeyRef ) X-ORIGIN 'IPA v4.1' ) -objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' DESC 'IPA vault' SUP top STRUCTURAL MUST ( cn ) MAY ( description ) X-ORIGIN 'IPA v4.2' ) -objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' DESC 'IPA vault container' SUP top STRUCTURAL MUST ( cn ) MAY ( description ) X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' DESC 'IPA vault' SUP top STRUCTURAL MUST ( cn ) MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.2' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' DESC 'IPA vault container' SUP top STRUCTURAL MUST ( cn ) MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.2' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update index dac2f67112dc33f012c6d559285464fb7c944d1a..4f36a8066504fb3577fc9f78c830412e9702f617 100644 --- a/install/updates/40-vault.update +++ b/install/updates/40-vault.update @@ -3,6 +3,13 @@ default: objectClass: top default: objectClass: ipaVaultContainer default: cn: vaults default: description: Root vault container +default: aci: (target="ldap:///cn=*,cn=users,cn=vaults,$SUFFIX")(targetattr="*")(version 3.0; acl "Allow add macro dn"; allow (add) userdn = "ldap:///uid=($$attr.cn),cn=users,cn=accounts,$SUFFIX";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container members can access the container"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can modify the container"; allow(read, search, compare, write) userattr="owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can manage sub-containers"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#USERDN";) dn: cn=services,cn=vaults,$SUFFIX default: objectClass: top diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 25372d0f02058fb5efd9f5dece96073ea1d78646..7ec36836a741bc0669ab1be59192532136e8e126 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -34,7 +34,8 @@ from ipalib import api, errors from ipalib import Str, Bytes, Flag from ipalib.frontend import Command from ipalib.plugable import Registry -from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete, LDAPSearch, LDAPUpdate, LDAPRetrieve +from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete, LDAPSearch, LDAPUpdate, LDAPRetrieve,\ + LDAPAddMember, LDAPRemoveMember from ipalib.request import context from ipalib.plugins.user import split_principal from ipalib import _, ngettext @@ -73,6 +74,18 @@ EXAMPLES: Delete a vault: ipa vault-del MyVault """) + _(""" + Add a vault owner: + ipa vault-add-owner MyVault --users testuser +""") + _(""" + Delete a vault owner: + ipa vault-remove-owner MyVault --users testuser +""") + _(""" + Add a vault member: + ipa vault-add-member MyVault --users testuser +""") + _(""" + Delete a vault member: + ipa vault-remove-member MyVault --users testuser +""") + _(""" List private vault containers: ipa vaultcontainer-find """) + _(""" @@ -90,6 +103,18 @@ EXAMPLES: """) + _(""" Delete a vault container: ipa vaultcontainer-del MyContainer +""") + _(""" + Add a vault container owner: + ipa vaultcontainer-add-owner MyContainer --users testuser +""") + _(""" + Delete a vault container owner: + ipa vaultcontainer-remove-owner MyContainer --users testuser +""") + _(""" + Add a vault container member: + ipa vaultcontainer-add-member MyContainer --users testuser +""") + _(""" + Delete a vault container member: + ipa vaultcontainer-remove-member MyContainer --users testuser """) register = Registry() @@ -110,12 +135,18 @@ class vaultcontainer(LDAPObject): 'cn', 'container_id', 'description', + 'owner', + 'member', ] search_display_attributes = [ 'cn', 'container_id', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vault Containers') label_singular = _('Vault Container') @@ -252,6 +283,11 @@ class vaultcontainer_add(LDAPCreate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent containers if they don't exist try: ldap = self.obj.backend @@ -265,6 +301,7 @@ class vaultcontainer_add(LDAPCreate): { 'objectclass': api.Object.vaultcontainer.object_class, 'cn': parent_rdn['cn'], + 'owner': owner_dn, }) ldap.add_entry(parent) @@ -389,6 +426,89 @@ class vaultcontainer_show(LDAPRetrieve): @register() +class vaultcontainer_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return (completed, dn) + + + at register() +class vaultcontainer_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault container.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return (completed, dn) + + + at register() +class vaultcontainer_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return (completed, dn) + + + at register() +class vaultcontainer_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault container.') + + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['container_id'] = self.obj.get_id(dn) + + return (completed, dn) + + + at register() class vault(LDAPObject): __doc__ = _(""" Vault object. @@ -402,12 +522,18 @@ class vault(LDAPObject): 'cn', 'vault_id', 'description', + 'owner', + 'member', ] search_display_attributes = [ 'cn', 'vault_id', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vaults') label_singular = _('Vault') @@ -586,6 +712,11 @@ class vault_add(LDAPCreate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent containers if they don't exist try: ldap = self.obj.backend @@ -599,6 +730,7 @@ class vault_add(LDAPCreate): { 'objectclass': api.Object.vaultcontainer.object_class, 'cn': parent_rdn['cn'], + 'owner': owner_dn, }) ldap.add_entry(parent) @@ -826,6 +958,17 @@ class vault_archive(LDAPRetrieve): assert isinstance(dn, DN) vault_id = self.obj.get_id(dn) + + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) + entry_attrs['vault_id'] = vault_id # connect to KRA @@ -970,6 +1113,17 @@ class vault_retrieve(LDAPRetrieve): assert isinstance(dn, DN) vault_id = self.obj.get_id(dn) + + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) + entry_attrs['vault_id'] = vault_id wrapped_session_key = base64.b64decode(options['wrapped_session_key']) @@ -1001,3 +1155,85 @@ class vault_retrieve(LDAPRetrieve): kra_account.logout() return dn + + + at register() +class vault_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return (completed, dn) + + + at register() +class vault_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return (completed, dn) + + + at register() +class vault_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return (completed, dn) + + + at register() +class vault_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + + entry_attrs['vault_id'] = self.obj.get_id(dn) + + return (completed, dn) diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py index 01896ce1811dd8b3829bc266ff288494fdb3746f..9ef30c1035880dba839922570bf568bcdc6d0937 100644 --- a/ipatests/test_xmlrpc/test_vault_plugin.py +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -97,6 +97,7 @@ class test_vault(Declarative): 'objectclass': (u'ipaVaultContainer', u'top'), 'cn': [private_container], 'container_id': u'/users/admin/%s/' % private_container, + 'owner_user': [u'admin'], }, }, }, @@ -146,6 +147,7 @@ class test_vault(Declarative): 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_container, api.env.basedn), 'cn': [private_container], 'container_id': u'/users/admin/%s/' % private_container, + 'owner_user': [u'admin'], }, }, }, @@ -166,6 +168,7 @@ class test_vault(Declarative): 'cn': [private_container], 'container_id': u'/users/admin/%s/' % private_container, 'description': [u'Private container'], + 'owner_user': [u'admin'], }, }, }, @@ -213,6 +216,7 @@ class test_vault(Declarative): 'objectclass': (u'ipaVaultContainer', u'top'), 'cn': [shared_container], 'container_id': u'/shared/%s/' % shared_container, + 'owner_user': [u'admin'], }, }, }, @@ -256,6 +260,7 @@ class test_vault(Declarative): 'dn': u'cn=%s,cn=shared,cn=vaults,%s' % (shared_container, api.env.basedn), 'cn': [shared_container], 'container_id': u'/shared/%s/' % shared_container, + 'owner_user': [u'admin'], }, }, }, @@ -277,6 +282,7 @@ class test_vault(Declarative): 'cn': [shared_container], 'container_id': u'/shared/%s/' % shared_container, 'description': [u'shared container'], + 'owner_user': [u'admin'], }, }, }, @@ -316,6 +322,7 @@ class test_vault(Declarative): 'objectclass': (u'ipaVaultContainer', u'top'), 'cn': [service_container], 'container_id': u'/services/%s/' % service_container, + 'owner_user': [u'admin'], }, }, }, @@ -334,6 +341,7 @@ class test_vault(Declarative): 'objectclass': (u'ipaVaultContainer', u'top'), 'cn': [base_container], 'container_id': u'/users/admin/%s/' % base_container, + 'owner_user': [u'admin'], }, }, }, @@ -355,6 +363,7 @@ class test_vault(Declarative): 'objectclass': (u'ipaVaultContainer', u'top'), 'cn': [child_container], 'container_id': u'/users/admin/%s/%s/' % (base_container, child_container), + 'owner_user': [u'admin'], }, }, }, @@ -378,6 +387,7 @@ class test_vault(Declarative): 'cn': [grandchild_container], 'container_id': u'/users/admin/%s/%s/%s/' % (base_container, child_container, grandchild_container), + 'owner_user': [u'admin'], }, }, }, @@ -425,6 +435,7 @@ class test_vault(Declarative): 'objectclass': (u'ipaVault', u'top'), 'cn': [private_vault], 'vault_id': u'/users/admin/%s' % private_vault, + 'owner_user': [u'admin'], }, }, }, @@ -474,6 +485,7 @@ class test_vault(Declarative): 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s' % (private_vault, api.env.basedn), 'cn': [private_vault], 'vault_id': u'/users/admin/%s' % private_vault, + 'owner_user': [u'admin'], }, }, }, @@ -494,6 +506,7 @@ class test_vault(Declarative): 'cn': [private_vault], 'vault_id': u'/users/admin/%s' % private_vault, 'description': [u'Private vault'], + 'owner_user': [u'admin'], }, }, }, @@ -515,6 +528,7 @@ class test_vault(Declarative): 'cn': [private_vault], 'vault_id': u'/users/admin/%s' % private_vault, 'description': [u'Private vault'], + 'owner_user': [u'admin'], }, }, }, @@ -534,6 +548,7 @@ class test_vault(Declarative): 'cn': [private_vault], 'vault_id': u'/users/admin/%s' % private_vault, 'description': [u'Private vault'], + 'owner_user': [u'admin'], 'nonce': fuzzy_string, 'encrypted_data': fuzzy_string, 'data': 'c2JVcmV0', @@ -558,6 +573,7 @@ class test_vault(Declarative): 'cn': [private_vault], 'vault_id': u'/users/admin/%s' % private_vault, 'description': [u'Private vault'], + 'owner_user': [u'admin'], }, }, }, @@ -579,6 +595,7 @@ class test_vault(Declarative): 'cn': [private_vault], 'vault_id': u'/users/admin/%s' % private_vault, 'description': [u'Private vault'], + 'owner_user': [u'admin'], 'nonce': fuzzy_string, 'encrypted_data': fuzzy_string, 'text': u'secret', -- 1.9.0 From edewata at redhat.com Mon Jan 26 19:15:00 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 26 Jan 2015 13:15:00 -0600 Subject: [Freeipa-devel] [PATCH] 356 Added command to retrieve vault transport certificate. In-Reply-To: <54587267.7030806@redhat.com> References: <54480E30.8040905@redhat.com> <5448E41D.5030401@redhat.com> <5450262C.9050906@redhat.com> <54587267.7030806@redhat.com> Message-ID: <54C69234.3050104@redhat.com> On 11/4/2014 12:29 AM, Endi Sukma Dewata wrote: > On 10/28/2014 6:26 PM, Endi Sukma Dewata wrote: >> On 10/23/2014 6:18 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 22.10.2014 v 22:06 Endi Sukma Dewata napsal(a): >>>> A new command has been added to retrieve the vault transport >>>> certificate and optionally save it into a file. The vault archive >>>> and retrieve command has been modified to retrieve the transport >>>> certificate and store it locally for subsequent usage. This way >>>> it's no longer necessary to manually import the transport >>>> certificate into the client's NSS database. >>> >>> As part of the CA certificate renewal feature in 4.1, I have added a >>> LDAP certificate store to IPA, see >>> . Currently it >>> supports only CA certificates, but can be extended to support end entity >>> certificates rather easily. If you use it for the vault transport >>> certificate, it can be added to the client NSS database automatically on >>> install. >>> >>> Honza >>> >> >> I'm attaching a new patch that's identical to the previous one with >> ticket URL updated. I'm thinking we should check this patch in first >> because it's already done, and then investigate the use of CA cert >> management utility as a separate enhancement since the it seems to need >> to be generalized before it can be used to manage KRA transport cert. >> I'll also need to investigate the KRA transport cert replacement process >> to make sure it can be accommodated via IPA's cert management utility. > > Revised the patch to always download the transport certificate (no local > caching). Further optimization can be done later. Rebased on top of #355-3, no code changes. -- Endi S. Dewata -------------- next part -------------- >From 56e1211f42faa1e4c36184efdcddc3af23310cda Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 22 Oct 2014 10:02:25 -0400 Subject: [PATCH] Added command to retrieve vault transport certificate. A new command has been added to retrieve the vault transport certificate and optionally save it into a file. The vault archive and retrieve command has been modified to retrieve the transport certificate and store it locally for subsequent usage. This way it's no longer necessary to manually import the transport certificate into the client's NSS database. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 5 ++++ VERSION | 4 +-- ipalib/plugins/vault.py | 80 +++++++++++++++++++++++++++++++++++++++++++++++-- 3 files changed, 84 insertions(+), 5 deletions(-) diff --git a/API.txt b/API.txt index f6fd2686a49dfabc053a772818904ca6c14f3b53..f64fd1570efff9a2eb2e277e16ceef2ebb1a9ae3 100644 --- a/API.txt +++ b/API.txt @@ -4676,6 +4676,11 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_transport_cert +args: 0,2,1 +option: Str('out?', cli_name='out') +option: Str('version?', exclude='webui') +output: Output('result', None, None) command: vaultcontainer_add args: 1,9,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True) diff --git a/VERSION b/VERSION index b0250045145d17e40df3828d0c50be1db8867625..c75e5376c1041a701908ea7e23c8b4e570eb21b6 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=114 -# Last change: edewata - added vault access control +IPA_API_VERSION_MINOR=115 +# Last change: edewata - added vault transport certificate diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 7ec36836a741bc0669ab1be59192532136e8e126..58f0ae494c0d0c2c3a66f708cbe7c1545bdeec84 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -25,6 +25,8 @@ import shutil import string import tempfile +import nss.nss as nss + import pki import pki.account import pki.crypto @@ -118,7 +120,6 @@ EXAMPLES: """) register = Registry() -transport_cert_nickname = 'KRA Transport Certificate' @register() class vaultcontainer(LDAPObject): @@ -845,6 +846,63 @@ class vault_show(LDAPRetrieve): @register() +class vault_transport_cert(Command): + __doc__ = _('Retrieve vault transport certificate.') + + + # list of attributes we want exported to JSON + json_friendly_attributes = ( + 'takes_args', + ) + + takes_options = ( + Str('out?', + cli_name='out', + doc=_('Output file to store the transport certificate'), + ), + ) + + has_output_params = ( + Str('certificate', + label=_('Certificate'), + ), + ) + + def __json__(self): + json_dict = dict( + (a, getattr(self, a)) for a in self.json_friendly_attributes + ) + json_dict['takes_options'] = list(self.get_json_options()) + return json_dict + + def forward(self, *args, **options): + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + response = super(vault_transport_cert, self).forward(*args, **options) + + if file: + with open(file, 'w') as f: + f.write(response['result']['certificate']) + + return response + + def execute(self, *args, **options): + + kra_client = api.Backend.kra.get_client() + transport_cert = kra_client.system_certs.get_transport_cert() + return { + 'result': { + 'certificate': transport_cert.encoded + } + } + + + at register() class vault_archive(LDAPRetrieve): __doc__ = _('Archive data into a vault.') @@ -931,7 +989,15 @@ class vault_archive(LDAPRetrieve): session_key = crypto.generate_session_key() # retrieve transport certificate - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + api.Command.vault_transport_cert(out=unicode(filename)) + transport_cert_der = nss.read_der_from_file(filename, True) + nss_transport_cert = nss.Certificate(transport_cert_der) + + finally: + os.remove(filename) # wrap session key with transport certificate wrapped_session_key = crypto.asymmetric_wrap( @@ -1070,7 +1136,15 @@ class vault_retrieve(LDAPRetrieve): session_key = crypto.generate_session_key() # retrieve transport certificate - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + api.Command.vault_transport_cert(out=unicode(filename)) + transport_cert_der = nss.read_der_from_file(filename, True) + nss_transport_cert = nss.Certificate(transport_cert_der) + + finally: + os.remove(filename) # wrap session key with transport certificate wrapped_session_key = crypto.asymmetric_wrap( -- 1.9.0 From jcholast at redhat.com Tue Jan 27 07:40:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 Jan 2015 08:40:42 +0100 Subject: [Freeipa-devel] [PATCH] 397 Do not crash when replica is unreachable in ipa-restore Message-ID: <54C740FA.6090103@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-397-Do-not-crash-when-replica-is-unreachable-in-ipa-rest.patch Type: text/x-patch Size: 1384 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 27 07:42:19 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 Jan 2015 08:42:19 +0100 Subject: [Freeipa-devel] [PATCH] 396 Create correct log directories during full restore in ipa-restore In-Reply-To: <54C669AB.9020209@redhat.com> References: <54C6211B.8010903@redhat.com> <54C669AB.9020209@redhat.com> Message-ID: <54C7415B.9040104@redhat.com> Dne 26.1.2015 v 17:22 Martin Kosek napsal(a): > On 01/26/2015 12:12 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > I tested the use case and log directories were properly created. > > So ACK, works for me. > > Martin > Thanks. Pushed to: master: c90286cbbc1ab21e185c4d60d3a86142172c47ca ipa-4-1: 275fb2dcec64d7de48bec9faf16c4551d18c6c42 -- Jan Cholasta From mbabinsk at redhat.com Tue Jan 27 08:50:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Jan 2015 09:50:29 +0100 Subject: [Freeipa-devel] [PATCH 0005] Fixed some of the issues reported in FreeIPA code by covscan Message-ID: <54C75155.1070506@redhat.com> The attached patch is related to https://fedorahosted.org/freeipa/ticket/4795 and fixes (hopefully) some of the defects reported by subsequent scans. There are also 21 defects reported in asn1/asn1c/*.c files (http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16545/log/freeipa-4.1.99.201501261541GIT871f9bb-0.fc21/scan-results.html). Since this code is (semi)-automatically generated by asn1c software, we should decide what to do with them. Should I try to fix them by hand and/or report them upstream? Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0005-1-fixed-issues-reported-in-FreeIPA-code-by-covscan.patch Type: text/x-patch Size: 9239 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jan 27 09:10:21 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Jan 2015 11:10:21 +0200 Subject: [Freeipa-devel] [PATCH 0005] Fixed some of the issues reported in FreeIPA code by covscan In-Reply-To: <54C75155.1070506@redhat.com> References: <54C75155.1070506@redhat.com> Message-ID: <20150127091021.GE4383@redhat.com> On Tue, 27 Jan 2015, Martin Babinsky wrote: >The attached patch is related to >https://fedorahosted.org/freeipa/ticket/4795 and fixes (hopefully) >some of the defects reported by subsequent scans. NACK overall. If you want to provide fixes, make them separate of each other and explain each fix. See below for details. > >There are also 21 defects reported in asn1/asn1c/*.c files (http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16545/log/freeipa-4.1.99.201501261541GIT871f9bb-0.fc21/scan-results.html). >Since this code is (semi)-automatically generated by asn1c software, >we should decide what to do with them. > >Should I try to fix them by hand and/or report them upstream? No manual fixes, we'll need to find out a way to fix them upstream. > >Martin^3 >From 4732626ed0fb8ec0fb2074c55955ab570eac58fa Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Fri, 16 Jan 2015 15:43:17 +0100 >Subject: [PATCH] Fixed issues reported in FreeIPA code by covscan > >This patch is related to https://fedorahosted.org/freeipa/ticket/4795. >Performed another scan and fixed/waived some defects reported by Coverity in >IPA C code. >--- > daemons/ipa-kdb/ipa_kdb_audit_as.c | 5 +++++ > daemons/ipa-kdb/ipa_kdb_mspac.c | 5 +---- > daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- > daemons/ipa-sam/ipa_sam.c | 2 +- > .../ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c | 8 ++++++-- > daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 4 +++- > daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c | 3 ++- > daemons/ipa-slapi-plugins/libotp/Makefile.am | 4 +++- > daemons/ipa-slapi-plugins/libotp/otp_config.c | 9 ++++++++- > util/ipa_krb5.h | 2 ++ > 10 files changed, 35 insertions(+), 18 deletions(-) > >diff --git a/daemons/ipa-kdb/ipa_kdb_audit_as.c b/daemons/ipa-kdb/ipa_kdb_audit_as.c >index 52c165442bde61d3ce88843b122aae7fe0fae50b..81ccbc2de28681c9c90b932fb14831965e0b246c 100644 >--- a/daemons/ipa-kdb/ipa_kdb_audit_as.c >+++ b/daemons/ipa-kdb/ipa_kdb_audit_as.c >@@ -20,6 +20,7 @@ > * along with this program. If not, see . > */ > >+#include > #include "ipa_kdb.h" > #include "ipa_pwd.h" NACK, why do you need syslog.h here? > >@@ -120,7 +121,11 @@ void ipadb_audit_as_req(krb5_context kcontext, > client->last_failed = authtime; > client->mask |= KMASK_LAST_FAILED; > break; >+ /*coverity[dead_error_begin]*/ > default: >+ krb5_klog_syslog(LOG_ERR, >+ "Got an unexpected value of error_code: %d\n", >+ error_code); > return; > } > >diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c >index a4500070760e83994c8155a12ee6414b5ebee9e0..0f47d1f4bd536e24b9d46a35232ad558b33b4b26 100644 >--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >@@ -54,9 +54,6 @@ struct ipadb_mspac { > time_t last_update; > }; > >- >-int krb5_klog_syslog(int, const char *, ...); >- > static char *user_pac_attrs[] = { > "objectClass", > "uid", What does this fix have to do with coverity? Please separate patches and submit one by one. >@@ -2074,7 +2071,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, > } > } > >- kerr = ipadb_get_pac(context, client_entry ? client_entry : client, &pac); >+ kerr = ipadb_get_pac(context, client, &pac); > if (kerr != 0 && kerr != ENOENT) { > goto done; > } NACK, this change is wrong and breaks conditional delegation. >diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c >index e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a 100644 >--- a/daemons/ipa-kdb/ipa_kdb_principals.c >+++ b/daemons/ipa-kdb/ipa_kdb_principals.c >@@ -1894,19 +1894,16 @@ static krb5_error_code ipadb_modify_principal(krb5_context kcontext, > if (!ipactx) { > return KRB5_KDB_DBNOTINITED; > } >- >+ kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >+ if (kerr != 0) { >+ goto done; >+ } > ied = (struct ipadb_e_data *)entry->e_data; > if (!ied || !ied->entry_dn) { >- kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >- if (kerr != 0) { >- goto done; >- } >- > kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); > if (kerr != 0) { > goto done; > } >- > /* FIXME: no alias allowed for now, should we allow modifies > * by alias name ? */ > kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); NACK, we only want to touch entry->princ and fetch it if it does not exist. The cost of these operations is sufficient enough to postpone. >diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c >index 07249fd27b362ed6499e372d651192dfc31b5173..ea9c18888503f40bfc288703d985530a66539b7d 100644 >--- a/daemons/ipa-sam/ipa_sam.c >+++ b/daemons/ipa-sam/ipa_sam.c >@@ -1487,7 +1487,7 @@ static bool ldapgroup2displayentry(struct ldap_search_state *state, > return false; > } > break; >- >+ /*coverity[dead_error_begin]*/ > default: > DEBUG(0,("unknown group type: %d\n", group_type)); > talloc_free(sid); >diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >index 233813745795344f31a7dcf1931cf74a09f1e552..2990fba51452fcbe1c67572b0d1a64d5565e6eba 100644 >--- a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c >@@ -111,13 +111,17 @@ static bool is_pwd_enabled(const char *user_dn) > Slapi_Entry *entry = NULL; > uint32_t authtypes; > Slapi_DN *sdn; >+ int search_result = 0; > > sdn = slapi_sdn_new_dn_byval(user_dn); > if (sdn == NULL) > return false; > >- slapi_search_internal_get_entry(sdn, attrs, &entry, >- otp_config_plugin_id(otp_config)); >+ search_result = slapi_search_internal_get_entry(sdn, attrs, &entry, >+ otp_config_plugin_id(otp_config)); >+ if (search_result != LDAP_SUCCESS) { >+ LOG_TRACE("Entry not found. Error code: %d\n", search_result); >+ } > slapi_sdn_free(&sdn); > if (entry == NULL) > return false; What does this fix have to do with Coverity? >diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >index 84eff17013d2742d1b5e5c4ea5f4e22ee290d785..b28e2d220a41628277dbdce84dfdbc5952476190 100644 >--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >@@ -634,7 +634,9 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb) > is_krb = 0; > is_smb = 0; > is_ipant = 0; >- >+ /* coverity[fallthrough] >+ * After examining the output of covscan, we think that this >+ * fallthrough is intentional.*/ > case LDAP_MOD_ADD: > if (!lmod->mod_bvalues || > !lmod->mod_bvalues[0]) { >diff --git a/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c b/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c >index 2b07de45b63dab36a0b7167e3583e88ebd07f6f7..061fd12521f072498ecc72858dfe79ba46624a51 100644 >--- a/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c >+++ b/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c >@@ -1027,9 +1027,10 @@ static int ipauuid_pre_op(Slapi_PBlock *pb, int modtype) > > slapi_mod_free(&next_mod); > break; >- >+ /*coverity[dead_error_begin]*/ > default: > /* never reached, just silence compiler */ >+ LOG_TRACE("Got unexpected value of modtype: %d\n", modtype); > break; > } > >diff --git a/daemons/ipa-slapi-plugins/libotp/Makefile.am b/daemons/ipa-slapi-plugins/libotp/Makefile.am >index 4428f6bdc38a4e4ec224d1fa70744d8381f7e0b1..71b9c19f40379ba6c61858984f9de0253020e00d 100644 >--- a/daemons/ipa-slapi-plugins/libotp/Makefile.am >+++ b/daemons/ipa-slapi-plugins/libotp/Makefile.am >@@ -1,5 +1,7 @@ > MAINTAINERCLEANFILES = *~ Makefile.in >-AM_CPPFLAGS = -I/usr/include/dirsrv >+PLUGIN_COMMON_DIR = ../common >+AM_CPPFLAGS = -I/usr/include/dirsrv \ >+ -I$(PLUGIN_COMMON_DIR) > > noinst_LTLIBRARIES = libhotp.la libotp.la > libhotp_la_SOURCES = hotp.c hotp.h >diff --git a/daemons/ipa-slapi-plugins/libotp/otp_config.c b/daemons/ipa-slapi-plugins/libotp/otp_config.c >index ac2cfc72aa9f72af8eb5b5c565650325ac8bf714..0d87ac0cdf35fd0d457ee5f2ee22d6cf4b1297cd 100644 >--- a/daemons/ipa-slapi-plugins/libotp/otp_config.c >+++ b/daemons/ipa-slapi-plugins/libotp/otp_config.c >@@ -38,6 +38,7 @@ > * END COPYRIGHT BLOCK **/ > > #include "otp_config.h" >+#include "util.h" > > #include > #include >@@ -214,6 +215,7 @@ struct otp_config *otp_config_init(Slapi_ComponentId *plugin_id) > > struct otp_config *cfg = NULL; > void *node = NULL; >+ int search_result = 0; > > cfg = (typeof(cfg)) slapi_ch_calloc(1, sizeof(*cfg)); > cfg->plugin_id = plugin_id; >@@ -236,7 +238,12 @@ struct otp_config *otp_config_init(Slapi_ComponentId *plugin_id) > cfg->records = rec; > > /* Load the specified entry. */ >- slapi_search_internal_get_entry(rec->sdn, NULL, &entry, plugin_id); >+ search_result = slapi_search_internal_get_entry(rec->sdn, >+ NULL, &entry, plugin_id); >+ if (search_result != LDAP_SUCCESS) { >+ LOG_TRACE("Entry not found. Error code: %d\n", >+ search_result); >+ } > update(cfg, rec->sdn, entry); > slapi_entry_free(entry); > } What does this fix have to do with coverity? >diff --git a/util/ipa_krb5.h b/util/ipa_krb5.h >index 7b877aa665dd6cb4e0c1cf9d8153319cc8f61a20..2153bd57142d1468031d0aa4b5d3f59ef5c890b5 100644 >--- a/util/ipa_krb5.h >+++ b/util/ipa_krb5.h >@@ -30,6 +30,8 @@ struct keys_container { > #define KEYTAB_RET_OID "2.16.840.1.113730.3.8.10.2" > #define KEYTAB_GET_OID "2.16.840.1.113730.3.8.10.5" > >+int krb5_klog_syslog(int, const char *, ...); >+ > void > ipa_krb5_free_ktypes(krb5_context context, krb5_enctype *val); > >-- >2.1.0 > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -- / Alexander Bokovoy From mbasti at redhat.com Tue Jan 27 09:41:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Jan 2015 10:41:49 +0100 Subject: [Freeipa-devel] [PATCH 0004] added dbus-python dependency to freeipa-client In-Reply-To: <54C66D0C.4020300@redhat.com> References: <54C66D0C.4020300@redhat.com> Message-ID: <54C75D5D.7070703@redhat.com> On 26/01/15 17:36, Martin Babinsky wrote: > See attached patch related to > https://fedorahosted.org/freeipa/ticket/4863. > > Martin^3 > > Thank for your patch, IMO client is not dependent on dbus module, but ipapython requires dbus module. We should add this dependency to ipapython package, because AFAIK ipa-client-install do not need dbus at all. Martin^2 -- Martin Basti From mkosek at redhat.com Tue Jan 27 12:37:27 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Jan 2015 13:37:27 +0100 Subject: [Freeipa-devel] [PATCH 003] Use 'remove-ds.pl' to remove DS instance during server uninstall In-Reply-To: <54C66F6E.2040608@redhat.com> References: <54C0CB37.3040605@redhat.com> <54C0D7D0.8040109@redhat.com> <54C0DCAC.8050409@redhat.com> <54C0E141.5080700@redhat.com> <54C10339.8080800@redhat.com> <54C27D2C.7000406@redhat.com> <54C63A3D.6040309@redhat.com> <54C63BB2.9060602@redhat.com> <54C66F6E.2040608@redhat.com> Message-ID: <54C78687.7080500@redhat.com> On 01/26/2015 05:46 PM, Martin Basti wrote: > On 26/01/15 14:05, Martin Babinsky wrote: >> On 01/26/2015 01:59 PM, Martin Babinsky wrote: >>> On 01/23/2015 05:56 PM, Martin Basti wrote: >>>> On 22/01/15 15:03, Martin Babinsky wrote: >>>>> On 01/22/2015 12:38 PM, Martin Babinsky wrote: >>>>>> On 01/22/2015 12:19 PM, Martin Kosek wrote: >>>>>>> On 01/22/2015 11:58 AM, Martin Babinsky wrote: >>>>>>>> On 01/22/2015 11:04 AM, Martin Babinsky wrote: >>>>>>>>> The attached patch addresses >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4487. >>>>>>>>> >>>>>>>>> Using 'remove-ds.pl' script from 389-ds during server/replica >>>>>>>>> uninstallation should allow for cleaner removal of DS instance >>>>>>>>> with no >>>>>>>>> leftovers (opened ports etc). >>>>>>>>> >>>>>>>>> Martin^3 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-devel mailing list >>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>> >>>>>>>> Thanks to Martin^2 for explaining the rules governing the placement >>>>>>>> of new >>>>>>>> attributes into BasePathNamespace class. >>>>>>>> >>>>>>>> Attaching updated patch. >>>>>>>> >>>>>>>> Martin^3 >>>>>>> >>>>>>> I see you kept erase_ds_instance_data still in the dsinstance. What is >>>>>>> the >>>>>>> motivation? I thought that just like with PKI, with DS we will also >>>>>>> have >>>>>>> uninstall based solely only on the DS uninstall script and remove our >>>>>>> custom >>>>>>> removal. >>>>>>> >>>>>>> We can keep the manual removal somewhere in wiki, but I would >>>>>>> personally not >>>>>>> keep/maintain it in FreeIPA code. >>>>>>> >>>>>> I originally thought that I will keep erase_ds_instance-data as a >>>>>> failsafe method to clean up the dirsrv data in th case that >>>>>> remove-ds.pl >>>>>> fails. >>>>>> >>>>>> But I will remove the method altogether and change the code so that it >>>>>> prints out some warning about manual removal of DS data when >>>>>> remove-ds.pl fails. >>>>>> >>>>>> Martin^2 >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> Updated patch attached >>>>> >>>>> Martin^3 >>>>> >>>> >>>> Hi, >>>> >>>> thank you for patch, but I have a few nitpicks: >>>> >>>> 1) Extra parenthesis >>>> + root_logger.error(("Failed to remove CA DS instance. >>>> You may " >>>> + "need to remove instance data >>>> manually")) >>>> >>>> and (twice) >>>> >>>> + root_logger.error(("Failed to remove DS instance. You >>>> may " >>>> + "need to remove instance data >>>> manually")) >>>> >>>> and >>>> >>>> + root_logger.debug(("'%s' failed. " >>>> + "Attempting to force removal" % >>>> paths.REMOVE_DS_PL)) >>>> >>>> 2) Remove unused paths: >>>> USR_LIB_DIRSRV_SLAPD_INSTANCE_DIR_TEMPLATE >>>> SLAPD_INSTANCE_LOCK_TEMPLATE >>>> USR_LIB_SLAPD_INSTANCE_TEMPLATE >>>> >>>> Please do double check. >>>> >>>> 3) IMO we should avoid hardcoded value 'slapd' >>>> instance_name = '-'.join(['slapd', serverid]) >>>> >>>> you may create module variable DS_INSTANCE_PREFIX and use it. Dont >>>> forget to change it in following place as well. >>>> ipaserver/install/dsinstance.py:117: instance_prefix = 'slapd-' >>>> >>>> 4) >>>> DS keytab hasn't been removed, it is okay? >>>> It is created by IPA (krbinstance), not by DS install script. >>>> >>>> >>>> Martin^2 >>>> >>> Thanks for suggestions, attaching updated patch >>> >>> Martin^3 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Missed one little thing. Attaching updated patch. >> >> Martin^3 > Thank you, ACK. > Pushed to master: 55b7eed77e5f76c159ba157d020e93aa9d43bdc5 Martin From dkupka at redhat.com Tue Jan 27 15:22:37 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 27 Jan 2015 16:22:37 +0100 Subject: [Freeipa-devel] [PATCHES 301-302] ID override sshpubkey handling In-Reply-To: <1508237010.276360.1422286405591.JavaMail.zimbra@redhat.com> References: <1508237010.276360.1422286405591.JavaMail.zimbra@redhat.com> Message-ID: <54C7AD3D.6000208@redhat.com> On 01/26/2015 04:33 PM, Tomas Babej wrote: > Hi, > > the following two patches make sure that sshpubkeys work both with -mod and -add commands of ipaoverrideuser objects. Also covers the use cases with unit tests. > > https://fedorahosted.org/freeipa/ticket/4868 > > Tomas > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi, thanks for the patches but right now we need just a small fix for ipa-4-1 (attached). Your patches will latter go into ipa-4-2. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0038-idviews-Allow-setting-ssh-public-key-on-ipauseroverr.patch Type: text/x-patch Size: 1349 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 27 15:45:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Jan 2015 16:45:42 +0100 Subject: [Freeipa-devel] [PATCH] 397 Do not crash when replica is unreachable in ipa-restore In-Reply-To: <54C740FA.6090103@redhat.com> References: <54C740FA.6090103@redhat.com> Message-ID: <54C7B2A6.7060302@redhat.com> On 01/27/2015 08:40 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Works like a charm, ACK. Pushed to: master: deb70d5b13ce0e7ec77debb4aa17d75df4c1dedd ipa-4-1: 74853b66f092a057c22ee811e945f631e6d65059 Martin From jcholast at redhat.com Tue Jan 27 16:04:01 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 Jan 2015 17:04:01 +0100 Subject: [Freeipa-devel] [PATCHES 301-302] ID override sshpubkey handling In-Reply-To: <54C7AD3D.6000208@redhat.com> References: <1508237010.276360.1422286405591.JavaMail.zimbra@redhat.com> <54C7AD3D.6000208@redhat.com> Message-ID: <54C7B6F1.3010204@redhat.com> Dne 27.1.2015 v 16:22 David Kupka napsal(a): > On 01/26/2015 04:33 PM, Tomas Babej wrote: >> Hi, >> >> the following two patches make sure that sshpubkeys work both with >> -mod and -add commands of ipaoverrideuser objects. Also covers the use >> cases with unit tests. >> >> https://fedorahosted.org/freeipa/ticket/4868 >> >> Tomas >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Hi, > > thanks for the patches but right now we need just a small fix for > ipa-4-1 (attached). Thanks, ACK. Pushed to: master: 3b87302f5a280c044a8e6a8b4aa08a29e3b4b0d5 ipa-4-1: 0dc7448b3634be443806db45ffead57107213ad6 > Your patches will latter go into ipa-4-2. +1 -- Jan Cholasta From mbabinsk at redhat.com Tue Jan 27 16:21:52 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Jan 2015 17:21:52 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master Message-ID: <54C7BB20.1080109@redhat.com> This series of patches is related to https://fedorahosted.org/freeipa/ticket/4795. The attached patches attempt to address some of the defects encountered during running covscan on freeipa-master branch. The complete list is here: http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html These patches do not fix defects 1 to 22 which occur in a code generated by asn1c, defect 23 which is related to https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead code). Each patch contains a detailed description of a defect and a proposed fix to address it. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0005-1-added-warning-message-after-default-branch.patch Type: text/x-patch Size: 3657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0006-1-proposed-fix-for-a-defect-reported-in-ipa_kdb_mspac.patch Type: text/x-patch Size: 1808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0007-1-proposed-fix-fo-a-defect-reported-in-ipa_kdb_princip.patch Type: text/x-patch Size: 2250 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0008-1-proposed-fix-for-a-defect-reported-in-ipa_otp_lastto.patch Type: text/x-patch Size: 3632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0009-1-added-an-informational-comment-about-intentional-fal.patch Type: text/x-patch Size: 1679 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0010-1-added-a-debug-message-to-ipa_uuid.c.patch Type: text/x-patch Size: 2366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0011-1-proposed-fix-for-a-defect-found-in-otp_config.c.patch Type: text/x-patch Size: 4501 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 27 17:04:01 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Jan 2015 18:04:01 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150127165610.GH4383@vda.li> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> Message-ID: <54C7C501.2090004@redhat.com> On 27.1.2015 17:56, Alexander Bokovoy wrote: > On Tue, 27 Jan 2015, Martin Babinsky wrote: >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Tue, 27 Jan 2015 13:21:33 +0100 >> Subject: [PATCH 3/7] proposed fix fo a defect reported in >> 'ipa_kdb_principals.c' >> >> The patch addresses the following defect reported by covscan in FreeIPA >> master: >> >> """ >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >> assign_zero: Assigning: >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >> deref_parm_in_call: Function "strdup" dereferences "value" >> """ >> >> Again I have consulted this with Simo and he pointed out that this may indeed >> be a bug and that we should always parse principal name. >> >> This is a part of series of patches related to >> https://fedorahosted.org/freeipa/ticket/4795 >> --- >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >> b/daemons/ipa-kdb/ipa_kdb_principals.c >> index >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >> 100644 >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >> @@ -1894,19 +1894,16 @@ static krb5_error_code >> ipadb_modify_principal(krb5_context kcontext, >> if (!ipactx) { >> return KRB5_KDB_DBNOTINITED; >> } >> - >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> + if (kerr != 0) { >> + goto done; >> + } >> ied = (struct ipadb_e_data *)entry->e_data; >> if (!ied || !ied->entry_dn) { >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> - if (kerr != 0) { >> - goto done; >> - } >> - >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); >> if (kerr != 0) { >> goto done; >> } >> - >> /* FIXME: no alias allowed for now, should we allow modifies >> * by alias name ? */ >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >> -- >> 2.1.0 >> > NACK. > > This part actually looked to me familiar and it was indeed raised in > past. I marked the Coverity report for this as a false positive but it > sprung again. > > Last time I wrote (2014-04-07): > ------------------------------------------------------ > I remember looking at this bug already in past and I looked at it again. > I think it is false positive. ipadb_modify_principal() is only called > from ipadb_put_principal() when entry for the principal has no > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls > ipadb_entry_to_mods() with a principal which might be set to NULL. > However, ipadb_entry_to_mods() will only dereference this principal when > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. > ------------------------------------------------------- Hmm... It may work for now but it also may break silently in future if we break current assumption "ipadb_modify_principal() is only called from ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag set". Personally I'm against this kind of implicit assumptions in code. I was bitten tooooo may times by exactly this in BIND and I don't think we should do that in our code. Alexander, if you really don't want to move krb5_unparse_name() call then we really need to handle this "impossible" case in some other way. Maybe with an assert()? It would do nothing as long as your assumption holds and will clearly show where the problem is if we break the assumption in future. -- Petr^2 Spacek From pspacek at redhat.com Tue Jan 27 17:05:49 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Jan 2015 18:05:49 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150127170230.GM4383@vda.li> References: <54C7BB20.1080109@redhat.com> <20150127170230.GM4383@vda.li> Message-ID: <54C7C56D.9060503@redhat.com> On 27.1.2015 18:02, Alexander Bokovoy wrote: >> >> - slapi_search_internal_get_entry(sdn, attrs, &entry, >> - otp_config_plugin_id(otp_config)); >> + search_result = slapi_search_internal_get_entry(sdn, attrs, &entry, >> + otp_config_plugin_id(otp_config)); >> + if (search_result != LDAP_SUCCESS) { >> + LOG_TRACE("Entry not found. Error code: %d\n", search_result); >> + } > I would rather say something more defensive here: > "Unable to access LDAP entry. Perhaps it does not exist? Error code: %d\n" Would it be possible to print the DN? It may be useful in cases where it actually happened ... -- Petr^2 Spacek From pspacek at redhat.com Tue Jan 27 17:32:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Jan 2015 18:32:59 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150127172323.GN4383@vda.li> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <20150127172323.GN4383@vda.li> Message-ID: <54C7CBCB.4020600@redhat.com> On 27.1.2015 18:23, Alexander Bokovoy wrote: > On Tue, 27 Jan 2015, Petr Spacek wrote: >> On 27.1.2015 17:56, Alexander Bokovoy wrote: >>> On Tue, 27 Jan 2015, Martin Babinsky wrote: >>>> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 >>>> From: Martin Babinsky >>>> Date: Tue, 27 Jan 2015 13:21:33 +0100 >>>> Subject: [PATCH 3/7] proposed fix fo a defect reported in >>>> 'ipa_kdb_principals.c' >>>> >>>> The patch addresses the following defect reported by covscan in FreeIPA >>>> master: >>>> >>>> """ >>>> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >>>> assign_zero: Assigning: >>>> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >>>> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >>>> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >>>> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >>>> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >>>> deref_parm_in_call: Function "strdup" dereferences "value" >>>> """ >>>> >>>> Again I have consulted this with Simo and he pointed out that this may indeed >>>> be a bug and that we should always parse principal name. >>>> >>>> This is a part of series of patches related to >>>> https://fedorahosted.org/freeipa/ticket/4795 >>>> --- >>>> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >>>> 1 file changed, 4 insertions(+), 7 deletions(-) >>>> >>>> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >>>> b/daemons/ipa-kdb/ipa_kdb_principals.c >>>> index >>>> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >>>> >>>> 100644 >>>> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >>>> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >>>> @@ -1894,19 +1894,16 @@ static krb5_error_code >>>> ipadb_modify_principal(krb5_context kcontext, >>>> if (!ipactx) { >>>> return KRB5_KDB_DBNOTINITED; >>>> } >>>> - >>>> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >>>> + if (kerr != 0) { >>>> + goto done; >>>> + } >>>> ied = (struct ipadb_e_data *)entry->e_data; >>>> if (!ied || !ied->entry_dn) { >>>> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >>>> - if (kerr != 0) { >>>> - goto done; >>>> - } >>>> - >>>> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); >>>> if (kerr != 0) { >>>> goto done; >>>> } >>>> - >>>> /* FIXME: no alias allowed for now, should we allow modifies >>>> * by alias name ? */ >>>> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >>>> -- >>>> 2.1.0 >>>> >>> NACK. >>> >>> This part actually looked to me familiar and it was indeed raised in >>> past. I marked the Coverity report for this as a false positive but it >>> sprung again. >>> >>> Last time I wrote (2014-04-07): >>> ------------------------------------------------------ >>> I remember looking at this bug already in past and I looked at it again. >>> I think it is false positive. ipadb_modify_principal() is only called >>> from ipadb_put_principal() when entry for the principal has no >>> KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls >>> ipadb_entry_to_mods() with a principal which might be set to NULL. >>> However, ipadb_entry_to_mods() will only dereference this principal when >>> KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. >>> ------------------------------------------------------- >> >> Hmm... It may work for now but it also may break silently in future if we >> break current assumption "ipadb_modify_principal() is only called from >> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag >> set". >> >> Personally I'm against this kind of implicit assumptions in code. I was bitten >> tooooo may times by exactly this in BIND and I don't think we should do that >> in our code. >> >> Alexander, if you really don't want to move krb5_unparse_name() call then we >> really need to handle this "impossible" case in some other way. Maybe with an >> assert()? It would do nothing as long as your assumption holds and will >> clearly show where the problem is if we break the assumption in future. > What about following just before creating mods? > > if (principal == NULL && entry->mask & KMASK_PRINCIPAL) { > goto done; > } I don't know this piece of code so I can't say anything in particular. Are you 100 % sure that it will not cause any harm in future? I'm hesitant to introduce a goto branching which is not testable nowadays. Personally I would prefer either assert() or moving the code as proposed in the patch. Thank you for understanding. -- Petr Spacek @ Red Hat From mbabinsk at redhat.com Tue Jan 27 17:36:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Jan 2015 18:36:39 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C7C56D.9060503@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127170230.GM4383@vda.li> <54C7C56D.9060503@redhat.com> Message-ID: <54C7CCA7.9000204@redhat.com> On 01/27/2015 06:05 PM, Petr Spacek wrote: > On 27.1.2015 18:02, Alexander Bokovoy wrote: >>> >>> - slapi_search_internal_get_entry(sdn, attrs, &entry, >>> - otp_config_plugin_id(otp_config)); >>> + search_result = slapi_search_internal_get_entry(sdn, attrs, &entry, >>> + otp_config_plugin_id(otp_config)); >>> + if (search_result != LDAP_SUCCESS) { >>> + LOG_TRACE("Entry not found. Error code: %d\n", search_result); >>> + } >> I would rather say something more defensive here: >> "Unable to access LDAP entry. Perhaps it does not exist? Error code: %d\n" > > Would it be possible to print the DN? It may be useful in cases where it > actually happened ... > I will look into it. Martin^3 From mbabinsk at redhat.com Tue Jan 27 17:45:54 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 27 Jan 2015 18:45:54 +0100 Subject: [Freeipa-devel] [PATCH 0004] added dbus-python dependency to freeipa-client In-Reply-To: <54C75D5D.7070703@redhat.com> References: <54C66D0C.4020300@redhat.com> <54C75D5D.7070703@redhat.com> Message-ID: <54C7CED2.9000201@redhat.com> On 01/27/2015 10:41 AM, Martin Basti wrote: > On 26/01/15 17:36, Martin Babinsky wrote: >> See attached patch related to >> https://fedorahosted.org/freeipa/ticket/4863. >> >> Martin^3 >> >> > > Thank for your patch, > > IMO client is not dependent on dbus module, but ipapython requires dbus > module. > We should add this dependency to ipapython package, because AFAIK > ipa-client-install do not need dbus at all. > > Martin^2 > > True indeed. I have moved 'dbus-python' dependency to freeipa-python and removed it from freeipa-server. Now freeipa-python package should cover dbus-python deps for the whole freeipa-* suite. Martin^3 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0004-2-added-dbus-python-as-dependency-for-freeipa-client.patch Type: text/x-patch Size: 1149 bytes Desc: not available URL: From pspacek at redhat.com Tue Jan 27 18:00:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Jan 2015 19:00:09 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150127174115.GP4383@vda.li> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <20150127172323.GN4383@vda.li> <54C7CBCB.4020600@redhat.com> <20150127174115.GP4383@vda.li> Message-ID: <54C7D229.60505@redhat.com> On 27.1.2015 18:41, Alexander Bokovoy wrote: > On Tue, 27 Jan 2015, Petr Spacek wrote: >> On 27.1.2015 18:23, Alexander Bokovoy wrote: >>> On Tue, 27 Jan 2015, Petr Spacek wrote: >>>> On 27.1.2015 17:56, Alexander Bokovoy wrote: >>>>> On Tue, 27 Jan 2015, Martin Babinsky wrote: >>>>>> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 >>>>>> From: Martin Babinsky >>>>>> Date: Tue, 27 Jan 2015 13:21:33 +0100 >>>>>> Subject: [PATCH 3/7] proposed fix fo a defect reported in >>>>>> 'ipa_kdb_principals.c' >>>>>> >>>>>> The patch addresses the following defect reported by covscan in FreeIPA >>>>>> master: >>>>>> >>>>>> """ >>>>>> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >>>>>> assign_zero: Assigning: >>>>>> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >>>>>> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >>>>>> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >>>>>> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >>>>>> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >>>>>> deref_parm_in_call: Function "strdup" dereferences "value" >>>>>> """ >>>>>> >>>>>> Again I have consulted this with Simo and he pointed out that this may >>>>>> indeed >>>>>> be a bug and that we should always parse principal name. >>>>>> >>>>>> This is a part of series of patches related to >>>>>> https://fedorahosted.org/freeipa/ticket/4795 >>>>>> --- >>>>>> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >>>>>> 1 file changed, 4 insertions(+), 7 deletions(-) >>>>>> >>>>>> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>> b/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>> index >>>>>> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >>>>>> >>>>>> >>>>>> 100644 >>>>>> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>> @@ -1894,19 +1894,16 @@ static krb5_error_code >>>>>> ipadb_modify_principal(krb5_context kcontext, >>>>>> if (!ipactx) { >>>>>> return KRB5_KDB_DBNOTINITED; >>>>>> } >>>>>> - >>>>>> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >>>>>> + if (kerr != 0) { >>>>>> + goto done; >>>>>> + } >>>>>> ied = (struct ipadb_e_data *)entry->e_data; >>>>>> if (!ied || !ied->entry_dn) { >>>>>> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >>>>>> - if (kerr != 0) { >>>>>> - goto done; >>>>>> - } >>>>>> - >>>>>> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); >>>>>> if (kerr != 0) { >>>>>> goto done; >>>>>> } >>>>>> - >>>>>> /* FIXME: no alias allowed for now, should we allow modifies >>>>>> * by alias name ? */ >>>>>> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >>>>>> -- >>>>>> 2.1.0 >>>>>> >>>>> NACK. >>>>> >>>>> This part actually looked to me familiar and it was indeed raised in >>>>> past. I marked the Coverity report for this as a false positive but it >>>>> sprung again. >>>>> >>>>> Last time I wrote (2014-04-07): >>>>> ------------------------------------------------------ >>>>> I remember looking at this bug already in past and I looked at it again. >>>>> I think it is false positive. ipadb_modify_principal() is only called >>>>> from ipadb_put_principal() when entry for the principal has no >>>>> KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls >>>>> ipadb_entry_to_mods() with a principal which might be set to NULL. >>>>> However, ipadb_entry_to_mods() will only dereference this principal when >>>>> KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. >>>>> ------------------------------------------------------- >>>> >>>> Hmm... It may work for now but it also may break silently in future if we >>>> break current assumption "ipadb_modify_principal() is only called from >>>> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL >>>> flag >>>> set". >>>> >>>> Personally I'm against this kind of implicit assumptions in code. I was >>>> bitten >>>> tooooo may times by exactly this in BIND and I don't think we should do that >>>> in our code. >>>> >>>> Alexander, if you really don't want to move krb5_unparse_name() call then we >>>> really need to handle this "impossible" case in some other way. Maybe with an >>>> assert()? It would do nothing as long as your assumption holds and will >>>> clearly show where the problem is if we break the assumption in future. >>> What about following just before creating mods? >>> >>> if (principal == NULL && entry->mask & KMASK_PRINCIPAL) { >>> goto done; >>> } >> >> I don't know this piece of code so I can't say anything in particular. >> >> Are you 100 % sure that it will not cause any harm in future? I'm hesitant to >> introduce a goto branching which is not testable nowadays. >> >> Personally I would prefer either assert() or moving the code as proposed in >> the patch. > assert() (with exit) is wrong here. Logging a note -- OK. > > I'm opposing moving the code because this is one of functions that gets > called for _every_ Kerberos authentication as we modify last > authentication time. Does it matter? Does krb5_unparse_name() have an significant performance impact? (I did not read the code so I'm asking.) Given that the function is in authentication path, I think that it should fail if original assumptions do not hold anymore. I.e. I would modify the code to do this: if (principal == NULL && entry->mask & KMASK_PRINCIPAL) { krberr = KRB5_KDB_INTERNAL_ERROR; log("Sky is falling!"); goto done; } This would require review if all code under done: label can handle all NULL pointers gracefully. ... Isn't it too much work instead of one assert()? For an error condition which cannot ever happen (you claimed)? :-) BTW there is also an unconditional dereference ied = (struct ipadb_e_data *)entry->e_data; without check that entry is not NULL. Maybe it can not happen in current code but it should be supplemented with assert(entry != NULL) or other check. -- Petr Spacek @ Red Hat From abokovoy at redhat.com Tue Jan 27 18:52:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Jan 2015 20:52:43 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C7D229.60505@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <20150127172323.GN4383@vda.li> <54C7CBCB.4020600@redhat.com> <20150127174115.GP4383@vda.li> <54C7D229.60505@redhat.com> Message-ID: <20150127185243.GQ4383@vda.li> On Tue, 27 Jan 2015, Petr Spacek wrote: >>> I don't know this piece of code so I can't say anything in particular. >>> >>> Are you 100 % sure that it will not cause any harm in future? I'm hesitant to >>> introduce a goto branching which is not testable nowadays. >>> >>> Personally I would prefer either assert() or moving the code as proposed in >>> the patch. >> assert() (with exit) is wrong here. Logging a note -- OK. >> >> I'm opposing moving the code because this is one of functions that gets >> called for _every_ Kerberos authentication as we modify last >> authentication time. > >Does it matter? Does krb5_unparse_name() have an significant performance >impact? (I did not read the code so I'm asking.) It is calling malloc()/realloc() so yes, it does matter. We cache information about principal via DN in ied->entry_dn because we need the DN instead of the principal in most cases except the case of adding a principal to the database. >Given that the function is in authentication path, I think that it should fail >if original assumptions do not hold anymore. > >I.e. I would modify the code to do this: >if (principal == NULL && entry->mask & KMASK_PRINCIPAL) { > krberr = KRB5_KDB_INTERNAL_ERROR; > log("Sky is falling!"); > goto done; >} > >This would require review if all code under done: label can handle all NULL >pointers gracefully. > >... Isn't it too much work instead of one assert()? For an error condition >which cannot ever happen (you claimed)? :-) What would assert do? abort() the process when compiled without NDEBUG? I don't think it is what we need for the KDC. > >BTW >there is also an unconditional dereference >ied = (struct ipadb_e_data *)entry->e_data; >without check that entry is not NULL. Maybe it can not happen in current code >but it should be supplemented with assert(entry != NULL) or other check. Sometimes line has to be drawn somewhere. Whole MIT Kerberos is built in this style where defence is happening in upper layers. -- / Alexander Bokovoy From rcritten at redhat.com Tue Jan 27 18:59:18 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Jan 2015 13:59:18 -0500 Subject: [Freeipa-devel] [PATCH] 397 Do not crash when replica is unreachable in ipa-restore In-Reply-To: <54C7B2A6.7060302@redhat.com> References: <54C740FA.6090103@redhat.com> <54C7B2A6.7060302@redhat.com> Message-ID: <54C7E006.4020009@redhat.com> Martin Kosek wrote: > On 01/27/2015 08:40 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Works like a charm, ACK. > > Pushed to: > master: deb70d5b13ce0e7ec77debb4aa17d75df4c1dedd > ipa-4-1: 74853b66f092a057c22ee811e945f631e6d65059 > Sorry I missed this earlier, but this could be a timebomb. It means that there is some master out there that still has its old changelog and is waiting to push changes you may not want back to the restored master(s). It would definitely be worth testing a scenario like this: 3 masters, A, B, C. Backup A Add a bunch of data shut down C Restore A Re-init B Confirm that that data you added is gone Start up C See what happens. I suspect that data will be re-added. rob From simo at redhat.com Tue Jan 27 19:55:03 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Jan 2015 14:55:03 -0500 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C7C501.2090004@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> Message-ID: <1422388503.2970.3.camel@willson.usersys.redhat.com> On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: > On 27.1.2015 17:56, Alexander Bokovoy wrote: > > On Tue, 27 Jan 2015, Martin Babinsky wrote: > >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 > >> From: Martin Babinsky > >> Date: Tue, 27 Jan 2015 13:21:33 +0100 > >> Subject: [PATCH 3/7] proposed fix fo a defect reported in > >> 'ipa_kdb_principals.c' > >> > >> The patch addresses the following defect reported by covscan in FreeIPA > >> master: > >> > >> """ > >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: > >> assign_zero: Assigning: > >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: > >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", > >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: > >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences > >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: > >> deref_parm_in_call: Function "strdup" dereferences "value" > >> """ > >> > >> Again I have consulted this with Simo and he pointed out that this may indeed > >> be a bug and that we should always parse principal name. > >> > >> This is a part of series of patches related to > >> https://fedorahosted.org/freeipa/ticket/4795 > >> --- > >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- > >> 1 file changed, 4 insertions(+), 7 deletions(-) > >> > >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c > >> b/daemons/ipa-kdb/ipa_kdb_principals.c > >> index > >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a > >> 100644 > >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c > >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c > >> @@ -1894,19 +1894,16 @@ static krb5_error_code > >> ipadb_modify_principal(krb5_context kcontext, > >> if (!ipactx) { > >> return KRB5_KDB_DBNOTINITED; > >> } > >> - > >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> + if (kerr != 0) { > >> + goto done; > >> + } > >> ied = (struct ipadb_e_data *)entry->e_data; > >> if (!ied || !ied->entry_dn) { > >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> - if (kerr != 0) { > >> - goto done; > >> - } > >> - > >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); > >> if (kerr != 0) { > >> goto done; > >> } > >> - > >> /* FIXME: no alias allowed for now, should we allow modifies > >> * by alias name ? */ > >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); > >> -- > >> 2.1.0 > >> > > NACK. > > > > This part actually looked to me familiar and it was indeed raised in > > past. I marked the Coverity report for this as a false positive but it > > sprung again. > > > > Last time I wrote (2014-04-07): > > ------------------------------------------------------ > > I remember looking at this bug already in past and I looked at it again. > > I think it is false positive. ipadb_modify_principal() is only called > > from ipadb_put_principal() when entry for the principal has no > > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls > > ipadb_entry_to_mods() with a principal which might be set to NULL. > > However, ipadb_entry_to_mods() will only dereference this principal when > > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. > > ------------------------------------------------------- > > Hmm... It may work for now but it also may break silently in future if we > break current assumption "ipadb_modify_principal() is only called from > ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag > set". > > Personally I'm against this kind of implicit assumptions in code. I was bitten > tooooo may times by exactly this in BIND and I don't think we should do that > in our code. > > Alexander, if you really don't want to move krb5_unparse_name() call then we > really need to handle this "impossible" case in some other way. Maybe with an > assert()? It would do nothing as long as your assumption holds and will > clearly show where the problem is if we break the assumption in future. > The problem here is that we are unconditionally calling ipadb_entry_to_mods() and passing 'principal' to it. If we do not call krb5_unparse_name() then principal is NULL. If we want to keep parsing the principal as a conditional I am ok with that, but then we need to test the right condition, the code should be: +if (!ied || !ied->entry_dn || entry->mask & KMASK_PRINCIPAL) { + .. krb5_unparse_name .. +} if (!ied || !ied->entry_dn) { - .. krb5_unparse_name .. ... Later on again we call, again unconditionally krb5_free_unparsed_name() to which we pass principal again, but this function is safe when principal is NULL. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Jan 27 20:05:47 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Jan 2015 21:05:47 +0100 Subject: [Freeipa-devel] [PATCH] 397 Do not crash when replica is unreachable in ipa-restore In-Reply-To: <54C7E006.4020009@redhat.com> References: <54C740FA.6090103@redhat.com> <54C7B2A6.7060302@redhat.com> <54C7E006.4020009@redhat.com> Message-ID: <54C7EF9B.2040404@redhat.com> On 01/27/2015 07:59 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 01/27/2015 08:40 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Works like a charm, ACK. >> >> Pushed to: >> master: deb70d5b13ce0e7ec77debb4aa17d75df4c1dedd >> ipa-4-1: 74853b66f092a057c22ee811e945f631e6d65059 >> > > Sorry I missed this earlier, but this could be a timebomb. Ah, and I saw that one as a clear one. > It means that there is some master out there that still has its old > changelog and is waiting to push changes you may not want back to the > restored master(s). This is a long shot, but doesn't changes done in https://fedorahosted.org/freeipa/ticket/4822 prevent other masters to sent updates and actually force them to re-initialize from restored master? Also CCing Thierry. > It would definitely be worth testing a scenario like this: > > 3 masters, A, B, C. > > Backup A > > Add a bunch of data > > shut down C > > Restore A > > Re-init B > > Confirm that that data you added is gone > > Start up C > > See what happens. I suspect that data will be re-added. If this is the case, should we print big fat warning in ipa-restore "Some of your replication agreements could not be disabled, there are the consequences... yadda yadda yadda... Are you sure you want to continue?"? Martin From abokovoy at redhat.com Tue Jan 27 20:07:31 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Jan 2015 22:07:31 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <1422388503.2970.3.camel@willson.usersys.redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> Message-ID: <20150127200731.GB6592@redhat.com> On Tue, 27 Jan 2015, Simo Sorce wrote: >On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: >> On 27.1.2015 17:56, Alexander Bokovoy wrote: >> > On Tue, 27 Jan 2015, Martin Babinsky wrote: >> >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 >> >> From: Martin Babinsky >> >> Date: Tue, 27 Jan 2015 13:21:33 +0100 >> >> Subject: [PATCH 3/7] proposed fix fo a defect reported in >> >> 'ipa_kdb_principals.c' >> >> >> >> The patch addresses the following defect reported by covscan in FreeIPA >> >> master: >> >> >> >> """ >> >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >> >> assign_zero: Assigning: >> >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >> >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >> >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >> >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >> >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >> >> deref_parm_in_call: Function "strdup" dereferences "value" >> >> """ >> >> >> >> Again I have consulted this with Simo and he pointed out that this may indeed >> >> be a bug and that we should always parse principal name. >> >> >> >> This is a part of series of patches related to >> >> https://fedorahosted.org/freeipa/ticket/4795 >> >> --- >> >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >> >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >> >> b/daemons/ipa-kdb/ipa_kdb_principals.c >> >> index >> >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >> >> 100644 >> >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >> >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >> >> @@ -1894,19 +1894,16 @@ static krb5_error_code >> >> ipadb_modify_principal(krb5_context kcontext, >> >> if (!ipactx) { >> >> return KRB5_KDB_DBNOTINITED; >> >> } >> >> - >> >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> >> + if (kerr != 0) { >> >> + goto done; >> >> + } >> >> ied = (struct ipadb_e_data *)entry->e_data; >> >> if (!ied || !ied->entry_dn) { >> >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> >> - if (kerr != 0) { >> >> - goto done; >> >> - } >> >> - >> >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); >> >> if (kerr != 0) { >> >> goto done; >> >> } >> >> - >> >> /* FIXME: no alias allowed for now, should we allow modifies >> >> * by alias name ? */ >> >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >> >> -- >> >> 2.1.0 >> >> >> > NACK. >> > >> > This part actually looked to me familiar and it was indeed raised in >> > past. I marked the Coverity report for this as a false positive but it >> > sprung again. >> > >> > Last time I wrote (2014-04-07): >> > ------------------------------------------------------ >> > I remember looking at this bug already in past and I looked at it again. >> > I think it is false positive. ipadb_modify_principal() is only called >> > from ipadb_put_principal() when entry for the principal has no >> > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls >> > ipadb_entry_to_mods() with a principal which might be set to NULL. >> > However, ipadb_entry_to_mods() will only dereference this principal when >> > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. >> > ------------------------------------------------------- >> >> Hmm... It may work for now but it also may break silently in future if we >> break current assumption "ipadb_modify_principal() is only called from >> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag >> set". >> >> Personally I'm against this kind of implicit assumptions in code. I was bitten >> tooooo may times by exactly this in BIND and I don't think we should do that >> in our code. >> >> Alexander, if you really don't want to move krb5_unparse_name() call then we >> really need to handle this "impossible" case in some other way. Maybe with an >> assert()? It would do nothing as long as your assumption holds and will >> clearly show where the problem is if we break the assumption in future. >> > >The problem here is that we are unconditionally calling >ipadb_entry_to_mods() and passing 'principal' to it. ipadb_entry_to_mods() is fine with principal == NULL because entry->mask doesn't have KMASK_PRINCIPAL in this case. ipadb_modify_principal() is just a helper to make ipadb_put_principal() a simpler logic to understand. Note that in other parts of the code we call ipadb_put_principal(), currently only in ipa_kdb_audit_as.c, so this is our interface to the external users, including the rest of KDC. >If we do not call krb5_unparse_name() then principal is NULL. > >If we want to keep parsing the principal as a conditional I am ok with >that, but then we need to test the right condition, the code should be: > >+if (!ied || !ied->entry_dn || entry->mask & KMASK_PRINCIPAL) { >+ .. krb5_unparse_name .. >+} > >if (!ied || !ied->entry_dn) { >- .. krb5_unparse_name .. >... > >Later on again we call, again unconditionally krb5_free_unparsed_name() >to which we pass principal again, but this function is safe when >principal is NULL. The question is what we want to achieve. What KMASK_PRINCIPAL is set on the entry, we create a new principal. If it is not set, we modify existing principal. That's it. -- / Alexander Bokovoy From simo at redhat.com Tue Jan 27 20:13:22 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Jan 2015 15:13:22 -0500 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150127200731.GB6592@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> Message-ID: <1422389602.2970.5.camel@willson.usersys.redhat.com> On Tue, 2015-01-27 at 22:07 +0200, Alexander Bokovoy wrote: > On Tue, 27 Jan 2015, Simo Sorce wrote: > >On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: > >> On 27.1.2015 17:56, Alexander Bokovoy wrote: > >> > On Tue, 27 Jan 2015, Martin Babinsky wrote: > >> >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 > >> >> From: Martin Babinsky > >> >> Date: Tue, 27 Jan 2015 13:21:33 +0100 > >> >> Subject: [PATCH 3/7] proposed fix fo a defect reported in > >> >> 'ipa_kdb_principals.c' > >> >> > >> >> The patch addresses the following defect reported by covscan in FreeIPA > >> >> master: > >> >> > >> >> """ > >> >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: > >> >> assign_zero: Assigning: > >> >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: > >> >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", > >> >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: > >> >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences > >> >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: > >> >> deref_parm_in_call: Function "strdup" dereferences "value" > >> >> """ > >> >> > >> >> Again I have consulted this with Simo and he pointed out that this may indeed > >> >> be a bug and that we should always parse principal name. > >> >> > >> >> This is a part of series of patches related to > >> >> https://fedorahosted.org/freeipa/ticket/4795 > >> >> --- > >> >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- > >> >> 1 file changed, 4 insertions(+), 7 deletions(-) > >> >> > >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> b/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> index > >> >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a > >> >> 100644 > >> >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> @@ -1894,19 +1894,16 @@ static krb5_error_code > >> >> ipadb_modify_principal(krb5_context kcontext, > >> >> if (!ipactx) { > >> >> return KRB5_KDB_DBNOTINITED; > >> >> } > >> >> - > >> >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> >> + if (kerr != 0) { > >> >> + goto done; > >> >> + } > >> >> ied = (struct ipadb_e_data *)entry->e_data; > >> >> if (!ied || !ied->entry_dn) { > >> >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> >> - if (kerr != 0) { > >> >> - goto done; > >> >> - } > >> >> - > >> >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); > >> >> if (kerr != 0) { > >> >> goto done; > >> >> } > >> >> - > >> >> /* FIXME: no alias allowed for now, should we allow modifies > >> >> * by alias name ? */ > >> >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); > >> >> -- > >> >> 2.1.0 > >> >> > >> > NACK. > >> > > >> > This part actually looked to me familiar and it was indeed raised in > >> > past. I marked the Coverity report for this as a false positive but it > >> > sprung again. > >> > > >> > Last time I wrote (2014-04-07): > >> > ------------------------------------------------------ > >> > I remember looking at this bug already in past and I looked at it again. > >> > I think it is false positive. ipadb_modify_principal() is only called > >> > from ipadb_put_principal() when entry for the principal has no > >> > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls > >> > ipadb_entry_to_mods() with a principal which might be set to NULL. > >> > However, ipadb_entry_to_mods() will only dereference this principal when > >> > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. > >> > ------------------------------------------------------- > >> > >> Hmm... It may work for now but it also may break silently in future if we > >> break current assumption "ipadb_modify_principal() is only called from > >> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag > >> set". > >> > >> Personally I'm against this kind of implicit assumptions in code. I was bitten > >> tooooo may times by exactly this in BIND and I don't think we should do that > >> in our code. > >> > >> Alexander, if you really don't want to move krb5_unparse_name() call then we > >> really need to handle this "impossible" case in some other way. Maybe with an > >> assert()? It would do nothing as long as your assumption holds and will > >> clearly show where the problem is if we break the assumption in future. > >> > > > >The problem here is that we are unconditionally calling > >ipadb_entry_to_mods() and passing 'principal' to it. > ipadb_entry_to_mods() is fine with principal == NULL because entry->mask > doesn't have KMASK_PRINCIPAL in this case. ipadb_modify_principal() is > just a helper to make ipadb_put_principal() a simpler logic to > understand. > > Note that in other parts of the code we call ipadb_put_principal(), > currently only in ipa_kdb_audit_as.c, so this is our interface to the > external users, including the rest of KDC. Yeah in fact I was pondering changing ipadb_entry_to_mods() to make sure 'principal' actually is not NULL. I would consider it a good defensive measure if Martin wants to add it to this patch. The very fact we've gone over this a few times and we are discussing it means the interface is not clear and can lead to errors in future. So we need to improve the code flow. > >If we do not call krb5_unparse_name() then principal is NULL. > > > >If we want to keep parsing the principal as a conditional I am ok with > >that, but then we need to test the right condition, the code should be: > > > >+if (!ied || !ied->entry_dn || entry->mask & KMASK_PRINCIPAL) { > >+ .. krb5_unparse_name .. > >+} > > > >if (!ied || !ied->entry_dn) { > >- .. krb5_unparse_name .. > >... > > > >Later on again we call, again unconditionally krb5_free_unparsed_name() > >to which we pass principal again, but this function is safe when > >principal is NULL. > The question is what we want to achieve. What KMASK_PRINCIPAL is set on > the entry, we create a new principal. If it is not set, we modify > existing principal. That's it. Sorry I fail to parse this statement, my aim is to make the code clearer so that future modifications will not trip on this issue. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Tue Jan 27 20:20:15 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Jan 2015 22:20:15 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <1422389602.2970.5.camel@willson.usersys.redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> Message-ID: <20150127202015.GC6592@redhat.com> On Tue, 27 Jan 2015, Simo Sorce wrote: >On Tue, 2015-01-27 at 22:07 +0200, Alexander Bokovoy wrote: >> On Tue, 27 Jan 2015, Simo Sorce wrote: >> >On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: >> >> On 27.1.2015 17:56, Alexander Bokovoy wrote: >> >> > On Tue, 27 Jan 2015, Martin Babinsky wrote: >> >> >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 >> >> >> From: Martin Babinsky >> >> >> Date: Tue, 27 Jan 2015 13:21:33 +0100 >> >> >> Subject: [PATCH 3/7] proposed fix fo a defect reported in >> >> >> 'ipa_kdb_principals.c' >> >> >> >> >> >> The patch addresses the following defect reported by covscan in FreeIPA >> >> >> master: >> >> >> >> >> >> """ >> >> >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >> >> >> assign_zero: Assigning: >> >> >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >> >> >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >> >> >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >> >> >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >> >> >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >> >> >> deref_parm_in_call: Function "strdup" dereferences "value" >> >> >> """ >> >> >> >> >> >> Again I have consulted this with Simo and he pointed out that this may indeed >> >> >> be a bug and that we should always parse principal name. >> >> >> >> >> >> This is a part of series of patches related to >> >> >> https://fedorahosted.org/freeipa/ticket/4795 >> >> >> --- >> >> >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >> >> >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> >> >> >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> b/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> index >> >> >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >> >> >> 100644 >> >> >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> @@ -1894,19 +1894,16 @@ static krb5_error_code >> >> >> ipadb_modify_principal(krb5_context kcontext, >> >> >> if (!ipactx) { >> >> >> return KRB5_KDB_DBNOTINITED; >> >> >> } >> >> >> - >> >> >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> >> >> + if (kerr != 0) { >> >> >> + goto done; >> >> >> + } >> >> >> ied = (struct ipadb_e_data *)entry->e_data; >> >> >> if (!ied || !ied->entry_dn) { >> >> >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> >> >> - if (kerr != 0) { >> >> >> - goto done; >> >> >> - } >> >> >> - >> >> >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); >> >> >> if (kerr != 0) { >> >> >> goto done; >> >> >> } >> >> >> - >> >> >> /* FIXME: no alias allowed for now, should we allow modifies >> >> >> * by alias name ? */ >> >> >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >> >> >> -- >> >> >> 2.1.0 >> >> >> >> >> > NACK. >> >> > >> >> > This part actually looked to me familiar and it was indeed raised in >> >> > past. I marked the Coverity report for this as a false positive but it >> >> > sprung again. >> >> > >> >> > Last time I wrote (2014-04-07): >> >> > ------------------------------------------------------ >> >> > I remember looking at this bug already in past and I looked at it again. >> >> > I think it is false positive. ipadb_modify_principal() is only called >> >> > from ipadb_put_principal() when entry for the principal has no >> >> > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls >> >> > ipadb_entry_to_mods() with a principal which might be set to NULL. >> >> > However, ipadb_entry_to_mods() will only dereference this principal when >> >> > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. >> >> > ------------------------------------------------------- >> >> >> >> Hmm... It may work for now but it also may break silently in future if we >> >> break current assumption "ipadb_modify_principal() is only called from >> >> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag >> >> set". >> >> >> >> Personally I'm against this kind of implicit assumptions in code. I was bitten >> >> tooooo may times by exactly this in BIND and I don't think we should do that >> >> in our code. >> >> >> >> Alexander, if you really don't want to move krb5_unparse_name() call then we >> >> really need to handle this "impossible" case in some other way. Maybe with an >> >> assert()? It would do nothing as long as your assumption holds and will >> >> clearly show where the problem is if we break the assumption in future. >> >> >> > >> >The problem here is that we are unconditionally calling >> >ipadb_entry_to_mods() and passing 'principal' to it. >> ipadb_entry_to_mods() is fine with principal == NULL because entry->mask >> doesn't have KMASK_PRINCIPAL in this case. ipadb_modify_principal() is >> just a helper to make ipadb_put_principal() a simpler logic to >> understand. >> >> Note that in other parts of the code we call ipadb_put_principal(), >> currently only in ipa_kdb_audit_as.c, so this is our interface to the >> external users, including the rest of KDC. > >Yeah in fact I was pondering changing ipadb_entry_to_mods() to make sure >'principal' actually is not NULL. I would consider it a good defensive >measure if Martin wants to add it to this patch. If you want to go this way, then move out setting principal in ipadb_entry_to_mods() to a separate function and call it explicitly in case principal != NULL. The reason for that is because our cached entry will have ied->entry_dn non-NULL so it means all cached entries will get to ipadb_entry_to_mods() with principal == NULL. This is our ideal case, yet you would break it if you'd require 'principal' is not NULL in ipadb_entry_to_mods(). >The very fact we've gone over this a few times and we are discussing it >means the interface is not clear and can lead to errors in future. So we >need to improve the code flow. I think splitting out principal handling into a separate function would make it clearer and more explicit. -- / Alexander Bokovoy From tbordaz at redhat.com Tue Jan 27 20:28:04 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 27 Jan 2015 21:28:04 +0100 Subject: [Freeipa-devel] [PATCH] 397 Do not crash when replica is unreachable in ipa-restore In-Reply-To: <54C7EF9B.2040404@redhat.com> References: <54C740FA.6090103@redhat.com> <54C7B2A6.7060302@redhat.com> <54C7E006.4020009@redhat.com> <54C7EF9B.2040404@redhat.com> Message-ID: <54C7F4D4.9070004@redhat.com> On 01/27/2015 09:05 PM, Martin Kosek wrote: > On 01/27/2015 07:59 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 01/27/2015 08:40 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>> >>> Works like a charm, ACK. >>> >>> Pushed to: >>> master: deb70d5b13ce0e7ec77debb4aa17d75df4c1dedd >>> ipa-4-1: 74853b66f092a057c22ee811e945f631e6d65059 >>> >> >> Sorry I missed this earlier, but this could be a timebomb. > > Ah, and I saw that one as a clear one. > >> It means that there is some master out there that still has its old >> changelog and is waiting to push changes you may not want back to the >> restored master(s). > > This is a long shot, but doesn't changes done in > https://fedorahosted.org/freeipa/ticket/4822 > prevent other masters to sent updates and actually force them to > re-initialize from restored master? Also CCing Thierry. > >> It would definitely be worth testing a scenario like this: >> >> 3 masters, A, B, C. >> >> Backup A >> >> Add a bunch of data >> >> shut down C >> >> Restore A >> >> Re-init B >> >> Confirm that that data you added is gone >> >> Start up C >> >> See what happens. I suspect that data will be re-added. My understanding is that https://fedorahosted.org/freeipa/ticket/4822 removed the RUV (during restore) from the import ldif file. So in that case C should not be able to replicate to A, because A has no RUV (especially replicageneration). Now it needs to be tested. thanks thierry > > If this is the case, should we print big fat warning in ipa-restore > "Some of your replication agreements could not be disabled, there are > the consequences... yadda yadda yadda... Are you sure you want to > continue?"? > > Martin From simo at redhat.com Tue Jan 27 20:51:51 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Jan 2015 15:51:51 -0500 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150127202015.GC6592@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> Message-ID: <1422391911.2970.7.camel@willson.usersys.redhat.com> On Tue, 2015-01-27 at 22:20 +0200, Alexander Bokovoy wrote: > On Tue, 27 Jan 2015, Simo Sorce wrote: > >On Tue, 2015-01-27 at 22:07 +0200, Alexander Bokovoy wrote: > >> On Tue, 27 Jan 2015, Simo Sorce wrote: > >> >On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: > >> >> On 27.1.2015 17:56, Alexander Bokovoy wrote: > >> >> > On Tue, 27 Jan 2015, Martin Babinsky wrote: > >> >> >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 > >> >> >> From: Martin Babinsky > >> >> >> Date: Tue, 27 Jan 2015 13:21:33 +0100 > >> >> >> Subject: [PATCH 3/7] proposed fix fo a defect reported in > >> >> >> 'ipa_kdb_principals.c' > >> >> >> > >> >> >> The patch addresses the following defect reported by covscan in FreeIPA > >> >> >> master: > >> >> >> > >> >> >> """ > >> >> >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: > >> >> >> assign_zero: Assigning: > >> >> >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: > >> >> >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", > >> >> >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: > >> >> >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences > >> >> >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: > >> >> >> deref_parm_in_call: Function "strdup" dereferences "value" > >> >> >> """ > >> >> >> > >> >> >> Again I have consulted this with Simo and he pointed out that this may indeed > >> >> >> be a bug and that we should always parse principal name. > >> >> >> > >> >> >> This is a part of series of patches related to > >> >> >> https://fedorahosted.org/freeipa/ticket/4795 > >> >> >> --- > >> >> >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- > >> >> >> 1 file changed, 4 insertions(+), 7 deletions(-) > >> >> >> > >> >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> b/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> index > >> >> >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a > >> >> >> 100644 > >> >> >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> @@ -1894,19 +1894,16 @@ static krb5_error_code > >> >> >> ipadb_modify_principal(krb5_context kcontext, > >> >> >> if (!ipactx) { > >> >> >> return KRB5_KDB_DBNOTINITED; > >> >> >> } > >> >> >> - > >> >> >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> >> >> + if (kerr != 0) { > >> >> >> + goto done; > >> >> >> + } > >> >> >> ied = (struct ipadb_e_data *)entry->e_data; > >> >> >> if (!ied || !ied->entry_dn) { > >> >> >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> >> >> - if (kerr != 0) { > >> >> >> - goto done; > >> >> >> - } > >> >> >> - > >> >> >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); > >> >> >> if (kerr != 0) { > >> >> >> goto done; > >> >> >> } > >> >> >> - > >> >> >> /* FIXME: no alias allowed for now, should we allow modifies > >> >> >> * by alias name ? */ > >> >> >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); > >> >> >> -- > >> >> >> 2.1.0 > >> >> >> > >> >> > NACK. > >> >> > > >> >> > This part actually looked to me familiar and it was indeed raised in > >> >> > past. I marked the Coverity report for this as a false positive but it > >> >> > sprung again. > >> >> > > >> >> > Last time I wrote (2014-04-07): > >> >> > ------------------------------------------------------ > >> >> > I remember looking at this bug already in past and I looked at it again. > >> >> > I think it is false positive. ipadb_modify_principal() is only called > >> >> > from ipadb_put_principal() when entry for the principal has no > >> >> > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls > >> >> > ipadb_entry_to_mods() with a principal which might be set to NULL. > >> >> > However, ipadb_entry_to_mods() will only dereference this principal when > >> >> > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. > >> >> > ------------------------------------------------------- > >> >> > >> >> Hmm... It may work for now but it also may break silently in future if we > >> >> break current assumption "ipadb_modify_principal() is only called from > >> >> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag > >> >> set". > >> >> > >> >> Personally I'm against this kind of implicit assumptions in code. I was bitten > >> >> tooooo may times by exactly this in BIND and I don't think we should do that > >> >> in our code. > >> >> > >> >> Alexander, if you really don't want to move krb5_unparse_name() call then we > >> >> really need to handle this "impossible" case in some other way. Maybe with an > >> >> assert()? It would do nothing as long as your assumption holds and will > >> >> clearly show where the problem is if we break the assumption in future. > >> >> > >> > > >> >The problem here is that we are unconditionally calling > >> >ipadb_entry_to_mods() and passing 'principal' to it. > >> ipadb_entry_to_mods() is fine with principal == NULL because entry->mask > >> doesn't have KMASK_PRINCIPAL in this case. ipadb_modify_principal() is > >> just a helper to make ipadb_put_principal() a simpler logic to > >> understand. > >> > >> Note that in other parts of the code we call ipadb_put_principal(), > >> currently only in ipa_kdb_audit_as.c, so this is our interface to the > >> external users, including the rest of KDC. > > > >Yeah in fact I was pondering changing ipadb_entry_to_mods() to make sure > >'principal' actually is not NULL. I would consider it a good defensive > >measure if Martin wants to add it to this patch. > If you want to go this way, then move out setting principal in > ipadb_entry_to_mods() to a separate function and call it explicitly in > case principal != NULL. The reason for that is because our cached entry > will have ied->entry_dn non-NULL so it means all cached entries will get > to ipadb_entry_to_mods() with principal == NULL. This is our ideal case, > yet you would break it if you'd require 'principal' is not NULL in > ipadb_entry_to_mods(). I never said I require it to be not null, I just said that the function should check it is not null when entry->mask & KMASK_PRINCIPAL is true. Currently we do not check, we should check: if (entry->mask & KMASK_PRINCIPAL) { if (principal == NULL) { -> error out } } That's all I said. > >The very fact we've gone over this a few times and we are discussing it > >means the interface is not clear and can lead to errors in future. So we > >need to improve the code flow. > I think splitting out principal handling into a separate function would > make it clearer and more explicit. That is also an option, but won't really change the workflow. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Tue Jan 27 21:04:29 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Jan 2015 23:04:29 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <1422391911.2970.7.camel@willson.usersys.redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> <1422391911.2970.7.camel@willson.usersys.redhat.com> Message-ID: <20150127210429.GD6592@redhat.com> On Tue, 27 Jan 2015, Simo Sorce wrote: >On Tue, 2015-01-27 at 22:20 +0200, Alexander Bokovoy wrote: >> On Tue, 27 Jan 2015, Simo Sorce wrote: >> >On Tue, 2015-01-27 at 22:07 +0200, Alexander Bokovoy wrote: >> >> On Tue, 27 Jan 2015, Simo Sorce wrote: >> >> >On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: >> >> >> On 27.1.2015 17:56, Alexander Bokovoy wrote: >> >> >> > On Tue, 27 Jan 2015, Martin Babinsky wrote: >> >> >> >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 >> >> >> >> From: Martin Babinsky >> >> >> >> Date: Tue, 27 Jan 2015 13:21:33 +0100 >> >> >> >> Subject: [PATCH 3/7] proposed fix fo a defect reported in >> >> >> >> 'ipa_kdb_principals.c' >> >> >> >> >> >> >> >> The patch addresses the following defect reported by covscan in FreeIPA >> >> >> >> master: >> >> >> >> >> >> >> >> """ >> >> >> >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >> >> >> >> assign_zero: Assigning: >> >> >> >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >> >> >> >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >> >> >> >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >> >> >> >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >> >> >> >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >> >> >> >> deref_parm_in_call: Function "strdup" dereferences "value" >> >> >> >> """ >> >> >> >> >> >> >> >> Again I have consulted this with Simo and he pointed out that this may indeed >> >> >> >> be a bug and that we should always parse principal name. >> >> >> >> >> >> >> >> This is a part of series of patches related to >> >> >> >> https://fedorahosted.org/freeipa/ticket/4795 >> >> >> >> --- >> >> >> >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >> >> >> >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> >> >> >> >> >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> >> b/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> >> index >> >> >> >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >> >> >> >> 100644 >> >> >> >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >> >> >> >> @@ -1894,19 +1894,16 @@ static krb5_error_code >> >> >> >> ipadb_modify_principal(krb5_context kcontext, >> >> >> >> if (!ipactx) { >> >> >> >> return KRB5_KDB_DBNOTINITED; >> >> >> >> } >> >> >> >> - >> >> >> >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> >> >> >> + if (kerr != 0) { >> >> >> >> + goto done; >> >> >> >> + } >> >> >> >> ied = (struct ipadb_e_data *)entry->e_data; >> >> >> >> if (!ied || !ied->entry_dn) { >> >> >> >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >> >> >> >> - if (kerr != 0) { >> >> >> >> - goto done; >> >> >> >> - } >> >> >> >> - >> >> >> >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); >> >> >> >> if (kerr != 0) { >> >> >> >> goto done; >> >> >> >> } >> >> >> >> - >> >> >> >> /* FIXME: no alias allowed for now, should we allow modifies >> >> >> >> * by alias name ? */ >> >> >> >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >> >> >> >> -- >> >> >> >> 2.1.0 >> >> >> >> >> >> >> > NACK. >> >> >> > >> >> >> > This part actually looked to me familiar and it was indeed raised in >> >> >> > past. I marked the Coverity report for this as a false positive but it >> >> >> > sprung again. >> >> >> > >> >> >> > Last time I wrote (2014-04-07): >> >> >> > ------------------------------------------------------ >> >> >> > I remember looking at this bug already in past and I looked at it again. >> >> >> > I think it is false positive. ipadb_modify_principal() is only called >> >> >> > from ipadb_put_principal() when entry for the principal has no >> >> >> > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls >> >> >> > ipadb_entry_to_mods() with a principal which might be set to NULL. >> >> >> > However, ipadb_entry_to_mods() will only dereference this principal when >> >> >> > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. >> >> >> > ------------------------------------------------------- >> >> >> >> >> >> Hmm... It may work for now but it also may break silently in future if we >> >> >> break current assumption "ipadb_modify_principal() is only called from >> >> >> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag >> >> >> set". >> >> >> >> >> >> Personally I'm against this kind of implicit assumptions in code. I was bitten >> >> >> tooooo may times by exactly this in BIND and I don't think we should do that >> >> >> in our code. >> >> >> >> >> >> Alexander, if you really don't want to move krb5_unparse_name() call then we >> >> >> really need to handle this "impossible" case in some other way. Maybe with an >> >> >> assert()? It would do nothing as long as your assumption holds and will >> >> >> clearly show where the problem is if we break the assumption in future. >> >> >> >> >> > >> >> >The problem here is that we are unconditionally calling >> >> >ipadb_entry_to_mods() and passing 'principal' to it. >> >> ipadb_entry_to_mods() is fine with principal == NULL because entry->mask >> >> doesn't have KMASK_PRINCIPAL in this case. ipadb_modify_principal() is >> >> just a helper to make ipadb_put_principal() a simpler logic to >> >> understand. >> >> >> >> Note that in other parts of the code we call ipadb_put_principal(), >> >> currently only in ipa_kdb_audit_as.c, so this is our interface to the >> >> external users, including the rest of KDC. >> > >> >Yeah in fact I was pondering changing ipadb_entry_to_mods() to make sure >> >'principal' actually is not NULL. I would consider it a good defensive >> >measure if Martin wants to add it to this patch. >> If you want to go this way, then move out setting principal in >> ipadb_entry_to_mods() to a separate function and call it explicitly in >> case principal != NULL. The reason for that is because our cached entry >> will have ied->entry_dn non-NULL so it means all cached entries will get >> to ipadb_entry_to_mods() with principal == NULL. This is our ideal case, >> yet you would break it if you'd require 'principal' is not NULL in >> ipadb_entry_to_mods(). > >I never said I require it to be not null, I just said that the function >should check it is not null when entry->mask & KMASK_PRINCIPAL is true. >Currently we do not check, we should check: >if (entry->mask & KMASK_PRINCIPAL) { > if (principal == NULL) { -> error out } >} > >That's all I said. Ok, this is also a possiblity in ipadb_entry_to_mods(). I would, however, prefer singling this part out to make clear in the callers ipadb_add_principal() and ipadb_modify_principal() that we handle 'principal' separately from the rest of the fields. An attempt is attached. -- / Alexander Bokovoy -------------- next part -------------- diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index e158c23..735ac12 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -1474,10 +1474,42 @@ done: return kerr; } +static krb5_error_code ipadb_principal_to_mods(krb5_context kcontext, + struct ipadb_mods *imods, + char *principal, + int mod_op) +{ + krb5_error_code kerr; + + if (principal == NULL) { + kerr = EINVAL; + goto done; + } + + + /* KADM5_PRINCIPAL */ + if (entry->mask & KMASK_PRINCIPAL) { + kerr = ipadb_get_ldap_mod_str(imods, "krbPrincipalName", + principal, mod_op); + if (kerr) { + goto done; + } + kerr = ipadb_get_ldap_mod_str(imods, "ipaKrbPrincipalAlias", + principal, mod_op); + if (kerr) { + goto done; + } + } + + kerr = 0; + +done: + return kerr; +} + static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, struct ipadb_mods *imods, krb5_db_entry *entry, - char *principal, int mod_op) { krb5_error_code kerr; @@ -1863,8 +1895,14 @@ static krb5_error_code ipadb_add_principal(krb5_context kcontext, goto done; } + kerr = ipadb_principal_to_mods(kcontext, imods, + principal, LDAP_MOD_ADD); + if (kerr != 0) { + goto done; + } + kerr = ipadb_entry_to_mods(kcontext, imods, - entry, principal, LDAP_MOD_ADD); + entry, LDAP_MOD_ADD); if (kerr != 0) { goto done; } @@ -1895,6 +1933,11 @@ static krb5_error_code ipadb_modify_principal(krb5_context kcontext, return KRB5_KDB_DBNOTINITED; } + kerr = new_ipadb_mods(&imods); + if (kerr) { + goto done; + } + ied = (struct ipadb_e_data *)entry->e_data; if (!ied || !ied->entry_dn) { kerr = krb5_unparse_name(kcontext, entry->princ, &principal); @@ -1919,11 +1962,13 @@ static krb5_error_code ipadb_modify_principal(krb5_context kcontext, kerr = KRB5_KDB_INTERNAL_ERROR; goto done; } - } - kerr = new_ipadb_mods(&imods); - if (kerr) { - goto done; + kerr = ipadb_principal_to_mods(kcontext, imods, + principal, LDAP_MOD_REPLACE); + if (kerr != 0) { + goto done; + } + } kerr = ipadb_entry_to_mods(kcontext, imods, From simo at redhat.com Tue Jan 27 21:15:50 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Jan 2015 16:15:50 -0500 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150127210429.GD6592@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> <1422391911.2970.7.camel@willson.usersys.redhat.com> <20150127210429.GD6592@redhat.com> Message-ID: <1422393350.2970.9.camel@willson.usersys.redhat.com> On Tue, 2015-01-27 at 23:04 +0200, Alexander Bokovoy wrote: > On Tue, 27 Jan 2015, Simo Sorce wrote: > >On Tue, 2015-01-27 at 22:20 +0200, Alexander Bokovoy wrote: > >> On Tue, 27 Jan 2015, Simo Sorce wrote: > >> >On Tue, 2015-01-27 at 22:07 +0200, Alexander Bokovoy wrote: > >> >> On Tue, 27 Jan 2015, Simo Sorce wrote: > >> >> >On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: > >> >> >> On 27.1.2015 17:56, Alexander Bokovoy wrote: > >> >> >> > On Tue, 27 Jan 2015, Martin Babinsky wrote: > >> >> >> >> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 > >> >> >> >> From: Martin Babinsky > >> >> >> >> Date: Tue, 27 Jan 2015 13:21:33 +0100 > >> >> >> >> Subject: [PATCH 3/7] proposed fix fo a defect reported in > >> >> >> >> 'ipa_kdb_principals.c' > >> >> >> >> > >> >> >> >> The patch addresses the following defect reported by covscan in FreeIPA > >> >> >> >> master: > >> >> >> >> > >> >> >> >> """ > >> >> >> >> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: > >> >> >> >> assign_zero: Assigning: > >> >> >> >> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: > >> >> >> >> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", > >> >> >> >> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: > >> >> >> >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences > >> >> >> >> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: > >> >> >> >> deref_parm_in_call: Function "strdup" dereferences "value" > >> >> >> >> """ > >> >> >> >> > >> >> >> >> Again I have consulted this with Simo and he pointed out that this may indeed > >> >> >> >> be a bug and that we should always parse principal name. > >> >> >> >> > >> >> >> >> This is a part of series of patches related to > >> >> >> >> https://fedorahosted.org/freeipa/ticket/4795 > >> >> >> >> --- > >> >> >> >> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- > >> >> >> >> 1 file changed, 4 insertions(+), 7 deletions(-) > >> >> >> >> > >> >> >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> >> b/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> >> index > >> >> >> >> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a > >> >> >> >> 100644 > >> >> >> >> --- a/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> >> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c > >> >> >> >> @@ -1894,19 +1894,16 @@ static krb5_error_code > >> >> >> >> ipadb_modify_principal(krb5_context kcontext, > >> >> >> >> if (!ipactx) { > >> >> >> >> return KRB5_KDB_DBNOTINITED; > >> >> >> >> } > >> >> >> >> - > >> >> >> >> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> >> >> >> + if (kerr != 0) { > >> >> >> >> + goto done; > >> >> >> >> + } > >> >> >> >> ied = (struct ipadb_e_data *)entry->e_data; > >> >> >> >> if (!ied || !ied->entry_dn) { > >> >> >> >> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > >> >> >> >> - if (kerr != 0) { > >> >> >> >> - goto done; > >> >> >> >> - } > >> >> >> >> - > >> >> >> >> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); > >> >> >> >> if (kerr != 0) { > >> >> >> >> goto done; > >> >> >> >> } > >> >> >> >> - > >> >> >> >> /* FIXME: no alias allowed for now, should we allow modifies > >> >> >> >> * by alias name ? */ > >> >> >> >> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); > >> >> >> >> -- > >> >> >> >> 2.1.0 > >> >> >> >> > >> >> >> > NACK. > >> >> >> > > >> >> >> > This part actually looked to me familiar and it was indeed raised in > >> >> >> > past. I marked the Coverity report for this as a false positive but it > >> >> >> > sprung again. > >> >> >> > > >> >> >> > Last time I wrote (2014-04-07): > >> >> >> > ------------------------------------------------------ > >> >> >> > I remember looking at this bug already in past and I looked at it again. > >> >> >> > I think it is false positive. ipadb_modify_principal() is only called > >> >> >> > from ipadb_put_principal() when entry for the principal has no > >> >> >> > KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls > >> >> >> > ipadb_entry_to_mods() with a principal which might be set to NULL. > >> >> >> > However, ipadb_entry_to_mods() will only dereference this principal when > >> >> >> > KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. > >> >> >> > ------------------------------------------------------- > >> >> >> > >> >> >> Hmm... It may work for now but it also may break silently in future if we > >> >> >> break current assumption "ipadb_modify_principal() is only called from > >> >> >> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag > >> >> >> set". > >> >> >> > >> >> >> Personally I'm against this kind of implicit assumptions in code. I was bitten > >> >> >> tooooo may times by exactly this in BIND and I don't think we should do that > >> >> >> in our code. > >> >> >> > >> >> >> Alexander, if you really don't want to move krb5_unparse_name() call then we > >> >> >> really need to handle this "impossible" case in some other way. Maybe with an > >> >> >> assert()? It would do nothing as long as your assumption holds and will > >> >> >> clearly show where the problem is if we break the assumption in future. > >> >> >> > >> >> > > >> >> >The problem here is that we are unconditionally calling > >> >> >ipadb_entry_to_mods() and passing 'principal' to it. > >> >> ipadb_entry_to_mods() is fine with principal == NULL because entry->mask > >> >> doesn't have KMASK_PRINCIPAL in this case. ipadb_modify_principal() is > >> >> just a helper to make ipadb_put_principal() a simpler logic to > >> >> understand. > >> >> > >> >> Note that in other parts of the code we call ipadb_put_principal(), > >> >> currently only in ipa_kdb_audit_as.c, so this is our interface to the > >> >> external users, including the rest of KDC. > >> > > >> >Yeah in fact I was pondering changing ipadb_entry_to_mods() to make sure > >> >'principal' actually is not NULL. I would consider it a good defensive > >> >measure if Martin wants to add it to this patch. > >> If you want to go this way, then move out setting principal in > >> ipadb_entry_to_mods() to a separate function and call it explicitly in > >> case principal != NULL. The reason for that is because our cached entry > >> will have ied->entry_dn non-NULL so it means all cached entries will get > >> to ipadb_entry_to_mods() with principal == NULL. This is our ideal case, > >> yet you would break it if you'd require 'principal' is not NULL in > >> ipadb_entry_to_mods(). > > > >I never said I require it to be not null, I just said that the function > >should check it is not null when entry->mask & KMASK_PRINCIPAL is true. > >Currently we do not check, we should check: > >if (entry->mask & KMASK_PRINCIPAL) { > > if (principal == NULL) { -> error out } > >} > > > >That's all I said. > Ok, this is also a possiblity in ipadb_entry_to_mods(). > > I would, however, prefer singling this part out to make clear in the > callers ipadb_add_principal() and ipadb_modify_principal() that we > handle 'principal' separately from the rest of the fields. > > An attempt is attached. > The patch is incomplete, but this approach looks sensible. Martin, can you pick this up as the way to fix this coverity issue ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Wed Jan 28 07:51:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 28 Jan 2015 08:51:39 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <1422393350.2970.9.camel@willson.usersys.redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> <1422391911.2970.7.camel@willson.usersys.redhat.com> <20150127210429.GD6592@redhat.com> <1422393350.2970.9.camel@willson.usersys.redhat.com> Message-ID: <54C8950B.4000104@redhat.com> On 01/27/2015 10:15 PM, Simo Sorce wrote: > On Tue, 2015-01-27 at 23:04 +0200, Alexander Bokovoy wrote: >> On Tue, 27 Jan 2015, Simo Sorce wrote: >>> On Tue, 2015-01-27 at 22:20 +0200, Alexander Bokovoy wrote: >>>> On Tue, 27 Jan 2015, Simo Sorce wrote: >>>>> On Tue, 2015-01-27 at 22:07 +0200, Alexander Bokovoy wrote: >>>>>> On Tue, 27 Jan 2015, Simo Sorce wrote: >>>>>>> On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: >>>>>>>> On 27.1.2015 17:56, Alexander Bokovoy wrote: >>>>>>>>> On Tue, 27 Jan 2015, Martin Babinsky wrote: >>>>>>>>>> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 00:00:00 2001 >>>>>>>>>> From: Martin Babinsky >>>>>>>>>> Date: Tue, 27 Jan 2015 13:21:33 +0100 >>>>>>>>>> Subject: [PATCH 3/7] proposed fix fo a defect reported in >>>>>>>>>> 'ipa_kdb_principals.c' >>>>>>>>>> >>>>>>>>>> The patch addresses the following defect reported by covscan in FreeIPA >>>>>>>>>> master: >>>>>>>>>> >>>>>>>>>> """ >>>>>>>>>> Error: FORWARD_NULL (CWE-476): /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >>>>>>>>>> assign_zero: Assigning: >>>>>>>>>> "principal" = "NULL". /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >>>>>>>>>> var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >>>>>>>>>> which dereferences it. /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >>>>>>>>>> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >>>>>>>>>> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >>>>>>>>>> deref_parm_in_call: Function "strdup" dereferences "value" >>>>>>>>>> """ >>>>>>>>>> >>>>>>>>>> Again I have consulted this with Simo and he pointed out that this may indeed >>>>>>>>>> be a bug and that we should always parse principal name. >>>>>>>>>> >>>>>>>>>> This is a part of series of patches related to >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4795 >>>>>>>>>> --- >>>>>>>>>> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >>>>>>>>>> 1 file changed, 4 insertions(+), 7 deletions(-) >>>>>>>>>> >>>>>>>>>> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>> b/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>> index >>>>>>>>>> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >>>>>>>>>> 100644 >>>>>>>>>> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>> @@ -1894,19 +1894,16 @@ static krb5_error_code >>>>>>>>>> ipadb_modify_principal(krb5_context kcontext, >>>>>>>>>> if (!ipactx) { >>>>>>>>>> return KRB5_KDB_DBNOTINITED; >>>>>>>>>> } >>>>>>>>>> - >>>>>>>>>> + kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >>>>>>>>>> + if (kerr != 0) { >>>>>>>>>> + goto done; >>>>>>>>>> + } >>>>>>>>>> ied = (struct ipadb_e_data *)entry->e_data; >>>>>>>>>> if (!ied || !ied->entry_dn) { >>>>>>>>>> - kerr = krb5_unparse_name(kcontext, entry->princ, &principal); >>>>>>>>>> - if (kerr != 0) { >>>>>>>>>> - goto done; >>>>>>>>>> - } >>>>>>>>>> - >>>>>>>>>> kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); >>>>>>>>>> if (kerr != 0) { >>>>>>>>>> goto done; >>>>>>>>>> } >>>>>>>>>> - >>>>>>>>>> /* FIXME: no alias allowed for now, should we allow modifies >>>>>>>>>> * by alias name ? */ >>>>>>>>>> kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >>>>>>>>>> -- >>>>>>>>>> 2.1.0 >>>>>>>>>> >>>>>>>>> NACK. >>>>>>>>> >>>>>>>>> This part actually looked to me familiar and it was indeed raised in >>>>>>>>> past. I marked the Coverity report for this as a false positive but it >>>>>>>>> sprung again. >>>>>>>>> >>>>>>>>> Last time I wrote (2014-04-07): >>>>>>>>> ------------------------------------------------------ >>>>>>>>> I remember looking at this bug already in past and I looked at it again. >>>>>>>>> I think it is false positive. ipadb_modify_principal() is only called >>>>>>>>> from ipadb_put_principal() when entry for the principal has no >>>>>>>>> KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls >>>>>>>>> ipadb_entry_to_mods() with a principal which might be set to NULL. >>>>>>>>> However, ipadb_entry_to_mods() will only dereference this principal when >>>>>>>>> KMASK_PRINCIPAL flag is set in the entry, i.e. never for this code path. >>>>>>>>> ------------------------------------------------------- >>>>>>>> >>>>>>>> Hmm... It may work for now but it also may break silently in future if we >>>>>>>> break current assumption "ipadb_modify_principal() is only called from >>>>>>>> ipadb_put_principal() when entry for the principal has no KMASK_PRINCIPAL flag >>>>>>>> set". >>>>>>>> >>>>>>>> Personally I'm against this kind of implicit assumptions in code. I was bitten >>>>>>>> tooooo may times by exactly this in BIND and I don't think we should do that >>>>>>>> in our code. >>>>>>>> >>>>>>>> Alexander, if you really don't want to move krb5_unparse_name() call then we >>>>>>>> really need to handle this "impossible" case in some other way. Maybe with an >>>>>>>> assert()? It would do nothing as long as your assumption holds and will >>>>>>>> clearly show where the problem is if we break the assumption in future. >>>>>>>> >>>>>>> >>>>>>> The problem here is that we are unconditionally calling >>>>>>> ipadb_entry_to_mods() and passing 'principal' to it. >>>>>> ipadb_entry_to_mods() is fine with principal == NULL because entry->mask >>>>>> doesn't have KMASK_PRINCIPAL in this case. ipadb_modify_principal() is >>>>>> just a helper to make ipadb_put_principal() a simpler logic to >>>>>> understand. >>>>>> >>>>>> Note that in other parts of the code we call ipadb_put_principal(), >>>>>> currently only in ipa_kdb_audit_as.c, so this is our interface to the >>>>>> external users, including the rest of KDC. >>>>> >>>>> Yeah in fact I was pondering changing ipadb_entry_to_mods() to make sure >>>>> 'principal' actually is not NULL. I would consider it a good defensive >>>>> measure if Martin wants to add it to this patch. >>>> If you want to go this way, then move out setting principal in >>>> ipadb_entry_to_mods() to a separate function and call it explicitly in >>>> case principal != NULL. The reason for that is because our cached entry >>>> will have ied->entry_dn non-NULL so it means all cached entries will get >>>> to ipadb_entry_to_mods() with principal == NULL. This is our ideal case, >>>> yet you would break it if you'd require 'principal' is not NULL in >>>> ipadb_entry_to_mods(). >>> >>> I never said I require it to be not null, I just said that the function >>> should check it is not null when entry->mask & KMASK_PRINCIPAL is true. >>> Currently we do not check, we should check: >>> if (entry->mask & KMASK_PRINCIPAL) { >>> if (principal == NULL) { -> error out } >>> } >>> >>> That's all I said. >> Ok, this is also a possiblity in ipadb_entry_to_mods(). >> >> I would, however, prefer singling this part out to make clear in the >> callers ipadb_add_principal() and ipadb_modify_principal() that we >> handle 'principal' separately from the rest of the fields. >> >> An attempt is attached. >> > > The patch is incomplete, but this approach looks sensible. > > Martin, > can you pick this up as the way to fix this coverity issue ? > > Simo. > Yes I will try to implement it and post all the updates ASAP. -- Martin^3 Babinsky From mkosek at redhat.com Wed Jan 28 08:46:26 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Jan 2015 09:46:26 +0100 Subject: [Freeipa-devel] [PATCH 0004] added dbus-python dependency to freeipa-client In-Reply-To: <54C7CED2.9000201@redhat.com> References: <54C66D0C.4020300@redhat.com> <54C75D5D.7070703@redhat.com> <54C7CED2.9000201@redhat.com> Message-ID: <54C8A1E2.2020200@redhat.com> On 01/27/2015 06:45 PM, Martin Babinsky wrote: > On 01/27/2015 10:41 AM, Martin Basti wrote: >> On 26/01/15 17:36, Martin Babinsky wrote: >>> See attached patch related to >>> https://fedorahosted.org/freeipa/ticket/4863. >>> >>> Martin^3 >>> >>> >> >> Thank for your patch, >> >> IMO client is not dependent on dbus module, but ipapython requires dbus >> module. >> We should add this dependency to ipapython package, because AFAIK >> ipa-client-install do not need dbus at all. >> >> Martin^2 >> >> > True indeed. I have moved 'dbus-python' dependency to freeipa-python and > removed it from freeipa-server. > > Now freeipa-python package should cover dbus-python deps for the whole > freeipa-* suite. > > Martin^3 I do not think it should be removed from freeipa-server. After all, it is direct dependency of this package: $ git grep "import dbus" ipapython/certmonger.py:import dbus ipaserver/install/cainstance.py:import dbus ipaserver/install/httpinstance.py:import dbus It will not change the outcome, as freeipa-python is a dependency of freeipa-server, but will be better for packaging hygiene, IMO. Martin From mbabinsk at redhat.com Wed Jan 28 09:11:10 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 28 Jan 2015 10:11:10 +0100 Subject: [Freeipa-devel] [PATCH 0004] added dbus-python dependency to freeipa-client In-Reply-To: <54C8A1E2.2020200@redhat.com> References: <54C66D0C.4020300@redhat.com> <54C75D5D.7070703@redhat.com> <54C7CED2.9000201@redhat.com> <54C8A1E2.2020200@redhat.com> Message-ID: <54C8A7AE.9040702@redhat.com> On 01/28/2015 09:46 AM, Martin Kosek wrote: > On 01/27/2015 06:45 PM, Martin Babinsky wrote: >> On 01/27/2015 10:41 AM, Martin Basti wrote: >>> On 26/01/15 17:36, Martin Babinsky wrote: >>>> See attached patch related to >>>> https://fedorahosted.org/freeipa/ticket/4863. >>>> >>>> Martin^3 >>>> >>>> >>> >>> Thank for your patch, >>> >>> IMO client is not dependent on dbus module, but ipapython requires dbus >>> module. >>> We should add this dependency to ipapython package, because AFAIK >>> ipa-client-install do not need dbus at all. >>> >>> Martin^2 >>> >>> >> True indeed. I have moved 'dbus-python' dependency to freeipa-python and >> removed it from freeipa-server. >> >> Now freeipa-python package should cover dbus-python deps for the whole >> freeipa-* suite. >> >> Martin^3 > > I do not think it should be removed from freeipa-server. After all, it is > direct dependency of this package: > > $ git grep "import dbus" > ipapython/certmonger.py:import dbus > ipaserver/install/cainstance.py:import dbus > ipaserver/install/httpinstance.py:import dbus > > It will not change the outcome, as freeipa-python is a dependency of > freeipa-server, but will be better for packaging hygiene, IMO. > > Martin > Ok updated the patch accordingly. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0004-3-added-dbus-python-as-dependency-for-freeipa-python.patch Type: text/x-patch Size: 875 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 28 09:16:07 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Jan 2015 10:16:07 +0100 Subject: [Freeipa-devel] [PATCH 0004] added dbus-python dependency to freeipa-client In-Reply-To: <54C8A7AE.9040702@redhat.com> References: <54C66D0C.4020300@redhat.com> <54C75D5D.7070703@redhat.com> <54C7CED2.9000201@redhat.com> <54C8A1E2.2020200@redhat.com> <54C8A7AE.9040702@redhat.com> Message-ID: <54C8A8D7.7060207@redhat.com> On 01/28/2015 10:11 AM, Martin Babinsky wrote: > On 01/28/2015 09:46 AM, Martin Kosek wrote: >> On 01/27/2015 06:45 PM, Martin Babinsky wrote: >>> On 01/27/2015 10:41 AM, Martin Basti wrote: >>>> On 26/01/15 17:36, Martin Babinsky wrote: >>>>> See attached patch related to >>>>> https://fedorahosted.org/freeipa/ticket/4863. >>>>> >>>>> Martin^3 >>>>> >>>>> >>>> >>>> Thank for your patch, >>>> >>>> IMO client is not dependent on dbus module, but ipapython requires dbus >>>> module. >>>> We should add this dependency to ipapython package, because AFAIK >>>> ipa-client-install do not need dbus at all. >>>> >>>> Martin^2 >>>> >>>> >>> True indeed. I have moved 'dbus-python' dependency to freeipa-python and >>> removed it from freeipa-server. >>> >>> Now freeipa-python package should cover dbus-python deps for the whole >>> freeipa-* suite. >>> >>> Martin^3 >> >> I do not think it should be removed from freeipa-server. After all, it is >> direct dependency of this package: >> >> $ git grep "import dbus" >> ipapython/certmonger.py:import dbus >> ipaserver/install/cainstance.py:import dbus >> ipaserver/install/httpinstance.py:import dbus >> >> It will not change the outcome, as freeipa-python is a dependency of >> freeipa-server, but will be better for packaging hygiene, IMO. >> >> Martin >> > > Ok updated the patch accordingly. > This is fine, ACK. Pushed to: master: debb9974988b4a89d0aab8ea8c3b3a1a54397d1f ipa-4-1: f5352a8f2f777dce3bf91ac63e04e75532053762 Martin From mbabinsk at redhat.com Wed Jan 28 11:05:21 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 28 Jan 2015 12:05:21 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C8950B.4000104@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127165610.GH4383@vda.li> <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> <1422391911.2970.7.camel@willson.usersys.redhat.com> <20150127210429.GD6592@redhat.com> <1422393350.2970.9.camel@willson.usersys.redhat.com> <54C8950B.4000104@redhat.com> Message-ID: <54C8C271.3020000@redhat.com> On 01/28/2015 08:51 AM, Martin Babinsky wrote: > On 01/27/2015 10:15 PM, Simo Sorce wrote: >> On Tue, 2015-01-27 at 23:04 +0200, Alexander Bokovoy wrote: >>> On Tue, 27 Jan 2015, Simo Sorce wrote: >>>> On Tue, 2015-01-27 at 22:20 +0200, Alexander Bokovoy wrote: >>>>> On Tue, 27 Jan 2015, Simo Sorce wrote: >>>>>> On Tue, 2015-01-27 at 22:07 +0200, Alexander Bokovoy wrote: >>>>>>> On Tue, 27 Jan 2015, Simo Sorce wrote: >>>>>>>> On Tue, 2015-01-27 at 18:04 +0100, Petr Spacek wrote: >>>>>>>>> On 27.1.2015 17:56, Alexander Bokovoy wrote: >>>>>>>>>> On Tue, 27 Jan 2015, Martin Babinsky wrote: >>>>>>>>>>> From 23a823c3c5933d5c14342e15c00599af74b84118 Mon Sep 17 >>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>> From: Martin Babinsky >>>>>>>>>>> Date: Tue, 27 Jan 2015 13:21:33 +0100 >>>>>>>>>>> Subject: [PATCH 3/7] proposed fix fo a defect reported in >>>>>>>>>>> 'ipa_kdb_principals.c' >>>>>>>>>>> >>>>>>>>>>> The patch addresses the following defect reported by covscan >>>>>>>>>>> in FreeIPA >>>>>>>>>>> master: >>>>>>>>>>> >>>>>>>>>>> """ >>>>>>>>>>> Error: FORWARD_NULL (CWE-476): >>>>>>>>>>> /daemons/ipa-kdb/ipa_kdb_principals.c:1886: >>>>>>>>>>> assign_zero: Assigning: >>>>>>>>>>> "principal" = "NULL". >>>>>>>>>>> /daemons/ipa-kdb/ipa_kdb_principals.c:1929: >>>>>>>>>>> var_deref_model: Passing null pointer "principal" to >>>>>>>>>>> "ipadb_entry_to_mods", >>>>>>>>>>> which dereferences it. >>>>>>>>>>> /daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >>>>>>>>>>> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" >>>>>>>>>>> dereferences >>>>>>>>>>> "principal". /daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >>>>>>>>>>> deref_parm_in_call: Function "strdup" dereferences "value" >>>>>>>>>>> """ >>>>>>>>>>> >>>>>>>>>>> Again I have consulted this with Simo and he pointed out that >>>>>>>>>>> this may indeed >>>>>>>>>>> be a bug and that we should always parse principal name. >>>>>>>>>>> >>>>>>>>>>> This is a part of series of patches related to >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4795 >>>>>>>>>>> --- >>>>>>>>>>> daemons/ipa-kdb/ipa_kdb_principals.c | 11 ++++------- >>>>>>>>>>> 1 file changed, 4 insertions(+), 7 deletions(-) >>>>>>>>>>> >>>>>>>>>>> diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>>> b/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>>> index >>>>>>>>>>> e158c236eab5c7c5a7c12664dbde5d51cc55406d..760faeef224701c3dc4ee69d16df043e9c622d9a >>>>>>>>>>> >>>>>>>>>>> 100644 >>>>>>>>>>> --- a/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>>> +++ b/daemons/ipa-kdb/ipa_kdb_principals.c >>>>>>>>>>> @@ -1894,19 +1894,16 @@ static krb5_error_code >>>>>>>>>>> ipadb_modify_principal(krb5_context kcontext, >>>>>>>>>>> if (!ipactx) { >>>>>>>>>>> return KRB5_KDB_DBNOTINITED; >>>>>>>>>>> } >>>>>>>>>>> - >>>>>>>>>>> + kerr = krb5_unparse_name(kcontext, entry->princ, >>>>>>>>>>> &principal); >>>>>>>>>>> + if (kerr != 0) { >>>>>>>>>>> + goto done; >>>>>>>>>>> + } >>>>>>>>>>> ied = (struct ipadb_e_data *)entry->e_data; >>>>>>>>>>> if (!ied || !ied->entry_dn) { >>>>>>>>>>> - kerr = krb5_unparse_name(kcontext, entry->princ, >>>>>>>>>>> &principal); >>>>>>>>>>> - if (kerr != 0) { >>>>>>>>>>> - goto done; >>>>>>>>>>> - } >>>>>>>>>>> - >>>>>>>>>>> kerr = ipadb_fetch_principals(ipactx, 0, principal, >>>>>>>>>>> &res); >>>>>>>>>>> if (kerr != 0) { >>>>>>>>>>> goto done; >>>>>>>>>>> } >>>>>>>>>>> - >>>>>>>>>>> /* FIXME: no alias allowed for now, should we allow >>>>>>>>>>> modifies >>>>>>>>>>> * by alias name ? */ >>>>>>>>>>> kerr = ipadb_find_principal(kcontext, 0, res, >>>>>>>>>>> &principal, &lentry); >>>>>>>>>>> -- >>>>>>>>>>> 2.1.0 >>>>>>>>>>> >>>>>>>>>> NACK. >>>>>>>>>> >>>>>>>>>> This part actually looked to me familiar and it was indeed >>>>>>>>>> raised in >>>>>>>>>> past. I marked the Coverity report for this as a false >>>>>>>>>> positive but it >>>>>>>>>> sprung again. >>>>>>>>>> >>>>>>>>>> Last time I wrote (2014-04-07): >>>>>>>>>> ------------------------------------------------------ >>>>>>>>>> I remember looking at this bug already in past and I looked at >>>>>>>>>> it again. >>>>>>>>>> I think it is false positive. ipadb_modify_principal() is only >>>>>>>>>> called >>>>>>>>>> from ipadb_put_principal() when entry for the principal has no >>>>>>>>>> KMASK_PRINCIPAL flag set. Next, ipadb_modify_principal() calls >>>>>>>>>> ipadb_entry_to_mods() with a principal which might be set to >>>>>>>>>> NULL. >>>>>>>>>> However, ipadb_entry_to_mods() will only dereference this >>>>>>>>>> principal when >>>>>>>>>> KMASK_PRINCIPAL flag is set in the entry, i.e. never for this >>>>>>>>>> code path. >>>>>>>>>> ------------------------------------------------------- >>>>>>>>> >>>>>>>>> Hmm... It may work for now but it also may break silently in >>>>>>>>> future if we >>>>>>>>> break current assumption "ipadb_modify_principal() is only >>>>>>>>> called from >>>>>>>>> ipadb_put_principal() when entry for the principal has no >>>>>>>>> KMASK_PRINCIPAL flag >>>>>>>>> set". >>>>>>>>> >>>>>>>>> Personally I'm against this kind of implicit assumptions in >>>>>>>>> code. I was bitten >>>>>>>>> tooooo may times by exactly this in BIND and I don't think we >>>>>>>>> should do that >>>>>>>>> in our code. >>>>>>>>> >>>>>>>>> Alexander, if you really don't want to move krb5_unparse_name() >>>>>>>>> call then we >>>>>>>>> really need to handle this "impossible" case in some other way. >>>>>>>>> Maybe with an >>>>>>>>> assert()? It would do nothing as long as your assumption holds >>>>>>>>> and will >>>>>>>>> clearly show where the problem is if we break the assumption in >>>>>>>>> future. >>>>>>>>> >>>>>>>> >>>>>>>> The problem here is that we are unconditionally calling >>>>>>>> ipadb_entry_to_mods() and passing 'principal' to it. >>>>>>> ipadb_entry_to_mods() is fine with principal == NULL because >>>>>>> entry->mask >>>>>>> doesn't have KMASK_PRINCIPAL in this case. >>>>>>> ipadb_modify_principal() is >>>>>>> just a helper to make ipadb_put_principal() a simpler logic to >>>>>>> understand. >>>>>>> >>>>>>> Note that in other parts of the code we call ipadb_put_principal(), >>>>>>> currently only in ipa_kdb_audit_as.c, so this is our interface to >>>>>>> the >>>>>>> external users, including the rest of KDC. >>>>>> >>>>>> Yeah in fact I was pondering changing ipadb_entry_to_mods() to >>>>>> make sure >>>>>> 'principal' actually is not NULL. I would consider it a good >>>>>> defensive >>>>>> measure if Martin wants to add it to this patch. >>>>> If you want to go this way, then move out setting principal in >>>>> ipadb_entry_to_mods() to a separate function and call it explicitly in >>>>> case principal != NULL. The reason for that is because our cached >>>>> entry >>>>> will have ied->entry_dn non-NULL so it means all cached entries >>>>> will get >>>>> to ipadb_entry_to_mods() with principal == NULL. This is our ideal >>>>> case, >>>>> yet you would break it if you'd require 'principal' is not NULL in >>>>> ipadb_entry_to_mods(). >>>> >>>> I never said I require it to be not null, I just said that the function >>>> should check it is not null when entry->mask & KMASK_PRINCIPAL is true. >>>> Currently we do not check, we should check: >>>> if (entry->mask & KMASK_PRINCIPAL) { >>>> if (principal == NULL) { -> error out } >>>> } >>>> >>>> That's all I said. >>> Ok, this is also a possiblity in ipadb_entry_to_mods(). >>> >>> I would, however, prefer singling this part out to make clear in the >>> callers ipadb_add_principal() and ipadb_modify_principal() that we >>> handle 'principal' separately from the rest of the fields. >>> >>> An attempt is attached. >>> >> >> The patch is incomplete, but this approach looks sensible. >> >> Martin, >> can you pick this up as the way to fix this coverity issue ? >> >> Simo. >> > Yes I will try to implement it and post all the updates ASAP. > I have tried to incorporate Alexander's patch to the 'ipa_kdb_principals.c'. However covscan is still not happy about it and reports FORWARD_NULL defect: """ Error: FORWARD_NULL (CWE-476): freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1926: assign_zero: Assigning: "principal" = "NULL". freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1974: var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", which dereferences it. freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1525:9: deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences "principal". freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: deref_parm_in_call: Function "strdup" dereferences "value". """ Should I keep the changes and add annotation marking it as false positive? -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0007-2-proposed-fix-fo-a-defect-reported-in-ipa_kdb_princip.patch Type: text/x-patch Size: 3978 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jan 28 11:11:26 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 28 Jan 2015 13:11:26 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C8C271.3020000@redhat.com> References: <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> <1422391911.2970.7.camel@willson.usersys.redhat.com> <20150127210429.GD6592@redhat.com> <1422393350.2970.9.camel@willson.usersys.redhat.com> <54C8950B.4000104@redhat.com> <54C8C271.3020000@redhat.com> Message-ID: <20150128111126.GH6592@redhat.com> On Wed, 28 Jan 2015, Martin Babinsky wrote: >>> can you pick this up as the way to fix this coverity issue ? >>> >>> Simo. >>> >> Yes I will try to implement it and post all the updates ASAP. >> > > I have tried to incorporate Alexander's patch to the 'ipa_kdb_principals.c'. > However covscan is still not happy about it and reports FORWARD_NULL defect: > > """ > Error: FORWARD_NULL (CWE-476): > freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1926: > assign_zero: Assigning: "principal" = "NULL". > freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1974: > var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", > which dereferences it. > freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1525:9: > deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences > "principal". > freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: > deref_parm_in_call: Function "strdup" dereferences "value". > """ > > Should I keep the changes and add annotation marking it as false positive? You actually missed part of my patch which removed 'principal' argument of ipadb_entry_to_mods(). When 'principal' processing is moved to a separate function, 'principal' is not needed anymore in the ipadb_entry_to_mods() and thus can be removed. I didn't finish removing the actual code for the KMASK_PRINCIPAL from the ipadb_entry_to_mods() and this is what Simo called is 'incomplete' in my patch. Removing it would remove errors reported by covscan. -- / Alexander Bokovoy From mbabinsk at redhat.com Wed Jan 28 12:06:32 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 28 Jan 2015 13:06:32 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150128111126.GH6592@redhat.com> References: <54C7C501.2090004@redhat.com> <1422388503.2970.3.camel@willson.usersys.redhat.com> <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> <1422391911.2970.7.camel@willson.usersys.redhat.com> <20150127210429.GD6592@redhat.com> <1422393350.2970.9.camel@willson.usersys.redhat.com> <54C8950B.4000104@redhat.com> <54C8C271.3020000@redhat.com> <20150128111126.GH6592@redhat.com> Message-ID: <54C8D0C8.4070102@redhat.com> On 01/28/2015 12:11 PM, Alexander Bokovoy wrote: > On Wed, 28 Jan 2015, Martin Babinsky wrote: >>>> can you pick this up as the way to fix this coverity issue ? >>>> >>>> Simo. >>>> >>> Yes I will try to implement it and post all the updates ASAP. >>> >> >> I have tried to incorporate Alexander's patch to the >> 'ipa_kdb_principals.c'. However covscan is still not happy about it >> and reports FORWARD_NULL defect: >> >> """ >> Error: FORWARD_NULL (CWE-476): >> freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1926: >> assign_zero: Assigning: "principal" = "NULL". >> freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1974: >> var_deref_model: Passing null pointer "principal" to >> "ipadb_entry_to_mods", which dereferences it. >> freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1525:9: >> deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >> "principal". >> freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >> deref_parm_in_call: Function "strdup" dereferences "value". >> """ >> >> Should I keep the changes and add annotation marking it as false >> positive? > You actually missed part of my patch which removed 'principal' argument > of ipadb_entry_to_mods(). When 'principal' processing is moved to a > separate function, 'principal' is not needed anymore in the > ipadb_entry_to_mods() and thus can be removed. I didn't finish removing > the actual code for the KMASK_PRINCIPAL from the ipadb_entry_to_mods() > and this is what Simo called is 'incomplete' in my patch. > > Removing it would remove errors reported by covscan. > > Oh I'm sorry Alexander, looks like my ability to comprehend written text "excels" today. I'm attaching the updated patch. This one really fixes the defect. If it's OK then I will once again send the whole series of patches (including updated ones) for review. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0007-4-proposed-fix-to-a-defect-reported-in-ipa_kdb_princip.patch Type: text/x-patch Size: 5376 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jan 28 12:19:21 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 28 Jan 2015 14:19:21 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C8D0C8.4070102@redhat.com> References: <20150127200731.GB6592@redhat.com> <1422389602.2970.5.camel@willson.usersys.redhat.com> <20150127202015.GC6592@redhat.com> <1422391911.2970.7.camel@willson.usersys.redhat.com> <20150127210429.GD6592@redhat.com> <1422393350.2970.9.camel@willson.usersys.redhat.com> <54C8950B.4000104@redhat.com> <54C8C271.3020000@redhat.com> <20150128111126.GH6592@redhat.com> <54C8D0C8.4070102@redhat.com> Message-ID: <20150128121921.GI6592@redhat.com> On Wed, 28 Jan 2015, Martin Babinsky wrote: >On 01/28/2015 12:11 PM, Alexander Bokovoy wrote: >>On Wed, 28 Jan 2015, Martin Babinsky wrote: >>>>>can you pick this up as the way to fix this coverity issue ? >>>>> >>>>>Simo. >>>>> >>>>Yes I will try to implement it and post all the updates ASAP. >>>> >>> >>>I have tried to incorporate Alexander's patch to the >>>'ipa_kdb_principals.c'. However covscan is still not happy about it >>>and reports FORWARD_NULL defect: >>> >>>""" >>>Error: FORWARD_NULL (CWE-476): >>>freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1926: >>>assign_zero: Assigning: "principal" = "NULL". >>>freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1974: >>>var_deref_model: Passing null pointer "principal" to >>>"ipadb_entry_to_mods", which dereferences it. >>>freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1525:9: >>>deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >>>"principal". >>>freeipa-4.1.99.201501280935GITbeaceb7/daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >>>deref_parm_in_call: Function "strdup" dereferences "value". >>>""" >>> >>>Should I keep the changes and add annotation marking it as false >>>positive? >>You actually missed part of my patch which removed 'principal' argument >>of ipadb_entry_to_mods(). When 'principal' processing is moved to a >>separate function, 'principal' is not needed anymore in the >>ipadb_entry_to_mods() and thus can be removed. I didn't finish removing >>the actual code for the KMASK_PRINCIPAL from the ipadb_entry_to_mods() >>and this is what Simo called is 'incomplete' in my patch. >> >>Removing it would remove errors reported by covscan. >> >> >Oh I'm sorry Alexander, looks like my ability to comprehend written >text "excels" today. > >I'm attaching the updated patch. This one really fixes the defect. If >it's OK then I will once again send the whole series of patches >(including updated ones) for review. Few small comments inline in the patch after I re-read it in more detail. :) > >-- >Martin^3 Babinsky >From 66367394feebced7ca712075dc804becad6ae667 Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Wed, 28 Jan 2015 12:53:22 +0100 >Subject: [PATCH 3/7] proposed a fix to a defect reported in 'ipa_kdb_principals.c' > >The patch addresses the following defect reported by covscan in FreeIPA >master: > >""" >Error: FORWARD_NULL (CWE-476): >/daemons/ipa-kdb/ipa_kdb_principals.c:1886: assign_zero: Assigning: >"principal" = "NULL". >/daemons/ipa-kdb/ipa_kdb_principals.c:1929: >var_deref_model: Passing null pointer "principal" to "ipadb_entry_to_mods", >which dereferences it. >/daemons/ipa-kdb/ipa_kdb_principals.c:1491:9: >deref_parm_in_call: Function "ipadb_get_ldap_mod_str" dereferences >"principal". >/daemons/ipa-kdb/ipa_kdb_principals.c:1174:5: >deref_parm_in_call: Function "strdup" dereferences "value" >""" > >This is a part of series of patches related to >https://fedorahosted.org/freeipa/ticket/4795 > >--- > daemons/ipa-kdb/ipa_kdb_principals.c | 78 ++++++++++++++++++++++++------------ > 1 file changed, 53 insertions(+), 25 deletions(-) > >diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c >index e158c236eab5c7c5a7c12664dbde5d51cc55406d..b2752d974a7441851903a44d1a983ff180f7cb4f 100644 >--- a/daemons/ipa-kdb/ipa_kdb_principals.c >+++ b/daemons/ipa-kdb/ipa_kdb_principals.c >@@ -1474,10 +1474,43 @@ done: > return kerr; > } > >+static krb5_error_code ipadb_principal_to_mods(krb5_context kcontext, >+ struct ipadb_mods *imods, >+ krb5_db_entry *entry, you can remove 'entry' argument here. Given that we call ipadb_principal_to_mods() explicitly now, the check for (entry->mask & KMASK_PRINCIPAL) is not needed at this level. If 'principal' is NULL, we'll bail out. If it is not NULL, we add it into mods, this makes the whole independent of 'entry'. The differentiation based on the KMASK_PRINCIPAL happens in ipadb_put_principal() where we decide what higher level helper to call -- to add principal or to modify it. In both cases we actually add 'principal' to the 'imods' but with different LDAP operation (ADD or REPLACE). >+ char *principal, >+ int mod_op) >+{ >+ krb5_error_code kerr; >+ >+ if (principal == NULL) { >+ kerr = EINVAL; >+ goto done; >+ } >+ >+ >+ /* KADM5_PRINCIPAL */ >+ if (entry->mask & KMASK_PRINCIPAL) { you can now remove this condition. >+ kerr = ipadb_get_ldap_mod_str(imods, "krbPrincipalName", >+ principal, mod_op); >+ if (kerr) { >+ goto done; >+ } >+ kerr = ipadb_get_ldap_mod_str(imods, "ipaKrbPrincipalAlias", >+ principal, mod_op); >+ if (kerr) { >+ goto done; >+ } >+ } >+ >+ kerr = 0; >+ >+done: >+ return kerr; >+} >+ > static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, > struct ipadb_mods *imods, > krb5_db_entry *entry, >- char *principal, > int mod_op) > { > krb5_error_code kerr; >@@ -1486,20 +1519,6 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, > > /* check each mask flag in order */ > >- /* KADM5_PRINCIPAL */ >- if (entry->mask & KMASK_PRINCIPAL) { >- kerr = ipadb_get_ldap_mod_str(imods, "krbPrincipalName", >- principal, mod_op); >- if (kerr) { >- goto done; >- } >- kerr = ipadb_get_ldap_mod_str(imods, "ipaKrbPrincipalAlias", >- principal, mod_op); >- if (kerr) { >- goto done; >- } >- } >- > /* KADM5_PRINC_EXPIRE_TIME */ > if (entry->mask & KMASK_PRINC_EXPIRE_TIME) { > kerr = ipadb_get_ldap_mod_time(imods, >@@ -1863,8 +1882,13 @@ static krb5_error_code ipadb_add_principal(krb5_context kcontext, > goto done; > } > >- kerr = ipadb_entry_to_mods(kcontext, imods, >- entry, principal, LDAP_MOD_ADD); >+ kerr = ipadb_principal_to_mods(kcontext, imods, entry, >+ principal, LDAP_MOD_ADD); >+ if (kerr != 0) { >+ goto done; >+ } >+ >+ kerr = ipadb_entry_to_mods(kcontext, imods, entry, LDAP_MOD_ADD); > if (kerr != 0) { > goto done; > } >@@ -1895,18 +1919,21 @@ static krb5_error_code ipadb_modify_principal(krb5_context kcontext, > return KRB5_KDB_DBNOTINITED; > } > >+ kerr = new_ipadb_mods(&imods); >+ if (kerr) { >+ goto done; >+ } >+ > ied = (struct ipadb_e_data *)entry->e_data; > if (!ied || !ied->entry_dn) { > kerr = krb5_unparse_name(kcontext, entry->princ, &principal); > if (kerr != 0) { > goto done; > } >- > kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); > if (kerr != 0) { > goto done; > } >- > /* FIXME: no alias allowed for now, should we allow modifies > * by alias name ? */ > kerr = ipadb_find_principal(kcontext, 0, res, &principal, &lentry); >@@ -1919,15 +1946,16 @@ static krb5_error_code ipadb_modify_principal(krb5_context kcontext, > kerr = KRB5_KDB_INTERNAL_ERROR; > goto done; > } >- } > >- kerr = new_ipadb_mods(&imods); >- if (kerr) { >- goto done; >+ kerr = ipadb_principal_to_mods(kcontext, imods, entry, >+ principal, LDAP_MOD_REPLACE); >+ if (kerr != 0) { >+ goto done; >+ } >+ > } > >- kerr = ipadb_entry_to_mods(kcontext, imods, >- entry, principal, LDAP_MOD_REPLACE); >+ kerr = ipadb_entry_to_mods(kcontext, imods, entry, LDAP_MOD_REPLACE); > if (kerr != 0) { > goto done; > } >-- >2.1.0 > -- / Alexander Bokovoy From pspacek at redhat.com Wed Jan 28 12:39:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 28 Jan 2015 13:39:59 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C7CCA7.9000204@redhat.com> References: <54C7BB20.1080109@redhat.com> <20150127170230.GM4383@vda.li> <54C7C56D.9060503@redhat.com> <54C7CCA7.9000204@redhat.com> Message-ID: <54C8D89F.2010605@redhat.com> On 27.1.2015 18:36, Martin Babinsky wrote: > On 01/27/2015 06:05 PM, Petr Spacek wrote: >> On 27.1.2015 18:02, Alexander Bokovoy wrote: >>>> >>>> - slapi_search_internal_get_entry(sdn, attrs, &entry, >>>> - otp_config_plugin_id(otp_config)); >>>> + search_result = slapi_search_internal_get_entry(sdn, attrs, &entry, >>>> + otp_config_plugin_id(otp_config)); >>>> + if (search_result != LDAP_SUCCESS) { >>>> + LOG_TRACE("Entry not found. Error code: %d\n", search_result); >>>> + } >>> I would rather say something more defensive here: >>> "Unable to access LDAP entry. Perhaps it does not exist? Error code: %d\n" >> >> Would it be possible to print the DN? It may be useful in cases where it >> actually happened ... >> > I will look into it. BTW the error message should also contain __FILE__ and __LINE__ values to unambiguously identify what happened - even if the error message "Unable to access LDAP entry. Perhaps it does not exist? Error code: %d\n" is the same on multiple places. Thank you! -- Petr^2 Spacek From mbabinsk at redhat.com Wed Jan 28 12:55:39 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 28 Jan 2015 13:55:39 +0100 Subject: [Freeipa-devel] [PATCH 0185] Use dyndns_update instead of deprecated ipa_dyndns_update in sssd.conf In-Reply-To: <54BD01C9.80503@redhat.com> References: <54BCF280.8010407@redhat.com> <54BCF4D8.1060609@redhat.com> <20150119122427.GC24278@hendrix.lan> <54BD01C9.80503@redhat.com> Message-ID: <54C8DC4B.7060606@redhat.com> On 01/19/2015 02:08 PM, Martin Basti wrote: > On 19/01/15 13:24, Jakub Hrozek wrote: >> On Mon, Jan 19, 2015 at 01:13:12PM +0100, Martin Kosek wrote: >>> On 01/19/2015 01:03 PM, Martin Basti wrote: >>>> ipa_dyndns_update option is deprecated in sssd. >>>> >>>> Patch attached. >>> Can you please create a ticket? It is a non-trivial change. >>> >>> I am also wondering if somebody from SSSD could double check that the >>> dyndns >>> configuration added to sssd.conf by ipa-client-install is indeed sane >>> and >>> recommended. >> LGTM. > Ticket: > https://fedorahosted.org/freeipa/ticket/4849 > > Patch with ticket attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me. ACK -- Martin^3 Babinsky From mkosek at redhat.com Wed Jan 28 13:29:32 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Jan 2015 14:29:32 +0100 Subject: [Freeipa-devel] [PATCH 0185] Use dyndns_update instead of deprecated ipa_dyndns_update in sssd.conf In-Reply-To: <54C8DC4B.7060606@redhat.com> References: <54BCF280.8010407@redhat.com> <54BCF4D8.1060609@redhat.com> <20150119122427.GC24278@hendrix.lan> <54BD01C9.80503@redhat.com> <54C8DC4B.7060606@redhat.com> Message-ID: <54C8E43C.1070509@redhat.com> On 01/28/2015 01:55 PM, Martin Babinsky wrote: > On 01/19/2015 02:08 PM, Martin Basti wrote: >> On 19/01/15 13:24, Jakub Hrozek wrote: >>> On Mon, Jan 19, 2015 at 01:13:12PM +0100, Martin Kosek wrote: >>>> On 01/19/2015 01:03 PM, Martin Basti wrote: >>>>> ipa_dyndns_update option is deprecated in sssd. >>>>> >>>>> Patch attached. >>>> Can you please create a ticket? It is a non-trivial change. >>>> >>>> I am also wondering if somebody from SSSD could double check that the >>>> dyndns >>>> configuration added to sssd.conf by ipa-client-install is indeed sane >>>> and >>>> recommended. >>> LGTM. >> Ticket: >> https://fedorahosted.org/freeipa/ticket/4849 >> >> Patch with ticket attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Works for me. > > ACK > Thanks. I just fixed 2 typos and the commit message and pushed to: master: e29f9280fd33b55c096289e34cd98300f618b5f4 ipa-4-1: 031bdca03077b39f16eb0e938a1087aefd272ea8 Martin From mbabinsk at redhat.com Wed Jan 28 13:53:19 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 28 Jan 2015 14:53:19 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C7BB20.1080109@redhat.com> References: <54C7BB20.1080109@redhat.com> Message-ID: <54C8E9CF.5060206@redhat.com> On 01/27/2015 05:21 PM, Martin Babinsky wrote: > This series of patches is related to > https://fedorahosted.org/freeipa/ticket/4795. > > The attached patches attempt to address some of the defects encountered > during running covscan on freeipa-master branch. > > The complete list is here: > http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html > > > These patches do not fix defects 1 to 22 which occur in a code generated > by asn1c, defect 23 which is related to > https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead code). > > Each patch contains a detailed description of a defect and a proposed > fix to address it. > > Martin^3 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Attaching updated patches. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0005-2-added-warning-message-after-default-branch.patch Type: text/x-patch Size: 3239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0006-1-proposed-fix-for-a-defect-reported-in-ipa_kdb_mspac.patch Type: text/x-patch Size: 1808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0007-5-proposed-fix-to-a-defect-reported-in-ipa_kdb_princip.patch Type: text/x-patch Size: 5137 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0008-2-proposed-fix-for-a-defect-reported-in-ipa_otp_lastto.patch Type: text/x-patch Size: 3654 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0009-1-added-an-informational-comment-about-intentional-fal.patch Type: text/x-patch Size: 1679 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0010-2-added-a-debug-message-to-ipa_uuid.c.patch Type: text/x-patch Size: 2158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0011-2-proposed-fix-for-a-defect-found-in-otp_config.c.patch Type: text/x-patch Size: 4540 bytes Desc: not available URL: From simo at redhat.com Wed Jan 28 14:37:43 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Jan 2015 09:37:43 -0500 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C8E9CF.5060206@redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> Message-ID: <1422455863.2970.14.camel@willson.usersys.redhat.com> On Wed, 2015-01-28 at 14:53 +0100, Martin Babinsky wrote: > On 01/27/2015 05:21 PM, Martin Babinsky wrote: > > This series of patches is related to > > https://fedorahosted.org/freeipa/ticket/4795. > > > > The attached patches attempt to address some of the defects encountered > > during running covscan on freeipa-master branch. > > > > The complete list is here: > > http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html > > > > > > These patches do not fix defects 1 to 22 which occur in a code generated > > by asn1c, defect 23 which is related to > > https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead code). > > > > Each patch contains a detailed description of a defect and a proposed > > fix to address it. > > > > Martin^3 > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Attaching updated patches. > You are gratuitously removing empty lines in various patches. They are there to make the code flow more readable, please do not remove them. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Wed Jan 28 15:46:58 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 28 Jan 2015 16:46:58 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <1422455863.2970.14.camel@willson.usersys.redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> <1422455863.2970.14.camel@willson.usersys.redhat.com> Message-ID: <54C90472.5080007@redhat.com> On 01/28/2015 03:37 PM, Simo Sorce wrote: > On Wed, 2015-01-28 at 14:53 +0100, Martin Babinsky wrote: >> On 01/27/2015 05:21 PM, Martin Babinsky wrote: >>> This series of patches is related to >>> https://fedorahosted.org/freeipa/ticket/4795. >>> >>> The attached patches attempt to address some of the defects encountered >>> during running covscan on freeipa-master branch. >>> >>> The complete list is here: >>> http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html >>> >>> >>> These patches do not fix defects 1 to 22 which occur in a code generated >>> by asn1c, defect 23 which is related to >>> https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead code). >>> >>> Each patch contains a detailed description of a defect and a proposed >>> fix to address it. >>> >>> Martin^3 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Attaching updated patches. >> > > You are gratuitously removing empty lines in various patches. > They are there to make the code flow more readable, please do not remove > them. > > Simo. > Attaching updated patches. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0005-3-ipa-kdb-unexpected-error-code-in-ipa_kdb_audit_as_re.patch Type: text/x-patch Size: 3272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0006-2-always-get-PAC-for-client-principal-if-AS_REQ-is-tru.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0007-6-ipa-kdb-more-robust-handling-of-principal-addition-e.patch Type: text/x-patch Size: 4764 bytes Desc: not available URL: -------------- next part -------------- From 0ae11ce017b30752c917893b3ecfa137bd421f99 Mon Sep 17 00:00:00 2001 From: Martin Babinsky Date: Wed, 28 Jan 2015 16:26:14 +0100 Subject: [PATCH 4/7] OTP: failed search for the user of last token emits an error message This patch fixes the following defect reported by covscan: """ Error: CHECKED_RETURN (CWE-252): /daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c:119: check_return: Calling "slapi_search_internal_get_entry" without checking return value (as is done elsewhere 14 out of 16 times). /daemons/ipa-slapi-plugins/ipa-enrollment/ipa_enrollment.c:402: example_checked: Example 1: "slapi_search_internal_get_entry(sdn, NULL, &config_entry, ipaenrollment_plugin_id)" has its value checked in "(rc = slapi_search_internal_get_entry(sdn, NULL, &config_entry, ipaenrollment_plugin_id)) != 0". /daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c:207: example_assign: Example 2: Assigning: "ret" = return value from "slapi_search_internal_get_entry(sdn, NULL, &config_entry, getPluginID())". /daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c:212: example_checked: Example 2 (cont.): "ret" has its value checked in "ret". /daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c:651: example_assign: Example 3: Assigning: "search_result" = return value from "slapi_search_internal_get_entry(sdn, attrlist, e2, ipapwd_plugin_id)". /daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c:653: example_checked: Example 3 (cont.): "search_result" has its value checked in "search_result != 0". /daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:1035: example_assign: Example 4: Assigning: "ret" = return value from "slapi_search_internal_get_entry(tmp_dn, NULL, &pwdop->pwdata.target, ipapwd_plugin_id)". /daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:1039: example_checked: Example 4 (cont.): "ret" has its value checked in "ret != 0". /daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:817: example_assign: Example 5: Assigning: "ret" = return value from "slapi_search_internal_get_entry(tmp_dn, NULL, &e, getPluginID())". /daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:820: example_checked: Example 5 (cont.): "ret" has its value checked in "ret == 10". """ this patch is a part of a series related to https://fedorahosted.org/freeipa/ticket/4795 --- .../ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c index 233813745795344f31a7dcf1931cf74a09f1e552..a085a3a328a19e4c49bbc7ad6220564b59488e12 100644 --- a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c +++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c @@ -111,13 +111,19 @@ static bool is_pwd_enabled(const char *user_dn) Slapi_Entry *entry = NULL; uint32_t authtypes; Slapi_DN *sdn; + int search_result = 0; sdn = slapi_sdn_new_dn_byval(user_dn); if (sdn == NULL) return false; - slapi_search_internal_get_entry(sdn, attrs, &entry, - otp_config_plugin_id(otp_config)); + search_result = slapi_search_internal_get_entry(sdn, attrs, &entry, + otp_config_plugin_id(otp_config)); + if (search_result != LDAP_SUCCESS) { + LOG_TRACE("File '%s' line %d: Unable to access LDAP entry '%s'. " + "Perhaps it doesn't exist? Error code: %d\n", __FILE__, + __LINE__, slapi_sdn_get_dn(sdn), search_result); + } slapi_sdn_free(&sdn); if (entry == NULL) return false; -- 2.1.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0008-3-OTP-failed-search-for-the-user-of-last-token-emits-a.patch Type: text/x-patch Size: 3663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0009-2-ipa-pwd-extop-added-an-informational-comment-about-i.patch Type: text/x-patch Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0010-3-ipa-uuid-emit-a-message-when-unexpected-mod-type-is-.patch Type: text/x-patch Size: 2107 bytes Desc: not available URL: -------------- next part -------------- From 874f959b5872c749e73c3fa00d6a1d183955fc6c Mon Sep 17 00:00:00 2001 From: Martin Babinsky Date: Wed, 28 Jan 2015 16:28:50 +0100 Subject: [PATCH 7/7] OTP: emit a log message when LDAP entry for config record is not found This patch proposes a fix to the following defect found by covscan of FreeIPA master code: """ Error: CHECKED_RETURN (CWE-252): /daemons/ipa-slapi-plugins/libotp/otp_config.c:239: check_return: Calling "slapi_search_internal_get_entry" without checking return value (as is done elsewhere 14 out of 16 times). /daemons/ipa-slapi-plugins/ipa-enrollment/ipa_enrollment.c:402: example_checked: Example 1: "slapi_search_internal_get_entry(sdn, NULL, &config_entry, ipaenrollment_plugin_id)" has its value checked in "(rc = slapi_search_internal_get_entry(sdn, NULL, &config_entry, ipaenrollment_plugin_id)) != 0". /daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c:207: example_assign: Example 2: Assigning: "ret" = return value from "slapi_search_internal_get_entry(sdn, NULL, &config_entry, getPluginID())". /daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c:212: example_checked: Example 2 (cont.): "ret" has its value checked in "ret". /daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c:651: example_assign: Example 3: Assigning: "search_result" = return value from "slapi_search_internal_get_entry(sdn, attrlist, e2, ipapwd_plugin_id)". /daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c:653: example_checked: Example 3 (cont.): "search_result" has its value checked in "search_result != 0". /daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:1035: example_assign: Example 4: Assigning: "ret" = return value from "slapi_search_internal_get_entry(tmp_dn, NULL, &pwdop->pwdata.target, ipapwd_plugin_id)". /daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c:1039: example_checked: Example 4 (cont.): "ret" has its value checked in "ret != 0". /daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:817: example_assign: Example 5: Assigning: "ret" = return value from "slapi_search_internal_get_entry(tmp_dn, NULL, &e, getPluginID())". /daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:820: example_checked: Example 5 (cont.): "ret" has its value checked in "ret == 10". """ The patch is a part of series related to https://fedorahosted.org/freeipa/ticket/4795 --- daemons/ipa-slapi-plugins/libotp/Makefile.am | 4 +++- daemons/ipa-slapi-plugins/libotp/otp_config.c | 11 ++++++++++- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-slapi-plugins/libotp/Makefile.am b/daemons/ipa-slapi-plugins/libotp/Makefile.am index 4428f6bdc38a4e4ec224d1fa70744d8381f7e0b1..71b9c19f40379ba6c61858984f9de0253020e00d 100644 --- a/daemons/ipa-slapi-plugins/libotp/Makefile.am +++ b/daemons/ipa-slapi-plugins/libotp/Makefile.am @@ -1,5 +1,7 @@ MAINTAINERCLEANFILES = *~ Makefile.in -AM_CPPFLAGS = -I/usr/include/dirsrv +PLUGIN_COMMON_DIR = ../common +AM_CPPFLAGS = -I/usr/include/dirsrv \ + -I$(PLUGIN_COMMON_DIR) noinst_LTLIBRARIES = libhotp.la libotp.la libhotp_la_SOURCES = hotp.c hotp.h diff --git a/daemons/ipa-slapi-plugins/libotp/otp_config.c b/daemons/ipa-slapi-plugins/libotp/otp_config.c index ac2cfc72aa9f72af8eb5b5c565650325ac8bf714..685b2d9d259db3cc3d542cc5e86e184dee6d1737 100644 --- a/daemons/ipa-slapi-plugins/libotp/otp_config.c +++ b/daemons/ipa-slapi-plugins/libotp/otp_config.c @@ -38,6 +38,7 @@ * END COPYRIGHT BLOCK **/ #include "otp_config.h" +#include "util.h" #include #include @@ -214,6 +215,7 @@ struct otp_config *otp_config_init(Slapi_ComponentId *plugin_id) struct otp_config *cfg = NULL; void *node = NULL; + int search_result = 0; cfg = (typeof(cfg)) slapi_ch_calloc(1, sizeof(*cfg)); cfg->plugin_id = plugin_id; @@ -236,7 +238,14 @@ struct otp_config *otp_config_init(Slapi_ComponentId *plugin_id) cfg->records = rec; /* Load the specified entry. */ - slapi_search_internal_get_entry(rec->sdn, NULL, &entry, plugin_id); + search_result = slapi_search_internal_get_entry(rec->sdn, + NULL, &entry, plugin_id); + if (search_result != LDAP_SUCCESS) { + LOG_TRACE("File '%s' line %d: Unable to access LDAP entry " + "'%s'. Perhaps it doesn't exist? " + "Error code: %d\n", __FILE__, __LINE__, + slapi_sdn_get_dn(rec->sdn), search_result); + } update(cfg, rec->sdn, entry); slapi_entry_free(entry); } -- 2.1.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0011-3-OTP-emit-a-log-message-when-LDAP-entry-for-config-re.patch Type: text/x-patch Size: 4564 bytes Desc: not available URL: From simo at redhat.com Wed Jan 28 15:57:40 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Jan 2015 10:57:40 -0500 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C90472.5080007@redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> <1422455863.2970.14.camel@willson.usersys.redhat.com> <54C90472.5080007@redhat.com> Message-ID: <1422460660.2970.21.camel@willson.usersys.redhat.com> On Wed, 2015-01-28 at 16:46 +0100, Martin Babinsky wrote: > On 01/28/2015 03:37 PM, Simo Sorce wrote: > > On Wed, 2015-01-28 at 14:53 +0100, Martin Babinsky wrote: > >> On 01/27/2015 05:21 PM, Martin Babinsky wrote: > >>> This series of patches is related to > >>> https://fedorahosted.org/freeipa/ticket/4795. > >>> > >>> The attached patches attempt to address some of the defects encountered > >>> during running covscan on freeipa-master branch. > >>> > >>> The complete list is here: > >>> http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html > >>> > >>> > >>> These patches do not fix defects 1 to 22 which occur in a code generated > >>> by asn1c, defect 23 which is related to > >>> https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead code). > >>> > >>> Each patch contains a detailed description of a defect and a proposed > >>> fix to address it. > >>> > >>> Martin^3 > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >>> > >> > >> Attaching updated patches. > >> > > > > You are gratuitously removing empty lines in various patches. > > They are there to make the code flow more readable, please do not remove > > them. > > > > Simo. > > > Attaching updated patches. > LGTM. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Jan 28 17:30:23 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 28 Jan 2015 19:30:23 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54C90472.5080007@redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> <1422455863.2970.14.camel@willson.usersys.redhat.com> <54C90472.5080007@redhat.com> Message-ID: <20150128173023.GJ6592@redhat.com> On Wed, 28 Jan 2015, Martin Babinsky wrote: > On 01/28/2015 03:37 PM, Simo Sorce wrote: >> On Wed, 2015-01-28 at 14:53 +0100, Martin Babinsky wrote: >>> On 01/27/2015 05:21 PM, Martin Babinsky wrote: >>>> This series of patches is related to >>>> https://fedorahosted.org/freeipa/ticket/4795. >>>> >>>> The attached patches attempt to address some of the defects encountered >>>> during running covscan on freeipa-master branch. >>>> >>>> The complete list is here: >>>> http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html >>>> >>>> >>>> These patches do not fix defects 1 to 22 which occur in a code generated >>>> by asn1c, defect 23 which is related to >>>> https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead code). >>>> >>>> Each patch contains a detailed description of a defect and a proposed >>>> fix to address it. >>>> >>>> Martin^3 >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>> Attaching updated patches. >>> >> >> You are gratuitously removing empty lines in various patches. >> They are there to make the code flow more readable, please do not remove >> them. >> >> Simo. >> > Attaching updated patches. > Patches look OK for me now. I need to test them in a clean install so please don't commit them yet. -- / Alexander Bokovoy From npmccallum at redhat.com Wed Jan 28 22:58:57 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 28 Jan 2015 17:58:57 -0500 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <54B3DFDE.9090608@redhat.com> References: <1416499988.2902.11.camel@redhat.com> <1420511219.3049.11.camel@redhat.com> <54B3DFDE.9090608@redhat.com> Message-ID: <1422485937.26683.121.camel@redhat.com> Attached is a new version which fixes most of the issues found. Comments below. On Mon, 2015-01-12 at 15:53 +0100, Petr Viktorin wrote: > On 01/06/2015 03:26 AM, Nathaniel McCallum wrote: > > On Thu, 2014-11-20 at 11:13 -0500, Nathaniel McCallum wrote: > >> >This tests the general workflow for OTP including most possible > >> >token combinations. This includes 5872 tests. Further optimization > >> >is possible to reduce the number of duplicate tests run. > >> > > >> >Things not yet tested: > >> >* ipa-kdb > >> >* ipa-otpd > >> >* otptoken-sync > >> >* RADIUS proxy > >> >* token self-management > >> >* type specific attributes > > Attached is the latest iteration of the OTP test work. This now includes > > all major cases except token self-management and RADIUS proxy (which > > will come in its own patch). Token self-management is held up by the > > fact that I can't get alternate ccaches to work with the API. I have > > tried kinit-ing to an independent ccache and exporting KRB5CCNAME, but > > this doesn't work for some reason I can't figure out. > > > > I ended up creating my own fixture mechanism. I'm not in love with it, > > but it is simple and at least gets the scoping correct. It also > > generates individual tests for each parameterized state, so the output > > is both correct and obvious. > > > > I also implemented OTP myself. This isn't much code, but pyotp has a > > major bug and is dead upstream. I'd like to migrate to > > python-cryptography when it lands as a dependency of FreeIPA. But due to > > timing issues, we can't land it now. This will be a small patch in the > > future. > > > > Even with the caveats above, I feel like the test coverage provided by > > this test is worth review/merge. As a rough estimate, I think this is > > about 70% code coverage. Of the remaining coverage, I see: > > * RADIUS proxy - 10% > > * token self-management - 10% > > * misc testable - 5% > > * misc untestable - 5% > > > > All tests in this patch succeed on 4.1.2. > > It doesn't work for me on the 4.2 branch, see the attached errors. Not > sure what I'm doing wrong. This doesn't work at all on the 4.2 branch. This is because nose, like the upstream test harnesses, executes yielded tests as they are yielded. However, pytest does not. It collects all the yielded tests into a single bundle and then runs them after the state of their fixtures is already destroyed. This complete breaks the fixturize() decorator. Why are we using pytest again? It may offer nifty features, but it sucks at integration testing. > See some comments andnitpicks inline. > > > > > > freeipa-npmccallum-0081.1-Add-initial-tests-for-OTP.patch > > > > > > From c7b01ea4415db3847110ffe51a9bb5193072d1a8 Mon Sep 17 00:00:00 2001 > > From: Nathaniel McCallum > > Date: Thu, 20 Nov 2014 11:02:00 -0500 > > Subject: [PATCH] Add initial tests for OTP > > > > This tests the general workflow for OTP including most possible > > token combinations. It includes tests for all token options, > > enablement scenarios and token synchronization. > > --- > > ipatests/test_xmlrpc/test_otptoken_plugin.py | 536 +++++++++++++++++++++++++++ > > 1 file changed, 536 insertions(+) > > create mode 100644 ipatests/test_xmlrpc/test_otptoken_plugin.py > > > > diff --git a/ipatests/test_xmlrpc/test_otptoken_plugin.py b/ipatests/test_xmlrpc/test_otptoken_plugin.py > > new file mode 100644 > > index 0000000000000000000000000000000000000000..7a27d720cb9789c648e45aece1ebd0b6b751e3d8 > > --- /dev/null > > +++ b/ipatests/test_xmlrpc/test_otptoken_plugin.py > > @@ -0,0 +1,536 @@ > > +# Authors: > > +# Nathaniel McCallum > > +# > > +# Copyright (C) 2014 Red Hat > > +# see file 'COPYING' for use and warranty information > > +# > > +# This program is free software; you can redistribute it and/or modify > > +# it under the terms of the GNU General Public License as published by > > +# the Free Software Foundation, either version 3 of the License, or > > +# (at your option) any later version. > > +# > > +# This program is distributed in the hope that it will be useful, > > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > +# GNU General Public License for more details. > > +# > > +# You should have received a copy of the GNU General Public License > > +# along with this program. If not, see. > > + > > +""" > > +Test the `ipalib/plugins/otptoken.py` module. > > +""" > > + > > +import abc > > +import base64 > > +import hashlib > > +import hmac > > +import os > > +import unittest > > +import urlparse > > +import uuid > > +import random > > +import string > > +import struct > > +import subprocess > > +import time > > +import types > > + > > +from datetime import datetime, timedelta > > + > > +from ipalib import api > > +from xmlrpc_test import XMLRPC_test, Declarative > > ^ unused > > > +from ipatests.util import assert_deepequal, raises > > I recommend nose.tools.assert_raises rather than ipatests.util.raises -- > it's easier to debug if an unexpected error occurs. Fixed. > > +from ipapython.version import API_VERSION > > +from ipapython.dn import DN > > +import ldap > > + > > + > > +class Fixture(object): > > + __metaclass__ = abc.ABCMeta > > + > > + @property > > + def context(self): > > + try: > > + return self.__fixtures > > + except AttributeError: > > + return tuple() > > + > > + @context.setter > > + def context(self, value): > > + self.__fixtures = value > > + > > + @abc.abstractmethod > > + def __enter__(self): > > + raise NotImplementedError() > > + > > + @abc.abstractmethod > > + def __exit__(self, type, value, traceback): > > + raise NotImplementedError() > > + > > + def __repr__(self): > > + return '%s()' % self.__class__.__name__ > > It seems that this class could be written as: > > class Fixture(object): > context = () > > and all the rest except __repr__ is unnecessary. > For documenting what subclasses should add/override, a mention in a > docstring might be more helpful than ABC stubs. Fixed. > > +def fixturize(*args): > > + def outer(func): > > + def inner(s, fixtures=args, ctx=()): > > + try: > > + fixture = fixtures[0] > > + except IndexError: > > + yield (lambda *a: func(s, *a),) + ctx > > + else: > > + for f in fixture if type(fixture) is tuple else (fixture,): > > + if isinstance(f, Fixture): > > + f.context = ctx > > + > > + if hasattr(f, "__enter__"): > > + with f as tmp: > > + for test in inner(s, fixtures[1:], ctx + (tmp,)): > > + yield test > > + else: > > + for test in inner(s, fixtures[1:], ctx + (f,)): > > + yield test > > + > > + inner.__name__ = func.__name__ > > + return inner > > + return outer > > Well, that works. A docstring would be really nice though. Fixed, with extensive documentation. > > +def cmd(cmd, *args, **kwargs): > > + return api.Command[cmd](*args, version=API_VERSION, **kwargs) > > This requires rpcclient to be connected. See the XMLRPC_test class for > the necessary setup. Fixed. > > +class AuthenticationError(Exception): > > + pass > > + > > + > > +class Login(object): > > + def __repr__(self): > > + return '%s()' % self.__class__.__name__ > > + > > + def __init__(self): > > + self.__fails = 0 > > + > > + def __call__(self, uid, pwd): > > + try: > > + self.login(uid, pwd) > > + self.__fails = 0 > > + except: > > + self.__fails += 1 > > + if self.__fails > 2: > > + cmd('user_unlock', uid) > > + self.__fails = 0 > > + raise > > I'm not sure what you're doing here. Documented. I'm keeping the account from getting locked when we test authentication failures. > > + > > + def login(self, uid, pwd): > > + raise NotImplementedError() > > + > > + > > +class LDAPLogin(Login): > > + def __init__(self): > > + super(LDAPLogin, self).__init__() > > + > > + self.__conn = ldap.initialize('ldap://' + api.env.host) > > + > > + def login(self, uid, pwd): > > + dn = DN(('uid', uid), api.env.container_user, api.env.basedn) > > + try: > > + self.__conn.simple_bind_s(str(dn), pwd) > > + except ldap.INVALID_CREDENTIALS as e: > > + raise AuthenticationError(e.message) > > + > > + > > +class Krb5Login(Login): > > + def __init__(self): > > + super(Krb5Login, self).__init__() > > + > > + self.__fast = subprocess.Popen( > > + ['/usr/bin/klist'], > > + stdout=subprocess.PIPE > > + ).communicate()[0].split('\n')[0].split(': ')[1] > > + > > + def kinit(self, uid, pwd, newpwd=None, ccache="FILE:/dev/null"): > > + data = pwd + '\n' > > + if newpwd is not None: > > + data += newpwd + '\n' + newpwd + '\n' > > + > > + p = subprocess.Popen( > > + ['/usr/bin/kinit', > > + '-T', self.__fast, > > + '-c', ccache, > > + uid + '@' + api.env.realm], > > + stdin=subprocess.PIPE, > > + stdout=subprocess.PIPE, > > + stderr=subprocess.PIPE > > + ) > > + out, err = p.communicate(data) > > Can you use ipautil.run here? Fixed. > > + if p.returncode != 0: > > + raise AuthenticationError(out, err) > > + > > + def login(self, uid, pwd): > > + self.kinit(uid, pwd) > > + > > + > > +class User(Fixture): > > + def __init__(self, **kwargs): > > + self.username = u''.join(random.sample(string.lowercase, 20)) > > + self.password = u''.join(random.sample(string.letters, 20)) > > Could you prefix the test user with `test`, so it's identifiable when it > doesn't get deleted for some reason? Fixed. > > + self.__kwargs = kwargs > > + > > + def __enter__(self): > > + cmd('user_add', self.username, > > + userpassword=self.password, > > + givenname=self.username[:len(self.username) / 2], > > + sn=self.username[len(self.username) / 2:], > > + **self.__kwargs) > > + > > + # Change password > > + Krb5Login().kinit(self.username, self.password, self.password) > > + return self > > + > > + def __exit__(self, type, value, traceback): > > + cmd('user_del', self.username) > > + > > + > > +class Enablement(Fixture): > > + def __repr__(self): > > + return "Enablement(%s)" % ("user" if self.user else "global") > > + > > + def __set_authtype(self, authtype): > > + if self.user: > > + for fixture in self.context: > > + if isinstance(fixture, User): > > + cmd('user_mod', fixture.username, ipauserauthtype=authtype) > > + return > > + assert False > > + else: > > + cmd('config_mod', ipauserauthtype=authtype) > > + time.sleep(60) # Work around cfg update hack in ipa-kdb > > The config_mod might raise EmptyModList which you should ignore. Fixed. > > + > > + def __init__(self, user=True): > > + self.user = user > > + > > + def __enter__(self): > > + self.__set_authtype((u'otp',)) > > + return self > > + > > + def __exit__(self, type, value, traceback): > > + self.__set_authtype(()) > > + > > + > > +class Token(dict, Fixture): > > Why is Token a dict, as opposed to having a "params" dict? Because a token is just a collection of parameters. See how we define the tokens in the fixtures. > > + @property > > + def type(self): > > + return self[u'type'].upper() > > + > > + @property > > + def active(self): > > + if self.get(u'ipatokendisabled', False): > > + return False > > + > > + nb = self.get(u'ipatokennotbefore', None) > > + if nb is not None and datetime.now() < nb: > > + return False > > + > > + na = self.get(u'ipatokennotafter', None) > > + if na is not None and datetime.now() > na: > > + return False > > + > > + return True > > + > > + def __repr__(self): > > + prefixes = ['ipatoken' + x for x in ('totp', 'hotp', 'otp', '')] > > + > > + args = {} > > + for k, v in self.items(): > > + for prefix in prefixes: > > + if k.startswith(prefix): > > + k = k[len(prefix):] > > + break > > + > > + if k in ('key', 'uniqueid', 'owner'): > > + continue > > + > > + if isinstance(v, datetime): > > + v = v.strftime("%Y%m%d%H%M%SZ") > > + > > + args[k] = v > > + > > + return "%s(%s:%d|%d%s%s%r)" % ( > > + args.pop('type').upper(), > > + args.pop('algorithm'), > > + args.pop('digits'), > > + args.pop('counter', args.pop('timestep', 0)), > > + ':' if self.type == 'TOTP' else '', > > + str(args.pop('clockoffset', '')), > > + args > > + ) > > + > > + def otp(self, at=0): > > + # I first attempted implementing this with pyotp. However, pyotp has > > + # a critical bug which appeared in testing. I fixed this bug and > > + # submitted it upstream:https://github.com/nathforge/pyotp/pull/9 > > + # > > + # However, upstream pyotp appears to be dead. For now, I have > > + # implemented the algorithm myself. In the future, it would be nice > > + # to use python-cryptography here. > > + > > + # If the token is time-based, calculate the counter from the time. > > + if self.type == u"TOTP": > > + intrvl = self[u'ipatokentotptimestep'] > > + offset = self.get(u'ipatokentotpclockoffset', 0) > > + at = (time.time() + offset + intrvl * at) / intrvl > > + > > + # Otherwise, just account for the specified counter offset. > > + elif self.type == u"HOTP": > > + if at < 0: # Skip invalid test offsets. > > + raise unittest.SkipTest() > > + at += self.get(u'ipatokenhotpcounter', 0) > > + > > + # Create the HMAC of the current counter > > + countr = struct.pack("!Q", at) > > + hasher = getattr(hashlib, self[u'ipatokenotpalgorithm']) > > hashlib.new(self[u'ipatokenotpalgorithm']) should work It doesn't. HMAC needs the function itself as input, not a new instance. > > + digest = hmac.HMAC(self[u'ipatokenotpkey'], countr, hasher).digest() > > + > > + # Get the number of digits > > + digits = self[u'ipatokenotpdigits'] > > + > > + # Truncate the digest > > + offset = ord(digest[-1]) & 0xf > > + binary = (ord(digest[offset+0]) & 0x7f) << 0x18 > > + binary |= (ord(digest[offset+1]) & 0xff) << 0x10 > > + binary |= (ord(digest[offset+2]) & 0xff) << 0x08 > > + binary |= (ord(digest[offset+3]) & 0xff) << 0x00 > > + binary = binary % (10 ** digits) > > + > > + return "0" * (digits - len(str(binary))) + str(binary) > > str(binary).rjust(digits, '0') Fixed. > > + def __init__(self, **kwargs): > > + super(Token, self).__init__(**kwargs) > > + > > + # Add in default values. > > + self.setdefault(u'ipatokenuniqueid', unicode(uuid.uuid4())) > > + self.setdefault(u'ipatokenotpkey', os.urandom(20)) > > + for i in range(len(api.Object['otptoken'].params)): > > + param = api.Object['otptoken'].params[i] > > + if param.default is not None and param.name: > > + self.setdefault(param.name, param.default) > > + > > + # Remove defaults that don't apply. > > + types = { > > + "HOTP": (u'ipatokenhotpcounter',), > > + "TOTP": (u'ipatokentotptimestep', u'ipatokentotpclockoffset'), > > + } > > + for k, names in types.items(): > > + if k != self.type: > > + for name in names: > > + del self[name] > > + > > + def __enter__(self): > > + kwargs = {} > > + kwargs.update(self) > > kwargs = dict(self) Fixed. > > + # Get the owner from the user fixture. > > + for fixture in self.context: > > + if isinstance(fixture, User): > > + kwargs[u'ipatokenowner'] = fixture.username > > + break > > + > > + # Add the token. > > + result = cmd('otptoken_add', **kwargs) > > + > > + try: > > + # Remove the URI and validate the rest of the return value. > > + uri = result.get('result', {}).pop('uri', None) > > + expected = {} > > + for k, v in kwargs.items(): > > + if k == 'setattr': > > + continue > > + > > + if isinstance(v, bool): > > + expected[k] = (unicode(v).upper(),) > > + elif isinstance(v, int): > > + expected[k] = (unicode(v),) > > + else: > > + expected[k] = (v,) > > + expected[u'type'] = expected[u'type'][0].upper() > > + expected[u'dn'] = u'ipatokenuniqueid=%s,cn=otp,dc=example,dc=com' > > + expected[u'dn'] %= self[u'ipatokenuniqueid'] > > That only works for dc=example,dc=com; use: > DN(('ipatokenuniqueid', self[u'ipatokenuniqueid']), 'cn=otp', > api.env.basedn) Fixed. > > + assert_deepequal({ > > + u'summary': u'Added OTP token "%s"' % self[u'ipatokenuniqueid'], > > + u'result': expected, > > + u'value': self[u'ipatokenuniqueid'], > > + }, result) > > + > > + # Validate the URI. > > + split = urlparse.urlsplit(uri) > > + assert split.scheme == u'otpauth' > > + assert split.netloc.upper() == self.type > > + assert split.path == '/%s@%s:%s' % ( > > + kwargs[u'ipatokenowner'], > > + api.env.realm, > > + self[u'ipatokenuniqueid'] > > + ) > > + > > + # Validate the query. > > + types = { > > + "HOTP": {u'counter': self.get(u'ipatokenhotpcounter')}, > > + "TOTP": {u'period': self.get(u'ipatokentotptimestep')}, > > + } > > + query = { > > + u'algorithm': self.get(u'ipatokenotpalgorithm'), > > + u'issuer': u'%s@%s' % (kwargs[u'ipatokenowner'], api.env.realm), > > + u'digits': self.get(u'ipatokenotpdigits'), > > + u'secret': base64.b32encode(self[u'ipatokenotpkey']), > > + } > > + query.update(types.get(self.type, {})) > > + assert_deepequal( > > + {k: (unicode(v),) for k, v in query.items()}, > > + urlparse.parse_qs(split.query) > > + ) > > + except: > > + cmd('otptoken_del', self[u'ipatokenuniqueid']) > > + raise > > + > > + return self > > + > > + def __exit__(self, type, value, traceback): > > + cmd('otptoken_del', self[u'ipatokenuniqueid']) > > + > > + > > +def auth(success, login, user, token, pwd=None, at=0): > > + if pwd is None: > > + pwd = user.password > > + > > + if isinstance(at, basestring): > > + code = at > > + > > + else: > > + code = token.otp(at) if token else '123456' > > + if code is None: # Skip invalid test offsets. > > + raise unittest.SkipTest() > > + > > + if success: > > + login(user.username, pwd + code) > > + else: > > + raises(AuthenticationError, login, user.username, pwd + code) > > + > > + > > +class TestEnablement: > > Classes should derive from object. (Same for TestTokens, TestSync) Fixed. > > + # This describes the success conditions for authentication. > > + # 1. If user-auth-type does not include otp: password-only. > > + # 2. Otherwise, if no token exists: password-only. > > + # 3. Otherwise: password AND code. > > + # > > + # All states not accounted for here MUST fail. > > + # > > + # Format: (enabled, token created, pwd given, token given): success > > + EXPECTATIONS = { > > + (False, False, True, False): True, # Condition 1 > > + (False, True, True, False): True, # Condition 1 > > + (True, False, True, False): True, # Condition 2 > > + (True, True, True, True): True, # Condition 3 > > + } > > + > > + @fixturize(Krb5Login(), User(), ( > > + None, > > + Enablement(True), > > + Enablement(False) > > + ), ( > > + None, > > + Token() > > + ), ( > > + (True, None, ''), # Password-only > > + (True, None, 0), # Both > > + (False, '', 1), # Code-only > > + (False, '', ''), # Neither > > + (False, 'xxx', 2), # Bad password > > + (False, None, '123456'), # Bad code > > + ) > > + ) > > + def test(self, login, user, enablement, token, params): > > + success, pwd, at = params > > + > > + if success: > > + success = self.EXPECTATIONS.get(( > > + enablement is not None, > > + token is not None, > > + pwd is None, > > + isinstance(at, int) > > + ), False) > > + > > + auth(success, login, user, token, pwd, at) > > + > > + > > +class TestTokens: > > + TODAY = datetime.now().replace(microsecond=0) > > + TOMORROW = TODAY + timedelta(1) > > + YESTERDAY = TODAY - timedelta(1) > > + > > + @fixturize( > > + Krb5Login(), > > + User(ipauserauthtype=(u'otp')), ( > > + Token(type=u'hotp'), > > + Token(type=u'HOTP'), > > + Token(type=u'HOTP', ipatokenhotpcounter=1000), > > + > > + Token(type=u'totp'), > > + Token(type=u'TOTP'), > > + Token(type=u'TOTP', ipatokentotptimestep=60), > > + Token(type=u'TOTP', ipatokentotpclockoffset=30000), > > + > > + Token(ipatokenotpalgorithm=u'sha1'), > > + Token(ipatokenotpalgorithm=u'sha256'), > > + Token(ipatokenotpalgorithm=u'sha384'), > > + Token(ipatokenotpalgorithm=u'sha512'), > > + > > + Token(ipatokenotpdigits=6), > > + Token(ipatokenotpdigits=8), > > + > > + Token(ipatokendisabled=False), > > + Token(ipatokennotbefore=YESTERDAY), > > + Token(ipatokennotafter=TOMORROW), > > + > > + Token(ipatokendisabled=True), > > + Token(ipatokennotbefore=TOMORROW), > > + Token(ipatokennotafter=YESTERDAY), > > + ), ( > > + (False, -1000), # Check distant past OTP > > + (True, -2), # Check past OTP > > + (True, 0), # Check current OTP > > + (False, 0), # Check duplicate OTP > > + (True, 1), # Check next OTP > > + (True, 3), # Check future OTP > > + (False, 1000), # Check distant future OTP > > + ) > > + ) > > + def test(self, login, user, token, params): > > + auth(params[0] and token.active, login, user, token, None, params[1]) > > + > > + > > +class TestSync: > > + """NOTE: this test requires ca.crt in your confdir so that the client can > > +validate the server's certificate.""" > > + > > + @fixturize(Krb5Login(), User(ipauserauthtype=(u'otp')), ( > > + Token(type=u'hotp'), > > + Token(type=u'totp') > > + ), ( > > + (False, True, 0), # Normal token operation > > + (False, False, 7), # Skip-ahead failure > > + (True, True, 7), # Skip-ahead success after sync > > + ) > > + ) > > + def test(self, login, user, token, params): > > + sync, success, at = params > > + > > + if sync: > > + cmd('otptoken_sync', > > + user=user.username, > > + password=user.password, > > + first_code=unicode(token.otp(at)), > > + second_code=unicode(token.otp(at + 1))) > > + at += 2 > > + > > + auth(success, login, user, token, None, at) > > -- 2.1.0 > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0081.2-Add-initial-tests-for-OTP.patch Type: text/x-patch Size: 21022 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 29 07:48:57 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 Jan 2015 08:48:57 +0100 Subject: [Freeipa-devel] [PATCH 0081] Add initial tests for OTP In-Reply-To: <1422485937.26683.121.camel@redhat.com> References: <1416499988.2902.11.camel@redhat.com> <1420511219.3049.11.camel@redhat.com> <54B3DFDE.9090608@redhat.com> <1422485937.26683.121.camel@redhat.com> Message-ID: <54C9E5E9.60003@redhat.com> On 01/28/2015 11:58 PM, Nathaniel McCallum wrote: > Attached is a new version which fixes most of the issues found. > > Comments below. Thanks! > > On Mon, 2015-01-12 at 15:53 +0100, Petr Viktorin wrote: >> On 01/06/2015 03:26 AM, Nathaniel McCallum wrote: >>> On Thu, 2014-11-20 at 11:13 -0500, Nathaniel McCallum wrote: >>>>> This tests the general workflow for OTP including most possible >>>>> token combinations. This includes 5872 tests. Further optimization >>>>> is possible to reduce the number of duplicate tests run. >>>>> >>>>> Things not yet tested: >>>>> * ipa-kdb >>>>> * ipa-otpd >>>>> * otptoken-sync >>>>> * RADIUS proxy >>>>> * token self-management >>>>> * type specific attributes >>> Attached is the latest iteration of the OTP test work. This now includes >>> all major cases except token self-management and RADIUS proxy (which >>> will come in its own patch). Token self-management is held up by the >>> fact that I can't get alternate ccaches to work with the API. I have >>> tried kinit-ing to an independent ccache and exporting KRB5CCNAME, but >>> this doesn't work for some reason I can't figure out. >>> >>> I ended up creating my own fixture mechanism. I'm not in love with it, >>> but it is simple and at least gets the scoping correct. It also >>> generates individual tests for each parameterized state, so the output >>> is both correct and obvious. >>> >>> I also implemented OTP myself. This isn't much code, but pyotp has a >>> major bug and is dead upstream. I'd like to migrate to >>> python-cryptography when it lands as a dependency of FreeIPA. But due to >>> timing issues, we can't land it now. This will be a small patch in the >>> future. >>> >>> Even with the caveats above, I feel like the test coverage provided by >>> this test is worth review/merge. As a rough estimate, I think this is >>> about 70% code coverage. Of the remaining coverage, I see: >>> * RADIUS proxy - 10% >>> * token self-management - 10% >>> * misc testable - 5% >>> * misc untestable - 5% >>> >>> All tests in this patch succeed on 4.1.2. >> >> It doesn't work for me on the 4.2 branch, see the attached errors. Not >> sure what I'm doing wrong. > > This doesn't work at all on the 4.2 branch. This is because nose, like > the upstream test harnesses, executes yielded tests as they are yielded. > However, pytest does not. It collects all the yielded tests into a > single bundle and then runs them after the state of their fixtures is > already destroyed. This complete breaks the fixturize() decorator. > > Why are we using pytest again? It may offer nifty features, but it sucks > at integration testing. While right now, I am mostly concerned about OTP testing in FreeIPA 4.1.* as this is the release going in downstream releases, the next step after successfully reviewing&testing of ipa-4-1 incarnation of the packages will be update in master branch, i.e. making them work with our favorite testing framework - pytest :-). Martin From mbabinsk at redhat.com Thu Jan 29 11:57:17 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 29 Jan 2015 12:57:17 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150128173023.GJ6592@redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> <1422455863.2970.14.camel@willson.usersys.redhat.com> <54C90472.5080007@redhat.com> <20150128173023.GJ6592@redhat.com> Message-ID: <54CA201D.6010009@redhat.com> On 01/28/2015 06:30 PM, Alexander Bokovoy wrote: > On Wed, 28 Jan 2015, Martin Babinsky wrote: >> On 01/28/2015 03:37 PM, Simo Sorce wrote: >>> On Wed, 2015-01-28 at 14:53 +0100, Martin Babinsky wrote: >>>> On 01/27/2015 05:21 PM, Martin Babinsky wrote: >>>>> This series of patches is related to >>>>> https://fedorahosted.org/freeipa/ticket/4795. >>>>> >>>>> The attached patches attempt to address some of the defects >>>>> encountered >>>>> during running covscan on freeipa-master branch. >>>>> >>>>> The complete list is here: >>>>> http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html >>>>> >>>>> >>>>> >>>>> These patches do not fix defects 1 to 22 which occur in a code >>>>> generated >>>>> by asn1c, defect 23 which is related to >>>>> https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead >>>>> code). >>>>> >>>>> Each patch contains a detailed description of a defect and a proposed >>>>> fix to address it. >>>>> >>>>> Martin^3 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> Attaching updated patches. >>>> >>> >>> You are gratuitously removing empty lines in various patches. >>> They are there to make the code flow more readable, please do not remove >>> them. >>> >>> Simo. >>> >> Attaching updated patches. >> > Patches look OK for me now. I need to test them in a clean install so > please don't commit them yet. > Some vim backup files crept into the previous attachment. Re-sending the correct patchset. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0005-3-ipa-kdb-unexpected-error-code-in-ipa_kdb_audit_as_re.patch Type: text/x-patch Size: 3272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0006-2-always-get-PAC-for-client-principal-if-AS_REQ-is-tru.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0007-6-ipa-kdb-more-robust-handling-of-principal-addition-e.patch Type: text/x-patch Size: 4764 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0008-3-OTP-failed-search-for-the-user-of-last-token-emits-a.patch Type: text/x-patch Size: 3663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0009-2-ipa-pwd-extop-added-an-informational-comment-about-i.patch Type: text/x-patch Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0010-3-ipa-uuid-emit-a-message-when-unexpected-mod-type-is-.patch Type: text/x-patch Size: 2107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0011-3-OTP-emit-a-log-message-when-LDAP-entry-for-config-re.patch Type: text/x-patch Size: 4564 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jan 29 12:42:11 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 29 Jan 2015 14:42:11 +0200 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54CA201D.6010009@redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> <1422455863.2970.14.camel@willson.usersys.redhat.com> <54C90472.5080007@redhat.com> <20150128173023.GJ6592@redhat.com> <54CA201D.6010009@redhat.com> Message-ID: <20150129124211.GL6592@redhat.com> On Thu, 29 Jan 2015, Martin Babinsky wrote: > On 01/28/2015 06:30 PM, Alexander Bokovoy wrote: >> On Wed, 28 Jan 2015, Martin Babinsky wrote: >>> On 01/28/2015 03:37 PM, Simo Sorce wrote: >>>> On Wed, 2015-01-28 at 14:53 +0100, Martin Babinsky wrote: >>>>> On 01/27/2015 05:21 PM, Martin Babinsky wrote: >>>>>> This series of patches is related to >>>>>> https://fedorahosted.org/freeipa/ticket/4795. >>>>>> >>>>>> The attached patches attempt to address some of the defects >>>>>> encountered >>>>>> during running covscan on freeipa-master branch. >>>>>> >>>>>> The complete list is here: >>>>>> http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html >>>>>> >>>>>> >>>>>> >>>>>> These patches do not fix defects 1 to 22 which occur in a code >>>>>> generated >>>>>> by asn1c, defect 23 which is related to >>>>>> https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead >>>>>> code). >>>>>> >>>>>> Each patch contains a detailed description of a defect and a proposed >>>>>> fix to address it. >>>>>> >>>>>> Martin^3 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> Attaching updated patches. >>>>> >>>> >>>> You are gratuitously removing empty lines in various patches. >>>> They are there to make the code flow more readable, please do not remove >>>> them. >>>> >>>> Simo. >>>> >>> Attaching updated patches. >>> >> Patches look OK for me now. I need to test them in a clean install so >> please don't commit them yet. >> > > Some vim backup files crept into the previous attachment. Re-sending the > correct patchset. ACK. -- / Alexander Bokovoy From thozza at redhat.com Thu Jan 29 14:42:49 2015 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 29 Jan 2015 15:42:49 +0100 Subject: [Freeipa-devel] [PATCH 0319] Fix crash caused by race condition during resolver cache flushing In-Reply-To: <54B51AA7.7070801@redhat.com> References: <54B51AA7.7070801@redhat.com> Message-ID: <54CA46E9.4070605@redhat.com> On 01/13/2015 02:16 PM, Petr Spacek wrote: > Hello, > > This patch should be applied to v2 branch. > > Fix crash caused by race condition during resolver cache flushing. > > dns_view_flushcache() call has to be always done in single-thread mode. > Locking around the call was missing in forwarder reconfiguration and > zone deletion which could cause crash. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/142 ACK. I was not able to reproduce the issue with this patch included in bind-dyndb-ldap package using reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=1126841#c14 Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From redhatrises at gmail.com Thu Jan 29 15:04:29 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 29 Jan 2015 08:04:29 -0700 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise In-Reply-To: <54B6A602.9060101@redhat.com> References: <54B69B41.9070404@redhat.com> <54B6A097.9020601@redhat.com> <54B6A1F4.8000807@redhat.com> <54B6A602.9060101@redhat.com> Message-ID: Hello, Here is a patch for https://fedorahosted.org/freeipa/ticket/4029 I added test cases for valid and invalid advice. Thanks, Gabe On Wed, Jan 14, 2015 at 10:23 AM, Tomas Babej wrote: > > On 01/14/2015 06:13 PM, Gabe Alford wrote: > > On Wed, Jan 14, 2015 at 10:05 AM, Tomas Babej wrote: > >> >> On 01/14/2015 06:00 PM, Tomas Babej wrote: >> >> >> On 01/14/2015 05:37 PM, Tomas Babej wrote: >> >> >> On 01/14/2015 02:55 PM, Gabe Alford wrote: >> >> Hello, >> >> In looking into https://fedorahosted.org/freeipa/ticket/4029 I >> am wondering if there should be separate ipa-advise test, Yes/No? Could be >> handy in the future to test more ipa-advise output? Or should this test be >> added to the test_legacy_clients.py? >> >> Thanks, >> >> Gabe >> >> On Tue, Dec 2, 2014 at 9:21 PM, Gabe Alford >> wrote: >> >>> Hello, >>> >>> I was going to try my hand at attempting a patch for ipa-tests. However >>> in wanting to test my patch, I am not sure how to run ipa-tests to check if >>> it works or not. Documentation is not really clear on what needs to be done >>> to start a test and run a test. This is for >>> https://fedorahosted.org/freeipa/ticket/4029 >>> >>> I have attached the patch that I have yet to really test with ipa-test. >>> Any help on how to test the patch running ipa-tests would be great. Of >>> course, if one of the reviewers looks at the patch and looks good, then I >>> would be happy with that as well. >>> >>> Thanks, >>> >>> Gabe >>> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> Hello, >> >> TL;DR: feel free to create a separate ipa-advise test file. Test >> requested in this ticket really does not belong to the legacy clients >> feature test. >> >> As for the any new tests that might come: I think tests for ipa-advise >> that are specific to that particular feature should be tested with that >> feature, more so, if they contain parts that are supposed to work >> copy-pasted. If a tests, however, tests a general behaviour of ipa-advise, >> it should live in the ipa-advise namespace, hence separate test file. >> >> HTH, >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> >> The attached patch looks fine, although, please also test for a >> non-zero return code number. >> >> >> Upon hitting send I noticed you did not include raiseonerr=False into the >> run_command call. You need to do that, otherwise a exception will be >> raised, since ipa-advise exited with non-zero return code. >> > Thanks Tomas. > > Which do you prefer: a test_advise.py or an update to the existing > patch? > > > A new test file, as I pointed out in the second email :) sorry for > splitting. > > However, it would be the best if you could spin up a positive test as well > (maybe listing out available advices), not just this negative one, to > justify the overhead reinstalling IPA for testing this feature. > > > >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0039-ipatests-Add-tests-for-valid-and-invalid-ipa-advise.patch Type: application/octet-stream Size: 5893 bytes Desc: not available URL: From redhatrises at gmail.com Thu Jan 29 16:10:34 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 29 Jan 2015 09:10:34 -0700 Subject: [Freeipa-devel] [PATCH 0041] permission-add does not prompt for ipapermright option in interactive mode Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4872 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0041-permission-add-does-not-prompt-for-ipapermright-in-i.patch Type: application/octet-stream Size: 1228 bytes Desc: not available URL: From lslebodn at redhat.com Fri Jan 30 09:34:37 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 30 Jan 2015 10:34:37 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <54CA201D.6010009@redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> <1422455863.2970.14.camel@willson.usersys.redhat.com> <54C90472.5080007@redhat.com> <20150128173023.GJ6592@redhat.com> <54CA201D.6010009@redhat.com> Message-ID: <20150130093436.GB6603@mail.corp.redhat.com> On (29/01/15 12:57), Martin Babinsky wrote: >Date: Wed, 28 Jan 2015 16:28:01 +0100 >Subject: [PATCH 6/7] ipa-uuid: emit a message when unexpected mod type is > encountered > >This patch is related to the following defect reported by covscan of FreeIPA >master code: > >""" >Error: DEADCODE (CWE-561): /daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:796: >cond_const: Condition "modtype != 1", taking false branch. Now the value of >"modtype" is equal to 1. >/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:796: >cond_const: Condition "modtype != 4", taking false branch. Now the value of >"modtype" is equal to 4. >/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:941: >equality_cond: Jumping to case "1". >/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:957: equality_cond: Jumping to >case "4". >/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:940: intervals: When >switching on "modtype", the value of "modtype" must be in one of the following >intervals: {[1,1], [4,4]}. >/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:940: dead_error_condition: The >switch value "modtype" cannot reach the default case. >/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c:1031: dead_error_begin: >Execution cannot reach this statement: "default:". >""" > >The patch is a part of series related to >https://fedorahosted.org/freeipa/ticket/4795 > >--- > daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c | 2 ++ > 1 file changed, 2 insertions(+) > >diff --git a/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c b/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c >index 2b07de45b63dab36a0b7167e3583e88ebd07f6f7..93da0f15b8acfc02beddf4e884a735897a7513fe 100644 >--- a/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c >+++ b/daemons/ipa-slapi-plugins/ipa-uuid/ipa_uuid.c >@@ -1030,6 +1030,8 @@ static int ipauuid_pre_op(Slapi_PBlock *pb, int modtype) > > default: > /* never reached, just silence compiler */ >+ LOG_TRACE("File '%s' line %d: Got unexpected value of modtype:" >+ "%d\n", __FILE__, __LINE__, modtype); > break; It is good idea to add "__FILE__, __LINE__" to debug message. It would be better if macro LOG_TRACE added this info itself. @see macro LOG_FATAL and LOG_TRACE file: daemons/ipa-slapi-plugins/common/util.h #define LOG_FATAL(fmt, ...) \ slapi_log_error(SLAPI_LOG_FATAL, log_func, \ "[file %s, line %d]: " fmt, \ __FILE__, __LINE__, ##__VA_ARGS__) #define LOG_TRACE(fmt, ...) \ slapi_log_error(SLAPI_LOG_TRACE, log_func, fmt, ##__VA_ARGS__) LS From mbabinsk at redhat.com Fri Jan 30 09:54:50 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Jan 2015 10:54:50 +0100 Subject: [Freeipa-devel] [PATCH 0012] migrate-ds: exit with error message if no users/groups to migrate are found Message-ID: <54CB54EA.5060106@redhat.com> Attached patch fixes https://fedorahosted.org/freeipa/ticket/4864. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0012-1-migrate-ds-exit-with-error-message-if-no-users-group.patch Type: text/x-patch Size: 2405 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Jan 30 10:00:18 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Jan 2015 11:00:18 +0100 Subject: [Freeipa-devel] [PATCH 0012] migrate-ds: exit with error message if no users/groups to migrate are found In-Reply-To: <54CB54EA.5060106@redhat.com> References: <54CB54EA.5060106@redhat.com> Message-ID: <54CB5632.1070702@redhat.com> On 01/30/2015 10:54 AM, Martin Babinsky wrote: > Attached patch fixes https://fedorahosted.org/freeipa/ticket/4864. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Got the ticket number wrong. Should be https://fedorahosted.org/freeipa/ticket/4846 Attaching patch with fixed description. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0012-1-migrate-ds-exit-with-error-message-if-no-users-group.patch Type: text/x-patch Size: 2405 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 30 10:04:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 Jan 2015 11:04:30 +0100 Subject: [Freeipa-devel] [PATCHES 0005-0011] Fix some of the defects reported by covscan on freeipa-master In-Reply-To: <20150129124211.GL6592@redhat.com> References: <54C7BB20.1080109@redhat.com> <54C8E9CF.5060206@redhat.com> <1422455863.2970.14.camel@willson.usersys.redhat.com> <54C90472.5080007@redhat.com> <20150128173023.GJ6592@redhat.com> <54CA201D.6010009@redhat.com> <20150129124211.GL6592@redhat.com> Message-ID: <54CB572E.9070405@redhat.com> On 01/29/2015 01:42 PM, Alexander Bokovoy wrote: > On Thu, 29 Jan 2015, Martin Babinsky wrote: >> On 01/28/2015 06:30 PM, Alexander Bokovoy wrote: >>> On Wed, 28 Jan 2015, Martin Babinsky wrote: >>>> On 01/28/2015 03:37 PM, Simo Sorce wrote: >>>>> On Wed, 2015-01-28 at 14:53 +0100, Martin Babinsky wrote: >>>>>> On 01/27/2015 05:21 PM, Martin Babinsky wrote: >>>>>>> This series of patches is related to >>>>>>> https://fedorahosted.org/freeipa/ticket/4795. >>>>>>> >>>>>>> The attached patches attempt to address some of the defects >>>>>>> encountered >>>>>>> during running covscan on freeipa-master branch. >>>>>>> >>>>>>> The complete list is here: >>>>>>> http://cov01.lab.eng.brq.redhat.com/covscanhub/task/16553/log/freeipa-4.1.99.201501270952GITc90286c-0.fc21/scan-results.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> These patches do not fix defects 1 to 22 which occur in a code >>>>>>> generated >>>>>>> by asn1c, defect 23 which is related to >>>>>>> https://fedorahosted.org/freeipa/ticket/4861, and defect 27 (dead >>>>>>> code). >>>>>>> >>>>>>> Each patch contains a detailed description of a defect and a proposed >>>>>>> fix to address it. >>>>>>> >>>>>>> Martin^3 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> >>>>>> Attaching updated patches. >>>>>> >>>>> >>>>> You are gratuitously removing empty lines in various patches. >>>>> They are there to make the code flow more readable, please do not remove >>>>> them. >>>>> >>>>> Simo. >>>>> >>>> Attaching updated patches. >>>> >>> Patches look OK for me now. I need to test them in a clean install so >>> please don't commit them yet. >>> >> >> Some vim backup files crept into the previous attachment. Re-sending the >> correct patchset. > ACK. > Good discussion&quick turnaround, thanks to all! Pushed to: master: 782ad366390e1672ebe3584b2c88f58d757e38b3 ipa-4-1: 5bad375656723595d60abba494992c27accebbe9 (links to all patches in the ticket) Martin From mkosek at redhat.com Fri Jan 30 12:13:24 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 Jan 2015 13:13:24 +0100 Subject: [Freeipa-devel] [PATCH] 494 group-detach does not add correct objectclasses Message-ID: <54CB7564.8040106@redhat.com> https://fedorahosted.org/freeipa/ticket/4874 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-494-group-detach-does-not-add-correct-objectclasses.patch Type: text/x-patch Size: 838 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 30 14:04:20 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Jan 2015 09:04:20 -0500 Subject: [Freeipa-devel] [PATCH] 494 group-detach does not add correct objectclasses In-Reply-To: <54CB7564.8040106@redhat.com> References: <54CB7564.8040106@redhat.com> Message-ID: <54CB8F64.7050104@redhat.com> Martin Kosek wrote: > https://fedorahosted.org/freeipa/ticket/4874 LGTM but a test please to prevent future regressions. rob From mbabinsk at redhat.com Fri Jan 30 14:05:53 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 30 Jan 2015 15:05:53 +0100 Subject: [Freeipa-devel] [PATCH 0013] ipa-client-install: put eol character after the last line of altered config file(s) Message-ID: <54CB8FC1.4000003@redhat.com> https://fedorahosted.org/freeipa/ticket/4864 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0013-1-ipa-client-install-put-eol-character-after-the-last-.patch Type: text/x-patch Size: 1035 bytes Desc: not available URL: From lkrispen at redhat.com Fri Jan 30 15:09:48 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 30 Jan 2015 16:09:48 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141215170150.00437756@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> Message-ID: <54CB9EBC.2030405@redhat.com> On 12/15/2014 11:01 PM, Simo Sorce wrote: > Hello fellow developers, I added this new design: > http://www.freeipa.org/page/V4/Domain_Levels > > It is a prerequisite for both the Replica Promotion design: > http://www.freeipa.org/page/V4/Replica_Promotion > and the Topology plugins design: > http://www.freeipa.org/page/V4/Manage_replication_topology > (Ludwig will change this to include the changes we have discussed in a > previous phone call, and which involve mostly Domain Level/Domain > Upgrades/migrations issues) I've updated this now, it just needs a reviewer There is also a working implementation for this state, just some cleanup before review (or feedback from design review) > > As usual feel free to add as needed or comments and ask questions. > > Simo. >