Re: [Freeipa-devel] IPA Python API
Dne 17.6.2015 v 19:18 Drew Erny napsal(a): On 06/17/2015 01:24 AM, Jan Cholasta wrote: Dne 16.6.2015 v 20:29 Drew Erny napsal(a): Hi, All, ... Call api.Backend.rpcclient.connect(ccache=krbV.default_context().default_ccache()) to make the problem go away. This doesn't work. The Flask application runs (as I mentioned in a different email) with or without this change, but it will not run in debug mode either way. That's probably because there are no credentials in the default ccache. You might try to kinit first and/or supply a different ccache. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0001 Provide Kerberos over HTTP (MS-KKDCP)
On Wed, 2015-06-17 at 21:21 +0200, Christian Heimes wrote: > On 2015-06-17 18:09, Nathaniel McCallum wrote: > > On Fri, 2015-06-12 at 17:58 -0400, Adam Young wrote: > >> On 06/12/2015 03:40 PM, Nathaniel McCallum wrote: > >>> It doesn't apply again. > >>> > >>> On Tue, 2015-06-09 at 15:55 +0200, Christian Heimes wrote: > On 2015-05-27 15:16, Christian Heimes wrote: > > Hello, > > > > here is my first patch for FreeIPA. The patch integrates python > > -kdcproxy > > for MS-KKDCP support (aka Kerberos over HTTPS). > > > > https://www.freeipa.org/page/V4/KDC_Proxy > > > > Ticket: https://fedorahosted.org/freeipa/ticket/4801 > freeipa-cheimes-0001-2-Provide-Kerberos-over-HTTP-MS-KKDCP.patch > doesn't > apply anymore. The new patch is based on the current master. > > Christian > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: > http://www.freeipa.org/page/Contribute/Code > > Thanks Nathaniel, > > quick review before I have to leave again. A couple of Red Hatters > from > Brno just arrived at the hotel. I'll grab a beer with them. > > > I'm reviewing Adam's version of Christian's patch. > > > > * FreeIPA should require python-kdcproxy >= 0.3 considering there > are > > lots of fixes related to this project. > > We need to package it first, when I'm back from NHO. I've started to > study the packaging docs in the engineering section. Maybe you or > somebody else can walk me through the process next week? I'm happy to walk you through it. However, it is already built (just not pushed): http://koji.fedoraproject.org/koji/packageinfo?packageID=19292 > > * KDC Proxy path is not configurable. This probably needs to be > noted > > in documentation somewhere when mentioning the default path. > > LGTM > > > * Has OID 2.16.840.1.113730.3.8.3.28 been officially claimed? > > How? I thought 2.16.840.1.113730.3.8.3 is in our own OID space and we > don't have to register it with IANA. Or are you referring to another > registry? We have our own registry. I can walk you through the details off -thread. > > * There is a new permission: Read IPA Masters KDC Proxy. Is this > > necessary. Can't the config be world-readable and admin writable? > There > > is no extra security in hiding this attribute. This also completely > > removes the need for a keytab since anonymous binding can be used. > This > > also, I believe, removes the need for a service. > > That would make the code simpler and shorter too. I'm +0 on the > proposal. > > > > * The creation of the kdcproxy user is trailed by "exit 0". Why? > > https://fedoraproject.org/wiki/Packaging:UsersAndGroups recommends "e > xit 0". > > > > * replicainstall.py has trailing whitespace > > I'll address it with my next patch. > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Community Portal Prototype
Hello, all, I've built a prototype of the community portal, and I'd like a quick sanity check on it. If someone would look over the architecture of this code and make sure that the design is sensible before I proceed any further, that would be very helpful. The source code can be found here: https://github.com/dperny/freeipa-communityportal This code should run on your machine, and you should be able to add users to the staging tree. It might not, howver; the point is to have the code looked at before I spend anymore time on it. The Community Portal prototype is a Python Flask web-application that acts as a client to a FreeIPA server. It collects input from the unwashed masses (in the form of a user sign-up page) and then sends it to the FreeIPA server. This way, the Community Portal acts like a gateway between the FreeIPA server and the anonymous community users, restricting the commands they can send to the server. Right now, the server imports FreeIPA's Python ipalib module, which allows it to act like a client. It uses api.Command.stageuser_add(...) to add new users to the staging area of the FreeIPA database. It then sends an email to the admin (or, rather, it logs an email to the console instead of sending one, in the prototype) to alert them to the fact that a user has signed up. All feedback is welcome. Thanks, Drew -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0001 Provide Kerberos over HTTP (MS-KKDCP)
On 2015-06-17 18:09, Nathaniel McCallum wrote: > On Fri, 2015-06-12 at 17:58 -0400, Adam Young wrote: >> On 06/12/2015 03:40 PM, Nathaniel McCallum wrote: >>> It doesn't apply again. >>> >>> On Tue, 2015-06-09 at 15:55 +0200, Christian Heimes wrote: On 2015-05-27 15:16, Christian Heimes wrote: > Hello, > > here is my first patch for FreeIPA. The patch integrates python > -kdcproxy > for MS-KKDCP support (aka Kerberos over HTTPS). > > https://www.freeipa.org/page/V4/KDC_Proxy > > Ticket: https://fedorahosted.org/freeipa/ticket/4801 freeipa-cheimes-0001-2-Provide-Kerberos-over-HTTP-MS-KKDCP.patch doesn't apply anymore. The new patch is based on the current master. Christian -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code Thanks Nathaniel, quick review before I have to leave again. A couple of Red Hatters from Brno just arrived at the hotel. I'll grab a beer with them. > I'm reviewing Adam's version of Christian's patch. > > * FreeIPA should require python-kdcproxy >= 0.3 considering there are > lots of fixes related to this project. We need to package it first, when I'm back from NHO. I've started to study the packaging docs in the engineering section. Maybe you or somebody else can walk me through the process next week? > * KDC Proxy path is not configurable. This probably needs to be noted > in documentation somewhere when mentioning the default path. LGTM > * Has OID 2.16.840.1.113730.3.8.3.28 been officially claimed? How? I thought 2.16.840.1.113730.3.8.3 is in our own OID space and we don't have to register it with IANA. Or are you referring to another registry? > * There is a new permission: Read IPA Masters KDC Proxy. Is this > necessary. Can't the config be world-readable and admin writable? There > is no extra security in hiding this attribute. This also completely > removes the need for a keytab since anonymous binding can be used. This > also, I believe, removes the need for a service. That would make the code simpler and shorter too. I'm +0 on the proposal. > * The creation of the kdcproxy user is trailed by "exit 0". Why? https://fedoraproject.org/wiki/Packaging:UsersAndGroups recommends "exit 0". > * replicainstall.py has trailing whitespace I'll address it with my next patch. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] IPA Python API
On 06/17/2015 01:24 AM, Jan Cholasta wrote: Dne 16.6.2015 v 20:29 Drew Erny napsal(a): Hi, All, ... Call api.Backend.rpcclient.connect(ccache=krbV.default_context().default_ccache()) to make the problem go away. This doesn't work. The Flask application runs (as I mentioned in a different email) with or without this change, but it will not run in debug mode either way. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] user deletion in offline mode does not get replicated after node recovery
Hello, Thanks Oleg for the access on the VMs. I confirm that you hit https://fedorahosted.org/389/ticket/47788 I updated this ticket with the details found in your tests. Unfortunately we have no fix yet for this ticket although it is an important one. In your test,on a master a user entry (and its related group...) were successfully deleted/updated but on one replica the deletion of the user entry was skipped but related updates (group) were successful. I agree that it is a timing problem and should occur rarely. thanks thierry On 06/17/2015 12:58 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 11:06 AM, Ludwig Krispenz wrote: Hi Oleg, can you give a bit more info on the scenarios when this happens. Always or is it a timing problem ? I guess it is a timing problem. It happened yesterday, today I was unable to reproduce this. The scenario is very simple: create a user1, make sure it's there turn off a replica, then create another user on master and delete user1 on master, then turn replica back on. I still have an infrastructure with 2 replicas having a user that was deleted on master. Now all the user (and other data) manipulations on this very setup work as intended. Ludwig On 06/16/2015 07:02 PM, thierry bordaz wrote: Hello On Master: User 'onmaster' was deleted [16/Jun/2015:10:16:45 -0400] conn=402 op=19 SRCH base="cn=otp,dc=bagam,dc=net" scope=1 filter="(&(objectClass=ipatoken)(ipatokenOwner=uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net))" attrs="ipatokenNotAfter description ipatokenOwner objectClass ipatokenDisabled ipatokenVendor managedBy ipatokenModel ipatokenNotBefore ipatokenUniqueID ipatokenSerial" [16/Jun/2015:10:16:45 -0400] conn=402 op=19 RESULT err=0 tag=101 nentries=0 etime=0 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:16:45 -0400] conn=402 op=21 UNBIND [16/Jun/2015:10:16:45 -0400] conn=402 op=21 fd=120 closed - U1 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 RESULT err=0 tag=107 nentries=0 etime=0 csn=55802fcf00030004 Replication agreement failed to replicate it to the replica2 [16/Jun/2015:10:18:36 -0400] NSMMReplicationPlugin - agmt="cn=f22master.bagam.net-to-f22replica2.bagam.net" (f22replica2:389): Consumer failed to replay change (uniqueid b8242e18-143111e5-b1d0d0c3-ae5854ff, CSN 55802fcf00030004): Operations error (1). Will retry later. On replica2: The replicated operation failed [16/Jun/2015:10:18:27 -0400] conn=8 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=5 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [16/Jun/2015:10:18:27 -0400] conn=8 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 because of DB failures to update. The failures were E_AGAIN or E_DB_DEADLOCK. In such situation, DS retries after a small delay. The problem is that it retried 50 times without success. [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=55802fcf00030004) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (55802fcf00030004); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net (uniqid: b8242e18-143111e5-b1d0d0c3-ae5854ff, optype: 32) to changelog csn 55802fcf00030004 [16/Jun/2015:10:18:34 -0400] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code but did not set SLAPI_RESULT_CODE The MAIN issue here is that replica2 successfully applied others updates after 55802fcf00030004 from the same replica (e.g csn=55802fcf00040004) I do not know if master was able to detect this failure and to replay this update. but I am afraid it did not !! It is looking like you hit https://fedorahosted.org/389/ticket/47788 Is it possible to access your VM ? [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 [16/Jun/2015:10:18:35 -0400] conn=8 op=7 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:36 -0400] conn=8 op=7 RESULT err=0 tag=103 nentries=0 etime=1 csn=55802fcf00040004 [16/Jun/2015:10:18:36 -0400] conn=8 op=8 DEL dn="cn=onmaster,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=8 RESULT e
Re: [Freeipa-devel] [PATCH] 0001 Provide Kerberos over HTTP (MS-KKDCP)
On Fri, 2015-06-12 at 17:58 -0400, Adam Young wrote: > On 06/12/2015 03:40 PM, Nathaniel McCallum wrote: > > It doesn't apply again. > > > > On Tue, 2015-06-09 at 15:55 +0200, Christian Heimes wrote: > > > On 2015-05-27 15:16, Christian Heimes wrote: > > > > Hello, > > > > > > > > here is my first patch for FreeIPA. The patch integrates python > > > > -kdcproxy > > > > for MS-KKDCP support (aka Kerberos over HTTPS). > > > > > > > > https://www.freeipa.org/page/V4/KDC_Proxy > > > > > > > > Ticket: https://fedorahosted.org/freeipa/ticket/4801 > > > freeipa-cheimes-0001-2-Provide-Kerberos-over-HTTP-MS-KKDCP.patch > > > doesn't > > > apply anymore. The new patch is based on the current master. > > > > > > Christian > > > > > > -- > > > Manage your subscription for the Freeipa-devel mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Contribute to FreeIPA: > > > http://www.freeipa.org/page/Contribute/Code I'm reviewing Adam's version of Christian's patch. * FreeIPA should require python-kdcproxy >= 0.3 considering there are lots of fixes related to this project. * KDC Proxy path is not configurable. This probably needs to be noted in documentation somewhere when mentioning the default path. * Has OID 2.16.840.1.113730.3.8.3.28 been officially claimed? * There is a new permission: Read IPA Masters KDC Proxy. Is this necessary. Can't the config be world-readable and admin writable? There is no extra security in hiding this attribute. This also completely removes the need for a keytab since anonymous binding can be used. This also, I believe, removes the need for a service. * The creation of the kdcproxy user is trailed by "exit 0". Why? * replicainstall.py has trailing whitespace Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
On 06/17/2015 05:43 PM, Oleg Fayans wrote: On 06/17/2015 05:34 PM, Ludwig Krispenz wrote: On 06/17/2015 05:26 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 05:13 PM, Ludwig Krispenz wrote: Hi, On 06/17/2015 05:07 PM, Oleg Fayans wrote: On 06/17/2015 04:59 PM, Ludwig Krispenz wrote: On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. just to be clear, you have master <-> replica1 <-> replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. To be precise, my topology is as follows master <-> replica3 <-> replica2 <-> replica1 And I disabled the replica3 <-> replica2. So I expected the changes on master to be only visible on master and replica3, but actually it kept replicating to all nodes. root@f22replica1:/home/ofayans]$ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Number of entries returned 3 root@f22replica1:/home/ofayans]$ ipa topologysegment-show realm replica3-to-replica2 Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Replication agreement enabled: off can you do a ldapsearch on cn=realm,cn=topology, .. $ ldapsearch -LLL -b "cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net" -D "cn=Directory Manager" -w '' dn: cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net cn: realm ipaReplTopoConfRoot: dc=bagam,dc=net objectClass: top objectClass: iparepltopoconf dn: cn=replica1-to-replica2,cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentRightNode: f22replica2.bagam.net ipaReplTopoSegmentDirection: both cn: replica1-to-replica2 ipaReplTopoSegmentLeftNode: f22replica1.bagam.net objectClass: iparepltoposegment objectClass: top replica1 - replica2 dn: cn=f22master.bagam.net-to-f22replica3.bagam.net,cn=realm,cn=topology,cn=ip a,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentDirection: both objectClass: iparepltoposegment objectClass: top cn: f22master.bagam.net-to-f22replica3.bagam.net ipaReplTopoSegmentLeftNode: f22master.bagam.net ipaReplTopoSegmentRightNode: f22replica3.bagam.net ipaReplTopoSegmentStatus: autogen master - replica3 dn: cn=f22replica3.bagam.net-f22replica1.bagam.net,cn=realm,cn=topology,cn=ipa ,cn=etc,dc=bagam,dc=net objectClass: iparepltoposegment objectClass: top ipaReplTopoSegmentLeftNode: f22replica3.bagam.net cn: f22replica3.bagam.net-f22replica1.bagam.net ipaReplTopoSegmentDirection: both ipaReplTopoSegmentRightNode: f22replica1.bagam.net replica3 - replica1 but this does not match your segment-find output, there is no segment replica2 - replica3 You know what, this is because I did ldapsearch on replica3, while I posted the results of topologysegment-find run on replica1. But this means that there is a breakage in the replication between replica1 and the rest of topology (the result of topologysegment-find is the same across master-replica2-replica3 and different on replica1) the replication agreements on r3 match the output of the cn=realm search, saying you have a topology master <--> r3 <--> r1 <--> r2. could it be that you made changes while the segment was (partially) disabled. We would need the full history of topology changes and on replica3 do a search -b "cn=config" "objectclass=nsds5replicationagreement" $ ldapsearch -LLL -b "cn=config" "objectclass=nsds5replicationagreement" -D "cn=Directory Manager" -w '' dn: cn=f22replica3.bagam.net-to-f22replica1.bagam.net,cn=replica,cn=dc\3Dbagam \2Cdc\3Dnet,cn=mapping tree,cn=config objectClass: nsds5replicationagreement objectClass: ipaReplTopoManagedAgreement objectClass: top cn: f22replica3.bagam.net-to-f22replica1.bagam.net nsDS5ReplicaHost: f22replica1.bagam.net nsDS5ReplicaPort: 389 nsds5replicaTimeout: 300 nsDS5ReplicaRoot: dc=bagam,dc=net description: f22replic
Re: [Freeipa-devel] FreeIPA 4.2 Alpha preparations
On 06/17/2015 12:31 PM, Fraser Tweedale wrote: > On Wed, Jun 17, 2015 at 07:55:10AM +0200, Martin Kosek wrote: >> On 06/16/2015 05:29 PM, Fraser Tweedale wrote: >>> On Tue, Jun 16, 2015 at 05:10:00PM +0200, Martin Kosek wrote: On 06/12/2015 11:34 AM, Martin Kosek wrote: > Hello all, > > As discussed in the last 2 weeks, we are getting close to the 4.2 finish > line > and releasing FreeIPA 4.2 Alpha 1. We already have most of the major RFEs > complete, some still miss some partial functionality, but most are > testable and > in Alpha state already. > > We need to now find out what is blocking us from releasing the Alpha. I > know > only about 2 issues: > > - ipa-replica-manage del does not work well with the Topology plugin yet > - Petr > Vobornik and Ludwig are working on it > - ipa-replica-prepare had some issues after upgrade from 4.1.x to 4.2.0 > due to > inaccesible certificate profiles - Jan, Martin2, Fraser was investigating > > Is that correct? Feature owners, please let me know if any of the major > feature > regressed and is not working properly, maybe by other patch sets being > merged. > > When the blockers are resolved or documented, we should release the > beast. Any > volunteer for the release process? > > Finally, I put together a release note draft for the Alpha, please help me > completing and updating it: > > http://www.freeipa.org/page/Releases/4.2.0.alpha1 > > Thanks everyone! > I saw many fixes in Topology, that's good. I heard that pki-core 10.2.4 broke us, but I could not reproduce it today with fully updated F22 machine and I was able to install FreeIPA 4.2.git If this is the case, can we just release the Alpha? >>> >>> There are still some big brokens for upgrades. The fixes for pki >>> are merged but there is no release yet. >> >> What is the ETA? It would be nice to have the fix for Alpha, the package can >> be built in the freeipa-4.2 COPR repo, together with the 4.2 Alpha release. >> If the ETA is too far, we may need to release Alpha regardless as there are >> some Test Days planned next week and upgrade is not required for such test >> days. >> > Based on people educating me about how LDAP replication works: > tomorrow, hopefully. In any case, I'm glad to know that the test > days will not be affected by upgrade issues. Well, I will need some release in COPR for the test day. If clean install works, it is good for me. So if you do not have Dogtag release with upgrade issues fixed, I would just release Alpha as is, with this limitation. I do not expect people upgrading to Alpha from production releases before 4.2 anyway. > >>> I am only aware of one >>> reported issue for new installations: ipa-replica-prepare failing >>> when run on a replica (I haven't gotten to investigating this one >>> yet). >> >> >> Right. This must be fixed before GA, but Alpha can live without it IMO. > > I investigated this regression today - details are in another > thread, but it appears to be introduced by a different change and I > have requested comment from those more familiar with that change. > > Thanks, > Fraser > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
On 06/17/2015 05:34 PM, Ludwig Krispenz wrote: On 06/17/2015 05:26 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 05:13 PM, Ludwig Krispenz wrote: Hi, On 06/17/2015 05:07 PM, Oleg Fayans wrote: On 06/17/2015 04:59 PM, Ludwig Krispenz wrote: On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. just to be clear, you have master <-> replica1 <-> replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. To be precise, my topology is as follows master <-> replica3 <-> replica2 <-> replica1 And I disabled the replica3 <-> replica2. So I expected the changes on master to be only visible on master and replica3, but actually it kept replicating to all nodes. root@f22replica1:/home/ofayans]$ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Number of entries returned 3 root@f22replica1:/home/ofayans]$ ipa topologysegment-show realm replica3-to-replica2 Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Replication agreement enabled: off can you do a ldapsearch on cn=realm,cn=topology, .. $ ldapsearch -LLL -b "cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net" -D "cn=Directory Manager" -w '' dn: cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net cn: realm ipaReplTopoConfRoot: dc=bagam,dc=net objectClass: top objectClass: iparepltopoconf dn: cn=replica1-to-replica2,cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentRightNode: f22replica2.bagam.net ipaReplTopoSegmentDirection: both cn: replica1-to-replica2 ipaReplTopoSegmentLeftNode: f22replica1.bagam.net objectClass: iparepltoposegment objectClass: top replica1 - replica2 dn: cn=f22master.bagam.net-to-f22replica3.bagam.net,cn=realm,cn=topology,cn=ip a,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentDirection: both objectClass: iparepltoposegment objectClass: top cn: f22master.bagam.net-to-f22replica3.bagam.net ipaReplTopoSegmentLeftNode: f22master.bagam.net ipaReplTopoSegmentRightNode: f22replica3.bagam.net ipaReplTopoSegmentStatus: autogen master - replica3 dn: cn=f22replica3.bagam.net-f22replica1.bagam.net,cn=realm,cn=topology,cn=ipa ,cn=etc,dc=bagam,dc=net objectClass: iparepltoposegment objectClass: top ipaReplTopoSegmentLeftNode: f22replica3.bagam.net cn: f22replica3.bagam.net-f22replica1.bagam.net ipaReplTopoSegmentDirection: both ipaReplTopoSegmentRightNode: f22replica1.bagam.net replica3 - replica1 but this does not match your segment-find output, there is no segment replica2 - replica3 You know what, this is because I did ldapsearch on replica3, while I posted the results of topologysegment-find run on replica1. But this means that there is a breakage in the replication between replica1 and the rest of topology (the result of topologysegment-find is the same across master-replica2-replica3 and different on replica1) and on replica3 do a search -b "cn=config" "objectclass=nsds5replicationagreement" $ ldapsearch -LLL -b "cn=config" "objectclass=nsds5replicationagreement" -D "cn=Directory Manager" -w '' dn: cn=f22replica3.bagam.net-to-f22replica1.bagam.net,cn=replica,cn=dc\3Dbagam \2Cdc\3Dnet,cn=mapping tree,cn=config objectClass: nsds5replicationagreement objectClass: ipaReplTopoManagedAgreement objectClass: top cn: f22replica3.bagam.net-to-f22replica1.bagam.net nsDS5ReplicaHost: f22replica1.bagam.net nsDS5ReplicaPort: 389 nsds5replicaTimeout: 300 nsDS5ReplicaRoot: dc=bagam,dc=net description: f22replica3.bagam.net to f22replica1.bagam.net ipaReplTopoManagedAgreementState: managed agreement - generated by topology pl ugin nsDS5ReplicaTransportInfo: LDAP nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krbl
Re: [Freeipa-devel] disabling topology segment has no effect
On 06/17/2015 05:26 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 05:13 PM, Ludwig Krispenz wrote: Hi, On 06/17/2015 05:07 PM, Oleg Fayans wrote: On 06/17/2015 04:59 PM, Ludwig Krispenz wrote: On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. just to be clear, you have master <-> replica1 <-> replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. To be precise, my topology is as follows master <-> replica3 <-> replica2 <-> replica1 And I disabled the replica3 <-> replica2. So I expected the changes on master to be only visible on master and replica3, but actually it kept replicating to all nodes. root@f22replica1:/home/ofayans]$ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Number of entries returned 3 root@f22replica1:/home/ofayans]$ ipa topologysegment-show realm replica3-to-replica2 Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Replication agreement enabled: off can you do a ldapsearch on cn=realm,cn=topology, .. $ ldapsearch -LLL -b "cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net" -D "cn=Directory Manager" -w '' dn: cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net cn: realm ipaReplTopoConfRoot: dc=bagam,dc=net objectClass: top objectClass: iparepltopoconf dn: cn=replica1-to-replica2,cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentRightNode: f22replica2.bagam.net ipaReplTopoSegmentDirection: both cn: replica1-to-replica2 ipaReplTopoSegmentLeftNode: f22replica1.bagam.net objectClass: iparepltoposegment objectClass: top replica1 - replica2 dn: cn=f22master.bagam.net-to-f22replica3.bagam.net,cn=realm,cn=topology,cn=ip a,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentDirection: both objectClass: iparepltoposegment objectClass: top cn: f22master.bagam.net-to-f22replica3.bagam.net ipaReplTopoSegmentLeftNode: f22master.bagam.net ipaReplTopoSegmentRightNode: f22replica3.bagam.net ipaReplTopoSegmentStatus: autogen master - replica3 dn: cn=f22replica3.bagam.net-f22replica1.bagam.net,cn=realm,cn=topology,cn=ipa ,cn=etc,dc=bagam,dc=net objectClass: iparepltoposegment objectClass: top ipaReplTopoSegmentLeftNode: f22replica3.bagam.net cn: f22replica3.bagam.net-f22replica1.bagam.net ipaReplTopoSegmentDirection: both ipaReplTopoSegmentRightNode: f22replica1.bagam.net replica3 - replica1 but this does not match your segment-find output, there is no segment replica2 - replica3 and on replica3 do a search -b "cn=config" "objectclass=nsds5replicationagreement" $ ldapsearch -LLL -b "cn=config" "objectclass=nsds5replicationagreement" -D "cn=Directory Manager" -w '' dn: cn=f22replica3.bagam.net-to-f22replica1.bagam.net,cn=replica,cn=dc\3Dbagam \2Cdc\3Dnet,cn=mapping tree,cn=config objectClass: nsds5replicationagreement objectClass: ipaReplTopoManagedAgreement objectClass: top cn: f22replica3.bagam.net-to-f22replica1.bagam.net nsDS5ReplicaHost: f22replica1.bagam.net nsDS5ReplicaPort: 389 nsds5replicaTimeout: 300 nsDS5ReplicaRoot: dc=bagam,dc=net description: f22replica3.bagam.net to f22replica1.bagam.net ipaReplTopoManagedAgreementState: managed agreement - generated by topology pl ugin nsDS5ReplicaTransportInfo: LDAP nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in ternalModifyTimestamp nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 20150617151930Z nsds5replicaLastUpdateEnd: 20150617151930Z nsds5re
Re: [Freeipa-devel] disabling topology segment has no effect
Hi Ludwig, On 06/17/2015 05:13 PM, Ludwig Krispenz wrote: Hi, On 06/17/2015 05:07 PM, Oleg Fayans wrote: On 06/17/2015 04:59 PM, Ludwig Krispenz wrote: On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. just to be clear, you have master <-> replica1 <-> replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. To be precise, my topology is as follows master <-> replica3 <-> replica2 <-> replica1 And I disabled the replica3 <-> replica2. So I expected the changes on master to be only visible on master and replica3, but actually it kept replicating to all nodes. root@f22replica1:/home/ofayans]$ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Number of entries returned 3 root@f22replica1:/home/ofayans]$ ipa topologysegment-show realm replica3-to-replica2 Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Replication agreement enabled: off can you do a ldapsearch on cn=realm,cn=topology, .. $ ldapsearch -LLL -b "cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net" -D "cn=Directory Manager" -w '' dn: cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net cn: realm ipaReplTopoConfRoot: dc=bagam,dc=net objectClass: top objectClass: iparepltopoconf dn: cn=replica1-to-replica2,cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentRightNode: f22replica2.bagam.net ipaReplTopoSegmentDirection: both cn: replica1-to-replica2 ipaReplTopoSegmentLeftNode: f22replica1.bagam.net objectClass: iparepltoposegment objectClass: top dn: cn=f22master.bagam.net-to-f22replica3.bagam.net,cn=realm,cn=topology,cn=ip a,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentDirection: both objectClass: iparepltoposegment objectClass: top cn: f22master.bagam.net-to-f22replica3.bagam.net ipaReplTopoSegmentLeftNode: f22master.bagam.net ipaReplTopoSegmentRightNode: f22replica3.bagam.net ipaReplTopoSegmentStatus: autogen dn: cn=f22replica3.bagam.net-f22replica1.bagam.net,cn=realm,cn=topology,cn=ipa ,cn=etc,dc=bagam,dc=net objectClass: iparepltoposegment objectClass: top ipaReplTopoSegmentLeftNode: f22replica3.bagam.net cn: f22replica3.bagam.net-f22replica1.bagam.net ipaReplTopoSegmentDirection: both ipaReplTopoSegmentRightNode: f22replica1.bagam.net and on replica3 do a search -b "cn=config" "objectclass=nsds5replicationagreement" $ ldapsearch -LLL -b "cn=config" "objectclass=nsds5replicationagreement" -D "cn=Directory Manager" -w '' dn: cn=f22replica3.bagam.net-to-f22replica1.bagam.net,cn=replica,cn=dc\3Dbagam \2Cdc\3Dnet,cn=mapping tree,cn=config objectClass: nsds5replicationagreement objectClass: ipaReplTopoManagedAgreement objectClass: top cn: f22replica3.bagam.net-to-f22replica1.bagam.net nsDS5ReplicaHost: f22replica1.bagam.net nsDS5ReplicaPort: 389 nsds5replicaTimeout: 300 nsDS5ReplicaRoot: dc=bagam,dc=net description: f22replica3.bagam.net to f22replica1.bagam.net ipaReplTopoManagedAgreementState: managed agreement - generated by topology pl ugin nsDS5ReplicaTransportInfo: LDAP nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in ternalModifyTimestamp nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts uccessfulauth krblastfailedauth krbloginfailedcount nsds5replicareapactive: 0 nsds5replicaLastUpdateStart: 20150617151930Z nsds5replicaLastUpdateEnd: 20150617151930Z nsds5replicaChangesSentSinceStartup:: Njo1LzMyOSA0OjcvMCA= nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd ate succeeded nsds5replicaUpdateInProgress: FALSE nsds5replicaLastI
Re: [Freeipa-devel] disabling topology segment has no effect
Hi, On 06/17/2015 05:07 PM, Oleg Fayans wrote: On 06/17/2015 04:59 PM, Ludwig Krispenz wrote: On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. just to be clear, you have master <-> replica1 <-> replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. To be precise, my topology is as follows master <-> replica3 <-> replica2 <-> replica1 And I disabled the replica3 <-> replica2. So I expected the changes on master to be only visible on master and replica3, but actually it kept replicating to all nodes. root@f22replica1:/home/ofayans]$ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Number of entries returned 3 root@f22replica1:/home/ofayans]$ ipa topologysegment-show realm replica3-to-replica2 Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Replication agreement enabled: off can you do a ldapsearch on cn=realm,cn=topology, .. and on replica3 do a search -b "cn=config" "objectclass=nsds5replicationagreement" would like to see the raw data. It reproduces though even in a situation with the topology replica3 <-> master <-> replica1 <-> replica2 and you disable the replica1-replica2 segment on replica3 (quite expectedly) and disable one of the segments, one would expect the changes implemented on master would not be replicated to other nodes (or do I misunderstand the concept of disabling a segment?). However, in reality any changes in master do get replicated despite the segment is disabled. Is it a correct behavior? The second question is: if disabled segments should not let the changes through, then we probably should implement a check for topology disconnection in similar way as `ipa topologysegment-del` does. I mean, whenever a user tries to disable a segment, the plugin should probably check whether it disconnects any of the nodes. well, I think disabling should be temporary, you want to disconnect for some time. eg for debugging, not deleting the agreement completely, I would allow this. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
On 06/17/2015 04:59 PM, Ludwig Krispenz wrote: On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. just to be clear, you have master <-> replica1 <-> replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. To be precise, my topology is as follows master <-> replica3 <-> replica2 <-> replica1 And I disabled the replica3 <-> replica2. So I expected the changes on master to be only visible on master and replica3, but actually it kept replicating to all nodes. root@f22replica1:/home/ofayans]$ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Number of entries returned 3 root@f22replica1:/home/ofayans]$ ipa topologysegment-show realm replica3-to-replica2 Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Replication agreement enabled: off It reproduces though even in a situation with the topology replica3 <-> master <-> replica1 <-> replica2 and you disable the replica1-replica2 segment on replica3 (quite expectedly) and disable one of the segments, one would expect the changes implemented on master would not be replicated to other nodes (or do I misunderstand the concept of disabling a segment?). However, in reality any changes in master do get replicated despite the segment is disabled. Is it a correct behavior? The second question is: if disabled segments should not let the changes through, then we probably should implement a check for topology disconnection in similar way as `ipa topologysegment-del` does. I mean, whenever a user tries to disable a segment, the plugin should probably check whether it disconnects any of the nodes. well, I think disabling should be temporary, you want to disconnect for some time. eg for debugging, not deleting the agreement completely, I would allow this. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. just to be clear, you have master <-> replica1 <-> replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. It reproduces though even in a situation with the topology replica3 <-> master <-> replica1 <-> replica2 and you disable the replica1-replica2 segment on replica3 (quite expectedly) and disable one of the segments, one would expect the changes implemented on master would not be replicated to other nodes (or do I misunderstand the concept of disabling a segment?). However, in reality any changes in master do get replicated despite the segment is disabled. Is it a correct behavior? The second question is: if disabled segments should not let the changes through, then we probably should implement a check for topology disconnection in similar way as `ipa topologysegment-del` does. I mean, whenever a user tries to disable a segment, the plugin should probably check whether it disconnects any of the nodes. well, I think disabling should be temporary, you want to disconnect for some time. eg for debugging, not deleting the agreement completely, I would allow this. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
On 06/17/2015 04:31 PM, Simo Sorce wrote: On Wed, 2015-06-17 at 16:15 +0200, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? and disable one of the segments, one would expect the changes implemented on master would not be replicated to other nodes (or do I misunderstand the concept of disabling a segment?). However, in reality any changes in master do get replicated despite the segment is disabled. Is it a correct behavior? The second question is: if disabled segments should not let the changes through, then we probably should implement a check for topology disconnection in similar way as `ipa topologysegment-del` does. I mean, whenever a user tries to disable a segment, the plugin should probably check whether it disconnects any of the nodes. well, I think disabling should be temporary, you want to disconnect for some time. eg for debugging, not deleting the agreement completely, I would allow this. Too dangerous, I would honestly not even offer the option to disable anything via the framework for now. +1 Anyway, if the feature does not work as expected for now, I would disable it rather than fixing, as it's not a critical functionality for alpha. Do we really want to allow an admin to cause split brains ? If an admin forgets to re-enable a segment pretty quickly you get in a very undesirable state if that segment caused a split brain. It may make sense if it were some time-based command, where you must enter a (short) time period when the segment is disabled, so that it re-enabled automatically when the window expires, but that is not something we are getting in the short term. My 2c, Simo. + 1 for implementing time-based segment disabling. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0084] Fix OTP token URI generation
On 06/17/2015 04:44 PM, Simo Sorce wrote: On Wed, 2015-06-17 at 10:26 -0400, Nathaniel McCallum wrote: Google Authenticator fails if the algorithm is not uppercase. https://fedorahosted.org/freeipa/ticket/5047 LGTM. Simo. ACK pushed to master: * 4dfa23256dc2e35480843beef92e03b1bafd578b Fix OTP token URI generation ipa-4-1: * de7aed148623075d4fda7b3ecb46344cf2589b4a Fix OTP token URI generation -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? On master. It reproduces though even in a situation with the topology replica3 <-> master <-> replica1 <-> replica2 and you disable the replica1-replica2 segment on replica3 (quite expectedly) and disable one of the segments, one would expect the changes implemented on master would not be replicated to other nodes (or do I misunderstand the concept of disabling a segment?). However, in reality any changes in master do get replicated despite the segment is disabled. Is it a correct behavior? The second question is: if disabled segments should not let the changes through, then we probably should implement a check for topology disconnection in similar way as `ipa topologysegment-del` does. I mean, whenever a user tries to disable a segment, the plugin should probably check whether it disconnects any of the nodes. well, I think disabling should be temporary, you want to disconnect for some time. eg for debugging, not deleting the agreement completely, I would allow this. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0084] Fix OTP token URI generation
On Wed, 2015-06-17 at 10:26 -0400, Nathaniel McCallum wrote: > Google Authenticator fails if the algorithm is not uppercase. > > https://fedorahosted.org/freeipa/ticket/5047 LGTM. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
On Wed, 2015-06-17 at 16:15 +0200, Ludwig Krispenz wrote: > On 06/17/2015 03:37 PM, Oleg Fayans wrote: > > Hi Ludwig, Petr, > > > > Presently I have noticed that disabling a segment, using `ipa > > topologysegment-mod realm replica1-to-replica2 > > --enabled=off` does not have effect on the way the data is replicated. > > > > I mean that if we have the following tolopogy: > > master <-> replica1 <-> replica2 > on which server did you apply the mod ? > > and disable one of the segments, one would expect the changes > > implemented on master would not be replicated to other nodes (or do I > > misunderstand the concept of disabling a segment?). However, in > > reality any changes in master do get replicated despite the segment is > > disabled. > > > > Is it a correct behavior? > > > > The second question is: if disabled segments should not let the > > changes through, then we probably should implement a check for > > topology disconnection in similar way as `ipa topologysegment-del` > > does. I mean, whenever a user tries to disable a segment, the plugin > > should probably check whether it disconnects any of the nodes. > well, I think disabling should be temporary, you want to disconnect for > some time. eg for debugging, not deleting the agreement completely, I > would allow this. Too dangerous, I would honestly not even offer the option to disable anything via the framework for now. Do we really want to allow an admin to cause split brains ? If an admin forgets to re-enable a segment pretty quickly you get in a very undesirable state if that segment caused a split brain. It may make sense if it were some time-based command, where you must enter a (short) time period when the segment is disabled, so that it re-enabled automatically when the window expires, but that is not something we are getting in the short term. My 2c, Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0084] Fix OTP token URI generation
Google Authenticator fails if the algorithm is not uppercase. https://fedorahosted.org/freeipa/ticket/5047From 2d266d7f17ca5450253d7bcc2a2fe5cf4a5ed327 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum Date: Wed, 17 Jun 2015 10:21:55 -0400 Subject: [PATCH] Fix OTP token URI generation Google Authenticator fails if the algorithm is not uppercase. https://fedorahosted.org/freeipa/ticket/5047 --- ipalib/plugins/otptoken.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py index 867659ec2a867b2dba79922a4e98b7b6254e81bf..294c1c54afdfa6a13d37766d6851affa44ece60c 100644 --- a/ipalib/plugins/otptoken.py +++ b/ipalib/plugins/otptoken.py @@ -325,7 +325,7 @@ class otptoken_add(LDAPCreate): args['issuer'] = issuer args['secret'] = base64.b32encode(entry_attrs['ipatokenotpkey']) args['digits'] = entry_attrs['ipatokenotpdigits'] -args['algorithm'] = entry_attrs['ipatokenotpalgorithm'] +args['algorithm'] = entry_attrs['ipatokenotpalgorithm'].upper() if options['type'] == 'totp': args['period'] = entry_attrs['ipatokentotptimestep'] elif options['type'] == 'hotp': -- 2.4.3 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] disabling topology segment has no effect
On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 on which server did you apply the mod ? and disable one of the segments, one would expect the changes implemented on master would not be replicated to other nodes (or do I misunderstand the concept of disabling a segment?). However, in reality any changes in master do get replicated despite the segment is disabled. Is it a correct behavior? The second question is: if disabled segments should not let the changes through, then we probably should implement a check for topology disconnection in similar way as `ipa topologysegment-del` does. I mean, whenever a user tries to disable a segment, the plugin should probably check whether it disconnects any of the nodes. well, I think disabling should be temporary, you want to disconnect for some time. eg for debugging, not deleting the agreement completely, I would allow this. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 879 Verify replication topology for a suffix
On 06/17/2015 02:15 PM, Ludwig Krispenz wrote:
On 06/17/2015 02:04 PM, Petr Vobornik wrote:
With patch "878 topology: check topology in ipa-replica-manage del"
we can use the same logic for POC of
ipa topologysuffix-verify
command.
Checks done:
1. check if the topology is not disconnected. In other words if
there are replication paths between all servers.
2. check if servers don't have more than a recommended number of
replication agreements (which was set to 4)
I'm not sure what else we want to test but these two seemed as low
hanging fruit.
don't know how hard it is, but I had thought of calculating something
like a "degree of connectivity", eg to find single points of failure.
In a topology A <--> B <--> C <--> D, if B or C are down (temporariliy)
the topology is disconnected. If extending to
A <--> B <--> C <--> D <--> A one server con be taken offline, so a
brute force would be to check for each server if it could be removed
The original POC(attached) of the graph traversal did such brute force
check(only one server removed at a time). In other words, it's easy.
Computing indegree and outdegree of each node is easy as well.
Additional checks can be also added later.
https://fedorahosted.org/freeipa/ticket/4302
--
Petr Vobornik
#!/usr/bin/python
# Python Breath First Search
#
# Intendted for FreeIPA topology check
# structure of segment:
#
# edges:
#
# topologysegment
# - cn
# - iparepltoposegmentrightnode
# - iparepltoposegmentdirection
# - iparepltoposegmentleftnode
#
#
# vertices:
# masters
# - cn
class Graph():
"""
Simple graph structure with vertices, edges and adjectency list
"""
vertices = set()
edges = []
adj = dict()
def add_vertex(self, vertex):
self.vertices.add(vertex)
self.adj[vertex] = []
def add_edge(self, left, right):
self.edges.append((left, right))
self.adj[left].append(right)
def remove_vertex(self, vertex):
self.vertices.remove(vertex)
# delete adjacencies
del self.adj[vertex]
for key, adj in self.adj.iteritems():
adj[:] = [v for v in adj if v != vertex]
# delete edges
edges = [e for e in self.edges if e[0] != vertex and e[1] != vertex]
self.edges[:] = edges
def bfs(graph, start=None):
if not start:
start = list(graph.vertices)[0]
visited = set()
queue = [start]
while queue:
vertex = queue.pop(0)
if vertex not in visited:
visited.add(vertex)
queue.extend(set(graph.adj.get(vertex, [])) - visited)
return visited
def make_graph(servers, segments):
graph = Graph()
for s in servers:
graph.add_vertex(s)
for s in segments:
direction = s[2]
if direction == 'both':
graph.add_edge(s[0], s[1])
graph.add_edge(s[1], s[0])
if direction == 'left-right':
graph.add_edge(s[0], s[1])
if direction == 'right-left':
graph.add_edge(s[1], s[0])
return graph
def print_results(errors):
if not errors:
print "Initial topology is in order. All servers can replicate"
else:
print "Initial topology has some errors"
print_errors(errors)
def print_results_removed(removed, errors):
if not errors:
print removed + " is safe to remove"
else:
print removed + " is not safe to remove"
print_errors(errors)
def print_errors(errors):
for e in errors:
print e[0] + " can't contact: " + ', '.join(e[2])
def iterate_start(graph):
servers = list(graph.vertices)
servers.sort()
e = []
for s in servers:
visited = bfs(graph, s)
not_visited = set(servers) - visited
if not_visited:
e.append((s, visited, not_visited))
return e
def test():
servers = {'a', 'b', 'c', 'd'}
# left, right, direction
segments = [
('a', 'b', 'both'),
('b', 'd', 'both'),
('a', 'd', 'right-left'),
('c', 'd', 'right-left'),
('c', 'd', 'left-right'),
]
g = make_graph(servers, segments)
visited = bfs(g)
not_visited = servers - visited
print ""
print "= all servers ==="
errors = iterate_start(g)
print_results(errors)
for s in servers:
g = make_graph(servers, segments)
g.remove_vertex(s)
print ""
print "= removing: " + s + " ==="
errors = iterate_start(g)
print_results_removed(s, errors)
test()
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] disabling topology segment has no effect
Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master <-> replica1 <-> replica2 and disable one of the segments, one would expect the changes implemented on master would not be replicated to other nodes (or do I misunderstand the concept of disabling a segment?). However, in reality any changes in master do get replicated despite the segment is disabled. Is it a correct behavior? The second question is: if disabled segments should not let the changes through, then we probably should implement a check for topology disconnection in similar way as `ipa topologysegment-del` does. I mean, whenever a user tries to disable a segment, the plugin should probably check whether it disconnects any of the nodes. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] update on freeipa 4.2 pki issues
On Wed, Jun 17, 2015 at 01:43:03PM +0200, thierry bordaz wrote: > On 06/17/2015 01:09 PM, Fraser Tweedale wrote: > >On Wed, Jun 17, 2015 at 12:28:33PM +0200, thierry bordaz wrote: > >>Hello Fraser, > >> > >>The schema is propagated on all replica. So if you update the > >>schema, the updates will be eventually present everywhere. > >>There is two ways to update the schema. > >> > >> * online update (prefered), you simply do a ldapmodify on > >>'cn=schema' adding/updating attributetypes/objectclasses > >> * offline. You stop a replica/master, update the schema files, > >>start the server. This is not the prefered solution because > >>depending on version of DS it can take more time to detect the > >>new schema and propagated it. > >> > >>Do you know how CS schema upgrade will be done (online/offline) ? > >>Is it the new definitions > >>http://www.freeipa.org/page/V4/Certificate_Profiles#Schema ? > >> > >>Thanks > >>thierry > >> > >Thanks Thierry for your detailed reply! The schema is actually > >defined by Dogtag and is used only by the Dogtag directory tree > >(under DN o=ipa-ca). I will do an online update. > > > >Cheers, > >Fraser > > Hi Fraser, > > The schema is per DS instance so all suffixes will share the same schema. > Now only o=ipaca entries will use the new definitions. > > During upgrade, if you do online update of 'cn=schema', the next update (on > main sufix or o=ipaca) will trigger the replication of those definitions. > The exact replication scenario of the schema depends on the version of DS > but the definitions should eventually be present on all instances. > You may check if the definitions are propagated on each instance with > 'ldapsearch -h -p 389 -D "cn=directory manager" -w ... -b "cn=schema" > attributetypes objectclasses. > > I am not sure what is the 'Migrate file-base profile' scenario. Is it an > import (ldif2db) of new profiles with entries containing new schema > defintions ? > It is not a direct import via ldif2db(8), but in essence, yes - new entries are added which contain attributes defined by in the new schema. Cheers, Fraser > thanks > thierry > > > >>On 06/17/2015 07:52 AM, Martin Kosek wrote: > >>>On 06/16/2015 06:39 PM, Fraser Tweedale wrote: > I fixed several issues which broke Dogtag upgrades involving > particular versions; these will be in the next release. > > I haven't yet gotten to to the reported failure running > ipa-replica-upgrade on a replica (but I haven't forgotten about it > either.) This is the only issue affecting *fresh installs* that I > am aware of. If you know of others please let me know! > > The remaining Dogtag-related upgrade problem is caused by new DS > schema on the Dogtag side, which is used for LDAP-based profiles. > There is not yet an automatic schema upgrade facility for Dogtag, so > the new schema was missing. > > The planned approach is: > > - Either Dogtag or FreeIPA will add the new CS schema on upgrade. > (Eventually Dogtag will need to manage its own schema updates but > right now there is no facility, and the new schema is only used by > IPA.) > >>>If possible, I would prefer Dogtag to update the schema the best it can, > >>>otherwise there is a risk of collisions or upgrade breakages if FreeIPA > >>>starts updating Dogtag internals. > >>> > - Migrate file-based profiles into LDAP during IPA upgrade. But for > this to work, I need to make sure that if new schema is added, > then entries that use the new schema, replication to instances > that did not yet have the new schema will not break. Anyone who > knows LDAP better than me, please share your knowledge! > >>>Shouldn't schema just replicate, when the first FreeIPA+CS is upgraded? > >>>CCing Thierry for reference, he had a lot of fun with schema upgrades. > >>> > - If my assumptions about replication are wrong, the best approach > will probably be to have the administrator perform profile > migration (via a script) as a later task, after all replicas have > been upgraded. > >>>Not a fan of this, FreeIPA upgrades should be ideally automatic and > >>>straightforward. So far we did not have problems with automatic upgrades > >>>(well, except Dogtag9->Dogtag10 upgrade - I would prefer not to have such > >>>situation again). > >>> > >>>Thanks for updates! > >>>Martin > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0266] ipa-ca-install fix: reconnect ldap2 after DS restart
https://fedorahosted.org/freeipa/ticket/5064
Patch attached.
--
Martin Basti
From eabe6829c0c8c0c855cc4606384897ed908b40d5 Mon Sep 17 00:00:00 2001
From: Martin Basti
Date: Wed, 17 Jun 2015 14:19:25 +0200
Subject: [PATCH] ipa-ca-install fix: reconnect ldap2 after DS restart
https://fedorahosted.org/freeipa/ticket/5064
---
ipaserver/install/ca.py | 8
1 file changed, 8 insertions(+)
diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py
index 1ef8b2c418bdc09e7c9cb4ec70d7d8653b662e32..173befb3773e1d50dee624647e43f3563ca6ae87 100644
--- a/ipaserver/install/ca.py
+++ b/ipaserver/install/ca.py
@@ -122,8 +122,16 @@ def install_step_0(standalone, replica_config, options):
postinstall = True
else:
postinstall = False
+
+if standalone:
+api.Backend.ldap2.disconnect()
+
ca = cainstance.install_replica_ca(replica_config, postinstall)
+if standalone:
+api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
+ bind_pw=dm_password)
+
if not standalone:
ca.configure_certmonger_renewal()
ca.import_ra_cert(replica_config.dir + "/ra.p12")
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 879 Verify replication topology for a suffix
On 06/17/2015 02:04 PM, Petr Vobornik wrote: With patch "878 topology: check topology in ipa-replica-manage del" we can use the same logic for POC of ipa topologysuffix-verify command. Checks done: 1. check if the topology is not disconnected. In other words if there are replication paths between all servers. 2. check if servers don't have more than a recommended number of replication agreements (which was set to 4) I'm not sure what else we want to test but these two seemed as low hanging fruit. don't know how hard it is, but I had thought of calculating something like a "degree of connectivity", eg to find single points of failure. In a topology A <--> B <--> C <--> D, if B or C are down (temporariliy) the topology is disconnected. If extending to A <--> B <--> C <--> D <--> A one server con be taken offline, so a brute force would be to check for each server if it could be removed Additional checks can be also added later. https://fedorahosted.org/freeipa/ticket/4302 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 879 Verify replication topology for a suffix
With patch "878 topology: check topology in ipa-replica-manage del" we
can use the same logic for POC of
ipa topologysuffix-verify
command.
Checks done:
1. check if the topology is not disconnected. In other words if
there are replication paths between all servers.
2. check if servers don't have more than a recommended number of
replication agreements (which was set to 4)
I'm not sure what else we want to test but these two seemed as low
hanging fruit. Additional checks can be also added later.
https://fedorahosted.org/freeipa/ticket/4302
--
Petr Vobornik
From 60360ec4c1c836859ff9b79ecc5670f5ea47fc5a Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Wed, 17 Jun 2015 13:50:32 +0200
Subject: [PATCH] Verify replication topology for a suffix
Checks done:
1. check if the topology is not disconnected. In other words if
there are replication paths between all servers.
2. check if servers don't have more than a recommended number of
replication agreements(4)
https://fedorahosted.org/freeipa/ticket/4302
---
API.txt| 5 +++
VERSION| 4 +--
ipalib/constants.py| 4 +++
ipalib/plugins/topology.py | 83 ++
4 files changed, 94 insertions(+), 2 deletions(-)
diff --git a/API.txt b/API.txt
index c7f02b9e6d120348ee90a3e6ff34646728e2b332..f072210230ffc30c0995945a423565ab06b87675 100644
--- a/API.txt
+++ b/API.txt
@@ -4911,6 +4911,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: topologysuffix_verify
+args: 1,1,1
+arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True)
+option: Str('version?', exclude='webui')
+output: Output('result', None, None)
command: trust_add
args: 1,13,3
arg: Str('cn', attribute=True, cli_name='realm', multivalue=False, primary_key=True, required=True)
diff --git a/VERSION b/VERSION
index f38b4946553aecea1a458f9cf57387e93929fef5..fd3c76446ec5b180356da03ea916df09abb7b028 100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=134
-# Last change: jcholast - User life cycle: provide preserved user virtual attribute
+IPA_API_VERSION_MINOR=135
+# Last change: pvoborni: add topologysuffix-verify command
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 330f9df74e604d9875a7a9624312ea8944d5..a062505c349436332d430af4fd29c76d20c85343 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -170,6 +170,10 @@ DEFAULT_CONFIG = (
# KRA plugin
('kra_host', FQDN), # Set in Env._finalize_core()
+# Topology plugin
+('recommended_max_agmts', 4), # Recommended maximum number of replication
+ # agreements
+
# Special CLI:
('prompt_all', False),
('interactive', True),
diff --git a/ipalib/plugins/topology.py b/ipalib/plugins/topology.py
index 494d3bb0a564e5c8ef3d7c2af50dbf1e83a36e1f..49060d672b6522277014b0b9c1e0ecb92e091077 100644
--- a/ipalib/plugins/topology.py
+++ b/ipalib/plugins/topology.py
@@ -10,6 +10,7 @@ from ipalib.plugins.baseldap import (
LDAPRetrieve)
from ipalib import _, ngettext
from ipalib import output
+from ipalib.util import create_topology_graph, get_topology_connection_errors
from ipapython.dn import DN
@@ -401,3 +402,85 @@ class topologysuffix_mod(LDAPUpdate):
@register()
class topologysuffix_show(LDAPRetrieve):
__doc__ = _('Show managed suffix.')
+
+
+@register()
+class topologysuffix_verify(LDAPQuery):
+__doc__ = _('''
+Verify replication topology for suffix.
+
+Checks done:
+ 1. check if a topology is not disconnected. In other words if there are
+ replication paths between all servers.
+ 2. check if servers don't have more than the recommended number of
+ replication agreements
+''')
+
+def execute(self, *keys, **options):
+
+validate_domain_level(self.api)
+
+masters = self.api.Command.server_find('', sizelimit=0)['result']
+segments = self.api.Command.topologysegment_find(
+keys[0], sizelimit=0)['result']
+graph = create_topology_graph(masters, segments)
+master_cns = [m['cn'][0] for m in masters]
+master_cns.sort()
+
+# check if each master can contact others
+connect_errors = get_topology_connection_errors(graph)
+
+# check if suggested maximum number of agreements per replica
+max_agmts_errors = []
+for m in master_cns:
+# chosen direction doesn't matter much given that 'both' is the
+# only allowed direction
+suppliers = graph.get_tails(m)
+if le
[Freeipa-devel] [PATCH] 878 topology: check topology in ipa-replica-manage del
ipa-replica-manage del now:
- checks the whole current topology(before deletion), reports issues
- simulates deletion of server and checks the topology again, reports issues
Asks admin if he wants to continue with the deletion if any errors are
found.
https://fedorahosted.org/freeipa/ticket/4302
--
Petr Vobornik
From 892672e4841b6b143c953fca0f221c34e146a6ba Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Wed, 17 Jun 2015 13:33:24 +0200
Subject: [PATCH] topology: check topology in ipa-replica-manage del
ipa-replica-manage del now:
- checks the whole current topology(before deletion), reports issues
- simulates deletion of server and checks the topology again, reports issues
Asks admin if he wants to continue with the deletion if any errors are found.
https://fedorahosted.org/freeipa/ticket/4302
---
install/tools/ipa-replica-manage | 41
ipalib/util.py | 48
ipapython/graph.py | 69
3 files changed, 152 insertions(+), 6 deletions(-)
create mode 100644 ipapython/graph.py
diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index 1b93166bce5c1d1fa6cba41cd87bc0833b2efe57..6442a68c8dbc1842ba3ff9ae80f63b688ab506b0 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -35,6 +35,7 @@ from ipaserver.plugins import ldap2
from ipapython import version, ipaldap
from ipalib import api, errors, util
from ipalib.constants import CACERT
+from ipalib.util import create_topology_graph, get_topology_connection_errors
from ipapython.ipa_log_manager import *
from ipapython.dn import DN
from ipapython.config import IPAOptionParser
@@ -562,11 +563,39 @@ def check_last_link(delrepl, realm, dirman_passwd, force):
return None
def check_last_link_managed(api, masters, hostname, force):
-# segments = api.Command.topologysegment_find(u'realm', sizelimit=0).get('result')
-# replica_names = [m.single_value('cn') for m in masters]
-# orphaned = []
-# TODO add proper graph traversing algorithm here
-return None
+"""
+Check if 'hostname' is safe to delete.
+
+:returns: list of errors after future deletion
+"""
+
+segments = api.Command.topologysegment_find(u'realm', sizelimit=0).get('result')
+graph = create_topology_graph(masters, segments)
+
+# check topology before removal
+orig_errors = get_topology_connection_errors(graph)
+if orig_errors:
+print "Current topology is disconnected:"
+print_connect_errors(orig_errors)
+
+# after removal
+graph.remove_vertex(hostname)
+new_errors = get_topology_connection_errors(graph)
+if new_errors:
+print "Topology after removal of %s will be disconnected:" % hostname
+print_connect_errors(new_errors)
+
+if orig_errors or new_errors:
+if not force and not ipautil.user_input("Continue to delete?", False):
+sys.exit("Aborted")
+
+return new_errors
+
+def print_connect_errors(errors):
+for error in errors:
+msg = "Server %(srv)s can't contact servers: %(replicas)s"
+msg = msg % {'srv': error[0], 'replicas': ', '.join(error[2])}
+print msg
def enforce_host_existence(host, message=None):
if host is not None and not ipautil.host_exists(host):
@@ -676,7 +705,7 @@ def del_master_managed(realm, hostname, options):
masters = api.Command.server_find('', sizelimit=0)['result']
# 3. Check topology
-orphans = check_last_link_managed(api, masters, hostname, options.force)
+check_last_link_managed(api, masters, hostname, options.force)
# 4. Check that we are not leaving the installation without CA and/or DNS
#And pick new CA master.
diff --git a/ipalib/util.py b/ipalib/util.py
index 44478a2d1eed6d66e54949e0840e6d62310830c5..6f7d4a67174aa2f3df8a92f1a25d20a16d3b3f03 100644
--- a/ipalib/util.py
+++ b/ipalib/util.py
@@ -42,6 +42,7 @@ from ipalib.text import _
from ipapython.ssh import SSHPublicKey
from ipapython.dn import DN, RDN
from ipapython.dnsutil import DNSName
+from ipapython.graph import Graph
def json_serialize(obj):
@@ -780,3 +781,50 @@ def validate_idna_domain(value):
if error:
raise ValueError(error)
+
+
+def create_topology_graph(masters, segments):
+"""
+Create an oriented graph from topology defined by masters and segments.
+
+:param masters
+:param segments
+:returns: Graph
+"""
+graph = Graph()
+
+for m in masters:
+graph.add_vertex(m['cn'][0])
+
+for s in segments:
+direction = s['iparepltoposegmentdirection'][0]
+left = s['iparepltoposegmentleftnode'][0]
+right = s['iparepltoposegmentrightnode'][0]
+if direction == u'both':
+graph.add_edge(left, right)
+graph.add_edge(right, left)
+if direction == u'left-right':
+graph.add_edge(left, right)
+
Re: [Freeipa-devel] update on freeipa 4.2 pki issues
On 06/17/2015 01:09 PM, Fraser Tweedale wrote: On Wed, Jun 17, 2015 at 12:28:33PM +0200, thierry bordaz wrote: Hello Fraser, The schema is propagated on all replica. So if you update the schema, the updates will be eventually present everywhere. There is two ways to update the schema. * online update (prefered), you simply do a ldapmodify on 'cn=schema' adding/updating attributetypes/objectclasses * offline. You stop a replica/master, update the schema files, start the server. This is not the prefered solution because depending on version of DS it can take more time to detect the new schema and propagated it. Do you know how CS schema upgrade will be done (online/offline) ? Is it the new definitions http://www.freeipa.org/page/V4/Certificate_Profiles#Schema ? Thanks thierry Thanks Thierry for your detailed reply! The schema is actually defined by Dogtag and is used only by the Dogtag directory tree (under DN o=ipa-ca). I will do an online update. Cheers, Fraser Hi Fraser, The schema is per DS instance so all suffixes will share the same schema. Now only o=ipaca entries will use the new definitions. During upgrade, if you do online update of 'cn=schema', the next update (on main sufix or o=ipaca) will trigger the replication of those definitions. The exact replication scenario of the schema depends on the version of DS but the definitions should eventually be present on all instances. You may check if the definitions are propagated on each instance with 'ldapsearch -h -p 389 -D "cn=directory manager" -w ... -b "cn=schema" attributetypes objectclasses. I am not sure what is the 'Migrate file-base profile' scenario. Is it an import (ldif2db) of new profiles with entries containing new schema defintions ? thanks thierry On 06/17/2015 07:52 AM, Martin Kosek wrote: On 06/16/2015 06:39 PM, Fraser Tweedale wrote: I fixed several issues which broke Dogtag upgrades involving particular versions; these will be in the next release. I haven't yet gotten to to the reported failure running ipa-replica-upgrade on a replica (but I haven't forgotten about it either.) This is the only issue affecting *fresh installs* that I am aware of. If you know of others please let me know! The remaining Dogtag-related upgrade problem is caused by new DS schema on the Dogtag side, which is used for LDAP-based profiles. There is not yet an automatic schema upgrade facility for Dogtag, so the new schema was missing. The planned approach is: - Either Dogtag or FreeIPA will add the new CS schema on upgrade. (Eventually Dogtag will need to manage its own schema updates but right now there is no facility, and the new schema is only used by IPA.) If possible, I would prefer Dogtag to update the schema the best it can, otherwise there is a risk of collisions or upgrade breakages if FreeIPA starts updating Dogtag internals. - Migrate file-based profiles into LDAP during IPA upgrade. But for this to work, I need to make sure that if new schema is added, then entries that use the new schema, replication to instances that did not yet have the new schema will not break. Anyone who knows LDAP better than me, please share your knowledge! Shouldn't schema just replicate, when the first FreeIPA+CS is upgraded? CCing Thierry for reference, he had a lot of fun with schema upgrades. - If my assumptions about replication are wrong, the best approach will probably be to have the administrator perform profile migration (via a script) as a later task, after all replicas have been upgraded. Not a fan of this, FreeIPA upgrades should be ideally automatic and straightforward. So far we did not have problems with automatic upgrades (well, except Dogtag9->Dogtag10 upgrade - I would prefer not to have such situation again). Thanks for updates! Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0252-0253] DNSSEC: allow to move DNSSEC key master to another IPA server
On 17/06/15 13:26, Petr Spacek wrote:
On 16.6.2015 15:40, Martin Basti wrote:
On 05/06/15 12:54, Petr Spacek wrote:
On 20.5.2015 18:00, Martin Basti wrote:
This patch allows to disable DNSSEC key master on IPA server, or replace
current DNSSEC key master with another IPA server.
Only for master branch.
https://fedorahosted.org/freeipa/ticket/4657
Patches attached.
NACK. This happens on DNSSEC key master:
$ ipa-dns-install --disable-dnssec-master
Do you want to disable current DNSSEC key master? [no]: yes
Unexpected error - see /var/log/ipaserver-install.log for details:
TypeError: sequence item 0: expected string, DNSName found
2015-06-05T10:52:35Z DEBUG File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line
733, in run_script
return_value = main_function()
File "/sbin/ipa-dns-install", line 128, in main
dns_installer.disable_dnssec_master(options.unattended)
File "/usr/lib/python2.7/site-packages/ipaserver/install/dns.py", line 112,
in disable_dnssec_master
", ".join(dnssec_zones))
2015-06-05T10:52:35Z DEBUG The ipa-dns-install command failed, exception:
TypeError: sequence item 0: expected string, DNSName found
Updated patches attached.
Due new installers, more changes were required.
Sorry, NACK, I'm not able to apply this patch set to current master
(69607250b9762a6c9b657dd31653b03d54a7b411).
Rebased patches attached.
--
Martin Basti
From 5f19362a7aa18e0a19f6871249e4a40d6052 Mon Sep 17 00:00:00 2001
From: Martin Basti
Date: Wed, 13 May 2015 14:45:32 +0200
Subject: [PATCH 1/2] DNSSEC: allow to disable/replace DNSSEC key master
This commit allows to replace or disable DNSSEC key master
Replacing DNSSEC master requires to copy kasp.db file manually by user
ipa-dns-install:
--disable-dnssec-master DNSSEC master will be disabled
--replace-dnssec-master=IPA_SERVER DNSSEC master will be replaced, by
IPA_SERVER (required to rerun ipa-dns-install wit appropriate options).
--dnssec-master --kasp-db=FILE This configure new DNSSEC master server, kasp.db from old server is required
https://fedorahosted.org/freeipa/ticket/4657
---
install/tools/ipa-dns-install | 18 +++
ipaplatform/base/paths.py | 1 +
ipaserver/install/dns.py | 240 -
ipaserver/install/odsexporterinstance.py | 12 +-
ipaserver/install/opendnssecinstance.py| 69 +++--
ipaserver/install/server/install.py| 23 +++
ipaserver/install/server/replicainstall.py | 31 +++-
7 files changed, 373 insertions(+), 21 deletions(-)
diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install
index fd9311657e813988310db2be604ca68d26936af5..0f640c3e85b1a5eb717be5082c2fdf030ec4eec5 100755
--- a/install/tools/ipa-dns-install
+++ b/install/tools/ipa-dns-install
@@ -61,6 +61,17 @@ def parse_options():
help="DNS zone manager e-mail address. Defaults to hostmaster@DOMAIN")
parser.add_option("-U", "--unattended", dest="unattended", action="store_true",
default=False, help="unattended installation never prompts the user")
+parser.add_option("--disable-dnssec-master", dest="disable_dnssec_master",
+ action="store_true", default=False, help="Disable the "
+ "DNSSEC master on this server")
+parser.add_option("--replace-dnssec-master", dest="replace_dnssec_master",
+ type="string", metavar="IPA_DNS_SERVER_HOSTNAME",
+ action="store", help="Replace the current DNSSEC master "
+ "with the specified IPA server")
+parser.add_option("--kasp-db", dest="kasp_db_file", type="string",
+ metavar="FILE", action="store", help="Copy OpenDNSSEC "
+ "metadata from the specified file (will not create a new "
+ "kasp.db file)")
options, args = parser.parse_args()
safe_options = parser.get_safe_opts(options)
@@ -70,10 +81,17 @@ def parse_options():
elif options.reverse_zones and options.no_reverse:
parser.error("You cannot specify a --reverse-zone option together with --no-reverse")
+if options.disable_dnssec_master and options.replace_dnssec_master:
+parser.error("You cannot specify a --disable-dnssec-master option "
+ "together with --replace-dnssec-master")
+
if options.unattended:
if not options.forwarders and not options.no_forwarders:
parser.error("You must specify at least one --forwarder option or --no-forwarders option")
+if options.kasp_db_file and not ipautil.file_exists(options.kasp_db_file):
+parser.error("File %s does not exist" % options.kasp_db_file)
+
if options.dm_password:
print ("WARNING: Option -p/--ds-password is deprecated "
"and should not be used anymore.")
diff --git a/ipaplatform/base/paths.py b/ipaplatform/b
Re: [Freeipa-devel] [PATCHES 0252-0253] DNSSEC: allow to move DNSSEC key master to another IPA server
On 16.6.2015 15:40, Martin Basti wrote: > On 05/06/15 12:54, Petr Spacek wrote: >> On 20.5.2015 18:00, Martin Basti wrote: >>> This patch allows to disable DNSSEC key master on IPA server, or replace >>> current DNSSEC key master with another IPA server. >>> >>> Only for master branch. >>> >>> https://fedorahosted.org/freeipa/ticket/4657 >>> >>> Patches attached. >> NACK. This happens on DNSSEC key master: >> $ ipa-dns-install --disable-dnssec-master >> >> Do you want to disable current DNSSEC key master? [no]: yes >> Unexpected error - see /var/log/ipaserver-install.log for details: >> TypeError: sequence item 0: expected string, DNSName found >> >> 2015-06-05T10:52:35Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line >> 733, in run_script >> return_value = main_function() >> >>File "/sbin/ipa-dns-install", line 128, in main >> dns_installer.disable_dnssec_master(options.unattended) >> >>File "/usr/lib/python2.7/site-packages/ipaserver/install/dns.py", line >> 112, >> in disable_dnssec_master >> ", ".join(dnssec_zones)) >> >> 2015-06-05T10:52:35Z DEBUG The ipa-dns-install command failed, exception: >> TypeError: sequence item 0: expected string, DNSName found >> > Updated patches attached. > > Due new installers, more changes were required. Sorry, NACK, I'm not able to apply this patch set to current master (69607250b9762a6c9b657dd31653b03d54a7b411). -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] update on freeipa 4.2 pki issues
On Wed, Jun 17, 2015 at 12:28:33PM +0200, thierry bordaz wrote: > Hello Fraser, > >The schema is propagated on all replica. So if you update the >schema, the updates will be eventually present everywhere. >There is two ways to update the schema. > > * online update (prefered), you simply do a ldapmodify on >'cn=schema' adding/updating attributetypes/objectclasses > * offline. You stop a replica/master, update the schema files, >start the server. This is not the prefered solution because >depending on version of DS it can take more time to detect the >new schema and propagated it. > >Do you know how CS schema upgrade will be done (online/offline) ? >Is it the new definitions >http://www.freeipa.org/page/V4/Certificate_Profiles#Schema ? > >Thanks >thierry > Thanks Thierry for your detailed reply! The schema is actually defined by Dogtag and is used only by the Dogtag directory tree (under DN o=ipa-ca). I will do an online update. Cheers, Fraser > On 06/17/2015 07:52 AM, Martin Kosek wrote: > >On 06/16/2015 06:39 PM, Fraser Tweedale wrote: > >>I fixed several issues which broke Dogtag upgrades involving > >>particular versions; these will be in the next release. > >> > >>I haven't yet gotten to to the reported failure running > >>ipa-replica-upgrade on a replica (but I haven't forgotten about it > >>either.) This is the only issue affecting *fresh installs* that I > >>am aware of. If you know of others please let me know! > >> > >>The remaining Dogtag-related upgrade problem is caused by new DS > >>schema on the Dogtag side, which is used for LDAP-based profiles. > >>There is not yet an automatic schema upgrade facility for Dogtag, so > >>the new schema was missing. > >> > >>The planned approach is: > >> > >>- Either Dogtag or FreeIPA will add the new CS schema on upgrade. > >> (Eventually Dogtag will need to manage its own schema updates but > >> right now there is no facility, and the new schema is only used by > >> IPA.) > > > >If possible, I would prefer Dogtag to update the schema the best it can, > >otherwise there is a risk of collisions or upgrade breakages if FreeIPA > >starts updating Dogtag internals. > > > >>- Migrate file-based profiles into LDAP during IPA upgrade. But for > >> this to work, I need to make sure that if new schema is added, > >> then entries that use the new schema, replication to instances > >> that did not yet have the new schema will not break. Anyone who > >> knows LDAP better than me, please share your knowledge! > > > >Shouldn't schema just replicate, when the first FreeIPA+CS is upgraded? > >CCing Thierry for reference, he had a lot of fun with schema upgrades. > > > >> > >>- If my assumptions about replication are wrong, the best approach > >> will probably be to have the administrator perform profile > >> migration (via a script) as a later task, after all replicas have > >> been upgraded. > > > >Not a fan of this, FreeIPA upgrades should be ideally automatic and > >straightforward. So far we did not have problems with automatic upgrades > >(well, except Dogtag9->Dogtag10 upgrade - I would prefer not to have such > >situation again). > > > >Thanks for updates! > >Martin > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] user deletion in offline mode does not get replicated after node recovery
Hi Ludwig, On 06/17/2015 11:06 AM, Ludwig Krispenz wrote: Hi Oleg, can you give a bit more info on the scenarios when this happens. Always or is it a timing problem ? I guess it is a timing problem. It happened yesterday, today I was unable to reproduce this. The scenario is very simple: create a user1, make sure it's there turn off a replica, then create another user on master and delete user1 on master, then turn replica back on. I still have an infrastructure with 2 replicas having a user that was deleted on master. Now all the user (and other data) manipulations on this very setup work as intended. Ludwig On 06/16/2015 07:02 PM, thierry bordaz wrote: Hello On Master: User 'onmaster' was deleted [16/Jun/2015:10:16:45 -0400] conn=402 op=19 SRCH base="cn=otp,dc=bagam,dc=net" scope=1 filter="(&(objectClass=ipatoken)(ipatokenOwner=uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net))" attrs="ipatokenNotAfter description ipatokenOwner objectClass ipatokenDisabled ipatokenVendor managedBy ipatokenModel ipatokenNotBefore ipatokenUniqueID ipatokenSerial" [16/Jun/2015:10:16:45 -0400] conn=402 op=19 RESULT err=0 tag=101 nentries=0 etime=0 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:16:45 -0400] conn=402 op=21 UNBIND [16/Jun/2015:10:16:45 -0400] conn=402 op=21 fd=120 closed - U1 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 RESULT err=0 tag=107 nentries=0 etime=0 csn=55802fcf00030004 Replication agreement failed to replicate it to the replica2 [16/Jun/2015:10:18:36 -0400] NSMMReplicationPlugin - agmt="cn=f22master.bagam.net-to-f22replica2.bagam.net" (f22replica2:389): Consumer failed to replay change (uniqueid b8242e18-143111e5-b1d0d0c3-ae5854ff, CSN 55802fcf00030004): Operations error (1). Will retry later. On replica2: The replicated operation failed [16/Jun/2015:10:18:27 -0400] conn=8 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=5 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [16/Jun/2015:10:18:27 -0400] conn=8 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 because of DB failures to update. The failures were E_AGAIN or E_DB_DEADLOCK. In such situation, DS retries after a small delay. The problem is that it retried 50 times without success. [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=55802fcf00030004) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (55802fcf00030004); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net (uniqid: b8242e18-143111e5-b1d0d0c3-ae5854ff, optype: 32) to changelog csn 55802fcf00030004 [16/Jun/2015:10:18:34 -0400] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code but did not set SLAPI_RESULT_CODE The MAIN issue here is that replica2 successfully applied others updates after 55802fcf00030004 from the same replica (e.g csn=55802fcf00040004) I do not know if master was able to detect this failure and to replay this update. but I am afraid it did not !! It is looking like you hit https://fedorahosted.org/389/ticket/47788 Is it possible to access your VM ? [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 [16/Jun/2015:10:18:35 -0400] conn=8 op=7 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:36 -0400] conn=8 op=7 RESULT err=0 tag=103 nentries=0 etime=1 csn=55802fcf00040004 [16/Jun/2015:10:18:36 -0400] conn=8 op=8 DEL dn="cn=onmaster,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=8 RESULT err=0 tag=107 nentries=0 etime=1 csn=55802fcf00070004 [16/Jun/2015:10:18:37 -0400] conn=8 op=9 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=9 RESULT err=0 tag=103 nentries=0 etime=0 csn=55802fd6 On 06/16/2015 04:49 PM, Oleg Fayans wrote: Hi all, I've bumped into a strange problem with only a part of changes implemented on master during replica outage get replicated after replica recovery. Namely: when I delete an existing user on the master while the node is offline, these changes do not get to the node when it's back online.
Re: [Freeipa-devel] IPA Python API
On 17.6.2015 07:24, Jan Cholasta wrote:
> Dne 16.6.2015 v 20:29 Drew Erny napsal(a):
>> Hi, All,
>>
>> I'm using the IPA Python API to write the Community Portal. Most of the
>> documentation for using the IPA Python API is targeted a plugin authors,
>> and this isn't a plugin for (what I think are) good reasons. I'm doing
>>
>> # in the main program
>> import api from ipalib
>> api.bootstrap(context="client")
>> api.finalize()
>> api.Backend.rpcclient.connect()
>
> Call
>
>
> api.Backend.rpcclient.connect(ccache=krbV.default_context().default_ccache())
>
> to make the problem go away.
Is there a simple way how to get a reasonable error message ('not connected to
IPA server' or so) here?
Calling commands from Python should not be that hard to debug :-)
Petr^2 Spacek
>> # and then, inside of a separate class
>> api.Command.stageuser_add(...)
>>
>> Which is how doc/examples/python-api.py shows it.
>>
>> However, calling api.Command.stageuser_add(...) causes
>> AttributeError: No context.rpcclient_... in thread 'Thread-1'
>>
>> I think this is probably related to the fact that I haven't configured
>> my program to connect to any particular IPA server, because before the
>> program errors out, it prints:
>> ipa: INFO: Forwarding 'stageuser_add' to json server 'None'
>>
>> If the problem is the lack of a target server, as I suspect, how would I
>> configure the program to connect to a particular IPA server? If this
>> isn't caused by that, what could the causes be?
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] FreeIPA 4.2 Alpha preparations
On Wed, Jun 17, 2015 at 07:55:10AM +0200, Martin Kosek wrote: > On 06/16/2015 05:29 PM, Fraser Tweedale wrote: > >On Tue, Jun 16, 2015 at 05:10:00PM +0200, Martin Kosek wrote: > >>On 06/12/2015 11:34 AM, Martin Kosek wrote: > >>>Hello all, > >>> > >>>As discussed in the last 2 weeks, we are getting close to the 4.2 finish > >>>line > >>>and releasing FreeIPA 4.2 Alpha 1. We already have most of the major RFEs > >>>complete, some still miss some partial functionality, but most are > >>>testable and > >>>in Alpha state already. > >>> > >>>We need to now find out what is blocking us from releasing the Alpha. I > >>>know > >>>only about 2 issues: > >>> > >>>- ipa-replica-manage del does not work well with the Topology plugin yet - > >>>Petr > >>>Vobornik and Ludwig are working on it > >>>- ipa-replica-prepare had some issues after upgrade from 4.1.x to 4.2.0 > >>>due to > >>>inaccesible certificate profiles - Jan, Martin2, Fraser was investigating > >>> > >>>Is that correct? Feature owners, please let me know if any of the major > >>>feature > >>>regressed and is not working properly, maybe by other patch sets being > >>>merged. > >>> > >>>When the blockers are resolved or documented, we should release the beast. > >>>Any > >>>volunteer for the release process? > >>> > >>>Finally, I put together a release note draft for the Alpha, please help me > >>>completing and updating it: > >>> > >>>http://www.freeipa.org/page/Releases/4.2.0.alpha1 > >>> > >>>Thanks everyone! > >>> > >> > >>I saw many fixes in Topology, that's good. I heard that pki-core 10.2.4 > >>broke > >>us, but I could not reproduce it today with fully updated F22 machine and I > >>was > >>able to install FreeIPA 4.2.git > >> > >>If this is the case, can we just release the Alpha? > > > >There are still some big brokens for upgrades. The fixes for pki > >are merged but there is no release yet. > > What is the ETA? It would be nice to have the fix for Alpha, the package can > be built in the freeipa-4.2 COPR repo, together with the 4.2 Alpha release. > If the ETA is too far, we may need to release Alpha regardless as there are > some Test Days planned next week and upgrade is not required for such test > days. > Based on people educating me about how LDAP replication works: tomorrow, hopefully. In any case, I'm glad to know that the test days will not be affected by upgrade issues. > >I am only aware of one > >reported issue for new installations: ipa-replica-prepare failing > >when run on a replica (I haven't gotten to investigating this one > >yet). > > > Right. This must be fixed before GA, but Alpha can live without it IMO. I investigated this regression today - details are in another thread, but it appears to be introduced by a different change and I have requested comment from those more familiar with that change. Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] update on freeipa 4.2 pki issues
Hello Fraser, The schema is propagated on all replica. So if you update the schema, the updates will be eventually present everywhere. There is two ways to update the schema. * online update (prefered), you simply do a ldapmodify on 'cn=schema' adding/updating attributetypes/objectclasses * offline. You stop a replica/master, update the schema files, start the server. This is not the prefered solution because depending on version of DS it can take more time to detect the new schema and propagated it. Do you know how CS schema upgrade will be done (online/offline) ? Is it the new definitions http://www.freeipa.org/page/V4/Certificate_Profiles#Schema ? Thanks thierry On 06/17/2015 07:52 AM, Martin Kosek wrote: On 06/16/2015 06:39 PM, Fraser Tweedale wrote: I fixed several issues which broke Dogtag upgrades involving particular versions; these will be in the next release. I haven't yet gotten to to the reported failure running ipa-replica-upgrade on a replica (but I haven't forgotten about it either.) This is the only issue affecting *fresh installs* that I am aware of. If you know of others please let me know! The remaining Dogtag-related upgrade problem is caused by new DS schema on the Dogtag side, which is used for LDAP-based profiles. There is not yet an automatic schema upgrade facility for Dogtag, so the new schema was missing. The planned approach is: - Either Dogtag or FreeIPA will add the new CS schema on upgrade. (Eventually Dogtag will need to manage its own schema updates but right now there is no facility, and the new schema is only used by IPA.) If possible, I would prefer Dogtag to update the schema the best it can, otherwise there is a risk of collisions or upgrade breakages if FreeIPA starts updating Dogtag internals. - Migrate file-based profiles into LDAP during IPA upgrade. But for this to work, I need to make sure that if new schema is added, then entries that use the new schema, replication to instances that did not yet have the new schema will not break. Anyone who knows LDAP better than me, please share your knowledge! Shouldn't schema just replicate, when the first FreeIPA+CS is upgraded? CCing Thierry for reference, he had a lot of fun with schema upgrades. - If my assumptions about replication are wrong, the best approach will probably be to have the administrator perform profile migration (via a script) as a later task, after all replicas have been upgraded. Not a fan of this, FreeIPA upgrades should be ideally automatic and straightforward. So far we did not have problems with automatic upgrades (well, except Dogtag9->Dogtag10 upgrade - I would prefer not to have such situation again). Thanks for updates! Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] with new cert profiles patches ipa-replica-prepare fails after update
On Fri, Jun 12, 2015 at 03:47:38PM +0200, Petr Vobornik wrote:
> On 06/12/2015 03:18 PM, Fraser Tweedale wrote:
> >On Thu, Jun 11, 2015 at 09:59:03AM +0200, Martin Babinsky wrote:
> >>On 06/04/2015 04:03 PM, Petr Vobornik wrote:
> >>>- ipa-replica-prepare works
> >>>- old IPA server was upgraded to today's master (with Cert profiles
> >>>patches)
> >>>- ipa-replica-prepare fails with:
> >>>
> >>>Log:
> >>>
> >>>ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
> >>>ipa: DEBUG: cert valid True for "CN=repl.example.com,O=EXAMPLE.COM"
> >>>ipa: DEBUG: handshake complete, peer = [beef::cafe]:8443
> >>>ipa: DEBUG: Protocol: TLS1.2
> >>>ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_GCM_SHA256
> >>>ipa: DEBUG: request status 200
> >>>ipa: DEBUG: request reason_phrase u'OK'
> >>>ipa: DEBUG: request headers {'date': 'Thu, 04 Jun 2015 13:54:09 GMT',
> >>>'content-length': '148', 'content-type': 'application/xml', 'server':
> >>>'Apache-Coyote/1.1'}
> >>>ipa: DEBUG: request body ' >>>standalone="no"?>1Profile
> >>>caIPAserviceCert Not Found'
> >>>ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
> >>>"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> >>>execute
> >>> return_value = self.run()
> >>> File
> >>>"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
> >>>line 338, in run
> >>> self.copy_ds_certificate()
> >>> File
> >>>"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
> >>>line 383, in copy_ds_certificate
> >>> self.export_certdb("dscert", passwd_fname)
> >>> File
> >>>"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
> >>>line 595, in export_certdb
> >>> db.create_server_cert(nickname, hostname, ca_db)
> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
> >>>line 337, in create_server_cert
> >>> cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
> >>>line 419, in issue_server_cert
> >>> raise RuntimeError("Certificate issuance failed")
> >>>
> >>
> >>Bump, I have also came across this issue (see log:
> >>http://pastebin.test.redhat.com/289434).
> >>
> >>--
> >>Martin^3 Babinsky
> >
> >It was reported to me that the issue was reproducible after upgrade
> >from 4.1.4 to master, but I was not able to reproduce. Can anyone
> >who has encountered it please:
> >
> >- state fedora version(s) affected and precise build of Dogtag
> >- provide ipaupgrade.log and /var/log/pki/pki-tomcat/ca/debug
> >
> >Thanks,
> >Fraser
> >
>
> I see similar issue when creating a replica file from second
> replica/master, all git master. I.e. the prepare on first server obviously
> works.
>
> The error is different though:
>
> ipa: DEBUG: request status 200
> ipa: DEBUG: request reason_phrase u'OK'
> ipa: DEBUG: request headers {'date': 'Fri, 12 Jun 2015 13:46:32 GMT',
> 'content-length': '133', 'content-type': 'application/xml', 'server':
> 'Apache-Coyote/1.1'}
> ipa: DEBUG: request body ' standalone="no"?>1Invalid
> Credential.'
> ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> execute
> return_value = self.run()
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
> line 338, in run
> self.copy_ds_certificate()
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
> line 383, in copy_ds_certificate
> self.export_certdb("dscert", passwd_fname)
> File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
> line 595, in export_certdb
> db.create_server_cert(nickname, hostname, ca_db)
> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line
> 337, in create_server_cert
> cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
> File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line
> 419, in issue_server_cert
> raise RuntimeError("Certificate issuance failed")
>
> --
> Petr Vobornik
I spent some time debugging tihs issue today. It appears to be
introduced by commit:
commit 2acedb2d5d4a4c0987c670e14eb04b8bd9ffc034
Author: David Kupka
Date: Mon Jun 8 05:23:56 2015 +
Move CA installation code into single module.
https://fedorahosted.org/freeipa/ticket/4468
Reviewed-By: Jan Cholasta
During the execution of ipa-replica-prepare, the RA cert (nickname
"ipaCert") gets added to the /etc/httpd/alias/ NSSDB, but then
removed somehow while executing http.create_instance(). I have not
yet precisely identified the cause enough to fix it. Hopefully
David or Honza can some light.
Cheers,
Fraser
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org
Re: [Freeipa-devel] user deletion in offline mode does not get replicated after node recovery
Hi Oleg, can you give a bit more info on the scenarios when this happens. Always or is it a timing problem ? Ludwig On 06/16/2015 07:02 PM, thierry bordaz wrote: Hello On Master: User 'onmaster' was deleted [16/Jun/2015:10:16:45 -0400] conn=402 op=19 SRCH base="cn=otp,dc=bagam,dc=net" scope=1 filter="(&(objectClass=ipatoken)(ipatokenOwner=uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net))" attrs="ipatokenNotAfter description ipatokenOwner objectClass ipatokenDisabled ipatokenVendor managedBy ipatokenModel ipatokenNotBefore ipatokenUniqueID ipatokenSerial" [16/Jun/2015:10:16:45 -0400] conn=402 op=19 RESULT err=0 tag=101 nentries=0 etime=0 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:16:45 -0400] conn=402 op=21 UNBIND [16/Jun/2015:10:16:45 -0400] conn=402 op=21 fd=120 closed - U1 [16/Jun/2015:10:16:45 -0400] conn=402 op=20 RESULT err=0 tag=107 nentries=0 etime=0 csn=55802fcf00030004 Replication agreement failed to replicate it to the replica2 [16/Jun/2015:10:18:36 -0400] NSMMReplicationPlugin - agmt="cn=f22master.bagam.net-to-f22replica2.bagam.net" (f22replica2:389): Consumer failed to replay change (uniqueid b8242e18-143111e5-b1d0d0c3-ae5854ff, CSN 55802fcf00030004): Operations error (1). Will retry later. On replica2: The replicated operation failed [16/Jun/2015:10:18:27 -0400] conn=8 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=5 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" [16/Jun/2015:10:18:27 -0400] conn=8 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 because of DB failures to update. The failures were E_AGAIN or E_DB_DEADLOCK. In such situation, DS retries after a small delay. The problem is that it retried 50 times without success. [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: retry (49) the transaction (csn=55802fcf00030004) failed (rc=-30993 (BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock)) [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn: failed to write entry with csn (55802fcf00030004); db error - -30993 BDB0068 DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock [16/Jun/2015:10:18:34 -0400] NSMMReplicationPlugin - write_changelog_and_ruv: can't add a change for uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net (uniqid: b8242e18-143111e5-b1d0d0c3-ae5854ff, optype: 32) to changelog csn 55802fcf00030004 [16/Jun/2015:10:18:34 -0400] - SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN plugin returned error code but did not set SLAPI_RESULT_CODE The MAIN issue here is that replica2 successfully applied others updates after 55802fcf00030004 from the same replica (e.g csn=55802fcf00040004) I do not know if master was able to detect this failure and to replay this update. but I am afraid it did not !! It is looking like you hit https://fedorahosted.org/389/ticket/47788 Is it possible to access your VM ? [16/Jun/2015:10:18:27 -0400] conn=8 op=6 DEL dn="uid=onmaster,cn=users,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:35 -0400] conn=8 op=6 RESULT err=1 tag=107 nentries=0 etime=8 csn=55802fcf00030004 [16/Jun/2015:10:18:35 -0400] conn=8 op=7 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:36 -0400] conn=8 op=7 RESULT err=0 tag=103 nentries=0 etime=1 csn=55802fcf00040004 [16/Jun/2015:10:18:36 -0400] conn=8 op=8 DEL dn="cn=onmaster,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=8 RESULT err=0 tag=107 nentries=0 etime=1 csn=55802fcf00070004 [16/Jun/2015:10:18:37 -0400] conn=8 op=9 MOD dn="cn=ipausers,cn=groups,cn=accounts,dc=bagam,dc=net" [16/Jun/2015:10:18:37 -0400] conn=8 op=9 RESULT err=0 tag=103 nentries=0 etime=0 csn=55802fd6 On 06/16/2015 04:49 PM, Oleg Fayans wrote: Hi all, I've bumped into a strange problem with only a part of changes implemented on master during replica outage get replicated after replica recovery. Namely: when I delete an existing user on the master while the node is offline, these changes do not get to the node when it's back online. User creation, however, gets replicated as expected. Steps to reproduce: 1. Create the following tolopogy: replica1 <-> master <-> replica2 <-> replica3 2. Create user1 on master, make sure it appears on all replicas 3. Turn off replica2 4. On master delete user1 and create user2, make sure the changes get replicated to replica1 5. Turn on replica2 Expected results: A minute or so after repica2 is back up, 1. user1 does not exist neither on replica2 nor on replica3 2. user2 exists both on repli
Re: [Freeipa-devel] [PATCH 0014] correct handling of one directional segments
On 06/17/2015 10:35 AM, thierry bordaz wrote: On 06/17/2015 09:25 AM, Ludwig Krispenz wrote: Hi, thanks for review, see answers inline. On 06/16/2015 05:17 PM, thierry bordaz wrote: On 06/16/2015 11:41 AM, Ludwig Krispenz wrote: this patch adresses issues in checking existing segments for one directional segments and correctly handles the merging of segments, so that all agreements will be removed when the merged segment is deleted This is looking good to me with few comments * in ipa_topo_cfg_replica_segment_find, if 'dir=0' or 'dir=bidirectionnal' the reverse direction is bidirectionnal. Is it the expected result ? yes. 0 does not exist as valid direct and if we are looking for (A,B,both) this could als be expressed as (B,A,both). we do not really look for a opposite direction of (A,B,dir) but for a segment (B,A,revdir) which covers this segment. * in ipa_topo_check_segment_is_valid and ipa_topo_util_find_segment, may be hardening leftnode,rightnode,dir if they are NULL. (if the entry violate schema). if we can arrive at a state where an entry violates the schema I think we have more trouble, I want to avoid adding code for handling errors which cannot exist. Hi Ludwig, thanks for your explanations. All of them makes sense and so for me the patch is valid. I have a minor question about schema violation. When we add an entry, in preop we did not yet check the schema. So ipa_topo_pre_add->ipa_topo_check_segment_is_valid may be called with an invalid segment entry where some attributes are missing (like ipaReplTopoSegmentDirection). good point, in preop we cannot rely on schema been checked, need to add a check. Also something that is not clear to. I have a segment seg=ipa_topo_cfg_replica_segment_find(.., A, B, SEGMENT_RIGHT_LEFT, ..);. my understanding is that seg->right != 0 and seg->left == 0. is that correct ? no :-) one directional segments are a bit confusing. a replication agreement B-->A can be represented by a segment (A,B,right-left) or (B,A,left-right). when doing segment_find (A,B,right-left) we are looking if any segment covers this and teh result could be a segment (B,A,left right with seg->left !=0 thanks thierry * ipa_topo_util_segm_dir if direction does not match any of the strings, it returns -1. 0 would be better if we decide to test bit mask. yes, but in preop we check that only valid directions are added, so it might be unnecesarry to handle it, but if you want I can change it. * in ipa_topo_util_segment_update:810, ex_segm is a rigth_left segment. Why trying to call ipa_topo_cfg_agmt_dup with ex_segm->left in priority. Why not ex_segm->right first ? no, we don't know if it is a right-left segment. we have (A,B,left-right), the segment for the other direction could be (A.B,right-left) or (B,A,left-right). All we know is that it is not bidirectional, otherwise (A,B,left-right) would have been rejected in the preop test. So there is one agmt, left or right and take the existing one. * * in ipa_topo_util_delete_segments_for_host, If segment localhost->delhost is bidirectional, how can it exists a reverse segment delhost->localhost ? I thought those segments have been merged ? if it is bidirectional check_reverse is set to 0 and reveres is not attempted Thanks thierry -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0264] Server Upgrade: disconnect ldap2 connection before DS restart
On 16/06/15 16:04, Simo Sorce wrote: On Wed, 2015-06-10 at 13:47 +0200, Martin Basti wrote: Without this patch, upgrade may failed when api.Backend.ldap2 was connected before DS restart. Patch attached. although this patch is fine as is, I wonder why it is needed. I would argue that ldap2 should be able to reconnect on its own if the connection is broken, where am I wrong ? Simo. Honza also proposed this, it would be better, but not in 4.2.0. Martin^2 -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] correct handling of one directional segments
On 06/17/2015 09:25 AM, Ludwig Krispenz wrote: Hi, thanks for review, see answers inline. On 06/16/2015 05:17 PM, thierry bordaz wrote: On 06/16/2015 11:41 AM, Ludwig Krispenz wrote: this patch adresses issues in checking existing segments for one directional segments and correctly handles the merging of segments, so that all agreements will be removed when the merged segment is deleted This is looking good to me with few comments * in ipa_topo_cfg_replica_segment_find, if 'dir=0' or 'dir=bidirectionnal' the reverse direction is bidirectionnal. Is it the expected result ? yes. 0 does not exist as valid direct and if we are looking for (A,B,both) this could als be expressed as (B,A,both). we do not really look for a opposite direction of (A,B,dir) but for a segment (B,A,revdir) which covers this segment. * in ipa_topo_check_segment_is_valid and ipa_topo_util_find_segment, may be hardening leftnode,rightnode,dir if they are NULL. (if the entry violate schema). if we can arrive at a state where an entry violates the schema I think we have more trouble, I want to avoid adding code for handling errors which cannot exist. Hi Ludwig, thanks for your explanations. All of them makes sense and so for me the patch is valid. I have a minor question about schema violation. When we add an entry, in preop we did not yet check the schema. So ipa_topo_pre_add->ipa_topo_check_segment_is_valid may be called with an invalid segment entry where some attributes are missing (like ipaReplTopoSegmentDirection). Also something that is not clear to. I have a segment seg=ipa_topo_cfg_replica_segment_find(.., A, B, SEGMENT_RIGHT_LEFT, ..);. my understanding is that seg->right != 0 and seg->left == 0. is that correct ? thanks thierry * ipa_topo_util_segm_dir if direction does not match any of the strings, it returns -1. 0 would be better if we decide to test bit mask. yes, but in preop we check that only valid directions are added, so it might be unnecesarry to handle it, but if you want I can change it. * in ipa_topo_util_segment_update:810, ex_segm is a rigth_left segment. Why trying to call ipa_topo_cfg_agmt_dup with ex_segm->left in priority. Why not ex_segm->right first ? no, we don't know if it is a right-left segment. we have (A,B,left-right), the segment for the other direction could be (A.B,right-left) or (B,A,left-right). All we know is that it is not bidirectional, otherwise (A,B,left-right) would have been rejected in the preop test. So there is one agmt, left or right and take the existing one. * * in ipa_topo_util_delete_segments_for_host, If segment localhost->delhost is bidirectional, how can it exists a reverse segment delhost->localhost ? I thought those segments have been merged ? if it is bidirectional check_reverse is set to 0 and reveres is not attempted Thanks thierry -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] correct handling of one directional segments
Hi, thanks for review, see answers inline. On 06/16/2015 05:17 PM, thierry bordaz wrote: On 06/16/2015 11:41 AM, Ludwig Krispenz wrote: this patch adresses issues in checking existing segments for one directional segments and correctly handles the merging of segments, so that all agreements will be removed when the merged segment is deleted This is looking good to me with few comments * in ipa_topo_cfg_replica_segment_find, if 'dir=0' or 'dir=bidirectionnal' the reverse direction is bidirectionnal. Is it the expected result ? yes. 0 does not exist as valid direct and if we are looking for (A,B,both) this could als be expressed as (B,A,both). we do not really look for a opposite direction of (A,B,dir) but for a segment (B,A,revdir) which covers this segment. * in ipa_topo_check_segment_is_valid and ipa_topo_util_find_segment, may be hardening leftnode,rightnode,dir if they are NULL. (if the entry violate schema). if we can arrive at a state where an entry violates the schema I think we have more trouble, I want to avoid adding code for handling errors which cannot exist. * ipa_topo_util_segm_dir if direction does not match any of the strings, it returns -1. 0 would be better if we decide to test bit mask. yes, but in preop we check that only valid directions are added, so it might be unnecesarry to handle it, but if you want I can change it. * in ipa_topo_util_segment_update:810, ex_segm is a rigth_left segment. Why trying to call ipa_topo_cfg_agmt_dup with ex_segm->left in priority. Why not ex_segm->right first ? no, we don't know if it is a right-left segment. we have (A,B,left-right), the segment for the other direction could be (A.B,right-left) or (B,A,left-right). All we know is that it is not bidirectional, otherwise (A,B,left-right) would have been rejected in the preop test. So there is one agmt, left or right and take the existing one. * * in ipa_topo_util_delete_segments_for_host, If segment localhost->delhost is bidirectional, how can it exists a reverse segment delhost->localhost ? I thought those segments have been merged ? if it is bidirectional check_reverse is set to 0 and reveres is not attempted Thanks thierry -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
