From simo at redhat.com Sun Jan 1 23:08:40 2012 From: simo at redhat.com (Simo Sorce) Date: Sun, 01 Jan 2012 18:08:40 -0500 Subject: [Freeipa-devel] [PATCH] fix typo in ipalib/plugins/role.py In-Reply-To: References: Message-ID: <1325459320.30661.3.camel@willson.li.ssimo.org> On Sat, 2011-12-31 at 10:15 +0100, J?r?me Fenal wrote: > diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py > index bdca3ec..d01791b 100644 > --- a/ipalib/plugins/role.py > +++ b/ipalib/plugins/role.py > @@ -45,7 +45,7 @@ EXAMPLES: > Add some privileges to this role: > ipa role-add-privilege --privileges=addusers junioradmin > ipa role-add-privilege --privileges=change_password junioradmin > - ipa role-add-privilege --privileges=add_user_to_default_group > juioradmin > + ipa role-add-privilege --privileges=add_user_to_default_group > junioradmin > > Add a group of users to this role: > ipa group-add --desc="User admins" useradmins > Obvious ACK. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Jan 2 08:09:50 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 02 Jan 2012 09:09:50 +0100 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <20111221204954.GH31934@redhat.com> References: <4E96B5AB.4030800@redhat.com> <4E970565.6040009@redhat.com> <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> <4ED8E717.7050302@redhat.com> <4ED8E859.1050407@redhat.com> <20111202202631.GA29560@redhat.com> <4EF1DFFC.4060905@redhat.com> <4EF20C99.3040502@redhat.com> <20111221204954.GH31934@redhat.com> Message-ID: <4F01664E.8060101@redhat.com> Dne 21.12.2011 21:49, Alexander Bokovoy napsal(a): > On Wed, 21 Dec 2011, Jan Cholasta wrote: >> >> Fixed cachedproperty so that the return value is cached per-instance >> instead of per-class. >> >> Updated patch attached. > Works for me, thanks. > > Could you please do a favor and use the decorator syntax as suggested > by the documentation of cachedproperty class? > >> @@ -1218,7 +1219,6 @@ class ra(rabase.rabase): >> self.ipa_key_size = "2048" >> self.ipa_certificate_nickname = "ipaCert" >> self.ca_certificate_nickname = "caCert" >> - self.ca_host = None >> try: >> f = open(self.pwd_file, "r") >> self.password = f.readline().strip() >> @@ -1283,6 +1283,7 @@ class ra(rabase.rabase): >> return host >> else: >> return api.env.ca_host > > Instead of >> + ca_host = cachedproperty(_select_ca) > rather have > @cachedproperty > def ca_host(self): > > where ca_host() is _select_ca(). > > Decorators are supported by Python 2.4. > Here you go. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-54.4-fix-read-only-write.patch Type: text/x-patch Size: 9387 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 2 08:25:01 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 02 Jan 2012 09:25:01 +0100 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4EEA60A6.90109@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> <4EEA60A6.90109@redhat.com> Message-ID: <4F0169DD.90105@redhat.com> Dne 15.12.2011 22:03, Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 7.12.2011 17:28, Jan Cholasta napsal(a): >>> [PATCH] 65 Configure ssh and sshd during ipa-client-install. >>> >>> For ssh, VerifyHostKeyDNS option is enabled. >>> >>> For sshd, KerberosAuthentication, GSSAPIAuthentication and UsePAM >>> options are enabled (this can be disabled using --no-sshd >>> ipa-client-install option). >>> >> >> Changed this not to implicitly trust DNS, as discussed on yesterday's >> meeting. You can make SSH trust DNS explicitly using --ssh-trust-dns >> ipa-client-install option. >> >> Honza >> > > Traceback if ipaserver package is not installed. > > # ipa-client-install > [snip] > Created /etc/ipa/default.conf > ipa : ERROR cannot import plugins sub-package > ipaserver.install.plugins.plugins: No module named > ipaserver.install.plugins > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 1474, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 1461, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 1277, in install > api.finalize() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 656, in > finalize > self.__do_if_not_done('load_plugins') > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 452, in > __do_if_not_done > getattr(self, name)() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 599, in > load_plugins > self.import_plugins('ipaserver/install/plugins') > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 625, in > import_plugins > raise e > ImportError: No module named ipaserver.install.plugins > > You need to use a context other than 'installer'. I used 'cli_installer' > to proceed. OK. > > Is this what I should expect when logging into an enrolled client: > > $ slogin -v doberman.example.com > [ snip ] > debug1: matching host key fingerprint found in DNS > The authenticity of host 'doberman.example.com. (192.168.186.9)' can't > be established. > RSA key fingerprint is 99:4a:4e:7f:4e:79:56:f6:00:4a:db:67:63:24:77:79. > Matching host key fingerprint found in DNS. > Are you sure you want to continue connecting (yes/no)? > > That part seems to be working, I guess I didn't expected to be asked. > > When I tested without DNS it said something about key not found in DNS > as I would expect. That's because I have set VerifyHostKeyDNS to "ask" by default. It can easily be changed to "no", if that's what we want. > > I'm unable to add another pub key: > $ ipa user-mod --addattr ipasshpubkey=== tuser1 > ipa: ERROR: invalid 'ipasshpubkey': must be binary data > > $ ipa user-mod --sshpubkey=== tuser1 > [SUCCESS] Will fix. > > I wonder if normalize_ssh_pubkeys should not be validate_ssh_pubkeys(). > It isn't really converting them to some common format, just confirming > that they are valid keys, right? Well, it does the base64-decoding of the key blob. But I agree, "normalize" is probably not the right name for this kind of operation. > > rob Honza -- Jan Cholasta From mkosek at redhat.com Mon Jan 2 08:46:43 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Jan 2012 09:46:43 +0100 Subject: [Freeipa-devel] [PATCH] 180 Add missing --pkey-only option for selfservice and In-Reply-To: <4EE2B6D6.90301@redhat.com> References: <1323445643.7177.45.camel@balmora.brq.redhat.com> <4EE2B6D6.90301@redhat.com> Message-ID: <1325494003.2265.11.camel@priserak> On Fri, 2011-12-09 at 19:33 -0600, Endi Sukma Dewata wrote: > On 12/9/2011 9:47 AM, Martin Kosek wrote: > > pkey-only functionality has to be implemented separately for these > > modules as they are based on crud.Search instead of standard > > LDAPSearch. > > > > Delegation commands were modified in the process to allow ACIs > > without 'memberof' as delegation ACIs. This check is no longer > > needed since delegation ACI prefixe ensures the ACI type. > > > > https://fedorahosted.org/freeipa/ticket/2092 > > From UI perspective this is ACKed. I'm sending a patch to enable paging > on these pages. > Thanks for the UI review Endi. If there are no objections from server people too we can push this. A rebased version for current master is attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-180-2-add-missing-pkey-only-option-for-selfservice-and-del.patch Type: text/x-patch Size: 17508 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jan 2 08:53:53 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Jan 2012 11:53:53 +0300 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <4F01664E.8060101@redhat.com> References: <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> <4ED8E717.7050302@redhat.com> <4ED8E859.1050407@redhat.com> <20111202202631.GA29560@redhat.com> <4EF1DFFC.4060905@redhat.com> <4EF20C99.3040502@redhat.com> <20111221204954.GH31934@redhat.com> <4F01664E.8060101@redhat.com> Message-ID: <20120102085353.GA29356@redhat.com> On Mon, 02 Jan 2012, Jan Cholasta wrote: > > def ca_host(self): > > > >where ca_host() is _select_ca(). > > > >Decorators are supported by Python 2.4. > > > > Here you go. ACK. Pushed to master. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jan 2 09:00:10 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Jan 2012 12:00:10 +0300 Subject: [Freeipa-devel] Branch 'ipa-2-1' - selinux/ipa_httpd In-Reply-To: <20120102085317.984293D21@lists.fedorahosted.org> References: <20120102085317.984293D21@lists.fedorahosted.org> Message-ID: <20120102090010.GB29356@redhat.com> On Mon, 02 Jan 2012, abbra wrote: > selinux/ipa_httpd/ipa_httpd.te | 2 ++ > 1 file changed, 2 insertions(+) > > New commits: > commit d214ba7547fdda279fa3fd38129a600979d6213b > Author: Alexander Bokovoy > Date: Wed Dec 21 14:44:06 2011 +0200 > > Re-enable web password migration on Fedora 16 after SE Linux policy restrictions > > Web password migration tool uses connection to the LDAPI socket. > Enable access to the ns-slapd socket. This one was to fix #769440 and was pushed to Fedora 16/Rawhide repos on December 21st as part of 389-ds reenterant plugins re-spin. I forgot to send it as a patch to the list before going to vacation, silly me. > > diff --git a/selinux/ipa_httpd/ipa_httpd.te b/selinux/ipa_httpd/ipa_httpd.te > index 65b161f..64525ba 100644 > --- a/selinux/ipa_httpd/ipa_httpd.te > +++ b/selinux/ipa_httpd/ipa_httpd.te > @@ -7,6 +7,7 @@ require { > type var_run_t; > type krb5kdc_t; > type cert_t; > + type dirsrv_t; > class sock_file write; > class unix_stream_socket connectto; > class file write; > @@ -15,6 +16,7 @@ require { > # Let Apache, bind and the KDC talk to DS over ldapi > allow httpd_t var_run_t:sock_file write; > allow httpd_t initrc_t:unix_stream_socket connectto; > +allow httpd_t dirsrv_t:unix_stream_socket connectto; > allow krb5kdc_t var_run_t:sock_file write; > allow krb5kdc_t initrc_t:unix_stream_socket connectto; > allow named_t var_run_t:sock_file write; > > -- / Alexander Bokovoy From mkosek at redhat.com Mon Jan 2 15:58:30 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Jan 2012 16:58:30 +0100 Subject: [Freeipa-devel] [PATCH] [ipa-2-1] 183 Make sure that install tools log Message-ID: <1325519910.25703.8.camel@balmora.brq.redhat.com> This is a ipa-2-1 branch fix only. master branch use better and more sophisticated approach to fix logging (ticket 2022). ---- When any log message is emitted before IPA install tools logging is configured, it may break and leave install tools log empty. This happens for example when ipa-server-install --ip-address=$IP_ADDRESS is run. This patch makes sure that logging is right in these cases. https://fedorahosted.org/freeipa/ticket/2214 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-183-make-sure-that-install-tools-log.patch Type: text/x-patch Size: 1475 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jan 2 16:35:24 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Jan 2012 19:35:24 +0300 Subject: [Freeipa-devel] [PATCH] [ipa-2-1] 183 Make sure that install tools log In-Reply-To: <1325519910.25703.8.camel@balmora.brq.redhat.com> References: <1325519910.25703.8.camel@balmora.brq.redhat.com> Message-ID: <20120102163524.GD29356@redhat.com> On Mon, 02 Jan 2012, Martin Kosek wrote: > This is a ipa-2-1 branch fix only. master branch use better and more > sophisticated approach to fix logging (ticket 2022). > > ---- > When any log message is emitted before IPA install tools logging is > configured, it may break and leave install tools log empty. This > happens for example when > > ipa-server-install --ip-address=$IP_ADDRESS > > is run. > > This patch makes sure that logging is right in these cases. > > https://fedorahosted.org/freeipa/ticket/2214 This is a good start. However, we'll still get messages from --ip-address processing lost. What about adding a Handler class to buffer LogRecords? Set it in the root logger as the very first action in those three tools (ipa-dns-install, ipa-replica-prepare, ipa-server-install) that accept --ip-address option. When standard_logging_setup() is called, it would check for existing handlers and first pull in the records, then remove the handler, call basicSetup() and re-issue the LogRecords again? This way we'll get all the records recovered and will get around IPACheckedAddress limitations. -- / Alexander Bokovoy From jfenal at gmail.com Mon Jan 2 16:41:08 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 2 Jan 2012 17:41:08 +0100 Subject: [Freeipa-devel] Translation to French for freeipa completed Message-ID: Hi all, I'm glad to announce that the French translation for FreeIPA software has been completed, as on Transifex, except for 21 strings related to entitlement.py. Given the recent developments, I'm not sure it is 100% up to date with current code. What is the policy regarding pushing updates to Transifex (strings freeze before pushing out a new release, or once in a while) ? Regards, thanks in advance, J?r?me -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Jan 3 08:36:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jan 2012 09:36:11 +0100 Subject: [Freeipa-devel] [PATCH] [ipa-2-1] 183 Make sure that install tools log In-Reply-To: <20120102163524.GD29356@redhat.com> References: <1325519910.25703.8.camel@balmora.brq.redhat.com> <20120102163524.GD29356@redhat.com> Message-ID: <1325579771.22407.1.camel@balmora.brq.redhat.com> On Mon, 2012-01-02 at 19:35 +0300, Alexander Bokovoy wrote: > On Mon, 02 Jan 2012, Martin Kosek wrote: > > This is a ipa-2-1 branch fix only. master branch use better and more > > sophisticated approach to fix logging (ticket 2022). > > > > ---- > > When any log message is emitted before IPA install tools logging is > > configured, it may break and leave install tools log empty. This > > happens for example when > > > > ipa-server-install --ip-address=$IP_ADDRESS > > > > is run. > > > > This patch makes sure that logging is right in these cases. > > > > https://fedorahosted.org/freeipa/ticket/2214 > This is a good start. However, we'll still get messages from > --ip-address processing lost. > > What about adding a Handler class to buffer LogRecords? > > Set it in the root logger as the very first action in those three > tools (ipa-dns-install, ipa-replica-prepare, ipa-server-install) that accept > --ip-address option. > > When standard_logging_setup() is called, it would check for existing > handlers and first pull in the records, then remove the handler, > call basicSetup() and re-issue the LogRecords again? > > This way we'll get all the records recovered and will get around > IPACheckedAddress limitations. > That's a good idea! This way we won't miss any log before our logging setup. Updated patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-183-2-make-sure-that-install-tools-log.patch Type: text/x-patch Size: 5162 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 3 09:06:38 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Jan 2012 10:06:38 +0100 Subject: [Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server Message-ID: <4F02C51E.80502@redhat.com> This ticket was divided into 4 small almost independent patches. 1) 62-Added-support-of-custom-field-validators 2) 63-Added-validation-logic-to-multivalued-text-field - depends on 1 3) 64-Added-client-side-validation-of-A-and-AAAA-DNS-recor - depends on 1 4) 65-Fixed-IPv6-validation-special-case-single-colon - minor fix Patch descriptions: 1) Added support of custom field validators Current validation logic supports only validation based on metadata. It can be extended only by overriding field's validation method. This approach requires creating subclasses of field for each different format of desired value. It's inconvenient for cases like adding the same validation logic to two different subclasses of field. This patch is adding support for creating custom validators. Validator is an object which contains validation logic. Validation is executed in a validate(value, context) method. This method checks if the value is valid and returns a validation result. Validation result is a simple object which contains valid property and an error message if valid is false. Field is extended by validators property. It can be set in spec object or later. It should contain instances of validators for the field. Validators are run in field's validation method. 2) Added validation logic to multivalued text field 3) Added client-side validation of A and AAAA DNS records 4) Fixed IPv6 validation special case: single colon IPv6 parsing was incorrectly evaluating ':' as a valid IPv6 address. All: https://fedorahosted.org/freeipa/ticket/1466 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0062-Added-support-of-custom-field-validators.patch Type: text/x-patch Size: 7074 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0063-Added-validation-logic-to-multivalued-text-field.patch Type: text/x-patch Size: 2938 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0064-Added-client-side-validation-of-A-and-AAAA-DNS-recor.patch Type: text/x-patch Size: 5862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0065-Fixed-IPv6-validation-special-case-single-colon.patch Type: text/x-patch Size: 1587 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 3 09:18:16 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Jan 2012 10:18:16 +0100 Subject: [Freeipa-devel] [PATCH] 333 Reload UI when the user changes. In-Reply-To: <4EF20434.6090501@redhat.com> References: <4EF1337B.9080304@redhat.com> <4EF13874.7040203@redhat.com> <4EF20434.6090501@redhat.com> Message-ID: <4F02C7D8.8020703@redhat.com> On 12/21/2011 05:07 PM, Petr Vobornik wrote: >> On 12/21/2011 02:37 AM, Endi Sukma Dewata wrote: >> >> New patch to fix infinite reload problem with test fixtures. >> > > ACK > Was pushed to master by Endi. -- Petr Vobornik From pvoborni at redhat.com Tue Jan 3 09:20:14 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Jan 2012 10:20:14 +0100 Subject: [Freeipa-devel] [PATCH] 334 Reload UI on server upgrade. In-Reply-To: <4EF2042D.5080707@redhat.com> References: <4EF13FCD.9030103@redhat.com> <4EF2042D.5080707@redhat.com> Message-ID: <4F02C84E.3010604@redhat.com> On 12/21/2011 05:07 PM, Petr Vobornik wrote: > On 12/21/2011 03:09 AM, Endi Sukma Dewata wrote: >> The JSON server has been modified to return the version number >> in all responses. The UI has been modified to keep the version >> obtained during env operation and check the version returned >> in subsequent operations. If the version changes the UI will >> reload itself. >> >> Ticket #946 > > ACK > Was pushed to master by Endi. -- Petr Vobornik From abokovoy at redhat.com Tue Jan 3 10:27:51 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Jan 2012 13:27:51 +0300 Subject: [Freeipa-devel] [PATCH] [ipa-2-1] 183 Make sure that install tools log In-Reply-To: <1325579771.22407.1.camel@balmora.brq.redhat.com> References: <1325519910.25703.8.camel@balmora.brq.redhat.com> <20120102163524.GD29356@redhat.com> <1325579771.22407.1.camel@balmora.brq.redhat.com> Message-ID: <20120103102751.GB21825@redhat.com> On Tue, 03 Jan 2012, Martin Kosek wrote: > > This way we'll get all the records recovered and will get around > > IPACheckedAddress limitations. > > > > That's a good idea! This way we won't miss any log before our logging > setup. Updated patch attached. Tried it on F16. With 2.1.4-3 there is no ipaserver-install.log, with the patch I'm getting all the proper logging. Good! ACK. -- / Alexander Bokovoy From mkosek at redhat.com Tue Jan 3 11:28:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jan 2012 12:28:11 +0100 Subject: [Freeipa-devel] [PATCH] [ipa-2-1] 183 Make sure that install tools log In-Reply-To: <20120103102751.GB21825@redhat.com> References: <1325519910.25703.8.camel@balmora.brq.redhat.com> <20120102163524.GD29356@redhat.com> <1325579771.22407.1.camel@balmora.brq.redhat.com> <20120103102751.GB21825@redhat.com> Message-ID: <1325590091.22407.15.camel@balmora.brq.redhat.com> On Tue, 2012-01-03 at 13:27 +0300, Alexander Bokovoy wrote: > On Tue, 03 Jan 2012, Martin Kosek wrote: > > > This way we'll get all the records recovered and will get around > > > IPACheckedAddress limitations. > > > > > > > That's a good idea! This way we won't miss any log before our logging > > setup. Updated patch attached. > Tried it on F16. With 2.1.4-3 there is no ipaserver-install.log, with > the patch I'm getting all the proper logging. Good! > > ACK. > Pushed to ipa-2-1. Martin From pvoborni at redhat.com Tue Jan 3 12:20:26 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Jan 2012 13:20:26 +0100 Subject: [Freeipa-devel] [PATCH] 066 Added support for memberof attribute in permission Message-ID: <4F02F28A.1060306@redhat.com> The attribute was added to adder dialog and details facet. It uses entity select(group) widget. https://fedorahosted.org/freeipa/ticket/2101 Proper functionality of this patch depends on ticket #2100 - Rob's patch 912. Also fixing one label regression. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0066-Added-support-for-memberof-attribute-in-permission.patch Type: text/x-patch Size: 3187 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 3 12:27:10 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Jan 2012 13:27:10 +0100 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4EDEA39C.5010206@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> Message-ID: <4F02F41E.1030309@redhat.com> On 12/07/2011 12:22 AM, Rob Crittenden wrote: > Resending as a [PATCH] > I've created UI portion patch (#2101). The show command seems working well, but the mod command is not returning the memberof attribute after execution. It is needed for Web UI (if we want to support modification of memberof attr there). Otherwise we would have to call show command after each mod. I'm blaming it on these lines in permission.py:340: for r in result: if not r.startswith('member'): entry_attrs[r] = result[r] return dn -- Petr Vobornik From mkosek at redhat.com Tue Jan 3 16:03:50 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jan 2012 17:03:50 +0100 Subject: [Freeipa-devel] [PATCH] 184 Add DNS check to conncheck port probe Message-ID: <1325606630.22407.31.camel@balmora.brq.redhat.com> It is pointless to report failures for all checked ports when the target hostname is not resolvable - user may get easily confused. This patch changes this behavior so that conncheck fails with a proper error and does not even continue to port probing part. https://fedorahosted.org/freeipa/ticket/1984 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-184-add-dns-check-to-conncheck-port-probe.patch Type: text/x-patch Size: 1314 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 3 19:27:39 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Jan 2012 14:27:39 -0500 Subject: [Freeipa-devel] [PATCH] 0294 remove delegation from browser config In-Reply-To: <4EF0F8DD.5010503@redhat.com> References: <4EF0F8DD.5010503@redhat.com> Message-ID: <4F0356AB.2070702@redhat.com> Adam Young wrote: > Hold this patch until all of the S4U2 code is pushed, otherwise it will > break the WebUI This will only affect newly installed servers. Should a new jar be generated on upgrades? rob From edewata at redhat.com Wed Jan 4 03:53:23 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 03 Jan 2012 21:53:23 -0600 Subject: [Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server In-Reply-To: <4F02C51E.80502@redhat.com> References: <4F02C51E.80502@redhat.com> Message-ID: <4F03CD33.80903@redhat.com> On 1/3/2012 3:06 AM, Petr Vobornik wrote: > 1) 62-Added-support-of-custom-field-validators > 2) 63-Added-validation-logic-to-multivalued-text-field - depends on 1 > 3) 64-Added-client-side-validation-of-A-and-AAAA-DNS-recor - depends on 1 > 4) 65-Fixed-IPv6-validation-special-case-single-colon - minor fix ACK and pushed to master. There are some minor issues but they can be fixed later since they don't cause regression: 1. The IPv4 validator can take quads or integer, but it looks like according to RFC 1035 section 3.4.1 (http://tools.ietf.org/html/rfc1035) the A record should only take quads: A records cause no additional section processing. The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6") 2. The DNS record adder dialog doesn't validate the A/AAAA records. We might want to define some hidden fields, one field for each record type, then the field will only appear if you select the type from the drop-down list. This way each field can have its own validators. This solution is similar to permission target widget and will be the basis for ticket #2208. 3. The host adder dialog doesn't validate the IP address. 4. The widget_value_changed() in IPA.multivalued_field is not needed because it's identical to the one in IPA.field. 5. Existing problem, in the DNS Resource Records page the delete operation doesn't work. I think this will be addressed in #2094. 6. Existing problem, in the extract_child_value() in IPA.multivalued_text_widget if the value is an empty array the function will return the array itself instead of empty string. 7. Existing problem, in net.js:330 the error message should be for leading instead of trailing zeros. -- Endi S. Dewata From ayoung at redhat.com Wed Jan 4 14:19:30 2012 From: ayoung at redhat.com (Adam Young) Date: Wed, 04 Jan 2012 09:19:30 -0500 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: References: Message-ID: <4F045FF2.5050100@redhat.com> On 01/02/2012 11:41 AM, J?r?me Fenal wrote: > Hi all, > > I'm glad to announce that the French translation for FreeIPA software > has been completed, as on Transifex, except for 21 strings related to > entitlement.py. > > Given the recent developments, I'm not sure it is 100% up to date with > current code. > > What is the policy regarding pushing updates to Transifex (strings > freeze before pushing out a new release, or once in a while) ? > > Regards, thanks in advance, > > J?r?me > -- > J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ > Paris.pm - http://paris.mongueurs.net/ > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel jdennis can confirm, but: It should be safe to push them. We still need to do a deliberate import into IPA in order to get the strings, and the way the Python gettext code works, it should not pick up strings that are not matched to a part of the code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Wed Jan 4 14:41:32 2012 From: jdennis at redhat.com (John Dennis) Date: Wed, 04 Jan 2012 09:41:32 -0500 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: References: Message-ID: <4F04651C.8060804@redhat.com> On 01/02/2012 11:41 AM, J?r?me Fenal wrote: > Hi all, > > I'm glad to announce that the French translation for FreeIPA software > has been completed, as on Transifex, except for 21 strings related to > entitlement.py. > > Given the recent developments, I'm not sure it is 100% up to date with > current code. > > What is the policy regarding pushing updates to Transifex (strings > freeze before pushing out a new release, or once in a while) ? Thank you J?r?me doing the translations, we very much appreciate it! The pot file on Transifex needs to be updated to a more current version and that update happens to be sitting in our patch queue waiting for a commit to our git repository. We expect the commit to occur today. We pull new po files from Transifex prior to new releases. We have been remiss by not have a formal string freeze in the past and announcing it, we do not want to make that mistake again and are going to add this to our release scheduling. Let me know if there is anything else I can help you with. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Jan 4 14:45:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 09:45:33 -0500 Subject: [Freeipa-devel] [PATCH 57] update i18n pot file for branch ipa-2-1 In-Reply-To: <201112082036.pB8KaH0D011647@int-mx12.intmail.prod.int.phx2.redhat.com> References: <201112082036.pB8KaH0D011647@int-mx12.intmail.prod.int.phx2.redhat.com> Message-ID: <4F04660D.8080104@redhat.com> John Dennis wrote: > > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ pushed to ipa-2-1 From rcritten at redhat.com Wed Jan 4 14:45:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 09:45:44 -0500 Subject: [Freeipa-devel] [PATCH 58] update i18n pot file for branch master In-Reply-To: <201112082109.pB8L9O7t022694@int-mx02.intmail.prod.int.phx2.redhat.com> References: <201112082109.pB8L9O7t022694@int-mx02.intmail.prod.int.phx2.redhat.com> Message-ID: <4F046618.2070703@redhat.com> John Dennis wrote: > > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ pushed to master From rcritten at redhat.com Wed Jan 4 14:49:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 09:49:54 -0500 Subject: [Freeipa-devel] [PATCH] 184 Add DNS check to conncheck port probe In-Reply-To: <1325606630.22407.31.camel@balmora.brq.redhat.com> References: <1325606630.22407.31.camel@balmora.brq.redhat.com> Message-ID: <4F046712.5040903@redhat.com> Martin Kosek wrote: > It is pointless to report failures for all checked ports when the > target hostname is not resolvable - user may get easily confused. > This patch changes this behavior so that conncheck fails with > a proper error and does not even continue to port probing part. > > https://fedorahosted.org/freeipa/ticket/1984 ack, pushed to master From jfenal at gmail.com Wed Jan 4 14:56:33 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Wed, 4 Jan 2012 15:56:33 +0100 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: <4F04651C.8060804@redhat.com> References: <4F04651C.8060804@redhat.com> Message-ID: 2012/1/4 John Dennis > On 01/02/2012 11:41 AM, J?r?me Fenal wrote: > >> Hi all, >> >> I'm glad to announce that the French translation for FreeIPA software >> has been completed, as on Transifex, except for 21 strings related to >> entitlement.py. >> >> Given the recent developments, I'm not sure it is 100% up to date with >> current code. >> >> What is the policy regarding pushing updates to Transifex (strings >> freeze before pushing out a new release, or once in a while) ? >> > > Thank you J?r?me doing the translations, we very much appreciate it! > > The pot file on Transifex needs to be updated to a more current version > and that update happens to be sitting in our patch queue waiting for a > commit to our git repository. We expect the commit to occur today. > > We pull new po files from Transifex prior to new releases. > > We have been remiss by not have a formal string freeze in the past and > announcing it, we do not want to make that mistake again and are going to > add this to our release scheduling. > > Let me know if there is anything else I can help you with. > Thanks Dennis, I'll watch commits, and the subsequent update on Transifex (is this part automated ?). Regards, J. -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfenal at gmail.com Wed Jan 4 14:58:19 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Wed, 4 Jan 2012 15:58:19 +0100 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: References: <4F04651C.8060804@redhat.com> Message-ID: 2012/1/4 J?r?me Fenal > 2012/1/4 John Dennis > >> On 01/02/2012 11:41 AM, J?r?me Fenal wrote: >> >>> Hi all, >>> >>> I'm glad to announce that the French translation for FreeIPA software >>> has been completed, as on Transifex, except for 21 strings related to >>> entitlement.py. >>> >>> Given the recent developments, I'm not sure it is 100% up to date with >>> current code. >>> >>> What is the policy regarding pushing updates to Transifex (strings >>> freeze before pushing out a new release, or once in a while) ? >>> >> >> Thank you J?r?me doing the translations, we very much appreciate it! >> >> The pot file on Transifex needs to be updated to a more current version >> and that update happens to be sitting in our patch queue waiting for a >> commit to our git repository. We expect the commit to occur today. >> >> We pull new po files from Transifex prior to new releases. >> >> We have been remiss by not have a formal string freeze in the past and >> announcing it, we do not want to make that mistake again and are going to >> add this to our release scheduling. >> >> Let me know if there is anything else I can help you with. >> > > Thanks Dennis > Well, I meant : "Thanks John"... -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Wed Jan 4 15:32:39 2012 From: jdennis at redhat.com (John Dennis) Date: Wed, 04 Jan 2012 10:32:39 -0500 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: References: <4F04651C.8060804@redhat.com> Message-ID: <4F047117.9070108@redhat.com> On 01/04/2012 09:56 AM, J?r?me Fenal wrote: > 2012/1/4 John Dennis > > The pot file on Transifex needs to be updated to a more current > version and that update happens to be sitting in our patch queue > waiting for a commit to our git repository. We expect the commit to > occur today. > Thanks Dennis, I'll watch commits, and the subsequent update on > Transifex (is this part automated ?). Yes, it's automated. Transifex watches our git repo and pulls the pot file whenever it is updated (or at least that's the way it's supposed to work, Transifex has been somewhat of a moving target :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jfenal at gmail.com Wed Jan 4 15:34:32 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Wed, 4 Jan 2012 16:34:32 +0100 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: <4F047117.9070108@redhat.com> References: <4F04651C.8060804@redhat.com> <4F047117.9070108@redhat.com> Message-ID: 2012/1/4 John Dennis > On 01/04/2012 09:56 AM, J?r?me Fenal wrote: > > Thanks Dennis, I'll watch commits, and the subsequent update on >> Transifex (is this part automated ?). >> > > Yes, it's automated. Transifex watches our git repo and pulls the pot file > whenever it is updated (or at least that's the way it's supposed to work, > Transifex has been somewhat of a moving target :-) OK, thanks. Let's wait a day or two until Transifex does what it's supposed to do. Regards, J?r?me -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Jan 4 18:03:10 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 04 Jan 2012 12:03:10 -0600 Subject: [Freeipa-devel] [PATCH] 066 Added support for memberof attribute in permission In-Reply-To: <4F02F28A.1060306@redhat.com> References: <4F02F28A.1060306@redhat.com> Message-ID: <4F04945E.7010502@redhat.com> On 1/3/2012 6:20 AM, Petr Vobornik wrote: > The attribute was added to adder dialog and details facet. It uses > entity select(group) widget. > > https://fedorahosted.org/freeipa/ticket/2101 > > Proper functionality of this patch depends on ticket #2100 - Rob's patch > 912. > > Also fixing one label regression. I think the memberof is one of possible permission targets, so it should be added into the IPA.permission_target_widget. The memberof drop-down list should appear only when you select memberof as the target. -- Endi S. Dewata From edewata at redhat.com Wed Jan 4 18:03:18 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 04 Jan 2012 12:03:18 -0600 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F02F41E.1030309@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> Message-ID: <4F049466.5020507@redhat.com> On 1/3/2012 6:27 AM, Petr Vobornik wrote: > On 12/07/2011 12:22 AM, Rob Crittenden wrote: >> Resending as a [PATCH] >> > I've created UI portion patch (#2101). The show command seems working > well, but the mod command is not returning the memberof attribute after > execution. It is needed for Web UI (if we want to support modification > of memberof attr there). Otherwise we would have to call show command > after each mod. > > I'm blaming it on these lines in permission.py:340: > for r in result: > if not r.startswith('member'): > entry_attrs[r] = result[r] > return dn Yes, that part should probably look something like: for attr in self.obj.aci_attributes: if attr in result: entry_attrs[attr] = result[attr] Also another thing, in _make_aci() in aci.py there are 2 exclusivity rules: * type, filter, subtree and targetgroup are mutually exclusive * filter and memberof are mutually exclusive Based on these rules it's possible to have memberof and targetgroup in the same permission, but not filter with targetgroup, which seems to be inconsistent because memberof generates a subset of ACI's generated by filter. The filter generates an ACI with a generic 'targetfilter=', and memberof seems to be a convenience method to generate an ACI with a more specific 'targetfilter=(memberOf=)'. So the 2 rules should be combined because, like filter, memberof should be mutually exclusive from the other targets too. -- Endi S. Dewata From rcritten at redhat.com Wed Jan 4 18:20:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 13:20:18 -0500 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F049466.5020507@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> <4F049466.5020507@redhat.com> Message-ID: <4F049862.5030409@redhat.com> Endi Sukma Dewata wrote: > On 1/3/2012 6:27 AM, Petr Vobornik wrote: >> On 12/07/2011 12:22 AM, Rob Crittenden wrote: >>> Resending as a [PATCH] >>> >> I've created UI portion patch (#2101). The show command seems working >> well, but the mod command is not returning the memberof attribute after >> execution. It is needed for Web UI (if we want to support modification >> of memberof attr there). Otherwise we would have to call show command >> after each mod. >> >> I'm blaming it on these lines in permission.py:340: >> for r in result: >> if not r.startswith('member'): >> entry_attrs[r] = result[r] >> return dn > > Yes, that part should probably look something like: > > for attr in self.obj.aci_attributes: > if attr in result: > entry_attrs[attr] = result[attr] I'm not sure why that was there unless it is to exclude members of the permission (remember, we show things in reverse). > Also another thing, in _make_aci() in aci.py there are 2 exclusivity rules: > * type, filter, subtree and targetgroup are mutually exclusive > * filter and memberof are mutually exclusive > > Based on these rules it's possible to have memberof and targetgroup in > the same permission, but not filter with targetgroup, which seems to be > inconsistent because memberof generates a subset of ACI's generated by > filter. > > The filter generates an ACI with a generic 'targetfilter=', and > memberof seems to be a convenience method to generate an ACI with a more > specific 'targetfilter=(memberOf=)'. > > So the 2 rules should be combined because, like filter, memberof should > be mutually exclusive from the other targets too. > This is specifically allowed because it lets you restrict the members of the memberof group to modify only the values of the targetgroup (e.g. group membership). If anything I'd relax it so filter and targetgroup aren't mutually exclusive. I'm not sure of the use case for this though. rob From simo at redhat.com Wed Jan 4 19:12:12 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jan 2012 14:12:12 -0500 Subject: [Freeipa-devel] [PATCH] 475 Fix setup of replication agreements on replicas Message-ID: <1325704332.30661.134.camel@willson.li.ssimo.org> The work done to create the ipa-csreplica-manage tool introduced a bug in normal replication agreements setups which caused replicas to not properly filter out attributes that absoluteley must not be replicated around. This patch should fix the issue. Trac ticket TBC Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-475-1-Fix-replication-setup.patch Type: text/x-patch Size: 3876 bytes Desc: not available URL: From mkosek at redhat.com Wed Jan 4 19:38:30 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Jan 2012 20:38:30 +0100 Subject: [Freeipa-devel] [PATCH] 185-188 Let replicas install without DNS Message-ID: <1325705910.2136.13.camel@priserak> Patches 185-186 are needed to make ipa-replica-install run without crashes. How to test: on server: 1) install the server (ipa.example.com is not resolvable) # ipa-server-install -p kokos123 -a kokos123 --no-host-dns --hostname=ipa.example.com 2) Add a record for replica.example.com to /etc/hosts 3) Prepare the replica (without 188 it refuses to create the replica file) # ipa-replica-prepare replica.example.com on replica: 1) Add a record for ipa.example.com to /etc/hosts 2) Install replica (replica.example.com is not resolvable) # ipa-replica-install --no-host-dns --ip-address=IP_ADDRESS REPLICA_FILE The installer now use IP_ADDRESS to create a record /etc/hosts and make the replica resolvable ---- Let ipa-replica-prepare and ipa-replica-install work without proper DNS records as records in /etc/hosts are sufficient for DS replication. 1) ipa-replica-prepare now just checks if the replica hostname is resolvable (DNS records are not required). It is now able to prepare a replica file even when the replica IP address is present in /etc/hosts only. 2) ipa-replica-install is now able to proceed when the hostname is not resolvable. It uses an IP address passed in a new option --ip-address to create a record in /etc/hosts in the same way as ipa-server-install does. https://fedorahosted.org/freeipa/ticket/2139 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-185-fix-ldap-add-calls-in-replication-module.patch Type: text/x-patch Size: 3120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-186-prevent-service-restart-failures-in-ipa-replica-inst.patch Type: text/x-patch Size: 2765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-187-fix-ldap-updates-in-ipa-replica-install.patch Type: text/x-patch Size: 1009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-188-let-replicas-install-without-dns.patch Type: text/x-patch Size: 11979 bytes Desc: not available URL: From edewata at redhat.com Wed Jan 4 19:41:38 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 04 Jan 2012 13:41:38 -0600 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F049862.5030409@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> <4F049466.5020507@redhat.com> <4F049862.5030409@redhat.com> Message-ID: <4F04AB72.3020501@redhat.com> On 1/4/2012 12:20 PM, Rob Crittenden wrote: >> Also another thing, in _make_aci() in aci.py there are 2 exclusivity >> rules: >> * type, filter, subtree and targetgroup are mutually exclusive >> * filter and memberof are mutually exclusive >> >> Based on these rules it's possible to have memberof and targetgroup in >> the same permission, but not filter with targetgroup, which seems to be >> inconsistent because memberof generates a subset of ACI's generated by >> filter. >> >> The filter generates an ACI with a generic 'targetfilter=', and >> memberof seems to be a convenience method to generate an ACI with a more >> specific 'targetfilter=(memberOf=)'. >> >> So the 2 rules should be combined because, like filter, memberof should >> be mutually exclusive from the other targets too. > > This is specifically allowed because it lets you restrict the members of > the memberof group to modify only the values of the targetgroup (e.g. > group membership). If anything I'd relax it so filter and targetgroup > aren't mutually exclusive. I'm not sure of the use case for this though. Hmm.. I think the memberof is used to define ACI target instead of the subject (bind rule). See the following command: ipa permission-add test --permissions=all --memberof=editors --targetgroup=ipausers It generates the following ACI: (targetfilter = "(memberOf=cn=editors,cn=groups,cn=accounts, dc=example,dc=com)") (target = "ldap:///cn=ipausers,cn=groups,cn=accounts, dc=example,dc=com") (version 3.0;acl "permission:test";allow (all) groupdn = "ldap:///cn=test,cn=permissions,cn=pbac, dc=example,dc=com";) If I understand correctly this ACI gives members of cn=test full access to members of cn=editors under the cn=ipausers subtree. To give members of cn=editors full access to cn=ipausers subtree I think the cn=editors would have to be added as a member of cn=test permission indirectly via privileges and roles. Since target and targetfilter attributes can co-exist in the ACI, I agree that we might want to relax the rules. So the permission target can be defined with a subtree, or a filter, or both. With a subtree we can specify either a generic subtree, a type, or a targetgroup. With a filter we can specify either a generic filter or a memberof. Is this correct? This will require some UI changes too. -- Endi S. Dewata From rcritten at redhat.com Wed Jan 4 20:11:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 15:11:29 -0500 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <20111214192250.GA11084@redhat.com> References: <4EE66277.5060409@redhat.com> <1323735307.4413.109.camel@willson.li.ssimo.org> <4EE699B0.1030403@redhat.com> <4EE8F679.1010509@redhat.com> <20111214192250.GA11084@redhat.com> Message-ID: <4F04B271.1010101@redhat.com> Alexander Bokovoy wrote: > On Wed, 14 Dec 2011, Rob Crittenden wrote: > >> Dmitri Pal wrote: >>> On 12/12/2011 07:15 PM, Simo Sorce wrote: >>>> On Mon, 2011-12-12 at 15:22 -0500, Rob Crittenden wrote: >>>>> This patch adds support for s4u2proxy. This means that the Apache >>>>> server >>>>> will obtain the ldap service ticket on behalf of the user rather than >>>>> the using having to send their TGT. The user's ticket still needs to >>>>> be >>>>> forwardable, we just don't require it to be forwarded any more. >>>> >>>> Should we make the patch allow the old behavior by using a switch that >>>> revert to forwarding the TGT ? >>>> >>>> It would be useful during upgrades if some of your servers still need >>>> forwarded TGTs, or if you want to use a newer client against an old >>>> server while you have the newer stuff under test. >>>> (And to test in general). >>>> >>>> Simo. >>> +1 >>> >> >> Updated patch attached. >> >> rob > >> > From 03a2c9a536811437e4847e1c6b11d2ac0eff98f2 Mon Sep 17 00:00:00 2001 >> From: Rob Crittenden >> Date: Thu, 8 Dec 2011 14:23:18 -0500 >> Subject: [PATCH] Don't set delegation flag in client, we're using S4U2Proxy >> now >> >> A forwardable ticket is still required but we no longer need to send >> the TGT to the IPA server. A new flag, --delegation, is available if >> the old behavior is required. > A minor point: please fix commit message to use proper option name: > > --delegate > >> + parser.add_option('--delegate', action='store_true', >> + help='Delegate the TGT to the IPA server', >> + ) > > Otherwise ACK. > Updated both patches. The first (914) to address Alexander's concern. The second to add a new global lock directive. I updated the mod_auth_kerb patch based on feedback from the package maintainer. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-914-2-nodelegation.patch Type: text/x-patch Size: 6033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-915-1-s4u2proxy.patch Type: text/x-patch Size: 4804 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 4 20:32:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 15:32:03 -0500 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F04AB72.3020501@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> <4F049466.5020507@redhat.com> <4F049862.5030409@redhat.com> <4F04AB72.3020501@redhat.com> Message-ID: <4F04B743.1020208@redhat.com> Endi Sukma Dewata wrote: > On 1/4/2012 12:20 PM, Rob Crittenden wrote: >>> Also another thing, in _make_aci() in aci.py there are 2 exclusivity >>> rules: >>> * type, filter, subtree and targetgroup are mutually exclusive >>> * filter and memberof are mutually exclusive >>> >>> Based on these rules it's possible to have memberof and targetgroup in >>> the same permission, but not filter with targetgroup, which seems to be >>> inconsistent because memberof generates a subset of ACI's generated by >>> filter. >>> >>> The filter generates an ACI with a generic 'targetfilter=', and >>> memberof seems to be a convenience method to generate an ACI with a more >>> specific 'targetfilter=(memberOf=)'. >>> >>> So the 2 rules should be combined because, like filter, memberof should >>> be mutually exclusive from the other targets too. >> >> This is specifically allowed because it lets you restrict the members of >> the memberof group to modify only the values of the targetgroup (e.g. >> group membership). If anything I'd relax it so filter and targetgroup >> aren't mutually exclusive. I'm not sure of the use case for this though. > > Hmm.. I think the memberof is used to define ACI target instead of the > subject (bind rule). See the following command: You're right. IIRC I added memberof to make v1-style delegation easier. > > ipa permission-add test --permissions=all > --memberof=editors --targetgroup=ipausers > > It generates the following ACI: > > (targetfilter = "(memberOf=cn=editors,cn=groups,cn=accounts, > dc=example,dc=com)") > (target = "ldap:///cn=ipausers,cn=groups,cn=accounts, > dc=example,dc=com") > (version 3.0;acl "permission:test";allow (all) > groupdn = "ldap:///cn=test,cn=permissions,cn=pbac, > dc=example,dc=com";) > > If I understand correctly this ACI gives members of cn=test full access > to members of cn=editors under the cn=ipausers subtree. In this case there is no subtree, cn=ipausers is a group. > To give members of cn=editors full access to cn=ipausers subtree I think > the cn=editors would have to be added as a member of cn=test permission > indirectly via privileges and roles. > > Since target and targetfilter attributes can co-exist in the ACI, I > agree that we might want to relax the rules. So the permission target > can be defined with a subtree, or a filter, or both. With a subtree we > can specify either a generic subtree, a type, or a targetgroup. With a > filter we can specify either a generic filter or a memberof. Is this > correct? > > This will require some UI changes too. > There are a lot of things we CAN allow, the 389-ds acis are extremely flexible. The question is do we need to? I'm all for providing lots of rope but acis are very hard to get right and can be difficult to read and debug which is why I tried to keep things as simple as I could. I think its fine if we have some constraints. rob From edewata at redhat.com Wed Jan 4 21:26:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 04 Jan 2012 15:26:53 -0600 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F04B743.1020208@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> <4F049466.5020507@redhat.com> <4F049862.5030409@redhat.com> <4F04AB72.3020501@redhat.com> <4F04B743.1020208@redhat.com> Message-ID: <4F04C41D.30802@redhat.com> On 1/4/2012 2:32 PM, Rob Crittenden wrote: >> ipa permission-add test --permissions=all >> --memberof=editors --targetgroup=ipausers >> >> It generates the following ACI: >> >> (targetfilter = "(memberOf=cn=editors,cn=groups,cn=accounts, >> dc=example,dc=com)") >> (target = "ldap:///cn=ipausers,cn=groups,cn=accounts, >> dc=example,dc=com") >> (version 3.0;acl "permission:test";allow (all) >> groupdn = "ldap:///cn=test,cn=permissions,cn=pbac, >> dc=example,dc=com";) >> >> If I understand correctly this ACI gives members of cn=test full access >> to members of cn=editors under the cn=ipausers subtree. > > In this case there is no subtree, cn=ipausers is a group. Right, specifying filter/memberof with targetgroup doesn't make sense because there's no entries under the group. But it's still possible to create useful ACI by specifying filter/memberof with type/subtree. For example, the following permission targets users that are members of editors only: ipa permission-add test --permissions=all --memberof=editors --type=user It will generate the following ACI target: (target = "ldap:///uid=*,cn=users,cn=accounts,dc=example,dc=com") >> Since target and targetfilter attributes can co-exist in the ACI, I >> agree that we might want to relax the rules. So the permission target >> can be defined with a subtree, or a filter, or both. With a subtree we >> can specify either a generic subtree, a type, or a targetgroup. With a >> filter we can specify either a generic filter or a memberof. Is this >> correct? > > There are a lot of things we CAN allow, the 389-ds acis are extremely > flexible. The question is do we need to? I'm all for providing lots of > rope but acis are very hard to get right and can be difficult to read > and debug which is why I tried to keep things as simple as I could. I > think its fine if we have some constraints. Either one is OK for me. For consistency & simplicity it might be better to combine the rules such that filter, memberof, type, subtree, and targetgroup are mutually exclusive. The memberof wasn't available in the UI before and the CLI support wasn't complete either, so I'm not sure if anybody is relying on this feature prior to this. But if we want more flexibility to support scenario like above with filter/memberof and type/subtree together, we will need to split the target into subtree and filter as described earlier. -- Endi S. Dewata From rcritten at redhat.com Wed Jan 4 21:47:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jan 2012 16:47:09 -0500 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F04C41D.30802@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> <4F049466.5020507@redhat.com> <4F049862.5030409@redhat.com> <4F04AB72.3020501@redhat.com> <4F04B743.1020208@redhat.com> <4F04C41D.30802@redhat.com> Message-ID: <4F04C8DD.9090708@redhat.com> Endi Sukma Dewata wrote: > On 1/4/2012 2:32 PM, Rob Crittenden wrote: >>> ipa permission-add test --permissions=all >>> --memberof=editors --targetgroup=ipausers >>> >>> It generates the following ACI: >>> >>> (targetfilter = "(memberOf=cn=editors,cn=groups,cn=accounts, >>> dc=example,dc=com)") >>> (target = "ldap:///cn=ipausers,cn=groups,cn=accounts, >>> dc=example,dc=com") >>> (version 3.0;acl "permission:test";allow (all) >>> groupdn = "ldap:///cn=test,cn=permissions,cn=pbac, >>> dc=example,dc=com";) >>> >>> If I understand correctly this ACI gives members of cn=test full access >>> to members of cn=editors under the cn=ipausers subtree. >> >> In this case there is no subtree, cn=ipausers is a group. > > Right, specifying filter/memberof with targetgroup doesn't make sense > because there's no entries under the group. But it's still possible to > create useful ACI by specifying filter/memberof with type/subtree. For > example, the following permission targets users that are members of > editors only: > > ipa permission-add test --permissions=all > --memberof=editors --type=user > > It will generate the following ACI target: > > (target = "ldap:///uid=*,cn=users,cn=accounts,dc=example,dc=com") > >>> Since target and targetfilter attributes can co-exist in the ACI, I >>> agree that we might want to relax the rules. So the permission target >>> can be defined with a subtree, or a filter, or both. With a subtree we >>> can specify either a generic subtree, a type, or a targetgroup. With a >>> filter we can specify either a generic filter or a memberof. Is this >>> correct? >> >> There are a lot of things we CAN allow, the 389-ds acis are extremely >> flexible. The question is do we need to? I'm all for providing lots of >> rope but acis are very hard to get right and can be difficult to read >> and debug which is why I tried to keep things as simple as I could. I >> think its fine if we have some constraints. > > Either one is OK for me. > > For consistency & simplicity it might be better to combine the rules > such that filter, memberof, type, subtree, and targetgroup are mutually > exclusive. The memberof wasn't available in the UI before and the CLI > support wasn't complete either, so I'm not sure if anybody is relying on > this feature prior to this. > > But if we want more flexibility to support scenario like above with > filter/memberof and type/subtree together, we will need to split the > target into subtree and filter as described earlier. > I guess I'm just not convinced this additional complexity would buy us anything. Updated patch attached that fixes the memberof display and updates the tests trivially. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-912-1-permission.patch Type: text/x-patch Size: 7290 bytes Desc: not available URL: From edewata at redhat.com Wed Jan 4 22:32:41 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 04 Jan 2012 16:32:41 -0600 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F04C8DD.9090708@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> <4F049466.5020507@redhat.com> <4F049862.5030409@redhat.com> <4F04AB72.3020501@redhat.com> <4F04B743.1020208@redhat.com> <4F04C41D.30802@redhat.com> <4F04C8DD.9090708@redhat.com> Message-ID: <4F04D389.7010404@redhat.com> On 1/4/2012 3:47 PM, Rob Crittenden wrote: > I guess I'm just not convinced this additional complexity would buy us > anything. > > Updated patch attached that fixes the memberof display and updates the > tests trivially. OK, the mod output is fixed. Since the exclusivity rules aren't changed, the following combinations are currently possible via CLI: 1. filter 2a. type 2b. type + memberof 3a. subtree 3b. subtree + memberof 4a. targetgroup 4b. targetgroup + memberof As discussed previously it doesn't really make sense to use memberof with targetgroup, so should we fix the rules to avoid combination #4b? If #4b is acceptable then this patch is ACKed as is. Here's the UI modification that Petr has created in patch #66 (click Add): http://edewata.fedorapeople.org/freeipa/install/ui/#rolebased=permission&ipaserver=rolebased&navigation=ipaserver To reflect the correct possible combinations, we probably should move the 'Member of group' field somewhere below the 'Target' drop-down list and show it only when 'Type' or 'Subtree' is selected. If we keep option #4b then we should also show it when the 'Target group' is selected. -- Endi S. Dewata From jfenal at gmail.com Thu Jan 5 09:32:12 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Thu, 5 Jan 2012 10:32:12 +0100 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: References: <4F04651C.8060804@redhat.com> <4F047117.9070108@redhat.com> Message-ID: 2012/1/4 J?r?me Fenal > 2012/1/4 John Dennis > >> On 01/04/2012 09:56 AM, J?r?me Fenal wrote: >> >> Thanks Dennis, I'll watch commits, and the subsequent update on >>> Transifex (is this part automated ?). >>> >> >> Yes, it's automated. Transifex watches our git repo and pulls the pot >> file whenever it is updated (or at least that's the way it's supposed to >> work, Transifex has been somewhat of a moving target :-) >> > > OK, thanks. Let's wait a day or two until Transifex does what it's > supposed to do. > Hi, Just a quick note to let you know that Transifex did update the .po. I'm back at 58% completion :( Regards, J. -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Jan 5 10:21:30 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Jan 2012 13:21:30 +0300 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <4F04B271.1010101@redhat.com> References: <4EE66277.5060409@redhat.com> <1323735307.4413.109.camel@willson.li.ssimo.org> <4EE699B0.1030403@redhat.com> <4EE8F679.1010509@redhat.com> <20111214192250.GA11084@redhat.com> <4F04B271.1010101@redhat.com> Message-ID: <20120105102130.GE24492@redhat.com> On Wed, 04 Jan 2012, Rob Crittenden wrote: > >>+ parser.add_option('--delegate', action='store_true', > >>+ help='Delegate the TGT to the IPA server', > >>+ ) > > > >Otherwise ACK. > > > > Updated both patches. The first (914) to address Alexander's > concern. The second to add a new global lock directive. I updated > the mod_auth_kerb patch based on feedback from the package > maintainer. I'm testing both patches. Unfortunately, there is no mod_auth_kerb option KrbConstrainedDelegationLock in the mod_auth_kerb 5.4-8 that you have provided. SourceForge is broken these days and I can't access anything on mod_auth_kerb upstream to verify if their development tree contains support for the option. I have disabled KrbConstrainedDelegationLock for time being. Other than that all works for me. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jan 5 10:29:46 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Jan 2012 13:29:46 +0300 Subject: [Freeipa-devel] CLDAP failures In-Reply-To: <1324566046.28622.169.camel@willson.li.ssimo.org> References: <20111222142008.GI31934@redhat.com> <1324566046.28622.169.camel@willson.li.ssimo.org> Message-ID: <20120105102946.GF24492@redhat.com> On Thu, 22 Dec 2011, Simo Sorce wrote: > On Thu, 2011-12-22 at 16:20 +0200, Alexander Bokovoy wrote: > > Hi, > > > > attached are two traces -- against IPA CLDAP plugin and AD win2k8. > > > Please try the attached patch. Tested and it works now for the same environment. ACK. https://fedorahosted.org/freeipa/ticket/2210 > > HTH, > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From b17b8bd67adf7d679ee1e9c4eed777091d6daecd Mon Sep 17 00:00:00 2001 > From: Simo Sorce > Date: Thu, 22 Dec 2011 09:59:20 -0500 > Subject: [PATCH] ipa-cldap: Support clients asking for default domain > > --- > .../ipa-cldap/ipa_cldap_netlogon.c | 22 +++++++++++++++++++- > 1 files changed, 21 insertions(+), 1 deletions(-) > > diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c > index 6eb7eb9b1b88bb190a75feeab39a2fe5ff2719bf..180a067ff8d95f984bd91233f5fb5811c9e140b5 100644 > --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c > +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c > @@ -215,6 +215,7 @@ int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, > struct berval *reply) > { > char hostname[MAXHOSTNAMELEN + 1]; /* NOTE: lenght hardcoded in kernel */ > + char domname[MAXHOSTNAMELEN + 1]; /* NOTE: lenght hardcoded in kernel */ > char *domain = NULL; > char *guid = NULL; > char *sid = NULL; > @@ -289,11 +290,30 @@ int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, > req->kvps.pairs[i].attr.bv_val); > } > > - if (!domain || !ntver) { > + if (!ntver) { > ret = EINVAL; > goto done; > } > > + /* If no domain is provide the client is asking for our own domain, > + * read our own domain name from the system */ > + if (!domain) { > + ret = getdomainname(domname, MAXHOSTNAMELEN); > + if (ret == -1) { > + ret = errno; > + goto done; > + } > + domname[MAXHOSTNAMELEN] = '\0'; > + p = strchr(hostname, '.'); > + if (p) { > + domain = strdup(p + 1); > + if (!domain) { > + ret = ENOMEM; > + goto done; > + } > + } > + } > + > /* FIXME: we support only NETLOGON_NT_VERSION_5EX for now */ > if (!(ntver & NETLOGON_NT_VERSION_5EX)) { > ret = EINVAL; > -- > 1.7.7.4 > -- / Alexander Bokovoy From simo at redhat.com Thu Jan 5 14:38:42 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Jan 2012 09:38:42 -0500 Subject: [Freeipa-devel] CLDAP failures In-Reply-To: <20120105102946.GF24492@redhat.com> References: <20111222142008.GI31934@redhat.com> <1324566046.28622.169.camel@willson.li.ssimo.org> <20120105102946.GF24492@redhat.com> Message-ID: <1325774322.30661.139.camel@willson.li.ssimo.org> On Thu, 2012-01-05 at 13:29 +0300, Alexander Bokovoy wrote: > On Thu, 22 Dec 2011, Simo Sorce wrote: > > > On Thu, 2011-12-22 at 16:20 +0200, Alexander Bokovoy wrote: > > > Hi, > > > > > > attached are two traces -- against IPA CLDAP plugin and AD win2k8. > > > > > > Please try the attached patch. > Tested and it works now for the same environment. > ACK. > > https://fedorahosted.org/freeipa/ticket/2210 Thanks pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Thu Jan 5 15:01:44 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 05 Jan 2012 10:01:44 -0500 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: References: <4F04651C.8060804@redhat.com> <4F047117.9070108@redhat.com> Message-ID: <4F05BB58.8050100@redhat.com> On 01/05/2012 04:32 AM, J?r?me Fenal wrote: > Just a quick note to let you know that Transifex did update the .po. > I'm back at 58% completion :( J?r?me everyone on the IPA team would like to thank you for helping us with the translation and wanted to express our regret some of your work was for naught due to an out of date pot file, please accept our apology. On our developer conference call this morning we put into place a policy to update the pot file once a month during active development (our current situation) and to have a string freeze prior to release. Thanks from the entire IPA team! John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ohamada at redhat.com Thu Jan 5 16:10:05 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 05 Jan 2012 17:10:05 +0100 Subject: [Freeipa-devel] [PATCH] 7 Ignore srchost option in hbactest Message-ID: <4F05CB5D.20701@redhat.com> https://fedorahosted.org/freeipa/ticket/2085 New version of SSSD begins ignoring sourcehost value of HBAC rules by default. In order to match this behaviour the sourcehost option in hbactest is optional now, but the value of sourcehost is ignored in all rules. Every rule's sourcehost value is set to 'ALL' what turns sourchost value comparation off. For every such a rule warning is displayed to inform the user about changes. Also the unit tests for hbactest plugin were updated. Every test was doubled. The second ones test the plugin without sourcehost option. They are supposed to have the same result. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-7-HBAC-test-optional-sourcehost-option.patch Type: text/x-patch Size: 11229 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 5 16:21:31 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 05 Jan 2012 10:21:31 -0600 Subject: [Freeipa-devel] [PATCH] Added account status into user search facet. Message-ID: <4F05CE0B.8000102@redhat.com> The user search facet has been modified to show the account status. The IPA.boolean_format has been converted into a class to allow behavior customization. Ticket #1996 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0335-Added-account-status-into-user-search-facet.patch Type: text/x-patch Size: 10533 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jan 5 16:40:33 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Jan 2012 19:40:33 +0300 Subject: [Freeipa-devel] [PATCH] 7 Ignore srchost option in hbactest In-Reply-To: <4F05CB5D.20701@redhat.com> References: <4F05CB5D.20701@redhat.com> Message-ID: <20120105164033.GH24492@redhat.com> On Thu, 05 Jan 2012, Ondrej Hamada wrote: > https://fedorahosted.org/freeipa/ticket/2085 > > New version of SSSD begins ignoring sourcehost value of HBAC rules by > default. In order to match this behaviour the sourcehost option in > hbactest is optional now, but the value of sourcehost is ignored in all > rules. Every rule's sourcehost value is set to 'ALL' what turns sourchost > value comparation off. For every such a rule warning is displayed to > inform the user about changes. > > Also the unit tests for hbactest plugin were updated. Every test was > doubled. The second ones test the plugin without sourcehost option. They > are supposed to have the same result. Looks OK for me. One possibility to enhance the tests is to verify that sourcehost-based version also checks warning being set to something other than None. ACK -- / Alexander Bokovoy From rcritten at redhat.com Thu Jan 5 18:17:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 13:17:20 -0500 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <20120105102130.GE24492@redhat.com> References: <4EE66277.5060409@redhat.com> <1323735307.4413.109.camel@willson.li.ssimo.org> <4EE699B0.1030403@redhat.com> <4EE8F679.1010509@redhat.com> <20111214192250.GA11084@redhat.com> <4F04B271.1010101@redhat.com> <20120105102130.GE24492@redhat.com> Message-ID: <4F05E930.5040906@redhat.com> Alexander Bokovoy wrote: > On Wed, 04 Jan 2012, Rob Crittenden wrote: >>>> + parser.add_option('--delegate', action='store_true', >>>> + help='Delegate the TGT to the IPA server', >>>> + ) >>> >>> Otherwise ACK. >>> >> >> Updated both patches. The first (914) to address Alexander's >> concern. The second to add a new global lock directive. I updated >> the mod_auth_kerb patch based on feedback from the package >> maintainer. > I'm testing both patches. Unfortunately, there is no mod_auth_kerb > option KrbConstrainedDelegationLock in the mod_auth_kerb 5.4-8 that > you have provided. SourceForge is broken these days and I can't access > anything on mod_auth_kerb upstream to verify if their development tree > contains support for the option. > > I have disabled KrbConstrainedDelegationLock for time being. > > Other than that all works for me. An updated mod_auth_kerb package is in the ipa-devel repo. rob From rcritten at redhat.com Thu Jan 5 18:36:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 13:36:11 -0500 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4F04D389.7010404@redhat.com> References: <4EDEA362.2070209@redhat.com> <4EDEA39C.5010206@redhat.com> <4F02F41E.1030309@redhat.com> <4F049466.5020507@redhat.com> <4F049862.5030409@redhat.com> <4F04AB72.3020501@redhat.com> <4F04B743.1020208@redhat.com> <4F04C41D.30802@redhat.com> <4F04C8DD.9090708@redhat.com> <4F04D389.7010404@redhat.com> Message-ID: <4F05ED9B.1000409@redhat.com> Endi Sukma Dewata wrote: > On 1/4/2012 3:47 PM, Rob Crittenden wrote: >> I guess I'm just not convinced this additional complexity would buy us >> anything. >> >> Updated patch attached that fixes the memberof display and updates the >> tests trivially. > > OK, the mod output is fixed. Since the exclusivity rules aren't changed, > the following combinations are currently possible via CLI: > > 1. filter > 2a. type > 2b. type + memberof > 3a. subtree > 3b. subtree + memberof > 4a. targetgroup > 4b. targetgroup + memberof > > As discussed previously it doesn't really make sense to use memberof > with targetgroup, so should we fix the rules to avoid combination #4b? > If #4b is acceptable then this patch is ACKed as is. > > Here's the UI modification that Petr has created in patch #66 (click Add): > > http://edewata.fedorapeople.org/freeipa/install/ui/#rolebased=permission&ipaserver=rolebased&navigation=ipaserver > > > To reflect the correct possible combinations, we probably should move > the 'Member of group' field somewhere below the 'Target' drop-down list > and show it only when 'Type' or 'Subtree' is selected. If we keep option > #4b then we should also show it when the 'Target group' is selected. > I opened ticket 2222 to disallow memberof and targetgroup. Pushed to master. rob From rcritten at redhat.com Thu Jan 5 19:14:04 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 14:14:04 -0500 Subject: [Freeipa-devel] [PATCH] fix typo in ipalib/plugins/role.py In-Reply-To: <1325459320.30661.3.camel@willson.li.ssimo.org> References: <1325459320.30661.3.camel@willson.li.ssimo.org> Message-ID: <4F05F67C.8090803@redhat.com> Simo Sorce wrote: > On Sat, 2011-12-31 at 10:15 +0100, J?r?me Fenal wrote: >> diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py >> index bdca3ec..d01791b 100644 >> --- a/ipalib/plugins/role.py >> +++ b/ipalib/plugins/role.py >> @@ -45,7 +45,7 @@ EXAMPLES: >> Add some privileges to this role: >> ipa role-add-privilege --privileges=addusers junioradmin >> ipa role-add-privilege --privileges=change_password junioradmin >> - ipa role-add-privilege --privileges=add_user_to_default_group >> juioradmin >> + ipa role-add-privilege --privileges=add_user_to_default_group >> junioradmin >> >> Add a group of users to this role: >> ipa group-add --desc="User admins" useradmins >> > > Obvious ACK. > > Simo. > pushed to master and ipa-2-1 From rcritten at redhat.com Thu Jan 5 19:14:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 14:14:16 -0500 Subject: [Freeipa-devel] [PATCH] fix typo in ipalib/plugins/role.py (2) In-Reply-To: References: Message-ID: <4F05F688.2010104@redhat.com> J?r?me Fenal wrote: > diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py > --- a/ipalib/plugins/role.py > +++ b/ipalib/plugins/role.py > @@ -54,7 +54,7 @@ EXAMPLES: > Display information about a role: > ipa role-show junioradmin > > - The result of this is that any users in the group 'useradmins' can > + The result of this is that any users in the group 'junioradmin' can > add users, reset passwords or add a user to the default IPA user group. > """) ACK, pushed to master and ipa-2-1 From jfenal at gmail.com Thu Jan 5 20:16:04 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Thu, 5 Jan 2012 21:16:04 +0100 Subject: [Freeipa-devel] Translation to French for freeipa completed In-Reply-To: <4F05BB58.8050100@redhat.com> References: <4F04651C.8060804@redhat.com> <4F047117.9070108@redhat.com> <4F05BB58.8050100@redhat.com> Message-ID: 2012/1/5 John Dennis > On 01/05/2012 04:32 AM, J?r?me Fenal wrote: > >> Just a quick note to let you know that Transifex did update the .po. >> I'm back at 58% completion :( >> > > J?r?me everyone on the IPA team would like to thank you for helping us > with the translation and wanted to express our regret some of your work was > for naught due to an out of date pot file, please accept our apology. > > On our developer conference call this morning we put into place a policy > to update the pot file once a month during active development (our current > situation) and to have a string freeze prior to release. > Hi John, No problem, this is the power of open source : continuous improvement of code (and processes). And I also could have wondered about the freshness of the pot file before... ;) Regards, J. -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jan 5 21:36:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 16:36:21 -0500 Subject: [Freeipa-devel] [PATCH] 185-188 Let replicas install without DNS In-Reply-To: <1325705910.2136.13.camel@priserak> References: <1325705910.2136.13.camel@priserak> Message-ID: <4F0617D5.4070203@redhat.com> Martin Kosek wrote: > Patches 185-186 are needed to make ipa-replica-install run without > crashes. > > How to test: > > on server: > 1) install the server (ipa.example.com is not resolvable) > # ipa-server-install -p kokos123 -a kokos123 --no-host-dns > --hostname=ipa.example.com > > 2) Add a record for replica.example.com to /etc/hosts > 3) Prepare the replica (without 188 it refuses to create the replica > file) > # ipa-replica-prepare replica.example.com > > on replica: > 1) Add a record for ipa.example.com to /etc/hosts > 2) Install replica (replica.example.com is not resolvable) > # ipa-replica-install --no-host-dns --ip-address=IP_ADDRESS REPLICA_FILE > > The installer now use IP_ADDRESS to create a record /etc/hosts and make > the replica resolvable > > ---- > Let ipa-replica-prepare and ipa-replica-install work without > proper DNS records as records in /etc/hosts are sufficient for > DS replication. > > 1) ipa-replica-prepare now just checks if the replica hostname > is resolvable (DNS records are not required). It is now able > to prepare a replica file even when the replica IP address is > present in /etc/hosts only. > 2) ipa-replica-install is now able to proceed when the hostname > is not resolvable. It uses an IP address passed in a new > option --ip-address to create a record in /etc/hosts in the > same way as ipa-server-install does. > > https://fedorahosted.org/freeipa/ticket/2139 NACK on patch 185. The exceptions need to be changed to catch DuplicateEntry instead of ALREADY_EXISTS Otherwise looks ok. rob From rcritten at redhat.com Thu Jan 5 22:38:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Jan 2012 17:38:22 -0500 Subject: [Freeipa-devel] [PATCH] 920 fix error message when re-adding users to sudorule Message-ID: <4F06265E.1080603@redhat.com> When re-adding an external user to a sudorule the wrong error message was showing (not found instead of already a member). Also display external users by default. This relies on my patch 919 to apply. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-920-sudorule.patch Type: text/x-patch Size: 2198 bytes Desc: not available URL: From edewata at redhat.com Fri Jan 6 05:14:14 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 05 Jan 2012 23:14:14 -0600 Subject: [Freeipa-devel] [PATCH] 335 Added account status into user search facet. In-Reply-To: <4F05CE0B.8000102@redhat.com> References: <4F05CE0B.8000102@redhat.com> Message-ID: <4F068326.8050305@redhat.com> On 1/5/2012 10:21 AM, Endi Sukma Dewata wrote: > The user search facet has been modified to show the account status. > The IPA.boolean_format has been converted into a class to allow > behavior customization. > > Ticket #1996 Fixed jslint warning. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0335-2-Added-account-status-into-user-search-facet.patch Type: text/x-patch Size: 10495 bytes Desc: not available URL: From edewata at redhat.com Fri Jan 6 05:14:20 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 05 Jan 2012 23:14:20 -0600 Subject: [Freeipa-devel] [PATCH] 336 Added policies into user details page. Message-ID: <4F06832C.6070300@redhat.com> The user details page has been modified to show the password policy and Kerberos ticket policy that apply to the user. The policy are displayed as read-only since they may affect other users. Changing a policy should be done in the respective policy details page. Ticket #703 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0336-Added-policies-into-user-details-page.patch Type: text/x-patch Size: 33867 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 6 07:59:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Jan 2012 08:59:11 +0100 Subject: [Freeipa-devel] [PATCH] 185-188 Let replicas install without DNS In-Reply-To: <4F0617D5.4070203@redhat.com> References: <1325705910.2136.13.camel@priserak> <4F0617D5.4070203@redhat.com> Message-ID: <1325836751.2159.11.camel@priserak> On Thu, 2012-01-05 at 16:36 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > Patches 185-186 are needed to make ipa-replica-install run without > > crashes. > > > > How to test: > > > > on server: > > 1) install the server (ipa.example.com is not resolvable) > > # ipa-server-install -p kokos123 -a kokos123 --no-host-dns > > --hostname=ipa.example.com > > > > 2) Add a record for replica.example.com to /etc/hosts > > 3) Prepare the replica (without 188 it refuses to create the replica > > file) > > # ipa-replica-prepare replica.example.com > > > > on replica: > > 1) Add a record for ipa.example.com to /etc/hosts > > 2) Install replica (replica.example.com is not resolvable) > > # ipa-replica-install --no-host-dns --ip-address=IP_ADDRESS REPLICA_FILE > > > > The installer now use IP_ADDRESS to create a record /etc/hosts and make > > the replica resolvable > > > > ---- > > Let ipa-replica-prepare and ipa-replica-install work without > > proper DNS records as records in /etc/hosts are sufficient for > > DS replication. > > > > 1) ipa-replica-prepare now just checks if the replica hostname > > is resolvable (DNS records are not required). It is now able > > to prepare a replica file even when the replica IP address is > > present in /etc/hosts only. > > 2) ipa-replica-install is now able to proceed when the hostname > > is not resolvable. It uses an IP address passed in a new > > option --ip-address to create a record in /etc/hosts in the > > same way as ipa-server-install does. > > > > https://fedorahosted.org/freeipa/ticket/2139 > > NACK on patch 185. The exceptions need to be changed to catch > DuplicateEntry instead of ALREADY_EXISTS > > Otherwise looks ok. > > rob Good catch, Rob! Attaching an updated set of patches. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-185-2-fix-ldap-add-calls-in-replication-module.patch Type: text/x-patch Size: 3472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-186-prevent-service-restart-failures-in-ipa-replica-inst.patch Type: text/x-patch Size: 2765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-187-fix-ldap-updates-in-ipa-replica-install.patch Type: text/x-patch Size: 1009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-188-let-replicas-install-without-dns.patch Type: text/x-patch Size: 11983 bytes Desc: not available URL: From jcholast at redhat.com Fri Jan 6 09:07:32 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 06 Jan 2012 10:07:32 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4EE8BEEF.1080408@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> Message-ID: <4F06B9D4.6010300@redhat.com> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>> The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter >>>>> but these weren't available in the sudorule plugin. >>>>> >>>>> I've added support for these. sudoOrder enforces uniqueness because >>>>> duplicates are undefined. >>>>> >>>>> I also added support for a GeneralizedTime parameter type. This is >>>>> similar to the existing AccessTime parameter but it only handles a >>>>> single time value. >>>> >>>> You should parse the date/time part of the value with >>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, >>>> that way you'll get most of the validation for free. >>> >>> Yes but it gives a crappy error message, just saying that some data is >>> left over not what is wrong. >> >> IMHO having a separate error message for every field in the time string >> (like you do in the patch) is an overkill, simple "invalid time" and/or >> "unknown time format" should suffice (we don't have errors like "invalid >> 3rd octet" for IP adresses either). > > Well, the work is done, hard to go back on a better error message. > >>> >>>> Also, it would be nice to be able to enter the value in more >>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize >>>> that to LDAP generalized time. >>> >>> When dealing with time there are so many ways to input and display the >>> same values this becomes difficult. >>> >>> I'd expect that the times for these two attributes will be relatively >>> simple and I somehow doubt users are going to want seconds, leap seconds >>> or fractions, but we'll need to consider how to do it for future >>> consistency (otherwise we could have a case where time is entered in one >>> format for some attributes and another for others). >>> >>> If we input in a nice way we need to output in the same way. >> >> We could make the preferred input/output time format user-configurable, >> defaulting to current locale time format. This format would be used for >> output. For input, we could go over a list of formats (first the >> user-configured format, then current locale format, then a handful of >> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first format >> that can be successfully used to parse the time string. > > See how far you get into the rabbit hole with even this simple format? I don't mind, as long as it is the right thing to do (IMHO) :) Anyway, I think this could be done on the client side, so we might use your patch without changes. However, I would prefer if the parameter class was more generic, so we could use it (hypothetically) to store time in some other way than LDAP generalized time attribute (at least name it DateTime please). > > The LDAP GeneralizedTime needs to be either in GMT or include a > differential. This gets us into the territory where the client could be > in a different timezone than the server which leads us to why we dropped > AccessTime in the first place. Speaking of time zones, the differential alone is not a sufficient time zone description, as it doesn't account for DST. Is there a way to store time in LDAP with full time zone name (just in case it's needed sometime in future)? > So I'd like the user to supply the > timezone themselves so I don't have to guess (wrongly) and let them > worry about differing timezones. We don't have to guess, IIRC there is a way to get the local timezone differential in both Python and JavaScript, so the client could supply it automatically if necessary. > > rob Honza -- Jan Cholasta From mkosek at redhat.com Fri Jan 6 13:30:54 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Jan 2012 14:30:54 +0100 Subject: [Freeipa-devel] [PATCH] 189 Fix selfservice-find crashes Message-ID: <1325856654.2159.19.camel@priserak> Ignore empty options when performing an ACI search so that the find command does not crash. https://fedorahosted.org/freeipa/ticket/2011 https://fedorahosted.org/freeipa/ticket/2012 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-189-fix-selfservice-find-crashes.patch Type: text/x-patch Size: 5333 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 6 13:31:28 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Jan 2012 14:31:28 +0100 Subject: [Freeipa-devel] [PATCH] 190 Restore ACI when aci_mod fails Message-ID: <1325856688.2159.20.camel@priserak> aci_mod command is composed of 2 ACI commands: aci_del which deletes the old ACI and aci_add which adds the new modified ACI. However, if aci_add command fails then both new and the old ACI are lost. Old ACI must be restored in this case. https://fedorahosted.org/freeipa/ticket/2013 https://fedorahosted.org/freeipa/ticket/2014 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-190-restore-aci-when-aci_mod-fails.patch Type: text/x-patch Size: 4206 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jan 6 13:50:11 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 06 Jan 2012 14:50:11 +0100 Subject: [Freeipa-devel] [PATCH] 336 Added policies into user details page. In-Reply-To: <4F06832C.6070300@redhat.com> References: <4F06832C.6070300@redhat.com> Message-ID: <4F06FC13.2060704@redhat.com> On 01/06/2012 06:14 AM, Endi Sukma Dewata wrote: > The user details page has been modified to show the password policy > and Kerberos ticket policy that apply to the user. The policy are > displayed as read-only since they may affect other users. Changing > a policy should be done in the respective policy details page. > > Ticket #703 > NACK 1) you are calling krbtpolicy-show without any user specific information so it always get the global policy. It should be call with an user argument. Minor: 2) Why not call pwpolicy-show --user=user_login instead of getting the policy's name from dn? Combining 1), 2) and user-show will allow to get all necessary information for the facet in a single batch at refresh. Otherwise it seems fine. -- Petr Vobornik From pvoborni at redhat.com Fri Jan 6 14:33:34 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 06 Jan 2012 15:33:34 +0100 Subject: [Freeipa-devel] [PATCH] 335 Added account status into user search facet. In-Reply-To: <4F068326.8050305@redhat.com> References: <4F05CE0B.8000102@redhat.com> <4F068326.8050305@redhat.com> Message-ID: <4F07063E.9020708@redhat.com> On 01/06/2012 06:14 AM, Endi Sukma Dewata wrote: > On 1/5/2012 10:21 AM, Endi Sukma Dewata wrote: >> The user search facet has been modified to show the account status. >> The IPA.boolean_format has been converted into a class to allow >> behavior customization. >> >> Ticket #1996 > > Fixed jslint warning. > ACK and pushed to master. (improvement) But before closing the ticket I must ask if it covers all parts of the ticket? Especially the part: "easy identifiable from the list they are in. For examply by an icon, or in a change in font color." Right now the information is there, but is it easy identifiable? Should we ask UXD for an input? -- Petr Vobornik From mkosek at redhat.com Fri Jan 6 16:39:55 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Jan 2012 17:39:55 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 182 Create per-type DNS API based on options In-Reply-To: <1324482381.11925.16.camel@balmora.brq.redhat.com> References: <1324482381.11925.16.camel@balmora.brq.redhat.com> Message-ID: <1325867995.2159.26.camel@priserak> On Wed, 2011-12-21 at 16:46 +0100, Martin Kosek wrote: > This is a fully functional prototype of the new DNS API based on new > options instead of new commands. It still has rough edges (missing > tests, extended help) but should give a very good picture about the new > API and provide a base for WebUI guys. > > ------- > Use new structured DNSRecord parameters to generate per-type API > for all supported DNS RR types. This should help significantly > the end-user with manipulating complex DNS record type (MX, LOC, > etc.). > > All enhancements are integrated to current DNS record commands: > > 1) dnsrecord-add > - Records can be either entered as a raw value (e.g. --mx-rec= > "1 srv1.example.com" for MX record) or per-part: > --mx-preference=1 --mx-exchanger=srv1.example.com > - CLI interactive help behavior was changed. It will ask for > a record type and then ask for all DNS record part values > (e.g. MX Preference value, MX Exchanger value). > > 2) dnsrecord-mod > - This command can now operate in 2 modes. When only a raw DNS > record is entered (e.g. --mx-rec="1 srv1.example.com") it > operates in standard mode and replaces any previous mxrecord > value with the --mx-rec value. > > When any structured parameter (e.g. --mx-preference) is passed > it modifies just the specified parts of one mxrecord value > referred by --mx-rec: > --mx-rec="1 srv1.example.com" --mx-preference=2 > - New interactive help has been implemented. It will ask for a > record to be modified (in the same manner as dnsrecord-del) > and then let user change DNS record part(s) for chosen > records. > > 3) All dnsrecord-* commands have now --structured option > - When this option is passed, instead of displaying raw DNS values > all DNS records are parsed and displayed per-part. Example: > > $ ipa dnsrecord-show example.com @ --structured > Record name: @ > Records: > Record type: MX > Record data: 0 server1.example.com. > MX Preference: 0 > MX Exchanger: server1.example.com. > > Record type: NS > Record data: ns1.example.com. > NS Hostname: ns1.example.com. > > All API changes are compatible with clients without this patch. > > https://fedorahosted.org/freeipa/ticket/2082 > > ------------------------------------------------ > A little demonstration of the new API capabilities: > > #### New help with option groups for per-type options > # ipa dnsrecord-add --help > Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] > > Options: > ... > --structured Parse all raw DNS records and return them in a > structured way > ... > A Record: > --a-rec=ARECORD Comma-separated list of raw A records > --a-ip-address=STR IP Address > > AAAA Record: > --aaaa-rec=AAAARECORD > Comma-separated list of raw AAAA records > --aaaa-ip-address=STR > IP Address > ... > MX Record: > --mx-rec=MXRECORD Comma-separated list of raw MX records > --mx-preference=INT > Preference given to this exchanger. Lower values > are > more preferred > --mx-exchanger=STR A host willing to act as a mail exchanger > > #### Standard dnsrecord-add > # ipa dnsrecord-add example.com server1 --a-rec=10.0.0.1 > Record name: server1 > A record: 10.0.0.1 > > #### New interactive help for dnsrecord-add > # ipa dnsrecord-add example.com server1 > Please choose a type of DNS resource record to be added > The most common types for this type of zone are: A, AAAA > > DNS resource record type: AAAA > AAAA IP Address: 2001:db8::1428:57ab > Record name: server1 > A record: 10.0.0.1 > AAAA record: 2001:db8::1428:57ab > > # ipa dnsrecord-add example.com @ > Please choose a type of DNS resource record to be added > The most common types for this type of zone are: NS, MX, LOC > > DNS resource record type: MX > MX Preference: 0 > MX Exchanger: server1.example.com. > Record name: example.com > MX record: 0 server1.example.com. > NS record: vm-068.idm.lab.bos.redhat.com. > > #### Old-stype mod command > # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." > Record name: example.com > MX record: 1 server1.example.com. > NS record: vm-068.idm.lab.bos.redhat.com. > > #### Modification via new structured options: > # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." --mx-preference=2 > Record name: example.com > MX record: 2 server1.example.com. > NS record: vm-068.idm.lab.bos.redhat.com. > > #### Modification via new interactive help: > # ipa dnsrecord-mod example.com @ > No option to modify specific record provided. > Current DNS record contents: > > MX record: 2 server1.example.com. > NS record: vm-068.idm.lab.bos.redhat.com. > > Modify MX record '2 server1.example.com.'? Yes/No (default No): y > MX Preference [2]: 3 > MX Exchanger [server1.example.com.]: > Modify NS record 'vm-068.idm.lab.bos.redhat.com.'? Yes/No (default No): > Record name: example.com > MX record: 3 server1.example.com. > NS record: vm-068.idm.lab.bos.redhat.com. > > #### Example of use of --structured option (this will be useful for WebUI): > # ipa dnsrecord-show example.com @ --structured > Record name: @ > Records: > Record type: MX > Record data: 3 server1.example.com. > MX Preference: 3 > MX Exchanger: server1.example.com. > > Record type: NS > Record data: vm-068.idm.lab.bos.redhat.com. > NS Hostname: vm-068.idm.lab.bos.redhat.com. > > #### dnsrecord-del works in the same way as the old one: > # ipa dnsrecord-del example.com server1 > No option to delete specific record provided. > Delete all? Yes/No (default No): > Current DNS record contents: > > AAAA record: 2001:db8::1428:57ab > A record: 10.0.0.1 > > Delete AAAA record '2001:db8::1428:57ab'? Yes/No (default No): y > Delete A record '10.0.0.1'? Yes/No (default No): > Record name: server1 > A record: 10.0.0.1 I prepared a rebased version of the patch set for easier review. There are few changes: - DNS module was extended to mention new interactive modes and options - one bug in dnsrecord-mod interactive mode was fixed - only one value per DNS type can be modified at one time - all translatable strings in DNS module with more than one placeholder were converted to dict format Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-172-5-refactor-dnsrecord-processing.patch Type: text/x-patch Size: 97146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-175-2-fix-parameter-csv-parsing.patch Type: text/x-patch Size: 1653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-181-improve-cli-output-for-complex-commands.patch Type: text/x-patch Size: 3822 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-182-2-create-per-type-dns-api.patch Type: text/x-patch Size: 113084 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 6 17:00:49 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Jan 2012 12:00:49 -0500 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements Message-ID: <4F0728C1.9010902@redhat.com> A bug when creating replication agreements has caused memberOf to be dropped from the exclusion list. This patch adds a tool that will find and fix the agreements. It will be run when the package is installed so end-users should never need to do anything, but it is harmless if run multiple times. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-921-fixreplica.patch Type: text/x-patch Size: 11705 bytes Desc: not available URL: From edewata at redhat.com Fri Jan 6 17:26:47 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 06 Jan 2012 11:26:47 -0600 Subject: [Freeipa-devel] [PATCH] 335 Added account status into user search facet. In-Reply-To: <4F07063E.9020708@redhat.com> References: <4F05CE0B.8000102@redhat.com> <4F068326.8050305@redhat.com> <4F07063E.9020708@redhat.com> Message-ID: <4F072ED7.8060506@redhat.com> On 1/6/2012 8:33 AM, Petr Vobornik wrote: > ACK and pushed to master. (improvement) > > But before closing the ticket I must ask if it covers all parts of the > ticket? > > Especially the part: "easy identifiable from the list they are in. > For examply by an icon, or in a change in font color." > > Right now the information is there, but is it easy identifiable? Should > we ask UXD for an input? I sent the question to Kyle, waiting for a response now. Using icon or color are some methods suggested by the ticket, but I don't think it's a requirement. At least this patch addresses the missing functionality asked by the ticket: being able to identify disabled entries without going into the details page. -- Endi S. Dewata From jfenal at gmail.com Fri Jan 6 22:11:01 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 6 Jan 2012 23:11:01 +0100 Subject: [Freeipa-devel] Trivial doc patch for automember.py Message-ID: Hi all, A few more glitches found during translation. Regards, J. diff --git a/ipalib/plugins/automember.py b/ipalib/plugins/automember.py index ff5a2ba..3b65218 100644 --- a/ipalib/plugins/automember.py +++ b/ipalib/plugins/automember.py @@ -41,11 +41,11 @@ entry is added to the appropriate group or hostgroup. EXAMPLES: - Create the initial group or hostgroup: + Add the initial group or hostgroup: ipa hostgroup-add --desc="Web Servers" webservers ipa group-add --desc="Developers" devel - Create the initial rule: + Add the initial rule: ipa automember-add --type=hostgroup webservers ipa automember-add --type=group devel @@ -84,7 +84,7 @@ EXAMPLES: ipa automember-default-group-set --default-group=webservers --type=hostgroup ipa automember-default-group-set --default-group=ipausers --type=group - Set the default target group: + Remove the default target group: ipa automember-default-group-remove --type=hostgroup ipa automember-default-group-remove --type=group @@ -174,7 +174,7 @@ class automember(LDAPObject): Str('automemberdefaultgroup?', cli_name='default_group', label=_('Default Group'), - doc=_('Default group for entires to land'), + doc=_('Default group for entries to land'), flags=['no_create', 'no_update', 'no_search'] ), ) @@ -347,7 +347,7 @@ class automember_remove_condition(LDAPUpdate): """) takes_options = regex_attrs + group_type takes_args = automember_rule - msg_summary = _('Removed condition(s) to "%(value)s"') + msg_summary = _('Removed condition(s) from "%(value)s"') # Prepare the output to expect failed results has_output = ( -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: automember.diff Type: text/x-patch Size: 1668 bytes Desc: not available URL: From dpal at redhat.com Fri Jan 6 22:53:10 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Jan 2012 17:53:10 -0500 Subject: [Freeipa-devel] [PATCH] 335 Added account status into user search facet. In-Reply-To: <4F07063E.9020708@redhat.com> References: <4F05CE0B.8000102@redhat.com> <4F068326.8050305@redhat.com> <4F07063E.9020708@redhat.com> Message-ID: <4F077B56.4090404@redhat.com> On 01/06/2012 09:33 AM, Petr Vobornik wrote: > On 01/06/2012 06:14 AM, Endi Sukma Dewata wrote: >> On 1/5/2012 10:21 AM, Endi Sukma Dewata wrote: >>> The user search facet has been modified to show the account status. >>> The IPA.boolean_format has been converted into a class to allow >>> behavior customization. >>> >>> Ticket #1996 >> >> Fixed jslint warning. >> > > ACK and pushed to master. (improvement) > > But before closing the ticket I must ask if it covers all parts of the > ticket? > > Especially the part: "easy identifiable from the list they are in. > For examply by an icon, or in a change in font color." > > Right now the information is there, but is it easy identifiable? > Should we ask UXD for an input? > I will ask Kyle. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ohamada at redhat.com Sat Jan 7 20:05:55 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Sat, 07 Jan 2012 21:05:55 +0100 Subject: [Freeipa-devel] [PATCH] 7 Ignore srchost option in hbactest In-Reply-To: <20120105164033.GH24492@redhat.com> References: <4F05CB5D.20701@redhat.com> <20120105164033.GH24492@redhat.com> Message-ID: <4F08A5A3.1000107@redhat.com> On 01/05/2012 05:40 PM, Alexander Bokovoy wrote: > On Thu, 05 Jan 2012, Ondrej Hamada wrote: >> https://fedorahosted.org/freeipa/ticket/2085 >> >> New version of SSSD begins ignoring sourcehost value of HBAC rules by >> default. In order to match this behaviour the sourcehost option in >> hbactest is optional now, but the value of sourcehost is ignored in all >> rules. Every rule's sourcehost value is set to 'ALL' what turns sourchost >> value comparation off. For every such a rule warning is displayed to >> inform the user about changes. >> >> Also the unit tests for hbactest plugin were updated. Every test was >> doubled. The second ones test the plugin without sourcehost option. They >> are supposed to have the same result. > Looks OK for me. One possibility to enhance the tests is to verify > that sourcehost-based version also checks warning being set to > something other than None. > > ACK Done. I've also made one modification - warnings appear only when srchost option is used and unittests checks whether they've appeared. I've also updated the text in docstring to be mentioning srchost option as optional only. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-7-1-HBAC-test-optional-sourcehost-option.patch Type: text/x-patch Size: 15906 bytes Desc: not available URL: From jfenal at gmail.com Sun Jan 8 14:22:06 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sun, 8 Jan 2012 15:22:06 +0100 Subject: [Freeipa-devel] Non easily translatable strings Message-ID: Hi all, Going on on my translation to French for FreeIPA, it happens some strings will be difficult to translate, because they use non-named arguments. Here is the full list (search for \%s.*\%s in code or pot file) : ipalib/plugins/baseldap.py:1548 Search for %s with these %s %s. ipalib/plugins/baseldap.py:1549 Search for %s without these %s %s. ipalib/plugins/config.py:228 %s default attribute %s would not be allowed! ipalib/plugins/dns.py:1316 Delete %s '%s'? ipalib/plugins/dns.py:1331 %s record with value %s not found ipalib/plugins/sudorule.py:655 Added option "%s" to Sudo Rule "%s" ipalib/plugins/sudorule.py:710 Removed option "%s" from Sudo Rule "%s" ipa-client/ipa-join.c:746 Error parsing "%s": %s.\n ipa-client/ipa-rmkeytab.c:230 ipa-client/ipa-rmkeytab.c:237 Failed to open keytab '%s': %s\n Do you want to handle it from here (I can code in Perl, but Python is cryptic to me), or do you want me to create a ticket ? Regards, J. -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Sun Jan 8 15:35:23 2012 From: jdennis at redhat.com (John Dennis) Date: Sun, 08 Jan 2012 10:35:23 -0500 Subject: [Freeipa-devel] Non easily translatable strings In-Reply-To: References: Message-ID: <4F09B7BB.5080804@redhat.com> On 01/08/2012 09:22 AM, J?r?me Fenal wrote: > Hi all, > > Going on on my translation to French for FreeIPA, it happens some > strings will be difficult to translate, because they use non-named > arguments. > > Do you want to handle it from here (I can code in Perl, but Python is > cryptic to me), or do you want me to create a ticket ? Hi J?r?me: Thanks, actually we already have a ticket open for this https://fedorahosted.org/freeipa/ticket/2179 And we also have this ticket open to assure the problem does not repeat itself https://fedorahosted.org/freeipa/ticket/1958 -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From marco.pizzoli at gmail.com Sun Jan 8 15:44:14 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 8 Jan 2012 16:44:14 +0100 Subject: [Freeipa-devel] FreeIPA Italian translation Message-ID: Hi guys, I started to follow this mailing list only few time ago and I see there's a work in progress for language translations. If could be helpful, I would be glad to give my contribute to the Italian's one. I'm Italian mother tongue. Could someone give me a reference on what to do? Thanks Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfenal at gmail.com Sun Jan 8 16:04:46 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sun, 8 Jan 2012 17:04:46 +0100 Subject: [Freeipa-devel] FreeIPA Italian translation In-Reply-To: References: Message-ID: 2012/1/8 Marco Pizzoli > Hi guys, > I started to follow this mailing list only few time ago and I see there's > a work in progress for language translations. > > If could be helpful, I would be glad to give my contribute to the > Italian's one. I'm Italian mother tongue. > Could someone give me a reference on what to do? > Ciao Marco. The best way would be for you to : - review and follow processes setup by the Italian translation team for Fedora : https://fedoraproject.org/wiki/L10N_Italian_Team - get a login on Transifex - get a login on fas - get in teams - announce translation effort - translate. Regards, J. -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Sun Jan 8 16:13:30 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 8 Jan 2012 17:13:30 +0100 Subject: [Freeipa-devel] FreeIPA Italian translation In-Reply-To: References: Message-ID: > Ciao Marco. > > The best way would be for you to : > - review and follow processes setup by the Italian translation team for > Fedora : https://fedoraproject.org/wiki/L10N_Italian_Team > - get a login on Transifex > - get a login on fas > - get in teams > - announce translation effort > - translate. > Salut Jerome, Thank you, I will follow that road. Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Jan 9 06:53:28 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Jan 2012 08:53:28 +0200 Subject: [Freeipa-devel] [PATCH] 7 Ignore srchost option in hbactest In-Reply-To: <4F08A5A3.1000107@redhat.com> References: <4F05CB5D.20701@redhat.com> <20120105164033.GH24492@redhat.com> <4F08A5A3.1000107@redhat.com> Message-ID: <20120109065328.GD31251@redhat.com> On Sat, 07 Jan 2012, Ondrej Hamada wrote: > On 01/05/2012 05:40 PM, Alexander Bokovoy wrote: > >On Thu, 05 Jan 2012, Ondrej Hamada wrote: > >>https://fedorahosted.org/freeipa/ticket/2085 > >> > >>New version of SSSD begins ignoring sourcehost value of HBAC rules by > >>default. In order to match this behaviour the sourcehost option in > >>hbactest is optional now, but the value of sourcehost is ignored in all > >>rules. Every rule's sourcehost value is set to 'ALL' what turns sourchost > >>value comparation off. For every such a rule warning is displayed to > >>inform the user about changes. > >> > >>Also the unit tests for hbactest plugin were updated. Every test was > >>doubled. The second ones test the plugin without sourcehost option. They > >>are supposed to have the same result. > >Looks OK for me. One possibility to enhance the tests is to verify > >that sourcehost-based version also checks warning being set to > >something other than None. > > > >ACK > Done. I've also made one modification - warnings appear only when > srchost option is used and unittests checks whether they've > appeared. I've also updated the text in docstring to be mentioning > srchost option as optional only. Great. ACK, pushed to master. -- / Alexander Bokovoy From jdennis at redhat.com Mon Jan 9 15:01:51 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 09 Jan 2012 10:01:51 -0500 Subject: [Freeipa-devel] Fwd: Type conversions (was: enhancement tickets) In-Reply-To: <4F0AFD61.8070002@redhat.com> References: <4F0AFD61.8070002@redhat.com> Message-ID: <4F0B015F.7030002@redhat.com> Forwarding to freeipa-devel where this should have gone in the first place ... -------- Original Message -------- Subject: Type conversions (was: enhancement tickets) Date: Mon, 09 Jan 2012 09:44:49 -0500 From: John Dennis To: Jan Cholasta CC: Rob Crittenden , Martin Kosek , Endi Sukma Dewata , Petr Vobornik , Alexander Bokovoy On 01/09/2012 03:34 AM, Jan Cholasta wrote: >>> And ticket 2033. I have a vague notion you decided to defer this, am I >>> remembering correctly? >> >> Nope, I'm working on a patch to fix this ticket. I had a patch for it, >> but I have realized that the problem lies deeper than I thought, so I'm >> working on a new patch now. >> >> The new patch changes the way parameter values are encoded and decoded >> so that it is done in "border" backends (ldap2, xmlclient, >> Executioner-based backends) instead of doing it ad-hoc all over the >> code. This means that when a value enters IPA (either from a RPC >> interface or from LDAP), it is converted from the backend-specific type >> to the parameter type (which can be anything now, IP address object, DN >> object, etc.) in a backend-specific way. When it leaves IPA, it is >> converted back to backend-specific type, in a backend-specific way. >> Inside IPA, the values are passed using the parameter type, so there is >> no need to do any type conversions inside IPA. This will help me fix >> 1487 and I believe it will also help John with his DN cleanup work >> (because he won't have to care about converting the DNs to and from >> strings). >> >> Turns out it is pretty tricky to do everything right, but I (hopefully) >> solved all the big issues and will submit the patch soon. I'm very interested in this work. I too have recognized that we have a very real structural problem with how we handle the types we use internally, especially when it corresponds to an external type and requires conversion. In fact we do a remarkably bad job in this area, we have conversions which are done ad hoc all over the place. There is no well established place for the conversions to occur and it's difficult to know at any point in the code what type to expect. I faced this problem when trying to do the DN clean-up work. In fact the biggest hurdle I faced was refactoring the code such that when a dn enters our system it is converted to a DN object and when it leaves our system it is converted back to a string representation at the logical API boundaries. I have code sitting in a personal branch that does a lot of this. It also caused me to locate and find all the weird hidden places where conversions magically occur (a good example being the decorators in the ldap2 module). I'd like to work with you on this, see what you've done and maybe we should compare notes and share code. Also given this is a structural issue perhaps the devel team should review proposed changes since it's significant to the architecture. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pvoborni at redhat.com Mon Jan 9 15:20:33 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 09 Jan 2012 16:20:33 +0100 Subject: [Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server In-Reply-To: <4F03CD33.80903@redhat.com> References: <4F02C51E.80502@redhat.com> <4F03CD33.80903@redhat.com> Message-ID: <4F0B05C1.3090700@redhat.com> On 01/04/2012 04:53 AM, Endi Sukma Dewata wrote: > On 1/3/2012 3:06 AM, Petr Vobornik wrote: >> 1) 62-Added-support-of-custom-field-validators >> 2) 63-Added-validation-logic-to-multivalued-text-field - depends on 1 >> 3) 64-Added-client-side-validation-of-A-and-AAAA-DNS-recor - depends on 1 >> 4) 65-Fixed-IPv6-validation-special-case-single-colon - minor fix > > ACK and pushed to master. There are some minor issues but they can be > fixed later since they don't cause regression: New patch attached. > > 1. The IPv4 validator can take quads or integer, but it looks like > according to RFC 1035 section 3.4.1 (http://tools.ietf.org/html/rfc1035) > the A record should only take quads: > > A records cause no additional section processing. The RDATA section > of an A line in a master file is an Internet address expressed as four > decimal numbers separated by dots without any imbedded spaces (e.g., > "10.2.0.52" or "192.0.5.6") CLI also accepts integer formatted addresses and it also works with bind. So I would not change it or I would change it on both sides. > > 2. The DNS record adder dialog doesn't validate the A/AAAA records. We > might want to define some hidden fields, one field for each record type, > then the field will only appear if you select the type from the > drop-down list. This way each field can have its own validators. This > solution is similar to permission target widget and will be the basis > for ticket #2208. Done. I'm dynamically changing only validators for the field. In #2208 I will probably drastically change it. My idea is prepare nice metadata (like record type - validator mappings and such) and generate adder and edit dialogs. > > 3. The host adder dialog doesn't validate the IP address. Validation added. Also be aware of ticket: https://fedorahosted.org/freeipa/ticket/2229 > > 4. The widget_value_changed() in IPA.multivalued_field is not needed > because it's identical to the one in IPA.field. Removed > 5. Existing problem, in the DNS Resource Records page the delete > operation doesn't work. I think this will be addressed in #2094. > Will fix in #2094 > 6. Existing problem, in the extract_child_value() in > IPA.multivalued_text_widget if the value is an empty array the function > will return the array itself instead of empty string. Fixed > 7. Existing problem, in net.js:330 the error message should be for > leading instead of trailing zeros. > Fixed Some thoughts when I was implementing #2: I wanted to use only one field and abandon the overriding of create_add_command in record_adder_dialog (I don't like that hack). I was thinking about two possible solutions: 1) Override field's save method and use something like this: "record[type_got_from_other_widget] = values". Problem is that this method doesn't work with command construction in adder dialog and details facet - they rely on fields.name will be different from the type. 2) Second approach was to dynamically change field's name. This seemed bad because the field can be saved in fields map under original name, not his current name. (Adding and removing from the map seemed even worse). In the end I left it as it was. How evil are those approaches or the relying on fields name (the field can put something other or even more values to record in its save mehtod.) in command construction? Do we want to keep those constrains (field should save under its name only one value)? -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0067-Added-IP-address-validator-to-Host-and-DNS-record-ad.patch Type: text/x-patch Size: 8634 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 9 20:38:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Jan 2012 15:38:58 -0500 Subject: [Freeipa-devel] ipa-2.1 branch freeze Message-ID: <4F0B5062.9060502@redhat.com> Please refrain from pushing anything to the 2.1 branch for the next couple of days. I'm in the process of merging patches in from master and it will make my life easier if the tree remains static. thanks rob From edewata at redhat.com Tue Jan 10 05:50:08 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 09 Jan 2012 23:50:08 -0600 Subject: [Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server In-Reply-To: <4F0B05C1.3090700@redhat.com> References: <4F02C51E.80502@redhat.com> <4F03CD33.80903@redhat.com> <4F0B05C1.3090700@redhat.com> Message-ID: <4F0BD190.6010004@redhat.com> On 1/9/2012 9:20 AM, Petr Vobornik wrote: >> 2. The DNS record adder dialog doesn't validate the A/AAAA records. We >> might want to define some hidden fields, one field for each record type, >> then the field will only appear if you select the type from the >> drop-down list. This way each field can have its own validators. This >> solution is similar to permission target widget and will be the basis >> for ticket #2208. > > Done. I'm dynamically changing only validators for the field. In #2208 I > will probably drastically change it. My idea is prepare nice metadata > (like record type - validator mappings and such) and generate adder and > edit dialogs. One problem, try adding an A record but enter an IPv6 address, you'll get an error message. Then change it to AAAA, the message is still there even though the data is now correct. I think the on_type_change() should call validate(). Another problem, after adding the AAAA record, close the dialog, then then an A record, the validator is still IPv6. I think the on_type_change() should be called from reset() instead of widgets_created(). The change to select_widget.save() might not be necessary because the dialog will call create() before reset(). >> 6. Existing problem, in the extract_child_value() in >> IPA.multivalued_text_widget if the value is an empty array the function >> will return the array itself instead of empty string. > > Fixed It works, but it might be better to use if (value instanceof Array). > Some thoughts when I was implementing #2: > I wanted to use only one field and abandon the overriding of > create_add_command in record_adder_dialog (I don't like that hack). > I was thinking about two possible solutions: > 1) Override field's save method and use something like this: > "record[type_got_from_other_widget] = values". Problem is that this > method doesn't work with command construction in adder dialog and > details facet - they rely on fields.name will be different from the type. > 2) Second approach was to dynamically change field's name. This seemed > bad because the field can be saved in fields map under original name, > not his current name. (Adding and removing from the map seemed even worse). > > In the end I left it as it was. > > How evil are those approaches or the relying on fields name (the field > can put something other or even more values to record in its save > mehtod.) in command construction? Do we want to keep those constrains > (field should save under its name only one value)? We might be able to fix the create_add_command() in entity_adder dialog to iterate through the record's contents instead of using the fields list. Then you can customize the save() to produce the correct record. -- Endi S. Dewata From edewata at redhat.com Tue Jan 10 07:35:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jan 2012 01:35:53 -0600 Subject: [Freeipa-devel] [PATCH] 336 Added policies into user details page. In-Reply-To: <4F06FC13.2060704@redhat.com> References: <4F06832C.6070300@redhat.com> <4F06FC13.2060704@redhat.com> Message-ID: <4F0BEA59.5010604@redhat.com> On 1/6/2012 7:50 AM, Petr Vobornik wrote: > 1) you are calling krbtpolicy-show without any user specific information > so it always get the global policy. It should be call with an user > argument. Fixed. Right now it's read only. I think we should provide an interface to edit the Kerberos ticket policy for each user, but I don't think it's as simple as making the fields editable because there are 2 operations that we need to support: Update (krbtpolicy-mod) and Reset (krbtpolicy-reset). The krbtpolicy-mod probably can be called together with user-mod when we click Update, but we need a new button for the Reset operation because it's completely different than the details facet's Reset button. > Minor: > 2) Why not call pwpolicy-show --user=user_login instead of getting the > policy's name from dn? Fixed. The password policy is intentionally made read only because the policy belongs to the group, not the user. If we make it editable it might confuse the admin into thinking that he's changing the policy for the user only whereas he's actually changing the policy for the whole group. We might be able to show the password policy in group details page too, but I'm not sure if it's necessary. > Combining 1), 2) and user-show will allow to get all necessary > information for the facet in a single batch at refresh. This will be done in the next patch. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0336-2-Added-policies-into-user-details-page.patch Type: text/x-patch Size: 33649 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 10 07:36:05 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jan 2012 01:36:05 -0600 Subject: [Freeipa-devel] [PATCH] 337 Load user data and policies in a single batch. Message-ID: <4F0BEA65.8090408@redhat.com> The user details facet has been modified to load the user data, password policy and Kerberos ticket policy in a single batch command. Ticket #703 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0337-Load-user-data-and-policies-in-a-single-batch.patch Type: text/x-patch Size: 20499 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 10 08:22:05 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jan 2012 02:22:05 -0600 Subject: [Freeipa-devel] [PATCH] 338 Added instructions to generate CRL. Message-ID: <4F0BF52D.7040302@redhat.com> The certificate request dialog box has been modified to show the OpenSSL commands for generating a CRL. The realm and entry names in the test data have been fixed to be more consistent. Ticket #1012 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0338-Added-instructions-to-generate-CRL.patch Type: text/x-patch Size: 185558 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 10 09:11:44 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Jan 2012 10:11:44 +0100 Subject: [Freeipa-devel] [PATCH] 066 Added support for memberof attribute in permission In-Reply-To: <4F04945E.7010502@redhat.com> References: <4F02F28A.1060306@redhat.com> <4F04945E.7010502@redhat.com> Message-ID: <4F0C00D0.3060309@redhat.com> On 01/04/2012 07:03 PM, Endi Sukma Dewata wrote: > On 1/3/2012 6:20 AM, Petr Vobornik wrote: >> The attribute was added to adder dialog and details facet. It uses >> entity select(group) widget. >> >> https://fedorahosted.org/freeipa/ticket/2101 >> >> Proper functionality of this patch depends on ticket #2100 - Rob's patch >> 912. >> >> Also fixing one label regression. > > I think the memberof is one of possible permission targets, so it should > be added into the IPA.permission_target_widget. The memberof drop-down > list should appear only when you select memberof as the target. > Updated patch attached. Modified according to discussion for patch 912: > To reflect the correct possible combinations, we probably should move the 'Member of group' field somewhere below the 'Target' drop-down list and show it only when 'Type' or 'Subtree' is selected. If we keep option #4b then we should also show it when the 'Target group' is selected. Also memberof is not visible for target=='targetgroup' https://fedorahosted.org/freeipa/ticket/2222 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0066-1-Added-support-for-memberof-attribute-in-permission.patch Type: text/x-patch Size: 6252 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jan 10 09:24:56 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Jan 2012 11:24:56 +0200 Subject: [Freeipa-devel] [PATCH, master] 0039 Allow hbactest to work with HBAC rules exceeding default IPA limits Message-ID: <20120110092456.GF31251@redhat.com> When multiple HBAC rules are defined, IPA default limits to retrieve objects may limit the scope of HBAC testing. To allow full range of rules to be tested support for --sizelimit option is added. In addition, when --rules option is specified, make sure only those rules are retrieved regardless total number of rules defined. This should also speed up HBAC test performance for real life scenarios when few new rules are added to large collection of rules. https://fedorahosted.org/freeipa/ticket/2230 -- / Alexander Bokovoy -------------- next part -------------- >From 44261e7c9263cc6d4e1ca8132750ff29228dfa82 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 10 Jan 2012 11:15:26 +0200 Subject: [PATCH] Allow hbactest to work with HBAC rules exceeding default IPA limits When multiple HBAC rules are defined, IPA default limits to retrieve objects may limit the scope of HBAC testing. To allow full range of rules to be tested support for --sizelimit option is added. In addition, when --rules option is specified, make sure only those rules are retrieved regardless total number of rules defined. This should also speed up HBAC test performance for real life scenarios when few new rules are added to large collection of rules. https://fedorahosted.org/freeipa/ticket/2230 --- API.txt | 3 ++- ipalib/plugins/hbactest.py | 28 +++++++++++++++++++++++++--- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index 493d5a3ff235e2a6f2599896114365af54086d16..60e6316e1c7f5de3adaeeecd3896fe8a422c4c38 100644 --- a/API.txt +++ b/API.txt @@ -1455,7 +1455,7 @@ output: Output('summary', (, ), None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('value', , None) command: hbactest -args: 0,8,6 +args: 0,9,6 option: Str('user', cli_name='user', primary_key=True) option: Str('sourcehost?', cli_name='srchost') option: Str('targethost', cli_name='host') @@ -1464,6 +1464,7 @@ option: Str('rules*', cli_name='rules', csv=True) option: Flag('nodetail?', autofill=True, cli_name='nodetail', default=False) option: Flag('enabled?', autofill=True, cli_name='enabled', default=False) option: Flag('disabled?', autofill=True, cli_name='disabled', default=False) +option: Int('sizelimit?', autofill=False, minvalue=0) output: Output('summary', (, ), None) output: Output('warning', (, , ), None) output: Output('matched', (, , ), None) diff --git a/ipalib/plugins/hbactest.py b/ipalib/plugins/hbactest.py index f1b608d21a69bbd57577455157d8e78e11a54733..92b7145a3fca717b4699749c2ec2b88ae3647cd5 100644 --- a/ipalib/plugins/hbactest.py +++ b/ipalib/plugins/hbactest.py @@ -18,7 +18,7 @@ # along with this program. If not, see . from ipalib import api, errors, output -from ipalib import Command, Str, Flag +from ipalib import Command, Str, Flag, Int from types import NoneType from ipalib.cli import to_cli from ipalib import _, ngettext @@ -40,7 +40,7 @@ having access to the production environment. ipa hbactest --user= --host= --service= [--rules=rules-list] [--nodetail] [--enabled] [--disabled] - [--srchost= ] + [--srchost= ] [--sizelimit= ] --user, --host, and --service are mandatory, others are optional. @@ -57,6 +57,8 @@ having access to the production environment. all IPA enabled rules. If no --rules specified, simulation is run against all IPA enabled rules. + By default there is a IPA-wide limit to number of entries fetched, you can change it + with --sizelimit option. If --srchost is specified, it will be ignored. It is left because of compatibility reasons only. @@ -208,6 +210,13 @@ class hbactest(Command): cli_name='disabled', label=_('Include all disabled IPA rules into test'), ), + Int('sizelimit?', + label=_('Size Limit'), + doc=_('Maximum number of rules to process when no --rules is specified'), + flags=['no_display'], + minvalue=0, + autofill=False, + ), ) def canonicalize(self, host): @@ -224,7 +233,6 @@ class hbactest(Command): # 2. Required options are (user, source host, target host, service) # 3. Options: rules to test (--rules, --enabled, --disabled), request for detail output rules = [] - hbacset = self.api.Command.hbacrule_find()['result'] # Use all enabled IPA rules by default all_enabled = True @@ -238,6 +246,10 @@ class hbactest(Command): all_enabled = False all_disabled = False + sizelimit = None + if 'sizelimit' in options: + sizelimit = int(options['sizelimit']) + # Check if --disabled is specified, include all disabled IPA rules if options['disabled']: all_disabled = True @@ -247,6 +259,16 @@ class hbactest(Command): if options['enabled']: all_enabled = True + hbacset = [] + if len(testrules) == 0: + hbacset = self.api.Command.hbacrule_find(sizelimit=sizelimit)['result'] + else: + for rule in testrules: + try: + hbacset.append(self.api.Command.hbacrule_show(rule)['result']) + except: + pass + # We have some rules, import them # --enabled will import all enabled rules (default) # --disabled will import all disabled rules -- 1.7.8 From pvoborni at redhat.com Tue Jan 10 09:34:59 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Jan 2012 10:34:59 +0100 Subject: [Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server In-Reply-To: <4F0BD190.6010004@redhat.com> References: <4F02C51E.80502@redhat.com> <4F03CD33.80903@redhat.com> <4F0B05C1.3090700@redhat.com> <4F0BD190.6010004@redhat.com> Message-ID: <4F0C0643.1050805@redhat.com> Updated patch attached. On 01/10/2012 06:50 AM, Endi Sukma Dewata wrote: > On 1/9/2012 9:20 AM, Petr Vobornik wrote: > > One problem, try adding an A record but enter an IPv6 address, you'll > get an error message. Then change it to AAAA, the message is still there > even though the data is now correct. I think the on_type_change() should > call validate(). Fixed > Another problem, after adding the AAAA record, close the dialog, then > then an A record, the validator is still IPv6. I think the > on_type_change() should be called from reset() instead of > widgets_created(). The change to select_widget.save() might not be > necessary because the dialog will call create() before reset(). Fixed >>> 6. Existing problem, in the extract_child_value() in >>> IPA.multivalued_text_widget if the value is an empty array the function >>> will return the array itself instead of empty string. >> >> Fixed > > It works, but it might be better to use if (value instanceof Array). Changed. >> Some thoughts when I was implementing #2: >> I wanted to use only one field and abandon the overriding of >> create_add_command in record_adder_dialog (I don't like that hack). >> I was thinking about two possible solutions: >> 1) Override field's save method and use something like this: >> "record[type_got_from_other_widget] = values". Problem is that this >> method doesn't work with command construction in adder dialog and >> details facet - they rely on fields.name will be different from the type. >> 2) Second approach was to dynamically change field's name. This seemed >> bad because the field can be saved in fields map under original name, >> not his current name. (Adding and removing from the map seemed even >> worse). >> >> In the end I left it as it was. >> >> How evil are those approaches or the relying on fields name (the field >> can put something other or even more values to record in its save >> mehtod.) in command construction? Do we want to keep those constrains >> (field should save under its name only one value)? > > We might be able to fix the create_add_command() in entity_adder dialog > to iterate through the record's contents instead of using the fields > list. Then you can customize the save() to produce the correct record. Yes, in adder dialog it is very trivial - just simple for-in loop. But to be consistent it would have to be changed in details facet too. Which is not so trivial but it can be done. So to summarize it: it (#1) is OK to do it in some future patch if it is needed. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0067-1-Added-IP-address-validator-to-Host-and-DNS-record-ad.patch Type: text/x-patch Size: 8727 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 10 11:40:13 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jan 2012 12:40:13 +0100 Subject: [Freeipa-devel] [PATCH] 189 Fix ipa-server-install for dual NICs Message-ID: <1326195613.27400.14.camel@balmora.brq.redhat.com> Depends on my patch 188 --- A server may have 2 or more NICs and its hostname may thus resolve to 2 and more forward addresses. IP address checks in install scripts does not expect this setup and may fail or crash. This script adds a support for multiple forward addresses for a hostname. The install scripts do not crash now. When one IP address is needed, user is asked to choose from all detected server IP addresses. https://fedorahosted.org/freeipa/ticket/2154 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-189-fix-ipa-server-install-for-dual-nics.patch Type: text/x-patch Size: 15557 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jan 10 17:58:42 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Jan 2012 18:58:42 +0100 Subject: [Freeipa-devel] [PATCH] 336 Added policies into user details page. In-Reply-To: <4F0BEA59.5010604@redhat.com> References: <4F06832C.6070300@redhat.com> <4F06FC13.2060704@redhat.com> <4F0BEA59.5010604@redhat.com> Message-ID: <4F0C7C52.2040302@redhat.com> On 01/10/2012 08:35 AM, Endi Sukma Dewata wrote: > On 1/6/2012 7:50 AM, Petr Vobornik wrote: >> 1) you are calling krbtpolicy-show without any user specific information >> so it always get the global policy. It should be call with an user >> argument. > > Fixed. Right now it's read only. I think we should provide an interface > to edit the Kerberos ticket policy for each user, but I don't think it's > as simple as making the fields editable because there are 2 operations > that we need to support: Update (krbtpolicy-mod) and Reset > (krbtpolicy-reset). The krbtpolicy-mod probably can be called together > with user-mod when we click Update, but we need a new button for the > Reset operation because it's completely different than the details > facet's Reset button. I wouldn't modify it there too. Maybe the original ticket (new facet) wasn't a bad idea. But for reading this implementation is really fine. > >> Minor: >> 2) Why not call pwpolicy-show --user=user_login instead of getting the >> policy's name from dn? > > Fixed. The password policy is intentionally made read only because the > policy belongs to the group, not the user. If we make it editable it > might confuse the admin into thinking that he's changing the policy for > the user only whereas he's actually changing the policy for the whole > group. Agree >We might be able to show the password policy in group details > page too, but I'm not sure if it's necessary. We will see if some user will want it. > >> Combining 1), 2) and user-show will allow to get all necessary >> information for the facet in a single batch at refresh. > > This will be done in the next patch. > ACK and pushed to master -- Petr Vobornik From pvoborni at redhat.com Tue Jan 10 18:00:43 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Jan 2012 19:00:43 +0100 Subject: [Freeipa-devel] [PATCH] 337 Load user data and policies in a single batch. In-Reply-To: <4F0BEA65.8090408@redhat.com> References: <4F0BEA65.8090408@redhat.com> Message-ID: <4F0C7CCB.1060100@redhat.com> On 01/10/2012 08:36 AM, Endi Sukma Dewata wrote: > The user details facet has been modified to load the user data, > password policy and Kerberos ticket policy in a single batch > command. > > Ticket #703 > > ACK and pushed to master -- Petr Vobornik From sgallagh at redhat.com Tue Jan 10 19:31:51 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 10 Jan 2012 14:31:51 -0500 Subject: [Freeipa-devel] New SSSD FAQ page in the works Message-ID: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> It's come up more than once that SSSD needs a Frequently Asked Questions page to field some of our more common questions. I'm reaching out to the SSSD and FreeIPA user and developer communities to help us flesh out this page. I've begun it with the two most common questions I've received lately, as well as a basic primer on enabling debug logging to help identify issues. I'd like some additional suggestions on what questions should be answered on that page, as well as opening the page to volunteer-edits to add answers to any questions they may have had and solved (or enlisted aid in solving) in the past. The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can be edited by anyone with a free Fedora account. If you don't have one, you can register quickly and easily at https://admin.fedorahosted.org/accounts Thank you very much for your contributions. Once this page has some meat, I will also be looking for interested translators to take a stab at making it accessible to non-English-native users. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Tue Jan 10 22:48:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Jan 2012 17:48:56 -0500 Subject: [Freeipa-devel] [PATCH] [ipa-2-1] 183 Make sure that install tools log In-Reply-To: <1325590091.22407.15.camel@balmora.brq.redhat.com> References: <1325519910.25703.8.camel@balmora.brq.redhat.com> <20120102163524.GD29356@redhat.com> <1325579771.22407.1.camel@balmora.brq.redhat.com> <20120103102751.GB21825@redhat.com> <1325590091.22407.15.camel@balmora.brq.redhat.com> Message-ID: <4F0CC058.1090407@redhat.com> Martin Kosek wrote: > On Tue, 2012-01-03 at 13:27 +0300, Alexander Bokovoy wrote: >> On Tue, 03 Jan 2012, Martin Kosek wrote: >>>> This way we'll get all the records recovered and will get around >>>> IPACheckedAddress limitations. >>>> >>> >>> That's a good idea! This way we won't miss any log before our logging >>> setup. Updated patch attached. >> Tried it on F16. With 2.1.4-3 there is no ipaserver-install.log, with >> the patch I'm getting all the proper logging. Good! >> >> ACK. >> > > Pushed to ipa-2-1. > > Martin This should probably be ported to master as well, right? rob From abokovoy at redhat.com Wed Jan 11 05:16:25 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Jan 2012 07:16:25 +0200 Subject: [Freeipa-devel] [PATCH] [ipa-2-1] 183 Make sure that install tools log In-Reply-To: <4F0CC058.1090407@redhat.com> References: <1325519910.25703.8.camel@balmora.brq.redhat.com> <20120102163524.GD29356@redhat.com> <1325579771.22407.1.camel@balmora.brq.redhat.com> <20120103102751.GB21825@redhat.com> <1325590091.22407.15.camel@balmora.brq.redhat.com> <4F0CC058.1090407@redhat.com> Message-ID: <20120111051624.GA3891@redhat.com> On Tue, 10 Jan 2012, Rob Crittenden wrote: > Martin Kosek wrote: > >On Tue, 2012-01-03 at 13:27 +0300, Alexander Bokovoy wrote: > >>On Tue, 03 Jan 2012, Martin Kosek wrote: > >>>>This way we'll get all the records recovered and will get around > >>>>IPACheckedAddress limitations. > >>>> > >>> > >>>That's a good idea! This way we won't miss any log before our logging > >>>setup. Updated patch attached. > >>Tried it on F16. With 2.1.4-3 there is no ipaserver-install.log, with > >>the patch I'm getting all the proper logging. Good! > >> > >>ACK. > >> > > > >Pushed to ipa-2-1. > > > >Martin > > This should probably be ported to master as well, right? No, master has John's logging framework which solves this problem differently. This particular patch was done to avoid backporting the logging code to ipa-2-1. -- / Alexander Bokovoy From edewata at redhat.com Wed Jan 11 06:52:11 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 11 Jan 2012 00:52:11 -0600 Subject: [Freeipa-devel] [PATCH] 066 Added support for memberof attribute in permission In-Reply-To: <4F0C00D0.3060309@redhat.com> References: <4F02F28A.1060306@redhat.com> <4F04945E.7010502@redhat.com> <4F0C00D0.3060309@redhat.com> Message-ID: <4F0D319B.8070700@redhat.com> On 1/10/2012 3:11 AM, Petr Vobornik wrote: > Updated patch attached. ACK and pushed to master. It looks like there's a server problem, in the details page setting the member of to empty will generate an error. -- Endi S. Dewata From edewata at redhat.com Wed Jan 11 06:54:01 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 11 Jan 2012 00:54:01 -0600 Subject: [Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server In-Reply-To: <4F0C0643.1050805@redhat.com> References: <4F02C51E.80502@redhat.com> <4F03CD33.80903@redhat.com> <4F0B05C1.3090700@redhat.com> <4F0BD190.6010004@redhat.com> <4F0C0643.1050805@redhat.com> Message-ID: <4F0D3209.5020202@redhat.com> On 1/10/2012 3:34 AM, Petr Vobornik wrote: > Updated patch attached. ACK and pushed to master. >> We might be able to fix the create_add_command() in entity_adder dialog >> to iterate through the record's contents instead of using the fields >> list. Then you can customize the save() to produce the correct record. > > Yes, in adder dialog it is very trivial - just simple for-in loop. But > to be consistent it would have to be changed in details facet too. Which > is not so trivial but it can be done. So to summarize it: it (#1) is OK > to do it in some future patch if it is needed. Agreed. -- Endi S. Dewata From mkosek at redhat.com Wed Jan 11 07:35:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Jan 2012 08:35:31 +0100 Subject: [Freeipa-devel] [PATCH] 190 Fix ipa-server-install for dual NICs In-Reply-To: <1326195613.27400.14.camel@balmora.brq.redhat.com> References: <1326195613.27400.14.camel@balmora.brq.redhat.com> Message-ID: <1326267331.9621.1.camel@balmora.brq.redhat.com> It seems I sent two patches with number 189. Sending a patch with a correct number. Martin On Tue, 2012-01-10 at 12:40 +0100, Martin Kosek wrote: > Depends on my patch 188 > --- > A server may have 2 or more NICs and its hostname may thus resolve > to 2 and more forward addresses. IP address checks in install > scripts does not expect this setup and may fail or crash. > > This script adds a support for multiple forward addresses for > a hostname. The install scripts do not crash now. When one IP > address is needed, user is asked to choose from all detected > server IP addresses. > > https://fedorahosted.org/freeipa/ticket/2154 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-190-fix-ipa-server-install-for-dual-nics.patch Type: text/x-patch Size: 15557 bytes Desc: not available URL: From simo at redhat.com Wed Jan 11 19:32:12 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jan 2012 14:32:12 -0500 Subject: [Freeipa-devel] New Devel branch 2.2 Message-ID: <1326310332.30661.368.camel@willson.li.ssimo.org> Hello fellow developers, The Hunting Season for version 2.2 is officially open. I have just pushed the ipa-2-2 branch into the upstream git tree. The current version is set to 2.1.90 and will go up from there until we are ready to release FreeIPA version 2.2.0 The 2.1 branch is now officially closed to development and only patches for major defects or security issues should be pushed there. The 2.2 branch has more than 200 patches backported from master which is still marching towards the 3.0 release. The 2.2 branch is meant to provide a number of features we wanted to initially defer to 3.0, but finally decided to release earlier in the 2.x series. This means you have to be careful about which patches should be committed to both trees and which shouldn't. Have fun! Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jan 11 20:16:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 15:16:18 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 182 Create per-type DNS API based on options In-Reply-To: <1325867995.2159.26.camel@priserak> References: <1324482381.11925.16.camel@balmora.brq.redhat.com> <1325867995.2159.26.camel@priserak> Message-ID: <4F0DEE12.2020306@redhat.com> Martin Kosek wrote: > On Wed, 2011-12-21 at 16:46 +0100, Martin Kosek wrote: >> This is a fully functional prototype of the new DNS API based on new >> options instead of new commands. It still has rough edges (missing >> tests, extended help) but should give a very good picture about the new >> API and provide a base for WebUI guys. >> >> ------- >> Use new structured DNSRecord parameters to generate per-type API >> for all supported DNS RR types. This should help significantly >> the end-user with manipulating complex DNS record type (MX, LOC, >> etc.). >> >> All enhancements are integrated to current DNS record commands: >> >> 1) dnsrecord-add >> - Records can be either entered as a raw value (e.g. --mx-rec= >> "1 srv1.example.com" for MX record) or per-part: >> --mx-preference=1 --mx-exchanger=srv1.example.com >> - CLI interactive help behavior was changed. It will ask for >> a record type and then ask for all DNS record part values >> (e.g. MX Preference value, MX Exchanger value). >> >> 2) dnsrecord-mod >> - This command can now operate in 2 modes. When only a raw DNS >> record is entered (e.g. --mx-rec="1 srv1.example.com") it >> operates in standard mode and replaces any previous mxrecord >> value with the --mx-rec value. >> >> When any structured parameter (e.g. --mx-preference) is passed >> it modifies just the specified parts of one mxrecord value >> referred by --mx-rec: >> --mx-rec="1 srv1.example.com" --mx-preference=2 >> - New interactive help has been implemented. It will ask for a >> record to be modified (in the same manner as dnsrecord-del) >> and then let user change DNS record part(s) for chosen >> records. >> >> 3) All dnsrecord-* commands have now --structured option >> - When this option is passed, instead of displaying raw DNS values >> all DNS records are parsed and displayed per-part. Example: >> >> $ ipa dnsrecord-show example.com @ --structured >> Record name: @ >> Records: >> Record type: MX >> Record data: 0 server1.example.com. >> MX Preference: 0 >> MX Exchanger: server1.example.com. >> >> Record type: NS >> Record data: ns1.example.com. >> NS Hostname: ns1.example.com. >> >> All API changes are compatible with clients without this patch. >> >> https://fedorahosted.org/freeipa/ticket/2082 >> >> ------------------------------------------------ >> A little demonstration of the new API capabilities: >> >> #### New help with option groups for per-type options >> # ipa dnsrecord-add --help >> Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] >> >> Options: >> ... >> --structured Parse all raw DNS records and return them in a >> structured way >> ... >> A Record: >> --a-rec=ARECORD Comma-separated list of raw A records >> --a-ip-address=STR IP Address >> >> AAAA Record: >> --aaaa-rec=AAAARECORD >> Comma-separated list of raw AAAA records >> --aaaa-ip-address=STR >> IP Address >> ... >> MX Record: >> --mx-rec=MXRECORD Comma-separated list of raw MX records >> --mx-preference=INT >> Preference given to this exchanger. Lower values >> are >> more preferred >> --mx-exchanger=STR A host willing to act as a mail exchanger >> >> #### Standard dnsrecord-add >> # ipa dnsrecord-add example.com server1 --a-rec=10.0.0.1 >> Record name: server1 >> A record: 10.0.0.1 >> >> #### New interactive help for dnsrecord-add >> # ipa dnsrecord-add example.com server1 >> Please choose a type of DNS resource record to be added >> The most common types for this type of zone are: A, AAAA >> >> DNS resource record type: AAAA >> AAAA IP Address: 2001:db8::1428:57ab >> Record name: server1 >> A record: 10.0.0.1 >> AAAA record: 2001:db8::1428:57ab >> >> # ipa dnsrecord-add example.com @ >> Please choose a type of DNS resource record to be added >> The most common types for this type of zone are: NS, MX, LOC >> >> DNS resource record type: MX >> MX Preference: 0 >> MX Exchanger: server1.example.com. >> Record name: example.com >> MX record: 0 server1.example.com. >> NS record: vm-068.idm.lab.bos.redhat.com. >> >> #### Old-stype mod command >> # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." >> Record name: example.com >> MX record: 1 server1.example.com. >> NS record: vm-068.idm.lab.bos.redhat.com. >> >> #### Modification via new structured options: >> # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." --mx-preference=2 >> Record name: example.com >> MX record: 2 server1.example.com. >> NS record: vm-068.idm.lab.bos.redhat.com. >> >> #### Modification via new interactive help: >> # ipa dnsrecord-mod example.com @ >> No option to modify specific record provided. >> Current DNS record contents: >> >> MX record: 2 server1.example.com. >> NS record: vm-068.idm.lab.bos.redhat.com. >> >> Modify MX record '2 server1.example.com.'? Yes/No (default No): y >> MX Preference [2]: 3 >> MX Exchanger [server1.example.com.]: >> Modify NS record 'vm-068.idm.lab.bos.redhat.com.'? Yes/No (default No): >> Record name: example.com >> MX record: 3 server1.example.com. >> NS record: vm-068.idm.lab.bos.redhat.com. >> >> #### Example of use of --structured option (this will be useful for WebUI): >> # ipa dnsrecord-show example.com @ --structured >> Record name: @ >> Records: >> Record type: MX >> Record data: 3 server1.example.com. >> MX Preference: 3 >> MX Exchanger: server1.example.com. >> >> Record type: NS >> Record data: vm-068.idm.lab.bos.redhat.com. >> NS Hostname: vm-068.idm.lab.bos.redhat.com. >> >> #### dnsrecord-del works in the same way as the old one: >> # ipa dnsrecord-del example.com server1 >> No option to delete specific record provided. >> Delete all? Yes/No (default No): >> Current DNS record contents: >> >> AAAA record: 2001:db8::1428:57ab >> A record: 10.0.0.1 >> >> Delete AAAA record '2001:db8::1428:57ab'? Yes/No (default No): y >> Delete A record '10.0.0.1'? Yes/No (default No): >> Record name: server1 >> A record: 10.0.0.1 > > I prepared a rebased version of the patch set for easier review. There > are few changes: > - DNS module was extended to mention new interactive modes and options > - one bug in dnsrecord-mod interactive mode was fixed - only one value > per DNS type can be modified at one time > - all translatable strings in DNS module with more than one placeholder > were converted to dict format > > Martin Just fix these few things before pushing, otherwise ACK x 4: - Add continuation \\ to the example "Add new reverse zone specified by network IP address:" - Bump VERSION so it applies cleanly against master - This is probably not an issue since the older clients won't have this updated help, but this example does not work on older clients: # ipa dnsrecord-add example.com @ --mx-preference=20 --mx-exchanger=mail2 Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] ipa: error: no such option: --mx-preference Something to consider outside the scope of this patch is now that we have option groups, break out the standard options into groups. I'm thinking about things like output (--all, --raw, --structured), direct attribute modification (--addattr, --setattr, --delattr) and command-specific. Some balance would be required to not bloat the help too much but this kind of clarity has been requested for a while. This functionality is really good. I'm sure the full rewrites and weeks of back and forth have been a drag but the end product is very nice. Great work. rob From rcritten at redhat.com Wed Jan 11 20:39:51 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 15:39:51 -0500 Subject: [Freeipa-devel] [PATCH] 062-065 Ticket 1466 Validate AAAA records as valid IPv6 prior to sending to server In-Reply-To: <4F0D3209.5020202@redhat.com> References: <4F02C51E.80502@redhat.com> <4F03CD33.80903@redhat.com> <4F0B05C1.3090700@redhat.com> <4F0BD190.6010004@redhat.com> <4F0C0643.1050805@redhat.com> <4F0D3209.5020202@redhat.com> Message-ID: <4F0DF397.5040207@redhat.com> Endi Sukma Dewata wrote: > On 1/10/2012 3:34 AM, Petr Vobornik wrote: >> Updated patch attached. > > ACK and pushed to master. > >>> We might be able to fix the create_add_command() in entity_adder dialog >>> to iterate through the record's contents instead of using the fields >>> list. Then you can customize the save() to produce the correct record. >> >> Yes, in adder dialog it is very trivial - just simple for-in loop. But >> to be consistent it would have to be changed in details facet too. Which >> is not so trivial but it can be done. So to summarize it: it (#1) is OK >> to do it in some future patch if it is needed. > > Agreed. > pushed to ipa-2-2 From rcritten at redhat.com Wed Jan 11 20:40:05 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 15:40:05 -0500 Subject: [Freeipa-devel] [PATCH] 066 Added support for memberof attribute in permission In-Reply-To: <4F0D319B.8070700@redhat.com> References: <4F02F28A.1060306@redhat.com> <4F04945E.7010502@redhat.com> <4F0C00D0.3060309@redhat.com> <4F0D319B.8070700@redhat.com> Message-ID: <4F0DF3A5.8000704@redhat.com> Endi Sukma Dewata wrote: > On 1/10/2012 3:11 AM, Petr Vobornik wrote: >> Updated patch attached. > > ACK and pushed to master. > > It looks like there's a server problem, in the details page setting the > member of to empty will generate an error. > pushed to ipa-2-2 From rcritten at redhat.com Wed Jan 11 20:40:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 15:40:30 -0500 Subject: [Freeipa-devel] [PATCH] 337 Load user data and policies in a single batch. In-Reply-To: <4F0C7CCB.1060100@redhat.com> References: <4F0BEA65.8090408@redhat.com> <4F0C7CCB.1060100@redhat.com> Message-ID: <4F0DF3BE.60900@redhat.com> Petr Vobornik wrote: > On 01/10/2012 08:36 AM, Endi Sukma Dewata wrote: >> The user details facet has been modified to load the user data, >> password policy and Kerberos ticket policy in a single batch >> command. >> >> Ticket #703 >> >> > ACK and pushed to master > pushed to ipa-2-2 From rcritten at redhat.com Wed Jan 11 20:40:36 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 15:40:36 -0500 Subject: [Freeipa-devel] [PATCH] 336 Added policies into user details page. In-Reply-To: <4F0C7C52.2040302@redhat.com> References: <4F06832C.6070300@redhat.com> <4F06FC13.2060704@redhat.com> <4F0BEA59.5010604@redhat.com> <4F0C7C52.2040302@redhat.com> Message-ID: <4F0DF3C4.3060004@redhat.com> Petr Vobornik wrote: > On 01/10/2012 08:35 AM, Endi Sukma Dewata wrote: >> On 1/6/2012 7:50 AM, Petr Vobornik wrote: >>> 1) you are calling krbtpolicy-show without any user specific information >>> so it always get the global policy. It should be call with an user >>> argument. >> >> Fixed. Right now it's read only. I think we should provide an interface >> to edit the Kerberos ticket policy for each user, but I don't think it's >> as simple as making the fields editable because there are 2 operations >> that we need to support: Update (krbtpolicy-mod) and Reset >> (krbtpolicy-reset). The krbtpolicy-mod probably can be called together >> with user-mod when we click Update, but we need a new button for the >> Reset operation because it's completely different than the details >> facet's Reset button. > > I wouldn't modify it there too. Maybe the original ticket (new facet) > wasn't a bad idea. But for reading this implementation is really fine. > >> >>> Minor: >>> 2) Why not call pwpolicy-show --user=user_login instead of getting the >>> policy's name from dn? >> >> Fixed. The password policy is intentionally made read only because the >> policy belongs to the group, not the user. If we make it editable it >> might confuse the admin into thinking that he's changing the policy for >> the user only whereas he's actually changing the policy for the whole >> group. > > Agree > >> We might be able to show the password policy in group details >> page too, but I'm not sure if it's necessary. > > We will see if some user will want it. > >> >>> Combining 1), 2) and user-show will allow to get all necessary >>> information for the facet in a single batch at refresh. >> >> This will be done in the next patch. >> > ACK and pushed to master > pushed to ipa-2-2 From rcritten at redhat.com Wed Jan 11 20:49:28 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 15:49:28 -0500 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <20120105102130.GE24492@redhat.com> References: <4EE66277.5060409@redhat.com> <1323735307.4413.109.camel@willson.li.ssimo.org> <4EE699B0.1030403@redhat.com> <4EE8F679.1010509@redhat.com> <20111214192250.GA11084@redhat.com> <4F04B271.1010101@redhat.com> <20120105102130.GE24492@redhat.com> Message-ID: <4F0DF5D8.4000102@redhat.com> Alexander Bokovoy wrote: > On Wed, 04 Jan 2012, Rob Crittenden wrote: >>>> + parser.add_option('--delegate', action='store_true', >>>> + help='Delegate the TGT to the IPA server', >>>> + ) >>> >>> Otherwise ACK. >>> >> >> Updated both patches. The first (914) to address Alexander's >> concern. The second to add a new global lock directive. I updated >> the mod_auth_kerb patch based on feedback from the package >> maintainer. > I'm testing both patches. Unfortunately, there is no mod_auth_kerb > option KrbConstrainedDelegationLock in the mod_auth_kerb 5.4-8 that > you have provided. SourceForge is broken these days and I can't access > anything on mod_auth_kerb upstream to verify if their development tree > contains support for the option. > > I have disabled KrbConstrainedDelegationLock for time being. > > Other than that all works for me. pushed to ipa-2-2 and master rob From simo at redhat.com Wed Jan 11 22:14:12 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jan 2012 17:14:12 -0500 Subject: [Freeipa-devel] [PATCH] disable depoendencies on samba4-libs in v2.2 Message-ID: <1326320052.30661.375.camel@willson.li.ssimo.org> Build fixes to avoid dependency on samba4 packages, that work is going into 3.0 Ticket #2244 Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-2.2-simo-1-Disable-MS-PAC-handling-in-2.2.patch Type: text/x-patch Size: 4786 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 11 22:29:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 17:29:59 -0500 Subject: [Freeipa-devel] [PATCH] #2169 Fix PAC Validation In-Reply-To: <1323312262.16138.55.camel@willson.li.ssimo.org> References: <1323312262.16138.55.camel@willson.li.ssimo.org> Message-ID: <4F0E0D67.3070604@redhat.com> Simo Sorce wrote: > > PAC Validation was not correct for all cases. > > In order to test this patch you must use the krb5 packages in the > ipa-devel repo as they contains some patches that were necessary to fix > various issues with s4u2proxy cases including PAC verification. > > Fixes 2169 > > Simo. ACK From rcritten at redhat.com Wed Jan 11 22:30:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jan 2012 17:30:09 -0500 Subject: [Freeipa-devel] [PATCH] #2170 Properly sign PACs In-Reply-To: <1323312383.16138.57.camel@willson.li.ssimo.org> References: <1323312383.16138.57.camel@willson.li.ssimo.org> Message-ID: <4F0E0D71.2080603@redhat.com> Simo Sorce wrote: > > The PAC signing code would fail to add the correct KDC checksum in the > cross-realm TGT case. This was discovered while investigating s4u2proxy > issues. > > This patch is dependent on patch 472 for ticket #2169 > > Fixes #2170 > > Simo. ACK From simo at redhat.com Wed Jan 11 22:42:26 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jan 2012 17:42:26 -0500 Subject: [Freeipa-devel] [PATCH] #2169 Fix PAC Validation In-Reply-To: <4F0E0D67.3070604@redhat.com> References: <1323312262.16138.55.camel@willson.li.ssimo.org> <4F0E0D67.3070604@redhat.com> Message-ID: <1326321746.30661.376.camel@willson.li.ssimo.org> On Wed, 2012-01-11 at 17:29 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > > > PAC Validation was not correct for all cases. > > > > In order to test this patch you must use the krb5 packages in the > > ipa-devel repo as they contains some patches that were necessary to fix > > various issues with s4u2proxy cases including PAC verification. > > > > Fixes 2169 > > > > Simo. > > ACK Pushed to master. Also pushed to ipa-2-2 to maintain the code in sync even though this code will be disabled there. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jan 11 22:42:27 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jan 2012 17:42:27 -0500 Subject: [Freeipa-devel] [PATCH] #2170 Properly sign PACs In-Reply-To: <4F0E0D71.2080603@redhat.com> References: <1323312383.16138.57.camel@willson.li.ssimo.org> <4F0E0D71.2080603@redhat.com> Message-ID: <1326321747.30661.377.camel@willson.li.ssimo.org> On Wed, 2012-01-11 at 17:30 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > > > The PAC signing code would fail to add the correct KDC checksum in the > > cross-realm TGT case. This was discovered while investigating s4u2proxy > > issues. > > > > This patch is dependent on patch 472 for ticket #2169 > > > > Fixes #2170 > > > > Simo. > > ACK > Pushed to master. Also pushed to ipa-2-2 to maintain the code in sync even though this code will be disabled there. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Jan 11 22:48:47 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Jan 2012 17:48:47 -0500 Subject: [Freeipa-devel] New Devel branch 2.2 In-Reply-To: <1326310332.30661.368.camel@willson.li.ssimo.org> References: <1326310332.30661.368.camel@willson.li.ssimo.org> Message-ID: <4F0E11CF.1020207@redhat.com> On 01/11/2012 02:32 PM, Simo Sorce wrote: > Hello fellow developers, > > The Hunting Season for version 2.2 is officially open. > > I have just pushed the ipa-2-2 branch into the upstream git tree. > The current version is set to 2.1.90 and will go up from there until we > are ready to release FreeIPA version 2.2.0 > > The 2.1 branch is now officially closed to development and only patches > for major defects or security issues should be pushed there. > > The 2.2 branch has more than 200 patches backported from master which is > still marching towards the 3.0 release. The 2.2 branch is meant to > provide a number of features we wanted to initially defer to 3.0, but > finally decided to release earlier in the 2.x series. > > This means you have to be careful about which patches should be > committed to both trees and which shouldn't. > > > Have fun! > > Simo. > This overrides previous decision not to release on the 2.x branch and move everything to 3.0 only. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jhrozek at redhat.com Thu Jan 12 00:11:57 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 12 Jan 2012 01:11:57 +0100 Subject: [Freeipa-devel] [SSSD] New SSSD FAQ page in the works In-Reply-To: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> References: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <20120112001157.GA16893@hendrix.redhat.com> On Tue, Jan 10, 2012 at 02:31:51PM -0500, Stephen Gallagher wrote: > It's come up more than once that SSSD needs a Frequently Asked Questions > page to field some of our more common questions. I'm reaching out to the > SSSD and FreeIPA user and developer communities to help us flesh out > this page. > > I've begun it with the two most common questions I've received lately, > as well as a basic primer on enabling debug logging to help identify > issues. > > I'd like some additional suggestions on what questions should be > answered on that page, as well as opening the page to volunteer-edits to > add answers to any questions they may have had and solved (or enlisted > aid in solving) in the past. > I'm not sure if the FAQ is the right place, but I couldn't find any place on the wiki that would explain what an LTM release is. I know that some people are struggling with the differences between RFC2307 and RFC2307bis schema. I wonder if we should include that in the FAQ, too, even though it is explained in the manual pages. I also think that the last paragraph in the "Troubleshooting" section should include a link that would tell how to contact the community for further assistance. From mkosek at redhat.com Thu Jan 12 10:10:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Jan 2012 11:10:14 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 182 Create per-type DNS API based on options In-Reply-To: <4F0DEE12.2020306@redhat.com> References: <1324482381.11925.16.camel@balmora.brq.redhat.com> <1325867995.2159.26.camel@priserak> <4F0DEE12.2020306@redhat.com> Message-ID: <1326363014.21013.35.camel@balmora.brq.redhat.com> On Wed, 2012-01-11 at 15:16 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2011-12-21 at 16:46 +0100, Martin Kosek wrote: > >> This is a fully functional prototype of the new DNS API based on new > >> options instead of new commands. It still has rough edges (missing > >> tests, extended help) but should give a very good picture about the new > >> API and provide a base for WebUI guys. > >> > >> ------- > >> Use new structured DNSRecord parameters to generate per-type API > >> for all supported DNS RR types. This should help significantly > >> the end-user with manipulating complex DNS record type (MX, LOC, > >> etc.). > >> > >> All enhancements are integrated to current DNS record commands: > >> > >> 1) dnsrecord-add > >> - Records can be either entered as a raw value (e.g. --mx-rec= > >> "1 srv1.example.com" for MX record) or per-part: > >> --mx-preference=1 --mx-exchanger=srv1.example.com > >> - CLI interactive help behavior was changed. It will ask for > >> a record type and then ask for all DNS record part values > >> (e.g. MX Preference value, MX Exchanger value). > >> > >> 2) dnsrecord-mod > >> - This command can now operate in 2 modes. When only a raw DNS > >> record is entered (e.g. --mx-rec="1 srv1.example.com") it > >> operates in standard mode and replaces any previous mxrecord > >> value with the --mx-rec value. > >> > >> When any structured parameter (e.g. --mx-preference) is passed > >> it modifies just the specified parts of one mxrecord value > >> referred by --mx-rec: > >> --mx-rec="1 srv1.example.com" --mx-preference=2 > >> - New interactive help has been implemented. It will ask for a > >> record to be modified (in the same manner as dnsrecord-del) > >> and then let user change DNS record part(s) for chosen > >> records. > >> > >> 3) All dnsrecord-* commands have now --structured option > >> - When this option is passed, instead of displaying raw DNS values > >> all DNS records are parsed and displayed per-part. Example: > >> > >> $ ipa dnsrecord-show example.com @ --structured > >> Record name: @ > >> Records: > >> Record type: MX > >> Record data: 0 server1.example.com. > >> MX Preference: 0 > >> MX Exchanger: server1.example.com. > >> > >> Record type: NS > >> Record data: ns1.example.com. > >> NS Hostname: ns1.example.com. > >> > >> All API changes are compatible with clients without this patch. > >> > >> https://fedorahosted.org/freeipa/ticket/2082 > >> > >> ------------------------------------------------ > >> A little demonstration of the new API capabilities: > >> > >> #### New help with option groups for per-type options > >> # ipa dnsrecord-add --help > >> Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] > >> > >> Options: > >> ... > >> --structured Parse all raw DNS records and return them in a > >> structured way > >> ... > >> A Record: > >> --a-rec=ARECORD Comma-separated list of raw A records > >> --a-ip-address=STR IP Address > >> > >> AAAA Record: > >> --aaaa-rec=AAAARECORD > >> Comma-separated list of raw AAAA records > >> --aaaa-ip-address=STR > >> IP Address > >> ... > >> MX Record: > >> --mx-rec=MXRECORD Comma-separated list of raw MX records > >> --mx-preference=INT > >> Preference given to this exchanger. Lower values > >> are > >> more preferred > >> --mx-exchanger=STR A host willing to act as a mail exchanger > >> > >> #### Standard dnsrecord-add > >> # ipa dnsrecord-add example.com server1 --a-rec=10.0.0.1 > >> Record name: server1 > >> A record: 10.0.0.1 > >> > >> #### New interactive help for dnsrecord-add > >> # ipa dnsrecord-add example.com server1 > >> Please choose a type of DNS resource record to be added > >> The most common types for this type of zone are: A, AAAA > >> > >> DNS resource record type: AAAA > >> AAAA IP Address: 2001:db8::1428:57ab > >> Record name: server1 > >> A record: 10.0.0.1 > >> AAAA record: 2001:db8::1428:57ab > >> > >> # ipa dnsrecord-add example.com @ > >> Please choose a type of DNS resource record to be added > >> The most common types for this type of zone are: NS, MX, LOC > >> > >> DNS resource record type: MX > >> MX Preference: 0 > >> MX Exchanger: server1.example.com. > >> Record name: example.com > >> MX record: 0 server1.example.com. > >> NS record: vm-068.idm.lab.bos.redhat.com. > >> > >> #### Old-stype mod command > >> # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." > >> Record name: example.com > >> MX record: 1 server1.example.com. > >> NS record: vm-068.idm.lab.bos.redhat.com. > >> > >> #### Modification via new structured options: > >> # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." --mx-preference=2 > >> Record name: example.com > >> MX record: 2 server1.example.com. > >> NS record: vm-068.idm.lab.bos.redhat.com. > >> > >> #### Modification via new interactive help: > >> # ipa dnsrecord-mod example.com @ > >> No option to modify specific record provided. > >> Current DNS record contents: > >> > >> MX record: 2 server1.example.com. > >> NS record: vm-068.idm.lab.bos.redhat.com. > >> > >> Modify MX record '2 server1.example.com.'? Yes/No (default No): y > >> MX Preference [2]: 3 > >> MX Exchanger [server1.example.com.]: > >> Modify NS record 'vm-068.idm.lab.bos.redhat.com.'? Yes/No (default No): > >> Record name: example.com > >> MX record: 3 server1.example.com. > >> NS record: vm-068.idm.lab.bos.redhat.com. > >> > >> #### Example of use of --structured option (this will be useful for WebUI): > >> # ipa dnsrecord-show example.com @ --structured > >> Record name: @ > >> Records: > >> Record type: MX > >> Record data: 3 server1.example.com. > >> MX Preference: 3 > >> MX Exchanger: server1.example.com. > >> > >> Record type: NS > >> Record data: vm-068.idm.lab.bos.redhat.com. > >> NS Hostname: vm-068.idm.lab.bos.redhat.com. > >> > >> #### dnsrecord-del works in the same way as the old one: > >> # ipa dnsrecord-del example.com server1 > >> No option to delete specific record provided. > >> Delete all? Yes/No (default No): > >> Current DNS record contents: > >> > >> AAAA record: 2001:db8::1428:57ab > >> A record: 10.0.0.1 > >> > >> Delete AAAA record '2001:db8::1428:57ab'? Yes/No (default No): y > >> Delete A record '10.0.0.1'? Yes/No (default No): > >> Record name: server1 > >> A record: 10.0.0.1 > > > > I prepared a rebased version of the patch set for easier review. There > > are few changes: > > - DNS module was extended to mention new interactive modes and options > > - one bug in dnsrecord-mod interactive mode was fixed - only one value > > per DNS type can be modified at one time > > - all translatable strings in DNS module with more than one placeholder > > were converted to dict format > > > > Martin Rob, thanks for the review! I am glad that this new API effort was successful. > > Just fix these few things before pushing, otherwise ACK x 4: > > - Add continuation \\ to the example "Add new reverse zone specified by > network IP address:" Fixed. > - Bump VERSION so it applies cleanly against master Fixed. > - This is probably not an issue since the older clients won't have this > updated help, but this example does not work on older clients: > > # ipa dnsrecord-add example.com @ --mx-preference=20 --mx-exchanger=mail2 > Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] > > ipa: error: no such option: --mx-preference Yes, this is OK since the older clients because their help or --help does not offer these new options. > > Something to consider outside the scope of this patch is now that we > have option groups, break out the standard options into groups. I'm > thinking about things like output (--all, --raw, --structured), direct > attribute modification (--addattr, --setattr, --delattr) and > command-specific. Some balance would be required to not bloat the help > too much but this kind of clarity has been requested for a while. Good idea. I have created a ticket for this purpose and scheduled it for February: https://fedorahosted.org/freeipa/ticket/2254 > > This functionality is really good. I'm sure the full rewrites and weeks > of back and forth have been a drag but the end product is very nice. > > Great work. > > rob Thanks! Pushed to master, ipa-2-2. Martin From abokovoy at redhat.com Thu Jan 12 13:49:46 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 12 Jan 2012 15:49:46 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <4EEA6410.2030803@redhat.com> References: <20111114093243.GA312@redhat.com> <4ED8F15B.7060602@redhat.com> <20111207114948.GA32281@redhat.com> <4EE67E9C.9080805@redhat.com> <20111212225535.GE9668@redhat.com> <4EEA6410.2030803@redhat.com> Message-ID: <20120112134946.GA7380@redhat.com> On Thu, 15 Dec 2011, Rob Crittenden wrote: > >If this is acceptable, I can do refactoring in a different ticket. > > NACK. > > We still have the value passed in by the user, right (in > options['user'] and options['group'])? We basically take that, > create a DN out of it, then pull the same value out. Why not skip > all that and just look at the raw values instead? > > Or there is already a helper to get the key out of a dn, see > self.Object.user.get_primary_key_from_dn(str(group)) > > Also, I found this doesn't handle a list of users or groups. If you > pass in --users=joe,all then both get added as external users > (assuming joe doesn't already exist, of course). Refactored the patch using original values from options[]: $ ipa sudorule-add-runasuser testr --group=all ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a group name $ ipa sudorule-add-runasuser testr --group=admins,all ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a group name $ ipa sudorule-add-runasuser testr --user=admin,all ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a user name $ ipa sudorule-add-runasgroup testr --group=admin,all ipa: ERROR: invalid 'runas-group': RunAsGroup does not accept 'all' as a group name Accepts a single value or a list. This is a patch against master (should apply to ipa-2-2 w/o issues). -- / Alexander Bokovoy -------------- next part -------------- >From 9b11875d84b341220e299560671551d3c538f20a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 14 Nov 2011 11:23:19 +0200 Subject: [PATCH] Validate sudo RunAsUser/RunAsGroup arguments FreeIPA SUDO rules use --usercat/--groupcat to specify that rule applies to all users or groups. Thus, sudorule-add-runasuser and sudorule-add-runasgroup accept specific groups and users and do not accept ALL reserved word. The patch validates user and group passed to these commands and reports appropriate errors when these are ALL. Ticket #1496 https://fedorahosted.org/freeipa/ticket/1496 --- ipalib/plugins/sudorule.py | 39 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 38 insertions(+), 1 deletions(-) diff --git a/ipalib/plugins/sudorule.py b/ipalib/plugins/sudorule.py index 93ca03f0170d922b91eff45ec2f42871336973f1..65a1d8541cd52c89e7fcb7b70adccf73490bdcbc 100644 --- a/ipalib/plugins/sudorule.py +++ b/ipalib/plugins/sudorule.py @@ -472,13 +472,34 @@ class sudorule_remove_host(LDAPRemoveMember): api.register(sudorule_remove_host) - class sudorule_add_runasuser(LDAPAddMember): __doc__ = _('Add users and groups for Sudo to execute as.') member_attributes = ['ipasudorunas'] member_count_out = ('%i object added.', '%i objects added.') + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + def check_validity(runas): + v = unicode(runas) + if v.upper() == u'ALL': + return False + return True + + if 'user' in options: + for name in options['user']: + if not check_validity(name): + raise errors.ValidationError(name='runas-user', + error=unicode(_("RunAsUser does not accept '%(name)s' as a user name")) % + dict(name=name)) + if 'group' in options: + for name in options['group']: + if not check_validity(name): + raise errors.ValidationError(name='runas-user', + error=unicode(_("RunAsUser does not accept '%(name)s' as a group name")) % + dict(name=name)) + + return dn + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): completed_external = 0 # Sift through the user failures. We assume that these are all @@ -547,6 +568,22 @@ class sudorule_add_runasgroup(LDAPAddMember): member_attributes = ['ipasudorunasgroup'] member_count_out = ('%i object added.', '%i objects added.') + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + def check_validity(runas): + v = unicode(runas) + if v.upper() == u'ALL': + return False + return True + + if 'group' in options: + for name in options['group']: + if not check_validity(name): + raise errors.ValidationError(name='runas-group', + error=unicode(_("RunAsGroup does not accept '%(name)s' as a group name")) % + dict(name=name)) + + return dn + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): completed_external = 0 # Sift through the group failures. We assume that these are all -- 1.7.8.2 From rcritten at redhat.com Thu Jan 12 14:19:45 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 09:19:45 -0500 Subject: [Freeipa-devel] [PATCH] disable depoendencies on samba4-libs in v2.2 In-Reply-To: <1326320052.30661.375.camel@willson.li.ssimo.org> References: <1326320052.30661.375.camel@willson.li.ssimo.org> Message-ID: <4F0EEC01.1040709@redhat.com> Simo Sorce wrote: > Build fixes to avoid dependency on samba4 packages, > that work is going into 3.0 > > Ticket #2244 > > Simo. ACK From simo at redhat.com Thu Jan 12 14:26:54 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jan 2012 09:26:54 -0500 Subject: [Freeipa-devel] [PATCH] disable depoendencies on samba4-libs in v2.2 In-Reply-To: <4F0EEC01.1040709@redhat.com> References: <1326320052.30661.375.camel@willson.li.ssimo.org> <4F0EEC01.1040709@redhat.com> Message-ID: <1326378414.4737.0.camel@willson.li.ssimo.org> On Thu, 2012-01-12 at 09:19 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > Build fixes to avoid dependency on samba4 packages, > > that work is going into 3.0 > > > > Ticket #2244 > > > > Simo. > > ACK Thanks, pushed to ipa-2-2 Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Jan 12 16:18:16 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Jan 2012 17:18:16 +0100 Subject: [Freeipa-devel] [PATCH] 191 Fix maxvalue in DNS plugin Message-ID: <1326385096.21013.37.camel@balmora.brq.redhat.com> This bug prevented a build on 32b systems. Pushed as a one-liner to master, ipa-2-2. --- Having a Parameter maxvalue larger that 2G makes Python convert it to "long" type instead of "int" type. Our framework than fails to bootstrap the API when it detects long integer in Parameter maxvalue. Remove the clashing maxvalue out entirely as we can't transfer values larger than 2G anyway (xmlrpc limitation). https://fedorahosted.org/freeipa/ticket/2082 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-191-fix-maxvalue-in-dns-plugin.patch Type: text/x-patch Size: 12419 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 12 17:56:39 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 12 Jan 2012 11:56:39 -0600 Subject: [Freeipa-devel] [PATCH] 339 Fixed problem removing automount keys and DNS records. Message-ID: <4F0F1ED7.5040109@redhat.com> Due to a recent change the deleting automount keys and DNS records no longer worked. The functions that are supposed to get the selected values has been fixed to use the correct names and element type. They also have been converted into methods of the search facets. Ticket #2256 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0339-Fixed-problem-removing-automount-keys-and-DNS-record.patch Type: text/x-patch Size: 6695 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 12 22:36:24 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 17:36:24 -0500 Subject: [Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance In-Reply-To: <4EE90D98.6030900@redhat.com> References: <4EE90D98.6030900@redhat.com> Message-ID: <4F0F6068.9000602@redhat.com> John Dennis wrote: > This patch adds an ipa memcached service, it does the following: > > * adds SysV initscript for ipa_memcached > > * adds systemd service file for ipa_memcached > > * adds tmpfiles.d configuration file for /var/run/ipa_memcached > > * adds configuration file for ipa_memcached > > * adds memcacheinstance.py file to create service instance during server > install > > * invokes installation of ipa_memcached during ipa-server-install > > * adds dependencies to spec file > > * adds ipa_memcached to ipactl service control The conditionals for > F15 are probably not needed in the spec. Not worth a NACK on its own. Do we need to create /var/run/ipa_memcached/ ourselves? If the answer is no then ACK. rob From rcritten at redhat.com Thu Jan 12 22:37:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 17:37:21 -0500 Subject: [Freeipa-devel] [PATCH 60] Implement session support in server, Manage sessions in WSGI In-Reply-To: <4EE90EA8.5020803@redhat.com> References: <4EE90EA8.5020803@redhat.com> Message-ID: <4F0F60A1.4080206@redhat.com> John Dennis wrote: > This patch adds the ipalib/session.py file which implements a cookie > based session cache using memcached. > > It also invokes the session cookie support when a HTTP request is > received and stores the session data in the per-thread context object. > ACK. It might be handy to have a way to get the cache stats and potentially drop a given entry. Something to think about for the future. rob From rcritten at redhat.com Thu Jan 12 22:39:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 17:39:16 -0500 Subject: [Freeipa-devel] [PATCH] 185-188 Let replicas install without DNS In-Reply-To: <1325836751.2159.11.camel@priserak> References: <1325705910.2136.13.camel@priserak> <4F0617D5.4070203@redhat.com> <1325836751.2159.11.camel@priserak> Message-ID: <4F0F6114.3060104@redhat.com> Martin Kosek wrote: > On Thu, 2012-01-05 at 16:36 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Patches 185-186 are needed to make ipa-replica-install run without >>> crashes. >>> >>> How to test: >>> >>> on server: >>> 1) install the server (ipa.example.com is not resolvable) >>> # ipa-server-install -p kokos123 -a kokos123 --no-host-dns >>> --hostname=ipa.example.com >>> >>> 2) Add a record for replica.example.com to /etc/hosts >>> 3) Prepare the replica (without 188 it refuses to create the replica >>> file) >>> # ipa-replica-prepare replica.example.com >>> >>> on replica: >>> 1) Add a record for ipa.example.com to /etc/hosts >>> 2) Install replica (replica.example.com is not resolvable) >>> # ipa-replica-install --no-host-dns --ip-address=IP_ADDRESS REPLICA_FILE >>> >>> The installer now use IP_ADDRESS to create a record /etc/hosts and make >>> the replica resolvable >>> >>> ---- >>> Let ipa-replica-prepare and ipa-replica-install work without >>> proper DNS records as records in /etc/hosts are sufficient for >>> DS replication. >>> >>> 1) ipa-replica-prepare now just checks if the replica hostname >>> is resolvable (DNS records are not required). It is now able >>> to prepare a replica file even when the replica IP address is >>> present in /etc/hosts only. >>> 2) ipa-replica-install is now able to proceed when the hostname >>> is not resolvable. It uses an IP address passed in a new >>> option --ip-address to create a record in /etc/hosts in the >>> same way as ipa-server-install does. >>> >>> https://fedorahosted.org/freeipa/ticket/2139 >> >> NACK on patch 185. The exceptions need to be changed to catch >> DuplicateEntry instead of ALREADY_EXISTS >> >> Otherwise looks ok. >> >> rob > > Good catch, Rob! Attaching an updated set of patches. > > Martin ACK all around. rob From jdennis at redhat.com Thu Jan 12 23:15:36 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 12 Jan 2012 18:15:36 -0500 Subject: [Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance In-Reply-To: <4F0F6068.9000602@redhat.com> References: <4EE90D98.6030900@redhat.com> <4F0F6068.9000602@redhat.com> Message-ID: <4F0F6998.8020507@redhat.com> On 01/12/2012 05:36 PM, Rob Crittenden wrote: > John Dennis wrote: >> This patch adds an ipa memcached service, it does the following: >> >> * adds SysV initscript for ipa_memcached >> >> * adds systemd service file for ipa_memcached >> >> * adds tmpfiles.d configuration file for /var/run/ipa_memcached >> >> * adds configuration file for ipa_memcached >> >> * adds memcacheinstance.py file to create service instance during server >> install >> >> * invokes installation of ipa_memcached during ipa-server-install >> >> * adds dependencies to spec file >> >> * adds ipa_memcached to ipactl service control > > The conditionals for> F15 are probably not needed in the spec. Not > worth a NACK on its own. Because we'll never deploy < f16? Or because you believe there is a version issue not properly addressed? > > Do we need to create /var/run/ipa_memcached/ ourselves? > > If the answer is no then ACK. Not sure I understand the question because the spec file does create /var/run/ipa_memcached and that directory must exist. Upon reboot it is recreated because of the tmpfiles configuration in /etc/tmpfiles.d/ipa.conf for >= f15. What is your concern? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Jan 12 23:19:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 18:19:13 -0500 Subject: [Freeipa-devel] [PATCH] 922 document ping plugin Message-ID: <4F0F6A71.5020209@redhat.com> Add some documentation to the ping plugin. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-922-ping.patch Type: text/x-diff Size: 1661 bytes Desc: not available URL: From jdennis at redhat.com Thu Jan 12 23:20:51 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 12 Jan 2012 18:20:51 -0500 Subject: [Freeipa-devel] [PATCH 60] Implement session support in server, Manage sessions in WSGI In-Reply-To: <4F0F60A1.4080206@redhat.com> References: <4EE90EA8.5020803@redhat.com> <4F0F60A1.4080206@redhat.com> Message-ID: <4F0F6AD3.2010703@redhat.com> On 01/12/2012 05:37 PM, Rob Crittenden wrote: > John Dennis wrote: >> This patch adds the ipalib/session.py file which implements a cookie >> based session cache using memcached. >> >> It also invokes the session cookie support when a HTTP request is >> received and stores the session data in the per-thread context object. >> > > ACK. > > It might be handy to have a way to get the cache stats and potentially > drop a given entry. Something to think about for the future. It's trival to get the cache stats on the server: import ipalib.session print session_mgr.get_server_statistics() Or do you mean get the stats as an ipa command? The next patch which will follow in a little bit does include a method to delete a cache entry, that's used when a ticket expires. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Thu Jan 12 23:27:41 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jan 2012 18:27:41 -0500 Subject: [Freeipa-devel] [PATCH] 922 document ping plugin In-Reply-To: <4F0F6A71.5020209@redhat.com> References: <4F0F6A71.5020209@redhat.com> Message-ID: <1326410861.4737.22.camel@willson.li.ssimo.org> On Thu, 2012-01-12 at 18:19 -0500, Rob Crittenden wrote: > Add some documentation to the ping plugin. ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jan 12 23:32:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 18:32:20 -0500 Subject: [Freeipa-devel] [PATCH] 923 catch ipa-managed-entries exception Message-ID: <4F0F6D84.30409@redhat.com> If for some reason the managed entries definitions don't exist ipa-managed-entries -l will raise a nasty traceback. This will catch it and show a error. I think this was caused by a past update problem. I don't think it is an issue any more but it is worthwhile to add a try/except around this search. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-923-exception.patch Type: text/x-diff Size: 1475 bytes Desc: not available URL: From simo at redhat.com Thu Jan 12 23:35:32 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jan 2012 18:35:32 -0500 Subject: [Freeipa-devel] [PATCH] 923 catch ipa-managed-entries exception In-Reply-To: <4F0F6D84.30409@redhat.com> References: <4F0F6D84.30409@redhat.com> Message-ID: <1326411332.4737.23.camel@willson.li.ssimo.org> On Thu, 2012-01-12 at 18:32 -0500, Rob Crittenden wrote: > If for some reason the managed entries definitions don't exist > ipa-managed-entries -l will raise a nasty traceback. This will catch > it > and show a error. > > I think this was caused by a past update problem. I don't think it is > an > issue any more but it is worthwhile to add a try/except around this > search. ACK Simo. > -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Fri Jan 13 02:03:30 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 12 Jan 2012 21:03:30 -0500 Subject: [Freeipa-devel] [PATCH 61] Cache authentication in session Message-ID: <4F0F90F2.40403@redhat.com> -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0061-Cache-authentication-in-session.patch Type: text/x-patch Size: 68482 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 13 03:36:52 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 22:36:52 -0500 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <20120112134946.GA7380@redhat.com> References: <20111114093243.GA312@redhat.com> <4ED8F15B.7060602@redhat.com> <20111207114948.GA32281@redhat.com> <4EE67E9C.9080805@redhat.com> <20111212225535.GE9668@redhat.com> <4EEA6410.2030803@redhat.com> <20120112134946.GA7380@redhat.com> Message-ID: <4F0FA6D4.7060309@redhat.com> Alexander Bokovoy wrote: > On Thu, 15 Dec 2011, Rob Crittenden wrote: >>> If this is acceptable, I can do refactoring in a different ticket. >> >> NACK. >> >> We still have the value passed in by the user, right (in >> options['user'] and options['group'])? We basically take that, >> create a DN out of it, then pull the same value out. Why not skip >> all that and just look at the raw values instead? >> >> Or there is already a helper to get the key out of a dn, see >> self.Object.user.get_primary_key_from_dn(str(group)) >> >> Also, I found this doesn't handle a list of users or groups. If you >> pass in --users=joe,all then both get added as external users >> (assuming joe doesn't already exist, of course). > Refactored the patch using original values from options[]: > > $ ipa sudorule-add-runasuser testr --group=all > ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a group name > $ ipa sudorule-add-runasuser testr --group=admins,all > ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a group name > $ ipa sudorule-add-runasuser testr --user=admin,all > ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a user name > $ ipa sudorule-add-runasgroup testr --group=admin,all > ipa: ERROR: invalid 'runas-group': RunAsGroup does not accept 'all' as a group name > > Accepts a single value or a list. > > This is a patch against master (should apply to ipa-2-2 w/o issues). Tested in 2-2, works fine. ACK. rob From rcritten at redhat.com Fri Jan 13 03:47:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 22:47:29 -0500 Subject: [Freeipa-devel] [PATCH] 180 Add missing --pkey-only option for selfservice and In-Reply-To: <1325494003.2265.11.camel@priserak> References: <1323445643.7177.45.camel@balmora.brq.redhat.com> <4EE2B6D6.90301@redhat.com> <1325494003.2265.11.camel@priserak> Message-ID: <4F0FA951.9050506@redhat.com> Martin Kosek wrote: > On Fri, 2011-12-09 at 19:33 -0600, Endi Sukma Dewata wrote: >> On 12/9/2011 9:47 AM, Martin Kosek wrote: >>> pkey-only functionality has to be implemented separately for these >>> modules as they are based on crud.Search instead of standard >>> LDAPSearch. >>> >>> Delegation commands were modified in the process to allow ACIs >>> without 'memberof' as delegation ACIs. This check is no longer >>> needed since delegation ACI prefixe ensures the ACI type. >>> >>> https://fedorahosted.org/freeipa/ticket/2092 >> >> From UI perspective this is ACKed. I'm sending a patch to enable paging >> on these pages. >> > > Thanks for the UI review Endi. If there are no objections from server > people too we can push this. > > A rebased version for current master is attached. > > Martin The delegation tests fail with creation. Here is what it looks like from the cli. # ipa delegation-add --attrs=street,c,l,st,postalcode --group=editors --permissions=write --membergroup=admins delegation1 ipa: ERROR: Delegation 'delegation1' not found rob From rcritten at redhat.com Fri Jan 13 03:53:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 22:53:02 -0500 Subject: [Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance In-Reply-To: <4F0F6998.8020507@redhat.com> References: <4EE90D98.6030900@redhat.com> <4F0F6068.9000602@redhat.com> <4F0F6998.8020507@redhat.com> Message-ID: <4F0FAA9E.1080601@redhat.com> John Dennis wrote: > On 01/12/2012 05:36 PM, Rob Crittenden wrote: >> John Dennis wrote: >>> This patch adds an ipa memcached service, it does the following: >>> >>> * adds SysV initscript for ipa_memcached >>> >>> * adds systemd service file for ipa_memcached >>> >>> * adds tmpfiles.d configuration file for /var/run/ipa_memcached >>> >>> * adds configuration file for ipa_memcached >>> >>> * adds memcacheinstance.py file to create service instance during server >>> install >>> >>> * invokes installation of ipa_memcached during ipa-server-install >>> >>> * adds dependencies to spec file >>> >>> * adds ipa_memcached to ipactl service control >> >> The conditionals for> F15 are probably not needed in the spec. Not >> worth a NACK on its own. > > Because we'll never deploy < f16? Or because you believe there is a > version issue not properly addressed? Because we would never deploy on < F15 (and more likely F16). Can't argue with the clarity that this stuff only works on F15+. >> >> Do we need to create /var/run/ipa_memcached/ ourselves? >> >> If the answer is no then ACK. > > Not sure I understand the question because the spec file does create > /var/run/ipa_memcached and that directory must exist. Upon reboot it is > recreated because of the tmpfiles configuration in > /etc/tmpfiles.d/ipa.conf for >= f15. What is your concern? I don't see it being created in the spec file: $ grep ipa_memcached /tmp/freeipa-jdennis-0059-Modify-spec-file-to-add-ipa_memcached-service.patch | grep mkdir rob From rcritten at redhat.com Fri Jan 13 03:55:17 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 22:55:17 -0500 Subject: [Freeipa-devel] [PATCH] 922 document ping plugin In-Reply-To: <1326410861.4737.22.camel@willson.li.ssimo.org> References: <4F0F6A71.5020209@redhat.com> <1326410861.4737.22.camel@willson.li.ssimo.org> Message-ID: <4F0FAB25.3030208@redhat.com> Simo Sorce wrote: > On Thu, 2012-01-12 at 18:19 -0500, Rob Crittenden wrote: >> Add some documentation to the ping plugin. > > ACK > > Simo. > pushed to master and ipa-2-2 From rcritten at redhat.com Fri Jan 13 03:55:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2012 22:55:31 -0500 Subject: [Freeipa-devel] [PATCH] 923 catch ipa-managed-entries exception In-Reply-To: <1326411332.4737.23.camel@willson.li.ssimo.org> References: <4F0F6D84.30409@redhat.com> <1326411332.4737.23.camel@willson.li.ssimo.org> Message-ID: <4F0FAB33.3040209@redhat.com> Simo Sorce wrote: > On Thu, 2012-01-12 at 18:32 -0500, Rob Crittenden wrote: >> If for some reason the managed entries definitions don't exist >> ipa-managed-entries -l will raise a nasty traceback. This will catch >> it >> and show a error. >> >> I think this was caused by a past update problem. I don't think it is >> an >> issue any more but it is worthwhile to add a try/except around this >> search. > > ACK > > Simo. >> pushed to master and ipa-2-2 From mkosek at redhat.com Fri Jan 13 08:36:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jan 2012 09:36:53 +0100 Subject: [Freeipa-devel] [PATCH] 185-188 Let replicas install without DNS In-Reply-To: <4F0F6114.3060104@redhat.com> References: <1325705910.2136.13.camel@priserak> <4F0617D5.4070203@redhat.com> <1325836751.2159.11.camel@priserak> <4F0F6114.3060104@redhat.com> Message-ID: <1326443813.12113.11.camel@priserak> On Thu, 2012-01-12 at 17:39 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-01-05 at 16:36 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> Patches 185-186 are needed to make ipa-replica-install run without > >>> crashes. > >>> > >>> How to test: > >>> > >>> on server: > >>> 1) install the server (ipa.example.com is not resolvable) > >>> # ipa-server-install -p kokos123 -a kokos123 --no-host-dns > >>> --hostname=ipa.example.com > >>> > >>> 2) Add a record for replica.example.com to /etc/hosts > >>> 3) Prepare the replica (without 188 it refuses to create the replica > >>> file) > >>> # ipa-replica-prepare replica.example.com > >>> > >>> on replica: > >>> 1) Add a record for ipa.example.com to /etc/hosts > >>> 2) Install replica (replica.example.com is not resolvable) > >>> # ipa-replica-install --no-host-dns --ip-address=IP_ADDRESS REPLICA_FILE > >>> > >>> The installer now use IP_ADDRESS to create a record /etc/hosts and make > >>> the replica resolvable > >>> > >>> ---- > >>> Let ipa-replica-prepare and ipa-replica-install work without > >>> proper DNS records as records in /etc/hosts are sufficient for > >>> DS replication. > >>> > >>> 1) ipa-replica-prepare now just checks if the replica hostname > >>> is resolvable (DNS records are not required). It is now able > >>> to prepare a replica file even when the replica IP address is > >>> present in /etc/hosts only. > >>> 2) ipa-replica-install is now able to proceed when the hostname > >>> is not resolvable. It uses an IP address passed in a new > >>> option --ip-address to create a record in /etc/hosts in the > >>> same way as ipa-server-install does. > >>> > >>> https://fedorahosted.org/freeipa/ticket/2139 > >> > >> NACK on patch 185. The exceptions need to be changed to catch > >> DuplicateEntry instead of ALREADY_EXISTS > >> > >> Otherwise looks ok. > >> > >> rob > > > > Good catch, Rob! Attaching an updated set of patches. > > > > Martin > > ACK all around. > > rob Pushed to master, ipa-2-2. Martin From abokovoy at redhat.com Fri Jan 13 09:04:23 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Jan 2012 11:04:23 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <4F0FA6D4.7060309@redhat.com> References: <20111114093243.GA312@redhat.com> <4ED8F15B.7060602@redhat.com> <20111207114948.GA32281@redhat.com> <4EE67E9C.9080805@redhat.com> <20111212225535.GE9668@redhat.com> <4EEA6410.2030803@redhat.com> <20120112134946.GA7380@redhat.com> <4F0FA6D4.7060309@redhat.com> Message-ID: <20120113090423.GE7380@redhat.com> On Thu, 12 Jan 2012, Rob Crittenden wrote: > >>(assuming joe doesn't already exist, of course). > >Refactored the patch using original values from options[]: > > > >$ ipa sudorule-add-runasuser testr --group=all > >ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a group name > >$ ipa sudorule-add-runasuser testr --group=admins,all > >ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a group name > >$ ipa sudorule-add-runasuser testr --user=admin,all > >ipa: ERROR: invalid 'runas-user': RunAsUser does not accept 'all' as a user name > >$ ipa sudorule-add-runasgroup testr --group=admin,all > >ipa: ERROR: invalid 'runas-group': RunAsGroup does not accept 'all' as a group name > > > >Accepts a single value or a list. > > > >This is a patch against master (should apply to ipa-2-2 w/o issues). > > Tested in 2-2, works fine. ACK. Pushed to master, ipa-2-2. -- / Alexander Bokovoy From pvoborni at redhat.com Fri Jan 13 14:58:24 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Jan 2012 15:58:24 +0100 Subject: [Freeipa-devel] [PATCH] 068 UI for SELinux user mapping Message-ID: <4F104690.8020508@redhat.com> This patch adds UI for SELinux user mapping. Its design is based on HBAC Rule design. https://fedorahosted.org/freeipa/ticket/2145 Probably some labels and menu position should be changed. Live demo with limited functionality is at http://pvoborni.fedorapeople.org/selinuxusermap/#policy=selinuxusermap&navigation=policy Note: the patch is zipped because it has 760KB (update of metadata .json files) -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0068-UI-for-SELinux-user-mapping.patch.zip Type: application/zip Size: 36027 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 13 15:10:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:10:35 -0500 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <4F0728C1.9010902@redhat.com> References: <4F0728C1.9010902@redhat.com> Message-ID: <4F10496B.6070900@redhat.com> Rob Crittenden wrote: > A bug when creating replication agreements has caused memberOf to be > dropped from the exclusion list. This patch adds a tool that will find > and fix the agreements. It will be run when the package is installed so > end-users should never need to do anything, but it is harmless if run > multiple times. > > rob The wrong list attribute was being updated, this new patch updates nsDS5ReplicatedAttributeList instead of nsDS5ReplicatedAttributeListTotal. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-921-2-fixreplica.patch Type: text/x-diff Size: 11689 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 13 15:11:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:11:03 -0500 Subject: [Freeipa-devel] [PATCH] 475 Fix setup of replication agreements on replicas In-Reply-To: <1325704332.30661.134.camel@willson.li.ssimo.org> References: <1325704332.30661.134.camel@willson.li.ssimo.org> Message-ID: <4F104987.9030002@redhat.com> Simo Sorce wrote: > The work done to create the ipa-csreplica-manage tool introduced a bug > in normal replication agreements setups which caused replicas to not > properly filter out attributes that absoluteley must not be replicated > around. > > This patch should fix the issue. > Trac ticket TBC > > Simo. ACK From simo at redhat.com Fri Jan 13 15:24:09 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Jan 2012 10:24:09 -0500 Subject: [Freeipa-devel] [PATCH] 475 Fix setup of replication agreements on replicas In-Reply-To: <4F104987.9030002@redhat.com> References: <1325704332.30661.134.camel@willson.li.ssimo.org> <4F104987.9030002@redhat.com> Message-ID: <1326468249.10198.31.camel@willson.li.ssimo.org> On Fri, 2012-01-13 at 10:11 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > The work done to create the ipa-csreplica-manage tool introduced a bug > > in normal replication agreements setups which caused replicas to not > > properly filter out attributes that absoluteley must not be replicated > > around. > > > > This patch should fix the issue. > > Trac ticket TBC > > > > Simo. > > ACK Pushed to master, ipa-2-1, ipa-2-2 Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Jan 13 15:28:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:28:15 -0500 Subject: [Freeipa-devel] [PATCH] 190 Restore ACI when aci_mod fails In-Reply-To: <1325856688.2159.20.camel@priserak> References: <1325856688.2159.20.camel@priserak> Message-ID: <4F104D8F.7050508@redhat.com> Martin Kosek wrote: > aci_mod command is composed of 2 ACI commands: aci_del which > deletes the old ACI and aci_add which adds the new modified ACI. > However, if aci_add command fails then both new and the old ACI > are lost. Old ACI must be restored in this case. > > https://fedorahosted.org/freeipa/ticket/2013 > https://fedorahosted.org/freeipa/ticket/2014 ACK From rcritten at redhat.com Fri Jan 13 15:38:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:38:38 -0500 Subject: [Freeipa-devel] [PATCH] 338 Added instructions to generate CRL. In-Reply-To: <4F0BF52D.7040302@redhat.com> References: <4F0BF52D.7040302@redhat.com> Message-ID: <4F104FFE.1080704@redhat.com> Endi Sukma Dewata wrote: > The certificate request dialog box has been modified to show > the OpenSSL commands for generating a CRL. > > The realm and entry names in the test data have been fixed to > be more consistent. > > Ticket #1012 ACK but you need to clean up the commit message. This is about CSR not CRL. rob From rcritten at redhat.com Fri Jan 13 15:40:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:40:35 -0500 Subject: [Freeipa-devel] [PATCH, master] 0039 Allow hbactest to work with HBAC rules exceeding default IPA limits In-Reply-To: <20120110092456.GF31251@redhat.com> References: <20120110092456.GF31251@redhat.com> Message-ID: <4F105073.30208@redhat.com> Alexander Bokovoy wrote: > When multiple HBAC rules are defined, IPA default limits to retrieve > objects may limit the scope of HBAC testing. To allow full range of > rules to be tested support for --sizelimit option is added. > > In addition, when --rules option is specified, make sure only those > rules are retrieved regardless total number of rules defined. This > should also speed up HBAC test performance for real life scenarios > when few new rules are added to large collection of rules. > > https://fedorahosted.org/freeipa/ticket/2230 ACK From rcritten at redhat.com Fri Jan 13 15:48:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:48:18 -0500 Subject: [Freeipa-devel] [PATCH] 190 Fix ipa-server-install for dual NICs In-Reply-To: <1326267331.9621.1.camel@balmora.brq.redhat.com> References: <1326195613.27400.14.camel@balmora.brq.redhat.com> <1326267331.9621.1.camel@balmora.brq.redhat.com> Message-ID: <4F105242.4010707@redhat.com> Martin Kosek wrote: > It seems I sent two patches with number 189. Sending a patch with a > correct number. > > Martin > > On Tue, 2012-01-10 at 12:40 +0100, Martin Kosek wrote: >> Depends on my patch 188 >> --- >> A server may have 2 or more NICs and its hostname may thus resolve >> to 2 and more forward addresses. IP address checks in install >> scripts does not expect this setup and may fail or crash. >> >> This script adds a support for multiple forward addresses for >> a hostname. The install scripts do not crash now. When one IP >> address is needed, user is asked to choose from all detected >> server IP addresses. >> >> https://fedorahosted.org/freeipa/ticket/2154 You have a patch 190 already as well :-) This appears to depend on another patch that I haven't applied yet. Can you see if it has unpushed dependencies? (removing the adtrust part was relatively easy and unrelated). rob From rcritten at redhat.com Fri Jan 13 15:52:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:52:29 -0500 Subject: [Freeipa-devel] [PATCH] 898 check for duplicate hostgroups In-Reply-To: <4E988F48.7030009@redhat.com> References: <4E988F48.7030009@redhat.com> Message-ID: <4F10533D.4020608@redhat.com> Rob Crittenden wrote: > When adding a hostgroup check for current existence of hostgroup and > netgroup > > The netgroup gets added automatically so we need to check in advance for > it. But we also need to look for the hostgroup otherwise the error > message is confusing (netgroup already exists). > > Also convert to using existing already_exists handler. > > rob Just to close the loop, this patch was replaced by Martin's patch 153 Improve hostgroup/netgroup collision checks rob From rcritten at redhat.com Fri Jan 13 15:55:08 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 10:55:08 -0500 Subject: [Freeipa-devel] [PATCH] 189 Fix selfservice-find crashes In-Reply-To: <1325856654.2159.19.camel@priserak> References: <1325856654.2159.19.camel@priserak> Message-ID: <4F1053DC.2090503@redhat.com> Martin Kosek wrote: > Ignore empty options when performing an ACI search so that the > find command does not crash. > > https://fedorahosted.org/freeipa/ticket/2011 > https://fedorahosted.org/freeipa/ticket/2012 I tested this and it works, I just wanted to confirm that this is the behavior we want. Empty search options are ignored. I think we'll want to document this somewhere at a minimum. rob From pvoborni at redhat.com Fri Jan 13 16:09:43 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Jan 2012 17:09:43 +0100 Subject: [Freeipa-devel] [ui-devel-tool] Updating and creating Web UI .json files Message-ID: <4F105747.5050409@redhat.com> I have created a helper tool (script) for updating install/ui/test/data/*.json files which are used for offline presentation of FreeIPA Web UI. So I'm sharing it as it might be useful for others. Main purpose: * updating ipa_init*.json files (should replace old not-working bash script) * creating new *.json files when implementing new UI functionality * updating existing files when modifying UI. Pros: * command definition is very easy - just copy it from Chromium or other developer tool a paste it into the code (with little text around). How it works: * user can define commands - concrete command with name, arguments and options then it can * call the command (using curl) and get JSON response from IPA server * modify the response * save response to file * or print response to console Current modification of response: * replaces dns, domains, hostname from IPA server's to dev.example.com * removes principal and version (no more various GIT versions) * removes trailing whitespaces Additional functionality: * possibility to define command groups * can execute multiple commands or groups * list defined commands and groups Common usage: ipa-json.py -v -d -s --methods method_name method_2_name or type 'ipa-json.py -h' for more options note: command and method mean basically the same, the naming should be united... Possible future enhancements: * add kerberos authentication * split definition of methods, code and configuration to multiple files -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-json.py Type: text/x-python Size: 12717 bytes Desc: not available URL: From abokovoy at redhat.com Fri Jan 13 16:25:34 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Jan 2012 18:25:34 +0200 Subject: [Freeipa-devel] [PATCH, master] 0039 Allow hbactest to work with HBAC rules exceeding default IPA limits In-Reply-To: <4F105073.30208@redhat.com> References: <20120110092456.GF31251@redhat.com> <4F105073.30208@redhat.com> Message-ID: <20120113162534.GD2805@redhat.com> On Fri, 13 Jan 2012, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >When multiple HBAC rules are defined, IPA default limits to retrieve > >objects may limit the scope of HBAC testing. To allow full range of > >rules to be tested support for --sizelimit option is added. > > > >In addition, when --rules option is specified, make sure only those > >rules are retrieved regardless total number of rules defined. This > >should also speed up HBAC test performance for real life scenarios > >when few new rules are added to large collection of rules. > > > >https://fedorahosted.org/freeipa/ticket/2230 > > ACK Thanks. Pushed to master, ipa-2-2. -- / Alexander Bokovoy From jdennis at redhat.com Fri Jan 13 16:33:25 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 13 Jan 2012 11:33:25 -0500 Subject: [Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance In-Reply-To: <4F0FAA9E.1080601@redhat.com> References: <4EE90D98.6030900@redhat.com> <4F0F6068.9000602@redhat.com> <4F0F6998.8020507@redhat.com> <4F0FAA9E.1080601@redhat.com> Message-ID: <4F105CD5.7090409@redhat.com> On 01/12/2012 10:53 PM, Rob Crittenden wrote: > John Dennis wrote: >> On 01/12/2012 05:36 PM, Rob Crittenden wrote: >>> John Dennis wrote: >>>> This patch adds an ipa memcached service, it does the following: >>>> >>>> * adds SysV initscript for ipa_memcached >>>> >>>> * adds systemd service file for ipa_memcached >>>> >>>> * adds tmpfiles.d configuration file for /var/run/ipa_memcached >>>> >>>> * adds configuration file for ipa_memcached >>>> >>>> * adds memcacheinstance.py file to create service instance during server >>>> install >>>> >>>> * invokes installation of ipa_memcached during ipa-server-install >>>> >>>> * adds dependencies to spec file >>>> >>>> * adds ipa_memcached to ipactl service control >>> >>> The conditionals for> F15 are probably not needed in the spec. Not >>> worth a NACK on its own. >> >> Because we'll never deploy< f16? Or because you believe there is a >> version issue not properly addressed? > > Because we would never deploy on< F15 (and more likely F16). Can't > argue with the clarity that this stuff only works on F15+. > >>> >>> Do we need to create /var/run/ipa_memcached/ ourselves? >>> >>> If the answer is no then ACK. >> >> Not sure I understand the question because the spec file does create >> /var/run/ipa_memcached and that directory must exist. Upon reboot it is >> recreated because of the tmpfiles configuration in >> /etc/tmpfiles.d/ipa.conf for>= f15. What is your concern? > > I don't see it being created in the spec file: > > $ grep ipa_memcached > /tmp/freeipa-jdennis-0059-Modify-spec-file-to-add-ipa_memcached-service.patch > | grep mkdir > > rob It's there, but just crafted a bit differently than what your grep was looking for. +mkdir -p %{buildroot}%{_localstatedir}/run/ +install -d -m 0700 %{buildroot}%{_localstatedir}/run/ipa_memcached/ -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Jan 13 16:39:24 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 11:39:24 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F06B9D4.6010300@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> Message-ID: <4F105E3C.3090907@redhat.com> Jan Cholasta wrote: > Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter >>>>>> but these weren't available in the sudorule plugin. >>>>>> >>>>>> I've added support for these. sudoOrder enforces uniqueness because >>>>>> duplicates are undefined. >>>>>> >>>>>> I also added support for a GeneralizedTime parameter type. This is >>>>>> similar to the existing AccessTime parameter but it only handles a >>>>>> single time value. >>>>> >>>>> You should parse the date/time part of the value with >>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, >>>>> that way you'll get most of the validation for free. >>>> >>>> Yes but it gives a crappy error message, just saying that some data is >>>> left over not what is wrong. >>> >>> IMHO having a separate error message for every field in the time string >>> (like you do in the patch) is an overkill, simple "invalid time" and/or >>> "unknown time format" should suffice (we don't have errors like "invalid >>> 3rd octet" for IP adresses either). >> >> Well, the work is done, hard to go back on a better error message. >> >>>> >>>>> Also, it would be nice to be able to enter the value in more >>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize >>>>> that to LDAP generalized time. >>>> >>>> When dealing with time there are so many ways to input and display the >>>> same values this becomes difficult. >>>> >>>> I'd expect that the times for these two attributes will be relatively >>>> simple and I somehow doubt users are going to want seconds, leap >>>> seconds >>>> or fractions, but we'll need to consider how to do it for future >>>> consistency (otherwise we could have a case where time is entered in >>>> one >>>> format for some attributes and another for others). >>>> >>>> If we input in a nice way we need to output in the same way. >>> >>> We could make the preferred input/output time format user-configurable, >>> defaulting to current locale time format. This format would be used for >>> output. For input, we could go over a list of formats (first the >>> user-configured format, then current locale format, then a handful of >>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first format >>> that can be successfully used to parse the time string. >> >> See how far you get into the rabbit hole with even this simple format? > > I don't mind, as long as it is the right thing to do (IMHO) :) > > Anyway, I think this could be done on the client side, so we might use > your patch without changes. However, I would prefer if the parameter > class was more generic, so we could use it (hypothetically) to store > time in some other way than LDAP generalized time attribute (at least > name it DateTime please). > Ok, I'm fine with that. >> >> The LDAP GeneralizedTime needs to be either in GMT or include a >> differential. This gets us into the territory where the client could be >> in a different timezone than the server which leads us to why we dropped >> AccessTime in the first place. > > Speaking of time zones, the differential alone is not a sufficient time > zone description, as it doesn't account for DST. Is there a way to store > time in LDAP with full time zone name (just in case it's needed sometime > in future)? There is no way to store DST in LDAP (probably for good reason). Oddly enough the older LDAP v3 RFC (2252) strongly recommends using only GMT but the RFC that obsoletes it (4517) does not include this. > >> So I'd like the user to supply the >> timezone themselves so I don't have to guess (wrongly) and let them >> worry about differing timezones. > > We don't have to guess, IIRC there is a way to get the local timezone > differential in both Python and JavaScript, so the client could supply > it automatically if necessary. I was thinking more about non-IPA clients (like sudo and notBefore). Updated patches attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-918-1-generalizedtime.patch Type: text/x-diff Size: 9145 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-1-sudo.patch Type: text/x-diff Size: 15563 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 13 16:51:32 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 11:51:32 -0500 Subject: [Freeipa-devel] Trivial doc patch for automember.py In-Reply-To: References: Message-ID: <4F106114.8080403@redhat.com> J?r?me Fenal wrote: > J?r?me Fenal - ACK, pushed to master and ipa-2-2 From edewata at redhat.com Fri Jan 13 16:59:24 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 13 Jan 2012 10:59:24 -0600 Subject: [Freeipa-devel] [PATCH] 338 Added instructions to generate CRL. In-Reply-To: <4F104FFE.1080704@redhat.com> References: <4F0BF52D.7040302@redhat.com> <4F104FFE.1080704@redhat.com> Message-ID: <4F1062EC.7040004@redhat.com> On 1/13/2012 9:38 AM, Rob Crittenden wrote: >> The certificate request dialog box has been modified to show >> the OpenSSL commands for generating a CRL. >> >> The realm and entry names in the test data have been fixed to >> be more consistent. >> >> Ticket #1012 > > ACK but you need to clean up the commit message. This is about CSR not CRL. Fixed and pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Jan 13 17:06:21 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 13 Jan 2012 11:06:21 -0600 Subject: [Freeipa-devel] [PATCH] 338 Added instructions to generate CRL. In-Reply-To: <4F1062EC.7040004@redhat.com> References: <4F0BF52D.7040302@redhat.com> <4F104FFE.1080704@redhat.com> <4F1062EC.7040004@redhat.com> Message-ID: <4F10648D.3020609@redhat.com> On 1/13/2012 10:59 AM, Endi Sukma Dewata wrote: > Fixed and pushed to master. And ipa-2-2. -- Endi S. Dewata From abokovoy at redhat.com Fri Jan 13 17:11:16 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Jan 2012 19:11:16 +0200 Subject: [Freeipa-devel] [PATCH] Fix slapi plugins build In-Reply-To: <1324403736.28622.123.camel@willson.li.ssimo.org> References: <1324403178.28622.121.camel@willson.li.ssimo.org> <1324403736.28622.123.camel@willson.li.ssimo.org> Message-ID: <20120113171116.GE2805@redhat.com> On Tue, 20 Dec 2011, Simo Sorce wrote: > On Tue, 2011-12-20 at 12:46 -0500, Simo Sorce wrote: > > This patch is needed to fix the slapi plugins to build against the > > thread-safe (reentrant) version of openldap libraries. > > > > I haven't changed ipa-clients because they are not threaded programs and > > wanted to restrict the change as much as possible. > > > > Fixes #2198. > > > > The same patch can be cherry-picked against both 2.1.x and master. > > I actually created 2 new patches (one for 2-1 and one for master) where > I also change the spec file so that freeipa packages depend on the new > 389ds package that uses the ldap_r library as both 389ds and plugins > must be build with the same libraries. Pushed ipa-2-1, ipa-2-2, master. The patch is also in Fedora 15, Fedora 16, and Rawhide. I filed ticket 2262 for making possible to autodetect proper SLAPI use of libldap/libldap_r -- / Alexander Bokovoy From ayoung at redhat.com Fri Jan 13 17:38:55 2012 From: ayoung at redhat.com (Adam Young) Date: Fri, 13 Jan 2012 12:38:55 -0500 Subject: [Freeipa-devel] [ui-devel-tool] Updating and creating Web UI .json files In-Reply-To: <4F105747.5050409@redhat.com> References: <4F105747.5050409@redhat.com> Message-ID: <4F106C2F.2090406@redhat.com> On 01/13/2012 11:09 AM, Petr Vobornik wrote: > I have created a helper tool (script) for updating > install/ui/test/data/*.json files which are used for offline > presentation of FreeIPA Web UI. So I'm sharing it as it might be > useful for others. > > Main purpose: > * updating ipa_init*.json files (should replace old not-working bash > script) > * creating new *.json files when implementing new UI functionality > * updating existing files when modifying UI. > > Pros: > * command definition is very easy - just copy it from Chromium or > other developer tool a paste it into the code (with little text around). > > How it works: > * user can define commands - concrete command with name, arguments and > options > > then it can > * call the command (using curl) and get JSON response from IPA server > * modify the response > * save response to file > * or print response to console > > Current modification of response: > * replaces dns, domains, hostname from IPA server's to dev.example.com > * removes principal and version (no more various GIT versions) > * removes trailing whitespaces > > Additional functionality: > * possibility to define command groups > * can execute multiple commands or groups > * list defined commands and groups > > Common usage: > ipa-json.py -v -d -s --methods method_name method_2_name > > or type 'ipa-json.py -h' for more options > > note: command and method mean basically the same, the naming should be > united... > > Possible future enhancements: > * add kerberos authentication > * split definition of methods, code and configuration to multiple files > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Petr, Kerberos should be pretty straight forward. For command line curl it is --negotiate -u --delegation always so you should be able to add those options right before c.setopt(pycurl.URL, url) || || -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Jan 13 19:30:55 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Jan 2012 14:30:55 -0500 Subject: [Freeipa-devel] [ui-devel-tool] Updating and creating Web UI .json files In-Reply-To: <4F106C2F.2090406@redhat.com> References: <4F105747.5050409@redhat.com> <4F106C2F.2090406@redhat.com> Message-ID: <1326483055.10198.33.camel@willson.li.ssimo.org> On Fri, 2012-01-13 at 12:38 -0500, Adam Young wrote: > On 01/13/2012 11:09 AM, Petr Vobornik wrote: > > I have created a helper tool (script) for updating > > install/ui/test/data/*.json files which are used for offline > > presentation of FreeIPA Web UI. So I'm sharing it as it might be > > useful for others. > > > > Main purpose: > > * updating ipa_init*.json files (should replace old not-working bash > > script) > > * creating new *.json files when implementing new UI functionality > > * updating existing files when modifying UI. > > > > Pros: > > * command definition is very easy - just copy it from Chromium or > > other developer tool a paste it into the code (with little text > > around). > > > > How it works: > > * user can define commands - concrete command with name, arguments > > and options > > > > then it can > > * call the command (using curl) and get JSON response from IPA > > server > > * modify the response > > * save response to file > > * or print response to console > > > > Current modification of response: > > * replaces dns, domains, hostname from IPA server's to > > dev.example.com > > * removes principal and version (no more various GIT versions) > > * removes trailing whitespaces > > > > Additional functionality: > > * possibility to define command groups > > * can execute multiple commands or groups > > * list defined commands and groups > > > > Common usage: > > ipa-json.py -v -d -s --methods method_name method_2_name > > > > or type 'ipa-json.py -h' for more options > > > > note: command and method mean basically the same, the naming should > > be united... > > > > Possible future enhancements: > > * add kerberos authentication > > * split definition of methods, code and configuration to multiple > > files > > > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Petr, > > Kerberos should be pretty straight forward. For command line curl it > is > > --negotiate -u --delegation always > > so you should be able to add those options right before > c.setopt(pycurl.URL, url) > > Actually this is changing. With 2.2 we are introducing s4u2proxy, so you should negotiate but you should *not* delegate anymore. Also with the session support you will need to start using secure cookies and make sure the tool behaves correctly with multiple redirects when you want to use json. The xml-rpc interface will not use session for the time being. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Jan 13 19:53:14 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2012 14:53:14 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers Message-ID: <4F108BAA.2020604@redhat.com> When viewing a certificate it will show the serial number as hex (dec). # ipa service-show HTTP/rawhide.example.com Principal: HTTP/rawhide.example.com at EXAMPLE.COM Certificate: [snip] Keytab: True Managed by: rawhide.example.com Subject: CN=rawhide.example.com,O=EXAMPLE.COM Serial Number: 0x403 (1027) Issuer: CN=EXAMPLE.COM Certificate Authority Not Before: Fri Jan 13 15:00:44 2012 UTC Not After: Thu Jan 13 15:00:44 2022 UTC Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 Fingerprint (SHA1): c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-924-serial.patch Type: text/x-diff Size: 5352 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 13 20:02:26 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jan 2012 21:02:26 +0100 Subject: [Freeipa-devel] [PATCH] 192 Replace float with Decimal Message-ID: <1326484946.2354.0.camel@priserak> This patch fixes RHEL 6.2 build issue. ---- Having float type as a base type for floating point parameter in ipalib introduces several issues, e.g. problem with representation or value comparison. Python language provides Decimal type which help overcome these issue. This patch replaces a float type with Decimal type in Float parameter. A precision attribute was added to Float parameter that can be used to limit a number of decimal places in parameter representation. This approach fixes a problem with API.txt validation where comparison of float values may fail on different architectures due to float representation error. In order to safely transfer the parameter value over RPC it is being converted to string which is then converted back to Decimal number on server side. https://fedorahosted.org/freeipa/ticket/2260 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-192-replace-float-with-decimal.patch Type: text/x-patch Size: 26996 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 13 20:07:51 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jan 2012 21:07:51 +0100 Subject: [Freeipa-devel] [PATCH] 190 Fix ipa-server-install for dual NICs In-Reply-To: <4F105242.4010707@redhat.com> References: <1326195613.27400.14.camel@balmora.brq.redhat.com> <1326267331.9621.1.camel@balmora.brq.redhat.com> <4F105242.4010707@redhat.com> Message-ID: <1326485271.2354.3.camel@priserak> On Fri, 2012-01-13 at 10:48 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > It seems I sent two patches with number 189. Sending a patch with a > > correct number. > > > > Martin > > > > On Tue, 2012-01-10 at 12:40 +0100, Martin Kosek wrote: > >> Depends on my patch 188 > >> --- > >> A server may have 2 or more NICs and its hostname may thus resolve > >> to 2 and more forward addresses. IP address checks in install > >> scripts does not expect this setup and may fail or crash. > >> > >> This script adds a support for multiple forward addresses for > >> a hostname. The install scripts do not crash now. When one IP > >> address is needed, user is asked to choose from all detected > >> server IP addresses. > >> > >> https://fedorahosted.org/freeipa/ticket/2154 > > You have a patch 190 already as well :-) Hm, yes :-) > > This appears to depend on another patch that I haven't applied yet. Can > you see if it has unpushed dependencies? (removing the adtrust part was > relatively easy and unrelated). > > rob It depended on patch 188 (it was written in the top of the mail). Since it was pushed today, this patch should be applicable to master branch. I checked it and it should be OK. Martin From mkosek at redhat.com Fri Jan 13 20:57:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jan 2012 21:57:29 +0100 Subject: [Freeipa-devel] [PATCH] 190 Restore ACI when aci_mod fails In-Reply-To: <4F104D8F.7050508@redhat.com> References: <1325856688.2159.20.camel@priserak> <4F104D8F.7050508@redhat.com> Message-ID: <1326488249.2212.0.camel@priserak> On Fri, 2012-01-13 at 10:28 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > aci_mod command is composed of 2 ACI commands: aci_del which > > deletes the old ACI and aci_add which adds the new modified ACI. > > However, if aci_add command fails then both new and the old ACI > > are lost. Old ACI must be restored in this case. > > > > https://fedorahosted.org/freeipa/ticket/2013 > > https://fedorahosted.org/freeipa/ticket/2014 > > ACK Pushed to master, ipa-2-2. Martin From rmeggins at redhat.com Fri Jan 13 23:17:53 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 13 Jan 2012 16:17:53 -0700 Subject: [Freeipa-devel] [PATCH] Ticket #1891 - Rewrite IPA plugins to take advantage of the single transaction Message-ID: <4F10BBA1.4060000@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-rmeggins-0004-Rewrite-IPA-plugins-to-take-advantage-of.patch URL: From rmeggins at redhat.com Fri Jan 13 23:41:58 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 13 Jan 2012 16:41:58 -0700 Subject: [Freeipa-devel] [PATCH] 192 Replace float with Decimal In-Reply-To: <1326484946.2354.0.camel@priserak> References: <1326484946.2354.0.camel@priserak> Message-ID: <4F10C146.8060009@redhat.com> On 01/13/2012 01:02 PM, Martin Kosek wrote: > This patch fixes RHEL 6.2 build issue. > ---- > Having float type as a base type for floating point parameter in > ipalib introduces several issues, e.g. problem with representation > or value comparison. Python language provides Decimal type which > help overcome these issue. > > This patch replaces a float type with Decimal type in Float > parameter. A precision attribute was added to Float parameter that > can be used to limit a number of decimal places in parameter > representation. This approach fixes a problem with API.txt > validation where comparison of float values may fail on different > architectures due to float representation error. > > In order to safely transfer the parameter value over RPC it is > being converted to string which is then converted back to Decimal > number on server side. > > https://fedorahosted.org/freeipa/ticket/2260 works for me - ./makeapi --validate passes in make - using RHEL 6.2 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Jan 16 07:55:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jan 2012 08:55:14 +0100 Subject: [Freeipa-devel] [PATCH] 189 Fix selfservice-find crashes In-Reply-To: <4F1053DC.2090503@redhat.com> References: <1325856654.2159.19.camel@priserak> <4F1053DC.2090503@redhat.com> Message-ID: <1326700514.3319.3.camel@balmora.brq.redhat.com> On Fri, 2012-01-13 at 10:55 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > Ignore empty options when performing an ACI search so that the > > find command does not crash. > > > > https://fedorahosted.org/freeipa/ticket/2011 > > https://fedorahosted.org/freeipa/ticket/2012 > > I tested this and it works, I just wanted to confirm that this is the > behavior we want. Empty search options are ignored. I think we'll want > to document this somewhere at a minimum. > > rob I think so. This is the way that our -find commands behave: # ipa user-find --last= -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1198000000 GID: 1198000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ---------------------------- I wondered where to add this information, this is what "man ipa" says: find commands take an optional criteria string as their only positional argument. If present, all objects with an attribute that contains the criteria string are displayed. If an option representing an attribute is set, only object with the attribute exactly matching the speci? fied value are displayed. Without parameters all objects of the corresponding type are dis? played. We may enhance this documentation if we find it insufficient. Martin From jhrozek at redhat.com Mon Jan 16 08:59:21 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 16 Jan 2012 09:59:21 +0100 Subject: [Freeipa-devel] [SSSD] New SSSD FAQ page in the works In-Reply-To: <20120112001157.GA16893@hendrix.redhat.com> References: <1326223911.10196.13.camel@sgallagh520.sgallagh.bos.redhat.com> <20120112001157.GA16893@hendrix.redhat.com> Message-ID: <20120116085921.GA16693@zeppelin.brq.redhat.com> On Thu, Jan 12, 2012 at 01:11:57AM +0100, Jakub Hrozek wrote: > On Tue, Jan 10, 2012 at 02:31:51PM -0500, Stephen Gallagher wrote: > > It's come up more than once that SSSD needs a Frequently Asked Questions > > page to field some of our more common questions. I'm reaching out to the > > SSSD and FreeIPA user and developer communities to help us flesh out > > this page. > > > > I've begun it with the two most common questions I've received lately, > > as well as a basic primer on enabling debug logging to help identify > > issues. > > > > I'd like some additional suggestions on what questions should be > > answered on that page, as well as opening the page to volunteer-edits to > > add answers to any questions they may have had and solved (or enlisted > > aid in solving) in the past. > > > > I'm not sure if the FAQ is the right place, but I couldn't find any > place on the wiki that would explain what an LTM release is. > > I know that some people are struggling with the differences between > RFC2307 and RFC2307bis schema. I wonder if we should include that in the > FAQ, too, even though it is explained in the manual pages. > > I also think that the last paragraph in the "Troubleshooting" section > should include a link that would tell how to contact the community for > further assistance. Done: https://fedorahosted.org/sssd/wiki/FAQ?action=diff&version=11&old_version=8 From mkosek at redhat.com Mon Jan 16 11:22:55 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jan 2012 12:22:55 +0100 Subject: [Freeipa-devel] [PATCH] 180 Add missing --pkey-only option for selfservice and In-Reply-To: <4F0FA951.9050506@redhat.com> References: <1323445643.7177.45.camel@balmora.brq.redhat.com> <4EE2B6D6.90301@redhat.com> <1325494003.2265.11.camel@priserak> <4F0FA951.9050506@redhat.com> Message-ID: <1326712975.3319.21.camel@balmora.brq.redhat.com> On Thu, 2012-01-12 at 22:47 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2011-12-09 at 19:33 -0600, Endi Sukma Dewata wrote: > >> On 12/9/2011 9:47 AM, Martin Kosek wrote: > >>> pkey-only functionality has to be implemented separately for these > >>> modules as they are based on crud.Search instead of standard > >>> LDAPSearch. > >>> > >>> Delegation commands were modified in the process to allow ACIs > >>> without 'memberof' as delegation ACIs. This check is no longer > >>> needed since delegation ACI prefixe ensures the ACI type. > >>> > >>> https://fedorahosted.org/freeipa/ticket/2092 > >> > >> From UI perspective this is ACKed. I'm sending a patch to enable paging > >> on these pages. > >> > > > > Thanks for the UI review Endi. If there are no objections from server > > people too we can push this. > > > > A rebased version for current master is attached. > > > > Martin > > The delegation tests fail with creation. Here is what it looks like from > the cli. > > # ipa delegation-add --attrs=street,c,l,st,postalcode --group=editors > --permissions=write --membergroup=admins delegation1 > ipa: ERROR: Delegation 'delegation1' not found > > rob In this case, delegation was broken earlier in a recent patch "Display the value of memberOf ACIs in permission plugin". A new version of the patch #180 adding the --pkey-only option + fixing the delegation plugin is attached. Delegation plugin is pretty simple and straightforward after this patch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-180-3-add-missing-pkey-only-option-for-selfservice-and-del.patch Type: text/x-patch Size: 17500 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jan 16 11:32:14 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 16 Jan 2012 12:32:14 +0100 Subject: [Freeipa-devel] [PATCH] 339 Fixed problem removing automount keys and DNS records. In-Reply-To: <4F0F1ED7.5040109@redhat.com> References: <4F0F1ED7.5040109@redhat.com> Message-ID: <4F140ABE.4060809@redhat.com> On 01/12/2012 06:56 PM, Endi Sukma Dewata wrote: > Due to a recent change the deleting automount keys and DNS records no > longer worked. The functions that are supposed to get the selected > values has been fixed to use the correct names and element type. They > also have been converted into methods of the search facets. > > Ticket #2256 > ACK Pushed to master, ipa-2-2. -- Petr Vobornik From mkosek at redhat.com Mon Jan 16 11:40:23 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jan 2012 12:40:23 +0100 Subject: [Freeipa-devel] [PATCH] 909 show HBAC and Sudo rule membership In-Reply-To: <4ED93183.2040105@redhat.com> References: <4ED93183.2040105@redhat.com> Message-ID: <1326714023.3319.23.camel@balmora.brq.redhat.com> On Fri, 2011-12-02 at 15:13 -0500, Rob Crittenden wrote: > The CLI wasn't showing HBAC and Sudo rule membership because it lacked a > label. These already show in the UI. > > rob ACK. Pushed to master, ipa-2-2. Martin From ohamada at redhat.com Mon Jan 16 12:06:24 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Mon, 16 Jan 2012 13:06:24 +0100 Subject: [Freeipa-devel] [PATCH] 8 localhost.localdomain clients refused to join ipa domain Message-ID: <4F1412C0.3070204@redhat.com> https://fedorahosted.org/freeipa/ticket/2112 Machines with hostname 'localhost.localdomain' are refused from joining IPA domain and proper error message is shown. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-localhost.localdomain-clients-refused-to-join.patch Type: text/x-patch Size: 1123 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 16 12:25:50 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Jan 2012 13:25:50 +0100 Subject: [Freeipa-devel] Fwd: Type conversions In-Reply-To: <4F0B015F.7030002@redhat.com> References: <4F0AFD61.8070002@redhat.com> <4F0B015F.7030002@redhat.com> Message-ID: <4F14174E.9090909@redhat.com> Dne 9.1.2012 16:01, John Dennis napsal(a): > Forwarding to freeipa-devel where this should have gone in the first > place ... > > -------- Original Message -------- > Subject: Type conversions (was: enhancement tickets) > Date: Mon, 09 Jan 2012 09:44:49 -0500 > From: John Dennis > To: Jan Cholasta > CC: Rob Crittenden , Martin Kosek > , Endi Sukma Dewata , Petr > Vobornik , Alexander Bokovoy > > On 01/09/2012 03:34 AM, Jan Cholasta wrote: > >>>> And ticket 2033. I have a vague notion you decided to defer this, am I >>>> remembering correctly? >>> >>> Nope, I'm working on a patch to fix this ticket. I had a patch for it, >>> but I have realized that the problem lies deeper than I thought, so I'm >>> working on a new patch now. >>> >>> The new patch changes the way parameter values are encoded and decoded >>> so that it is done in "border" backends (ldap2, xmlclient, >>> Executioner-based backends) instead of doing it ad-hoc all over the >>> code. This means that when a value enters IPA (either from a RPC >>> interface or from LDAP), it is converted from the backend-specific type >>> to the parameter type (which can be anything now, IP address object, DN >>> object, etc.) in a backend-specific way. When it leaves IPA, it is >>> converted back to backend-specific type, in a backend-specific way. >>> Inside IPA, the values are passed using the parameter type, so there is >>> no need to do any type conversions inside IPA. This will help me fix >>> 1487 and I believe it will also help John with his DN cleanup work >>> (because he won't have to care about converting the DNs to and from >>> strings). >>> >>> Turns out it is pretty tricky to do everything right, but I (hopefully) >>> solved all the big issues and will submit the patch soon. > > I'm very interested in this work. I too have recognized that we have a > very real structural problem with how we handle the types we use > internally, especially when it corresponds to an external type and > requires conversion. In fact we do a remarkably bad job in this area, we > have conversions which are done ad hoc all over the place. There is no > well established place for the conversions to occur and it's difficult > to know at any point in the code what type to expect. > > I faced this problem when trying to do the DN clean-up work. In fact the > biggest hurdle I faced was refactoring the code such that when a dn > enters our system it is converted to a DN object and when it leaves our > system it is converted back to a string representation at the logical > API boundaries. > > I have code sitting in a personal branch that does a lot of this. It > also caused me to locate and find all the weird hidden places where > conversions magically occur (a good example being the decorators in the > ldap2 module). > > I'd like to work with you on this, see what you've done and maybe we > should compare notes and share code. Also given this is a structural > issue perhaps the devel team should review proposed changes since it's > significant to the architecture. > Ticket: https://fedorahosted.org/freeipa/ticket/2265 Honza -- Jan Cholasta From mkosek at redhat.com Mon Jan 16 13:14:21 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jan 2012 14:14:21 +0100 Subject: [Freeipa-devel] [PATCH] 916 make category and members mutually exclusive in Sudo In-Reply-To: <4EE67CDC.8010603@redhat.com> References: <4EE67CDC.8010603@redhat.com> Message-ID: <1326719661.3319.36.camel@balmora.brq.redhat.com> On Mon, 2011-12-12 at 17:14 -0500, Rob Crittenden wrote: > This patch makes all categories and their equivalent members mutually > exclusive like in the HBAC plugin. So if you have usercat='all' you > can't add users. > > Added test cases for these as well. > > I also modified the default list of attributes to include the RunAs > attributes. > > rob NACK. I see several issues in this patch: 1) Error messages should be internationalized since they can be read by a user (this problem is in HBAC too) 2) All constructs like this one can be simplified (and thus made less error prone). + if 'cmdcategory' in _entry_attrs and \ + _entry_attrs['cmdcategory'][0].lower() == 'all': + raise errors.MutuallyExclusiveError(reason="commands cannot be added when command category='all'") can be changed to: + if _entry_attrs.get('cmdcategory', [''])[0].lower() == 'all': + raise errors.MutuallyExclusiveError(...) I think the code would be then also more readable. 3) I think this code only works by an accident :-) + if ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') \ + in _entry_attrs and \ + (_entry_attrs['ipasudorunasusercategory'][0].lower() == 'all' or \ + _entry_attrs['ipasudorunasgroupcategory'][0].lower() == 'all'): + raise errors.MutuallyExclusiveError(reason="users cannot be added when runAs user or runAs group category='all'") ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') simply returns 'ipasudorunasusercategory'. Thus the check for 'ipasudorunasgroupcategory' in _entry_attrs is not performed at all. Thanks to this bug, user is then able to pass a runAsGroup to sudorule with groupcat == 'all': # ipa sudorule-add foo --runasgroupcat=all --------------------- Added Sudo Rule "foo" --------------------- Rule name: foo Enabled: TRUE RunAs Group category: all # ipa sudorule-add-runasuser foo --groups=admins Rule name: foo Enabled: TRUE RunAs Group category: all Groups of RunAs Users: admins ------------------------- Number of members added 1 ------------------------- A change proposed in 1) could make the change simpler: + if _entry_attrs.get('ipasudorunasusercategory', [''])[0].lower() == 'all' or \ + _entry_attrs.get('ipasudorunasgroupcategory', [''])[0].lower() == 'all': + raise ... Martin From pvoborni at redhat.com Mon Jan 16 14:02:58 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 16 Jan 2012 15:02:58 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 069 Added refresh button for UI Message-ID: <4F142E12.9000009@redhat.com> This patch have some open issues therefore WIP tag. 1) Button position: I added the button into facet header next to 'add', 'delete', 'reset', 'update' buttons as shown on the picture ( http://pvoborni.fedorapeople.org/images/2051-refresh-button.png ). I'm not sure if it's the right position. I can also imagine it somewhere in the page header - in the green area on the right on the top main menu (Identity, Policy...) level. 2) Button icon: I used reset button icon. This is not good because in details facet reset and refresh button have the same icon. I think this icon is more suitable for refresh button and reset button should get new icon (maybe with reverse direction of the arrow). Probably we should ask UXD for opinion and icon. Patch description: Web UI is caching records. Currently only possible ways how to display updated record which was changed elsewhere - ie. in CLI are: * refresh page in browser (takes really long on slow vpns) * search facet: change filter, find, change filter back, find * entity details: go to search, select other entry, go back to search, select original entry * association facet: same as entity details These are inconvenient methods. This patch adds Refresh button to search, details and association facet. This button executes facets refresh method. https://fedorahosted.org/freeipa/ticket/2051 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0069-Added-refresh-button-for-UI.patch Type: text/x-patch Size: 8423 bytes Desc: not available URL: From mkosek at redhat.com Mon Jan 16 14:53:10 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jan 2012 15:53:10 +0100 Subject: [Freeipa-devel] [PATCH] 917 user automember for ipa default user In-Reply-To: <4EE6CFEF.8010606@redhat.com> References: <4EE6CF82.5010609@redhat.com> <4EE6CFEF.8010606@redhat.com> Message-ID: <1326725590.3319.54.camel@balmora.brq.redhat.com> On Mon, 2011-12-12 at 23:09 -0500, Rob Crittenden wrote: > Rob Crittenden wrote: > > Rather than manually adding users to the default ipa users group > > configure automember to do it for us. > > > > This was quite simple for new installs but a bit complex on upgrades so > > I implemented it as an update plugin. > > > > I also added a unit test for the config module. The majority of config > > is ignored for now. I'm afraid we'd run into too many false positives if > > we test each element, and most of these just store data so there isn't a > > lot that can go wrong. > > > > rob > > Small revision. I wasn't shipping the update plugin. > > rob I have few minor-ish issues: 0) I was thinking if this new approach for assignment of ipa default users is safe enough. If user accidentally mess with automember and modifies/deletes the default group rule, new users may be omitted from the default group set in IPA config. Are we sure that we are OK with this? 1) Several tests are provided with a hard-code basedn (dc=greyoak,dc=com). api.env.basedn would a better choice 2) We could optimize user.py not to retrieve config from LDAP since it is now needed only when api.env.wait_for_attr is now. I think this may speedup the command a little bit: ... # Automember adds our user to the default group for us. if self.api.env.wait_for_attr: config = ldap.get_ipa_config()[1] def_primary_group = config.get('ipadefaultprimarygroup') newentry = wait_for_value(ldap, dn, 'memberOf', def_primary_group) entry_from_entry(entry_attrs, newentry) ... Martin From dpal at redhat.com Mon Jan 16 15:13:33 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Jan 2012 10:13:33 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 069 Added refresh button for UI In-Reply-To: <4F142E12.9000009@redhat.com> References: <4F142E12.9000009@redhat.com> Message-ID: <4F143E9D.4030803@redhat.com> On 01/16/2012 09:02 AM, Petr Vobornik wrote: > This patch have some open issues therefore WIP tag. > > 1) Button position: > I added the button into facet header next to 'add', 'delete', 'reset', > 'update' buttons as shown on the picture ( > http://pvoborni.fedorapeople.org/images/2051-refresh-button.png ). I'm > not sure if it's the right position. I can also imagine it somewhere > in the page header - in the green area on the right on the top main > menu (Identity, Policy...) level. > > 2) Button icon: > I used reset button icon. This is not good because in details facet > reset and refresh button have the same icon. > I think this icon is more suitable for refresh button and reset button > should get new icon (maybe with reverse direction of the arrow). > > Probably we should ask UXD for opinion and icon. > Kyle can you please take a look? > > Patch description: > > Web UI is caching records. Currently only possible ways how to display > updated record which was changed elsewhere - ie. in CLI are: > * refresh page in browser (takes really long on slow vpns) > * search facet: change filter, find, change filter back, find > * entity details: go to search, select other entry, go back to > search, select original entry > * association facet: same as entity details > > These are inconvenient methods. > > This patch adds Refresh button to search, details and association > facet. This button executes facets refresh method. > > https://fedorahosted.org/freeipa/ticket/2051 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Jan 16 15:25:14 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 16 Jan 2012 16:25:14 +0100 Subject: [Freeipa-devel] [PATCH] 0273-fix-navigation In-Reply-To: <4E28F0B2.9060305@redhat.com> References: <4E28EFD6.8040609@redhat.com> <4E28F0B2.9060305@redhat.com> Message-ID: <4F14415A.4030409@redhat.com> On 07/22/2011 05:38 AM, Adam Young wrote: > fix navigation It seems that this patch is no longer necessary - first part is implemented (differently) in commit 740bacdfb9b7258a21669873efbd7639aebbdd71 (Tickets #1507, 1516, 1517) and second part in b36df6e9b9c1104d37fe14782a7e21e57097a7c0 (Tickets: 1451, 1462, 1493, 1497, 1532, 1534). -- Petr Vobornik From rcritten at redhat.com Mon Jan 16 15:47:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 10:47:26 -0500 Subject: [Freeipa-devel] [PATCH] 180 Add missing --pkey-only option for selfservice and In-Reply-To: <1326712975.3319.21.camel@balmora.brq.redhat.com> References: <1323445643.7177.45.camel@balmora.brq.redhat.com> <4EE2B6D6.90301@redhat.com> <1325494003.2265.11.camel@priserak> <4F0FA951.9050506@redhat.com> <1326712975.3319.21.camel@balmora.brq.redhat.com> Message-ID: <4F14468E.6020606@redhat.com> Martin Kosek wrote: > On Thu, 2012-01-12 at 22:47 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Fri, 2011-12-09 at 19:33 -0600, Endi Sukma Dewata wrote: >>>> On 12/9/2011 9:47 AM, Martin Kosek wrote: >>>>> pkey-only functionality has to be implemented separately for these >>>>> modules as they are based on crud.Search instead of standard >>>>> LDAPSearch. >>>>> >>>>> Delegation commands were modified in the process to allow ACIs >>>>> without 'memberof' as delegation ACIs. This check is no longer >>>>> needed since delegation ACI prefixe ensures the ACI type. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2092 >>>> >>>> From UI perspective this is ACKed. I'm sending a patch to enable paging >>>> on these pages. >>>> >>> >>> Thanks for the UI review Endi. If there are no objections from server >>> people too we can push this. >>> >>> A rebased version for current master is attached. >>> >>> Martin >> >> The delegation tests fail with creation. Here is what it looks like from >> the cli. >> >> # ipa delegation-add --attrs=street,c,l,st,postalcode --group=editors >> --permissions=write --membergroup=admins delegation1 >> ipa: ERROR: Delegation 'delegation1' not found >> >> rob > > In this case, delegation was broken earlier in a recent patch "Display > the value of memberOf ACIs in permission plugin". > > A new version of the patch #180 adding the --pkey-only option + fixing > the delegation plugin is attached. Delegation plugin is pretty simple > and straightforward after this patch. > > Martin ACK From rcritten at redhat.com Mon Jan 16 16:39:00 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 11:39:00 -0500 Subject: [Freeipa-devel] [PATCH] 916 make category and members mutually exclusive in Sudo In-Reply-To: <1326719661.3319.36.camel@balmora.brq.redhat.com> References: <4EE67CDC.8010603@redhat.com> <1326719661.3319.36.camel@balmora.brq.redhat.com> Message-ID: <4F1452A4.6090208@redhat.com> Martin Kosek wrote: > On Mon, 2011-12-12 at 17:14 -0500, Rob Crittenden wrote: >> This patch makes all categories and their equivalent members mutually >> exclusive like in the HBAC plugin. So if you have usercat='all' you >> can't add users. >> >> Added test cases for these as well. >> >> I also modified the default list of attributes to include the RunAs >> attributes. >> >> rob > > NACK. I see several issues in this patch: > > 1) Error messages should be internationalized since they can be read by > a user (this problem is in HBAC too) > > 2) All constructs like this one can be simplified (and thus made less > error prone). > > + if 'cmdcategory' in _entry_attrs and \ > + _entry_attrs['cmdcategory'][0].lower() == 'all': > + raise errors.MutuallyExclusiveError(reason="commands cannot be added when command category='all'") > > can be changed to: > > + if _entry_attrs.get('cmdcategory', [''])[0].lower() == 'all': > + raise errors.MutuallyExclusiveError(...) > > I think the code would be then also more readable. > > 3) I think this code only works by an accident :-) > > + if ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') \ > + in _entry_attrs and \ > + (_entry_attrs['ipasudorunasusercategory'][0].lower() == 'all' or \ > + _entry_attrs['ipasudorunasgroupcategory'][0].lower() == 'all'): > + raise errors.MutuallyExclusiveError(reason="users cannot be added when runAs user or runAs group category='all'") > > ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') simply > returns 'ipasudorunasusercategory'. Thus the check for > 'ipasudorunasgroupcategory' in _entry_attrs is not performed at all. > Thanks to this bug, user is then able to pass a runAsGroup to sudorule > with groupcat == 'all': > > # ipa sudorule-add foo --runasgroupcat=all > --------------------- > Added Sudo Rule "foo" > --------------------- > Rule name: foo > Enabled: TRUE > RunAs Group category: all > # ipa sudorule-add-runasuser foo --groups=admins > Rule name: foo > Enabled: TRUE > RunAs Group category: all > Groups of RunAs Users: admins > ------------------------- > Number of members added 1 > ------------------------- > > A change proposed in 1) could make the change simpler: > > + if _entry_attrs.get('ipasudorunasusercategory', [''])[0].lower() == 'all' or \ > + _entry_attrs.get('ipasudorunasgroupcategory', [''])[0].lower() == 'all': > + raise ... > > Martin > > Updated patch attached. Using the is_all() function instead. Opened separate ticket to internationalize HBAC exceptions, https://fedorahosted.org/freeipa/ticket/2267 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-916-1-sudo.patch Type: text/x-diff Size: 13304 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 16 17:09:55 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Jan 2012 18:09:55 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F108BAA.2020604@redhat.com> References: <4F108BAA.2020604@redhat.com> Message-ID: <4F1459E3.4050309@redhat.com> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): > When viewing a certificate it will show the serial number as hex (dec). > > # ipa service-show HTTP/rawhide.example.com > Principal: HTTP/rawhide.example.com at EXAMPLE.COM > Certificate: [snip] > Keytab: True > Managed by: rawhide.example.com > Subject: CN=rawhide.example.com,O=EXAMPLE.COM > Serial Number: 0x403 (1027) > Issuer: CN=EXAMPLE.COM Certificate Authority > Not Before: Fri Jan 13 15:00:44 2012 UTC > Not After: Thu Jan 13 15:00:44 2022 UTC > Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 > Fingerprint (SHA1): > c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 > > rob > NACK Displaying a host or a service in the webUI fails with "IPA error 3009: invalid 'serial_number': Decimal or hexadecimal number is required for serial number". I would suggest to do the nifty formatting of serial numbers on the client side, that would fix the webUI issue, allow non-IPA clients to parse the number without dissecting the string representation of it and probably also save me a hack in the type conversion overhaul. You could for example add a parameter flag like "format_serial_number" to indicate to the client that it should format the value as a serial number. Honza -- Jan Cholasta From jcholast at redhat.com Mon Jan 16 17:27:49 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Jan 2012 18:27:49 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F105E3C.3090907@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> Message-ID: <4F145E15.7050609@redhat.com> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>> Jan Cholasta wrote: >>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>> sudoNotAfter >>>>>>> but these weren't available in the sudorule plugin. >>>>>>> >>>>>>> I've added support for these. sudoOrder enforces uniqueness because >>>>>>> duplicates are undefined. >>>>>>> >>>>>>> I also added support for a GeneralizedTime parameter type. This is >>>>>>> similar to the existing AccessTime parameter but it only handles a >>>>>>> single time value. >>>>>> >>>>>> You should parse the date/time part of the value with >>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, >>>>>> that way you'll get most of the validation for free. >>>>> >>>>> Yes but it gives a crappy error message, just saying that some data is >>>>> left over not what is wrong. >>>> >>>> IMHO having a separate error message for every field in the time string >>>> (like you do in the patch) is an overkill, simple "invalid time" and/or >>>> "unknown time format" should suffice (we don't have errors like >>>> "invalid >>>> 3rd octet" for IP adresses either). >>> >>> Well, the work is done, hard to go back on a better error message. >>> >>>>> >>>>>> Also, it would be nice to be able to enter the value in more >>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize >>>>>> that to LDAP generalized time. >>>>> >>>>> When dealing with time there are so many ways to input and display the >>>>> same values this becomes difficult. >>>>> >>>>> I'd expect that the times for these two attributes will be relatively >>>>> simple and I somehow doubt users are going to want seconds, leap >>>>> seconds >>>>> or fractions, but we'll need to consider how to do it for future >>>>> consistency (otherwise we could have a case where time is entered in >>>>> one >>>>> format for some attributes and another for others). >>>>> >>>>> If we input in a nice way we need to output in the same way. >>>> >>>> We could make the preferred input/output time format user-configurable, >>>> defaulting to current locale time format. This format would be used for >>>> output. For input, we could go over a list of formats (first the >>>> user-configured format, then current locale format, then a handful of >>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first format >>>> that can be successfully used to parse the time string. >>> >>> See how far you get into the rabbit hole with even this simple format? >> >> I don't mind, as long as it is the right thing to do (IMHO) :) >> >> Anyway, I think this could be done on the client side, so we might use >> your patch without changes. However, I would prefer if the parameter >> class was more generic, so we could use it (hypothetically) to store >> time in some other way than LDAP generalized time attribute (at least >> name it DateTime please). >> > > Ok, I'm fine with that. Thanks. > >>> >>> The LDAP GeneralizedTime needs to be either in GMT or include a >>> differential. This gets us into the territory where the client could be >>> in a different timezone than the server which leads us to why we dropped >>> AccessTime in the first place. >> >> Speaking of time zones, the differential alone is not a sufficient time >> zone description, as it doesn't account for DST. Is there a way to store >> time in LDAP with full time zone name (just in case it's needed sometime >> in future)? > > There is no way to store DST in LDAP (probably for good reason). Oddly > enough the older LDAP v3 RFC (2252) strongly recommends using only GMT > but the RFC that obsoletes it (4517) does not include this. Thanks for the info. > >> >>> So I'd like the user to supply the >>> timezone themselves so I don't have to guess (wrongly) and let them >>> worry about differing timezones. >> >> We don't have to guess, IIRC there is a way to get the local timezone >> differential in both Python and JavaScript, so the client could supply >> it automatically if necessary. > > I was thinking more about non-IPA clients (like sudo and notBefore). I think this can still be done at least in CLI, but it could be done in a separate patch. > > Updated patches attached. > > rob Patch 919 doesn't cleanly apply on current master (neither does 916 BTW). Honza -- Jan Cholasta From dpal at redhat.com Mon Jan 16 17:37:07 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Jan 2012 12:37:07 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F1459E3.4050309@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> Message-ID: <4F146043.30404@redhat.com> On 01/16/2012 12:09 PM, Jan Cholasta wrote: > Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >> When viewing a certificate it will show the serial number as hex (dec). >> >> # ipa service-show HTTP/rawhide.example.com >> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >> Certificate: [snip] >> Keytab: True >> Managed by: rawhide.example.com >> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >> Serial Number: 0x403 (1027) >> Issuer: CN=EXAMPLE.COM Certificate Authority >> Not Before: Fri Jan 13 15:00:44 2012 UTC >> Not After: Thu Jan 13 15:00:44 2022 UTC >> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >> Fingerprint (SHA1): >> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >> >> rob >> > > NACK > > Displaying a host or a service in the webUI fails with "IPA error > 3009: invalid 'serial_number': Decimal or hexadecimal number is > required for serial number". > > I would suggest to do the nifty formatting of serial numbers on the > client side, that would fix the webUI issue, allow non-IPA clients to > parse the number without dissecting the string representation of it > and probably also save me a hack in the type conversion overhaul. You > could for example add a parameter flag like "format_serial_number" to > indicate to the client that it should format the value as a serial > number. > > Honza > Somewhat related question about cert serial numbers... Can the serial numbers be arbitrarily strings in future or serial number is always a number by spec? Is it a GUID? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Mon Jan 16 17:54:23 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Jan 2012 18:54:23 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F146043.30404@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146043.30404@redhat.com> Message-ID: <4F14644F.90102@redhat.com> Dne 16.1.2012 18:37, Dmitri Pal napsal(a): > On 01/16/2012 12:09 PM, Jan Cholasta wrote: >> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>> When viewing a certificate it will show the serial number as hex (dec). >>> >>> # ipa service-show HTTP/rawhide.example.com >>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>> Certificate: [snip] >>> Keytab: True >>> Managed by: rawhide.example.com >>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>> Serial Number: 0x403 (1027) >>> Issuer: CN=EXAMPLE.COM Certificate Authority >>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>> Not After: Thu Jan 13 15:00:44 2022 UTC >>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>> Fingerprint (SHA1): >>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>> >>> rob >>> >> >> NACK >> >> Displaying a host or a service in the webUI fails with "IPA error >> 3009: invalid 'serial_number': Decimal or hexadecimal number is >> required for serial number". >> >> I would suggest to do the nifty formatting of serial numbers on the >> client side, that would fix the webUI issue, allow non-IPA clients to >> parse the number without dissecting the string representation of it >> and probably also save me a hack in the type conversion overhaul. You >> could for example add a parameter flag like "format_serial_number" to >> indicate to the client that it should format the value as a serial >> number. >> >> Honza >> > > Somewhat related question about cert serial numbers... > Can the serial numbers be arbitrarily strings in future or serial number > is always a number by spec? Is it a GUID? > AFAIK it must be an integer. -- Jan Cholasta From rcritten at redhat.com Mon Jan 16 18:35:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 13:35:22 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F1459E3.4050309@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> Message-ID: <4F146DEA.5070204@redhat.com> Jan Cholasta wrote: > Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >> When viewing a certificate it will show the serial number as hex (dec). >> >> # ipa service-show HTTP/rawhide.example.com >> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >> Certificate: [snip] >> Keytab: True >> Managed by: rawhide.example.com >> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >> Serial Number: 0x403 (1027) >> Issuer: CN=EXAMPLE.COM Certificate Authority >> Not Before: Fri Jan 13 15:00:44 2012 UTC >> Not After: Thu Jan 13 15:00:44 2022 UTC >> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >> Fingerprint (SHA1): >> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >> >> rob >> > > NACK > > Displaying a host or a service in the webUI fails with "IPA error 3009: > invalid 'serial_number': Decimal or hexadecimal number is required for > serial number". > > I would suggest to do the nifty formatting of serial numbers on the > client side, that would fix the webUI issue, allow non-IPA clients to > parse the number without dissecting the string representation of it and > probably also save me a hack in the type conversion overhaul. You could > for example add a parameter flag like "format_serial_number" to indicate > to the client that it should format the value as a serial number. > > Honza > Well, we want to do as little client formatting as possible. The idea is to have a very thin client. I'll look into fixing the UI side. rob From mkosek at redhat.com Mon Jan 16 19:10:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jan 2012 20:10:19 +0100 Subject: [Freeipa-devel] [PATCH] 180 Add missing --pkey-only option for selfservice and In-Reply-To: <4F14468E.6020606@redhat.com> References: <1323445643.7177.45.camel@balmora.brq.redhat.com> <4EE2B6D6.90301@redhat.com> <1325494003.2265.11.camel@priserak> <4F0FA951.9050506@redhat.com> <1326712975.3319.21.camel@balmora.brq.redhat.com> <4F14468E.6020606@redhat.com> Message-ID: <1326741019.2026.3.camel@priserak> On Mon, 2012-01-16 at 10:47 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-01-12 at 22:47 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Fri, 2011-12-09 at 19:33 -0600, Endi Sukma Dewata wrote: > >>>> On 12/9/2011 9:47 AM, Martin Kosek wrote: > >>>>> pkey-only functionality has to be implemented separately for these > >>>>> modules as they are based on crud.Search instead of standard > >>>>> LDAPSearch. > >>>>> > >>>>> Delegation commands were modified in the process to allow ACIs > >>>>> without 'memberof' as delegation ACIs. This check is no longer > >>>>> needed since delegation ACI prefixe ensures the ACI type. > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/2092 > >>>> > >>>> From UI perspective this is ACKed. I'm sending a patch to enable paging > >>>> on these pages. > >>>> > >>> > >>> Thanks for the UI review Endi. If there are no objections from server > >>> people too we can push this. > >>> > >>> A rebased version for current master is attached. > >>> > >>> Martin > >> > >> The delegation tests fail with creation. Here is what it looks like from > >> the cli. > >> > >> # ipa delegation-add --attrs=street,c,l,st,postalcode --group=editors > >> --permissions=write --membergroup=admins delegation1 > >> ipa: ERROR: Delegation 'delegation1' not found > >> > >> rob > > > > In this case, delegation was broken earlier in a recent patch "Display > > the value of memberOf ACIs in permission plugin". > > > > A new version of the patch #180 adding the --pkey-only option + fixing > > the delegation plugin is attached. Delegation plugin is pretty simple > > and straightforward after this patch. > > > > Martin > > ACK Thanks. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Mon Jan 16 19:13:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jan 2012 20:13:22 +0100 Subject: [Freeipa-devel] [PATCH] 331 Enabled paging on self-service permissions and delegations. In-Reply-To: <4EE769A2.1050203@redhat.com> References: <4EE2B6D8.10807@redhat.com> <4EE769A2.1050203@redhat.com> Message-ID: <1326741202.2026.4.camel@priserak> On Tue, 2011-12-13 at 16:05 +0100, Petr Vobornik wrote: > On 12/10/2011 02:33 AM, Endi Sukma Dewata wrote: > > Paging has been enabled on self-service permissions and delegations > > list pages. The search facet's get_pkeys() has been fixed to handle > > non-array value. New test data files have been added as well. > > > > Ticket #2092 > > > > This patch depends on Martin's patch #180. > > > ACK > > Push should wait for Martin's patch ACK/push. > My patch #180 was pushed thus I pushed this patch to master, ipa-2-2 as well. Martin From rcritten at redhat.com Mon Jan 16 20:43:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 15:43:58 -0500 Subject: [Freeipa-devel] [PATCH] 917 user automember for ipa default user In-Reply-To: <1326725590.3319.54.camel@balmora.brq.redhat.com> References: <4EE6CF82.5010609@redhat.com> <4EE6CFEF.8010606@redhat.com> <1326725590.3319.54.camel@balmora.brq.redhat.com> Message-ID: <4F148C0E.4030008@redhat.com> Martin Kosek wrote: > On Mon, 2011-12-12 at 23:09 -0500, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Rather than manually adding users to the default ipa users group >>> configure automember to do it for us. >>> >>> This was quite simple for new installs but a bit complex on upgrades so >>> I implemented it as an update plugin. >>> >>> I also added a unit test for the config module. The majority of config >>> is ignored for now. I'm afraid we'd run into too many false positives if >>> we test each element, and most of these just store data so there isn't a >>> lot that can go wrong. >>> >>> rob >> >> Small revision. I wasn't shipping the update plugin. >> >> rob > > I have few minor-ish issues: > > 0) I was thinking if this new approach for assignment of ipa default > users is safe enough. If user accidentally mess with automember and > modifies/deletes the default group rule, new users may be omitted from > the default group set in IPA config. Are we sure that we are OK with > this? I made some stricter tests that don't allow users to manage the conditions of the default users group nor use an existing rule with conditions for the default users group. > 1) Several tests are provided with a hard-code basedn > (dc=greyoak,dc=com). api.env.basedn would a better choice Ouch, fixed. > 2) We could optimize user.py not to retrieve config from LDAP since it > is now needed only when api.env.wait_for_attr is now. I think this may > speedup the command a little bit: > ... > # Automember adds our user to the default group for us. > if self.api.env.wait_for_attr: > config = ldap.get_ipa_config()[1] > def_primary_group = config.get('ipadefaultprimarygroup') > newentry = wait_for_value(ldap, dn, 'memberOf', > def_primary_group) > entry_from_entry(entry_attrs, newentry) > ... Ok, that's a good idea. I think this path is going to go away soon though once we have transactions in 389-ds. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-917-2-defaultuser.patch Type: text/x-diff Size: 20504 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 16 21:02:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 16:02:33 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F146DEA.5070204@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> Message-ID: <4F149069.4060704@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>> When viewing a certificate it will show the serial number as hex (dec). >>> >>> # ipa service-show HTTP/rawhide.example.com >>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>> Certificate: [snip] >>> Keytab: True >>> Managed by: rawhide.example.com >>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>> Serial Number: 0x403 (1027) >>> Issuer: CN=EXAMPLE.COM Certificate Authority >>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>> Not After: Thu Jan 13 15:00:44 2022 UTC >>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>> Fingerprint (SHA1): >>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>> >>> rob >>> >> >> NACK >> >> Displaying a host or a service in the webUI fails with "IPA error 3009: >> invalid 'serial_number': Decimal or hexadecimal number is required for >> serial number". >> >> I would suggest to do the nifty formatting of serial numbers on the >> client side, that would fix the webUI issue, allow non-IPA clients to >> parse the number without dissecting the string representation of it and >> probably also save me a hack in the type conversion overhaul. You could >> for example add a parameter flag like "format_serial_number" to indicate >> to the client that it should format the value as a serial number. >> >> Honza >> > > Well, we want to do as little client formatting as possible. The idea is > to have a very thin client. > > I'll look into fixing the UI side. I don't see this error in services, it displays correctly. I'm not sure if it is my browser or what but hosts don't display much of anything for me. rob From rcritten at redhat.com Tue Jan 17 03:20:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 22:20:02 -0500 Subject: [Freeipa-devel] [PATCH] 916 make category and members mutually exclusive in Sudo In-Reply-To: <4F1452A4.6090208@redhat.com> References: <4EE67CDC.8010603@redhat.com> <1326719661.3319.36.camel@balmora.brq.redhat.com> <4F1452A4.6090208@redhat.com> Message-ID: <4F14E8E2.5030305@redhat.com> Rob Crittenden wrote: > Martin Kosek wrote: >> On Mon, 2011-12-12 at 17:14 -0500, Rob Crittenden wrote: >>> This patch makes all categories and their equivalent members mutually >>> exclusive like in the HBAC plugin. So if you have usercat='all' you >>> can't add users. >>> >>> Added test cases for these as well. >>> >>> I also modified the default list of attributes to include the RunAs >>> attributes. >>> >>> rob >> >> NACK. I see several issues in this patch: >> >> 1) Error messages should be internationalized since they can be read by >> a user (this problem is in HBAC too) >> >> 2) All constructs like this one can be simplified (and thus made less >> error prone). >> >> + if 'cmdcategory' in _entry_attrs and \ >> + _entry_attrs['cmdcategory'][0].lower() == 'all': >> + raise errors.MutuallyExclusiveError(reason="commands cannot be added >> when command category='all'") >> >> can be changed to: >> >> + if _entry_attrs.get('cmdcategory', [''])[0].lower() == 'all': >> + raise errors.MutuallyExclusiveError(...) >> >> I think the code would be then also more readable. >> >> 3) I think this code only works by an accident :-) >> >> + if ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') \ >> + in _entry_attrs and \ >> + (_entry_attrs['ipasudorunasusercategory'][0].lower() == 'all' or \ >> + _entry_attrs['ipasudorunasgroupcategory'][0].lower() == 'all'): >> + raise errors.MutuallyExclusiveError(reason="users cannot be added >> when runAs user or runAs group category='all'") >> >> ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') simply >> returns 'ipasudorunasusercategory'. Thus the check for >> 'ipasudorunasgroupcategory' in _entry_attrs is not performed at all. >> Thanks to this bug, user is then able to pass a runAsGroup to sudorule >> with groupcat == 'all': >> >> # ipa sudorule-add foo --runasgroupcat=all >> --------------------- >> Added Sudo Rule "foo" >> --------------------- >> Rule name: foo >> Enabled: TRUE >> RunAs Group category: all >> # ipa sudorule-add-runasuser foo --groups=admins >> Rule name: foo >> Enabled: TRUE >> RunAs Group category: all >> Groups of RunAs Users: admins >> ------------------------- >> Number of members added 1 >> ------------------------- >> >> A change proposed in 1) could make the change simpler: >> >> + if _entry_attrs.get('ipasudorunasusercategory', [''])[0].lower() == >> 'all' or \ >> + _entry_attrs.get('ipasudorunasgroupcategory', [''])[0].lower() == >> 'all': >> + raise ... >> >> Martin >> >> > > Updated patch attached. Using the is_all() function instead. Opened > separate ticket to internationalize HBAC exceptions, > https://fedorahosted.org/freeipa/ticket/2267 > > rob Rebased against ipa-2-2. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-916-2-sudo.patch Type: text/x-diff Size: 5396 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 17 03:55:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 22:55:29 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F145E15.7050609@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> Message-ID: <4F14F131.3080503@redhat.com> Jan Cholasta wrote: > Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>> sudoNotAfter >>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>> >>>>>>>> I've added support for these. sudoOrder enforces uniqueness because >>>>>>>> duplicates are undefined. >>>>>>>> >>>>>>>> I also added support for a GeneralizedTime parameter type. This is >>>>>>>> similar to the existing AccessTime parameter but it only handles a >>>>>>>> single time value. >>>>>>> >>>>>>> You should parse the date/time part of the value with >>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, >>>>>>> that way you'll get most of the validation for free. >>>>>> >>>>>> Yes but it gives a crappy error message, just saying that some >>>>>> data is >>>>>> left over not what is wrong. >>>>> >>>>> IMHO having a separate error message for every field in the time >>>>> string >>>>> (like you do in the patch) is an overkill, simple "invalid time" >>>>> and/or >>>>> "unknown time format" should suffice (we don't have errors like >>>>> "invalid >>>>> 3rd octet" for IP adresses either). >>>> >>>> Well, the work is done, hard to go back on a better error message. >>>> >>>>>> >>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>> normalize >>>>>>> that to LDAP generalized time. >>>>>> >>>>>> When dealing with time there are so many ways to input and display >>>>>> the >>>>>> same values this becomes difficult. >>>>>> >>>>>> I'd expect that the times for these two attributes will be relatively >>>>>> simple and I somehow doubt users are going to want seconds, leap >>>>>> seconds >>>>>> or fractions, but we'll need to consider how to do it for future >>>>>> consistency (otherwise we could have a case where time is entered in >>>>>> one >>>>>> format for some attributes and another for others). >>>>>> >>>>>> If we input in a nice way we need to output in the same way. >>>>> >>>>> We could make the preferred input/output time format >>>>> user-configurable, >>>>> defaulting to current locale time format. This format would be used >>>>> for >>>>> output. For input, we could go over a list of formats (first the >>>>> user-configured format, then current locale format, then a handful of >>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first format >>>>> that can be successfully used to parse the time string. >>>> >>>> See how far you get into the rabbit hole with even this simple format? >>> >>> I don't mind, as long as it is the right thing to do (IMHO) :) >>> >>> Anyway, I think this could be done on the client side, so we might use >>> your patch without changes. However, I would prefer if the parameter >>> class was more generic, so we could use it (hypothetically) to store >>> time in some other way than LDAP generalized time attribute (at least >>> name it DateTime please). >>> >> >> Ok, I'm fine with that. > > Thanks. > >> >>>> >>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>> differential. This gets us into the territory where the client could be >>>> in a different timezone than the server which leads us to why we >>>> dropped >>>> AccessTime in the first place. >>> >>> Speaking of time zones, the differential alone is not a sufficient time >>> zone description, as it doesn't account for DST. Is there a way to store >>> time in LDAP with full time zone name (just in case it's needed sometime >>> in future)? >> >> There is no way to store DST in LDAP (probably for good reason). Oddly >> enough the older LDAP v3 RFC (2252) strongly recommends using only GMT >> but the RFC that obsoletes it (4517) does not include this. > > Thanks for the info. > >> >>> >>>> So I'd like the user to supply the >>>> timezone themselves so I don't have to guess (wrongly) and let them >>>> worry about differing timezones. >>> >>> We don't have to guess, IIRC there is a way to get the local timezone >>> differential in both Python and JavaScript, so the client could supply >>> it automatically if necessary. >> >> I was thinking more about non-IPA clients (like sudo and notBefore). > > I think this can still be done at least in CLI, but it could be done in > a separate patch. > >> >> Updated patches attached. >> >> rob > > Patch 919 doesn't cleanly apply on current master (neither does 916 BTW). > > Honza > Rebased patch (and 916 too, separately). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-918-1-generalizedtime.patch Type: text/x-diff Size: 9145 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-2-sudo.patch Type: text/x-diff Size: 15846 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 17 04:37:23 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jan 2012 23:37:23 -0500 Subject: [Freeipa-devel] [PATCH] 925 Make deleting replication agreements nicer Message-ID: <4F14FB03.7010208@redhat.com> Check for the existence of a replication agreement before deleting it. When using ipa-replica-manage or ipa-csreplica-manage to delete an agreement with a host we would try to make a connection to that host prior to tryign to delete it. This meant that the trying to delete a host we don't hvae an agreement with would return a connection error instead of a "no agreement with host foo" error. Also display a completed message when an agreement is removed. https://fedorahosted.org/freeipa/ticket/2048 https://fedorahosted.org/freeipa/ticket/2125 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-925-replica.patch Type: text/x-diff Size: 7556 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 17 08:28:32 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Jan 2012 09:28:32 +0100 Subject: [Freeipa-devel] [PATCH] 917 user automember for ipa default user In-Reply-To: <4F148C0E.4030008@redhat.com> References: <4EE6CF82.5010609@redhat.com> <4EE6CFEF.8010606@redhat.com> <1326725590.3319.54.camel@balmora.brq.redhat.com> <4F148C0E.4030008@redhat.com> Message-ID: <1326788912.3012.4.camel@balmora.brq.redhat.com> On Mon, 2012-01-16 at 15:43 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2011-12-12 at 23:09 -0500, Rob Crittenden wrote: > >> Rob Crittenden wrote: > >>> Rather than manually adding users to the default ipa users group > >>> configure automember to do it for us. > >>> > >>> This was quite simple for new installs but a bit complex on upgrades so > >>> I implemented it as an update plugin. > >>> > >>> I also added a unit test for the config module. The majority of config > >>> is ignored for now. I'm afraid we'd run into too many false positives if > >>> we test each element, and most of these just store data so there isn't a > >>> lot that can go wrong. > >>> > >>> rob > >> > >> Small revision. I wasn't shipping the update plugin. > >> > >> rob > > > > I have few minor-ish issues: > > > > 0) I was thinking if this new approach for assignment of ipa default > > users is safe enough. If user accidentally mess with automember and > > modifies/deletes the default group rule, new users may be omitted from > > the default group set in IPA config. Are we sure that we are OK with > > this? > > I made some stricter tests that don't allow users to manage the > conditions of the default users group nor use an existing rule with > conditions for the default users group. > > > 1) Several tests are provided with a hard-code basedn > > (dc=greyoak,dc=com). api.env.basedn would a better choice > > Ouch, fixed. > > > 2) We could optimize user.py not to retrieve config from LDAP since it > > is now needed only when api.env.wait_for_attr is now. I think this may > > speedup the command a little bit: > > ... > > # Automember adds our user to the default group for us. > > if self.api.env.wait_for_attr: > > config = ldap.get_ipa_config()[1] > > def_primary_group = config.get('ipadefaultprimarygroup') > > newentry = wait_for_value(ldap, dn, 'memberOf', > > def_primary_group) > > entry_from_entry(entry_attrs, newentry) > > ... > > Ok, that's a good idea. I think this path is going to go away soon > though once we have transactions in 389-ds. > > rob > Thanks, it safer now. We just have to fix ipa-server-install too: # ipa-server-install ... [12/13]: restarting httpd [13/13]: configuring httpd to start on boot done configuring httpd. Applying LDAP updates Unexpected error - see ipaserver-install.log for details: The default users group cannot be removed or modified There is also a bug in is_default_users group - all non-group automember rules are rejected: # ipa hostgroup-add --desc="Web Servers" webservers ---------------------------- Added hostgroup "webservers" ---------------------------- Host-group: webservers Description: Web Servers # ipa automember-add --type=hostgroup webservers ---------------------------------- Added automember rule "webservers" ---------------------------------- Automember Rule: webservers # ipa automember-add-condition --key=fqdn --type=hostgroup --inclusive-regex=^web[1-9]+\.example\.com webservers ipa: ERROR: The default users group cannot be removed or modified A buch of tests in test_automember_plugin.py is failing because of this bug too. Martin From mkosek at redhat.com Tue Jan 17 08:53:35 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Jan 2012 09:53:35 +0100 Subject: [Freeipa-devel] [PATCH] 916 make category and members mutually exclusive in Sudo In-Reply-To: <4F14E8E2.5030305@redhat.com> References: <4EE67CDC.8010603@redhat.com> <1326719661.3319.36.camel@balmora.brq.redhat.com> <4F1452A4.6090208@redhat.com> <4F14E8E2.5030305@redhat.com> Message-ID: <1326790415.3012.9.camel@balmora.brq.redhat.com> On Mon, 2012-01-16 at 22:20 -0500, Rob Crittenden wrote: > Rob Crittenden wrote: > > Martin Kosek wrote: > >> On Mon, 2011-12-12 at 17:14 -0500, Rob Crittenden wrote: > >>> This patch makes all categories and their equivalent members mutually > >>> exclusive like in the HBAC plugin. So if you have usercat='all' you > >>> can't add users. > >>> > >>> Added test cases for these as well. > >>> > >>> I also modified the default list of attributes to include the RunAs > >>> attributes. > >>> > >>> rob > >> > >> NACK. I see several issues in this patch: > >> > >> 1) Error messages should be internationalized since they can be read by > >> a user (this problem is in HBAC too) > >> > >> 2) All constructs like this one can be simplified (and thus made less > >> error prone). > >> > >> + if 'cmdcategory' in _entry_attrs and \ > >> + _entry_attrs['cmdcategory'][0].lower() == 'all': > >> + raise errors.MutuallyExclusiveError(reason="commands cannot be added > >> when command category='all'") > >> > >> can be changed to: > >> > >> + if _entry_attrs.get('cmdcategory', [''])[0].lower() == 'all': > >> + raise errors.MutuallyExclusiveError(...) > >> > >> I think the code would be then also more readable. > >> > >> 3) I think this code only works by an accident :-) > >> > >> + if ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') \ > >> + in _entry_attrs and \ > >> + (_entry_attrs['ipasudorunasusercategory'][0].lower() == 'all' or \ > >> + _entry_attrs['ipasudorunasgroupcategory'][0].lower() == 'all'): > >> + raise errors.MutuallyExclusiveError(reason="users cannot be added > >> when runAs user or runAs group category='all'") > >> > >> ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') simply > >> returns 'ipasudorunasusercategory'. Thus the check for > >> 'ipasudorunasgroupcategory' in _entry_attrs is not performed at all. > >> Thanks to this bug, user is then able to pass a runAsGroup to sudorule > >> with groupcat == 'all': > >> > >> # ipa sudorule-add foo --runasgroupcat=all > >> --------------------- > >> Added Sudo Rule "foo" > >> --------------------- > >> Rule name: foo > >> Enabled: TRUE > >> RunAs Group category: all > >> # ipa sudorule-add-runasuser foo --groups=admins > >> Rule name: foo > >> Enabled: TRUE > >> RunAs Group category: all > >> Groups of RunAs Users: admins > >> ------------------------- > >> Number of members added 1 > >> ------------------------- > >> > >> A change proposed in 1) could make the change simpler: > >> > >> + if _entry_attrs.get('ipasudorunasusercategory', [''])[0].lower() == > >> 'all' or \ > >> + _entry_attrs.get('ipasudorunasgroupcategory', [''])[0].lower() == > >> 'all': > >> + raise ... > >> > >> Martin > >> > >> > > > > Updated patch attached. Using the is_all() function instead. Opened > > separate ticket to internationalize HBAC exceptions, > > https://fedorahosted.org/freeipa/ticket/2267 > > > > rob > > Rebased against ipa-2-2. > > rob There are still few issues: 1) test_sudorule_plugin.py is missing in the new commit 2) The patch does not work for ipasudorunasusercategory or ipasudorunasgroupcategory as they are not in self.obj.default_attributes 3) I also saw some internal errors: # ipa sudorule-show foo --all dn: ipauniqueid=a0e84cda-40e5-11e1-a35b-00163e7228ea,cn=sudorules,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com Rule name: foo Enabled: TRUE User category: all RunAs Group category: all Groups of RunAs Users: admins ipauniqueid: a0e84cda-40e5-11e1-a35b-00163e7228ea objectclass: ipaassociation, ipasudorul # ipa sudorule-add-user foo --users=admin ipa: ERROR: an internal error has occurred # ipa sudorule-add-user foo --groups=admins ipa: ERROR: an internal error has occurred # ipa sudorule-mod foo --hostcat=all # ipa sudorule-add-host foo --hosts=`hostname` ipa: ERROR: an internal error has occurred Martin From mkosek at redhat.com Tue Jan 17 10:27:16 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Jan 2012 11:27:16 +0100 Subject: [Freeipa-devel] [PATCH] 192 Replace float with Decimal In-Reply-To: <1326484946.2354.0.camel@priserak> References: <1326484946.2354.0.camel@priserak> Message-ID: <1326796036.3012.14.camel@balmora.brq.redhat.com> On Fri, 2012-01-13 at 21:02 +0100, Martin Kosek wrote: > This patch fixes RHEL 6.2 build issue. > ---- > Having float type as a base type for floating point parameter in > ipalib introduces several issues, e.g. problem with representation > or value comparison. Python language provides Decimal type which > help overcome these issue. > > This patch replaces a float type with Decimal type in Float > parameter. A precision attribute was added to Float parameter that > can be used to limit a number of decimal places in parameter > representation. This approach fixes a problem with API.txt > validation where comparison of float values may fail on different > architectures due to float representation error. > > In order to safely transfer the parameter value over RPC it is > being converted to string which is then converted back to Decimal > number on server side. > > https://fedorahosted.org/freeipa/ticket/2260 > Sending an improved version of the patch with following major changes: 1) Float parameter was renamed to Decimal as it base type is different and would confuse users otherwise. 2) Parameter maxvalue, minvalue and default can be also passed as a string and not just as a decimal.Decimal value. Parameter definition is then much simpler. 3) LDAP backend encoder was enhanced to support this new type (it converts it to string just like a float value). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-192-2-replace-float-with-decimal.patch Type: text/x-patch Size: 33811 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 17 11:38:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Jan 2012 12:38:37 +0100 Subject: [Freeipa-devel] [PATCH] 192 Replace float with Decimal In-Reply-To: <1326796036.3012.14.camel@balmora.brq.redhat.com> References: <1326484946.2354.0.camel@priserak> <1326796036.3012.14.camel@balmora.brq.redhat.com> Message-ID: <1326800317.3012.16.camel@balmora.brq.redhat.com> On Tue, 2012-01-17 at 11:27 +0100, Martin Kosek wrote: > On Fri, 2012-01-13 at 21:02 +0100, Martin Kosek wrote: > > This patch fixes RHEL 6.2 build issue. > > ---- > > Having float type as a base type for floating point parameter in > > ipalib introduces several issues, e.g. problem with representation > > or value comparison. Python language provides Decimal type which > > help overcome these issue. > > > > This patch replaces a float type with Decimal type in Float > > parameter. A precision attribute was added to Float parameter that > > can be used to limit a number of decimal places in parameter > > representation. This approach fixes a problem with API.txt > > validation where comparison of float values may fail on different > > architectures due to float representation error. > > > > In order to safely transfer the parameter value over RPC it is > > being converted to string which is then converted back to Decimal > > number on server side. > > > > https://fedorahosted.org/freeipa/ticket/2260 > > > > Sending an improved version of the patch with following major changes: > > 1) Float parameter was renamed to Decimal as it base type is different > and would confuse users otherwise. > > 2) Parameter maxvalue, minvalue and default can be also passed as a > string and not just as a decimal.Decimal value. Parameter definition is > then much simpler. > > 3) LDAP backend encoder was enhanced to support this new type (it > converts it to string just like a float value). > > Martin I forgot to add an encoding rule to JSON xmlrpc server. This can be useful in a future when Decimal type is actually used for a real LDAP attribute. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-192-3-replace-float-with-decimal.patch Type: text/x-patch Size: 34560 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 17 13:59:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jan 2012 08:59:13 -0500 Subject: [Freeipa-devel] [PATCH] 916 make category and members mutually exclusive in Sudo In-Reply-To: <1326790415.3012.9.camel@balmora.brq.redhat.com> References: <4EE67CDC.8010603@redhat.com> <1326719661.3319.36.camel@balmora.brq.redhat.com> <4F1452A4.6090208@redhat.com> <4F14E8E2.5030305@redhat.com> <1326790415.3012.9.camel@balmora.brq.redhat.com> Message-ID: <4F157EB1.4060808@redhat.com> Martin Kosek wrote: > On Mon, 2012-01-16 at 22:20 -0500, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On Mon, 2011-12-12 at 17:14 -0500, Rob Crittenden wrote: >>>>> This patch makes all categories and their equivalent members mutually >>>>> exclusive like in the HBAC plugin. So if you have usercat='all' you >>>>> can't add users. >>>>> >>>>> Added test cases for these as well. >>>>> >>>>> I also modified the default list of attributes to include the RunAs >>>>> attributes. >>>>> >>>>> rob >>>> >>>> NACK. I see several issues in this patch: >>>> >>>> 1) Error messages should be internationalized since they can be read by >>>> a user (this problem is in HBAC too) >>>> >>>> 2) All constructs like this one can be simplified (and thus made less >>>> error prone). >>>> >>>> + if 'cmdcategory' in _entry_attrs and \ >>>> + _entry_attrs['cmdcategory'][0].lower() == 'all': >>>> + raise errors.MutuallyExclusiveError(reason="commands cannot be added >>>> when command category='all'") >>>> >>>> can be changed to: >>>> >>>> + if _entry_attrs.get('cmdcategory', [''])[0].lower() == 'all': >>>> + raise errors.MutuallyExclusiveError(...) >>>> >>>> I think the code would be then also more readable. >>>> >>>> 3) I think this code only works by an accident :-) >>>> >>>> + if ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') \ >>>> + in _entry_attrs and \ >>>> + (_entry_attrs['ipasudorunasusercategory'][0].lower() == 'all' or \ >>>> + _entry_attrs['ipasudorunasgroupcategory'][0].lower() == 'all'): >>>> + raise errors.MutuallyExclusiveError(reason="users cannot be added >>>> when runAs user or runAs group category='all'") >>>> >>>> ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') simply >>>> returns 'ipasudorunasusercategory'. Thus the check for >>>> 'ipasudorunasgroupcategory' in _entry_attrs is not performed at all. >>>> Thanks to this bug, user is then able to pass a runAsGroup to sudorule >>>> with groupcat == 'all': >>>> >>>> # ipa sudorule-add foo --runasgroupcat=all >>>> --------------------- >>>> Added Sudo Rule "foo" >>>> --------------------- >>>> Rule name: foo >>>> Enabled: TRUE >>>> RunAs Group category: all >>>> # ipa sudorule-add-runasuser foo --groups=admins >>>> Rule name: foo >>>> Enabled: TRUE >>>> RunAs Group category: all >>>> Groups of RunAs Users: admins >>>> ------------------------- >>>> Number of members added 1 >>>> ------------------------- >>>> >>>> A change proposed in 1) could make the change simpler: >>>> >>>> + if _entry_attrs.get('ipasudorunasusercategory', [''])[0].lower() == >>>> 'all' or \ >>>> + _entry_attrs.get('ipasudorunasgroupcategory', [''])[0].lower() == >>>> 'all': >>>> + raise ... >>>> >>>> Martin >>>> >>>> >>> >>> Updated patch attached. Using the is_all() function instead. Opened >>> separate ticket to internationalize HBAC exceptions, >>> https://fedorahosted.org/freeipa/ticket/2267 >>> >>> rob >> >> Rebased against ipa-2-2. >> >> rob > > There are still few issues: > > 1) test_sudorule_plugin.py is missing in the new commit > > 2) The patch does not work for ipasudorunasusercategory or > ipasudorunasgroupcategory as they are not in self.obj.default_attributes > > 3) I also saw some internal errors: > > # ipa sudorule-show foo --all > dn: > ipauniqueid=a0e84cda-40e5-11e1-a35b-00163e7228ea,cn=sudorules,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > Rule name: foo > Enabled: TRUE > User category: all > RunAs Group category: all > Groups of RunAs Users: admins > ipauniqueid: a0e84cda-40e5-11e1-a35b-00163e7228ea > objectclass: ipaassociation, ipasudorul > > # ipa sudorule-add-user foo --users=admin > ipa: ERROR: an internal error has occurred > > # ipa sudorule-add-user foo --groups=admins > ipa: ERROR: an internal error has occurred > > # ipa sudorule-mod foo --hostcat=all > # ipa sudorule-add-host foo --hosts=`hostname` > ipa: ERROR: an internal error has occurred > > Martin > Somehow sent the wrong version of the patch. This one should be better. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-916-3-sudo.patch Type: text/x-diff Size: 13426 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 17 14:13:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jan 2012 09:13:44 -0500 Subject: [Freeipa-devel] [PATCH] 926 fix s4u2proxy update file Message-ID: <4F158218.9050108@redhat.com> I used the wrong template variable for hosts. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-926-s4u2proxy.patch Type: text/x-diff Size: 1174 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 17 14:23:34 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jan 2012 09:23:34 -0500 Subject: [Freeipa-devel] [PATCH] 917 user automember for ipa default user In-Reply-To: <1326788912.3012.4.camel@balmora.brq.redhat.com> References: <4EE6CF82.5010609@redhat.com> <4EE6CFEF.8010606@redhat.com> <1326725590.3319.54.camel@balmora.brq.redhat.com> <4F148C0E.4030008@redhat.com> <1326788912.3012.4.camel@balmora.brq.redhat.com> Message-ID: <4F158466.9050601@redhat.com> Martin Kosek wrote: > On Mon, 2012-01-16 at 15:43 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Mon, 2011-12-12 at 23:09 -0500, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Rather than manually adding users to the default ipa users group >>>>> configure automember to do it for us. >>>>> >>>>> This was quite simple for new installs but a bit complex on upgrades so >>>>> I implemented it as an update plugin. >>>>> >>>>> I also added a unit test for the config module. The majority of config >>>>> is ignored for now. I'm afraid we'd run into too many false positives if >>>>> we test each element, and most of these just store data so there isn't a >>>>> lot that can go wrong. >>>>> >>>>> rob >>>> >>>> Small revision. I wasn't shipping the update plugin. >>>> >>>> rob >>> >>> I have few minor-ish issues: >>> >>> 0) I was thinking if this new approach for assignment of ipa default >>> users is safe enough. If user accidentally mess with automember and >>> modifies/deletes the default group rule, new users may be omitted from >>> the default group set in IPA config. Are we sure that we are OK with >>> this? >> >> I made some stricter tests that don't allow users to manage the >> conditions of the default users group nor use an existing rule with >> conditions for the default users group. >> >>> 1) Several tests are provided with a hard-code basedn >>> (dc=greyoak,dc=com). api.env.basedn would a better choice >> >> Ouch, fixed. >> >>> 2) We could optimize user.py not to retrieve config from LDAP since it >>> is now needed only when api.env.wait_for_attr is now. I think this may >>> speedup the command a little bit: >>> ... >>> # Automember adds our user to the default group for us. >>> if self.api.env.wait_for_attr: >>> config = ldap.get_ipa_config()[1] >>> def_primary_group = config.get('ipadefaultprimarygroup') >>> newentry = wait_for_value(ldap, dn, 'memberOf', >>> def_primary_group) >>> entry_from_entry(entry_attrs, newentry) >>> ... >> >> Ok, that's a good idea. I think this path is going to go away soon >> though once we have transactions in 389-ds. >> >> rob >> > > Thanks, it safer now. We just have to fix ipa-server-install too: > > # ipa-server-install > ... > [12/13]: restarting httpd > [13/13]: configuring httpd to start on boot > done configuring httpd. > Applying LDAP updates > Unexpected error - see ipaserver-install.log for details: > The default users group cannot be removed or modified > > There is also a bug in is_default_users group - all non-group automember > rules are rejected: > > # ipa hostgroup-add --desc="Web Servers" webservers > ---------------------------- > Added hostgroup "webservers" > ---------------------------- > Host-group: webservers > Description: Web Servers > # ipa automember-add --type=hostgroup webservers > ---------------------------------- > Added automember rule "webservers" > ---------------------------------- > Automember Rule: webservers > # ipa automember-add-condition --key=fqdn --type=hostgroup > --inclusive-regex=^web[1-9]+\.example\.com webservers > ipa: ERROR: The default users group cannot be removed or modified > > A buch of tests in test_automember_plugin.py is failing because of this > bug too. > > Martin > Ah, I was just running the config tests :-( The is_default_users_group() was trivial and fixed all but two tests. It did however show a potentially fatal problem to the patch. If we use automember for users then the default group will NEVER get used because we guarantee that users are always added to one automember group (ipausers). This sort of defeats the purpose of being able to set a default group. So I'm thinking we'll need to drop this patch. rob From jcholast at redhat.com Tue Jan 17 15:12:13 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 Jan 2012 16:12:13 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F149069.4060704@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> Message-ID: <4F158FCD.4040604@redhat.com> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>> When viewing a certificate it will show the serial number as hex (dec). >>>> >>>> # ipa service-show HTTP/rawhide.example.com >>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>> Certificate: [snip] >>>> Keytab: True >>>> Managed by: rawhide.example.com >>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>> Serial Number: 0x403 (1027) >>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>> Fingerprint (SHA1): >>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>> >>>> rob >>>> >>> >>> NACK >>> >>> Displaying a host or a service in the webUI fails with "IPA error 3009: >>> invalid 'serial_number': Decimal or hexadecimal number is required for >>> serial number". >>> >>> I would suggest to do the nifty formatting of serial numbers on the >>> client side, that would fix the webUI issue, allow non-IPA clients to >>> parse the number without dissecting the string representation of it and >>> probably also save me a hack in the type conversion overhaul. You could >>> for example add a parameter flag like "format_serial_number" to indicate >>> to the client that it should format the value as a serial number. >>> >>> Honza >>> >> >> Well, we want to do as little client formatting as possible. The idea is >> to have a very thin client. It doesn't seem right to me to enforce this specific representation of what is really just an integer at the API level. Doing a little formatting on the client side won't make the client(s) particularly fat, will it? IMHO there is too much stuff done on server that would make more sense to do on client anyway (especially CLI-specific stuff such as CSV parsing). What is the reason we want such a thin client? I believe there should be clear separation of presentation and content, but perhaps I'm a little bit too idealistic :-). >> >> I'll look into fixing the UI side. > > I don't see this error in services, it displays correctly. I'm not sure > if it is my browser or what but hosts don't display much of anything for > me. > > rob I have just checked both master and ipa-2-2 and I'm getting the same error message (tested in Firefox 9.0.1) when viewing details of a host or a service with the usercertificate attribute set. BTW, wouldn't it make sense to format serial numbers in the cert plugin in the same way? Honza -- Jan Cholasta From edewata at redhat.com Tue Jan 17 15:13:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 17 Jan 2012 09:13:57 -0600 Subject: [Freeipa-devel] [PATCH] 068 UI for SELinux user mapping In-Reply-To: <4F104690.8020508@redhat.com> References: <4F104690.8020508@redhat.com> Message-ID: <4F159035.50400@redhat.com> On 1/13/2012 8:58 AM, Petr Vobornik wrote: > This patch adds UI for SELinux user mapping. Its design is based on HBAC > Rule design. > > https://fedorahosted.org/freeipa/ticket/2145 > > Probably some labels and menu position should be changed. > > Live demo with limited functionality is at > http://pvoborni.fedorapeople.org/selinuxusermap/#policy=selinuxusermap&navigation=policy > > > Note: the patch is zipped because it has 760KB (update of metadata .json > files) One issue, the selinux.js is not installed. It needs to be included in Makefile.am. Other than that it's ACKed, feel free to push after fixing it. -- Endi S. Dewata From edewata at redhat.com Tue Jan 17 15:19:11 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 17 Jan 2012 09:19:11 -0600 Subject: [Freeipa-devel] [PATCH] 068 UI for SELinux user mapping In-Reply-To: <4F104690.8020508@redhat.com> References: <4F104690.8020508@redhat.com> Message-ID: <4F15916F.2080604@redhat.com> On 1/13/2012 8:58 AM, Petr Vobornik wrote: > This patch adds UI for SELinux user mapping. Its design is based on HBAC > Rule design. > > https://fedorahosted.org/freeipa/ticket/2145 > > Probably some labels and menu position should be changed. > > Live demo with limited functionality is at > http://pvoborni.fedorapeople.org/selinuxusermap/#policy=selinuxusermap&navigation=policy > > > Note: the patch is zipped because it has 760KB (update of metadata .json > files) One issue, the selinux.js is not installed. It needs to be included in Makefile.am. Other than that it's ACKed, feel free to push after fixing it. -- Endi S. Dewata From edewata at redhat.com Tue Jan 17 15:36:03 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 17 Jan 2012 09:36:03 -0600 Subject: [Freeipa-devel] [PATCH] [WIP] 069 Added refresh button for UI In-Reply-To: <4F142E12.9000009@redhat.com> References: <4F142E12.9000009@redhat.com> Message-ID: <4F159563.1050109@redhat.com> On 1/16/2012 8:02 AM, Petr Vobornik wrote: > 1) Button position: > I added the button into facet header next to 'add', 'delete', 'reset', > 'update' buttons as shown on the picture ( > http://pvoborni.fedorapeople.org/images/2051-refresh-button.png ). I'm > not sure if it's the right position. I can also imagine it somewhere in > the page header - in the green area on the right on the top main menu > (Identity, Policy...) level. I think it's the right place, but UXD might have some idea about the button order. > 2) Button icon: > I used reset button icon. This is not good because in details facet > reset and refresh button have the same icon. > I think this icon is more suitable for refresh button and reset button > should get new icon (maybe with reverse direction of the arrow). > > Probably we should ask UXD for opinion and icon. Yeah, maybe the Reset button probably should look like an Undo button: http://www.iconarchive.com/show/must-have-icons-by-visualpharm/Undo-icon.html The code is ACKed, feel free to push after feedback from UXD. -- Endi S. Dewata From mkosek at redhat.com Tue Jan 17 16:52:33 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Jan 2012 17:52:33 +0100 Subject: [Freeipa-devel] [PATCH] 926 fix s4u2proxy update file In-Reply-To: <4F158218.9050108@redhat.com> References: <4F158218.9050108@redhat.com> Message-ID: <1326819153.3012.19.camel@balmora.brq.redhat.com> On Tue, 2012-01-17 at 09:13 -0500, Rob Crittenden wrote: > I used the wrong template variable for hosts. > > rob ACK. Works fine now. Pushed to master, ipa-2-2. Martin From rcritten at redhat.com Tue Jan 17 21:37:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jan 2012 16:37:20 -0500 Subject: [Freeipa-devel] [PATCH 61] Cache authentication in session In-Reply-To: <4F0F90F2.40403@redhat.com> References: <4F0F90F2.40403@redhat.com> Message-ID: <4F15EA10.7010206@redhat.com> John Dennis wrote: > Both of these are defined in ipalib/rpc.py (among others): +KRB5_CC_NOTFOUND = -1765328243 # Matching credential not found +KRB5_FCC_NOFILE = -1765328189 # No credentials cache found Perhaps all those defines should be moved to krb_utils.py. RPM build errors on non-SysV systems: File listed twice: /usr/share/ipa/ui/extension.js Installed (but unpackaged) file(s) found: /etc/rc.d/init.d/ipa_memcached make: *** [rpms] Error 1 (extention.js isn't yours) In the ipa_memcached service PID_PATH needs to be PIDFILE. It would be nice if sessions worked with the lite-server. I am unable to view the web UI. It just loops requesting all the the javascript files over and over again. rob From rcritten at redhat.com Tue Jan 17 22:59:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jan 2012 17:59:15 -0500 Subject: [Freeipa-devel] [PATCH] 927 fix deleting hbac rules when selinux user maps are involved Message-ID: <4F15FD43.5000402@redhat.com> When deleting an HBAC rule we need to ensure that an SELinux user map isn't pointing at it. The search for this didn't work well at all. This patch corrects the search and makes it more specific. I also tested that it works with the --continue flag of hbacrule-del. The ticket has instructions on testing. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-927-selinux.patch Type: text/x-diff Size: 5245 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 17 23:04:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jan 2012 18:04:03 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F158FCD.4040604@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> Message-ID: <4F15FE63.8090209@redhat.com> Jan Cholasta wrote: > Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>> When viewing a certificate it will show the serial number as hex >>>>> (dec). >>>>> >>>>> # ipa service-show HTTP/rawhide.example.com >>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>> Certificate: [snip] >>>>> Keytab: True >>>>> Managed by: rawhide.example.com >>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>> Serial Number: 0x403 (1027) >>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>> Fingerprint (SHA1): >>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>> >>>>> rob >>>>> >>>> >>>> NACK >>>> >>>> Displaying a host or a service in the webUI fails with "IPA error 3009: >>>> invalid 'serial_number': Decimal or hexadecimal number is required for >>>> serial number". >>>> >>>> I would suggest to do the nifty formatting of serial numbers on the >>>> client side, that would fix the webUI issue, allow non-IPA clients to >>>> parse the number without dissecting the string representation of it and >>>> probably also save me a hack in the type conversion overhaul. You could >>>> for example add a parameter flag like "format_serial_number" to >>>> indicate >>>> to the client that it should format the value as a serial number. >>>> >>>> Honza >>>> >>> >>> Well, we want to do as little client formatting as possible. The idea is >>> to have a very thin client. > > It doesn't seem right to me to enforce this specific representation of > what is really just an integer at the API level. Doing a little > formatting on the client side won't make the client(s) particularly fat, > will it? Yes. The current code just outputs labels and data. There is no "if it is this attribute then do that" logic. > > IMHO there is too much stuff done on server that would make more sense > to do on client anyway (especially CLI-specific stuff such as CSV > parsing). What is the reason we want such a thin client? To avoid double work such that every time we want a formatting change we have to change it in multiple places. This lesson was learned in v1. > I believe there should be clear separation of presentation and content, > but perhaps I'm a little bit too idealistic :-). You have a point, serial number is defined as an integer. Perhaps we should revisit this decision to display hex at all. > >>> >>> I'll look into fixing the UI side. >> >> I don't see this error in services, it displays correctly. I'm not sure >> if it is my browser or what but hosts don't display much of anything for >> me. >> >> rob > > I have just checked both master and ipa-2-2 and I'm getting the same > error message (tested in Firefox 9.0.1) when viewing details of a host > or a service with the usercertificate attribute set. > > BTW, wouldn't it make sense to format serial numbers in the cert plugin > in the same way? Perhaps. Like I said, I'm not really in favor of this change. rob From mkosek at redhat.com Wed Jan 18 09:04:44 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jan 2012 10:04:44 +0100 Subject: [Freeipa-devel] [PATCH] 916 make category and members mutually exclusive in Sudo In-Reply-To: <4F157EB1.4060808@redhat.com> References: <4EE67CDC.8010603@redhat.com> <1326719661.3319.36.camel@balmora.brq.redhat.com> <4F1452A4.6090208@redhat.com> <4F14E8E2.5030305@redhat.com> <1326790415.3012.9.camel@balmora.brq.redhat.com> <4F157EB1.4060808@redhat.com> Message-ID: <1326877484.12447.2.camel@balmora.brq.redhat.com> On Tue, 2012-01-17 at 08:59 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2012-01-16 at 22:20 -0500, Rob Crittenden wrote: > >> Rob Crittenden wrote: > >>> Martin Kosek wrote: > >>>> On Mon, 2011-12-12 at 17:14 -0500, Rob Crittenden wrote: > >>>>> This patch makes all categories and their equivalent members mutually > >>>>> exclusive like in the HBAC plugin. So if you have usercat='all' you > >>>>> can't add users. > >>>>> > >>>>> Added test cases for these as well. > >>>>> > >>>>> I also modified the default list of attributes to include the RunAs > >>>>> attributes. > >>>>> > >>>>> rob > >>>> > >>>> NACK. I see several issues in this patch: > >>>> > >>>> 1) Error messages should be internationalized since they can be read by > >>>> a user (this problem is in HBAC too) > >>>> > >>>> 2) All constructs like this one can be simplified (and thus made less > >>>> error prone). > >>>> > >>>> + if 'cmdcategory' in _entry_attrs and \ > >>>> + _entry_attrs['cmdcategory'][0].lower() == 'all': > >>>> + raise errors.MutuallyExclusiveError(reason="commands cannot be added > >>>> when command category='all'") > >>>> > >>>> can be changed to: > >>>> > >>>> + if _entry_attrs.get('cmdcategory', [''])[0].lower() == 'all': > >>>> + raise errors.MutuallyExclusiveError(...) > >>>> > >>>> I think the code would be then also more readable. > >>>> > >>>> 3) I think this code only works by an accident :-) > >>>> > >>>> + if ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') \ > >>>> + in _entry_attrs and \ > >>>> + (_entry_attrs['ipasudorunasusercategory'][0].lower() == 'all' or \ > >>>> + _entry_attrs['ipasudorunasgroupcategory'][0].lower() == 'all'): > >>>> + raise errors.MutuallyExclusiveError(reason="users cannot be added > >>>> when runAs user or runAs group category='all'") > >>>> > >>>> ('ipasudorunasusercategory' or 'ipasudorunasgroupcategory') simply > >>>> returns 'ipasudorunasusercategory'. Thus the check for > >>>> 'ipasudorunasgroupcategory' in _entry_attrs is not performed at all. > >>>> Thanks to this bug, user is then able to pass a runAsGroup to sudorule > >>>> with groupcat == 'all': > >>>> > >>>> # ipa sudorule-add foo --runasgroupcat=all > >>>> --------------------- > >>>> Added Sudo Rule "foo" > >>>> --------------------- > >>>> Rule name: foo > >>>> Enabled: TRUE > >>>> RunAs Group category: all > >>>> # ipa sudorule-add-runasuser foo --groups=admins > >>>> Rule name: foo > >>>> Enabled: TRUE > >>>> RunAs Group category: all > >>>> Groups of RunAs Users: admins > >>>> ------------------------- > >>>> Number of members added 1 > >>>> ------------------------- > >>>> > >>>> A change proposed in 1) could make the change simpler: > >>>> > >>>> + if _entry_attrs.get('ipasudorunasusercategory', [''])[0].lower() == > >>>> 'all' or \ > >>>> + _entry_attrs.get('ipasudorunasgroupcategory', [''])[0].lower() == > >>>> 'all': > >>>> + raise ... > >>>> > >>>> Martin > >>>> > >>>> > >>> > >>> Updated patch attached. Using the is_all() function instead. Opened > >>> separate ticket to internationalize HBAC exceptions, > >>> https://fedorahosted.org/freeipa/ticket/2267 > >>> > >>> rob > >> > >> Rebased against ipa-2-2. > >> > >> rob > > > > There are still few issues: > > > > 1) test_sudorule_plugin.py is missing in the new commit > > > > 2) The patch does not work for ipasudorunasusercategory or > > ipasudorunasgroupcategory as they are not in self.obj.default_attributes > > > > 3) I also saw some internal errors: > > > > # ipa sudorule-show foo --all > > dn: > > ipauniqueid=a0e84cda-40e5-11e1-a35b-00163e7228ea,cn=sudorules,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > Rule name: foo > > Enabled: TRUE > > User category: all > > RunAs Group category: all > > Groups of RunAs Users: admins > > ipauniqueid: a0e84cda-40e5-11e1-a35b-00163e7228ea > > objectclass: ipaassociation, ipasudorul > > > > # ipa sudorule-add-user foo --users=admin > > ipa: ERROR: an internal error has occurred > > > > # ipa sudorule-add-user foo --groups=admins > > ipa: ERROR: an internal error has occurred > > > > # ipa sudorule-mod foo --hostcat=all > > # ipa sudorule-add-host foo --hosts=`hostname` > > ipa: ERROR: an internal error has occurred > > > > Martin > > > > Somehow sent the wrong version of the patch. This one should be better. > > rob Yes, its much better. Works fine, ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Wed Jan 18 09:06:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jan 2012 10:06:39 +0100 Subject: [Freeipa-devel] [PATCH] 917 user automember for ipa default user In-Reply-To: <4F158466.9050601@redhat.com> References: <4EE6CF82.5010609@redhat.com> <4EE6CFEF.8010606@redhat.com> <1326725590.3319.54.camel@balmora.brq.redhat.com> <4F148C0E.4030008@redhat.com> <1326788912.3012.4.camel@balmora.brq.redhat.com> <4F158466.9050601@redhat.com> Message-ID: <1326877599.12447.3.camel@balmora.brq.redhat.com> On Tue, 2012-01-17 at 09:23 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2012-01-16 at 15:43 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Mon, 2011-12-12 at 23:09 -0500, Rob Crittenden wrote: > >>>> Rob Crittenden wrote: > >>>>> Rather than manually adding users to the default ipa users group > >>>>> configure automember to do it for us. > >>>>> > >>>>> This was quite simple for new installs but a bit complex on upgrades so > >>>>> I implemented it as an update plugin. > >>>>> > >>>>> I also added a unit test for the config module. The majority of config > >>>>> is ignored for now. I'm afraid we'd run into too many false positives if > >>>>> we test each element, and most of these just store data so there isn't a > >>>>> lot that can go wrong. > >>>>> > >>>>> rob > >>>> > >>>> Small revision. I wasn't shipping the update plugin. > >>>> > >>>> rob > >>> > >>> I have few minor-ish issues: > >>> > >>> 0) I was thinking if this new approach for assignment of ipa default > >>> users is safe enough. If user accidentally mess with automember and > >>> modifies/deletes the default group rule, new users may be omitted from > >>> the default group set in IPA config. Are we sure that we are OK with > >>> this? > >> > >> I made some stricter tests that don't allow users to manage the > >> conditions of the default users group nor use an existing rule with > >> conditions for the default users group. > >> > >>> 1) Several tests are provided with a hard-code basedn > >>> (dc=greyoak,dc=com). api.env.basedn would a better choice > >> > >> Ouch, fixed. > >> > >>> 2) We could optimize user.py not to retrieve config from LDAP since it > >>> is now needed only when api.env.wait_for_attr is now. I think this may > >>> speedup the command a little bit: > >>> ... > >>> # Automember adds our user to the default group for us. > >>> if self.api.env.wait_for_attr: > >>> config = ldap.get_ipa_config()[1] > >>> def_primary_group = config.get('ipadefaultprimarygroup') > >>> newentry = wait_for_value(ldap, dn, 'memberOf', > >>> def_primary_group) > >>> entry_from_entry(entry_attrs, newentry) > >>> ... > >> > >> Ok, that's a good idea. I think this path is going to go away soon > >> though once we have transactions in 389-ds. > >> > >> rob > >> > > > > Thanks, it safer now. We just have to fix ipa-server-install too: > > > > # ipa-server-install > > ... > > [12/13]: restarting httpd > > [13/13]: configuring httpd to start on boot > > done configuring httpd. > > Applying LDAP updates > > Unexpected error - see ipaserver-install.log for details: > > The default users group cannot be removed or modified > > > > There is also a bug in is_default_users group - all non-group automember > > rules are rejected: > > > > # ipa hostgroup-add --desc="Web Servers" webservers > > ---------------------------- > > Added hostgroup "webservers" > > ---------------------------- > > Host-group: webservers > > Description: Web Servers > > # ipa automember-add --type=hostgroup webservers > > ---------------------------------- > > Added automember rule "webservers" > > ---------------------------------- > > Automember Rule: webservers > > # ipa automember-add-condition --key=fqdn --type=hostgroup > > --inclusive-regex=^web[1-9]+\.example\.com webservers > > ipa: ERROR: The default users group cannot be removed or modified > > > > A buch of tests in test_automember_plugin.py is failing because of this > > bug too. > > > > Martin > > > > Ah, I was just running the config tests :-( > > The is_default_users_group() was trivial and fixed all but two tests. It > did however show a potentially fatal problem to the patch. > > If we use automember for users then the default group will NEVER get > used because we guarantee that users are always added to one automember > group (ipausers). This sort of defeats the purpose of being able to set > a default group. So I'm thinking we'll need to drop this patch. > > rob That's true. It seems that our current approach for adding users to default group is not that bad after all. Martin From jcholast at redhat.com Wed Jan 18 10:37:47 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 Jan 2012 11:37:47 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F15FE63.8090209@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> Message-ID: <4F16A0FB.9080808@redhat.com> Dne 18.1.2012 00:04, Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>> Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>> When viewing a certificate it will show the serial number as hex >>>>>> (dec). >>>>>> >>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>> Certificate: [snip] >>>>>> Keytab: True >>>>>> Managed by: rawhide.example.com >>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>> Serial Number: 0x403 (1027) >>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>> Fingerprint (SHA1): >>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> NACK >>>>> >>>>> Displaying a host or a service in the webUI fails with "IPA error >>>>> 3009: >>>>> invalid 'serial_number': Decimal or hexadecimal number is required for >>>>> serial number". >>>>> >>>>> I would suggest to do the nifty formatting of serial numbers on the >>>>> client side, that would fix the webUI issue, allow non-IPA clients to >>>>> parse the number without dissecting the string representation of it >>>>> and >>>>> probably also save me a hack in the type conversion overhaul. You >>>>> could >>>>> for example add a parameter flag like "format_serial_number" to >>>>> indicate >>>>> to the client that it should format the value as a serial number. >>>>> >>>>> Honza >>>>> >>>> >>>> Well, we want to do as little client formatting as possible. The >>>> idea is >>>> to have a very thin client. >> >> It doesn't seem right to me to enforce this specific representation of >> what is really just an integer at the API level. Doing a little >> formatting on the client side won't make the client(s) particularly fat, >> will it? > > Yes. The current code just outputs labels and data. There is no "if it > is this attribute then do that" logic. > >> >> IMHO there is too much stuff done on server that would make more sense >> to do on client anyway (especially CLI-specific stuff such as CSV >> parsing). What is the reason we want such a thin client? > > To avoid double work such that every time we want a formatting change we > have to change it in multiple places. This lesson was learned in v1. > >> I believe there should be clear separation of presentation and content, >> but perhaps I'm a little bit too idealistic :-). > > You have a point, serial number is defined as an integer. Perhaps we > should revisit this decision to display hex at all. > > >> >>>> >>>> I'll look into fixing the UI side. >>> >>> I don't see this error in services, it displays correctly. I'm not sure >>> if it is my browser or what but hosts don't display much of anything for >>> me. >>> >>> rob >> >> I have just checked both master and ipa-2-2 and I'm getting the same >> error message (tested in Firefox 9.0.1) when viewing details of a host >> or a service with the usercertificate attribute set. >> >> BTW, wouldn't it make sense to format serial numbers in the cert plugin >> in the same way? > > Perhaps. Like I said, I'm not really in favor of this change. > > rob Maybe we can do a compromise of some sort. What about allowing the client to specify with each request what representation/formatting the server should use for the resulting entries and attributes? Honza -- Jan Cholasta From pvoborni at redhat.com Wed Jan 18 16:16:57 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 18 Jan 2012 17:16:57 +0100 Subject: [Freeipa-devel] [PATCH] 068 UI for SELinux user mapping In-Reply-To: <4F159035.50400@redhat.com> References: <4F104690.8020508@redhat.com> <4F159035.50400@redhat.com> Message-ID: <4F16F079.5070700@redhat.com> On 01/17/2012 04:13 PM, Endi Sukma Dewata wrote: > On 1/13/2012 8:58 AM, Petr Vobornik wrote: >> This patch adds UI for SELinux user mapping. Its design is based on HBAC >> Rule design. >> >> https://fedorahosted.org/freeipa/ticket/2145 > > One issue, the selinux.js is not installed. It needs to be included in > Makefile.am. Other than that it's ACKed, feel free to push after fixing it. > Fixed, pushed to master, ipa-2-2 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0068-1-UI-for-SELinux-user-mapping.patch.zip Type: application/zip Size: 36178 bytes Desc: not available URL: From edewata at redhat.com Wed Jan 18 16:21:39 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 18 Jan 2012 10:21:39 -0600 Subject: [Freeipa-devel] [PATCH] 340 Enabled paging on automount keys. Message-ID: <4F16F193.30300@redhat.com> The automount keys search facet has been modified to support paging. Since the automountkey-find command doesn't support --pkey-only option, the facet is configured such that during a refresh operation it will retrieve all entries (including the key and info attributes) and then display only the ones that are supposed to be visible in the current page. Ticket #2093 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0340-Enabled-paging-on-automount-keys.patch Type: text/x-patch Size: 15965 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 19 00:44:00 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 18 Jan 2012 18:44:00 -0600 Subject: [Freeipa-devel] [PATCH] 340 Enabled paging on automount keys. In-Reply-To: <4F16F193.30300@redhat.com> References: <4F16F193.30300@redhat.com> Message-ID: <4F176750.9060500@redhat.com> On 1/18/2012 10:21 AM, Endi Sukma Dewata wrote: > The automount keys search facet has been modified to support paging. > Since the automountkey-find command doesn't support --pkey-only > option, the facet is configured such that during a refresh operation > it will retrieve all entries (including the key and info attributes) > and then display only the ones that are supposed to be visible in > the current page. > > Ticket #2093 New patch attached. Some attributes weren't renamed properly. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0340-1-Enabled-paging-on-automount-keys.patch Type: text/x-patch Size: 16525 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 19 00:48:58 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 18 Jan 2012 18:48:58 -0600 Subject: [Freeipa-devel] [PATCH] 341 Show disabled entries in gray. Message-ID: <4F17687A.9010504@redhat.com> The users, HBAC/sudo rules, HBAC test, and SELinux list pages have been modified to show disabled entries in gray. Icons will be added separately. Ticket #1996 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0341-Show-disabled-entries-in-gray.patch Type: text/x-patch Size: 22460 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 19 06:04:06 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 19 Jan 2012 00:04:06 -0600 Subject: [Freeipa-devel] [PATCH] 342 Fixed inconsistent status labels. Message-ID: <4F17B256.4090606@redhat.com> This patch modifies the status attributes in users, DNS zones, HBAC/sudo rules, HBAC test, and SELinux User Map to use the same label (i.e. Status) and values (i.e. Enabled/Disabled). The method to change the status will be modified separately. Ticket #2247 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0342-Fixed-inconsistent-status-labels.patch Type: text/x-patch Size: 23032 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 19 13:55:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jan 2012 14:55:24 +0100 Subject: [Freeipa-devel] [PATCH] 193 Mark optional DNS record parts Message-ID: <1326981324.24237.20.camel@balmora.brq.redhat.com> This patch is needed for ticket 2208 (UI for new DNS interface) so that UI can distinguish between required and optional DNS part params. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-193-mark-optional-dns-record-parts.patch Type: text/x-patch Size: 2668 bytes Desc: not available URL: From ayoung at redhat.com Thu Jan 19 20:55:54 2012 From: ayoung at redhat.com (Adam Young) Date: Thu, 19 Jan 2012 15:55:54 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 069 Added refresh button for UI In-Reply-To: <4F159563.1050109@redhat.com> References: <4F142E12.9000009@redhat.com> <4F159563.1050109@redhat.com> Message-ID: <4F18835A.6020907@redhat.com> On 01/17/2012 10:36 AM, Endi Sukma Dewata wrote: > On 1/16/2012 8:02 AM, Petr Vobornik wrote: >> 1) Button position: >> I added the button into facet header next to 'add', 'delete', 'reset', >> 'update' buttons as shown on the picture ( >> http://pvoborni.fedorapeople.org/images/2051-refresh-button.png ). I'm >> not sure if it's the right position. I can also imagine it somewhere in >> the page header - in the green area on the right on the top main menu >> (Identity, Policy...) level. > > I think it's the right place, but UXD might have some idea about the > button order. > >> 2) Button icon: >> I used reset button icon. This is not good because in details facet >> reset and refresh button have the same icon. >> I think this icon is more suitable for refresh button and reset button >> should get new icon (maybe with reverse direction of the arrow). >> >> Probably we should ask UXD for opinion and icon. > > Yeah, maybe the Reset button probably should look like an Undo button: > http://www.iconarchive.com/show/must-have-icons-by-visualpharm/Undo-icon.html > > > The code is ACKed, feel free to push after feedback from UXD. > I think we should be clear that this is a "reload the data" and not "Refresh the UI" as there is already a rather prominant button to do the latter.... From rcritten at redhat.com Thu Jan 19 21:56:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jan 2012 16:56:10 -0500 Subject: [Freeipa-devel] [PATCH] 928 fix automount submounts Message-ID: <4F18917A.90205@redhat.com> There is a --parentmap option in automountmap-add-indirect. This is used to create submount maps but wasn't working at all. It now creates the proper key entry pointing to another map. See ticket https://fedorahosted.org/freeipa/ticket/1268 for more details and examples. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-928-automount.patch Type: text/x-diff Size: 7494 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 19 22:08:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jan 2012 17:08:15 -0500 Subject: [Freeipa-devel] [PATCH] 192 Replace float with Decimal In-Reply-To: <1326800317.3012.16.camel@balmora.brq.redhat.com> References: <1326484946.2354.0.camel@priserak> <1326796036.3012.14.camel@balmora.brq.redhat.com> <1326800317.3012.16.camel@balmora.brq.redhat.com> Message-ID: <4F18944F.9010201@redhat.com> Martin Kosek wrote: > On Tue, 2012-01-17 at 11:27 +0100, Martin Kosek wrote: >> On Fri, 2012-01-13 at 21:02 +0100, Martin Kosek wrote: >>> This patch fixes RHEL 6.2 build issue. >>> ---- >>> Having float type as a base type for floating point parameter in >>> ipalib introduces several issues, e.g. problem with representation >>> or value comparison. Python language provides Decimal type which >>> help overcome these issue. >>> >>> This patch replaces a float type with Decimal type in Float >>> parameter. A precision attribute was added to Float parameter that >>> can be used to limit a number of decimal places in parameter >>> representation. This approach fixes a problem with API.txt >>> validation where comparison of float values may fail on different >>> architectures due to float representation error. >>> >>> In order to safely transfer the parameter value over RPC it is >>> being converted to string which is then converted back to Decimal >>> number on server side. >>> >>> https://fedorahosted.org/freeipa/ticket/2260 >>> >> >> Sending an improved version of the patch with following major changes: >> >> 1) Float parameter was renamed to Decimal as it base type is different >> and would confuse users otherwise. >> >> 2) Parameter maxvalue, minvalue and default can be also passed as a >> string and not just as a decimal.Decimal value. Parameter definition is >> then much simpler. >> >> 3) LDAP backend encoder was enhanced to support this new type (it >> converts it to string just like a float value). >> >> Martin > > I forgot to add an encoding rule to JSON xmlrpc server. This can be > useful in a future when Decimal type is actually used for a real LDAP > attribute. > > Martin ACK. This is fine API-wise because the data is transmitted as a string, so even if the client side defines the parameter as a Float it won't affect what the server receives. The only possible downside is that the precision requested on the client won't be honored on the server, but then again the server decides what level of precision we want to support. rob From rcritten at redhat.com Thu Jan 19 22:10:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jan 2012 17:10:12 -0500 Subject: [Freeipa-devel] [PATCH] 8 localhost.localdomain clients refused to join ipa domain In-Reply-To: <4F1412C0.3070204@redhat.com> References: <4F1412C0.3070204@redhat.com> Message-ID: <4F1894C4.4060704@redhat.com> Ondrej Hamada wrote: > https://fedorahosted.org/freeipa/ticket/2112 > > Machines with hostname 'localhost.localdomain' are refused from joining > IPA domain and proper error message is shown. This should probably check for just localhost as well. It is good that the check is done here as ipa-join can be run outside of ipa-client-install, but I wonder if it should be checked there as well. By the time that ipa-join is called the user is potentially prompted for a bunch of data whereas we could check the hostname very early in ipa-client-install. rob From rcritten at redhat.com Thu Jan 19 22:21:51 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jan 2012 17:21:51 -0500 Subject: [Freeipa-devel] [PATCH] 190 Fix ipa-server-install for dual NICs In-Reply-To: <1326485271.2354.3.camel@priserak> References: <1326195613.27400.14.camel@balmora.brq.redhat.com> <1326267331.9621.1.camel@balmora.brq.redhat.com> <4F105242.4010707@redhat.com> <1326485271.2354.3.camel@priserak> Message-ID: <4F18977F.6070407@redhat.com> Martin Kosek wrote: > On Fri, 2012-01-13 at 10:48 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> It seems I sent two patches with number 189. Sending a patch with a >>> correct number. >>> >>> Martin >>> >>> On Tue, 2012-01-10 at 12:40 +0100, Martin Kosek wrote: >>>> Depends on my patch 188 >>>> --- >>>> A server may have 2 or more NICs and its hostname may thus resolve >>>> to 2 and more forward addresses. IP address checks in install >>>> scripts does not expect this setup and may fail or crash. >>>> >>>> This script adds a support for multiple forward addresses for >>>> a hostname. The install scripts do not crash now. When one IP >>>> address is needed, user is asked to choose from all detected >>>> server IP addresses. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2154 >> >> You have a patch 190 already as well :-) > > Hm, yes :-) >> >> This appears to depend on another patch that I haven't applied yet. Can >> you see if it has unpushed dependencies? (removing the adtrust part was >> relatively easy and unrelated). >> >> rob > > It depended on patch 188 (it was written in the top of the mail). Since > it was pushed today, this patch should be applicable to master branch. I > checked it and it should be OK. > > Martin > Still not applying $ patch -p1 --dry-run < /tmp/freeipa-mkosek-190-fix-ipa-server-install-for-dual-nics.patch patching file install/tools/ipa-dns-install patching file install/tools/ipa-replica-conncheck patching file install/tools/ipa-replica-install patching file ipapython/dnsclient.py Hunk #3 FAILED at 404. 1 out of 3 hunks FAILED -- saving rejects to file ipapython/dnsclient.py.rej patching file ipaserver/install/bindinstance.py patching file ipaserver/install/installutils.py From mkosek at redhat.com Fri Jan 20 07:19:42 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jan 2012 08:19:42 +0100 Subject: [Freeipa-devel] [PATCH] 192 Replace float with Decimal In-Reply-To: <4F18944F.9010201@redhat.com> References: <1326484946.2354.0.camel@priserak> <1326796036.3012.14.camel@balmora.brq.redhat.com> <1326800317.3012.16.camel@balmora.brq.redhat.com> <4F18944F.9010201@redhat.com> Message-ID: <1327043982.2204.4.camel@priserak> On Thu, 2012-01-19 at 17:08 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2012-01-17 at 11:27 +0100, Martin Kosek wrote: > >> On Fri, 2012-01-13 at 21:02 +0100, Martin Kosek wrote: > >>> This patch fixes RHEL 6.2 build issue. > >>> ---- > >>> Having float type as a base type for floating point parameter in > >>> ipalib introduces several issues, e.g. problem with representation > >>> or value comparison. Python language provides Decimal type which > >>> help overcome these issue. > >>> > >>> This patch replaces a float type with Decimal type in Float > >>> parameter. A precision attribute was added to Float parameter that > >>> can be used to limit a number of decimal places in parameter > >>> representation. This approach fixes a problem with API.txt > >>> validation where comparison of float values may fail on different > >>> architectures due to float representation error. > >>> > >>> In order to safely transfer the parameter value over RPC it is > >>> being converted to string which is then converted back to Decimal > >>> number on server side. > >>> > >>> https://fedorahosted.org/freeipa/ticket/2260 > >>> > >> > >> Sending an improved version of the patch with following major changes: > >> > >> 1) Float parameter was renamed to Decimal as it base type is different > >> and would confuse users otherwise. > >> > >> 2) Parameter maxvalue, minvalue and default can be also passed as a > >> string and not just as a decimal.Decimal value. Parameter definition is > >> then much simpler. > >> > >> 3) LDAP backend encoder was enhanced to support this new type (it > >> converts it to string just like a float value). > >> > >> Martin > > > > I forgot to add an encoding rule to JSON xmlrpc server. This can be > > useful in a future when Decimal type is actually used for a real LDAP > > attribute. > > > > Martin > > ACK. This is fine API-wise because the data is transmitted as a string, > so even if the client side defines the parameter as a Float it won't > affect what the server receives. The only possible downside is that the > precision requested on the client won't be honored on the server, but > then again the server decides what level of precision we want to support. > > rob Thanks for review. You are right, Decimal data type should handle a param when its string or float. But we are even safer here as Decimal parameters in new DNS API are the first parameters of this type in FreeIPA. So old clients shouldn't even know any Decimal parameter. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Fri Jan 20 08:40:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jan 2012 09:40:57 +0100 Subject: [Freeipa-devel] [PATCH] 194 Fix ipa-server-install for dual NICs In-Reply-To: <4F18977F.6070407@redhat.com> References: <1326195613.27400.14.camel@balmora.brq.redhat.com> <1326267331.9621.1.camel@balmora.brq.redhat.com> <4F105242.4010707@redhat.com> <1326485271.2354.3.camel@priserak> <4F18977F.6070407@redhat.com> Message-ID: <1327048857.2204.13.camel@priserak> On Thu, 2012-01-19 at 17:21 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2012-01-13 at 10:48 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> It seems I sent two patches with number 189. Sending a patch with a > >>> correct number. > >>> > >>> Martin > >>> > >>> On Tue, 2012-01-10 at 12:40 +0100, Martin Kosek wrote: > >>>> Depends on my patch 188 > >>>> --- > >>>> A server may have 2 or more NICs and its hostname may thus resolve > >>>> to 2 and more forward addresses. IP address checks in install > >>>> scripts does not expect this setup and may fail or crash. > >>>> > >>>> This script adds a support for multiple forward addresses for > >>>> a hostname. The install scripts do not crash now. When one IP > >>>> address is needed, user is asked to choose from all detected > >>>> server IP addresses. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/2154 > >> > >> You have a patch 190 already as well :-) > > > > Hm, yes :-) > >> > >> This appears to depend on another patch that I haven't applied yet. Can > >> you see if it has unpushed dependencies? (removing the adtrust part was > >> relatively easy and unrelated). > >> > >> rob > > > > It depended on patch 188 (it was written in the top of the mail). Since > > it was pushed today, this patch should be applicable to master branch. I > > checked it and it should be OK. > > > > Martin > > > > Still not applying > > $ patch -p1 --dry-run < > /tmp/freeipa-mkosek-190-fix-ipa-server-install-for-dual-nics.patch > patching file install/tools/ipa-dns-install > patching file install/tools/ipa-replica-conncheck > patching file install/tools/ipa-replica-install > patching file ipapython/dnsclient.py > Hunk #3 FAILED at 404. > 1 out of 3 hunks FAILED -- saving rejects to file ipapython/dnsclient.py.rej > patching file ipaserver/install/bindinstance.py > patching file ipaserver/install/installutils.py > Hmm, this is a mystery. It applies fine on both my master and ipa-2-2 branches: $ git log --oneline 8c230f1 Replace float with Decimal ea678b5 UI for SELinux user mapping ... $ git apply ~/patches/freeipa-mkosek-194-ipa-2-2.patch $ I wonder why the patch fails on your ipapython/dnsclient.py as its last change is somewhere in 2010. I attached patches for both master and ipa-2-2 (without the trust bits), I hope its OK now. These patch includes a fix for unattended mode which was introduced in previous version. I was even able to finally assign a unique number to this patch :-) Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-194-2-fix-ipa-server-install-for-dual-nics.patch Type: text/x-patch Size: 16437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-194-2-ipa-2-2.patch Type: text/x-patch Size: 15676 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 20 09:08:26 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jan 2012 10:08:26 +0100 Subject: [Freeipa-devel] [PATCH] 195-199 New DNS features Message-ID: <1327050506.2204.23.camel@priserak> This set of patches implements support and API for features introduced in a new bind-dyndb-ldap (bind-dyndb-ldap-1.1.0-0.6.a1): - global bind-dyndb-ldap settings in LDAP (cn=dns,$SUFFIX) - conditional per-zone forwarding - per-zone configuration of automatic PTR updates - zone transfer - AllowQuery and AllowTransfer ACIs - new bind-dyndb-ldap now also skips invalid records in a zone instead of refusing to load an entire zone More detailed description and examples are in these separate patches. In order to test it, a new bind-dyndb-ldap version is needed. It is not in updates-testing repo yet as it waits for a new release of bind which should occur in few next days. But it can be downloaded from koji: F15: http://koji.fedoraproject.org/koji/buildinfo?buildID=294138 F16: http://koji.fedoraproject.org/koji/buildinfo?buildID=294137 Have fun! Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-195-update-schema-for-bind-dyndb-ldap.patch Type: text/x-patch Size: 9613 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-196-global-dns-options.patch Type: text/x-patch Size: 11739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-197-query-and-transfer-acls.patch Type: text/x-patch Size: 24493 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-198-add-dns-conditional-forwarding.patch Type: text/x-patch Size: 7584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-199-add-api-for-ptr-sync-control.patch Type: text/x-patch Size: 6018 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 20 11:00:25 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jan 2012 12:00:25 +0100 Subject: [Freeipa-devel] [PATCH] 200 Ease zonemgr restrictions Message-ID: <1327057225.2204.24.camel@priserak> Admin e-mail validator currently requires an email to be in a second-level domain (hostmaster at example.com). This is too restrictive. Top level domain e-mails (hostmaster at testrelm) should also be allowed. This patch also fixes default zonemgr value in help texts and man pages. https://fedorahosted.org/freeipa/ticket/2272 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-200-ease-zonemgr-restrictions.patch Type: text/x-patch Size: 5835 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 20 14:22:07 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jan 2012 15:22:07 +0100 Subject: [Freeipa-devel] [PATCH] 201 Improve host-add error message Message-ID: <1327069327.2204.25.camel@priserak> host-add command allows to add a host and its IP address via --ip-address option. When the address is invalid, it throws an error and refuses to operate. However, the invalid IP address error message is always the same which is not right as it forces a user to guess the reason of rejection (loopback address, link-local address or invalid address at all was passed, etc.). This patch changes host-add validator to print the error message. https://fedorahosted.org/freeipa/ticket/2229 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-201-improve-host-add-error-message.patch Type: text/x-patch Size: 1267 bytes Desc: not available URL: From ohamada at redhat.com Fri Jan 20 14:33:51 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 20 Jan 2012 15:33:51 +0100 Subject: [Freeipa-devel] [PATCH] 8 localhost.localdomain clients refused to join ipa domain In-Reply-To: <4F1894C4.4060704@redhat.com> References: <4F1412C0.3070204@redhat.com> <4F1894C4.4060704@redhat.com> Message-ID: <4F197B4F.3060105@redhat.com> On 01/19/2012 11:10 PM, Rob Crittenden wrote: > Ondrej Hamada wrote: >> https://fedorahosted.org/freeipa/ticket/2112 >> >> Machines with hostname 'localhost.localdomain' are refused from joining >> IPA domain and proper error message is shown. > > This should probably check for just localhost as well. > > It is good that the check is done here as ipa-join can be run outside > of ipa-client-install, but I wonder if it should be checked there as > well. By the time that ipa-join is called the user is potentially > prompted for a bunch of data whereas we could check the hostname very > early in ipa-client-install. > > rob Hostname checking is now in both ipa-client-install and ipa-join. Also the checking is done against both the 'localhost' and 'localhost.localdomain' hostnames. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-8-1-localhost.localdomain-clients-refused-to-join.patch Type: text/x-patch Size: 2129 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 20 14:43:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Jan 2012 09:43:44 -0500 Subject: [Freeipa-devel] [PATCH] 201 Improve host-add error message In-Reply-To: <1327069327.2204.25.camel@priserak> References: <1327069327.2204.25.camel@priserak> Message-ID: <4F197DA0.8030606@redhat.com> Martin Kosek wrote: > host-add command allows to add a host and its IP address via > --ip-address option. When the address is invalid, it throws > an error and refuses to operate. However, the invalid IP address > error message is always the same which is not right as it forces > a user to guess the reason of rejection (loopback address, > link-local address or invalid address at all was passed, etc.). > > This patch changes host-add validator to print the error message. > > https://fedorahosted.org/freeipa/ticket/2229 ACK From mkosek at redhat.com Fri Jan 20 15:34:28 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jan 2012 16:34:28 +0100 Subject: [Freeipa-devel] [PATCH] 201 Improve host-add error message In-Reply-To: <4F197DA0.8030606@redhat.com> References: <1327069327.2204.25.camel@priserak> <4F197DA0.8030606@redhat.com> Message-ID: <1327073668.2204.26.camel@priserak> On Fri, 2012-01-20 at 09:43 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > host-add command allows to add a host and its IP address via > > --ip-address option. When the address is invalid, it throws > > an error and refuses to operate. However, the invalid IP address > > error message is always the same which is not right as it forces > > a user to guess the reason of rejection (loopback address, > > link-local address or invalid address at all was passed, etc.). > > > > This patch changes host-add validator to print the error message. > > > > https://fedorahosted.org/freeipa/ticket/2229 > > ACK > Pushed to master, ipa-2-2. Martin From rcritten at redhat.com Fri Jan 20 16:10:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Jan 2012 11:10:29 -0500 Subject: [Freeipa-devel] [PATCH] 930 add conflicts on mod_ssl Message-ID: <4F1991F5.4070006@redhat.com> We again need to prevent mod_ssl from being installed since we proxy for dogtag now. mod_proxy provides a single API for doing SSL proxying and if mod_ssl is merely loaded in Apache it grabs the interface for doing this from mod_nss. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-930-conflict.patch Type: text/x-diff Size: 1652 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 20 18:33:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Jan 2012 13:33:21 -0500 Subject: [Freeipa-devel] [PATCH] 931 ship ipa-upgradeconfig man page Message-ID: <4F19B371.5030201@redhat.com> The ipa-upgradeconfig man page was not being packaged. I updated the man page to include info about the proxy config change and modified the tool so you have to be root to execute it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-931-man.patch Type: text/x-diff Size: 2665 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 20 20:15:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Jan 2012 15:15:31 -0500 Subject: [Freeipa-devel] [PATCH] 932 Add support for storing MAC address in host entries. Message-ID: <4F19CB63.3010903@redhat.com> macaddress is a multi-valued attribute and we allow multiple entries. This is from the objectclass ieee802device. This is added manually when doing a mod or add and not as a default to support existing host entries that do not have this objectclass. If this were added to the defaults then existing hosts missing this objectclass would not be found by host-find. It is possible to get ethers data out of nss by configuring nsswitch.conf to use ldap for ethers and running getent ethers I tested nslcd and it only returned one macaddress value. I don't know if this is a deficiency in nslcd or expected behavior. https://fedorahosted.org/freeipa/ticket/1132 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-932-macaddress.patch Type: text/x-diff Size: 12470 bytes Desc: not available URL: From rmeggins at redhat.com Fri Jan 20 23:09:43 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 20 Jan 2012 16:09:43 -0700 Subject: [Freeipa-devel] 389 systemd changes Message-ID: <4F19F437.8040809@redhat.com> I have to change the dirsrv at .service file for 389 in order to add ExecStopPost=/usr/bin/rm -f @localstatedir@/run/@package_name@/slapd-%i.pid so that the pid file is removed during shutdown. Without this, various upgrade things fail silently until they blow up later at runtime. I know the freeipa installer copies this file from /lib/systemd/system to /etc/systemd/system - what about during upgrade? From abokovoy at redhat.com Sat Jan 21 08:54:32 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 21 Jan 2012 10:54:32 +0200 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <4F19F437.8040809@redhat.com> References: <4F19F437.8040809@redhat.com> Message-ID: <20120121085432.GG29844@redhat.com> On Fri, 20 Jan 2012, Rich Megginson wrote: > I have to change the dirsrv at .service file for 389 in order to add > ExecStopPost=/usr/bin/rm -f @localstatedir@/run/@package_name@/slapd-%i.pid > so that the pid file is removed during shutdown. Without this, > various upgrade things fail silently until they blow up later at > runtime. > > I know the freeipa installer copies this file from > /lib/systemd/system to /etc/systemd/system - what about during > upgrade? In Fedora we have upgrade script that can handle this. Please make a ticket for me. -- / Alexander Bokovoy From simo at redhat.com Sun Jan 22 07:31:15 2012 From: simo at redhat.com (Simo Sorce) Date: Sun, 22 Jan 2012 02:31:15 -0500 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <20120121085432.GG29844@redhat.com> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> Message-ID: <1327217475.13963.91.camel@willson.li.ssimo.org> On Sat, 2012-01-21 at 10:54 +0200, Alexander Bokovoy wrote: > On Fri, 20 Jan 2012, Rich Megginson wrote: > > > I have to change the dirsrv at .service file for 389 in order to add > > ExecStopPost=/usr/bin/rm -f @localstatedir@/run/@package_name@/slapd-%i.pid > > so that the pid file is removed during shutdown. Without this, > > various upgrade things fail silently until they blow up later at > > runtime. > > > > I know the freeipa installer copies this file from > > /lib/systemd/system to /etc/systemd/system - what about during > > upgrade? > In Fedora we have upgrade script that can handle this. Please make a > ticket for me. Shouldn't we just 'include' the original file and not copy it ? If we include it a change in the file will be automatically picked up. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Sun Jan 22 13:12:33 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 22 Jan 2012 15:12:33 +0200 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <1327217475.13963.91.camel@willson.li.ssimo.org> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> <1327217475.13963.91.camel@willson.li.ssimo.org> Message-ID: <20120122131233.GI29844@redhat.com> On Sun, 22 Jan 2012, Simo Sorce wrote: > On Sat, 2012-01-21 at 10:54 +0200, Alexander Bokovoy wrote: > > On Fri, 20 Jan 2012, Rich Megginson wrote: > > > > > I have to change the dirsrv at .service file for 389 in order to add > > > ExecStopPost=/usr/bin/rm -f @localstatedir@/run/@package_name@/slapd-%i.pid > > > so that the pid file is removed during shutdown. Without this, > > > various upgrade things fail silently until they blow up later at > > > runtime. > > > > > > I know the freeipa installer copies this file from > > > /lib/systemd/system to /etc/systemd/system - what about during > > > upgrade? > > In Fedora we have upgrade script that can handle this. Please make a > > ticket for me. > > Shouldn't we just 'include' the original file and not copy it ? > If we include it a change in the file will be automatically picked up. We can't due to systemd design and use of it in 389-ds. LimitNOFILE needs to be changed in the service file directly, not in the environment file in /etc/sysconfig or otherwise it will not be picked up by the systemd. -- / Alexander Bokovoy From simo at redhat.com Sun Jan 22 22:27:57 2012 From: simo at redhat.com (Simo Sorce) Date: Sun, 22 Jan 2012 17:27:57 -0500 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <20120122131233.GI29844@redhat.com> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> <1327217475.13963.91.camel@willson.li.ssimo.org> <20120122131233.GI29844@redhat.com> Message-ID: <1327271277.13963.92.camel@willson.li.ssimo.org> On Sun, 2012-01-22 at 15:12 +0200, Alexander Bokovoy wrote: > On Sun, 22 Jan 2012, Simo Sorce wrote: > > > On Sat, 2012-01-21 at 10:54 +0200, Alexander Bokovoy wrote: > > > On Fri, 20 Jan 2012, Rich Megginson wrote: > > > > > > > I have to change the dirsrv at .service file for 389 in order to add > > > > ExecStopPost=/usr/bin/rm -f @localstatedir@/run/@package_name@/slapd-%i.pid > > > > so that the pid file is removed during shutdown. Without this, > > > > various upgrade things fail silently until they blow up later at > > > > runtime. > > > > > > > > I know the freeipa installer copies this file from > > > > /lib/systemd/system to /etc/systemd/system - what about during > > > > upgrade? > > > In Fedora we have upgrade script that can handle this. Please make a > > > ticket for me. > > > > Shouldn't we just 'include' the original file and not copy it ? > > If we include it a change in the file will be automatically picked up. > We can't due to systemd design and use of it in 389-ds. > > LimitNOFILE needs to be changed in the service file directly, not in > the environment file in /etc/sysconfig or otherwise it will not be > picked up by the systemd. I am not talking about using /set/sysconfig options, but the .include directive for service files. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Jan 23 06:03:48 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Jan 2012 08:03:48 +0200 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <1327271277.13963.92.camel@willson.li.ssimo.org> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> <1327217475.13963.91.camel@willson.li.ssimo.org> <20120122131233.GI29844@redhat.com> <1327271277.13963.92.camel@willson.li.ssimo.org> Message-ID: <20120123060348.GJ29844@redhat.com> On Sun, 22 Jan 2012, Simo Sorce wrote: > > > Shouldn't we just 'include' the original file and not copy it ? > > > If we include it a change in the file will be automatically picked up. > > We can't due to systemd design and use of it in 389-ds. > > > > LimitNOFILE needs to be changed in the service file directly, not in > > the environment file in /etc/sysconfig or otherwise it will not be > > picked up by the systemd. > > I am not talking about using /set/sysconfig options, but the .include > directive for service files. So, something like this for 389-ds? ----8<--------8<--------8<--------- [Unit] Description=389 Directory Server %i. BindTo=dirsrv.target After=dirsrv.target [Service] Type=forking Environment=PIDDIR=/var/run/dirsrv EnvironmentFile=/etc/sysconfig/dirsrv EnvironmentFile=/etc/sysconfig/dirsrv-%i ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i ${PIDDIR}/slapd-%i.pid -w ${PIDDIR}/slapd-%i.startpid .include /etc/sysconfig/dirsrv.systemd ----8<--------8<--------8<--------- and then with following /etc/sysconfig/dirsrv.systemd: ----8<--------8<--------8<--------- [Service] LimitNOFILE=8192 ----8<--------8<--------8<--------- local overrides can be created? It seems to work. You can't use %i macro in .include unfortunately so any configuration change will be global, not per service instance. # systemctl show dirsrv at IPA-LOCAL.service|grep LimitNOFILE LimitNOFILE=8192 # systemctl status dirsrv at IPA-LOCAL.service dirsrv at IPA-LOCAL.service - 389 Directory Server IPA-LOCAL. Loaded: loaded (/lib/systemd/system/dirsrv at .service; enabled) Active: active (running) since Mon, 23 Jan 2012 00:47:32 -0500; 11min ago Process: 30927 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i ${PIDDIR}/slapd-%i.pid -w ${PIDDIR}/slapd-%i.startpid (code=exited, status=0/SUCCESS) Main PID: 30929 (ns-slapd) CGroup: name=systemd:/system/dirsrv at .service/IPA-LOCAL ? 30929 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-IPA-LOCAL -i /var/run/dirsrv/slapd-IPA-LOCAL.p... I would still need a ticket to make appropriate removals in ipapython/platform/fedora16.py so that we would modify /etc/sysconfig/dirsrv.systemd and still do symlink re-linking in /etc/systemd/system/dirsrv.target.wants/. -- / Alexander Bokovoy From jcholast at redhat.com Mon Jan 23 10:14:28 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Jan 2012 11:14:28 +0100 Subject: [Freeipa-devel] [PATCH] 932 Add support for storing MAC address in host entries. In-Reply-To: <4F19CB63.3010903@redhat.com> References: <4F19CB63.3010903@redhat.com> Message-ID: <4F1D3304.6040809@redhat.com> Dne 20.1.2012 21:15, Rob Crittenden napsal(a): > macaddress is a multi-valued attribute and we allow multiple entries. > This is from the objectclass ieee802device. This is added manually when > doing a mod or add and not as a default to support existing host entries > that do not have this objectclass. If this were added to the defaults > then existing hosts missing this objectclass would not be found by > host-find. > > It is possible to get ethers data out of nss by configuring > nsswitch.conf to use ldap for ethers and running getent ethers > > I tested nslcd and it only returned one macaddress value. I don't know > if this is a deficiency in nslcd or expected behavior. > > https://fedorahosted.org/freeipa/ticket/1132 > > rob > @@ -442,6 +448,7 @@ class host_add(LDAPCreate): x509.verify_cert_subject(ldap, keys[-1], cert) entry_attrs['usercertificate'] = cert entry_attrs['managedby'] = dn + entry_attrs['objectclass'].append('ieee802device') return dn def post_callback(self, ldap, dn, entry_attrs, *keys, **options): Why do you add the objectclass here instead of adding it to host plugin's object_class attribute? Honza -- Jan Cholasta From simo at redhat.com Mon Jan 23 13:24:09 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Jan 2012 08:24:09 -0500 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <20120123060348.GJ29844@redhat.com> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> <1327217475.13963.91.camel@willson.li.ssimo.org> <20120122131233.GI29844@redhat.com> <1327271277.13963.92.camel@willson.li.ssimo.org> <20120123060348.GJ29844@redhat.com> Message-ID: <1327325049.13963.97.camel@willson.li.ssimo.org> On Mon, 2012-01-23 at 08:03 +0200, Alexander Bokovoy wrote: > On Sun, 22 Jan 2012, Simo Sorce wrote: > > > > Shouldn't we just 'include' the original file and not copy it ? > > > > If we include it a change in the file will be automatically picked up. > > > We can't due to systemd design and use of it in 389-ds. > > > > > > LimitNOFILE needs to be changed in the service file directly, not in > > > the environment file in /etc/sysconfig or otherwise it will not be > > > picked up by the systemd. > > > > I am not talking about using /set/sysconfig options, but the .include > > directive for service files. > So, something like this for 389-ds? No, you should include the actual dirsrv default service file (if any, otherwise the sysconfig one might be ok I guess). > ----8<--------8<--------8<--------- > [Unit] > Description=389 Directory Server %i. > BindTo=dirsrv.target > After=dirsrv.target > > [Service] > Type=forking > Environment=PIDDIR=/var/run/dirsrv > EnvironmentFile=/etc/sysconfig/dirsrv > EnvironmentFile=/etc/sysconfig/dirsrv-%i > ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i ${PIDDIR}/slapd-%i.pid -w ${PIDDIR}/slapd-%i.startpid > .include /etc/sysconfig/dirsrv.systemd > ----8<--------8<--------8<--------- > > and then with following /etc/sysconfig/dirsrv.systemd: > ----8<--------8<--------8<--------- > [Service] > LimitNOFILE=8192 > ----8<--------8<--------8<--------- > > local overrides can be created? Yes I think if you put directives after the include they will override whatever is in the include. Also I would put as much as possible in the include file and put in the specific instance files only the parameters we need to override. > It seems to work. You can't use %i macro in .include unfortunately so > any configuration change will be global, not per service instance. That's fine we want to put in there only global configuration anyways, and then override in our specific per instance control files. > # systemctl show dirsrv at IPA-LOCAL.service|grep LimitNOFILE > LimitNOFILE=8192 > # systemctl status dirsrv at IPA-LOCAL.service > dirsrv at IPA-LOCAL.service - 389 Directory Server IPA-LOCAL. > Loaded: loaded (/lib/systemd/system/dirsrv at .service; enabled) > Active: active (running) since Mon, 23 Jan 2012 00:47:32 -0500; 11min ago > Process: 30927 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i ${PIDDIR}/slapd-%i.pid -w ${PIDDIR}/slapd-%i.startpid (code=exited, status=0/SUCCESS) > Main PID: 30929 (ns-slapd) > CGroup: name=systemd:/system/dirsrv at .service/IPA-LOCAL > ? 30929 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-IPA-LOCAL -i /var/run/dirsrv/slapd-IPA-LOCAL.p... > > I would still need a ticket to make appropriate removals in > ipapython/platform/fedora16.py so that we would modify > /etc/sysconfig/dirsrv.systemd and still do symlink re-linking in > /etc/systemd/system/dirsrv.target.wants/. ok. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Jan 23 14:37:08 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Jan 2012 16:37:08 +0200 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <1327325049.13963.97.camel@willson.li.ssimo.org> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> <1327217475.13963.91.camel@willson.li.ssimo.org> <20120122131233.GI29844@redhat.com> <1327271277.13963.92.camel@willson.li.ssimo.org> <20120123060348.GJ29844@redhat.com> <1327325049.13963.97.camel@willson.li.ssimo.org> Message-ID: <20120123143708.GL29844@redhat.com> On Mon, 23 Jan 2012, Simo Sorce wrote: > On Mon, 2012-01-23 at 08:03 +0200, Alexander Bokovoy wrote: > > On Sun, 22 Jan 2012, Simo Sorce wrote: > > > > > Shouldn't we just 'include' the original file and not copy it ? > > > > > If we include it a change in the file will be automatically picked up. > > > > We can't due to systemd design and use of it in 389-ds. > > > > > > > > LimitNOFILE needs to be changed in the service file directly, not in > > > > the environment file in /etc/sysconfig or otherwise it will not be > > > > picked up by the systemd. > > > > > > I am not talking about using /set/sysconfig options, but the .include > > > directive for service files. > > So, something like this for 389-ds? > > No, you should include the actual dirsrv default service file (if any, > otherwise the sysconfig one might be ok I guess). There is /lib/systemd/system/dirsrv at .service. The content below is from there and I think there is no need to make .include in a /etc/systemd/system/dirsrv at .service copy of it as we can ask Rich to make proper change in the original service unit. This way we only would have settings in /etc/sysconfig (or in /etc/dirsrv if that's better) and you'd have no need to intervene into /etc/systemd/system. Paths are irrelevant but I'd prefer to use common places like /etc/sysconfig. > > > ----8<--------8<--------8<--------- > > [Unit] > > Description=389 Directory Server %i. > > BindTo=dirsrv.target > > After=dirsrv.target > > > > [Service] > > Type=forking > > Environment=PIDDIR=/var/run/dirsrv > > EnvironmentFile=/etc/sysconfig/dirsrv > > EnvironmentFile=/etc/sysconfig/dirsrv-%i > > ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i ${PIDDIR}/slapd-%i.pid -w ${PIDDIR}/slapd-%i.startpid > > .include /etc/sysconfig/dirsrv.systemd > > ----8<--------8<--------8<--------- > > > > and then with following /etc/sysconfig/dirsrv.systemd: > > ----8<--------8<--------8<--------- > > [Service] > > LimitNOFILE=8192 > > ----8<--------8<--------8<--------- > > > > local overrides can be created? > > Yes I think if you put directives after the include they will override > whatever is in the include. Depends on directive. > Also I would put as much as possible in the include file and put in the > specific instance files only the parameters we need to override. There is no specific instance service unit. There is one service unit that processes all instances, that's the whole purpose of @-services (dirsrv at .service). > > > It seems to work. You can't use %i macro in .include unfortunately so > > any configuration change will be global, not per service instance. > > That's fine we want to put in there only global configuration anyways, > and then override in our specific per instance control files. See above. There are no per-instance control files. -- / Alexander Bokovoy From pvoborni at redhat.com Mon Jan 23 14:41:55 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Jan 2012 15:41:55 +0100 Subject: [Freeipa-devel] [PATCH] 340 Enabled paging on automount keys. In-Reply-To: <4F176750.9060500@redhat.com> References: <4F16F193.30300@redhat.com> <4F176750.9060500@redhat.com> Message-ID: <4F1D71B3.3000703@redhat.com> On 01/19/2012 01:44 AM, Endi Sukma Dewata wrote: > On 1/18/2012 10:21 AM, Endi Sukma Dewata wrote: >> The automount keys search facet has been modified to support paging. >> Since the automountkey-find command doesn't support --pkey-only >> option, the facet is configured such that during a refresh operation >> it will retrieve all entries (including the key and info attributes) >> and then display only the ones that are supposed to be visible in >> the current page. >> >> Ticket #2093 > > New patch attached. Some attributes weren't renamed properly. > ACK and pushed to master, ipa-2-2 -- Petr Vobornik From pvoborni at redhat.com Mon Jan 23 14:42:23 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Jan 2012 15:42:23 +0100 Subject: [Freeipa-devel] [PATCH] 341 Show disabled entries in gray. In-Reply-To: <4F17687A.9010504@redhat.com> References: <4F17687A.9010504@redhat.com> Message-ID: <4F1D71CF.9080909@redhat.com> On 01/19/2012 01:48 AM, Endi Sukma Dewata wrote: > The users, HBAC/sudo rules, HBAC test, and SELinux list pages have > been modified to show disabled entries in gray. Icons will be added > separately. > > Ticket #1996 > > ACK and pushed to master, ipa-2-2 -- Petr Vobornik From pvoborni at redhat.com Mon Jan 23 14:42:45 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Jan 2012 15:42:45 +0100 Subject: [Freeipa-devel] [PATCH] 342 Fixed inconsistent status labels. In-Reply-To: <4F17B256.4090606@redhat.com> References: <4F17B256.4090606@redhat.com> Message-ID: <4F1D71E5.8070503@redhat.com> On 01/19/2012 07:04 AM, Endi Sukma Dewata wrote: > This patch modifies the status attributes in users, DNS zones, > HBAC/sudo rules, HBAC test, and SELinux User Map to use the same > label (i.e. Status) and values (i.e. Enabled/Disabled). The method > to change the status will be modified separately. > > Ticket #2247 > ACK and pushed to master, ipa-2-2 -- Petr Vobornik From pvoborni at redhat.com Mon Jan 23 15:03:57 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Jan 2012 16:03:57 +0100 Subject: [Freeipa-devel] [PATCH] 341 Show disabled entries in gray. In-Reply-To: <4F1D71CF.9080909@redhat.com> References: <4F17687A.9010504@redhat.com> <4F1D71CF.9080909@redhat.com> Message-ID: <4F1D76DD.305@redhat.com> On 01/23/2012 03:42 PM, Petr Vobornik wrote: > On 01/19/2012 01:48 AM, Endi Sukma Dewata wrote: >> The users, HBAC/sudo rules, HBAC test, and SELinux list pages have >> been modified to show disabled entries in gray. Icons will be added >> separately. >> >> Ticket #1996 >> >> > > ACK and pushed to master, ipa-2-2 > The patch is completely fine, but I missed that in Kyle's mockup was also shown status icons. I assume we want to do it too. https://fedorahosted.org/freeipa/attachment/ticket/1996/deactivated_column.png -- Petr Vobornik From mkosek at redhat.com Mon Jan 23 15:09:25 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jan 2012 16:09:25 +0100 Subject: [Freeipa-devel] [PATCH] 931 ship ipa-upgradeconfig man page In-Reply-To: <4F19B371.5030201@redhat.com> References: <4F19B371.5030201@redhat.com> Message-ID: <1327331365.11792.11.camel@balmora.brq.redhat.com> On Fri, 2012-01-20 at 13:33 -0500, Rob Crittenden wrote: > The ipa-upgradeconfig man page was not being packaged. > > I updated the man page to include info about the proxy config change and > modified the tool so you have to be root to execute it. > > rob ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Mon Jan 23 15:24:36 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jan 2012 16:24:36 +0100 Subject: [Freeipa-devel] [PATCH] 932 Add support for storing MAC address in host entries. In-Reply-To: <4F1D3304.6040809@redhat.com> References: <4F19CB63.3010903@redhat.com> <4F1D3304.6040809@redhat.com> Message-ID: <1327332276.11792.17.camel@balmora.brq.redhat.com> On Mon, 2012-01-23 at 11:14 +0100, Jan Cholasta wrote: > Dne 20.1.2012 21:15, Rob Crittenden napsal(a): > > macaddress is a multi-valued attribute and we allow multiple entries. > > This is from the objectclass ieee802device. This is added manually when > > doing a mod or add and not as a default to support existing host entries > > that do not have this objectclass. If this were added to the defaults > > then existing hosts missing this objectclass would not be found by > > host-find. > > > > It is possible to get ethers data out of nss by configuring > > nsswitch.conf to use ldap for ethers and running getent ethers > > > > I tested nslcd and it only returned one macaddress value. I don't know > > if this is a deficiency in nslcd or expected behavior. > > > > https://fedorahosted.org/freeipa/ticket/1132 > > > > rob > > > > @@ -442,6 +448,7 @@ class host_add(LDAPCreate): > x509.verify_cert_subject(ldap, keys[-1], cert) > entry_attrs['usercertificate'] = cert > entry_attrs['managedby'] = dn > + entry_attrs['objectclass'].append('ieee802device') > return dn > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > > Why do you add the objectclass here instead of adding it to host > plugin's object_class attribute? > > Honza > As Rob pointed out, old host records without ieee802device objectclass wouldn't then be matched in host-find command. I checked the patch and it looks ok. I have just 3 minor issues: 1) As you didn't specify the param with csv=True its values cannot be entered in a comma-separated list. I think we can enable this feature for MAC Address 2) I would fix capitalization of label of macaddress. A second word in a label is lowercase in other params. 3) I think we may want to implement a normalizer for MAC address which would make it either lowercase or uppercase so that we provide results with consistent case. Martin From jcholast at redhat.com Mon Jan 23 15:28:15 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Jan 2012 16:28:15 +0100 Subject: [Freeipa-devel] [PATCH] 932 Add support for storing MAC address in host entries. In-Reply-To: <1327332276.11792.17.camel@balmora.brq.redhat.com> References: <4F19CB63.3010903@redhat.com> <4F1D3304.6040809@redhat.com> <1327332276.11792.17.camel@balmora.brq.redhat.com> Message-ID: <4F1D7C8F.2080309@redhat.com> Dne 23.1.2012 16:24, Martin Kosek napsal(a): > On Mon, 2012-01-23 at 11:14 +0100, Jan Cholasta wrote: >> Dne 20.1.2012 21:15, Rob Crittenden napsal(a): >>> macaddress is a multi-valued attribute and we allow multiple entries. >>> This is from the objectclass ieee802device. This is added manually when >>> doing a mod or add and not as a default to support existing host entries >>> that do not have this objectclass. If this were added to the defaults >>> then existing hosts missing this objectclass would not be found by >>> host-find. >>> >>> It is possible to get ethers data out of nss by configuring >>> nsswitch.conf to use ldap for ethers and running getent ethers >>> >>> I tested nslcd and it only returned one macaddress value. I don't know >>> if this is a deficiency in nslcd or expected behavior. >>> >>> https://fedorahosted.org/freeipa/ticket/1132 >>> >>> rob >>> >> >> @@ -442,6 +448,7 @@ class host_add(LDAPCreate): >> x509.verify_cert_subject(ldap, keys[-1], cert) >> entry_attrs['usercertificate'] = cert >> entry_attrs['managedby'] = dn >> + entry_attrs['objectclass'].append('ieee802device') >> return dn >> >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> >> Why do you add the objectclass here instead of adding it to host >> plugin's object_class attribute? >> >> Honza >> > > As Rob pointed out, old host records without ieee802device objectclass > wouldn't then be matched in host-find command. Whoops, I have missed that. Anyway, it's good to know that, I might have to fix my SSH patches. > > I checked the patch and it looks ok. I have just 3 minor issues: > > 1) As you didn't specify the param with csv=True its values cannot be > entered in a comma-separated list. I think we can enable this feature > for MAC Address > > 2) I would fix capitalization of label of macaddress. A second word in a > label is lowercase in other params. > > 3) I think we may want to implement a normalizer for MAC address which > would make it either lowercase or uppercase so that we provide results > with consistent case. > > Martin > Honza -- Jan Cholasta From pvoborni at redhat.com Mon Jan 23 16:03:38 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Jan 2012 17:03:38 +0100 Subject: [Freeipa-devel] [PATCH] 070 Modifying DNS UI to benefit from new DNS API Message-ID: <4F1D84DA.30802@redhat.com> DNS UI was modified to offer structured way of defining DNS records. https://fedorahosted.org/freeipa/ticket/2208 This patch depends on Martin's patch #193. Preview: http://pvoborni.fedorapeople.org/dns/#dns=dnsrecord&identity=dns&navigation=identity&dnsrecord-facet=default&dnsrecord-pkey=testrec&dnszone-pkey=test.com Possible modifications: 1) modify labels to exclude record type's name. 2) hide empty tables (as I suggested in ticket description) 3) attributes which are displayed in table columns can be easily changed or reordered. I used following principle: "If type has up to 4 attributes: show them all in table if not, show raw value." This way all data are displayed and columns are not too narrow. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0070-Modifying-DNS-UI-to-benefit-from-new-DNS-API.patch Type: text/x-patch Size: 292270 bytes Desc: not available URL: From rmeggins at redhat.com Mon Jan 23 16:13:18 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jan 2012 09:13:18 -0700 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <20120123143708.GL29844@redhat.com> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> <1327217475.13963.91.camel@willson.li.ssimo.org> <20120122131233.GI29844@redhat.com> <1327271277.13963.92.camel@willson.li.ssimo.org> <20120123060348.GJ29844@redhat.com> <1327325049.13963.97.camel@willson.li.ssimo.org> <20120123143708.GL29844@redhat.com> Message-ID: <4F1D871E.4040108@redhat.com> On 01/23/2012 07:37 AM, Alexander Bokovoy wrote: > On Mon, 23 Jan 2012, Simo Sorce wrote: >> On Mon, 2012-01-23 at 08:03 +0200, Alexander Bokovoy wrote: >>> On Sun, 22 Jan 2012, Simo Sorce wrote: >>>>>> Shouldn't we just 'include' the original file and not copy it ? >>>>>> If we include it a change in the file will be automatically picked up. >>>>> We can't due to systemd design and use of it in 389-ds. >>>>> >>>>> LimitNOFILE needs to be changed in the service file directly, not in >>>>> the environment file in /etc/sysconfig or otherwise it will not be >>>>> picked up by the systemd. >>>> I am not talking about using /set/sysconfig options, but the .include >>>> directive for service files. >>> So, something like this for 389-ds? >> No, you should include the actual dirsrv default service file (if any, >> otherwise the sysconfig one might be ok I guess). > There is /lib/systemd/system/dirsrv at .service. The content below is > from there and I think there is no need to make .include in a > /etc/systemd/system/dirsrv at .service copy of it as we can ask Rich to > make proper change in the original service unit. > > This way we only would have settings in /etc/sysconfig (or in > /etc/dirsrv if that's better) and you'd have no need to intervene into > /etc/systemd/system. Paths are irrelevant but I'd prefer to use common > places like /etc/sysconfig. I have filed this ticket https://fedorahosted.org/freeipa/ticket/2300 What changes do I need to make to 389? >>> ----8<--------8<--------8<--------- >>> [Unit] >>> Description=389 Directory Server %i. >>> BindTo=dirsrv.target >>> After=dirsrv.target >>> >>> [Service] >>> Type=forking >>> Environment=PIDDIR=/var/run/dirsrv >>> EnvironmentFile=/etc/sysconfig/dirsrv >>> EnvironmentFile=/etc/sysconfig/dirsrv-%i >>> ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i ${PIDDIR}/slapd-%i.pid -w ${PIDDIR}/slapd-%i.startpid >>> .include /etc/sysconfig/dirsrv.systemd >>> ----8<--------8<--------8<--------- >>> >>> and then with following /etc/sysconfig/dirsrv.systemd: >>> ----8<--------8<--------8<--------- >>> [Service] >>> LimitNOFILE=8192 >>> ----8<--------8<--------8<--------- >>> >>> local overrides can be created? >> Yes I think if you put directives after the include they will override >> whatever is in the include. > Depends on directive. > > >> Also I would put as much as possible in the include file and put in the >> specific instance files only the parameters we need to override. > There is no specific instance service unit. There is one service unit > that processes all instances, that's the whole purpose of @-services > (dirsrv at .service). > >>> It seems to work. You can't use %i macro in .include unfortunately so >>> any configuration change will be global, not per service instance. >> That's fine we want to put in there only global configuration anyways, >> and then override in our specific per instance control files. > See above. There are no per-instance control files. > From mkosek at redhat.com Mon Jan 23 16:36:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jan 2012 17:36:49 +0100 Subject: [Freeipa-devel] [PATCH] 927 fix deleting hbac rules when selinux user maps are involved In-Reply-To: <4F15FD43.5000402@redhat.com> References: <4F15FD43.5000402@redhat.com> Message-ID: <1327336609.11792.23.camel@balmora.brq.redhat.com> On Tue, 2012-01-17 at 17:59 -0500, Rob Crittenden wrote: > When deleting an HBAC rule we need to ensure that an SELinux user map > isn't pointing at it. The search for this didn't work well at all. > > This patch corrects the search and makes it more specific. > > I also tested that it works with the --continue flag of hbacrule-del. > > The ticket has instructions on testing. > > rob Works fine. There is just one part that is IMO too complicated: + hbacrule = options['seealso'] + kw = dict(cn=hbacrule, all=True) _entries = api.Command.hbacrule_find(None, **kw)['result'] del options['seealso'] - if _entries: - options['seealso'] = _entries[0]['dn'] + found = False + # look for an exact match. The search may return partial + # matches. + for entry in _entries: + if entry['cn'][0] == hbacrule: + found = True + options['seealso'] = entry['dn'] + if not found: + return dict(count=0, result=[], truncated=False) I think hbacrule_find(None, cn=HBACRULE) should not return partial matches, but just the exact match (tried with hbacrule-find --name=HBACRULE). Then the loop over entries wouldn't be needed. Couldn't we simply call hbacrule_show since we want just one HBAC rule with a known primary key? Martin From rcritten at redhat.com Mon Jan 23 17:07:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Jan 2012 12:07:30 -0500 Subject: [Freeipa-devel] [PATCH] 932 Add support for storing MAC address in host entries. In-Reply-To: <4F1D3304.6040809@redhat.com> References: <4F19CB63.3010903@redhat.com> <4F1D3304.6040809@redhat.com> Message-ID: <4F1D93D2.4040409@redhat.com> Jan Cholasta wrote: > Dne 20.1.2012 21:15, Rob Crittenden napsal(a): >> macaddress is a multi-valued attribute and we allow multiple entries. >> This is from the objectclass ieee802device. This is added manually when >> doing a mod or add and not as a default to support existing host entries >> that do not have this objectclass. If this were added to the defaults >> then existing hosts missing this objectclass would not be found by >> host-find. >> >> It is possible to get ethers data out of nss by configuring >> nsswitch.conf to use ldap for ethers and running getent ethers >> >> I tested nslcd and it only returned one macaddress value. I don't know >> if this is a deficiency in nslcd or expected behavior. >> >> https://fedorahosted.org/freeipa/ticket/1132 >> >> rob >> > > @@ -442,6 +448,7 @@ class host_add(LDAPCreate): > x509.verify_cert_subject(ldap, keys[-1], cert) > entry_attrs['usercertificate'] = cert > entry_attrs['managedby'] = dn > + entry_attrs['objectclass'].append('ieee802device') > return dn > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > > Why do you add the objectclass here instead of adding it to host > plugin's object_class attribute? For upgrades. If there are existing hosts that don't have this objectclass in the list then host-find won't find them. The alternative was to create a new class variable, search_objectclass but it seemed like overkill for this one-off. rob From rcritten at redhat.com Mon Jan 23 17:20:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Jan 2012 12:20:58 -0500 Subject: [Freeipa-devel] [PATCH] 927 fix deleting hbac rules when selinux user maps are involved In-Reply-To: <1327336609.11792.23.camel@balmora.brq.redhat.com> References: <4F15FD43.5000402@redhat.com> <1327336609.11792.23.camel@balmora.brq.redhat.com> Message-ID: <4F1D96FA.60708@redhat.com> Martin Kosek wrote: > On Tue, 2012-01-17 at 17:59 -0500, Rob Crittenden wrote: >> When deleting an HBAC rule we need to ensure that an SELinux user map >> isn't pointing at it. The search for this didn't work well at all. >> >> This patch corrects the search and makes it more specific. >> >> I also tested that it works with the --continue flag of hbacrule-del. >> >> The ticket has instructions on testing. >> >> rob > > Works fine. There is just one part that is IMO too complicated: > > + hbacrule = options['seealso'] > + kw = dict(cn=hbacrule, all=True) > _entries = api.Command.hbacrule_find(None, **kw)['result'] > del options['seealso'] > - if _entries: > - options['seealso'] = _entries[0]['dn'] > + found = False > + # look for an exact match. The search may return partial > + # matches. > + for entry in _entries: > + if entry['cn'][0] == hbacrule: > + found = True > + options['seealso'] = entry['dn'] > + if not found: > + return dict(count=0, result=[], truncated=False) > > I think hbacrule_find(None, cn=HBACRULE) should not return partial > matches, but just the exact match (tried with hbacrule-find > --name=HBACRULE). Then the loop over entries wouldn't be needed. > > Couldn't we simply call hbacrule_show since we want just one HBAC rule > with a known primary key? > > Martin > hbacrule_show would need to be modified to take a dn, that would be a way to fix this. rob From dpal at redhat.com Mon Jan 23 17:23:26 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 23 Jan 2012 12:23:26 -0500 Subject: [Freeipa-devel] [PATCH] 341 Show disabled entries in gray. In-Reply-To: <4F1D76DD.305@redhat.com> References: <4F17687A.9010504@redhat.com> <4F1D71CF.9080909@redhat.com> <4F1D76DD.305@redhat.com> Message-ID: <4F1D978E.8080007@redhat.com> On 01/23/2012 10:03 AM, Petr Vobornik wrote: > On 01/23/2012 03:42 PM, Petr Vobornik wrote: >> On 01/19/2012 01:48 AM, Endi Sukma Dewata wrote: >>> The users, HBAC/sudo rules, HBAC test, and SELinux list pages have >>> been modified to show disabled entries in gray. Icons will be added >>> separately. >>> >>> Ticket #1996 >>> >>> >> >> ACK and pushed to master, ipa-2-2 >> > > The patch is completely fine, but I missed that in Kyle's mockup was > also shown status icons. I assume we want to do it too. > > https://fedorahosted.org/freeipa/attachment/ticket/1996/deactivated_column.png > > > I might be confused but the mockup above does not make much sense. Is it intended for user list rather than for HBAC because "Account Status" for HBAC does not make any sense? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ohamada at redhat.com Mon Jan 23 17:45:56 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Mon, 23 Jan 2012 18:45:56 +0100 Subject: [Freeipa-devel] [PATCH] 9 Don't set nsds5replicaupdateschedule in replication agreements Message-ID: <4F1D9CD4.8080106@redhat.com> https://fedorahosted.org/freeipa/ticket/1482 The nsDS5ReplicaUpdateSchedule parameter is omitted what results in replication being run all the time. The parameter is still used for forcing replica update but after that action it is always deleted. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-9-Leave-nsds5replicaupdateschedule-parameter-unset.patch Type: text/x-patch Size: 2811 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 23 17:57:07 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Jan 2012 18:57:07 +0100 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4F0169DD.90105@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> <4EEA60A6.90109@redhat.com> <4F0169DD.90105@redhat.com> Message-ID: <4F1D9F73.4020209@redhat.com> I have updated and rebased the patches: [PATCH] 59 Add LDAP schema for SSH public keys. No changes. [PATCH] 60 Add LDAP ACIs for SSH public key schema. Requires patch 59. No changes. [PATCH] 61 Add support for SSH public keys to user and host objects. Requires patch 59 and 66. Added new virtual attribute for SSH public key fingerprints to both user and host. The ipasshuser and ipasshhost objectclasses are now automatically added to user and host objects when necessary. The --addattr issue is fixed in patch 66. [PATCH] 62 Add API initialization to ipa-client-install. Changed API context to "cli_installer". [PATCH] 63 Move the nsupdate functionality to separate function in ipa-client-install. No changes. [PATCH] 64 Update host SSH public keys on the server during client install. Requires patch 59, 61, 62, 63, 66 and 67. The host SSH public keys are now loaded from a platform specific location instead of /etc/ssh. [PATCH] 65 Configure ssh and sshd during ipa-client-install. Requires patch 67. The configuration files are now looked for in a platform specific location instead of /etc/ssh Also I have added 2 new patches to the patchset: [PATCH] 66 Base64-decode unicode values in Bytes parameters. Fix wrong handling of strings in --setattr/--addattr/--delattr. These changes make it possible to use Bytes in --setattr/--addattr/--delattr without errors. It might seem that this patch breaks the API, but it does not. Bytes parameters are currently used only for certificate attribute of host and service objects and these attributes are normalized using ipalib.x509 functions, so both raw binary values and base64-encoded values are accepted. I have checked that old client works with new server without problems. [PATCH] 67 Add SSH service to platform-specific services. Add method for getting configuration directory path of a service, so that a different SSH configuration directory can be specified on different platforms. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-59.1-ssh-ldap-schema.patch Type: text/x-patch Size: 3604 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-60.1-ssh-ldap-aci.patch Type: text/x-patch Size: 5811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-61.1-ssh-host-user-plugins.patch Type: text/x-patch Size: 24279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-62.1-ipa-client-install-api.patch Type: text/x-patch Size: 4112 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-63.1-ipa-client-install-nsupdate.patch Type: text/x-patch Size: 2213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-64.1-ssh-install-update-keys.patch Type: text/x-patch Size: 5689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-65.2-ssh-install-config-sshd.patch Type: text/x-patch Size: 6594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-66-parameter-bytes-base64.patch Type: text/x-patch Size: 3058 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-67-ssh-platform-service.patch Type: text/x-patch Size: 3844 bytes Desc: not available URL: From edewata at redhat.com Mon Jan 23 18:06:33 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 23 Jan 2012 12:06:33 -0600 Subject: [Freeipa-devel] [PATCH] 341 Show disabled entries in gray. In-Reply-To: <4F1D76DD.305@redhat.com> References: <4F17687A.9010504@redhat.com> <4F1D71CF.9080909@redhat.com> <4F1D76DD.305@redhat.com> Message-ID: <4F1DA1A9.40609@redhat.com> On 1/23/2012 9:03 AM, Petr Vobornik wrote: > On 01/23/2012 03:42 PM, Petr Vobornik wrote: >> On 01/19/2012 01:48 AM, Endi Sukma Dewata wrote: >>> The users, HBAC/sudo rules, HBAC test, and SELinux list pages have >>> been modified to show disabled entries in gray. Icons will be added >>> separately. >>> >>> Ticket #1996 >> >> ACK and pushed to master, ipa-2-2 > > The patch is completely fine, but I missed that in Kyle's mockup was > also shown status icons. I assume we want to do it too. > > https://fedorahosted.org/freeipa/attachment/ticket/1996/deactivated_column.png Yes, I was planning to do it after #342 so we can use the same formatter to add the icons into the Status column. -- Endi S. Dewata From edewata at redhat.com Mon Jan 23 18:07:28 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 23 Jan 2012 12:07:28 -0600 Subject: [Freeipa-devel] [PATCH] 341 Show disabled entries in gray. In-Reply-To: <4F1D978E.8080007@redhat.com> References: <4F17687A.9010504@redhat.com> <4F1D71CF.9080909@redhat.com> <4F1D76DD.305@redhat.com> <4F1D978E.8080007@redhat.com> Message-ID: <4F1DA1E0.6070202@redhat.com> On 1/23/2012 11:23 AM, Dmitri Pal wrote: >> https://fedorahosted.org/freeipa/attachment/ticket/1996/deactivated_column.png > > I might be confused but the mockup above does not make much sense. > Is it intended for user list rather than for HBAC because "Account > Status" for HBAC does not make any sense? The mockup was only used to show how the icons and the color should be used to indicate deactivated/disabled entries. Per discussion with Kyle we're changing the "Enabled" and "Account Status" columns into "Status". This way it will be consistent for all entities. https://fedorahosted.org/freeipa/ticket/2247 -- Endi S. Dewata From edewata at redhat.com Mon Jan 23 18:13:41 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 23 Jan 2012 12:13:41 -0600 Subject: [Freeipa-devel] [PATCH] 341 Show disabled entries in gray. In-Reply-To: <4F1DA1E0.6070202@redhat.com> References: <4F17687A.9010504@redhat.com> <4F1D71CF.9080909@redhat.com> <4F1D76DD.305@redhat.com> <4F1D978E.8080007@redhat.com> <4F1DA1E0.6070202@redhat.com> Message-ID: <4F1DA355.6010005@redhat.com> On 1/23/2012 12:07 PM, Endi Sukma Dewata wrote: > On 1/23/2012 11:23 AM, Dmitri Pal wrote: >>> https://fedorahosted.org/freeipa/attachment/ticket/1996/deactivated_column.png >>> >> >> I might be confused but the mockup above does not make much sense. >> Is it intended for user list rather than for HBAC because "Account >> Status" for HBAC does not make any sense? > > The mockup was only used to show how the icons and the color should be > used to indicate deactivated/disabled entries. Per discussion with Kyle > we're changing the "Enabled" and "Account Status" columns into "Status". > This way it will be consistent for all entities. > > https://fedorahosted.org/freeipa/ticket/2247 Here's how it looks now, they all use "Status": Users: http://edewata.fedorapeople.org/freeipa/install/ui/#identity=user&navigation=identity DNS Zones: http://edewata.fedorapeople.org/freeipa/install/ui/#dns=dnszone&identity=dns&navigation=identity HBAC Rules: http://edewata.fedorapeople.org/freeipa/install/ui/#hbac=hbacrule&policy=hbac&navigation=policy Sudo Rules: http://edewata.fedorapeople.org/freeipa/install/ui/#sudo=sudorule&policy=sudo&navigation=policy -- Endi S. Dewata From rcritten at redhat.com Mon Jan 23 20:10:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Jan 2012 15:10:13 -0500 Subject: [Freeipa-devel] [PATCH] 8 localhost.localdomain clients refused to join ipa domain In-Reply-To: <4F197B4F.3060105@redhat.com> References: <4F1412C0.3070204@redhat.com> <4F1894C4.4060704@redhat.com> <4F197B4F.3060105@redhat.com> Message-ID: <4F1DBEA5.2040807@redhat.com> Ondrej Hamada wrote: > On 01/19/2012 11:10 PM, Rob Crittenden wrote: >> Ondrej Hamada wrote: >>> https://fedorahosted.org/freeipa/ticket/2112 >>> >>> Machines with hostname 'localhost.localdomain' are refused from joining >>> IPA domain and proper error message is shown. >> >> This should probably check for just localhost as well. >> >> It is good that the check is done here as ipa-join can be run outside >> of ipa-client-install, but I wonder if it should be checked there as >> well. By the time that ipa-join is called the user is potentially >> prompted for a bunch of data whereas we could check the hostname very >> early in ipa-client-install. >> >> rob > > Hostname checking is now in both ipa-client-install and ipa-join. Also > the checking is done against both the 'localhost' and > 'localhost.localdomain' hostnames. > ACK, pushed to master and ipa-2-2 rob From rcritten at redhat.com Mon Jan 23 20:46:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Jan 2012 15:46:15 -0500 Subject: [Freeipa-devel] [PATCH] 200 Ease zonemgr restrictions In-Reply-To: <1327057225.2204.24.camel@priserak> References: <1327057225.2204.24.camel@priserak> Message-ID: <4F1DC717.70309@redhat.com> Martin Kosek wrote: > Admin e-mail validator currently requires an email to be in > a second-level domain (hostmaster at example.com). This is too > restrictive. Top level domain e-mails (hostmaster at testrelm) > should also be allowed. > > This patch also fixes default zonemgr value in help texts and man > pages. > > https://fedorahosted.org/freeipa/ticket/2272 This fixes the problem of single component domain installation but it does seem to really weaken the checking. For example, if you install with your domain as example.com you can set the zonemgr e-mail to hostmaster at example. I don't want to make this too complex, just wanted another opinion. rob From rcritten at redhat.com Mon Jan 23 21:10:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Jan 2012 16:10:59 -0500 Subject: [Freeipa-devel] [PATCH] 194 Fix ipa-server-install for dual NICs In-Reply-To: <1327048857.2204.13.camel@priserak> References: <1326195613.27400.14.camel@balmora.brq.redhat.com> <1326267331.9621.1.camel@balmora.brq.redhat.com> <4F105242.4010707@redhat.com> <1326485271.2354.3.camel@priserak> <4F18977F.6070407@redhat.com> <1327048857.2204.13.camel@priserak> Message-ID: <4F1DCCE3.4070902@redhat.com> Martin Kosek wrote: > On Thu, 2012-01-19 at 17:21 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Fri, 2012-01-13 at 10:48 -0500, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> It seems I sent two patches with number 189. Sending a patch with a >>>>> correct number. >>>>> >>>>> Martin >>>>> >>>>> On Tue, 2012-01-10 at 12:40 +0100, Martin Kosek wrote: >>>>>> Depends on my patch 188 >>>>>> --- >>>>>> A server may have 2 or more NICs and its hostname may thus resolve >>>>>> to 2 and more forward addresses. IP address checks in install >>>>>> scripts does not expect this setup and may fail or crash. >>>>>> >>>>>> This script adds a support for multiple forward addresses for >>>>>> a hostname. The install scripts do not crash now. When one IP >>>>>> address is needed, user is asked to choose from all detected >>>>>> server IP addresses. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2154 >>>> >>>> You have a patch 190 already as well :-) >>> >>> Hm, yes :-) >>>> >>>> This appears to depend on another patch that I haven't applied yet. Can >>>> you see if it has unpushed dependencies? (removing the adtrust part was >>>> relatively easy and unrelated). >>>> >>>> rob >>> >>> It depended on patch 188 (it was written in the top of the mail). Since >>> it was pushed today, this patch should be applicable to master branch. I >>> checked it and it should be OK. >>> >>> Martin >>> >> >> Still not applying >> >> $ patch -p1 --dry-run< >> /tmp/freeipa-mkosek-190-fix-ipa-server-install-for-dual-nics.patch >> patching file install/tools/ipa-dns-install >> patching file install/tools/ipa-replica-conncheck >> patching file install/tools/ipa-replica-install >> patching file ipapython/dnsclient.py >> Hunk #3 FAILED at 404. >> 1 out of 3 hunks FAILED -- saving rejects to file ipapython/dnsclient.py.rej >> patching file ipaserver/install/bindinstance.py >> patching file ipaserver/install/installutils.py >> > > Hmm, this is a mystery. It applies fine on both my master and ipa-2-2 > branches: > > $ git log --oneline > 8c230f1 Replace float with Decimal > ea678b5 UI for SELinux user mapping > ... > $ git apply ~/patches/freeipa-mkosek-194-ipa-2-2.patch > $ > > I wonder why the patch fails on your ipapython/dnsclient.py as its last > change is somewhere in 2010. > > I attached patches for both master and ipa-2-2 (without the trust bits), > I hope its OK now. These patch includes a fix for unattended mode which > was introduced in previous version. I was even able to finally assign a > unique number to this patch :-) > > Martin ACK, pushed to master and ipa-2-2 rob From rcritten at redhat.com Mon Jan 23 22:04:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Jan 2012 17:04:38 -0500 Subject: [Freeipa-devel] [PATCH] 189 Fix selfservice-find crashes In-Reply-To: <1326700514.3319.3.camel@balmora.brq.redhat.com> References: <1325856654.2159.19.camel@priserak> <4F1053DC.2090503@redhat.com> <1326700514.3319.3.camel@balmora.brq.redhat.com> Message-ID: <4F1DD976.9050200@redhat.com> Martin Kosek wrote: > On Fri, 2012-01-13 at 10:55 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Ignore empty options when performing an ACI search so that the >>> find command does not crash. >>> >>> https://fedorahosted.org/freeipa/ticket/2011 >>> https://fedorahosted.org/freeipa/ticket/2012 >> >> I tested this and it works, I just wanted to confirm that this is the >> behavior we want. Empty search options are ignored. I think we'll want >> to document this somewhere at a minimum. >> >> rob > > I think so. This is the way that our -find commands behave: > > # ipa user-find --last= > -------------- > 1 user matched > -------------- > User login: admin > Last name: Administrator > Home directory: /home/admin > Login shell: /bin/bash > UID: 1198000000 > GID: 1198000000 > Account disabled: False > Password: True > Kerberos keys available: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > > I wondered where to add this information, this is what "man ipa" says: > > find commands take an optional criteria string as their only positional argument. If present, > all objects with an attribute that contains the criteria string are displayed. If an option > representing an attribute is set, only object with the attribute exactly matching the speci? > fied value are displayed. Without parameters all objects of the corresponding type are dis? > played. > > We may enhance this documentation if we find it insufficient. > > Martin > I think adding something like: "Options with empty values are ignored" or something like that. rob From rcritten at redhat.com Mon Jan 23 22:08:19 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Jan 2012 17:08:19 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F16A0FB.9080808@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> Message-ID: <4F1DDA53.6090206@redhat.com> Jan Cholasta wrote: > Dne 18.1.2012 00:04, Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>>> Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>>> When viewing a certificate it will show the serial number as hex >>>>>>> (dec). >>>>>>> >>>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>>> Certificate: [snip] >>>>>>> Keytab: True >>>>>>> Managed by: rawhide.example.com >>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>>> Serial Number: 0x403 (1027) >>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>>> Fingerprint (SHA1): >>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> NACK >>>>>> >>>>>> Displaying a host or a service in the webUI fails with "IPA error >>>>>> 3009: >>>>>> invalid 'serial_number': Decimal or hexadecimal number is required >>>>>> for >>>>>> serial number". >>>>>> >>>>>> I would suggest to do the nifty formatting of serial numbers on the >>>>>> client side, that would fix the webUI issue, allow non-IPA clients to >>>>>> parse the number without dissecting the string representation of it >>>>>> and >>>>>> probably also save me a hack in the type conversion overhaul. You >>>>>> could >>>>>> for example add a parameter flag like "format_serial_number" to >>>>>> indicate >>>>>> to the client that it should format the value as a serial number. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Well, we want to do as little client formatting as possible. The >>>>> idea is >>>>> to have a very thin client. >>> >>> It doesn't seem right to me to enforce this specific representation of >>> what is really just an integer at the API level. Doing a little >>> formatting on the client side won't make the client(s) particularly fat, >>> will it? >> >> Yes. The current code just outputs labels and data. There is no "if it >> is this attribute then do that" logic. >> >>> >>> IMHO there is too much stuff done on server that would make more sense >>> to do on client anyway (especially CLI-specific stuff such as CSV >>> parsing). What is the reason we want such a thin client? >> >> To avoid double work such that every time we want a formatting change we >> have to change it in multiple places. This lesson was learned in v1. >> >>> I believe there should be clear separation of presentation and content, >>> but perhaps I'm a little bit too idealistic :-). >> >> You have a point, serial number is defined as an integer. Perhaps we >> should revisit this decision to display hex at all. >> >> >>> >>>>> >>>>> I'll look into fixing the UI side. >>>> >>>> I don't see this error in services, it displays correctly. I'm not sure >>>> if it is my browser or what but hosts don't display much of anything >>>> for >>>> me. >>>> >>>> rob >>> >>> I have just checked both master and ipa-2-2 and I'm getting the same >>> error message (tested in Firefox 9.0.1) when viewing details of a host >>> or a service with the usercertificate attribute set. >>> >>> BTW, wouldn't it make sense to format serial numbers in the cert plugin >>> in the same way? >> >> Perhaps. Like I said, I'm not really in favor of this change. >> >> rob > > Maybe we can do a compromise of some sort. What about allowing the > client to specify with each request what representation/formatting the > server should use for the resulting entries and attributes? That would be mighty flexible but would open a new can of worms. I think long term I'd like to be able to request what attributes to see (ala ldapsearch) but that too is a bit out of scope. This comes down to Output being rather loosely defined and we already have a ticket open on that. It basically just defines the broad types of data to be returned (string, list, dict, etc) but not the internal components of complex types. rob From jdennis at redhat.com Mon Jan 23 23:03:15 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 Jan 2012 18:03:15 -0500 Subject: [Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance In-Reply-To: <4F105CD5.7090409@redhat.com> References: <4EE90D98.6030900@redhat.com> <4F0F6068.9000602@redhat.com> <4F0F6998.8020507@redhat.com> <4F0FAA9E.1080601@redhat.com> <4F105CD5.7090409@redhat.com> Message-ID: <4F1DE733.9080502@redhat.com> This patch supersedes the previous patch, it corrects two issue Rob raised in a later patch review The fixed issues are: * spec file did not install ipa_memcached SysV initscript on SvsV systems. * Typo in the name of the pid file variable in the ipa_memcached initscript -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0059-1-Modify-spec-file-to-add-ipa_memcached-service-Instal.patch Type: text/x-patch Size: 10116 bytes Desc: not available URL: From jdennis at redhat.com Mon Jan 23 23:11:41 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 Jan 2012 18:11:41 -0500 Subject: [Freeipa-devel] [PATCH 60] Implement session support in server, Manage sessions in WSGI In-Reply-To: <4EE90EA8.5020803@redhat.com> References: <4EE90EA8.5020803@redhat.com> Message-ID: <4F1DE92D.2030109@redhat.com> This patch is self NAK'ed because it's contents have been rolled into the rebased patch freeipa-jdennis-0061-1-add-session-manager-and-cache-krb-auth.patch -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Mon Jan 23 23:15:42 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 Jan 2012 18:15:42 -0500 Subject: [Freeipa-devel] [PATCH 61] Cache authentication in session In-Reply-To: <4F15EA10.7010206@redhat.com> References: <4F0F90F2.40403@redhat.com> <4F15EA10.7010206@redhat.com> Message-ID: <4F1DEA1E.2090807@redhat.com> On 01/17/2012 04:37 PM, Rob Crittenden wrote: > John Dennis wrote: >> > > > Both of these are defined in ipalib/rpc.py (among others): > > +KRB5_CC_NOTFOUND = -1765328243 # Matching credential not found > +KRB5_FCC_NOFILE = -1765328189 # No credentials cache found > > Perhaps all those defines should be moved to krb_utils.py. > > RPM build errors on non-SysV systems: > File listed twice: /usr/share/ipa/ui/extension.js > Installed (but unpackaged) file(s) found: > /etc/rc.d/init.d/ipa_memcached > make: *** [rpms] Error 1 > > (extention.js isn't yours) > > In the ipa_memcached service PID_PATH needs to be PIDFILE. > > It would be nice if sessions worked with the lite-server. > > I am unable to view the web UI. It just loops requesting all the the > javascript files over and over again. > > rob Rebased patch attached (includes contents of previous patch 60). The issues with ipa_memcached belonged to patch 59, that patch was rebased and resubmitted. I cannot reproduce the looping problem you saw. The only thing I can think of is that you were running with SELinux enabled and currently ipa_memcached requires SELinux to be disabled otherwise the whole caching mechanism fails. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Mon Jan 23 23:17:11 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 Jan 2012 18:17:11 -0500 Subject: [Freeipa-devel] [PATCH 61] Cache authentication in session In-Reply-To: <4F1DEA1E.2090807@redhat.com> References: <4F0F90F2.40403@redhat.com> <4F15EA10.7010206@redhat.com> <4F1DEA1E.2090807@redhat.com> Message-ID: <4F1DEA77.8040408@redhat.com> On 01/23/2012 06:15 PM, John Dennis wrote: > Rebased patch attached (includes contents of previous patch 60). > > The issues with ipa_memcached belonged to patch 59, that patch was > rebased and resubmitted. > > I cannot reproduce the looping problem you saw. The only thing I can > think of is that you were running with SELinux enabled and currently > ipa_memcached requires SELinux to be disabled otherwise the whole > caching mechanism fails. O.K., let's try this again with the patch actually attached :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0061-1-add-session-manager-and-cache-krb-auth.patch Type: text/x-patch Size: 78549 bytes Desc: not available URL: From rmeggins at redhat.com Tue Jan 24 00:27:37 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 23 Jan 2012 17:27:37 -0700 Subject: [Freeipa-devel] 389 systemd changes In-Reply-To: <20120123143708.GL29844@redhat.com> References: <4F19F437.8040809@redhat.com> <20120121085432.GG29844@redhat.com> <1327217475.13963.91.camel@willson.li.ssimo.org> <20120122131233.GI29844@redhat.com> <1327271277.13963.92.camel@willson.li.ssimo.org> <20120123060348.GJ29844@redhat.com> <1327325049.13963.97.camel@willson.li.ssimo.org> <20120123143708.GL29844@redhat.com> Message-ID: <4F1DFAF9.4010708@redhat.com> On 01/23/2012 07:37 AM, Alexander Bokovoy wrote: > On Mon, 23 Jan 2012, Simo Sorce wrote: >> On Mon, 2012-01-23 at 08:03 +0200, Alexander Bokovoy wrote: >>> On Sun, 22 Jan 2012, Simo Sorce wrote: >>>>>> Shouldn't we just 'include' the original file and not copy it ? >>>>>> If we include it a change in the file will be automatically picked up. >>>>> We can't due to systemd design and use of it in 389-ds. >>>>> >>>>> LimitNOFILE needs to be changed in the service file directly, not in >>>>> the environment file in /etc/sysconfig or otherwise it will not be >>>>> picked up by the systemd. >>>> I am not talking about using /set/sysconfig options, but the .include >>>> directive for service files. >>> So, something like this for 389-ds? >> No, you should include the actual dirsrv default service file (if any, >> otherwise the sysconfig one might be ok I guess). > There is /lib/systemd/system/dirsrv at .service. The content below is > from there and I think there is no need to make .include in a > /etc/systemd/system/dirsrv at .service copy of it as we can ask Rich to > make proper change in the original service unit. > > This way we only would have settings in /etc/sysconfig (or in > /etc/dirsrv if that's better) and you'd have no need to intervene into > /etc/systemd/system. Paths are irrelevant but I'd prefer to use common > places like /etc/sysconfig. Done. This will be going out in 1.2.10.a7. I also changed the spec file so that the .pid files are removed after shutting down the servers and before doing the update, so the update to a7 should be smooth even if ipa does not amend the service file. Please test and let me know (once it is available). >>> ----8<--------8<--------8<--------- >>> [Unit] >>> Description=389 Directory Server %i. >>> BindTo=dirsrv.target >>> After=dirsrv.target >>> >>> [Service] >>> Type=forking >>> Environment=PIDDIR=/var/run/dirsrv >>> EnvironmentFile=/etc/sysconfig/dirsrv >>> EnvironmentFile=/etc/sysconfig/dirsrv-%i >>> ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i ${PIDDIR}/slapd-%i.pid -w ${PIDDIR}/slapd-%i.startpid >>> .include /etc/sysconfig/dirsrv.systemd >>> ----8<--------8<--------8<--------- >>> >>> and then with following /etc/sysconfig/dirsrv.systemd: >>> ----8<--------8<--------8<--------- >>> [Service] >>> LimitNOFILE=8192 >>> ----8<--------8<--------8<--------- >>> >>> local overrides can be created? >> Yes I think if you put directives after the include they will override >> whatever is in the include. > Depends on directive. > > >> Also I would put as much as possible in the include file and put in the >> specific instance files only the parameters we need to override. > There is no specific instance service unit. There is one service unit > that processes all instances, that's the whole purpose of @-services > (dirsrv at .service). > >>> It seems to work. You can't use %i macro in .include unfortunately so >>> any configuration change will be global, not per service instance. >> That's fine we want to put in there only global configuration anyways, >> and then override in our specific per instance control files. > See above. There are no per-instance control files. > From mkosek at redhat.com Tue Jan 24 07:58:27 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jan 2012 08:58:27 +0100 Subject: [Freeipa-devel] [PATCH] 927 fix deleting hbac rules when selinux user maps are involved In-Reply-To: <4F1D96FA.60708@redhat.com> References: <4F15FD43.5000402@redhat.com> <1327336609.11792.23.camel@balmora.brq.redhat.com> <4F1D96FA.60708@redhat.com> Message-ID: <1327391907.8230.3.camel@balmora.brq.redhat.com> On Mon, 2012-01-23 at 12:20 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2012-01-17 at 17:59 -0500, Rob Crittenden wrote: > >> When deleting an HBAC rule we need to ensure that an SELinux user map > >> isn't pointing at it. The search for this didn't work well at all. > >> > >> This patch corrects the search and makes it more specific. > >> > >> I also tested that it works with the --continue flag of hbacrule-del. > >> > >> The ticket has instructions on testing. > >> > >> rob > > > > Works fine. There is just one part that is IMO too complicated: > > > > + hbacrule = options['seealso'] > > + kw = dict(cn=hbacrule, all=True) > > _entries = api.Command.hbacrule_find(None, **kw)['result'] > > del options['seealso'] > > - if _entries: > > - options['seealso'] = _entries[0]['dn'] > > + found = False > > + # look for an exact match. The search may return partial > > + # matches. > > + for entry in _entries: > > + if entry['cn'][0] == hbacrule: > > + found = True > > + options['seealso'] = entry['dn'] > > + if not found: > > + return dict(count=0, result=[], truncated=False) > > > > I think hbacrule_find(None, cn=HBACRULE) should not return partial > > matches, but just the exact match (tried with hbacrule-find > > --name=HBACRULE). Then the loop over entries wouldn't be needed. > > > > Couldn't we simply call hbacrule_show since we want just one HBAC rule > > with a known primary key? > > > > Martin > > > > hbacrule_show would need to be modified to take a dn, that would be a > way to fix this. > > rob Not sure I see the problem with hbacrule_show. I tested this piece of code and it worked fine: selinuxusermap_find: ... if 'seealso' in options: hbacrule = options['seealso'] try: hbac = api.Command['hbacrule_show'](hbacrule, all=True)['result'] dn = hbac['dn'] except errors.NotFound: return dict(count=0, result=[], truncated=False) options['seealso'] = dn ... Martin From mkosek at redhat.com Tue Jan 24 08:15:38 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jan 2012 09:15:38 +0100 Subject: [Freeipa-devel] [PATCH] 200 Ease zonemgr restrictions In-Reply-To: <4F1DC717.70309@redhat.com> References: <1327057225.2204.24.camel@priserak> <4F1DC717.70309@redhat.com> Message-ID: <1327392938.8230.10.camel@balmora.brq.redhat.com> On Mon, 2012-01-23 at 15:46 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > Admin e-mail validator currently requires an email to be in > > a second-level domain (hostmaster at example.com). This is too > > restrictive. Top level domain e-mails (hostmaster at testrelm) > > should also be allowed. > > > > This patch also fixes default zonemgr value in help texts and man > > pages. > > > > https://fedorahosted.org/freeipa/ticket/2272 > > This fixes the problem of single component domain installation but it > does seem to really weaken the checking. > > For example, if you install with your domain as example.com you can set > the zonemgr e-mail to hostmaster at example. > > I don't want to make this too complex, just wanted another opinion. > > rob Good point. But if we want to allow top-level domain e-mails we'd need to allow e-mails like hostmaster at example. How would this situation be different from hostmaster at testrelm ? (This was the reported failing e-mail). Both e-mails are syntactically OK. Martin From mkosek at redhat.com Tue Jan 24 08:30:48 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jan 2012 09:30:48 +0100 Subject: [Freeipa-devel] [PATCH] 189 Fix selfservice-find crashes In-Reply-To: <4F1DD976.9050200@redhat.com> References: <1325856654.2159.19.camel@priserak> <4F1053DC.2090503@redhat.com> <1326700514.3319.3.camel@balmora.brq.redhat.com> <4F1DD976.9050200@redhat.com> Message-ID: <1327393848.8230.12.camel@balmora.brq.redhat.com> On Mon, 2012-01-23 at 17:04 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2012-01-13 at 10:55 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> Ignore empty options when performing an ACI search so that the > >>> find command does not crash. > >>> > >>> https://fedorahosted.org/freeipa/ticket/2011 > >>> https://fedorahosted.org/freeipa/ticket/2012 > >> > >> I tested this and it works, I just wanted to confirm that this is the > >> behavior we want. Empty search options are ignored. I think we'll want > >> to document this somewhere at a minimum. > >> > >> rob > > > > I think so. This is the way that our -find commands behave: > > > > # ipa user-find --last= > > -------------- > > 1 user matched > > -------------- > > User login: admin > > Last name: Administrator > > Home directory: /home/admin > > Login shell: /bin/bash > > UID: 1198000000 > > GID: 1198000000 > > Account disabled: False > > Password: True > > Kerberos keys available: True > > ---------------------------- > > Number of entries returned 1 > > ---------------------------- > > > > I wondered where to add this information, this is what "man ipa" says: > > > > find commands take an optional criteria string as their only positional argument. If present, > > all objects with an attribute that contains the criteria string are displayed. If an option > > representing an attribute is set, only object with the attribute exactly matching the speci? > > fied value are displayed. Without parameters all objects of the corresponding type are dis? > > played. > > > > We may enhance this documentation if we find it insufficient. > > > > Martin > > > > I think adding something like: "Options with empty values are ignored" > or something like that. > > rob Good idea. I enhanced ipa(1) man pages with this information (and made the header more consistent with a rest of our man pages). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-189-2-fix-selfservice-find-crashes.patch Type: text/x-patch Size: 7195 bytes Desc: not available URL: From abokovoy at redhat.com Tue Jan 24 11:02:18 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Jan 2012 13:02:18 +0200 Subject: [Freeipa-devel] freeipa is broken in Rawhide due to python-ldap 2.4.6 Message-ID: <20120124110218.GA11943@redhat.com> Hi! Apparently, Rawhide has moved to python-ldap 2.4.6. This release breaks freeipa build as EncodeControlTuples is not exposed (neither exist) in 2.4 branch anymore. Thus, our make-lint fails. The build in Rawhide itself doesn't fail as can be seen by freeipa-2.1.4-4.fc17 because we don't run make-lint during build process. However, FreeIPA installation will fail as ipaserver/ipaldap.py tries to import the symbol which does not exist. The fix is simple but before applying it under one-liner rule can someone explain me what was the purpose of using these control tuples symbols? I've got through git history for the ipaserver/ipaldap.py down to its initial version and while symbols were introduced, they were never used. diff --git a/ipaserver/ipaldap.py b/ipaserver/ipaldap.py index 4dca604..f69ebe6 100644 --- a/ipaserver/ipaldap.py +++ b/ipaserver/ipaldap.py @@ -32,7 +32,7 @@ import time import struct import ldap.sasl import ldapurl -from ldap.controls import LDAPControl,DecodeControlTuples,EncodeControlTuples +from ldap.controls import LDAPControl from ldap.ldapobject import SimpleLDAPObject from ipaserver import ipautil from ipalib import errors -- / Alexander Bokovoy From rcritten at redhat.com Tue Jan 24 13:42:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Jan 2012 08:42:33 -0500 Subject: [Freeipa-devel] freeipa is broken in Rawhide due to python-ldap 2.4.6 In-Reply-To: <20120124110218.GA11943@redhat.com> References: <20120124110218.GA11943@redhat.com> Message-ID: <4F1EB549.2080408@redhat.com> Alexander Bokovoy wrote: > Hi! > > Apparently, Rawhide has moved to python-ldap 2.4.6. This release > breaks freeipa build as EncodeControlTuples is not exposed (neither > exist) in 2.4 branch anymore. Thus, our make-lint fails. > > The build in Rawhide itself doesn't fail as can be seen by > freeipa-2.1.4-4.fc17 because we don't run make-lint during build > process. However, FreeIPA installation will fail as > ipaserver/ipaldap.py tries to import the symbol which does not exist. > > The fix is simple but before applying it under one-liner rule can > someone explain me what was the purpose of using these control tuples > symbols? I've got through git history for the ipaserver/ipaldap.py > down to its initial version and while symbols were introduced, they > were never used. > > diff --git a/ipaserver/ipaldap.py b/ipaserver/ipaldap.py > index 4dca604..f69ebe6 100644 > --- a/ipaserver/ipaldap.py > +++ b/ipaserver/ipaldap.py > @@ -32,7 +32,7 @@ import time > import struct > import ldap.sasl > import ldapurl > -from ldap.controls import LDAPControl,DecodeControlTuples,EncodeControlTuples > +from ldap.controls import LDAPControl > from ldap.ldapobject import SimpleLDAPObject > from ipaserver import ipautil > from ipalib import errors > This looks fine, ACK. This dates back to 2007 when the project first started. We were having a heck of a time getting delegated TGTs working so we came up with a fallback mechanism using the LDAP proxy control. Basically we would take the incoming principal, convert it into a DN, bind to LDAP using a client cert issued to the server during install, then execute this proxy control to "become" that user (and this code is still available in ipaldap.py now). As it turned out we didn't need these other two imports but they were never removed. Fortunately we found the python GSSAPI code in the Apple calendar project and were able to package that (though we've long suffered under their horrible naming convention of calling it pyKerberos). rob From rcritten at redhat.com Tue Jan 24 14:21:32 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Jan 2012 09:21:32 -0500 Subject: [Freeipa-devel] [PATCH] 200 Ease zonemgr restrictions In-Reply-To: <1327392938.8230.10.camel@balmora.brq.redhat.com> References: <1327057225.2204.24.camel@priserak> <4F1DC717.70309@redhat.com> <1327392938.8230.10.camel@balmora.brq.redhat.com> Message-ID: <4F1EBE6C.2090002@redhat.com> Martin Kosek wrote: > On Mon, 2012-01-23 at 15:46 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Admin e-mail validator currently requires an email to be in >>> a second-level domain (hostmaster at example.com). This is too >>> restrictive. Top level domain e-mails (hostmaster at testrelm) >>> should also be allowed. >>> >>> This patch also fixes default zonemgr value in help texts and man >>> pages. >>> >>> https://fedorahosted.org/freeipa/ticket/2272 >> >> This fixes the problem of single component domain installation but it >> does seem to really weaken the checking. >> >> For example, if you install with your domain as example.com you can set >> the zonemgr e-mail to hostmaster at example. >> >> I don't want to make this too complex, just wanted another opinion. >> >> rob > > Good point. But if we want to allow top-level domain e-mails we'd need > to allow e-mails like hostmaster at example. How would this situation be > different from hostmaster at testrelm ? (This was the reported failing > e-mail). Both e-mails are syntactically OK. > > Martin > The complex part I had in mind was comparing the domain in the e-mail addr with the configured domain. We need to be able to support when IPA is itself a subdomain but the hostmaster is in the primary: domain=sub.example.com, hostmaster at example.com. It might also point somewhere else entirely, hostmaster at hosted.com. Maybe we ensure that the e-mail address domain is equal to or a part of the configured domain OR the domain is already resolvable? So move right to left matching as it goes. Of course this would allow hostmaster at com but we may just have to live with it. rob From pvoborni at redhat.com Tue Jan 24 14:52:09 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jan 2012 15:52:09 +0100 Subject: [Freeipa-devel] [PATCH] 071 Added paging to DNS record search facet Message-ID: <4F1EC599.20302@redhat.com> Patch Description: Paging in DNS record search facet was disabled because there was a mismatch between primary keys sent by server and values displayed in the facet. The facet was modified to enable paging. To preserve amount of information which was displayed before, current rows have variable height - they can contain more that one line depending on number of values in the record. Each record has a checkbox and indsname in its first line to distinguish one record from others. Because there is only one checkbox for record, delete command is called with --del-all option which causes that entire record is removed. Individual values can be deleted in record's details facet. https://fedorahosted.org/freeipa/ticket/2094 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0071-Added-paging-to-DNS-record-search-facet.patch Type: text/x-patch Size: 7012 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 24 15:08:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Jan 2012 10:08:33 -0500 Subject: [Freeipa-devel] [PATCH] 927 fix deleting hbac rules when selinux user maps are involved In-Reply-To: <1327391907.8230.3.camel@balmora.brq.redhat.com> References: <4F15FD43.5000402@redhat.com> <1327336609.11792.23.camel@balmora.brq.redhat.com> <4F1D96FA.60708@redhat.com> <1327391907.8230.3.camel@balmora.brq.redhat.com> Message-ID: <4F1EC971.5070702@redhat.com> Martin Kosek wrote: > On Mon, 2012-01-23 at 12:20 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Tue, 2012-01-17 at 17:59 -0500, Rob Crittenden wrote: >>>> When deleting an HBAC rule we need to ensure that an SELinux user map >>>> isn't pointing at it. The search for this didn't work well at all. >>>> >>>> This patch corrects the search and makes it more specific. >>>> >>>> I also tested that it works with the --continue flag of hbacrule-del. >>>> >>>> The ticket has instructions on testing. >>>> >>>> rob >>> >>> Works fine. There is just one part that is IMO too complicated: >>> >>> + hbacrule = options['seealso'] >>> + kw = dict(cn=hbacrule, all=True) >>> _entries = api.Command.hbacrule_find(None, **kw)['result'] >>> del options['seealso'] >>> - if _entries: >>> - options['seealso'] = _entries[0]['dn'] >>> + found = False >>> + # look for an exact match. The search may return partial >>> + # matches. >>> + for entry in _entries: >>> + if entry['cn'][0] == hbacrule: >>> + found = True >>> + options['seealso'] = entry['dn'] >>> + if not found: >>> + return dict(count=0, result=[], truncated=False) >>> >>> I think hbacrule_find(None, cn=HBACRULE) should not return partial >>> matches, but just the exact match (tried with hbacrule-find >>> --name=HBACRULE). Then the loop over entries wouldn't be needed. >>> >>> Couldn't we simply call hbacrule_show since we want just one HBAC rule >>> with a known primary key? >>> >>> Martin >>> >> >> hbacrule_show would need to be modified to take a dn, that would be a >> way to fix this. >> >> rob > > Not sure I see the problem with hbacrule_show. I tested this piece of > code and it worked fine: > > selinuxusermap_find: > ... > if 'seealso' in options: > hbacrule = options['seealso'] > > try: > hbac = api.Command['hbacrule_show'](hbacrule, > all=True)['result'] > dn = hbac['dn'] > except errors.NotFound: > return dict(count=0, result=[], truncated=False) > options['seealso'] = dn > ... > > Martin > Ok, I misunderstood your point. Yes, this is vastly better. Updated patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-927-1-selinux.patch Type: text/x-diff Size: 5765 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 24 15:33:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Jan 2012 10:33:13 -0500 Subject: [Freeipa-devel] [PATCH] 189 Fix selfservice-find crashes In-Reply-To: <1327393848.8230.12.camel@balmora.brq.redhat.com> References: <1325856654.2159.19.camel@priserak> <4F1053DC.2090503@redhat.com> <1326700514.3319.3.camel@balmora.brq.redhat.com> <4F1DD976.9050200@redhat.com> <1327393848.8230.12.camel@balmora.brq.redhat.com> Message-ID: <4F1ECF39.4040005@redhat.com> Martin Kosek wrote: > On Mon, 2012-01-23 at 17:04 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Fri, 2012-01-13 at 10:55 -0500, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> Ignore empty options when performing an ACI search so that the >>>>> find command does not crash. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2011 >>>>> https://fedorahosted.org/freeipa/ticket/2012 >>>> >>>> I tested this and it works, I just wanted to confirm that this is the >>>> behavior we want. Empty search options are ignored. I think we'll want >>>> to document this somewhere at a minimum. >>>> >>>> rob >>> >>> I think so. This is the way that our -find commands behave: >>> >>> # ipa user-find --last= >>> -------------- >>> 1 user matched >>> -------------- >>> User login: admin >>> Last name: Administrator >>> Home directory: /home/admin >>> Login shell: /bin/bash >>> UID: 1198000000 >>> GID: 1198000000 >>> Account disabled: False >>> Password: True >>> Kerberos keys available: True >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> I wondered where to add this information, this is what "man ipa" says: >>> >>> find commands take an optional criteria string as their only positional argument. If present, >>> all objects with an attribute that contains the criteria string are displayed. If an option >>> representing an attribute is set, only object with the attribute exactly matching the speci? >>> fied value are displayed. Without parameters all objects of the corresponding type are dis? >>> played. >>> >>> We may enhance this documentation if we find it insufficient. >>> >>> Martin >>> >> >> I think adding something like: "Options with empty values are ignored" >> or something like that. >> >> rob > > Good idea. I enhanced ipa(1) man pages with this information (and made > the header more consistent with a rest of our man pages). > > Martin ACK From rcritten at redhat.com Tue Jan 24 15:48:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Jan 2012 10:48:01 -0500 Subject: [Freeipa-devel] [PATCH] 193 Mark optional DNS record parts In-Reply-To: <1326981324.24237.20.camel@balmora.brq.redhat.com> References: <1326981324.24237.20.camel@balmora.brq.redhat.com> Message-ID: <4F1ED2B1.80701@redhat.com> Martin Kosek wrote: > This patch is needed for ticket 2208 (UI for new DNS interface) so that > UI can distinguish between required and optional DNS part params. > > Martin ACK from me if this is what the UI needs. rob From mkosek at redhat.com Tue Jan 24 15:54:48 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jan 2012 16:54:48 +0100 Subject: [Freeipa-devel] [PATCH] 189 Fix selfservice-find crashes In-Reply-To: <4F1ECF39.4040005@redhat.com> References: <1325856654.2159.19.camel@priserak> <4F1053DC.2090503@redhat.com> <1326700514.3319.3.camel@balmora.brq.redhat.com> <4F1DD976.9050200@redhat.com> <1327393848.8230.12.camel@balmora.brq.redhat.com> <4F1ECF39.4040005@redhat.com> Message-ID: <1327420488.8230.20.camel@balmora.brq.redhat.com> On Tue, 2012-01-24 at 10:33 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2012-01-23 at 17:04 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Fri, 2012-01-13 at 10:55 -0500, Rob Crittenden wrote: > >>>> Martin Kosek wrote: > >>>>> Ignore empty options when performing an ACI search so that the > >>>>> find command does not crash. > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/2011 > >>>>> https://fedorahosted.org/freeipa/ticket/2012 > >>>> > >>>> I tested this and it works, I just wanted to confirm that this is the > >>>> behavior we want. Empty search options are ignored. I think we'll want > >>>> to document this somewhere at a minimum. > >>>> > >>>> rob > >>> > >>> I think so. This is the way that our -find commands behave: > >>> > >>> # ipa user-find --last= > >>> -------------- > >>> 1 user matched > >>> -------------- > >>> User login: admin > >>> Last name: Administrator > >>> Home directory: /home/admin > >>> Login shell: /bin/bash > >>> UID: 1198000000 > >>> GID: 1198000000 > >>> Account disabled: False > >>> Password: True > >>> Kerberos keys available: True > >>> ---------------------------- > >>> Number of entries returned 1 > >>> ---------------------------- > >>> > >>> I wondered where to add this information, this is what "man ipa" says: > >>> > >>> find commands take an optional criteria string as their only positional argument. If present, > >>> all objects with an attribute that contains the criteria string are displayed. If an option > >>> representing an attribute is set, only object with the attribute exactly matching the speci? > >>> fied value are displayed. Without parameters all objects of the corresponding type are dis? > >>> played. > >>> > >>> We may enhance this documentation if we find it insufficient. > >>> > >>> Martin > >>> > >> > >> I think adding something like: "Options with empty values are ignored" > >> or something like that. > >> > >> rob > > > > Good idea. I enhanced ipa(1) man pages with this information (and made > > the header more consistent with a rest of our man pages). > > > > Martin > > ACK Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Tue Jan 24 15:57:13 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jan 2012 16:57:13 +0100 Subject: [Freeipa-devel] [PATCH] 193 Mark optional DNS record parts In-Reply-To: <4F1ED2B1.80701@redhat.com> References: <1326981324.24237.20.camel@balmora.brq.redhat.com> <4F1ED2B1.80701@redhat.com> Message-ID: <1327420633.8230.21.camel@balmora.brq.redhat.com> On Tue, 2012-01-24 at 10:48 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > This patch is needed for ticket 2208 (UI for new DNS interface) so that > > UI can distinguish between required and optional DNS part params. > > > > Martin > > ACK from me if this is what the UI needs. > > rob Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Tue Jan 24 16:22:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jan 2012 17:22:22 +0100 Subject: [Freeipa-devel] [PATCH] 927 fix deleting hbac rules when selinux user maps are involved In-Reply-To: <4F1EC971.5070702@redhat.com> References: <4F15FD43.5000402@redhat.com> <1327336609.11792.23.camel@balmora.brq.redhat.com> <4F1D96FA.60708@redhat.com> <1327391907.8230.3.camel@balmora.brq.redhat.com> <4F1EC971.5070702@redhat.com> Message-ID: <1327422142.8230.23.camel@balmora.brq.redhat.com> On Tue, 2012-01-24 at 10:08 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2012-01-23 at 12:20 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Tue, 2012-01-17 at 17:59 -0500, Rob Crittenden wrote: > >>>> When deleting an HBAC rule we need to ensure that an SELinux user map > >>>> isn't pointing at it. The search for this didn't work well at all. > >>>> > >>>> This patch corrects the search and makes it more specific. > >>>> > >>>> I also tested that it works with the --continue flag of hbacrule-del. > >>>> > >>>> The ticket has instructions on testing. > >>>> > >>>> rob > >>> > >>> Works fine. There is just one part that is IMO too complicated: > >>> > >>> + hbacrule = options['seealso'] > >>> + kw = dict(cn=hbacrule, all=True) > >>> _entries = api.Command.hbacrule_find(None, **kw)['result'] > >>> del options['seealso'] > >>> - if _entries: > >>> - options['seealso'] = _entries[0]['dn'] > >>> + found = False > >>> + # look for an exact match. The search may return partial > >>> + # matches. > >>> + for entry in _entries: > >>> + if entry['cn'][0] == hbacrule: > >>> + found = True > >>> + options['seealso'] = entry['dn'] > >>> + if not found: > >>> + return dict(count=0, result=[], truncated=False) > >>> > >>> I think hbacrule_find(None, cn=HBACRULE) should not return partial > >>> matches, but just the exact match (tried with hbacrule-find > >>> --name=HBACRULE). Then the loop over entries wouldn't be needed. > >>> > >>> Couldn't we simply call hbacrule_show since we want just one HBAC rule > >>> with a known primary key? > >>> > >>> Martin > >>> > >> > >> hbacrule_show would need to be modified to take a dn, that would be a > >> way to fix this. > >> > >> rob > > > > Not sure I see the problem with hbacrule_show. I tested this piece of > > code and it worked fine: > > > > selinuxusermap_find: > > ... > > if 'seealso' in options: > > hbacrule = options['seealso'] > > > > try: > > hbac = api.Command['hbacrule_show'](hbacrule, > > all=True)['result'] > > dn = hbac['dn'] > > except errors.NotFound: > > return dict(count=0, result=[], truncated=False) > > options['seealso'] = dn > > ... > > > > Martin > > > > Ok, I misunderstood your point. Yes, this is vastly better. Updated > patch attached. > > rob ACK if you change if 'seealso' in options: to: if options.get('seealso'): so that the following case is fixed: # ipa selinuxusermap-find --hbacrule= ipa: ERROR: 'cn' is required Martin From pvoborni at redhat.com Tue Jan 24 17:38:18 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jan 2012 18:38:18 +0100 Subject: [Freeipa-devel] [PATCH] 070 Modifying DNS UI to benefit from new DNS API In-Reply-To: <4F1D84DA.30802@redhat.com> References: <4F1D84DA.30802@redhat.com> Message-ID: <4F1EEC8A.4090508@redhat.com> On 01/23/2012 05:03 PM, Petr Vobornik wrote: > DNS UI was modified to offer structured way of defining DNS records. > > https://fedorahosted.org/freeipa/ticket/2208 > > This patch depends on Martin's patch #193. > > Preview: > http://pvoborni.fedorapeople.org/dns/#dns=dnsrecord&identity=dns&navigation=identity&dnsrecord-facet=default&dnsrecord-pkey=testrec&dnszone-pkey=test.com > > > Possible modifications: > 1) modify labels to exclude record type's name. > 2) hide empty tables (as I suggested in ticket description) > 3) attributes which are displayed in table columns can be easily changed > or reordered. I used following principle: "If type has up to 4 > attributes: show them all in table if not, show raw value." This way all > data are displayed and columns are not too narrow. > > The static page preview was extended. It now contains also modifications from my patch #071 - paging in DNS record search facet ( https://fedorahosted.org/freeipa/ticket/2094 ) Search facet page: http://pvoborni.fedorapeople.org/dns/#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=test.com -- Petr Vobornik From edewata at redhat.com Tue Jan 24 20:03:54 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 24 Jan 2012 14:03:54 -0600 Subject: [Freeipa-devel] [PATCH] 070 Modifying DNS UI to benefit from new DNS API In-Reply-To: <4F1D84DA.30802@redhat.com> References: <4F1D84DA.30802@redhat.com> Message-ID: <4F1F0EAA.6090908@redhat.com> On 1/23/2012 10:03 AM, Petr Vobornik wrote: > DNS UI was modified to offer structured way of defining DNS records. > > https://fedorahosted.org/freeipa/ticket/2208 > > This patch depends on Martin's patch #193. > > Preview: > http://pvoborni.fedorapeople.org/dns/#dns=dnsrecord&identity=dns&navigation=identity&dnsrecord-facet=default&dnsrecord-pkey=testrec&dnszone-pkey=test.com Some issues that I think need to be fixed before push: 1. In the record details page, deleting the last value in the record generates a JavaScript error stopping the execution. It should redirect back to the search page. 2. The nsec_part_types is multi-valued, but the drop down list only allows one value. We might need to use a text field to allow multiple values until we find a better solution. Right now this can't be tested properly due to https://fedorahosted.org/freeipa/ticket/2307. 3. Some attributes should be displayed as a drop down list in the dialog box. One of them is already defined using options but it does not appear as a drop down list. They include: * sig_part_type_covered * rrsig_part_type_covered * naptr_part_flags 4. There should be enough space to show the attributes of the following records in separate columns (instead of showing the raw data): * SRV * SSHFP 5. The following attributes probably should be shown as text areas in the edit dialog and should not be displayed in the table because it could be too long: * cert_part_certificate_or_crl * ds_part_digest * key_part_public_key * sig_part_signature * rrsig_part_signature * sshfp_part_fingerprint 6. In the record edit dialog, the Edit button probably better be called Save or Update. Issues that can be fixed later: 7. The record type header (e.g. A record) on the left of the table probably can be moved above the table to allow wider table. For comparison, in HBAC/sudo rule details page the tables occupy the entire width of the page. 8. After deleting a value, the Delete button remains enabled although there's no values selected. 9. The Edit links in the tables could be replaced with icons. Another option is to convert the record values into links which will open the dialog. 10. We could use an FQDN validator for some attributes. It can be used in host adder dialog too. 11. We could use a float validator for some attributes. 12. If possible, include an example of each record type in the test data. > Possible modifications: > 1) modify labels to exclude record type's name. Agreed. The current labels could be confusing. For example, the a_ip_address has a label 'A IP Address'. I think it should be just 'IP Address' or 'IPv4 Address'. The labels do not need to include the record type because they will always be displayed within the context of a record. The doc can provide a more verbose explanation, e.g. 'IPv4 address for DNS A record', which we can show as a tooltip. > 2) hide empty tables (as I suggested in ticket description) OK. We probably can move the Add and Delete buttons next to the type header and keep it there even when the table is visible. > 3) attributes which are displayed in table columns can be easily changed > or reordered. I used following principle: "If type has up to 4 > attributes: show them all in table if not, show raw value." This way all > data are displayed and columns are not too narrow. For LOC record we probably can use a formatter to show some of the attributes in a concise way: Latitude Longitude Altitude ------------------------------------------------ 35? 46' 26.687" N 78? 40' 34.499" W 363.06 For other record types that have many attributes, the raw data could be hard to read without knowing the exact order of the attributes and it's not aligned using columns. It might be better to show the most important attributes only. The rest of the attributes can be viewed in the edit dialog. -- Endi S. Dewata From rcritten at redhat.com Tue Jan 24 22:11:25 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Jan 2012 17:11:25 -0500 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4F1D9F73.4020209@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> <4EEA60A6.90109@redhat.com> <4F0169DD.90105@redhat.com> <4F1D9F73.4020209@redhat.com> Message-ID: <4F1F2C8D.2070901@redhat.com> Jan Cholasta wrote: > I have updated and rebased the patches: > > > [PATCH] 59 Add LDAP schema for SSH public keys. > > No changes. > > [PATCH] 60 Add LDAP ACIs for SSH public key schema. > Requires patch 59. > > No changes. > > [PATCH] 61 Add support for SSH public keys to user and host objects. > Requires patch 59 and 66. > > Added new virtual attribute for SSH public key fingerprints to both user > and host. > > The ipasshuser and ipasshhost objectclasses are now automatically added > to user and host objects when necessary. > > The --addattr issue is fixed in patch 66. > > [PATCH] 62 Add API initialization to ipa-client-install. > > Changed API context to "cli_installer". > > [PATCH] 63 Move the nsupdate functionality to separate function in > ipa-client-install. > > No changes. > > [PATCH] 64 Update host SSH public keys on the server during client install. > Requires patch 59, 61, 62, 63, 66 and 67. > > The host SSH public keys are now loaded from a platform specific > location instead of /etc/ssh. > > [PATCH] 65 Configure ssh and sshd during ipa-client-install. > Requires patch 67. > > The configuration files are now looked for in a platform specific > location instead of /etc/ssh > > > Also I have added 2 new patches to the patchset: > > > [PATCH] 66 Base64-decode unicode values in Bytes parameters. > > Fix wrong handling of strings in --setattr/--addattr/--delattr. > > These changes make it possible to use Bytes in > --setattr/--addattr/--delattr without errors. > > It might seem that this patch breaks the API, but it does not. Bytes > parameters are currently used only for certificate attribute of host and > service objects and these attributes are normalized using ipalib.x509 > functions, so both raw binary values and base64-encoded values are > accepted. I have checked that old client works with new server without > problems. > > [PATCH] 67 Add SSH service to platform-specific services. > > Add method for getting configuration directory path of a service, so > that a different SSH configuration directory can be specified on > different platforms. > > > Honza > FYI, the schema change in 59.1 didn't apply cleanly in 2.2. This patch set lacks a way to upgrade an existing install to support SSH keys. Patch 61 you can drop the md5 and sha1 imports and import them from ipalib.compat instead. Patch 65 should there be a way to set --ssh-trust-dns on master installs? 66 is ACK and I think can be pushed separately. 67 not to be too pedantic but it would read better if the sshd service started on its own line. I installed my system with DNS and added VerifyHostKeyDNS to my ssh_config on both my client and server but both sides still said the host key couldn't be found in DNS. Not sure if it is something I did/didn't do or not. I like showing just the fingerprint by default, it is much nicer than the whole key. This fails: $ ipa user-mod --delattr ipasshpubkey= tuser1 [Tue Jan 24 16:41:52 2012] [error] ipa: ERROR: non-public: UnicodeDecodeError: 'utf8' codec can't decode byte 0x91 in position 21: invalid start byte [Tue Jan 24 16:41:52 2012] [error] Traceback (most recent call last): [Tue Jan 24 16:41:52 2012] [error] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 230, in wsgi_execute [Tue Jan 24 16:41:52 2012] [error] result = self.Command[name](*args, **options) [Tue Jan 24 16:41:52 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in __call__ [Tue Jan 24 16:41:52 2012] [error] ret = self.run(*args, **options) [Tue Jan 24 16:41:52 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run [Tue Jan 24 16:41:52 2012] [error] return self.execute(*args, **options) [Tue Jan 24 16:41:52 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1106, in execute [Tue Jan 24 16:41:52 2012] [error] self.process_attr_options(entry_attrs, dn, keys, options) [Tue Jan 24 16:41:52 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 784, in process_attr_options [Tue Jan 24 16:41:52 2012] [error] raise errors.AttrValueNotFound(attr=attr, value=delval) [Tue Jan 24 16:41:52 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/errors.py", line 268, in __init__ [Tue Jan 24 16:41:52 2012] [error] self.strerror = ugettext(self.format) % kw [Tue Jan 24 16:41:52 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/text.py", line 248, in __mod__ [Tue Jan 24 16:41:52 2012] [error] return self.__unicode__() % kw [Tue Jan 24 16:41:52 2012] [error] UnicodeDecodeError: 'utf8' codec can't decode byte 0x91 in position 21: invalid start byte This is very, very close. rob From jcholast at redhat.com Wed Jan 25 08:38:42 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Jan 2012 09:38:42 +0100 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4F1F2C8D.2070901@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> <4EEA60A6.90109@redhat.com> <4F0169DD.90105@redhat.com> <4F1D9F73.4020209@redhat.com> <4F1F2C8D.2070901@redhat.com> Message-ID: <4F1FBF92.6040305@redhat.com> Dne 24.1.2012 23:11, Rob Crittenden napsal(a): > Jan Cholasta wrote: >> I have updated and rebased the patches: >> >> >> [PATCH] 59 Add LDAP schema for SSH public keys. >> >> No changes. >> >> [PATCH] 60 Add LDAP ACIs for SSH public key schema. >> Requires patch 59. >> >> No changes. >> >> [PATCH] 61 Add support for SSH public keys to user and host objects. >> Requires patch 59 and 66. >> >> Added new virtual attribute for SSH public key fingerprints to both user >> and host. >> >> The ipasshuser and ipasshhost objectclasses are now automatically added >> to user and host objects when necessary. >> >> The --addattr issue is fixed in patch 66. >> >> [PATCH] 62 Add API initialization to ipa-client-install. >> >> Changed API context to "cli_installer". >> >> [PATCH] 63 Move the nsupdate functionality to separate function in >> ipa-client-install. >> >> No changes. >> >> [PATCH] 64 Update host SSH public keys on the server during client >> install. >> Requires patch 59, 61, 62, 63, 66 and 67. >> >> The host SSH public keys are now loaded from a platform specific >> location instead of /etc/ssh. >> >> [PATCH] 65 Configure ssh and sshd during ipa-client-install. >> Requires patch 67. >> >> The configuration files are now looked for in a platform specific >> location instead of /etc/ssh >> >> >> Also I have added 2 new patches to the patchset: >> >> >> [PATCH] 66 Base64-decode unicode values in Bytes parameters. >> >> Fix wrong handling of strings in --setattr/--addattr/--delattr. >> >> These changes make it possible to use Bytes in >> --setattr/--addattr/--delattr without errors. >> >> It might seem that this patch breaks the API, but it does not. Bytes >> parameters are currently used only for certificate attribute of host and >> service objects and these attributes are normalized using ipalib.x509 >> functions, so both raw binary values and base64-encoded values are >> accepted. I have checked that old client works with new server without >> problems. >> >> [PATCH] 67 Add SSH service to platform-specific services. >> >> Add method for getting configuration directory path of a service, so >> that a different SSH configuration directory can be specified on >> different platforms. >> >> >> Honza >> > > FYI, the schema change in 59.1 didn't apply cleanly in 2.2. I did all the patches on top of master. Should I rebase them to ipa-2-2? > > This patch set lacks a way to upgrade an existing install to support SSH > keys. I will create a patch with the update files. > > Patch 61 you can drop the md5 and sha1 imports and import them from > ipalib.compat instead. Is this OK in ipapython? > > Patch 65 should there be a way to set --ssh-trust-dns on master installs? Possibly. Should I add the ssh-related command-line options of ipa-client-install to ipa-server-install as well? > > 66 is ACK and I think can be pushed separately. > > 67 not to be too pedantic but it would read better if the sshd service > started on its own line. I'm not sure I follow. > > I installed my system with DNS and added VerifyHostKeyDNS to my > ssh_config on both my client and server but both sides still said the > host key couldn't be found in DNS. Not sure if it is something I > did/didn't do or not. Make sure that both use IPA DNS server and that the SSHFP records exist (they should be created automatically in ipa-client-install, or ipa host-mod with --updatedns). > > I like showing just the fingerprint by default, it is much nicer than > the whole key. I think so :-) > > This fails: > > $ ipa user-mod --delattr ipasshpubkey= tuser1 > > [Tue Jan 24 16:41:52 2012] [error] ipa: ERROR: non-public: > UnicodeDecodeError: 'utf8' codec can't decode byte 0x91 in position 21: > invalid start byte > [Tue Jan 24 16:41:52 2012] [error] Traceback (most recent call last): > [Tue Jan 24 16:41:52 2012] [error] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 230, in > wsgi_execute > [Tue Jan 24 16:41:52 2012] [error] result = self.Command[name](*args, > **options) > [Tue Jan 24 16:41:52 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in > __call__ > [Tue Jan 24 16:41:52 2012] [error] ret = self.run(*args, **options) > [Tue Jan 24 16:41:52 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run > [Tue Jan 24 16:41:52 2012] [error] return self.execute(*args, **options) > [Tue Jan 24 16:41:52 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line > 1106, in execute > [Tue Jan 24 16:41:52 2012] [error] > self.process_attr_options(entry_attrs, dn, keys, options) > [Tue Jan 24 16:41:52 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 784, > in process_attr_options > [Tue Jan 24 16:41:52 2012] [error] raise > errors.AttrValueNotFound(attr=attr, value=delval) > [Tue Jan 24 16:41:52 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/errors.py", line 268, in __init__ > [Tue Jan 24 16:41:52 2012] [error] self.strerror = ugettext(self.format) > % kw > [Tue Jan 24 16:41:52 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/text.py", line 248, in __mod__ > [Tue Jan 24 16:41:52 2012] [error] return self.__unicode__() % kw > [Tue Jan 24 16:41:52 2012] [error] UnicodeDecodeError: 'utf8' codec > can't decode byte 0x91 in position 21: invalid start byte Good catch, will fix (as part of patch 66, so self-NACK on the current version). > > This is very, very close. > > rob Honza -- Jan Cholasta From mkosek at redhat.com Wed Jan 25 13:54:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Jan 2012 14:54:31 +0100 Subject: [Freeipa-devel] [PATCH] 202 Add reverse DNS record when forward is created Message-ID: <1327499671.19882.4.camel@balmora.brq.redhat.com> Adding reverse DNS record may be a time consuming task, especially for IPv6 addresses. Having a way to automatically create a reverse record when a forward record is created could speed up the process. host-add command already has this possibility. This patch takes advantage of the new per-type API and adds new options for A/AAAA record types: --a-create-reverse and --aaaa-create-reverse. These commands can be used to automatically create reverse records for new A/AAAA addresses (both forward and reverse zones need to be managed by FreeIPA server): ipa dnsrecord-add example.com foo --a-rec=10.0.0.1 --a-create-reverse This command would add a new A record to record foo in zone example.com and a PTR record to appropriate reverse zone for IP address 10.0.0.1 (for example PTR record 1 in zone 0.0.10.in-addr.arpa. pointing to foo.example.com.). Few modification were done to new DNS API to support this feature: - Refactor --ip-address option handling from host-add and place it to dns.py to be used by both modules - Add support for "extra" per-type options - Hide DNS record part options in dnsrecord_find command as they have no effect for this command https://fedorahosted.org/freeipa/ticket/2009 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-202-add-reverse-dns-record-when-forward-is-created.patch Type: text/x-patch Size: 54177 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 25 14:12:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 09:12:38 -0500 Subject: [Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance In-Reply-To: <4F1DE733.9080502@redhat.com> References: <4EE90D98.6030900@redhat.com> <4F0F6068.9000602@redhat.com> <4F0F6998.8020507@redhat.com> <4F0FAA9E.1080601@redhat.com> <4F105CD5.7090409@redhat.com> <4F1DE733.9080502@redhat.com> Message-ID: <4F200DD6.8070708@redhat.com> John Dennis wrote: > This patch supersedes the previous patch, it corrects two issue Rob > raised in a later patch review > > The fixed issues are: > > * spec file did not install ipa_memcached SysV initscript on SvsV systems. > > * Typo in the name of the pid file variable in the ipa_memcached initscript > NACK, two small things. ipa-server-install man page needs to be updated with new option. ipa_memcached is not chkconfig'd on/off when it is installed/uninstalled. Also, can you update the commit message, it isn't as descriptive as it usually is :-) rob From rcritten at redhat.com Wed Jan 25 14:16:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 09:16:22 -0500 Subject: [Freeipa-devel] [PATCH 61] Cache authentication in session In-Reply-To: <4F1DEA77.8040408@redhat.com> References: <4F0F90F2.40403@redhat.com> <4F15EA10.7010206@redhat.com> <4F1DEA1E.2090807@redhat.com> <4F1DEA77.8040408@redhat.com> Message-ID: <4F200EB6.9070209@redhat.com> John Dennis wrote: > On 01/23/2012 06:15 PM, John Dennis wrote: >> Rebased patch attached (includes contents of previous patch 60). >> >> The issues with ipa_memcached belonged to patch 59, that patch was >> rebased and resubmitted. >> >> I cannot reproduce the looping problem you saw. The only thing I can >> think of is that you were running with SELinux enabled and currently >> ipa_memcached requires SELinux to be disabled otherwise the whole >> caching mechanism fails. > > O.K., let's try this again with the patch actually attached :-) NACK. It doesn't work if ipa_memcached is not configured (-M install option). I tested this last night then picked up testing again this morning and was greeted with the attached image. I'm not sure if this is a browser issue, the fact that my browser was being redirected from a VM to the display on my desktop or the current cosmic rays. We also need a way to do a logout. The user can do a kdestroy and still have an active session. If this isn't covered in the any current tickets please open a new one. As far as I can tell you provide a facility for invalidating a cache entry, I'm just not sure if that is enough for the UI guys to hook in to. I think you were right about SELinux. When I put it into permissive mode then the caching worked. The UI is much more responsive now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: corrupt.png Type: image/png Size: 149924 bytes Desc: not available URL: From simo at redhat.com Wed Jan 25 14:37:43 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 25 Jan 2012 09:37:43 -0500 Subject: [Freeipa-devel] [PATCH 61] Cache authentication in session In-Reply-To: <4F200EB6.9070209@redhat.com> References: <4F0F90F2.40403@redhat.com> <4F15EA10.7010206@redhat.com> <4F1DEA1E.2090807@redhat.com> <4F1DEA77.8040408@redhat.com> <4F200EB6.9070209@redhat.com> Message-ID: <1327502263.13963.173.camel@willson.li.ssimo.org> On Wed, 2012-01-25 at 09:16 -0500, Rob Crittenden wrote: > John Dennis wrote: > > On 01/23/2012 06:15 PM, John Dennis wrote: > >> Rebased patch attached (includes contents of previous patch 60). > >> > >> The issues with ipa_memcached belonged to patch 59, that patch was > >> rebased and resubmitted. > >> > >> I cannot reproduce the looping problem you saw. The only thing I can > >> think of is that you were running with SELinux enabled and currently > >> ipa_memcached requires SELinux to be disabled otherwise the whole > >> caching mechanism fails. > > > > O.K., let's try this again with the patch actually attached :-) > > NACK. It doesn't work if ipa_memcached is not configured (-M install > option). > > I tested this last night then picked up testing again this morning and > was greeted with the attached image. I'm not sure if this is a browser > issue, the fact that my browser was being redirected from a VM to the > display on my desktop or the current cosmic rays. > > We also need a way to do a logout. The user can do a kdestroy and still > have an active session. If this isn't covered in the any current tickets > please open a new one. As far as I can tell you provide a facility for > invalidating a cache entry, I'm just not sure if that is enough for the > UI guys to hook in to. > > I think you were right about SELinux. When I put it into permissive mode > then the caching worked. The UI is much more responsive now. We definitely need a ticket to add a "Log Out" button. It is nice when you can log out even if you haven't destroyed your credentials. May be used by a normal user to go to the form based login to login as admin w/o having to kinit admin first in the future. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jan 25 16:19:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 11:19:21 -0500 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4F1FBF92.6040305@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> <4EEA60A6.90109@redhat.com> <4F0169DD.90105@redhat.com> <4F1D9F73.4020209@redhat.com> <4F1F2C8D.2070901@redhat.com> <4F1FBF92.6040305@redhat.com> Message-ID: <4F202B89.2090109@redhat.com> Jan Cholasta wrote: > Dne 24.1.2012 23:11, Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> I have updated and rebased the patches: >>> >>> >>> [PATCH] 59 Add LDAP schema for SSH public keys. >>> >>> No changes. >>> >>> [PATCH] 60 Add LDAP ACIs for SSH public key schema. >>> Requires patch 59. >>> >>> No changes. >>> >>> [PATCH] 61 Add support for SSH public keys to user and host objects. >>> Requires patch 59 and 66. >>> >>> Added new virtual attribute for SSH public key fingerprints to both user >>> and host. >>> >>> The ipasshuser and ipasshhost objectclasses are now automatically added >>> to user and host objects when necessary. >>> >>> The --addattr issue is fixed in patch 66. >>> >>> [PATCH] 62 Add API initialization to ipa-client-install. >>> >>> Changed API context to "cli_installer". >>> >>> [PATCH] 63 Move the nsupdate functionality to separate function in >>> ipa-client-install. >>> >>> No changes. >>> >>> [PATCH] 64 Update host SSH public keys on the server during client >>> install. >>> Requires patch 59, 61, 62, 63, 66 and 67. >>> >>> The host SSH public keys are now loaded from a platform specific >>> location instead of /etc/ssh. >>> >>> [PATCH] 65 Configure ssh and sshd during ipa-client-install. >>> Requires patch 67. >>> >>> The configuration files are now looked for in a platform specific >>> location instead of /etc/ssh >>> >>> >>> Also I have added 2 new patches to the patchset: >>> >>> >>> [PATCH] 66 Base64-decode unicode values in Bytes parameters. >>> >>> Fix wrong handling of strings in --setattr/--addattr/--delattr. >>> >>> These changes make it possible to use Bytes in >>> --setattr/--addattr/--delattr without errors. >>> >>> It might seem that this patch breaks the API, but it does not. Bytes >>> parameters are currently used only for certificate attribute of host and >>> service objects and these attributes are normalized using ipalib.x509 >>> functions, so both raw binary values and base64-encoded values are >>> accepted. I have checked that old client works with new server without >>> problems. >>> >>> [PATCH] 67 Add SSH service to platform-specific services. >>> >>> Add method for getting configuration directory path of a service, so >>> that a different SSH configuration directory can be specified on >>> different platforms. >>> >>> >>> Honza >>> >> >> FYI, the schema change in 59.1 didn't apply cleanly in 2.2. > > I did all the patches on top of master. Should I rebase them to ipa-2-2? No, it's fine, was more a heads-up for when we commit the changes than anything else. It was an easy merge to do. >> >> This patch set lacks a way to upgrade an existing install to support SSH >> keys. > > I will create a patch with the update files. > >> >> Patch 61 you can drop the md5 and sha1 imports and import them from >> ipalib.compat instead. > > Is this OK in ipapython? It should be, ipa-python and ipalib should be packaged together so I think it is safe. >> >> Patch 65 should there be a way to set --ssh-trust-dns on master installs? > > Possibly. Should I add the ssh-related command-line options of > ipa-client-install to ipa-server-install as well? I guess so. It would be an easy option to miss at install time but I think its worthwhile. The replica installer would need this as well (and man pages). >> >> 66 is ACK and I think can be pushed separately. >> >> 67 not to be too pedantic but it would read better if the sshd service >> started on its own line. > > I'm not sure I follow. wellknownservices wraps the screen, it would easier to read. Note that it currently wraps the screen with the messagebus service too on the first line, it would be nice to fix that too :-) >> >> I installed my system with DNS and added VerifyHostKeyDNS to my >> ssh_config on both my client and server but both sides still said the >> host key couldn't be found in DNS. Not sure if it is something I >> did/didn't do or not. > > Make sure that both use IPA DNS server and that the SSHFP records exist > (they should be created automatically in ipa-client-install, or ipa > host-mod with --updatedns). Yeah, and AFAIK that was all there. It worked when I tested this the last time, I'll chalk this up as my mistake. >> >> I like showing just the fingerprint by default, it is much nicer than >> the whole key. > > I think so :-) > >> >> This fails: >> >> $ ipa user-mod --delattr ipasshpubkey= tuser1 >> >> [Tue Jan 24 16:41:52 2012] [error] ipa: ERROR: non-public: >> UnicodeDecodeError: 'utf8' codec can't decode byte 0x91 in position 21: >> invalid start byte >> [Tue Jan 24 16:41:52 2012] [error] Traceback (most recent call last): >> [Tue Jan 24 16:41:52 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 230, in >> wsgi_execute >> [Tue Jan 24 16:41:52 2012] [error] result = self.Command[name](*args, >> **options) >> [Tue Jan 24 16:41:52 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in >> __call__ >> [Tue Jan 24 16:41:52 2012] [error] ret = self.run(*args, **options) >> [Tue Jan 24 16:41:52 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run >> [Tue Jan 24 16:41:52 2012] [error] return self.execute(*args, **options) >> [Tue Jan 24 16:41:52 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line >> 1106, in execute >> [Tue Jan 24 16:41:52 2012] [error] >> self.process_attr_options(entry_attrs, dn, keys, options) >> [Tue Jan 24 16:41:52 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 784, >> in process_attr_options >> [Tue Jan 24 16:41:52 2012] [error] raise >> errors.AttrValueNotFound(attr=attr, value=delval) >> [Tue Jan 24 16:41:52 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/errors.py", line 268, in >> __init__ >> [Tue Jan 24 16:41:52 2012] [error] self.strerror = ugettext(self.format) >> % kw >> [Tue Jan 24 16:41:52 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/text.py", line 248, in __mod__ >> [Tue Jan 24 16:41:52 2012] [error] return self.__unicode__() % kw >> [Tue Jan 24 16:41:52 2012] [error] UnicodeDecodeError: 'utf8' codec >> can't decode byte 0x91 in position 21: invalid start byte > > Good catch, will fix (as part of patch 66, so self-NACK on the current > version). Ok rob From ohamada at redhat.com Wed Jan 25 16:50:55 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Wed, 25 Jan 2012 17:50:55 +0100 Subject: [Freeipa-devel] [PATCH] 10 --no-reverse option in ipa-replica-install is not honoured Message-ID: <4F2032EF.9010409@redhat.com> https://fedorahosted.org/freeipa/ticket/2161 The option '--no-reverse' was not honoured in replica-install because of wrongly placed condition checking. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-10-Honor-no-reverse-option-on-replica.patch Type: text/x-patch Size: 1805 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 25 19:13:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 14:13:43 -0500 Subject: [Freeipa-devel] [PATCH] 932 Add support for storing MAC address in host entries. In-Reply-To: <1327332276.11792.17.camel@balmora.brq.redhat.com> References: <4F19CB63.3010903@redhat.com> <4F1D3304.6040809@redhat.com> <1327332276.11792.17.camel@balmora.brq.redhat.com> Message-ID: <4F205467.4030601@redhat.com> Martin Kosek wrote: > On Mon, 2012-01-23 at 11:14 +0100, Jan Cholasta wrote: >> Dne 20.1.2012 21:15, Rob Crittenden napsal(a): >>> macaddress is a multi-valued attribute and we allow multiple entries. >>> This is from the objectclass ieee802device. This is added manually when >>> doing a mod or add and not as a default to support existing host entries >>> that do not have this objectclass. If this were added to the defaults >>> then existing hosts missing this objectclass would not be found by >>> host-find. >>> >>> It is possible to get ethers data out of nss by configuring >>> nsswitch.conf to use ldap for ethers and running getent ethers >>> >>> I tested nslcd and it only returned one macaddress value. I don't know >>> if this is a deficiency in nslcd or expected behavior. >>> >>> https://fedorahosted.org/freeipa/ticket/1132 >>> >>> rob >>> >> >> @@ -442,6 +448,7 @@ class host_add(LDAPCreate): >> x509.verify_cert_subject(ldap, keys[-1], cert) >> entry_attrs['usercertificate'] = cert >> entry_attrs['managedby'] = dn >> + entry_attrs['objectclass'].append('ieee802device') >> return dn >> >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> >> Why do you add the objectclass here instead of adding it to host >> plugin's object_class attribute? >> >> Honza >> > > As Rob pointed out, old host records without ieee802device objectclass > wouldn't then be matched in host-find command. > > I checked the patch and it looks ok. I have just 3 minor issues: > > 1) As you didn't specify the param with csv=True its values cannot be > entered in a comma-separated list. I think we can enable this feature > for MAC Address > > 2) I would fix capitalization of label of macaddress. A second word in a > label is lowercase in other params. > > 3) I think we may want to implement a normalizer for MAC address which > would make it either lowercase or uppercase so that we provide results > with consistent case. Good ideas all. Updated patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-932-1-macaddress.patch Type: text/x-diff Size: 12577 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 25 19:18:05 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 14:18:05 -0500 Subject: [Freeipa-devel] [PATCH] 927 fix deleting hbac rules when selinux user maps are involved In-Reply-To: <1327422142.8230.23.camel@balmora.brq.redhat.com> References: <4F15FD43.5000402@redhat.com> <1327336609.11792.23.camel@balmora.brq.redhat.com> <4F1D96FA.60708@redhat.com> <1327391907.8230.3.camel@balmora.brq.redhat.com> <4F1EC971.5070702@redhat.com> <1327422142.8230.23.camel@balmora.brq.redhat.com> Message-ID: <4F20556D.9020307@redhat.com> Martin Kosek wrote: > On Tue, 2012-01-24 at 10:08 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Mon, 2012-01-23 at 12:20 -0500, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On Tue, 2012-01-17 at 17:59 -0500, Rob Crittenden wrote: >>>>>> When deleting an HBAC rule we need to ensure that an SELinux user map >>>>>> isn't pointing at it. The search for this didn't work well at all. >>>>>> >>>>>> This patch corrects the search and makes it more specific. >>>>>> >>>>>> I also tested that it works with the --continue flag of hbacrule-del. >>>>>> >>>>>> The ticket has instructions on testing. >>>>>> >>>>>> rob >>>>> >>>>> Works fine. There is just one part that is IMO too complicated: >>>>> >>>>> + hbacrule = options['seealso'] >>>>> + kw = dict(cn=hbacrule, all=True) >>>>> _entries = api.Command.hbacrule_find(None, **kw)['result'] >>>>> del options['seealso'] >>>>> - if _entries: >>>>> - options['seealso'] = _entries[0]['dn'] >>>>> + found = False >>>>> + # look for an exact match. The search may return partial >>>>> + # matches. >>>>> + for entry in _entries: >>>>> + if entry['cn'][0] == hbacrule: >>>>> + found = True >>>>> + options['seealso'] = entry['dn'] >>>>> + if not found: >>>>> + return dict(count=0, result=[], truncated=False) >>>>> >>>>> I think hbacrule_find(None, cn=HBACRULE) should not return partial >>>>> matches, but just the exact match (tried with hbacrule-find >>>>> --name=HBACRULE). Then the loop over entries wouldn't be needed. >>>>> >>>>> Couldn't we simply call hbacrule_show since we want just one HBAC rule >>>>> with a known primary key? >>>>> >>>>> Martin >>>>> >>>> >>>> hbacrule_show would need to be modified to take a dn, that would be a >>>> way to fix this. >>>> >>>> rob >>> >>> Not sure I see the problem with hbacrule_show. I tested this piece of >>> code and it worked fine: >>> >>> selinuxusermap_find: >>> ... >>> if 'seealso' in options: >>> hbacrule = options['seealso'] >>> >>> try: >>> hbac = api.Command['hbacrule_show'](hbacrule, >>> all=True)['result'] >>> dn = hbac['dn'] >>> except errors.NotFound: >>> return dict(count=0, result=[], truncated=False) >>> options['seealso'] = dn >>> ... >>> >>> Martin >>> >> >> Ok, I misunderstood your point. Yes, this is vastly better. Updated >> patch attached. >> >> rob > > ACK if you change > > if 'seealso' in options: > > to: > > if options.get('seealso'): > > so that the following case is fixed: > > # ipa selinuxusermap-find --hbacrule= > ipa: ERROR: 'cn' is required > > Martin > Fixed, pushed to master and ipa-2-2 rob From rcritten at redhat.com Wed Jan 25 20:18:04 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 15:18:04 -0500 Subject: [Freeipa-devel] [PATCH] 9 Don't set nsds5replicaupdateschedule in replication agreements In-Reply-To: <4F1D9CD4.8080106@redhat.com> References: <4F1D9CD4.8080106@redhat.com> Message-ID: <4F20637C.3060406@redhat.com> Ondrej Hamada wrote: > https://fedorahosted.org/freeipa/ticket/1482 > > The nsDS5ReplicaUpdateSchedule parameter is omitted what results in > replication being run all the time. The parameter is still used for > forcing replica update but after that action it is always deleted. ACK, pushed to master and ipa-2-2 rob From rcritten at redhat.com Wed Jan 25 21:45:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Jan 2012 16:45:56 -0500 Subject: [Freeipa-devel] [PATCH] 195-199 New DNS features In-Reply-To: <1327050506.2204.23.camel@priserak> References: <1327050506.2204.23.camel@priserak> Message-ID: <4F207814.3050600@redhat.com> Martin Kosek wrote: > This set of patches implements support and API for features introduced > in a new bind-dyndb-ldap (bind-dyndb-ldap-1.1.0-0.6.a1): > - global bind-dyndb-ldap settings in LDAP (cn=dns,$SUFFIX) > - conditional per-zone forwarding > - per-zone configuration of automatic PTR updates > - zone transfer > - AllowQuery and AllowTransfer ACIs > - new bind-dyndb-ldap now also skips invalid records in a zone instead > of refusing to load an entire zone > > More detailed description and examples are in these separate patches. In > order to test it, a new bind-dyndb-ldap version is needed. It is not in > updates-testing repo yet as it waits for a new release of bind which > should occur in few next days. But it can be downloaded from koji: > > F15: http://koji.fedoraproject.org/koji/buildinfo?buildID=294138 > F16: http://koji.fedoraproject.org/koji/buildinfo?buildID=294137 > > Have fun! > Martin In patch 195 there is a white-space fix to the idnsRecord. Was this intentional? Also a typo in the commit message, AllowTransger. In patch 197 there is this suspicious code in _normalize_ipnetmask + ipnetmask = ipnetmask The comment and copyright date in dns.py::update_dnszone_acls() needs to be updated Patch 98 I think you want to drop the worth "with" in this? + Forward all request for sub-zone of example.com to another nameserver with + using a "first" policy (it will send the queries to the selected forwarder yes, And now for some things I saw when testing. I upgraded an existing instance installed with DNS. ipa dnsconfig-show returned nothing. I disabled persistent search then set it to '' and now I always see Zone refresh interval: 0 Not sure if I should have seen that initially or not. I tried testing the query policy but was unable to get it working: # ipa dnszone-mod example.com --allow-query="\!10.0.0.1,any" # service named restart 'dig -t soa example.com' always worked. My test hosts are behind a NAT but I tried both the real and the NAT IP address and in both cases it worked. So I set up transfer rules instead and this time was very picky about what IP address to accept and used on the NAT address. Using that it worked as expected. So I went back and worked on query again. It seems like the ! addresses aren't working as expected, that or it is an ordering problem perhaps (e.g. I wonder if I'm seeing the problem in your comment #16 in ticket 1211). I wonder if the summary should reflect that named needs to be restarted. rob From edewata at redhat.com Thu Jan 26 06:07:31 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 26 Jan 2012 00:07:31 -0600 Subject: [Freeipa-devel] [PATCH] 178+179 Add missing managing hosts filtering options In-Reply-To: <1323785580.4265.26.camel@balmora.brq.redhat.com> References: <1323362703.16789.17.camel@balmora.brq.redhat.com> <4EE27BEC.6090607@redhat.com> <4EE285FF.7080202@redhat.com> <1323785580.4265.26.camel@balmora.brq.redhat.com> Message-ID: <4F20EDA3.7040909@redhat.com> On 12/13/2011 8:13 AM, Martin Kosek wrote: >>>> Host object has a virtual attribute "managing" containing all hosts >>>> it manages (governed by managedBy attribute). This patch also adds >>>> standard membership filtering options: >>>> --man-hosts=HOSTS: Only hosts managing _all_ HOSTS are returned >>>> --not-man-hosts=HOSTS: Only hosts which do not manage _any_ host >>>> in HOSTS are returned >>>> >>>> https://fedorahosted.org/freeipa/ticket/1675 >>> >>> ACK, it works for me. I'll update the UI to use the new option. >> >> I take that back. It's NACK. >> Patch #178 causes the dnszone-find --forward-only to return the reverse >> zone. > > Good catch, thanks. Fixed. Sorry for the delay. I applied 178-2 and rebased 179-2 into 179-3 (patch attached). It works except for one issue, when the host has no managedby, calling host-find with either of these options will generate an internal error. # ipa host-add test.example.com --force ----------------------------- Added host "test.example.com" ----------------------------- Host name: test.example.com Principal name: host/test.example.com at EXAMPLE.COM Password: False Keytab: False Managed by: test.example.com # ipa host-remove-managedby test.example.com --hosts=test.example.com Host name: test.example.com Principal name: host/test.example.com at EXAMPLE.COM --------------------------- Number of members removed 1 --------------------------- # ipa host-find --man-hosts=test.example.com ipa: ERROR: an internal error has occurred The above command should have returned no hosts. # ipa host-find --not-man-hosts=test.example.com ipa: ERROR: an internal error has occurred The above command should have returned all hosts. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-179-3-add-missing-managing-hosts-filtering-options.patch Type: text/x-patch Size: 10696 bytes Desc: not available URL: From jcholast at redhat.com Thu Jan 26 08:24:52 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jan 2012 09:24:52 +0100 Subject: [Freeipa-devel] [PATCH] 10 --no-reverse option in ipa-replica-install is not honoured In-Reply-To: <4F2032EF.9010409@redhat.com> References: <4F2032EF.9010409@redhat.com> Message-ID: <4F210DD4.4020500@redhat.com> Dne 25.1.2012 17:50, Ondrej Hamada napsal(a): > https://fedorahosted.org/freeipa/ticket/2161 > > The option '--no-reverse' was not honoured in replica-install because of > wrongly placed condition checking. > NACK The --no-reverse options means "do not create new reverse zone if there is no existing suitable reverse zone". Your patch changes the semantics of the option to "do not use any reverse zone". One problem I see is that the name of the option is misleading. It should probably be changed to "--no-new-reverse". Anyway, the ticket should IMO be closed as invalid. It is a case of people not reading documentation and then being surprised why things don't work the way they assumed. Honza -- Jan Cholasta From mkosek at redhat.com Thu Jan 26 12:48:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jan 2012 13:48:47 +0100 Subject: [Freeipa-devel] [PATCH] 178+179 Add missing managing hosts filtering options In-Reply-To: <4F20EDA3.7040909@redhat.com> References: <1323362703.16789.17.camel@balmora.brq.redhat.com> <4EE27BEC.6090607@redhat.com> <4EE285FF.7080202@redhat.com> <1323785580.4265.26.camel@balmora.brq.redhat.com> <4F20EDA3.7040909@redhat.com> Message-ID: <1327582127.7914.1.camel@balmora.brq.redhat.com> On Thu, 2012-01-26 at 00:07 -0600, Endi Sukma Dewata wrote: > On 12/13/2011 8:13 AM, Martin Kosek wrote: > >>>> Host object has a virtual attribute "managing" containing all hosts > >>>> it manages (governed by managedBy attribute). This patch also adds > >>>> standard membership filtering options: > >>>> --man-hosts=HOSTS: Only hosts managing _all_ HOSTS are returned > >>>> --not-man-hosts=HOSTS: Only hosts which do not manage _any_ host > >>>> in HOSTS are returned > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/1675 > >>> > >>> ACK, it works for me. I'll update the UI to use the new option. > >> > >> I take that back. It's NACK. > >> Patch #178 causes the dnszone-find --forward-only to return the reverse > >> zone. > > > > Good catch, thanks. Fixed. > > Sorry for the delay. I applied 178-2 and rebased 179-2 into 179-3 (patch > attached). It works except for one issue, when the host has no > managedby, calling host-find with either of these options will generate > an internal error. > > # ipa host-add test.example.com --force > ----------------------------- > Added host "test.example.com" > ----------------------------- > Host name: test.example.com > Principal name: host/test.example.com at EXAMPLE.COM > Password: False > Keytab: False > Managed by: test.example.com > > # ipa host-remove-managedby test.example.com --hosts=test.example.com > Host name: test.example.com > Principal name: host/test.example.com at EXAMPLE.COM > --------------------------- > Number of members removed 1 > --------------------------- > > # ipa host-find --man-hosts=test.example.com > ipa: ERROR: an internal error has occurred > > The above command should have returned no hosts. > > # ipa host-find --not-man-hosts=test.example.com > ipa: ERROR: an internal error has occurred > > The above command should have returned all hosts. > Thanks for the review Endi and a good catch. I rebased the patches and fixed this issue. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-178-2-fix-ldap2-combine_filters.patch Type: text/x-patch Size: 3623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-179-3-add-missing-managing-hosts-filtering-options.patch Type: text/x-patch Size: 10982 bytes Desc: not available URL: From mkosek at redhat.com Thu Jan 26 13:16:40 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jan 2012 14:16:40 +0100 Subject: [Freeipa-devel] [PATCH] 932 Add support for storing MAC address in host entries. In-Reply-To: <4F205467.4030601@redhat.com> References: <4F19CB63.3010903@redhat.com> <4F1D3304.6040809@redhat.com> <1327332276.11792.17.camel@balmora.brq.redhat.com> <4F205467.4030601@redhat.com> Message-ID: <1327583800.7914.2.camel@balmora.brq.redhat.com> On Wed, 2012-01-25 at 14:13 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2012-01-23 at 11:14 +0100, Jan Cholasta wrote: > >> Dne 20.1.2012 21:15, Rob Crittenden napsal(a): > >>> macaddress is a multi-valued attribute and we allow multiple entries. > >>> This is from the objectclass ieee802device. This is added manually when > >>> doing a mod or add and not as a default to support existing host entries > >>> that do not have this objectclass. If this were added to the defaults > >>> then existing hosts missing this objectclass would not be found by > >>> host-find. > >>> > >>> It is possible to get ethers data out of nss by configuring > >>> nsswitch.conf to use ldap for ethers and running getent ethers > >>> > >>> I tested nslcd and it only returned one macaddress value. I don't know > >>> if this is a deficiency in nslcd or expected behavior. > >>> > >>> https://fedorahosted.org/freeipa/ticket/1132 > >>> > >>> rob > >>> > >> > >> @@ -442,6 +448,7 @@ class host_add(LDAPCreate): > >> x509.verify_cert_subject(ldap, keys[-1], cert) > >> entry_attrs['usercertificate'] = cert > >> entry_attrs['managedby'] = dn > >> + entry_attrs['objectclass'].append('ieee802device') > >> return dn > >> > >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > >> > >> Why do you add the objectclass here instead of adding it to host > >> plugin's object_class attribute? > >> > >> Honza > >> > > > > As Rob pointed out, old host records without ieee802device objectclass > > wouldn't then be matched in host-find command. > > > > I checked the patch and it looks ok. I have just 3 minor issues: > > > > 1) As you didn't specify the param with csv=True its values cannot be > > entered in a comma-separated list. I think we can enable this feature > > for MAC Address > > > > 2) I would fix capitalization of label of macaddress. A second word in a > > label is lowercase in other params. > > > > 3) I think we may want to implement a normalizer for MAC address which > > would make it either lowercase or uppercase so that we provide results > > with consistent case. > > Good ideas all. Updated patch attached. > > rob ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Thu Jan 26 15:58:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jan 2012 16:58:19 +0100 Subject: [Freeipa-devel] [PATCH] 195-199 New DNS features In-Reply-To: <4F207814.3050600@redhat.com> References: <1327050506.2204.23.camel@priserak> <4F207814.3050600@redhat.com> Message-ID: <1327593499.7914.23.camel@balmora.brq.redhat.com> On Wed, 2012-01-25 at 16:45 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > This set of patches implements support and API for features introduced > > in a new bind-dyndb-ldap (bind-dyndb-ldap-1.1.0-0.6.a1): > > - global bind-dyndb-ldap settings in LDAP (cn=dns,$SUFFIX) > > - conditional per-zone forwarding > > - per-zone configuration of automatic PTR updates > > - zone transfer > > - AllowQuery and AllowTransfer ACIs > > - new bind-dyndb-ldap now also skips invalid records in a zone instead > > of refusing to load an entire zone > > > > More detailed description and examples are in these separate patches. In > > order to test it, a new bind-dyndb-ldap version is needed. It is not in > > updates-testing repo yet as it waits for a new release of bind which > > should occur in few next days. But it can be downloaded from koji: > > > > F15: http://koji.fedoraproject.org/koji/buildinfo?buildID=294138 > > F16: http://koji.fedoraproject.org/koji/buildinfo?buildID=294137 > > > > Have fun! > > Martin > > Rob, thanks for review, I know that all this may really time-consuming. I updated all tickets where the testing may be tricky and provided a howto for testing. I also did some more tests of bind-dyndb-ldap and found few bugs: Dynamic update for zone without idnsAllowSyncPTR does not work: https://bugzilla.redhat.com/show_bug.cgi?id=784815 Conditional forwarding does not work for sub-zones: https://bugzilla.redhat.com/show_bug.cgi?id=784820 > In patch 195 there is a white-space fix to the idnsRecord. Was this > intentional? Yes. > Also a typo in the commit message, AllowTransger. Fixed. You have very keen eyes :-) > > In patch 197 there is this suspicious code in _normalize_ipnetmask > > + ipnetmask = ipnetmask Fixed. > > The comment and copyright date in dns.py::update_dnszone_acls() needs to > be updated Fixed. I explained why we need to set idnsAllowTransfer in all configured zones in the fixed comment. > > Patch 98 I think you want to drop the worth "with" in this? > > + Forward all request for sub-zone of example.com to another nameserver with > + using a "first" policy (it will send the queries to the selected forwarder > yes, > Yup. Fixed. > And now for some things I saw when testing. > > I upgraded an existing instance installed with DNS. > > ipa dnsconfig-show returned nothing. I disabled persistent search then > set it to '' and now I always see > > Zone refresh interval: 0 > > Not sure if I should have seen that initially or not. I used to automatically disable zone refresh when persistent search was enabled, but I see it may confuse users. I fixed this part to rather check the current configuration in LDAP, compare it to passed values and raise ValidationError only when an invalid combination could happen. > > I tried testing the query policy but was unable to get it working: > > # ipa dnszone-mod example.com --allow-query="\!10.0.0.1,any" > # service named restart > > 'dig -t soa example.com' always worked. > > My test hosts are behind a NAT but I tried both the real and the NAT IP > address and in both cases it worked. > > So I set up transfer rules instead and this time was very picky about > what IP address to accept and used on the NAT address. Using that it > worked as expected. > > So I went back and worked on query again. It seems like the ! addresses > aren't working as expected, that or it is an ordering problem perhaps > (e.g. I wonder if I'm seeing the problem in your comment #16 in ticket > 1211). I see you hit the same error as I hit yesterday. The main problem here is that idnsAllowQuery and idnsAllowTransfer attribute holding the query and transfer ACLs are multi-valued attributes. However, the evaluation is very order-sensitive which does not play well with LDAP nature. I discussed this with Adam Tkac and the plan is to change these ACL attributes to single-valued and divide the ACLs with semicolon (the same approach is already used for idnsupdatepolicy) to ensure the order. This is a relevant upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/50 > > I wonder if the summary should reflect that named needs to be restarted. > > rob Hmm, interesting idea. I will have to discuss the situations and changes of configuration in LDAP when named needs to be reloaded/restarted. A notice in the Summary may help prevent confusion. I will keep fixed patches in my local tree until the bind-dyndb-ldap with fixed ACLs is released as it will require some more changes in this patch set. Martin From edewata at redhat.com Thu Jan 26 16:26:10 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 26 Jan 2012 10:26:10 -0600 Subject: [Freeipa-devel] [PATCH] 178+179 Add missing managing hosts filtering options In-Reply-To: <1327582127.7914.1.camel@balmora.brq.redhat.com> References: <1323362703.16789.17.camel@balmora.brq.redhat.com> <4EE27BEC.6090607@redhat.com> <4EE285FF.7080202@redhat.com> <1323785580.4265.26.camel@balmora.brq.redhat.com> <4F20EDA3.7040909@redhat.com> <1327582127.7914.1.camel@balmora.brq.redhat.com> Message-ID: <4F217EA2.3070500@redhat.com> On 1/26/2012 6:48 AM, Martin Kosek wrote: >> Sorry for the delay. I applied 178-2 and rebased 179-2 into 179-3 (patch >> attached). It works except for one issue, when the host has no >> managedby, calling host-find with either of these options will generate >> an internal error. > > Thanks for the review Endi and a good catch. I rebased the patches and > fixed this issue. I had to rebase 179 again (patch attached) due to a recent API.txt and VERSION change. ACK and pushed to master and ipa-2-2. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-179-5-add-missing-managing-hosts-filtering-options.patch Type: text/x-patch Size: 10981 bytes Desc: not available URL: From edewata at redhat.com Thu Jan 26 16:33:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 26 Jan 2012 10:33:57 -0600 Subject: [Freeipa-devel] [PATCH] Fixed host managed-by adder dialog. Message-ID: <4F218075.8020104@redhat.com> The host managed-by adder dialog has been fixed to use the new --not-man-hosts option to filter out hosts that are already added. Ticket #1675 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0343-Fixed-host-managed-by-adder-dialog.patch Type: text/x-patch Size: 1108 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 26 19:11:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Jan 2012 14:11:26 -0500 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files Message-ID: <4F21A55E.2000102@redhat.com> Add a %ghost to some files installed by the UI so that they are owned by freeipa-server when the server is installed and they will be removed by rpm when the package is removed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-933-ghost.patch Type: text/x-diff Size: 1865 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 26 21:37:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Jan 2012 16:37:59 -0500 Subject: [Freeipa-devel] [PATCH] 934 don't bind on TLS connect failure Message-ID: <4F21C7B7.8020707@redhat.com> In our installer LDAP library (also used by replication tools) we handle the case where the remote server hasn't started yet (wait_on_bind). What this doesn't handle is if the connection fails with SERVER_DOWN due to a TLS failure like hostname doesn't match the remote cert. Binding anyway causes a segfault in openldap. I've opened a bug against openldap, it shouldn't segfault. I also added this patch as a workaround. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-934-bind.patch Type: text/x-diff Size: 1212 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 27 09:58:44 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jan 2012 10:58:44 +0100 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <4F21A55E.2000102@redhat.com> References: <4F21A55E.2000102@redhat.com> Message-ID: <1327658324.30921.4.camel@balmora.brq.redhat.com> On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: > Add a %ghost to some files installed by the UI so that they are owned by > freeipa-server when the server is installed and they will be removed by > rpm when the package is removed. > > rob I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this intentional? We may want to keep ca.crt intact when freeipa package is uninstalled... This a list of files in /usr/share/ipa/ that we do not own: file /usr/share/ipa/html/krb.con is not owned by any package file /usr/share/ipa/html/preferences.html is not owned by any package file /usr/share/ipa/html/configure.jar is not owned by any package file /usr/share/ipa/html/krbrealm.con is not owned by any package >> file /usr/share/ipa/html/ca.crt is not owned by any package file /usr/share/ipa/html/krb5.ini is not owned by any package Martin From mkosek at redhat.com Fri Jan 27 10:38:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jan 2012 11:38:53 +0100 Subject: [Freeipa-devel] [PATCH] 934 don't bind on TLS connect failure In-Reply-To: <4F21C7B7.8020707@redhat.com> References: <4F21C7B7.8020707@redhat.com> Message-ID: <1327660733.30921.7.camel@balmora.brq.redhat.com> On Thu, 2012-01-26 at 16:37 -0500, Rob Crittenden wrote: > In our installer LDAP library (also used by replication tools) we handle > the case where the remote server hasn't started yet (wait_on_bind). What > this doesn't handle is if the connection fails with SERVER_DOWN due to a > TLS failure like hostname doesn't match the remote cert. > > Binding anyway causes a segfault in openldap. > > I've opened a bug against openldap, it shouldn't segfault. I also added > this patch as a workaround. > > rob I wasn't able to reproduce the crash yet, but it seems that your patch corrupts the error messages. Instead of standard error like: # ipa-replica-manage del vm-xxx Unable to delete replica vm-xxx: {'desc': "Can't contact LDAP server"} I get those (after I applied your patch): # ipa-replica-manage del vm-xxx Unable to delete replica vm-xxx: 'info' # ipa-replica-manage del vm-142 Unable to delete replica vm-142: 'info' # ipa-replica-manage force-sync --from=vm-xxx unexpected error: 'info' # ipa-replica-manage force-sync --from=vm-142 unexpected error: 'info' Martin From abokovoy at redhat.com Fri Jan 27 11:09:12 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jan 2012 13:09:12 +0200 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <1327658324.30921.4.camel@balmora.brq.redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> Message-ID: <20120127110912.GD11943@redhat.com> On Fri, 27 Jan 2012, Martin Kosek wrote: > On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: > > Add a %ghost to some files installed by the UI so that they are owned by > > freeipa-server when the server is installed and they will be removed by > > rpm when the package is removed. > > > > rob > > I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this > intentional? We may want to keep ca.crt intact when freeipa package is > uninstalled... There is /etc/ipa/ca.crt as well, and appropriate certificate imported into nss database too. > > This a list of files in /usr/share/ipa/ that we do not own: > file /usr/share/ipa/html/krb.con is not owned by any package > file /usr/share/ipa/html/preferences.html is not owned by any package > file /usr/share/ipa/html/configure.jar is not owned by any package > file /usr/share/ipa/html/krbrealm.con is not owned by any package > >> file /usr/share/ipa/html/ca.crt is not owned by any package > file /usr/share/ipa/html/krb5.ini is not owned by any package What about files in /etc/ipa/? -- / Alexander Bokovoy From mkosek at redhat.com Fri Jan 27 11:34:02 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jan 2012 12:34:02 +0100 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <20120127110912.GD11943@redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <20120127110912.GD11943@redhat.com> Message-ID: <1327664042.30921.9.camel@balmora.brq.redhat.com> On Fri, 2012-01-27 at 13:09 +0200, Alexander Bokovoy wrote: > On Fri, 27 Jan 2012, Martin Kosek wrote: > > On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: > > > Add a %ghost to some files installed by the UI so that they are owned by > > > freeipa-server when the server is installed and they will be removed by > > > rpm when the package is removed. > > > > > > rob > > > > I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this > > intentional? We may want to keep ca.crt intact when freeipa package is > > uninstalled... > There is /etc/ipa/ca.crt as well, and appropriate certificate imported > into nss database too. > > > > > This a list of files in /usr/share/ipa/ that we do not own: > > file /usr/share/ipa/html/krb.con is not owned by any package > > file /usr/share/ipa/html/preferences.html is not owned by any package > > file /usr/share/ipa/html/configure.jar is not owned by any package > > file /usr/share/ipa/html/krbrealm.con is not owned by any package > > >> file /usr/share/ipa/html/ca.crt is not owned by any package > > file /usr/share/ipa/html/krb5.ini is not owned by any package > What about files in /etc/ipa/? > I see that ca.crt is the only file that we don't own. Thus we are consistent in %ghost files with /usr/share/ipa/html/ca.crt. Martin From abokovoy at redhat.com Fri Jan 27 11:55:39 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jan 2012 13:55:39 +0200 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <1327664042.30921.9.camel@balmora.brq.redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <20120127110912.GD11943@redhat.com> <1327664042.30921.9.camel@balmora.brq.redhat.com> Message-ID: <20120127115539.GE11943@redhat.com> On Fri, 27 Jan 2012, Martin Kosek wrote: > > > file /usr/share/ipa/html/configure.jar is not owned by any package > > > file /usr/share/ipa/html/krbrealm.con is not owned by any package > > > >> file /usr/share/ipa/html/ca.crt is not owned by any package > > > file /usr/share/ipa/html/krb5.ini is not owned by any package > > What about files in /etc/ipa/? > > > > I see that ca.crt is the only file that we don't own. Thus we are > consistent in %ghost files with /usr/share/ipa/html/ca.crt. Do you want ca.crt be removed on uninstall? Or treated as a config file? -- / Alexander Bokovoy From mkosek at redhat.com Fri Jan 27 11:58:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jan 2012 12:58:49 +0100 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <20120127115539.GE11943@redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <20120127110912.GD11943@redhat.com> <1327664042.30921.9.camel@balmora.brq.redhat.com> <20120127115539.GE11943@redhat.com> Message-ID: <1327665529.30921.11.camel@balmora.brq.redhat.com> On Fri, 2012-01-27 at 13:55 +0200, Alexander Bokovoy wrote: > On Fri, 27 Jan 2012, Martin Kosek wrote: > > > > file /usr/share/ipa/html/configure.jar is not owned by any package > > > > file /usr/share/ipa/html/krbrealm.con is not owned by any package > > > > >> file /usr/share/ipa/html/ca.crt is not owned by any package > > > > file /usr/share/ipa/html/krb5.ini is not owned by any package > > > What about files in /etc/ipa/? > > > > > > > I see that ca.crt is the only file that we don't own. Thus we are > > consistent in %ghost files with /usr/share/ipa/html/ca.crt. > Do you want ca.crt be removed on uninstall? Or treated as a config > file? In my opinion the certificate should be handled as a config file, i.e. should not be removed on uninstall. If you and Rob agree with such behavior, its ACK from me for this patch as is. Martin From abokovoy at redhat.com Fri Jan 27 12:04:53 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jan 2012 14:04:53 +0200 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <1327665529.30921.11.camel@balmora.brq.redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <20120127110912.GD11943@redhat.com> <1327664042.30921.9.camel@balmora.brq.redhat.com> <20120127115539.GE11943@redhat.com> <1327665529.30921.11.camel@balmora.brq.redhat.com> Message-ID: <20120127120453.GF11943@redhat.com> On Fri, 27 Jan 2012, Martin Kosek wrote: > On Fri, 2012-01-27 at 13:55 +0200, Alexander Bokovoy wrote: > > On Fri, 27 Jan 2012, Martin Kosek wrote: > > > > > file /usr/share/ipa/html/configure.jar is not owned by any package > > > > > file /usr/share/ipa/html/krbrealm.con is not owned by any package > > > > > >> file /usr/share/ipa/html/ca.crt is not owned by any package > > > > > file /usr/share/ipa/html/krb5.ini is not owned by any package > > > > What about files in /etc/ipa/? > > > > > > > > > > I see that ca.crt is the only file that we don't own. Thus we are > > > consistent in %ghost files with /usr/share/ipa/html/ca.crt. > > Do you want ca.crt be removed on uninstall? Or treated as a config > > file? > > In my opinion the certificate should be handled as a config file, i.e. > should not be removed on uninstall. If you and Rob agree with such > behavior, its ACK from me for this patch as is. I'm also leaning to treat certificates as config files. -- / Alexander Bokovoy From rcritten at redhat.com Fri Jan 27 14:26:05 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jan 2012 09:26:05 -0500 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <1327658324.30921.4.camel@balmora.brq.redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> Message-ID: <4F22B3FD.8070208@redhat.com> Martin Kosek wrote: > On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: >> Add a %ghost to some files installed by the UI so that they are owned by >> freeipa-server when the server is installed and they will be removed by >> rpm when the package is removed. >> >> rob > > I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this > intentional? We may want to keep ca.crt intact when freeipa package is > uninstalled... > > This a list of files in /usr/share/ipa/ that we do not own: > file /usr/share/ipa/html/krb.con is not owned by any package > file /usr/share/ipa/html/preferences.html is not owned by any package > file /usr/share/ipa/html/configure.jar is not owned by any package > file /usr/share/ipa/html/krbrealm.con is not owned by any package >>> file /usr/share/ipa/html/ca.crt is not owned by any package > file /usr/share/ipa/html/krb5.ini is not owned by any package > > Martin > This was my thinking exactly. Right now if you uninstall the rpms and re-install them then (at least apparently) the server continues to work. I might be talked into adding a config(noreplace) if we want this at least owned by the package. rob From simo at redhat.com Fri Jan 27 14:33:58 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Jan 2012 09:33:58 -0500 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <4F22B3FD.8070208@redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <4F22B3FD.8070208@redhat.com> Message-ID: <1327674839.13963.203.camel@willson.li.ssimo.org> On Fri, 2012-01-27 at 09:26 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: > >> Add a %ghost to some files installed by the UI so that they are owned by > >> freeipa-server when the server is installed and they will be removed by > >> rpm when the package is removed. > >> > >> rob > > > > I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this > > intentional? We may want to keep ca.crt intact when freeipa package is > > uninstalled... > > > > This a list of files in /usr/share/ipa/ that we do not own: > > file /usr/share/ipa/html/krb.con is not owned by any package > > file /usr/share/ipa/html/preferences.html is not owned by any package > > file /usr/share/ipa/html/configure.jar is not owned by any package > > file /usr/share/ipa/html/krbrealm.con is not owned by any package > >>> file /usr/share/ipa/html/ca.crt is not owned by any package > > file /usr/share/ipa/html/krb5.ini is not owned by any package > > > > Martin > > > > This was my thinking exactly. > > Right now if you uninstall the rpms and re-install them then (at least > apparently) the server continues to work. > > I might be talked into adding a config(noreplace) if we want this at > least owned by the package. I add my +1 at keeping ca.crt around. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Jan 27 15:00:10 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jan 2012 16:00:10 +0100 Subject: [Freeipa-devel] [PATCH] 070 Modifying DNS UI to benefit from new DNS API In-Reply-To: <4F1F0EAA.6090908@redhat.com> References: <4F1D84DA.30802@redhat.com> <4F1F0EAA.6090908@redhat.com> Message-ID: <4F22BBFA.7040307@redhat.com> Note to Endi: sending again to devel-list On 01/24/2012 09:03 PM, Endi Sukma Dewata wrote: > On 1/23/2012 10:03 AM, Petr Vobornik wrote: >> DNS UI was modified to offer structured way of defining DNS records. >> >> https://fedorahosted.org/freeipa/ticket/2208 >> >> This patch depends on Martin's patch #193. >> >> Preview: >> http://pvoborni.fedorapeople.org/dns/#dns=dnsrecord&identity=dns&navigation=identity&dnsrecord-facet=default&dnsrecord-pkey=testrec&dnszone-pkey=test.com >> > > Some issues that I think need to be fixed before push: > > 1. In the record details page, deleting the last value in the record > generates a JavaScript error stopping the execution. It should redirect > back to the search page. Fixed > > 2. The nsec_part_types is multi-valued, but the drop down list only > allows one value. We might need to use a text field to allow multiple > values until we find a better solution. Right now this can't be tested > properly due to https://fedorahosted.org/freeipa/ticket/2307. Changed to text. I left there a commented-out option definition with a TODO: comment to remind that it should be changed later. > > 3. Some attributes should be displayed as a drop down list in the dialog > box. One of them is already defined using options but it does not appear > as a drop down list. They include: > * sig_part_type_covered > * rrsig_part_type_covered > * naptr_part_flags Fixed. > > 4. There should be enough space to show the attributes of the following > records in separate columns (instead of showing the raw data): > * SRV > * SSHFP Fixed. > > 5. The following attributes probably should be shown as text areas in > the edit dialog and should not be displayed in the table because it > could be too long: > * cert_part_certificate_or_crl > * ds_part_digest > * key_part_public_key > * sig_part_signature > * rrsig_part_signature > * sshfp_part_fingerprint Fixed. > > 6. In the record edit dialog, the Edit button probably better be called > Save or Update. Changed to Update. > > Issues that can be fixed later: > > 7. The record type header (e.g. A record) on the left of the table > probably can be moved above the table to allow wider table. For > comparison, in HBAC/sudo rule details page the tables occupy the entire > width of the page. Maybe. I will wait for Kyle's review (WWKR). In this implementation the table is too narrow, if we moved the headers and extend the table the space for one type will be too height a user will have to scroll a lot. Both are not ideal. > > 8. After deleting a value, the Delete button remains enabled although > there's no values selected. Fixed - on update are all checkboxes unselected. > > 9. The Edit links in the tables could be replaced with icons. Another > option is to convert the record values into links which will open the > dialog. I agree. WWKR > > 10. We could use an FQDN validator for some attributes. It can be used > in host adder dialog too. Agree, but will do it later. > > 11. We could use a float validator for some attributes. Maybe, but will do it later. > > 12. If possible, include an example of each record type in the test data. > >> Possible modifications: >> 1) modify labels to exclude record type's name. > > Agreed. The current labels could be confusing. For example, the > a_ip_address has a label 'A IP Address'. I think it should be just 'IP > Address' or 'IPv4 Address'. The labels do not need to include the record > type because they will always be displayed within the context of a > record. The doc can provide a more verbose explanation, e.g. 'IPv4 > address for DNS A record', which we can show as a tooltip. Changed. I also changed the type's header to not include the 'record' ie: from 'A record' to 'A' as it was before. > >> 2) hide empty tables (as I suggested in ticket description) > > OK. We probably can move the Add and Delete buttons next to the type > header and keep it there even when the table is visible. WWKR > >> 3) attributes which are displayed in table columns can be easily changed >> or reordered. I used following principle: "If type has up to 4 >> attributes: show them all in table if not, show raw value." This way all >> data are displayed and columns are not too narrow. > > For LOC record we probably can use a formatter to show some of the > attributes in a concise way: > > Latitude Longitude Altitude > ------------------------------------------------ > 35? 46' 26.687" N 78? 40' 34.499" W 363.06 I like it, will do later. > > For other record types that have many attributes, the raw data could be > hard to read without knowing the exact order of the attributes and it's > not aligned using columns. It might be better to show the most important > attributes only. The rest of the attributes can be viewed in the edit > dialog. > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0070-1-Modifying-DNS-UI-to-benefit-from-new-DNS-API.patch Type: text/x-patch Size: 294517 bytes Desc: not available URL: From mkosek at redhat.com Fri Jan 27 15:56:56 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jan 2012 16:56:56 +0100 Subject: [Freeipa-devel] [PATCH] 203 Add argument help to CLI Message-ID: <1327679816.29228.13.camel@balmora.brq.redhat.com> An example of the improved help: # ipa help user-add Purpose: Add a new user. Usage: ipa [global-options] user-add LOGIN [options] Positional arguments: LOGIN: User login Options: -h, --help show this help message and exit --first=STR First name --last=STR Last name --cn=STR Full name ... We may want to improve help for most arguments we use. Most of them are missing. In this patch I updated just the CRITERIA argument that was complained about in the relevant BZ. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-203-add-argument-help-to-cli.patch Type: text/x-patch Size: 4309 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jan 27 16:49:54 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jan 2012 17:49:54 +0100 Subject: [Freeipa-devel] [PATCH] 072 Navigation and redirection to various facets Message-ID: <4F22D5B2.4080701@redhat.com> In current implementation target facet of navigation(from menu) and redirection is always one exact facet per entity. There isn't a way to navigate to different facet from menu or redirect to different facets from various facets. This patch adds: * possibility to define menu items which can navigate to different facets of various entities. This also means that now current menu tree can contain leafs with the same entity. * possibility to define redirection target per facet - it is needed to keep breadcrumb navigation consistent with various navigation tree patch leading leafs with same entity. This functionality is needed for Automember UI. Automember UI is designed as if it was for two entities but it is in fact only one. Note: attaching early (missing a lot of stuff) WIP patch of Automember UI to illustrate usage of this patch. https://fedorahosted.org/freeipa/ticket/2195 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0072-Navigation-and-redirection-to-various-facets.patch Type: text/x-patch Size: 11696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0068-Automember-UI.patch Type: text/x-patch Size: 20056 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 27 18:21:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jan 2012 13:21:58 -0500 Subject: [Freeipa-devel] [PATCH] 935 fix winsync replica management Message-ID: <4F22EB46.5060307@redhat.com> The ipa-replica-manage tool was trying to contact the AD server to do replica management including re-initialize, force-sync and del. The AD server is unaware of IPA, the winsync plugin handles this for us. This patch avoids contact the AD server when it detects a winsync agreement. I also require root when creating a winsync agreement as we need to write to the 389-ds NSS database. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-935-winsync.patch Type: text/x-diff Size: 8347 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 27 18:22:51 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jan 2012 13:22:51 -0500 Subject: [Freeipa-devel] [PATCH] 934 don't bind on TLS connect failure In-Reply-To: <1327660733.30921.7.camel@balmora.brq.redhat.com> References: <4F21C7B7.8020707@redhat.com> <1327660733.30921.7.camel@balmora.brq.redhat.com> Message-ID: <4F22EB7B.3090309@redhat.com> Martin Kosek wrote: > On Thu, 2012-01-26 at 16:37 -0500, Rob Crittenden wrote: >> In our installer LDAP library (also used by replication tools) we handle >> the case where the remote server hasn't started yet (wait_on_bind). What >> this doesn't handle is if the connection fails with SERVER_DOWN due to a >> TLS failure like hostname doesn't match the remote cert. >> >> Binding anyway causes a segfault in openldap. >> >> I've opened a bug against openldap, it shouldn't segfault. I also added >> this patch as a workaround. >> >> rob > > I wasn't able to reproduce the crash yet, but it seems that your patch > corrupts the error messages. > > Instead of standard error like: > # ipa-replica-manage del vm-xxx > Unable to delete replica vm-xxx: {'desc': "Can't contact LDAP server"} > > I get those (after I applied your patch): > # ipa-replica-manage del vm-xxx > Unable to delete replica vm-xxx: 'info' > # ipa-replica-manage del vm-142 > Unable to delete replica vm-142: 'info' > # ipa-replica-manage force-sync --from=vm-xxx > unexpected error: 'info' > # ipa-replica-manage force-sync --from=vm-142 > unexpected error: 'info' I had run into the same problem last night but forgot to send out an updated patch. Attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-934-1-bind.patch Type: text/x-diff Size: 1224 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jan 30 09:00:53 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jan 2012 10:00:53 +0100 Subject: [Freeipa-devel] [PATCH] Fixed host managed-by adder dialog. In-Reply-To: <4F218075.8020104@redhat.com> References: <4F218075.8020104@redhat.com> Message-ID: <4F265C45.4090301@redhat.com> On 01/26/2012 05:33 PM, Endi Sukma Dewata wrote: > The host managed-by adder dialog has been fixed to use the new > --not-man-hosts option to filter out hosts that are already added. > > Ticket #1675 > > ACK -- Petr Vobornik From mkosek at redhat.com Mon Jan 30 09:34:54 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jan 2012 10:34:54 +0100 Subject: [Freeipa-devel] [PATCH] 934 don't bind on TLS connect failure In-Reply-To: <4F22EB7B.3090309@redhat.com> References: <4F21C7B7.8020707@redhat.com> <1327660733.30921.7.camel@balmora.brq.redhat.com> <4F22EB7B.3090309@redhat.com> Message-ID: <1327916094.4985.0.camel@balmora.brq.redhat.com> On Fri, 2012-01-27 at 13:22 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-01-26 at 16:37 -0500, Rob Crittenden wrote: > >> In our installer LDAP library (also used by replication tools) we handle > >> the case where the remote server hasn't started yet (wait_on_bind). What > >> this doesn't handle is if the connection fails with SERVER_DOWN due to a > >> TLS failure like hostname doesn't match the remote cert. > >> > >> Binding anyway causes a segfault in openldap. > >> > >> I've opened a bug against openldap, it shouldn't segfault. I also added > >> this patch as a workaround. > >> > >> rob > > > > I wasn't able to reproduce the crash yet, but it seems that your patch > > corrupts the error messages. > > > > Instead of standard error like: > > # ipa-replica-manage del vm-xxx > > Unable to delete replica vm-xxx: {'desc': "Can't contact LDAP server"} > > > > I get those (after I applied your patch): > > # ipa-replica-manage del vm-xxx > > Unable to delete replica vm-xxx: 'info' > > # ipa-replica-manage del vm-142 > > Unable to delete replica vm-142: 'info' > > # ipa-replica-manage force-sync --from=vm-xxx > > unexpected error: 'info' > > # ipa-replica-manage force-sync --from=vm-142 > > unexpected error: 'info' > > I had run into the same problem last night but forgot to send out an > updated patch. Attached. > > rob ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Mon Jan 30 09:35:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jan 2012 10:35:59 +0100 Subject: [Freeipa-devel] [PATCH] 934 don't bind on TLS connect failure In-Reply-To: <4F22EB7B.3090309@redhat.com> References: <4F21C7B7.8020707@redhat.com> <1327660733.30921.7.camel@balmora.brq.redhat.com> <4F22EB7B.3090309@redhat.com> Message-ID: <1327916159.4985.1.camel@balmora.brq.redhat.com> On Fri, 2012-01-27 at 13:22 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-01-26 at 16:37 -0500, Rob Crittenden wrote: > >> In our installer LDAP library (also used by replication tools) we handle > >> the case where the remote server hasn't started yet (wait_on_bind). What > >> this doesn't handle is if the connection fails with SERVER_DOWN due to a > >> TLS failure like hostname doesn't match the remote cert. > >> > >> Binding anyway causes a segfault in openldap. > >> > >> I've opened a bug against openldap, it shouldn't segfault. I also added > >> this patch as a workaround. > >> > >> rob > > > > I wasn't able to reproduce the crash yet, but it seems that your patch > > corrupts the error messages. > > > > Instead of standard error like: > > # ipa-replica-manage del vm-xxx > > Unable to delete replica vm-xxx: {'desc': "Can't contact LDAP server"} > > > > I get those (after I applied your patch): > > # ipa-replica-manage del vm-xxx > > Unable to delete replica vm-xxx: 'info' > > # ipa-replica-manage del vm-142 > > Unable to delete replica vm-142: 'info' > > # ipa-replica-manage force-sync --from=vm-xxx > > unexpected error: 'info' > > # ipa-replica-manage force-sync --from=vm-142 > > unexpected error: 'info' > > I had run into the same problem last night but forgot to send out an > updated patch. Attached. > > rob Yes, now the error messages are OK. ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Mon Jan 30 10:06:52 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jan 2012 11:06:52 +0100 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <4F22B3FD.8070208@redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <4F22B3FD.8070208@redhat.com> Message-ID: <1327918012.4985.4.camel@balmora.brq.redhat.com> On Fri, 2012-01-27 at 09:26 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: > >> Add a %ghost to some files installed by the UI so that they are owned by > >> freeipa-server when the server is installed and they will be removed by > >> rpm when the package is removed. > >> > >> rob > > > > I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this > > intentional? We may want to keep ca.crt intact when freeipa package is > > uninstalled... > > > > This a list of files in /usr/share/ipa/ that we do not own: > > file /usr/share/ipa/html/krb.con is not owned by any package > > file /usr/share/ipa/html/preferences.html is not owned by any package > > file /usr/share/ipa/html/configure.jar is not owned by any package > > file /usr/share/ipa/html/krbrealm.con is not owned by any package > >>> file /usr/share/ipa/html/ca.crt is not owned by any package > > file /usr/share/ipa/html/krb5.ini is not owned by any package > > > > Martin > > > > This was my thinking exactly. > > Right now if you uninstall the rpms and re-install them then (at least > apparently) the server continues to work. > > I might be talked into adding a config(noreplace) if we want this at > least owned by the package. I think it would be a good idea. We already own for example default.conf with config(noreplace) which is also generated during installation. There 2 ca.crt's to manage this way: /usr/share/ipa/html/ca.crt /etc/ipa/ca.crt Martin From mkosek at redhat.com Mon Jan 30 12:46:38 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jan 2012 13:46:38 +0100 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <4F10496B.6070900@redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> Message-ID: <1327927598.4985.17.camel@balmora.brq.redhat.com> On Fri, 2012-01-13 at 10:10 -0500, Rob Crittenden wrote: > Rob Crittenden wrote: > > A bug when creating replication agreements has caused memberOf to be > > dropped from the exclusion list. This patch adds a tool that will find > > and fix the agreements. It will be run when the package is installed so > > end-users should never need to do anything, but it is harmless if run > > multiple times. > > > > rob > > The wrong list attribute was being updated, this new patch updates > nsDS5ReplicatedAttributeList instead of nsDS5ReplicatedAttributeListTotal. > > rob The script itself works fine. I would just remove: + config.add_standard_options(parser) as these options are not used in the script anyway: --realm=REALM Override default IPA realm --server=SERVER Override default IPA server --domain=DOMAIN Override default IPA DNS domain The script install/tools/ipa-managed-entries has the same kind of error. My main concern is if it is conceptually OK to create a separate script for one-time fixes like this one. What if we find another problem with replica agreements where we would need to update existing agreements? Would we create another fix tool or enhance ipa-fixreplica? I am just afraid that in time we would "pollute" our ipa-* tool collection with one time fixes. Maybe we could move this agreement fix to a plugin in ipa-ldap-updater or create a more general tool for one-time fixes like this one. I am thinking about something like this: ipa-server-remedy [-l/--list] [-u/--unit] [-d/--debug] [-t/--test] When run without options it would run all remedy "plugins" to fix all possible one-time errors. There would be also these options: --list: list all remedy "plugins". In this case there would be just this one --unit: run just the chosen remedy "plugin" --debug, --test: the same functionality as in your patch Martin From mkosek at redhat.com Mon Jan 30 13:51:42 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jan 2012 14:51:42 +0100 Subject: [Freeipa-devel] [PATCH] 928 fix automount submounts In-Reply-To: <4F18917A.90205@redhat.com> References: <4F18917A.90205@redhat.com> Message-ID: <1327931502.4985.22.camel@balmora.brq.redhat.com> On Thu, 2012-01-19 at 16:56 -0500, Rob Crittenden wrote: > There is a --parentmap option in automountmap-add-indirect. This is used > to create submount maps but wasn't working at all. It now creates the > proper key entry pointing to another map. > > See ticket https://fedorahosted.org/freeipa/ticket/1268 for more details > and examples. > > rob Works fine. I have just one minor issue. There was one untranslatable string: + textui.print_plain('maps not connected to /etc/auto.master:') I just wonder - can automount maps contain spaces? They are allowed in our framework. I think this part would not work correctly then: automountinformation='-fstype=autofs ldap:%s' % map Martin From jhrozek at redhat.com Mon Jan 30 14:06:27 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 30 Jan 2012 15:06:27 +0100 Subject: [Freeipa-devel] [PATCH] 928 fix automount submounts In-Reply-To: <1327931502.4985.22.camel@balmora.brq.redhat.com> References: <4F18917A.90205@redhat.com> <1327931502.4985.22.camel@balmora.brq.redhat.com> Message-ID: <20120130140627.GB4704@zeppelin.brq.redhat.com> On Mon, Jan 30, 2012 at 02:51:42PM +0100, Martin Kosek wrote: > On Thu, 2012-01-19 at 16:56 -0500, Rob Crittenden wrote: > > There is a --parentmap option in automountmap-add-indirect. This is used > > to create submount maps but wasn't working at all. It now creates the > > proper key entry pointing to another map. > > > > See ticket https://fedorahosted.org/freeipa/ticket/1268 for more details > > and examples. > > > > rob > > Works fine. I have just one minor issue. There was one untranslatable > string: > > + textui.print_plain('maps not connected to /etc/auto.master:') > > I just wonder - can automount maps contain spaces? They are allowed in > our framework. I think this part would not work correctly then: > > automountinformation='-fstype=autofs ldap:%s' % map > > Martin > As far as automount is concerned, the maps are just filesystem names (that's what automounter historically used). So a space would be rare and unwise to use, but technically possible. From abokovoy at redhat.com Mon Jan 30 14:28:51 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Jan 2012 16:28:51 +0200 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <1327927598.4985.17.camel@balmora.brq.redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> <1327927598.4985.17.camel@balmora.brq.redhat.com> Message-ID: <20120130142851.GG11943@redhat.com> On Mon, 30 Jan 2012, Martin Kosek wrote: > My main concern is if it is conceptually OK to create a separate script > for one-time fixes like this one. What if we find another problem with > replica agreements where we would need to update existing agreements? > Would we create another fix tool or enhance ipa-fixreplica? I am just > afraid that in time we would "pollute" our ipa-* tool collection with > one time fixes. > > Maybe we could move this agreement fix to a plugin in ipa-ldap-updater > or create a more general tool for one-time fixes like this one. I am > thinking about something like this: > ipa-server-remedy [-l/--list] [-u/--unit] [-d/--debug] [-t/--test] > When run without options it would run all remedy "plugins" to fix all > possible one-time errors. There would be also these options: > --list: list all remedy "plugins". In this case there would be just this > one > --unit: run just the chosen remedy "plugin" > --debug, --test: the same functionality as in your patch We do have ipa-ldap-updater which now supports plugins and may serve the same purpose without introducing new utility... -- / Alexander Bokovoy From mkosek at redhat.com Mon Jan 30 14:37:04 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jan 2012 15:37:04 +0100 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <20120130142851.GG11943@redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> <1327927598.4985.17.camel@balmora.brq.redhat.com> <20120130142851.GG11943@redhat.com> Message-ID: <1327934224.4985.24.camel@balmora.brq.redhat.com> On Mon, 2012-01-30 at 16:28 +0200, Alexander Bokovoy wrote: > On Mon, 30 Jan 2012, Martin Kosek wrote: > > My main concern is if it is conceptually OK to create a separate script > > for one-time fixes like this one. What if we find another problem with > > replica agreements where we would need to update existing agreements? > > Would we create another fix tool or enhance ipa-fixreplica? I am just > > afraid that in time we would "pollute" our ipa-* tool collection with > > one time fixes. > > > > Maybe we could move this agreement fix to a plugin in ipa-ldap-updater > > or create a more general tool for one-time fixes like this one. I am > > thinking about something like this: > > ipa-server-remedy [-l/--list] [-u/--unit] [-d/--debug] [-t/--test] > > When run without options it would run all remedy "plugins" to fix all > > possible one-time errors. There would be also these options: > > --list: list all remedy "plugins". In this case there would be just this > > one > > --unit: run just the chosen remedy "plugin" > > --debug, --test: the same functionality as in your patch > We do have ipa-ldap-updater which now supports plugins and may serve > the same purpose without introducing new utility... > Yes, this was my first suggestion. I mentioned this general utility as a second option if we need to implement this onetime fix as a separate tool for some reason. Martin From rcritten at redhat.com Mon Jan 30 14:48:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 09:48:33 -0500 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <1327934224.4985.24.camel@balmora.brq.redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> <1327927598.4985.17.camel@balmora.brq.redhat.com> <20120130142851.GG11943@redhat.com> <1327934224.4985.24.camel@balmora.brq.redhat.com> Message-ID: <4F26ADC1.8050102@redhat.com> Martin Kosek wrote: > On Mon, 2012-01-30 at 16:28 +0200, Alexander Bokovoy wrote: >> On Mon, 30 Jan 2012, Martin Kosek wrote: >>> My main concern is if it is conceptually OK to create a separate script >>> for one-time fixes like this one. What if we find another problem with >>> replica agreements where we would need to update existing agreements? >>> Would we create another fix tool or enhance ipa-fixreplica? I am just >>> afraid that in time we would "pollute" our ipa-* tool collection with >>> one time fixes. >>> >>> Maybe we could move this agreement fix to a plugin in ipa-ldap-updater >>> or create a more general tool for one-time fixes like this one. I am >>> thinking about something like this: >>> ipa-server-remedy [-l/--list] [-u/--unit] [-d/--debug] [-t/--test] >>> When run without options it would run all remedy "plugins" to fix all >>> possible one-time errors. There would be also these options: >>> --list: list all remedy "plugins". In this case there would be just this >>> one >>> --unit: run just the chosen remedy "plugin" >>> --debug, --test: the same functionality as in your patch >> We do have ipa-ldap-updater which now supports plugins and may serve >> the same purpose without introducing new utility... >> > > Yes, this was my first suggestion. I mentioned this general utility as a > second option if we need to implement this onetime fix as a separate > tool for some reason. > > Martin > This is for FreeIPA 2.1 which doesn't support update plugins. rob From abokovoy at redhat.com Mon Jan 30 14:55:20 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Jan 2012 16:55:20 +0200 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <1327934224.4985.24.camel@balmora.brq.redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> <1327927598.4985.17.camel@balmora.brq.redhat.com> <20120130142851.GG11943@redhat.com> <1327934224.4985.24.camel@balmora.brq.redhat.com> Message-ID: <20120130145520.GH11943@redhat.com> On Mon, 30 Jan 2012, Martin Kosek wrote: > > > Maybe we could move this agreement fix to a plugin in ipa-ldap-updater > > > or create a more general tool for one-time fixes like this one. I am > > > thinking about something like this: > > > ipa-server-remedy [-l/--list] [-u/--unit] [-d/--debug] [-t/--test] > > > When run without options it would run all remedy "plugins" to fix all > > > possible one-time errors. There would be also these options: > > > --list: list all remedy "plugins". In this case there would be just this > > > one > > > --unit: run just the chosen remedy "plugin" > > > --debug, --test: the same functionality as in your patch > > We do have ipa-ldap-updater which now supports plugins and may serve > > the same purpose without introducing new utility... > > > > Yes, this was my first suggestion. I mentioned this general utility as a > second option if we need to implement this onetime fix as a separate > tool for some reason. Yep. I'd rather convert all our fixers to ipa-ldap-updater plugins than to do separate tools. We could make a separate mode that simply runs plugins of type REMEDY_UPDATE (does not exist right now). Rob, do you agree as well? -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jan 30 14:57:16 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Jan 2012 16:57:16 +0200 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <4F26ADC1.8050102@redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> <1327927598.4985.17.camel@balmora.brq.redhat.com> <20120130142851.GG11943@redhat.com> <1327934224.4985.24.camel@balmora.brq.redhat.com> <4F26ADC1.8050102@redhat.com> Message-ID: <20120130145716.GI11943@redhat.com> On Mon, 30 Jan 2012, Rob Crittenden wrote: > >Yes, this was my first suggestion. I mentioned this general utility as a > >second option if we need to implement this onetime fix as a separate > >tool for some reason. > > > >Martin > > > > This is for FreeIPA 2.1 which doesn't support update plugins. I think we can handle 2.1 branch separately but for 2.2 onwards this could be a standard procedure which could be wired into postinstall scriplet on RPM-based systems. -- / Alexander Bokovoy From rcritten at redhat.com Mon Jan 30 15:04:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 10:04:59 -0500 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <20120130145716.GI11943@redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> <1327927598.4985.17.camel@balmora.brq.redhat.com> <20120130142851.GG11943@redhat.com> <1327934224.4985.24.camel@balmora.brq.redhat.com> <4F26ADC1.8050102@redhat.com> <20120130145716.GI11943@redhat.com> Message-ID: <4F26B19B.6020204@redhat.com> Alexander Bokovoy wrote: > On Mon, 30 Jan 2012, Rob Crittenden wrote: >>> Yes, this was my first suggestion. I mentioned this general utility as a >>> second option if we need to implement this onetime fix as a separate >>> tool for some reason. >>> >>> Martin >>> >> >> This is for FreeIPA 2.1 which doesn't support update plugins. > I think we can handle 2.1 branch separately but for 2.2 onwards this > could be a standard procedure which could be wired into postinstall > scriplet on RPM-based systems. That's the plan. Once this script gets acked it is a short hop to being an update plugin that will be reviewed separately. rob From rcritten at redhat.com Mon Jan 30 15:12:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 10:12:15 -0500 Subject: [Freeipa-devel] [PATCH] 928 fix automount submounts In-Reply-To: <20120130140627.GB4704@zeppelin.brq.redhat.com> References: <4F18917A.90205@redhat.com> <1327931502.4985.22.camel@balmora.brq.redhat.com> <20120130140627.GB4704@zeppelin.brq.redhat.com> Message-ID: <4F26B34F.2060308@redhat.com> Jakub Hrozek wrote: > On Mon, Jan 30, 2012 at 02:51:42PM +0100, Martin Kosek wrote: >> On Thu, 2012-01-19 at 16:56 -0500, Rob Crittenden wrote: >>> There is a --parentmap option in automountmap-add-indirect. This is used >>> to create submount maps but wasn't working at all. It now creates the >>> proper key entry pointing to another map. >>> >>> See ticket https://fedorahosted.org/freeipa/ticket/1268 for more details >>> and examples. >>> >>> rob >> >> Works fine. I have just one minor issue. There was one untranslatable >> string: >> >> + textui.print_plain('maps not connected to /etc/auto.master:') >> >> I just wonder - can automount maps contain spaces? They are allowed in >> our framework. I think this part would not work correctly then: >> >> automountinformation='-fstype=autofs ldap:%s' % map >> >> Martin >> > > As far as automount is concerned, the maps are just filesystem names > (that's what automounter historically used). So a space would be rare and > unwise to use, but technically possible. I'll ask the autofs maintainer what he thinks. I think this would blow up their parser as well. This is their format, not ours. rob From rcritten at redhat.com Mon Jan 30 15:50:25 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 10:50:25 -0500 Subject: [Freeipa-devel] [PATCH] 921 fix existing replication agreements In-Reply-To: <4F26B19B.6020204@redhat.com> References: <4F0728C1.9010902@redhat.com> <4F10496B.6070900@redhat.com> <1327927598.4985.17.camel@balmora.brq.redhat.com> <20120130142851.GG11943@redhat.com> <1327934224.4985.24.camel@balmora.brq.redhat.com> <4F26ADC1.8050102@redhat.com> <20120130145716.GI11943@redhat.com> <4F26B19B.6020204@redhat.com> Message-ID: <4F26BC41.5030405@redhat.com> Rob Crittenden wrote: > Alexander Bokovoy wrote: >> On Mon, 30 Jan 2012, Rob Crittenden wrote: >>>> Yes, this was my first suggestion. I mentioned this general utility >>>> as a >>>> second option if we need to implement this onetime fix as a separate >>>> tool for some reason. >>>> >>>> Martin >>>> >>> >>> This is for FreeIPA 2.1 which doesn't support update plugins. >> I think we can handle 2.1 branch separately but for 2.2 onwards this >> could be a standard procedure which could be wired into postinstall >> scriplet on RPM-based systems. > > That's the plan. Once this script gets acked it is a short hop to being > an update plugin that will be reviewed separately. > > rob > Updated ipa-2-1 branch patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-921-3-fixreplica.patch Type: text/x-diff Size: 11977 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 30 16:22:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 11:22:16 -0500 Subject: [Freeipa-devel] [PATCH] 203 Add argument help to CLI In-Reply-To: <1327679816.29228.13.camel@balmora.brq.redhat.com> References: <1327679816.29228.13.camel@balmora.brq.redhat.com> Message-ID: <4F26C3B8.4090702@redhat.com> Martin Kosek wrote: > An example of the improved help: > > # ipa help user-add > Purpose: Add a new user. > Usage: ipa [global-options] user-add LOGIN [options] > > Positional arguments: > LOGIN: User login > > Options: > -h, --help show this help message and exit > --first=STR First name > --last=STR Last name > --cn=STR Full name > ... > > > We may want to improve help for most arguments we use. Most of them are > missing. In this patch I updated just the CRITERIA argument that was > complained about in the relevant BZ. > > Martin Patch looks ok, I just think the output could be improved. I think it should look similar to the existing usage output, so, similar indention and description columns lined up: Usage: ipa [global-options] user-add LOGIN [options] Positional arguments: LOGIN User login Options: -h, --help show this help message and exit rob From mkosek at redhat.com Mon Jan 30 16:30:02 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jan 2012 17:30:02 +0100 Subject: [Freeipa-devel] [PATCH] 925 Make deleting replication agreements nicer In-Reply-To: <4F14FB03.7010208@redhat.com> References: <4F14FB03.7010208@redhat.com> Message-ID: <1327941002.4985.31.camel@balmora.brq.redhat.com> On Mon, 2012-01-16 at 23:37 -0500, Rob Crittenden wrote: > Check for the existence of a replication agreement before deleting it. > > When using ipa-replica-manage or ipa-csreplica-manage to delete an > agreement with a host we would try to make a connection to that host > prior to tryign to delete it. This meant that the trying to delete a > host we don't hvae an agreement with would return a connection error > instead of a "no agreement with host foo" error. > > Also display a completed message when an agreement is removed. > > https://fedorahosted.org/freeipa/ticket/2048 > https://fedorahosted.org/freeipa/ticket/2125 > > rob ACK, works fine. Pushed to master, ipa-2-2. Martin From rcritten at redhat.com Mon Jan 30 16:52:19 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 11:52:19 -0500 Subject: [Freeipa-devel] [PATCH] 202 Add reverse DNS record when forward is created In-Reply-To: <1327499671.19882.4.camel@balmora.brq.redhat.com> References: <1327499671.19882.4.camel@balmora.brq.redhat.com> Message-ID: <4F26CAC3.5000804@redhat.com> Martin Kosek wrote: > Adding reverse DNS record may be a time consuming task, especially > for IPv6 addresses. Having a way to automatically create a reverse > record when a forward record is created could speed up the process. > host-add command already has this possibility. > > This patch takes advantage of the new per-type API and adds new > options for A/AAAA record types: --a-create-reverse and > --aaaa-create-reverse. These commands can be used to automatically > create reverse records for new A/AAAA addresses (both forward > and reverse zones need to be managed by FreeIPA server): > > ipa dnsrecord-add example.com foo --a-rec=10.0.0.1 --a-create-reverse > > This command would add a new A record to record foo in zone > example.com and a PTR record to appropriate reverse zone for > IP address 10.0.0.1 (for example PTR record 1 in zone > 0.0.10.in-addr.arpa. pointing to foo.example.com.). > > Few modification were done to new DNS API to support this feature: > - Refactor --ip-address option handling from host-add and place it > to dns.py to be used by both modules > - Add support for "extra" per-type options > - Hide DNS record part options in dnsrecord_find command as they > have no effect for this command > > https://fedorahosted.org/freeipa/ticket/2009 Can the options -a-create-reverse and -aaaa-create-reverse be combined? I was able to create an IPv4 addr using -aaaa-create-reverse: # ipa dnsrecord-add example.com baz --a-rec=192.168.166.115 --aaaa-create-reverse Record name: baz A record: 192.168.166.115 Otherwise the patch seems fine. rob From rcritten at redhat.com Mon Jan 30 18:53:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 13:53:38 -0500 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <1327918012.4985.4.camel@balmora.brq.redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <4F22B3FD.8070208@redhat.com> <1327918012.4985.4.camel@balmora.brq.redhat.com> Message-ID: <4F26E732.6010300@redhat.com> Martin Kosek wrote: > On Fri, 2012-01-27 at 09:26 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: >>>> Add a %ghost to some files installed by the UI so that they are owned by >>>> freeipa-server when the server is installed and they will be removed by >>>> rpm when the package is removed. >>>> >>>> rob >>> >>> I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this >>> intentional? We may want to keep ca.crt intact when freeipa package is >>> uninstalled... >>> >>> This a list of files in /usr/share/ipa/ that we do not own: >>> file /usr/share/ipa/html/krb.con is not owned by any package >>> file /usr/share/ipa/html/preferences.html is not owned by any package >>> file /usr/share/ipa/html/configure.jar is not owned by any package >>> file /usr/share/ipa/html/krbrealm.con is not owned by any package >>>>> file /usr/share/ipa/html/ca.crt is not owned by any package >>> file /usr/share/ipa/html/krb5.ini is not owned by any package >>> >>> Martin >>> >> >> This was my thinking exactly. >> >> Right now if you uninstall the rpms and re-install them then (at least >> apparently) the server continues to work. >> >> I might be talked into adding a config(noreplace) if we want this at >> least owned by the package. > > I think it would be a good idea. We already own for example default.conf > with config(noreplace) which is also generated during installation. > > There 2 ca.crt's to manage this way: > /usr/share/ipa/html/ca.crt > /etc/ipa/ca.crt > > Martin > Ok, added both of these. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-933-1-ghost.patch Type: text/x-diff Size: 2649 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 30 19:41:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 14:41:57 -0500 Subject: [Freeipa-devel] [PATCH] 928 fix automount submounts In-Reply-To: <4F26B34F.2060308@redhat.com> References: <4F18917A.90205@redhat.com> <1327931502.4985.22.camel@balmora.brq.redhat.com> <20120130140627.GB4704@zeppelin.brq.redhat.com> <4F26B34F.2060308@redhat.com> Message-ID: <4F26F285.4050006@redhat.com> Rob Crittenden wrote: > Jakub Hrozek wrote: >> On Mon, Jan 30, 2012 at 02:51:42PM +0100, Martin Kosek wrote: >>> On Thu, 2012-01-19 at 16:56 -0500, Rob Crittenden wrote: >>>> There is a --parentmap option in automountmap-add-indirect. This is >>>> used >>>> to create submount maps but wasn't working at all. It now creates the >>>> proper key entry pointing to another map. >>>> >>>> See ticket https://fedorahosted.org/freeipa/ticket/1268 for more >>>> details >>>> and examples. >>>> >>>> rob >>> >>> Works fine. I have just one minor issue. There was one untranslatable >>> string: >>> >>> + textui.print_plain('maps not connected to /etc/auto.master:') >>> >>> I just wonder - can automount maps contain spaces? They are allowed in >>> our framework. I think this part would not work correctly then: >>> >>> automountinformation='-fstype=autofs ldap:%s' % map >>> >>> Martin >>> >> >> As far as automount is concerned, the maps are just filesystem names >> (that's what automounter historically used). So a space would be rare and >> unwise to use, but technically possible. > > I'll ask the autofs maintainer what he thinks. I think this would blow > up their parser as well. This is their format, not ours. I tried this out. Spaces work fine both in a mount name and in a map name: /etc/auto.master: /- /etc/auto.direct /attic /etc/auto.attic --------------------------- /etc/auto.direct: --------------------------- /etc/auto.attic: sub2 -fstype=autofs ldap:auto sub maps not connected to /etc/auto.master: --------------------------- /etc/auto sub: space attic:/foo bar --------------------------- # ls /attic/sub2/space test # mount|grep attic attic:/foo bar/ on /attic/sub2/space type nfs ... So it looks like spaces aren't an issue. rob From rcritten at redhat.com Mon Jan 30 22:16:04 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jan 2012 17:16:04 -0500 Subject: [Freeipa-devel] [PATCH] 936 support defaultNamingContext and basedn in migration Message-ID: <4F2716A4.1050000@redhat.com> Add support for defaultNamingContext which is available in 389-ds 1.2.10-0.9.a8. If the attribute isn't returned continue to use namingContexts to determine the basedn. While I was in poking at this I added support to the migration plugin to be able to pass in the basedn of the remote server. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-936-defaultnaming.patch Type: text/x-diff Size: 12559 bytes Desc: not available URL: From edewata at redhat.com Mon Jan 30 23:50:37 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 30 Jan 2012 17:50:37 -0600 Subject: [Freeipa-devel] [PATCH] [WIP] 069 Added refresh button for UI In-Reply-To: <4F159563.1050109@redhat.com> References: <4F142E12.9000009@redhat.com> <4F159563.1050109@redhat.com> Message-ID: <4F272CCD.3070601@redhat.com> On 1/17/2012 9:36 AM, Endi Sukma Dewata wrote: > On 1/16/2012 8:02 AM, Petr Vobornik wrote: >> 1) Button position: >> I added the button into facet header next to 'add', 'delete', 'reset', >> 'update' buttons as shown on the picture ( >> http://pvoborni.fedorapeople.org/images/2051-refresh-button.png ). I'm >> not sure if it's the right position. I can also imagine it somewhere in >> the page header - in the green area on the right on the top main menu >> (Identity, Policy...) level. > > I think it's the right place, but UXD might have some idea about the > button order. > >> 2) Button icon: >> I used reset button icon. This is not good because in details facet >> reset and refresh button have the same icon. >> I think this icon is more suitable for refresh button and reset button >> should get new icon (maybe with reverse direction of the arrow). >> >> Probably we should ask UXD for opinion and icon. > > Yeah, maybe the Reset button probably should look like an Undo button: > http://www.iconarchive.com/show/must-have-icons-by-visualpharm/Undo-icon.html > > The code is ACKed, feel free to push after feedback from UXD. OK'd by Kyle in ticket #2051. Pushed to master and ipa-2-2. One more issue, in the details page the Refresh and Reset buttons are actually doing a similar thing. They both cancel unsaved changes in the page, but the difference is the Reset button will show the values originally loaded when you open the page (which might be stale) whereas the Refresh button will reload the latest values from the server. So I think we can remove the Refresh button from the details page and modify the Reset button to do a refresh. We can leave the Undo buttons as is. This way we don't need a new icon for Refresh. What do you think? -- Endi S. Dewata From edewata at redhat.com Tue Jan 31 00:09:39 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 30 Jan 2012 18:09:39 -0600 Subject: [Freeipa-devel] [PATCH] 070 Modifying DNS UI to benefit from new DNS API In-Reply-To: <4F22B9EE.1000204@redhat.com> References: <4F1D84DA.30802@redhat.com> <4F1F0EAA.6090908@redhat.com> <4F22B9EE.1000204@redhat.com> Message-ID: <4F273143.1080504@redhat.com> On 1/27/2012 8:51 AM, Petr Vobornik wrote: > Updated patch attached. ACK and pushed to master and ipa-2-2. See also the comments below. >> 5. The following attributes probably should be shown as text areas in >> the edit dialog and should not be displayed in the table because it >> could be too long: >> * cert_part_certificate_or_crl >> * ds_part_digest >> * key_part_public_key >> * sig_part_signature >> * rrsig_part_signature >> * sshfp_part_fingerprint > > Fixed. The sig_part_signature and rrsig_part_signature actually still appear in the table since we're showing the raw data but I think we can deal with it later once we decide which columns to show in the table. Another possibility, instead of hiding these fields we can also show just the first few characters. >> 7. The record type header (e.g. A record) on the left of the table >> probably can be moved above the table to allow wider table. For >> comparison, in HBAC/sudo rule details page the tables occupy the entire >> width of the page. > > Maybe. I will wait for Kyle's review (WWKR). In this implementation the > table is too narrow, if we moved the headers and extend the table the > space for one type will be too height a user will have to scroll a lot. > Both are not ideal. OK'd by Kyle in ticket #2208. Let's leave it as is for now. One thing though, in HBAC/sudo rules the Add/Delete buttons occupy the same box as the last column header. In the DNS records page the buttons occupy a separate box. This can be fixed later. >> 9. The Edit links in the tables could be replaced with icons. Another >> option is to convert the record values into links which will open the >> dialog. > > I agree. WWKR Kyle said links are OK for now. >>> 2) hide empty tables (as I suggested in ticket description) >> >> OK. We probably can move the Add and Delete buttons next to the type >> header and keep it there even when the table is visible. > > WWKR Same reason, leaving it as is. Additional improvements: 13. In the details page the title of the Add/Delete/Edit dialogs could be modified to mention the record type. 14. The IPA.dns.record_metadata is lazily initialized in get_record_metadata(). I suppose this is because the validators are dependent on the metadata loaded from the server. However, being a standalone function, it doesn't prevent someone from calling get_record_metadata() too early and still get an error. We might be able to address this by moving the initialization into IPA.dns.record_entity.init() because it's guaranteed to be called after entity creation which will only happen after loading the metadata. 15. Currently when calling IPA.dns.get_record_type() you'd have to append the 'record' manually. The function can be modified to take the record type only, then internally append the 'record' prefix to find the metadata for that type. 16. Existing issue: some parameters in the specs (e.g. validators, policies, formats) are objects instead of the class/factory. For example: factory: IPA.dnszone_adder_dialog, policies: [ IPA.dnsrecord_adder_dialog_type_policy({ type_field: 'record_type' }) ] Compare it with: factory: IPA.dnszone_adder_dialog, policies: [ { factory: IPA.dnsrecord_adder_dialog_type_policy, type_field: 'record_type' } ] This is not an issue now, but if we want to make the spec more declarative (see ticket #2052) I think we should avoid executing a code in order to construct the spec. We also still need to figure out how to handle messages and dynamic specs properly (see user.js:35-36). Suppose we have a fully declarative spec we can move the spec out of the entity class (and maybe into a separate json file) to simplify UI customization, but I'm still not sure if it's possible due to the dynamic nature of the UI. Suppose it's not possible, we might as well create the objects directly instead of using 2 stages (spec -> object): that.adder_dialog(IPA.dnszone_adder_dialog({ policies: [ IPA.dnsrecord_adder_dialog_type_policy({ type_field: 'record_type' }) ] }); 17. The code in dns.js:1751,1759 could be replaced with callback functions supplied by the facet. var widget = ... get the table widget ... widget.remove_on_success(function(data, text_status, xhr) { that.load(data); // load facet }); widget.remove_on_error(function(xhr, text_status, error_thrown) { that.refresh(); // load facet }); -- Endi S. Dewata From mkosek at redhat.com Tue Jan 31 09:02:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 31 Jan 2012 10:02:39 +0100 Subject: [Freeipa-devel] [PATCH] 202 Add reverse DNS record when forward is created In-Reply-To: <4F26CAC3.5000804@redhat.com> References: <1327499671.19882.4.camel@balmora.brq.redhat.com> <4F26CAC3.5000804@redhat.com> Message-ID: <1328000559.13977.11.camel@balmora.brq.redhat.com> On Mon, 2012-01-30 at 11:52 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > Adding reverse DNS record may be a time consuming task, especially > > for IPv6 addresses. Having a way to automatically create a reverse > > record when a forward record is created could speed up the process. > > host-add command already has this possibility. > > > > This patch takes advantage of the new per-type API and adds new > > options for A/AAAA record types: --a-create-reverse and > > --aaaa-create-reverse. These commands can be used to automatically > > create reverse records for new A/AAAA addresses (both forward > > and reverse zones need to be managed by FreeIPA server): > > > > ipa dnsrecord-add example.com foo --a-rec=10.0.0.1 --a-create-reverse > > > > This command would add a new A record to record foo in zone > > example.com and a PTR record to appropriate reverse zone for > > IP address 10.0.0.1 (for example PTR record 1 in zone > > 0.0.10.in-addr.arpa. pointing to foo.example.com.). > > > > Few modification were done to new DNS API to support this feature: > > - Refactor --ip-address option handling from host-add and place it > > to dns.py to be used by both modules > > - Add support for "extra" per-type options > > - Hide DNS record part options in dnsrecord_find command as they > > have no effect for this command > > > > https://fedorahosted.org/freeipa/ticket/2009 > > Can the options -a-create-reverse and -aaaa-create-reverse be combined? > I was able to create an IPv4 addr using -aaaa-create-reverse: > > # ipa dnsrecord-add example.com baz --a-rec=192.168.166.115 > --aaaa-create-reverse > Record name: baz > A record: 192.168.166.115 > > Otherwise the patch seems fine. These 2 options can be combined, you can add both A and AAAA forward records and create records in their reverse records at the same time: ipa dnsrecord-add example.com bar --a-rec=10.0.0.1 --a-create-reverse --aaaa-rec=2001::beef:1 --aaaa-create-reverse In your case the option --aaaa-create-reverse is ignored as there is no AAAA rec added. Thus no AAAA record callback which would create this reverse record is called. We may implement some checks which would throw a validation error when --a-create-reverse/--aaaa-create-reverse is called without a respective A/AAAA record. Martin From sbose at redhat.com Tue Jan 31 11:45:31 2012 From: sbose at redhat.com (Sumit Bose) Date: Tue, 31 Jan 2012 12:45:31 +0100 Subject: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3 Message-ID: <20120131114531.GD28503@localhost.localdomain> Hi, for the IPAv3 trust feature we have to add the objectclass ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be visible on the Windows side of the trust. The only MUST attribute of both objectclasses is ipaNTSecurityIdentifier the SID or the user or group. We would like to manage the SIDS with the DNA plugin since they have to be unique in the IPA domain. The trust support will typically be added to a running IPA domain, because we do not plan to install it by default and we have to consider updated v2 environments as well. So the question arises what is the most preferred way to add a DNA configuration to an existing Directory Server setup with replication. Nathan suggested to create the configuration with the full range on the first master, configure the other master with no available values and let the DNA plugin transfer the ranges between the masters. This will lead to the following steps: 1. Check if there are already shared configuration entries in cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 2a. if not we can create the initial configuration on the current master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1000 dnaMaxValue: eval($SIDMAX) # Maybe 200k ? dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with ipaNTSecurityIdentifier=999 on the current master 4a. Done on the first master 2b. if there are already entries we can create the configuration for an additional master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3b. Done on the additional master, DNA plugin will sort out the rest Do these steps make sense? Is it necessary to add a lock to prevent a race condition btween step 1 and 2a, i.e. two admins try to prepare IPA for trusts independently at the same time? Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on the first master, the range on the second master will start at 2^31? So the usage of the full range will be quite sparse if dnaMaxValue is set too high. Step 3a on the first master might need some time to finish. Is it necessary to set some kind of lock to prevent the configuration of the DNA plugin on other masters while this task is running or is it safe to add another master at any time? Are there other ways to introduce the DNA configuration? Nathan suggested also that the ranges can be configured manually without overlap, but if possible I would prefer the automatic way. Thank you for your help. bye, Sumit From pvoborni at redhat.com Tue Jan 31 13:01:28 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 Jan 2012 14:01:28 +0100 Subject: [Freeipa-devel] [PATCH] 070 Modifying DNS UI to benefit from new DNS API In-Reply-To: <4F273143.1080504@redhat.com> References: <4F1D84DA.30802@redhat.com> <4F1F0EAA.6090908@redhat.com> <4F22B9EE.1000204@redhat.com> <4F273143.1080504@redhat.com> Message-ID: <4F27E628.4000702@redhat.com> On 01/31/2012 01:09 AM, Endi Sukma Dewata wrote: > On 1/27/2012 8:51 AM, Petr Vobornik wrote: >> Updated patch attached. > > ACK and pushed to master and ipa-2-2. See also the comments below. > >>> 5. The following attributes probably should be shown as text areas in >>> the edit dialog and should not be displayed in the table because it >>> could be too long: >>> * cert_part_certificate_or_crl >>> * ds_part_digest >>> * key_part_public_key >>> * sig_part_signature >>> * rrsig_part_signature >>> * sshfp_part_fingerprint >> >> Fixed. > > The sig_part_signature and rrsig_part_signature actually still appear in > the table since we're showing the raw data but I think we can deal with > it later once we decide which columns to show in the table. > > Another possibility, instead of hiding these fields we can also show > just the first few characters. Yes, some right combinations of columns possibly with custom formatters. In this case some future user feedback would be nice. > >>> 7. The record type header (e.g. A record) on the left of the table >>> probably can be moved above the table to allow wider table. For >>> comparison, in HBAC/sudo rule details page the tables occupy the entire >>> width of the page. >> >> Maybe. I will wait for Kyle's review (WWKR). In this implementation the >> table is too narrow, if we moved the headers and extend the table the >> space for one type will be too height a user will have to scroll a lot. >> Both are not ideal. > > OK'd by Kyle in ticket #2208. Let's leave it as is for now. > > One thing though, in HBAC/sudo rules the Add/Delete buttons occupy the > same box as the last column header. In the DNS records page the buttons > occupy a separate box. This can be fixed later. The buttons are in last column which doesn't have a label because it doesn't need it - the column contains edit links. So it is consistent. It would change automatically if we decide to remove/change the edit link -> remove the column itself. The only thing I don't like on the buttons is that they have slightly different vertical alignment than the rest of the labels - existing issue. And that they have too wide left padding/margin/cell-space. > Additional improvements: > > 13. In the details page the title of the Add/Delete/Edit dialogs could > be modified to mention the record type. Yeah, I was lazy. > > 14. The IPA.dns.record_metadata is lazily initialized in > get_record_metadata(). I suppose this is because the validators are > dependent on the metadata loaded from the server. However, being a > standalone function, it doesn't prevent someone from calling > get_record_metadata() too early and still get an error. > > We might be able to address this by moving the initialization into > IPA.dns.record_entity.init() because it's guaranteed to be called after > entity creation which will only happen after loading the metadata. I don't see it as a big problem. The only thing which would change is that the caller would get null object instead of raising some exception. In both cases the call would have to be postponed after initialization. Sometimes I see exception as a better way because it is screaming: "You are doing something bad/too early...". In init it would be called each time users uses the UI and it would have bigger indentation. > > 15. Currently when calling IPA.dns.get_record_type() you'd have to > append the 'record' manually. The function can be modified to take the > record type only, then internally append the 'record' prefix to find the > metadata for that type. Agree. Also other parts may benefit from some kind of normalization of record name - on various parts are used different representations subsequent transformations: ie -'A' -> 'a' -> 'arecord'. > > 16. Existing issue: some parameters in the specs (e.g. validators, > policies, formats) are objects instead of the class/factory. For example: > > factory: IPA.dnszone_adder_dialog, > policies: [ > IPA.dnsrecord_adder_dialog_type_policy({ > type_field: 'record_type' > }) > ] > > Compare it with: > > factory: IPA.dnszone_adder_dialog, > policies: [ > { > factory: IPA.dnsrecord_adder_dialog_type_policy, > type_field: 'record_type' > } > ] > > This is not an issue now, but if we want to make the spec more > declarative (see ticket #2052) I think we should avoid executing a code > in order to construct the spec. We also still need to figure out how to > handle messages and dynamic specs properly (see user.js:35-36). > > Suppose we have a fully declarative spec we can move the spec out of the > entity class (and maybe into a separate json file) to simplify UI > customization, but I'm still not sure if it's possible due to the > dynamic nature of the UI. Suppose it's not possible, we might as well > create the objects directly instead of using 2 stages (spec -> object): > > that.adder_dialog(IPA.dnszone_adder_dialog({ > policies: [ > IPA.dnsrecord_adder_dialog_type_policy({ > type_field: 'record_type' > }) > ] > }); Totally agree. I was thinking about doing it, but I postponed it. It may be also beneficial for columns and their formatter definitions. I'm thinking about some generic collection with integrated builder which can initialize itself by the spec object. > > 17. The code in dns.js:1751,1759 could be replaced with callback > functions supplied by the facet. > > var widget = ... get the table widget ... > widget.remove_on_success(function(data, text_status, xhr) { > that.load(data); // load facet > }); > widget.remove_on_error(function(xhr, text_status, error_thrown) { > that.refresh(); // load facet > }); > For automember I'm creating a more generic table widget with capabilities of adding/removing of entries. Basically it is the dns record table stripped of DNS stuff and with some new override points. The plan is that this widget should be a base class for dns recored table, association table and automember condition table and maybe also for options in hbac rules. I may implement it there. -- Petr Vobornik From pvoborni at redhat.com Tue Jan 31 13:10:17 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 Jan 2012 14:10:17 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 069 Added refresh button for UI In-Reply-To: <4F272CCD.3070601@redhat.com> References: <4F142E12.9000009@redhat.com> <4F159563.1050109@redhat.com> <4F272CCD.3070601@redhat.com> Message-ID: <4F27E839.1000703@redhat.com> On 01/31/2012 12:50 AM, Endi Sukma Dewata wrote: > > OK'd by Kyle in ticket #2051. Pushed to master and ipa-2-2. > > One more issue, in the details page the Refresh and Reset buttons are > actually doing a similar thing. They both cancel unsaved changes in the > page, but the difference is the Reset button will show the values > originally loaded when you open the page (which might be stale) whereas > the Refresh button will reload the latest values from the server. So I > think we can remove the Refresh button from the details page and modify > the Reset button to do a refresh. We can leave the Undo buttons as is. > This way we don't need a new icon for Refresh. What do you think? > It is a possible solution. I agree that users can be confused what is the difference between them. With low latency and quick line they may appear similar. I wonder if someone is using the reset button at all. So I'm not opposed to it. -- Petr Vobornik From ohamada at redhat.com Tue Jan 31 14:25:24 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Tue, 31 Jan 2012 15:25:24 +0100 Subject: [Freeipa-devel] [PATCH] 10 --no-reverse option in ipa-replica-install is not honoured In-Reply-To: <4F210DD4.4020500@redhat.com> References: <4F2032EF.9010409@redhat.com> <4F210DD4.4020500@redhat.com> Message-ID: <4F27F9D4.7060005@redhat.com> On 01/26/2012 09:24 AM, Jan Cholasta wrote: > Dne 25.1.2012 17:50, Ondrej Hamada napsal(a): >> https://fedorahosted.org/freeipa/ticket/2161 >> >> The option '--no-reverse' was not honoured in replica-install because of >> wrongly placed condition checking. >> > > NACK > > The --no-reverse options means "do not create new reverse zone if > there is no existing suitable reverse zone". Your patch changes the > semantics of the option to "do not use any reverse zone". > > One problem I see is that the name of the option is misleading. It > should probably be changed to "--no-new-reverse". > > Anyway, the ticket should IMO be closed as invalid. It is a case of > people not reading documentation and then being surprised why things > don't work the way they assumed. > > Honza > According to discussion with jgalipea and rcrit: the option will stay as it is, just the manpages and documentation will be updated. This patch patches the option descriptions in code and in manpages. For documentation update was created a new ticket: https://fedorahosted.org/freeipa/ticket/2330 -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-10-1-Fix-no-reverse-option-description.patch Type: text/x-patch Size: 3860 bytes Desc: not available URL: From jdennis at redhat.com Tue Jan 31 14:35:22 2012 From: jdennis at redhat.com (John Dennis) Date: Tue, 31 Jan 2012 09:35:22 -0500 Subject: [Freeipa-devel] session authentication issues Message-ID: <4F27FC2A.7000008@redhat.com> Good news, bad news. I had mistakenly believed the session authentication was working properly, but it's not. The good news is that the session code seems to work flawlessly and has for a while. The bad news is that the approach we took with using redirects to a login url seems to be fundamentally flawed. Also the introduction of S4U2proxy has changed some assumptions about what we see in the Kerberos ccache on the server (but this should be easy to address). I'll try to be brief (I know not my usual :-) The fundamental problem is that using redirects cause the POST data to be lost. This was a bit tricky to diagnose because using Firebug on the browser didn't show the redirect activity and because so much on the client side happens in javascript code. And on the server we don't have a way to show the complete HTTP request, just what handlers it hits and the HTTP headers the handlers see. So from both the browser and server perspective it appeared the redirects were working as expected, but there wasn't enough information to (easily) see where things were going astray. The diagnosis was further complicated by the fact the problem would clear itself on the next request (after credentials had been established eliminating the need for a redirect). Simple explanation: A redirect seen by XMLHttpRequest (i.e. Ajax) causes a POST to be converted to a GET. The web UI uses Ajax to send POST (wrapped by JQerry). Using a redirect breaks our whole RPC mechanism. More detail: (skip to Bottom line simple summary if don't want the details) XMLHttpRequest appears to be somewhat underspecified, this is compounded by XMLHttpRequest implementation differences in different browsers. As best as I can understand at the moment Javascript does not implement XMLHttpRequest in native Javascript using networking primitives, rather it's leverages the XMLHttpRequest implmentation in the browser, thus it's at the mercy of the browser implementation. The HTTP protocol also specifies certain behavior with respect to redirects for security reasons. You're not supposed to send POST data to another server on a redirect unless the user is prompted and OK's the re-transmission. But Ajax operates a layer below and is not in a good position to prompt the user, nor would that necessarily be desired behavior from Javascript code. This page gives some good explanations and provides Javascript test code to see how compliant your browser is: http://www.mnot.net/javascript/xmlhttprequest/ One might think that the decision to convert from POST to GET on a redirect would be governed by whether the new URL was located on the same origin server as the original URL (the idea is to avoid sending POST data to a different server), but apparently thats not how it works, the mere fact it's a redirect triggers the conversion (is this XMLHttpRequest implementation specific??) What happens with F16 Firefox is the original post to /ipa/json gets redirected to /ipa/login as a GET (because Firefox won't send POST during a redirect). Then /ipa/login redirect again after obtaining credentials back to the original /ipa/json, but what arrives at the RPC interface is a GET not a post (again due to redirects). The POST data has been lost. As best I can tell all this is happening inside Firefox's XMLHttpRequest implementation and the Javascript making the Ajax call never sees it (not 100% sure about this though). Thus our Javascript code thinks it sent something it never actually did. The RPC code on the server doesn't complain it received a GET instead of a POST, instead it tries to read the RPC data from query parameters on the URL. It fails to find RPC data and sends an IPA error back stating the command is unknown. From an Ajax/HTTP perspective this was 100% successful, it got back a good response, that we later interpret as an IPA error and put up a dialog box. Then our Javascript issues the next RPC, none of the redirects occur and everything works wonderfully. The fact the redirects are occurring in the XMLHttpRequest layer also seems to induce another undesirable behavior. Despite the fact we send back a session cookie on the first request that session cookie is not sent back in the subsequent redirects. Each time one of the redirects hits the server we allocate a new session because we think none exists yet. Thus for the first request we end up creating two sessions that will never be used (they will eventually get purged but it's not optimal). Bottom line simple summary: We tried to hide the new authentication mechanism behind clever redirects so our existing code would be ignorant of it, instead everything would happen at the HTTP protocol level and from the perspective of the web UI code nothing would be different. But Ajax does not have consistent behavior with redirects across implementations, even if one version of Firefox did what we wanted it would probably break on another browser. Also, it doesn't appears as if there are enough hooks in the XMLHttpRequest and Javascript implementations to hook the redirect and modify behavior. I don't think the designers of XMLHttpRequest anticipated this, not 100% sure though. Thus I don't think we can hide the new authentication mechanism at the HTTP protocol level. I believe instead we have to handle this inside our RPC layer. If we issue an RPC and get a IPA error back stating we need credentials we will need to send a (synchronous) Ajax request to the /ipa/login URL to obtain credentials and store them in the session. If that succeeds we need to resubmit the exact same RPC call that previously failed. This also would have the nice benefit of not creating empty unused sessions during redirects. S4U2proxy issue: My implementation would check the validity of the TGT if the session contained a Kerberos ccache for the user and redirect to login if it expired. But with S4U2proxy there is no TGT. But shouldn't we have service ticket for HTTP that should be checked? I'm not sure we do. In the past we've said it's OK for a client to access the RPC URL without Kerberos ticket because we always will need a service ticket for LDAP to process the RPC. I'm not sure the assumption every RPC will touch LDAP is true nor do I believe leaving the RPC URL unsecured is a good practice. Rather I believe the entrance to the RPC needs to be authenticated which can only be done by checking the ccache stored in the session. Kerberos experts feel free to chime in here. Ha, so much for being brief :-) John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Tue Jan 31 14:38:30 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 31 Jan 2012 15:38:30 +0100 Subject: [Freeipa-devel] [PATCH] 203 Add argument help to CLI In-Reply-To: <4F26C3B8.4090702@redhat.com> References: <1327679816.29228.13.camel@balmora.brq.redhat.com> <4F26C3B8.4090702@redhat.com> Message-ID: <1328020710.13977.43.camel@balmora.brq.redhat.com> On Mon, 2012-01-30 at 11:22 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > An example of the improved help: > > > > # ipa help user-add > > Purpose: Add a new user. > > Usage: ipa [global-options] user-add LOGIN [options] > > > > Positional arguments: > > LOGIN: User login > > > > Options: > > -h, --help show this help message and exit > > --first=STR First name > > --last=STR Last name > > --cn=STR Full name > > ... > > > > > > We may want to improve help for most arguments we use. Most of them are > > missing. In this patch I updated just the CRITERIA argument that was > > complained about in the relevant BZ. > > > > Martin > > Patch looks ok, I just think the output could be improved. > > I think it should look similar to the existing usage output, so, similar > indention and description columns lined up: > > Usage: ipa [global-options] user-add LOGIN [options] > > Positional arguments: > LOGIN User login > > Options: > -h, --help show this help message and exit > > rob I agree. I refactored the patch to integrate better with OptionParser and rather provide a support of argument help directly instead of misusing description field. New patch adds a formatter capable of formatting arguments consistently with options format (as you proposed). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-203-2-add-argument-help-to-cli.patch Type: text/x-patch Size: 5799 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 31 14:54:43 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 31 Jan 2012 08:54:43 -0600 Subject: [Freeipa-devel] [PATCH] 071 Added paging to DNS record search facet In-Reply-To: <4F1EC599.20302@redhat.com> References: <4F1EC599.20302@redhat.com> Message-ID: <4F2800B3.7030803@redhat.com> On 1/24/2012 8:52 AM, Petr Vobornik wrote: > Patch Description: > Paging in DNS record search facet was disabled because there was a > mismatch between primary keys sent by server and values displayed in the > facet. > > The facet was modified to enable paging. To preserve amount of > information which was displayed before, current rows have variable > height - they can contain more that one line depending on number of > values in the record. Each record has a checkbox and indsname in its > first line to distinguish one record from others. Because there is only > one checkbox for record, delete command is called with --del-all option > which causes that entire record is removed. Individual values can be > deleted in record's details facet. > > https://fedorahosted.org/freeipa/ticket/2094 ACK. OK'd by Kyle too. Pushed to master and ipa-2-2. Just one comment, the new deleter_dialog parameter for the search facet might not be necessary. The DNS record deleter dialog could be added into the DNS record entity like in host.js:161. The nested DNS record search facet has a managed_entity which points to the DNS record entity. The facet will be able to find the deleter dialog using the managed_entity in search.js:146. Another possibility is to move the nested search facet into the DNS record entity itself. -- Endi S. Dewata From edewata at redhat.com Tue Jan 31 14:54:52 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 31 Jan 2012 08:54:52 -0600 Subject: [Freeipa-devel] [PATCH] Fixed host managed-by adder dialog. In-Reply-To: <4F265C45.4090301@redhat.com> References: <4F218075.8020104@redhat.com> <4F265C45.4090301@redhat.com> Message-ID: <4F2800BC.1060004@redhat.com> On 1/30/2012 3:00 AM, Petr Vobornik wrote: > On 01/26/2012 05:33 PM, Endi Sukma Dewata wrote: >> The host managed-by adder dialog has been fixed to use the new >> --not-man-hosts option to filter out hosts that are already added. >> >> Ticket #1675 > > ACK Pushed to master and ipa-2-2. -- Endi S. Dewata From pvoborni at redhat.com Tue Jan 31 15:33:03 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 31 Jan 2012 16:33:03 +0100 Subject: [Freeipa-devel] [PATCH] 073 Automember UI Message-ID: <4F2809AF.1090108@redhat.com> New UI for automember. Implemented: * search facet core * rule details facet * attribute_table_widget - new base class for tables which contains multivalued attribute with special add/remove commands * adding/removing conditions in details facet TODO (will follow): * label translations * UI for defining default rules Note: depends on my patch #72 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0073-Automember-UI.patch Type: text/x-patch Size: 39790 bytes Desc: not available URL: From simo at redhat.com Tue Jan 31 15:47:59 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Jan 2012 10:47:59 -0500 Subject: [Freeipa-devel] session authentication issues In-Reply-To: <4F27FC2A.7000008@redhat.com> References: <4F27FC2A.7000008@redhat.com> Message-ID: <1328024879.13963.272.camel@willson.li.ssimo.org> On Tue, 2012-01-31 at 09:35 -0500, John Dennis wrote: > Good news, bad news. I had mistakenly believed the session > authentication was working properly, but it's not. The good news is that > the session code seems to work flawlessly and has for a while. The bad > news is that the approach we took with using redirects to a login url > seems to be fundamentally flawed. Also the introduction of S4U2proxy has > changed some assumptions about what we see in the Kerberos ccache on the > server (but this should be easy to address). > > I'll try to be brief (I know not my usual :-) > > The fundamental problem is that using redirects cause the POST data to > be lost. This was a bit tricky to diagnose because using Firebug on the > browser didn't show the redirect activity and because so much on the > client side happens in javascript code. And on the server we don't have > a way to show the complete HTTP request, just what handlers it hits and > the HTTP headers the handlers see. So from both the browser and server > perspective it appeared the redirects were working as expected, but > there wasn't enough information to (easily) see where things were going > astray. The diagnosis was further complicated by the fact the problem > would clear itself on the next request (after credentials had been > established eliminating the need for a redirect). > > Simple explanation: > > A redirect seen by XMLHttpRequest (i.e. Ajax) causes a POST to be > converted to a GET. > > The web UI uses Ajax to send POST (wrapped by JQerry). Using a redirect > breaks our whole RPC mechanism. > > More detail: > > (skip to Bottom line simple summary if don't want the details) > > XMLHttpRequest appears to be somewhat underspecified, this is compounded > by XMLHttpRequest implementation differences in different browsers. As > best as I can understand at the moment Javascript does not implement > XMLHttpRequest in native Javascript using networking primitives, rather > it's leverages the XMLHttpRequest implmentation in the browser, thus > it's at the mercy of the browser implementation. > > The HTTP protocol also specifies certain behavior with respect to > redirects for security reasons. You're not supposed to send POST data to > another server on a redirect unless the user is prompted and OK's the > re-transmission. But Ajax operates a layer below and is not in a good > position to prompt the user, nor would that necessarily be desired > behavior from Javascript code. > > This page gives some good explanations and provides Javascript test code > to see how compliant your browser is: > http://www.mnot.net/javascript/xmlhttprequest/ > > One might think that the decision to convert from POST to GET on a > redirect would be governed by whether the new URL was located on the > same origin server as the original URL (the idea is to avoid sending > POST data to a different server), but apparently thats not how it works, > the mere fact it's a redirect triggers the conversion (is this > XMLHttpRequest implementation specific??) > > What happens with F16 Firefox is the original post to /ipa/json gets > redirected to /ipa/login as a GET (because Firefox won't send POST > during a redirect). I am a bit confused, you repeat a couple of times that the POST is translated into a GET, but you do not say what data is sent in this GET ? > Then /ipa/login redirect again after obtaining > credentials back to the original /ipa/json, but what arrives at the RPC > interface is a GET not a post (again due to redirects). The POST data > has been lost. As best I can tell all this is happening inside Firefox's > XMLHttpRequest implementation and the Javascript making the Ajax call > never sees it (not 100% sure about this though). Thus our Javascript > code thinks it sent something it never actually did. > > The RPC code on the server doesn't complain it received a GET instead of > a POST, instead it tries to read the RPC data from query parameters on > the URL. It fails to find RPC data and sends an IPA error back stating > the command is unknown. From an Ajax/HTTP perspective this was 100% > successful, it got back a good response, that we later interpret as an > IPA error and put up a dialog box. Then our Javascript issues the next > RPC, none of the redirects occur and everything works wonderfully. > > The fact the redirects are occurring in the XMLHttpRequest layer also > seems to induce another undesirable behavior. Despite the fact we send > back a session cookie on the first request that session cookie is not > sent back in the subsequent redirects. Each time one of the redirects > hits the server we allocate a new session because we think none exists > yet. Thus for the first request we end up creating two sessions that > will never be used (they will eventually get purged but it's not optimal). I am a bit surprised here. Shouldn't we create a session only once Negotiate auth is completed and we know the user is authenticated ? If so where do the other sessions come from ? > Bottom line simple summary: > > We tried to hide the new authentication mechanism behind clever > redirects so our existing code would be ignorant of it, instead > everything would happen at the HTTP protocol level and from the > perspective of the web UI code nothing would be different. > > But Ajax does not have consistent behavior with redirects across > implementations, even if one version of Firefox did what we wanted it > would probably break on another browser. > > Also, it doesn't appears as if there are enough hooks in the > XMLHttpRequest and Javascript implementations to hook the redirect and > modify behavior. I don't think the designers of XMLHttpRequest > anticipated this, not 100% sure though. > > Thus I don't think we can hide the new authentication mechanism at the > HTTP protocol level. We could, but we'd need to handle sessions in conjuction with mod_auth_kerb like Adam proposed a while back. By integrating them we could avoid redirects in the xmlrpc case by handling negotiate only when a valid session is not available. But there is another problem here, that still makes this solution not good enough. The completely transparent redirect method is only ok when the browser do have valid credentials. But when the browser doesn't and form based auth is used we are back to square zero. > I believe instead we have to handle this inside our RPC layer. If we > issue an RPC and get a IPA error back stating we need credentials we > will need to send a (synchronous) Ajax request to the /ipa/login URL to > obtain credentials and store them in the session. If that succeeds we > need to resubmit the exact same RPC call that previously failed. This > also would have the nice benefit of not creating empty unused sessions > during redirects. Yes I think for the json endpoint this is what we need to do, because the ajax application needs to be aware it may have to not only give an error, but to actually cause the whole page to refresh and point to /ipa/login in order to potentially perform non-negotiate auth. > S4U2proxy issue: > > My implementation would check the validity of the TGT if the session > contained a Kerberos ccache for the user and redirect to login if it > expired. But with S4U2proxy there is no TGT. But shouldn't we have > service ticket for HTTP that should be checked? I'm not sure we do. In > the past we've said it's OK for a client to access the RPC URL without > Kerberos ticket because we always will need a service ticket for LDAP to > process the RPC. I'm not sure the assumption every RPC will touch LDAP > is true nor do I believe leaving the RPC URL unsecured is a good > practice. Rather I believe the entrance to the RPC needs to be > authenticated which can only be done by checking the ccache stored in > the session. Kerberos experts feel free to chime in here. In the s4u2proxy case you do not have the TGT but you still have an evidence ticket you can use (the HTTP ticket) in the ccache. > Ha, so much for being brief :-) Great report as usual. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Tue Jan 31 16:29:24 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 31 Jan 2012 10:29:24 -0600 Subject: [Freeipa-devel] [PATCH] 344 Added icons for status column. Message-ID: <4F2816E4.5020803@redhat.com> The status formatter was modified to show enabled/disabled icon before the status text. The format classes were renamed to formatter to avoid confusion with the format() method. A new parameter 'type' was added to the formatter to determine the output type (e.g. text/html). Ticket #1996 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0344-Added-icons-for-status-column.patch Type: text/x-patch Size: 12126 bytes Desc: not available URL: From mkosek at redhat.com Tue Jan 31 17:41:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 31 Jan 2012 18:41:09 +0100 Subject: [Freeipa-devel] [PATCH] 933 %ghost some UI files In-Reply-To: <4F26E732.6010300@redhat.com> References: <4F21A55E.2000102@redhat.com> <1327658324.30921.4.camel@balmora.brq.redhat.com> <4F22B3FD.8070208@redhat.com> <1327918012.4985.4.camel@balmora.brq.redhat.com> <4F26E732.6010300@redhat.com> Message-ID: <1328031669.13977.49.camel@balmora.brq.redhat.com> On Mon, 2012-01-30 at 13:53 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2012-01-27 at 09:26 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Thu, 2012-01-26 at 14:11 -0500, Rob Crittenden wrote: > >>>> Add a %ghost to some files installed by the UI so that they are owned by > >>>> freeipa-server when the server is installed and they will be removed by > >>>> rpm when the package is removed. > >>>> > >>>> rob > >>> > >>> I see you did not add /usr/share/ipa/html/ca.crt to %ghost too. Is this > >>> intentional? We may want to keep ca.crt intact when freeipa package is > >>> uninstalled... > >>> > >>> This a list of files in /usr/share/ipa/ that we do not own: > >>> file /usr/share/ipa/html/krb.con is not owned by any package > >>> file /usr/share/ipa/html/preferences.html is not owned by any package > >>> file /usr/share/ipa/html/configure.jar is not owned by any package > >>> file /usr/share/ipa/html/krbrealm.con is not owned by any package > >>>>> file /usr/share/ipa/html/ca.crt is not owned by any package > >>> file /usr/share/ipa/html/krb5.ini is not owned by any package > >>> > >>> Martin > >>> > >> > >> This was my thinking exactly. > >> > >> Right now if you uninstall the rpms and re-install them then (at least > >> apparently) the server continues to work. > >> > >> I might be talked into adding a config(noreplace) if we want this at > >> least owned by the package. > > > > I think it would be a good idea. We already own for example default.conf > > with config(noreplace) which is also generated during installation. > > > > There 2 ca.crt's to manage this way: > > /usr/share/ipa/html/ca.crt > > /etc/ipa/ca.crt > > > > Martin > > > > Ok, added both of these. > > rob ACK. Pushed to master, ipa-2-2. (There was a small rebase for master). Martin From edewata at redhat.com Tue Jan 31 17:50:33 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 31 Jan 2012 11:50:33 -0600 Subject: [Freeipa-devel] [PATCH] 345 Hide Add/Delete buttons in self-service mode. Message-ID: <4F2829E9.2070409@redhat.com> Users do not have add/delete permission in self-service mode, so the search facet was modified to hide the Add/Delete buttons. Ticket #2188 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0345-Hide-Add-Delete-buttons-in-self-service-mode.patch Type: text/x-patch Size: 1075 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 31 17:51:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 31 Jan 2012 11:51:57 -0600 Subject: [Freeipa-devel] [PATCH] 346 Use fixed font when displaying certificate. Message-ID: <4F282A3D.3020007@redhat.com> The textareas used to display certificates were modified to use fixed font. Ticket #2017 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0346-Use-fixed-font-when-displaying-certificate.patch Type: text/x-patch Size: 3935 bytes Desc: not available URL: From edewata at redhat.com Tue Jan 31 20:45:32 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 31 Jan 2012 14:45:32 -0600 Subject: [Freeipa-devel] [PATCH] 347 Show password expiration date. Message-ID: <4F2852EC.9040908@redhat.com> The user details page was modified to show the password expiration date next to the existing password field. Fixed problem resetting password in self-service mode. The JSON interface for the passwd command requires the username to be specified although the equivalent CLI command doesn't require it. Ticket #2064 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0347-Show-password-expiration-date.patch Type: text/x-patch Size: 10479 bytes Desc: not available URL: From jdennis at redhat.com Tue Jan 31 22:03:28 2012 From: jdennis at redhat.com (John Dennis) Date: Tue, 31 Jan 2012 17:03:28 -0500 Subject: [Freeipa-devel] Fwd: Miroslav we need some policy for IPA back ported to F16 and RHEL6. In-Reply-To: <4F286471.7050601@redhat.com> References: <4F286471.7050601@redhat.com> Message-ID: <4F286530.5040303@redhat.com> FYI, selinux policy for ipa memcached is being worked on ... -------- Original Message -------- Subject: Miroslav we need some policy for IPA back ported to F16 and RHEL6. Date: Tue, 31 Jan 2012 17:00:17 -0500 From: Daniel J Walsh To: Miroslav Grepl CC: John Dennis -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 f322c5c3685ac8e9c3e86c24f63ad78887be7a9b Basically we probably want all of memcached policy and the apache parts of this patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8oZHEACgkQrlYvE4MpobN0GwCfdVdVcasS5zzS64DdpAwHzjUy hpYAoKGuaBAzKxKZp35Y7CbWhbN4iQnB =56bI -----END PGP SIGNATURE-----