From rcritten at redhat.com Wed Feb 1 04:25:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 31 Jan 2012 23:25:31 -0500 Subject: [Freeipa-devel] [PATCH] 937 configure /etc/openldap/ldap.conf Message-ID: <4F28BEBB.20008@redhat.com> Configure the openldap configuration file with the basics for IPA. This is mostly to make querying with StartTLS easier but it does make ldapsearch a lot nicer in general. I got a little carried away with the man page. I wanted to include that we were updating yet another configuration file and found no FILES section at all so I added one. I think I caught every file we update, it is the bulk in any case. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-937-ldapconf.patch Type: text/x-diff Size: 3908 bytes Desc: not available URL: From mkosek at redhat.com Wed Feb 1 08:35:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 01 Feb 2012 09:35:59 +0100 Subject: [Freeipa-devel] [PATCH] 937 configure /etc/openldap/ldap.conf In-Reply-To: <4F28BEBB.20008@redhat.com> References: <4F28BEBB.20008@redhat.com> Message-ID: <1328085359.24522.2.camel@balmora.brq.redhat.com> On Tue, 2012-01-31 at 23:25 -0500, Rob Crittenden wrote: > Configure the openldap configuration file with the basics for IPA. This > is mostly to make querying with StartTLS easier but it does make > ldapsearch a lot nicer in general. > > I got a little carried away with the man page. I wanted to include that > we were updating yet another configuration file and found no FILES > section at all so I added one. I think I caught every file we update, it > is the bulk in any case. > > rob Works fine. ACK if you add missing /etc/krb5.conf to the new FILES section. Martin From simo at redhat.com Wed Feb 1 13:50:08 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 01 Feb 2012 08:50:08 -0500 Subject: [Freeipa-devel] [PATCH] 937 configure /etc/openldap/ldap.conf In-Reply-To: <4F28BEBB.20008@redhat.com> References: <4F28BEBB.20008@redhat.com> Message-ID: <1328104208.21059.20.camel@willson.li.ssimo.org> On Tue, 2012-01-31 at 23:25 -0500, Rob Crittenden wrote: > Configure the openldap configuration file with the basics for IPA. > This > is mostly to make querying with StartTLS easier but it does make > ldapsearch a lot nicer in general. > > I got a little carried away with the man page. I wanted to include > that > we were updating yet another configuration file and found no FILES > section at all so I added one. I think I caught every file we update, > it > is the bulk in any case. > Ack Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Wed Feb 1 14:55:25 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 01 Feb 2012 15:55:25 +0100 Subject: [Freeipa-devel] [PATCH] 344 Added icons for status column. In-Reply-To: <4F2816E4.5020803@redhat.com> References: <4F2816E4.5020803@redhat.com> Message-ID: <4F29525D.7030502@redhat.com> On 01/31/2012 05:29 PM, Endi Sukma Dewata wrote: > The status formatter was modified to show enabled/disabled icon > before the status text. > > The format classes were renamed to formatter to avoid confusion > with the format() method. A new parameter 'type' was added to the > formatter to determine the output type (e.g. text/html). > > Ticket #1996 > ACK, pushed to master, ipa-2-2 -- Petr Vobornik From pvoborni at redhat.com Wed Feb 1 14:55:41 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 01 Feb 2012 15:55:41 +0100 Subject: [Freeipa-devel] [PATCH] 345 Hide Add/Delete buttons in self-service mode. In-Reply-To: <4F2829E9.2070409@redhat.com> References: <4F2829E9.2070409@redhat.com> Message-ID: <4F29526D.2040701@redhat.com> On 01/31/2012 06:50 PM, Endi Sukma Dewata wrote: > Users do not have add/delete permission in self-service mode, so > the search facet was modified to hide the Add/Delete buttons. > > Ticket #2188 > ACK, pushed to master, ipa-2-2 -- Petr Vobornik From pvoborni at redhat.com Wed Feb 1 14:55:58 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 01 Feb 2012 15:55:58 +0100 Subject: [Freeipa-devel] [PATCH] 346 Use fixed font when displaying certificate. In-Reply-To: <4F282A3D.3020007@redhat.com> References: <4F282A3D.3020007@redhat.com> Message-ID: <4F29527E.9000202@redhat.com> On 01/31/2012 06:51 PM, Endi Sukma Dewata wrote: > The textareas used to display certificates were modified to use > fixed font. > > Ticket #2017 > ACK, pushed to master, ipa-2-2 -- Petr Vobornik From pvoborni at redhat.com Wed Feb 1 14:56:17 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 01 Feb 2012 15:56:17 +0100 Subject: [Freeipa-devel] [PATCH] 347 Show password expiration date. In-Reply-To: <4F2852EC.9040908@redhat.com> References: <4F2852EC.9040908@redhat.com> Message-ID: <4F295291.9040901@redhat.com> On 01/31/2012 09:45 PM, Endi Sukma Dewata wrote: > The user details page was modified to show the password expiration > date next to the existing password field. > > Fixed problem resetting password in self-service mode. The JSON > interface for the passwd command requires the username to be > specified although the equivalent CLI command doesn't require it. > > Ticket #2064 > ACK, pushed to master, ipa-2-2 -- Petr Vobornik From mkosek at redhat.com Wed Feb 1 15:44:45 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 01 Feb 2012 16:44:45 +0100 Subject: [Freeipa-devel] [PATCH] 204 Improve netgroup-add error messages Message-ID: <1328111085.24522.4.camel@balmora.brq.redhat.com> These two situations in netgroup-add need to be distinguished: 1) Netgroup cannot be added because a hostgroup with the same name created a colliding managed netgroup 2) Another native netgroup with the same name exists This patch checks the colliding netgroup and raise appropriate error message based on this finding. https://fedorahosted.org/freeipa/ticket/2069 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-204-improve-netgroup-add-error-messages.patch Type: text/x-patch Size: 2630 bytes Desc: not available URL: From mkosek at redhat.com Wed Feb 1 16:55:07 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 01 Feb 2012 17:55:07 +0100 Subject: [Freeipa-devel] [PATCH] 205 Remove UDP checks from conncheck Message-ID: <1328115307.24522.5.camel@balmora.brq.redhat.com> UDP port checks in ipa-replica-conncheck always returns OK even if they are closed by firewall. They cannot be reliably checked in the same way as TCP ports as there is no session management as in TCP protocol. We cannot guarantee a response on the checked side without our own echo server bound to checked port. This patch removes UDP port checks altogether so that user gets a consistent conncheck report without confusing UDP results. https://fedorahosted.org/freeipa/ticket/2062 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-205-remove-udp-checks-from-conncheck.patch Type: text/x-patch Size: 4280 bytes Desc: not available URL: From dpal at redhat.com Wed Feb 1 17:00:43 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 01 Feb 2012 12:00:43 -0500 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 In-Reply-To: <20120131114531.GD28503@localhost.localdomain> References: <20120131114531.GD28503@localhost.localdomain> Message-ID: <4F296FBB.6040403@redhat.com> On 01/31/2012 06:45 AM, Sumit Bose wrote: > Hi, > > for the IPAv3 trust feature we have to add the objectclass > ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be > visible on the Windows side of the trust. The only MUST attribute of > both objectclasses is ipaNTSecurityIdentifier the SID or the user or > group. We would like to manage the SIDS with the DNA plugin since they > have to be unique in the IPA domain. > > The trust support will typically be added to a running IPA domain, > because we do not plan to install it by default and we have to consider > updated v2 environments as well. So the question arises what is the most > preferred way to add a DNA configuration to an existing Directory Server > setup with replication. > > Nathan suggested to create the configuration with the full range on the > first master, configure the other master with no available values > and let the DNA plugin transfer the ranges between the masters. > > This will lead to the following steps: > > 1. Check if there are already shared configuration entries in > cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > 2a. if not we can create the initial configuration on the current > master: > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > changetype: add > objectclass: top > objectclass: extensibleObject > cn: SIDs > dnaType: ipaNTSecurityIdentifier > dnaNextValue: 1000 > dnaMaxValue: eval($SIDMAX) # Maybe 200k ? > dnaMagicRegen: 999 > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > dnaScope: $SUFFIX > dnaThreshold: 500 > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with > ipaNTSecurityIdentifier=999 on the current master > > 4a. Done on the first master > > 2b. if there are already entries we can create the configuration for an > additional master: > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > changetype: add > objectclass: top > objectclass: extensibleObject > cn: SIDs > dnaType: ipaNTSecurityIdentifier > dnaNextValue: 1101 > dnaMaxValue: 1100 > dnaMagicRegen: 999 > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > dnaScope: $SUFFIX > dnaThreshold: 500 > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > 3b. Done on the additional master, DNA plugin will sort out the rest > > > > Do these steps make sense? > > Is it necessary to add a lock to prevent a race condition btween step 1 > and 2a, i.e. two admins try to prepare IPA for trusts independently at > the same time? > > Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on > the first master, the range on the second master will start at 2^31? So > the usage of the full range will be quite sparse if dnaMaxValue is set > too high. > > Step 3a on the first master might need some time to finish. Is it > necessary to set some kind of lock to prevent the configuration of the > DNA plugin on other masters while this task is running or is it safe to > add another master at any time? > > Are there other ways to introduce the DNA configuration? Nathan > suggested also that the ranges can be configured manually without > overlap, but if possible I would prefer the automatic way. > > Thank you for your help. > > bye, > Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Couple comments. 1) What is the impact on the replication? 2) How we can prevent the case when in the distributed topology the change starts from two ends? 3) What is the speed of the propagation of this configuration in a 20 replica architecture? 4) Would it be better to generate the SIDs on every replica? We already have UID/GID and GUIDs for the entries. If SID is derived from entry GUID the change can be made locally and does not require replication. The GUIDs are already replicated so the SID can be generated locally like we do with the other non replicated attributes. In this case you just need to install a new plugin on your replicas and change configuration entry to enable it. As soon as this entry is replicated the plugin will kick in and would start adding SIDs to users and groups in the background on every replica. Overall there will be less traffic and no need to deal with DNA ranges. Is it possible to derive SID from other attribute in the User or group object? 5) If we go with the way Summit suggested we also need to have a special handling in the ipa-replica-prepare depending upon whether the SID support is on or off. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Feb 1 18:39:34 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Feb 2012 13:39:34 -0500 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 In-Reply-To: <20120131114531.GD28503@localhost.localdomain> References: <20120131114531.GD28503@localhost.localdomain> Message-ID: <4F2986E6.8030006@redhat.com> Sumit Bose wrote: > Hi, > > for the IPAv3 trust feature we have to add the objectclass > ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be > visible on the Windows side of the trust. The only MUST attribute of > both objectclasses is ipaNTSecurityIdentifier the SID or the user or > group. We would like to manage the SIDS with the DNA plugin since they > have to be unique in the IPA domain. > > The trust support will typically be added to a running IPA domain, > because we do not plan to install it by default and we have to consider > updated v2 environments as well. So the question arises what is the most > preferred way to add a DNA configuration to an existing Directory Server > setup with replication. > > Nathan suggested to create the configuration with the full range on the > first master, configure the other master with no available values > and let the DNA plugin transfer the ranges between the masters. > > This will lead to the following steps: > > 1. Check if there are already shared configuration entries in > cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > 2a. if not we can create the initial configuration on the current > master: > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > changetype: add > objectclass: top > objectclass: extensibleObject > cn: SIDs > dnaType: ipaNTSecurityIdentifier > dnaNextValue: 1000 > dnaMaxValue: eval($SIDMAX) # Maybe 200k ? > dnaMagicRegen: 999 > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > dnaScope: $SUFFIX > dnaThreshold: 500 > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with > ipaNTSecurityIdentifier=999 on the current master > > 4a. Done on the first master > > 2b. if there are already entries we can create the configuration for an > additional master: > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > changetype: add > objectclass: top > objectclass: extensibleObject > cn: SIDs > dnaType: ipaNTSecurityIdentifier > dnaNextValue: 1101 > dnaMaxValue: 1100 > dnaMagicRegen: 999 > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > dnaScope: $SUFFIX > dnaThreshold: 500 > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > 3b. Done on the additional master, DNA plugin will sort out the rest > > > > Do these steps make sense? > > Is it necessary to add a lock to prevent a race condition btween step 1 > and 2a, i.e. two admins try to prepare IPA for trusts independently at > the same time? There is no locking/notification mechansim to do this AFAIK. The "first master" in this case really means the first one that gets updated packages. The updates that happen at rpm upgrade time happen with the server listening only on ldapi so it would be very possible for two servers to apply the updates at the same time without knowing it. > > Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on > the first master, the range on the second master will start at 2^31? So > the usage of the full range will be quite sparse if dnaMaxValue is set > too high. > > Step 3a on the first master might need some time to finish. Is it > necessary to set some kind of lock to prevent the configuration of the > DNA plugin on other masters while this task is running or is it safe to > add another master at any time? In fact it might take a REALLY long time if there are a lot of users. This would happen at the end of an rpm upgrade, I wonder if we'd want a separate task to run instead. If we can figure out a way to have only one server do all the updates then I don't think the DNA config would be an issue. > Are there other ways to introduce the DNA configuration? Nathan > suggested also that the ranges can be configured manually without > overlap, but if possible I would prefer the automatic way. I think coordinating manual ranges would be hard, I agree with Sumit that automatic is the way to go. I wonder if before shutting things down for upgrade something creates cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX and sets a magic value in it specific to the host that added it. When any other changes are done relating to this update if the hostname doesn't match that magic value the updates are skipped. We tend to construct full dns for reference rather than searching so I'd think that even if there was a replication conflict entry created it would never get used because of the unique dn it would get. rob From simo at redhat.com Wed Feb 1 18:59:15 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 01 Feb 2012 13:59:15 -0500 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 In-Reply-To: <4F296FBB.6040403@redhat.com> References: <20120131114531.GD28503@localhost.localdomain> <4F296FBB.6040403@redhat.com> Message-ID: <1328122755.21059.45.camel@willson.li.ssimo.org> On Wed, 2012-02-01 at 12:00 -0500, Dmitri Pal wrote: > On 01/31/2012 06:45 AM, Sumit Bose wrote: > > Hi, > > > > for the IPAv3 trust feature we have to add the objectclass > > ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be > > visible on the Windows side of the trust. The only MUST attribute of > > both objectclasses is ipaNTSecurityIdentifier the SID or the user or > > group. We would like to manage the SIDS with the DNA plugin since they > > have to be unique in the IPA domain. > > > > The trust support will typically be added to a running IPA domain, > > because we do not plan to install it by default and we have to consider > > updated v2 environments as well. So the question arises what is the most > > preferred way to add a DNA configuration to an existing Directory Server > > setup with replication. > > > > Nathan suggested to create the configuration with the full range on the > > first master, configure the other master with no available values > > and let the DNA plugin transfer the ranges between the masters. This is the way to go. > > This will lead to the following steps: > > > > 1. Check if there are already shared configuration entries in > > cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > 2a. if not we can create the initial configuration on the current > > master: > > > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > > changetype: add > > objectclass: top > > objectclass: extensibleObject > > cn: SIDs > > dnaType: ipaNTSecurityIdentifier > > dnaNextValue: 1000 > > dnaMaxValue: eval($SIDMAX) # Maybe 200k ? > > dnaMagicRegen: 999 > > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > > dnaScope: $SUFFIX > > dnaThreshold: 500 > > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with > > ipaNTSecurityIdentifier=999 on the current master This should be done as a task in Directory server. > > 4a. Done on the first master I am not sure I understand what does this means. > > 2b. if there are already entries we can create the configuration for an > > additional master: > > > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > > changetype: add > > objectclass: top > > objectclass: extensibleObject > > cn: SIDs > > dnaType: ipaNTSecurityIdentifier > > dnaNextValue: 1101 > > dnaMaxValue: 1100 > > dnaMagicRegen: 999 > > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > > dnaScope: $SUFFIX > > dnaThreshold: 500 > > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > 3b. Done on the additional master, DNA plugin will sort out the rest > > > > > > > > Do these steps make sense? Yes. > > Is it necessary to add a lock to prevent a race condition btween step 1 > > and 2a, i.e. two admins try to prepare IPA for trusts independently at > > the same time? No, if admins are so dumb not to coordinate on adding this infrastructure changing stuff and do it at the exact same moment it's really their problem. We will, of course, document that they should be careful. > > Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on > > the first master, the range on the second master will start at 2^31? So > > the usage of the full range will be quite sparse if dnaMaxValue is set > > too high. True, ranges are always split in half for now. > > Step 3a on the first master might need some time to finish. Is it > > necessary to set some kind of lock to prevent the configuration of the > > DNA plugin on other masters while this task is running or is it safe to > > add another master at any time? safe, the task to add SIDs to users should be an explicit DS task set up only by the ipa-trust-install script. > > Are there other ways to introduce the DNA configuration? Nathan > > suggested also that the ranges can be configured manually without > > overlap, but if possible I would prefer the automatic way. Automatic is better, less error prone. > Couple comments. > 1) What is the impact on the replication? If you have many users the first replication would take a long time. > 2) How we can prevent the case when in the distributed topology the > change starts from two ends? By documenting that you do not run ipa-trust-install on 2 ends. > 3) What is the speed of the propagation of this configuration in a 20 > replica architecture? It depends on the replica topology and what master you run the install on. > 4) Would it be better to generate the SIDs on every replica? We already > have UID/GID and GUIDs for the entries. If SID is derived from entry > GUID the change can be made locally and does not require replication. SIDs cannot be derived from GUIDs. > The GUIDs are already replicated so the SID can be generated locally > like we do with the other non replicated attributes. In this case you > just need to install a new plugin on your replicas and change > configuration entry to enable it. As soon as this entry is replicated > the plugin will kick in and would start adding SIDs to users and groups > in the background on every replica. Overall there will be less traffic > and no need to deal with DNA ranges. Is it possible to derive SID from > other attribute in the User or group object? We have thought about using uidNumber/gidNumber but the problem is that in configurations where admins decide their values a uidNumber may overlap numerically with a gidNumber of a normal group (User Private groups would be excluded). This in turn would cause a user and a group to have the same SID, which is very bad. The same issue would occur if admins force identical uidNumbers/gidNumbers on users/groups. Thinking more about it we could punt on creating the SID if such a condition is detected, so it could still be a valid idea to use the uid/gid as the RID for a SID, but it could cause confusion to not see some groups/users show up without some way to warn when the internal plugin finds such a conflict. > 5) If we go with the way Summit suggested we also need to have a special > handling in the ipa-replica-prepare depending upon whether the SID > support is on or off. This is a very minor issue. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Feb 1 19:01:28 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 01 Feb 2012 14:01:28 -0500 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 In-Reply-To: <4F2986E6.8030006@redhat.com> References: <20120131114531.GD28503@localhost.localdomain> <4F2986E6.8030006@redhat.com> Message-ID: <1328122888.21059.47.camel@willson.li.ssimo.org> On Wed, 2012-02-01 at 13:39 -0500, Rob Crittenden wrote: > Sumit Bose wrote: > > Hi, > > > > for the IPAv3 trust feature we have to add the objectclass > > ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be > > visible on the Windows side of the trust. The only MUST attribute of > > both objectclasses is ipaNTSecurityIdentifier the SID or the user or > > group. We would like to manage the SIDS with the DNA plugin since they > > have to be unique in the IPA domain. > > > > The trust support will typically be added to a running IPA domain, > > because we do not plan to install it by default and we have to consider > > updated v2 environments as well. So the question arises what is the most > > preferred way to add a DNA configuration to an existing Directory Server > > setup with replication. > > > > Nathan suggested to create the configuration with the full range on the > > first master, configure the other master with no available values > > and let the DNA plugin transfer the ranges between the masters. > > > > This will lead to the following steps: > > > > 1. Check if there are already shared configuration entries in > > cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > 2a. if not we can create the initial configuration on the current > > master: > > > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > > changetype: add > > objectclass: top > > objectclass: extensibleObject > > cn: SIDs > > dnaType: ipaNTSecurityIdentifier > > dnaNextValue: 1000 > > dnaMaxValue: eval($SIDMAX) # Maybe 200k ? > > dnaMagicRegen: 999 > > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > > dnaScope: $SUFFIX > > dnaThreshold: 500 > > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with > > ipaNTSecurityIdentifier=999 on the current master > > > > 4a. Done on the first master > > > > 2b. if there are already entries we can create the configuration for an > > additional master: > > > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > > changetype: add > > objectclass: top > > objectclass: extensibleObject > > cn: SIDs > > dnaType: ipaNTSecurityIdentifier > > dnaNextValue: 1101 > > dnaMaxValue: 1100 > > dnaMagicRegen: 999 > > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > > dnaScope: $SUFFIX > > dnaThreshold: 500 > > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > 3b. Done on the additional master, DNA plugin will sort out the rest > > > > > > > > Do these steps make sense? > > > > Is it necessary to add a lock to prevent a race condition btween step 1 > > and 2a, i.e. two admins try to prepare IPA for trusts independently at > > the same time? > > There is no locking/notification mechansim to do this AFAIK. > > The "first master" in this case really means the first one that gets > updated packages. The updates that happen at rpm upgrade time happen > with the server listening only on ldapi so it would be very possible for > two servers to apply the updates at the same time without knowing it. The trust stuff is always explicitly installed manually, so there is no problem at rpm upgrade time. Either the configuration is already there or there is no configuration to care about. > > Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on > > the first master, the range on the second master will start at 2^31? So > > the usage of the full range will be quite sparse if dnaMaxValue is set > > too high. > > > > Step 3a on the first master might need some time to finish. Is it > > necessary to set some kind of lock to prevent the configuration of the > > DNA plugin on other masters while this task is running or is it safe to > > add another master at any time? > > In fact it might take a REALLY long time if there are a lot of users. > This would happen at the end of an rpm upgrade, I wonder if we'd want a > separate task to run instead. Nothing to do at rpm updagrade time. > If we can figure out a way to have only one server do all the updates > then I don't think the DNA config would be an issue. Only one server should do them see my other email. > > Are there other ways to introduce the DNA configuration? Nathan > > suggested also that the ranges can be configured manually without > > overlap, but if possible I would prefer the automatic way. > > I think coordinating manual ranges would be hard, I agree with Sumit > that automatic is the way to go. > > I wonder if before shutting things down for upgrade something creates > cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX and sets a magic value in it > specific to the host that added it. > > When any other changes are done relating to this update if the hostname > doesn't match that magic value the updates are skipped. > > We tend to construct full dns for reference rather than searching so I'd > think that even if there was a replication conflict entry created it > would never get used because of the unique dn it would get. I don't think this is necessary, it does not avoid races anyways. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Wed Feb 1 19:09:15 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 01 Feb 2012 13:09:15 -0600 Subject: [Freeipa-devel] [PATCH] 072 Navigation and redirection to various facets In-Reply-To: <4F22D5B2.4080701@redhat.com> References: <4F22D5B2.4080701@redhat.com> Message-ID: <4F298DDB.7080904@redhat.com> On 1/27/2012 10:49 AM, Petr Vobornik wrote: > In current implementation target facet of navigation(from menu) and > redirection is always one exact facet per entity. There isn't a way to > navigate to different facet from menu or redirect to different facets > from various facets. > > This patch adds: > * possibility to define menu items which can navigate to different > facets of various entities. This also means that now current menu tree > can contain leafs with the same entity. > * possibility to define redirection target per facet - it is needed to > keep breadcrumb navigation consistent with various navigation tree patch > leading leafs with same entity. > > This functionality is needed for Automember UI. Automember UI is > designed as if it was for two entities but it is in fact only one. > > Note: attaching early (missing a lot of stuff) WIP patch of Automember > UI to illustrate usage of this patch. > > https://fedorahosted.org/freeipa/ticket/2195 ACK. Pushed to master and ipa-2-2. There are some existing problems with redirection. In users search facet, when you click a user that's already deleted via CLI, the UI doesn't redirect. This is because it uses a batch command to pull user data & policies. The batch itself will return a success although the operations inside it fail. The automount location and map do not redirect either if it's already deleted. The automount key does redirect, but to the locations instead of to the map. -- Endi S. Dewata From edewata at redhat.com Wed Feb 1 19:09:56 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 01 Feb 2012 13:09:56 -0600 Subject: [Freeipa-devel] [PATCH] 073 Automember UI In-Reply-To: <4F2809AF.1090108@redhat.com> References: <4F2809AF.1090108@redhat.com> Message-ID: <4F298E04.1060207@redhat.com> On 1/31/2012 9:33 AM, Petr Vobornik wrote: > New UI for automember. > > Implemented: > * search facet core > * rule details facet > * attribute_table_widget - new base class for tables which contains > multivalued attribute with special add/remove commands > * adding/removing conditions in details facet > > TODO (will follow): > * label translations > * UI for defining default rules > > Note: depends on my patch #72 ACK. Pushed to master and ipa-2-2. As you mentioned in the earlier patch, the automember is one entity but it behaves like two separate entities for group and hostgroup. And the navigation map is composed of entities so that's why you had to fix the navigation code to be able to distinguish the facets for automember group and hostgroup. I've been thinking we might want to detach the 1-1 relationship between the server plugin and the UI entity. This way we could define an entity that can encapsulate the interactions with multiple server plugins, or multiple entities using the same plugins like automember. So instead of calling IPA.command directly, the facet will call a method in the entity and it will execute the appropriate command(s). The command could be a batch and the entity could merge the results into a single object which can be handled by the facet more easily. In other words the entity will become the persistent layer. Another thing, right now in the fields spec we specify the widgets that the fields going to use (I know I suggested it :)). Maybe it should have been the other way around. So in the widgets spec we specify the fields that the widgets are mapped to. This is related to the above point, the field will be part of persistent layer too. The facets and widgets are the clients of the persistent layer. The fields could later be moved into the entity definition. The facets will only contain widgets. About the navigation map and entities, we could probably detach them too, but it can be discussed later. -- Endi S. Dewata From rcritten at redhat.com Wed Feb 1 21:45:28 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Feb 2012 16:45:28 -0500 Subject: [Freeipa-devel] [PATCH] 938 consolidate external member code Message-ID: <4F29B278.9070107@redhat.com> We had code all over the place to handle adding and removing external members from a variety of attributes. I consolidated these all into two functions in baseldap.py. This obsoletes my patch 920 but this patch includes the improved error reporting that was present. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-938-external.patch Type: text/x-diff Size: 25813 bytes Desc: not available URL: From rcritten at redhat.com Wed Feb 1 21:45:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 01 Feb 2012 16:45:56 -0500 Subject: [Freeipa-devel] [PATCH] 920 fix error message when re-adding users to sudorule In-Reply-To: <4F06265E.1080603@redhat.com> References: <4F06265E.1080603@redhat.com> Message-ID: <4F29B294.8040101@redhat.com> Rob Crittenden wrote: > When re-adding an external user to a sudorule the wrong error message > was showing (not found instead of already a member). > > Also display external users by default. > > This relies on my patch 919 to apply. Patch withdrawn. This is obsoleted by my patch 937. rob From mkosek at redhat.com Thu Feb 2 11:10:41 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Feb 2012 12:10:41 +0100 Subject: [Freeipa-devel] [PATCH] 206 Improve password change error message Message-ID: <1328181041.24421.9.camel@balmora.brq.redhat.com> User always receives the same error message if he changes his password via "ipa passwd" command and the new password fails configured password policy. He then has to investigate on his own the actual reason why was the policy violated. This patch improves our SLAPI PWD plugins to provide a better error message explaining the violation reason. https://fedorahosted.org/freeipa/ticket/2067 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-206-improve-password-change-error-message.patch Type: text/x-patch Size: 4423 bytes Desc: not available URL: From sbose at redhat.com Thu Feb 2 11:25:45 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 2 Feb 2012 12:25:45 +0100 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 In-Reply-To: <1328122755.21059.45.camel@willson.li.ssimo.org> References: <20120131114531.GD28503@localhost.localdomain> <4F296FBB.6040403@redhat.com> <1328122755.21059.45.camel@willson.li.ssimo.org> Message-ID: <20120202112544.GJ28503@localhost.localdomain> On Wed, Feb 01, 2012 at 01:59:15PM -0500, Simo Sorce wrote: > On Wed, 2012-02-01 at 12:00 -0500, Dmitri Pal wrote: > > On 01/31/2012 06:45 AM, Sumit Bose wrote: > > > Hi, > > > > > > for the IPAv3 trust feature we have to add the objectclass > > > ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be > > > visible on the Windows side of the trust. The only MUST attribute of > > > both objectclasses is ipaNTSecurityIdentifier the SID or the user or > > > group. We would like to manage the SIDS with the DNA plugin since they > > > have to be unique in the IPA domain. > > > > > > The trust support will typically be added to a running IPA domain, > > > because we do not plan to install it by default and we have to consider > > > updated v2 environments as well. So the question arises what is the most > > > preferred way to add a DNA configuration to an existing Directory Server > > > setup with replication. > > > > > > Nathan suggested to create the configuration with the full range on the > > > first master, configure the other master with no available values > > > and let the DNA plugin transfer the ranges between the masters. > > This is the way to go. > > > > This will lead to the following steps: > > > > > > 1. Check if there are already shared configuration entries in > > > cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > > > 2a. if not we can create the initial configuration on the current > > > master: > > > > > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > > > changetype: add > > > objectclass: top > > > objectclass: extensibleObject > > > cn: SIDs > > > dnaType: ipaNTSecurityIdentifier > > > dnaNextValue: 1000 > > > dnaMaxValue: eval($SIDMAX) # Maybe 200k ? > > > dnaMagicRegen: 999 > > > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > > > dnaScope: $SUFFIX > > > dnaThreshold: 500 > > > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > > > 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with > > > ipaNTSecurityIdentifier=999 on the current master > > This should be done as a task in Directory server. > > > > 4a. Done on the first master > > I am not sure I understand what does this means. > > > > 2b. if there are already entries we can create the configuration for an > > > additional master: > > > > > > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > > > changetype: add > > > objectclass: top > > > objectclass: extensibleObject > > > cn: SIDs > > > dnaType: ipaNTSecurityIdentifier > > > dnaNextValue: 1101 > > > dnaMaxValue: 1100 > > > dnaMagicRegen: 999 > > > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) > > > dnaScope: $SUFFIX > > > dnaThreshold: 500 > > > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX > > > > > > 3b. Done on the additional master, DNA plugin will sort out the rest > > > > > > > > > > > > Do these steps make sense? > > Yes. > > > > Is it necessary to add a lock to prevent a race condition btween step 1 > > > and 2a, i.e. two admins try to prepare IPA for trusts independently at > > > the same time? > > No, if admins are so dumb not to coordinate on adding this > infrastructure changing stuff and do it at the exact same moment it's > really their problem. We will, of course, document that they should be > careful. > > > > Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on > > > the first master, the range on the second master will start at 2^31? So > > > the usage of the full range will be quite sparse if dnaMaxValue is set > > > too high. > > True, ranges are always split in half for now. > > > > Step 3a on the first master might need some time to finish. Is it > > > necessary to set some kind of lock to prevent the configuration of the > > > DNA plugin on other masters while this task is running or is it safe to > > > add another master at any time? > > safe, the task to add SIDs to users should be an explicit DS task set up > only by the ipa-trust-install script. > > > > Are there other ways to introduce the DNA configuration? Nathan > > > suggested also that the ranges can be configured manually without > > > overlap, but if possible I would prefer the automatic way. > > Automatic is better, less error prone. > > > Couple comments. > > 1) What is the impact on the replication? > > If you have many users the first replication would take a long time. > > > 2) How we can prevent the case when in the distributed topology the > > change starts from two ends? > > By documenting that you do not run ipa-trust-install on 2 ends. > > > 3) What is the speed of the propagation of this configuration in a 20 > > replica architecture? > > It depends on the replica topology and what master you run the install > on. > > > 4) Would it be better to generate the SIDs on every replica? We already > > have UID/GID and GUIDs for the entries. If SID is derived from entry > > GUID the change can be made locally and does not require replication. > > SIDs cannot be derived from GUIDs. > > > The GUIDs are already replicated so the SID can be generated locally > > like we do with the other non replicated attributes. In this case you > > just need to install a new plugin on your replicas and change > > configuration entry to enable it. As soon as this entry is replicated > > the plugin will kick in and would start adding SIDs to users and groups > > in the background on every replica. Overall there will be less traffic > > and no need to deal with DNA ranges. Is it possible to derive SID from > > other attribute in the User or group object? > > We have thought about using uidNumber/gidNumber but the problem is that > in configurations where admins decide their values a uidNumber may > overlap numerically with a gidNumber of a normal group (User Private > groups would be excluded). This in turn would cause a user and a group > to have the same SID, which is very bad. The same issue would occur if > admins force identical uidNumbers/gidNumbers on users/groups. > > Thinking more about it we could punt on creating the SID if such a > condition is detected, so it could still be a valid idea to use the > uid/gid as the RID for a SID, but it could cause confusion to not see > some groups/users show up without some way to warn when the internal > plugin finds such a conflict. > > > 5) If we go with the way Summit suggested we also need to have a special > > handling in the ipa-replica-prepare depending upon whether the SID > > support is on or off. > > This is a very minor issue. > > Simo. Simo, thank you for give detailed responses and explanations here. To make it - hopefully - even clearer I try to describe the step that are necessary to enable IPA for trust and to create trust to AD domains. I assume that we start from a running IPAv2 setup with replication: 1. Update IPA to v3, install the new packages, run everything that is needed for the update. This step will not create anything related to trust (only the needed python code and config file templates are installed) 2. Call ipa-adtrust-install to enable IPA to handle trust, this will - create the samba configuration - add cn=trust to the DIT - generate a domain SID and stores it in the DIT - add the well know administrator and admin group SIDs to the admin user and the admins group respectively - activate the CLDAP directory server plugin - add DNA configuration to automatically add SIDs to users and groups on the server where ipa-adtrust-install 3. Now SIDs can be added to users and groups, this can be done - as Simo mentioned above with the help of a directory server task to generate them as fast a possible - but if there are concerns about the traffic caused by the replication, this can also be done by an external script, with a rate limitation or during non-office hours this process might take some time, but since it has to be done only once I think it is even acceptable if it needs some days to finish, as long as it is documented :-) 4. Now ipa-adtrust-install can be called on other IPA servers which will now skip the configuration steps which can already be found in the replicated tree, some of the remaining ones are: - create the samba configuration - activate the CLDAP directory server plugin - add SID DNA configuration with an empty range 5. Finally a trust to an AD domain can be created my calling 'net rpc trust create ...' (Alexander is working on the integration into the ipa utility so that it will be more like 'ipa adtrust-create' or similar). bye, Sumit > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Thu Feb 2 11:39:23 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 2 Feb 2012 13:39:23 +0200 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 In-Reply-To: <20120202112544.GJ28503@localhost.localdomain> References: <20120131114531.GD28503@localhost.localdomain> <4F296FBB.6040403@redhat.com> <1328122755.21059.45.camel@willson.li.ssimo.org> <20120202112544.GJ28503@localhost.localdomain> Message-ID: <20120202113923.GN11943@redhat.com> On Thu, 02 Feb 2012, Sumit Bose wrote: > Simo, thank you for give detailed responses and explanations here. To > make it - hopefully - even clearer I try to describe the step that are > necessary to enable IPA for trust and to create trust to AD domains. > > I assume that we start from a running IPAv2 setup with replication: > > 1. Update IPA to v3, install the new packages, run everything that is > needed for the update. This step will not create anything related to > trust (only the needed python code and config file templates are > installed) > > 2. Call ipa-adtrust-install to enable IPA to handle trust, this will > - create the samba configuration > - add cn=trust to the DIT > - generate a domain SID and stores it in the DIT > - add the well know administrator and admin group SIDs to the admin user > and the admins group respectively > - activate the CLDAP directory server plugin > - add DNA configuration to automatically add SIDs to users and groups > on the server where ipa-adtrust-install At this point 'ipa trust ...' set of commands mentioned in (5) will be able to operate because we'll have enough information about our own domain to proceed with trusts to other domains. > 3. Now SIDs can be added to users and groups, this can be done > - as Simo mentioned above with the help of a directory server task to > generate them as fast a possible > - but if there are concerns about the traffic caused by the > replication, this can also be done by an external script, with a > rate limitation or during non-office hours > this process might take some time, but since it has to be done only once > I think it is even acceptable if it needs some days to finish, as long > as it is documented :-) Agree. There are two separate phases here, actually: - trust creation - trust usage Normal usage is possible after step (3), creating trusts is possible before (3), albeight it wouldn't be quite usable besides administrator account. > 4. Now ipa-adtrust-install can be called on other IPA servers which will > now skip the configuration steps which can already be found in the > replicated tree, some of the remaining ones are: > - create the samba configuration > - activate the CLDAP directory server plugin > - add SID DNA configuration with an empty range ACK. There is also need to add DNS records to get these IPA servers in use for AD discovery. > 5. Finally a trust to an AD domain can be created my calling 'net rpc > trust create ...' (Alexander is working on the integration into the ipa > utility so that it will be more like 'ipa adtrust-create' or similar). Yep. -- / Alexander Bokovoy From mkosek at redhat.com Thu Feb 2 12:57:21 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Feb 2012 13:57:21 +0100 Subject: [Freeipa-devel] [PATCH] 207 Improve dnszone-add error message Message-ID: <1328187441.24421.10.camel@balmora.brq.redhat.com> When a new DNS record is being added to DNS zone via command ipa dnsrecord-add ZONE @ and the target ZONE does not exist it returns ObjectclassViolation which may confuse users. Make sure that standard DNS Zone NotFound exception is returned. https://fedorahosted.org/freeipa/ticket/2270 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-207-improve-dnszone-add-error-message.patch Type: text/x-patch Size: 1473 bytes Desc: not available URL: From simo at redhat.com Thu Feb 2 14:08:18 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 02 Feb 2012 09:08:18 -0500 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 In-Reply-To: <20120202113923.GN11943@redhat.com> References: <20120131114531.GD28503@localhost.localdomain> <4F296FBB.6040403@redhat.com> <1328122755.21059.45.camel@willson.li.ssimo.org> <20120202112544.GJ28503@localhost.localdomain> <20120202113923.GN11943@redhat.com> Message-ID: <1328191698.21059.66.camel@willson.li.ssimo.org> On Thu, 2012-02-02 at 13:39 +0200, Alexander Bokovoy wrote: > On Thu, 02 Feb 2012, Sumit Bose wrote: > > Simo, thank you for give detailed responses and explanations here. To > > make it - hopefully - even clearer I try to describe the step that are > > necessary to enable IPA for trust and to create trust to AD domains. > > > > I assume that we start from a running IPAv2 setup with replication: > > > > 1. Update IPA to v3, install the new packages, run everything that is > > needed for the update. This step will not create anything related to > > trust (only the needed python code and config file templates are > > installed) > > > > 2. Call ipa-adtrust-install to enable IPA to handle trust, this will > > - create the samba configuration > > - add cn=trust to the DIT > > - generate a domain SID and stores it in the DIT > > - add the well know administrator and admin group SIDs to the admin user > > and the admins group respectively > > - activate the CLDAP directory server plugin > > - add DNA configuration to automatically add SIDs to users and groups > > on the server where ipa-adtrust-install > At this point 'ipa trust ...' set of commands mentioned in (5) will be > able to operate because we'll have enough information about our own > domain to proceed with trusts to other domains. > > > > 3. Now SIDs can be added to users and groups, this can be done > > - as Simo mentioned above with the help of a directory server task to > > generate them as fast a possible > > - but if there are concerns about the traffic caused by the > > replication, this can also be done by an external script, with a > > rate limitation or during non-office hours > > this process might take some time, but since it has to be done only once > > I think it is even acceptable if it needs some days to finish, as long > > as it is documented :-) > Agree. > > There are two separate phases here, actually: > - trust creation > - trust usage > > Normal usage is possible after step (3), creating trusts is possible > before (3), albeight it wouldn't be quite usable besides administrator > account. > > > 4. Now ipa-adtrust-install can be called on other IPA servers which will > > now skip the configuration steps which can already be found in the > > replicated tree, some of the remaining ones are: > > - create the samba configuration > > - activate the CLDAP directory server plugin > > - add SID DNA configuration with an empty range > ACK. There is also need to add DNS records to get these IPA servers in > use for AD discovery. This is actually critical, the other servers need to have the DNA plugin properly configured, otherwise creating a user on another server will not add the SID, and we will have some users missing them. So I am thinking that we have 2 strategies here: - Require we run a ipa-trust-prepare script on all masters before we populate users - Add a new plugin, enabled by default at upgrade time, that is able to detect trust were activated, and when that happens it automatically adds the CLDAP and DNA plugins needed configuration. There is also the problem of the samba configuration (Still the server will need a restart so it is not a complete solution I guess). The second would be nice, but it seem a lot more complex than what we can afford for a first release and still has some gotchas. Also we need to consider that we may not want to make all servers expose samba and cldap. In most cases admins would want to enable only servers that are close to the AD domain they want to trust. So we need the DNA plugin configured everywhere, because it works at user creation, but we need to be able to *not* configure samba, cldap (and _msdcs DNS records) where not wanted. We will also need a way to show which servers are 'trust' enabled so that admins can easily inspect their setup. > > 5. Finally a trust to an AD domain can be created my calling 'net rpc > > trust create ...' (Alexander is working on the integration into the ipa > > utility so that it will be more like 'ipa adtrust-create' or similar). > Yep. ack to all the rest. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Feb 2 17:13:01 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 02 Feb 2012 18:13:01 +0100 Subject: [Freeipa-devel] [PATCH] 074 Automember UI - default groups Message-ID: <4F2AC41D.5060508@redhat.com> In this patch was implemented and added a control for defining default automember groups. There is a difference from UXD spec. In the spec the control was placed below table in the search facet. This was not working well with the combobox in the control. Open combobox requires some space below it. As it was placed at the bottom of the page it created unwanted blank space and forced showing scrollbars. Moving the control above the table solves the problem without rewriting combobox logic. It can be rewritten and moved down later. https://fedorahosted.org/freeipa/ticket/2195 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0074-Automember-UI-default-groups.patch Type: text/x-patch Size: 14414 bytes Desc: not available URL: From jcholast at redhat.com Thu Feb 2 17:22:23 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 02 Feb 2012 18:22:23 +0100 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4F202B89.2090109@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> <4EEA60A6.90109@redhat.com> <4F0169DD.90105@redhat.com> <4F1D9F73.4020209@redhat.com> <4F1F2C8D.2070901@redhat.com> <4F1FBF92.6040305@redhat.com> <4F202B89.2090109@redhat.com> Message-ID: <4F2AC64F.10805@redhat.com> Updated & rebased the patches. I have also attached a patch that Rob made: [PATCH] Don't use sets when calculating the modlist so order is preserved. This is for the LDAP updater in particular. When adding new schema order can be important when one objectclass depends on another via SUP. Without this patch updates won't work. Dne 25.1.2012 17:19, Rob Crittenden napsal(a): >>> >>> Patch 61 you can drop the md5 and sha1 imports and import them from >>> ipalib.compat instead. >> >> Is this OK in ipapython? > > It should be, ipa-python and ipalib should be packaged together so I > think it is safe. Turns out this change breaks ipa-upgradeconfig. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-59.2-ssh-ldap-schema.patch Type: text/x-patch Size: 5495 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-60.2-ssh-ldap-aci.patch Type: text/x-patch Size: 8789 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-61.2-ssh-host-user-plugins.patch Type: text/x-patch Size: 24652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-62.2-ipa-client-install-api.patch Type: text/x-patch Size: 4112 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-63.2-ipa-client-install-nsupdate.patch Type: text/x-patch Size: 2213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-64.2-ssh-install-update-keys.patch Type: text/x-patch Size: 9674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-65.3-ssh-install-config-sshd.patch Type: text/x-patch Size: 11277 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-66.1-parameter-bytes-base64.patch Type: text/x-patch Size: 3734 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-67.1-ssh-platform-service.patch Type: text/x-patch Size: 4047 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-ldap-updater-fix.patch Type: text/x-patch Size: 1815 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 2 20:35:42 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Feb 2012 21:35:42 +0100 Subject: [Freeipa-devel] [PATCH] 208 Fix raw format for ACI commands Message-ID: <1328214942.4284.0.camel@priserak> ACI plugins (permission, selfservice and delegation) were not prepared to serve ACIs in a raw format, i.e. raw "aci" attribute taken from LDAP. This patch fixes all these plugins and their commands to provide provide this format. Few ACI raw format unit tests were added for all these plugins. https://fedorahosted.org/freeipa/ticket/2010 https://fedorahosted.org/freeipa/ticket/2223 https://fedorahosted.org/freeipa/ticket/2228 https://fedorahosted.org/freeipa/ticket/2232 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-208-fix-raw-format-for-aci-commands.patch Type: text/x-patch Size: 19686 bytes Desc: not available URL: From mkosek at redhat.com Fri Feb 3 08:42:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Feb 2012 09:42:49 +0100 Subject: [Freeipa-devel] [PATCH] 209 Improve migration help Message-ID: <1328258569.21801.0.camel@balmora.brq.redhat.com> Improve migration help topic so that it easier understandable: - Add missing list of Topic commands - Add one more example to demonstrate migration abilities - Add breaks to too long lines to improve readibility https://fedorahosted.org/freeipa/ticket/2174 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-209-improve-migration-help.patch Type: text/x-patch Size: 3346 bytes Desc: not available URL: From pvoborni at redhat.com Fri Feb 3 10:43:01 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Feb 2012 11:43:01 +0100 Subject: [Freeipa-devel] [PATCH] 075 Automember UI - Fixed I18n labels Message-ID: <4F2BBA35.3080606@redhat.com> Hard-coded labels in Automember UI have been moved into internal.py to allow translation. Note: should be final patch for #2195 https://fedorahosted.org/freeipa/ticket/2195 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0075-Automember-UI-Fixed-I18n-labels.patch Type: text/x-patch Size: 10734 bytes Desc: not available URL: From mkosek at redhat.com Fri Feb 3 14:22:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Feb 2012 15:22:59 +0100 Subject: [Freeipa-devel] [PATCH] 210-213 Fix DNS record param issues Message-ID: <1328278979.21801.5.camel@balmora.brq.redhat.com> Endi found several issues with the new per-type DNS API. This set of patches fixes them all. Testing should be quite straightforward, all linked tickets contain failing scenarios. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-210-fix-txt-record-parsing.patch Type: text/x-patch Size: 2735 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-211-fix-nsec-record-conversion.patch Type: text/x-patch Size: 10635 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-212-add-srv-record-target-validator.patch Type: text/x-patch Size: 2505 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-213-add-data-field-for-a6-record.patch Type: text/x-patch Size: 7100 bytes Desc: not available URL: From rcritten at redhat.com Fri Feb 3 14:55:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Feb 2012 09:55:26 -0500 Subject: [Freeipa-devel] [PATCH] 204 Improve netgroup-add error messages In-Reply-To: <1328111085.24522.4.camel@balmora.brq.redhat.com> References: <1328111085.24522.4.camel@balmora.brq.redhat.com> Message-ID: <4F2BF55E.9050402@redhat.com> Martin Kosek wrote: > These two situations in netgroup-add need to be distinguished: > 1) Netgroup cannot be added because a hostgroup with the same name > created a colliding managed netgroup > 2) Another native netgroup with the same name exists > > This patch checks the colliding netgroup and raise appropriate > error message based on this finding. > > https://fedorahosted.org/freeipa/ticket/2069 ACK From rcritten at redhat.com Fri Feb 3 15:05:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Feb 2012 10:05:33 -0500 Subject: [Freeipa-devel] [PATCH] 207 Improve dnszone-add error message In-Reply-To: <1328187441.24421.10.camel@balmora.brq.redhat.com> References: <1328187441.24421.10.camel@balmora.brq.redhat.com> Message-ID: <4F2BF7BD.1040105@redhat.com> Martin Kosek wrote: > When a new DNS record is being added to DNS zone via command > ipa dnsrecord-add ZONE @ > and the target ZONE does not exist it returns ObjectclassViolation > which may confuse users. Make sure that standard DNS Zone NotFound > exception is returned. > > https://fedorahosted.org/freeipa/ticket/2270 nack, I show two test failures with this patch. ====================================================================== FAIL: test_dns[29]: dnsrecord_add: Add MX record to zone u'dnszone.test' using dnsrecord_add ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/rcrit/redhat/freeipa-review/tests/test_xmlrpc/xmlrpc_test.py", line 220, in func = lambda: self.check(nice, test) File "/home/rcrit/redhat/freeipa-review/tests/test_xmlrpc/xmlrpc_test.py", line 236, in check self.check_output(nice, cmd, args, options, expected) File "/home/rcrit/redhat/freeipa-review/tests/test_xmlrpc/xmlrpc_test.py", line 264, in check_output assert_deepequal(expected, got, nice) File "/home/rcrit/redhat/freeipa-review/tests/util.py", line 320, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/home/rcrit/redhat/freeipa-review/tests/util.py", line 314, in assert_deepequal doc, sorted(missing), sorted(extra), expected, got, stack AssertionError: assert_deepequal: dict keys mismatch. test_dns[29]: dnsrecord_add: Add MX record to zone u'dnszone.test' using dnsrecord_add missing keys = ['nsrecord'] extra keys = [] expected = {'objectclass': [u'top', u'idnsrecord', u'idnszone'], 'dn': u'idnsname=dnszone.test,cn=dns,dc=greyoak,dc=com', 'mxrecord': [u'0 ns1.dnszone.test.'], 'nsrecord': [u'ns1.dnszone.test.'], 'idnsname': [u'dnszone.test']} got = {'objectclass': (u'top', u'idnsrecord'), 'dn': u'idnsname=@,idnsname=dnszone.test,cn=dns,dc=greyoak,dc=com', 'mxrecord': (u'0 ns1.dnszone.test.',), 'idnsname': (u'@',)} path = ('result',) ====================================================================== FAIL: test_dns[33]: dnsrecord_add: Add LOC record to zone u'dnszone.test' using dnsrecord_add ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/rcrit/redhat/freeipa-review/tests/test_xmlrpc/xmlrpc_test.py", line 220, in func = lambda: self.check(nice, test) File "/home/rcrit/redhat/freeipa-review/tests/test_xmlrpc/xmlrpc_test.py", line 236, in check self.check_output(nice, cmd, args, options, expected) File "/home/rcrit/redhat/freeipa-review/tests/test_xmlrpc/xmlrpc_test.py", line 264, in check_output assert_deepequal(expected, got, nice) File "/home/rcrit/redhat/freeipa-review/tests/util.py", line 320, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/home/rcrit/redhat/freeipa-review/tests/util.py", line 314, in assert_deepequal doc, sorted(missing), sorted(extra), expected, got, stack AssertionError: assert_deepequal: dict keys mismatch. test_dns[33]: dnsrecord_add: Add LOC record to zone u'dnszone.test' using dnsrecord_add missing keys = ['nsrecord'] extra keys = [] expected = {'dn': u'idnsname=dnszone.test,cn=dns,dc=greyoak,dc=com', 'nsrecord': [u'ns1.dnszone.test.'], 'objectclass': [u'top', u'idnsrecord', u'idnszone'], 'locrecord': [u'49 11 42.400 N 16 36 29.600 E 227.64'], 'mxrecord': [u'0 ns1.dnszone.test.'], 'idnsname': [u'dnszone.test']} got = {'locrecord': (u'49 11 42.400 N 16 36 29.600 E 227.64',), 'objectclass': (u'top', u'idnsrecord'), 'dn': u'idnsname=@,idnsname=dnszone.test,cn=dns,dc=greyoak,dc=com', 'mxrecord': (u'0 ns1.dnszone.test.',), 'idnsname': (u'@',)} path = ('result',) From mkosek at redhat.com Fri Feb 3 15:07:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Feb 2012 16:07:39 +0100 Subject: [Freeipa-devel] [PATCH] 204 Improve netgroup-add error messages In-Reply-To: <4F2BF55E.9050402@redhat.com> References: <1328111085.24522.4.camel@balmora.brq.redhat.com> <4F2BF55E.9050402@redhat.com> Message-ID: <1328281659.21801.6.camel@balmora.brq.redhat.com> On Fri, 2012-02-03 at 09:55 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > These two situations in netgroup-add need to be distinguished: > > 1) Netgroup cannot be added because a hostgroup with the same name > > created a colliding managed netgroup > > 2) Another native netgroup with the same name exists > > > > This patch checks the colliding netgroup and raise appropriate > > error message based on this finding. > > > > https://fedorahosted.org/freeipa/ticket/2069 > > ACK Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Fri Feb 3 15:15:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Feb 2012 16:15:53 +0100 Subject: [Freeipa-devel] [PATCH] 207 Improve dnszone-add error message In-Reply-To: <4F2BF7BD.1040105@redhat.com> References: <1328187441.24421.10.camel@balmora.brq.redhat.com> <4F2BF7BD.1040105@redhat.com> Message-ID: <1328282153.21801.8.camel@balmora.brq.redhat.com> On Fri, 2012-02-03 at 10:05 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > When a new DNS record is being added to DNS zone via command > > ipa dnsrecord-add ZONE @ > > and the target ZONE does not exist it returns ObjectclassViolation > > which may confuse users. Make sure that standard DNS Zone NotFound > > exception is returned. > > > > https://fedorahosted.org/freeipa/ticket/2270 > > nack, I show two test failures with this patch. > Thanks for catching this. It was a stupid mistake, possibly from some clever late fix. Fixed patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-207-2-improve-dnszone-add-error-message.patch Type: text/x-patch Size: 1438 bytes Desc: not available URL: From abokovoy at redhat.com Fri Feb 3 15:19:21 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 3 Feb 2012 17:19:21 +0200 Subject: [Freeipa-devel] [PATCH] 210-213 Fix DNS record param issues In-Reply-To: <1328278979.21801.5.camel@balmora.brq.redhat.com> References: <1328278979.21801.5.camel@balmora.brq.redhat.com> Message-ID: <20120203151921.GP11943@redhat.com> On Fri, 03 Feb 2012, Martin Kosek wrote: > Endi found several issues with the new per-type DNS API. This set of > patches fixes them all. Testing should be quite straightforward, all > linked tickets contain failing scenarios. > > Martin > >From 9a4d5f97866cd9c28d5040a88c3e6626a073417c Mon Sep 17 00:00:00 2001 > From: Martin Kosek > Date: Fri, 3 Feb 2012 10:01:27 +0100 > Subject: [PATCH 1/4] Fix TXT record parsing > > TXT record validation fails to parse the record if it contains > spaces. Standard DNS part parser uses a space to divide record > parts. A special parser thus need to be implemented for this RR > type. > > https://fedorahosted.org/freeipa/ticket/2306 ACK. > >From bd417d9c2ee5355d2ac1a40a09ad1d1b5630eba5 Mon Sep 17 00:00:00 2001 > From: Martin Kosek > Date: Fri, 3 Feb 2012 10:41:21 +0100 > Subject: [PATCH 2/4] Fix NSEC record conversion > > NSEC record needs special treatment as it is not composed from > a fixed set of DNS parts divided by space, but it contains > a multivalued DNS part "types" containing a list of RR types > it covers. > > There was already a special method for parsing raw NSEC record > to DNS parts, but the other direction was missing. This patch > adds special NSEC convertor to fix this issue. > > https://fedorahosted.org/freeipa/ticket/2307 ACK > >From 9b6e99aad423cba821618fd7da1d37672649a24f Mon Sep 17 00:00:00 2001 > From: Martin Kosek > Date: Fri, 3 Feb 2012 14:25:53 +0100 > Subject: [PATCH 3/4] Add SRV record target validator > > Add missing SRV record target validator to filter out possible > user errors. > > https://fedorahosted.org/freeipa/ticket/2308 ACK > >From 7cadf3a0e739372f86184bf93c636f5b4e99a9cc Mon Sep 17 00:00:00 2001 > From: Martin Kosek > Date: Fri, 3 Feb 2012 14:52:34 +0100 > Subject: [PATCH 4/4] Add data field for A6 record > > Since A6 is an obsolete RR type, no DNS part option was created. > This is, however, not consistent with the rest of per-type API > and may cause problems. This patch adds at least a DNS part for > raw A6 record data so that the record type is treated consistently. > > https://fedorahosted.org/freeipa/ticket/2309 ACK -- / Alexander Bokovoy From rcritten at redhat.com Fri Feb 3 15:25:28 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Feb 2012 10:25:28 -0500 Subject: [Freeipa-devel] [PATCH] 208 Fix raw format for ACI commands In-Reply-To: <1328214942.4284.0.camel@priserak> References: <1328214942.4284.0.camel@priserak> Message-ID: <4F2BFC68.8060200@redhat.com> Martin Kosek wrote: > ACI plugins (permission, selfservice and delegation) were not > prepared to serve ACIs in a raw format, i.e. raw "aci" attribute > taken from LDAP. This patch fixes all these plugins and their > commands to provide provide this format. Few ACI raw format unit > tests were added for all these plugins. > > https://fedorahosted.org/freeipa/ticket/2010 > https://fedorahosted.org/freeipa/ticket/2223 > https://fedorahosted.org/freeipa/ticket/2228 > https://fedorahosted.org/freeipa/ticket/2232 Showing a raw delegation entry doesn't include the cn but it does for permission and selfservice. The domain is hardcoded in the tests (glad to see this affect someone else, it often gets me). The tests otherwise work. rob From mkosek at redhat.com Fri Feb 3 15:28:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Feb 2012 16:28:19 +0100 Subject: [Freeipa-devel] [PATCH] 210-213 Fix DNS record param issues In-Reply-To: <20120203151921.GP11943@redhat.com> References: <1328278979.21801.5.camel@balmora.brq.redhat.com> <20120203151921.GP11943@redhat.com> Message-ID: <1328282899.21801.9.camel@balmora.brq.redhat.com> On Fri, 2012-02-03 at 17:19 +0200, Alexander Bokovoy wrote: > On Fri, 03 Feb 2012, Martin Kosek wrote: > > Endi found several issues with the new per-type DNS API. This set of > > patches fixes them all. Testing should be quite straightforward, all > > linked tickets contain failing scenarios. > > > > Martin > > > >From 9a4d5f97866cd9c28d5040a88c3e6626a073417c Mon Sep 17 00:00:00 2001 > > From: Martin Kosek > > Date: Fri, 3 Feb 2012 10:01:27 +0100 > > Subject: [PATCH 1/4] Fix TXT record parsing > > > > TXT record validation fails to parse the record if it contains > > spaces. Standard DNS part parser uses a space to divide record > > parts. A special parser thus need to be implemented for this RR > > type. > > > > https://fedorahosted.org/freeipa/ticket/2306 > ACK. > > > > >From bd417d9c2ee5355d2ac1a40a09ad1d1b5630eba5 Mon Sep 17 00:00:00 2001 > > From: Martin Kosek > > Date: Fri, 3 Feb 2012 10:41:21 +0100 > > Subject: [PATCH 2/4] Fix NSEC record conversion > > > > NSEC record needs special treatment as it is not composed from > > a fixed set of DNS parts divided by space, but it contains > > a multivalued DNS part "types" containing a list of RR types > > it covers. > > > > There was already a special method for parsing raw NSEC record > > to DNS parts, but the other direction was missing. This patch > > adds special NSEC convertor to fix this issue. > > > > https://fedorahosted.org/freeipa/ticket/2307 > ACK > > > >From 9b6e99aad423cba821618fd7da1d37672649a24f Mon Sep 17 00:00:00 2001 > > From: Martin Kosek > > Date: Fri, 3 Feb 2012 14:25:53 +0100 > > Subject: [PATCH 3/4] Add SRV record target validator > > > > Add missing SRV record target validator to filter out possible > > user errors. > > > > https://fedorahosted.org/freeipa/ticket/2308 > ACK > > > >From 7cadf3a0e739372f86184bf93c636f5b4e99a9cc Mon Sep 17 00:00:00 2001 > > From: Martin Kosek > > Date: Fri, 3 Feb 2012 14:52:34 +0100 > > Subject: [PATCH 4/4] Add data field for A6 record > > > > Since A6 is an obsolete RR type, no DNS part option was created. > > This is, however, not consistent with the rest of per-type API > > and may cause problems. This patch adds at least a DNS part for > > raw A6 record data so that the record type is treated consistently. > > > > https://fedorahosted.org/freeipa/ticket/2309 > ACK > Pushed all to master, ipa-2-2. Martin From rcritten at redhat.com Fri Feb 3 15:29:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Feb 2012 10:29:57 -0500 Subject: [Freeipa-devel] [PATCH] 207 Improve dnszone-add error message In-Reply-To: <1328282153.21801.8.camel@balmora.brq.redhat.com> References: <1328187441.24421.10.camel@balmora.brq.redhat.com> <4F2BF7BD.1040105@redhat.com> <1328282153.21801.8.camel@balmora.brq.redhat.com> Message-ID: <4F2BFD75.5060603@redhat.com> Martin Kosek wrote: > On Fri, 2012-02-03 at 10:05 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> When a new DNS record is being added to DNS zone via command >>> ipa dnsrecord-add ZONE @ >>> and the target ZONE does not exist it returns ObjectclassViolation >>> which may confuse users. Make sure that standard DNS Zone NotFound >>> exception is returned. >>> >>> https://fedorahosted.org/freeipa/ticket/2270 >> >> nack, I show two test failures with this patch. >> > > Thanks for catching this. It was a stupid mistake, possibly from some > clever late fix. Fixed patch attached. > > Martin ACK From rcritten at redhat.com Fri Feb 3 15:32:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Feb 2012 10:32:18 -0500 Subject: [Freeipa-devel] [PATCH] 209 Improve migration help In-Reply-To: <1328258569.21801.0.camel@balmora.brq.redhat.com> References: <1328258569.21801.0.camel@balmora.brq.redhat.com> Message-ID: <4F2BFE02.8080505@redhat.com> Martin Kosek wrote: > Improve migration help topic so that it easier understandable: > - Add missing list of Topic commands > - Add one more example to demonstrate migration abilities > - Add breaks to too long lines to improve readibility > > https://fedorahosted.org/freeipa/ticket/2174 ACK From mkosek at redhat.com Fri Feb 3 15:32:34 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Feb 2012 16:32:34 +0100 Subject: [Freeipa-devel] [PATCH] 207 Improve dnszone-add error message In-Reply-To: <4F2BFD75.5060603@redhat.com> References: <1328187441.24421.10.camel@balmora.brq.redhat.com> <4F2BF7BD.1040105@redhat.com> <1328282153.21801.8.camel@balmora.brq.redhat.com> <4F2BFD75.5060603@redhat.com> Message-ID: <1328283154.21801.10.camel@balmora.brq.redhat.com> On Fri, 2012-02-03 at 10:29 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2012-02-03 at 10:05 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> When a new DNS record is being added to DNS zone via command > >>> ipa dnsrecord-add ZONE @ > >>> and the target ZONE does not exist it returns ObjectclassViolation > >>> which may confuse users. Make sure that standard DNS Zone NotFound > >>> exception is returned. > >>> > >>> https://fedorahosted.org/freeipa/ticket/2270 > >> > >> nack, I show two test failures with this patch. > >> > > > > Thanks for catching this. It was a stupid mistake, possibly from some > > clever late fix. Fixed patch attached. > > > > Martin > > ACK Pushed to master, ipa-2-2. Martin From rcritten at redhat.com Fri Feb 3 15:45:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Feb 2012 10:45:38 -0500 Subject: [Freeipa-devel] [PATCH] 208 Fix raw format for ACI commands In-Reply-To: <4F2BFC68.8060200@redhat.com> References: <1328214942.4284.0.camel@priserak> <4F2BFC68.8060200@redhat.com> Message-ID: <4F2C0122.1080008@redhat.com> Rob Crittenden wrote: > Martin Kosek wrote: >> ACI plugins (permission, selfservice and delegation) were not >> prepared to serve ACIs in a raw format, i.e. raw "aci" attribute >> taken from LDAP. This patch fixes all these plugins and their >> commands to provide provide this format. Few ACI raw format unit >> tests were added for all these plugins. >> >> https://fedorahosted.org/freeipa/ticket/2010 >> https://fedorahosted.org/freeipa/ticket/2223 >> https://fedorahosted.org/freeipa/ticket/2228 >> https://fedorahosted.org/freeipa/ticket/2232 > > Showing a raw delegation entry doesn't include the cn but it does for > permission and selfservice. > > The domain is hardcoded in the tests (glad to see this affect someone > else, it often gets me). The tests otherwise work. Martin reminded me that selfservice entries exist only as an ACI which is why no cn is displayed. ACK if the tests are fixed. rob From rcritten at redhat.com Fri Feb 3 15:52:05 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 Feb 2012 10:52:05 -0500 Subject: [Freeipa-devel] [PATCH] 206 Improve password change error message In-Reply-To: <1328181041.24421.9.camel@balmora.brq.redhat.com> References: <1328181041.24421.9.camel@balmora.brq.redhat.com> Message-ID: <4F2C02A5.7040007@redhat.com> Martin Kosek wrote: > User always receives the same error message if he changes his password > via "ipa passwd" command and the new password fails configured > password policy. He then has to investigate on his own the actual > reason why was the policy violated. This patch improves our SLAPI PWD > plugins to provide a better error message explaining the violation > reason. > > https://fedorahosted.org/freeipa/ticket/2067 Excellent work, ACK. rob From mkosek at redhat.com Fri Feb 3 15:52:27 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Feb 2012 16:52:27 +0100 Subject: [Freeipa-devel] [PATCH] 209 Improve migration help In-Reply-To: <4F2BFE02.8080505@redhat.com> References: <1328258569.21801.0.camel@balmora.brq.redhat.com> <4F2BFE02.8080505@redhat.com> Message-ID: <1328284347.21801.12.camel@balmora.brq.redhat.com> On Fri, 2012-02-03 at 10:32 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > Improve migration help topic so that it easier understandable: > > - Add missing list of Topic commands > > - Add one more example to demonstrate migration abilities > > - Add breaks to too long lines to improve readibility > > > > https://fedorahosted.org/freeipa/ticket/2174 > > ACK Pushed to master, ipa-2-2. Martin From abokovoy at redhat.com Fri Feb 3 15:53:04 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 3 Feb 2012 17:53:04 +0200 Subject: [Freeipa-devel] [PATCH] 0040-0042 Fedora packages fixes merge Message-ID: <20120203155304.GQ11943@redhat.com> Hi, attached are three patches that differentiate current freeipa-2.1.4 builds in Fedora 16/Rawhide from upstream. These are primarily to adopt to systemd and python-ldap changes. 1. freeipa-abbra-0040-inifiles-support.patch introduces a way to modify sectioned inifiles used by freedesktop.org software like systemd service units. The patch also fixes a subtle bug in traditional config files handling when variables do not exist before replacement. 2. freeipa-abbra-0041-upgrade-systemd.patch introduces an upgrade script to fix common issues found when migrating from SysV to systemd and to adopt to systemd changes done recently for 389-ds (as of 1.2.10-0.8.a7 and above). freeipa.spec.in part is not included as this script is actual only for Fedora 16/Rawhide repos. 3. freeipa-abbra-0042-python-ldap-2.4.6-support.patch one-line fix to support python-ldap 2.4.6 from Rawhide. All patches are in freeipa-2.1.4-5.fc16 (.fc17) available from updates-testing (in case of F16) or directly in Rawhide. Fixes: https://fedorahosted.org/freeipa/ticket/2117 https://fedorahosted.org/freeipa/ticket/2300 -- / Alexander Bokovoy -------------- next part -------------- >From 16d3d30130215d74295e89ba5a51522eed45e180 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 1 Feb 2012 14:20:53 +0200 Subject: [PATCH 1/3] Add management of inifiles to allow manipulation of systemd units inifile_replace_variables() works similar to config_replace_variables() but allows to apply changes to specific section of an inifile. Inifiles are commonly used by freedesktop.org software and particularly used by systemd. When modifying inifile, all changes will be applied to specific section. Also fixes corner case in config_replace_variables() which would dublicate variables when adding them. --- ipapython/ipautil.py | 100 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 99 insertions(+), 1 deletions(-) diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py index 718f209b32649df23177dcab7d5105d01c0cd7bc..e141e00171cb86bec58a6be0b3e7d1f51a24faf1 100644 --- a/ipapython/ipautil.py +++ b/ipapython/ipautil.py @@ -1245,7 +1245,7 @@ $)''', re.VERBOSE) new_vars = replacevars.copy() new_vars.update(appendvars) newvars_view = set(new_vars.keys()) - set(old_values.keys()) - append_view = (set(appendvars.keys()) - set(replacevars.keys())) - set(old_values.keys()) + append_view = (set(appendvars.keys()) - newvars_view) for item in newvars_view: new_config.write("%s=%s\n" % (item,new_vars[item])) for item in append_view: @@ -1262,6 +1262,104 @@ $)''', re.VERBOSE) return old_values +def inifile_replace_variables(filepath, section, replacevars=dict(), appendvars=dict()): + """ + Take a section-structured key=value based configuration file, and write new version + with certain values replaced or appended within the section + + All (key,value) pairs from replacevars and appendvars that were not found + in the configuration file, will be added there. + + It is responsibility of a caller to ensure that replacevars and + appendvars do not overlap. + + It is responsibility of a caller to back up file. + + returns dictionary of affected keys and their previous values + + One have to run restore_context(filepath) afterwards or + security context of the file will not be correct after modification + """ + pattern = re.compile(''' +(^ + \[ + (?P
.+) \] + (\s+((\#|;).*)?)? +$)|(^ + \s* + (?P