[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 number generator 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== Delet
Re: [Freeipa-devel] Planning FreeIPA Upstream Doc changes
On Aug 8, 2013, at 12:19 AM, "Martin Kosek" 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 > 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
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 +0000, 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
[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 <> 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] About private ssh host keys in IPA
On Jun 1, 2012, at 6:35 AM, "Stephen Gallagher" wrote: > On Fri, 2012-06-01 at 09:24 -0400, Simo Sorce wrote: >> This is about Ticket 1978 (originally rhbz746036). >> >> This RFE asks for storing private SSH Host Keys in FreeIPA. >> >> We have been triaging this ticket today, and I have to admit I am biased >> toward simply closing down the ticket. >> >> However we want to reach out community and interested parties that >> opened the tick to understand if there are reasons strong enough to >> consider implementing it. >> >> The reason I am against this is that in FreeIPA we already provide >> public Key integration. This means that when the host is re-installed >> new keys are loaded in IPA and clients do not get the obnoxious warning >> message that keys have changed, because enrolled clients (with the >> appropriate integration bits) trust FreeIPA so they do not need to ask >> the user to confirm on a key change. >> >> Storing Private Keys poses various liability issues, in order to be able >> to restore keys you need to give access to those keys to an admin, as >> there is no other way to authenticate just the host itself (it was just >> blown away and reinstalled). >> This means any admin account that can perform reinstalls need to have >> access to *read* private keys out of LDAP, which means that >> A) The central tenet of Asymetric authentication is that private keys >> are 'private'. >> B) keys are readable from LDAP to some accounts, any slight error in >> ACIs would risk exposing all private keys. >> C) most probably low level (junior admin) accounts will have read access >> to pretty much all private keys, because those admins are the one tasked >> with re-installs. However those admins are also the ones less trusted, >> yet by giving them access to private keys they are enabled to perform >> MITM attacks against pretty much any of the machines managed by FreeIPA. >> >> For these reasons I am against storing SSH Private Keys. I would like to >> know what are the reasons to instead implement this feature and the >> security considerations around those reasons. >>> From my point of view the balance between feature vs security issues >> trips in disfavor of implementing the feature but I am willing to be >> convinced otherwise if there are good reasons to, and security issues >> can be properly addressed with some clever scheme. > > > For the record, I am also in favor of just closing the ticket. It's much > safer and wiser to require re-provisioning of the public key in the > FreeIPA server than it is to try storing the private key. I suspect that > when we had the original conversation on IRC, it was before we had > decided that FreeIPA would be managing public keys. I am firmly against > ever storing host private keys in a central location. +1 I am also for the public and against the private. ___ 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-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
Re: [Freeipa-devel] [PATCH] 135 Host page fixed to work with disabled DNS support
On May 4, 2012, at 5:18 AM, Petr Vobornik wrote: > When DNS support was disabled there were following errors in Web UI: > 1) Host details page was not filled with data > 2) Host adder dialog was broken -> unusable > 3) DNS tab was displayed in navigation > > The bugs were fixed by: > > 1) Was caused by entity_link_widget. The widget was modified to do not show > link if other_entity (in this case dnsrecord) is not present. > > 2) Was caused by host_fqdn_widget. The widget is unusable because without DNS > support it doesn't have access to DNS zone entity. The section with this > widget was removed. Also IP address field was removed because it shouln't be > used without DNS support. New 'fqdn' text box was added for specifying > hostname. > > 3) New DNS config entity was initialized but it wasn't shown because it > caused some JavaScript error. The dnsconfig's init method was modified to > throw expected exception. Now no dns entity is initialized and therefore DNS > tab in navigation is not displayed. > > https://fedorahosted.org/freeipa/ticket/2728 > -- > Petr Vobornik > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Patch tested and works as advertised! ACK ___ 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 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aqu...@citrixonline.com<mailto:jr.aqu...@citrixonline.com> http://www.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] 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 > > 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] 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
[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.3478 C: +1 805.717.0365 jr.aqu...@citrixonline.com<mailto:jr.aqu...@citrixonline.com> http://www.citrixonline.com<http://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-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
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] 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] 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] 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
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 hours<https://fedorahosted.org/freeipa/timeline?from=2012-02-23T15%3A42%3A49Z&precision=second> ago by rmeggins Replying to rcritten<https://fedorahosted.org/freeipa/ticket/2303#comment:16>: Replying to rmeggins<https://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
[Freeipa-devel] [PATCH] 42 Add CleanRUV Task to ipa-replica-manage del
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 -JR bing3rlPEeuph.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] 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
[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.com<http://www.gotomypc.com> Online Meetings Made Easy: www.gotomeeting.com<http://www.gotomeeting.com> Web Events Made Easy:www.gotowebinar.com<http://www.gotowebinar.com> Remote Support Made Easy: www.gotoassist.com<http://www.gotoassist.com> <> 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 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-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] 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-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 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 Dennis" wrote: >> >>> On 02/20/2012 01:49 PM, JR Aquino wrote: >>>> On Feb 17, 2012, at 3:18 PM, John Dennis wrote: >>>> >>>>> >>>>> -- >>>>> John Dennis >>>>> >>>>> 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 >>>> >>>> >>>> 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] [PATCH 62] Tweak the session auth to reflect developer consensus.
On Feb 20, 2012, at 12:48 PM, "John Dennis" wrote: > On 02/20/2012 01:49 PM, JR Aquino wrote: >> On Feb 17, 2012, at 3:18 PM, John Dennis wrote: >> >>> >>> -- >>> John Dennis >>> >>> 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 >> >> >> 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 > > 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 17, 2012, at 3:18 PM, John Dennis wrote: > > -- > John Dennis > > 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 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] [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
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
[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_m
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.com>brett.campb...@citrix.com<mailto:brett.campb...@citrix.com>>
> Date: September 19, 2011 6:48:55 PM PDT
> To: JR Aquino
> <<mailto:jr.aqu...@citrix.com>jr.aqu...@citrix.com<mailto:jr.aqu...@citrix.com>>
> Cc: Jason Vagalatos
> <<mailto:jason.vagala...@citrix.com>jason.vagala...@citrix.com<mailto: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.com<mailto: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 ###
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Sep 20, 2011, at 4:13 AM, Martin Kosek wrote: > On Fri, 2011-09-16 at 16:37 +0000, JR Aquino wrote: >> 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. >>>> >>>> >>>> >>>>> >>>>> 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.
[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.com>brett.campb...@citrix.com<mailto:brett.campb...@citrix.com>>
Date: September 19, 2011 6:48:55 PM PDT
To: JR Aquino
<<mailto:jr.aqu...@citrix.com>jr.aqu...@citrix.com<mailto:jr.aqu...@citrix.com>>
Cc: Jason Vagalatos
<<mailto:jason.vagala...@citrix.com>jason.vagala...@citrix.com<mailto: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.com<mailto: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
Re: [Freeipa-devel] [PATCH] #1793 Fix expiration on password change
On Sep 19, 2011, at 6:37 AM, Simo Sorce wrote: > Changing passwords would not properly set expiration date with the new > ipa-kdb code. > > Patches fixes this. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > <0001-ipa-kdb-Properly-set-password-expiration-time.patch>___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Works Perfectly! ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 874 suppress managed netgroups as indirect members of hosts
On Sep 14, 2011, at 1:39 PM, Rob Crittenden wrote: > Suppress managed netgroups as indirect members of hosts. This enhances a > previous patch that I did for hostgroups. > > rob Works as advertised: ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 40 Adjust replica installation to omit processing memberof computations
Adjust ipa-replica-install, ipa_init.json, json_metadata.json, replication.py, and dsinstance.py to accomodate Fractional replication changes. A bug is being addressed in 389 ds to allow for the transmission of memberof data during replication due to the potentially high resource impact of having to recompute all of a production directory's memberof referential integrity. The installation scripts for FreeIPA replica's need to be modified in conjunction with this effort. https://fedorahosted.org/freeipa/ticket/1794 bin4fkMpLlNtr.bin Description: freeipa-jraquino-0040-Adjust-replica-installation-to-omit-processing-memberof.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 Sep 16, 2011, at 2:11 AM, Martin Kosek wrote: > On Thu, 2011-09-15 at 17:25 +0000, 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. >> >> >> >>> >>> 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 disabling&enabling 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 th
Re: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry
On Sep 16, 2011, at 4:41 AM, "Alexander Bokovoy" 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 ack&push. >> >> 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 15, 2011, at 1:47 AM, Martin Kosek wrote: > On Thu, 2011-09-15 at 00:47 +0000, 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. > > 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 disabling&enabling 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 +0000, 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] > 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 >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 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 >>>>>> https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries >>>>>> during Replica installation >>>>> >>>>> 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. >> >> > > 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 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 +0000, 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 >>>>> https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during >>>>> Replica installation >>>> >>>> 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. > > 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 ___ 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 +0000, 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 >>>> https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during >>>> Replica installation >>> >>> 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 Jul 22, 2011, at 6:54 AM, Martin Kosek wrote: > On Thu, 2011-07-21 at 23:00 +0000, 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 >> https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during >> Replica installation > > 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 Crittenden" 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" 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 2, 2011, at 1:09 AM, Martin Kosek wrote: > On Tue, 2011-08-02 at 07:25 +0000, JR Aquino wrote: >> On Aug 1, 2011, at 11:28 PM, "Martin Kosek" 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. >>>>>>
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" wrote: > On Mon, 2011-08-01 at 19:11 +0000, 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
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. >>>>
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 +0000, 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 >> https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during >> Replica installation > > 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] 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 +0000, 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
[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 https://fedorahosted.org/freeipa/ticket/1222 - Add Managed Entries during Replica installation 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] 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=foo"<- in this scenario, we >>> don't actually want or need a 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 " <- 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] 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. >> >>>> >&g
Re: [Freeipa-devel] [PATCH] 37 Correct sudo runasuser and runasgroup attributes in schema
On Jul 19, 2011, at 2:20 AM, Martin Kosek wrote:
> On Mon, 2011-07-18 at 23:43 +0000, 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.
Fixed indentation from spaces to tabs.
Also removed trailing whitespace.
binmBnIXdjGaS.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
Re: [Freeipa-devel] [PATCH] 31 Correct behavior for sudorunasgroup vs sudorunasuser
On Jul 19, 2011, at 2:05 PM, JR Aquino wrote: > On Jul 19, 2011, at 7:30 AM, Martin Kosek wrote: > >> On Tue, 2011-06-14 at 19:03 +0000, 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 Final Patch: -Fixed indentation of makefile to use tabs instead of spaces- binC59UFyftgb.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] 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 +0000, 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
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 wh
Re: [Freeipa-devel] [PATCH] 37 Correct sudo runasuser and runasgroup attributes in schema
On Jul 19, 2011, at 2:32 AM, "Martin Kosek" wrote:
> On Mon, 2011-07-18 at 23:43 +0000, 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
[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] 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] 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] 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. > > Added PATCH to subject line. ___ 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] 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] Proposal: drop DENY rules from HBAC
> >> >> I think that an explicit allow list is usually way better because with >> deny rules it's easy to fail to enumerate all entities that should be >> denied, resulting in allowing access we didn't want to. >> >> However, does anyone still remember why we opted for deny rules during >> design phase in the first place? > > IMO it was convenience. > >> Was it a compatibility with some existing system (that our users might >> be migrating from) or just to provide a convenient construct to our >> users? > > No other system we know of does this. > >> >> By removing the deny rules, do we break compatibility with anything >> else than the IPA tech preview in RHEL and upstream FreeIPA 2.0? > > > Not that we know of. We break Fedora compatibility but we can handle it > with the smart upgrade script that detects the presence of the deny > rules and bails out before updating the system asking user to fix deny > rules manually before updating. >> The Sudo implementation for FreeIPA has looked to HBAC for direction and similarity in a lot of ways. I would ask if we are going to remove 'deny' that we leave those pieces in reach for reference in future use when Sudo will need to try to integrate, as Sudo want to have both permit and deny rules. ___ 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
[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] 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
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
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-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 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.
>>>
>>>
>>
>>
>> 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] 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] 30 Display remaining external hosts when removing from sudorule
On Jun 13, 2011, at 11:45 AM, wrote: > 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) > It helps when a patch is actually attached. binPqMBkmsa8F.bin Description: freeipa-jraquino-0030-Display-remaning-external-hosts-when-removing-from-sudorule.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 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. > > 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
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] 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 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
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
[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] FreeIPA Auto Membership CLI
On Jun 2, 2011, at 12:59 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 06/02/2011 11:39 AM, JR Aquino wrote: >>> 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===--- >>> >> >> This presentation assumes that the description is not empty. >> In general case it is not true so I would suggest fixed labels even if >> the values would have duplicates. >> >> Group: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com >> Description: >> Regex: fqdn=^web[1-9]+.example.com >> - >> Group: cn=mailservers,cn=hostgroups,cn=accounts,dc=example,dc=com >> Description: >> Regex: fqdn=^mail[1-9]+.example.com >> - >> Group: cn=webservers,cn=hostgroups,cn=accounts,dc=example,dc=com >> Description: >> Regex: fqdn=^www[1-9]+.example.com >> - >> >> Keep the indent that you proposed, it looks OK with the indent. > > Just note that the code that does the rendering is extremely simplistic so > control over indention may require a fair bit of work. I think indention is > handled via nesting, so returning data as lists of lists may do the trick. Excellent! That is really good to know! I was worried I'd have to override output_for_cli() I'll repost once I have the suggested layout implemented. Thanks guys! > > That or you are going to have to override output_for_cli() and do all the > output manually but that should be a last resort. > > rob > > ___ > 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] 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-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.
>>
>> 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] 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 >>> >> >> 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 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 Crittenden" 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] 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 Crittenden" 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 24, 2011, at 8:17 AM, Rob Crittenden wrote: > JR Aquino wrote: >> On May 23, 2011, at 2:42 PM, "Rob Crittenden" 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 23, 2011, at 2:42 PM, "Rob Crittenden" 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] 28 Move Managed Entries into their own container
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 binD0dTkzJ5ys.bin Description: freeipa-jraquino-0028-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] 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 > 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
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] 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
[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] 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-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 .
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
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] 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 ', instead of printing > an error message about unknown command. > > https://fedorahosted.org/freeipa/ticket/914 > > Honza > > -- > Jan Cholasta > ___ > 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
[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-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 +0000, 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
