[Freeipa-devel] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past
If you are seeing clock skew errors in /var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then you will need to verify the time/date of the server to make sure NTP isn't freaked out. If the system date is correct, it is possible that the change numbergenerator has skewed.[01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949 op=7 repl="dc=example,dc=com": Excessive clock skew from supplier RUV[01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment limit exceeded; value - 1448518, limit - 86400[01/Feb/2014:14:42:06 -0800] - CSN generator's state:[01/Feb/2014:14:42:06 -0800] - replica id: 115[01/Feb/2014:14:42:06 -0800] - sampled time: 1391294526[01/Feb/2014:14:42:06 -0800] - local offset: 0[01/Feb/2014:14:42:06 -0800] - remote offset: 0[01/Feb/2014:14:42:06 -0800] - sequence number: 55067The following NsState_Script should be used to determine whether the change number generator has jumped significantly from the real time/date.https://github.com/richm/scripts/blob/master/readNsState.pyThe usage for the script works like this:[r...@ipaserver.ops jaquino]# ./readNsState.py /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldifnsState is cwBGPfBSAQACAA==Little EndianFor replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 115 Sampled Time : 1391476038 Gen as csn : 52f03d4600020115 Time as str : Mon Feb 3 17:07:18 2014 Local Offset : 0 Remote Offset : 1 Seq. num : 2 System time : Mon Feb 3 17:09:11 2014 Diff in sec. : 113 Day:sec diff : 0:113If the output from the above command is over a day or more out of sync, then the reason is because the CSN generator has become grossly skewed. It will be necessary to perform the following steps to recover.How to resolve this issue• 1: Select an ipa server to be authoritative and write the contents of its database to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -a /tmp/master-389.ldif Note that without the -r option it is deliberately ommiting the tainted replication data which contains the bad CSNs• 2: On the ipa server, shutdown its dirsrv daemon down so that you can reset the attribute responsible for the serial generation, and so that you can re-initialize its db from the known good ldif On the master supplier: ipactl stop• 3: Sanitize the dse.ldif Configuration File On the master supplier: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwA3QPBSAQABAA== Delete the entire line• 3.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^ / {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv new.dse.ldif backup the old dse.ldif and replace it with the new one: # mv dse.ldif dse.saved.ldif # mv new.dse.ldif dse.ldif• 4: Import the data from the known good ldif. This will mark all the changes with CSNs that match the current time/date stamps On the master supplier: chmod 644 /tmp/master-389.ldif /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i /tmp/master-389.ldif• 5: Restart the ipa daemons on the master supplier #ipactl start• 6: When the daemon starts, it will see that it does not have an nsState and will write new CSN's to -all- of the newly imported good data with today's timetamp, we need to take that data and write -it- out to an ldif file On the master supplier: /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot -r -a /tmp/replication-master-389.ldif ^ the -r tells it to include all replica data which includes the newly blessed CSN data transfer the file to all of the ipa servers in the fleet• 7: Now we must re-initialize _every other_ ipa consumer server in the fleet with the new good data. Steps 7-10 need to be done 1 at a time on each ipa consumer server ipactl stop• 8: Sanitize the dse.ldif Configuration File On the ipa server: edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and remove the nsState attribute from the replica config entry You DO NOT want to remove the nsState from: dn: cn=uniqueid generator,cn=config The stanza you want to remove the value from is: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config The attribute will look like this: nsState:: cwA3QPBSAQABAA== Delete the entire line• 8.1: Remove traces of stale CSN tracking in the Replica Agreements themeselves File
Re: [Freeipa-devel] Planning FreeIPA Upstream Doc changes
On Aug 8, 2013, at 12:19 AM, Martin Kosek mko...@redhat.com wrote: Hello all, This is a follow up for upstream doc maintenance questions I had on freeipa-users in June: http://www.redhat.com/archives/freeipa-users/2013-June/msg00202.html As Content Writer taking care of the User Guide (on docs.fedoraproject.org) no longer has resources to maintain it and the guide become partially outdated. FreeIPA development team and community will need to take over as it was agreed this is of a great benefit to the project. I would like to propose a plan to revive the guide: 1) Move FreeIPA Guide out of current Deon's git tree (hosted on https://fedorahosted.org/freeipa-guide/) to git owned by FreeIPA. There are 2 options: A) Host and package it in current FreeIPA git along with a code. Handling the doc patches would be much simpler, however it would mean, that the docs for next version would need to be prepared at the time when code is ready for release which could either postpone the release and release with incomplete doc (this introduces question how should the git be tagged/branched). B) Add a new git tree to FreeIPA fedorahosted account (freeipa/docs.git) and release the docs asynchronously to the code (there could be of course a preliminary version on FreeIPA.org site). I was already thinking about options to seamlessly integrate an RPM with docs to FreeIPA Web UI which could then provide relevant help links from the UI dialogs to the right spots of documentation. - so far, it seems that option B) will get us more flexibility and would avoid people contributing to the code only downloading also the doc. WHEN: this step would be right after the plan is acknowledged ^ +1 And I agree that a preliminary should be hosted on the FreeIPA.org project portal rather than the fedora documentation site. It feels more natural that way. Ideally, it should be trivial to check out or grab the relevant rpm for a given version as we move forward into new releases, that way an admin can view the doc that refers specifically to their running release rather than be confused about up-to-date features that may not exist on theirs. 2) Update the guide to match FreeIPA 3.3 - currently, the guide is approximately on FreeIPA 3.1 level - I filed Trac tickets for gaps I identified in the guide: https://fedorahosted.org/freeipa/milestone/Revive%20FreeIPA%20guide - I would keep the guide in Docbook format unless there are strong reasons to use other format and avoid loosing information. It is very easy to generate all sorts of formats (html, pdf, epub) out of Docbook with publican utility which is packaged in Fedora - easy build in koji - ideally, editorial would be done by a potential contractor we identified WHEN: most should be done in August, some can be done in September 3) Host the result on FreeIPA.org - we used to release to Fedora documentation portal, but I am thinking it would be more natural to host a project site on project portal instead of Fedora Documentation which rather holds general Fedora infrastructure books. It may be also more intuitive for users to find it on FreeIPA.org than on Fedora docs. - we can take advantage of publican and build a doc site like docs.freeipa.org which would held publican-managed doc site with our guides. I tried to play with publican and this is a first PoC result: http://mkosek.fedorapeople.org/publican_site/ - I would prefer if our generated user guides (including current Extending guide hosted on abbra.fedorapeople.org site) use Docbook + be integrated in the site + wiki to have them all under the same roof with consistent look WHEN: Before FreeIPA 3.4 is released ^+1 I've always found it a little awkward to hunt docs down at the fedora documentation portal. 4) Start maintaining and releasing User guide with FreeIPA releases - revive Affects doc Trac ticket flag and make sure that Doc is updated along with RFEs and bugfixes - the process of tracking and doing the doc updates and changes is essential in order to keep the doc updated and useful for our users - ideally, editorial would be done by a contractor WHEN: Before 3.4 is release Any ideas or comments very welcome. Thanks, Martin Thanks carrying the torch! -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0043 Allow-PKI-CA-Replica-Installs-when-CRL-exceeds-default
Due to a limitation with 389 DS, the nsslapd-maxbersize cannot be set dynamically. This causes an issue during IPA PKI-CA Replica installs, when the master has a CRL that exceeds the default limit. The cainstance.py code attempts to set this value prior to performing the initial PKI-CA replication, however, since the value cannot be set dynamically, the installation fails. This patch works around the issue by adding the ldif to the original initialization values bootstrapped by the call to setup-ds.pl FreeIPA Ticket: https://fedorahosted.org/freeipa/ticket/3314 Upstream 389 Ticket: https://fedorahosted.org/389/ticket/542 Keeping your head in the cloud ~ JR Aquino Senior Information Security Specialist, Technical Operations T: +1 805 690 3478 | F: +1 805 879 3730 | M: +1 805 717 0365 GIAC Certified Exploit Researcher and Advanced Penetration Tester | GIAC WebApplication Penetration Tester | GIAC Certified Incident Handler jr.aqu...@citrix.com [cid:ba63f4c4-1eef-428b-adb2-ab9598cbdf0e@citrixonline.com] Powering mobile workstyles and cloud services inline: image002.jpg binhFVYuqyWNC.bin Description: freeipa-jraquino-0043-Allow-PKI-CA-Replica-Installs-when-CRL-exceeds-default.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0043 Allow-PKI-CA-Replica-Installs-when-CRL-exceeds-default
On Dec 19, 2012, at 2:32 PM, Simo Sorce wrote: On Wed, 2012-12-19 at 20:52 +, JR Aquino wrote: Due to a limitation with 389 DS, the nsslapd-maxbersize cannot be set dynamically. This causes an issue during IPA PKI-CA Replica installs, when the master has a CRL that exceeds the default limit. The cainstance.py code attempts to set this value prior to performing the initial PKI-CA replication, however, since the value cannot be set dynamically, the installation fails. This patch works around the issue by adding the ldif to the original initialization values bootstrapped by the call to setup-ds.pl Why are we not simply restarting the instance after setting the value ? What's in database.ldif ? What produces it ? /usr/share/pki/ca/conf/database.ldif is part of the dogtag installation and it contains the following entry: dn: cn=config changetype: modify replace: nsslapd-maxbersize nsslapd-maxbersize: 209715200 It's purpose is to increase the limit for maxbersize from 2097152 to 209715200. The ldif is inserted via the jars that are wrapped by pkisilent... So this leaves 3 options: #1 Add code to perform the ldap insert followed by a dirsrv restart into the cainstance.py code #2 Add recode the jar files from DogTag to require a dirsrv restart after the insert, but prior to the replication #3 Just initialize the dirsrv database with the correct value to begin with. 1 line fix #4 Ask 389 to allow maxbersize to be a dynamically initialized variable #3 Seemed the path of least resistance. I did take the time to code #1 and verify that it worked as well. I have a ticket open for #4 Alee hinted that the jar modifications for #2 might not be trivial... Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 492 Add options to reduce writes from KDC
On May 29, 2012, at 1:32 PM, Simo Sorce wrote: On Fri, 2012-05-25 at 18:36 -0400, Simo Sorce wrote: The original ldap driver we used up to 2.2 had 2 options admins could set to limit the amount of writes to the database on certain auditing related operations. In particular disable_last_success is really important to reduce the load on database servers. I have implemented ticket #2734 with a little twist. Instead of adding local options in krb5.conf I create global options in the LDAP tree, so that all KDCs in the domain have the same configuration. The 2 new options can be set in ipaConfigString attribute of the cn=ipaConfig object under cn=etc,$SUFFIX These are: KDC:Disable Last Success KDC:Disable Lockout The first string if set will disable updating the krbLastSuccessfulAuth field in the service/user entry. The second one will prevent changing any of the Lockout related fields and will effectively disable lockout policies. I think we may want to set the first one by default in future. The last successful auth field is not very interesting in general and is cause for a lot of writes that pressure a lot the LDAP server and get replicated everywhere with a storm multiplier effect we'd like to avoid. The lockout one instead happen only when there are failed authentication attempt, this means it never happens when keytabs are used for example. And even with users it should happen rarely enough that traking lockouts by default make leaving these writes on by default is a good tradeoff. Note that simply setting the lockout policy to never lockout is *not* equivalent to setting KDC:Disable Lockout, as it does not prevent writes to the database. I've tested setting KDC:Disable Last Success and it effectively prevent MOD operation from showing up in the server access log. Any change to these configuration options requires a reconnection from the KDC to the LDAP server, the simplest way to cause that is to restart the KDC service. Attached also rebased patch that cleanly applies on top of 2.2. Simo. -- Simo Sorce * Red Hat, Inc * New York freeipa-2.2-simo-492-1-Add-support-for-disabling-KDC-writes.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK This patch and KDC:Disable Last Success brought the writes and replications down by an order of a magnitude! ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 44 Add Automember Test to simulate logic decisions
This will be _very_ helpful for testing automember logic against potential users / hosts. This patch addes a new plugin to FreeIPA that tests automember logic decisions https://fedorahosted.org/freeipa/ticket/2535 ~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors://0/0 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrixonline.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 41-2 During ipa-client-install verify forward and reverse dns lookup of server
On Feb 28, 2012, at 10:43 AM, JR Aquino wrote: On Feb 23, 2012, at 3:56 PM, JR Aquino wrote: ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py ipa-client-install does not currently have an equivalent This patch adds valid_dns to ipapython/ipautil.py to validate foward and reverse DNS This patch adds the valid_dns test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server https://fedorahosted.org/freeipa/ticket/2438 Rebased and corrected patch freeipa-jraquino-0041-During-ipa-client-install-verify-forward-and-reve.patch NEW Rebased and corrected patch binRR6EszAHr3.bin Description: freeipa-jraquino-0041-During-ipa-client-install-verify-forward-and-reve.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 41-2 During ipa-client-install verify forward and reverse dns lookup of server
On Feb 23, 2012, at 3:56 PM, JR Aquino wrote: ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py ipa-client-install does not currently have an equivalent This patch adds valid_dns to ipapython/ipautil.py to validate foward and reverse DNS This patch adds the valid_dns test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server https://fedorahosted.org/freeipa/ticket/2438 Rebased and corrected patch bindX1RM8528Y.bin Description: freeipa-jraquino-0041-During-ipa-client-install-verify-forward-and-reve.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 42-2 Add CleanRUV Task to ipa-replica-manage del
On Feb 24, 2012, at 3:09 PM, JR Aquino wrote: ipa-replica-manage del causes tombstone entries to remain in 389 DS. This has proven to be problematic. We can automatically perform the cleanup task at the deletion time to minimize orphans and ghosts in the directory. This patch runs the cleanruv action on all masters following a delete. https://fedorahosted.org/freeipa/ticket/2303 Rebased and corrected patch attached binWWeistyorV.bin Description: freeipa-jraquino-0042-Add-CleanRUV-Task-to-ipa-replica-manage-del.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] 43 Inherit nssldap security access settings during replica install
When making adjustments to increase the bind security settings of a FreeIPA server, it is best practice to inherit those settings when installing a new replica server. Inherit the following bind security settings when performing a replica install: 'nsslapd-allow-unauthenticated-binds', 'nsslapd-require-secure-binds', 'nsslapd-allow-anonymous-access', 'nsslapd-minssf' https://fedorahosted.org/freeipa/ticket/1930 ~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrixonline.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ biniPrOqnvzLw.bin Description: freeipa-jraquino-0043-Inherit-nssldap-security-access-settings-during-replia-install.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 42-3 Add CleanRUV Task to ipa-replica-manage del
On Feb 28, 2012, at 10:44 AM, JR Aquino wrote: On Feb 24, 2012, at 3:09 PM, JR Aquino wrote: ipa-replica-manage del causes tombstone entries to remain in 389 DS. This has proven to be problematic. We can automatically perform the cleanup task at the deletion time to minimize orphans and ghosts in the directory. This patch runs the cleanruv action on all masters following a delete. https://fedorahosted.org/freeipa/ticket/2303 Rebased and corrected patch attached NACK Testing turned up a missed case for handling an exception during --force. Corrected patch attached binDrvIN7QXPR.bin Description: freeipa-jraquino-0042-Add-CleanRUV-Task-to-ipa-replica-manage-del.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 41 During ipa-client-install verify forward and reverse dns lookup of server
On Feb 27, 2012, at 8:43 AM, Rob Crittenden wrote: JR Aquino wrote: ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py ipa-client-install does not currently have an equivalent This patch adds valid_dns to ipapython/ipautil.py to validate foward and reverse DNS This patch adds the valid_dns test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server https://fedorahosted.org/freeipa/ticket/2438 Would it make sense to use verify_fqdn() from installutils.py? Ya, I thought about that initially. It cannot be done for the problem we are trying to solve. ipaserver/install/installutils.py ^ This only comes along via the installation of the server package. We'd need to move this to ipapython to be usable by the client but it would do a lot more checking and no code duplication. We are trying to make sure that ipa-client-install on Client systems are capable of doing the fwd/reverse and they don't receive any of the server rpms. That is why this patch add's this functionality to ipapython. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 41 During ipa-client-install verify forward and reverse dns lookup of server
On Feb 27, 2012, at 1:29 PM, Rob Crittenden wrote: JR Aquino wrote: On Feb 27, 2012, at 8:43 AM, Rob Crittenden wrote: JR Aquino wrote: ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py ipa-client-install does not currently have an equivalent This patch adds valid_dns to ipapython/ipautil.py to validate foward and reverse DNS This patch adds the valid_dns test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server https://fedorahosted.org/freeipa/ticket/2438 Would it make sense to use verify_fqdn() from installutils.py? Ya, I thought about that initially. It cannot be done for the problem we are trying to solve. ipaserver/install/installutils.py ^ This only comes along via the installation of the server package. We'd need to move this to ipapython to be usable by the client but it would do a lot more checking and no code duplication. We are trying to make sure that ipa-client-install on Client systems are capable of doing the fwd/reverse and they don't receive any of the server rpms. That is why this patch add's this functionality to ipapython. I was thinking move verify_fqdn entirely into ipapython which is shared between the client and server. That way we have shared code for verifying hostnames during installation. rob Reformatted patch per Rob's request to move verify_fqnd() into a shared space: ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py ipa-client-install does not currently have an equivalent This patch moves verify_fqdn() from installutils.py to ipapython/ipautil.py to validate foward and reverse DNS This patch adds the verify_fqdn() test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server binbuDwJXVibI.bin Description: freeipa-jraquino-0041-During-ipa-client-install-verify-forward-and-reve.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 957 don't always run memberof_init on re-initialize
On Feb 22, 2012, at 11:26 AM, Rob Crittenden wrote: We include memberof when doing a total sync so there is no need to re-run the memberOf task in ipa-replica-manage re-initialize unless the agreement doesn't set nsDS5ReplicatedAttributeListTotal. rob ACK Patch tested and clean ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 42 Add CleanRUV Task to ipa-replica-manage del
On Feb 24, 2012, at 3:22 PM, Simo Sorce wrote: On Fri, 2012-02-24 at 23:09 +, JR Aquino wrote: ipa-replica-manage del causes tombstone entries to remain in 389 DS. This has proven to be problematic. We can automatically perform the cleanup task at the deletion time to minimize orphans and ghosts in the directory. This patch runs the cleanruv action on all masters following a delete. https://fedorahosted.org/freeipa/ticket/2303 Uhmm I think I'll NACK this one. You should clean_ruv() in del_link() not in del_master() Simo. Rich, please correct me if I am mistaken. I don't believe you need to do clean_ruv() at all for a del_link()... it's not the individual replica agreements changing that needs purging. It is the deletion of a master that requires you to purge via clean_ruv(). From the Ticket: https://fedorahosted.org/freeipa/ticket/2303#comment:17 Changed 32 hourshttps://fedorahosted.org/freeipa/timeline?from=2012-02-23T15%3A42%3A49Zprecision=second ago by rmeggins Replying to rcrittenhttps://fedorahosted.org/freeipa/ticket/2303#comment:16: Replying to rmegginshttps://fedorahosted.org/freeipa/ticket/2303#comment:14: How so? That is, how does a 389 plugin running on server A know that server B has been removed as a replica? Well, right. Maybe it's my lack of understanding what we need to do for CLEANRUV. I'm still unclear on which host(s) we need to do anything when removing a replica. My reading of JR's comment was any host that knew anything about a replica that is deleted needs a task run. Once you create a replica, the information about that replica is propagated to all other replicas (eventually, depending on the speed of replication) and stored in the RUV tombstone entry. So when you remove a replica, you should also run the CLEANRUV task to remove the information about that replica from all other replicas. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 42 Add CleanRUV Task to ipa-replica-manage del
On Feb 24, 2012, at 3:09 PM, JR Aquino wrote: ipa-replica-manage del causes tombstone entries to remain in 389 DS. This has proven to be problematic. We can automatically perform the cleanup task at the deletion time to minimize orphans and ghosts in the directory. This patch runs the cleanruv action on all masters following a delete. https://fedorahosted.org/freeipa/ticket/2303 Instructions for testing this Patch: 0. Setup at least 3 FreeIPA replica servers. 1. Perform the following search on one of the servers to verify the Replica-ID's in the Tombstone: $ ldapsearch -xLLL -D cn=directory manager -W -b dc=example,dc=com \ '((nsuniqueid=---)(objectclass=nstombstone))' 2. Verify that all 3 servers are present in the replica list: $ ipa-replica-manage list 3. Delete one of the Replicas $ ipa-replia-manage del ipa#.example.com 4. ReRun the Tombstone search on all remaining servers to confirm the RUV entry has been cleaned: # ldapsearch -xLLL -D cn=directory manager -W -b dc=example,dc=com \ '((nsuniqueid=---)(objectclass=nstombstone))' 5. Verify that the replica server has been deleted: $ ipa-replica-manage list ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 41 During ipa-client-install verify forward and reverse dns lookup of server
ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py ipa-client-install does not currently have an equivalent This patch adds valid_dns to ipapython/ipautil.py to validate foward and reverse DNS This patch adds the valid_dns test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server https://fedorahosted.org/freeipa/ticket/2438 ~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrix.com http://www.citrixonline.com [cid:a16377d3-9b36-4f56-9cfb-cc81c3bcaecd@citrixonline.com] Access Your PC or Mac From Anywhere: www.gotomypc.comhttp://www.gotomypc.com Online Meetings Made Easy: www.gotomeeting.comhttp://www.gotomeeting.com Web Events Made Easy:www.gotowebinar.comhttp://www.gotowebinar.com Remote Support Made Easy: www.gotoassist.comhttp://www.gotoassist.com inline: image001.jpg binTZQ25RYUVf.bin Description: freeipa-jraquino-0041-During-ipa-client-install-verify-forward-and-reve.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 957 don't always run memberof_init on re-initialize
On Feb 22, 2012, at 11:26 AM, Rob Crittenden wrote: We include memberof when doing a total sync so there is no need to re-run the memberOf task in ipa-replica-manage re-initialize unless the agreement doesn't set nsDS5ReplicatedAttributeListTotal. rob freeipa-rcrit-957-memberof.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel NACK :/ When using this patch, it seems to provide the replica with nsDS5ReplicatedAttributeList but omits the nsDS5ReplicatedAttributeListTotal which causes / triggers the memberof. The current 2.1.4 has the opposite problem... It HAS nsDS5ReplicatedAttributeListTotal but does not have nsDS5ReplicatedAttributeList... So when it adds all the memberof data, the replica replicates all that info back to the master and anyone else in the replica party. -JR ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 957 don't always run memberof_init on re-initialize
On Feb 22, 2012, at 7:10 PM, Rob Crittenden wrote: JR Aquino wrote: On Feb 22, 2012, at 11:26 AM, Rob Crittenden wrote: We include memberof when doing a total sync so there is no need to re-run the memberOf task in ipa-replica-manage re-initialize unless the agreement doesn't set nsDS5ReplicatedAttributeListTotal. rob freeipa-rcrit-957-memberof.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel NACK :/ When using this patch, it seems to provide the replica with nsDS5ReplicatedAttributeList but omits the nsDS5ReplicatedAttributeListTotal which causes / triggers the memberof. The current 2.1.4 has the opposite problem... It HAS nsDS5ReplicatedAttributeListTotal but does not have nsDS5ReplicatedAttributeList... So when it adds all the memberof data, the replica replicates all that info back to the master and anyone else in the replica party. -JR 2.1.4 doesn't set nsDS5ReplicatedAttributeListTotal. Ah. I see my problem I am running my 2.1.4 with 7351780552f5d21d8d92fd2f08aedf4985a3c926 (Replication: Adjust replica installation to omit processing memberof computations) cherry picked So in that case, it means... yes your patch appropriately runs a fixup because the Total is missing without other patches. I suppose I need to do a build with both patches present to get a clear confirmation that both patches are critical to optimize the replication process. I will do a follow up tomorrow. I suspect this is an easy ack This patch doesn't add anything, it just doesn't run the memberof task if nsDS5ReplicatedAttributeListTotal is defined. Since you don't have this attribute set then that's why it isn't working. To test in 2.1.4 after the agreement is set up you can add this with something like this (untested, YMMV): # ldapmodify -x -D 'cn=directory manager' -W dn: cn=meTomaster.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsDS5ReplicatedAttributeList nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount So the steps would be: 1. Install master 2. Install replica 3. Update agreement as above (if needed) 4. Make sure patch is applied 5. ipa-replica-manage re-initialize replica.example.com You should not see a memberof storm. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 62] Tweak the session auth to reflect developer consensus.
On Feb 17, 2012, at 3:18 PM, John Dennis wrote: -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ freeipa-jdennis-0062-Tweak-the-session-auth-to-reflect-developer-consensu.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel When trying to use Adam's trick: http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ I get this: [Mon Feb 20 10:44:29 2012] [error] [client x.x.x.x] AttributeError: 'thread._local' object has no attribute 'principal' -JR ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 62] Tweak the session auth to reflect developer consensus.
On Feb 20, 2012, at 12:48 PM, John Dennis jden...@redhat.com wrote: On 02/20/2012 01:49 PM, JR Aquino wrote: On Feb 17, 2012, at 3:18 PM, John Dennis wrote: -- John Dennisjden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ freeipa-jdennis-0062-Tweak-the-session-auth-to-reflect-developer-consensu.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel When trying to use Adam's trick: http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ I get this: [Mon Feb 20 10:44:29 2012] [error] [client x.x.x.x] AttributeError: 'thread._local' object has no attribute 'principal' Works for me, both with a valid ticket and without. Did you restart the server after applying the patch? Are you up to date with all the patches? My latest pull was this morning. Maybe around 8am PST for 2-2 The only variation was your patch added. I tried to perform a batch host group add, so perhaps the specific action I was trying was part of my problem? Restarted, re kinited... -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 62] Tweak the session auth to reflect developer consensus.
On Feb 20, 2012, at 1:12 PM, John Dennis wrote: On 02/20/2012 04:00 PM, JR Aquino wrote: On Feb 20, 2012, at 12:48 PM, John Dennisjden...@redhat.com wrote: On 02/20/2012 01:49 PM, JR Aquino wrote: On Feb 17, 2012, at 3:18 PM, John Dennis wrote: -- John Dennisjden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ freeipa-jdennis-0062-Tweak-the-session-auth-to-reflect-developer-consensu.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel When trying to use Adam's trick: http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ I get this: [Mon Feb 20 10:44:29 2012] [error] [client x.x.x.x] AttributeError: 'thread._local' object has no attribute 'principal' Works for me, both with a valid ticket and without. Did you restart the server after applying the patch? Are you up to date with all the patches? My latest pull was this morning. Maybe around 8am PST for 2-2 The only variation was your patch added. I tried to perform a batch host group add, so perhaps the specific action I was trying was part of my problem? Restarted, re kinited... Oh, I have a hunch, you might be running with an outdated /etc/httpd/conf.d/ipa.conf file which gets set up when you do an install, I bet you only got half the patch update, you probably updated the python files but not the Apache configuration. Why don't you send me that file as well and let me have a peek at it. Ok. uninstalling and reinstalling definitely made the difference. I can now confirm that the patch does appear to solve my original issue with curl. I'll look through the other items listed in the comments of the patch and weigh in on what I can in there. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Freeipa-users] Announcing FreeIPA 2.1.4
On Dec 6, 2011, at 1:09 PM, Simo Sorce wrote: Thanks Rob for all the great work! I want to add just one warning that may escape users attention. Due to the need to address the CSRF attack, our command line tools (including ipa-client-install) will not work on newer servers until you upgrade those clients. The reason is that the old tools never sent the Referer header. How do you upgrade your clients if they are RHEL and the Server is Fedora? The newer tools should work w/o any issue against an old server. Unfortunately although CSRF attacks are a concern only when using the Web UI, we had to break compatibility because a browser could be subverted to use the xml-rpc interface used by the CLI tools, and we couldn't leave that hole open even though this means we are breaking backwards compatibility. So if you need to have a gradual upgrade you should start from clients (and install images) before upgrading the server. Keep in mind though that the flaw will not be fixed until you upgrade the server. So, although the flaw is not really critical (IMO), you should not delay upgrades too long in production environments and be careful on administrative clients where you use admin credentials. HTH, Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] #1794 - Speed up replica setup
On Oct 7, 2011, at 11:14 AM, Simo Sorce wrote: On Mon, 2011-10-03 at 18:17 -0400, Simo Sorce wrote: On Mon, 2011-10-03 at 16:20 -0400, Simo Sorce wrote: Newer 389ds servers have a new option to have a different set of filtered attributes from normal replication. This has been added in order to allow DS to replicate memberof attributes only during a total update so that we do not need to run a fixup memberof task on a replica at install time. This task is quite inefficient for big database and can take a long time. By replicating memberof while the DB is locked we are guaranteed the memberof list is consistent so we do not need a fixup. This patch allows to enable this feature dynamically. If the server does not yet support the new option it falls back to the previous behavior. Fixes: https://fedorahosted.org/freeipa/ticket/1794 I am sending the patch but it has been jointly developed at various stages by Nathan, JR, and me. Simo. After some thinking I found out that we cannot commit this patch until the memberof plugin is converted to use the new transaction interfaces for plugins, as otherwise it is possible to run into race conditions where the member/memberof relations are not settled if a new replica is installed while member attributes are being changed. Granted the race is quite small and unlikely but real. So please test and ack it, but we need to defer pushing to stable branches until ds copes. I think it is ok to push to master for testing, DS should have the necessary support by the time we make another stable release from master and in our test environments I am sure we will never hit the race. After some more testing I found a small bug that can cause issues in some conditions, new patch attached. Simo. ACK with 389-ds-base-1.2.10-0.4.a4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] HBAC Authorization Alternative to SSSD
Attached is a pam_python module that can be used to perform FreeIPA HBAC
authorization in conjunction with pam_python.so
(http://ace-host.stuart.id.au/russell/files/pam_python/)
I have been working on this for a while as an alternative to sssd on systems
that cannot support the sssd installation. There is no caching provided by
this code, and is intended as a proof of concept or interim fix on a small
scale.
I have been craving a more formal c code approach to this general method, but
am not adept in the c language. If anyone is feeling savoy, assistance in
creating a more formal pam module would be very appreciated!
#!/usr/bin/env python
#
# pam_pyauth.py (Python LDAP RBAC)
#
# Requires Python 2.4 or Greater
#
# Copyright (c) 2010 Jr Aquino
#
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted (subject to the limitations in the
# disclaimer below) provided that the following conditions are met:
#
#* Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
#* Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the
# distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT
# HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
# BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
# OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
# IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
import re
import os
import socket
import syslog
import ldap
class LDAP(object):
This class is used for defining ldap.conf values and searching ldap
def __init__(self):
# Initial Setup
# Read in ldap.conf
conf = open('/etc/ldap.conf', 'r').readlines()
# Setup base variables
self.binddn = None
self.bindpw = None
self.baseDN = None
self.ugroupDN = None
self.pwgroupDN = None
self.sysgroupDN = None
self.hostgroupDN = None
self.ignore_users = []
self.ldap_servers = []
# Regex Definitions
uri_check = uri_check = re.compile(r'uri ((ldap|ldaps)://(.*))')
binddn_check = re.compile(r'binddn (.*)')
bindpw_check = re.compile(r'bindpw (.*)')
basedn_check = re.compile(r'base (.*)')
ignore_check = re.compile(r'nss_initgroups_ignoreusers (.*)')
ugroup_check = re.compile(r'nss_base_group (.*)')
pwgroup_check = re.compile(r'nss_base_passwd (.*)')
sysgroup_check = re.compile(r'nss_base_systemgroup (.*)')
ldaphostgroup_check = re.compile(r'nss_base_hostgroup (.*)')
rolegroup_check = re.compile(r'nss_base_rolegroup (.*)')
ignore_users = []
ldap_servers = []
# Anonymously bind if no auth data present
self.binddn = ''
self.bindpw = ''
# Parse ldap.conf
for line in conf:
binddn_match = binddn_check.search(line)
bindpw_match = bindpw_check.search(line)
basedn_match = basedn_check.search(line)
uri_match = uri_check.search(line)
ignore_match = ignore_check.search(line)
ugroup_match = ugroup_check.search(line)
pwgroup_match = pwgroup_check.search(line)
sysgroup_match = sysgroup_check.search(line)
hostgroup_match = ldaphostgroup_check.search(line)
rolegroup_match = rolegroup_check.search(line)
if binddn_match:
self.binddn = binddn_match.group(1)
if bindpw_match:
self.bindpw = bindpw_match.group(1)
if basedn_match:
self.baseDN = basedn_match.group(1)
if uri_match:
self.ldap_servers = uri_match.group(1).split()
if ignore_match:
self.ignore_users = ignore_match.group(1).split(',')
if ugroup_match:
self.ugroupDN = ugroup_match.group(1)
if pwgroup_match:
self.pwgroupDN = pwgroup_match.group(1)
if sysgroup_match:
self.sysgroupDN = sysgroup_match.group(1)
if hostgroup_match:
self.hostgroupDN = hostgroup_match.group(1
Re: [Freeipa-devel] [PATCH] #1794 - Speed up replica setup
On Oct 3, 2011, at 3:17 PM, Simo Sorce wrote: On Mon, 2011-10-03 at 16:20 -0400, Simo Sorce wrote: Newer 389ds servers have a new option to have a different set of filtered attributes from normal replication. This has been added in order to allow DS to replicate memberof attributes only during a total update so that we do not need to run a fixup memberof task on a replica at install time. This task is quite inefficient for big database and can take a long time. By replicating memberof while the DB is locked we are guaranteed the memberof list is consistent so we do not need a fixup. This patch allows to enable this feature dynamically. If the server does not yet support the new option it falls back to the previous behavior. Fixes: https://fedorahosted.org/freeipa/ticket/1794 I am sending the patch but it has been jointly developed at various stages by Nathan, JR, and me. Simo. After some thinking I found out that we cannot commit this patch until the memberof plugin is converted to use the new transaction interfaces for plugins, as otherwise it is possible to run into race conditions where the member/memberof relations are not settled if a new replica is installed while member attributes are being changed. Granted the race is quite small and unlikely but real. So please test and ack it, but we need to defer pushing to stable branches until ds copes. I think it is ok to push to master for testing, DS should have the necessary support by the time we make another stable release from master and in our test environments I am sure we will never hit the race. Do we know which 389-ds-base incorporates the new option? I would like to test and ack, but I'm not sure if I have a fixed 389-ds-base installed. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Still failing on 5.7 with the same error........
On Sep 19, 2011, at 10:16 PM, JR Aquino wrote:
We're having significant reproducible problems with rhel 5.7 + FreeIPA
master...
I'm not sure if it is localized to us or even which side is responsible for
the error...
Has anyone had success with rhel 5.7's repo included FreeIPA client joining a
fedora based FreeIPA server?
We are essentially dead in the water at this point.
Sent from my iPad
Begin forwarded message:
From: Brett Campbell
mailto:brett.campb...@citrix.combrett.campb...@citrix.commailto:brett.campb...@citrix.com
Date: September 19, 2011 6:48:55 PM PDT
To: JR Aquino
mailto:jr.aqu...@citrix.comjr.aqu...@citrix.commailto:jr.aqu...@citrix.com
Cc: Jason Vagalatos
mailto:jason.vagala...@citrix.comjason.vagala...@citrix.commailto:jason.vagala...@citrix.com
Subject: RE: Still failing on 5.7 with the same error
Apparently this error is printed from FreeIPA code and not an underlying
library.
Here’s the relevant bit from ipa-getkeytab.c:
/* Format of response
*
* KeytabGetRequest ::= SEQUENCE {
* new_kvno Int32
* SEQUENCE OF KeyTypes
* }
*
* * List of accepted enctypes *
* KeyTypes ::= SEQUENCE {
* enctype Int32
* }
*/
rtag = ber_scanf(sctrl, {i{, kvno);
if (rtag == LBER_ERROR) {
fprintf(stderr, ber_scanf() failed, Invalid control ?!\n);
goto error_out;
}
However, the call that’s failing (ber_scanf()) is one from the openldap
library:
[root@util1 Server]# strings /usr/lib/liblber-2.3.so.0 |grep ber_scanf
ber_scanf
ber_scanf fmt (%s) ber:
ber_scanf: unknown fmt %c
ber_scanf
From: /O=EXPERTCITY.COM/OU=BETA.EXPERTCITY/CN=RECIPIENTS/CN=BRETT.CAMPBELL On
Behalf Of Brett Campbell
Sent: Monday, September 19, 2011 6:29 PM
To: mailto:jr.aqu...@citrix.com mailto:jr.aqu...@citrix.com
jr.aqu...@citrix.commailto:jr.aqu...@citrix.com
Subject: Still failing on 5.7 with the same error
Are you sure it’s not the server? Can you check the logs?
[root@util1 Server]# cat /etc/issue
Red Hat Enterprise Linux Server release 5.7 (Tikanga)
Kernel \r on an \m
[root@util1 Server]#
[root@util1 Server]#
[root@util1 Server]#
[root@util1 Server]# rpm --aid -ivh /tmp/ipa-client-2.0-14.el5_7.1.x86_64.rpm
certmonger-0.42-1.el5.x86_64.rpm
cyrus-sasl-gssapi-2.1.22-5.el5_4.3.x86_64.rpm
sssd-client-1.5.1-37.el5.x86_64.rpm sssd-1.5.1-37.el5.x86_64.rpm
xmlrpc-c-1.16.24-1206.1840.el5.x86_64.rpm
libcollection-0.6.0-10.el5.x86_64.rpm libdhash-0.4.2-10.el5.x86_64.rpm
libldb-0.9.10-33.el5.x86_64.rpm libtdb-1.2.1-6.el5.x86_64.rpm
openssl-devel-0.9.8e-20.el5.x86_64.rpm libref_array-0.1.1-10.el5.x86_64.rpm
libpath_utils-0.2.1-10.el5.x86_64.rpm libini_config-0.6.1-10.el5.x86_64.rpm
libref_array-0.1.1-10.el5.x86_64.rpm openldap24-libs-2.4.23-5.el5.x86_64.rpm
xmlrpc-c-client-1.16.24-1206.1840.el5.x86_64.rpm
libtalloc-2.0.1-11.el5.x86_64.rpm c-ares-1.6.0-5.el5.x86_64.rpm
krb5-devel-1.6.1-62.el5.x86_64.rpm zlib-devel-1.2.3-4.el5.x86_64.rpm
libtevent-0.9.8-10.el5.x86_64.rpm e2fsprogs-devel-1.39-33.el5.x86_64.rpm
keyutils-libs-devel-1.2-1.el5.x86_64.rpm
libselinux-devel-1.33.4-5.7.el5.x86_64.rpm
libsepol-devel-1.15.2-3.el5.x86_64.rpm
warning: /tmp/ipa-client-2.0-14.el5_7.1.x86_64.rpm: Header V3 DSA signature:
NOKEY, key ID 37017186
Preparing...### [100%]
1:libtalloc ### [ 4%]
2:libtevent ### [ 8%]
3:xmlrpc-c ### [ 12%]
4:xmlrpc-c-client### [ 15%]
5:libref_array ### [ 19%]
6:libtdb ### [ 23%]
7:libcollection ### [ 27%]
8:cyrus-sasl-gssapi ### [ 31%]
9:libldb ### [ 35%]
10:certmonger ### [ 38%]
11:c-ares ### [ 42%]
12:openldap24-libs### [ 46%]
13:libpath_utils ### [ 50%]
14:libini_config ### [ 54%]
15:libdhash ### [ 58%]
16:sssd-client### [ 62%]
17:sssd ### [ 65%]
18:libsepol-devel ### [ 69%]
19:libselinux-devel
[Freeipa-devel] Fwd: Still failing on 5.7 with the same error........
We're having significant reproducible problems with rhel 5.7 + FreeIPA master...
I'm not sure if it is localized to us or even which side is responsible for the
error...
Has anyone had success with rhel 5.7's repo included FreeIPA client joining a
fedora based FreeIPA server?
We are essentially dead in the water at this point.
Sent from my iPad
Begin forwarded message:
From: Brett Campbell
mailto:brett.campb...@citrix.combrett.campb...@citrix.commailto:brett.campb...@citrix.com
Date: September 19, 2011 6:48:55 PM PDT
To: JR Aquino
mailto:jr.aqu...@citrix.comjr.aqu...@citrix.commailto:jr.aqu...@citrix.com
Cc: Jason Vagalatos
mailto:jason.vagala...@citrix.comjason.vagala...@citrix.commailto:jason.vagala...@citrix.com
Subject: RE: Still failing on 5.7 with the same error
Apparently this error is printed from FreeIPA code and not an underlying
library.
Here’s the relevant bit from ipa-getkeytab.c:
/* Format of response
*
* KeytabGetRequest ::= SEQUENCE {
* new_kvno Int32
* SEQUENCE OF KeyTypes
* }
*
* * List of accepted enctypes *
* KeyTypes ::= SEQUENCE {
* enctype Int32
* }
*/
rtag = ber_scanf(sctrl, {i{, kvno);
if (rtag == LBER_ERROR) {
fprintf(stderr, ber_scanf() failed, Invalid control ?!\n);
goto error_out;
}
However, the call that’s failing (ber_scanf()) is one from the openldap library:
[root@util1 Server]# strings /usr/lib/liblber-2.3.so.0 |grep ber_scanf
ber_scanf
ber_scanf fmt (%s) ber:
ber_scanf: unknown fmt %c
ber_scanf
From: /O=EXPERTCITY.COM/OU=BETA.EXPERTCITY/CN=RECIPIENTS/CN=BRETT.CAMPBELL On
Behalf Of Brett Campbell
Sent: Monday, September 19, 2011 6:29 PM
To: mailto:jr.aqu...@citrix.com mailto:jr.aqu...@citrix.com
jr.aqu...@citrix.commailto:jr.aqu...@citrix.com
Subject: Still failing on 5.7 with the same error
Are you sure it’s not the server? Can you check the logs?
[root@util1 Server]# cat /etc/issue
Red Hat Enterprise Linux Server release 5.7 (Tikanga)
Kernel \r on an \m
[root@util1 Server]#
[root@util1 Server]#
[root@util1 Server]#
[root@util1 Server]# rpm --aid -ivh /tmp/ipa-client-2.0-14.el5_7.1.x86_64.rpm
certmonger-0.42-1.el5.x86_64.rpm cyrus-sasl-gssapi-2.1.22-5.el5_4.3.x86_64.rpm
sssd-client-1.5.1-37.el5.x86_64.rpm sssd-1.5.1-37.el5.x86_64.rpm
xmlrpc-c-1.16.24-1206.1840.el5.x86_64.rpm libcollection-0.6.0-10.el5.x86_64.rpm
libdhash-0.4.2-10.el5.x86_64.rpm libldb-0.9.10-33.el5.x86_64.rpm
libtdb-1.2.1-6.el5.x86_64.rpm openssl-devel-0.9.8e-20.el5.x86_64.rpm
libref_array-0.1.1-10.el5.x86_64.rpm libpath_utils-0.2.1-10.el5.x86_64.rpm
libini_config-0.6.1-10.el5.x86_64.rpm libref_array-0.1.1-10.el5.x86_64.rpm
openldap24-libs-2.4.23-5.el5.x86_64.rpm
xmlrpc-c-client-1.16.24-1206.1840.el5.x86_64.rpm
libtalloc-2.0.1-11.el5.x86_64.rpm c-ares-1.6.0-5.el5.x86_64.rpm
krb5-devel-1.6.1-62.el5.x86_64.rpm zlib-devel-1.2.3-4.el5.x86_64.rpm
libtevent-0.9.8-10.el5.x86_64.rpm e2fsprogs-devel-1.39-33.el5.x86_64.rpm
keyutils-libs-devel-1.2-1.el5.x86_64.rpm
libselinux-devel-1.33.4-5.7.el5.x86_64.rpm
libsepol-devel-1.15.2-3.el5.x86_64.rpm
warning: /tmp/ipa-client-2.0-14.el5_7.1.x86_64.rpm: Header V3 DSA signature:
NOKEY, key ID 37017186
Preparing...### [100%]
1:libtalloc ### [ 4%]
2:libtevent ### [ 8%]
3:xmlrpc-c ### [ 12%]
4:xmlrpc-c-client### [ 15%]
5:libref_array ### [ 19%]
6:libtdb ### [ 23%]
7:libcollection ### [ 27%]
8:cyrus-sasl-gssapi ### [ 31%]
9:libldb ### [ 35%]
10:certmonger ### [ 38%]
11:c-ares ### [ 42%]
12:openldap24-libs### [ 46%]
13:libpath_utils ### [ 50%]
14:libini_config ### [ 54%]
15:libdhash ### [ 58%]
16:sssd-client### [ 62%]
17:sssd ### [ 65%]
18:libsepol-devel ### [ 69%]
19:libselinux-devel ### [ 73%]
20:keyutils-libs-devel### [ 77%]
21:e2fsprogs-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Sep 16, 2011, at 4:41 AM, Alexander Bokovoy aboko...@redhat.com wrote: On Fri, 16 Sep 2011, Martin Kosek wrote: Great, most bugs are fixed. I only saw these 2 minor bugs. If those are fixed, I think we can ackpush. 1) Man pages: --list option is still not right, formating is wrong +\fB\-l\fR, -\-list\fR 2) Enable action is missing a notice for the user, like the disable action has: # ipa-managed-entries -e 'cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' disable Disabling Plugin # ipa-managed-entries -e 'cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' enable This hurts. :) Can't we have a shortcut that allows to specify only name of the managed entry and we will expand it to full DN? Current approach is way error-prone for admins to accidently make a typo or two... It may look intimidating via email, but the tool provides --list to show the exact line thats needed to copy past, it also does checks to prevent accidental typos. The user isn't expected to know the full dn off the top of their head :) The other nice thing is that the tool is not limited to only the stock FreeIPA managed entries, so it will also list, enable, and disable any custom user created managed entries, or future FreeIPA entries without modification. -jr -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Sep 16, 2011, at 2:11 AM, Martin Kosek wrote: On Thu, 2011-09-15 at 17:25 +, JR Aquino wrote: On Sep 15, 2011, at 1:47 AM, Martin Kosek wrote: On Thu, 2011-09-15 at 00:47 +, JR Aquino wrote: On Jul 22, 2011, at 7:05 AM, Martin Kosek wrote: 5) I was thinking if there is a better solution to enabling/disabling of the plugin. Likes setting something like managedEntryEnabled attribute to on/off as we do with compat plugin. Current concept with disabling the definition by damaging the originFilter and then restoring it from an LDIF seems a bit awkward to me. This has been completely changed: Instead of looking to ldif files, an ldap look up is now performed to dynamically list the available managed entries. Now we are talking :-) I like the new approach. high five I have reviewed your patch, basic functionality looks good. But I still have few (nitpicking) comments: 1) There are parts from the previous file that are no longer needed since you switched to different approach: +import os +from ipaserver.install.ldapupdate import LDAPUpdate, BadSyntax +import StringIO +import ldif +except BadSyntax, e: +print There is a syntax error in this update file: +print %s % e +sys.exit(1) Removed 2) I saw few whitespace errors on following lines of the patch: 419, 433 and 453 Fixed whitespace errors 3) Output of the --list method is confusing: # ipa-managed-entries --list Directory Manager password: Available Managed Entry Plugins: cn=upg definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com cn=ngp definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com You must specify a managed entry definition # echo $? 1 a) I shouldn't be asked to specify a managed entry definition for --list Fixed b) The listing was successful, so we shouldn't return error code Corrected error code 4) Return code for disabling an already disabled entry should be 2 (according to man pages): # ipa-managed-entries -e 'cn=upg definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' disable Directory Manager password: Plugin already disabled # echo $? 0 Fixed error code 5) Strange is, that enabling a disabled plugin gives me return code 2: # ipa-managed-entries -e 'cn=upg definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' enable Directory Manager password: Enabling Plugin # echo $? 2 Return codes for these actions should fit the man pages. Fixed error code 6) I would improve working with LDAP filters, current solution is error prone. Try disablingenabling NGP Defition, we end up with this originFilter: originfilter: ((objectclass=ipahostgroup)) I think the cleanest solution would be to use ldap.make_filter and ldap.combine_filters functions to play with these filter. You can inspire yourself in this example I wrote for DNS plugin: rev_zone_filter = ldap.make_filter(search_kw, rules=ldap.MATCH_NONE, exact=False, trailing_wildcard=False) filter = ldap.combine_filters((rev_zone_filter, filter), rules=ldap.MATCH_ALL) Rob and you addressed this in the mailing list. For the record, I do agree that we are lacking a method for reading and modifying existing ldap filters. We will continue with the simple string method here for this iteration. 7) Entering Directory Manager every time may be a bit tedious. Could we use current Kerberos credentials and fall-back to asking Directory Manager password if it doesn't work? Its already done this way in ipa-replica-manage for example. We could fix this, however, as an enhancement in another patch. Fixed. We now will use gssapi if available, and prompt for password if there is no ticket. 8) Man page - please use the new united FreeIPA man page header. Instead of +.TH ipa-managed-entries 1 Sept 15 2011 freeipa use: +.TH ipa-managed-entries 1 Sept 15 2011 FreeIPA FreeIPA Manual Pages Fixed 9) Man page - comma is missing for --list option: +\fB\-l\-\-list\fR Fixed 10) install/po/Makefile.in should be updated to: there is still reference to ipa-host-net-manage and ipa-managed-entries reference is missing Fixed Great, most bugs are fixed. I only saw these 2 minor bugs. If those are fixed, I think we can ackpush. 1) Man pages: --list option is still not right, formating is wrong +\fB\-l\fR, -\-list\fR This typo is now corrected 2) Enable action is missing a notice for the user, like the disable action has: # ipa-managed-entries -e 'cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' disable Disabling Plugin The output is now corrected. # ipa-managed-entries -e 'cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,dc
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Sep 15, 2011, at 1:47 AM, Martin Kosek wrote: On Thu, 2011-09-15 at 00:47 +, JR Aquino wrote: On Jul 22, 2011, at 7:05 AM, Martin Kosek wrote: 5) I was thinking if there is a better solution to enabling/disabling of the plugin. Likes setting something like managedEntryEnabled attribute to on/off as we do with compat plugin. Current concept with disabling the definition by damaging the originFilter and then restoring it from an LDIF seems a bit awkward to me. This has been completely changed: Instead of looking to ldif files, an ldap look up is now performed to dynamically list the available managed entries. Now we are talking :-) I like the new approach. high five I have reviewed your patch, basic functionality looks good. But I still have few (nitpicking) comments: 1) There are parts from the previous file that are no longer needed since you switched to different approach: +import os +from ipaserver.install.ldapupdate import LDAPUpdate, BadSyntax +import StringIO +import ldif +except BadSyntax, e: +print There is a syntax error in this update file: +print %s % e +sys.exit(1) Removed 2) I saw few whitespace errors on following lines of the patch: 419, 433 and 453 Fixed whitespace errors 3) Output of the --list method is confusing: # ipa-managed-entries --list Directory Manager password: Available Managed Entry Plugins: cn=upg definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com cn=ngp definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com You must specify a managed entry definition # echo $? 1 a) I shouldn't be asked to specify a managed entry definition for --list Fixed b) The listing was successful, so we shouldn't return error code Corrected error code 4) Return code for disabling an already disabled entry should be 2 (according to man pages): # ipa-managed-entries -e 'cn=upg definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' disable Directory Manager password: Plugin already disabled # echo $? 0 Fixed error code 5) Strange is, that enabling a disabled plugin gives me return code 2: # ipa-managed-entries -e 'cn=upg definition,cn=definitions,cn=managed entries,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' enable Directory Manager password: Enabling Plugin # echo $? 2 Return codes for these actions should fit the man pages. Fixed error code 6) I would improve working with LDAP filters, current solution is error prone. Try disablingenabling NGP Defition, we end up with this originFilter: originfilter: ((objectclass=ipahostgroup)) I think the cleanest solution would be to use ldap.make_filter and ldap.combine_filters functions to play with these filter. You can inspire yourself in this example I wrote for DNS plugin: rev_zone_filter = ldap.make_filter(search_kw, rules=ldap.MATCH_NONE, exact=False, trailing_wildcard=False) filter = ldap.combine_filters((rev_zone_filter, filter), rules=ldap.MATCH_ALL) Rob and you addressed this in the mailing list. For the record, I do agree that we are lacking a method for reading and modifying existing ldap filters. We will continue with the simple string method here for this iteration. 7) Entering Directory Manager every time may be a bit tedious. Could we use current Kerberos credentials and fall-back to asking Directory Manager password if it doesn't work? Its already done this way in ipa-replica-manage for example. We could fix this, however, as an enhancement in another patch. Fixed. We now will use gssapi if available, and prompt for password if there is no ticket. 8) Man page - please use the new united FreeIPA man page header. Instead of +.TH ipa-managed-entries 1 Sept 15 2011 freeipa use: +.TH ipa-managed-entries 1 Sept 15 2011 FreeIPA FreeIPA Manual Pages Fixed 9) Man page - comma is missing for --list option: +\fB\-l\-\-list\fR Fixed 10) install/po/Makefile.in should be updated to: there is still reference to ipa-host-net-manage and ipa-managed-entries reference is missing Fixed bin1u2MkpIsph.bin Description: freeipa-jraquino-0025-Create-Tool-for-Enabling-Disabling-Managed-Entries.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Jul 22, 2011, at 7:05 AM, Martin Kosek wrote: On Thu, 2011-07-21 at 23:52 +, JR Aquino wrote: On Apr 25, 2011, at 9:00 AM, Simo Sorce wrote: On Mon, 2011-04-25 at 14:59 +, JR Aquino wrote: On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: On Thu, 2011-04-21 at 23:28 +, JR Aquino wrote: Hmmm Both Private Groups and the Hostgroup - Netgroup Managed Entries create objects in the container: cn=Managed Entries,cn=plugins,cn=config Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, and one in the cn=config How will these be treated by replication and the multi masters? Only the common objects in the public suffix are replicated. I think at some point we discussed that we should use a filter in the private config entry made so that we could enable/disable the plugin by simply making the filter result true/false. Thus not ever touch the entries in cn=config but simply enable/disable the functionality by (not)adding the appropriate attributes to objects so that filters would (not) match. Simo. This tool works by toggling the originfilter: objectclass=disabled in order to turn off the plugin. But this is backwards, because originfilter is defined in the configuration entry stored in cn=config Meaning as soon as you change it one server will behave differently from the others until you go and change it on each and every server. Finally able to revisit this Patch / Ticket: (To be used in conjunction with Patch 38) 25 Create Tool for Enabling/Disabling Managed Entry Plugins https://fedorahosted.org/freeipa/ticket/1181 Remove legacy ipa-host-net-manage Add ipa-managed-entries tool Add man page for ipa-managed-entries tool I have found few issues with the patch: 1) I don't think its necessary to change BuildRequires to 389-ds-base-devel = 1.2.8 This is no longer necessary and has been removed. 2) Invalid comment in get_dirman_password() function. There is no verification of the password. It just prompts it This has been corrected 3) ipa-managed entries man pages: copy paste error: +Directory Server will need to be restarted after the schema compatibility plugin has been enabled. Copy / Paste Typo corrected 4) Invalid help of the program: # ipa-managed-entries --help Usage: ipa-managed-entries [options] enable|disable ipa-managed-entries [options] - status action is missing - running program without action is not allowed, i.e. should not be offered Corrected help entries 5) I was thinking if there is a better solution to enabling/disabling of the plugin. Likes setting something like managedEntryEnabled attribute to on/off as we do with compat plugin. Current concept with disabling the definition by damaging the originFilter and then restoring it from an LDIF seems a bit awkward to me. This has been completely changed: Instead of looking to ldif files, an ldap look up is now performed to dynamically list the available managed entries. 6) ipa-managed-entries crashes when managed entry is a wrong file: # ipa-managed-entries status -f /usr/share/ipa/managed-entries.ldif Directory Manager password: Traceback (most recent call last): File /usr/sbin/ipa-managed-entries, line 245, in module sys.exit(main()) File /usr/sbin/ipa-managed-entries, line 141, in main originFilter = entry_attr['originFilter'][0] KeyError: 'originFilter' This is no longer an issue now that it is no longer using the ldif files. 7) What if there are more managed entries in the LDIF? This concept would not work correctly then. A behavior I would expect: a) User (optionally) passes a directory with managed entries LDIFs b) ipa-managed-entries analyzes all LDIFs and prints available Managed Entry definitions c) I would choose the one I want to enable/disable via ipa-managed-entries option Also no longer an issue. Martin Corrected Patch Attached: binscouuEWzDP.bin Description: freeipa-jraquino-0025-Create-Tool-for-Enabling-Disabling-Managed-Entries.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 38 Move Managed Entries into their own container in the replicated space.
On Sep 8, 2011, at 4:38 AM, Martin Kosek wrote: On Tue, 2011-09-06 at 22:33 +, JR Aquino wrote: On Jul 22, 2011, at 6:54 AM, Martin Kosek wrote: On Thu, 2011-07-21 at 23:00 +, JR Aquino wrote: Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container A separate patch will cover the management tool https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation extended solution I found few issues with the patch (tested along with 25): 1) When upgrading an old instance, NGP and UGP definitions in cn=Managed Entries,cn=plugins,cn=config were not deleted. This lead to 2 managed entries plugin definitions Fixed this condition. 389 prohibits the deletion of Managed Entries while they are active. I had to perform the repointing to the new cn=etc container, perform the migration of the legacy configs, then perform a restart of dirsrv. 2) Managed entries on a replica didn't work for me. For example UPG was created on a master, but was not on a replica This should also be resolved now. Martin I had to break out the connection code in update for ldapupdate.py so that connections could be reestablished post dirsrv restart. I also had to create a service class to perform the restart. installutils.py has been modified to provide wait_for_open_socket() similar to wait_for_open_port() Hello JR, I tested you patch, it works fine for both upgrading the replicas and new installations. Old Managed Entries definitions were successfully deleted. I just found few issues with the patch format itself: 1) Commit message is all wrong, its all on the Subject line which is then put to commit title during git am. I suggest using our standard commit message formatting: COMMIT_TITLE COMMIT_DESCRIPTION TRAC_TICKET_LINK 2) There were few whitespace errors: $ git apply ~/freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch /home/mkosek/freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch:519: trailing whitespace. /home/mkosek/freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch:526: trailing whitespace. Otherwise the patch looks good to me, if it is OK with Rob (since he wrote the entire ldapupdate.py) I think we can push it after you fix the 2 changes I proposed. Fixed the whitespace errors and adjusted the commit message. binxRjEG2Pvey.bin Description: freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 38 Move Managed Entries into their own container in the replicated space.
On Sep 8, 2011, at 10:41 AM, JR Aquino wrote: On Sep 8, 2011, at 10:06 AM, JR Aquino wrote: On Sep 8, 2011, at 4:38 AM, Martin Kosek wrote: On Tue, 2011-09-06 at 22:33 +, JR Aquino wrote: On Jul 22, 2011, at 6:54 AM, Martin Kosek wrote: On Thu, 2011-07-21 at 23:00 +, JR Aquino wrote: Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container A separate patch will cover the management tool https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation extended solution I found few issues with the patch (tested along with 25): 1) When upgrading an old instance, NGP and UGP definitions in cn=Managed Entries,cn=plugins,cn=config were not deleted. This lead to 2 managed entries plugin definitions Fixed this condition. 389 prohibits the deletion of Managed Entries while they are active. I had to perform the repointing to the new cn=etc container, perform the migration of the legacy configs, then perform a restart of dirsrv. 2) Managed entries on a replica didn't work for me. For example UPG was created on a master, but was not on a replica This should also be resolved now. Martin I had to break out the connection code in update for ldapupdate.py so that connections could be reestablished post dirsrv restart. I also had to create a service class to perform the restart. installutils.py has been modified to provide wait_for_open_socket() similar to wait_for_open_port() Hello JR, I tested you patch, it works fine for both upgrading the replicas and new installations. Old Managed Entries definitions were successfully deleted. I just found few issues with the patch format itself: 1) Commit message is all wrong, its all on the Subject line which is then put to commit title during git am. I suggest using our standard commit message formatting: COMMIT_TITLE COMMIT_DESCRIPTION TRAC_TICKET_LINK 2) There were few whitespace errors: $ git apply ~/freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch /home/mkosek/freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch:519: trailing whitespace. /home/mkosek/freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch:526: trailing whitespace. Otherwise the patch looks good to me, if it is OK with Rob (since he wrote the entire ldapupdate.py) I think we can push it after you fix the 2 changes I proposed. Fixed the whitespace errors and adjusted the commit message. freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch Self NAK Looks like I missed a piece in this recent patch that creates the cn=etc containers out of order. New patch to follow shortly Ok. Whitespace errors corrected Commit Format Corrected Order of creation for Managed Entry Container is now corrected Martin if you could do a quick double check to make sure everything still looks clean to you. After that, I believe it just needs Rob's blessing. binrtjvT9NWv7.bin Description: freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 38 Move Managed Entries into their own container in the replicated space.
On Jul 22, 2011, at 6:54 AM, Martin Kosek wrote: On Thu, 2011-07-21 at 23:00 +, JR Aquino wrote: Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container A separate patch will cover the management tool https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation extended solution I found few issues with the patch (tested along with 25): 1) When upgrading an old instance, NGP and UGP definitions in cn=Managed Entries,cn=plugins,cn=config were not deleted. This lead to 2 managed entries plugin definitions Fixed this condition. 389 prohibits the deletion of Managed Entries while they are active. I had to perform the repointing to the new cn=etc container, perform the migration of the legacy configs, then perform a restart of dirsrv. 2) Managed entries on a replica didn't work for me. For example UPG was created on a master, but was not on a replica This should also be resolved now. Martin I had to break out the connection code in update for ldapupdate.py so that connections could be reestablished post dirsrv restart. I also had to create a service class to perform the restart. installutils.py has been modified to provide wait_for_open_socket() similar to wait_for_open_port() binT4VI49YJbg.bin Description: freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 39 Improve sudorule documentation
https://fedorahosted.org/freeipa/ticket/1657 Added brief explanations for the various Sudo components in the top level doc. Added doc entries for RunAs User and RunAs Group. freeipa-jraquino-0039-Improve-sudorule-documentation.patch Description: freeipa-jraquino-0039-Improve-sudorule-documentation.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Aug 3, 2011, at 7:32 AM, Rob Crittenden wrote: JR Aquino wrote: On Aug 2, 2011, at 5:55 AM, Rob Crittendenrcrit...@redhat.com wrote: JR Aquino wrote: I am fairly opposed to removing 'default' attrs which the rules are applied to... I am happy to provide a means to override them. While it may be second nature for all of us to know that there is an fqdn attribute, etc, our consumers are likely not going to intrinsically know our schema. We also deliberately mask the real attribute names in the framework. (fqdn = Host name) Providing a default feels like a happy medium which allows for ease of use and somewhat of a safety belt against users defining an incorrect attribute name. It also might get somewhat tiring to constantly provide --key=fqdn every time you add a hostname regex? Ok, but when you display rules fqdn is displayed. How are users to know they shouldn't include fqdn= when removing existing rules? I guess my preference would be to heavily document, in the example, the plugin, and the docs... My concern is that without a default, a typo in the attr would produce unintended results. Without a schema checker, it's kinda tough to take an attr at face value from a user. Does the python ldap implementation have a means to check schema in order to verify an attribute? The design of the automember pluginhHaving the attr in the Regex does make for some complexity We do have a schema checker. You can test for existence of an attribute with something like: import ldap as _ldap obj = ldap.schema.get_obj(_ldap.schema.AttributeType, attr) if obj is None: # Error, no such attribute def check_attr(self, attr): Verify that the user supplied key is a valid attribute in the schema ldap = self.api.Backend.ldap2 obj = ldap.schema.get_obj(_ldap.schema.AttributeType, attr) return obj [Thu Aug 04 16:58:41 2011] [error] File /usr/lib/python2.7/site-packages/ipalib/plugins/automember.py, line 209, in check_attr [Thu Aug 04 16:58:41 2011] [error] obj = ldap.schema.get_obj(_ldap.schema.AttributeType, attr) [Thu Aug 04 16:58:41 2011] [error] AttributeError: 'NoneType' object has no attribute 'get_obj' Seems that ldap doesn't have a get_obj inside of schema? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Aug 2, 2011, at 5:55 AM, Rob Crittenden rcrit...@redhat.com wrote: JR Aquino wrote: I am fairly opposed to removing 'default' attrs which the rules are applied to... I am happy to provide a means to override them. While it may be second nature for all of us to know that there is an fqdn attribute, etc, our consumers are likely not going to intrinsically know our schema. We also deliberately mask the real attribute names in the framework. (fqdn = Host name) Providing a default feels like a happy medium which allows for ease of use and somewhat of a safety belt against users defining an incorrect attribute name. It also might get somewhat tiring to constantly provide --key=fqdn every time you add a hostname regex? Ok, but when you display rules fqdn is displayed. How are users to know they shouldn't include fqdn= when removing existing rules? I guess my preference would be to heavily document, in the example, the plugin, and the docs... My concern is that without a default, a typo in the attr would produce unintended results. Without a schema checker, it's kinda tough to take an attr at face value from a user. Does the python ldap implementation have a means to check schema in order to verify an attribute? The design of the automember pluginhHaving the attr in the Regex does make for some complexity ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Aug 1, 2011, at 11:28 PM, Martin Kosek mko...@redhat.com wrote: On Mon, 2011-08-01 at 19:11 +, JR Aquino wrote: On Aug 1, 2011, at 5:56 AM, Rob Crittenden wrote: Martin Kosek wrote: On Sat, 2011-07-30 at 00:54 +, JR Aquino wrote: On Jul 21, 2011, at 8:53 AM, JR Aquino wrote: On Jul 21, 2011, at 7:31 AM, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-07-21 at 03:37 +, JR Aquino wrote: Rob, I'm afraid I believe that ldap lookup is necessary. The user inputs a standard string to represent the possible host group… If i simply perform a get_dn it will indeed provide a dn, however, it won't verify that the host group actually exists… (you don't want to create an assignment rule for a non existent target host group) Martin, (except for the name Clarity), I have addressed your observations in this latest patch. Could you please have a look and let me know if there is anything else I need to take care of? Great, preparing the command parameters in pre_callback is much cleaner. Good point about the LDAP lookup. This looks a lot better but there are still a few issues: If group_dn is in the object then you can use self.obj.handle_not_found(*keys) for the NotFound. Ok, I will give that a shot! Or if it can't be moved, in the calls to group_dn() you can use the ldap handle passed into pre_callback. I guess you are using the includetype tuple to avoid coding long variable names everywhere? Would a symbol be better, eg: INCLUDE_RE = 'automemberinclusiveregex' EXCLUDE_RE = 'automemberexclusiveregex' That works, I'll swap em. I agree with Rob here, this will make the code better. Is there a way to validate the regex? Now that you mention it, I believe if I import re, we should be able to validate the initial regex and raise an exception if it is bogus. If we were to add an equivalent user group handler would it be the same code in add_condition and remove_condition? It is sort of nice to have everything together at the moment, I suspect it will need to be generalized at some point. Well. For the groups, I was thinking it starts to get a little different. I would still reuse the condition, but I believe I would pivot users into groups based upon something like their manager? Adding a clarity with no rules won't let you add rules: # ipa hostgroup-add --desc=hg1 hg1 # ipa hostgroupclarity-add hg1 # ipa hostgroupclarity-add-condition --exclusive-hostname-regex=^web5\.example\.com hg1 ipa: ERROR: no modifications to be performed This ^ is deliberate, you cannot add an exclusion rule if there is no existing or simultaneous inclusive rule. :) Martin asked for that, and I think its wise. Yes, it is wise :-) But the error message is really not clear to the user. We should tell him that there must be at least one inclusive rule. I wonder if we shouldn't force user to create a hostgroupclarity object with at least one inclusive rule and than make sure that in all operations at least one inclusive rule stays here. Or we could delete the empty LDAP object after the last inclusive rule is removed, as we do with DNS record LDAP objects in dnsrecord-del. The way you explained clarity today in IRC, how it brings clarity to managing membership with names no human can grok, I got it. Still, clarity is a bit awkward as a name. automember might be a better choice. Fair enough ;) I tried, perhaps I can /allude/ to it in the help / docs. automember it is. One final class I have been struggling with that I want to add… The object and attribute which defines the 'default group' is the parent of the actual rules… i.e. cn=hostgroup,cn=automember,cn=etc… The ipa cli seems to only want to let me make mods that assume I am specifying a target object on the cli… ipa hostgroupautomember-default-group=foorulename- in this scenario, we don't actually want or need a rule name because its the container above… I have had success making the writes, but the cli syntax just doesn't lend itself to that level of abstraction… Any suggestions? I think the best shot would be to create a new command and overload the execute method in that case. Like in hbacrule_enable. You would be able to set dn correctly here and do the update. Does it makes sense? Rob? Martin I agree. We are better off abstracting things now so we can get the API right. I think we can stick more or less with the command names, just in a new plugin and some new arguments. I see the plugin with the following methods: Each takes a single argument, the name of the rule. I don't think I'd stick type into the DN so you wouldn't be able to use the same rule name for different object types. If we want to allow that then we'd need to add --type to a lot more commands. There is no mod to change types, you have to delete and re-add. automember-add Add an automember rule --type=ENUM
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Aug 2, 2011, at 1:09 AM, Martin Kosek wrote: On Tue, 2011-08-02 at 07:25 +, JR Aquino wrote: On Aug 1, 2011, at 11:28 PM, Martin Kosek mko...@redhat.com wrote: On Mon, 2011-08-01 at 19:11 +, JR Aquino wrote: On Aug 1, 2011, at 5:56 AM, Rob Crittenden wrote: Martin Kosek wrote: On Sat, 2011-07-30 at 00:54 +, JR Aquino wrote: On Jul 21, 2011, at 8:53 AM, JR Aquino wrote: On Jul 21, 2011, at 7:31 AM, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-07-21 at 03:37 +, JR Aquino wrote: Rob, I'm afraid I believe that ldap lookup is necessary. The user inputs a standard string to represent the possible host group… If i simply perform a get_dn it will indeed provide a dn, however, it won't verify that the host group actually exists… (you don't want to create an assignment rule for a non existent target host group) Martin, (except for the name Clarity), I have addressed your observations in this latest patch. Could you please have a look and let me know if there is anything else I need to take care of? Great, preparing the command parameters in pre_callback is much cleaner. Good point about the LDAP lookup. This looks a lot better but there are still a few issues: If group_dn is in the object then you can use self.obj.handle_not_found(*keys) for the NotFound. Ok, I will give that a shot! Or if it can't be moved, in the calls to group_dn() you can use the ldap handle passed into pre_callback. I guess you are using the includetype tuple to avoid coding long variable names everywhere? Would a symbol be better, eg: INCLUDE_RE = 'automemberinclusiveregex' EXCLUDE_RE = 'automemberexclusiveregex' That works, I'll swap em. I agree with Rob here, this will make the code better. Is there a way to validate the regex? Now that you mention it, I believe if I import re, we should be able to validate the initial regex and raise an exception if it is bogus. If we were to add an equivalent user group handler would it be the same code in add_condition and remove_condition? It is sort of nice to have everything together at the moment, I suspect it will need to be generalized at some point. Well. For the groups, I was thinking it starts to get a little different. I would still reuse the condition, but I believe I would pivot users into groups based upon something like their manager? Adding a clarity with no rules won't let you add rules: # ipa hostgroup-add --desc=hg1 hg1 # ipa hostgroupclarity-add hg1 # ipa hostgroupclarity-add-condition --exclusive-hostname-regex=^web5\.example\.com hg1 ipa: ERROR: no modifications to be performed This ^ is deliberate, you cannot add an exclusion rule if there is no existing or simultaneous inclusive rule. :) Martin asked for that, and I think its wise. Yes, it is wise :-) But the error message is really not clear to the user. We should tell him that there must be at least one inclusive rule. I wonder if we shouldn't force user to create a hostgroupclarity object with at least one inclusive rule and than make sure that in all operations at least one inclusive rule stays here. Or we could delete the empty LDAP object after the last inclusive rule is removed, as we do with DNS record LDAP objects in dnsrecord-del. The way you explained clarity today in IRC, how it brings clarity to managing membership with names no human can grok, I got it. Still, clarity is a bit awkward as a name. automember might be a better choice. Fair enough ;) I tried, perhaps I can /allude/ to it in the help / docs. automember it is. One final class I have been struggling with that I want to add… The object and attribute which defines the 'default group' is the parent of the actual rules… i.e. cn=hostgroup,cn=automember,cn=etc… The ipa cli seems to only want to let me make mods that assume I am specifying a target object on the cli… ipa hostgroupautomember-default-group=foorulename- in this scenario, we don't actually want or need a rule name because its the container above… I have had success making the writes, but the cli syntax just doesn't lend itself to that level of abstraction… Any suggestions? I think the best shot would be to create a new command and overload the execute method in that case. Like in hbacrule_enable. You would be able to set dn correctly here and do the update. Does it makes sense? Rob? Martin I agree. We are better off abstracting things now so we can get the API right. I think we can stick more or less with the command names, just in a new plugin and some new arguments. I see the plugin with the following methods: Each takes a single argument, the name of the rule. I don't think I'd stick type into the DN so you wouldn't be able to use the same rule name for different object types. If we want to allow that then we'd need to add --type to a lot
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Aug 1, 2011, at 5:56 AM, Rob Crittenden wrote: Martin Kosek wrote: On Sat, 2011-07-30 at 00:54 +, JR Aquino wrote: On Jul 21, 2011, at 8:53 AM, JR Aquino wrote: On Jul 21, 2011, at 7:31 AM, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-07-21 at 03:37 +, JR Aquino wrote: Rob, I'm afraid I believe that ldap lookup is necessary. The user inputs a standard string to represent the possible host group… If i simply perform a get_dn it will indeed provide a dn, however, it won't verify that the host group actually exists… (you don't want to create an assignment rule for a non existent target host group) Martin, (except for the name Clarity), I have addressed your observations in this latest patch. Could you please have a look and let me know if there is anything else I need to take care of? Great, preparing the command parameters in pre_callback is much cleaner. Good point about the LDAP lookup. This looks a lot better but there are still a few issues: If group_dn is in the object then you can use self.obj.handle_not_found(*keys) for the NotFound. Ok, I will give that a shot! Or if it can't be moved, in the calls to group_dn() you can use the ldap handle passed into pre_callback. I guess you are using the includetype tuple to avoid coding long variable names everywhere? Would a symbol be better, eg: INCLUDE_RE = 'automemberinclusiveregex' EXCLUDE_RE = 'automemberexclusiveregex' That works, I'll swap em. I agree with Rob here, this will make the code better. Is there a way to validate the regex? Now that you mention it, I believe if I import re, we should be able to validate the initial regex and raise an exception if it is bogus. If we were to add an equivalent user group handler would it be the same code in add_condition and remove_condition? It is sort of nice to have everything together at the moment, I suspect it will need to be generalized at some point. Well. For the groups, I was thinking it starts to get a little different. I would still reuse the condition, but I believe I would pivot users into groups based upon something like their manager? Adding a clarity with no rules won't let you add rules: # ipa hostgroup-add --desc=hg1 hg1 # ipa hostgroupclarity-add hg1 # ipa hostgroupclarity-add-condition --exclusive-hostname-regex=^web5\.example\.com hg1 ipa: ERROR: no modifications to be performed This ^ is deliberate, you cannot add an exclusion rule if there is no existing or simultaneous inclusive rule. :) Martin asked for that, and I think its wise. Yes, it is wise :-) But the error message is really not clear to the user. We should tell him that there must be at least one inclusive rule. I wonder if we shouldn't force user to create a hostgroupclarity object with at least one inclusive rule and than make sure that in all operations at least one inclusive rule stays here. Or we could delete the empty LDAP object after the last inclusive rule is removed, as we do with DNS record LDAP objects in dnsrecord-del. The way you explained clarity today in IRC, how it brings clarity to managing membership with names no human can grok, I got it. Still, clarity is a bit awkward as a name. automember might be a better choice. Fair enough ;) I tried, perhaps I can /allude/ to it in the help / docs. automember it is. One final class I have been struggling with that I want to add… The object and attribute which defines the 'default group' is the parent of the actual rules… i.e. cn=hostgroup,cn=automember,cn=etc… The ipa cli seems to only want to let me make mods that assume I am specifying a target object on the cli… ipa hostgroupautomember-default-group=foorulename- in this scenario, we don't actually want or need a rule name because its the container above… I have had success making the writes, but the cli syntax just doesn't lend itself to that level of abstraction… Any suggestions? I think the best shot would be to create a new command and overload the execute method in that case. Like in hbacrule_enable. You would be able to set dn correctly here and do the update. Does it makes sense? Rob? Martin I agree. We are better off abstracting things now so we can get the API right. I think we can stick more or less with the command names, just in a new plugin and some new arguments. I see the plugin with the following methods: Each takes a single argument, the name of the rule. I don't think I'd stick type into the DN so you wouldn't be able to use the same rule name for different object types. If we want to allow that then we'd need to add --type to a lot more commands. There is no mod to change types, you have to delete and re-add. automember-add Add an automember rule --type=ENUM(hostgroup, group) --desc=STR description of this auto
Re: [Freeipa-devel] [PATCH] 38 Move Managed Entries into their own container in the replicated space.
On Jul 22, 2011, at 6:54 AM, Martin Kosek wrote: On Thu, 2011-07-21 at 23:00 +, JR Aquino wrote: Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container A separate patch will cover the management tool https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation extended solution I found few issues with the patch (tested along with 25): 1) When upgrading an old instance, NGP and UGP definitions in cn=Managed Entries,cn=plugins,cn=config were not deleted. This lead to 2 managed entries plugin definitions 2) Managed entries on a replica didn't work for me. For example UPG was created on a master, but was not on a replica Were you using 389 1.2.9? I believe the Requires should actually be present in /this/ patch instead of patch 25... 1.2.9 provides a means for directing the plugin to the NEW container in cn=etc, and after that is done, the old entries can be deleted by the code once they are no longer 'in use'. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Jul 21, 2011, at 7:31 AM, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-07-21 at 03:37 +, JR Aquino wrote: Rob, I'm afraid I believe that ldap lookup is necessary. The user inputs a standard string to represent the possible host group… If i simply perform a get_dn it will indeed provide a dn, however, it won't verify that the host group actually exists… (you don't want to create an assignment rule for a non existent target host group) Martin, (except for the name Clarity), I have addressed your observations in this latest patch. Could you please have a look and let me know if there is anything else I need to take care of? Great, preparing the command parameters in pre_callback is much cleaner. Good point about the LDAP lookup. This looks a lot better but there are still a few issues: If group_dn is in the object then you can use self.obj.handle_not_found(*keys) for the NotFound. Ok, I will give that a shot! Or if it can't be moved, in the calls to group_dn() you can use the ldap handle passed into pre_callback. I guess you are using the includetype tuple to avoid coding long variable names everywhere? Would a symbol be better, eg: INCLUDE_RE = 'automemberinclusiveregex' EXCLUDE_RE = 'automemberexclusiveregex' That works, I'll swap em. I agree with Rob here, this will make the code better. Is there a way to validate the regex? Now that you mention it, I believe if I import re, we should be able to validate the initial regex and raise an exception if it is bogus. If we were to add an equivalent user group handler would it be the same code in add_condition and remove_condition? It is sort of nice to have everything together at the moment, I suspect it will need to be generalized at some point. Well. For the groups, I was thinking it starts to get a little different. I would still reuse the condition, but I believe I would pivot users into groups based upon something like their manager? Adding a clarity with no rules won't let you add rules: # ipa hostgroup-add --desc=hg1 hg1 # ipa hostgroupclarity-add hg1 # ipa hostgroupclarity-add-condition --exclusive-hostname-regex=^web5\.example\.com hg1 ipa: ERROR: no modifications to be performed This ^ is deliberate, you cannot add an exclusion rule if there is no existing or simultaneous inclusive rule. :) Martin asked for that, and I think its wise. Yes, it is wise :-) But the error message is really not clear to the user. We should tell him that there must be at least one inclusive rule. I wonder if we shouldn't force user to create a hostgroupclarity object with at least one inclusive rule and than make sure that in all operations at least one inclusive rule stays here. Or we could delete the empty LDAP object after the last inclusive rule is removed, as we do with DNS record LDAP objects in dnsrecord-del. The way you explained clarity today in IRC, how it brings clarity to managing membership with names no human can grok, I got it. Still, clarity is a bit awkward as a name. automember might be a better choice. Fair enough ;) I tried, perhaps I can /allude/ to it in the help / docs. automember it is. One final class I have been struggling with that I want to add… The object and attribute which defines the 'default group' is the parent of the actual rules… i.e. cn=hostgroup,cn=automember,cn=etc… The ipa cli seems to only want to let me make mods that assume I am specifying a target object on the cli… ipa hostgroupautomember-default-group=foorulename- in this scenario, we don't actually want or need a rule name because its the container above… I have had success making the writes, but the cli syntax just doesn't lend itself to that level of abstraction… Any suggestions? I think the best shot would be to create a new command and overload the execute method in that case. Like in hbacrule_enable. You would be able to set dn correctly here and do the update. Does it makes sense? Rob? Martin I agree. We are better off abstracting things now so we can get the API right. I think we can stick more or less with the command names, just in a new plugin and some new arguments. I see the plugin with the following methods: Each takes a single argument, the name of the rule. I don't think I'd stick type into the DN so you wouldn't be able to use the same rule name for different object types. If we want to allow that then we'd need to add --type to a lot more commands. There is no mod to change types, you have to delete and re-add. automember-add Add an automember rule --type=ENUM (hostgroup, group) --desc=STR description of this auto membership rule --inclusive-regex=LIST Inclusive Regex --exclusive-regex=LIST Exclusive Regex automember-add-condition Add conditions to automember rule
[Freeipa-devel] [PATCH] 38 Move Managed Entries into their own container in the replicated space.
Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container A separate patch will cover the management tool https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation extended solution bin4Vi5JD3D3Q.bin Description: freeipa-jraquino-0038-Move-Managed-Entries-into-their-own-container.patch ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Apr 25, 2011, at 9:00 AM, Simo Sorce wrote: On Mon, 2011-04-25 at 14:59 +, JR Aquino wrote: On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: On Thu, 2011-04-21 at 23:28 +, JR Aquino wrote: Hmmm Both Private Groups and the Hostgroup - Netgroup Managed Entries create objects in the container: cn=Managed Entries,cn=plugins,cn=config Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, and one in the cn=config How will these be treated by replication and the multi masters? Only the common objects in the public suffix are replicated. I think at some point we discussed that we should use a filter in the private config entry made so that we could enable/disable the plugin by simply making the filter result true/false. Thus not ever touch the entries in cn=config but simply enable/disable the functionality by (not)adding the appropriate attributes to objects so that filters would (not) match. Simo. This tool works by toggling the originfilter: objectclass=disabled in order to turn off the plugin. But this is backwards, because originfilter is defined in the configuration entry stored in cn=config Meaning as soon as you change it one server will behave differently from the others until you go and change it on each and every server. Finally able to revisit this Patch / Ticket: (To be used in conjunction with Patch 38) 25 Create Tool for Enabling/Disabling Managed Entry Plugins https://fedorahosted.org/freeipa/ticket/1181 Remove legacy ipa-host-net-manage Add ipa-managed-entries tool Add man page for ipa-managed-entries tool binnZSMRerxG0.bin Description: freeipa-jraquino-0025-Create-Tool-for-Enabling-Disabling-Managed-Entries.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Jul 20, 2011, at 8:37 AM, Rob Crittenden wrote: JR Aquino wrote: On Jul 15, 2011, at 7:55 AM, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-07-14 at 23:05 +, JR Aquino wrote: On Jul 14, 2011, at 11:55 AM, wrote: https://fedorahosted.org/freeipa/ticket/1272 * Added new container in etc to hold the automembership configs. * Modified constants to point to the new container * Modified dsinstance to create the container * Modified hostgroup.py to add the new commands * Added xmlrpc test to verify functionality Minor adjustment: Auto Membership Plugin isn't available until 1.2.9-0.2+ Modified freeipa.spec.in: BuildRequires: 389-ds-base-devel= 1.2.9-0.2 I have reviewed your patch. Basic functionality is OK but I have some concerns. 1) I am not sure with the command name, it is not really clear to me what this command does. But I know from my experience that inventing a cool name for something new may be the most difficult task at all :-) Maybe command name hostgrouprule or hostgroupauto would be more clear? Perhaps my example docs were too soft with fqdn=^www[1-9]+\.example\.com etc.. I should 'clarify'... perhaps what I need to do is add more useful information to the doc, for example If I were to add to the doc area examples where hostnames are like: w[1-9]+s2r8\.example\.com The real reason for the usefulness of this technology, is in SaaS, Cloud, and Cluster environments, where the hostnames tend to be non-human readable, and more like a serial number detailing their function, their rack location, or their vm-instance, etc... It is because of those scenarios that caused me so much grief as a security engineer trying to assign rights that it became clear that I could just define the reproducible pattern to match assignment into a host group. The hostnames needed clarity in order to understand where they belonged in the network. I'll give it one more chance to pass the censors since I've been internally calling it clarity for the last 2 1/2 years that I've been using it... 2) Overloading execute method in functions hostgroupclarity_add_condition and hostgroupclarity_remove_condition is an over-kill for me. I think we could just read current inclusive/exclusive regexes in pre_callback, modify them and let LDAPUpdate class do the standard LDAP operations. I'll recode to perform the actions in a pre_callback. 3) I miss hostgroupclarity-mod module. What would I do if I want to update Description? Thank you for catching this, I will add it. 4) I didn't like this construct in the code, its error prone to potential future parameter changes. +if len(options) == 2: # 'all' and 'raw' are always sent +raise errors.EmptyModlist() I know it's in baseldap.py but I still wouldn't like to see this in plugins. I should be able to omit that once the code is located in the pre_callback. 5) Test test_clarityrule_plugin.py: reference to inexistent python module: +Test the `ipalib/plugins/clarityrule.py` module. Thank you, that is left over from a previous attempt. I will remove it. Then I did some real testing of the new command: 6) Invalid examples, fqdn is not supposed to be a part of regex $ ipa hostgroupclarity-add --inclusive-hostname-regex=fqdn=^www[1-9]+\.example\.com webservers Hostgroup Clarity Rule: webservers Inclusive Regex: fqdn=fqdn=^www[1-9]+.example.com Also an oversight, thanks, I will correct it. 7) It does not make sense to have a rule with only an exclusive regex: $ ipa hostgroupclarity-add --exclusive-hostname-regex=^www5+\.example\.com webservers Hostgroup Clarity Rule: webservers $ ipa host-add --force foo.example.co $ ipa hostgroup-show webservers Host-group: webservers Description: Web Servers Member hosts: www1.example.com I think we should 1) hide exclusive regex option in hostgroupclarity-add and 2) check that there is at least one inclusive regex in the rule when running hostgroupclarity-add-condition and hostgroupclarity-remove-condition. I agree, I'll hide it during the creation, and force it to require an inclusive prior to adding an exclusive. 8) Plugin incorrectly handles a situation when both inclusive and exclusive regex-es are being added: $ ipa hostgroupclarity-add --inclusive-hostname-regex=^www[1-9]+\.example\.com webservers Hostgroup Clarity Rule: webservers Inclusive Regex: fqdn=^www[1-9]+.example.com $ ipa hostgroupclarity-add-condition --inclusive-hostname-regex=^web[1-9]+\.example\.com --exclusive-hostname-regex=www5\.example\.com webservers Inclusive Regex: fqdn=^web[1-9]+.example.com, fqdn=^www[1-9]+.example.com Exclusive Regex: www5.example.com Exclusive regex misses fqdn. Will look into this. 9) Removing multiple conditions also works incorrectly: $ ipa hostgroupclarity-show webservers Hostgroup Clarity Rule
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
Rob, I'm afraid I believe that ldap lookup is necessary. The user inputs a standard string to represent the possible host group… If i simply perform a get_dn it will indeed provide a dn, however, it won't verify that the host group actually exists… (you don't want to create an assignment rule for a non existent target host group) Martin, (except for the name Clarity), I have addressed your observations in this latest patch. Could you please have a look and let me know if there is anything else I need to take care of? Good point about the LDAP lookup. This looks a lot better but there are still a few issues: If group_dn is in the object then you can use self.obj.handle_not_found(*keys) for the NotFound. Ok, I will give that a shot! Or if it can't be moved, in the calls to group_dn() you can use the ldap handle passed into pre_callback. I guess you are using the includetype tuple to avoid coding long variable names everywhere? Would a symbol be better, eg: INCLUDE_RE = 'automemberinclusiveregex' EXCLUDE_RE = 'automemberexclusiveregex' That works, I'll swap em. Is there a way to validate the regex? Now that you mention it, I believe if I import re, we should be able to validate the initial regex and raise an exception if it is bogus. If we were to add an equivalent user group handler would it be the same code in add_condition and remove_condition? It is sort of nice to have everything together at the moment, I suspect it will need to be generalized at some point. Well. For the groups, I was thinking it starts to get a little different. I would still reuse the condition, but I believe I would pivot users into groups based upon something like their manager? Adding a clarity with no rules won't let you add rules: # ipa hostgroup-add --desc=hg1 hg1 # ipa hostgroupclarity-add hg1 # ipa hostgroupclarity-add-condition --exclusive-hostname-regex=^web5\.example\.com hg1 ipa: ERROR: no modifications to be performed This ^ is deliberate, you cannot add an exclusion rule if there is no existing or simultaneous inclusive rule. :) Martin asked for that, and I think its wise. The way you explained clarity today in IRC, how it brings clarity to managing membership with names no human can grok, I got it. Still, clarity is a bit awkward as a name. automember might be a better choice. Fair enough ;) I tried, perhaps I can /allude/ to it in the help / docs. automember it is. One final class I have been struggling with that I want to add… The object and attribute which defines the 'default group' is the parent of the actual rules… i.e. cn=hostgroup,cn=automember,cn=etc… The ipa cli seems to only want to let me make mods that assume I am specifying a target object on the cli… ipa hostgroupautomember-default-group=foo rulename - in this scenario, we don't actually want or need a rule name because its the container above… I have had success making the writes, but the cli syntax just doesn't lend itself to that level of abstraction… Any suggestions? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 37 Correct sudo runasuser and runasgroup attributes in schema
On Jul 19, 2011, at 2:32 AM, Martin Kosek mko...@redhat.com wrote:
On Mon, 2011-07-18 at 23:43 +, JR Aquino wrote:
https://fedorahosted.org/freeipa/ticket/1309
Added .update file to correct the sudo schema during freeipa updates on
older systems.
Modified Makefile.am to account for new .update file.
NACK.
This fixes the schema well, but sudoRunAsGroup attribute is still filled
incorrectly. I think that the sudo LDAP compat plugin has to be fixed
too. These 2 rules look suspicious:
schema-compat-entry-attribute: sudoRunAsGroup=%{ipaSudoRunAsExtGroup}
schema-compat-entry-attribute: sudoRunAsGroup=%deref(ipaSudoRunAs,cn)
And one more minor issue I saw, please fix indentation in Makefile.am.
Martin
Thank you Martin, I will see about addressing the indentation in the make file.
As for compat, please look at patch 31 which is also associated with this
ticket as it addresses the concern you are referring to:
https://fedorahosted.org/freeipa/ticket/1309
Sorry for the confusion, there was a long gap between fixes.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Jul 15, 2011, at 7:55 AM, Rob Crittenden wrote: Martin Kosek wrote: On Thu, 2011-07-14 at 23:05 +, JR Aquino wrote: On Jul 14, 2011, at 11:55 AM, wrote: https://fedorahosted.org/freeipa/ticket/1272 * Added new container in etc to hold the automembership configs. * Modified constants to point to the new container * Modified dsinstance to create the container * Modified hostgroup.py to add the new commands * Added xmlrpc test to verify functionality Minor adjustment: Auto Membership Plugin isn't available until 1.2.9-0.2+ Modified freeipa.spec.in: BuildRequires: 389-ds-base-devel= 1.2.9-0.2 I have reviewed your patch. Basic functionality is OK but I have some concerns. 1) I am not sure with the command name, it is not really clear to me what this command does. But I know from my experience that inventing a cool name for something new may be the most difficult task at all :-) Maybe command name hostgrouprule or hostgroupauto would be more clear? Perhaps my example docs were too soft with fqdn=^www[1-9]+\.example\.com etc.. I should 'clarify'... perhaps what I need to do is add more useful information to the doc, for example If I were to add to the doc area examples where hostnames are like: w[1-9]+s2r8\.example\.com The real reason for the usefulness of this technology, is in SaaS, Cloud, and Cluster environments, where the hostnames tend to be non-human readable, and more like a serial number detailing their function, their rack location, or their vm-instance, etc... It is because of those scenarios that caused me so much grief as a security engineer trying to assign rights that it became clear that I could just define the reproducible pattern to match assignment into a host group. The hostnames needed clarity in order to understand where they belonged in the network. I'll give it one more chance to pass the censors since I've been internally calling it clarity for the last 2 1/2 years that I've been using it... 2) Overloading execute method in functions hostgroupclarity_add_condition and hostgroupclarity_remove_condition is an over-kill for me. I think we could just read current inclusive/exclusive regexes in pre_callback, modify them and let LDAPUpdate class do the standard LDAP operations. I'll recode to perform the actions in a pre_callback. 3) I miss hostgroupclarity-mod module. What would I do if I want to update Description? Thank you for catching this, I will add it. 4) I didn't like this construct in the code, its error prone to potential future parameter changes. +if len(options) == 2: # 'all' and 'raw' are always sent +raise errors.EmptyModlist() I know it's in baseldap.py but I still wouldn't like to see this in plugins. I should be able to omit that once the code is located in the pre_callback. 5) Test test_clarityrule_plugin.py: reference to inexistent python module: +Test the `ipalib/plugins/clarityrule.py` module. Thank you, that is left over from a previous attempt. I will remove it. Then I did some real testing of the new command: 6) Invalid examples, fqdn is not supposed to be a part of regex $ ipa hostgroupclarity-add --inclusive-hostname-regex=fqdn=^www[1-9]+\.example\.com webservers Hostgroup Clarity Rule: webservers Inclusive Regex: fqdn=fqdn=^www[1-9]+.example.com Also an oversight, thanks, I will correct it. 7) It does not make sense to have a rule with only an exclusive regex: $ ipa hostgroupclarity-add --exclusive-hostname-regex=^www5+\.example\.com webservers Hostgroup Clarity Rule: webservers $ ipa host-add --force foo.example.co $ ipa hostgroup-show webservers Host-group: webservers Description: Web Servers Member hosts: www1.example.com I think we should 1) hide exclusive regex option in hostgroupclarity-add and 2) check that there is at least one inclusive regex in the rule when running hostgroupclarity-add-condition and hostgroupclarity-remove-condition. I agree, I'll hide it during the creation, and force it to require an inclusive prior to adding an exclusive. 8) Plugin incorrectly handles a situation when both inclusive and exclusive regex-es are being added: $ ipa hostgroupclarity-add --inclusive-hostname-regex=^www[1-9]+\.example\.com webservers Hostgroup Clarity Rule: webservers Inclusive Regex: fqdn=^www[1-9]+.example.com $ ipa hostgroupclarity-add-condition --inclusive-hostname-regex=^web[1-9]+\.example\.com --exclusive-hostname-regex=www5\.example\.com webservers Inclusive Regex: fqdn=^web[1-9]+.example.com, fqdn=^www[1-9]+.example.com Exclusive Regex: www5.example.com Exclusive regex misses fqdn. Will look into this. 9) Removing multiple conditions also works incorrectly: $ ipa hostgroupclarity-show webservers Hostgroup Clarity Rule: webservers Inclusive Regex: fqdn=^www[1-9]+.example.com, fqdn=^web[1-9]+.example.com Exclusive Regex: fqdn=www5
Re: [Freeipa-devel] [PATCH] 31 Correct behavior for sudorunasgroup vs sudorunasuser
On Jul 19, 2011, at 7:30 AM, Martin Kosek wrote: On Tue, 2011-06-14 at 19:03 +, JR Aquino wrote: Adjustment to install/share/schema_compat.uldif to correctly assign sudorunasuser for both a user and group object respectively. The bug had to do with the compat plugin syntax needing to correctly identify the difference behind intent with the 'runas' attributes. The difference is handling is: Sudo allowing someone to run a command as a user, or any user in a _group_. vs Sudo allowing someone to run a command as their own user but with a different _Group_ or GUID. This is a very subtle difference that can be frustrating to configure / think about. I have added a patch to address new standard installs and updates. (This Fix is blocked by https://bugzilla.redhat.com/show_bug.cgi?id=713209) NACK. 1) You forgot to update install/updates/Makefile.am so that the update is really executed. Please check that there won't be a conflict with your patch 37, they touch the same areas. Fixed 2) Syntax of the replace statement in .update files has changed since you submitted your patch. The old and the new value are delimited with :: now, IIRC. And Fixed binODuqdArXrj.bin Description: freeipa-jraquino-0031-Correct-behavior-for-sudorunasgroup-vs-sudorunasuser.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 35 remove escapes from the cvs parser in ipaserver/install/ldapupdate
On Jul 18, 2011, at 1:08 PM, wrote: https://fedorahosted.org/freeipa/ticket/1472 Changeset 8e086fd7b8c1edd0ccfec527c0699d396a7954f9 introduced a bug with ldapupdate resulting in incorrect handling of uldif files. Particularly the schema_compat.uldif. freeipa-jraquino-0035-remove-escapes-from-the-cvs-parser-in-ldapupdate.patch Added PATCH to subject line. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] 35 remove escapes from the cvs parser in ipaserver/install/ldapupdate
https://fedorahosted.org/freeipa/ticket/1472 Changeset 8e086fd7b8c1edd0ccfec527c0699d396a7954f9 introduced a bug with ldapupdate resulting in incorrect handling of uldif files. Particularly the schema_compat.uldif. binyrC3uyjN7A.bin Description: freeipa-jraquino-0035-remove-escapes-from-the-cvs-parser-in-ldapupdate.patch ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 36 Removed RunAs External Group is removed in the output when --all switch is used.
https://fedorahosted.org/freeipa/ticket/1348 Corrected behavior for ipa sudorule-remove-runasgroup rule1 --groups=tgroup2 --all binTRh8Wcv8ho.bin Description: freeipa-jraquino-0036-Removed-RunAs-External-Group-is-removed-in-the-output.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 37 Correct sudo runasuser and runasgroup attributes in schema
https://fedorahosted.org/freeipa/ticket/1309 Added .update file to correct the sudo schema during freeipa updates on older systems. Modified Makefile.am to account for new .update file. binuYzjiki10A.bin Description: freeipa-jraquino-0037-Correct-sudo-runasuser-and-runasgroup-attributes.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
https://fedorahosted.org/freeipa/ticket/1272 * Added new container in etc to hold the automembership configs. * Modified constants to point to the new container * Modified dsinstance to create the container * Modified hostgroup.py to add the new commands * Added xmlrpc test to verify functionality binfWm24aLDHv.bin Description: freeipa-jraquino-0034-Create-FreeIPA-CLI-Plugin-for-the-389-Auto-Membershi.patch ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 34 Create FreeIPA CLI Plugin for the 389 Auto Membership plugin
On Jul 14, 2011, at 11:55 AM, wrote: https://fedorahosted.org/freeipa/ticket/1272 * Added new container in etc to hold the automembership configs. * Modified constants to point to the new container * Modified dsinstance to create the container * Modified hostgroup.py to add the new commands * Added xmlrpc test to verify functionality Minor adjustment: Auto Membership Plugin isn't available until 1.2.9-0.2+ Modified freeipa.spec.in: BuildRequires: 389-ds-base-devel = 1.2.9-0.2 bin5faXeU99Xs.bin Description: freeipa-jraquino-0034-Create-FreeIPA-CLI-Plugin-for-the-389-Auto-Membershi.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 33 oneliner correct typo in ipasudorunas_group
https://fedorahosted.org/freeipa/ticket/1326 In case I haven't sent this out before. ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 29 Raise DuplicateEntry Error when adding a duplicate sudo option
On Jun 16, 2011, at 8:01 AM, Rob Crittenden wrote: JR Aquino wrote: On Jun 15, 2011, at 8:03 AM, Rob Crittenden wrote: A minor issue and a question. The minor issue is you changed a couple of options from optional to mandatory, which is fine, but we need to bump up the minor version in VERSION (older clients otherwise could not send the string and blow things up). Is there a rule of thumb or document that details when this is appropriate? The question is, should we raise EmptyModList() when removing an option that doesn't exist or NotFound(reason=_())? I think the second might be more explanatory but might be harder for handle in scripts (how would you distinguish between entry not found and option not found)? rob As per IRC conversation: Added new Exception: AttrValueNotFound Incremented minor version in VERSION Adjusted API 1276 (Raise AttrValueNotFound when trying to remove a non-existent option from Sudo rule) 1277 (Raise DuplicateEntry Error when adding a duplicate sudo option) 1308 (Make sudooption a required option for sudorule_remove_option) This is very close, found a couple more issues: I don't think I was very clear in what to update in VERSION, you want it to look like this: diff --git a/VERSION b/VERSION index 6cbf732..e31f0d0 100644 --- a/VERSION +++ b/VERSION @@ -79,4 +79,4 @@ IPA_DATA_VERSION=2010061412 # # IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=5 +IPA_API_VERSION_MINOR=6 Two tests are failing. One is failing because externalhost is returned as a tuple (rather than not at all). The second because sudorule_remove_option has changed the type of data being returned. rob Ok, the VERSION issue is resolved, and the ipasudoopt test issue is solved. I have created: https://fedorahosted.org/freeipa/ticket/1339 to address the externalhost tuple as it is separate from the sudo options effort. binL1EGmvO8nL.bin Description: freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] 32 Don't add empty tuple to entry_attrs['externalhost']
https://fedorahosted.org/freeipa/ticket/1339 binniSici8OHk.bin Description: freeipa-jraquino-0032-Dont-add-empty-tuple-to-entry_attrs-externalhost.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 802 add message summary to sudorule
On Jun 14, 2011, at 6:36 PM, Rob Crittenden wrote: Some of the sudorule commands were missing a message summary. ticket https://fedorahosted.org/freeipa/ticket/1255 rob freeipa-rcrit-802-sudo.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel NACK error: patch failed: ipalib/plugins/sudorule.py:189 error: ipalib/plugins/sudorule.py: patch does not apply Appears to perhaps be off by 1 line number. You might have to rebase. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 29 Raise DuplicateEntry Error when adding a duplicate sudo option
On Jun 15, 2011, at 8:03 AM, Rob Crittenden wrote: A minor issue and a question. The minor issue is you changed a couple of options from optional to mandatory, which is fine, but we need to bump up the minor version in VERSION (older clients otherwise could not send the string and blow things up). Is there a rule of thumb or document that details when this is appropriate? The question is, should we raise EmptyModList() when removing an option that doesn't exist or NotFound(reason=_())? I think the second might be more explanatory but might be harder for handle in scripts (how would you distinguish between entry not found and option not found)? rob As per IRC conversation: Added new Exception: AttrValueNotFound Incremented minor version in VERSION Adjusted API 1276 (Raise AttrValueNotFound when trying to remove a non-existent option from Sudo rule) 1277 (Raise DuplicateEntry Error when adding a duplicate sudo option) 1308 (Make sudooption a required option for sudorule_remove_option) binr2ad1uNgGK.bin Description: freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 31 Correct behavior for sudorunasgroup vs sudorunasuser
Adjustment to install/share/schema_compat.uldif to correctly assign sudorunasuser for both a user and group object respectively. The bug had to do with the compat plugin syntax needing to correctly identify the difference behind intent with the 'runas' attributes. The difference is handling is: Sudo allowing someone to run a command as a user, or any user in a _group_. vs Sudo allowing someone to run a command as their own user but with a different _Group_ or GUID. This is a very subtle difference that can be frustrating to configure / think about. I have added a patch to address new standard installs and updates. (This Fix is blocked by https://bugzilla.redhat.com/show_bug.cgi?id=713209) binkXtDn1WRLj.bin Description: freeipa-jraquino-0031-Correct-behavior-for-sudorunasgroup-vs-sudorunasuser.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 29 Raise DuplicateEntry Error when adding a duplicate sudo option
On Jun 14, 2011, at 11:06 AM, Rob Crittenden wrote:
JR Aquino wrote:
On Jun 10, 2011, at 3:11 PM, JR Aquino wrote:
On Jun 9, 2011, at 10:24 AM, Rob Crittenden wrote:
JR Aquino wrote:
https://fedorahosted.org/freeipa/ticket/1277
Raise DuplicateEntry Error when adding a duplicate sudo option
nack, this will still fail if no ipasudoopt is passed in.
Also, is this case-sensitive?
Yes, it is case sensitive (Example: sudoOption: env_keep+=SSH_AUTH_SOCK)
Here is an adjusted patch to account for no ipasudoopt as well as an empty
space.
freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch
Minor correction: Addressed the 1 character change needed to address #1276
Added notes to indicate this patch fixes:
#1276 (Removed option from Sudo rule message is displayed even when the
given option doesn't exist.)
#1277 (Added option to Sudo rule message is displayed even when the given
option already exists.)
#1308 (Internal error while removing sudorule option without --sudooption)
NACK
$ ipa sudorule-add test
--
Added sudo rule test
--
Rule name: test
Enabled: TRUE
$ ipa sudorule-remove-option test --sudooption=foo
---
sudorule-remove-option:
---
Rule name: test
ipa: ERROR: KeyError: 'ipasudoopt'
Traceback (most recent call last):
File /home/rcrit/redhat/freeipa-master/ipalib/cli.py, line 1141, in run
sys.exit(api.Backend.cli.run(argv))
File /home/rcrit/redhat/freeipa-master/ipalib/cli.py, line 965, in run
rv = cmd.output_for_cli(self.api.Backend.textui, result, *args, **options)
File /home/rcrit/redhat/freeipa-master/ipalib/plugins/sudorule.py, line
675, in output_for_cli
textui.print_attribute('Sudo Options', result['result']['ipasudoopt'])
KeyError: 'ipasudoopt'
ipa: ERROR: an internal error has occurred
Is this legal?
$ ipa sudorule-add-option test --sudooption=foo
sudorule-add-option:
Rule name: test
Sudo Options: foo
$ ipa sudorule-add-option test --sudooption=foo
ipa: ERROR: This entry already exists
$ ipa sudorule-add-option test --sudooption=FOO
sudorule-add-option:
Rule name: test
Sudo Options: foo
Sudo Options: FOO
This is legal ^ Or if you like double negatives, this is not illegal.
However, the only options that will be respected are listed:
http://www.gratisoft.us/sudo/man/1.8.1/sudoers.man.html in the SUDOERS OPTIONS
section. Some of the values can be singular like:
sudoOption: !authenticate which will allow you to run sudo without a password
or sudoOption: iolog_dir=/var/log/sudo-playback
I also noticed that ipasudoopt doesn't have a label and isn't shown in the
rule by default.
Here is a corrected patch to address the KeyError and the display issue.
binXCkevccW1o.bin
Description: freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 30 Display remaining external hosts when removing from sudorule
This small 2 line patch addresses 2 bugs: https://fedorahosted.org/freeipa/ticket/1269 - (Remaining external hosts not displayed while removing one from a sudorule.) https://fedorahosted.org/freeipa/ticket/1270 - (Removed external host is displayed in the output when --all switch is used) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 29 Raise DuplicateEntry Error when adding a duplicate sudo option
On Jun 9, 2011, at 10:24 AM, Rob Crittenden wrote: JR Aquino wrote: https://fedorahosted.org/freeipa/ticket/1277 Raise DuplicateEntry Error when adding a duplicate sudo option nack, this will still fail if no ipasudoopt is passed in. Also, is this case-sensitive? Yes, it is case sensitive (Example: sudoOption: env_keep+=SSH_AUTH_SOCK) Here is an adjusted patch to account for no ipasudoopt as well as an empty space. binlpJMvoMsfZ.bin Description: freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 29 Raise DuplicateEntry Error when adding a duplicate sudo option
On Jun 10, 2011, at 3:11 PM, JR Aquino wrote: On Jun 9, 2011, at 10:24 AM, Rob Crittenden wrote: JR Aquino wrote: https://fedorahosted.org/freeipa/ticket/1277 Raise DuplicateEntry Error when adding a duplicate sudo option nack, this will still fail if no ipasudoopt is passed in. Also, is this case-sensitive? Yes, it is case sensitive (Example: sudoOption: env_keep+=SSH_AUTH_SOCK) Here is an adjusted patch to account for no ipasudoopt as well as an empty space. freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch Minor correction: Addressed the 1 character change needed to address #1276 Added notes to indicate this patch fixes: #1276 (Removed option from Sudo rule message is displayed even when the given option doesn't exist.) #1277 (Added option to Sudo rule message is displayed even when the given option already exists.) #1308 (Internal error while removing sudorule option without --sudooption) binJhSIDaySFB.bin Description: freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 29 Raise DuplicateEntry Error when adding a duplicate sudo option
https://fedorahosted.org/freeipa/ticket/1277 Raise DuplicateEntry Error when adding a duplicate sudo option binJU77riy9dW.bin Description: freeipa-jraquino-0029-Raise-DuplicateEntry-Error-when-adding-a-duplicate.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Visibility of the sensitive LDAP data
On Jun 8, 2011, at 11:30 AM, Simo Sorce wrote: On Wed, 2011-06-08 at 14:15 -0400, Dmitri Pal wrote: Hi, We have been through this some time before and the decision made then still left me uneasy. We said that LDAP is by nature something is a readable by an authenticated used. Other than special password and key related attributes everything else should be readable. Now we have a bug https://bugzilla.redhat.com/show_bug.cgi?id=711693 It seems reasonable to hide the SUDO information from the normal user and not make it widely available. I would argue that the HBAC should fall into the same category. I suspect there is a way to hide this information and if we implemented everything correctly the UI and CLI should not fail and respecting the effective rights will not present the UI or fail the CLI command. So what should we do: 1) Leave as is and not bother at all (i.e. it is what it is) 2) Leave as is and defer the solution till later (do not fix it in 2.1 defer to 2.2) 3) Leave as is but document how to do it using permissions ACIs 4) Provide default ACIs that would hide the records for the broad user population Looking for an opinion here. I am for (2) Simo. I am also for (2) This logic becomes quite tricky however, because controlling this via ACI's would have to be cognizant of the authenticated user to be able to make the decision to show them only their /OWN/ authorization/access rights... ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Visibility of the sensitive LDAP data
On Jun 8, 2011, at 12:29 PM, Dmitri Pal wrote: On 06/08/2011 03:15 PM, JR Aquino wrote: 1) Leave as is and not bother at all (i.e. it is what it is) 2) Leave as is and defer the solution till later (do not fix it in 2.1 defer to 2.2) 3) Leave as is but document how to do it using permissions ACIs 4) Provide default ACIs that would hide the records for the broad user population Looking for an opinion here. I am for (2) Simo. I am also for (2) This logic becomes quite tricky however, because controlling this via ACI's would have to be cognizant of the authenticated user to be able to make the decision to show them only their /OWN/ authorization/access rights... I am not sure if the user really needs to see these things at all. The SUDO and HBAC rules should be seen by SSSD or the LDAP client on the host (until SUDO is SSSD integrated) the user does not need to see or fetch the rules for himself. I do not think that any system exposes its access control rules in a way that user can inspect and see in advance what he can do and what he can't. Correct, specifically... SSSD doesn't currently have support for SUDO, so a 'BindUser' is used to perform ldap lookups for sudo information, my point was, the Client/Server system is what is performing the ldap lookup, not the user itself. The system must have the ability to review all entries in order to perform the decision making process. Whether the FreeIPA cli allows a user to run 'ipa hbacrule-find or ipa sudorule-find' is somewhat moot, as they can just do an ldap search to find that information out anyway (in the case of sudo, all of the needed information is present in the clear in /etc/nss_ldap.conf anyway -owned by root-) So Yes, I think that it is important for the CLI to limit an authenticated user's commands based on their authorization. BUT I think in addition to that, it is important to understand that the backend would be a way to short-circuit any prohibitions we implement via the cli. I suppose ideally, you want to introduce a change that satisfies both requirements. -JR ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] FreeIPA Auto Membership CLI
I need feed back from the group regarding how we should present the output for Clarity, the 389 Directory Server Auto Membership Plugin... Currently, the output looks like this: ---=== EXAMPLE ===--- [root@auth2 ~]# ipa clarityrule-show testrule --all dn: cn=testrule,cn=automember,cn=etc,dc=expertcity,dc=com Clarity Rule: testrule Membership filter: objectclass=ipaHost Default Group: cn=orphans,cn=hostgroups,cn=accounts,dc=expertcity,dc=com Inclusive Regex: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com::fqdn=^web[1-9]+.example.com, cn=mailservers,cn=hostgroups,cn=accounts,dc=example,dc=com::fqdn=^mail[1-9]+.example.com, cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com::fqdn=^www[1-9]+.example.com Exclusive Regex: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com:blacklist www5:fqdn=^www5\.example\.com automembergroupingattr: member:dn automemberscope: dc=expertcity,dc=com objectclass: top, automemberdefinition ---=== EXAMPLE ===--- Each rule in the definition object is broken down into 3 distinct parts: Group to modify, Description, Attribute + Regular Expression to match. As time progresses it will be likely that these rules could get long and visually unappealing. I would like to know how we might better represent this info. Perhaps a breakout with indentation for each unique group defined in each rule? ---===SUGGESTION===--- [root@auth2 ~]# ipa clarityrule-show testrule --all dn: cn=testrule,cn=automember,cn=etc,dc=expertcity,dc=com Clarity Rule: testrule Membership filter: objectclass=ipaHost Default Group: cn=orphans,cn=hostgroups,cn=accounts,dc=expertcity,dc=com Inclusive Regex: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com FrontEnd: fqdn=^web[1-9]+.example.com, MainSite: fqdn=^www[1-9]+.example.com cn=mailservers,cn=hostgroups,cn=accounts,dc=example,dc=com SMTP: fqdn=^mail[1-9]+.example.com, Exclusive Regex: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com blacklist: www5:fqdn=^www5\.example\.com automembergroupingattr: member:dn automemberscope: dc=expertcity,dc=com objectclass: top, automemberdefinition ---===SUGGESTION===--- Using these rules, the Auto Membership Plugin monitors for insertions into the LDAP directory matching the Membership Filter; In this example, objectclass=ipaHost The object matching the filter is then compared against the exclusive rules to make sure there is not a marker which indicates the object should NOT be a member of a given group. Then the object is compared against the inclusive rules to determine if there is a match. If there is a match, the object is added to the group defined in the matching rule. If all rules are exhausted, the object is optionally added to the group defined by the Default Group attribute of the Definition. You can view the design document here for more details on the how the rules are represented within the raw directory. http://directory.fedoraproject.org/wiki/Auto_Membership_Design ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to memberof AND indirectmemberof attributes
On May 20, 2011, at 8:32 AM, Rob Crittenden wrote:
JR Aquino wrote:
On May 10, 2011, at 8:14 PM, Adam Young wrote:
On 05/10/2011 11:07 PM, Adam Young wrote:
On 05/10/2011 04:38 PM, JR Aquino wrote:
On Apr 22, 2011, at 12:53 PM, Rob Crittenden wrote:
JR Aquino wrote:
On Apr 12, 2011, at 9:45 AM, JR Aquino wrote:
Add HBAC Rule and Sudo Rule to users as indirect member attributes to
simplify the auditing of users for their indirect membership to their
authorization rights.
An Administrator should have the ability to quickly identify the
rights a user will have in the system.
For example. With the patch added, my user show looks like this:
# ipa user-show tester --all
dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com
User login: tester
First name: Tester
Last name: Engineering
Full name: Tester Engineering
Display name: Tester Engineering
Initials: TE
Home directory: /home/tester
GECOS field: Tester Engineering
Login shell: /bin/sh
Kerberos principal:
tes...@example.com
UID: 1829800388
GID: 1829800388
Account disabled: False
Member of groups: ipausers, auto-dev-deploy-tools, build-integration
ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0
krbpwdpolicyreference:
cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com
memberofindirect_HBAC rule: development
memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY,
AUTO-dev-deploy-tools_ZENOSS, build-integration
mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com
objectclass: top, person, organizationalperson, inetorgperson,
inetuser, posixaccount
freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
OPPS, forgot to have PATCH in the subject.
I think you need this as well, right?
-'memberof': ['group', 'netgroup', 'role'],
+'memberof': ['group', 'netgroup', 'role', 'sudorule',
'hbacrule'],
Some scope change.
Added memberof and memberofindirect
Added to user.py host.py group.py hostgroup.py
When using the --all flag it is now very clear to the administrator what
authorization rules these objects are directly or indirectly a memberof.
xmlrpc tests check out
Please review
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
The reason that this shows up in the UI is that it is generating
additional memberof attributes. It has nothing to do with the
memberofindirect:
You are also going to want need modify the sudo rule and HBAC rule to use
the serial associator on some facets. It looks like group at least has
things backwards. The group.js file I think needs a rule like this:
association_facet({
name: 'memberof_sudorule',
associator: IPA.serial_associator
}).
THis is because the API is for adding multiple groups to the sudo rule, but
the default behaviour is for adding multipleother entity tothis entity.
The above comment is regarding ticket:
https://fedorahosted.org/freeipa/ticket/1218 which is dependent on this
patch and ticket 1170
As for Patch 24 and ticket 1170, are there any other questions or does this
look ready to go?
Nack, this adds some additional API that isn't in API.txt.
It would be nice to add test cases for this as well, perhaps in the sudo and
hbac tests (create a rule, add a user to it, make sure when showing the user
you can see the rule).
New patch attached to address API and Tests.
(Please note Ticket# 1263 incase there are problems testing)
Please review and ack
binZSYqz8RswD.bin
Description: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-memberof-indirectmemberof-attrib.patch
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 28 Move Managed Entries into their own container
On May 24, 2011, at 10:48 AM, Rob Crittenden wrote: JR Aquino wrote: On May 24, 2011, at 8:17 AM, Rob Crittenden wrote: JR Aquino wrote: On May 23, 2011, at 2:42 PM, Rob Crittendenrcrit...@redhat.com wrote: JR Aquino wrote: On May 19, 2011, at 6:16 AM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 12:46 PM, JR Aquino wrote: This effects Ticket 1222 and Rob's patch 786 Per IRC Conversation with Simo and Rob, take the path of least change. The patch has been modified to correct the CN to match the DN rather than changing both. This looks good. I'm going to wait to push it at the same time as 786. Simo mentioned that I need to create the .update in the patch so that we remove the previous typo laden entry during updates. I added that to my patch. rob NACK both 28 and 786. Please see attached, and have a look at this new patch and ticket 1182 for a better understanding of the impact they have on these patches. Move Managed Entries into their own container in the replicated space. Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation Well, I like this in spirit but this requires a yet-unreleased version of 389-ds, right? Should we take the intermediate step of your previous 28 patch and my 786 and then address moving entries once 389-ds is released? Hrm. You have a good point... Should I plan on deleting the .update files for user private groups and nis/host groups in the separate patch that institutes the container move? Not sure I follow. What I'd like to do is take an incremental approach. Lets get managed entries working at all on replicas first, then deal with moving the configuration once this functionality is widely available. I hereby retract the big patch in favor of the incremental approach. Patch 786 and 28 are sane. Ok, but is this an ack ;-) ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 786 Configure Managed Entries on replicas.
On May 20, 2011, at 7:14 AM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: Rob Crittenden wrote: The Managed Entries plugin configurations weren't being created on replica installs. The templates were there but the cn=config portions were not. This patch adds them as updates. The template portion will be added in the initial replication. ticket 1222 To test: Install a master Install a replica On replica: kinit On replica: ipa user-add --first=timmy --last=test ttest On replica: ipa group-show ttest On master: ipa group-show ttest rob Updated patch attached. This requires jraquino patch 28 to work as expected. rob freeipa-rcrit-786-2-replica.patch NACK This patch is not applying to Master? error: patch failed: install/updates/Makefile.am:8 error: install/updates/Makefile.am: patch does not apply Rebased, it depended on my patch 769. ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 28 Move Managed Entries into their own container
On May 24, 2011, at 8:17 AM, Rob Crittenden wrote: JR Aquino wrote: On May 23, 2011, at 2:42 PM, Rob Crittendenrcrit...@redhat.com wrote: JR Aquino wrote: On May 19, 2011, at 6:16 AM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 12:46 PM, JR Aquino wrote: This effects Ticket 1222 and Rob's patch 786 Per IRC Conversation with Simo and Rob, take the path of least change. The patch has been modified to correct the CN to match the DN rather than changing both. This looks good. I'm going to wait to push it at the same time as 786. Simo mentioned that I need to create the .update in the patch so that we remove the previous typo laden entry during updates. I added that to my patch. rob NACK both 28 and 786. Please see attached, and have a look at this new patch and ticket 1182 for a better understanding of the impact they have on these patches. Move Managed Entries into their own container in the replicated space. Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation Well, I like this in spirit but this requires a yet-unreleased version of 389-ds, right? Should we take the intermediate step of your previous 28 patch and my 786 and then address moving entries once 389-ds is released? Hrm. You have a good point... Should I plan on deleting the .update files for user private groups and nis/host groups in the separate patch that institutes the container move? Not sure I follow. Let me try to be more clear. What I'd like to do is take an incremental approach. Yes I agree. Lets get managed entries working at all on replicas first, then deal with moving the configuration once this functionality is widely available. My new method performs an ldap lookup to query the contents of the legacy configuration objects, and actually moves them to the new locations which are replica friendly. Thus, I was suggesting, yes, let us move forward with baby steps, fix the cn naming oversight, fix the replica install oversight with the .update files. Then once ns-slapd 1.2.9 is available, implement the newer patch, which makes the .update files for host/nis and user private groups obsolete. (Since it will read the data, and any additional custom user created configs, and move them) That's what I had meant about having the future patch provide an updated method for handling the 'upgrade' and migration and remove those .update files as they would no longer be relevant. -JR ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 28 Move Managed Entries into their own container
On May 24, 2011, at 8:17 AM, Rob Crittenden wrote: JR Aquino wrote: On May 23, 2011, at 2:42 PM, Rob Crittendenrcrit...@redhat.com wrote: JR Aquino wrote: On May 19, 2011, at 6:16 AM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 12:46 PM, JR Aquino wrote: This effects Ticket 1222 and Rob's patch 786 Per IRC Conversation with Simo and Rob, take the path of least change. The patch has been modified to correct the CN to match the DN rather than changing both. This looks good. I'm going to wait to push it at the same time as 786. Simo mentioned that I need to create the .update in the patch so that we remove the previous typo laden entry during updates. I added that to my patch. rob NACK both 28 and 786. Please see attached, and have a look at this new patch and ticket 1182 for a better understanding of the impact they have on these patches. Move Managed Entries into their own container in the replicated space. Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation Well, I like this in spirit but this requires a yet-unreleased version of 389-ds, right? Should we take the intermediate step of your previous 28 patch and my 786 and then address moving entries once 389-ds is released? Hrm. You have a good point... Should I plan on deleting the .update files for user private groups and nis/host groups in the separate patch that institutes the container move? Not sure I follow. What I'd like to do is take an incremental approach. Lets get managed entries working at all on replicas first, then deal with moving the configuration once this functionality is widely available. I hereby retract the big patch in favor of the incremental approach. Patch 786 and 28 are sane. binkW6bl3YoI8.bin Description: freeipa-jraquino-0028-One-Liner-Typo-in-host_nis_groups-has-been-creating.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 28 Move Managed Entries into their own container
On May 23, 2011, at 2:42 PM, Rob Crittenden rcrit...@redhat.com wrote: JR Aquino wrote: On May 19, 2011, at 6:16 AM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 12:46 PM, JR Aquino wrote: This effects Ticket 1222 and Rob's patch 786 Per IRC Conversation with Simo and Rob, take the path of least change. The patch has been modified to correct the CN to match the DN rather than changing both. This looks good. I'm going to wait to push it at the same time as 786. Simo mentioned that I need to create the .update in the patch so that we remove the previous typo laden entry during updates. I added that to my patch. rob NACK both 28 and 786. Please see attached, and have a look at this new patch and ticket 1182 for a better understanding of the impact they have on these patches. Move Managed Entries into their own container in the replicated space. Create: cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX Create: cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX Create method for migrating any and all custom Managed Entries from the cn=config space into the new container. The Managed Entries plugin configurations weren't being created on replica installs. This patch addresses two seperate tickets and accounts for new installs, replica installs, and upgrades. https://fedorahosted.org/freeipa/ticket/1181 - Managed Entry Tool / New Container https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation Well, I like this in spirit but this requires a yet-unreleased version of 389-ds, right? Should we take the intermediate step of your previous 28 patch and my 786 and then address moving entries once 389-ds is released? Hrm. You have a good point... Should I plan on deleting the .update files for user private groups and nis/host groups in the separate patch that institutes the container move? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 786 Configure Managed Entries on replicas.
On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: Rob Crittenden wrote: The Managed Entries plugin configurations weren't being created on replica installs. The templates were there but the cn=config portions were not. This patch adds them as updates. The template portion will be added in the initial replication. ticket 1222 To test: Install a master Install a replica On replica: kinit On replica: ipa user-add --first=timmy --last=test ttest On replica: ipa group-show ttest On master: ipa group-show ttest rob Updated patch attached. This requires jraquino patch 28 to work as expected. rob freeipa-rcrit-786-2-replica.patch NACK This patch is not applying to Master? error: patch failed: install/updates/Makefile.am:8 error: install/updates/Makefile.am: patch does not apply ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 28 One Liner: Typo in host_nis_groups has been creating 2 CN's
This effects Ticket 1222 and Rob's patch 786 binlDpwG7aVPN.bin Description: freeipa-jraquino-0028-One-Liner-Typo-in-host_nis_groups-has-been-creating.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 28 One Liner: Typo in host_nis_groups has been creating 2 CN's
On May 18, 2011, at 12:46 PM, JR Aquino wrote: This effects Ticket 1222 and Rob's patch 786 Per IRC Conversation with Simo and Rob, take the path of least change. The patch has been modified to correct the CN to match the DN rather than changing both. binSqyGhoZYFC.bin Description: freeipa-jraquino-0028-One-Liner-Typo-in-host_nis_groups-has-been-creating.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 28 One Liner: Typo in host_nis_groups has been creating 2 CN's
On May 18, 2011, at 2:52 PM, Rob Crittenden wrote: JR Aquino wrote: On May 18, 2011, at 12:46 PM, JR Aquino wrote: This effects Ticket 1222 and Rob's patch 786 Per IRC Conversation with Simo and Rob, take the path of least change. The patch has been modified to correct the CN to match the DN rather than changing both. This looks good. I'm going to wait to push it at the same time as 786. Simo mentioned that I need to create the .update in the patch so that we remove the previous typo laden entry during updates. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 20 Assume ipa help for plugins
On May 13, 2011, at 5:48 AM, Jan Cholasta wrote: Show help for plugin when the user runs 'ipa plugin', instead of printing an error message about unknown command. https://fedorahosted.org/freeipa/ticket/914 Honza -- Jan Cholasta freeipa-jcholast-20-assume-ipa-help.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Looks Good! ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Move DNS to the Identity Tab?
On May 13, 2011, at 8:47 AM, Adam Young wrote: One minor piece of Feedback I got from people at the Summit was surprise that DNS was on the Policy tab and not on the Identity tab. Moving this is trivial. Does anyone object to me making that change? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Makes sense. It defines the Identity of the hosts etc... It's more an Identity than it is a Policy ;) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to memberof AND indirectmemberof attributes
On May 10, 2011, at 8:14 PM, Adam Young wrote:
On 05/10/2011 11:07 PM, Adam Young wrote:
On 05/10/2011 04:38 PM, JR Aquino wrote:
On Apr 22, 2011, at 12:53 PM, Rob Crittenden wrote:
JR Aquino wrote:
On Apr 12, 2011, at 9:45 AM, JR Aquino wrote:
Add HBAC Rule and Sudo Rule to users as indirect member attributes to
simplify the auditing of users for their indirect membership to their
authorization rights.
An Administrator should have the ability to quickly identify the rights
a user will have in the system.
For example. With the patch added, my user show looks like this:
# ipa user-show tester --all
dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com
User login: tester
First name: Tester
Last name: Engineering
Full name: Tester Engineering
Display name: Tester Engineering
Initials: TE
Home directory: /home/tester
GECOS field: Tester Engineering
Login shell: /bin/sh
Kerberos principal:
tes...@example.com
UID: 1829800388
GID: 1829800388
Account disabled: False
Member of groups: ipausers, auto-dev-deploy-tools, build-integration
ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0
krbpwdpolicyreference:
cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com
memberofindirect_HBAC rule: development
memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY,
AUTO-dev-deploy-tools_ZENOSS, build-integration
mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com
objectclass: top, person, organizationalperson, inetorgperson,
inetuser, posixaccount
freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
OPPS, forgot to have PATCH in the subject.
I think you need this as well, right?
-'memberof': ['group', 'netgroup', 'role'],
+'memberof': ['group', 'netgroup', 'role', 'sudorule', 'hbacrule'],
Some scope change.
Added memberof and memberofindirect
Added to user.py host.py group.py hostgroup.py
When using the --all flag it is now very clear to the administrator what
authorization rules these objects are directly or indirectly a memberof.
xmlrpc tests check out
Please review
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
The reason that this shows up in the UI is that it is generating additional
memberof attributes. It has nothing to do with the memberofindirect:
You are also going to want need modify the sudo rule and HBAC rule to use the
serial associator on some facets. It looks like group at least has things
backwards. The group.js file I think needs a rule like this:
association_facet({
name: 'memberof_sudorule',
associator: IPA.serial_associator
}).
THis is because the API is for adding multiple groups to the sudo rule, but
the default behaviour is for adding multiple other entity to this entity.
The above comment is regarding ticket:
https://fedorahosted.org/freeipa/ticket/1218 which is dependent on this patch
and ticket 1170
As for Patch 24 and ticket 1170, are there any other questions or does this
look ready to go?
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 27 Make sure ipa_config is read only when caching
It was discovered that using the batch plugin it was possible to store duplicate data in parts of the ipa_config during iterations. This was causing a cascading exec failures if any one of the batch executions failed. https://fedorahosted.org/freeipa/ticket/1220 bin76v44Z6apL.bin Description: freeipa-jraquino-0027-Make-sure-ipa_config-is-read-only-when-caching.patch ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to memberof AND indirectmemberof attributes
On Apr 22, 2011, at 12:53 PM, Rob Crittenden wrote: JR Aquino wrote: On Apr 12, 2011, at 9:45 AM, JR Aquino wrote: Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. An Administrator should have the ability to quickly identify the rights a user will have in the system. For example. With the patch added, my user show looks like this: # ipa user-show tester --all dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com User login: tester First name: Tester Last name: Engineering Full name: Tester Engineering Display name: Tester Engineering Initials: TE Home directory: /home/tester GECOS field: Tester Engineering Login shell: /bin/sh Kerberos principal: tes...@example.com UID: 1829800388 GID: 1829800388 Account disabled: False Member of groups: ipausers, auto-dev-deploy-tools, build-integration ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com memberofindirect_HBAC rule: development memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OPPS, forgot to have PATCH in the subject. I think you need this as well, right? -'memberof': ['group', 'netgroup', 'role'], +'memberof': ['group', 'netgroup', 'role', 'sudorule', 'hbacrule'], Some scope change. Added memberof and memberofindirect Added to user.py host.py group.py hostgroup.py When using the --all flag it is now very clear to the administrator what authorization rules these objects are directly or indirectly a memberof. xmlrpc tests check out Please review binPqnMACO4v3.bin Description: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-memberof-indirectmemberof-attrib.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: On Thu, 2011-04-21 at 23:28 +, JR Aquino wrote: Hmmm Both Private Groups and the Hostgroup - Netgroup Managed Entries create objects in the container: cn=Managed Entries,cn=plugins,cn=config Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, and one in the cn=config How will these be treated by replication and the multi masters? Only the common objects in the public suffix are replicated. I think at some point we discussed that we should use a filter in the private config entry made so that we could enable/disable the plugin by simply making the filter result true/false. Thus not ever touch the entries in cn=config but simply enable/disable the functionality by (not)adding the appropriate attributes to objects so that filters would (not) match. Simo. This tool works by toggling the originfilter: objectclass=disabled in order to turn off the plugin. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to (indirect)memberof attributes of user.py
On Apr 22, 2011, at 12:53 PM, Rob Crittenden wrote: JR Aquino wrote: On Apr 12, 2011, at 9:45 AM, JR Aquino wrote: Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. An Administrator should have the ability to quickly identify the rights a user will have in the system. For example. With the patch added, my user show looks like this: # ipa user-show tester --all dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com User login: tester First name: Tester Last name: Engineering Full name: Tester Engineering Display name: Tester Engineering Initials: TE Home directory: /home/tester GECOS field: Tester Engineering Login shell: /bin/sh Kerberos principal: tes...@example.com UID: 1829800388 GID: 1829800388 Account disabled: False Member of groups: ipausers, auto-dev-deploy-tools, build-integration ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com memberofindirect_HBAC rule: development memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OPPS, forgot to have PATCH in the subject. I think you need this as well, right? -'memberof': ['group', 'netgroup', 'role'], +'memberof': ['group', 'netgroup', 'role', 'sudorule', 'hbacrule'], Yes, you are right, the users can individually be assigned to rules directly. binZep0wDn7Vt.bin Description: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-memberof-indirectmemberof-attrib.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
This patch address ticket: * https://fedorahosted.org/freeipa/ticket/1181 This patch provides: * ipa-managed-entries tool which can enable/disable any of the managed entry plugins without the need of separate tools. -When run without any arguments, the tool will display a list of available plugins detected inside of /usr/share/ipa (this directory can be overridden with the --dir flag) * Man Page documenting the tool usage. * The removal of install/tools/ipa-host-net-manage and install/tools/man/ipa-host-net-manage.1 * Modification to ldap2.py: Added method for verifying upg is disabled by objectfilter: objectclass=disabled. The current code assumes that the user private group managed plugin is disabled, if the managed plugin entry is not present. Due to bug https://bugzilla.redhat.com/show_bug.cgi?id=660399, the running system will prohibit you from removing a Managed Entry plugin. NOTE: As I was writing this tool, I noticed that in addition to Managed Entry tools, we also seem to have Schema Compatibility management tools. I had considered rolling support for those plugins as well, but after further inspection, it appears that there is hierarchical way to determine our current 'Compatibility Plugins' via looking at the .uldif files. The method employed by the managed entry tool checks to see if the .ldif file contains a modification which adds an object to the container: cn=Managed Entries,cn=plugins,cn=config. If there is interest in it, we could consolidate ipa-compat-manage and ipa-nis-manage by deciding on a default Container for Compat plugins to be located in such as: cn=Schema Compatibility,cn=plugins,cn=config This would potentially give us 1 tool: ipa-plugin-manage that could handle the enabling / disabling of Compat and Managed Entry Plugins... binmndZmK7OrG.bin Description: freeipa-jraquino-0025-Create-Tool-for-Enabling-Disabling-Managed-Entries.patch ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 26 Delete the sudoers entry when disabling the Schema Compat plugin
This patch addresses ticket: https://fedorahosted.org/freeipa/ticket/1160 The disabling of the Schema Compat plugin is failing because the code was not removing all of the entries from the Schema Compatibility Container. This is a 1 line patch. bin6I2xD6AKSa.bin Description: freeipa-jraquino-0026-Delete-the-sudoers-entry-when-disabling-Schema-Compat.patch ~ Jr Aquino, GCIH | Information Security Specialist Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 jr.aqu...@citrixonline.com http://www.citrixonline.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Apr 21, 2011, at 4:03 PM, Simo Sorce sso...@redhat.commailto:sso...@redhat.com wrote: On Thu, 2011-04-21 at 15:30 -0400, Dmitri Pal wrote: On 04/21/2011 03:17 PM, JR Aquino wrote: This patch address ticket: * https://fedorahosted.org/freeipa/ticket/1181 https://fedorahosted.org/freeipa/ticket/1181 This patch provides: * ipa-managed-entries tool which can enable/disable any of the managed entry plugins without the need of separate tools. -When run without any arguments, the tool will display a list of available plugins detected inside of /usr/share/ipa (this directory can be overridden with the --dir flag) * Man Page documenting the tool usage. * The removal of install/tools/ipa-host-net-manage and install/tools/man/ipa-host-net-manage.1 * Modification to ldap2.py: Added method for verifying upg is disabled by objectfilter: objectclass=disabled. The current code assumes that the user private group managed plugin is disabled, if the managed plugin entry is not present. Due to bug https://bugzilla.redhat.com/show_bug.cgi?id=660399, the running system will prohibit you from removing a Managed Entry plugin. NOTE: As I was writing this tool, I noticed that in addition to Managed Entry tools, we also seem to have Schema Compatibility management tools. I had considered rolling support for those plugins as well, but after further inspection, it appears that there is hierarchical way to determine our current 'Compatibility Plugins' via looking at the .uldif files. The method employed by the managed entry tool checks to see if the .ldif file contains a modification which adds an object to the container: cn=Managed Entries,cn=plugins,cn=config. If there is interest in it, we could consolidate ipa-compat-manage and ipa-nis-manage by deciding on a default Container for Compat plugins to be located in such as: cn=Schema Compatibility,cn=plugins,cn=config This would potentially give us 1 tool: ipa-plugin-manage that could handle the enabling / disabling of Compat and Managed Entry Plugins... Please log an enhancement ticket. I think it will be deferred but having it in the backlog would be good. Please note that the schema compatibility plugin enabling/disabling should behave differently from the managed entries emabling/disabling. The schema compat plugins configurations are per server, so that you can decide which servers show it and which one doesn't (you may have many masters and only a few allocated to serve legacy machines that need the compat tree). This also means that you have to go to each server to enable/disable the compat trees. This should be made abundantly clear in the documentation of the respective tools. The managed entries stuff instead should be global, and shouldn't touch entries under cn=config (as they are local). If it does please let me know. Hmmm Both Private Groups and the Hostgroup - Netgroup Managed Entries create objects in the container: cn=Managed Entries,cn=plugins,cn=config Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, and one in the cn=config How will these be treated by replication and the multi masters? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.commailto:Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership
On Apr 20, 2011, at 10:32 AM, Rob Crittenden wrote:
...
Seems to work as advertised, I just have a couple of requests:
- Some of the comments are really long, can you limit to ~75 chars per line?
- In this code block:
for r in results:
direct.append(r[0])
try:
indirect.remove(r[0].lower())
except ValueError:
pass
We should log if a ValueError is thrown, this would mean something is
really wrong. Can you import logging in the file and replace pass with
something like:
logging.info('Failed to remove indirect entry %s from %s' % r[0], entry_dn)
I wonder if we should raise the ValueError too. This means that something
went very wrong.
Yes I agree that we should raise the error.
Here is the patch with the requested changes:
* Fixed width to be PEP8 compliant
* import logging
* Added logging line in exception
* Raise ValueError if we blow up during indirect removal.
Fixes 1-3 look good. I think for the exception you want:
except ValueError, e:
logging
raise e
A ValueError won't get returned over XML-RPC but the full backtrace will be
logged on the server side. The end-user will get a 903 (Internal error
raised).
rob
Ok adjusted patch attached to correct for the exception raised.
binBzK83O11Mp.bin
Description: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] About FreeIPA Blurb
On Apr 13, 2011, at 6:15 PM, Simo Sorce wrote: On Wed, 13 Apr 2011 17:05:02 -0400 Adam Young ayo...@redhat.com wrote: FreeIPA is a centralized authentication and authorization management framework, built on open standards, with a focus towards the needs of Linux and Unix clients. I'd like to ack, but when I see framework I think of something that needs further work and integration to be useful. If framework carries with it a stigma, it was not my intention to hint at an unfinished project. My intention was to capture the fact that the FreeIPA system is modular and plugin based, such that additional components can be added to the framework. If there is a better word to describe this trait, I am all for it! Authorization felt like a good strong word that would reflect the v2 features of HBAC/SUDO/DOGTAG. Something that very clearly separates FreeIPA from 'other' authentication solutions such as Standard LDAP, Kerberos, Novell eDirectory, or Symas Unified User Management. I'll take my crack at it: FreeIPA is an integrated identity and computer management solution, built on open standards, centered on servicing Linux and Unix based infrastructures Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] About FreeIPA Blurb
On Apr 13, 2011, at 6:40 PM, Adam Young wrote: On 04/13/2011 09:26 PM, Adam Young wrote: On 04/13/2011 09:15 PM, Simo Sorce wrote: On Wed, 13 Apr 2011 17:05:02 -0400 Adam Youngayo...@redhat.com wrote: FreeIPA is a centralized authentication and authorization management framework, built on open standards, with a focus towards the needs of Linux and Unix clients. I'd like to ack, but when I see framework I think of something that needs further work and integration to be useful. I'll take my crack at it: FreeIPA is an integrated identity and computer management solution, built on open standards, centered on servicing Linux and Unix based infrastructures I like that better. But identity and computer management is awkward. I think we should stick with authentication and authorization: Next hack: FreeIPA is an open standards based authentication and authorization solution for large scale Linux and Unix deployments. Self NACK. Next attempt: FreeIPA is an authentication and authorization framework for large scale Linux and Unix deployments. FreeIPA Integrates servers for Kerberos, LDAP, DNS, and X509 Certificates into a secure, reliable, and scalable identity management solution. I like it! ACK If there is a question about the word framework perhaps it can be nullified with a complete framework ? I see a lot of google hits for that pairing. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Add sudorule and hbacrule to indirectmemberof attributes of user.py
Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. An Administrator should have the ability to quickly identify the rights a user will have in the system. For example. With the patch added, my user show looks like this: # ipa user-show tester --all dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com User login: tester First name: Tester Last name: Engineering Full name: Tester Engineering Display name: Tester Engineering Initials: TE Home directory: /home/tester GECOS field: Tester Engineering Login shell: /bin/sh Kerberos principal: tes...@example.com UID: 1829800388 GID: 1829800388 Account disabled: False Member of groups: ipausers, auto-dev-deploy-tools, build-integration ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com memberofindirect_HBAC rule: development memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount binvUKVesFEPZ.bin Description: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to indirectmemberof attributes of user.py
On Apr 12, 2011, at 9:45 AM, JR Aquino wrote: Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. An Administrator should have the ability to quickly identify the rights a user will have in the system. For example. With the patch added, my user show looks like this: # ipa user-show tester --all dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com User login: tester First name: Tester Last name: Engineering Full name: Tester Engineering Display name: Tester Engineering Initials: TE Home directory: /home/tester GECOS field: Tester Engineering Login shell: /bin/sh Kerberos principal: tes...@example.com UID: 1829800388 GID: 1829800388 Account disabled: False Member of groups: ipausers, auto-dev-deploy-tools, build-integration ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com memberofindirect_HBAC rule: development memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel OPPS, forgot to have PATCH in the subject. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership
On Apr 12, 2011, at 10:55 AM, Rob Crittenden wrote:
JR Aquino wrote:
On Apr 7, 2011, at 7:08 PM, JR Aquino wrote:
On Apr 7, 2011, at 4:04 PM, JR Aquino wrote:
On Apr 7, 2011, at 3:42 PM, JR Aquino wrote:
On Mar 31, 2011, at 2:16 PM, JR Aquino wrote:
On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote:
JR Aquino wrote:
The following patch Removes around 20 lines of code and provides a
substantial increase in performance for FreeIPA member/memberof
verification searches.
The current code base blindly searches static containers for the
possible presence of members.
This patch provides a method for dynamically identifying the specific
objects to verify memberships for.
The attached patch addresses ticket:
https://fedorahosted.org/freeipa/ticket/1139
Without patch
ipa hostgroup-find
...
-
Number of entries returned 52
-
real 0m20.054s
user 0m0.934s
sys0m0.050s
With Patch
ipa find-hostgroup
...
-
Number of entries returned 52
-
real 0m15.064s
user 0m0.945s
sys0m0.057s
--
Number of entries returned 100
--
real 0m16.471s
user 0m0.814s
sys0m0.040s
Without Patch
ipa host-find
...
--
Number of entries returned 100
--
real 0m41.277s
user 0m0.806s
sys0m0.060s
With Patch
ipa host-find
...
--
Number of entries returned 100
--
real 0m16.385s
user 0m0.814s
sys0m0.053s
There is a typo in the first block, memeber.
Wouldn't it be clearer to do a negative test to continue:
if not 'member' in r[1]:
continue
rob
You're right!
Corrected patch attached.
Self Nack
After cli and webui testing, it turned out there was a previous try /
except block that was reseting the results value back to []
Corrected and reattaching new patch.
Testing cli and webui checks out correctly. Speed AND accuracy are now
addressed.
It was also discovered during the course of testing that this patch
addresses one of the causes for the bug thrown in:
https://fedorahosted.org/freeipa/ticket/1133
-JR
NACK
Looks like there may still need to be work with the indirect / direct
functions.
Will revisit next week.
Ok I finally think I've got it.
My for loop was in my try / except block. It has now been corrected.
I've tested the searches for: users, groups, sudocmds, sudcmdgroups,
sudorules, hosts, hostgroups, hbacrules, hbacsv, hbsvcgroups, and all
return as expected.
Please make sure that they return for you as well.
Please let me know if there is anything else I have missed.
Final Patch attached due to relationship with ticket 1133:
Added Comments regarding Ticket 1133 / calculating indirect:
+# If there is an exception here, it is due to a failure in
referential integrity.
+# All members should have corresponding memberOf entries.
Retested against all xmlrpc tests and passed.
Seems to work as advertised, I just have a couple of requests:
- Some of the comments are really long, can you limit to ~75 chars per line?
- In this code block:
for r in results:
direct.append(r[0])
try:
indirect.remove(r[0].lower())
except ValueError:
pass
We should log if a ValueError is thrown, this would mean something is really
wrong. Can you import logging in the file and replace pass with something
like:
logging.info('Failed to remove indirect entry %s from %s' % r[0], entry_dn)
I wonder if we should raise the ValueError too. This means that something
went very wrong.
Yes I agree that we should raise the error.
Here is the patch with the requested changes:
* Fixed width to be PEP8 compliant
* import logging
* Added logging line in exception
* Raise ValueError if we blow up during indirect removal.
binDAMuLLoWn0.bin
Description: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership
On Apr 7, 2011, at 7:08 PM, JR Aquino wrote: On Apr 7, 2011, at 4:04 PM, JR Aquino wrote: On Apr 7, 2011, at 3:42 PM, JR Aquino wrote: On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: JR Aquino wrote: The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. The current code base blindly searches static containers for the possible presence of members. This patch provides a method for dynamically identifying the specific objects to verify memberships for. The attached patch addresses ticket: https://fedorahosted.org/freeipa/ticket/1139 Without patch ipa hostgroup-find ... - Number of entries returned 52 - real 0m20.054s user 0m0.934s sys 0m0.050s With Patch ipa find-hostgroup ... - Number of entries returned 52 - real 0m15.064s user 0m0.945s sys 0m0.057s -- Number of entries returned 100 -- real 0m16.471s user 0m0.814s sys 0m0.040s Without Patch ipa host-find ... -- Number of entries returned 100 -- real 0m41.277s user 0m0.806s sys 0m0.060s With Patch ipa host-find ... -- Number of entries returned 100 -- real 0m16.385s user 0m0.814s sys 0m0.053s There is a typo in the first block, memeber. Wouldn't it be clearer to do a negative test to continue: if not 'member' in r[1]: continue rob You're right! Corrected patch attached. Self Nack After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] Corrected and reattaching new patch. Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 -JR NACK Looks like there may still need to be work with the indirect / direct functions. Will revisit next week. Ok I finally think I've got it. My for loop was in my try / except block. It has now been corrected. I've tested the searches for: users, groups, sudocmds, sudcmdgroups, sudorules, hosts, hostgroups, hbacrules, hbacsv, hbsvcgroups, and all return as expected. Please make sure that they return for you as well. Please let me know if there is anything else I have missed. Final Patch attached due to relationship with ticket 1133: Added Comments regarding Ticket 1133 / calculating indirect: +# If there is an exception here, it is due to a failure in referential integrity. +# All members should have corresponding memberOf entries. Retested against all xmlrpc tests and passed. binHAa9js33dy.bin Description: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage
Does this imply the use of ldap with tls now or just standard ldap? There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. On Apr 8, 2011, at 7:24 AM, Rob Crittenden rcrit...@redhat.com wrote: ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. Also force this to be run as root since we start/stop and configure/unconfigure services. ticket 1157 rob freeipa-rcrit-767-nis.patch ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 760 don't crash when calculating indirect
On Apr 8, 2011, at 7:32 AM, Rob Crittenden wrote: Martin Kosek wrote: On Wed, 2011-03-30 at 10:46 -0400, Rob Crittenden wrote: Rob Crittenden wrote: This prevents an internal error when calculating direct vs indirect membership. ticket 1133 I accidentally included a change from another patch. Updated patch attached. rob I think it is OK. But I would suggest adding some comment to the code - a reason why we pass the ValueError exception. It may not be self-explanatory when we return to this code in the future. Martin I'm withdrawing this patch. It seems to be covering up for a real problem. JR is doing further investigation. rob Yes, I believe I have identified the root cause of the crashes, and I believe they should be addressed by my patch for https://fedorahosted.org/freeipa/ticket/1139 My patch ensures that only the groups for which a member is a part of, will be searched to determine the object's direct or indirect membership. The only time this should throw an exception after the fix for 1139, should be if the memberOf plugin has failed to provide referential integrity. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage
On Apr 8, 2011, at 8:03 AM, Rob Crittenden wrote: On Apr 8, 2011, at 7:24 AM, Rob Crittendenrcrit...@redhat.com wrote: ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. Also force this to be run as root since we start/stop and configure/unconfigure services. ticket 1157 rob freeipa-rcrit-767-nis.patch JR Aquino wrote: Does this imply the use of ldap with tls now or just standard ldap? There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. It uses 389, no TLS. rob Is there a way to solve both problems? #1 Autobind limits root - ldapi #2 IPA Tools should not fail when 389ds:dse.ldif has minssf set? -Fixed the top posting. sorry about that.- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
