From edewata at redhat.com Sat Aug 1 00:56:51 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 31 Jul 2015 19:56:51 -0500 Subject: [Freeipa-devel] [PATCH] 370 Fixed missing KRA agent cert on replica. Message-ID: <55BC1953.4000607@redhat.com> The code that exports the KRA agent certificate has been moved such that it will be executed both on master and replica. https://fedorahosted.org/freeipa/ticket/5174 -- Endi S. Dewata -------------- next part -------------- From 04abaf7354d5c140d2bb88c7a58e54f0691fcbe4 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Sat, 1 Aug 2015 02:46:26 +0200 Subject: [PATCH] Fixed missing KRA agent cert on replica. The code that exports the KRA agent certificate has been moved such that it will be executed both on master and replica. https://fedorahosted.org/freeipa/ticket/5174 --- ipaserver/install/krainstance.py | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index 50ab424b0e59becfea9e7af4b8d43a32ccbdc823..fa50c3dec897d63b9d3522d196054163f7b3369a 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -256,6 +256,15 @@ class KRAInstance(DogtagInstance): os.remove(cfg_file) shutil.move(paths.KRA_BACKUP_KEYS_P12, paths.KRACERT_P12) + + # export ipaCert with private key for client authentication + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--client-cert", paths.KRA_AGENT_PEM] + ipautil.run(args) + self.log.debug("completed creating KRA instance") def __add_ra_user_to_agent_group(self): @@ -330,14 +339,6 @@ class KRAInstance(DogtagInstance): finally: os.remove(filename) - # export ipaCert with private key for client authentication - args = ["/usr/bin/pki", - "-d", paths.HTTPD_ALIAS_DIR, - "-C", paths.ALIAS_PWDFILE_TXT, - "client-cert-show", "ipaCert", - "--client-cert", paths.KRA_AGENT_PEM] - ipautil.run(args) - def __add_vault_container(self): sub_dict = { 'SUFFIX': self.suffix, -- 2.4.3 From mkosek at redhat.com Sun Aug 2 20:08:43 2015 From: mkosek at redhat.com (Martin Kosek) Date: Sun, 2 Aug 2015 22:08:43 +0200 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <55BBA2ED.4050201@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> Message-ID: <55BE78CB.5000307@redhat.com> On 07/31/2015 06:31 PM, Martin Basti wrote: > On 28/07/15 09:52, David Kupka wrote: >> On 27/07/15 16:45, David Kupka wrote: >>> On 15/01/15 17:13, David Kupka wrote: >>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>> >>>>>>>>> Thank you for patch: >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>> - "Failed to connect to server '%s'.", >>>>>>>>> server) >>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>> + except CalledProcessError as e: >>>>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>>> >>>>>>>>> IMO the error message should be more specific, add there something >>>>>>>>> like >>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>> >>>>>>>>> .replace() is not needed >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> + if len(ips) == 0: >>>>>>>>> >>>>>>>>> if not ips: >>>>>>>>> >>>>>>>>> is more pythonic by PEP8 >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>> >>>>>>> merciful NACK >>>>>>> >>>>>>> Thank you for the patch, unfortunately I hit one issue which needs >>>>>>> to be >>>>>>> resolved. >>>>>>> >>>>>>> If "sync PTR" is activated in zone settings, and reverse zone doesn't >>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA records was >>>>>>> succesfully updated, only PTR records failed. >>>>>>> >>>>>>> Bind log: >>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>>>>>> 'vm-101.example.com' AAAA >>>>>>> >>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for A/AAAA >>>>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>> for IP >>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>> >>>>>>> With IPv6 we have several addresses from different reverse zones and >>>>>>> this situation may happen often. >>>>>>> I suggest following: >>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>> fails, >>>>>>> user needs to read log, which addresses installer tried to update) >>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are there >>>>>>> and print proper error message >>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>> particular >>>>>>> IP address. >>>>>>> >>>>>>> Any other suggestions are welcome. >>>>>>> >>>>>> >>>>>> After long discussion with DNS and UX guru I've implemented it this >>>>>> way: >>>>>> 1. Call nsupdate only once with all updates. >>>>>> 2. Verify that the expected records are resolvable. >>>>>> 3. If no print list of missing A/AAAA, list of missing PTR records and >>>>>> list to mismatched PTR record. >>>>>> >>>>>> As this is running inside client we can't much more and it's up to user >>>>>> to check what's rotten in his DNS setup. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> >>>>> One more change to behave well in -crazy- exotic environments that >>>>> resolves more PTR records for single IP. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> Yet another change to make language nerds and our UX guru happy :-) >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>> Rebased patch attached. >>> >>> >> Updated patch attached. >> > Just for record this patch is for dualstack/IPv6 support. > IMO this ticket also requires to fix ipa-join to support IPv6. > > I still have doubts to have multihomed support as default, this may be > unexpected change of ipa-client-install behavior. > I know, is hard to detect which addresses user want to register in IPA without > crystal ball, but it should not be impossible :-) . > > I propose following solution: > > To add new options: > --multihomed or --all-ip-address - all IP addresses from client will be used > --ip-address - adress which will be registered on (IPA) DNS server > --ip-address-interface - interface from which address will be registered > > > 0) without any option specified, current behavior will be used + IPv6 > * detect which address is used to communicate with IPA server > * detect interface where this address belongs > * use ipv4 and all ipv6 addresses of this interface > * if --enable-dns-updates=true: configure SSSD as is configured now: > automatically detect which address is used + patched SSSD will also updates > proper IPv6 address > > 1) --multihomed or --all-ip-addresses (this is multihomed ticket) > * all adresses will be used > * if --enable-dns-updates=true: SSSD will be configured to send all ip_addresses > > 2) --ip-address option specified: > * only specified addresses will be used (+ check if this addresses exist locally) > * if --enable-dns-updates=true: ERROR dynamic updates may change this address > (user should choose static vs dynamic) > > 3) --ip-address-interface option specified: > * only addresses from specified interfaces will be used > * if --enable-dns-updates=true: SSSD will be configured to use these interfaces > to get addresses that will be dynamically updated on dns > > Modification of current patch should not be hard, we already have almost > everything implemented: > * method get_local_addresses should return dict {interface:[list of > addresses]}, this can be used in all of 4 cases. > * restore original function to detect IP address used to communicate with IPA > server > > I insist on 0) and 1), others may be stretch goal (easy to implement) > (It would be shame to not implemented multihomed support together with this > ticket, as it requires max 5 extra lines of code) > > Seems my proposal reasonable? > > What is you opinion Martin? Should we just use all addresses to be registered, > or try to keep old behavior as much as possible? > > Martin^2 To me, keeping the current behavior looks as a safer choice, especially given it seems that there is no CLI that admin could use to achieve the old behavior and only register the address in the FreeIPA server network. From jcholast at redhat.com Mon Aug 3 07:25:21 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 3 Aug 2015 09:25:21 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <1438366844.24296.27.camel@willson.usersys.redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> Message-ID: <55BF1761.4090600@redhat.com> Dne 31.7.2015 v 20:20 Simo Sorce napsal(a): > On Fri, 2015-07-31 at 16:41 +0200, Michael ?im??ek wrote: >> On 2015-07-31 07:52, Jan Cholasta wrote: >>> Hi Michael, >>> >>> Dne 29.7.2015 v 10:09 Michael ?im??ek napsal(a): >>>> Hi, >>>> >>>> this is the first attempt to port FreeIPA from deprecated >>>> python3-incompatible python-krbV library to python-gssapi. The patch >>>> depends on python-kerberos->python-gssapi patch [1] to apply cleanly, >>>> but the overlap is small, so I think it can be at least partially >>>> reviewed without it. >>>> >>>> Comments: >>>> I removed Backend.krb and KRB5_CCache classes as they were wrappers >>>> around krbV classes. I added few utility functions to krb_utils module >>>> that perform part of its functionality (no need for classes, because >>>> gssapi acquire calls don't pass any context objects, they wouldn't have >>>> any state). >>>> >>>> I merged the two different kinit_keytab functions. >>>> >>>> GSSAPI doesn't provide any method (that I'm aware of) to get default >>>> ccache name. In most cases this is not needed as we can simply not pass >>>> any name and it will use the default. The ldap plugin had to be adjusted >>>> for this - the connect method now takes new use_gssapi argument, which >>>> can turn on gssapi support without the need to supply explicit ccache >>>> name. The only place where the ccache name is really needed is the test >>>> server, where I use system klist command to obtain it. >>> >>> I would prefer if the semantics were the same as in IPAdmin, i.e. GSSAPI >>> is used by default if bind password is not specified, see >>> IPAdmin.do_bind() in ipapython.ipaldap. >> >> Just to clarify, the current flow in ldap module is: >> if ccache: # I added "or use_gssapi" here in this patch >> gssapi_bind >> elif autobind: >> external_bind >> else: >> simple_bind > > I had to make this change as well for my replica promotion code, and > incidentally used the same indicator "use_gssapi". > >> and you would like it to be changed into: >> if bind_pw: >> simple_bind >> elif autobind: >> external_bind >> else: >> gssapi_bind >> >> Is that correct? Actually this is what IPAdmin does: def do_bind(self, dm_password="", autobind=AUTOBIND_AUTO, timeout=DEFAULT_TIMEOUT): if dm_password: self.do_simple_bind(bindpw=dm_password, timeout=timeout) return if autobind != AUTOBIND_DISABLED and os.getegid() == 0 and self.ldapi: try: # autobind pw_name = pwd.getpwuid(os.geteuid()).pw_name self.do_external_bind(pw_name, timeout=timeout) return except errors.NotFound, e: if autobind == AUTOBIND_ENABLED: # autobind was required and failed, raise # exception that it failed raise #fall back self.do_sasl_gssapi_bind(timeout=timeout) > > I think this is what Jan wanted, but I am wondering if it is the right > thing to do. In ipa we have basically 2 possible default approaches. > One is to use GSSAPI, and one is to use LDAPI with external bind. > > The latter makes sense mostly only when running as root, so I am > wondering, should the default change depending on whether we are root > and we are connecting to the local LDAP server ? > > If this is a sensible option it means we have to preserver use_gssapi as > we may need to force use of gssapi in some case even when we are root > and connectiong to the local server (for example to test that the local > ccache can successfully be used). > > Jan, > what do you think ? I think GSSAPI should be the default and EXTERNAL should be opt-in, like in IPAdmin, see above. > >>> >>>> >>>> It's also not possible to directly get default realm name, what I do is >>>> importing nonexistent name, cannonicalizing it and extracting the realm >>>> from it. Which should work but is ugly. It would be better if we could >>>> modify the places that use it to not need it at all, but it's mostly >>>> used in ldap code and I don't understand that part of FreeIPA. >>>> Alternative would be parsing /etc/krb.conf. >>> >>> You should use api.env.realm where possible. I think this should be most >>> of the places where default realm is currently used, if not all of them. >> >> That would be great if all the usages could be replaced. How can I >> determine where api.env.realm can be used? In particular, I'm unsure >> about ipapython/config.py/__discover_config and ipaserver/plugins/join.py. I would just remove the code from __discover_config. It is used to get realm name in case it is not configured in /etc/ipa/default.conf, but it is called only from ipa-compat-manage and ipa-nis-manage, which can be run only on IPA server, and IPA server won't work if realm is not configured. As for join.py, you can just return api.env.realm in get_realm(). > > try: > realm = api.env.realm > except: > realm = dirty gssapi trick ? Please don't, you should always be able to choose the correct one instead of guessing. -- Jan Cholasta From mkosek at redhat.com Mon Aug 3 07:31:14 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 3 Aug 2015 09:31:14 +0200 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55BB8F38.1010808@redhat.com> References: <55BB8F38.1010808@redhat.com> Message-ID: <55BF18C2.1010808@redhat.com> On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote: > The CLIs to manage vault owners and members have been modified > to accept services with a new parameter. Due to name conflict, > the existing 'service' parameter has been renamed to > 'servicename'. > > A new ACL has been added to allow a service to create its own > service container. > > https://fedorahosted.org/freeipa/ticket/5172 I did not do a full review, I just saw some of the changes that made me worry - like renaming API command attribute. Wouldn't that make the older clients fail? See for example permission-* commands, we faced similar situation there and had to rename command attributes potentially used by old clients in the new format. From slaznick at redhat.com Mon Aug 3 08:55:07 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Mon, 3 Aug 2015 10:55:07 +0200 Subject: [Freeipa-devel] Time-Based Account Policies Message-ID: <55BF2C6B.3070205@redhat.com> Hi, I have made some changes to the structure of the HBAC time rules extension, namely the code that validates the time rules' strings was moved from the ipalib/parameters to the hbacrule module itself, and a more "fresh" approach was used in code for methods of adding/removing time policies to HBAC rules. A slight change was made to understanding a week in a month. The change follows the Java implementation of a week in a month as suggested by Petr V., given a week starts on Monday (=1; iso 8601). More on that on the previously mentioned link https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html What this change means is that a first week in a month is a week that contains at least 4 days. If it has less days, it's 0-th week (probably better than having it belong to the previous month as some sources also suggest - iso 8601 does not have a definition for a week in month but it has a definition for a week in a year). I had Jan C. check the current implementation of the FreeIPA side for the time-based policies and it seems to work as is. He created official number identifiers for the 2 new LDAP attributeTypes, too. \o/ I was also going through some old mockups for the WebUI Petr V. sent me earlier last month. It brought some questions worth sharing here. 1. Do we need time rules based on the day and week of the year? Currently, there is no such option as dayofyear or weekofyear in the rules language, although adding it should not be that much of a problem. I did not include them as it seemed more convenient to set the data as combinations of dayofmonth and monthofyear values. 2. Should we add dayofyear and weekofyear, a possible need for "intervals" might be required. An "interval" is a behavior from the iCalendar format. It basically functions as range() in Python, although with possible 'infinite' end. Example: should you have a recurrence rule on daily basis with interval=2, a rule would apply on every other day. This is kind of a question of keeping it easy and light or heading a way of robust implementation during which dragons may appear, although with a tiny tiny possibility of a golden treasure in the end. 3. The mockups for HBAC time policies show quite a wizard-like UI. While I might be very wrong here, I was thinking of rather a simple UI where user would be able to set the values for each of the rule keywords (timeofday, dayofweek, ...) directly in some text input fields with possible help of JavaScript, that would add text description to the user input (e.g. "Monday to Friday" with user input "1-5" at the dayofweek input field). 4. Do we want some special settings for "absolute" time policies (policies that start and end at certain time in year)? The issue now would be that some of such rules would have to be broken down in more than one time rule (e.g. rule starting at a certain time of a day in a month in one year and ending at a certain time, day and month of a different year might get broken down to up to 6 rules if I count right). This could actually be solved by a UI wizard-like setting where the user gets to pick the dates and times of the rule, a conversion method would need to be created and such a thing would then work for the CLI, too. Still, usually more than one time rule would be created for such cases. Thanks for keeping up with me and my long emails. I am a terrible person for that and I hope I will be able to cut them short in the future. Cheers, Standa -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0001-Added-time-based-policies-types-to-LDAP-schema.patch Type: text/x-patch Size: 3072 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0002-Added-methods-for-setting-time-based-policies.patch Type: text/x-patch Size: 30759 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0003-Created-basic-UI-for-setting-time-policies-at-HBAC-r.patch Type: text/x-patch Size: 17682 bytes Desc: not available URL: From cheimes at redhat.com Mon Aug 3 09:07:39 2015 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 3 Aug 2015 11:07:39 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <55BBAD13.8020308@redhat.com> References: <55BBAD13.8020308@redhat.com> Message-ID: <55BF2F5B.6000804@redhat.com> On 2015-07-31 19:14, Petr Viktorin wrote: > Hello, > Here is a batch of mostly mechanical changes: removing deprecated > features to prepare for Python 3. Out of curiosity, what tool did you use for patch 695-absolute-imports? Python-modernize adds from __future__ import absolute_imports and changes imports to explicit relative imports. In patch 693 you have removed test cases for CIDict.has_key(), but CIDict still provides the function. You should either keep the tests around or remove has_key() from CIDict. The rest looks good to me, but I haven't studied every change thoroughly. It's just too much. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From cheimes at redhat.com Mon Aug 3 09:22:44 2015 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 3 Aug 2015 11:22:44 +0200 Subject: [Freeipa-devel] [PATCH 022] make-lint Python 3 porting mode Message-ID: <55BF32E4.8020604@redhat.com> Python 3 porting mode for make-lint http://docs.pylint.org/features.html#general-options -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0022-make-lint-Python-3-porting-mode.patch Type: text/x-patch Size: 1418 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From cheimes at redhat.com Mon Aug 3 09:22:55 2015 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 3 Aug 2015 11:22:55 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <1438377255.24296.43.camel@willson.usersys.redhat.com> References: <55BBAD13.8020308@redhat.com> <1438377255.24296.43.camel@willson.usersys.redhat.com> Message-ID: <55BF32EF.8060500@redhat.com> On 2015-07-31 23:14, Simo Sorce wrote: > On Fri, 2015-07-31 at 19:14 +0200, Petr Viktorin wrote: >> Hello, >> Here is a batch of mostly mechanical changes: removing deprecated >> features to prepare for Python 3. >> > > Do we have accompanying lint (or similar) tests that will prevent new > patches from reintroducing py3 incompatible syntax ? pylint has a Python 3 porting mode. That should help, see patch 022. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jcholast at redhat.com Mon Aug 3 09:30:43 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 3 Aug 2015 11:30:43 +0200 Subject: [Freeipa-devel] [PATCH 022] make-lint Python 3 porting mode In-Reply-To: <55BF32E4.8020604@redhat.com> References: <55BF32E4.8020604@redhat.com> Message-ID: <55BF34C3.2000402@redhat.com> Hi, Dne 3.8.2015 v 11:22 Christian Heimes napsal(a): > Python 3 porting mode for make-lint > > http://docs.pylint.org/features.html#general-options I would rather wait until all the modernization patches are pulled in and then make the porting mode enabled by default. If it's optional, no one will use it. Honza -- Jan Cholasta From cheimes at redhat.com Mon Aug 3 09:35:17 2015 From: cheimes at redhat.com (Christian Heimes) Date: Mon, 3 Aug 2015 11:35:17 +0200 Subject: [Freeipa-devel] [PATCH 022] make-lint Python 3 porting mode In-Reply-To: <55BF34C3.2000402@redhat.com> References: <55BF32E4.8020604@redhat.com> <55BF34C3.2000402@redhat.com> Message-ID: <55BF35D5.20307@redhat.com> On 2015-08-03 11:30, Jan Cholasta wrote: > Hi, > > Dne 3.8.2015 v 11:22 Christian Heimes napsal(a): >> Python 3 porting mode for make-lint >> >> http://docs.pylint.org/features.html#general-options > > I would rather wait until all the modernization patches are pulled in > and then make the porting mode enabled by default. If it's optional, no > one will use it. In porting mode the normal checkers aren't executed. In order to enable the porting mode by default, make-lint has to run two passes: one linter instance with and one linter instance without the porting mode. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From abokovoy at redhat.com Mon Aug 3 09:45:34 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Aug 2015 12:45:34 +0300 Subject: [Freeipa-devel] Time-Based Account Policies In-Reply-To: <55BF2C6B.3070205@redhat.com> References: <55BF2C6B.3070205@redhat.com> Message-ID: <20150803094534.GB31709@redhat.com> On Mon, 03 Aug 2015, Stanislav Laznicka wrote: >Hi, > >I have made some changes to the structure of the HBAC time rules >extension, namely the code that validates the time rules' strings was >moved from the ipalib/parameters to the hbacrule module itself, and a >more "fresh" approach was used in code for methods of adding/removing >time policies to HBAC rules. Thanks for the advances. :) >A slight change was made to understanding a week in a month. The >change follows the Java implementation of a week in a month as >suggested by Petr V., given a week starts on Monday (=1; iso 8601). >More on that on the previously mentioned link > >https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html > >What this change means is that a first week in a month is a week that >contains at least 4 days. If it has less days, it's 0-th week >(probably better than having it belong to the previous month as some >sources also suggest - iso 8601 does not have a definition for a week >in month but it has a definition for a week in a year). Sounds fine. >I had Jan C. check the current implementation of the FreeIPA side for >the time-based policies and it seems to work as is. He created >official number identifiers for the 2 new LDAP attributeTypes, too. >\o/ > >I was also going through some old mockups for the WebUI Petr V. sent >me earlier last month. It brought some questions worth sharing here. > >1. Do we need time rules based on the day and week of the year? >Currently, there is no such option as dayofyear or weekofyear in the >rules language, although adding it should not be that much of a >problem. I did not include them as it seemed more convenient to set >the data as combinations of dayofmonth and monthofyear values. In business circles it is increasingly common to refer to events by their week numbers, especially in logistics and factory delivery. See http://www.cl.cam.ac.uk/~mgk25/iso-time.html for some details at the end of 'Date' section. >2. Should we add dayofyear and weekofyear, a possible need for >"intervals" might be required. An "interval" is a behavior from the >iCalendar format. It basically functions as range() in Python, >although with possible 'infinite' end. Example: should you have a >recurrence rule on daily basis with interval=2, a rule would apply on >every other day. This is kind of a question of keeping it easy and >light or heading a way of robust implementation during which dragons >may appear, although with a tiny tiny possibility of a golden treasure >in the end. Yes, I think intervals are required. >3. The mockups for HBAC time policies show quite a wizard-like UI. >While I might be very wrong here, I was thinking of rather a simple UI >where user would be able to set the values for each of the rule >keywords (timeofday, dayofweek, ...) directly in some text input >fields with possible help of JavaScript, that would add text >description to the user input (e.g. "Monday to Friday" with user input >"1-5" at the dayofweek input field). With JavaScript support your wizard-like approach would still work within the same page -- instead of moving 'next', you would need to modify a number of available input fields based on selected items. That's possible and I don't see much of trouble with it. >4. Do we want some special settings for "absolute" time policies >(policies that start and end at certain time in year)? The issue now >would be that some of such rules would have to be broken down in more >than one time rule (e.g. rule starting at a certain time of a day in a >month in one year and ending at a certain time, day and month of a >different year might get broken down to up to 6 rules if I count >right). This could actually be solved by a UI wizard-like setting >where the user gets to pick the dates and times of the rule, a >conversion method would need to be created and such a thing would then >work for the CLI, too. Still, usually more than one time rule would be >created for such cases. Same here. -- / Alexander Bokovoy From tbabej at redhat.com Mon Aug 3 11:30:44 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 3 Aug 2015 13:30:44 +0200 Subject: [Freeipa-devel] New freeipa-tools repo In-Reply-To: <55BA1167.6040809@redhat.com> References: <55BA0C86.5010707@redhat.com> <20150730115116.GJ4677@redhat.com> <55BA1167.6040809@redhat.com> Message-ID: <55BF50E4.7050804@redhat.com> On 07/30/2015 01:58 PM, Martin Kosek wrote: > On 07/30/2015 01:51 PM, Alexander Bokovoy wrote: >> On Thu, 30 Jul 2015, Martin Kosek wrote: >>> Hello all, >>> >>> Right now, the people pushing patches to FreeIPA use Petr's great "ipatool" >>> that is part of Petr's (CCed) ipa-tools repo forked from my old "ipa-tools" >>> repository. >>> >>> Recently, we have found that "ipatool" needs update due to 4.2 being released, >>> so I think this is a great moment to make this tool more official and use a >>> shared team repository so that people on the team can contribute and freely >>> improve it. >>> >>> As we have our shiny organization on github, I simply created new >>> "freeipa-tools" repo and with Petr's permission, moved "ipa-tools" content >>> there: >>> >>> https://github.com/freeipa/freeipa-tools >>> >>> If there are no objections, I would use that as the authoritative version of >>> the tools repo for the team. >>> >>> FreeIPA developers, please feel free to request access to >>> https://github.com/orgs/freeipa/teams/freeipa >>> if you want to commit to this repo. >> The link does not exist, you'd get 404 trying to access it. >> I don't see any way to add myself or request addition at >> https://github.com/freeipa > > Ah, looks like the github teams work differently then I though. You may need to > send me your github logins so that I can add people. > > If there is better way, please let me know. > As a heads up - the freeipa-ci repository containing the FreeIPA integration tests definitions under jenkins-job-builder is now available under freeipa organization as well. From mbabinsk at redhat.com Mon Aug 3 11:56:09 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 3 Aug 2015 13:56:09 +0200 Subject: [Freeipa-devel] [PATCH 0051] IPA server and replica installers can accept options from config file In-Reply-To: <55B9CA71.6010304@redhat.com> References: <55B8A8E0.404@redhat.com> <55B8B82D.7010309@redhat.com> <55B8ED95.5040208@redhat.com> <55B8F4B3.1000904@redhat.com> <55B9CA71.6010304@redhat.com> Message-ID: <55BF56D9.6080803@redhat.com> On 07/30/2015 08:55 AM, Jan Cholasta wrote: > Dne 29.7.2015 v 17:43 Petr Vobornik napsal(a): >> On 07/29/2015 05:13 PM, Martin Babinsky wrote: >>> On 07/29/2015 01:25 PM, Jan Cholasta wrote: >>>> Dne 29.7.2015 v 12:20 Martin Babinsky napsal(a): >>>>> Initial attempt to implement >>>>> https://fedorahosted.org/freeipa/ticket/4517 >>>>> >>>>> Some points to discuss: >>>>> >>>>> 1.) name of the config entries: currently the option names are derived >>>>> from CLI options but have underscores in them instead of dashes. Maybe >>>>> keeping the CLI option names also for config entries will make it >>>>> easier >>>>> for the user to transfer their CLI options from scripts to config >>>>> files. >>>> >>>> NACK. There is no point in generating config names from CLI names, >>>> which >>>> are generated from knob names - use knob names directly. >>>> >>> The problem is that in some cases the cli_name does not map directly to >>> knob name, leading in different naming of CLI options and config >>> entries, confusion and mayhem. > > What works for CLI may not work for config files and vice versa. For > example, this works for CLI: > > --no-ntp > --no-forwarders > --forwarder 1.2.3.4 --forwarder 5.6.7.8 > > but this works better in config file: > > ntp = False > forwarders = > forwarders = 1.2.3.4, 5.6.7.8 > >>> >>> These are some offenders from `ipaserver/install/server.py`: >>> http://fpaste.org/249424/18226114/ >>> >>> On the other hand, this can be an incentive to finally put an end to >>> inconsistent option/knob naming across server/replica/etc. installers. > > Yes please. > >> >> If the names are different than cli names, then they should be made >> discoverable somehow or be documented. > > IMHO documenting them is easy. > >> >>>>> >>>>> 2.) Config sections: there is currently only one valid section named >>>>> '[global]' in accordance with the format of 'default.conf'. Should we >>>>> have separate sections equivalent to option groups in CLI (e.g. >>>>> [basic], >>>>> [certificate system], [dns])? >>>> >>>> No, because they would have to be maintained forever. For example, some >>>> options are in wrong sections and we wouldn't be able to move them. >>>> >>> I'm also more inclined to a single section, at least for now since we >>> are pressed for time with this RFE. >>> >>> That's not to say that we should ditch Alexander's idea about separate >>> sections with overrides for different hosts. We should consider it as a >>> future enhancement to this feature once the basic plumbing is in place. > > Right. > >>>>> >>>>> 3.) Handling of unattended mode when specifying a config file: >>>>> Currently there is no connection between --config-file and unattended >>>>> mode. So when you run ipa-server-install using config file, you still >>>>> get asked for missing stuff. Should '--config-file' automatically >>>>> imply >>>>> '--unattended'? >>>> >>>> The behavior should be the same as if you specified the options on the >>>> command line. So no, --config-file should not imply --unattended. >>>> >>> That sound reasonable. the code behaves this way already so no changes >>> here. >>> >>>>> >>>>> There are probably other issues to discuss. Feel free to write >>>>> email/ping me on IRC. >>>>> >>>> >>>> (I haven't looked at the patch yet.) >>>> >>> Please take a look at it ASAP. I am on PTO tomorrow and on Friday, but I >>> will find time to work at it in the evening if you send me you comments. > > 1) IMO the option should be in the top-level option section, not in a > separate group (use "parser.add_option()"). > > Also maybe rename it to --config, AFAIK that's what is usually used. > > A short name ("-c"?) would be nice too. > > Nitpick: if the option is named --config-file, dest should be > "config_file", to make it easier to look it up in the code. > > > 2) Please don't duplicate the knob retrieval code, store knobs in a list > and pass that as an argument to parse_config_file. > > > 3) I'm not sure about using newline as a list separator. I don't know > about other IPA components, but SSSD in particular uses commas, maybe we > should be consistent with that? > > > 4) Booleans should be assignable either True or False, i.e. do not use > _parse_knob to parse them. > > > Honza > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0051.1-IPA-server-and-replica-installers-can-accept-options.patch Type: text/x-patch Size: 5496 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Aug 3 12:00:21 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 3 Aug 2015 14:00:21 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes Message-ID: <55BF57D5.5020703@redhat.com> This patch fixes the inconsistency between storing certificates in 'userCertificate'/'userCertificate;binary' attribute for the user entries: the certificate must be stored in the latter attribute only. Since a more general fix is out of 4.2.1 scope, I have implemented some workarounds in pre/post callbacks of user-* commands in order to enforce this behavior. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0052-store-certificates-issued-for-user-entries-as-userCe.patch Type: text/x-patch Size: 4853 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 3 12:14:54 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 3 Aug 2015 14:14:54 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55BF57D5.5020703@redhat.com> References: <55BF57D5.5020703@redhat.com> Message-ID: <55BF5B3E.60804@redhat.com> Hi, Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): > This patch fixes the inconsistency between storing certificates in > 'userCertificate'/'userCertificate;binary' attribute for the user > entries: the certificate must be stored in the latter attribute only. > > Since a more general fix is out of 4.2.1 scope, I have implemented some > workarounds in pre/post callbacks of user-* commands in order to enforce > this behavior. 1) + def convert_usercertificate_pre(self, entry_attrs, **options): + if options.get('all', False): + return We don't want to do any renaming when --raw is specified, not --all. Same for convert_usercertificate_post. 2) + self.obj.convert_usercertificate_pre(entry_attrs, **options) Rather than calling this directly from user_add, this should be called from baseuser.pre_common_callback(), which should be called from user_add.post_callback(). 3) IMO you should change user_{add,remove}_cert to call baseuser.convert_usercertificate_{pre,post} as well, to avoid code duplication. Honza -- Jan Cholasta From mbabinsk at redhat.com Mon Aug 3 12:34:19 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 3 Aug 2015 14:34:19 +0200 Subject: [Freeipa-devel] [PATCHES 0042-45] new commands for adding/removing certificates from entries In-Reply-To: <55A50D27.5000303@redhat.com> References: <558947C9.9020509@redhat.com> <559103A2.4080706@redhat.com> <55926999.5020301@redhat.com> <5592797F.6030509@redhat.com> <55928F78.6010408@redhat.com> <5593E58A.90801@redhat.com> <55950095.3000700@redhat.com> <55950431.9020505@redhat.com> <559530A5.7060404@redhat.com> <55954C89.1090804@redhat.com> <55954E68.3040805@redhat.com> <55A50D27.5000303@redhat.com> Message-ID: <55BF5FCB.5070404@redhat.com> On 07/14/2015 03:22 PM, Milan Kub?k wrote: > On 07/02/2015 04:44 PM, Jan Cholasta wrote: >> Dne 2.7.2015 v 16:36 Martin Babinsky napsal(a): >>> On 07/02/2015 02:37 PM, Martin Babinsky wrote: >>>> On 07/02/2015 11:28 AM, Martin Babinsky wrote: >>>>> On 07/02/2015 11:12 AM, Martin Babinsky wrote: >>>>>> On 07/01/2015 03:05 PM, Martin Babinsky wrote: >>>>>>> On 06/30/2015 02:45 PM, Martin Babinsky wrote: >>>>>>>> On 06/30/2015 01:11 PM, Martin Babinsky wrote: >>>>>>>>> On 06/30/2015 12:04 PM, Jan Cholasta wrote: >>>>>>>>>> Dne 29.6.2015 v 10:36 Martin Babinsky napsal(a): >>>>>>>>>>> On 06/23/2015 01:49 PM, Martin Babinsky wrote: >>>>>>>>>>>> This patchset implements new API commands for manipulating >>>>>>>>>>>> user/host/service userCertificate attribute alongside some >>>>>>>>>>>> underlying >>>>>>>>>>>> plumbing. >>>>>>>>>>>> >>>>>>>>>>>> PATCH 0045 is a small test suite that I slapped together since >>>>>>>>>>>> manual >>>>>>>>>>>> testing of this stuff is very cumbersome. It requires my PATCH >>>>>>>>>>>> 0040 to >>>>>>>>>>>> apply and work which was pushed to master recently >>>>>>>>>>>> (commit 74883bbc959058c8bfafd9f63e8fad0e3792ac28). >>>>>>>>>>>> >>>>>>>>>>>> The work is related to >>>>>>>>>>>> http://www.freeipa.org/page/V4/User_Certificates >>>>>>>>>>>> and https://fedorahosted.org/freeipa/ticket/4238 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Attaching updated patches. >>>>>>>>>>> >>>>>>>>>>> Here are some notes for Jan because I did some things >>>>>>>>>>> differently >>>>>>>>>>> than >>>>>>>>>>> we agreed on during review: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1.) I chose not to rename 'usercertificate' to >>>>>>>>>>> 'usercertificate;binary' >>>>>>>>>>> and back in pre/post callbacks. Despite the fact that the >>>>>>>>>>> correct >>>>>>>>>>> way to >>>>>>>>>>> name the certificate attribute is 'usercertificate;binary', I >>>>>>>>>>> feel >>>>>>>>>>> that >>>>>>>>>>> suddenly renaming it in the new code is asking for trouble. >>>>>>>>>> >>>>>>>>>> New code is new, there is no renaming, there is naming, and that >>>>>>>>>> naming >>>>>>>>>> should follow standards, and the standard is >>>>>>>>>> userCertificate;binary. >>>>>>>>>> >>>>>>>>>> (For the record I did not ask for any renaming in *old* host and >>>>>>>>>> service >>>>>>>>>> code.) >>>>>>>>>> >>>>>>>>> OK I will then use 'usercertificate;binary' and try to not break >>>>>>>>> things. >>>>>>>>>>> >>>>>>>>>>> I'm all for changing the mapping between CLI options and actual >>>>>>>>>>> attribute names but it should be done in a systematic fashion. >>>>>>>>>> >>>>>>>>>> +1, shall I post a patch? >>>>>>>>>> >>>>>>>>> That would be great, but I'm not sure if there is time for it. >>>>>>>>> Maybe we >>>>>>>>> can create a ticket for tracking? >>>>>>>>>>> >>>>>>>>>>> 2.) I have kept the `normalize_certs` function. It has the >>>>>>>>>>> potential to >>>>>>>>>>> catch incorrectly formatted/encoded certificates and in a way >>>>>>>>>>> circumvents the slightly demented way the framework deals with >>>>>>>>>>> supposedly binary data. >>>>>>>>>> >>>>>>>>>> One sentence above you asked for doing things in systematic >>>>>>>>>> fashion. >>>>>>>>>> This is exactly what it isn't. A systematic solution would be >>>>>>>>>> a new >>>>>>>>>> parameter type for certificates. >>>>>>>>>> >>>>>>>>> Ha I didn't notice that incorrect encoding is caught by validator. >>>>>>>>> >>>>>>>>> But I think that we still need to catch malformed certificates >>>>>>>>> that >>>>>>>>> can >>>>>>>>> not be decoded to DER and AFAIK we don't do that anywhere (failing >>>>>>>>> tests >>>>>>>>> when adding a random Base64-encoded string confirm this). >>>>>>>>> >>>>>>>>> All this probably stems from my confusion about the way IPA >>>>>>>>> framework >>>>>>>>> guesses binary data. For example, if I call >>>>>>>>> `api.Command.user_add_cert` >>>>>>>>> and fill 'certificate' option with Base64 blob reencoded to >>>>>>>>> Unicode, >>>>>>>>> everything works as expected. >>>>>>>>> >>>>>>>>> However, filling this option with 'str' leads to another round of >>>>>>>>> Base64 >>>>>>>>> encoding in the framework, leading to 'userCertificate;binary' >>>>>>>>> which is >>>>>>>>> filled by original Base64 blob instead of DER encoded cert. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I have also added two negative test cases which deal with >>>>>>>>>>> incorrectly >>>>>>>>>>> encoded and formatted certificates. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Attaching updated patches (actually only 44 is updated, I added the >>>>>>>> rename to/from 'usercertificate;binary' to user pre/post >>>>>>>> callbacks). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Another patch update attached (mainly fixing pep8 complaints and >>>>>>> reworking certificate validation). >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> >>>>>> >>>>> >>>>> I left a a bug in PATCH 0043. Attaching updated version. >>>>> >>>>> >>>>> >>>> Attaching updated patches. >>>> >>>> >>>> >>> Attaching revised patchset. >> >> Thanks, ACK on patch 42-44. >> >> Pushed to master: 76eea85701af80dc972c47e14aecc7a688b9c846 >> >>> >>> It would be nice if Milan could comment on PATCH 0045. >>> >> >> (I did not push this patch.) >> > Hi, > > sorry for the delay. The test looks good to me. > > Though we'll better rewrite the test after the Trackers for the plugins > involved in certificate signing and CA ACL enforcement will be > available. It won't be necessary right away, though. > > ACK > > Thanks, > Milan > So what about PATCH 45 (tests). Milan ACKed it, can we push it? -- Martin^3 Babinsky From jcholast at redhat.com Mon Aug 3 12:40:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 3 Aug 2015 14:40:29 +0200 Subject: [Freeipa-devel] [PATCHES 0042-45] new commands for adding/removing certificates from entries In-Reply-To: <55BF5FCB.5070404@redhat.com> References: <558947C9.9020509@redhat.com> <559103A2.4080706@redhat.com> <55926999.5020301@redhat.com> <5592797F.6030509@redhat.com> <55928F78.6010408@redhat.com> <5593E58A.90801@redhat.com> <55950095.3000700@redhat.com> <55950431.9020505@redhat.com> <559530A5.7060404@redhat.com> <55954C89.1090804@redhat.com> <55954E68.3040805@redhat.com> <55A50D27.5000303@redhat.com> <55BF5FCB.5070404@redhat.com> Message-ID: <55BF613D.70800@redhat.com> Dne 3.8.2015 v 14:34 Martin Babinsky napsal(a): > On 07/14/2015 03:22 PM, Milan Kub?k wrote: >> On 07/02/2015 04:44 PM, Jan Cholasta wrote: >>> Dne 2.7.2015 v 16:36 Martin Babinsky napsal(a): >>>> On 07/02/2015 02:37 PM, Martin Babinsky wrote: >>>>> On 07/02/2015 11:28 AM, Martin Babinsky wrote: >>>>>> On 07/02/2015 11:12 AM, Martin Babinsky wrote: >>>>>>> On 07/01/2015 03:05 PM, Martin Babinsky wrote: >>>>>>>> On 06/30/2015 02:45 PM, Martin Babinsky wrote: >>>>>>>>> On 06/30/2015 01:11 PM, Martin Babinsky wrote: >>>>>>>>>> On 06/30/2015 12:04 PM, Jan Cholasta wrote: >>>>>>>>>>> Dne 29.6.2015 v 10:36 Martin Babinsky napsal(a): >>>>>>>>>>>> On 06/23/2015 01:49 PM, Martin Babinsky wrote: >>>>>>>>>>>>> This patchset implements new API commands for manipulating >>>>>>>>>>>>> user/host/service userCertificate attribute alongside some >>>>>>>>>>>>> underlying >>>>>>>>>>>>> plumbing. >>>>>>>>>>>>> >>>>>>>>>>>>> PATCH 0045 is a small test suite that I slapped together since >>>>>>>>>>>>> manual >>>>>>>>>>>>> testing of this stuff is very cumbersome. It requires my PATCH >>>>>>>>>>>>> 0040 to >>>>>>>>>>>>> apply and work which was pushed to master recently >>>>>>>>>>>>> (commit 74883bbc959058c8bfafd9f63e8fad0e3792ac28). >>>>>>>>>>>>> >>>>>>>>>>>>> The work is related to >>>>>>>>>>>>> http://www.freeipa.org/page/V4/User_Certificates >>>>>>>>>>>>> and https://fedorahosted.org/freeipa/ticket/4238 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Attaching updated patches. >>>>>>>>>>>> >>>>>>>>>>>> Here are some notes for Jan because I did some things >>>>>>>>>>>> differently >>>>>>>>>>>> than >>>>>>>>>>>> we agreed on during review: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1.) I chose not to rename 'usercertificate' to >>>>>>>>>>>> 'usercertificate;binary' >>>>>>>>>>>> and back in pre/post callbacks. Despite the fact that the >>>>>>>>>>>> correct >>>>>>>>>>>> way to >>>>>>>>>>>> name the certificate attribute is 'usercertificate;binary', I >>>>>>>>>>>> feel >>>>>>>>>>>> that >>>>>>>>>>>> suddenly renaming it in the new code is asking for trouble. >>>>>>>>>>> >>>>>>>>>>> New code is new, there is no renaming, there is naming, and that >>>>>>>>>>> naming >>>>>>>>>>> should follow standards, and the standard is >>>>>>>>>>> userCertificate;binary. >>>>>>>>>>> >>>>>>>>>>> (For the record I did not ask for any renaming in *old* host and >>>>>>>>>>> service >>>>>>>>>>> code.) >>>>>>>>>>> >>>>>>>>>> OK I will then use 'usercertificate;binary' and try to not break >>>>>>>>>> things. >>>>>>>>>>>> >>>>>>>>>>>> I'm all for changing the mapping between CLI options and actual >>>>>>>>>>>> attribute names but it should be done in a systematic fashion. >>>>>>>>>>> >>>>>>>>>>> +1, shall I post a patch? >>>>>>>>>>> >>>>>>>>>> That would be great, but I'm not sure if there is time for it. >>>>>>>>>> Maybe we >>>>>>>>>> can create a ticket for tracking? >>>>>>>>>>>> >>>>>>>>>>>> 2.) I have kept the `normalize_certs` function. It has the >>>>>>>>>>>> potential to >>>>>>>>>>>> catch incorrectly formatted/encoded certificates and in a way >>>>>>>>>>>> circumvents the slightly demented way the framework deals with >>>>>>>>>>>> supposedly binary data. >>>>>>>>>>> >>>>>>>>>>> One sentence above you asked for doing things in systematic >>>>>>>>>>> fashion. >>>>>>>>>>> This is exactly what it isn't. A systematic solution would be >>>>>>>>>>> a new >>>>>>>>>>> parameter type for certificates. >>>>>>>>>>> >>>>>>>>>> Ha I didn't notice that incorrect encoding is caught by >>>>>>>>>> validator. >>>>>>>>>> >>>>>>>>>> But I think that we still need to catch malformed certificates >>>>>>>>>> that >>>>>>>>>> can >>>>>>>>>> not be decoded to DER and AFAIK we don't do that anywhere >>>>>>>>>> (failing >>>>>>>>>> tests >>>>>>>>>> when adding a random Base64-encoded string confirm this). >>>>>>>>>> >>>>>>>>>> All this probably stems from my confusion about the way IPA >>>>>>>>>> framework >>>>>>>>>> guesses binary data. For example, if I call >>>>>>>>>> `api.Command.user_add_cert` >>>>>>>>>> and fill 'certificate' option with Base64 blob reencoded to >>>>>>>>>> Unicode, >>>>>>>>>> everything works as expected. >>>>>>>>>> >>>>>>>>>> However, filling this option with 'str' leads to another round of >>>>>>>>>> Base64 >>>>>>>>>> encoding in the framework, leading to 'userCertificate;binary' >>>>>>>>>> which is >>>>>>>>>> filled by original Base64 blob instead of DER encoded cert. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I have also added two negative test cases which deal with >>>>>>>>>>>> incorrectly >>>>>>>>>>>> encoded and formatted certificates. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Attaching updated patches (actually only 44 is updated, I added >>>>>>>>> the >>>>>>>>> rename to/from 'usercertificate;binary' to user pre/post >>>>>>>>> callbacks). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Another patch update attached (mainly fixing pep8 complaints and >>>>>>>> reworking certificate validation). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I left a a bug in PATCH 0043. Attaching updated version. >>>>>> >>>>>> >>>>>> >>>>> Attaching updated patches. >>>>> >>>>> >>>>> >>>> Attaching revised patchset. >>> >>> Thanks, ACK on patch 42-44. >>> >>> Pushed to master: 76eea85701af80dc972c47e14aecc7a688b9c846 >>> >>>> >>>> It would be nice if Milan could comment on PATCH 0045. >>>> >>> >>> (I did not push this patch.) >>> >> Hi, >> >> sorry for the delay. The test looks good to me. >> >> Though we'll better rewrite the test after the Trackers for the plugins >> involved in certificate signing and CA ACL enforcement will be >> available. It won't be necessary right away, though. >> >> ACK >> >> Thanks, >> Milan >> > > So what about PATCH 45 (tests). Milan ACKed it, can we push it? > I don't see why not. Pushed to: master: 555229e33e44a200a4035d21da326f568b25946c ipa-4-2: d0db86f9b5ec33b9015163035ff84da20d859a2a -- Jan Cholasta From jcholast at redhat.com Mon Aug 3 12:46:02 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 3 Aug 2015 14:46:02 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55BF5B3E.60804@redhat.com> References: <55BF57D5.5020703@redhat.com> <55BF5B3E.60804@redhat.com> Message-ID: <55BF628A.1070204@redhat.com> Dne 3.8.2015 v 14:14 Jan Cholasta napsal(a): > Hi, > > Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): >> This patch fixes the inconsistency between storing certificates in >> 'userCertificate'/'userCertificate;binary' attribute for the user >> entries: the certificate must be stored in the latter attribute only. >> >> Since a more general fix is out of 4.2.1 scope, I have implemented some >> workarounds in pre/post callbacks of user-* commands in order to enforce >> this behavior. > > 1) > > + def convert_usercertificate_pre(self, entry_attrs, **options): > + if options.get('all', False): > + return > > We don't want to do any renaming when --raw is specified, not --all. > Same for convert_usercertificate_post. Actually, the attribute should be always renamed in convert_usercertificate_pre, otherwise we would modify the wrong attribute. In convert_usercertificate_post, it should actually be renamed only when --raw is specified. > > > 2) > > + self.obj.convert_usercertificate_pre(entry_attrs, **options) > > Rather than calling this directly from user_add, this should be called > from baseuser.pre_common_callback(), which should be called from > user_add.post_callback(). > > > 3) IMO you should change user_{add,remove}_cert to call > baseuser.convert_usercertificate_{pre,post} as well, to avoid code > duplication. > > > Honza > -- Jan Cholasta From mbabinsk at redhat.com Mon Aug 3 12:58:23 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 3 Aug 2015 14:58:23 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55BF628A.1070204@redhat.com> References: <55BF57D5.5020703@redhat.com> <55BF5B3E.60804@redhat.com> <55BF628A.1070204@redhat.com> Message-ID: <55BF656F.5010702@redhat.com> On 08/03/2015 02:46 PM, Jan Cholasta wrote: > Dne 3.8.2015 v 14:14 Jan Cholasta napsal(a): >> Hi, >> >> Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): >>> This patch fixes the inconsistency between storing certificates in >>> 'userCertificate'/'userCertificate;binary' attribute for the user >>> entries: the certificate must be stored in the latter attribute only. >>> >>> Since a more general fix is out of 4.2.1 scope, I have implemented some >>> workarounds in pre/post callbacks of user-* commands in order to enforce >>> this behavior. >> >> 1) >> >> + def convert_usercertificate_pre(self, entry_attrs, **options): >> + if options.get('all', False): >> + return >> >> We don't want to do any renaming when --raw is specified, not --all. >> Same for convert_usercertificate_post. > > Actually, the attribute should be always renamed in > convert_usercertificate_pre, otherwise we would modify the wrong > attribute. In convert_usercertificate_post, it should actually be > renamed only when --raw is specified. > If you do the rename in `convert_usercertificate_post` only when '--raw' is specified, then you get no certificate displayed when you do `ipa user-show` on user with userCertificate;binary attribute. Is this intended? (Keep in mind that `convert_usercertificate_post` should be called in post-callback when returning results back to user/client). >> >> >> 2) >> >> + self.obj.convert_usercertificate_pre(entry_attrs, **options) >> >> Rather than calling this directly from user_add, this should be called >> from baseuser.pre_common_callback(), which should be called from >> user_add.post_callback(). >> >> >> 3) IMO you should change user_{add,remove}_cert to call >> baseuser.convert_usercertificate_{pre,post} as well, to avoid code >> duplication. >> >> >> Honza >> > > -- Martin^3 Babinsky From jcholast at redhat.com Mon Aug 3 13:39:36 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 3 Aug 2015 15:39:36 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55BF656F.5010702@redhat.com> References: <55BF57D5.5020703@redhat.com> <55BF5B3E.60804@redhat.com> <55BF628A.1070204@redhat.com> <55BF656F.5010702@redhat.com> Message-ID: <55BF6F18.3090003@redhat.com> Dne 3.8.2015 v 14:58 Martin Babinsky napsal(a): > On 08/03/2015 02:46 PM, Jan Cholasta wrote: >> Dne 3.8.2015 v 14:14 Jan Cholasta napsal(a): >>> Hi, >>> >>> Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): >>>> This patch fixes the inconsistency between storing certificates in >>>> 'userCertificate'/'userCertificate;binary' attribute for the user >>>> entries: the certificate must be stored in the latter attribute only. >>>> >>>> Since a more general fix is out of 4.2.1 scope, I have implemented some >>>> workarounds in pre/post callbacks of user-* commands in order to >>>> enforce >>>> this behavior. >>> >>> 1) >>> >>> + def convert_usercertificate_pre(self, entry_attrs, **options): >>> + if options.get('all', False): >>> + return >>> >>> We don't want to do any renaming when --raw is specified, not --all. >>> Same for convert_usercertificate_post. >> >> Actually, the attribute should be always renamed in >> convert_usercertificate_pre, otherwise we would modify the wrong >> attribute. In convert_usercertificate_post, it should actually be >> renamed only when --raw is specified. >> > > If you do the rename in `convert_usercertificate_post` only when '--raw' > is specified, then you get no certificate displayed when you do `ipa > user-show` on user with userCertificate;binary attribute. Is this > intended? (Keep in mind that `convert_usercertificate_post` should be > called in post-callback when returning results back to user/client). Oops, I meant "rename only when --raw is *not* specified". >>> >>> >>> 2) >>> >>> + self.obj.convert_usercertificate_pre(entry_attrs, **options) >>> >>> Rather than calling this directly from user_add, this should be called >>> from baseuser.pre_common_callback(), which should be called from >>> user_add.post_callback(). >>> >>> >>> 3) IMO you should change user_{add,remove}_cert to call >>> baseuser.convert_usercertificate_{pre,post} as well, to avoid code >>> duplication. >>> >>> >>> Honza >>> >> >> > > -- Jan Cholasta From slaznick at redhat.com Mon Aug 3 14:12:41 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Mon, 3 Aug 2015 16:12:41 +0200 Subject: [Freeipa-devel] Time-Based Account Policies In-Reply-To: <20150803094534.GB31709@redhat.com> References: <55BF2C6B.3070205@redhat.com> <20150803094534.GB31709@redhat.com> Message-ID: <55BF76D9.4060200@redhat.com> On 08/03/2015 11:45 AM, Alexander Bokovoy wrote: > On Mon, 03 Aug 2015, Stanislav Laznicka wrote: >> Hi, >> >> I have made some changes to the structure of the HBAC time rules >> extension, namely the code that validates the time rules' strings was >> moved from the ipalib/parameters to the hbacrule module itself, and a >> more "fresh" approach was used in code for methods of adding/removing >> time policies to HBAC rules. > Thanks for the advances. :) > >> A slight change was made to understanding a week in a month. The >> change follows the Java implementation of a week in a month as >> suggested by Petr V., given a week starts on Monday (=1; iso 8601). >> More on that on the previously mentioned link >> >> https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html >> >> >> What this change means is that a first week in a month is a week that >> contains at least 4 days. If it has less days, it's 0-th week >> (probably better than having it belong to the previous month as some >> sources also suggest - iso 8601 does not have a definition for a week >> in month but it has a definition for a week in a year). > Sounds fine. > >> I had Jan C. check the current implementation of the FreeIPA side for >> the time-based policies and it seems to work as is. He created >> official number identifiers for the 2 new LDAP attributeTypes, too. \o/ >> >> I was also going through some old mockups for the WebUI Petr V. sent >> me earlier last month. It brought some questions worth sharing here. >> >> 1. Do we need time rules based on the day and week of the year? >> Currently, there is no such option as dayofyear or weekofyear in the >> rules language, although adding it should not be that much of a >> problem. I did not include them as it seemed more convenient to set >> the data as combinations of dayofmonth and monthofyear values. > In business circles it is increasingly common to refer to events by > their week numbers, especially in logistics and factory delivery. > > See http://www.cl.cam.ac.uk/~mgk25/iso-time.html for some details at the > end of 'Date' section. > It should go right in, then. > >> 2. Should we add dayofyear and weekofyear, a possible need for >> "intervals" might be required. An "interval" is a behavior from the >> iCalendar format. It basically functions as range() in Python, >> although with possible 'infinite' end. Example: should you have a >> recurrence rule on daily basis with interval=2, a rule would apply on >> every other day. This is kind of a question of keeping it easy and >> light or heading a way of robust implementation during which dragons >> may appear, although with a tiny tiny possibility of a golden >> treasure in the end. > Yes, I think intervals are required. > Alright. I gave it a little thought considering the current state of the language for time rules and considering where I should go with these intervals. The thing about the 'interval' in iCalendar is that to use it it is necessary to also add at least the 'frequency' and 'startdate' elements to the language. With that, adding 'enddate' and 'count' optional elements should not be that bad. What I am hoping for is that the same functionality as in iCalendar can be achieved here and so far I do not see why not. >> 3. The mockups for HBAC time policies show quite a wizard-like UI. >> While I might be very wrong here, I was thinking of rather a simple >> UI where user would be able to set the values for each of the rule >> keywords (timeofday, dayofweek, ...) directly in some text input >> fields with possible help of JavaScript, that would add text >> description to the user input (e.g. "Monday to Friday" with user >> input "1-5" at the dayofweek input field). > With JavaScript support your wizard-like approach would still work > within the same page -- instead of moving 'next', you would need to > modify a number of available input fields based on selected items. > That's possible and I don't see much of trouble with it. > >> 4. Do we want some special settings for "absolute" time policies >> (policies that start and end at certain time in year)? The issue now >> would be that some of such rules would have to be broken down in more >> than one time rule (e.g. rule starting at a certain time of a day in >> a month in one year and ending at a certain time, day and month of a >> different year might get broken down to up to 6 rules if I count >> right). This could actually be solved by a UI wizard-like setting >> where the user gets to pick the dates and times of the rule, a >> conversion method would need to be created and such a thing would >> then work for the CLI, too. Still, usually more than one time rule >> would be created for such cases. > Same here. > I might not have expressed myself clearly there, for which I am sorry. I was rather thinking that instead of different 'screens' for different time scenarios, like "Yearly", "Daily", etc., user should be able to set all the values in one UI pop-up screen directly as number values in text fields (with the exception of "absolute" time policies, perhaps). While the user experience may suffer a bit, to me it seems more clear, readable and flexible than to have some elements such as checkboxes and selects take care of that (although the values around the "interval" from iCalendar discussed here earlier would probably need just that). Hopefully, I made myself clearer here :) From abokovoy at redhat.com Mon Aug 3 14:30:28 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 3 Aug 2015 17:30:28 +0300 Subject: [Freeipa-devel] Time-Based Account Policies In-Reply-To: <55BF76D9.4060200@redhat.com> References: <55BF2C6B.3070205@redhat.com> <20150803094534.GB31709@redhat.com> <55BF76D9.4060200@redhat.com> Message-ID: <20150803143028.GF31709@redhat.com> On Mon, 03 Aug 2015, Stanislav Laznicka wrote: >>>dragons may appear, although with a tiny tiny possibility of a >>>golden treasure in the end. >>Yes, I think intervals are required. >> >Alright. I gave it a little thought considering the current state of >the language for time rules and considering where I should go with >these intervals. The thing about the 'interval' in iCalendar is that >to use it it is necessary to also add at least the 'frequency' and >'startdate' elements to the language. With that, adding 'enddate' and >'count' optional elements should not be that bad. What I am hoping for >is that the same functionality as in iCalendar can be achieved here >and so far I do not see why not. Yep. >>>3. The mockups for HBAC time policies show quite a wizard-like UI. >>>While I might be very wrong here, I was thinking of rather a >>>simple UI where user would be able to set the values for each of >>>the rule keywords (timeofday, dayofweek, ...) directly in some >>>text input fields with possible help of JavaScript, that would add >>>text description to the user input (e.g. "Monday to Friday" with >>>user input "1-5" at the dayofweek input field). >>With JavaScript support your wizard-like approach would still work >>within the same page -- instead of moving 'next', you would need to >>modify a number of available input fields based on selected items. >>That's possible and I don't see much of trouble with it. >> >>>4. Do we want some special settings for "absolute" time policies >>>(policies that start and end at certain time in year)? The issue >>>now would be that some of such rules would have to be broken down >>>in more than one time rule (e.g. rule starting at a certain time >>>of a day in a month in one year and ending at a certain time, day >>>and month of a different year might get broken down to up to 6 >>>rules if I count right). This could actually be solved by a UI >>>wizard-like setting where the user gets to pick the dates and >>>times of the rule, a conversion method would need to be created >>>and such a thing would then work for the CLI, too. Still, usually >>>more than one time rule would be created for such cases. >>Same here. >> >I might not have expressed myself clearly there, for which I am sorry. >I was rather thinking that instead of different 'screens' for >different time scenarios, like "Yearly", "Daily", etc., user should be >able to set all the values in one UI pop-up screen directly as number >values in text fields (with the exception of "absolute" time policies, >perhaps). While the user experience may suffer a bit, to me it seems >more clear, readable and flexible than to have some elements such as >checkboxes and selects take care of that (although the values around >the "interval" from iCalendar discussed here earlier would probably >need just that). Hopefully, I made myself clearer here :) If you are able to structure types of scenarios clearly, use accordion pattern to present them at the top level, like here: https://www.patternfly.org/widgets/#accordion (we are using PatternFly in our UI). Do per-scenario options in each panel as needed. -- / Alexander Bokovoy From tbordaz at redhat.com Mon Aug 3 15:34:02 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 03 Aug 2015 17:34:02 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55B75A9F.7090308@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> Message-ID: <55BF89EA.3050901@redhat.com> On 07/28/2015 12:34 PM, Jan Cholasta wrote: > Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >> >> >> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>> On 23/07/15 14:43, Martin Basti wrote: >>>>> Hello, >>>>> >>>>> I tried to fix #5145 and I partially succeeded. >>>>> >>>>> However, I cannot fix this part of ticket, where user is prompted to >>>>> write name and surname. >>>>> >>>>> $ ipa stageuser-add tuser --from-delete >>>>> First name: this will be ignored >>>>> Last name: this will be also ignored >>>>> ------------------------ >>>>> Added stage user "tuser" >>>>> ------------------------ >>>>> >>>>> As the first name and last name are mandatory attributes of >>>>> stageuser-add command, but they are not needed by when the >>>>> --from-delete option is used. >>>>> I would like to ask how to fix this issue, IMO this will be huge hack >>>>> in internal API. Or should we just document this bug as known issue >>>>> (thierry wrote that this is not use case that should be used often)? >>>>> >>>>> The best solution would be separate command, but this idea was >>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>> regarding the design" >>>>> >>>>> Regards >>>>> Martin^2 >>>>> >>>> Hello, >>>> >>>> as was mentioned before, we have issue with current internal API >>>> and the >>>> stageuser-add --from-delete command. >>>> >>>> We discussed this today, and we did not find a nice way how to fix it, >>>> so we propose this (which is IMO the best solution): >>>> >>>> * stageuser-add --from-delete should be deprecated >>> >>> +1 >>> >>>> * create new option for user-undel: used-undel --to-staged (or create >>>> new command) that will handle moving deleted users to staged area as >>>> --from-delete did. >>> >>> Make it new command please. >>> >>>> >>>> Instead of stageuser-add and option --from-delete, which work totally >>>> different, the command user-undel does similar operation than >>>> stage-user >>>> --from-delete, it just uses different container. >>> >>> NACK on stuffing everything into a single command just because it does >>> something similar. >> >> How about making it a 'stageuser-undel'? The 'user-undel' moves >> preserved user to active, so the 'stageuser-undel' would move preserved >> to staged. The action is similar, but has slightly different specifics >> (which attributes are preserved etc.), and for me the 'stageuser-undel' >> feels more natural than 'user-undel --to-staged' since it's basically >> the same as there is 'stageuser-add' for creating a staged user, not >> 'user-add --to-staged'. It would be in the same style as all the other >> commands concerning operations with users in staged container. > > Well, user-undel is the opposite of user-del, and stageuser-undel > should be the opposite of stageuser-del. The stageuser-undel you are > suggesting is not. > > Also I'm not sure if we want to (always) remove the deleted user once > a staged user is created from it, but -undel behaves like that. > > I don't think the command should be limited to deleted users only. > Active and deleted users share the same namespace, so it is an > arbitrary limitation. preserved users has been valid active user. In that sense active/preserved are managed by a same set of CLI (user-find,user-del,user-show) because a preserved user is a 'user'. So I would vote for continuing with a 'user-*' commands and use 'user-undel --to-stage'. > > I think that what we are looking for is the opposite of > stageuser-activate. So maybe user-stage? From edewata at redhat.com Mon Aug 3 15:36:58 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 3 Aug 2015 10:36:58 -0500 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55BF18C2.1010808@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> Message-ID: <55BF8A9A.30907@redhat.com> On 8/3/2015 2:31 AM, Martin Kosek wrote: > On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote: >> The CLIs to manage vault owners and members have been modified >> to accept services with a new parameter. Due to name conflict, >> the existing 'service' parameter has been renamed to >> 'servicename'. >> >> A new ACL has been added to allow a service to create its own >> service container. >> >> https://fedorahosted.org/freeipa/ticket/5172 > > I did not do a full review, I just saw some of the changes that made me worry - > like renaming API command attribute. Wouldn't that make the older clients fail? > > See for example permission-* commands, we faced similar situation there and had > to rename command attributes potentially used by old clients in the new format. Yes, it will break older clients. The problem is I cannot keep the legacy 'service' parameter for backward compatibility: Str( 'service?', cli_name='deprecated_service', doc=_('DEPRECATED: Service name of the service vault'), ), Str( 'servicename?', cli_name='service', doc=_('Service name of the service vault'), ), because it will conflict with a new 'service' parameter: [Mon Aug 03 17:19:00.197040 2015] [wsgi:error] [pid 9409] ipa: ERROR: Failed to start IPA: cannot override NameSpace.service value Str('service?', cli_name='deprecated_service', doc=Gettext('DEPRECATED: Service name of the service vault', domain='ipa', localedir=None)) with Str('service*', alwaysask=True, cli_name='services', csv=True, doc=u'services to add', label=u'member service') that was added automatically when I added the 'service' attribute member: attribute_members = { 'owner': ['user', 'group', 'service'], 'member': ['user', 'group', 'service'], } If there's a way to use a different parameter name for the 'service' attribute member to avoid conflict with the legacy 'service' parameter please let me know. The other option is to force the client to upgrade to the same version. Please let me know. Thanks. -- Endi S. Dewata From mbabinsk at redhat.com Mon Aug 3 16:41:19 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 3 Aug 2015 18:41:19 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55BF6F18.3090003@redhat.com> References: <55BF57D5.5020703@redhat.com> <55BF5B3E.60804@redhat.com> <55BF628A.1070204@redhat.com> <55BF656F.5010702@redhat.com> <55BF6F18.3090003@redhat.com> Message-ID: <55BF99AF.3060605@redhat.com> On 08/03/2015 03:39 PM, Jan Cholasta wrote: > Dne 3.8.2015 v 14:58 Martin Babinsky napsal(a): >> On 08/03/2015 02:46 PM, Jan Cholasta wrote: >>> Dne 3.8.2015 v 14:14 Jan Cholasta napsal(a): >>>> Hi, >>>> >>>> Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): >>>>> This patch fixes the inconsistency between storing certificates in >>>>> 'userCertificate'/'userCertificate;binary' attribute for the user >>>>> entries: the certificate must be stored in the latter attribute only. >>>>> >>>>> Since a more general fix is out of 4.2.1 scope, I have implemented >>>>> some >>>>> workarounds in pre/post callbacks of user-* commands in order to >>>>> enforce >>>>> this behavior. >>>> >>>> 1) >>>> >>>> + def convert_usercertificate_pre(self, entry_attrs, **options): >>>> + if options.get('all', False): >>>> + return >>>> >>>> We don't want to do any renaming when --raw is specified, not --all. >>>> Same for convert_usercertificate_post. >>> >>> Actually, the attribute should be always renamed in >>> convert_usercertificate_pre, otherwise we would modify the wrong >>> attribute. In convert_usercertificate_post, it should actually be >>> renamed only when --raw is specified. >>> >> >> If you do the rename in `convert_usercertificate_post` only when '--raw' >> is specified, then you get no certificate displayed when you do `ipa >> user-show` on user with userCertificate;binary attribute. Is this >> intended? (Keep in mind that `convert_usercertificate_post` should be >> called in post-callback when returning results back to user/client). > > Oops, I meant "rename only when --raw is *not* specified". > >>>> >>>> >>>> 2) >>>> >>>> + self.obj.convert_usercertificate_pre(entry_attrs, **options) >>>> >>>> Rather than calling this directly from user_add, this should be called >>>> from baseuser.pre_common_callback(), which should be called from >>>> user_add.post_callback(). >>>> >>>> >>>> 3) IMO you should change user_{add,remove}_cert to call >>>> baseuser.convert_usercertificate_{pre,post} as well, to avoid code >>>> duplication. >>>> >>>> >>>> Honza >>>> >>> >>> >> >> > > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0052.2-store-certificates-issued-for-user-entries-as-userCe.patch Type: text/x-patch Size: 6402 bytes Desc: not available URL: From mkosek at redhat.com Mon Aug 3 19:47:00 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 3 Aug 2015 21:47:00 +0200 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55BF8A9A.30907@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> Message-ID: <55BFC534.6010605@redhat.com> On 08/03/2015 05:36 PM, Endi Sukma Dewata wrote: > On 8/3/2015 2:31 AM, Martin Kosek wrote: >> On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote: >>> The CLIs to manage vault owners and members have been modified >>> to accept services with a new parameter. Due to name conflict, >>> the existing 'service' parameter has been renamed to >>> 'servicename'. >>> >>> A new ACL has been added to allow a service to create its own >>> service container. >>> >>> https://fedorahosted.org/freeipa/ticket/5172 >> >> I did not do a full review, I just saw some of the changes that made me worry - >> like renaming API command attribute. Wouldn't that make the older clients fail? >> >> See for example permission-* commands, we faced similar situation there and had >> to rename command attributes potentially used by old clients in the new format. > > Yes, it will break older clients. The problem is I cannot keep the legacy > 'service' parameter for backward compatibility: > > Str( > 'service?', > cli_name='deprecated_service', > doc=_('DEPRECATED: Service name of the service vault'), > ), > Str( > 'servicename?', > cli_name='service', > doc=_('Service name of the service vault'), > ), > > because it will conflict with a new 'service' parameter: > > [Mon Aug 03 17:19:00.197040 2015] [wsgi:error] [pid 9409] ipa: ERROR: Failed to > start IPA: cannot override NameSpace.service value Str('service?', > cli_name='deprecated_service', doc=Gettext('DEPRECATED: Service name of the > service vault', domain='ipa', localedir=None)) with Str('service*', > alwaysask=True, cli_name='services', csv=True, doc=u'services to add', > label=u'member service') > > that was added automatically when I added the 'service' attribute member: > > attribute_members = { > 'owner': ['user', 'group', 'service'], > 'member': ['user', 'group', 'service'], > } > > If there's a way to use a different parameter name for the 'service' attribute > member to avoid conflict with the legacy 'service' parameter please let me know. > > The other option is to force the client to upgrade to the same version. > > Please let me know. Thanks. > Honza, do we have any other options than to break API between 4.2.0 and 4.2.1? From edewata at redhat.com Mon Aug 3 20:37:27 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 3 Aug 2015 15:37:27 -0500 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55BFC534.6010605@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> Message-ID: <55BFD107.4060105@redhat.com> On 8/3/2015 2:47 PM, Martin Kosek wrote: > On 08/03/2015 05:36 PM, Endi Sukma Dewata wrote: >> On 8/3/2015 2:31 AM, Martin Kosek wrote: >>> On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote: >>>> The CLIs to manage vault owners and members have been modified >>>> to accept services with a new parameter. Due to name conflict, >>>> the existing 'service' parameter has been renamed to >>>> 'servicename'. >>>> >>>> A new ACL has been added to allow a service to create its own >>>> service container. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5172 >>> >>> I did not do a full review, I just saw some of the changes that made >>> me worry - >>> like renaming API command attribute. Wouldn't that make the older >>> clients fail? >>> >>> See for example permission-* commands, we faced similar situation >>> there and had >>> to rename command attributes potentially used by old clients in the >>> new format. >> >> Yes, it will break older clients. The problem is I cannot keep the legacy >> 'service' parameter for backward compatibility: >> >> Str( >> 'service?', >> cli_name='deprecated_service', >> doc=_('DEPRECATED: Service name of the service vault'), >> ), >> Str( >> 'servicename?', >> cli_name='service', >> doc=_('Service name of the service vault'), >> ), >> >> because it will conflict with a new 'service' parameter: >> >> [Mon Aug 03 17:19:00.197040 2015] [wsgi:error] [pid 9409] ipa: ERROR: >> Failed to >> start IPA: cannot override NameSpace.service value Str('service?', >> cli_name='deprecated_service', doc=Gettext('DEPRECATED: Service name >> of the >> service vault', domain='ipa', localedir=None)) with Str('service*', >> alwaysask=True, cli_name='services', csv=True, doc=u'services to add', >> label=u'member service') >> >> that was added automatically when I added the 'service' attribute member: >> >> attribute_members = { >> 'owner': ['user', 'group', 'service'], >> 'member': ['user', 'group', 'service'], >> } >> >> If there's a way to use a different parameter name for the 'service' >> attribute >> member to avoid conflict with the legacy 'service' parameter please >> let me know. >> >> The other option is to force the client to upgrade to the same version. >> >> Please let me know. Thanks. >> > > Honza, do we have any other options than to break API between 4.2.0 and > 4.2.1? Another option is to keep 2 vault plugins. The old plugin (1.0) will handle old IPA 4.2.0 clients. The new plugin (1.1) will handle the new IPA 4.2.1 clients. For this to work the plugins need to have different API URLs so they won't conflict/confuse the clients. Please also note that my next patch that adds the ability to change vault type, password, and keys will also require a client upgrade because the functionality is mainly implemented on the client side. In this case API URL versioning will be necessary. -- Endi S. Dewata From msimacek at redhat.com Mon Aug 3 21:56:39 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Mon, 3 Aug 2015 23:56:39 +0200 Subject: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi In-Reply-To: <1437989883.8077.2.camel@willson.usersys.redhat.com> References: <2026883365.1326941.1437480146008.JavaMail.zimbra@redhat.com> <1747692317.2396484.1437572854418.JavaMail.zimbra@redhat.com> <55B0BCDF.4070006@redhat.com> <55B53A5F.9@redhat.com> <1437989883.8077.2.camel@willson.usersys.redhat.com> Message-ID: <55BFE397.8080503@redhat.com> On 2015-07-27 11:38, Simo Sorce wrote: > On Sun, 2015-07-26 at 21:51 +0200, Michael ?im??ek wrote: >> It would probably be nicer to do the full cycle, but I'd like to >> avoid >> changes in behavior when porting from one library to another. And the >> code above doesn't actually hold any connection, so it would require >> more refactoring to make that happen. For now I would follow what the >> original code was doing. As for the exceptions, I think it would >> actually be justifiable to use the raw api's init_sec_context, >> because >> the high level api would just do the same call + the exception >> handling >> magic, which we want to avoid for now. Please let me know what do you >> think. >> Attaching updated patch that uses 'unicode' instead of >> raw.display_name >> and reverts back to using init_sec_context. > > Sorry, > but we should really not use the raw API here. > If it means more changes to the code, so be it, please us the high level > API as recommended by Robbie, we wrote a better API so that people would > use it, and we want to apply best practices when changing code in IPA. > Attaching new revision of the patch that performs the full negotiation cycle. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0001-5-Port-from-python-kerberos-to-python-gssapi.patch Type: text/x-patch Size: 10572 bytes Desc: not available URL: From ssorce at redhat.com Mon Aug 3 22:30:57 2015 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 03 Aug 2015 18:30:57 -0400 Subject: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi In-Reply-To: <55BFE397.8080503@redhat.com> References: <2026883365.1326941.1437480146008.JavaMail.zimbra@redhat.com> <1747692317.2396484.1437572854418.JavaMail.zimbra@redhat.com> <55B0BCDF.4070006@redhat.com> <55B53A5F.9@redhat.com> <1437989883.8077.2.camel@willson.usersys.redhat.com> <55BFE397.8080503@redhat.com> Message-ID: <1438641057.20262.6.camel@willson.usersys.redhat.com> On Mon, 2015-08-03 at 23:56 +0200, Michael ?im??ek wrote: > On 2015-07-27 11:38, Simo Sorce wrote: > > On Sun, 2015-07-26 at 21:51 +0200, Michael ?im??ek wrote: > >> It would probably be nicer to do the full cycle, but I'd like to > >> avoid > >> changes in behavior when porting from one library to another. And the > >> code above doesn't actually hold any connection, so it would require > >> more refactoring to make that happen. For now I would follow what the > >> original code was doing. As for the exceptions, I think it would > >> actually be justifiable to use the raw api's init_sec_context, > >> because > >> the high level api would just do the same call + the exception > >> handling > >> magic, which we want to avoid for now. Please let me know what do you > >> think. > >> Attaching updated patch that uses 'unicode' instead of > >> raw.display_name > >> and reverts back to using init_sec_context. > > > > Sorry, > > but we should really not use the raw API here. > > If it means more changes to the code, so be it, please us the high level > > API as recommended by Robbie, we wrote a better API so that people would > > use it, and we want to apply best practices when changing code in IPA. > > > > Attaching new revision of the patch that performs the full negotiation > cycle. > > Michael LGTM Thanks! From simo at redhat.com Mon Aug 3 22:43:43 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 03 Aug 2015 18:43:43 -0400 Subject: [Freeipa-devel] [PATCHES] Replica Promotion #2888 Message-ID: <1438641823.20262.16.camel@willson.usersys.redhat.com> Hello freeipa-devel, this patcheset implement the main piece of the replica promotion feature. It first introduces the custodia modules, custodia is a service that allows to securely transfer secrets between FreeIPA instances, using asymetric crypto and LDAP published keys to insure confidentiality. These patches intentionally duplicate some code in the installer in order to avoid regression in the "classic" installer code path, in the hope that the promotion functionality will not unintentionally break the classic prepare/install code paths. To use test this patchset you need the jwcrypto and custodia python packages. Jwcrypto ins in fedora rawhide already (built today for f22 too) and Custodia is under review. I prepared two copr repositories for now so people can build. Use dnf copr enable simo/jwcrypto and dnf copr enable simo/custodia on your devel VMs to get the proper packages (dnf install custodia will suffice to drag in all dependencies). To test do NOT follow the usual path of creating a replica file on the master server with the ipa-replica-prepare tool. Instead prepare a machine and run: ipa-client-install ipa-replica-install --promote That should be it. You can optionally test the --setup-dns install option, but --setup-ca and --seyup-kra do not work yet. If you kinit admin right after the client install, you'll be asked no passwords. Note that you need to raise the domain level to 1 before you can use the replica promotion code as it is intended to be used with the topology plugin activated. This patchset depends on the previous one sent last week. Cheers, Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-533-1-IPA-Custodia-Daemon.patch Type: text/x-patch Size: 23476 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-534-1-Add-Custodia-Client-code.patch Type: text/x-patch Size: 4462 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-535-1-Install-ipa-custodia-with-the-rest-of-ipa.patch Type: text/x-patch Size: 17032 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-536-1-Implement-replica-promotion-functionality.patch Type: text/x-patch Size: 51035 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-537-1-Change-DNS-installer-code-to-use-passed-in-api.patch Type: text/x-patch Size: 18809 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-538-1-Allow-ipa-replica-conncheck-to-use-default-creds.patch Type: text/x-patch Size: 9888 bytes Desc: not available URL: From edewata at redhat.com Mon Aug 3 23:20:33 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 3 Aug 2015 18:20:33 -0500 Subject: [Freeipa-devel] [PATCH] 371 Added support for changing vault encryption. Message-ID: <55BFF741.6080302@redhat.com> The vault-mod command has been modified to support changing vault encryption attributes (i.e. type, password, public/private keys) in addition to normal attributes (i.e. description). Changing the encryption requires retrieving the stored secret with the old attributes and rearchieving it with the new attributes. https://fedorahosted.org/freeipa/ticket/5176 -- Endi S. Dewata -------------- next part -------------- From e80928fa8e8a099576fcdbff08fd90a634600825 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 31 Jul 2015 07:53:15 +0200 Subject: [PATCH] Added support for changing vault encryption. The vault-mod command has been modified to support changing vault encryption attributes (i.e. type, password, public/private keys) in addition to normal attributes (i.e. description). Changing the encryption requires retrieving the stored secret with the old attributes and rearchieving it with the new attributes. https://fedorahosted.org/freeipa/ticket/5176 --- API.txt | 27 +++++- VERSION | 4 +- ipalib/plugins/vault.py | 239 ++++++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 248 insertions(+), 22 deletions(-) diff --git a/API.txt b/API.txt index 00b47b8709c81217d7f2a69e719093f4a04f1734..bd5c48998056ab94729cb1b475bf444707a883cb 100644 --- a/API.txt +++ b/API.txt @@ -5466,11 +5466,12 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?') option: Str('in?') +option: Flag('override_password?', autofill=True, default=False) option: Str('password?', cli_name='password') option: Str('password_file?', cli_name='password_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -5528,6 +5529,30 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod +args: 1,18,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('change_password?', autofill=True, default=False) +option: Str('description?', cli_name='desc') +option: Bytes('ipavaultsalt?', cli_name='salt') +option: Str('ipavaulttype?', cli_name='type') +option: Str('new_password?', cli_name='new_password') +option: Str('new_password_file?', cli_name='new_password_file') +option: Str('old_password?', cli_name='old_password') +option: Str('old_password_file?', cli_name='old_password_file') +option: Bytes('private_key?', cli_name='private_key') +option: Str('private_key_file?', cli_name='private_key_file') +option: Bytes('public_key?', cli_name='public_key') +option: Str('public_key_file?', cli_name='public_key_file') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_mod_internal args: 1,15,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') diff --git a/VERSION b/VERSION index c42bea06522dae55e1a89ff94ae394594086b467..feb9f4db92c7c7b95e9e5d5907b1f97e96b26886 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=149 -# Last change: edewata - Added CLI param and ACL for vault service operations +IPA_API_VERSION_MINOR=150 +# Last change: edewata - Added support for changing vault encryption. diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 3b62822366a62c90f843a6293589c28383e782ef..5bee6aaae8ddd306d4ee0c273143c9d0ffc913d5 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -133,19 +133,36 @@ EXAMPLES: ipa vault-show --shared """) + _(""" Show a user vault: - ipa vault-show --user + ipa vault-show """) + _(""" - Modify a private vault: - ipa vault-mod --desc + Modify vault description: + ipa vault-mod + [--user |--service |--shared] + --desc """) + _(""" - Modify a service vault: - ipa vault-mod --service --desc + Modify vault type: + ipa vault-mod + [--user |--service |--shared] + --type """) + _(""" - Modify a shared vault: - ipa vault-mod --shared --desc + Modify vault password: + ipa vault-mod + [--user |--service |--shared] + --change-password + ipa vault-mod + [--user |--service |--shared] + --old-password + --new-password + ipa vault-mod + [--user |--service |--shared] + --old-password-file + --new-password-file """) + _(""" - Modify a user vault: - ipa vault-mod --user --desc + Modify vault keys: + ipa vault-mod + [--user |--service |--shared] + --private-key-file + --public-key-file """) + _(""" Delete a private vault: ipa vault-del @@ -478,7 +495,7 @@ class vault(LDAPObject): print ' ** Passwords do not match! **' - def get_existing_password(self, new=False): + def get_existing_password(self): """ Gets existing password from user. """ @@ -818,9 +835,183 @@ class vault_find(LDAPSearch): @register() -class vault_mod(LDAPUpdate): +class vault_mod(PKQuery, Local): __doc__ = _('Modify a vault.') + takes_options = vault_options + ( + Str( + 'description?', + cli_name='desc', + doc=_('Vault description'), + ), + Str( + 'ipavaulttype?', + cli_name='type', + doc=_('Vault type'), + ), + Bytes( + 'ipavaultsalt?', + cli_name='salt', + doc=_('Vault salt'), + ), + Flag( + 'change_password?', + doc=_('Change password'), + ), + Str( + 'old_password?', + cli_name='old_password', + doc=_('Old vault password'), + ), + Str( # TODO: use File parameter + 'old_password_file?', + cli_name='old_password_file', + doc=_('File containing the old vault password'), + ), + Str( + 'new_password?', + cli_name='new_password', + doc=_('New vault password'), + ), + Str( # TODO: use File parameter + 'new_password_file?', + cli_name='new_password_file', + doc=_('File containing the new vault password'), + ), + Bytes( + 'private_key?', + cli_name='private_key', + doc=_('Old vault private key'), + ), + Str( # TODO: use File parameter + 'private_key_file?', + cli_name='private_key_file', + doc=_('File containing the old vault private key'), + ), + Bytes( + 'public_key?', + cli_name='public_key', + doc=_('New vault public key'), + ), + Str( # TODO: use File parameter + 'public_key_file?', + cli_name='public_key_file', + doc=_('File containing the new vault public key'), + ), + ) + + has_output = output.standard_entry + + def forward(self, *args, **options): + + vault_type = options.pop('ipavaulttype', False) + salt = options.pop('ipavaultsalt', False) + change_password = options.pop('change_password', False) + + old_password = options.pop('old_password', None) + old_password_file = options.pop('old_password_file', None) + new_password = options.pop('new_password', None) + new_password_file = options.pop('new_password_file', None) + + old_private_key = options.pop('private_key', None) + old_private_key_file = options.pop('private_key_file', None) + new_public_key = options.pop('public_key', None) + new_public_key_file = options.pop('public_key_file', None) + + if self.api.env.in_server: + backend = self.api.Backend.ldap2 + else: + backend = self.api.Backend.rpcclient + if not backend.isconnected(): + backend.connect(ccache=krbV.default_context().default_ccache()) + + # determine the vault type based on parameters specified + if vault_type: + pass + + elif change_password or \ + new_password or new_password_file or salt: + vault_type = u'symmetric' + + elif new_public_key or new_public_key_file: + vault_type = u'asymmetric' + + # if vault type is specified, retrieve existing secret + if vault_type: + opts = options.copy() + opts.pop('description', None) + + opts['password'] = old_password + opts['password_file'] = old_password_file + opts['private_key'] = old_private_key + opts['private_key_file'] = old_private_key_file + + response = self.api.Command.vault_retrieve(*args, **opts) + data = response['result']['data'] + + opts = options.copy() + + # if vault type is specified, update crypto attributes + if vault_type: + opts['ipavaulttype'] = vault_type + + if vault_type == u'standard': + opts['ipavaultsalt'] = None + opts['ipavaultpublickey'] = None + + elif vault_type == u'symmetric': + if salt: + opts['ipavaultsalt'] = salt + else: + opts['ipavaultsalt'] = os.urandom(16) + + opts['ipavaultpublickey'] = None + + elif vault_type == u'asymmetric': + + # get new vault public key + if new_public_key and new_public_key_file: + raise errors.MutuallyExclusiveError( + reason=_('New public key specified multiple times')) + + elif new_public_key: + pass + + elif new_public_key_file: + new_public_key = validated_read('public_key_file', + new_public_key_file, + mode='rb') + + else: + raise errors.ValidationError( + name='ipavaultpublickey', + error=_('Missing new vault public key')) + + opts['ipavaultsalt'] = None + opts['ipavaultpublickey'] = new_public_key + + response = self.api.Command.vault_mod_internal(*args, **opts) + + # if vault type is specified, rearchive existing secret + if vault_type: + opts = options.copy() + opts.pop('description', None) + + opts['data'] = data + opts['password'] = new_password + opts['password_file'] = new_password_file + opts['override_password'] = True + + self.api.Command.vault_archive(*args, **opts) + + return response + + + at register() +class vault_mod_internal(LDAPUpdate): + + NO_CLI = True + takes_options = LDAPUpdate.takes_options + vault_options msg_summary = _('Modified vault "%(value)s"') @@ -933,6 +1124,10 @@ class vault_archive(PKQuery, Local): cli_name='password_file', doc=_('File containing the vault password'), ), + Flag( + 'override_password?', + doc=_('Override existing password'), + ), ) has_output = output.standard_entry @@ -947,6 +1142,8 @@ class vault_archive(PKQuery, Local): password = options.get('password') password_file = options.get('password_file') + override_password = options.pop('override_password', False) + # don't send these parameters to server if 'data' in options: del options['data'] @@ -1001,15 +1198,19 @@ class vault_archive(PKQuery, Local): password = password.rstrip('\n') else: - password = self.obj.get_existing_password() + if override_password: + password = self.obj.get_new_password() + else: + password = self.obj.get_existing_password() - # verify password by retrieving existing data - opts = options.copy() - opts['password'] = password - try: - self.api.Command.vault_retrieve(*args, **opts) - except errors.NotFound: - pass + if not override_password: + # verify password by retrieving existing data + opts = options.copy() + opts['password'] = password + try: + self.api.Command.vault_retrieve(*args, **opts) + except errors.NotFound: + pass salt = vault['ipavaultsalt'][0] -- 2.4.3 From ftweedal at redhat.com Tue Aug 4 05:21:29 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 4 Aug 2015 15:21:29 +1000 Subject: [Freeipa-devel] [PATCH] 0030 Add permission for bypassing CA ACL enforcement Message-ID: <20150804052129.GG4843@dhcp-40-8.bne.redhat.com> The attached patch fixes https://fedorahosted.org/freeipa/ticket/5099. Thanks, Fraser -------------- next part -------------- From 294205795f595095f14eecb451f974cbf867ebe3 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Tue, 4 Aug 2015 01:13:09 -0400 Subject: [PATCH] Add permission for bypassing CA ACL enforcement Add the "Request Certificate ignoring CA ACLs" permission and associated ACI, initially assigned to "Certificate Administrators" privilege. Update cert-request command to skip CA ACL enforcement when the bind principal has this permission. Fixes: https://fedorahosted.org/freeipa/ticket/5099 --- install/updates/40-delegation.update | 15 +++++++++++++++ ipalib/plugins/cert.py | 13 ++++++++++--- 2 files changed, 25 insertions(+), 3 deletions(-) diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update index bc0736c5b6c07747586a56c2cbde9596c7522d1c..8d4f6296cbed7fcc968c2193022cb50b488c8561 100644 --- a/install/updates/40-delegation.update +++ b/install/updates/40-delegation.update @@ -144,6 +144,21 @@ default:member: cn=Certificate Administrators,cn=privileges,cn=pbac,$SUFFIX dn: $SUFFIX add:aci:(targetattr = "objectclass")(target = "ldap:///cn=request certificate with subjectaltname,cn=virtual operations,cn=etc,$SUFFIX" )(version 3.0; acl "permission:Request Certificate with SubjectAltName"; allow (write) groupdn = "ldap:///cn=Request Certificate with SubjectAltName,cn=permissions,cn=pbac,$SUFFIX";) +dn: cn=request certificate ignore caacl,cn=virtual operations,cn=etc,$SUFFIX +default:objectClass: top +default:objectClass: nsContainer +default:cn: request certificate ignore caacl + +dn: cn=Request Certificate ignoring CA ACLs,cn=permissions,cn=pbac,$SUFFIX +default:objectClass: top +default:objectClass: groupofnames +default:objectClass: ipapermission +default:cn: Request Certificate ignoring CA ACLs +default:member: cn=Certificate Administrators,cn=privileges,cn=pbac,$SUFFIX + +dn: $SUFFIX +add:aci:(targetattr = "objectclass")(target = "ldap:///cn=request certificate ignore caacl,cn=virtual operations,cn=etc,$SUFFIX" )(version 3.0; acl "permission:Request Certificate ignoring CA ACLs"; allow (write) groupdn = "ldap:///cn=Request Certificate ignoring CA ACLs,cn=permissions,cn=pbac,$SUFFIX";) + # Read privileges dn: cn=RBAC Readers,cn=privileges,cn=pbac,$SUFFIX diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 341bdd01766d50ba18ce7147d4408851e6f95487..8c06a9269d00d9bb4095944f965f942b8384aa0f 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -344,8 +344,6 @@ class cert_request(VirtualCommand): else: principal_type = SERVICE - caacl_check(principal_type, principal_string, ca, profile_id) - bind_principal = split_any_principal(getattr(context, 'principal')) bind_service, bind_name, bind_realm = bind_principal @@ -361,6 +359,15 @@ class cert_request(VirtualCommand): self.check_access() try: + self.check_access("request certificate ignore caacl") + bypass_caacl = True + except errors.ACIError: + bypass_caacl = False + + if not bypass_caacl: + caacl_check(principal_type, principal_string, ca, profile_id) + + try: subject = pkcs10.get_subject(csr) extensions = pkcs10.get_extensions(csr) subjectaltname = pkcs10.get_subjectaltname(csr) or () @@ -468,7 +475,7 @@ class cert_request(VirtualCommand): raise errors.ACIError(info=_( "Insufficient privilege to create a certificate " "with subject alt name '%s'.") % name) - if alt_principal_string is not None: + if alt_principal_string is not None and not bypass_caacl: caacl_check( principal_type, alt_principal_string, ca, profile_id) elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, -- 2.4.3 From mkosek at redhat.com Tue Aug 4 06:05:06 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 4 Aug 2015 08:05:06 +0200 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55BFD107.4060105@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> Message-ID: <55C05612.5060604@redhat.com> On 08/03/2015 10:37 PM, Endi Sukma Dewata wrote: > On 8/3/2015 2:47 PM, Martin Kosek wrote: >> On 08/03/2015 05:36 PM, Endi Sukma Dewata wrote: >>> On 8/3/2015 2:31 AM, Martin Kosek wrote: >>>> On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote: >>>>> The CLIs to manage vault owners and members have been modified >>>>> to accept services with a new parameter. Due to name conflict, >>>>> the existing 'service' parameter has been renamed to >>>>> 'servicename'. >>>>> >>>>> A new ACL has been added to allow a service to create its own >>>>> service container. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5172 >>>> >>>> I did not do a full review, I just saw some of the changes that made >>>> me worry - >>>> like renaming API command attribute. Wouldn't that make the older >>>> clients fail? >>>> >>>> See for example permission-* commands, we faced similar situation >>>> there and had >>>> to rename command attributes potentially used by old clients in the >>>> new format. >>> >>> Yes, it will break older clients. The problem is I cannot keep the legacy >>> 'service' parameter for backward compatibility: >>> >>> Str( >>> 'service?', >>> cli_name='deprecated_service', >>> doc=_('DEPRECATED: Service name of the service vault'), >>> ), >>> Str( >>> 'servicename?', >>> cli_name='service', >>> doc=_('Service name of the service vault'), >>> ), >>> >>> because it will conflict with a new 'service' parameter: >>> >>> [Mon Aug 03 17:19:00.197040 2015] [wsgi:error] [pid 9409] ipa: ERROR: >>> Failed to >>> start IPA: cannot override NameSpace.service value Str('service?', >>> cli_name='deprecated_service', doc=Gettext('DEPRECATED: Service name >>> of the >>> service vault', domain='ipa', localedir=None)) with Str('service*', >>> alwaysask=True, cli_name='services', csv=True, doc=u'services to add', >>> label=u'member service') >>> >>> that was added automatically when I added the 'service' attribute member: >>> >>> attribute_members = { >>> 'owner': ['user', 'group', 'service'], >>> 'member': ['user', 'group', 'service'], >>> } >>> >>> If there's a way to use a different parameter name for the 'service' >>> attribute >>> member to avoid conflict with the legacy 'service' parameter please >>> let me know. >>> >>> The other option is to force the client to upgrade to the same version. >>> >>> Please let me know. Thanks. >>> >> >> Honza, do we have any other options than to break API between 4.2.0 and >> 4.2.1? > > Another option is to keep 2 vault plugins. The old plugin (1.0) will handle old > IPA 4.2.0 clients. The new plugin (1.1) will handle the new IPA 4.2.1 clients. > For this to work the plugins need to have different API URLs so they won't > conflict/confuse the clients. We do not have that versions in FreeIPA (yet?). > Please also note that my next patch that adds the ability to change vault type, > password, and keys will also require a client upgrade because the functionality > is mainly implemented on the client side. In this case API URL versioning will > be necessary. Adding new commands and/or attributes is a common thing in FreeIPA. We just do the work, bump the minor API version and that's it. We planned having better version support in FreeIPA 4.4, we will see how it goes. Martin From mbabinsk at redhat.com Tue Aug 4 08:27:02 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 4 Aug 2015 10:27:02 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55BF99AF.3060605@redhat.com> References: <55BF57D5.5020703@redhat.com> <55BF5B3E.60804@redhat.com> <55BF628A.1070204@redhat.com> <55BF656F.5010702@redhat.com> <55BF6F18.3090003@redhat.com> <55BF99AF.3060605@redhat.com> Message-ID: <55C07756.4060106@redhat.com> On 08/03/2015 06:41 PM, Martin Babinsky wrote: > On 08/03/2015 03:39 PM, Jan Cholasta wrote: >> Dne 3.8.2015 v 14:58 Martin Babinsky napsal(a): >>> On 08/03/2015 02:46 PM, Jan Cholasta wrote: >>>> Dne 3.8.2015 v 14:14 Jan Cholasta napsal(a): >>>>> Hi, >>>>> >>>>> Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): >>>>>> This patch fixes the inconsistency between storing certificates in >>>>>> 'userCertificate'/'userCertificate;binary' attribute for the user >>>>>> entries: the certificate must be stored in the latter attribute only. >>>>>> >>>>>> Since a more general fix is out of 4.2.1 scope, I have implemented >>>>>> some >>>>>> workarounds in pre/post callbacks of user-* commands in order to >>>>>> enforce >>>>>> this behavior. >>>>> >>>>> 1) >>>>> >>>>> + def convert_usercertificate_pre(self, entry_attrs, **options): >>>>> + if options.get('all', False): >>>>> + return >>>>> >>>>> We don't want to do any renaming when --raw is specified, not --all. >>>>> Same for convert_usercertificate_post. >>>> >>>> Actually, the attribute should be always renamed in >>>> convert_usercertificate_pre, otherwise we would modify the wrong >>>> attribute. In convert_usercertificate_post, it should actually be >>>> renamed only when --raw is specified. >>>> >>> >>> If you do the rename in `convert_usercertificate_post` only when '--raw' >>> is specified, then you get no certificate displayed when you do `ipa >>> user-show` on user with userCertificate;binary attribute. Is this >>> intended? (Keep in mind that `convert_usercertificate_post` should be >>> called in post-callback when returning results back to user/client). >> >> Oops, I meant "rename only when --raw is *not* specified". >> >>>>> >>>>> >>>>> 2) >>>>> >>>>> + self.obj.convert_usercertificate_pre(entry_attrs, **options) >>>>> >>>>> Rather than calling this directly from user_add, this should be called >>>>> from baseuser.pre_common_callback(), which should be called from >>>>> user_add.post_callback(). >>>>> >>>>> >>>>> 3) IMO you should change user_{add,remove}_cert to call >>>>> baseuser.convert_usercertificate_{pre,post} as well, to avoid code >>>>> duplication. >>>>> >>>>> >>>>> Honza >>>>> >>>> >>>> >>> >>> >> >> > > Attaching updated patch. > > > I have realized that this patch also fixes https://fedorahosted.org/freeipa/ticket/5173 so I have added the link to the commit message. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0052.3-store-certificates-issued-for-user-entries-as-userCe.patch Type: text/x-patch Size: 6476 bytes Desc: not available URL: From lslebodn at redhat.com Tue Aug 4 08:28:40 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 4 Aug 2015 10:28:40 +0200 Subject: [Freeipa-devel] C coding style guide update In-Reply-To: <55B6380E.8040902@redhat.com> References: <55B11485.8020400@redhat.com> <20150726200910.GF22586@hendrix> <55B6380E.8040902@redhat.com> Message-ID: <20150804082840.GE15393@mail.corp.redhat.com> On (27/07/15 15:54), Michal ?idek wrote: >On 07/26/2015 10:09 PM, Jakub Hrozek wrote: >> - Variable Length arrays are very helpful, but explicitly mention >> they should be used with caution, especially if array size might >> come from the user > >+1 >We overuse talloc for very small allocations that can be done >automatically on stack. > They were already used 2.5 year ago (line 3903) 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3893) void nss_update_initgr_memcache(struct nss_ctx *nctx, 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3894) const char *name, const char *domain, 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3895) int gnum, uint32_t *groups) 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3896) { 1f15b746 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-19 08:48:06 -0500 3897) TALLOC_CTX *tmp_ctx = NULL; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3898) struct sss_domain_info *dom; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3899) struct ldb_result *res; 0c517cb7 src/responder/nss/nsssrv_cmd.c (Jakub Hrozek 2013-01-15 07:05:56 +0100 3900) struct sized_string delete_name; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3901) bool changed = false; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3902) uint32_t id; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3903) uint32_t gids[gnum]; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3904) int ret; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3905) int i, j; 408914f6 src/responder/nss/nsssrv_cmd.c (Simo Sorce 2012-12-05 17:40:44 +0000 3906) LS From jcholast at redhat.com Tue Aug 4 09:28:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 4 Aug 2015 11:28:29 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> Message-ID: <55C085BD.40402@redhat.com> Dne 31.7.2015 v 17:08 Gabe Alford napsal(a): > Updated patch attached. > > Thanks, > > Gabe > > On Thu, Jul 30, 2015 at 7:15 AM, Gabe Alford > wrote: > > On Thu, Jul 30, 2015 at 1:32 AM, Jan Cholasta > wrote: > > Dne 30.7.2015 v 09:23 Jan Cholasta napsal(a): > > Hi, > > Dne 29.7.2015 v 17:23 Gabe Alford napsal(a): > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4023 > > > Actually, 0 means unlimited for size limit, see > . > > > After reading the ticket I think this should be fixed the other > way around: make 0 mean unlimited for both time and size limit > and fix the config plugin and LDAPClient to respect that. > > > Thanks for the review. Updated patch attached. We still need to accept -1 in config-mod for backward compatibility - when received, it should be converted to 0. -- Jan Cholasta From ldoudova at redhat.com Tue Aug 4 11:37:46 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 04 Aug 2015 13:37:46 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55BA3051.2070703@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> Message-ID: <55C0A40A.8080606@redhat.com> Dne 30.7.2015 v 16:10 Martin Basti napsal(a): > On 30/07/15 16:09, Martin Basti wrote: >> On 29/07/15 16:10, Martin Basti wrote: >>> On 29/07/15 15:29, Lenka Doudova wrote: >>>> Hi, >>>> >>>> thanks a lot for the comments, will work on it tomorrow. >>>> >>>> Lenka >>>> >>>> Dne 29.7.2015 v 15:27 Martin Basti napsal(a): >>>>> On 27/07/15 16:47, Lenka Doudova wrote: >>>>>> Hi, >>>>>> >>>>>> I'm attaching a patch with automated tests for stageuser plugin >>>>>> (https://fedorahosted.org/freeipa/ticket/3813). The user plugin >>>>>> test is affected as well (one class was added). >>>>>> The tests seem a bit of a mess even to myself, but what with the >>>>>> way freeipa behaves I didn't know how else to implement them, but >>>>>> I'm eager to learn how to do it in a nicer way, if someone has a >>>>>> better idea. >>>>>> >>>>>> Lenka >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I just applied patches: >>>>> >>>>> 1) Please remove whitespace errors >>>>> $ git am >>>>> freeipa-lryznaro-0002-Automated-test-for-stageuser-plugin.patch >>>>> Applying: Automated test for stageuser plugin >>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:110: >>>>> trailing whitespace. >>>>> """ Tracker class for staged user LDAP object >>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:113: >>>>> trailing whitespace. >>>>> StageUserTracker object stores information about the user. >>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:121: >>>>> trailing whitespace. >>>>> u'krbprincipalexpiration', u'usercertificate', u'dn', >>>>> u'has_keytab', u'has_password', >>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:122: >>>>> trailing whitespace. >>>>> u'street', u'postalcode', u'facsimiletelephonenumber', >>>>> u'carlicense', >>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:125: >>>>> trailing whitespace. >>>>> u'cn', u'ipauniqueid', u'objectclass', u'description', >>>>> warning: squelched 50 whitespace errors >>>>> warning: 55 lines add whitespace errors. >>>>> >>>>> 2) >>>>> Please use new shorter format of license header >>>>> >>>>> 3) can you fix some of the most serious PEP8 errors >>>>> $ git show -U0 | pep8 --diff | wc -l >>>>> 198 >>>>> >>>>> 4) >>>>> if options != None: >>>>> >>>>> Please use "options *is not* None" >>>>> >>>>> 5) >>>>> For consistency it should be u'random' >>>>> if key == 'random': >>>>> self.attrs[u'randompassword'] = fuzzy_string >>>>> >>>>> Otherwise it looks good >>>>> Martin^2 >>>>> -- >>>>> Martin Basti >>>> >>> And also fix this please >>> >>> ./make-lint >>> ************* Module ipatests.test_xmlrpc.test_stageuser_plugin >>> ipatests/test_xmlrpc/test_stageuser_plugin.py:337: >>> [E0102(function-redefined), user2] function already defined line 44) >>> >>> -- >>> Martin Basti >>> >>> >> Ahoj, v patchi mas este uvedene svoje stare meno, mala by si v gite >> nastavit redhat email >> >> -- >> Martin Basti >> >> > Sorry for spam, you can safely ignore this. :) > > -- > Martin Basti > > Attaching new patch - (hopefully) fixed the errors from the old one + few test cases were added. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0002-Automated-test-for-stageuser-plugin.patch Type: text/x-patch Size: 53398 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Aug 4 11:50:49 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 4 Aug 2015 13:50:49 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55C07756.4060106@redhat.com> References: <55BF57D5.5020703@redhat.com> <55BF5B3E.60804@redhat.com> <55BF628A.1070204@redhat.com> <55BF656F.5010702@redhat.com> <55BF6F18.3090003@redhat.com> <55BF99AF.3060605@redhat.com> <55C07756.4060106@redhat.com> Message-ID: <55C0A719.8040404@redhat.com> On 08/04/2015 10:27 AM, Martin Babinsky wrote: > On 08/03/2015 06:41 PM, Martin Babinsky wrote: >> On 08/03/2015 03:39 PM, Jan Cholasta wrote: >>> Dne 3.8.2015 v 14:58 Martin Babinsky napsal(a): >>>> On 08/03/2015 02:46 PM, Jan Cholasta wrote: >>>>> Dne 3.8.2015 v 14:14 Jan Cholasta napsal(a): >>>>>> Hi, >>>>>> >>>>>> Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): >>>>>>> This patch fixes the inconsistency between storing certificates in >>>>>>> 'userCertificate'/'userCertificate;binary' attribute for the user >>>>>>> entries: the certificate must be stored in the latter attribute >>>>>>> only. >>>>>>> >>>>>>> Since a more general fix is out of 4.2.1 scope, I have implemented >>>>>>> some >>>>>>> workarounds in pre/post callbacks of user-* commands in order to >>>>>>> enforce >>>>>>> this behavior. >>>>>> >>>>>> 1) >>>>>> >>>>>> + def convert_usercertificate_pre(self, entry_attrs, **options): >>>>>> + if options.get('all', False): >>>>>> + return >>>>>> >>>>>> We don't want to do any renaming when --raw is specified, not --all. >>>>>> Same for convert_usercertificate_post. >>>>> >>>>> Actually, the attribute should be always renamed in >>>>> convert_usercertificate_pre, otherwise we would modify the wrong >>>>> attribute. In convert_usercertificate_post, it should actually be >>>>> renamed only when --raw is specified. >>>>> >>>> >>>> If you do the rename in `convert_usercertificate_post` only when >>>> '--raw' >>>> is specified, then you get no certificate displayed when you do `ipa >>>> user-show` on user with userCertificate;binary attribute. Is this >>>> intended? (Keep in mind that `convert_usercertificate_post` should be >>>> called in post-callback when returning results back to user/client). >>> >>> Oops, I meant "rename only when --raw is *not* specified". >>> >>>>>> >>>>>> >>>>>> 2) >>>>>> >>>>>> + self.obj.convert_usercertificate_pre(entry_attrs, **options) >>>>>> >>>>>> Rather than calling this directly from user_add, this should be >>>>>> called >>>>>> from baseuser.pre_common_callback(), which should be called from >>>>>> user_add.post_callback(). >>>>>> >>>>>> >>>>>> 3) IMO you should change user_{add,remove}_cert to call >>>>>> baseuser.convert_usercertificate_{pre,post} as well, to avoid code >>>>>> duplication. >>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> Attaching updated patch. >> >> >> > > I have realized that this patch also fixes > https://fedorahosted.org/freeipa/ticket/5173 so I have added the link to > the commit message. > > > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0052.4-store-certificates-issued-for-user-entries-as-userCe.patch Type: text/x-patch Size: 6422 bytes Desc: not available URL: From jcholast at redhat.com Tue Aug 4 11:57:59 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 4 Aug 2015 13:57:59 +0200 Subject: [Freeipa-devel] [PATCH 0052] store user certificates in 'userCertificate; binary' attributes In-Reply-To: <55C0A719.8040404@redhat.com> References: <55BF57D5.5020703@redhat.com> <55BF5B3E.60804@redhat.com> <55BF628A.1070204@redhat.com> <55BF656F.5010702@redhat.com> <55BF6F18.3090003@redhat.com> <55BF99AF.3060605@redhat.com> <55C07756.4060106@redhat.com> <55C0A719.8040404@redhat.com> Message-ID: <55C0A8C7.7080207@redhat.com> Dne 4.8.2015 v 13:50 Martin Babinsky napsal(a): > On 08/04/2015 10:27 AM, Martin Babinsky wrote: >> On 08/03/2015 06:41 PM, Martin Babinsky wrote: >>> On 08/03/2015 03:39 PM, Jan Cholasta wrote: >>>> Dne 3.8.2015 v 14:58 Martin Babinsky napsal(a): >>>>> On 08/03/2015 02:46 PM, Jan Cholasta wrote: >>>>>> Dne 3.8.2015 v 14:14 Jan Cholasta napsal(a): >>>>>>> Hi, >>>>>>> >>>>>>> Dne 3.8.2015 v 14:00 Martin Babinsky napsal(a): >>>>>>>> This patch fixes the inconsistency between storing certificates in >>>>>>>> 'userCertificate'/'userCertificate;binary' attribute for the user >>>>>>>> entries: the certificate must be stored in the latter attribute >>>>>>>> only. >>>>>>>> >>>>>>>> Since a more general fix is out of 4.2.1 scope, I have implemented >>>>>>>> some >>>>>>>> workarounds in pre/post callbacks of user-* commands in order to >>>>>>>> enforce >>>>>>>> this behavior. >>>>>>> >>>>>>> 1) >>>>>>> >>>>>>> + def convert_usercertificate_pre(self, entry_attrs, **options): >>>>>>> + if options.get('all', False): >>>>>>> + return >>>>>>> >>>>>>> We don't want to do any renaming when --raw is specified, not --all. >>>>>>> Same for convert_usercertificate_post. >>>>>> >>>>>> Actually, the attribute should be always renamed in >>>>>> convert_usercertificate_pre, otherwise we would modify the wrong >>>>>> attribute. In convert_usercertificate_post, it should actually be >>>>>> renamed only when --raw is specified. >>>>>> >>>>> >>>>> If you do the rename in `convert_usercertificate_post` only when >>>>> '--raw' >>>>> is specified, then you get no certificate displayed when you do `ipa >>>>> user-show` on user with userCertificate;binary attribute. Is this >>>>> intended? (Keep in mind that `convert_usercertificate_post` should be >>>>> called in post-callback when returning results back to user/client). >>>> >>>> Oops, I meant "rename only when --raw is *not* specified". >>>> >>>>>>> >>>>>>> >>>>>>> 2) >>>>>>> >>>>>>> + self.obj.convert_usercertificate_pre(entry_attrs, >>>>>>> **options) >>>>>>> >>>>>>> Rather than calling this directly from user_add, this should be >>>>>>> called >>>>>>> from baseuser.pre_common_callback(), which should be called from >>>>>>> user_add.post_callback(). >>>>>>> >>>>>>> >>>>>>> 3) IMO you should change user_{add,remove}_cert to call >>>>>>> baseuser.convert_usercertificate_{pre,post} as well, to avoid code >>>>>>> duplication. >>>>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> Attaching updated patch. >>> >>> >>> >> >> I have realized that this patch also fixes >> https://fedorahosted.org/freeipa/ticket/5173 so I have added the link to >> the commit message. >> >> >> > Attaching updated patch. > Thanks, ACK. Pushed to: master: 3257ac6b876e9e62cae58060c96c525ff0df1ae3 ipa-4-2: 8b3ed42d6b2bab57793b9921a672ed8994469109 -- Jan Cholasta From simo at redhat.com Tue Aug 4 12:20:03 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Aug 2015 08:20:03 -0400 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55C05612.5060604@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> Message-ID: <1438690803.20262.25.camel@willson.usersys.redhat.com> On Tue, 2015-08-04 at 08:05 +0200, Martin Kosek wrote: > On 08/03/2015 10:37 PM, Endi Sukma Dewata wrote: > > On 8/3/2015 2:47 PM, Martin Kosek wrote: > >> On 08/03/2015 05:36 PM, Endi Sukma Dewata wrote: > >>> On 8/3/2015 2:31 AM, Martin Kosek wrote: > >>>> On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote: > >>>>> The CLIs to manage vault owners and members have been modified > >>>>> to accept services with a new parameter. Due to name conflict, > >>>>> the existing 'service' parameter has been renamed to > >>>>> 'servicename'. > >>>>> > >>>>> A new ACL has been added to allow a service to create its own > >>>>> service container. > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/5172 > >>>> > >>>> I did not do a full review, I just saw some of the changes that made > >>>> me worry - > >>>> like renaming API command attribute. Wouldn't that make the older > >>>> clients fail? > >>>> > >>>> See for example permission-* commands, we faced similar situation > >>>> there and had > >>>> to rename command attributes potentially used by old clients in the > >>>> new format. > >>> > >>> Yes, it will break older clients. The problem is I cannot keep the legacy > >>> 'service' parameter for backward compatibility: > >>> > >>> Str( > >>> 'service?', > >>> cli_name='deprecated_service', > >>> doc=_('DEPRECATED: Service name of the service vault'), > >>> ), > >>> Str( > >>> 'servicename?', > >>> cli_name='service', > >>> doc=_('Service name of the service vault'), > >>> ), > >>> > >>> because it will conflict with a new 'service' parameter: > >>> > >>> [Mon Aug 03 17:19:00.197040 2015] [wsgi:error] [pid 9409] ipa: ERROR: > >>> Failed to > >>> start IPA: cannot override NameSpace.service value Str('service?', > >>> cli_name='deprecated_service', doc=Gettext('DEPRECATED: Service name > >>> of the > >>> service vault', domain='ipa', localedir=None)) with Str('service*', > >>> alwaysask=True, cli_name='services', csv=True, doc=u'services to add', > >>> label=u'member service') > >>> > >>> that was added automatically when I added the 'service' attribute member: > >>> > >>> attribute_members = { > >>> 'owner': ['user', 'group', 'service'], > >>> 'member': ['user', 'group', 'service'], > >>> } > >>> > >>> If there's a way to use a different parameter name for the 'service' > >>> attribute > >>> member to avoid conflict with the legacy 'service' parameter please > >>> let me know. > >>> > >>> The other option is to force the client to upgrade to the same version. > >>> > >>> Please let me know. Thanks. > >>> > >> > >> Honza, do we have any other options than to break API between 4.2.0 and > >> 4.2.1? > > > > Another option is to keep 2 vault plugins. The old plugin (1.0) will handle old > > IPA 4.2.0 clients. The new plugin (1.1) will handle the new IPA 4.2.1 clients. > > For this to work the plugins need to have different API URLs so they won't > > conflict/confuse the clients. > > We do not have that versions in FreeIPA (yet?). > > > Please also note that my next patch that adds the ability to change vault type, > > password, and keys will also require a client upgrade because the functionality > > is mainly implemented on the client side. In this case API URL versioning will > > be necessary. > > Adding new commands and/or attributes is a common thing in FreeIPA. We just do > the work, bump the minor API version and that's it. We planned having better > version support in FreeIPA 4.4, we will see how it goes. Martin, I do not think going on with business as usual is the right thing to do here. We know this is going to bite. I suggest Endy adds a *new* API if making it backwards compatible is not possible. The era of bumping whole API version must stop, the sooner the better. Simo. -- Simo Sorce * Red Hat, Inc * New York From tech at floriancrouzat.net Tue Aug 4 13:13:01 2015 From: tech at floriancrouzat.net (Florian Crouzat) Date: Tue, 04 Aug 2015 15:13:01 +0200 Subject: [Freeipa-devel] Exporting users "access formulars" Message-ID: <55C0BA5D.6030507@floriancrouzat.net> Hey, For security reason (mostly PCI-DSS) I have to print and sign-off access formular for every users, and also to maintain these formulars in time which means that every time I add a host to a hostgroup for example, I should reprint all access formulars for users with access to this hostgroup... I was wondering if it was possible to develop a feature that would allow one to select a user(s) from GUI and generate a csv/pdf/whatever file with all direct and indirect memberships/access for HBAC, groups and sudo-rule for the selected user(s). Maybe a first step would be to script something around ipa CLI commands (not sure if possible to dig into HBAC and groups from CLI though). What are your thoughts on such need, am I the only one wanting to export my users privileges directly from the software managing these privileges ? Regards, Florian From rcritten at redhat.com Tue Aug 4 13:44:42 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Aug 2015 09:44:42 -0400 Subject: [Freeipa-devel] 4.1 branch is broken Message-ID: <55C0C1CA.9020703@redhat.com> Commit 4d2ef43f broke the 4.1 branch. There is no ipaplatform/paths.py. rob From tbabej at redhat.com Tue Aug 4 13:49:41 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 4 Aug 2015 15:49:41 +0200 Subject: [Freeipa-devel] 4.1 branch is broken In-Reply-To: <55C0C1CA.9020703@redhat.com> References: <55C0C1CA.9020703@redhat.com> Message-ID: <55C0C2F5.9070506@redhat.com> On 08/04/2015 03:44 PM, Rob Crittenden wrote: > Commit 4d2ef43f broke the 4.1 branch. There is no ipaplatform/paths.py. > > rob > I don't think so, that particular commit is from May 29 2014, which predates the release of FreeIPA 4.0. This file (along with couple of other platform dependant files) is generated as part of make version-update. Tomas From mkosek at redhat.com Tue Aug 4 13:51:45 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 4 Aug 2015 15:51:45 +0200 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <1438690803.20262.25.camel@willson.usersys.redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> <1438690803.20262.25.camel@willson.usersys.redhat.com> Message-ID: <55C0C371.5060000@redhat.com> On 08/04/2015 02:20 PM, Simo Sorce wrote: > On Tue, 2015-08-04 at 08:05 +0200, Martin Kosek wrote: >> On 08/03/2015 10:37 PM, Endi Sukma Dewata wrote: >>> On 8/3/2015 2:47 PM, Martin Kosek wrote: >>>> On 08/03/2015 05:36 PM, Endi Sukma Dewata wrote: >>>>> On 8/3/2015 2:31 AM, Martin Kosek wrote: >>>>>> On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote: >>>>>>> The CLIs to manage vault owners and members have been modified >>>>>>> to accept services with a new parameter. Due to name conflict, >>>>>>> the existing 'service' parameter has been renamed to >>>>>>> 'servicename'. >>>>>>> >>>>>>> A new ACL has been added to allow a service to create its own >>>>>>> service container. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5172 >>>>>> >>>>>> I did not do a full review, I just saw some of the changes that made >>>>>> me worry - >>>>>> like renaming API command attribute. Wouldn't that make the older >>>>>> clients fail? >>>>>> >>>>>> See for example permission-* commands, we faced similar situation >>>>>> there and had >>>>>> to rename command attributes potentially used by old clients in the >>>>>> new format. >>>>> >>>>> Yes, it will break older clients. The problem is I cannot keep the legacy >>>>> 'service' parameter for backward compatibility: >>>>> >>>>> Str( >>>>> 'service?', >>>>> cli_name='deprecated_service', >>>>> doc=_('DEPRECATED: Service name of the service vault'), >>>>> ), >>>>> Str( >>>>> 'servicename?', >>>>> cli_name='service', >>>>> doc=_('Service name of the service vault'), >>>>> ), >>>>> >>>>> because it will conflict with a new 'service' parameter: >>>>> >>>>> [Mon Aug 03 17:19:00.197040 2015] [wsgi:error] [pid 9409] ipa: ERROR: >>>>> Failed to >>>>> start IPA: cannot override NameSpace.service value Str('service?', >>>>> cli_name='deprecated_service', doc=Gettext('DEPRECATED: Service name >>>>> of the >>>>> service vault', domain='ipa', localedir=None)) with Str('service*', >>>>> alwaysask=True, cli_name='services', csv=True, doc=u'services to add', >>>>> label=u'member service') >>>>> >>>>> that was added automatically when I added the 'service' attribute member: >>>>> >>>>> attribute_members = { >>>>> 'owner': ['user', 'group', 'service'], >>>>> 'member': ['user', 'group', 'service'], >>>>> } >>>>> >>>>> If there's a way to use a different parameter name for the 'service' >>>>> attribute >>>>> member to avoid conflict with the legacy 'service' parameter please >>>>> let me know. >>>>> >>>>> The other option is to force the client to upgrade to the same version. >>>>> >>>>> Please let me know. Thanks. >>>>> >>>> >>>> Honza, do we have any other options than to break API between 4.2.0 and >>>> 4.2.1? >>> >>> Another option is to keep 2 vault plugins. The old plugin (1.0) will handle old >>> IPA 4.2.0 clients. The new plugin (1.1) will handle the new IPA 4.2.1 clients. >>> For this to work the plugins need to have different API URLs so they won't >>> conflict/confuse the clients. >> >> We do not have that versions in FreeIPA (yet?). >> >>> Please also note that my next patch that adds the ability to change vault type, >>> password, and keys will also require a client upgrade because the functionality >>> is mainly implemented on the client side. In this case API URL versioning will >>> be necessary. >> >> Adding new commands and/or attributes is a common thing in FreeIPA. We just do >> the work, bump the minor API version and that's it. We planned having better >> version support in FreeIPA 4.4, we will see how it goes. > > Martin, I do not think going on with business as usual is the right > thing to do here. We know this is going to bite. > I suggest Endy adds a *new* API if making it backwards compatible is not > possible. The era of bumping whole API version must stop, the sooner the > better. My point is that we do not know yet how to do this kind of changes long term. So what I did not want to end up are 2 copy&pasted Vault plugins maintained forever, differing in just that. If you know how to do this without copypasting, I will be fine with that. From rcritten at redhat.com Tue Aug 4 13:52:25 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Aug 2015 09:52:25 -0400 Subject: [Freeipa-devel] 4.1 branch is broken In-Reply-To: <55C0C2F5.9070506@redhat.com> References: <55C0C1CA.9020703@redhat.com> <55C0C2F5.9070506@redhat.com> Message-ID: <55C0C399.6030608@redhat.com> Tomas Babej wrote: > > > On 08/04/2015 03:44 PM, Rob Crittenden wrote: >> Commit 4d2ef43f broke the 4.1 branch. There is no ipaplatform/paths.py. >> >> rob >> > > I don't think so, that particular commit is from May 29 2014, which > predates the release of FreeIPA 4.0. > > This file (along with couple of other platform dependant files) is > generated as part of make version-update. > > Tomas > You're right, my mistake. rob From rharwood at redhat.com Tue Aug 4 15:02:54 2015 From: rharwood at redhat.com (Robbie Harwood) Date: Tue, 04 Aug 2015 11:02:54 -0400 Subject: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi In-Reply-To: <55BFE397.8080503@redhat.com> References: <2026883365.1326941.1437480146008.JavaMail.zimbra@redhat.com> <1747692317.2396484.1437572854418.JavaMail.zimbra@redhat.com> <55B0BCDF.4070006@redhat.com> <55B53A5F.9@redhat.com> <1437989883.8077.2.camel@willson.usersys.redhat.com> <55BFE397.8080503@redhat.com> Message-ID: Michael ?im??ek writes: > Attaching new revision of the patch that performs the full negotiation > cycle. Looks good to me, thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From edewata at redhat.com Tue Aug 4 15:32:18 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 4 Aug 2015 10:32:18 -0500 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55C0C371.5060000@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> <1438690803.20262.25.camel@willson.usersys.redhat.com> <55C0C371.5060000@redhat.com> Message-ID: <55C0DB02.8080306@redhat.com> On 8/4/2015 8:51 AM, Martin Kosek wrote: >>>> Please also note that my next patch that adds the ability to change vault type, >>>> password, and keys will also require a client upgrade because the functionality >>>> is mainly implemented on the client side. In this case API URL versioning will >>>> be necessary. >>> >>> Adding new commands and/or attributes is a common thing in FreeIPA. We just do >>> the work, bump the minor API version and that's it. We planned having better >>> version support in FreeIPA 4.4, we will see how it goes. >> >> Martin, I do not think going on with business as usual is the right >> thing to do here. We know this is going to bite. >> I suggest Endy adds a *new* API if making it backwards compatible is not >> possible. The era of bumping whole API version must stop, the sooner the >> better. > > My point is that we do not know yet how to do this kind of changes long term. > So what I did not want to end up are 2 copy&pasted Vault plugins maintained > forever, differing in just that. > > If you know how to do this without copypasting, I will be fine with that. We probably can do it like this: * the old plugin continues to provide Vault 1.0 functionality * the new plugin will be a proxy to the old plugin except for the parts that have changed in Vault 1.1. Or the other way around: * the new plugin will provide Vault 1.1 functionality * the old plugin will be a proxy to the new plugin except for the parts that needs to be maintained for Vault 1.0. The first option is probably safer. In any case, IPA 4.2.1 will only provide a single client for Vault 1.1, but two services for Vault 1.0 and 1.1. -- Endi S. Dewata From mbabinsk at redhat.com Tue Aug 4 15:39:01 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 4 Aug 2015 17:39:01 +0200 Subject: [Freeipa-devel] Update of User Certificates design page Message-ID: <55C0DC95.9030400@redhat.com> Hello list, I am working on the update of http://www.freeipa.org/page/V4/User_Certificates design page. For now I have edited the "Feature Management" and "Howto Test" sections. Since this is my first time writing/editing designs, there surely is a room for improvement. Feel free to send me corrections or edit the parts you don't like outright. -- Martin^3 Babinsky From jpazdziora at redhat.com Tue Aug 4 16:47:45 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 4 Aug 2015 18:47:45 +0200 Subject: [Freeipa-devel] Update of User Certificates design page In-Reply-To: <55C0DC95.9030400@redhat.com> References: <55C0DC95.9030400@redhat.com> Message-ID: <20150804164745.GA1422@redhat.com> On Tue, Aug 04, 2015 at 05:39:01PM +0200, Martin Babinsky wrote: > > I am working on the update of > http://www.freeipa.org/page/V4/User_Certificates design page. > > For now I have edited the "Feature Management" and "Howto Test" sections. > > Since this is my first time writing/editing designs, there surely is a room > for improvement. Feel free to send me corrections or edit the parts you > don't like outright. The caIPAuserCert.txt file (content) is missing. Not sure if we want to recommend sed '1d;$d' cert.pem -- maybe command to convert to DER and then base64-encode would be more generic? That add ldap_user_certificate = userCertificate;binary to the domain section of sssd.conf step -- will it stay or is sssd going to be updated to use that value automagically? In that case, link to the ticket we are waiting for (https://fedorahosted.org/sssd/ticket/2742 ?) should be added so that it's clear that this step should be removed when the ticket is addressed. Otherwise, great effort with the How to Test section. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From ftweedal at redhat.com Wed Aug 5 04:10:51 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 5 Aug 2015 14:10:51 +1000 Subject: [Freeipa-devel] [PATCH] 0031 certprofile: add profile format explanation Message-ID: <20150805041051.GN4843@dhcp-40-8.bne.redhat.com> The attached patch addresses https://fedorahosted.org/freeipa/ticket/5089 Thanks, Fraser -------------- next part -------------- From 6002c60a4794c0e6ecc315e21575ef618cff6f06 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 23 Jul 2015 23:07:10 -0400 Subject: [PATCH] certprofile: add profile format explanation Part of: https://fedorahosted.org/freeipa/ticket/5089 --- ipalib/plugins/certprofile.py | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 658fbca3b4eb851eb5a22190c443044f6ceb8491..1dd4f403ee4461b83c053eb36019a8896506bb81 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -47,9 +47,29 @@ EXAMPLES: Show information about a profile: ipa certprofile-show ShortLivedUserCert + Save profile configuration to a file: + ipa certprofile-show caIPAserviceCert --out caIPAserviceCert.cfg + Search for profiles that do not store certificates: ipa certprofile-find --store=false +PROFILE CONFIGURATION FORMAT: + +The profile configuration format is the raw property-list format +used by Dogtag Certificate System. The XML format is not supported. + +The following restrictions apply to profiles managed by FreeIPA: + +- When importing a profile the "profileId" field, if present, must + match the ID given on the command line. + +- The "classId" field must be set to "caEnrollImpl" + +- The "auth.instance_id" field must be set to "raCertAuth" + +- The "certReqInputImpl" input class and "certOutputImpl" output + class must be used. + """) -- 2.4.3 From ftweedal at redhat.com Wed Aug 5 05:51:33 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 5 Aug 2015 15:51:33 +1000 Subject: [Freeipa-devel] [PATCH] 0032 Fix otptoken-remove-managedby command summary Message-ID: <20150805055133.GO4843@dhcp-40-8.bne.redhat.com> Small doc fix. Cheers, Fraser -------------- next part -------------- From 2879f147cacef06f0b3373ac21a78b9d08f8afbb Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Wed, 5 Aug 2015 15:50:07 +1000 Subject: [PATCH] Fix otptoken-remove-managedby command summary --- ipalib/plugins/otptoken.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py index 07df0ee3ee29032aaee35f1afc4d0b882d67ea75..a1e9a85a5d3acde9f5aa9f4cc19563e1d8672aba 100644 --- a/ipalib/plugins/otptoken.py +++ b/ipalib/plugins/otptoken.py @@ -467,7 +467,7 @@ class otptoken_add_managedby(LDAPAddMember): @register() class otptoken_remove_managedby(LDAPRemoveMember): - __doc__ = _('Remove hosts that can manage this host.') + __doc__ = _('Remove users that can manage this token.') member_attributes = ['managedby'] -- 2.4.3 From jcholast at redhat.com Wed Aug 5 06:09:01 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 5 Aug 2015 08:09:01 +0200 Subject: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi In-Reply-To: References: <2026883365.1326941.1437480146008.JavaMail.zimbra@redhat.com> <1747692317.2396484.1437572854418.JavaMail.zimbra@redhat.com> <55B0BCDF.4070006@redhat.com> <55B53A5F.9@redhat.com> <1437989883.8077.2.camel@willson.usersys.redhat.com> <55BFE397.8080503@redhat.com> Message-ID: <55C1A87D.2020600@redhat.com> Dne 4.8.2015 v 17:02 Robbie Harwood napsal(a): > Michael ?im??ek writes: > >> Attaching new revision of the patch that performs the full negotiation >> cycle. > > Looks good to me, thanks! IPA compiles and installs fine with the patch applied, so ACK. Pushed to master: f0b4c4487ed77a3037cbbc46206d598c58f06bb1 -- Jan Cholasta From jcholast at redhat.com Wed Aug 5 06:20:52 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 5 Aug 2015 08:20:52 +0200 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <1438339605.24296.4.camel@willson.usersys.redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> Message-ID: <55C1AB44.9020807@redhat.com> Hi, Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): > I've been carrying these patches in my tree for a while, I think it is > time to put them in master as they stand on their own. > > Simo. Patch 530: ACK Patch 531: ACK Patch 532: The methods should be static methods: @staticmethod def setOption(name, value): ... Honza -- Jan Cholasta From mbasti at redhat.com Wed Aug 5 09:27:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 5 Aug 2015 05:27:51 -0400 (EDT) Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55BF89EA.3050901@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> Message-ID: <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> ----- Original Message ----- From: "thierry bordaz" To: "Jan Cholasta" Cc: freeipa-devel at redhat.com Sent: Monday, August 3, 2015 5:34:02 PM Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged On 07/28/2015 12:34 PM, Jan Cholasta wrote: > Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >> >> >> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>> On 23/07/15 14:43, Martin Basti wrote: >>>>> Hello, >>>>> >>>>> I tried to fix #5145 and I partially succeeded. >>>>> >>>>> However, I cannot fix this part of ticket, where user is prompted to >>>>> write name and surname. >>>>> >>>>> $ ipa stageuser-add tuser --from-delete >>>>> First name: this will be ignored >>>>> Last name: this will be also ignored >>>>> ------------------------ >>>>> Added stage user "tuser" >>>>> ------------------------ >>>>> >>>>> As the first name and last name are mandatory attributes of >>>>> stageuser-add command, but they are not needed by when the >>>>> --from-delete option is used. >>>>> I would like to ask how to fix this issue, IMO this will be huge hack >>>>> in internal API. Or should we just document this bug as known issue >>>>> (thierry wrote that this is not use case that should be used often)? >>>>> >>>>> The best solution would be separate command, but this idea was >>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>> regarding the design" >>>>> >>>>> Regards >>>>> Martin^2 >>>>> >>>> Hello, >>>> >>>> as was mentioned before, we have issue with current internal API >>>> and the >>>> stageuser-add --from-delete command. >>>> >>>> We discussed this today, and we did not find a nice way how to fix it, >>>> so we propose this (which is IMO the best solution): >>>> >>>> * stageuser-add --from-delete should be deprecated >>> >>> +1 >>> >>>> * create new option for user-undel: used-undel --to-staged (or create >>>> new command) that will handle moving deleted users to staged area as >>>> --from-delete did. >>> >>> Make it new command please. >>> >>>> >>>> Instead of stageuser-add and option --from-delete, which work totally >>>> different, the command user-undel does similar operation than >>>> stage-user >>>> --from-delete, it just uses different container. >>> >>> NACK on stuffing everything into a single command just because it does >>> something similar. >> >> How about making it a 'stageuser-undel'? The 'user-undel' moves >> preserved user to active, so the 'stageuser-undel' would move preserved >> to staged. The action is similar, but has slightly different specifics >> (which attributes are preserved etc.), and for me the 'stageuser-undel' >> feels more natural than 'user-undel --to-staged' since it's basically >> the same as there is 'stageuser-add' for creating a staged user, not >> 'user-add --to-staged'. It would be in the same style as all the other >> commands concerning operations with users in staged container. > > Well, user-undel is the opposite of user-del, and stageuser-undel > should be the opposite of stageuser-del. The stageuser-undel you are > suggesting is not. > > Also I'm not sure if we want to (always) remove the deleted user once > a staged user is created from it, but -undel behaves like that. > > I don't think the command should be limited to deleted users only. > Active and deleted users share the same namespace, so it is an > arbitrary limitation. preserved users has been valid active user. In that sense active/preserved are managed by a same set of CLI (user-find,user-del,user-show) because a preserved user is a 'user'. So I would vote for continuing with a 'user-*' commands and use 'user-undel --to-stage'. But then if we will make any incompatible change between "user-undel" and "user-undel --to-stage" we may hit this issue again. I agree with Honza, this should be a separate command. Martin2 > > I think that what we are looking for is the opposite of > stageuser-activate. So maybe user-stage? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From tbordaz at redhat.com Wed Aug 5 09:55:41 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 05 Aug 2015 11:55:41 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> Message-ID: <55C1DD9D.8000806@redhat.com> On 08/05/2015 11:27 AM, Martin Basti wrote: > > ----- Original Message ----- > From: "thierry bordaz" > To: "Jan Cholasta" > Cc: freeipa-devel at redhat.com > Sent: Monday, August 3, 2015 5:34:02 PM > Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged > > On 07/28/2015 12:34 PM, Jan Cholasta wrote: >> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>> >>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>> Hello, >>>>>> >>>>>> I tried to fix #5145 and I partially succeeded. >>>>>> >>>>>> However, I cannot fix this part of ticket, where user is prompted to >>>>>> write name and surname. >>>>>> >>>>>> $ ipa stageuser-add tuser --from-delete >>>>>> First name: this will be ignored >>>>>> Last name: this will be also ignored >>>>>> ------------------------ >>>>>> Added stage user "tuser" >>>>>> ------------------------ >>>>>> >>>>>> As the first name and last name are mandatory attributes of >>>>>> stageuser-add command, but they are not needed by when the >>>>>> --from-delete option is used. >>>>>> I would like to ask how to fix this issue, IMO this will be huge hack >>>>>> in internal API. Or should we just document this bug as known issue >>>>>> (thierry wrote that this is not use case that should be used often)? >>>>>> >>>>>> The best solution would be separate command, but this idea was >>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>> regarding the design" >>>>>> >>>>>> Regards >>>>>> Martin^2 >>>>>> >>>>> Hello, >>>>> >>>>> as was mentioned before, we have issue with current internal API >>>>> and the >>>>> stageuser-add --from-delete command. >>>>> >>>>> We discussed this today, and we did not find a nice way how to fix it, >>>>> so we propose this (which is IMO the best solution): >>>>> >>>>> * stageuser-add --from-delete should be deprecated >>>> +1 >>>> >>>>> * create new option for user-undel: used-undel --to-staged (or create >>>>> new command) that will handle moving deleted users to staged area as >>>>> --from-delete did. >>>> Make it new command please. >>>> >>>>> Instead of stageuser-add and option --from-delete, which work totally >>>>> different, the command user-undel does similar operation than >>>>> stage-user >>>>> --from-delete, it just uses different container. >>>> NACK on stuffing everything into a single command just because it does >>>> something similar. >>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>> preserved user to active, so the 'stageuser-undel' would move preserved >>> to staged. The action is similar, but has slightly different specifics >>> (which attributes are preserved etc.), and for me the 'stageuser-undel' >>> feels more natural than 'user-undel --to-staged' since it's basically >>> the same as there is 'stageuser-add' for creating a staged user, not >>> 'user-add --to-staged'. It would be in the same style as all the other >>> commands concerning operations with users in staged container. >> Well, user-undel is the opposite of user-del, and stageuser-undel >> should be the opposite of stageuser-del. The stageuser-undel you are >> suggesting is not. >> >> Also I'm not sure if we want to (always) remove the deleted user once >> a staged user is created from it, but -undel behaves like that. >> >> I don't think the command should be limited to deleted users only. >> Active and deleted users share the same namespace, so it is an >> arbitrary limitation. > preserved users has been valid active user. In that sense > active/preserved are managed by a same set of CLI > (user-find,user-del,user-show) because a preserved user is a 'user'. So > I would vote for continuing with a 'user-*' commands and use 'user-undel > --to-stage'. > > But then if we will make any incompatible change between "user-undel" and "user-undel --to-stage" we may hit this issue again. I agree with Honza, this should be a separate command. What do you mean 'incompatible change' ? --to-stage option would only select a different container that the 'Active' one ? thanks thierry > Martin2 > >> I think that what we are looking for is the opposite of >> stageuser-activate. So maybe user-stage? > From jcholast at redhat.com Wed Aug 5 10:13:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 5 Aug 2015 12:13:42 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55C1DD9D.8000806@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> Message-ID: <55C1E1D6.1060104@redhat.com> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): > On 08/05/2015 11:27 AM, Martin Basti wrote: >> >> ----- Original Message ----- >> From: "thierry bordaz" >> To: "Jan Cholasta" >> Cc: freeipa-devel at redhat.com >> Sent: Monday, August 3, 2015 5:34:02 PM >> Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with >> user-undel --to-staged >> >> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>> >>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>> >>>>>>> However, I cannot fix this part of ticket, where user is prompted to >>>>>>> write name and surname. >>>>>>> >>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>> First name: this will be ignored >>>>>>> Last name: this will be also ignored >>>>>>> ------------------------ >>>>>>> Added stage user "tuser" >>>>>>> ------------------------ >>>>>>> >>>>>>> As the first name and last name are mandatory attributes of >>>>>>> stageuser-add command, but they are not needed by when the >>>>>>> --from-delete option is used. >>>>>>> I would like to ask how to fix this issue, IMO this will be huge >>>>>>> hack >>>>>>> in internal API. Or should we just document this bug as known issue >>>>>>> (thierry wrote that this is not use case that should be used often)? >>>>>>> >>>>>>> The best solution would be separate command, but this idea was >>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>> regarding the design" >>>>>>> >>>>>>> Regards >>>>>>> Martin^2 >>>>>>> >>>>>> Hello, >>>>>> >>>>>> as was mentioned before, we have issue with current internal API >>>>>> and the >>>>>> stageuser-add --from-delete command. >>>>>> >>>>>> We discussed this today, and we did not find a nice way how to fix >>>>>> it, >>>>>> so we propose this (which is IMO the best solution): >>>>>> >>>>>> * stageuser-add --from-delete should be deprecated >>>>> +1 >>>>> >>>>>> * create new option for user-undel: used-undel --to-staged (or >>>>>> create >>>>>> new command) that will handle moving deleted users to staged area as >>>>>> --from-delete did. >>>>> Make it new command please. >>>>> >>>>>> Instead of stageuser-add and option --from-delete, which work totally >>>>>> different, the command user-undel does similar operation than >>>>>> stage-user >>>>>> --from-delete, it just uses different container. >>>>> NACK on stuffing everything into a single command just because it does >>>>> something similar. >>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>> preserved user to active, so the 'stageuser-undel' would move preserved >>>> to staged. The action is similar, but has slightly different specifics >>>> (which attributes are preserved etc.), and for me the 'stageuser-undel' >>>> feels more natural than 'user-undel --to-staged' since it's basically >>>> the same as there is 'stageuser-add' for creating a staged user, not >>>> 'user-add --to-staged'. It would be in the same style as all the other >>>> commands concerning operations with users in staged container. >>> Well, user-undel is the opposite of user-del, and stageuser-undel >>> should be the opposite of stageuser-del. The stageuser-undel you are >>> suggesting is not. >>> >>> Also I'm not sure if we want to (always) remove the deleted user once >>> a staged user is created from it, but -undel behaves like that. >>> >>> I don't think the command should be limited to deleted users only. >>> Active and deleted users share the same namespace, so it is an >>> arbitrary limitation. >> preserved users has been valid active user. In that sense >> active/preserved are managed by a same set of CLI >> (user-find,user-del,user-show) because a preserved user is a 'user'. So >> I would vote for continuing with a 'user-*' commands and use 'user-undel >> --to-stage'. >> >> But then if we will make any incompatible change between "user-undel" >> and "user-undel --to-stage" we may hit this issue again. I agree with >> Honza, this should be a separate command. > What do you mean 'incompatible change' ? > > --to-stage option would only select a different container that the > 'Active' one ? That's not sufficient. The command should do the reverse of stageuser-activate, which is ADD and DELETE, possibly with some modifications of the entry between them, not MODRDN like user-undel does. -- Jan Cholasta From tbabej at redhat.com Wed Aug 5 10:29:14 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 5 Aug 2015 12:29:14 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Fix otptoken-remove-managedby command summary In-Reply-To: <20150805055133.GO4843@dhcp-40-8.bne.redhat.com> References: <20150805055133.GO4843@dhcp-40-8.bne.redhat.com> Message-ID: <55C1E57A.8030508@redhat.com> On 08/05/2015 07:51 AM, Fraser Tweedale wrote: > Small doc fix. > > Cheers, > Fraser > > > ACK, thanks for catching this. Pushed to: master: e28a45072004d93ced9bf81b3810fbd2652664b5 ipa-4-2: dc0745650a0172bb66350fb453ec4285e31a32ad Tomas From tbordaz at redhat.com Wed Aug 5 10:34:39 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 05 Aug 2015 12:34:39 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55C1E1D6.1060104@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> Message-ID: <55C1E6BF.1060309@redhat.com> On 08/05/2015 12:13 PM, Jan Cholasta wrote: > Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >> On 08/05/2015 11:27 AM, Martin Basti wrote: >>> >>> ----- Original Message ----- >>> From: "thierry bordaz" >>> To: "Jan Cholasta" >>> Cc: freeipa-devel at redhat.com >>> Sent: Monday, August 3, 2015 5:34:02 PM >>> Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with >>> user-undel --to-staged >>> >>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>> >>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>> >>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>> prompted to >>>>>>>> write name and surname. >>>>>>>> >>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>> First name: this will be ignored >>>>>>>> Last name: this will be also ignored >>>>>>>> ------------------------ >>>>>>>> Added stage user "tuser" >>>>>>>> ------------------------ >>>>>>>> >>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>> --from-delete option is used. >>>>>>>> I would like to ask how to fix this issue, IMO this will be huge >>>>>>>> hack >>>>>>>> in internal API. Or should we just document this bug as known >>>>>>>> issue >>>>>>>> (thierry wrote that this is not use case that should be used >>>>>>>> often)? >>>>>>>> >>>>>>>> The best solution would be separate command, but this idea was >>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>>> regarding the design" >>>>>>>> >>>>>>>> Regards >>>>>>>> Martin^2 >>>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> as was mentioned before, we have issue with current internal API >>>>>>> and the >>>>>>> stageuser-add --from-delete command. >>>>>>> >>>>>>> We discussed this today, and we did not find a nice way how to fix >>>>>>> it, >>>>>>> so we propose this (which is IMO the best solution): >>>>>>> >>>>>>> * stageuser-add --from-delete should be deprecated >>>>>> +1 >>>>>> >>>>>>> * create new option for user-undel: used-undel --to-staged (or >>>>>>> create >>>>>>> new command) that will handle moving deleted users to staged >>>>>>> area as >>>>>>> --from-delete did. >>>>>> Make it new command please. >>>>>> >>>>>>> Instead of stageuser-add and option --from-delete, which work >>>>>>> totally >>>>>>> different, the command user-undel does similar operation than >>>>>>> stage-user >>>>>>> --from-delete, it just uses different container. >>>>>> NACK on stuffing everything into a single command just because it >>>>>> does >>>>>> something similar. >>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>>> preserved user to active, so the 'stageuser-undel' would move >>>>> preserved >>>>> to staged. The action is similar, but has slightly different >>>>> specifics >>>>> (which attributes are preserved etc.), and for me the >>>>> 'stageuser-undel' >>>>> feels more natural than 'user-undel --to-staged' since it's basically >>>>> the same as there is 'stageuser-add' for creating a staged user, not >>>>> 'user-add --to-staged'. It would be in the same style as all the >>>>> other >>>>> commands concerning operations with users in staged container. >>>> Well, user-undel is the opposite of user-del, and stageuser-undel >>>> should be the opposite of stageuser-del. The stageuser-undel you are >>>> suggesting is not. >>>> >>>> Also I'm not sure if we want to (always) remove the deleted user once >>>> a staged user is created from it, but -undel behaves like that. >>>> >>>> I don't think the command should be limited to deleted users only. >>>> Active and deleted users share the same namespace, so it is an >>>> arbitrary limitation. >>> preserved users has been valid active user. In that sense >>> active/preserved are managed by a same set of CLI >>> (user-find,user-del,user-show) because a preserved user is a 'user'. So >>> I would vote for continuing with a 'user-*' commands and use >>> 'user-undel >>> --to-stage'. >>> >>> But then if we will make any incompatible change between "user-undel" >>> and "user-undel --to-stage" we may hit this issue again. I agree with >>> Honza, this should be a separate command. >> What do you mean 'incompatible change' ? >> >> --to-stage option would only select a different container that the >> 'Active' one ? > > That's not sufficient. The command should do the reverse of > stageuser-activate, which is ADD and DELETE, possibly with some > modifications of the entry between them, not MODRDN like user-undel does. > That is a good point. Do we need to modify anything from a deleted entry to a add it in the stage container. Already delete entry have been purged of several values (password, krb keys, membership,..) do you think of other attributes to remove ? IIRC the use case is a support engineer who activated too early an entry. So you are right he wants to unactivate it. A question is does the unactivation requires more modifications than the one did by 'user-del --preserve'. Note that we can not retrieve the attribute values when the entry was activated from stage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Wed Aug 5 10:53:08 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 5 Aug 2015 12:53:08 +0200 Subject: [Freeipa-devel] Exporting users "access formulars" In-Reply-To: <55C0BA5D.6030507@floriancrouzat.net> References: <55C0BA5D.6030507@floriancrouzat.net> Message-ID: <55C1EB14.3080308@redhat.com> On 08/04/2015 03:13 PM, Florian Crouzat wrote: > Hey, > > For security reason (mostly PCI-DSS) I have to print and sign-off access > formular for every users, and also to maintain these formulars in time > which means that every time I add a host to a hostgroup for example, I > should reprint all access formulars for users with access to this > hostgroup... > > I was wondering if it was possible to develop a feature that would allow > one to select a user(s) from GUI and generate a csv/pdf/whatever file > with all direct and indirect memberships/access for HBAC, groups and > sudo-rule for the selected user(s). > > Maybe a first step would be to script something around ipa CLI commands > (not sure if possible to dig into HBAC and groups from CLI though). > > What are your thoughts on such need, am I the only one wanting to export > my users privileges directly from the software managing these privileges ? > > Regards, > Florian > I'd recommend building a script to generate such a report, I'm not really sure it's a feature that would fit directly into the core at this state. You can access IPA's API directly using Python, which can be leveraged to generate a report using a suitable Python library, such as reportlab. Using the API you will get access to all the information available to you via the ipa command line tool. Examples of using Python API are available on the net, for example here's one user's submission which landed on the list some time ago: https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py API can be easily inspected in 4.2 using our new API browser: https://fedorahosted.org/freeipa/ticket/3129 If you're on a older release, adding -vv flag to any ipa command will do the job as well. HTH, Tomas From mkosek at redhat.com Wed Aug 5 12:32:37 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 5 Aug 2015 14:32:37 +0200 Subject: [Freeipa-devel] Exporting users "access formulars" In-Reply-To: <55C1EB14.3080308@redhat.com> References: <55C0BA5D.6030507@floriancrouzat.net> <55C1EB14.3080308@redhat.com> Message-ID: <55C20265.90900@redhat.com> On 08/05/2015 12:53 PM, Tomas Babej wrote: > > > On 08/04/2015 03:13 PM, Florian Crouzat wrote: >> Hey, >> >> For security reason (mostly PCI-DSS) I have to print and sign-off access >> formular for every users, and also to maintain these formulars in time >> which means that every time I add a host to a hostgroup for example, I >> should reprint all access formulars for users with access to this >> hostgroup... >> >> I was wondering if it was possible to develop a feature that would allow >> one to select a user(s) from GUI and generate a csv/pdf/whatever file >> with all direct and indirect memberships/access for HBAC, groups and >> sudo-rule for the selected user(s). >> >> Maybe a first step would be to script something around ipa CLI commands >> (not sure if possible to dig into HBAC and groups from CLI though). >> >> What are your thoughts on such need, am I the only one wanting to export >> my users privileges directly from the software managing these privileges ? >> >> Regards, >> Florian >> > > I'd recommend building a script to generate such a report, I'm not > really sure it's a feature that would fit directly into the core at this > state. > > You can access IPA's API directly using Python, which can be leveraged > to generate a report using a suitable Python library, such as reportlab. > > Using the API you will get access to all the information available to > you via the ipa command line tool. > > Examples of using Python API are available on the net, for example > here's one user's submission which landed on the list some time ago: > > https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py > > API can be easily inspected in 4.2 using our new API browser: > > https://fedorahosted.org/freeipa/ticket/3129 > > If you're on a older release, adding -vv flag to any ipa command will do > the job as well. > > HTH, > > Tomas > "ipa user-show USER --all" should show user and all group memberships, including special roles or permission in the RBAC. I am not sure about finding respective HBAC or SUDO rules, hbac-find or sudorule-find does not offer searching by user. I am afraid that for current versions, raw "ldapsearch" would need to be used. From tech at floriancrouzat.net Wed Aug 5 12:39:06 2015 From: tech at floriancrouzat.net (Florian Crouzat) Date: Wed, 05 Aug 2015 14:39:06 +0200 Subject: [Freeipa-devel] Exporting users "access formulars" In-Reply-To: <55C20265.90900@redhat.com> References: <55C0BA5D.6030507@floriancrouzat.net> <55C1EB14.3080308@redhat.com> <55C20265.90900@redhat.com> Message-ID: <55C203EA.2020706@floriancrouzat.net> On 08/05/2015 02:32 PM, Martin Kosek wrote: > On 08/05/2015 12:53 PM, Tomas Babej wrote: >> >> >> On 08/04/2015 03:13 PM, Florian Crouzat wrote: >>> Hey, >>> >>> For security reason (mostly PCI-DSS) I have to print and sign-off access >>> formular for every users, and also to maintain these formulars in time >>> which means that every time I add a host to a hostgroup for example, I >>> should reprint all access formulars for users with access to this >>> hostgroup... >>> >>> I was wondering if it was possible to develop a feature that would allow >>> one to select a user(s) from GUI and generate a csv/pdf/whatever file >>> with all direct and indirect memberships/access for HBAC, groups and >>> sudo-rule for the selected user(s). >>> >>> Maybe a first step would be to script something around ipa CLI commands >>> (not sure if possible to dig into HBAC and groups from CLI though). >>> >>> What are your thoughts on such need, am I the only one wanting to export >>> my users privileges directly from the software managing these privileges ? >>> >>> Regards, >>> Florian >>> >> >> I'd recommend building a script to generate such a report, I'm not >> really sure it's a feature that would fit directly into the core at this >> state. >> >> You can access IPA's API directly using Python, which can be leveraged >> to generate a report using a suitable Python library, such as reportlab. >> >> Using the API you will get access to all the information available to >> you via the ipa command line tool. >> >> Examples of using Python API are available on the net, for example >> here's one user's submission which landed on the list some time ago: >> >> https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py >> >> API can be easily inspected in 4.2 using our new API browser: >> >> https://fedorahosted.org/freeipa/ticket/3129 >> >> If you're on a older release, adding -vv flag to any ipa command will do >> the job as well. >> >> HTH, >> >> Tomas >> > > "ipa user-show USER --all" should show user and all group memberships, > including special roles or permission in the RBAC. > > I am not sure about finding respective HBAC or SUDO rules, hbac-find or > sudorule-find does not offer searching by user. I am afraid that for current > versions, raw "ldapsearch" would need to be used. > I wrote a shell script (bash+awk) that "do the job" by using "ipa user-show FOO" and looping over each hbac (ipa hbacrule-show), sudo (ipa sudorule-show), and groups (ipa group-show) ... But it's ugly and really dependant on the output of these commands. As Tomas said, there is an API and I could probably do it from python but I'm no dev so I'll stick my poor's man script for the moment... I was just hoping that this need would meet other people needs and hopefully justify the addition of a button in the GUI to export all theses informations automagically... But I know it's a lot to ask, and definitely not the top priority. Florian From mkosek at redhat.com Wed Aug 5 12:45:06 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 5 Aug 2015 14:45:06 +0200 Subject: [Freeipa-devel] Exporting users "access formulars" In-Reply-To: <55C203EA.2020706@floriancrouzat.net> References: <55C0BA5D.6030507@floriancrouzat.net> <55C1EB14.3080308@redhat.com> <55C20265.90900@redhat.com> <55C203EA.2020706@floriancrouzat.net> Message-ID: <55C20552.6030304@redhat.com> On 08/05/2015 02:39 PM, Florian Crouzat wrote: > On 08/05/2015 02:32 PM, Martin Kosek wrote: >> On 08/05/2015 12:53 PM, Tomas Babej wrote: >>> >>> >>> On 08/04/2015 03:13 PM, Florian Crouzat wrote: >>>> Hey, >>>> >>>> For security reason (mostly PCI-DSS) I have to print and sign-off access >>>> formular for every users, and also to maintain these formulars in time >>>> which means that every time I add a host to a hostgroup for example, I >>>> should reprint all access formulars for users with access to this >>>> hostgroup... >>>> >>>> I was wondering if it was possible to develop a feature that would allow >>>> one to select a user(s) from GUI and generate a csv/pdf/whatever file >>>> with all direct and indirect memberships/access for HBAC, groups and >>>> sudo-rule for the selected user(s). >>>> >>>> Maybe a first step would be to script something around ipa CLI commands >>>> (not sure if possible to dig into HBAC and groups from CLI though). >>>> >>>> What are your thoughts on such need, am I the only one wanting to export >>>> my users privileges directly from the software managing these privileges ? >>>> >>>> Regards, >>>> Florian >>>> >>> >>> I'd recommend building a script to generate such a report, I'm not >>> really sure it's a feature that would fit directly into the core at this >>> state. >>> >>> You can access IPA's API directly using Python, which can be leveraged >>> to generate a report using a suitable Python library, such as reportlab. >>> >>> Using the API you will get access to all the information available to >>> you via the ipa command line tool. >>> >>> Examples of using Python API are available on the net, for example >>> here's one user's submission which landed on the list some time ago: >>> >>> https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py >>> >>> API can be easily inspected in 4.2 using our new API browser: >>> >>> https://fedorahosted.org/freeipa/ticket/3129 >>> >>> If you're on a older release, adding -vv flag to any ipa command will do >>> the job as well. >>> >>> HTH, >>> >>> Tomas >>> >> >> "ipa user-show USER --all" should show user and all group memberships, >> including special roles or permission in the RBAC. >> >> I am not sure about finding respective HBAC or SUDO rules, hbac-find or >> sudorule-find does not offer searching by user. I am afraid that for current >> versions, raw "ldapsearch" would need to be used. >> > > I wrote a shell script (bash+awk) that "do the job" by using "ipa > user-show FOO" and looping over each hbac (ipa hbacrule-show), sudo (ipa > sudorule-show), and groups (ipa group-show) ... But it's ugly and really > dependant on the output of these commands. Right, this is not ideal and you may hit speed problems when you have hundreds of SUDO or HBAC rules. So as I said, it may be better to do "ldapsearch" with proper filter to find out all SUDO/HBAC rules for given user, get the name of such rule and if show it with "show" command if needed. > As Tomas said, there is an API and I could probably do it from python > but I'm no dev so I'll stick my poor's man script for the moment... > > I was just hoping that this need would meet other people needs and > hopefully justify the addition of a button in the GUI to export all > theses informations automagically... But I know it's a lot to ask, and > definitely not the top priority. > > Florian > From mkubik at redhat.com Wed Aug 5 12:57:16 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 5 Aug 2015 14:57:16 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches Message-ID: <55C2082C.6090907@redhat.com> Hi list, I'm sending the test plan [1] for certificate profiles and preliminary patches for it. The plan covers basic CRUD test and some corner cases. I'm open to more suggestions. More complicated tests involving certificate profiles will require the code (and tests) for CA ACLs merged, so it's not there at the moment. There are some unfinished test cases in places I wasn't sure what the result should be. We need to iterate through these to fix it. [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan Cheers, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0008-ipatests-Add-Certprofile-tracker-class-implementatio.patch Type: text/x-patch Size: 5516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0009-ipatests-Add-basic-tests-for-certificate-profile-plu.patch Type: text/x-patch Size: 29443 bytes Desc: not available URL: From simo at redhat.com Wed Aug 5 15:24:49 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 05 Aug 2015 11:24:49 -0400 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <55C1AB44.9020807@redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> Message-ID: <1438788289.20262.40.camel@willson.usersys.redhat.com> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: > Hi, > > Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): > > I've been carrying these patches in my tree for a while, I think it is > > time to put them in master as they stand on their own. > > > > Simo. > > Patch 530: ACK > > Patch 531: ACK > > Patch 532: > > The methods should be static methods: > > @staticmethod > def setOption(name, value): > ... Care to explain why ? @staticmethod is not used anywhere else in that file. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Wed Aug 5 15:33:15 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 5 Aug 2015 17:33:15 +0200 Subject: [Freeipa-devel] [PATCH 0355] Fix incorrect type comparison in trust-fetch-domains Message-ID: <55C22CBB.8030603@redhat.com> Hi, Value needs to be unpacked from the list and converted before comparison. https://fedorahosted.org/freeipa/ticket/5182 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0355-Fix-incorrect-type-comparison-in-trust-fetch-domains.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From abokovoy at redhat.com Wed Aug 5 18:23:02 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Aug 2015 21:23:02 +0300 Subject: [Freeipa-devel] [PATCH 0355] Fix incorrect type comparison in trust-fetch-domains In-Reply-To: <55C22CBB.8030603@redhat.com> References: <55C22CBB.8030603@redhat.com> Message-ID: <20150805182302.GM31709@redhat.com> On Wed, 05 Aug 2015, Tomas Babej wrote: >Hi, > > Value needs to be unpacked from the list and converted before comparison. > >https://fedorahosted.org/freeipa/ticket/5182 >From dee59d971acb733c1dee06a61cc0d79ac2f4fdb7 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 5 Aug 2015 17:31:47 +0200 >Subject: [PATCH] Fix incorrect type comparison in trust-fetch-domains > >Value needs to be unpacked from the list and converted before comparison. > >https://fedorahosted.org/freeipa/ticket/5182 >--- > ipalib/plugins/trust.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py >index 91ffaf7feadba0d180e0e95c54f7187cf71d0170..940e06a5ffa387c6cc18983d7b56f089f58a236e 100644 >--- a/ipalib/plugins/trust.py >+++ b/ipalib/plugins/trust.py >@@ -1487,7 +1487,7 @@ class trust_fetch_domains(LDAPRetrieve): > result['truncated'] = False > > # For one-way trust fetch over DBus. we don't get the list in this case. >- if trust['ipanttrustdirection'] & TRUST_BIDIRECTIONAL != TRUST_BIDIRECTIONAL: >+ if int(trust['ipanttrustdirection'][0]) != TRUST_BIDIRECTIONAL: > fetch_trusted_domains_over_dbus(self.api, self.log, keys[0]) > result['summary'] = unicode(_('List of trust domains successfully refreshed. Use trustdomain-find command to list them.')) > return result On one hand, ipanttrustdirection is a bitmask with only two possible bits could be set (TRUST_BIDIRECTIONAL is 00000011 for that reason). You could have AD as a trusted, not trusting domain (e.g. AD trusts us but we don't trust AD) in future. But we should be able to use the same dbus fetcher for both these cases and shouldn't use it for bidirectional yet because we can rely on Kerberos cross-realm TGTs. So, ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Aug 5 18:24:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Aug 2015 21:24:56 +0300 Subject: [Freeipa-devel] [PATCH 0355] Fix incorrect type comparison in trust-fetch-domains In-Reply-To: <55C22CBB.8030603@redhat.com> References: <55C22CBB.8030603@redhat.com> Message-ID: <20150805182456.GN31709@redhat.com> On Wed, 05 Aug 2015, Tomas Babej wrote: >Hi, > > Value needs to be unpacked from the list and converted before comparison. > >https://fedorahosted.org/freeipa/ticket/5182 One more -- this is bug https://bugzilla.redhat.com/show_bug.cgi?id=1250190, I think. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Aug 5 18:40:37 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 5 Aug 2015 21:40:37 +0300 Subject: [Freeipa-devel] [PATCH] 0194 Fix selector of protocol for LSA RPC binding string Message-ID: <20150805184037.GP31709@redhat.com> Hi, attached patch fixes a bug https://bugzilla.redhat.com/show_bug.cgi?id=1249455 details are in the commit message. -- / Alexander Bokovoy -------------- next part -------------- From 3e5edd4d8f334c053bf2e216d25b14f40590a7c4 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 5 Aug 2015 21:33:45 +0300 Subject: [PATCH] Fix selector of protocol for LSA RPC binding string For Windows Server 2012R2 and others which force SMB2 protocol use we have to specify right DCE RPC binding options. For using SMB1 protocol we have to omit specifying SMB2 protocol and anything else or otherwise SMB1 would be considered a pipe to connect to. This is by design of a binding string format. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1249455 diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index be6313e..f334eef 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -855,8 +855,8 @@ class TrustDomainInstance(object): We try NCACN_NP before NCACN_IP_TCP and use SMB2 before SMB1 or defaults. """ transports = (u'ncacn_np', u'ncacn_ip_tcp') - options = ( u'smb2', u'smb1', u'') - binding_template=lambda x,y,z: u'%s:%s[%s,print]' % (x, y, z) + options = ( u'smb2,print', u'print') + binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) return [binding_template(t, remote_host, o) for t in transports for o in options] def retrieve_anonymously(self, remote_host, discover_srv=False, search_pdc=False): -- 2.4.3 From edewata at redhat.com Wed Aug 5 22:21:42 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 5 Aug 2015 17:21:42 -0500 Subject: [Freeipa-devel] Installation issue on F23 Message-ID: <55C28C76.5010602@redhat.com> Hi, Just FYI, the recent IPA installation issue on F23 has been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1250724 by installing a new TomcatJSS package: https://admin.fedoraproject.org/updates/tomcatjss-7.1.3-1.fc23 The PKI dependency on TomcatJSS will be updated in the following ticket: https://fedorahosted.org/pki/ticket/1542 Once this is completed, please update the IPA dependency on PKI. Thanks. -- Endi S. Dewata From jcholast at redhat.com Thu Aug 6 05:21:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 6 Aug 2015 07:21:06 +0200 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <1438788289.20262.40.camel@willson.usersys.redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> Message-ID: <55C2EEC2.9090704@redhat.com> Dne 5.8.2015 v 17:24 Simo Sorce napsal(a): > On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: >> Hi, >> >> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): >>> I've been carrying these patches in my tree for a while, I think it is >>> time to put them in master as they stand on their own. >>> >>> Simo. >> >> Patch 530: ACK >> >> Patch 531: ACK >> >> Patch 532: >> >> The methods should be static methods: >> >> @staticmethod >> def setOption(name, value): >> ... > > Care to explain why ? > @staticmethod is not used anywhere else in that file. Because the methods do not use any instance or class state. They will of course work fine even if they are normal methods, but making them static methods is cleaner. -- Jan Cholasta From jcholast at redhat.com Thu Aug 6 06:22:40 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 6 Aug 2015 08:22:40 +0200 Subject: [Freeipa-devel] [PATCHES 466-468] install: Add common base class for server and replica install Message-ID: <55C2FD30.4030303@redhat.com> Hi, the attached patch fixes part of . See also Martin Babinsky's patch 51: . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-466-install-Support-overriding-knobs-in-subclasses.patch Type: text/x-patch Size: 12257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-467-install-Add-common-base-class-for-server-and-replica.patch Type: text/x-patch Size: 43920 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-468-install-Move-unattended-option-to-the-general-help-s.patch Type: text/x-patch Size: 2027 bytes Desc: not available URL: From tbabej at redhat.com Thu Aug 6 08:11:51 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 6 Aug 2015 10:11:51 +0200 Subject: [Freeipa-devel] [PATCH 0356] trusts: Detect missing Samba instance Message-ID: <55C316C7.8060806@redhat.com> Hi, In the event of invocation of trust related commands, IPA server needs to contact local Samba instance. This is not possible on servers that merely act as AD trust agents, since they do not have Samba instance running. Properly detect the absence of the Samba instance and output user-friendly message which includes list of servers that are capable of running the command, if such exist. List of commands affected: * ipa trust-add * ipa trust-fetch-domains * all of the trustdomain commands available via CLI https://fedorahosted.org/freeipa/ticket/5165 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0356-trusts-Detect-missing-Samba-instance.patch Type: text/x-patch Size: 6811 bytes Desc: not available URL: From tbabej at redhat.com Thu Aug 6 08:17:15 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 6 Aug 2015 10:17:15 +0200 Subject: [Freeipa-devel] [PATCH 0355] Fix incorrect type comparison in trust-fetch-domains In-Reply-To: <20150805182456.GN31709@redhat.com> References: <55C22CBB.8030603@redhat.com> <20150805182456.GN31709@redhat.com> Message-ID: <55C3180B.2020305@redhat.com> On 08/05/2015 08:24 PM, Alexander Bokovoy wrote: > On Wed, 05 Aug 2015, Tomas Babej wrote: >> Hi, >> >> Value needs to be unpacked from the list and converted before comparison. >> >> https://fedorahosted.org/freeipa/ticket/5182 > One more -- this is bug > https://bugzilla.redhat.com/show_bug.cgi?id=1250190, I think. > Pushed to: master: 7688bbcc33eb24a86ede7dc12ea9c64a27006aa8 ipa-4-2: 2812242df4fefcb6567dc3a117b5e55a3211de92 From tbabej at redhat.com Thu Aug 6 08:37:31 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 6 Aug 2015 10:37:31 +0200 Subject: [Freeipa-devel] [PATCH] 0194 Fix selector of protocol for LSA RPC binding string In-Reply-To: <20150805184037.GP31709@redhat.com> References: <20150805184037.GP31709@redhat.com> Message-ID: <55C31CCB.4080808@redhat.com> On 08/05/2015 08:40 PM, Alexander Bokovoy wrote: > Hi, > > attached patch fixes a bug > https://bugzilla.redhat.com/show_bug.cgi?id=1249455 > > details are in the commit message. > > > Looks good to me, generates bindings strings as described in the BZ. Just a readability nitpick, can we get rid of the binding_template lambda abstraction and use something like this? binding_template=u'%s:%s[%s]' return [binding_template % (t, remote_host, o) for t in transports for o in options] or just plain: return [u'%s:%s[%s]' % (t, remote_host, o) for t in transports for o in options] instead of: binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) return [binding_template(t, remote_host, o) for t in transports for o in options] Tomas From tbabej at redhat.com Thu Aug 6 08:55:18 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 6 Aug 2015 10:55:18 +0200 Subject: [Freeipa-devel] [PATCH 0357] trusts: Detect domain clash with IPA domain when adding a AD Message-ID: <55C320F6.4010009@redhat.com> Hi, When IPA is deployed in the same domain as AD, trust-add fails since the names of the local domain and trusted domain ranges is the same - it's always DOMAIN.NAME_id_range. When adding a trusted domain, we look for previous ranges for this domain (which may have been left behind by previous trust attempts). Since AD and IPA are in the same domain, we find a local domain range, which does not have a SID. Detect such domain collisions early and bail out with an appropriate error message. https://fedorahosted.org/freeipa/ticket/4549 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0357-trusts-Detect-domain-clash-with-IPA-domain-when-addi.patch Type: text/x-patch Size: 1668 bytes Desc: not available URL: From slaznick at redhat.com Thu Aug 6 10:33:34 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Thu, 6 Aug 2015 12:33:34 +0200 Subject: [Freeipa-devel] Time-Based Account Policies In-Reply-To: <20150803143028.GF31709@redhat.com> References: <55BF2C6B.3070205@redhat.com> <20150803094534.GB31709@redhat.com> <55BF76D9.4060200@redhat.com> <20150803143028.GF31709@redhat.com> Message-ID: <55C337FE.2030104@redhat.com> On 08/03/2015 04:30 PM, Alexander Bokovoy wrote: > On Mon, 03 Aug 2015, Stanislav Laznicka wrote: >>>> dragons may appear, although with a tiny tiny possibility of a >>>> golden treasure in the end. >>> Yes, I think intervals are required. >>> >> Alright. I gave it a little thought considering the current state of >> the language for time rules and considering where I should go with >> these intervals. The thing about the 'interval' in iCalendar is that >> to use it it is necessary to also add at least the 'frequency' and >> 'startdate' elements to the language. With that, adding 'enddate' and >> 'count' optional elements should not be that bad. What I am hoping >> for is that the same functionality as in iCalendar can be achieved >> here and so far I do not see why not. > Yep. So I have been struggling with this for some time but I hopefully have a solution now. As for the language, I suggest using a new keyword with possible values as in following: repeat=date1(-date2)?\+[1-9][0-9]*(d|w|m|y)(:[1-9][0-9]*)? Here, the date1 and optional date2 are dates in format YYYYMMDD and stand for the start and end dates. The number after + denotes the repetition interval and d/w/m/y stand for day/week/month/year periods respectively. I am omitting the SECONDLY, MINUTELY and HOURLY frequencies from iCalendar as I don't consider them appropriate for our purpose. Besides, if "repeat" is not set, the behavior is similar as with freq=SECONDLY. The number in the optional part with ':' stands for the iCalendar COUNT feature. **However**, I do not think the COUNT feature should be included in this implementation. It probably makes sense as far as the generating of "time events" (single occurences in time) goes, but in the context of time policies it seems quite confusing to me. Here are some reasons why I think it should not be included: 1. Suppose you want to set, say, something like freq=DAILY;count=100; with timeofday=0730-1600. Such range ends at 9:10 the first day and setting time with any freq+count combination would not therefore make much sense. Yes, omitting the time from COUNT would be possible solution, yet it is a different behavior as in iCalendar. 2. You want to set some really complex time policy that should repeat for certain amount of times. To me, it seems safer to set a certain fixed final date rather than have it automagically decided for you. 3. The code would get messier with COUNT included. Currently, the time policies are evaluated as they are parsed without the need of storing them. With COUNT, they will need to be stored and also, before the actual evaluation, the events would need to be generated which can be hard with more complex policies (is it possible to set an event that would never happen, yet each part describing it would be correct?). 4. Not including COUNT in implementation is not a blocker from importing from the iCalendar format. If anything, COUNT just allows generating a finite set of events. During the import, the last event of such set can be either counted and filled in as end date, or the events can just be imported one by one. Do you consider such a solution passable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Aug 6 11:31:30 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 6 Aug 2015 13:31:30 +0200 Subject: [Freeipa-devel] [PATCH 0051] IPA server and replica installers can accept options from config file In-Reply-To: <55BF56D9.6080803@redhat.com> References: <55B8A8E0.404@redhat.com> <55B8B82D.7010309@redhat.com> <55B8ED95.5040208@redhat.com> <55B8F4B3.1000904@redhat.com> <55B9CA71.6010304@redhat.com> <55BF56D9.6080803@redhat.com> Message-ID: <55C34592.7000902@redhat.com> On 08/03/2015 01:56 PM, Martin Babinsky wrote: > On 07/30/2015 08:55 AM, Jan Cholasta wrote: >> Dne 29.7.2015 v 17:43 Petr Vobornik napsal(a): >>> On 07/29/2015 05:13 PM, Martin Babinsky wrote: >>>> On 07/29/2015 01:25 PM, Jan Cholasta wrote: >>>>> Dne 29.7.2015 v 12:20 Martin Babinsky napsal(a): >>>>>> Initial attempt to implement >>>>>> https://fedorahosted.org/freeipa/ticket/4517 >>>>>> >>>>>> Some points to discuss: >>>>>> >>>>>> 1.) name of the config entries: currently the option names are >>>>>> derived >>>>>> from CLI options but have underscores in them instead of dashes. >>>>>> Maybe >>>>>> keeping the CLI option names also for config entries will make it >>>>>> easier >>>>>> for the user to transfer their CLI options from scripts to config >>>>>> files. >>>>> >>>>> NACK. There is no point in generating config names from CLI names, >>>>> which >>>>> are generated from knob names - use knob names directly. >>>>> >>>> The problem is that in some cases the cli_name does not map >>>> directly to >>>> knob name, leading in different naming of CLI options and config >>>> entries, confusion and mayhem. >> >> What works for CLI may not work for config files and vice versa. For >> example, this works for CLI: >> >> --no-ntp >> --no-forwarders >> --forwarder 1.2.3.4 --forwarder 5.6.7.8 >> >> but this works better in config file: >> >> ntp = False >> forwarders = >> forwarders = 1.2.3.4, 5.6.7.8 >> >>>> >>>> These are some offenders from `ipaserver/install/server.py`: >>>> http://fpaste.org/249424/18226114/ >>>> >>>> On the other hand, this can be an incentive to finally put an end to >>>> inconsistent option/knob naming across server/replica/etc. installers. >> >> Yes please. >> >>> >>> If the names are different than cli names, then they should be made >>> discoverable somehow or be documented. >> >> IMHO documenting them is easy. >> >>> >>>>>> >>>>>> 2.) Config sections: there is currently only one valid section named >>>>>> '[global]' in accordance with the format of 'default.conf'. Should we >>>>>> have separate sections equivalent to option groups in CLI (e.g. >>>>>> [basic], >>>>>> [certificate system], [dns])? >>>>> >>>>> No, because they would have to be maintained forever. For example, >>>>> some >>>>> options are in wrong sections and we wouldn't be able to move them. >>>>> >>>> I'm also more inclined to a single section, at least for now since we >>>> are pressed for time with this RFE. >>>> >>>> That's not to say that we should ditch Alexander's idea about separate >>>> sections with overrides for different hosts. We should consider it as a >>>> future enhancement to this feature once the basic plumbing is in place. >> >> Right. >> >>>>>> >>>>>> 3.) Handling of unattended mode when specifying a config file: >>>>>> Currently there is no connection between --config-file and unattended >>>>>> mode. So when you run ipa-server-install using config file, you still >>>>>> get asked for missing stuff. Should '--config-file' automatically >>>>>> imply >>>>>> '--unattended'? >>>>> >>>>> The behavior should be the same as if you specified the options on the >>>>> command line. So no, --config-file should not imply --unattended. >>>>> >>>> That sound reasonable. the code behaves this way already so no changes >>>> here. >>>> >>>>>> >>>>>> There are probably other issues to discuss. Feel free to write >>>>>> email/ping me on IRC. >>>>>> >>>>> >>>>> (I haven't looked at the patch yet.) >>>>> >>>> Please take a look at it ASAP. I am on PTO tomorrow and on Friday, >>>> but I >>>> will find time to work at it in the evening if you send me you >>>> comments. >> >> 1) IMO the option should be in the top-level option section, not in a >> separate group (use "parser.add_option()"). >> >> Also maybe rename it to --config, AFAIK that's what is usually used. >> >> A short name ("-c"?) would be nice too. >> >> Nitpick: if the option is named --config-file, dest should be >> "config_file", to make it easier to look it up in the code. >> >> >> 2) Please don't duplicate the knob retrieval code, store knobs in a list >> and pass that as an argument to parse_config_file. >> >> >> 3) I'm not sure about using newline as a list separator. I don't know >> about other IPA components, but SSSD in particular uses commas, maybe we >> should be consistent with that? >> >> >> 4) Booleans should be assignable either True or False, i.e. do not use >> _parse_knob to parse them. >> >> >> Honza >> > > Attaching updated patch. > > > Attaching updated patch. I have also sneaked in a small change that improves the testability of installers (making configurator a member of ConfigureTool instance). Should I send a separate patch for that? -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0051.2-IPA-server-and-replica-installers-can-accept-options.patch Type: text/x-patch Size: 6209 bytes Desc: not available URL: From abokovoy at redhat.com Thu Aug 6 11:34:23 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Aug 2015 07:34:23 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 0194 Fix selector of protocol for LSA RPC binding string In-Reply-To: <55C31CCB.4080808@redhat.com> References: <20150805184037.GP31709@redhat.com> <55C31CCB.4080808@redhat.com> Message-ID: <1487217271.7906702.1438860863022.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > On 08/05/2015 08:40 PM, Alexander Bokovoy wrote: > > Hi, > > > > attached patch fixes a bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1249455 > > > > details are in the commit message. > > > > > > > > Looks good to me, generates bindings strings as described in the BZ. > > Just a readability nitpick, can we get rid of the binding_template > lambda abstraction and use something like this? > > binding_template=u'%s:%s[%s]' > return [binding_template % (t, remote_host, o) for t in transports > for o in options] > > or just plain: > > return [u'%s:%s[%s]' % (t, remote_host, o) for t in transports for o > in options] > > instead of: > > binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) > return [binding_template(t, remote_host, o) for t in transports for > o in options] Up to you. :) -- / Alexander Bokovoy From mkosek at redhat.com Thu Aug 6 11:42:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 6 Aug 2015 13:42:46 +0200 Subject: [Freeipa-devel] [PATCH] 0194 Fix selector of protocol for LSA RPC binding string In-Reply-To: <55C31CCB.4080808@redhat.com> References: <20150805184037.GP31709@redhat.com> <55C31CCB.4080808@redhat.com> Message-ID: <55C34836.3000603@redhat.com> On 08/06/2015 10:37 AM, Tomas Babej wrote: > > > On 08/05/2015 08:40 PM, Alexander Bokovoy wrote: >> Hi, >> >> attached patch fixes a bug >> https://bugzilla.redhat.com/show_bug.cgi?id=1249455 >> >> details are in the commit message. >> >> >> > > Looks good to me, generates bindings strings as described in the BZ. > > Just a readability nitpick, can we get rid of the binding_template > lambda abstraction and use something like this? > > binding_template=u'%s:%s[%s]' > return [binding_template % (t, remote_host, o) for t in transports > for o in options] > > or just plain: > > return [u'%s:%s[%s]' % (t, remote_host, o) for t in transports for o > in options] > > instead of: > > binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) > return [binding_template(t, remote_host, o) for t in transports for > o in options] > > Tomas > Before pushing, please use https://fedorahosted.org/freeipa/ticket/5183 as reference. I just cloned it. Thanks, Martin From mbabinsk at redhat.com Thu Aug 6 12:29:30 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 6 Aug 2015 14:29:30 +0200 Subject: [Freeipa-devel] [PATCH 0053] fix crash when installer with no positional arguments handles invalid options Message-ID: <55C3532A.5050502@redhat.com> This bug was discovered when writing tests for functionality introduced in my PATCH 0051. This patch should apply on top of PATCH 0051. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0053-fix-crash-when-installer-with-no-positional-argument.patch Type: text/x-patch Size: 3755 bytes Desc: not available URL: From jcholast at redhat.com Thu Aug 6 12:35:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 6 Aug 2015 14:35:29 +0200 Subject: [Freeipa-devel] [PATCH 0053] fix crash when installer with no positional arguments handles invalid options In-Reply-To: <55C3532A.5050502@redhat.com> References: <55C3532A.5050502@redhat.com> Message-ID: <55C35491.1090701@redhat.com> Hi, Dne 6.8.2015 v 14:29 Martin Babinsky napsal(a): > This bug was discovered when writing tests for functionality introduced > in my PATCH 0051. > > This patch should apply on top of PATCH 0051. This whole patch can be reduced to: except core.KnobValueError as e: knob_cls = getattr(transformed_cls, e.name) try: - index = self.positional_arguments.index(e.name) - except IndexError: + if self.positional_arguments: + index = self.positional_arguments.index(e.name) + else: + raise ValueError + except ValueError: cli_name = knob_cls.cli_name or e.name.replace('_', '-') desc = "option --{0}".format(cli_name) else: Honza -- Jan Cholasta From mbabinsk at redhat.com Thu Aug 6 12:48:15 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 6 Aug 2015 14:48:15 +0200 Subject: [Freeipa-devel] [PATCH 0053] fix crash when installer with no positional arguments handles invalid options In-Reply-To: <55C35491.1090701@redhat.com> References: <55C3532A.5050502@redhat.com> <55C35491.1090701@redhat.com> Message-ID: <55C3578F.2060305@redhat.com> On 08/06/2015 02:35 PM, Jan Cholasta wrote: > Hi, > > Dne 6.8.2015 v 14:29 Martin Babinsky napsal(a): >> This bug was discovered when writing tests for functionality introduced >> in my PATCH 0051. >> >> This patch should apply on top of PATCH 0051. > > This whole patch can be reduced to: > > except core.KnobValueError as e: > knob_cls = getattr(transformed_cls, e.name) > try: > - index = self.positional_arguments.index(e.name) > - except IndexError: > + if self.positional_arguments: > + index = self.positional_arguments.index(e.name) > + else: > + raise ValueError > + except ValueError: > cli_name = knob_cls.cli_name or e.name.replace('_', '-') > desc = "option --{0}".format(cli_name) > else: > > Honza > Right. I have rewritten the patch in your way. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0053.1-fix-crash-when-installer-with-no-positional-argument.patch Type: text/x-patch Size: 1384 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Aug 6 12:55:21 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 6 Aug 2015 14:55:21 +0200 Subject: [Freeipa-devel] [PATCH 0054] test suite for functionality implemented #4517 Message-ID: <55C35939.5090101@redhat.com> I have slapped together a small test suite for the functionality implemented in PATCH 0051. Obviously it requires this patch to work. It also requires PATCH 0052 to pass all tests. https://fedorahosted.org/freeipa/ticket/4517 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0054-test-suite-for-configuration-of-installers-based-on-.patch Type: text/x-patch Size: 14575 bytes Desc: not available URL: From simo at redhat.com Thu Aug 6 12:56:34 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 06 Aug 2015 08:56:34 -0400 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <55C2EEC2.9090704@redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <55C2EEC2.9090704@redhat.com> Message-ID: <1438865794.20262.47.camel@willson.usersys.redhat.com> On Thu, 2015-08-06 at 07:21 +0200, Jan Cholasta wrote: > Dne 5.8.2015 v 17:24 Simo Sorce napsal(a): > > On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: > >> Hi, > >> > >> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): > >>> I've been carrying these patches in my tree for a while, I think it is > >>> time to put them in master as they stand on their own. > >>> > >>> Simo. > >> > >> Patch 530: ACK > >> > >> Patch 531: ACK > >> > >> Patch 532: > >> > >> The methods should be static methods: > >> > >> @staticmethod > >> def setOption(name, value): > >> ... > > > > Care to explain why ? > > @staticmethod is not used anywhere else in that file. > > Because the methods do not use any instance or class state. They will of > course work fine even if they are normal methods, but making them static > methods is cleaner. > Ok, I embedded the change in my tree. I am working on some fixes to the replica promotion patchset with Ludwig, so I will respin all of the patches at once later on. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Thu Aug 6 14:54:56 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 6 Aug 2015 16:54:56 +0200 Subject: [Freeipa-devel] Update of User Certificates design page In-Reply-To: <20150804164745.GA1422@redhat.com> References: <55C0DC95.9030400@redhat.com> <20150804164745.GA1422@redhat.com> Message-ID: <55C37540.6040103@redhat.com> On 08/04/2015 06:47 PM, Jan Pazdziora wrote: > On Tue, Aug 04, 2015 at 05:39:01PM +0200, Martin Babinsky wrote: >> >> I am working on the update of >> http://www.freeipa.org/page/V4/User_Certificates design page. >> >> For now I have edited the "Feature Management" and "Howto Test" sections. >> >> Since this is my first time writing/editing designs, there surely is a room >> for improvement. Feel free to send me corrections or edit the parts you >> don't like outright. > > The caIPAuserCert.txt file (content) is missing. > > Not sure if we want to recommend > > sed '1d;$d' cert.pem > > -- maybe command to convert to DER and then base64-encode would > be more generic? > > That > > add ldap_user_certificate = userCertificate;binary to the domain section of sssd.conf > > step -- will it stay or is sssd going to be updated to use that value > automagically? In that case, link to the ticket we are waiting for > (https://fedorahosted.org/sssd/ticket/2742 ?) should be added so > that it's clear that this step should be removed when the ticket > is addressed. > > Otherwise, great effort with the How to Test section. > Thank you for you comments. I have updated the design page accordingly. -- Martin^3 Babinsky From mkubik at redhat.com Thu Aug 6 15:26:01 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 6 Aug 2015 17:26:01 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch Message-ID: <55C37C89.3040209@redhat.com> Hi list, I just noticed that the bits built from ipa-4-2 branch cannot be installed. The freeipa packages built have version such as freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 The version check in the spec file makes the server-dns package obsolete the server package from tha same build. The cause is the commit [1]. This issue blocks us from running tests on ipa-4-2 branch. Should we bump the minor version on this branch to 4.2.1? [1]: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a Cheers, Milan From redhatrises at gmail.com Thu Aug 6 19:43:22 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 6 Aug 2015 13:43:22 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: <55C085BD.40402@redhat.com> References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> Message-ID: Hello, Updated patch attached. - Time limit is -1 for unlimited. I found this https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html in reference to keeping the time limit as -1 for unlimited. Sure enough, testing time limit at 0 did not work for unlimited as well as appeared to have negative effects on IPA. Also, I believe that http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s specifies unlimited for time limit as -1. (Please correct me if I am wrong.) - Size limit is 0 for unlimited per Jan's comment including a conversion from -1 to 0 if -1 is entered for unlimited size limit. > Actually, 0 means unlimited for size limit, see > < http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s> Thanks, Gabe On Tue, Aug 4, 2015 at 3:28 AM, Jan Cholasta wrote: > Dne 31.7.2015 v 17:08 Gabe Alford napsal(a): > >> Updated patch attached. >> >> Thanks, >> >> Gabe >> >> On Thu, Jul 30, 2015 at 7:15 AM, Gabe Alford > > wrote: >> >> On Thu, Jul 30, 2015 at 1:32 AM, Jan Cholasta > > wrote: >> >> Dne 30.7.2015 v 09:23 Jan Cholasta napsal(a): >> >> Hi, >> >> Dne 29.7.2015 v 17:23 Gabe Alford napsal(a): >> >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/4023 >> >> >> Actually, 0 means unlimited for size limit, see >> < >> http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s >> >. >> >> >> After reading the ticket I think this should be fixed the other >> way around: make 0 mean unlimited for both time and size limit >> and fix the config plugin and LDAPClient to respect that. >> >> >> Thanks for the review. Updated patch attached. >> > > We still need to accept -1 in config-mod for backward compatibility - when > received, it should be converted to 0. > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0053-4-Standardize-minvalue-for-ipasearchrecordlimit-and.patch Type: text/x-patch Size: 33632 bytes Desc: not available URL: From mkosek at redhat.com Fri Aug 7 06:44:55 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 7 Aug 2015 08:44:55 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C37C89.3040209@redhat.com> References: <55C37C89.3040209@redhat.com> Message-ID: <55C453E7.9030700@redhat.com> On 08/06/2015 05:26 PM, Milan Kub?k wrote: > Hi list, > > I just noticed that the bits built from ipa-4-2 branch cannot be installed. > The freeipa packages built have version such as > freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 > The version check in the spec file makes the server-dns package obsolete the > server package from tha same build. > The cause is the commit [1]. This issue blocks us from running tests on ipa-4-2 > branch. > > Should we bump the minor version on this branch to 4.2.1? > > [1]: > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a > > > Cheers, > Milan > Why does the spec calls for # upgrade path from monolithic -server to -server + -server-dns Obsoletes: %{name}-server <= 4.2.0 and not for # upgrade path from monolithic -server to -server + -server-dns Obsoletes: %{name}-server < 4.2.0 ? Is that the root cause of these issues? From jcholast at redhat.com Fri Aug 7 06:46:28 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 7 Aug 2015 08:46:28 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C453E7.9030700@redhat.com> References: <55C37C89.3040209@redhat.com> <55C453E7.9030700@redhat.com> Message-ID: <55C45444.1070104@redhat.com> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): > On 08/06/2015 05:26 PM, Milan Kub?k wrote: >> Hi list, >> >> I just noticed that the bits built from ipa-4-2 branch cannot be >> installed. >> The freeipa packages built have version such as >> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >> The version check in the spec file makes the server-dns package >> obsolete the >> server package from tha same build. >> The cause is the commit [1]. This issue blocks us from running tests >> on ipa-4-2 >> branch. >> >> Should we bump the minor version on this branch to 4.2.1? >> >> [1]: >> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >> >> >> >> Cheers, >> Milan >> > Why does the spec calls for > > # upgrade path from monolithic -server to -server + -server-dns > Obsoletes: %{name}-server <= 4.2.0 > > and not for > > # upgrade path from monolithic -server to -server + -server-dns > Obsoletes: %{name}-server < 4.2.0 > > ? Is that the root cause of these issues? AFAIK this would break updates from 4.2.0 to 4.2.1. -- Jan Cholasta From mkosek at redhat.com Fri Aug 7 07:17:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 7 Aug 2015 09:17:53 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C45444.1070104@redhat.com> References: <55C37C89.3040209@redhat.com> <55C453E7.9030700@redhat.com> <55C45444.1070104@redhat.com> Message-ID: <55C45BA1.3020209@redhat.com> On 08/07/2015 08:46 AM, Jan Cholasta wrote: > Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>> Hi list, >>> >>> I just noticed that the bits built from ipa-4-2 branch cannot be >>> installed. >>> The freeipa packages built have version such as >>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>> The version check in the spec file makes the server-dns package >>> obsolete the >>> server package from tha same build. >>> The cause is the commit [1]. This issue blocks us from running tests >>> on ipa-4-2 >>> branch. >>> >>> Should we bump the minor version on this branch to 4.2.1? >>> >>> [1]: >>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>> >>> >>> >>> >>> Cheers, >>> Milan >>> >> Why does the spec calls for >> >> # upgrade path from monolithic -server to -server + -server-dns >> Obsoletes: %{name}-server <= 4.2.0 >> >> and not for >> >> # upgrade path from monolithic -server to -server + -server-dns >> Obsoletes: %{name}-server < 4.2.0 >> >> ? Is that the root cause of these issues? > > AFAIK this would break updates from 4.2.0 to 4.2.1. I wonder how it could break the upgrade... From ftweedal at redhat.com Fri Aug 7 08:04:16 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 7 Aug 2015 18:04:16 +1000 Subject: [Freeipa-devel] [PATCH] 0033 Fix default CA ACL added during upgrade Message-ID: <20150807080416.GC4843@dhcp-40-8.bne.redhat.com> The attached patch fixes https://bugzilla.redhat.com/show_bug.cgi?id=1251225 Thanks, Fraser -------------- next part -------------- From 0431e9b8c8d1ea903e2b68e7fc33f10c38d11bda Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 7 Aug 2015 03:21:43 -0400 Subject: [PATCH] Fix default CA ACL added during upgrade The upgrade script is adding the default CA ACL with incorrect attributes - usercategory=all instead of servicecategory=all. Fix it to create the correct object. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1251225 --- ipaserver/install/server/upgrade.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index a342642b03abc05d0ce108ff2b774ea25904bd8e..1306e96e2a46b191b0bb8f33deccda54c5626558 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1306,7 +1306,7 @@ def add_default_caacl(ca): if not api.Command.caacl_find()['result']: api.Command.caacl_add(u'hosts_services_caIPAserviceCert', - hostcategory=u'all', usercategory=u'all') + hostcategory=u'all', servicecategory=u'all') api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', certprofile=(u'caIPAserviceCert',)) -- 2.4.3 From mbabinsk at redhat.com Fri Aug 7 09:47:57 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 7 Aug 2015 11:47:57 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fix default CA ACL added during upgrade In-Reply-To: <20150807080416.GC4843@dhcp-40-8.bne.redhat.com> References: <20150807080416.GC4843@dhcp-40-8.bne.redhat.com> Message-ID: <55C47ECD.6050902@redhat.com> On 08/07/2015 10:04 AM, Fraser Tweedale wrote: > The attached patch fixes > https://bugzilla.redhat.com/show_bug.cgi?id=1251225 > > Thanks, > Fraser > > > ACK but please put a link to the upstream ticket into the commit message (https://fedorahosted.org/freeipa/ticket/5185) -- Martin^3 Babinsky From ftweedal at redhat.com Fri Aug 7 10:43:33 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 7 Aug 2015 20:43:33 +1000 Subject: [Freeipa-devel] [PATCH] 0033 Fix default CA ACL added during upgrade In-Reply-To: <55C47ECD.6050902@redhat.com> References: <20150807080416.GC4843@dhcp-40-8.bne.redhat.com> <55C47ECD.6050902@redhat.com> Message-ID: <20150807104333.GF4843@dhcp-40-8.bne.redhat.com> On Fri, Aug 07, 2015 at 11:47:57AM +0200, Martin Babinsky wrote: > On 08/07/2015 10:04 AM, Fraser Tweedale wrote: > >The attached patch fixes > >https://bugzilla.redhat.com/show_bug.cgi?id=1251225 > > > >Thanks, > >Fraser > > > > > > > ACK but please put a link to the upstream ticket into the commit message > (https://fedorahosted.org/freeipa/ticket/5185) > Thanks; updated patch attached. > -- > Martin^3 Babinsky -------------- next part -------------- From 27ed22b3779bed6c37195129a04682f76953d13f Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 7 Aug 2015 03:21:43 -0400 Subject: [PATCH] Fix default CA ACL added during upgrade The upgrade script is adding the default CA ACL with incorrect attributes - usercategory=all instead of servicecategory=all. Fix it to create the correct object. Fixes: https://fedorahosted.org/freeipa/ticket/5185 --- ipaserver/install/server/upgrade.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index a342642b03abc05d0ce108ff2b774ea25904bd8e..1306e96e2a46b191b0bb8f33deccda54c5626558 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -1306,7 +1306,7 @@ def add_default_caacl(ca): if not api.Command.caacl_find()['result']: api.Command.caacl_add(u'hosts_services_caIPAserviceCert', - hostcategory=u'all', usercategory=u'all') + hostcategory=u'all', servicecategory=u'all') api.Command.caacl_add_profile(u'hosts_services_caIPAserviceCert', certprofile=(u'caIPAserviceCert',)) -- 2.4.3 From mbabinsk at redhat.com Fri Aug 7 10:44:59 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 7 Aug 2015 12:44:59 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fix default CA ACL added during upgrade In-Reply-To: <20150807104333.GF4843@dhcp-40-8.bne.redhat.com> References: <20150807080416.GC4843@dhcp-40-8.bne.redhat.com> <55C47ECD.6050902@redhat.com> <20150807104333.GF4843@dhcp-40-8.bne.redhat.com> Message-ID: <55C48C2B.6000506@redhat.com> On 08/07/2015 12:43 PM, Fraser Tweedale wrote: > On Fri, Aug 07, 2015 at 11:47:57AM +0200, Martin Babinsky wrote: >> On 08/07/2015 10:04 AM, Fraser Tweedale wrote: >>> The attached patch fixes >>> https://bugzilla.redhat.com/show_bug.cgi?id=1251225 >>> >>> Thanks, >>> Fraser >>> >>> >>> >> ACK but please put a link to the upstream ticket into the commit message >> (https://fedorahosted.org/freeipa/ticket/5185) >> > Thanks; updated patch attached. > >> -- >> Martin^3 Babinsky definitive unconditional ACK from me :). -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Aug 7 14:22:53 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 7 Aug 2015 16:22:53 +0200 Subject: [Freeipa-devel] [PATCH 0055] raise an exception when user tries to modify a local ID range Message-ID: <55C4BF3D.2050901@redhat.com> Short term fix for https://fedorahosted.org/freeipa/ticket/4826 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-055-idranges-raise-an-error-when-local-IPA-ID-range-is-b.patch Type: text/x-patch Size: 2154 bytes Desc: not available URL: From tbabej at redhat.com Fri Aug 7 14:51:43 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 7 Aug 2015 16:51:43 +0200 Subject: [Freeipa-devel] [PATCH 0055] raise an exception when user tries to modify a local ID range In-Reply-To: <55C4BF3D.2050901@redhat.com> References: <55C4BF3D.2050901@redhat.com> Message-ID: <55C4C5FF.20908@redhat.com> On 08/07/2015 04:22 PM, Martin Babinsky wrote: > Short term fix for https://fedorahosted.org/freeipa/ticket/4826 > > > Hi, couple of minor issues: 1.) Please create a separate constant for the WARNING section, now this segment is copy-pasted at three different places in the plugin. 2.) It would be nice to fix the broken indentation in the help texts for ipa idrange-add/mod whlie poking at that part of the code. 3.) 'ipa help idranges' does not produce any info, it error message needs to suggest 'ipa help idrange' Otherwise looks and works good. Tomas From mbabinsk at redhat.com Fri Aug 7 15:09:07 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 7 Aug 2015 17:09:07 +0200 Subject: [Freeipa-devel] [PATCH 0055] raise an exception when user tries to modify a local ID range In-Reply-To: <55C4C5FF.20908@redhat.com> References: <55C4BF3D.2050901@redhat.com> <55C4C5FF.20908@redhat.com> Message-ID: <55C4CA13.9070409@redhat.com> On 08/07/2015 04:51 PM, Tomas Babej wrote: > > > On 08/07/2015 04:22 PM, Martin Babinsky wrote: >> Short term fix for https://fedorahosted.org/freeipa/ticket/4826 >> >> >> > > Hi, > > couple of minor issues: > > 1.) Please create a separate constant for the WARNING section, now this > segment is copy-pasted at three different places in the plugin. > > 2.) It would be nice to fix the broken indentation in the help texts for > ipa idrange-add/mod whlie poking at that part of the code. > How should these sections be indented (especially the warning parts)? > 3.) 'ipa help idranges' does not produce any info, it error message > needs to suggest 'ipa help idrange' > > Otherwise looks and works good. > > Tomas > -- Martin^3 Babinsky From tbabej at redhat.com Fri Aug 7 15:25:36 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 7 Aug 2015 17:25:36 +0200 Subject: [Freeipa-devel] [PATCH 0055] raise an exception when user tries to modify a local ID range In-Reply-To: <55C4CA13.9070409@redhat.com> References: <55C4BF3D.2050901@redhat.com> <55C4C5FF.20908@redhat.com> <55C4CA13.9070409@redhat.com> Message-ID: <55C4CDF0.5050709@redhat.com> On 08/07/2015 05:09 PM, Martin Babinsky wrote: > On 08/07/2015 04:51 PM, Tomas Babej wrote: >> >> >> On 08/07/2015 04:22 PM, Martin Babinsky wrote: >>> Short term fix for https://fedorahosted.org/freeipa/ticket/4826 >>> >>> >>> >> >> Hi, >> >> couple of minor issues: >> >> 1.) Please create a separate constant for the WARNING section, now this >> segment is copy-pasted at three different places in the plugin. >> >> 2.) It would be nice to fix the broken indentation in the help texts for >> ipa idrange-add/mod whlie poking at that part of the code. >> > How should these sections be indented (especially the warning parts)? > The section is indented using 4 spaces in "ipa help idrange-mod" (-add). I see no point in doing so, Additionally, being a separate block of text, it is not visually separated from the options block. >> 3.) 'ipa help idranges' does not produce any info, it error message >> needs to suggest 'ipa help idrange' >> >> Otherwise looks and works good. >> >> Tomas >> > > From abokovoy at redhat.com Fri Aug 7 20:56:19 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Aug 2015 23:56:19 +0300 Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request In-Reply-To: <20150728130256.GA20980@p.redhat.com> References: <20150721114114.GA7078@p.redhat.com> <721412384.2383594.1437572511320.JavaMail.zimbra@redhat.com> <20150728101515.GA7078@p.redhat.com> <1438081537.13513.17.camel@willson.usersys.redhat.com> <20150728112634.GP21928@redhat.com> <20150728114229.GC17746@p.redhat.com> <20150728130256.GA20980@p.redhat.com> Message-ID: <20150807205619.GA22106@redhat.com> On Tue, 28 Jul 2015, Sumit Bose wrote: >On Tue, Jul 28, 2015 at 01:42:29PM +0200, Sumit Bose wrote: >> On Tue, Jul 28, 2015 at 02:26:34PM +0300, Alexander Bokovoy wrote: >> > On Tue, 28 Jul 2015, Simo Sorce wrote: >> > >On Tue, 2015-07-28 at 12:15 +0200, Sumit Bose wrote: >> > >>On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote: >> > >>> ----- Original Message ----- >> > >>> > From: "Sumit Bose" >> > >>> > To: "freeipa-devel" >> > >>> > Sent: Tuesday, July 21, 2015 7:41:14 AM >> > >>> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request >> > >>> > >> > >>> > Hi, >> > >>> > >> > >>> > this patch is my suggestion to solve >> > >>> > https://fedorahosted.org/freeipa/ticket/4844 . >> > >>> > >> > >>> > The original issue in the ticket has two part. One is a loop in libkrb5 >> > >>> > which is already fixed. The other is to handle canonicalization better. >> > >>> >> > >>> Sorry Sumit, >> > >>> I see several issues with this patck. >> > >>> >> > >>> first of all you should really not change ipadb_get_principal(), that's the >> > >>> wrong place to apply your logic. >> > >>> >> > >>> To support searching for the realm name case-insensitively all we should do >> > >>> is to always forcibly upper case the realm name at the same time we build the >> > >>> filter (in ipadb_fetch_principals(), if canonicalization was requested. >> > >>> Because we will never store (code to prevent that should probably be dded with >> > >>> this patch) a realm name that is not all caps. >> > >>> Then the post search matches should be done straight within ipadb_find_principal(). >> > >>> >> > >>> > The general way to allow canonicalization on a principal is to add the >> > >>> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together >> > >>> > with the objectclass 'ipaKrbPrincipal' to the user object. >> > >>> >> > >>> We have already a ticket open since long to remove krbprincipalalias, it was >> > >>> a mistake to add it and any patch that depends on it will be nacked by me. >> > >>> We need to use krbPrincipalName and krbCanonicalName. >> > >>> >> > >>> > Then the IPA >> > >>> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive >> > >>> > matches and the principal from 'krbcanonicalname' will be the canonical >> > >>> > principal used further on. The 'krbPrincipalName' is not suitable for >> > >>> > either because it has caseExact* matching rules and is a multivalue >> > >>> > attribute [2]. >> > >>> >> > >>> Case-exact match is a problem only if we do not canonicalize names when storing >> > >>> them, otherwise all you need to do is store a "search form" in krbPrincipalName >> > >>> and always change searches to that form (forcibly upper case realm, forcibly >> > >>> lowercase components) when canonicalization is requested. >> > >>> >> > >>> Additionally in the patch you are using stcasecmp(), that function is not >> > >>> acceptable, look at ipadb_find_principal() and you'll see we use ulc_casecmp() >> > >>> there. >> > >>> Also modyfing the principal before searching is done wrong (you use strchr() >> > >>> to find the @ sign, but you could find an @ in the components this way, you >> > >>> should use strrchr() at the very least), and is dangerous if done outside of >> > >>> the inner functions because then we never have a way to know the original >> > >>> form should it be needed. In any case as said above realm should be forcibly >> > >>> uppercase, given a flag in the escape function instead. >> > >> >> > >>Thank for for the review and the comments. >> > >> >> > >>I changed the patch as you suggested to upper-case the realm in the >> > >>escape function if the flag is set. >> > >> >> > >>I didn't add any checks to make sure that the realm of newly added >> > >>principal attributes is always upper case. Since the attributes can be >> > >>added via various ways I think the check should happen on the DS level >> > > >> > >We should indeed intercept add/modify operations and see if they try to >> > >set krbPrincipalName/krbCanonicalName and then validate the name. >> > >Return unwilling to perform if the case of the realm is different (or >> > >fix it on the fly, up for discussion) from the default case as >> > >configured in the server. >> > Will break trusts -- ipasam does add these principals for krbtgt/IPA at AD. >> > >> > >>but I see this more in the context of full canonicalization fix covered >> > >>by https://fedorahosted.org/freeipa/ticket/3864 . If you think this is a >> > >>requirement for the patch attached I would suggest to drop >> > >>https://fedorahosted.org/freeipa/ticket/4844 and solve it together with >> > >>#3864. >> > > >> > >We should clsoe 4844 as fixed upstream (there *was* a bug in libkrb5). >> > >I commented on #3864 about what we can do, and we can also avoid >> > >changing the schema. >> > Yep. >> > >> > >So on the new patches, what does "unify" means ? I do not get what it >> > >means (so probably it is a poor name), I guess you may want to call it >> > >"canonicalization" ? (or even 'canon' to shorten it a bit). >> > I have same question. I tried to understand why it is called unify and >> > failed. >> >> I didn't want to use 'canonical' because the result will not be the >> canonical name in the general case but only a name we use for searching. >> I was thinking about 'normalized' bit this has a special meaning with >> unicode. So I came up with 'unify'. But if you prefer 'canon' I can >> change it. >> >> > >> > >I think the worst case for a utf8 string is more then length*2, probably >> > >more like length*6, unless there is some guarantee around case changes >> > >that I am not aware of, that said we could probably just allocate on the >> > >stack a fixed size string of a KiB or so, the longest DNS name is 256 >> > >chars IIRC and a service name can't be that much longer, also usernames >> > >can't be arbitrarily long. So 1/2 KiB should probably be fine for a full >> > >principal name. (avoids a malloc too which is good). >> > Yes, sounds good. A hostname label can be up to 63 characters and full >> > domain name including dots would be 253 characters. At the same time, a >> > a component of the principal may be of arbitrary length. From practical >> > perspective it would probably be enough to go with a static buffer of >> > 1/2 KiB for the quickest case and fall back to malloc() if the size is >> > bigger than that one. >> >> ok, I will change this. > >new version with changed name and 1/2 KiB buffer attached. No changes to >the 2nd patch. Thanks. Patches look good to me. I, perhaps, would have added char *canon_princ = NULL; in the definition of canon_princ but as you never access it in case asprintf() failed, that's fine. Simo? -- / Alexander Bokovoy From ftweedal at redhat.com Sun Aug 9 07:38:48 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sun, 9 Aug 2015 17:38:48 +1000 Subject: [Freeipa-devel] [PATCH] 0034-0035 Allow SAN extension for cert-request self-service Message-ID: <20150809073848.GG4843@dhcp-40-8.bne.redhat.com> Patch 0035 fixes #5190 - Users unable to self-issue certificate with SAN. Patch 0034 adds more context to the virtual command ACIError denial messages. Thanks, Fraser -------------- next part -------------- From 9653b4bf835b36bc8e328405b2f19af0ebb3312e Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Sun, 9 Aug 2015 01:54:41 -0400 Subject: [PATCH 34/35] Give more info on virtual command access denial The current error message upon a virutal command access denial does not give any information about the virtual operation that was prohibited. Add more information to the ACIError message. --- ipalib/plugins/virtual.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/virtual.py b/ipalib/plugins/virtual.py index 414de4c0011b4ae49083d7820a3cb3708e3e16b1..3bbe32e538ab108d7abc71785e27664fea5ea248 100644 --- a/ipalib/plugins/virtual.py +++ b/ipalib/plugins/virtual.py @@ -62,7 +62,7 @@ class VirtualCommand(Command): try: if not ldap.can_write(operationdn, "objectclass"): raise errors.ACIError( - info=_('not allowed to perform this command')) + info=_('not allowed to perform operation: %s') % operation) except errors.NotFound: raise errors.ACIError(info=_('No such virtual command')) -- 2.4.3 -------------- next part -------------- From 40ecb936e0f5b1db1e9623d72a9c9dc53bc2c0dc Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Sun, 9 Aug 2015 03:25:58 -0400 Subject: [PATCH 35/35] Allow SAN extension for cert-request self-service Users cannot self-issue a certificate with a subjectAltName extension (e.g. with rfc822Name altNames). Suppress the cert-request "request certificate with subjectaltname" permission check when the bind principal is the target principal (i.e. cert-request self-service). Fixes: https://fedorahosted.org/freeipa/ticket/5190 --- ipalib/plugins/cert.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 341bdd01766d50ba18ce7147d4408851e6f95487..d612e9d38da44e4fd4768d286f930e51c71a1031 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -369,7 +369,7 @@ class cert_request(VirtualCommand): error=_("Failure decoding Certificate Signing Request: %s") % e) # host principals may bypass allowed ext check - if bind_principal_type != HOST: + if bind_principal != principal and bind_principal_type != HOST: for ext in extensions: operation = self._allowed_extensions.get(ext) if operation: -- 2.4.3 From ftweedal at redhat.com Sun Aug 9 10:03:47 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sun, 9 Aug 2015 20:03:47 +1000 Subject: [Freeipa-devel] [PATCH] 0036 Fix KRB5PrincipalName / UPN SAN comparison Message-ID: <20150809100347.GH4843@dhcp-40-8.bne.redhat.com> The attached patch fixes a bug in KRB5PrincipalName / UPN SAN validation. Thanks, Fraser -------------- next part -------------- From 5f2b87fb4a5b6d93bd8e946e53e27137280682c1 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Sun, 9 Aug 2015 05:55:04 -0400 Subject: [PATCH] Fix KRB5PrincipalName / UPN SAN comparison Depending on how the target principal name is conveyed to the command (i.e. with / without realm), the KRB5PrincipalName / UPN subjectAltName validation could be comparing unequal strings and erroneously rejecting a valid request. Normalise both side of the comparison to ensure that the principal names contain realm information. Fixes: https://fedorahosted.org/freeipa/ticket/5191 --- ipalib/plugins/cert.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 341bdd01766d50ba18ce7147d4408851e6f95487..f8a11ca2c5a3688f57c6c3839438fbd426369ecc 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -473,7 +473,7 @@ class cert_request(VirtualCommand): principal_type, alt_principal_string, ca, profile_id) elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, pkcs10.SAN_OTHERNAME_UPN): - if name != principal_string: + if split_any_principal(name) != principal: raise errors.ACIError( info=_("Principal '%s' in subject alt name does not " "match requested principal") % name) -- 2.4.3 From ssorce at redhat.com Sun Aug 9 18:45:50 2015 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 09 Aug 2015 14:45:50 -0400 Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request In-Reply-To: <20150807205619.GA22106@redhat.com> References: <20150721114114.GA7078@p.redhat.com> <721412384.2383594.1437572511320.JavaMail.zimbra@redhat.com> <20150728101515.GA7078@p.redhat.com> <1438081537.13513.17.camel@willson.usersys.redhat.com> <20150728112634.GP21928@redhat.com> <20150728114229.GC17746@p.redhat.com> <20150728130256.GA20980@p.redhat.com> <20150807205619.GA22106@redhat.com> Message-ID: <1439145950.20262.73.camel@willson.usersys.redhat.com> On Fri, 2015-08-07 at 23:56 +0300, Alexander Bokovoy wrote: > On Tue, 28 Jul 2015, Sumit Bose wrote: > >On Tue, Jul 28, 2015 at 01:42:29PM +0200, Sumit Bose wrote: > >> On Tue, Jul 28, 2015 at 02:26:34PM +0300, Alexander Bokovoy wrote: > >> > On Tue, 28 Jul 2015, Simo Sorce wrote: > >> > >On Tue, 2015-07-28 at 12:15 +0200, Sumit Bose wrote: > >> > >>On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote: > >> > >>> ----- Original Message ----- > >> > >>> > From: "Sumit Bose" > >> > >>> > To: "freeipa-devel" > >> > >>> > Sent: Tuesday, July 21, 2015 7:41:14 AM > >> > >>> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request > >> > >>> > > >> > >>> > Hi, > >> > >>> > > >> > >>> > this patch is my suggestion to solve > >> > >>> > https://fedorahosted.org/freeipa/ticket/4844 . > >> > >>> > > >> > >>> > The original issue in the ticket has two part. One is a loop in libkrb5 > >> > >>> > which is already fixed. The other is to handle canonicalization better. > >> > >>> > >> > >>> Sorry Sumit, > >> > >>> I see several issues with this patck. > >> > >>> > >> > >>> first of all you should really not change ipadb_get_principal(), that's the > >> > >>> wrong place to apply your logic. > >> > >>> > >> > >>> To support searching for the realm name case-insensitively all we should do > >> > >>> is to always forcibly upper case the realm name at the same time we build the > >> > >>> filter (in ipadb_fetch_principals(), if canonicalization was requested. > >> > >>> Because we will never store (code to prevent that should probably be dded with > >> > >>> this patch) a realm name that is not all caps. > >> > >>> Then the post search matches should be done straight within ipadb_find_principal(). > >> > >>> > >> > >>> > The general way to allow canonicalization on a principal is to add the > >> > >>> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together > >> > >>> > with the objectclass 'ipaKrbPrincipal' to the user object. > >> > >>> > >> > >>> We have already a ticket open since long to remove krbprincipalalias, it was > >> > >>> a mistake to add it and any patch that depends on it will be nacked by me. > >> > >>> We need to use krbPrincipalName and krbCanonicalName. > >> > >>> > >> > >>> > Then the IPA > >> > >>> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive > >> > >>> > matches and the principal from 'krbcanonicalname' will be the canonical > >> > >>> > principal used further on. The 'krbPrincipalName' is not suitable for > >> > >>> > either because it has caseExact* matching rules and is a multivalue > >> > >>> > attribute [2]. > >> > >>> > >> > >>> Case-exact match is a problem only if we do not canonicalize names when storing > >> > >>> them, otherwise all you need to do is store a "search form" in krbPrincipalName > >> > >>> and always change searches to that form (forcibly upper case realm, forcibly > >> > >>> lowercase components) when canonicalization is requested. > >> > >>> > >> > >>> Additionally in the patch you are using stcasecmp(), that function is not > >> > >>> acceptable, look at ipadb_find_principal() and you'll see we use ulc_casecmp() > >> > >>> there. > >> > >>> Also modyfing the principal before searching is done wrong (you use strchr() > >> > >>> to find the @ sign, but you could find an @ in the components this way, you > >> > >>> should use strrchr() at the very least), and is dangerous if done outside of > >> > >>> the inner functions because then we never have a way to know the original > >> > >>> form should it be needed. In any case as said above realm should be forcibly > >> > >>> uppercase, given a flag in the escape function instead. > >> > >> > >> > >>Thank for for the review and the comments. > >> > >> > >> > >>I changed the patch as you suggested to upper-case the realm in the > >> > >>escape function if the flag is set. > >> > >> > >> > >>I didn't add any checks to make sure that the realm of newly added > >> > >>principal attributes is always upper case. Since the attributes can be > >> > >>added via various ways I think the check should happen on the DS level > >> > > > >> > >We should indeed intercept add/modify operations and see if they try to > >> > >set krbPrincipalName/krbCanonicalName and then validate the name. > >> > >Return unwilling to perform if the case of the realm is different (or > >> > >fix it on the fly, up for discussion) from the default case as > >> > >configured in the server. > >> > Will break trusts -- ipasam does add these principals for krbtgt/IPA at AD. > >> > > >> > >>but I see this more in the context of full canonicalization fix covered > >> > >>by https://fedorahosted.org/freeipa/ticket/3864 . If you think this is a > >> > >>requirement for the patch attached I would suggest to drop > >> > >>https://fedorahosted.org/freeipa/ticket/4844 and solve it together with > >> > >>#3864. > >> > > > >> > >We should clsoe 4844 as fixed upstream (there *was* a bug in libkrb5). > >> > >I commented on #3864 about what we can do, and we can also avoid > >> > >changing the schema. > >> > Yep. > >> > > >> > >So on the new patches, what does "unify" means ? I do not get what it > >> > >means (so probably it is a poor name), I guess you may want to call it > >> > >"canonicalization" ? (or even 'canon' to shorten it a bit). > >> > I have same question. I tried to understand why it is called unify and > >> > failed. > >> > >> I didn't want to use 'canonical' because the result will not be the > >> canonical name in the general case but only a name we use for searching. > >> I was thinking about 'normalized' bit this has a special meaning with > >> unicode. So I came up with 'unify'. But if you prefer 'canon' I can > >> change it. > >> > >> > > >> > >I think the worst case for a utf8 string is more then length*2, probably > >> > >more like length*6, unless there is some guarantee around case changes > >> > >that I am not aware of, that said we could probably just allocate on the > >> > >stack a fixed size string of a KiB or so, the longest DNS name is 256 > >> > >chars IIRC and a service name can't be that much longer, also usernames > >> > >can't be arbitrarily long. So 1/2 KiB should probably be fine for a full > >> > >principal name. (avoids a malloc too which is good). > >> > Yes, sounds good. A hostname label can be up to 63 characters and full > >> > domain name including dots would be 253 characters. At the same time, a > >> > a component of the principal may be of arbitrary length. From practical > >> > perspective it would probably be enough to go with a static buffer of > >> > 1/2 KiB for the quickest case and fall back to malloc() if the size is > >> > bigger than that one. > >> > >> ok, I will change this. > > > >new version with changed name and 1/2 KiB buffer attached. No changes to > >the 2nd patch. > Thanks. > > Patches look good to me. I, perhaps, would have added > char *canon_princ = NULL; > > in the definition of canon_princ but as you never access it in case > asprintf() failed, that's fine. > > Simo? > LGTM. Simo. From ftweedal at redhat.com Mon Aug 10 04:39:04 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 10 Aug 2015 14:39:04 +1000 Subject: [Freeipa-devel] [PATCH] 0036 Add profile for DNP3 / IEC 62351-8 certificates Message-ID: <20150810043904.GD6626@dhcp-40-8.bne.redhat.com> The attached patch adds a DNP3 profile, addressing https://fedorahosted.org/freeipa/ticket/4752. It depends on my patch 0029 [1] which is a workaround for a python-nss bug [2] we are waiting on a fix for. [1] https://www.redhat.com/archives/freeipa-devel/2015-July/msg00623.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1246729 Thanks, Fraser -------------- next part -------------- From f2a386f54d586a1bee7158ff59fd5135b593190a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Fri, 24 Jul 2015 09:32:51 -0400 Subject: [PATCH] Add profile for DNP3 / IEC 62351-8 certificates The DNP3 smart-grid standard uses certificate with the IEC 62351-8 IECUserRoles extension. Add a profile for DNP3 certificates which copies the IECUserRoles extension from the CSR, if present. Also update cert-request to accept CSRs containing this extension. Fixes: https://fedorahosted.org/freeipa/ticket/4752 --- install/share/profiles/IECUserRoles.cfg | 114 ++++++++++++++++++++++++++++++++ install/share/profiles/Makefile.am | 1 + ipalib/plugins/cert.py | 1 + ipapython/dogtag.py | 1 + 4 files changed, 117 insertions(+) create mode 100644 install/share/profiles/IECUserRoles.cfg diff --git a/install/share/profiles/IECUserRoles.cfg b/install/share/profiles/IECUserRoles.cfg new file mode 100644 index 0000000000000000000000000000000000000000..9d2b4bb7932db42f6fc1f4e8edbc2bb741d8d8b6 --- /dev/null +++ b/install/share/profiles/IECUserRoles.cfg @@ -0,0 +1,114 @@ +profileId=IECUserRoles +classId=caEnrollImpl +desc=Enroll user certificates with IECUserRoles extension via IPA-RA agent authentication. +visible=false +enable=true +enableBy=admin +auth.instance_id=raCertAuth +name=IPA-RA Agent-Authenticated Server Certificate Enrollment +input.list=i1,i2 +input.i1.class_id=certReqInputImpl +input.i2.class_id=submitterInfoInputImpl +output.list=o1 +output.o1.class_id=certOutputImpl +policyset.list=serverCertSet +policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12 +policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl +policyset.serverCertSet.1.constraint.name=Subject Name Constraint +policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+ +policyset.serverCertSet.1.constraint.params.accept=true +policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl +policyset.serverCertSet.1.default.name=Subject Name Default +policyset.serverCertSet.1.default.params.name=CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O +policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl +policyset.serverCertSet.2.constraint.name=Validity Constraint +policyset.serverCertSet.2.constraint.params.range=740 +policyset.serverCertSet.2.constraint.params.notBeforeCheck=false +policyset.serverCertSet.2.constraint.params.notAfterCheck=false +policyset.serverCertSet.2.default.class_id=validityDefaultImpl +policyset.serverCertSet.2.default.name=Validity Default +policyset.serverCertSet.2.default.params.range=731 +policyset.serverCertSet.2.default.params.startTime=0 +policyset.serverCertSet.3.constraint.class_id=keyConstraintImpl +policyset.serverCertSet.3.constraint.name=Key Constraint +policyset.serverCertSet.3.constraint.params.keyType=RSA +policyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096 +policyset.serverCertSet.3.default.class_id=userKeyDefaultImpl +policyset.serverCertSet.3.default.name=Key Default +policyset.serverCertSet.4.constraint.class_id=noConstraintImpl +policyset.serverCertSet.4.constraint.name=No Constraint +policyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl +policyset.serverCertSet.4.default.name=Authority Key Identifier Default +policyset.serverCertSet.5.constraint.class_id=noConstraintImpl +policyset.serverCertSet.5.constraint.name=No Constraint +policyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl +policyset.serverCertSet.5.default.name=AIA Extension Default +policyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true +policyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName +policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://$IPA_CA_RECORD.$DOMAIN/ca/ocsp +policyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1 +policyset.serverCertSet.5.default.params.authInfoAccessCritical=false +policyset.serverCertSet.5.default.params.authInfoAccessNumADs=1 +policyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl +policyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint +policyset.serverCertSet.6.constraint.params.keyUsageCritical=true +policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false +policyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false +policyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl +policyset.serverCertSet.6.default.name=Key Usage Default +policyset.serverCertSet.6.default.params.keyUsageCritical=true +policyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true +policyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true +policyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true +policyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false +policyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false +policyset.serverCertSet.6.default.params.keyUsageCrlSign=false +policyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false +policyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false +policyset.serverCertSet.7.constraint.class_id=noConstraintImpl +policyset.serverCertSet.7.constraint.name=No Constraint +policyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl +policyset.serverCertSet.7.default.name=Extended Key Usage Extension Default +policyset.serverCertSet.7.default.params.exKeyUsageCritical=false +policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 +policyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl +policyset.serverCertSet.8.constraint.name=No Constraint +policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC +policyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl +policyset.serverCertSet.8.default.name=Signing Alg +policyset.serverCertSet.8.default.params.signingAlg=- +policyset.serverCertSet.9.constraint.class_id=noConstraintImpl +policyset.serverCertSet.9.constraint.name=No Constraint +policyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl +policyset.serverCertSet.9.default.name=CRL Distribution Points Extension Default +policyset.serverCertSet.9.default.params.crlDistPointsCritical=false +policyset.serverCertSet.9.default.params.crlDistPointsNum=1 +policyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true +policyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=$CRL_ISSUER +policyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName +policyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://$IPA_CA_RECORD.$DOMAIN/ipa/crl/MasterCRL.bin +policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName +policyset.serverCertSet.9.default.params.crlDistPointsReasons_0= +policyset.serverCertSet.10.constraint.class_id=noConstraintImpl +policyset.serverCertSet.10.constraint.name=No Constraint +policyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl +policyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default +policyset.serverCertSet.10.default.params.critical=false +policyset.serverCertSet.11.constraint.class_id=noConstraintImpl +policyset.serverCertSet.11.constraint.name=No Constraint +policyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl +policyset.serverCertSet.11.default.name=User Supplied Extension Default +policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17 +policyset.serverCertSet.12.constraint.class_id=noConstraintImpl +policyset.serverCertSet.12.constraint.name=No Constraint +policyset.serverCertSet.12.default.class_id=userExtensionDefaultImpl +policyset.serverCertSet.12.default.name=IECUserRoles Extension Default +policyset.serverCertSet.12.default.params.userExtOID=1.2.840.10070.8.1 diff --git a/install/share/profiles/Makefile.am b/install/share/profiles/Makefile.am index 4e6cf975a0f51d02ec29bd07ac8cb9ccc8320818..b5ccb6e9317a93c040b7de0e0bc1ca5cb88c33fc 100644 --- a/install/share/profiles/Makefile.am +++ b/install/share/profiles/Makefile.am @@ -3,6 +3,7 @@ NULL = appdir = $(IPA_DATA_DIR)/profiles app_DATA = \ caIPAserviceCert.cfg \ + IECUserRoles.cfg \ $(NULL) EXTRA_DIST = \ diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index 341bdd01766d50ba18ce7147d4408851e6f95487..6bb286e67f572655db518cbc8060c1eb928eda73 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -312,6 +312,7 @@ class cert_request(VirtualCommand): '2.5.29.17': 'request certificate with subjectaltname', '2.5.29.19': None, # Basic Constraints '2.5.29.37': None, # Extended Key Usage + '1.2.840.10070.8.1': None, # IECUserRoles (DNP3 / IEC 62351-8) } def execute(self, csr, **kw): diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 53085f7762fc828ed9fc6621fbf3a0c67ec6a656..0782d360ccf2ce2c90c4e9cfa66b5159e437e77c 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -45,6 +45,7 @@ from ipapython.ipa_log_manager import * INCLUDED_PROFILES = { # ( profile_id , description , store_issued) (u'caIPAserviceCert', u'Standard profile for network services', True), + (u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), } DEFAULT_PROFILE = u'caIPAserviceCert' -- 2.4.3 From ftweedal at redhat.com Mon Aug 10 04:46:14 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 10 Aug 2015 14:46:14 +1000 Subject: [Freeipa-devel] [PATCH] 0037 Add profile for DNP3 / IEC 62351-8 certificates In-Reply-To: <20150810043904.GD6626@dhcp-40-8.bne.redhat.com> References: <20150810043904.GD6626@dhcp-40-8.bne.redhat.com> Message-ID: <20150810044614.GE6626@dhcp-40-8.bne.redhat.com> Whups, that should be patch number >> 0037 << On Mon, Aug 10, 2015 at 02:39:04PM +1000, Fraser Tweedale wrote: > The attached patch adds a DNP3 profile, addressing > https://fedorahosted.org/freeipa/ticket/4752. > > It depends on my patch 0029 [1] which is a workaround for > a python-nss bug [2] we are waiting on a fix for. > > [1] https://www.redhat.com/archives/freeipa-devel/2015-July/msg00623.html > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1246729 > > Thanks, > Fraser From ofayans at redhat.com Mon Aug 10 06:20:39 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 10 Aug 2015 08:20:39 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin Message-ID: <55C842B7.6030503@redhat.com> Hi list, Here are 2 integration tests for topology plugin. Plus I got rid of using nose in test_ipaserver/test_topology_plugin.py: I am using @pytest.mark.skipif instead -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 11256 bytes Desc: not available URL: From ofayans at redhat.com Mon Aug 10 07:41:26 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 10 Aug 2015 09:41:26 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55C842B7.6030503@redhat.com> References: <55C842B7.6030503@redhat.com> Message-ID: <55C855A6.5050004@redhat.com> Hi all. Applied pPOP8 requirements to the code, removed unused imports. Please, disregard the first version of this patch On 08/10/2015 08:20 AM, Oleg Fayans wrote: > Hi list, > > Here are 2 integration tests for topology plugin. Plus I got rid of > using nose in test_ipaserver/test_topology_plugin.py: I am using > @pytest.mark.skipif instead > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.1-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 1122 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Aug 10 08:50:22 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 10 Aug 2015 10:50:22 +0200 Subject: [Freeipa-devel] [PATCH 0055] raise an exception when user tries to modify a local ID range In-Reply-To: <55C4CDF0.5050709@redhat.com> References: <55C4BF3D.2050901@redhat.com> <55C4C5FF.20908@redhat.com> <55C4CA13.9070409@redhat.com> <55C4CDF0.5050709@redhat.com> Message-ID: <55C865CE.7040507@redhat.com> On 08/07/2015 05:25 PM, Tomas Babej wrote: > > > On 08/07/2015 05:09 PM, Martin Babinsky wrote: >> On 08/07/2015 04:51 PM, Tomas Babej wrote: >>> >>> >>> On 08/07/2015 04:22 PM, Martin Babinsky wrote: >>>> Short term fix for https://fedorahosted.org/freeipa/ticket/4826 >>>> >>>> >>>> >>> >>> Hi, >>> >>> couple of minor issues: >>> >>> 1.) Please create a separate constant for the WARNING section, now this >>> segment is copy-pasted at three different places in the plugin. >>> >>> 2.) It would be nice to fix the broken indentation in the help texts for >>> ipa idrange-add/mod whlie poking at that part of the code. >>> >> How should these sections be indented (especially the warning parts)? >> > > The section is indented using 4 spaces in "ipa help idrange-mod" (-add). > I see no point in doing so, Additionally, being a separate block of > text, it is not visually separated from the options block. > >>> 3.) 'ipa help idranges' does not produce any info, it error message >>> needs to suggest 'ipa help idrange' >>> >>> Otherwise looks and works good. >>> >>> Tomas >>> >> >> Attaching updated patch. I have tried to improve the visibility of the warning message. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-055.1-idranges-raise-an-error-when-local-IPA-ID-range-is-b.patch Type: text/x-patch Size: 3927 bytes Desc: not available URL: From ofayans at redhat.com Mon Aug 10 08:54:45 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 10 Aug 2015 10:54:45 +0200 Subject: [Freeipa-devel] Topology Plugin design questions Message-ID: <55C866D5.5040808@redhat.com> Hi Ludwig, It seems the Design page for the topology plugin is a bit outdated. 1. It still operates with the terms like plugin version (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), although it was generally agreed, that we do not use plugin version at all. 2. The section http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition should be a bit clarified: Does this mean, that if we prepare a replica from a master that has domainlevel = 1, then the replica, that already had a domain level = 0 will raise it? Do we support this scenario at all? 3. Segment directions. Currently there is no way to specify segment direction using the cli `ipa topologysegment-add`. However the direction is shown with `ipa topologysegment-find` and `ipa topologysegment-show`, which leads to confusing of the users. We probably should remove this info from the output at all and update the design page accordingly. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mkubik at redhat.com Mon Aug 10 09:36:31 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 10 Aug 2015 11:36:31 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55C2082C.6090907@redhat.com> References: <55C2082C.6090907@redhat.com> Message-ID: <55C8709F.7030500@redhat.com> On 08/05/2015 02:57 PM, Milan Kub?k wrote: > Hi list, > > I'm sending the test plan [1] for certificate profiles and preliminary > patches for it. > The plan covers basic CRUD test and some corner cases. I'm open to more > suggestions. > > More complicated tests involving certificate profiles will require the > code (and tests) > for CA ACLs merged, so it's not there at the moment. > > There are some unfinished test cases in places I wasn't sure what the > result should be. > We need to iterate through these to fix it. > > > [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan > > Cheers, > Milan Hi all, have you had some time to look at the code and proposal? Today I want to write a basic CRUD test for the ACLs as well as a few test cases to check if the ACL is being enforced. It should make it into wiki today or by tomorrow. I'll send an update then. Cheers, Milan From jcholast at redhat.com Mon Aug 10 11:04:59 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Aug 2015 13:04:59 +0200 Subject: [Freeipa-devel] [PATCH] 370 Fixed missing KRA agent cert on replica. In-Reply-To: <55BC1953.4000607@redhat.com> References: <55BC1953.4000607@redhat.com> Message-ID: <55C8855B.20704@redhat.com> Dne 1.8.2015 v 02:56 Endi Sukma Dewata napsal(a): > The code that exports the KRA agent certificate has been moved > such that it will be executed both on master and replica. > > https://fedorahosted.org/freeipa/ticket/5174 Works for me, ACK. Pushed to: master: c8882f7d1c98a795195e7bd2e48323ce95edc858 ipa-4-2: ad6a87e05857d60cbc9c22f426397e37ef11c2ac -- Jan Cholasta From pvoborni at redhat.com Mon Aug 10 11:05:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 10 Aug 2015 13:05:26 +0200 Subject: [Freeipa-devel] [PATCH] 907 webui: add LDAP vs Kerberos behavior description to user auth types Message-ID: <55C88576.70804@redhat.com> Text in the ticket is IMHO wrong. Patch uses different text.: """" If you choose the password and two-factor authentication types at once, Kerberos still enforces authentication with both password and OTP. LDAP allows authentication with either one of the authentication types in this situation. """ One can also use only "Password" with kinit but must provide an armor ccache. e.g.: $ kinit admin $ klist Ticket cache: KEYRING:persistent:17127:17127 ... $ kinit -T KEYRING:persistent:17127:17127 fbar https://fedorahosted.org/freeipa/ticket/4935 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0907-webui-add-LDAP-vs-Kerberos-behavior-description-to-u.patch Type: text/x-patch Size: 6101 bytes Desc: not available URL: From ofayans at redhat.com Mon Aug 10 11:05:34 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 10 Aug 2015 13:05:34 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55C855A6.5050004@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> Message-ID: <55C8857E.7070802@redhat.com> Last update to the patch. On 08/10/2015 09:41 AM, Oleg Fayans wrote: > Hi all. > > Applied pPOP8 requirements to the code, removed unused imports. Please, > disregard the first version of this patch > > On 08/10/2015 08:20 AM, Oleg Fayans wrote: >> Hi list, >> >> Here are 2 integration tests for topology plugin. Plus I got rid of >> using nose in test_ipaserver/test_topology_plugin.py: I am using >> @pytest.mark.skipif instead >> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.2-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 11196 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 10 11:07:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 10 Aug 2015 13:07:51 +0200 Subject: [Freeipa-devel] [PATCH 0296] Fix upgrade sigdom and extdom config Message-ID: <55C88607.8070908@redhat.com> https://fedorahosted.org/freeipa/ticket/5151 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0296-Fix-upgrade-of-sidgen-and-extdom-plugins.patch Type: text/x-patch Size: 3662 bytes Desc: not available URL: From dkupka at redhat.com Mon Aug 10 12:52:21 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 10 Aug 2015 14:52:21 +0200 Subject: [Freeipa-devel] [PATCH] 907 webui: add LDAP vs Kerberos behavior description to user auth types In-Reply-To: <55C88576.70804@redhat.com> References: <55C88576.70804@redhat.com> Message-ID: <55C89E85.50005@redhat.com> On 10/08/15 13:05, Petr Vobornik wrote: > Text in the ticket is IMHO wrong. Patch uses different text.: > """" > If you choose the password and two-factor authentication types at once, > Kerberos still enforces authentication with both password and OTP. LDAP > allows authentication with either one of the authentication types in > this situation. > """ > > One can also use only "Password" with kinit but must provide an armor > ccache. > > e.g.: > $ kinit admin > $ klist > Ticket cache: KEYRING:persistent:17127:17127 > ... > $ kinit -T KEYRING:persistent:17127:17127 fbar > > > https://fedorahosted.org/freeipa/ticket/4935 > > Works for me, ACK. -- David Kupka From jcholast at redhat.com Mon Aug 10 12:54:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Aug 2015 14:54:37 +0200 Subject: [Freeipa-devel] [PATCH] 907 webui: add LDAP vs Kerberos behavior description to user auth types In-Reply-To: <55C89E85.50005@redhat.com> References: <55C88576.70804@redhat.com> <55C89E85.50005@redhat.com> Message-ID: <55C89F0D.7090108@redhat.com> Dne 10.8.2015 v 14:52 David Kupka napsal(a): > On 10/08/15 13:05, Petr Vobornik wrote: >> Text in the ticket is IMHO wrong. Patch uses different text.: >> """" >> If you choose the password and two-factor authentication types at once, >> Kerberos still enforces authentication with both password and OTP. LDAP >> allows authentication with either one of the authentication types in >> this situation. >> """ >> >> One can also use only "Password" with kinit but must provide an armor >> ccache. >> >> e.g.: >> $ kinit admin >> $ klist >> Ticket cache: KEYRING:persistent:17127:17127 >> ... >> $ kinit -T KEYRING:persistent:17127:17127 fbar >> >> >> https://fedorahosted.org/freeipa/ticket/4935 >> >> > Works for me, ACK. > Pushed to: master: ebc7ab1efedb99bd7aa80f53d1f845c3bdce8278 ipa-4-2: dcd8a154e64ac40273cf0d1f7c3e3478856c52ad -- Jan Cholasta From mbabinsk at redhat.com Mon Aug 10 12:59:06 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 10 Aug 2015 14:59:06 +0200 Subject: [Freeipa-devel] [PATCH 0296] Fix upgrade sigdom and extdom config In-Reply-To: <55C88607.8070908@redhat.com> References: <55C88607.8070908@redhat.com> Message-ID: <55C8A01A.9040308@redhat.com> On 08/10/2015 01:07 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5151 > > Patch attached. > ACK -- Martin^3 Babinsky From jcholast at redhat.com Mon Aug 10 13:04:15 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Aug 2015 15:04:15 +0200 Subject: [Freeipa-devel] [PATCH 0296] Fix upgrade sigdom and extdom config In-Reply-To: <55C8A01A.9040308@redhat.com> References: <55C88607.8070908@redhat.com> <55C8A01A.9040308@redhat.com> Message-ID: <55C8A14F.6030005@redhat.com> Dne 10.8.2015 v 14:59 Martin Babinsky napsal(a): > On 08/10/2015 01:07 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5151 >> >> Patch attached. >> > ACK > Pushed to: master: d7be2fd1bdd8c3e2aaf5e4d40714e5a835cfded8 ipa-4-2: 609abd5e30cbf84a7a23bc025e89df45222333f9 -- Jan Cholasta From simo at redhat.com Mon Aug 10 13:12:06 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 10 Aug 2015 09:12:06 -0400 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55C866D5.5040808@redhat.com> References: <55C866D5.5040808@redhat.com> Message-ID: <1439212326.20262.75.camel@willson.usersys.redhat.com> On Mon, 2015-08-10 at 10:54 +0200, Oleg Fayans wrote: > Hi Ludwig, > > It seems the Design page for the topology plugin is a bit outdated. > 1. It still operates with the terms like plugin version > (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), > although it was generally agreed, that we do not use plugin version at all. > > 2. The section > http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition > should be a bit clarified: > Does this mean, that if we prepare a replica from a master that has > domainlevel = 1, then the replica, that already had a domain level = 0 > will raise it? Do we support this scenario at all? No, the domain level must be raised by admin, it cannot be raised automatically by any component least of all a replica joining a domain. > 3. Segment directions. Currently there is no way to specify segment > direction using the cli `ipa topologysegment-add`. However the direction > is shown with `ipa topologysegment-find` and `ipa topologysegment-show`, > which leads to confusing of the users. We probably should remove this > info from the output at all and update the design page accordingly. Showing the direction will allow us in future to show if there are replication issues only in one of the direction. It is true we do not allow to change directions independently (for now at least), but the information shouldn't hurt. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Aug 10 13:22:08 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Aug 2015 15:22:08 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C45BA1.3020209@redhat.com> References: <55C37C89.3040209@redhat.com> <55C453E7.9030700@redhat.com> <55C45444.1070104@redhat.com> <55C45BA1.3020209@redhat.com> Message-ID: <55C8A580.7040700@redhat.com> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): > On 08/07/2015 08:46 AM, Jan Cholasta wrote: >> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>> Hi list, >>>> >>>> I just noticed that the bits built from ipa-4-2 branch cannot be >>>> installed. >>>> The freeipa packages built have version such as >>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>> >>>> The version check in the spec file makes the server-dns package >>>> obsolete the >>>> server package from tha same build. >>>> The cause is the commit [1]. This issue blocks us from running tests >>>> on ipa-4-2 >>>> branch. >>>> >>>> Should we bump the minor version on this branch to 4.2.1? >>>> >>>> [1]: >>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>> >>>> >>>> >>>> >>>> >>>> Cheers, >>>> Milan >>>> >>> Why does the spec calls for >>> >>> # upgrade path from monolithic -server to -server + -server-dns >>> Obsoletes: %{name}-server <= 4.2.0 >>> >>> and not for >>> >>> # upgrade path from monolithic -server to -server + -server-dns >>> Obsoletes: %{name}-server < 4.2.0 >>> >>> ? Is that the root cause of these issues? >> >> AFAIK this would break updates from 4.2.0 to 4.2.1. > > I wonder how it could break the upgrade... > Patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-469-spec-file-Fix-install-with-the-server-dns-subpackage.patch Type: text/x-patch Size: 1104 bytes Desc: not available URL: From akasurde at redhat.com Mon Aug 10 11:47:35 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 10 Aug 2015 17:17:35 +0530 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil Message-ID: <55C88F57.6000500@redhat.com> Hi All, This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-try-except-block-in-ipautil.patch Type: text/x-patch Size: 2991 bytes Desc: not available URL: From mkubik at redhat.com Mon Aug 10 14:03:51 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 10 Aug 2015 16:03:51 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C8AD57.7060206@redhat.com> References: <55C8AD57.7060206@redhat.com> Message-ID: <55C8AF47.4050201@redhat.com> -------- Forwarded Message -------- Subject: Re: [Freeipa-devel] Unable to install bits from ipa-4-2 branch Date: Mon, 10 Aug 2015 15:55:35 +0200 From: Jan Cholasta To: Milan Kub?k CC: Martin Kosek Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): > On 08/10/2015 03:22 PM, Jan Cholasta wrote: >> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>> Hi list, >>>>>> >>>>>> I just noticed that the bits built from ipa-4-2 branch cannot be >>>>>> installed. >>>>>> The freeipa packages built have version such as >>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>> >>>>>> >>>>>> The version check in the spec file makes the server-dns package >>>>>> obsolete the >>>>>> server package from tha same build. >>>>>> The cause is the commit [1]. This issue blocks us from running tests >>>>>> on ipa-4-2 >>>>>> branch. >>>>>> >>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>> >>>>>> [1]: >>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Milan >>>>>> >>>>> Why does the spec calls for >>>>> >>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>> >>>>> and not for >>>>> >>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>> Obsoletes: %{name}-server < 4.2.0 >>>>> >>>>> ? Is that the root cause of these issues? >>>> >>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>> >>> I wonder how it could break the upgrade... >>> >> >> Patch attached. >> > This won't help as long as we build something like > freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e Right. Updated patch attached. It will break updates from pre-server-dns git builds, but install should be fine. -- Jan Cholasta ACK, thanks. Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-469.1-spec-file-Fix-install-with-the-server-dns-subpackage.patch Type: text/x-patch Size: 1104 bytes Desc: not available URL: From dkupka at redhat.com Mon Aug 10 14:14:20 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 10 Aug 2015 16:14:20 +0200 Subject: [Freeipa-devel] [PATCH 0059] dbus: Create empty dbus.Array with specified signature Message-ID: <55C8B1BC.8050002@redhat.com> I was installing freeipa-server earlier today and it failed with "Unable to guess signature from empty list". I was unable to reproduce it but there is now harm in explicitly specifying the signature of the empty list to prevent this issue. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0059-dbus-Create-empty-dbus.Array-with-specified-signatur.patch Type: text/x-patch Size: 1155 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 10 14:41:32 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Aug 2015 16:41:32 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C8AF47.4050201@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> Message-ID: <55C8B81C.9000900@redhat.com> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): > > > > -------- Forwarded Message -------- > Subject: Re: [Freeipa-devel] Unable to install bits from ipa-4-2 branch > Date: Mon, 10 Aug 2015 15:55:35 +0200 > From: Jan Cholasta > To: Milan Kub?k > CC: Martin Kosek > > > > Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>> Hi list, >>>>>>> >>>>>>> I just noticed that the bits built from ipa-4-2 branch cannot be >>>>>>> installed. >>>>>>> The freeipa packages built have version such as >>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>> >>>>>>> >>>>>>> The version check in the spec file makes the server-dns package >>>>>>> obsolete the >>>>>>> server package from tha same build. >>>>>>> The cause is the commit [1]. This issue blocks us from running tests >>>>>>> on ipa-4-2 >>>>>>> branch. >>>>>>> >>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>> >>>>>>> [1]: >>>>>>>https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Milan >>>>>>> >>>>>> Why does the spec calls for >>>>>> >>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>> >>>>>> and not for >>>>>> >>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>> >>>>>> ? Is that the root cause of these issues? >>>>> >>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>> >>>> I wonder how it could break the upgrade... >>>> >>> >>> Patch attached. >>> >> This won't help as long as we build something like >> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e > > Right. Updated patch attached. It will break updates from pre-server-dns > git builds, but install should be fine. > > -- > Jan Cholasta > > > ACK, thanks. Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from the freeipa-4.2 COPR. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-469.2-spec-file-Fix-install-with-the-server-dns-subpackage.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Aug 10 14:58:07 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 10 Aug 2015 16:58:07 +0200 Subject: [Freeipa-devel] [PATCHES 466-468] install: Add common base class for server and replica install In-Reply-To: <55C2FD30.4030303@redhat.com> References: <55C2FD30.4030303@redhat.com> Message-ID: <55C8BBFF.7090907@redhat.com> On 08/06/2015 08:22 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes part of > . > > See also Martin Babinsky's patch 51: > . > > Honza > Sorry but NACK, see below: 1.) it seems that passing kwargs to Server components doesn't work as expected. See these logs (install on fresh F22 VM): http://fpaste.org/253416/21363814/ http://fpaste.org/253419/43921374/ 2.) the following code blows up in BaseServers' __init__: (http://fpaste.org/253400/21225314/) 392 if not self.dns.setup_dns: 393 if self.dns.forwarders: 394 raise RuntimeError( 395 "You cannot specify a --forwarder option without the " 396 "--setup-dns option") I think that the check should be: 392 if not self.setup_dns: 393 if self.dns.forwarders: IMHO BaseServerDNS class shouldn't have setup_dns knob, that should be set in the parent class (BaseServer) 3.) Is there any reason why BaseServer doesn't have 'master_password', 'idmax' and 'idstart' knobs? I know that these are then brought in by the derived Server class, but the check for them is in parent's __init__() method and it is IMHO a bit confusing 4.) please add license header to the beginning of 'ipaserver/install/server/common.py' file -- Martin^3 Babinsky From pviktori at redhat.com Mon Aug 10 15:08:48 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Aug 2015 17:08:48 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <1438377255.24296.43.camel@willson.usersys.redhat.com> References: <55BBAD13.8020308@redhat.com> <1438377255.24296.43.camel@willson.usersys.redhat.com> Message-ID: <55C8BE80.7080703@redhat.com> On 07/31/2015 11:14 PM, Simo Sorce wrote: > On Fri, 2015-07-31 at 19:14 +0200, Petr Viktorin wrote: >> Hello, >> Here is a batch of mostly mechanical changes: removing deprecated >> features to prepare for Python 3. >> > > Do we have accompanying lint (or similar) tests that will prevent new > patches from reintroducing py3 incompatible syntax ? Not yet. These patches are just first steps. Parts of IPA is still not compatible with Python 3 (even syntactically). So, linter would currently need an extensive blacklist/whitelist to be effective. -- Petr Viktorin From spoore at redhat.com Mon Aug 10 15:24:09 2015 From: spoore at redhat.com (Scott Poore) Date: Mon, 10 Aug 2015 11:24:09 -0400 (EDT) Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55C8709F.7030500@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> Message-ID: <1034063240.9562048.1439220248981.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Milan Kub?k" > To: "freeipa-devel" , "Scott Poore" , "Fraser Tweedale" > > Cc: "Namita Soman" , "Ales Marecek" > Sent: Monday, August 10, 2015 4:36:31 AM > Subject: Re: cert profiles - test plan + patches > > On 08/05/2015 02:57 PM, Milan Kub?k wrote: > > Hi list, > > > > I'm sending the test plan [1] for certificate profiles and preliminary > > patches for it. > > The plan covers basic CRUD test and some corner cases. I'm open to more > > suggestions. > > > > More complicated tests involving certificate profiles will require the > > code (and tests) > > for CA ACLs merged, so it's not there at the moment. > > > > There are some unfinished test cases in places I wasn't sure what the > > result should be. > > We need to iterate through these to fix it. > > > > > > [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan > > > > Cheers, > > Milan > Hi all, > > have you had some time to look at the code and proposal? > Today I want to write a basic CRUD test for the ACLs as well as a few > test cases to check if the ACL is being enforced. It should make it into > wiki today or by tomorrow. I'll send an update then. I haven't looked at the actual code yet. Is it checked into git for freeipa yet? This looks good to me for the basic CRUD tests. I do have some questions and requests. Existing tests: * Delete default profile - Did you find out what the expected result should be? * Try to rename the profile entry - Can this be renamed to be more specific to trying to rename ldap attr? - Can we get a new test case to test renaming with certprofile-mod --rename? Possible new tests: * Import a profile in xml - This should fail and I think is at least in the beginning a common mistake. * Change profile config from file - This one may be too large in scope but, could be limited to changing something simple to make sure the file is read and used. Where are you planning to put the CA ACL tests? In the same page? When you have that will you be adding a cert-request test? Thanks, Scott > > Cheers, > Milan > > From pviktori at redhat.com Mon Aug 10 15:39:29 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Aug 2015 17:39:29 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <55BF2F5B.6000804@redhat.com> References: <55BBAD13.8020308@redhat.com> <55BF2F5B.6000804@redhat.com> Message-ID: <55C8C5B1.9020604@redhat.com> On 08/03/2015 11:07 AM, Christian Heimes wrote: > On 2015-07-31 19:14, Petr Viktorin wrote: >> Hello, >> Here is a batch of mostly mechanical changes: removing deprecated >> features to prepare for Python 3. > > Out of curiosity, what tool did you use for patch 695-absolute-imports? > Python-modernize adds from __future__ import absolute_imports and > changes imports to explicit relative imports. I used modernize to find all the occurences, and fixed imports by hand. Most of IPA uses absolute imports, as recommended by PEP 8. > In patch 693 you have removed test cases for CIDict.has_key(), but > CIDict still provides the function. You should either keep the tests > around or remove has_key() from CIDict. I haven't removed them: "test_haskey" is only skipped under Python 3. I assumed that's enough to verify that `has_key` works well (i.e. the same as `in`), so in the other tests I do use `in` instead. I'm attaching updated patches, under Python 3 they remove CIDict.has_key a bit more formally. They're also rebased. > The rest looks good to me, but I haven't studied every change > thoroughly. It's just too much. Anything I can do to help? -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0691.2-Modernize-except-clauses.patch Type: text/x-patch Size: 273857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0692.2-Modernize-function-and-method-attribute-names.patch Type: text/x-patch Size: 5820 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0693.2-Replace-dict.has_key-with-the-in-operator.patch Type: text/x-patch Size: 17933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0694.2-Import-reduce-from-functools.patch Type: text/x-patch Size: 796 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0695.2-Use-absolute-imports.patch Type: text/x-patch Size: 46030 bytes Desc: not available URL: From mkubik at redhat.com Mon Aug 10 15:43:06 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 10 Aug 2015 17:43:06 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution Message-ID: <55C8C68A.1010606@redhat.com> Hi all, this patch fixes problem described in the ticket [1] that caused the test run to fail completely at every other or so run. I took the liberty to fix most of the pep8 issues while I was at it. Thanks to Jan Cholasta for help with identifying this one. [1]: https://fedorahosted.org/freeipa/ticket/5192 Cheers, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0010-tests-fix-the-list-comprehension-leak-in-python-2-an.patch Type: text/x-patch Size: 4533 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 10 15:54:17 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Aug 2015 17:54:17 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C8C68A.1010606@redhat.com> References: <55C8C68A.1010606@redhat.com> Message-ID: <55C8C929.5050806@redhat.com> On 10.8.2015 17:43, Milan Kub?k wrote: > Hi all, > > this patch fixes problem described in the ticket [1] > that caused the test run to fail completely at every other or so run. > I took the liberty to fix most of the pep8 issues while I was at it. > > Thanks to Jan Cholasta for help with identifying this one. IMO this would be more robust: t = None try: ... finally: del t nss.nss_shutdown() By assigning a value to the variable at the beginning you make sure that the del statement will not fail. Honza -- Jan Cholasta From mkubik at redhat.com Mon Aug 10 16:02:27 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 10 Aug 2015 18:02:27 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C8C929.5050806@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> Message-ID: <55C8CB13.7080201@redhat.com> On 08/10/2015 05:54 PM, Jan Cholasta wrote: > On 10.8.2015 17:43, Milan Kub?k wrote: >> Hi all, >> >> this patch fixes problem described in the ticket [1] >> that caused the test run to fail completely at every other or so run. >> I took the liberty to fix most of the pep8 issues while I was at it. >> >> Thanks to Jan Cholasta for help with identifying this one. > > IMO this would be more robust: > > t = None > try: > ... > finally: > del t > nss.nss_shutdown() > > By assigning a value to the variable at the beginning you make sure > that the del statement will not fail. > > Honza > Thanks for the idea. It also removed the version check. Updated patch attached. Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0010.1-tests-fix-the-list-comprehension-leak-in-python-2-an.patch Type: text/x-patch Size: 4938 bytes Desc: not available URL: From mkubik at redhat.com Mon Aug 10 16:22:28 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 10 Aug 2015 18:22:28 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C8CB13.7080201@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> Message-ID: <55C8CFC4.5080004@redhat.com> On 08/10/2015 06:02 PM, Milan Kub?k wrote: > On 08/10/2015 05:54 PM, Jan Cholasta wrote: >> On 10.8.2015 17:43, Milan Kub?k wrote: >>> Hi all, >>> >>> this patch fixes problem described in the ticket [1] >>> that caused the test run to fail completely at every other or so run. >>> I took the liberty to fix most of the pep8 issues while I was at it. >>> >>> Thanks to Jan Cholasta for help with identifying this one. >> >> IMO this would be more robust: >> >> t = None >> try: >> ... >> finally: >> del t >> nss.nss_shutdown() >> >> By assigning a value to the variable at the beginning you make sure >> that the del statement will not fail. >> >> Honza >> > Thanks for the idea. It also removed the version check. > Updated patch attached. > > Milan > > Self NACK. I have updated the fix for all of the leaks in that class. It seems to corrupt the database even when no init/shutdown was called. Just not so often. Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0010.2-tests-fix-the-list-comprehension-leak-in-python-2-an.patch Type: text/x-patch Size: 5626 bytes Desc: not available URL: From mkubik at redhat.com Mon Aug 10 16:50:57 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 10 Aug 2015 18:50:57 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <1034063240.9562048.1439220248981.JavaMail.zimbra@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <1034063240.9562048.1439220248981.JavaMail.zimbra@redhat.com> Message-ID: <55C8D671.2000703@redhat.com> Hi, On 08/10/2015 05:24 PM, Scott Poore wrote: > > ----- Original Message ----- >> From: "Milan Kub?k" >> To: "freeipa-devel" , "Scott Poore" , "Fraser Tweedale" >> >> Cc: "Namita Soman" , "Ales Marecek" >> Sent: Monday, August 10, 2015 4:36:31 AM >> Subject: Re: cert profiles - test plan + patches >> >> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>> Hi list, >>> >>> I'm sending the test plan [1] for certificate profiles and preliminary >>> patches for it. >>> The plan covers basic CRUD test and some corner cases. I'm open to more >>> suggestions. >>> >>> More complicated tests involving certificate profiles will require the >>> code (and tests) >>> for CA ACLs merged, so it's not there at the moment. >>> >>> There are some unfinished test cases in places I wasn't sure what the >>> result should be. >>> We need to iterate through these to fix it. >>> >>> >>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>> >>> Cheers, >>> Milan >> Hi all, >> >> have you had some time to look at the code and proposal? >> Today I want to write a basic CRUD test for the ACLs as well as a few >> test cases to check if the ACL is being enforced. It should make it into >> wiki today or by tomorrow. I'll send an update then. > I haven't looked at the actual code yet. Is it checked into git for freeipa yet? > > This looks good to me for the basic CRUD tests. I do have some questions and requests. > > Existing tests: > > * Delete default profile > - Did you find out what the expected result should be? > I reported this when Fraser was implementing the feature. He decided to allow this (earlier it has failed). At the time I didn't suggest otherwise. The design/documentation could be more clear on this as for, is it allowed to delete all profiles? Doing this will break an awful lot of things. The same applies to ACLs as well, Sub CAs later ditto. Deleting the default profile will break things even if other profiles remain as it is a default, when not specified in cert-request. Fraser, what do you think? > * Try to rename the profile entry > - Can this be renamed to be more specific to trying to rename ldap attr? > - Can we get a new test case to test renaming with certprofile-mod --rename? ACK > Possible new tests: > > * Import a profile in xml > - This should fail and I think is at least in the beginning a common mistake. I will add this. > * Change profile config from file > - This one may be too large in scope but, could be limited to changing something simple to make sure the file is read and used. ACK. Though this will be a part of the more complicated scenario. > Where are you planning to put the CA ACL tests? In the same page? I originally planned to put it under sub CAs, but since the specification for CA ACLs moved into the certificate profiles design, I can add it there. Counting will be done separately from test cases for profiles and it will be implemented (at least the CRUD test cases) in a module where the ACL Tracker will be implemented. > When you have that will you be adding a cert-request test? Yes. I will need to use cert-request to test if the ACL/profile is enforced, if enabled/disabled is in effect. I will not implement this in a module for cert-request, though. I think it will be better to implement these in a separate module to signify it is a test of a conjunction of several parts of the feature (profiles, ACLs and Sub CAs, once this is implemented. If you think otherwise, I'm open to suggestions. > Thanks, > Scott >> Cheers, >> Milan >> >> >> >> Cheers, Milan From mbasti at redhat.com Mon Aug 10 17:08:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 10 Aug 2015 19:08:56 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55C8857E.7070802@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> Message-ID: <55C8DAA8.70702@redhat.com> Thank you for patch, I have a few nitpicks: 1) On 10/08/15 13:05, Oleg Fayans wrote: > +def create_segment(master, leftnode, rightnode): > + """create_segment(master, leftnode, rightnode) Why do you add the name of method in docstring? 2) +def create_segment(master, leftnode, rightnode): + """create_segment(master, leftnode, rightnode) + creates a topology segment. The first argument is a node to run the command on + The first 3 arguments should be objects of class Host + Returns a hash object containing segment's name, leftnode, rightnode information + """ I would prefer to add assert there instead of just document that a Host object is needed assert(isinstance(master, Host)) ... 3) +def destroy_segment(master, segment_name): + """ + destroy_segment(master, segment_name) + Destroys topology segment. First argument should be object of class Host Instead of description of params as first, second etc., you may use following: +def destroy_segment(master, segment_name): + """ + Destroys topology segment. + :param master: reference to master object of class Host + :param segment: name fo segment and eventually this in other methods + :returns: Lorem ipsum sit dolor mit amet + :raises NotFound: if segment is not found 4) cls.replicas[:len(cls.replicas) - 1], I suggest cls.replicas[:-1] In [2]: a = [1, 2, 3, 4, 5] In [3]: a[:-1] Out[3]: [1, 2, 3, 4] 5) Why re.findall() and then you just use the first result? 'leftnode': self.leftnode_re.findall(i)[0] Isn't just re.search() enough? leftnode_re.search(value).group(1) Python 3 nitpick: I'm not sure if time when we should enforce python 2/3 compability already comes, but just for record: instead of open(file, 'r'), please use io.open(file, 'r') (import io before) -- Martin Basti From ksiddiqu at redhat.com Mon Aug 10 17:16:59 2015 From: ksiddiqu at redhat.com (Kaleemullah Siddiqui) Date: Mon, 10 Aug 2015 22:46:59 +0530 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <1034063240.9562048.1439220248981.JavaMail.zimbra@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <1034063240.9562048.1439220248981.JavaMail.zimbra@redhat.com> Message-ID: <55C8DC8B.6000205@redhat.com> On 08/10/2015 08:54 PM, Scott Poore wrote: > > ----- Original Message ----- >> From: "Milan Kub?k" >> To: "freeipa-devel" , "Scott Poore" , "Fraser Tweedale" >> >> Cc: "Namita Soman" , "Ales Marecek" >> Sent: Monday, August 10, 2015 4:36:31 AM >> Subject: Re: cert profiles - test plan + patches >> >> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>> Hi list, >>> >>> I'm sending the test plan [1] for certificate profiles and preliminary >>> patches for it. >>> The plan covers basic CRUD test and some corner cases. I'm open to more >>> suggestions. >>> >>> More complicated tests involving certificate profiles will require the >>> code (and tests) >>> for CA ACLs merged, so it's not there at the moment. >>> >>> There are some unfinished test cases in places I wasn't sure what the >>> result should be. >>> We need to iterate through these to fix it. >>> >>> >>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>> >>> Cheers, >>> Milan >> Hi all, >> >> have you had some time to look at the code and proposal? >> Today I want to write a basic CRUD test for the ACLs as well as a few >> test cases to check if the ACL is being enforced. It should make it into >> wiki today or by tomorrow. I'll send an update then. > I haven't looked at the actual code yet. Is it checked into git for freeipa yet? > > This looks good to me for the basic CRUD tests. I do have some questions and requests. > > Existing tests: > > * Delete default profile > - Did you find out what the expected result should be? > > * Try to rename the profile entry > - Can this be renamed to be more specific to trying to rename ldap attr? > - Can we get a new test case to test renaming with certprofile-mod --rename? > > Possible new tests: > > * Import a profile in xml > - This should fail and I think is at least in the beginning a common mistake. > > * Change profile config from file > - This one may be too large in scope but, could be limited to changing something simple to make sure the file is read and used. > > Where are you planning to put the CA ACL tests? In the same page? > > When you have that will you be adding a cert-request test? Some additional test cases (1) Non-existent profile with certprofile-show (2) certprofile-import with --store both true/false options (3) certprofile-find with store option > > Thanks, > Scott >> Cheers, >> Milan >> >> From edewata at redhat.com Mon Aug 10 18:35:29 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Aug 2015 13:35:29 -0500 Subject: [Freeipa-devel] [PATCH] 372 Added attribute to specify command's CLI name. Message-ID: <55C8EEF1.3000704@redhat.com> A new attribute has been added to the HasParams class to allow a command to specify a different CLI name if necessary. By default the command's CLI name is the same as the class name. https://fedorahosted.org/freeipa/ticket/5189 -- Endi S. Dewata -------------- next part -------------- From 6808e44b97148db8700e47d1d436dd0a30a0c9f9 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 7 Aug 2015 05:00:14 +0200 Subject: [PATCH] Added attribute to specify command's CLI name. A new attribute has been added to the HasParams class to allow a command to specify a different CLI name if necessary. By default the command's CLI name is the same as the class name. https://fedorahosted.org/freeipa/ticket/5189 --- ipalib/backend.py | 15 ++++++++++++-- ipalib/cli.py | 59 ++++++++++++++++++++++++++++++------------------------ ipalib/frontend.py | 19 ++++++++++++++++++ 3 files changed, 65 insertions(+), 28 deletions(-) diff --git a/ipalib/backend.py b/ipalib/backend.py index d510bc73396cd8b219836d28083e3165f226d466..48a4445c34a861d65e80f1fdaf711cbd0f643ae2 100644 --- a/ipalib/backend.py +++ b/ipalib/backend.py @@ -121,12 +121,23 @@ class Executioner(Backend): def destroy_context(self): destroy_context() + def find_command(self, cli_name): + # TODO: replace loop with a dict to map CLI names to commands + for name in self.Command: + cmd = self.Command[name] + if cmd.NO_CLI: + continue + if cmd.cli_name() == cli_name: + return cmd + return None + def execute(self, _name, *args, **options): error = None try: - if _name not in self.Command: + cmd = self.find_command(_name) + if not cmd: raise CommandError(name=_name) - result = self.Command[_name](*args, **options) + result = cmd(*args, **options) except PublicError, e: error = e except StandardError, e: diff --git a/ipalib/cli.py b/ipalib/cli.py index 4104e6482e4e713d701c6c1a4313ab6ecc899057..0fa00d3a6e32fc6095ca3b76270355cf9cb3dd2d 100644 --- a/ipalib/cli.py +++ b/ipalib/cli.py @@ -771,32 +771,40 @@ class help(frontend.Local): if outfile is None: outfile = sys.stdout writer = self._writer(outfile) - name = from_cli(key) - mod_name = '%s.%s' % (self._PLUGIN_BASE_MODULE, name) + if key is None: self.api.parser.print_help(outfile) return - if name == "topics": + + if key == "topics": self.print_topics(outfile) return - if name in self._topics: - self.print_commands(name, outfile) - elif name in self.Command: - cmd = self.Command[name] - if cmd.NO_CLI: - raise HelpError(topic=name) - self.Backend.cli.build_parser(cmd).print_help(outfile) - elif mod_name in sys.modules: - self.print_commands(name, outfile) - elif name == "commands": + + if key in self._topics: + self.print_commands(key, outfile) + return + + if key == "commands": mcl = max(len(s) for s in (self.Command)) for cname in self.Command: cmd = self.Command[cname] if cmd.NO_CLI: continue - writer('%s %s' % (to_cli(cmd.name).ljust(mcl), cmd.summary)) - else: - raise HelpError(topic=name) + writer('%s %s' % (cmd.cli_name().ljust(mcl), cmd.summary)) + return + + cmd = self.find_command(key) + if cmd: + self.Backend.cli.build_parser(cmd).print_help(outfile) + return + + name = from_cli(key) + mod_name = '%s.%s' % (self._PLUGIN_BASE_MODULE, name) + if mod_name in sys.modules: + self.print_commands(name, outfile) + return + + raise HelpError(topic=key) def _writer(self, outfile): def writer(string=''): @@ -848,7 +856,7 @@ class help(frontend.Local): writer(_('Topic commands:')) for c in commands: writer( - ' %s %s' % (to_cli(c.name).ljust(mcl), c.summary)) + ' %s %s' % (c.cli_name().ljust(mcl), c.summary)) writer() writer(_('To get command help, use:')) writer(_(' ipa --help')) @@ -866,10 +874,10 @@ class show_mappings(frontend.Command): has_output = tuple() def run(self, command_name, **options): - command_name = from_cli(command_name) - if command_name not in self.Command: + cmd = self.find_command(command_name) + if not cmd: raise CommandError(name=command_name) - params = self.Command[command_name].options + params = cmd.options out = [('Parameter','LDAP attribute'), ('=========','==============')] mcl = len(out[0][0]) @@ -1061,15 +1069,14 @@ class cli(backend.Executioner): print >>sys.stderr, 'Error: Command not specified' exit(2) (key, argv) = (argv[0], argv[1:]) - name = from_cli(key) - if name not in self.Command and len(argv) == 0: + cmd = self.find_command(key) + if not cmd and len(argv) == 0: try: self.Command.help(unicode(key), outfile=sys.stderr) except HelpError: pass - if name not in self.Command or self.Command[name].NO_CLI: + if not cmd: raise CommandError(name=key) - cmd = self.Command[name] return cmd def process_keyword_arguments(self, cmd, kw): @@ -1090,7 +1097,7 @@ class cli(backend.Executioner): cmd = self.get_command(argv) if cmd is None: return - name = cmd.name + name = cmd.cli_name() kw = self.parse(cmd, argv[1:]) if not isinstance(cmd, frontend.Local): self.create_context() @@ -1207,7 +1214,7 @@ class cli(backend.Executioner): return '[%s]' % name def usage_iter(self, cmd): - yield 'Usage: %%prog [global-options] %s' % to_cli(cmd.name) + yield 'Usage: %%prog [global-options] %s' % cmd.cli_name() for arg in cmd.args(): name = self.__get_arg_name(arg) if name is None: diff --git a/ipalib/frontend.py b/ipalib/frontend.py index 2ca3aaea82ea63702052eedbd7e4081f239cbaed..47cf318dc90e82f71b34ab4790d12bedbc9ed2ec 100644 --- a/ipalib/frontend.py +++ b/ipalib/frontend.py @@ -225,6 +225,15 @@ class HasParam(Plugin): # HasParam is the base class for most frontend plugins, that make it to users # This flag indicates that the command should not be available in the cli NO_CLI = False + CLI_NAME = None + + @classmethod + def cli_name(cls): + if cls.CLI_NAME: + return cls.CLI_NAME + + # TODO: replace with to_cli(cls.__name__) + return cls.__name__.replace('_', '-') def _get_param_iterable(self, name, verb='takes'): """ @@ -457,6 +466,16 @@ class Command(HasParam): self.validate_output(ret, options['version']) return ret + def find_command(self, cli_name): + # TODO: replace loop with a dict to map CLI names to commands + for name in self.Command: + cmd = self.Command[name] + if cmd.NO_CLI: + continue + if cmd.cli_name() == cli_name: + return cmd + return None + def soft_validate(self, values): errors = dict() for p in self.params(): -- 2.4.3 From edewata at redhat.com Mon Aug 10 18:47:43 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Aug 2015 13:47:43 -0500 Subject: [Freeipa-devel] [PATCH] 372 Added attribute to specify command's CLI name. In-Reply-To: <55C8EEF1.3000704@redhat.com> References: <55C8EEF1.3000704@redhat.com> Message-ID: <55C8F1CF.7000400@redhat.com> On 8/10/2015 1:35 PM, Endi Sukma Dewata wrote: > A new attribute has been added to the HasParams class to allow a > command to specify a different CLI name if necessary. By default > the command's CLI name is the same as the class name. > > https://fedorahosted.org/freeipa/ticket/5189 New patch attached. Fixed patch title & description. -- Endi S. Dewata -------------- next part -------------- >From 87e574bfd8fad47320e1dc77d27ec70ebdea7754 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 7 Aug 2015 05:00:14 +0200 Subject: [PATCH] Added attribute to change command's CLI name. A new attribute has been added to the HasParams class to allow a command to change the CLI name if necessary. By default the CLI name is the same as the command's class name. https://fedorahosted.org/freeipa/ticket/5189 --- ipalib/backend.py | 15 ++++++++++++-- ipalib/cli.py | 59 ++++++++++++++++++++++++++++++------------------------ ipalib/frontend.py | 19 ++++++++++++++++++ 3 files changed, 65 insertions(+), 28 deletions(-) diff --git a/ipalib/backend.py b/ipalib/backend.py index d510bc73396cd8b219836d28083e3165f226d466..48a4445c34a861d65e80f1fdaf711cbd0f643ae2 100644 --- a/ipalib/backend.py +++ b/ipalib/backend.py @@ -121,12 +121,23 @@ class Executioner(Backend): def destroy_context(self): destroy_context() + def find_command(self, cli_name): + # TODO: replace loop with a dict to map CLI names to commands + for name in self.Command: + cmd = self.Command[name] + if cmd.NO_CLI: + continue + if cmd.cli_name() == cli_name: + return cmd + return None + def execute(self, _name, *args, **options): error = None try: - if _name not in self.Command: + cmd = self.find_command(_name) + if not cmd: raise CommandError(name=_name) - result = self.Command[_name](*args, **options) + result = cmd(*args, **options) except PublicError, e: error = e except StandardError, e: diff --git a/ipalib/cli.py b/ipalib/cli.py index 4104e6482e4e713d701c6c1a4313ab6ecc899057..0fa00d3a6e32fc6095ca3b76270355cf9cb3dd2d 100644 --- a/ipalib/cli.py +++ b/ipalib/cli.py @@ -771,32 +771,40 @@ class help(frontend.Local): if outfile is None: outfile = sys.stdout writer = self._writer(outfile) - name = from_cli(key) - mod_name = '%s.%s' % (self._PLUGIN_BASE_MODULE, name) + if key is None: self.api.parser.print_help(outfile) return - if name == "topics": + + if key == "topics": self.print_topics(outfile) return - if name in self._topics: - self.print_commands(name, outfile) - elif name in self.Command: - cmd = self.Command[name] - if cmd.NO_CLI: - raise HelpError(topic=name) - self.Backend.cli.build_parser(cmd).print_help(outfile) - elif mod_name in sys.modules: - self.print_commands(name, outfile) - elif name == "commands": + + if key in self._topics: + self.print_commands(key, outfile) + return + + if key == "commands": mcl = max(len(s) for s in (self.Command)) for cname in self.Command: cmd = self.Command[cname] if cmd.NO_CLI: continue - writer('%s %s' % (to_cli(cmd.name).ljust(mcl), cmd.summary)) - else: - raise HelpError(topic=name) + writer('%s %s' % (cmd.cli_name().ljust(mcl), cmd.summary)) + return + + cmd = self.find_command(key) + if cmd: + self.Backend.cli.build_parser(cmd).print_help(outfile) + return + + name = from_cli(key) + mod_name = '%s.%s' % (self._PLUGIN_BASE_MODULE, name) + if mod_name in sys.modules: + self.print_commands(name, outfile) + return + + raise HelpError(topic=key) def _writer(self, outfile): def writer(string=''): @@ -848,7 +856,7 @@ class help(frontend.Local): writer(_('Topic commands:')) for c in commands: writer( - ' %s %s' % (to_cli(c.name).ljust(mcl), c.summary)) + ' %s %s' % (c.cli_name().ljust(mcl), c.summary)) writer() writer(_('To get command help, use:')) writer(_(' ipa --help')) @@ -866,10 +874,10 @@ class show_mappings(frontend.Command): has_output = tuple() def run(self, command_name, **options): - command_name = from_cli(command_name) - if command_name not in self.Command: + cmd = self.find_command(command_name) + if not cmd: raise CommandError(name=command_name) - params = self.Command[command_name].options + params = cmd.options out = [('Parameter','LDAP attribute'), ('=========','==============')] mcl = len(out[0][0]) @@ -1061,15 +1069,14 @@ class cli(backend.Executioner): print >>sys.stderr, 'Error: Command not specified' exit(2) (key, argv) = (argv[0], argv[1:]) - name = from_cli(key) - if name not in self.Command and len(argv) == 0: + cmd = self.find_command(key) + if not cmd and len(argv) == 0: try: self.Command.help(unicode(key), outfile=sys.stderr) except HelpError: pass - if name not in self.Command or self.Command[name].NO_CLI: + if not cmd: raise CommandError(name=key) - cmd = self.Command[name] return cmd def process_keyword_arguments(self, cmd, kw): @@ -1090,7 +1097,7 @@ class cli(backend.Executioner): cmd = self.get_command(argv) if cmd is None: return - name = cmd.name + name = cmd.cli_name() kw = self.parse(cmd, argv[1:]) if not isinstance(cmd, frontend.Local): self.create_context() @@ -1207,7 +1214,7 @@ class cli(backend.Executioner): return '[%s]' % name def usage_iter(self, cmd): - yield 'Usage: %%prog [global-options] %s' % to_cli(cmd.name) + yield 'Usage: %%prog [global-options] %s' % cmd.cli_name() for arg in cmd.args(): name = self.__get_arg_name(arg) if name is None: diff --git a/ipalib/frontend.py b/ipalib/frontend.py index 2ca3aaea82ea63702052eedbd7e4081f239cbaed..47cf318dc90e82f71b34ab4790d12bedbc9ed2ec 100644 --- a/ipalib/frontend.py +++ b/ipalib/frontend.py @@ -225,6 +225,15 @@ class HasParam(Plugin): # HasParam is the base class for most frontend plugins, that make it to users # This flag indicates that the command should not be available in the cli NO_CLI = False + CLI_NAME = None + + @classmethod + def cli_name(cls): + if cls.CLI_NAME: + return cls.CLI_NAME + + # TODO: replace with to_cli(cls.__name__) + return cls.__name__.replace('_', '-') def _get_param_iterable(self, name, verb='takes'): """ @@ -457,6 +466,16 @@ class Command(HasParam): self.validate_output(ret, options['version']) return ret + def find_command(self, cli_name): + # TODO: replace loop with a dict to map CLI names to commands + for name in self.Command: + cmd = self.Command[name] + if cmd.NO_CLI: + continue + if cmd.cli_name() == cli_name: + return cmd + return None + def soft_validate(self, values): errors = dict() for p in self.params(): -- 2.4.3 From edewata at redhat.com Mon Aug 10 18:48:31 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Aug 2015 13:48:31 -0500 Subject: [Freeipa-devel] [PATCH] 373 Fixed conflicting vault 'service' option. Message-ID: <55C8F1FF.9050308@redhat.com> A new vault API has been added to rename the 'service' option to 'servicename' to avoid conflicts with 'service' member in a future patch. The old API is retained for backward compatibility, but the implementation has been changed to invoke the new API. https://fedorahosted.org/freeipa/ticket/5193 -- Endi S. Dewata -------------- next part -------------- From 157d38f6954d5453eb494a542f027cc30eb4ea0d Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Thu, 6 Aug 2015 21:46:27 +0200 Subject: [PATCH] Fixed conflicting vault 'service' option. A new vault API has been added to rename the 'service' option to 'servicename' to avoid conflicts with 'service' member in a future patch. The old API is retained for backward compatibility, but the implementation has been changed to invoke the new API. https://fedorahosted.org/freeipa/ticket/5193 --- API.txt | 230 ++++++++- VERSION | 4 +- ipalib/plugins/vault.py | 595 +++++++++++++++++++----- ipatests/test_xmlrpc/test_vault2_plugin.py | 719 +++++++++++++++++++++++++++++ 4 files changed, 1435 insertions(+), 113 deletions(-) create mode 100644 ipatests/test_xmlrpc/test_vault2_plugin.py diff --git a/API.txt b/API.txt index 04f2f894f7667239d94a2a7278d0cc80704afeb5..9a777bd029d88f6882a9db341822544c6d1e7b5a 100644 --- a/API.txt +++ b/API.txt @@ -5396,6 +5396,232 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault2_add +args: 1,14,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description?', cli_name='desc') +option: Bytes('ipavaultpublickey?', cli_name='public_key') +option: Str('ipavaulttype?', cli_name='type') +option: Str('password?', cli_name='password') +option: Str('password_file?', cli_name='password_file') +option: Str('public_key_file?', cli_name='public_key_file') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault2_add_internal +args: 1,13,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Bytes('ipavaultpublickey', attribute=True, cli_name='public_key', multivalue=False, required=False) +option: Bytes('ipavaultsalt', attribute=True, cli_name='salt', multivalue=False, required=False) +option: Str('ipavaulttype', attribute=True, autofill=True, cli_name='type', default=u'standard', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault2_add_member +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault2_add_owner +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault2_archive +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('data?') +option: Str('in?') +option: Str('password?', cli_name='password') +option: Str('password_file?', cli_name='password_file') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault2_archive_internal +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('nonce') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Bytes('session_key') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Bytes('vault_data') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault2_del +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault2_find +args: 1,13,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('ipavaulttype', attribute=True, autofill=False, cli_name='type', default=u'standard', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault2_mod +args: 1,15,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Bytes('ipavaultpublickey', attribute=True, autofill=False, cli_name='public_key', multivalue=False, required=False) +option: Bytes('ipavaultsalt', attribute=True, autofill=False, cli_name='salt', multivalue=False, required=False) +option: Str('ipavaulttype', attribute=True, autofill=False, cli_name='type', default=u'standard', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('servicename?', cli_name='service') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault2_remove_member +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault2_remove_owner +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault2_retrieve +args: 1,11,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('out?') +option: Str('password?', cli_name='password') +option: Str('password_file?', cli_name='password_file') +option: Bytes('private_key?', cli_name='private_key') +option: Str('private_key_file?', cli_name='private_key_file') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault2_retrieve_internal +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('servicename?', cli_name='service') +option: Bytes('session_key') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault2_show +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('servicename?', cli_name='service') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) command: vault_add args: 1,14,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) @@ -5417,8 +5643,9 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add_internal -args: 1,11,3 +args: 1,13,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Bytes('ipavaultpublickey', attribute=True, cli_name='public_key', multivalue=False, required=False) @@ -5427,6 +5654,7 @@ option: Str('ipavaulttype', attribute=True, autofill=True, cli_name='type', defa option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') +option: Str('setattr*', cli_name='setattr', exclude='webui') option: Flag('shared?', autofill=True, default=False) option: Str('username?', cli_name='user') option: Str('version?', exclude='webui') diff --git a/VERSION b/VERSION index a3d586df47ab6a6136bd38c0151fe43876bf5ab3..e656524418e5fedbd318e6998aa67ffc20750533 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=148 -# Last change: ftweedal - add --out option to user-show +IPA_API_VERSION_MINOR=149 +# Last change: edewata - Fixed conflicting vault 'service' option. diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 423df6b7c0e39c46b20561133be8cd54560bf8b9..e32d378dbdc7118c2fd60aeabe7a3993c2d63c9c 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -257,11 +257,225 @@ vault_options = ( ), ) +vault2_options = ( + Str( + 'servicename?', + cli_name='service', + doc=_('Service name of the service vault'), + ), + Flag( + 'shared?', + doc=_('Shared vault'), + ), + Str( + 'username?', + cli_name='user', + doc=_('Username of the user vault'), + ), +) + +vault_add_options = ( + Str( + 'description?', + cli_name='desc', + doc=_('Vault description'), + ), + Str( + 'ipavaulttype?', + cli_name='type', + doc=_('Vault type'), + ), + Str( + 'password?', + cli_name='password', + doc=_('Vault password'), + ), + Str( # TODO: use File parameter + 'password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), + Bytes( + 'ipavaultpublickey?', + cli_name='public_key', + doc=_('Vault public key'), + ), + Str( # TODO: use File parameter + 'public_key_file?', + cli_name='public_key_file', + doc=_('File containing the vault public key'), + ), +) + +vault_archive_options = ( + Bytes( + 'data?', + doc=_('Binary data to archive'), + ), + Str( # TODO: use File parameter + 'in?', + doc=_('File containing data to archive'), + ), + Str( + 'password?', + cli_name='password', + doc=_('Vault password'), + ), + Str( # TODO: use File parameter + 'password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), +) + +vault_archive_internal_options = ( + Bytes( + 'session_key', + doc=_('Session key wrapped with transport certificate'), + ), + Bytes( + 'vault_data', + doc=_('Vault data encrypted with session key'), + ), + Bytes( + 'nonce', + doc=_('Nonce'), + ), +) + +vault_retrieve_options = ( + Str( + 'out?', + doc=_('File to store retrieved data'), + ), + Str( + 'password?', + cli_name='password', + doc=_('Vault password'), + ), + Str( # TODO: use File parameter + 'password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), + Bytes( + 'private_key?', + cli_name='private_key', + doc=_('Vault private key'), + ), + Str( # TODO: use File parameter + 'private_key_file?', + cli_name='private_key_file', + doc=_('File containing the vault private key'), + ), +) + +vault_retrieve_internal_options = ( + Bytes( + 'session_key', + doc=_('Session key wrapped with transport certificate'), + ), +) + + +def convert_options(**options): + options = options.copy() + + if 'service' in options: + options['servicename'] = options.pop('service') + + return options + @register() class vault(LDAPObject): __doc__ = _(""" - Vault object. + Vault 1.0 Plugin. + """) + + container_dn = api.env.container_vault + + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', + 'description', + 'ipavaulttype', + 'ipavaultsalt', + 'ipavaultpublickey', + 'owner', + 'member', + ] + search_display_attributes = [ + 'cn', + 'description', + 'ipavaulttype', + ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str( + 'cn', + cli_name='name', + label=_('Vault name'), + primary_key=True, + pattern='^[a-zA-Z0-9_.-]+$', + pattern_errmsg='may only include letters, numbers, _, ., and -', + maxlength=255, + ), + Str( + 'description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + Str( + 'ipavaulttype?', + cli_name='type', + label=_('Type'), + doc=_('Vault type'), + default=u'standard', + autofill=True, + ), + Bytes( + 'ipavaultsalt?', + cli_name='salt', + label=_('Salt'), + doc=_('Vault salt'), + flags=['no_search'], + ), + Bytes( + 'ipavaultpublickey?', + cli_name='public_key', + label=_('Public key'), + doc=_('Vault public key'), + flags=['no_search'], + ), + Str( + 'owner_user?', + label=_('Owner users'), + flags=['no_create', 'no_update', 'no_search'], + ), + Str( + 'owner_group?', + label=_('Owner groups'), + flags=['no_create', 'no_update', 'no_search'], + ), + ) + + + at register() +class vault2(LDAPObject): + __doc__ = _(""" + Vault 1.1 Plugin. """) container_dn = api.env.container_vault @@ -347,7 +561,7 @@ class vault(LDAPObject): Generates vault DN from parameters. """ - service = options.get('service') + service = options.get('servicename') shared = options.get('shared') user = options.get('username') @@ -369,7 +583,7 @@ class vault(LDAPObject): # TODO: create container_dn after object initialization then reuse it container_dn = DN(self.container_dn, self.api.env.basedn) - dn = super(vault, self).get_dn(*keys, **options) + dn = super(vault2, self).get_dn(*keys, **options) assert dn.endswith(container_dn) rdns = DN(*dn[:-len(container_dn)]) @@ -546,38 +760,26 @@ class vault(LDAPObject): class vault_add(PKQuery, Local): __doc__ = _('Create a new vault.') - takes_options = LDAPCreate.takes_options + vault_options + ( - Str( - 'description?', - cli_name='desc', - doc=_('Vault description'), - ), - Str( - 'ipavaulttype?', - cli_name='type', - doc=_('Vault type'), - ), - Str( - 'password?', - cli_name='password', - doc=_('Vault password'), - ), - Str( # TODO: use File parameter - 'password_file?', - cli_name='password_file', - doc=_('File containing the vault password'), - ), - Bytes( - 'ipavaultpublickey?', - cli_name='public_key', - doc=_('Vault public key'), - ), - Str( # TODO: use File parameter - 'public_key_file?', - cli_name='public_key_file', - doc=_('File containing the vault public key'), - ), - ) + NO_CLI = True + + takes_options = LDAPCreate.takes_options + vault_options + \ + vault_add_options + + has_output = output.standard_entry + + def forward(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_add(*args, **options) + + + at register() +class vault2_add(PKQuery, Local): + __doc__ = _('Create a new vault.') + + CLI_NAME = 'vault-add' + + takes_options = LDAPCreate.takes_options + vault2_options + \ + vault_add_options has_output = output.standard_entry @@ -654,7 +856,7 @@ class vault_add(PKQuery, Local): error=_('Missing vault public key')) # create vault - response = self.api.Command.vault_add_internal(*args, **options) + response = self.api.Command.vault2_add_internal(*args, **options) # prepare parameters for archival opts = options.copy() @@ -671,7 +873,7 @@ class vault_add(PKQuery, Local): del opts['ipavaultpublickey'] # archive blank data - self.api.Command.vault_archive(*args, **opts) + self.api.Command.vault2_archive(*args, **opts) return response @@ -681,7 +883,20 @@ class vault_add_internal(LDAPCreate): NO_CLI = True - takes_options = vault_options + takes_options = LDAPCreate.takes_options + vault_options + + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_add_internal(*args, **options) + + + at register() +class vault2_add_internal(LDAPCreate): + __doc__ = _('Create a new vault.') + + NO_CLI = True + + takes_options = LDAPCreate.takes_options + vault2_options msg_summary = _('Added vault "%(value)s"') @@ -715,8 +930,23 @@ class vault_add_internal(LDAPCreate): class vault_del(LDAPDelete): __doc__ = _('Delete a vault.') + NO_CLI = True + takes_options = LDAPDelete.takes_options + vault_options + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_del(*args, **options) + + + at register() +class vault2_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + CLI_NAME = 'vault-del' + + takes_options = LDAPDelete.takes_options + vault2_options + msg_summary = _('Deleted vault "%(value)s"') def pre_callback(self, ldap, dn, *keys, **options): @@ -756,10 +986,27 @@ class vault_del(LDAPDelete): class vault_find(LDAPSearch): __doc__ = _('Search for vaults.') + NO_CLI = True + takes_options = LDAPSearch.takes_options + vault_options has_output_params = LDAPSearch.has_output_params + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_find(*args, **options) + + + at register() +class vault2_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + CLI_NAME = 'vault-find' + + takes_options = LDAPSearch.takes_options + vault2_options + + has_output_params = LDAPSearch.has_output_params + msg_summary = ngettext( '%(count)d vault matched', '%(count)d vaults matched', @@ -793,10 +1040,25 @@ class vault_find(LDAPSearch): class vault_mod(LDAPUpdate): __doc__ = _('Modify a vault.') + NO_CLI = True + takes_options = LDAPUpdate.takes_options + vault_options + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_mod(*args, **options) + + + at register() +class vault2_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + takes_options = LDAPUpdate.takes_options + vault2_options + msg_summary = _('Modified vault "%(value)s"') + CLI_NAME = 'vault-mod' + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): @@ -813,13 +1075,29 @@ class vault_mod(LDAPUpdate): class vault_show(LDAPRetrieve): __doc__ = _('Display information about a vault.') + NO_CLI = True + takes_options = LDAPRetrieve.takes_options + vault_options has_output_params = LDAPRetrieve.has_output_params + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_show(*args, **options) + + + at register() +class vault2_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + CLI_NAME = 'vault-show' + + takes_options = LDAPRetrieve.takes_options + vault2_options + + has_output_params = LDAPRetrieve.has_output_params + def pre_callback(self, ldap, dn, attrs_list, *keys, **options): assert isinstance(dn, DN) - if not self.api.Command.kra_is_enabled()['result']: raise errors.InvocationError( format=_('KRA service is not enabled')) @@ -886,26 +1164,24 @@ class vaultconfig_show(Retrieve): class vault_archive(PKQuery, Local): __doc__ = _('Archive data into a vault.') - takes_options = vault_options + ( - Bytes( - 'data?', - doc=_('Binary data to archive'), - ), - Str( # TODO: use File parameter - 'in?', - doc=_('File containing data to archive'), - ), - Str( - 'password?', - cli_name='password', - doc=_('Vault password'), - ), - Str( # TODO: use File parameter - 'password_file?', - cli_name='password_file', - doc=_('File containing the vault password'), - ), - ) + NO_CLI = True + + takes_options = vault_options + vault_archive_options + + has_output = output.standard_entry + + def forward(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_archive(*args, **options) + + + at register() +class vault2_archive(PKQuery, Local): + __doc__ = _('Archive data into a vault.') + + CLI_NAME = 'vault-archive' + + takes_options = vault2_options + vault_archive_options has_output = output.standard_entry @@ -948,7 +1224,7 @@ class vault_archive(PKQuery, Local): backend.connect(ccache=krbV.default_context().default_ccache()) # retrieve vault info - vault = self.api.Command.vault_show(*args, **options)['result'] + vault = self.api.Command.vault2_show(*args, **options)['result'] vault_type = vault['ipavaulttype'][0] @@ -979,7 +1255,7 @@ class vault_archive(PKQuery, Local): opts = options.copy() opts['password'] = password try: - self.api.Command.vault_retrieve(*args, **opts) + self.api.Command.vault2_retrieve(*args, **opts) except errors.NotFound: pass @@ -1063,7 +1339,7 @@ class vault_archive(PKQuery, Local): options['vault_data'] = wrapped_vault_data - return self.api.Command.vault_archive_internal(*args, **options) + return self.api.Command.vault2_archive_internal(*args, **options) @register() @@ -1071,20 +1347,22 @@ class vault_archive_internal(PKQuery): NO_CLI = True - takes_options = vault_options + ( - Bytes( - 'session_key', - doc=_('Session key wrapped with transport certificate'), - ), - Bytes( - 'vault_data', - doc=_('Vault data encrypted with session key'), - ), - Bytes( - 'nonce', - doc=_('Nonce'), - ), - ) + takes_options = vault_options + vault_archive_internal_options + + has_output = output.standard_entry + + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_archive_internal(*args, **options) + + + at register() +class vault2_archive_internal(PKQuery): + __doc__ = _('Archive data into a vault.') + + NO_CLI = True + + takes_options = vault2_options + vault_archive_internal_options has_output = output.standard_entry @@ -1101,7 +1379,7 @@ class vault_archive_internal(PKQuery): wrapped_session_key = options.pop('session_key') # retrieve vault info - vault = self.api.Command.vault_show(*args, **options)['result'] + vault = self.api.Command.vault2_show(*args, **options)['result'] # connect to KRA kra_client = self.api.Backend.kra.get_client() @@ -1147,33 +1425,31 @@ class vault_archive_internal(PKQuery): class vault_retrieve(PKQuery, Local): __doc__ = _('Retrieve a data from a vault.') - takes_options = vault_options + ( - Str( - 'out?', - doc=_('File to store retrieved data'), - ), - Str( - 'password?', - cli_name='password', - doc=_('Vault password'), - ), - Str( # TODO: use File parameter - 'password_file?', - cli_name='password_file', - doc=_('File containing the vault password'), - ), + NO_CLI = True + + takes_options = vault_options + vault_retrieve_options + + has_output = output.standard_entry + has_output_params = ( Bytes( - 'private_key?', - cli_name='private_key', - doc=_('Vault private key'), - ), - Str( # TODO: use File parameter - 'private_key_file?', - cli_name='private_key_file', - doc=_('File containing the vault private key'), + 'data', + label=_('Data'), ), ) + def forward(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_retrieve(*args, **options) + + + at register() +class vault2_retrieve(PKQuery, Local): + __doc__ = _('Retrieve a data from a vault.') + + CLI_NAME = 'vault-retrieve' + + takes_options = vault2_options + vault_retrieve_options + has_output = output.standard_entry has_output_params = ( Bytes( @@ -1213,7 +1489,7 @@ class vault_retrieve(PKQuery, Local): backend.connect(ccache=krbV.default_context().default_ccache()) # retrieve vault info - vault = self.api.Command.vault_show(*args, **options)['result'] + vault = self.api.Command.vault2_show(*args, **options)['result'] vault_type = vault['ipavaulttype'][0] @@ -1241,7 +1517,7 @@ class vault_retrieve(PKQuery, Local): # send retrieval request to server options['session_key'] = wrapped_session_key.data - response = self.api.Command.vault_retrieve_internal(*args, **options) + response = self.api.Command.vault2_retrieve_internal(*args, **options) result = response['result'] nonce = result['nonce'] @@ -1295,7 +1571,8 @@ class vault_retrieve(PKQuery, Local): password = self.obj.get_existing_password() # generate encryption key from password - encryption_key = self.obj.generate_symmetric_key(password, salt) + encryption_key = \ + self.obj.generate_symmetric_key(password, salt) # decrypt data with encryption key data = self.obj.decrypt(data, symmetric_key=encryption_key) @@ -1347,12 +1624,22 @@ class vault_retrieve_internal(PKQuery): NO_CLI = True - takes_options = vault_options + ( - Bytes( - 'session_key', - doc=_('Session key wrapped with transport certificate'), - ), - ) + takes_options = vault_options + vault_retrieve_internal_options + + has_output = output.standard_entry + + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_retrieve_internal(*args, **options) + + + at register() +class vault2_retrieve_internal(PKQuery): + __doc__ = _('Retrieve a data from a vault.') + + NO_CLI = True + + takes_options = vault2_options + vault_retrieve_internal_options has_output = output.standard_entry @@ -1367,7 +1654,7 @@ class vault_retrieve_internal(PKQuery): wrapped_session_key = options.pop('session_key') # retrieve vault info - vault = self.api.Command.vault_show(*args, **options)['result'] + vault = self.api.Command.vault2_show(*args, **options)['result'] # connect to KRA kra_client = self.api.Backend.kra.get_client() @@ -1411,6 +1698,8 @@ class vault_retrieve_internal(PKQuery): class vault_add_owner(LDAPAddMember): __doc__ = _('Add owners to a vault.') + NO_CLI = True + takes_options = LDAPAddMember.takes_options + vault_options member_attributes = ['owner'] @@ -1430,11 +1719,40 @@ class vault_add_owner(LDAPAddMember): ), ) + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_add_owner(*args, **options) + + + at register() +class vault2_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault.') + + CLI_NAME = 'vault-add-owner' + + takes_options = LDAPAddMember.takes_options + vault2_options + + has_output = ( + output.Entry('result'), + output.Output( + 'failed', + type=dict, + doc=_('Owners that could not be added'), + ), + output.Output( + 'completed', + type=int, + doc=_('Number of owners added'), + ), + ) + @register() class vault_remove_owner(LDAPRemoveMember): __doc__ = _('Remove owners from a vault.') + NO_CLI = True + takes_options = LDAPRemoveMember.takes_options + vault_options member_attributes = ['owner'] @@ -1454,20 +1772,77 @@ class vault_remove_owner(LDAPRemoveMember): ), ) + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_remove_owner(*args, **options) + + + at register() +class vault2_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault.') + + CLI_NAME = 'vault-remove-owner' + + takes_options = LDAPRemoveMember.takes_options + vault2_options + + has_output = ( + output.Entry('result'), + output.Output( + 'failed', + type=dict, + doc=_('Owners that could not be removed'), + ), + output.Output( + 'completed', + type=int, + doc=_('Number of owners removed'), + ), + ) + @register() class vault_add_member(LDAPAddMember): __doc__ = _('Add members to a vault.') + NO_CLI = True + takes_options = LDAPAddMember.takes_options + vault_options + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_add_member(*args, **options) + + + at register() +class vault2_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault.') + + CLI_NAME = 'vault-add-member' + + takes_options = LDAPAddMember.takes_options + vault2_options + @register() class vault_remove_member(LDAPRemoveMember): __doc__ = _('Remove members from a vault.') + NO_CLI = True + takes_options = LDAPRemoveMember.takes_options + vault_options + def execute(self, *args, **options): + options = convert_options(**options) + return self.api.Command.vault2_remove_member(*args, **options) + + + at register() +class vault2_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault.') + + CLI_NAME = 'vault-remove-member' + + takes_options = LDAPRemoveMember.takes_options + vault2_options + @register() class kra_is_enabled(Command): diff --git a/ipatests/test_xmlrpc/test_vault2_plugin.py b/ipatests/test_xmlrpc/test_vault2_plugin.py new file mode 100644 index 0000000000000000000000000000000000000000..ff025967cb1aad61a4ed44173a780e73c0d5f3ac --- /dev/null +++ b/ipatests/test_xmlrpc/test_vault2_plugin.py @@ -0,0 +1,719 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2015 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +""" +Test the `ipalib/plugins/vault.py` module. +""" + +import nose +from ipalib import api, errors +from xmlrpc_test import Declarative, fuzzy_string + +vault_name = u'test_vault' +service_name = u'HTTP/server.example.com' +user_name = u'testuser' + +standard_vault_name = u'standard_test_vault' +symmetric_vault_name = u'symmetric_test_vault' +asymmetric_vault_name = u'asymmetric_test_vault' + +# binary data from \x00 to \xff +secret = ''.join(map(chr, xrange(0, 256))) + +password = u'password' + +public_key = """ +-----BEGIN PUBLIC KEY----- +MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnT61EFxUOQgCJdM0tmw/ +pRRPDPGchTClnU1eBtiQD3ItKYf1+weMGwGOSJXPtkto7NlE7Qs8WHAr0UjyeBDe +k/zeB6nSVdk47OdaW1AHrJL+44r238Jbm/+7VO5lTu6Z4N5p0VqoWNLi0Uh/CkqB +tsxXaaAgjMp0AGq2U/aO/akeEYWQOYIdqUKVgAEKX5MmIA8tmbmoYIQ+B4Q3vX7N +otG4eR6c2o9Fyjd+M4Gai5Ce0fSrigRvxAYi8xpRkQ5yQn5gf4WVrn+UKTfOIjLO +pVThop+Xivcre3SpI0kt6oZPhBw9i8gbMnqifVmGFpVdhq+QVBqp+MVJvTbhRPG6 +3wIDAQAB +-----END PUBLIC KEY----- +""" + +private_key = """ +-----BEGIN RSA PRIVATE KEY----- +MIIEpAIBAAKCAQEAnT61EFxUOQgCJdM0tmw/pRRPDPGchTClnU1eBtiQD3ItKYf1 ++weMGwGOSJXPtkto7NlE7Qs8WHAr0UjyeBDek/zeB6nSVdk47OdaW1AHrJL+44r2 +38Jbm/+7VO5lTu6Z4N5p0VqoWNLi0Uh/CkqBtsxXaaAgjMp0AGq2U/aO/akeEYWQ +OYIdqUKVgAEKX5MmIA8tmbmoYIQ+B4Q3vX7NotG4eR6c2o9Fyjd+M4Gai5Ce0fSr +igRvxAYi8xpRkQ5yQn5gf4WVrn+UKTfOIjLOpVThop+Xivcre3SpI0kt6oZPhBw9 +i8gbMnqifVmGFpVdhq+QVBqp+MVJvTbhRPG63wIDAQABAoIBAQCD2bXnfxPcMnvi +jaPwpvoDCPF0EBBHmk/0g5ApO2Qon3uBDJFUqbJwXrCY6o2d9MOJfnGONlKmcYA8 +X+d4h+SqwGjIkjxdYeSauS+Jy6Rzr1ptH/P8EjPQrfG9uJxYQDflV3nxYwwwVrx7 +8kccMPdteRB+8Bb7FzOHufMimmayCNFETnVT5CKH2PrYoPB+fr0itCipWOenDp33 +e73OV+K9U3rclmtHaoRxGohqByKfQRUkipjw4m+T3qfZZc5eN77RGW8J+oL1GVom +fwtiH7N1HVte0Dmd13nhiASg355kjqRPcIMPsRHvXkOpgg5HRUTKG5elqAyvvm27 +Fzj1YdeRAoGBAMnE61+FYh8qCyEGe8r6RGjO8iuoyk1t+0gBWbmILLBiRnj4K8Tc +k7HBG/pg3XCNbCuRwiLg8tk3VAAXzn6o+IJr3QnKbNCGa1lKfYU4mt11sBEyuL5V +NpZcZ8IiPhMlGyDA9cFbTMKOE08RqbOIdxOmTizFt0R5sYZAwOjEvBIZAoGBAMeC +N/P0bdrScFZGeS51wEdiWme/CO0IyGoqU6saI8L0dbmMJquiaAeIEjIKLqxH1RON +axhsyk97e0PCcc5QK62Utf50UUAbL/v7CpIG+qdSRYDO4bVHSCkwF32N3pYh/iVU +EsEBEkZiJi0dWa/0asDbsACutxcHda3RI5pi7oO3AoGAcbGNs/CUHt1xEfX2UaT+ +YVSjb2iYPlNH8gYYygvqqqVl8opdF3v3mYUoP8jPXrnCBzcF/uNk1HNx2O+RQxvx +lIQ1NGwlLsdfvBvWaPhBg6LqSHadVVrs/IMrUGA9PEp/Y9B3arIIqeSnCrn4Nxsh +higDCwWKRIKSPwVD7qXVGBkCgYEAu5/CASIRIeYgEXMLSd8hKcDcJo8o1MoauIT/ +1Hyrvw9pm0qrn2QHk3WrLvYWeJzBTTcEzZ6aEG+fN9UodA8/VGnzUc6QDsrCsKWh +hj0cArlDdeSZrYLQ4TNCFCiUePqU6QQM8weP6TMqlejxTKF+t8qi1bF5rCWuzP1P +D0UU7DcCgYAUvmEGckugS+FTatop8S/rmkcQ4Bf5M/YCZfsySavucDiHcBt0QtXt +Swh0XdDsYS3W1yj2XqqsQ7R58KNaffCHjjulWFzb5IiuSvvdxzWtiXHisOpO36MJ +kUlCMj24a8XsShzYTWBIyW2ngvGe3pQ9PfjkUdm0LGZjYITCBvgOKw== +-----END RSA PRIVATE KEY----- +""" + + +class test_vault2_plugin(Declarative): + + @classmethod + def setup_class(cls): + if not api.Backend.rpcclient.isconnected(): + api.Backend.rpcclient.connect(fallback=False) + + if not api.Command.kra_is_enabled()['result']: + raise nose.SkipTest('KRA service is not enabled') + + super(test_vault2_plugin, cls).setup_class() + + cleanup_commands = [ + ('vault2_del', [vault_name], {'continue': True}), + ('vault2_del', [vault_name], { + 'servicename': service_name, + 'continue': True + }), + ('vault2_del', [vault_name], {'shared': True, 'continue': True}), + ('vault2_del', [vault_name], { + 'username': user_name, + 'continue': True + }), + ('vault2_del', [standard_vault_name], {'continue': True}), + ('vault2_del', [symmetric_vault_name], {'continue': True}), + ('vault2_del', [asymmetric_vault_name], {'continue': True}), + ] + + tests = [ + + { + 'desc': 'Create private vault', + 'command': ( + 'vault2_add', + [vault_name], + {}, + ), + 'expected': { + 'value': vault_name, + 'summary': 'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Find private vaults', + 'command': ( + 'vault2_find', + [], + {}, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + }, + ], + }, + }, + + { + 'desc': 'Show private vault', + 'command': ( + 'vault2_show', + [vault_name], + {}, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Modify private vault', + 'command': ( + 'vault2_mod', + [vault_name], + { + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Delete private vault', + 'command': ( + 'vault2_del', + [vault_name], + {}, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create service vault', + 'command': ( + 'vault2_add', + [vault_name], + { + 'servicename': service_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,cn=kra,%s' + % (vault_name, service_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Find service vaults', + 'command': ( + 'vault2_find', + [], + { + 'servicename': service_name, + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,cn=kra,%s' + % (vault_name, service_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + }, + ], + }, + }, + + { + 'desc': 'Show service vault', + 'command': ( + 'vault2_show', + [vault_name], + { + 'servicename': service_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=services,cn=vaults,cn=kra,%s' + % (vault_name, service_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Modify service vault', + 'command': ( + 'vault2_mod', + [vault_name], + { + 'servicename': service_name, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Delete service vault', + 'command': ( + 'vault2_del', + [vault_name], + { + 'servicename': service_name, + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create shared vault', + 'command': ( + 'vault2_add', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,cn=kra,%s' + % (vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Find shared vaults', + 'command': ( + 'vault2_find', + [], + { + 'shared': True + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=shared,cn=vaults,cn=kra,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + }, + ], + }, + }, + + { + 'desc': 'Show shared vault', + 'command': ( + 'vault2_show', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=shared,cn=vaults,cn=kra,%s' + % (vault_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Modify shared vault', + 'command': ( + 'vault2_mod', + [vault_name], + { + 'shared': True, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Delete shared vault', + 'command': ( + 'vault2_del', + [vault_name], + { + 'shared': True + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create user vault', + 'command': ( + 'vault2_add', + [vault_name], + { + 'username': user_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Added vault "%s"' % vault_name, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,cn=kra,%s' + % (vault_name, user_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Find user vaults', + 'command': ( + 'vault2_find', + [], + { + 'username': user_name, + }, + ), + 'expected': { + 'count': 1, + 'truncated': False, + 'summary': u'1 vault matched', + 'result': [ + { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,cn=kra,%s' + % (vault_name, user_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + }, + ], + }, + }, + + { + 'desc': 'Show user vault', + 'command': ( + 'vault2_show', + [vault_name], + { + 'username': user_name, + }, + ), + 'expected': { + 'value': vault_name, + 'summary': None, + 'result': { + 'dn': u'cn=%s,cn=%s,cn=users,cn=vaults,cn=kra,%s' + % (vault_name, user_name, api.env.basedn), + 'cn': [vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Modify user vault', + 'command': ( + 'vault2_mod', + [vault_name], + { + 'username': user_name, + 'description': u'Test vault', + }, + ), + 'expected': { + 'value': vault_name, + 'summary': u'Modified vault "%s"' % vault_name, + 'result': { + 'cn': [vault_name], + 'description': [u'Test vault'], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Delete user vault', + 'command': ( + 'vault2_del', + [vault_name], + { + 'username': user_name, + }, + ), + 'expected': { + 'value': [vault_name], + 'summary': u'Deleted vault "%s"' % vault_name, + 'result': { + 'failed': (), + }, + }, + }, + + { + 'desc': 'Create standard vault', + 'command': ( + 'vault2_add', + [standard_vault_name], + {}, + ), + 'expected': { + 'value': standard_vault_name, + 'summary': 'Added vault "%s"' % standard_vault_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (standard_vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [standard_vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Archive secret into standard vault', + 'command': ( + 'vault2_archive', + [standard_vault_name], + { + 'data': secret, + }, + ), + 'expected': { + 'value': standard_vault_name, + 'summary': 'Archived data into vault "%s"' + % standard_vault_name, + 'result': {}, + }, + }, + + { + 'desc': 'Retrieve secret from standard vault', + 'command': ( + 'vault2_retrieve', + [standard_vault_name], + {}, + ), + 'expected': { + 'value': standard_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % standard_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { + 'desc': 'Create symmetric vault', + 'command': ( + 'vault2_add', + [symmetric_vault_name], + { + 'ipavaulttype': u'symmetric', + 'password': password, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': 'Added vault "%s"' % symmetric_vault_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (symmetric_vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [symmetric_vault_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Archive secret into symmetric vault', + 'command': ( + 'vault2_archive', + [symmetric_vault_name], + { + 'password': password, + 'data': secret, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': 'Archived data into vault "%s"' + % symmetric_vault_name, + 'result': {}, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault', + 'command': ( + 'vault2_retrieve', + [symmetric_vault_name], + { + 'password': password, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { + 'desc': 'Create asymmetric vault', + 'command': ( + 'vault2_add', + [asymmetric_vault_name], + { + 'ipavaulttype': u'asymmetric', + 'ipavaultpublickey': public_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': 'Added vault "%s"' % asymmetric_vault_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (asymmetric_vault_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [asymmetric_vault_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Archive secret into asymmetric vault', + 'command': ( + 'vault2_archive', + [asymmetric_vault_name], + { + 'data': secret, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': 'Archived data into vault "%s"' + % asymmetric_vault_name, + 'result': {}, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault', + 'command': ( + 'vault2_retrieve', + [asymmetric_vault_name], + { + 'private_key': private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + ] -- 2.4.3 From edewata at redhat.com Mon Aug 10 19:12:30 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Aug 2015 14:12:30 -0500 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55C0DB02.8080306@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> <1438690803.20262.25.camel@willson.usersys.redhat.com> <55C0C371.5060000@redhat.com> <55C0DB02.8080306@redhat.com> Message-ID: <55C8F79E.8070405@redhat.com> On 8/4/2015 10:32 AM, Endi Sukma Dewata wrote: >>> Martin, I do not think going on with business as usual is the right >>> thing to do here. We know this is going to bite. >>> I suggest Endy adds a *new* API if making it backwards compatible is not >>> possible. The era of bumping whole API version must stop, the sooner the >>> better. >> >> My point is that we do not know yet how to do this kind of changes >> long term. >> So what I did not want to end up are 2 copy&pasted Vault plugins >> maintained >> forever, differing in just that. >> >> If you know how to do this without copypasting, I will be fine with that. > > We probably can do it like this: > * the old plugin continues to provide Vault 1.0 functionality > * the new plugin will be a proxy to the old plugin except for the parts > that have changed in Vault 1.1. > > Or the other way around: > * the new plugin will provide Vault 1.1 functionality > * the old plugin will be a proxy to the new plugin except for the parts > that needs to be maintained for Vault 1.0. > > The first option is probably safer. > > In any case, IPA 4.2.1 will only provide a single client for Vault 1.1, > but two services for Vault 1.0 and 1.1. A new patch #369-1 is attached. It has been rebased on top of #372 and #373 that fix the conflicting parameter while maintaining backward compatibility. -- Endi S. Dewata -------------- next part -------------- >From 7f461c8fe5d567e9ddad3684a60037cdd90e833c Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Thu, 30 Jul 2015 23:20:34 +0200 Subject: [PATCH] Added CLI param and ACL for vault service operations. The CLIs to manage vault owners and members have been modified to accept services in addition to users and groups. A new ACL has been added to allow a service to create its own service container. https://fedorahosted.org/freeipa/ticket/5172 --- API.txt | 12 ++++++++---- VERSION | 4 ++-- install/share/vault.update | 1 + ipalib/plugins/vault.py | 21 +++++++++++++++------ 4 files changed, 26 insertions(+), 12 deletions(-) diff --git a/API.txt b/API.txt index 9a777bd029d88f6882a9db341822544c6d1e7b5a..81527bf60bb440ddfdacb25d63e211b154182487 100644 --- a/API.txt +++ b/API.txt @@ -5436,12 +5436,13 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault2_add_member -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) option: Str('servicename?', cli_name='service') option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) @@ -5451,12 +5452,13 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault2_add_owner -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) option: Str('servicename?', cli_name='service') option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) @@ -5549,12 +5551,13 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault2_remove_member -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) option: Str('servicename?', cli_name='service') option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) @@ -5564,12 +5567,13 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault2_remove_owner -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service*', alwaysask=True, cli_name='services', csv=True) option: Str('servicename?', cli_name='service') option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) diff --git a/VERSION b/VERSION index e656524418e5fedbd318e6998aa67ffc20750533..5309f3ddcc9ca05e8e4e6f59054f40ff70f9fc8c 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=149 -# Last change: edewata - Fixed conflicting vault 'service' option. +IPA_API_VERSION_MINOR=150 +# Last change: edewata - Added CLI param and ACL for vault service operations diff --git a/install/share/vault.update b/install/share/vault.update index 61a8940b544fbc839b931f337389ac35dc2d1ffa..14421b5189efe9b3d9491e845e74debca6e18941 100644 --- a/install/share/vault.update +++ b/install/share/vault.update @@ -8,6 +8,7 @@ default: objectClass: top default: objectClass: ipaVaultContainer default: cn: vaults default: aci: (target="ldap:///cn=*,cn=users,cn=vaults,cn=kra,$SUFFIX")(version 3.0; acl "Allow users to create private container"; allow (add) userdn = "ldap:///uid=($$attr.cn),cn=users,cn=accounts,$SUFFIX";) +default: aci: (target="ldap:///cn=*,cn=services,cn=vaults,cn=kra,$SUFFIX")(version 3.0; acl "Allow services to create private container"; allow (add) userdn = "ldap:///krbprincipalname=($$attr.cn)@$REALM,cn=services,cn=accounts,$SUFFIX";) default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Indirect container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#GROUPDN";) default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index e32d378dbdc7118c2fd60aeabe7a3993c2d63c9c..427b1ea1588af2fb09a99181b8773abdf8099b8d 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -199,16 +199,20 @@ EXAMPLES: ipa vault-retrieve --out data.bin --private-key-file private.pem """) + _(""" Add a vault owner: - ipa vault-add-owner --users + ipa vault-add-owner [--users ] \ + [--groups ] [--services ] """) + _(""" Delete a vault owner: - ipa vault-remove-owner --users + ipa vault-remove-owner [--users ] \ + [--groups ] [--services ] """) + _(""" Add a vault member: - ipa vault-add-member --users + ipa vault-add-member [--users ] \ + [--groups ] [--services ] """) + _(""" Delete a vault member: - ipa vault-remove-member --users + ipa vault-remove-member [--users ] \ + [--groups ] [--services ] """) @@ -499,8 +503,8 @@ class vault2(LDAPObject): 'ipavaulttype', ] attribute_members = { - 'owner': ['user', 'group'], - 'member': ['user', 'group'], + 'owner': ['user', 'group', 'service'], + 'member': ['user', 'group', 'service'], } label = _('Vaults') @@ -554,6 +558,11 @@ class vault2(LDAPObject): label=_('Owner groups'), flags=['no_create', 'no_update', 'no_search'], ), + Str( + 'owner_service?', + label=_('Owner services'), + flags=['no_create', 'no_update', 'no_search'], + ), ) def get_dn(self, *keys, **options): -- 2.4.3 From abokovoy at redhat.com Mon Aug 10 19:39:42 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 10 Aug 2015 22:39:42 +0300 Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request In-Reply-To: <1439145950.20262.73.camel@willson.usersys.redhat.com> References: <20150721114114.GA7078@p.redhat.com> <721412384.2383594.1437572511320.JavaMail.zimbra@redhat.com> <20150728101515.GA7078@p.redhat.com> <1438081537.13513.17.camel@willson.usersys.redhat.com> <20150728112634.GP21928@redhat.com> <20150728114229.GC17746@p.redhat.com> <20150728130256.GA20980@p.redhat.com> <20150807205619.GA22106@redhat.com> <1439145950.20262.73.camel@willson.usersys.redhat.com> Message-ID: <20150810193942.GH22106@redhat.com> On Sun, 09 Aug 2015, Simo Sorce wrote: >On Fri, 2015-08-07 at 23:56 +0300, Alexander Bokovoy wrote: >> On Tue, 28 Jul 2015, Sumit Bose wrote: >> >On Tue, Jul 28, 2015 at 01:42:29PM +0200, Sumit Bose wrote: >> >> On Tue, Jul 28, 2015 at 02:26:34PM +0300, Alexander Bokovoy wrote: >> >> > On Tue, 28 Jul 2015, Simo Sorce wrote: >> >> > >On Tue, 2015-07-28 at 12:15 +0200, Sumit Bose wrote: >> >> > >>On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote: >> >> > >>> ----- Original Message ----- >> >> > >>> > From: "Sumit Bose" >> >> > >>> > To: "freeipa-devel" >> >> > >>> > Sent: Tuesday, July 21, 2015 7:41:14 AM >> >> > >>> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request >> >> > >>> > >> >> > >>> > Hi, >> >> > >>> > >> >> > >>> > this patch is my suggestion to solve >> >> > >>> > https://fedorahosted.org/freeipa/ticket/4844 . >> >> > >>> > >> >> > >>> > The original issue in the ticket has two part. One is a loop in libkrb5 >> >> > >>> > which is already fixed. The other is to handle canonicalization better. >> >> > >>> >> >> > >>> Sorry Sumit, >> >> > >>> I see several issues with this patck. >> >> > >>> >> >> > >>> first of all you should really not change ipadb_get_principal(), that's the >> >> > >>> wrong place to apply your logic. >> >> > >>> >> >> > >>> To support searching for the realm name case-insensitively all we should do >> >> > >>> is to always forcibly upper case the realm name at the same time we build the >> >> > >>> filter (in ipadb_fetch_principals(), if canonicalization was requested. >> >> > >>> Because we will never store (code to prevent that should probably be dded with >> >> > >>> this patch) a realm name that is not all caps. >> >> > >>> Then the post search matches should be done straight within ipadb_find_principal(). >> >> > >>> >> >> > >>> > The general way to allow canonicalization on a principal is to add the >> >> > >>> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together >> >> > >>> > with the objectclass 'ipaKrbPrincipal' to the user object. >> >> > >>> >> >> > >>> We have already a ticket open since long to remove krbprincipalalias, it was >> >> > >>> a mistake to add it and any patch that depends on it will be nacked by me. >> >> > >>> We need to use krbPrincipalName and krbCanonicalName. >> >> > >>> >> >> > >>> > Then the IPA >> >> > >>> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive >> >> > >>> > matches and the principal from 'krbcanonicalname' will be the canonical >> >> > >>> > principal used further on. The 'krbPrincipalName' is not suitable for >> >> > >>> > either because it has caseExact* matching rules and is a multivalue >> >> > >>> > attribute [2]. >> >> > >>> >> >> > >>> Case-exact match is a problem only if we do not canonicalize names when storing >> >> > >>> them, otherwise all you need to do is store a "search form" in krbPrincipalName >> >> > >>> and always change searches to that form (forcibly upper case realm, forcibly >> >> > >>> lowercase components) when canonicalization is requested. >> >> > >>> >> >> > >>> Additionally in the patch you are using stcasecmp(), that function is not >> >> > >>> acceptable, look at ipadb_find_principal() and you'll see we use ulc_casecmp() >> >> > >>> there. >> >> > >>> Also modyfing the principal before searching is done wrong (you use strchr() >> >> > >>> to find the @ sign, but you could find an @ in the components this way, you >> >> > >>> should use strrchr() at the very least), and is dangerous if done outside of >> >> > >>> the inner functions because then we never have a way to know the original >> >> > >>> form should it be needed. In any case as said above realm should be forcibly >> >> > >>> uppercase, given a flag in the escape function instead. >> >> > >> >> >> > >>Thank for for the review and the comments. >> >> > >> >> >> > >>I changed the patch as you suggested to upper-case the realm in the >> >> > >>escape function if the flag is set. >> >> > >> >> >> > >>I didn't add any checks to make sure that the realm of newly added >> >> > >>principal attributes is always upper case. Since the attributes can be >> >> > >>added via various ways I think the check should happen on the DS level >> >> > > >> >> > >We should indeed intercept add/modify operations and see if they try to >> >> > >set krbPrincipalName/krbCanonicalName and then validate the name. >> >> > >Return unwilling to perform if the case of the realm is different (or >> >> > >fix it on the fly, up for discussion) from the default case as >> >> > >configured in the server. >> >> > Will break trusts -- ipasam does add these principals for krbtgt/IPA at AD. >> >> > >> >> > >>but I see this more in the context of full canonicalization fix covered >> >> > >>by https://fedorahosted.org/freeipa/ticket/3864 . If you think this is a >> >> > >>requirement for the patch attached I would suggest to drop >> >> > >>https://fedorahosted.org/freeipa/ticket/4844 and solve it together with >> >> > >>#3864. >> >> > > >> >> > >We should clsoe 4844 as fixed upstream (there *was* a bug in libkrb5). >> >> > >I commented on #3864 about what we can do, and we can also avoid >> >> > >changing the schema. >> >> > Yep. >> >> > >> >> > >So on the new patches, what does "unify" means ? I do not get what it >> >> > >means (so probably it is a poor name), I guess you may want to call it >> >> > >"canonicalization" ? (or even 'canon' to shorten it a bit). >> >> > I have same question. I tried to understand why it is called unify and >> >> > failed. >> >> >> >> I didn't want to use 'canonical' because the result will not be the >> >> canonical name in the general case but only a name we use for searching. >> >> I was thinking about 'normalized' bit this has a special meaning with >> >> unicode. So I came up with 'unify'. But if you prefer 'canon' I can >> >> change it. >> >> >> >> > >> >> > >I think the worst case for a utf8 string is more then length*2, probably >> >> > >more like length*6, unless there is some guarantee around case changes >> >> > >that I am not aware of, that said we could probably just allocate on the >> >> > >stack a fixed size string of a KiB or so, the longest DNS name is 256 >> >> > >chars IIRC and a service name can't be that much longer, also usernames >> >> > >can't be arbitrarily long. So 1/2 KiB should probably be fine for a full >> >> > >principal name. (avoids a malloc too which is good). >> >> > Yes, sounds good. A hostname label can be up to 63 characters and full >> >> > domain name including dots would be 253 characters. At the same time, a >> >> > a component of the principal may be of arbitrary length. From practical >> >> > perspective it would probably be enough to go with a static buffer of >> >> > 1/2 KiB for the quickest case and fall back to malloc() if the size is >> >> > bigger than that one. >> >> >> >> ok, I will change this. >> > >> >new version with changed name and 1/2 KiB buffer attached. No changes to >> >the 2nd patch. >> Thanks. >> >> Patches look good to me. I, perhaps, would have added >> char *canon_princ = NULL; >> >> in the definition of canon_princ but as you never access it in case >> asprintf() failed, that's fine. >> >> Simo? >> > >LGTM. Hold on. I think I've found a bug -- when krbPrincipalName values match insensitively but krbCanonicalName value is missing, we do not set principal to the matched value. This breaks canonicalization for case when there is only one krbPrincipalName as you don't need to have krbCanonicalName in this case. I have a prototype which still misses checks. -- / Alexander Bokovoy From edewata at redhat.com Mon Aug 10 19:45:18 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Aug 2015 14:45:18 -0500 Subject: [Freeipa-devel] [PATCH] 374 Fixed vault container ownership. Message-ID: <55C8FF4E.5010107@redhat.com> The vault-add command has been fixed such that if the user/service private vault container does not exist yet it will be created and owned by the user/service instead of the vault creator. https://fedorahosted.org/freeipa/ticket/5194 -- Endi S. Dewata -------------- next part -------------- From 35c2e903c1208591a3cabfd715cf297cb9de506d Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Mon, 10 Aug 2015 20:57:58 +0200 Subject: [PATCH] Fixed vault container ownership. The vault-add command has been fixed such that if the user/service private vault container does not exist yet it will be created and owned by the user/service instead of the vault creator. https://fedorahosted.org/freeipa/ticket/5194 --- ipalib/plugins/vault.py | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 427b1ea1588af2fb09a99181b8773abdf8099b8d..be1560181322d8323ab6d8f169e106a404aa0617 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -924,12 +924,33 @@ class vault2_add_internal(LDAPCreate): else: owner_dn = self.api.Object.user.get_dn(name) + parent_dn = DN(*dn[1:]) + + container_dn = DN(self.api.Object.vault.container_dn, + self.api.env.basedn) + + services_dn = DN(('cn', 'services'), container_dn) + users_dn = DN(('cn', 'users'), container_dn) + + if dn.endswith(services_dn): + # service container should be owned by the service + service = parent_dn[0]['cn'] + parent_owner_dn = self.api.Object.service.get_dn(service) + + elif dn.endswith(users_dn): + # user container should be owned by the user + user = parent_dn[0]['cn'] + parent_owner_dn = self.api.Object.user.get_dn(user) + + else: + parent_owner_dn = owner_dn + try: - parent_dn = DN(*dn[1:]) - self.obj.create_container(parent_dn, owner_dn) + self.obj.create_container(parent_dn, parent_owner_dn) except errors.DuplicateEntry, e: pass + # vault should be owned by the creator entry_attrs['owner'] = owner_dn return dn -- 2.4.3 From abokovoy at redhat.com Mon Aug 10 20:15:51 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 10 Aug 2015 23:15:51 +0300 Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request In-Reply-To: <20150810193942.GH22106@redhat.com> References: <20150721114114.GA7078@p.redhat.com> <721412384.2383594.1437572511320.JavaMail.zimbra@redhat.com> <20150728101515.GA7078@p.redhat.com> <1438081537.13513.17.camel@willson.usersys.redhat.com> <20150728112634.GP21928@redhat.com> <20150728114229.GC17746@p.redhat.com> <20150728130256.GA20980@p.redhat.com> <20150807205619.GA22106@redhat.com> <1439145950.20262.73.camel@willson.usersys.redhat.com> <20150810193942.GH22106@redhat.com> Message-ID: <20150810201550.GJ22106@redhat.com> On Mon, 10 Aug 2015, Alexander Bokovoy wrote: >On Sun, 09 Aug 2015, Simo Sorce wrote: >>On Fri, 2015-08-07 at 23:56 +0300, Alexander Bokovoy wrote: >>>On Tue, 28 Jul 2015, Sumit Bose wrote: >>>>On Tue, Jul 28, 2015 at 01:42:29PM +0200, Sumit Bose wrote: >>>>> On Tue, Jul 28, 2015 at 02:26:34PM +0300, Alexander Bokovoy wrote: >>>>> > On Tue, 28 Jul 2015, Simo Sorce wrote: >>>>> > >On Tue, 2015-07-28 at 12:15 +0200, Sumit Bose wrote: >>>>> > >>On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote: >>>>> > >>> ----- Original Message ----- >>>>> > >>> > From: "Sumit Bose" >>>>> > >>> > To: "freeipa-devel" >>>>> > >>> > Sent: Tuesday, July 21, 2015 7:41:14 AM >>>>> > >>> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request >>>>> > >>> > >>>>> > >>> > Hi, >>>>> > >>> > >>>>> > >>> > this patch is my suggestion to solve >>>>> > >>> > https://fedorahosted.org/freeipa/ticket/4844 . >>>>> > >>> > >>>>> > >>> > The original issue in the ticket has two part. One is a loop in libkrb5 >>>>> > >>> > which is already fixed. The other is to handle canonicalization better. >>>>> > >>> >>>>> > >>> Sorry Sumit, >>>>> > >>> I see several issues with this patck. >>>>> > >>> >>>>> > >>> first of all you should really not change ipadb_get_principal(), that's the >>>>> > >>> wrong place to apply your logic. >>>>> > >>> >>>>> > >>> To support searching for the realm name case-insensitively all we should do >>>>> > >>> is to always forcibly upper case the realm name at the same time we build the >>>>> > >>> filter (in ipadb_fetch_principals(), if canonicalization was requested. >>>>> > >>> Because we will never store (code to prevent that should probably be dded with >>>>> > >>> this patch) a realm name that is not all caps. >>>>> > >>> Then the post search matches should be done straight within ipadb_find_principal(). >>>>> > >>> >>>>> > >>> > The general way to allow canonicalization on a principal is to add the >>>>> > >>> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together >>>>> > >>> > with the objectclass 'ipaKrbPrincipal' to the user object. >>>>> > >>> >>>>> > >>> We have already a ticket open since long to remove krbprincipalalias, it was >>>>> > >>> a mistake to add it and any patch that depends on it will be nacked by me. >>>>> > >>> We need to use krbPrincipalName and krbCanonicalName. >>>>> > >>> >>>>> > >>> > Then the IPA >>>>> > >>> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive >>>>> > >>> > matches and the principal from 'krbcanonicalname' will be the canonical >>>>> > >>> > principal used further on. The 'krbPrincipalName' is not suitable for >>>>> > >>> > either because it has caseExact* matching rules and is a multivalue >>>>> > >>> > attribute [2]. >>>>> > >>> >>>>> > >>> Case-exact match is a problem only if we do not canonicalize names when storing >>>>> > >>> them, otherwise all you need to do is store a "search form" in krbPrincipalName >>>>> > >>> and always change searches to that form (forcibly upper case realm, forcibly >>>>> > >>> lowercase components) when canonicalization is requested. >>>>> > >>> >>>>> > >>> Additionally in the patch you are using stcasecmp(), that function is not >>>>> > >>> acceptable, look at ipadb_find_principal() and you'll see we use ulc_casecmp() >>>>> > >>> there. >>>>> > >>> Also modyfing the principal before searching is done wrong (you use strchr() >>>>> > >>> to find the @ sign, but you could find an @ in the components this way, you >>>>> > >>> should use strrchr() at the very least), and is dangerous if done outside of >>>>> > >>> the inner functions because then we never have a way to know the original >>>>> > >>> form should it be needed. In any case as said above realm should be forcibly >>>>> > >>> uppercase, given a flag in the escape function instead. >>>>> > >> >>>>> > >>Thank for for the review and the comments. >>>>> > >> >>>>> > >>I changed the patch as you suggested to upper-case the realm in the >>>>> > >>escape function if the flag is set. >>>>> > >> >>>>> > >>I didn't add any checks to make sure that the realm of newly added >>>>> > >>principal attributes is always upper case. Since the attributes can be >>>>> > >>added via various ways I think the check should happen on the DS level >>>>> > > >>>>> > >We should indeed intercept add/modify operations and see if they try to >>>>> > >set krbPrincipalName/krbCanonicalName and then validate the name. >>>>> > >Return unwilling to perform if the case of the realm is different (or >>>>> > >fix it on the fly, up for discussion) from the default case as >>>>> > >configured in the server. >>>>> > Will break trusts -- ipasam does add these principals for krbtgt/IPA at AD. >>>>> > >>>>> > >>but I see this more in the context of full canonicalization fix covered >>>>> > >>by https://fedorahosted.org/freeipa/ticket/3864 . If you think this is a >>>>> > >>requirement for the patch attached I would suggest to drop >>>>> > >>https://fedorahosted.org/freeipa/ticket/4844 and solve it together with >>>>> > >>#3864. >>>>> > > >>>>> > >We should clsoe 4844 as fixed upstream (there *was* a bug in libkrb5). >>>>> > >I commented on #3864 about what we can do, and we can also avoid >>>>> > >changing the schema. >>>>> > Yep. >>>>> > >>>>> > >So on the new patches, what does "unify" means ? I do not get what it >>>>> > >means (so probably it is a poor name), I guess you may want to call it >>>>> > >"canonicalization" ? (or even 'canon' to shorten it a bit). >>>>> > I have same question. I tried to understand why it is called unify and >>>>> > failed. >>>>> >>>>> I didn't want to use 'canonical' because the result will not be the >>>>> canonical name in the general case but only a name we use for searching. >>>>> I was thinking about 'normalized' bit this has a special meaning with >>>>> unicode. So I came up with 'unify'. But if you prefer 'canon' I can >>>>> change it. >>>>> >>>>> > >>>>> > >I think the worst case for a utf8 string is more then length*2, probably >>>>> > >more like length*6, unless there is some guarantee around case changes >>>>> > >that I am not aware of, that said we could probably just allocate on the >>>>> > >stack a fixed size string of a KiB or so, the longest DNS name is 256 >>>>> > >chars IIRC and a service name can't be that much longer, also usernames >>>>> > >can't be arbitrarily long. So 1/2 KiB should probably be fine for a full >>>>> > >principal name. (avoids a malloc too which is good). >>>>> > Yes, sounds good. A hostname label can be up to 63 characters and full >>>>> > domain name including dots would be 253 characters. At the same time, a >>>>> > a component of the principal may be of arbitrary length. From practical >>>>> > perspective it would probably be enough to go with a static buffer of >>>>> > 1/2 KiB for the quickest case and fall back to malloc() if the size is >>>>> > bigger than that one. >>>>> >>>>> ok, I will change this. >>>> >>>>new version with changed name and 1/2 KiB buffer attached. No changes to >>>>the 2nd patch. >>>Thanks. >>> >>>Patches look good to me. I, perhaps, would have added >>> char *canon_princ = NULL; >>> >>>in the definition of canon_princ but as you never access it in case >>>asprintf() failed, that's fine. >>> >>>Simo? >>> >> >>LGTM. >Hold on. I think I've found a bug -- when krbPrincipalName values match >insensitively but krbCanonicalName value is missing, we do not set >principal to the matched value. This breaks canonicalization for case >when there is only one krbPrincipalName as you don't need to have >krbCanonicalName in this case. > >I have a prototype which still misses checks. ... and I think we miss checks in few other places. I'm getting canonicalization working randomly -- sometimes one or two times in a row I get 'Client principal is not found' for canonicalization case: Aug 10 20:01:21 m1.example.com krb5kdc[18758](Error): searched for admin at example.com, found admin at EXAMPLE.COM, result is 1, index is 0, next val is (nil) Aug 10 20:01:21 m1.example.com krb5kdc[18758](Error): searched for krbtgt/example.com at example.com, found krbtgt/EXAMPLE.COM at EXAMPLE.COM, result is 1, index is 0, next val is (nil) Aug 10 20:01:21 m1.example.com krb5kdc[18758](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.122.99: NEEDED_PREAUTH: admin at example.com for krbtgt/example.com at example.com, Additional pre-authentication required Aug 10 20:01:24 m1.example.com krb5kdc[18758](Error): searched for admin at example.com, found admin at EXAMPLE.COM, result is 1, index is 0, next val is (nil) Aug 10 20:01:24 m1.example.com krb5kdc[18758](Error): searched for krbtgt/example.com at example.com, found krbtgt/EXAMPLE.COM at EXAMPLE.COM, result is 1, index is 0, next val is (nil) Aug 10 20:01:24 m1.example.com krb5kdc[18758](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.122.99: ISSUE: authtime 1439236884, etypes {rep=18 tkt=18 ses=18}, admin at example.com for krbtgt/example.com at example.com Aug 10 20:01:58 m1.example.com krb5kdc[18758](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.122.99: CLIENT_NOT_FOUND: admin at example.com for krbtgt/example.com at example.com, Client not found in Kerberos database These are logs with debugging I've added. -- / Alexander Bokovoy From ssorce at redhat.com Mon Aug 10 21:37:17 2015 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 10 Aug 2015 17:37:17 -0400 Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request In-Reply-To: <20150810201550.GJ22106@redhat.com> References: <20150721114114.GA7078@p.redhat.com> <721412384.2383594.1437572511320.JavaMail.zimbra@redhat.com> <20150728101515.GA7078@p.redhat.com> <1438081537.13513.17.camel@willson.usersys.redhat.com> <20150728112634.GP21928@redhat.com> <20150728114229.GC17746@p.redhat.com> <20150728130256.GA20980@p.redhat.com> <20150807205619.GA22106@redhat.com> <1439145950.20262.73.camel@willson.usersys.redhat.com> <20150810193942.GH22106@redhat.com> <20150810201550.GJ22106@redhat.com> Message-ID: <1439242637.20262.98.camel@willson.usersys.redhat.com> On Mon, 2015-08-10 at 23:15 +0300, Alexander Bokovoy wrote: > On Mon, 10 Aug 2015, Alexander Bokovoy wrote: > >On Sun, 09 Aug 2015, Simo Sorce wrote: > >>On Fri, 2015-08-07 at 23:56 +0300, Alexander Bokovoy wrote: > >>>On Tue, 28 Jul 2015, Sumit Bose wrote: > >>>>On Tue, Jul 28, 2015 at 01:42:29PM +0200, Sumit Bose wrote: > >>>>> On Tue, Jul 28, 2015 at 02:26:34PM +0300, Alexander Bokovoy wrote: > >>>>> > On Tue, 28 Jul 2015, Simo Sorce wrote: > >>>>> > >On Tue, 2015-07-28 at 12:15 +0200, Sumit Bose wrote: > >>>>> > >>On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote: > >>>>> > >>> ----- Original Message ----- > >>>>> > >>> > From: "Sumit Bose" > >>>>> > >>> > To: "freeipa-devel" > >>>>> > >>> > Sent: Tuesday, July 21, 2015 7:41:14 AM > >>>>> > >>> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request > >>>>> > >>> > > >>>>> > >>> > Hi, > >>>>> > >>> > > >>>>> > >>> > this patch is my suggestion to solve > >>>>> > >>> > https://fedorahosted.org/freeipa/ticket/4844 . > >>>>> > >>> > > >>>>> > >>> > The original issue in the ticket has two part. One is a loop in libkrb5 > >>>>> > >>> > which is already fixed. The other is to handle canonicalization better. > >>>>> > >>> > >>>>> > >>> Sorry Sumit, > >>>>> > >>> I see several issues with this patck. > >>>>> > >>> > >>>>> > >>> first of all you should really not change ipadb_get_principal(), that's the > >>>>> > >>> wrong place to apply your logic. > >>>>> > >>> > >>>>> > >>> To support searching for the realm name case-insensitively all we should do > >>>>> > >>> is to always forcibly upper case the realm name at the same time we build the > >>>>> > >>> filter (in ipadb_fetch_principals(), if canonicalization was requested. > >>>>> > >>> Because we will never store (code to prevent that should probably be dded with > >>>>> > >>> this patch) a realm name that is not all caps. > >>>>> > >>> Then the post search matches should be done straight within ipadb_find_principal(). > >>>>> > >>> > >>>>> > >>> > The general way to allow canonicalization on a principal is to add the > >>>>> > >>> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together > >>>>> > >>> > with the objectclass 'ipaKrbPrincipal' to the user object. > >>>>> > >>> > >>>>> > >>> We have already a ticket open since long to remove krbprincipalalias, it was > >>>>> > >>> a mistake to add it and any patch that depends on it will be nacked by me. > >>>>> > >>> We need to use krbPrincipalName and krbCanonicalName. > >>>>> > >>> > >>>>> > >>> > Then the IPA > >>>>> > >>> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive > >>>>> > >>> > matches and the principal from 'krbcanonicalname' will be the canonical > >>>>> > >>> > principal used further on. The 'krbPrincipalName' is not suitable for > >>>>> > >>> > either because it has caseExact* matching rules and is a multivalue > >>>>> > >>> > attribute [2]. > >>>>> > >>> > >>>>> > >>> Case-exact match is a problem only if we do not canonicalize names when storing > >>>>> > >>> them, otherwise all you need to do is store a "search form" in krbPrincipalName > >>>>> > >>> and always change searches to that form (forcibly upper case realm, forcibly > >>>>> > >>> lowercase components) when canonicalization is requested. > >>>>> > >>> > >>>>> > >>> Additionally in the patch you are using stcasecmp(), that function is not > >>>>> > >>> acceptable, look at ipadb_find_principal() and you'll see we use ulc_casecmp() > >>>>> > >>> there. > >>>>> > >>> Also modyfing the principal before searching is done wrong (you use strchr() > >>>>> > >>> to find the @ sign, but you could find an @ in the components this way, you > >>>>> > >>> should use strrchr() at the very least), and is dangerous if done outside of > >>>>> > >>> the inner functions because then we never have a way to know the original > >>>>> > >>> form should it be needed. In any case as said above realm should be forcibly > >>>>> > >>> uppercase, given a flag in the escape function instead. > >>>>> > >> > >>>>> > >>Thank for for the review and the comments. > >>>>> > >> > >>>>> > >>I changed the patch as you suggested to upper-case the realm in the > >>>>> > >>escape function if the flag is set. > >>>>> > >> > >>>>> > >>I didn't add any checks to make sure that the realm of newly added > >>>>> > >>principal attributes is always upper case. Since the attributes can be > >>>>> > >>added via various ways I think the check should happen on the DS level > >>>>> > > > >>>>> > >We should indeed intercept add/modify operations and see if they try to > >>>>> > >set krbPrincipalName/krbCanonicalName and then validate the name. > >>>>> > >Return unwilling to perform if the case of the realm is different (or > >>>>> > >fix it on the fly, up for discussion) from the default case as > >>>>> > >configured in the server. > >>>>> > Will break trusts -- ipasam does add these principals for krbtgt/IPA at AD. > >>>>> > > >>>>> > >>but I see this more in the context of full canonicalization fix covered > >>>>> > >>by https://fedorahosted.org/freeipa/ticket/3864 . If you think this is a > >>>>> > >>requirement for the patch attached I would suggest to drop > >>>>> > >>https://fedorahosted.org/freeipa/ticket/4844 and solve it together with > >>>>> > >>#3864. > >>>>> > > > >>>>> > >We should clsoe 4844 as fixed upstream (there *was* a bug in libkrb5). > >>>>> > >I commented on #3864 about what we can do, and we can also avoid > >>>>> > >changing the schema. > >>>>> > Yep. > >>>>> > > >>>>> > >So on the new patches, what does "unify" means ? I do not get what it > >>>>> > >means (so probably it is a poor name), I guess you may want to call it > >>>>> > >"canonicalization" ? (or even 'canon' to shorten it a bit). > >>>>> > I have same question. I tried to understand why it is called unify and > >>>>> > failed. > >>>>> > >>>>> I didn't want to use 'canonical' because the result will not be the > >>>>> canonical name in the general case but only a name we use for searching. > >>>>> I was thinking about 'normalized' bit this has a special meaning with > >>>>> unicode. So I came up with 'unify'. But if you prefer 'canon' I can > >>>>> change it. > >>>>> > >>>>> > > >>>>> > >I think the worst case for a utf8 string is more then length*2, probably > >>>>> > >more like length*6, unless there is some guarantee around case changes > >>>>> > >that I am not aware of, that said we could probably just allocate on the > >>>>> > >stack a fixed size string of a KiB or so, the longest DNS name is 256 > >>>>> > >chars IIRC and a service name can't be that much longer, also usernames > >>>>> > >can't be arbitrarily long. So 1/2 KiB should probably be fine for a full > >>>>> > >principal name. (avoids a malloc too which is good). > >>>>> > Yes, sounds good. A hostname label can be up to 63 characters and full > >>>>> > domain name including dots would be 253 characters. At the same time, a > >>>>> > a component of the principal may be of arbitrary length. From practical > >>>>> > perspective it would probably be enough to go with a static buffer of > >>>>> > 1/2 KiB for the quickest case and fall back to malloc() if the size is > >>>>> > bigger than that one. > >>>>> > >>>>> ok, I will change this. > >>>> > >>>>new version with changed name and 1/2 KiB buffer attached. No changes to > >>>>the 2nd patch. > >>>Thanks. > >>> > >>>Patches look good to me. I, perhaps, would have added > >>> char *canon_princ = NULL; > >>> > >>>in the definition of canon_princ but as you never access it in case > >>>asprintf() failed, that's fine. > >>> > >>>Simo? > >>> > >> > >>LGTM. > >Hold on. I think I've found a bug -- when krbPrincipalName values match > >insensitively but krbCanonicalName value is missing, we do not set > >principal to the matched value. This breaks canonicalization for case > >when there is only one krbPrincipalName as you don't need to have > >krbCanonicalName in this case. > > > >I have a prototype which still misses checks. > ... and I think we miss checks in few other places. I'm getting > canonicalization working randomly -- sometimes one or two times in a row > I get 'Client principal is not found' for canonicalization case: > > Aug 10 20:01:21 m1.example.com krb5kdc[18758](Error): searched for > admin at example.com, found admin at EXAMPLE.COM, result is 1, index is 0, > next val is (nil) > > Aug 10 20:01:21 m1.example.com krb5kdc[18758](Error): searched for > krbtgt/example.com at example.com, found krbtgt/EXAMPLE.COM at EXAMPLE.COM, > result is 1, index is 0, next val is (nil) > > Aug 10 20:01:21 m1.example.com krb5kdc[18758](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 192.168.122.99: NEEDED_PREAUTH: admin at example.com > for krbtgt/example.com at example.com, Additional pre-authentication > required > > Aug 10 20:01:24 m1.example.com krb5kdc[18758](Error): searched for > admin at example.com, found admin at EXAMPLE.COM, result is 1, index is 0, > next val is (nil) > > Aug 10 20:01:24 m1.example.com krb5kdc[18758](Error): searched for > krbtgt/example.com at example.com, found krbtgt/EXAMPLE.COM at EXAMPLE.COM, > result is 1, index is 0, next val is (nil) > > Aug 10 20:01:24 m1.example.com krb5kdc[18758](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 192.168.122.99: ISSUE: authtime 1439236884, etypes > {rep=18 tkt=18 ses=18}, admin at example.com for > krbtgt/example.com at example.com > > Aug 10 20:01:58 m1.example.com krb5kdc[18758](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 192.168.122.99: CLIENT_NOT_FOUND: admin at example.com > for krbtgt/example.com at example.com, Client not found in Kerberos > database > > These are logs with debugging I've added. > -- > / Alexander Bokovoy > After looking carefully at this with Alexander I think there are too many things to fix and check, and given the looming deadline for Fedora we should just postpone. These patches are not critical for us but it would be bad if they'd go in and not work as expected. I can take a better look at them when back from flock. Simo. From ftweedal at redhat.com Tue Aug 11 00:58:40 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 11 Aug 2015 10:58:40 +1000 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55C8D671.2000703@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <1034063240.9562048.1439220248981.JavaMail.zimbra@redhat.com> <55C8D671.2000703@redhat.com> Message-ID: <20150811005840.GQ6626@dhcp-40-8.bne.redhat.com> On Mon, Aug 10, 2015 at 06:50:57PM +0200, Milan Kub?k wrote: > Hi, > > On 08/10/2015 05:24 PM, Scott Poore wrote: > > > >----- Original Message ----- > >>From: "Milan Kub?k" > >>To: "freeipa-devel" , "Scott Poore" , "Fraser Tweedale" > >> > >>Cc: "Namita Soman" , "Ales Marecek" > >>Sent: Monday, August 10, 2015 4:36:31 AM > >>Subject: Re: cert profiles - test plan + patches > >> > >>On 08/05/2015 02:57 PM, Milan Kub?k wrote: > >>>Hi list, > >>> > >>>I'm sending the test plan [1] for certificate profiles and preliminary > >>>patches for it. > >>>The plan covers basic CRUD test and some corner cases. I'm open to more > >>>suggestions. > >>> > >>>More complicated tests involving certificate profiles will require the > >>>code (and tests) > >>>for CA ACLs merged, so it's not there at the moment. > >>> > >>>There are some unfinished test cases in places I wasn't sure what the > >>>result should be. > >>>We need to iterate through these to fix it. > >>> > >>> > >>>[1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan > >>> > >>>Cheers, > >>>Milan > >>Hi all, > >> > >>have you had some time to look at the code and proposal? > >>Today I want to write a basic CRUD test for the ACLs as well as a few > >>test cases to check if the ACL is being enforced. It should make it into > >>wiki today or by tomorrow. I'll send an update then. > >I haven't looked at the actual code yet. Is it checked into git for freeipa yet? > > > >This looks good to me for the basic CRUD tests. I do have some questions and requests. > > > >Existing tests: > > > >* Delete default profile > >- Did you find out what the expected result should be? > > > I reported this when Fraser was implementing the feature. He decided to > allow this (earlier it has failed). > At the time I didn't suggest otherwise. The design/documentation could be > more clear on this > as for, is it allowed to delete all profiles? Doing this will break an awful > lot of things. The same applies to > ACLs as well, Sub CAs later ditto. Deleting the default profile will break > things even if other profiles > remain as it is a default, when not specified in cert-request. > > Fraser, what do you think? > Yes, I think we should prevent deletion of default profile. I will file ticket and produce patch. I'm undecided about whether to prohibit deletion of other included profiles (of which there are currently zero, but it won't stay that way for long). > >* Try to rename the profile entry > >- Can this be renamed to be more specific to trying to rename ldap attr? > >- Can we get a new test case to test renaming with certprofile-mod --rename? > ACK > >Possible new tests: > > > >* Import a profile in xml > >- This should fail and I think is at least in the beginning a common mistake. > I will add this. > +1; agree on failure being expected result. > >* Change profile config from file > >- This one may be too large in scope but, could be limited to changing something simple to make sure the file is read and used. > ACK. Though this will be a part of the more complicated scenario. > >Where are you planning to put the CA ACL tests? In the same page? > I originally planned to put it under sub CAs, but since the specification > for CA ACLs moved into the certificate profiles design, I can add it there. > Counting will be done separately from test cases for profiles and it will be > implemented (at least the CRUD test cases) in a module where the ACL Tracker > will be implemented. > >When you have that will you be adding a cert-request test? > Yes. I will need to use cert-request to test if the ACL/profile is enforced, > if enabled/disabled > is in effect. I will not implement this in a module for cert-request, > though. > I think it will be better to implement these in a separate module to signify > it is a test > of a conjunction of several parts of the feature (profiles, ACLs and Sub > CAs, > once this is implemented. > If you think otherwise, I'm open to suggestions. > Separate module makes sense. Cheers, Fraser > >Thanks, > >Scott > >>Cheers, > >>Milan > >> > >> > >> > >> > > Cheers, > Milan From ftweedal at redhat.com Tue Aug 11 01:17:19 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 11 Aug 2015 11:17:19 +1000 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55C8709F.7030500@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> Message-ID: <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: > On 08/05/2015 02:57 PM, Milan Kub?k wrote: > >Hi list, > > > >I'm sending the test plan [1] for certificate profiles and preliminary > >patches for it. > >The plan covers basic CRUD test and some corner cases. I'm open to more > >suggestions. > > > >More complicated tests involving certificate profiles will require the > >code (and tests) > >for CA ACLs merged, so it's not there at the moment. > > > >There are some unfinished test cases in places I wasn't sure what the > >result should be. > >We need to iterate through these to fix it. > > > > > >[1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan > > > >Cheers, > >Milan > Hi all, > > have you had some time to look at the code and proposal? > Today I want to write a basic CRUD test for the ACLs as well as a few test > cases to check if the ACL is being enforced. It should make it into wiki > today or by tomorrow. I'll send an update then. > > Cheers, > Milan > Hi Milan, I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of comments: - Test case: Import profile with incorrect values - Expected result: refused with error. - A simple way to provoke this condition is to add a number to ``policyset.serverCertSet.list``. - A similar test case should exist for certprofile-mod. - Test case: Delete default profile - As discussed elsewhere, expected result should be failure. I filed ticket #5198 to make it so :) I will review the patch soon. Cheers, Fraser From jcholast at redhat.com Tue Aug 11 06:42:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 08:42:06 +0200 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55C8F79E.8070405@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> <1438690803.20262.25.camel@willson.usersys.redhat.com> <55C0C371.5060000@redhat.com> <55C0DB02.8080306@redhat.com> <55C8F79E.8070405@redhat.com> Message-ID: <55C9993E.9020604@redhat.com> On 10.8.2015 21:12, Endi Sukma Dewata wrote: > On 8/4/2015 10:32 AM, Endi Sukma Dewata wrote: >>>> Martin, I do not think going on with business as usual is the right >>>> thing to do here. We know this is going to bite. >>>> I suggest Endy adds a *new* API if making it backwards compatible is >>>> not >>>> possible. The era of bumping whole API version must stop, the sooner >>>> the >>>> better. >>> >>> My point is that we do not know yet how to do this kind of changes >>> long term. >>> So what I did not want to end up are 2 copy&pasted Vault plugins >>> maintained >>> forever, differing in just that. >>> >>> If you know how to do this without copypasting, I will be fine with >>> that. >> >> We probably can do it like this: >> * the old plugin continues to provide Vault 1.0 functionality >> * the new plugin will be a proxy to the old plugin except for the parts >> that have changed in Vault 1.1. >> >> Or the other way around: >> * the new plugin will provide Vault 1.1 functionality >> * the old plugin will be a proxy to the new plugin except for the parts >> that needs to be maintained for Vault 1.0. >> >> The first option is probably safer. >> >> In any case, IPA 4.2.1 will only provide a single client for Vault 1.1, >> but two services for Vault 1.0 and 1.1. > > A new patch #369-1 is attached. It has been rebased on top of #372 and > #373 that fix the conflicting parameter while maintaining backward > compatibility. I have modified the first version of the patch to maintain backward compatibility and not require your patches #372 and #373. Should be much easier to review. See attachment. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0369-2-Added-CLI-param-and-ACL-for-vault-service-operations.patch Type: text/x-patch Size: 12332 bytes Desc: not available URL: From mkubik at redhat.com Tue Aug 11 07:00:59 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 09:00:59 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C8CFC4.5080004@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> Message-ID: <55C99DAB.2020500@redhat.com> On 08/10/2015 06:22 PM, Milan Kub?k wrote: > On 08/10/2015 06:02 PM, Milan Kub?k wrote: >> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>> Hi all, >>>> >>>> this patch fixes problem described in the ticket [1] >>>> that caused the test run to fail completely at every other or so run. >>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>> >>>> Thanks to Jan Cholasta for help with identifying this one. >>> >>> IMO this would be more robust: >>> >>> t = None >>> try: >>> ... >>> finally: >>> del t >>> nss.nss_shutdown() >>> >>> By assigning a value to the variable at the beginning you make sure >>> that the del statement will not fail. >>> >>> Honza >>> >> Thanks for the idea. It also removed the version check. >> Updated patch attached. >> >> Milan >> >> > Self NACK. > > I have updated the fix for all of the leaks in that class. It seems to > corrupt the database even when no init/shutdown was called. Just not > so often. > > Milan > > NACK again. The problem is the reference counting. Even with this patch, there seems to be at least one reference left after 't' is deleted and nss.nss_shutdown races with the garbage collector. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Aug 11 07:08:47 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 09:08:47 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C99DAB.2020500@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> Message-ID: <55C99F7F.9060001@redhat.com> On 11.8.2015 09:00, Milan Kub?k wrote: > On 08/10/2015 06:22 PM, Milan Kub?k wrote: >> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>> Hi all, >>>>> >>>>> this patch fixes problem described in the ticket [1] >>>>> that caused the test run to fail completely at every other or so run. >>>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>>> >>>>> Thanks to Jan Cholasta for help with identifying this one. >>>> >>>> IMO this would be more robust: >>>> >>>> t = None >>>> try: >>>> ... >>>> finally: >>>> del t >>>> nss.nss_shutdown() >>>> >>>> By assigning a value to the variable at the beginning you make sure >>>> that the del statement will not fail. >>>> >>>> Honza >>>> >>> Thanks for the idea. It also removed the version check. >>> Updated patch attached. >>> >>> Milan >>> >>> >> Self NACK. >> >> I have updated the fix for all of the leaks in that class. It seems to >> corrupt the database even when no init/shutdown was called. Just not >> so often. >> >> Milan >> >> > NACK again. The problem is the reference counting. Even with this patch, > there seems to be at least one reference left after 't' is deleted and > nss.nss_shutdown races with the garbage collector. Doesn't the PKCDDocument object also reference some NSS objects? It might be worth trying to delete it manually before nss_shutdown as well. -- Jan Cholasta From jcholast at redhat.com Tue Aug 11 07:17:18 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 09:17:18 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55C1E6BF.1060309@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> Message-ID: <55C9A17E.4040506@redhat.com> On 5.8.2015 12:34, thierry bordaz wrote: > On 08/05/2015 12:13 PM, Jan Cholasta wrote: >> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>> >>>> ----- Original Message ----- >>>> From: "thierry bordaz" >>>> To: "Jan Cholasta" >>>> Cc: freeipa-devel at redhat.com >>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>> Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with >>>> user-undel --to-staged >>>> >>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>> >>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>> >>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>> prompted to >>>>>>>>> write name and surname. >>>>>>>>> >>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>> First name: this will be ignored >>>>>>>>> Last name: this will be also ignored >>>>>>>>> ------------------------ >>>>>>>>> Added stage user "tuser" >>>>>>>>> ------------------------ >>>>>>>>> >>>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>> --from-delete option is used. >>>>>>>>> I would like to ask how to fix this issue, IMO this will be huge >>>>>>>>> hack >>>>>>>>> in internal API. Or should we just document this bug as known >>>>>>>>> issue >>>>>>>>> (thierry wrote that this is not use case that should be used >>>>>>>>> often)? >>>>>>>>> >>>>>>>>> The best solution would be separate command, but this idea was >>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>>>> regarding the design" >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> as was mentioned before, we have issue with current internal API >>>>>>>> and the >>>>>>>> stageuser-add --from-delete command. >>>>>>>> >>>>>>>> We discussed this today, and we did not find a nice way how to fix >>>>>>>> it, >>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>> >>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>> +1 >>>>>>> >>>>>>>> * create new option for user-undel: used-undel --to-staged (or >>>>>>>> create >>>>>>>> new command) that will handle moving deleted users to staged >>>>>>>> area as >>>>>>>> --from-delete did. >>>>>>> Make it new command please. >>>>>>> >>>>>>>> Instead of stageuser-add and option --from-delete, which work >>>>>>>> totally >>>>>>>> different, the command user-undel does similar operation than >>>>>>>> stage-user >>>>>>>> --from-delete, it just uses different container. >>>>>>> NACK on stuffing everything into a single command just because it >>>>>>> does >>>>>>> something similar. >>>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>> preserved >>>>>> to staged. The action is similar, but has slightly different >>>>>> specifics >>>>>> (which attributes are preserved etc.), and for me the >>>>>> 'stageuser-undel' >>>>>> feels more natural than 'user-undel --to-staged' since it's basically >>>>>> the same as there is 'stageuser-add' for creating a staged user, not >>>>>> 'user-add --to-staged'. It would be in the same style as all the >>>>>> other >>>>>> commands concerning operations with users in staged container. >>>>> Well, user-undel is the opposite of user-del, and stageuser-undel >>>>> should be the opposite of stageuser-del. The stageuser-undel you are >>>>> suggesting is not. >>>>> >>>>> Also I'm not sure if we want to (always) remove the deleted user once >>>>> a staged user is created from it, but -undel behaves like that. >>>>> >>>>> I don't think the command should be limited to deleted users only. >>>>> Active and deleted users share the same namespace, so it is an >>>>> arbitrary limitation. >>>> preserved users has been valid active user. In that sense >>>> active/preserved are managed by a same set of CLI >>>> (user-find,user-del,user-show) because a preserved user is a 'user'. So >>>> I would vote for continuing with a 'user-*' commands and use >>>> 'user-undel >>>> --to-stage'. >>>> >>>> But then if we will make any incompatible change between "user-undel" >>>> and "user-undel --to-stage" we may hit this issue again. I agree with >>>> Honza, this should be a separate command. >>> What do you mean 'incompatible change' ? >>> >>> --to-stage option would only select a different container that the >>> 'Active' one ? >> >> That's not sufficient. The command should do the reverse of >> stageuser-activate, which is ADD and DELETE, possibly with some >> modifications of the entry between them, not MODRDN like user-undel does. >> > That is a good point. Do we need to modify anything from a deleted entry > to a add it in the stage container. > Already delete entry have been purged of several values (password, krb > keys, membership,..) do you think of other attributes to remove ? > > IIRC the use case is a support engineer who activated too early an > entry. So you are right he wants to unactivate it. A question is does > the unactivation requires more modifications than the one did by > 'user-del --preserve'. Note that we can not retrieve the attribute > values when the entry was activated from stage. I don't know if any modifications are needed ATM (doesn't mean there can't be any in the future), but the point is that if you are creating object A from object B using operation X, you should be creating object B from object A using the reverse of operation X, otherwise there *will* be inconsistencies, and we don't want that. -- Jan Cholasta From mbasti at redhat.com Tue Aug 11 07:32:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Aug 2015 09:32:38 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55C9A17E.4040506@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> Message-ID: <55C9A516.2010603@redhat.com> On 11/08/15 09:17, Jan Cholasta wrote: > On 5.8.2015 12:34, thierry bordaz wrote: >> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>> >>>>> ----- Original Message ----- >>>>> From: "thierry bordaz" >>>>> To: "Jan Cholasta" >>>>> Cc: freeipa-devel at redhat.com >>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with >>>>> user-undel --to-staged >>>>> >>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>> >>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>> >>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>> prompted to >>>>>>>>>> write name and surname. >>>>>>>>>> >>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>> First name: this will be ignored >>>>>>>>>> Last name: this will be also ignored >>>>>>>>>> ------------------------ >>>>>>>>>> Added stage user "tuser" >>>>>>>>>> ------------------------ >>>>>>>>>> >>>>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>>> --from-delete option is used. >>>>>>>>>> I would like to ask how to fix this issue, IMO this will be huge >>>>>>>>>> hack >>>>>>>>>> in internal API. Or should we just document this bug as known >>>>>>>>>> issue >>>>>>>>>> (thierry wrote that this is not use case that should be used >>>>>>>>>> often)? >>>>>>>>>> >>>>>>>>>> The best solution would be separate command, but this idea was >>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>>>>> regarding the design" >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Martin^2 >>>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> as was mentioned before, we have issue with current internal API >>>>>>>>> and the >>>>>>>>> stageuser-add --from-delete command. >>>>>>>>> >>>>>>>>> We discussed this today, and we did not find a nice way how to >>>>>>>>> fix >>>>>>>>> it, >>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>> >>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>> +1 >>>>>>>> >>>>>>>>> * create new option for user-undel: used-undel --to-staged (or >>>>>>>>> create >>>>>>>>> new command) that will handle moving deleted users to staged >>>>>>>>> area as >>>>>>>>> --from-delete did. >>>>>>>> Make it new command please. >>>>>>>> >>>>>>>>> Instead of stageuser-add and option --from-delete, which work >>>>>>>>> totally >>>>>>>>> different, the command user-undel does similar operation than >>>>>>>>> stage-user >>>>>>>>> --from-delete, it just uses different container. >>>>>>>> NACK on stuffing everything into a single command just because it >>>>>>>> does >>>>>>>> something similar. >>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>>> preserved >>>>>>> to staged. The action is similar, but has slightly different >>>>>>> specifics >>>>>>> (which attributes are preserved etc.), and for me the >>>>>>> 'stageuser-undel' >>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>> basically >>>>>>> the same as there is 'stageuser-add' for creating a staged user, >>>>>>> not >>>>>>> 'user-add --to-staged'. It would be in the same style as all the >>>>>>> other >>>>>>> commands concerning operations with users in staged container. >>>>>> Well, user-undel is the opposite of user-del, and stageuser-undel >>>>>> should be the opposite of stageuser-del. The stageuser-undel you are >>>>>> suggesting is not. >>>>>> >>>>>> Also I'm not sure if we want to (always) remove the deleted user >>>>>> once >>>>>> a staged user is created from it, but -undel behaves like that. >>>>>> >>>>>> I don't think the command should be limited to deleted users only. >>>>>> Active and deleted users share the same namespace, so it is an >>>>>> arbitrary limitation. >>>>> preserved users has been valid active user. In that sense >>>>> active/preserved are managed by a same set of CLI >>>>> (user-find,user-del,user-show) because a preserved user is a >>>>> 'user'. So >>>>> I would vote for continuing with a 'user-*' commands and use >>>>> 'user-undel >>>>> --to-stage'. >>>>> >>>>> But then if we will make any incompatible change between "user-undel" >>>>> and "user-undel --to-stage" we may hit this issue again. I agree with >>>>> Honza, this should be a separate command. >>>> What do you mean 'incompatible change' ? >>>> >>>> --to-stage option would only select a different container that the >>>> 'Active' one ? >>> >>> That's not sufficient. The command should do the reverse of >>> stageuser-activate, which is ADD and DELETE, possibly with some >>> modifications of the entry between them, not MODRDN like user-undel >>> does. >>> >> That is a good point. Do we need to modify anything from a deleted entry >> to a add it in the stage container. >> Already delete entry have been purged of several values (password, krb >> keys, membership,..) do you think of other attributes to remove ? >> >> IIRC the use case is a support engineer who activated too early an >> entry. So you are right he wants to unactivate it. A question is does >> the unactivation requires more modifications than the one did by >> 'user-del --preserve'. Note that we can not retrieve the attribute >> values when the entry was activated from stage. > > I don't know if any modifications are needed ATM (doesn't mean there > can't be any in the future), but the point is that if you are creating > object A from object B using operation X, you should be creating > object B from object A using the reverse of operation X, otherwise > there *will* be inconsistencies, and we don't want that. > +1 I agree with this -- Martin Basti From jcholast at redhat.com Tue Aug 11 07:34:07 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 09:34:07 +0200 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> Message-ID: <55C9A56F.40007@redhat.com> On 6.8.2015 21:43, Gabe Alford wrote: > Hello, > > Updated patch attached. > > - Time limit is -1 for unlimited. I found this > https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html > in reference to keeping the time limit as -1 for unlimited. This patch does two conflicting things: it coerces time limit of 0 to -1 and at the same time prohibits the user to use 0 for time limit. We should do just one of these and IMHO it should be the coercion of 0 to -1. > Sure enough, testing time limit at 0 did not work for unlimited as well > as appeared to have negative effects on IPA. This is because the time limit read from ipa config is not converted to int in ldap2.find_entries(), so the coercion does not work. Fix this and 0 will work just fine. > Also, I believe that > http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s > specifies unlimited for time limit as -1. (Please correct me if I am wrong.) python-ldap is layers below our API and should not determine what we use for unlimited time limit. I would prefer if we were self-consistent and use 0 for both time limit and size limit. > > - Size limit is 0 for unlimited per Jan's comment including a conversion > from -1 to 0 if -1 is entered for unlimited size limit. > >> Actually, 0 means unlimited for size limit, see >> > > Thanks, > > Gabe > > On Tue, Aug 4, 2015 at 3:28 AM, Jan Cholasta > wrote: > > Dne 31.7.2015 v 17:08 Gabe Alford napsal(a): > > Updated patch attached. > > Thanks, > > Gabe > > On Thu, Jul 30, 2015 at 7:15 AM, Gabe Alford > > >> > wrote: > > On Thu, Jul 30, 2015 at 1:32 AM, Jan Cholasta > > >> > wrote: > > Dne 30.7.2015 v 09:23 Jan Cholasta napsal(a): > > Hi, > > Dne 29.7.2015 v 17:23 Gabe Alford napsal(a): > > Hello, > > Fix for > https://fedorahosted.org/freeipa/ticket/4023 > > > Actually, 0 means unlimited for size limit, see > > . > > > After reading the ticket I think this should be fixed > the other > way around: make 0 mean unlimited for both time and > size limit > and fix the config plugin and LDAPClient to respect that. > > > Thanks for the review. Updated patch attached. > > > We still need to accept -1 in config-mod for backward compatibility > - when received, it should be converted to 0. > > -- > Jan Cholasta > > -- Jan Cholasta From mkubik at redhat.com Tue Aug 11 07:46:02 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 09:46:02 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C99F7F.9060001@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> <55C99F7F.9060001@redhat.com> Message-ID: <55C9A83A.9070901@redhat.com> On 08/11/2015 09:08 AM, Jan Cholasta wrote: > On 11.8.2015 09:00, Milan Kub?k wrote: > >> On 08/10/2015 06:22 PM, Milan Kub?k wrote: >> >>> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>> >>>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>> >>>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> this patch fixes problem described in the ticket [1] >>>>>> >>>>>> that caused the test run to fail completely at every other or so run. >>>>>> >>>>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>>>> >>>>>> >>>>>> >>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>> >>>>> >>>>> >>>>> IMO this would be more robust: >>>>> >>>>> >>>>> >>>>> t = None >>>>> >>>>> try: >>>>> >>>>> ... >>>>> >>>>> finally: >>>>> >>>>> del t >>>>> >>>>> nss.nss_shutdown() >>>>> >>>>> >>>>> >>>>> By assigning a value to the variable at the beginning you make sure >>>>> >>>>> that the del statement will not fail. >>>>> >>>>> >>>>> >>>>> Honza >>>>> >>>>> >>>>> >>>> Thanks for the idea. It also removed the version check. >>>> >>>> Updated patch attached. >>>> >>>> >>>> >>>> Milan >>>> >>>> >>>> >>>> >>>> >>> Self NACK. >>> >>> >>> >>> I have updated the fix for all of the leaks in that class. It seems to >>> >>> corrupt the database even when no init/shutdown was called. Just not >>> >>> so often. >>> >>> >>> >>> Milan >>> >>> >>> >>> >>> >> NACK again. The problem is the reference counting. Even with this patch, >> >> there seems to be at least one reference left after 't' is deleted and >> >> nss.nss_shutdown races with the garbage collector. >> > > > Doesn't the PKCDDocument object also reference some NSS objects? It > might be worth trying to delete it manually before nss_shutdown as well. > > > > > Yes, this patch doesn't work. There are still some references left. The problem may be on multiple places in here [1]. There may be a reference still bound to the doc label. Another problem is that python 2 code: [x for x in [123, 456]] creates 2 references to 456 as the list used in the assert lives for some time before it is garbage collected even though it is not reachable, holding a reference to the object labeled as t. I don't know how nss counts the references to its objects but I think we should delete all the objects that use/are used by nss explicitly. This means assigning the list produced by the list comprehension a name as well and the delete it when it is not needed. I'll send the patch shortly. [1]: https://paste.fedoraproject.org/253748/92783071/ Milan From jcholast at redhat.com Tue Aug 11 07:53:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 09:53:14 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9A83A.9070901@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> <55C99F7F.9060001@redhat.com> <55C9A83A.9070901@redhat.com> Message-ID: <55C9A9EA.8010907@redhat.com> On 11.8.2015 09:46, Milan Kub?k wrote: > On 08/11/2015 09:08 AM, Jan Cholasta wrote: >> On 11.8.2015 09:00, Milan Kub?k wrote: >> >>> On 08/10/2015 06:22 PM, Milan Kub?k wrote: >>> >>>> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>>> >>>>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>>> >>>>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> this patch fixes problem described in the ticket [1] >>>>>>> >>>>>>> that caused the test run to fail completely at every other or so >>>>>>> run. >>>>>>> >>>>>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>>> >>>>>> >>>>>> >>>>>> IMO this would be more robust: >>>>>> >>>>>> >>>>>> >>>>>> t = None >>>>>> >>>>>> try: >>>>>> >>>>>> ... >>>>>> >>>>>> finally: >>>>>> >>>>>> del t >>>>>> >>>>>> nss.nss_shutdown() >>>>>> >>>>>> >>>>>> >>>>>> By assigning a value to the variable at the beginning you make sure >>>>>> >>>>>> that the del statement will not fail. >>>>>> >>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> >>>>> Thanks for the idea. It also removed the version check. >>>>> >>>>> Updated patch attached. >>>>> >>>>> >>>>> >>>>> Milan >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Self NACK. >>>> >>>> >>>> >>>> I have updated the fix for all of the leaks in that class. It seems to >>>> >>>> corrupt the database even when no init/shutdown was called. Just not >>>> >>>> so often. >>>> >>>> >>>> >>>> Milan >>>> >>>> >>>> >>>> >>>> >>> NACK again. The problem is the reference counting. Even with this patch, >>> >>> there seems to be at least one reference left after 't' is deleted and >>> >>> nss.nss_shutdown races with the garbage collector. >>> >> >> >> Doesn't the PKCDDocument object also reference some NSS objects? It >> might be worth trying to delete it manually before nss_shutdown as well. >> >> >> >> >> > Yes, this patch doesn't work. There are still some references left. > > The problem may be on multiple places in here [1]. > > There may be a reference still bound to the doc label. > Another problem is that python 2 code: > > [x for x in [123, 456]] > > creates 2 references to 456 as the list used in the assert lives for > some time > before it is garbage collected even though it is not reachable, > holding a reference to the object labeled as t. > > I don't know how nss counts the references to its objects but I think we > should > delete all the objects that use/are used by nss explicitly. This means > assigning the list > produced by the list comprehension a name as well and the delete it when > it is not needed. > > I'll send the patch shortly. > > [1]: https://paste.fedoraproject.org/253748/92783071/ Given an assumption that all objects referenced only by local variables are deleted when a function returns, maybe this can be solved with: def nss_initialized(func): def decorated(*args, **kwargs): nss.nss_init_nodb() try: func(*args, **kwargs) finally: nss.nss_shutdown() return decorated ... class test_class(...): @nss_initialized def test_method(self): ... (OTOH and untested) -- Jan Cholasta From mbabinsk at redhat.com Tue Aug 11 07:57:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 11 Aug 2015 09:57:33 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C8C68A.1010606@redhat.com> References: <55C8C68A.1010606@redhat.com> Message-ID: <55C9AAED.2060909@redhat.com> On 08/10/2015 05:43 PM, Milan Kub?k wrote: > Hi all, > > this patch fixes problem described in the ticket [1] > that caused the test run to fail completely at every other or so run. > I took the liberty to fix most of the pep8 issues while I was at it. > > Thanks to Jan Cholasta for help with identifying this one. > > [1]: https://fedorahosted.org/freeipa/ticket/5192 > > Cheers, > Milan > > Hi Milan, I did not follow the rest of the conversation (probably should), but you can also workaround this python2 "feature" by using: """ assert list((t.id, t.options) for t in doc.getKeyPackages()) == \ """ In this case a list is constructed by calling a generator expression which does not leak variables to the outside scope. It may or may not help you but I think it's a trick worth trying. As a bonus it should be py2/3 compatible. -- Martin^3 Babinsky From ofayans at redhat.com Tue Aug 11 08:02:27 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 11 Aug 2015 10:02:27 +0200 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <1439212326.20262.75.camel@willson.usersys.redhat.com> References: <55C866D5.5040808@redhat.com> <1439212326.20262.75.camel@willson.usersys.redhat.com> Message-ID: <55C9AC13.7030705@redhat.com> Hi Simo, Thanks for the clarification. Should I update the design page myself, or is better to let Ludwig do it? On 08/10/2015 03:12 PM, Simo Sorce wrote: > On Mon, 2015-08-10 at 10:54 +0200, Oleg Fayans wrote: >> Hi Ludwig, >> >> It seems the Design page for the topology plugin is a bit outdated. >> 1. It still operates with the terms like plugin version >> (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), >> although it was generally agreed, that we do not use plugin version at all. >> >> 2. The section >> http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition >> should be a bit clarified: >> Does this mean, that if we prepare a replica from a master that has >> domainlevel = 1, then the replica, that already had a domain level = 0 >> will raise it? Do we support this scenario at all? > > No, the domain level must be raised by admin, it cannot be raised > automatically by any component least of all a replica joining a domain. > >> 3. Segment directions. Currently there is no way to specify segment >> direction using the cli `ipa topologysegment-add`. However the direction >> is shown with `ipa topologysegment-find` and `ipa topologysegment-show`, >> which leads to confusing of the users. We probably should remove this >> info from the output at all and update the design page accordingly. > > Showing the direction will allow us in future to show if there are > replication issues only in one of the direction. > > It is true we do not allow to change directions independently (for now > at least), but the information shouldn't hurt. > > Simo. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mkubik at redhat.com Tue Aug 11 08:03:38 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 10:03:38 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9AAED.2060909@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C9AAED.2060909@redhat.com> Message-ID: <55C9AC5A.5030300@redhat.com> On 08/11/2015 09:57 AM, Martin Babinsky wrote: > On 08/10/2015 05:43 PM, Milan Kub?k wrote: >> Hi all, >> >> this patch fixes problem described in the ticket [1] >> that caused the test run to fail completely at every other or so run. >> I took the liberty to fix most of the pep8 issues while I was at it. >> >> Thanks to Jan Cholasta for help with identifying this one. >> >> [1]: https://fedorahosted.org/freeipa/ticket/5192 >> >> Cheers, >> Milan >> >> > Hi Milan, > > I did not follow the rest of the conversation (probably should), but > you can also workaround this python2 "feature" by using: > > """ > assert list((t.id, t.options) for t in doc.getKeyPackages()) == \ > """ > > In this case a list is constructed by calling a generator expression > which does not leak variables to the outside scope. > > It may or may not help you but I think it's a trick worth trying. As a > bonus it should be py2/3 compatible. > Thanks for the suggestion, Martin. I will try that. Though, I suspect there may be other labels holding references to nss objects. I think I will combine this with Jan's suggestion. I will send an update once I'll have the results from a test run. Milan From tbordaz at redhat.com Tue Aug 11 08:06:27 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 11 Aug 2015 10:06:27 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55C0A40A.8080606@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> Message-ID: <55C9AD03.3070107@redhat.com> On 08/04/2015 01:37 PM, Lenka Doudova wrote: > > > Dne 30.7.2015 v 16:10 Martin Basti napsal(a): >> On 30/07/15 16:09, Martin Basti wrote: >>> On 29/07/15 16:10, Martin Basti wrote: >>>> On 29/07/15 15:29, Lenka Doudova wrote: >>>>> Hi, >>>>> >>>>> thanks a lot for the comments, will work on it tomorrow. >>>>> >>>>> Lenka >>>>> >>>>> Dne 29.7.2015 v 15:27 Martin Basti napsal(a): >>>>>> On 27/07/15 16:47, Lenka Doudova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm attaching a patch with automated tests for stageuser plugin >>>>>>> (https://fedorahosted.org/freeipa/ticket/3813). The user plugin >>>>>>> test is affected as well (one class was added). >>>>>>> The tests seem a bit of a mess even to myself, but what with the >>>>>>> way freeipa behaves I didn't know how else to implement them, >>>>>>> but I'm eager to learn how to do it in a nicer way, if someone >>>>>>> has a better idea. >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I just applied patches: >>>>>> >>>>>> 1) Please remove whitespace errors >>>>>> $ git am >>>>>> freeipa-lryznaro-0002-Automated-test-for-stageuser-plugin.patch >>>>>> Applying: Automated test for stageuser plugin >>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:110: >>>>>> trailing whitespace. >>>>>> """ Tracker class for staged user LDAP object >>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:113: >>>>>> trailing whitespace. >>>>>> StageUserTracker object stores information about the user. >>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:121: >>>>>> trailing whitespace. >>>>>> u'krbprincipalexpiration', u'usercertificate', u'dn', >>>>>> u'has_keytab', u'has_password', >>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:122: >>>>>> trailing whitespace. >>>>>> u'street', u'postalcode', u'facsimiletelephonenumber', >>>>>> u'carlicense', >>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:125: >>>>>> trailing whitespace. >>>>>> u'cn', u'ipauniqueid', u'objectclass', u'description', >>>>>> warning: squelched 50 whitespace errors >>>>>> warning: 55 lines add whitespace errors. >>>>>> >>>>>> 2) >>>>>> Please use new shorter format of license header >>>>>> >>>>>> 3) can you fix some of the most serious PEP8 errors >>>>>> $ git show -U0 | pep8 --diff | wc -l >>>>>> 198 >>>>>> >>>>>> 4) >>>>>> if options != None: >>>>>> >>>>>> Please use "options *is not* None" >>>>>> >>>>>> 5) >>>>>> For consistency it should be u'random' >>>>>> if key == 'random': >>>>>> self.attrs[u'randompassword'] = fuzzy_string >>>>>> >>>>>> Otherwise it looks good >>>>>> Martin^2 >>>>>> -- >>>>>> Martin Basti >>>>> >>>> And also fix this please >>>> >>>> ./make-lint >>>> ************* Module ipatests.test_xmlrpc.test_stageuser_plugin >>>> ipatests/test_xmlrpc/test_stageuser_plugin.py:337: >>>> [E0102(function-redefined), user2] function already defined line 44) >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> Ahoj, v patchi mas este uvedene svoje stare meno, mala by si v gite >>> nastavit redhat email >>> >>> -- >>> Martin Basti >>> >>> >> Sorry for spam, you can safely ignore this. :) >> >> -- >> Martin Basti >> >> > Attaching new patch - (hopefully) fixed the errors from the old one + > few test cases were added. > > Lenka > > Hello Lenka, This is a very impressive work and test framework. I have not understood all the details of the implementation so I just focus on the reading the tests body. The patch is looking great to me and I have really few minors comments. * About non existing stage user, you may try to activate a non existing one. Is it what TestStagedUser.test_activate does ? * In test_create_attr, I can see that user6 is activated. How is checked that the specified values are preserved ? (sorry my python skill is still very low) * Many testcases (http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan#Test_case:_Try_to_search_for_a_nonexistent_user) are about creating a stage user with various attributes (initial,shell, homedir...). I found uid/gid, are the others implemented ? * In TestActive.test_delete_preserve, does check_delete check the active container or the stageuser container ? * Does test_delete_preserved checks that the deleted entry has been permanently removed ? * Is test_preserved_membership the test case for https://fedorahosted.org/freeipa/ticket/5170 ? Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Tue Aug 11 08:35:33 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 11 Aug 2015 10:35:33 +0200 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: warn if IP address is used with --server option Message-ID: <55C9B3D5.4020902@redhat.com> Hi, Attached is the patch that adds warning when an IP is passed to --server in ipa-client-install (https://fedorahosted.org/freeipa/ticket/4932). Standa -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0001-ipa-client-install-warn-when-IP-used-in-server.patch Type: text/x-patch Size: 1758 bytes Desc: not available URL: From tbordaz at redhat.com Tue Aug 11 08:40:03 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 11 Aug 2015 10:40:03 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55C9A516.2010603@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> Message-ID: <55C9B4E3.8050007@redhat.com> On 08/11/2015 09:32 AM, Martin Basti wrote: > On 11/08/15 09:17, Jan Cholasta wrote: >> On 5.8.2015 12:34, thierry bordaz wrote: >>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "thierry bordaz" >>>>>> To: "Jan Cholasta" >>>>>> Cc: freeipa-devel at redhat.com >>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete >>>>>> with >>>>>> user-undel --to-staged >>>>>> >>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>> >>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>> >>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>> prompted to >>>>>>>>>>> write name and surname. >>>>>>>>>>> >>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>> First name: this will be ignored >>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>> ------------------------ >>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>> ------------------------ >>>>>>>>>>> >>>>>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>>>> --from-delete option is used. >>>>>>>>>>> I would like to ask how to fix this issue, IMO this will be >>>>>>>>>>> huge >>>>>>>>>>> hack >>>>>>>>>>> in internal API. Or should we just document this bug as known >>>>>>>>>>> issue >>>>>>>>>>> (thierry wrote that this is not use case that should be used >>>>>>>>>>> often)? >>>>>>>>>>> >>>>>>>>>>> The best solution would be separate command, but this idea was >>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>>>>>> regarding the design" >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Martin^2 >>>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> as was mentioned before, we have issue with current internal API >>>>>>>>>> and the >>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>> >>>>>>>>>> We discussed this today, and we did not find a nice way how >>>>>>>>>> to fix >>>>>>>>>> it, >>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>> >>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>> +1 >>>>>>>>> >>>>>>>>>> * create new option for user-undel: used-undel --to-staged (or >>>>>>>>>> create >>>>>>>>>> new command) that will handle moving deleted users to staged >>>>>>>>>> area as >>>>>>>>>> --from-delete did. >>>>>>>>> Make it new command please. >>>>>>>>> >>>>>>>>>> Instead of stageuser-add and option --from-delete, which work >>>>>>>>>> totally >>>>>>>>>> different, the command user-undel does similar operation than >>>>>>>>>> stage-user >>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>> NACK on stuffing everything into a single command just because it >>>>>>>>> does >>>>>>>>> something similar. >>>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>>>> preserved >>>>>>>> to staged. The action is similar, but has slightly different >>>>>>>> specifics >>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>> 'stageuser-undel' >>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>> basically >>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>> user, not >>>>>>>> 'user-add --to-staged'. It would be in the same style as all the >>>>>>>> other >>>>>>>> commands concerning operations with users in staged container. >>>>>>> Well, user-undel is the opposite of user-del, and stageuser-undel >>>>>>> should be the opposite of stageuser-del. The stageuser-undel you >>>>>>> are >>>>>>> suggesting is not. >>>>>>> >>>>>>> Also I'm not sure if we want to (always) remove the deleted user >>>>>>> once >>>>>>> a staged user is created from it, but -undel behaves like that. >>>>>>> >>>>>>> I don't think the command should be limited to deleted users only. >>>>>>> Active and deleted users share the same namespace, so it is an >>>>>>> arbitrary limitation. >>>>>> preserved users has been valid active user. In that sense >>>>>> active/preserved are managed by a same set of CLI >>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>> 'user'. So >>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>> 'user-undel >>>>>> --to-stage'. >>>>>> >>>>>> But then if we will make any incompatible change between >>>>>> "user-undel" >>>>>> and "user-undel --to-stage" we may hit this issue again. I agree >>>>>> with >>>>>> Honza, this should be a separate command. >>>>> What do you mean 'incompatible change' ? >>>>> >>>>> --to-stage option would only select a different container that the >>>>> 'Active' one ? >>>> >>>> That's not sufficient. The command should do the reverse of >>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>> modifications of the entry between them, not MODRDN like user-undel >>>> does. >>>> >>> That is a good point. Do we need to modify anything from a deleted >>> entry >>> to a add it in the stage container. >>> Already delete entry have been purged of several values (password, krb >>> keys, membership,..) do you think of other attributes to remove ? >>> >>> IIRC the use case is a support engineer who activated too early an >>> entry. So you are right he wants to unactivate it. A question is does >>> the unactivation requires more modifications than the one did by >>> 'user-del --preserve'. Note that we can not retrieve the attribute >>> values when the entry was activated from stage. >> >> I don't know if any modifications are needed ATM (doesn't mean there >> can't be any in the future), but the point is that if you are >> creating object A from object B using operation X, you should be >> creating object B from object A using the reverse of operation X, >> otherwise there *will* be inconsistencies, and we don't want that. >> > +1 > I agree with this > So my understanding is that you think a new verb should be created to allow: 'Active' -> 'Stage' I do not recall why this was not discussed or if it as already been rejected. I like the idea and I think it could be useful to Support Engineer. Now I am not sure we want to make 'easy' the action to 'unactivate' a user (currently it requires two operations). In your opinion, does it replace 'stageuser-add --from-delete' or 'user-undel --to-stage' ? or is it an additional subcommand. Also, activate/unactivate is not a NULL operation. Some values has been changed (uid,gid,uniqueuiid...) and some values will be lost (membership). About the verb, this is not because the previous action is 'activate' that we should use 'unactivate'. For example, Thomas raised the point that after 'user-del', 'user-restore' would have been more user friendly than 'user-undel' Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldoudova at redhat.com Tue Aug 11 08:57:02 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 11 Aug 2015 10:57:02 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55C9AD03.3070107@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> Message-ID: <55C9B8DE.9060907@redhat.com> On 08/11/2015 10:06 AM, thierry bordaz wrote: > On 08/04/2015 01:37 PM, Lenka Doudova wrote: >> >> >> Dne 30.7.2015 v 16:10 Martin Basti napsal(a): >>> On 30/07/15 16:09, Martin Basti wrote: >>>> On 29/07/15 16:10, Martin Basti wrote: >>>>> On 29/07/15 15:29, Lenka Doudova wrote: >>>>>> Hi, >>>>>> >>>>>> thanks a lot for the comments, will work on it tomorrow. >>>>>> >>>>>> Lenka >>>>>> >>>>>> Dne 29.7.2015 v 15:27 Martin Basti napsal(a): >>>>>>> On 27/07/15 16:47, Lenka Doudova wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm attaching a patch with automated tests for stageuser plugin >>>>>>>> (https://fedorahosted.org/freeipa/ticket/3813). The user plugin >>>>>>>> test is affected as well (one class was added). >>>>>>>> The tests seem a bit of a mess even to myself, but what with >>>>>>>> the way freeipa behaves I didn't know how else to implement >>>>>>>> them, but I'm eager to learn how to do it in a nicer way, if >>>>>>>> someone has a better idea. >>>>>>>> >>>>>>>> Lenka >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I just applied patches: >>>>>>> >>>>>>> 1) Please remove whitespace errors >>>>>>> $ git am >>>>>>> freeipa-lryznaro-0002-Automated-test-for-stageuser-plugin.patch >>>>>>> Applying: Automated test for stageuser plugin >>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:110: >>>>>>> trailing whitespace. >>>>>>> """ Tracker class for staged user LDAP object >>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:113: >>>>>>> trailing whitespace. >>>>>>> StageUserTracker object stores information about the user. >>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:121: >>>>>>> trailing whitespace. >>>>>>> u'krbprincipalexpiration', u'usercertificate', u'dn', >>>>>>> u'has_keytab', u'has_password', >>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:122: >>>>>>> trailing whitespace. >>>>>>> u'street', u'postalcode', u'facsimiletelephonenumber', >>>>>>> u'carlicense', >>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:125: >>>>>>> trailing whitespace. >>>>>>> u'cn', u'ipauniqueid', u'objectclass', u'description', >>>>>>> warning: squelched 50 whitespace errors >>>>>>> warning: 55 lines add whitespace errors. >>>>>>> >>>>>>> 2) >>>>>>> Please use new shorter format of license header >>>>>>> >>>>>>> 3) can you fix some of the most serious PEP8 errors >>>>>>> $ git show -U0 | pep8 --diff | wc -l >>>>>>> 198 >>>>>>> >>>>>>> 4) >>>>>>> if options != None: >>>>>>> >>>>>>> Please use "options *is not* None" >>>>>>> >>>>>>> 5) >>>>>>> For consistency it should be u'random' >>>>>>> if key == 'random': >>>>>>> self.attrs[u'randompassword'] = fuzzy_string >>>>>>> >>>>>>> Otherwise it looks good >>>>>>> Martin^2 >>>>>>> -- >>>>>>> Martin Basti >>>>>> >>>>> And also fix this please >>>>> >>>>> ./make-lint >>>>> ************* Module ipatests.test_xmlrpc.test_stageuser_plugin >>>>> ipatests/test_xmlrpc/test_stageuser_plugin.py:337: >>>>> [E0102(function-redefined), user2] function already defined line 44) >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>> Ahoj, v patchi mas este uvedene svoje stare meno, mala by si v gite >>>> nastavit redhat email >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> Sorry for spam, you can safely ignore this. :) >>> >>> -- >>> Martin Basti >>> >>> >> Attaching new patch - (hopefully) fixed the errors from the old one + >> few test cases were added. >> >> Lenka >> >> > > > Hello Lenka, > > This is a very impressive work and test framework. I have not > understood all the details of the implementation so I just focus on > the reading the tests body. > The patch is looking great to me and I have really few minors comments. > > * About non existing stage user, you may try to activate a non > existing one. Is it what TestStagedUser.test_activate does ? > No, it didn't occur to me to test activation of nonexistent user, I can add it. > > * In test_create_attr, I can see that user6 is activated. How is > checked that the specified values are preserved ? (sorry my python > skill is still very low) > The values are checked - in the test itself, using 'create_from_staged' I first copy attributes of stage user object to a new active user object (just object, not the ipa user itself) and in 'check_activate' I verify that values of ipa user correspond with those taken from staged user > > * Many testcases > (http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan#Test_case:_Try_to_search_for_a_nonexistent_user) > are about creating a stage user with various attributes > (initial,shell, homedir...). I found uid/gid, are the others > implemented ? > Yes, all the options are implemented using parametrized fixture 'stageduser2' + 'options_ok' list, tests are performed by 'test_create_attr' method. These tests also contain activation check (users can be activated and values are preserved). > > * In TestActive.test_delete_preserve, does check_delete check the > active container or the stageuser container ? > check_delete just checks the result of 'user-del' command (it just says that a certain user has been deleted). But after that, there is a verification that the user is no longer in _active_ container performed by running 'user-show' command with 'not found' as expected result. > > * Does test_delete_preserved checks that the deleted entry has been > permanently removed ? > If you mean whether there is a check like running 'user-show' command and expecting 'not found', no, there is not. I haven't thought about it. Can add. > * Is test_preserved_membership the test case for > https://fedorahosted.org/freeipa/ticket/5170 ? > I'd say that partly - it just verifies if membership can be added to a preserved user (expects failure of such attempt). It does not check whether a user with thus successfully assigned membership preserves it after 'user-undel' (but that is part of TestPreserved.test_reactivate_preserved - the 'check_attr_preservation' method verifies that reactivated user is member of 'ipausers' group only). Lenka > > Thanks > thierry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Aug 11 09:56:01 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 11 Aug 2015 11:56:01 +0200 Subject: [Freeipa-devel] [PATCH] 0034-0035 Allow SAN extension for cert-request self-service In-Reply-To: <20150809073848.GG4843@dhcp-40-8.bne.redhat.com> References: <20150809073848.GG4843@dhcp-40-8.bne.redhat.com> Message-ID: <55C9C6B1.4020300@redhat.com> On 08/09/2015 09:38 AM, Fraser Tweedale wrote: > Patch 0035 fixes #5190 - Users unable to self-issue certificate with > SAN. > > Patch 0034 adds more context to the virtual command ACIError denial > messages. > > Thanks, > Fraser > > > ACK to both patches. -- Martin^3 Babinsky From jcholast at redhat.com Tue Aug 11 10:26:22 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 12:26:22 +0200 Subject: [Freeipa-devel] [PATCH] 0034-0035 Allow SAN extension for cert-request self-service In-Reply-To: <55C9C6B1.4020300@redhat.com> References: <20150809073848.GG4843@dhcp-40-8.bne.redhat.com> <55C9C6B1.4020300@redhat.com> Message-ID: <55C9CDCE.6020306@redhat.com> On 11.8.2015 11:56, Martin Babinsky wrote: > On 08/09/2015 09:38 AM, Fraser Tweedale wrote: >> Patch 0035 fixes #5190 - Users unable to self-issue certificate with >> SAN. >> >> Patch 0034 adds more context to the virtual command ACIError denial >> messages. >> >> Thanks, >> Fraser >> >> >> > > ACK to both patches. > Pushed to: master: aafc0e980be43c4956308a39d2ca45c7e50fa3ab ipa-4-2: 0e44568695e22752c250ead17eeb08e7a1561466 -- Jan Cholasta From mkubik at redhat.com Tue Aug 11 10:33:02 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 12:33:02 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9AC5A.5030300@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C9AAED.2060909@redhat.com> <55C9AC5A.5030300@redhat.com> Message-ID: <55C9CF5E.3080602@redhat.com> On 08/11/2015 10:03 AM, Milan Kub?k wrote: > On 08/11/2015 09:57 AM, Martin Babinsky wrote: >> On 08/10/2015 05:43 PM, Milan Kub?k wrote: >>> Hi all, >>> >>> this patch fixes problem described in the ticket [1] >>> that caused the test run to fail completely at every other or so run. >>> I took the liberty to fix most of the pep8 issues while I was at it. >>> >>> Thanks to Jan Cholasta for help with identifying this one. >>> >>> [1]: https://fedorahosted.org/freeipa/ticket/5192 >>> >>> Cheers, >>> Milan >>> >>> >> Hi Milan, >> >> I did not follow the rest of the conversation (probably should), but >> you can also workaround this python2 "feature" by using: >> >> """ >> assert list((t.id, t.options) for t in doc.getKeyPackages()) == \ >> """ >> >> In this case a list is constructed by calling a generator expression >> which does not leak variables to the outside scope. >> >> It may or may not help you but I think it's a trick worth trying. As >> a bonus it should be py2/3 compatible. >> > Thanks for the suggestion, Martin. > > I will try that. Though, I suspect there may be other labels holding > references to nss objects. I think I will combine this with Jan's > suggestion. > > I will send an update once I'll have the results from a test run. > > Milan > After running the test with the decorator and list comprehensions replaced by a list initialization from a generator expression, it fails on this [1]. Does anyone know what is this teardown method supposed to do? Milan From mkubik at redhat.com Tue Aug 11 10:33:58 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 12:33:58 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9CF5E.3080602@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C9AAED.2060909@redhat.com> <55C9AC5A.5030300@redhat.com> <55C9CF5E.3080602@redhat.com> Message-ID: <55C9CF96.6020108@redhat.com> On 08/11/2015 12:33 PM, Milan Kub?k wrote: > On 08/11/2015 10:03 AM, Milan Kub?k wrote: >> On 08/11/2015 09:57 AM, Martin Babinsky wrote: >>> On 08/10/2015 05:43 PM, Milan Kub?k wrote: >>>> Hi all, >>>> >>>> this patch fixes problem described in the ticket [1] >>>> that caused the test run to fail completely at every other or so run. >>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>> >>>> Thanks to Jan Cholasta for help with identifying this one. >>>> >>>> [1]: https://fedorahosted.org/freeipa/ticket/5192 >>>> >>>> Cheers, >>>> Milan >>>> >>>> >>> Hi Milan, >>> >>> I did not follow the rest of the conversation (probably should), but >>> you can also workaround this python2 "feature" by using: >>> >>> """ >>> assert list((t.id, t.options) for t in doc.getKeyPackages()) == \ >>> """ >>> >>> In this case a list is constructed by calling a generator expression >>> which does not leak variables to the outside scope. >>> >>> It may or may not help you but I think it's a trick worth trying. As >>> a bonus it should be py2/3 compatible. >>> >> Thanks for the suggestion, Martin. >> >> I will try that. Though, I suspect there may be other labels holding >> references to nss objects. I think I will combine this with Jan's >> suggestion. >> >> I will send an update once I'll have the results from a test run. >> >> Milan >> > After running the test with the decorator and list comprehensions > replaced by a list initialization from a generator expression, it > fails on this [1]. > > Does anyone know what is this teardown method supposed to do? > > Milan [1]: https://paste.fedoraproject.org/253792/14392890/ From jcholast at redhat.com Tue Aug 11 10:38:15 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 12:38:15 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9CF96.6020108@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C9AAED.2060909@redhat.com> <55C9AC5A.5030300@redhat.com> <55C9CF5E.3080602@redhat.com> <55C9CF96.6020108@redhat.com> Message-ID: <55C9D097.8010609@redhat.com> On 11.8.2015 12:33, Milan Kub?k wrote: > On 08/11/2015 12:33 PM, Milan Kub?k wrote: >> On 08/11/2015 10:03 AM, Milan Kub?k wrote: >>> On 08/11/2015 09:57 AM, Martin Babinsky wrote: >>>> On 08/10/2015 05:43 PM, Milan Kub?k wrote: >>>>> Hi all, >>>>> >>>>> this patch fixes problem described in the ticket [1] >>>>> that caused the test run to fail completely at every other or so run. >>>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>>> >>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>> >>>>> [1]: https://fedorahosted.org/freeipa/ticket/5192 >>>>> >>>>> Cheers, >>>>> Milan >>>>> >>>>> >>>> Hi Milan, >>>> >>>> I did not follow the rest of the conversation (probably should), but >>>> you can also workaround this python2 "feature" by using: >>>> >>>> """ >>>> assert list((t.id, t.options) for t in doc.getKeyPackages()) == \ >>>> """ >>>> >>>> In this case a list is constructed by calling a generator expression >>>> which does not leak variables to the outside scope. >>>> >>>> It may or may not help you but I think it's a trick worth trying. As >>>> a bonus it should be py2/3 compatible. >>>> >>> Thanks for the suggestion, Martin. >>> >>> I will try that. Though, I suspect there may be other labels holding >>> references to nss objects. I think I will combine this with Jan's >>> suggestion. >>> >>> I will send an update once I'll have the results from a test run. >>> >>> Milan >>> >> After running the test with the decorator and list comprehensions >> replaced by a list initialization from a generator expression, it >> fails on this [1]. >> >> Does anyone know what is this teardown method supposed to do? >> >> Milan > [1]: https://paste.fedoraproject.org/253792/14392890/ > The error message means that the NSS database directory does not exist, it is not readable, or the NSS database is not initialized (as in certutil -N). -- Jan Cholasta From mkubik at redhat.com Tue Aug 11 10:43:28 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 12:43:28 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9D097.8010609@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C9AAED.2060909@redhat.com> <55C9AC5A.5030300@redhat.com> <55C9CF5E.3080602@redhat.com> <55C9CF96.6020108@redhat.com> <55C9D097.8010609@redhat.com> Message-ID: <55C9D1D0.40403@redhat.com> On 08/11/2015 12:38 PM, Jan Cholasta wrote: > On 11.8.2015 12:33, Milan Kub?k wrote: >> On 08/11/2015 12:33 PM, Milan Kub?k wrote: >>> On 08/11/2015 10:03 AM, Milan Kub?k wrote: >>>> On 08/11/2015 09:57 AM, Martin Babinsky wrote: >>>>> On 08/10/2015 05:43 PM, Milan Kub?k wrote: >>>>>> Hi all, >>>>>> >>>>>> this patch fixes problem described in the ticket [1] >>>>>> that caused the test run to fail completely at every other or so >>>>>> run. >>>>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>>>> >>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>> >>>>>> [1]: https://fedorahosted.org/freeipa/ticket/5192 >>>>>> >>>>>> Cheers, >>>>>> Milan >>>>>> >>>>>> >>>>> Hi Milan, >>>>> >>>>> I did not follow the rest of the conversation (probably should), but >>>>> you can also workaround this python2 "feature" by using: >>>>> >>>>> """ >>>>> assert list((t.id, t.options) for t in doc.getKeyPackages()) == \ >>>>> """ >>>>> >>>>> In this case a list is constructed by calling a generator expression >>>>> which does not leak variables to the outside scope. >>>>> >>>>> It may or may not help you but I think it's a trick worth trying. As >>>>> a bonus it should be py2/3 compatible. >>>>> >>>> Thanks for the suggestion, Martin. >>>> >>>> I will try that. Though, I suspect there may be other labels holding >>>> references to nss objects. I think I will combine this with Jan's >>>> suggestion. >>>> >>>> I will send an update once I'll have the results from a test run. >>>> >>>> Milan >>>> >>> After running the test with the decorator and list comprehensions >>> replaced by a list initialization from a generator expression, it >>> fails on this [1]. >>> >>> Does anyone know what is this teardown method supposed to do? >>> >>> Milan >> [1]: https://paste.fedoraproject.org/253792/14392890/ >> > > The error message means that the NSS database directory does not > exist, it is not readable, or the NSS database is not initialized (as > in certutil -N). > Thanks. My main question is why is it called in the teardown method (btw remnant from nose times it seems, but pytest executes it after every test case) Milan From ofayans at redhat.com Tue Aug 11 11:25:46 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 11 Aug 2015 13:25:46 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55C8DAA8.70702@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> Message-ID: <55C9DBBA.1090805@redhat.com> Hi Martin, Thanks for the review! On 08/10/2015 07:08 PM, Martin Basti wrote: > Thank you for patch, I have a few nitpicks: > > 1) > On 10/08/15 13:05, Oleg Fayans wrote: >> +def create_segment(master, leftnode, rightnode): >> + """create_segment(master, leftnode, rightnode) > Why do you add the name of method in docstring? My bad, fixed. > > > 2) > > +def create_segment(master, leftnode, rightnode): > + """create_segment(master, leftnode, rightnode) > + creates a topology segment. The first argument is a node to run the > command on > + The first 3 arguments should be objects of class Host > + Returns a hash object containing segment's name, leftnode, > rightnode information > + """ > > I would prefer to add assert there instead of just document that a Host > object is needed > assert(isinstance(master, Host)) > ... Fixed. Created a decorator that checks the type of arguments > > 3) > +def destroy_segment(master, segment_name): > + """ > + destroy_segment(master, segment_name) > + Destroys topology segment. First argument should be object of class > Host > > Instead of description of params as first, second etc., you may use > following: > > +def destroy_segment(master, segment_name): > + """ > + Destroys topology segment. > + :param master: reference to master object of class Host > + :param segment: name fo segment > and eventually this in other methods > + :returns: Lorem ipsum sit dolor mit amet > + :raises NotFound: if segment is not found > Fixed > > 4) > > cls.replicas[:len(cls.replicas) - 1], > > I suggest cls.replicas[:-1] > > In [2]: a = [1, 2, 3, 4, 5] > > In [3]: a[:-1] > Out[3]: [1, 2, 3, 4] > Fixed > > 5) > Why re.findall() and then you just use the first result? > 'leftnode': self.leftnode_re.findall(i)[0] > > Isn't just re.search() enough? > leftnode_re.search(value).group(1) in fact leftnode_re.findall(string)[0] and leftnode_re.search(string).group(1), Are equally bad from the readability point of view. The first one is even shorter a bit, so why change? :) > > > Python 3 nitpick: > I'm not sure if time when we should enforce python 2/3 compability > already comes, but just for record: > instead of open(file, 'r'), please use io.open(file, 'r') (import io > before) > Done. > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.3-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 11687 bytes Desc: not available URL: From cheimes at redhat.com Tue Aug 11 11:46:02 2015 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 11 Aug 2015 13:46:02 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9A83A.9070901@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> <55C99F7F.9060001@redhat.com> <55C9A83A.9070901@redhat.com> Message-ID: <55C9E07A.90705@redhat.com> On 2015-08-11 09:46, Milan Kub?k wrote: > On 08/11/2015 09:08 AM, Jan Cholasta wrote: >> On 11.8.2015 09:00, Milan Kub?k wrote: >> >>> On 08/10/2015 06:22 PM, Milan Kub?k wrote: >>> >>>> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>>> >>>>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>>> >>>>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> this patch fixes problem described in the ticket [1] >>>>>>> >>>>>>> that caused the test run to fail completely at every other or so >>>>>>> run. >>>>>>> >>>>>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>>> >>>>>> >>>>>> >>>>>> IMO this would be more robust: >>>>>> >>>>>> >>>>>> >>>>>> t = None >>>>>> >>>>>> try: >>>>>> >>>>>> ... >>>>>> >>>>>> finally: >>>>>> >>>>>> del t >>>>>> >>>>>> nss.nss_shutdown() >>>>>> >>>>>> >>>>>> >>>>>> By assigning a value to the variable at the beginning you make sure >>>>>> >>>>>> that the del statement will not fail. >>>>>> >>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>>> >>>>>> >>>>> Thanks for the idea. It also removed the version check. >>>>> >>>>> Updated patch attached. >>>>> >>>>> >>>>> >>>>> Milan >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Self NACK. >>>> >>>> >>>> >>>> I have updated the fix for all of the leaks in that class. It seems to >>>> >>>> corrupt the database even when no init/shutdown was called. Just not >>>> >>>> so often. >>>> >>>> >>>> >>>> Milan >>>> >>>> >>>> >>>> >>>> >>> NACK again. The problem is the reference counting. Even with this patch, >>> >>> there seems to be at least one reference left after 't' is deleted and >>> >>> nss.nss_shutdown races with the garbage collector. >>> >> >> >> Doesn't the PKCDDocument object also reference some NSS objects? It >> might be worth trying to delete it manually before nss_shutdown as well. >> >> >> >> >> > Yes, this patch doesn't work. There are still some references left. > > The problem may be on multiple places in here [1]. > > There may be a reference still bound to the doc label. > Another problem is that python 2 code: > > [x for x in [123, 456]] > > creates 2 references to 456 as the list used in the assert lives for > some time > before it is garbage collected even though it is not reachable, > holding a reference to the object labeled as t. In Python 2 the list comprehension leaks the internal loop variable. It was an oversight in the design of list comprehensions. This has been fixed in Python 3. You can work around the problem with a generator expression inside list() list(x for x in [123, 456]) is equivalent to [x for x in [123, 456]] except it doesn't leak x to the outer scope. If you suspect an issue related to cyclic GC, you can force a garbage collector run with gc.collect(). Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mkubik at redhat.com Tue Aug 11 11:52:16 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 13:52:16 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9E07A.90705@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> <55C99F7F.9060001@redhat.com> <55C9A83A.9070901@redhat.com> <55C9E07A.90705@redhat.com> Message-ID: <55C9E1F0.7060201@redhat.com> On 08/11/2015 01:46 PM, Christian Heimes wrote: > On 2015-08-11 09:46, Milan Kub?k wrote: >> On 08/11/2015 09:08 AM, Jan Cholasta wrote: >>> On 11.8.2015 09:00, Milan Kub?k wrote: >>> >>>> On 08/10/2015 06:22 PM, Milan Kub?k wrote: >>>> >>>>> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>>>> >>>>>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>>>> >>>>>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> this patch fixes problem described in the ticket [1] >>>>>>>> >>>>>>>> that caused the test run to fail completely at every other or so >>>>>>>> run. >>>>>>>> >>>>>>>> I took the liberty to fix most of the pep8 issues while I was at it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>>>> >>>>>>> >>>>>>> IMO this would be more robust: >>>>>>> >>>>>>> >>>>>>> >>>>>>> t = None >>>>>>> >>>>>>> try: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> finally: >>>>>>> >>>>>>> del t >>>>>>> >>>>>>> nss.nss_shutdown() >>>>>>> >>>>>>> >>>>>>> >>>>>>> By assigning a value to the variable at the beginning you make sure >>>>>>> >>>>>>> that the del statement will not fail. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks for the idea. It also removed the version check. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> >>>>>> >>>>>> Milan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Self NACK. >>>>> >>>>> >>>>> >>>>> I have updated the fix for all of the leaks in that class. It seems to >>>>> >>>>> corrupt the database even when no init/shutdown was called. Just not >>>>> >>>>> so often. >>>>> >>>>> >>>>> >>>>> Milan >>>>> >>>>> >>>>> >>>>> >>>>> >>>> NACK again. The problem is the reference counting. Even with this patch, >>>> >>>> there seems to be at least one reference left after 't' is deleted and >>>> >>>> nss.nss_shutdown races with the garbage collector. >>>> >>> >>> Doesn't the PKCDDocument object also reference some NSS objects? It >>> might be worth trying to delete it manually before nss_shutdown as well. >>> >>> >>> >>> >>> >> Yes, this patch doesn't work. There are still some references left. >> >> The problem may be on multiple places in here [1]. >> >> There may be a reference still bound to the doc label. >> Another problem is that python 2 code: >> >> [x for x in [123, 456]] >> >> creates 2 references to 456 as the list used in the assert lives for >> some time >> before it is garbage collected even though it is not reachable, >> holding a reference to the object labeled as t. > In Python 2 the list comprehension leaks the internal loop variable. It > was an oversight in the design of list comprehensions. This has been > fixed in Python 3. You can work around the problem with a generator > expression inside list() > > list(x for x in [123, 456]) > > is equivalent to > > [x for x in [123, 456]] > > except it doesn't leak x to the outer scope. > > If you suspect an issue related to cyclic GC, you can force a garbage > collector run with gc.collect(). > > Christian > > Hi Christian, I already use the generator expression as Martin suggested earlier today. Together with the decorator proposed by Jan. I had some trouble with the test teardown method, but it seems I had a minor problem in my environment as there was missing ~/.ipa/alias directory in the test run. On the other hand, while not changing the job on jenkins I wonder why it worked sometimes in this env. Milan From mbasti at redhat.com Tue Aug 11 12:02:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Aug 2015 14:02:46 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55C9DBBA.1090805@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> Message-ID: <55C9E466.4060503@redhat.com> NACK, comments inline. On 11/08/15 13:25, Oleg Fayans wrote: > Hi Martin, > > Thanks for the review! > > On 08/10/2015 07:08 PM, Martin Basti wrote: >> Thank you for patch, I have a few nitpicks: >> >> 1) >> On 10/08/15 13:05, Oleg Fayans wrote: >>> +def create_segment(master, leftnode, rightnode): >>> + """create_segment(master, leftnode, rightnode) >> Why do you add the name of method in docstring? > My bad, fixed. still there + tokenize_topologies(command_output) + takes an output of `ipa topologysegment-find` and returns an array of >> >> >> 2) >> >> +def create_segment(master, leftnode, rightnode): >> + """create_segment(master, leftnode, rightnode) >> + creates a topology segment. The first argument is a node to run the >> command on >> + The first 3 arguments should be objects of class Host >> + Returns a hash object containing segment's name, leftnode, >> rightnode information >> + """ >> >> I would prefer to add assert there instead of just document that a Host >> object is needed >> assert(isinstance(master, Host)) >> ... > > Fixed. Created a decorator that checks the type of arguments This does not scale well. If we will want to add new argument that is not host object, you need change it again. This might be used as function with specified variables that have to be host objects > >> >> 3) >> +def destroy_segment(master, segment_name): >> + """ >> + destroy_segment(master, segment_name) >> + Destroys topology segment. First argument should be object of class >> Host >> >> Instead of description of params as first, second etc., you may use >> following: >> >> +def destroy_segment(master, segment_name): >> + """ >> + Destroys topology segment. >> + :param master: reference to master object of class Host >> + :param segment: name fo segment >> and eventually this in other methods >> + :returns: Lorem ipsum sit dolor mit amet >> + :raises NotFound: if segment is not found >> > Fixed >> >> 4) >> >> cls.replicas[:len(cls.replicas) - 1], >> >> I suggest cls.replicas[:-1] >> >> In [2]: a = [1, 2, 3, 4, 5] >> >> In [3]: a[:-1] >> Out[3]: [1, 2, 3, 4] >> > Fixed >> >> 5) >> Why re.findall() and then you just use the first result? >> 'leftnode': self.leftnode_re.findall(i)[0] >> >> Isn't just re.search() enough? >> leftnode_re.search(value).group(1) > > in fact > leftnode_re.findall(string)[0] > and > leftnode_re.search(string).group(1), > Are equally bad from the readability point of view. The first one is > even shorter a bit, so why change? :) It depends on point of view, because when I reviewed it yesterday my brain raises exception that you are trying to add multiple values to single value attribute, because you used findall, I expected that you need multiple values, and then I saw that index [0] at the end, and I was pretty confused what are you trying to achieve. And because findall is not effective in case when you need to find just one occurrence. > >> >> >> Python 3 nitpick: >> I'm not sure if time when we should enforce python 2/3 compability >> already comes, but just for record: >> instead of open(file, 'r'), please use io.open(file, 'r') (import io >> before) >> > Done. >> >> >> > 1) +# empty comment here (several times) -- Martin Basti From simo at redhat.com Tue Aug 11 12:30:44 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 11 Aug 2015 08:30:44 -0400 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55C9AC13.7030705@redhat.com> References: <55C866D5.5040808@redhat.com> <1439212326.20262.75.camel@willson.usersys.redhat.com> <55C9AC13.7030705@redhat.com> Message-ID: <1439296244.20262.107.camel@willson.usersys.redhat.com> On Tue, 2015-08-11 at 10:02 +0200, Oleg Fayans wrote: > Hi Simo, > > Thanks for the clarification. Should I update the design page myself, or > is better to let Ludwig do it? Either way is fine by me. Simo. > On 08/10/2015 03:12 PM, Simo Sorce wrote: > > On Mon, 2015-08-10 at 10:54 +0200, Oleg Fayans wrote: > >> Hi Ludwig, > >> > >> It seems the Design page for the topology plugin is a bit outdated. > >> 1. It still operates with the terms like plugin version > >> (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), > >> although it was generally agreed, that we do not use plugin version at all. > >> > >> 2. The section > >> http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition > >> should be a bit clarified: > >> Does this mean, that if we prepare a replica from a master that has > >> domainlevel = 1, then the replica, that already had a domain level = 0 > >> will raise it? Do we support this scenario at all? > > > > No, the domain level must be raised by admin, it cannot be raised > > automatically by any component least of all a replica joining a domain. > > > >> 3. Segment directions. Currently there is no way to specify segment > >> direction using the cli `ipa topologysegment-add`. However the direction > >> is shown with `ipa topologysegment-find` and `ipa topologysegment-show`, > >> which leads to confusing of the users. We probably should remove this > >> info from the output at all and update the design page accordingly. > > > > Showing the direction will allow us in future to show if there are > > replication issues only in one of the direction. > > > > It is true we do not allow to change directions independently (for now > > at least), but the information shouldn't hurt. > > > > Simo. > > > -- Simo Sorce * Red Hat, Inc * New York From lslebodn at redhat.com Tue Aug 11 12:35:25 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 11 Aug 2015 14:35:25 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C8A580.7040700@redhat.com> References: <55C37C89.3040209@redhat.com> <55C453E7.9030700@redhat.com> <55C45444.1070104@redhat.com> <55C45BA1.3020209@redhat.com> <55C8A580.7040700@redhat.com> Message-ID: <20150811123525.GE15366@mail.corp.redhat.com> On (10/08/15 15:22), Jan Cholasta wrote: >Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>Hi list, >>>>> >>>>>I just noticed that the bits built from ipa-4-2 branch cannot be >>>>>installed. >>>>>The freeipa packages built have version such as >>>>>freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>> >>>>>The version check in the spec file makes the server-dns package >>>>>obsolete the >>>>>server package from tha same build. >>>>>The cause is the commit [1]. This issue blocks us from running tests >>>>>on ipa-4-2 >>>>>branch. >>>>> >>>>>Should we bump the minor version on this branch to 4.2.1? >>>>> >>>>>[1]: >>>>>https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>Cheers, >>>>>Milan >>>>> >>>>Why does the spec calls for >>>> >>>># upgrade path from monolithic -server to -server + -server-dns >>>>Obsoletes: %{name}-server <= 4.2.0 >>>> >>>>and not for >>>> >>>># upgrade path from monolithic -server to -server + -server-dns >>>>Obsoletes: %{name}-server < 4.2.0 >>>> >>>>? Is that the root cause of these issues? >>> >>>AFAIK this would break updates from 4.2.0 to 4.2.1. >> >>I wonder how it could break the upgrade... >> > >Patch attached. > >-- >Jan Cholasta >From a7fb34f1a4c32fb8fc1934e95ffbb26ed0d27e06 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Mon, 10 Aug 2015 15:19:56 +0200 >Subject: [PATCH] spec file: Fix install with the server-dns subpackage > >--- > freeipa.spec.in | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 57d3d26..0015191 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -169,7 +169,7 @@ Obsoletes: %{alt_name}-server < %{version} > Obsoletes: freeipa-server-selinux < 3.3.0 > > # upgrade path from monolithic -server to -server + -server-dns >-Obsoletes: %{name}-server <= 4.2.0 >+Obsoletes: %{name}-server < 4.2.1 > > # Versions of nss-pam-ldapd < 0.8.4 require a mapping from uniqueMember to > # member. >@@ -206,7 +206,7 @@ Conflicts: %{alt_name}-server-dns > Obsoletes: %{alt_name}-server-dns < %{version} > > # upgrade path from monolithic -server to -server + -server-dns >-Obsoletes: %{name}-server <= 4.2.0 >+Obsoletes: %{name}-server < 4.2.1 > > %description server-dns > IPA integrated DNS server with support for automatic DNSSEC signing. Is it a "(n:1) Many-to-one replacement"[1] or "(n:m) Many to many replacement"[1] ? I think the safest way would be to bump 4.2.0 -> 4.2.0.1 (without official release; it's just for developers) my 2 cents LS [1]https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages From mbabinsk at redhat.com Tue Aug 11 12:35:48 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 11 Aug 2015 14:35:48 +0200 Subject: [Freeipa-devel] [PATCH] 0037 Add profile for DNP3 / IEC 62351-8 certificates In-Reply-To: <20150810044614.GE6626@dhcp-40-8.bne.redhat.com> References: <20150810043904.GD6626@dhcp-40-8.bne.redhat.com> <20150810044614.GE6626@dhcp-40-8.bne.redhat.com> Message-ID: <55C9EC24.9080308@redhat.com> On 08/10/2015 06:46 AM, Fraser Tweedale wrote: > Whups, that should be patch number >> 0037 << > > On Mon, Aug 10, 2015 at 02:39:04PM +1000, Fraser Tweedale wrote: >> The attached patch adds a DNP3 profile, addressing >> https://fedorahosted.org/freeipa/ticket/4752. >> >> It depends on my patch 0029 [1] which is a workaround for >> a python-nss bug [2] we are waiting on a fix for. >> >> [1] https://www.redhat.com/archives/freeipa-devel/2015-July/msg00623.html >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1246729 >> >> Thanks, >> Fraser > Seems to work as expected, ACK. -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Aug 11 12:36:26 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 11 Aug 2015 14:36:26 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Work around python-nss bug on unrecognised OIDs In-Reply-To: <20150730040904.GA4243@dhcp-40-8.bne.redhat.com> References: <20150730040904.GA4243@dhcp-40-8.bne.redhat.com> Message-ID: <55C9EC4A.7060601@redhat.com> On 07/30/2015 06:09 AM, Fraser Tweedale wrote: > The attached patch works around a bug in python-nss triggered by > unrecognised PKCS#10 request extensions. It is needed for > https://fedorahosted.org/freeipa/ticket/4752 but can be reverted > once the python-nss bug is fixed. > > Thanks, > Fraser > > > ACK -- Martin^3 Babinsky From jcholast at redhat.com Tue Aug 11 12:58:26 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 14:58:26 +0200 Subject: [Freeipa-devel] [PATCH] 0037 Add profile for DNP3 / IEC 62351-8 certificates In-Reply-To: <55C9EC24.9080308@redhat.com> References: <20150810043904.GD6626@dhcp-40-8.bne.redhat.com> <20150810044614.GE6626@dhcp-40-8.bne.redhat.com> <55C9EC24.9080308@redhat.com> Message-ID: <55C9F172.9090403@redhat.com> On 11.8.2015 14:35, Martin Babinsky wrote: > On 08/10/2015 06:46 AM, Fraser Tweedale wrote: >> Whups, that should be patch number >> 0037 << >> >> On Mon, Aug 10, 2015 at 02:39:04PM +1000, Fraser Tweedale wrote: >>> The attached patch adds a DNP3 profile, addressing >>> https://fedorahosted.org/freeipa/ticket/4752. >>> >>> It depends on my patch 0029 [1] which is a workaround for >>> a python-nss bug [2] we are waiting on a fix for. >>> >>> [1] >>> https://www.redhat.com/archives/freeipa-devel/2015-July/msg00623.html >>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1246729 >>> >>> Thanks, >>> Fraser >> > > Seems to work as expected, ACK. > Pushed to: master: 812ab600a33f0a334e757420783583f700ec07e7 ipa-4-2: 2001e7b7b42e583e04e0cc18cecef328ef0c483d -- Jan Cholasta From mkubik at redhat.com Tue Aug 11 13:23:12 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 11 Aug 2015 15:23:12 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9A9EA.8010907@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> <55C99F7F.9060001@redhat.com> <55C9A83A.9070901@redhat.com> <55C9A9EA.8010907@redhat.com> Message-ID: <55C9F740.7060008@redhat.com> On 08/11/2015 09:53 AM, Jan Cholasta wrote: > On 11.8.2015 09:46, Milan Kub?k wrote: >> On 08/11/2015 09:08 AM, Jan Cholasta wrote: >>> On 11.8.2015 09:00, Milan Kub?k wrote: >>> >>>> On 08/10/2015 06:22 PM, Milan Kub?k wrote: >>>> >>>>> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>>>> >>>>>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>>>> >>>>>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> this patch fixes problem described in the ticket [1] >>>>>>>> >>>>>>>> that caused the test run to fail completely at every other or so >>>>>>>> run. >>>>>>>> >>>>>>>> I took the liberty to fix most of the pep8 issues while I was >>>>>>>> at it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> IMO this would be more robust: >>>>>>> >>>>>>> >>>>>>> >>>>>>> t = None >>>>>>> >>>>>>> try: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> finally: >>>>>>> >>>>>>> del t >>>>>>> >>>>>>> nss.nss_shutdown() >>>>>>> >>>>>>> >>>>>>> >>>>>>> By assigning a value to the variable at the beginning you make sure >>>>>>> >>>>>>> that the del statement will not fail. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks for the idea. It also removed the version check. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> >>>>>> >>>>>> Milan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Self NACK. >>>>> >>>>> >>>>> >>>>> I have updated the fix for all of the leaks in that class. It >>>>> seems to >>>>> >>>>> corrupt the database even when no init/shutdown was called. Just not >>>>> >>>>> so often. >>>>> >>>>> >>>>> >>>>> Milan >>>>> >>>>> >>>>> >>>>> >>>>> >>>> NACK again. The problem is the reference counting. Even with this >>>> patch, >>>> >>>> there seems to be at least one reference left after 't' is deleted and >>>> >>>> nss.nss_shutdown races with the garbage collector. >>>> >>> >>> >>> Doesn't the PKCDDocument object also reference some NSS objects? It >>> might be worth trying to delete it manually before nss_shutdown as >>> well. >>> >>> >>> >>> >>> >> Yes, this patch doesn't work. There are still some references left. >> >> The problem may be on multiple places in here [1]. >> >> There may be a reference still bound to the doc label. >> Another problem is that python 2 code: >> >> [x for x in [123, 456]] >> >> creates 2 references to 456 as the list used in the assert lives for >> some time >> before it is garbage collected even though it is not reachable, >> holding a reference to the object labeled as t. >> >> I don't know how nss counts the references to its objects but I think we >> should ow I think >> delete all the objects that use/are used by nss explicitly. This means >> assigning the list >> produced by the list comprehension a name as well and the delete it when >> it is not needed. >> >> I'll send the patch shortly. >> >> [1]: https://paste.fedoraproject.org/253748/92783071/ > > Given an assumption that all objects referenced only by local > variables are deleted when a function returns, maybe this can be > solved with: > > def nss_initialized(func): > def decorated(*args, **kwargs): > nss.nss_init_nodb() > try: > func(*args, **kwargs) > finally: > nss.nss_shutdown() > return decorated > > ... > > class test_class(...): > @nss_initialized > def test_method(self): > ... > > (OTOH and untested) > It seems that NSS decided the assumption doesn't hold. [1] Plus, the decorator seems to change the execution order of the test cases. [1]: https://paste.fedoraproject.org/253846/39299083/ Milan From ftweedal at redhat.com Tue Aug 11 13:23:36 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 11 Aug 2015 23:23:36 +1000 Subject: [Freeipa-devel] [PATCH] 0036 Fix KRB5PrincipalName / UPN SAN comparison In-Reply-To: <20150809100347.GH4843@dhcp-40-8.bne.redhat.com> References: <20150809100347.GH4843@dhcp-40-8.bne.redhat.com> Message-ID: <20150811132336.GM16439@dhcp-40-8.bne.redhat.com> On Sun, Aug 09, 2015 at 08:03:47PM +1000, Fraser Tweedale wrote: > The attached patch fixes a bug in KRB5PrincipalName / UPN SAN > validation. > > Thanks, > Fraser For testing this, the following `openssl req' config will serve as a starting point; customise the names / realm as appropriate. [ req ] prompt = no encrypt_key = no distinguished_name = dn req_extensions = exts [ dn ] commonName = "alice" [ exts ] subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:krb5principal [ krb5principal ] realm = EXPLICIT:0,GeneralString:IPA.LOCAL principalname = EXPLICIT:1,SEQUENCE:principalname [ principalname ] nametype = EXPLICIT:0,INT:0 namestring = EXPLICIT:1,SEQUENCE:namestring [ namestring ] part1 = GeneralString:alice From mbabinsk at redhat.com Tue Aug 11 13:31:50 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 11 Aug 2015 15:31:50 +0200 Subject: [Freeipa-devel] [PATCH] 0036 Fix KRB5PrincipalName / UPN SAN comparison In-Reply-To: <20150811132336.GM16439@dhcp-40-8.bne.redhat.com> References: <20150809100347.GH4843@dhcp-40-8.bne.redhat.com> <20150811132336.GM16439@dhcp-40-8.bne.redhat.com> Message-ID: <55C9F946.4040606@redhat.com> On 08/11/2015 03:23 PM, Fraser Tweedale wrote: > On Sun, Aug 09, 2015 at 08:03:47PM +1000, Fraser Tweedale wrote: >> The attached patch fixes a bug in KRB5PrincipalName / UPN SAN >> validation. >> >> Thanks, >> Fraser > > For testing this, the following `openssl req' config will serve as a > starting point; customise the names / realm as appropriate. > > [ req ] > prompt = no > encrypt_key = no > > distinguished_name = dn > req_extensions = exts > > [ dn ] > commonName = "alice" > > [ exts ] > subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:krb5principal > > [ krb5principal ] > realm = EXPLICIT:0,GeneralString:IPA.LOCAL > principalname = EXPLICIT:1,SEQUENCE:principalname > > [ principalname ] > nametype = EXPLICIT:0,INT:0 > namestring = EXPLICIT:1,SEQUENCE:namestring > > [ namestring ] > part1 = GeneralString:alice > Thank for help, I'm ASN.1 n00b. ACK. -- Martin^3 Babinsky From jcholast at redhat.com Tue Aug 11 13:34:25 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 15:34:25 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Work around python-nss bug on unrecognised OIDs In-Reply-To: <55C9EC4A.7060601@redhat.com> References: <20150730040904.GA4243@dhcp-40-8.bne.redhat.com> <55C9EC4A.7060601@redhat.com> Message-ID: <55C9F9E1.40504@redhat.com> On 11.8.2015 14:36, Martin Babinsky wrote: > On 07/30/2015 06:09 AM, Fraser Tweedale wrote: >> The attached patch works around a bug in python-nss triggered by >> unrecognised PKCS#10 request extensions. It is needed for >> https://fedorahosted.org/freeipa/ticket/4752 but can be reverted >> once the python-nss bug is fixed. >> >> Thanks, >> Fraser >> >> >> > ACK > Pushed to: master: e92f25bd50b60ce3c5d2c09bea700001050651a3 ipa-4-2: 190c7c08c87f6c57edde3cde4eaa1edeb9b7c8c4 -- Jan Cholasta From ofayans at redhat.com Tue Aug 11 13:36:36 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 11 Aug 2015 15:36:36 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55C9E466.4060503@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> Message-ID: <55C9FA64.1030307@redhat.com> Hi Martin, On 08/11/2015 02:02 PM, Martin Basti wrote: > NACK, comments inline. > > On 11/08/15 13:25, Oleg Fayans wrote: >> Hi Martin, >> >> Thanks for the review! >> >> On 08/10/2015 07:08 PM, Martin Basti wrote: >>> Thank you for patch, I have a few nitpicks: >>> >>> 1) >>> On 10/08/15 13:05, Oleg Fayans wrote: >>>> +def create_segment(master, leftnode, rightnode): >>>> + """create_segment(master, leftnode, rightnode) >>> Why do you add the name of method in docstring? >> My bad, fixed. > > still there > > + tokenize_topologies(command_output) > + takes an output of `ipa topologysegment-find` and returns an > array of > Fixed, sorry. > >>> >>> >>> 2) >>> >>> +def create_segment(master, leftnode, rightnode): >>> + """create_segment(master, leftnode, rightnode) >>> + creates a topology segment. The first argument is a node to run the >>> command on >>> + The first 3 arguments should be objects of class Host >>> + Returns a hash object containing segment's name, leftnode, >>> rightnode information >>> + """ >>> >>> I would prefer to add assert there instead of just document that a Host >>> object is needed >>> assert(isinstance(master, Host)) >>> ... >> >> Fixed. Created a decorator that checks the type of arguments > > This does not scale well. > If we will want to add new argument that is not host object, you need > change it again. Agreed. Modified the decorator so that you can specify a slice of arguments to be checked and a class to compare to. This does scale :) > > This might be used as function with specified variables that have to be > host objects >> >>> >>> 3) >>> +def destroy_segment(master, segment_name): >>> + """ >>> + destroy_segment(master, segment_name) >>> + Destroys topology segment. First argument should be object of class >>> Host >>> >>> Instead of description of params as first, second etc., you may use >>> following: >>> >>> +def destroy_segment(master, segment_name): >>> + """ >>> + Destroys topology segment. >>> + :param master: reference to master object of class Host >>> + :param segment: name fo segment >>> and eventually this in other methods >>> + :returns: Lorem ipsum sit dolor mit amet >>> + :raises NotFound: if segment is not found >>> >> Fixed >>> >>> 4) >>> >>> cls.replicas[:len(cls.replicas) - 1], >>> >>> I suggest cls.replicas[:-1] >>> >>> In [2]: a = [1, 2, 3, 4, 5] >>> >>> In [3]: a[:-1] >>> Out[3]: [1, 2, 3, 4] >>> >> Fixed >>> >>> 5) >>> Why re.findall() and then you just use the first result? >>> 'leftnode': self.leftnode_re.findall(i)[0] >>> >>> Isn't just re.search() enough? >>> leftnode_re.search(value).group(1) >> >> in fact >> leftnode_re.findall(string)[0] >> and >> leftnode_re.search(string).group(1), >> Are equally bad from the readability point of view. The first one is >> even shorter a bit, so why change? :) > > It depends on point of view, because when I reviewed it yesterday my > brain raises exception that you are trying to add multiple values to > single value attribute, because you used findall, I expected that you > need multiple values, and then I saw that index [0] at the end, and I > was pretty confused what are you trying to achieve. > > And because findall is not effective in case when you need to find just > one occurrence. I got it. Fixed. > > >> >>> >>> >>> Python 3 nitpick: >>> I'm not sure if time when we should enforce python 2/3 compability >>> already comes, but just for record: >>> instead of open(file, 'r'), please use io.open(file, 'r') (import io >>> before) >>> >> Done. >>> >>> >>> >> > > 1) > > +# > > empty comment here (several times) Removed > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.4-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 12100 bytes Desc: not available URL: From tbabej at redhat.com Tue Aug 11 14:08:55 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 11 Aug 2015 16:08:55 +0200 Subject: [Freeipa-devel] [PATCH 0359] adtrust-install: Correctly determine 4.2 FreeIPA servers Message-ID: <55CA01F7.6040100@redhat.com> Hi, We need to detect a list of FreeIPA 4.2 (and above) servers, since only there is the required version of SSSD present. Since the maximum domain level for 4.2 is 0 (and not 1), we can filter for any value of ipaMaxDomainLevel / ipaMinDomainLevel attributes to generate the list. https://fedorahosted.org/freeipa/ticket/5199 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0359-adtrust-install-Correctly-determine-4.2-FreeIPA-serv.patch Type: text/x-patch Size: 1528 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 11 14:58:11 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Aug 2015 17:58:11 +0300 Subject: [Freeipa-devel] [PATCH 0359] adtrust-install: Correctly determine 4.2 FreeIPA servers In-Reply-To: <55CA01F7.6040100@redhat.com> References: <55CA01F7.6040100@redhat.com> Message-ID: <20150811145811.GS22106@redhat.com> On Tue, 11 Aug 2015, Tomas Babej wrote: >Hi, > > We need to detect a list of FreeIPA 4.2 (and above) servers, since >only there is the required version of SSSD present. > >Since the maximum domain level for 4.2 is 0 (and not 1), we can filter >for any value of ipaMaxDomainLevel / ipaMinDomainLevel attributes >to generate the list. > >https://fedorahosted.org/freeipa/ticket/5199 >From 31bf121e4603bc1287eac88653ff48198c2f69c3 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Tue, 11 Aug 2015 16:05:32 +0200 >Subject: [PATCH] adtrust-install: Correctly determine 4.2 FreeIPA servers > >We need to detect a list of FreeIPA 4.2 (and above) servers, since >only there is the required version of SSSD present. > >Since the maximum domain level for 4.2 is 0 (and not 1), we can filter >for any value of ipaMaxDomainLevel / ipaMinDomainLevel attributes >to generate the list. > >https://fedorahosted.org/freeipa/ticket/5199 >--- > install/tools/ipa-adtrust-install | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install >index 5340c31d16ed78da0cb39725d9ae93c76470b698..21e58dd9f25e82429ce8d0c776d1b512c2661809 100755 >--- a/install/tools/ipa-adtrust-install >+++ b/install/tools/ipa-adtrust-install >@@ -396,7 +396,7 @@ def main(): > # Search only masters which have support for domain levels > # because only these masters will have SSSD recent enough to support AD trust agents > (entries_m, truncated) = smb.admin_conn.find_entries( >- filter="(&(objectclass=ipaSupportedDomainLevelConfig)(!(ipaMaxDomainLevel=0)))", >+ filter="(&(objectclass=ipaSupportedDomainLevelConfig)(ipaMaxDomainLevel=*)(ipaMinDomainLevel=*))", > base_dn=masters_dn, attrs_list=['cn'], scope=ldap.SCOPE_ONELEVEL) > except errors.NotFound: > pass ACK. I tested a manual version of this patch in the morning. -- / Alexander Bokovoy From jcholast at redhat.com Tue Aug 11 14:59:39 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Aug 2015 16:59:39 +0200 Subject: [Freeipa-devel] [PATCH 0359] adtrust-install: Correctly determine 4.2 FreeIPA servers In-Reply-To: <20150811145811.GS22106@redhat.com> References: <55CA01F7.6040100@redhat.com> <20150811145811.GS22106@redhat.com> Message-ID: <55CA0DDB.6010009@redhat.com> On 11.8.2015 16:58, Alexander Bokovoy wrote: > On Tue, 11 Aug 2015, Tomas Babej wrote: >> Hi, >> >> We need to detect a list of FreeIPA 4.2 (and above) servers, since >> only there is the required version of SSSD present. >> >> Since the maximum domain level for 4.2 is 0 (and not 1), we can filter >> for any value of ipaMaxDomainLevel / ipaMinDomainLevel attributes >> to generate the list. >> >> https://fedorahosted.org/freeipa/ticket/5199 > >> From 31bf121e4603bc1287eac88653ff48198c2f69c3 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Tue, 11 Aug 2015 16:05:32 +0200 >> Subject: [PATCH] adtrust-install: Correctly determine 4.2 FreeIPA servers >> >> We need to detect a list of FreeIPA 4.2 (and above) servers, since >> only there is the required version of SSSD present. >> >> Since the maximum domain level for 4.2 is 0 (and not 1), we can filter >> for any value of ipaMaxDomainLevel / ipaMinDomainLevel attributes >> to generate the list. >> >> https://fedorahosted.org/freeipa/ticket/5199 >> --- >> install/tools/ipa-adtrust-install | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/tools/ipa-adtrust-install >> b/install/tools/ipa-adtrust-install >> index >> 5340c31d16ed78da0cb39725d9ae93c76470b698..21e58dd9f25e82429ce8d0c776d1b512c2661809 >> 100755 >> --- a/install/tools/ipa-adtrust-install >> +++ b/install/tools/ipa-adtrust-install >> @@ -396,7 +396,7 @@ def main(): >> # Search only masters which have support for domain levels >> # because only these masters will have SSSD recent enough >> to support AD trust agents >> (entries_m, truncated) = smb.admin_conn.find_entries( >> - >> filter="(&(objectclass=ipaSupportedDomainLevelConfig)(!(ipaMaxDomainLevel=0)))", >> >> + >> filter="(&(objectclass=ipaSupportedDomainLevelConfig)(ipaMaxDomainLevel=*)(ipaMinDomainLevel=*))", >> >> base_dn=masters_dn, attrs_list=['cn'], >> scope=ldap.SCOPE_ONELEVEL) >> except errors.NotFound: >> pass > > ACK. I tested a manual version of this patch in the morning. > Pushed to: master: 1fc21e980bb901bf71f7ee024cdbb15c1caec3a7 ipa-4-2: ef192fb17be348c526029e8fa5165b9108e1f6da -- Jan Cholasta From mbasti at redhat.com Tue Aug 11 15:26:59 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Aug 2015 17:26:59 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fix default CA ACL added during upgrade In-Reply-To: <55C48C2B.6000506@redhat.com> References: <20150807080416.GC4843@dhcp-40-8.bne.redhat.com> <55C47ECD.6050902@redhat.com> <20150807104333.GF4843@dhcp-40-8.bne.redhat.com> <55C48C2B.6000506@redhat.com> Message-ID: <55CA1443.3060908@redhat.com> On 07/08/15 12:44, Martin Babinsky wrote: > On 08/07/2015 12:43 PM, Fraser Tweedale wrote: >> On Fri, Aug 07, 2015 at 11:47:57AM +0200, Martin Babinsky wrote: >>> On 08/07/2015 10:04 AM, Fraser Tweedale wrote: >>>> The attached patch fixes >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1251225 >>>> >>>> Thanks, >>>> Fraser >>>> >>>> >>>> >>> ACK but please put a link to the upstream ticket into the commit >>> message >>> (https://fedorahosted.org/freeipa/ticket/5185) >>> >> Thanks; updated patch attached. >> >>> -- >>> Martin^3 Babinsky > > definitive unconditional ACK from me :). > Pushed to: master: 9bbc798741c2872eaa6cc29d92c8b90104d65ee8 ipa-4-2: 8685c0d7b2463d0eef05ff351137afcc291621ec -- Martin Basti From mbasti at redhat.com Tue Aug 11 15:32:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 11 Aug 2015 17:32:56 +0200 Subject: [Freeipa-devel] [PATCH] 0036 Fix KRB5PrincipalName / UPN SAN comparison In-Reply-To: <55C9F946.4040606@redhat.com> References: <20150809100347.GH4843@dhcp-40-8.bne.redhat.com> <20150811132336.GM16439@dhcp-40-8.bne.redhat.com> <55C9F946.4040606@redhat.com> Message-ID: <55CA15A8.9020409@redhat.com> On 11/08/15 15:31, Martin Babinsky wrote: > On 08/11/2015 03:23 PM, Fraser Tweedale wrote: >> On Sun, Aug 09, 2015 at 08:03:47PM +1000, Fraser Tweedale wrote: >>> The attached patch fixes a bug in KRB5PrincipalName / UPN SAN >>> validation. >>> >>> Thanks, >>> Fraser >> >> For testing this, the following `openssl req' config will serve as a >> starting point; customise the names / realm as appropriate. >> >> [ req ] >> prompt = no >> encrypt_key = no >> >> distinguished_name = dn >> req_extensions = exts >> >> [ dn ] >> commonName = "alice" >> >> [ exts ] >> subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:krb5principal >> >> [ krb5principal ] >> realm = EXPLICIT:0,GeneralString:IPA.LOCAL >> principalname = EXPLICIT:1,SEQUENCE:principalname >> >> [ principalname ] >> nametype = EXPLICIT:0,INT:0 >> namestring = EXPLICIT:1,SEQUENCE:namestring >> >> [ namestring ] >> part1 = GeneralString:alice >> > > Thank for help, I'm ASN.1 n00b. > > ACK. > Pushed to: master: ba7e5df19433faddc1369a26824e7fc6efd7f983 ipa-4-2: 58cf1cd65fc1e8d02a8b5f43fd5157786e232486 -- Martin Basti From pvoborni at redhat.com Tue Aug 11 16:35:56 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 11 Aug 2015 18:35:56 +0200 Subject: [Freeipa-devel] Time-Based Account Policies In-Reply-To: <20150803143028.GF31709@redhat.com> References: <55BF2C6B.3070205@redhat.com> <20150803094534.GB31709@redhat.com> <55BF76D9.4060200@redhat.com> <20150803143028.GF31709@redhat.com> Message-ID: <55CA246C.3000006@redhat.com> On 08/03/2015 04:30 PM, Alexander Bokovoy wrote: > On Mon, 03 Aug 2015, Stanislav Laznicka wrote: > >>>> 3. The mockups for HBAC time policies show quite a wizard-like UI. >>>> While I might be very wrong here, I was thinking of rather a simple >>>> UI where user would be able to set the values for each of the rule >>>> keywords (timeofday, dayofweek, ...) directly in some text input >>>> fields with possible help of JavaScript, that would add text >>>> description to the user input (e.g. "Monday to Friday" with user >>>> input "1-5" at the dayofweek input field). >>> With JavaScript support your wizard-like approach would still work >>> within the same page -- instead of moving 'next', you would need to >>> modify a number of available input fields based on selected items. >>> That's possible and I don't see much of trouble with it. >>> >>>> 4. Do we want some special settings for "absolute" time policies >>>> (policies that start and end at certain time in year)? The issue now >>>> would be that some of such rules would have to be broken down in >>>> more than one time rule (e.g. rule starting at a certain time of a >>>> day in a month in one year and ending at a certain time, day and >>>> month of a different year might get broken down to up to 6 rules if >>>> I count right). This could actually be solved by a UI wizard-like >>>> setting where the user gets to pick the dates and times of the rule, >>>> a conversion method would need to be created and such a thing would >>>> then work for the CLI, too. Still, usually more than one time rule >>>> would be created for such cases. >>> Same here. >>> >> I might not have expressed myself clearly there, for which I am sorry. >> I was rather thinking that instead of different 'screens' for >> different time scenarios, like "Yearly", "Daily", etc., user should be >> able to set all the values in one UI pop-up screen directly as number >> values in text fields (with the exception of "absolute" time policies, >> perhaps). While the user experience may suffer a bit, to me it seems >> more clear, readable and flexible than to have some elements such as >> checkboxes and selects take care of that (although the values around >> the "interval" from iCalendar discussed here earlier would probably >> need just that). Hopefully, I made myself clearer here :) > If you are able to structure types of scenarios clearly, use accordion > pattern to present them at the top level, like here: > https://www.patternfly.org/widgets/#accordion (we are using PatternFly > in our UI). Do per-scenario options in each panel as needed. > Better to ask UX developer for an opinion ;) (Kyle CCd) -- Petr Vobornik From jcholast at redhat.com Wed Aug 12 05:52:56 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 12 Aug 2015 07:52:56 +0200 Subject: [Freeipa-devel] [PATCH 470] install: Fix server and replica install options Message-ID: <55CADF38.2070106@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-470-install-Fix-server-and-replica-install-options.patch Type: text/x-patch Size: 7684 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 12 10:22:23 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 12 Aug 2015 12:22:23 +0200 Subject: [Freeipa-devel] [PATCH 471] ULC: Prevent preserved users from being assigned membership Message-ID: <55CB1E5F.7030407@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-471-ULC-Prevent-preserved-users-from-being-assigned-memb.patch Type: text/x-patch Size: 5958 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 12 10:35:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Aug 2015 12:35:16 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55C9B4E3.8050007@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> Message-ID: <55CB2164.8020203@redhat.com> On 08/11/2015 10:40 AM, thierry bordaz wrote: > On 08/11/2015 09:32 AM, Martin Basti wrote: >> On 11/08/15 09:17, Jan Cholasta wrote: >>> On 5.8.2015 12:34, thierry bordaz wrote: >>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "thierry bordaz" >>>>>>> To: "Jan Cholasta" >>>>>>> Cc: freeipa-devel at redhat.com >>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete >>>>>>> with >>>>>>> user-undel --to-staged >>>>>>> >>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>> >>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>> >>>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>>> prompted to >>>>>>>>>>>> write name and surname. >>>>>>>>>>>> >>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>> ------------------------ >>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>> ------------------------ >>>>>>>>>>>> >>>>>>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>> I would like to ask how to fix this issue, IMO this will be >>>>>>>>>>>> huge >>>>>>>>>>>> hack >>>>>>>>>>>> in internal API. Or should we just document this bug as known >>>>>>>>>>>> issue >>>>>>>>>>>> (thierry wrote that this is not use case that should be used >>>>>>>>>>>> often)? >>>>>>>>>>>> >>>>>>>>>>>> The best solution would be separate command, but this idea was >>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>>>>>>> regarding the design" >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Martin^2 >>>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> as was mentioned before, we have issue with current internal >>>>>>>>>>> API >>>>>>>>>>> and the >>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>> >>>>>>>>>>> We discussed this today, and we did not find a nice way how >>>>>>>>>>> to fix >>>>>>>>>>> it, >>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>> >>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>>> * create new option for user-undel: used-undel --to-staged (or >>>>>>>>>>> create >>>>>>>>>>> new command) that will handle moving deleted users to staged >>>>>>>>>>> area as >>>>>>>>>>> --from-delete did. >>>>>>>>>> Make it new command please. >>>>>>>>>> >>>>>>>>>>> Instead of stageuser-add and option --from-delete, which work >>>>>>>>>>> totally >>>>>>>>>>> different, the command user-undel does similar operation than >>>>>>>>>>> stage-user >>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>> because it >>>>>>>>>> does >>>>>>>>>> something similar. >>>>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>>>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>>>>> preserved >>>>>>>>> to staged. The action is similar, but has slightly different >>>>>>>>> specifics >>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>> 'stageuser-undel' >>>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>>> basically >>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>> user, not >>>>>>>>> 'user-add --to-staged'. It would be in the same style as all the >>>>>>>>> other >>>>>>>>> commands concerning operations with users in staged container. >>>>>>>> Well, user-undel is the opposite of user-del, and stageuser-undel >>>>>>>> should be the opposite of stageuser-del. The stageuser-undel >>>>>>>> you are >>>>>>>> suggesting is not. >>>>>>>> >>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>> user once >>>>>>>> a staged user is created from it, but -undel behaves like that. >>>>>>>> >>>>>>>> I don't think the command should be limited to deleted users only. >>>>>>>> Active and deleted users share the same namespace, so it is an >>>>>>>> arbitrary limitation. >>>>>>> preserved users has been valid active user. In that sense >>>>>>> active/preserved are managed by a same set of CLI >>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>> 'user'. So >>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>> 'user-undel >>>>>>> --to-stage'. >>>>>>> >>>>>>> But then if we will make any incompatible change between >>>>>>> "user-undel" >>>>>>> and "user-undel --to-stage" we may hit this issue again. I agree >>>>>>> with >>>>>>> Honza, this should be a separate command. >>>>>> What do you mean 'incompatible change' ? >>>>>> >>>>>> --to-stage option would only select a different container that the >>>>>> 'Active' one ? >>>>> >>>>> That's not sufficient. The command should do the reverse of >>>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>>> modifications of the entry between them, not MODRDN like >>>>> user-undel does. >>>>> >>>> That is a good point. Do we need to modify anything from a deleted >>>> entry >>>> to a add it in the stage container. >>>> Already delete entry have been purged of several values (password, krb >>>> keys, membership,..) do you think of other attributes to remove ? >>>> >>>> IIRC the use case is a support engineer who activated too early an >>>> entry. So you are right he wants to unactivate it. A question is does >>>> the unactivation requires more modifications than the one did by >>>> 'user-del --preserve'. Note that we can not retrieve the attribute >>>> values when the entry was activated from stage. >>> >>> I don't know if any modifications are needed ATM (doesn't mean there >>> can't be any in the future), but the point is that if you are >>> creating object A from object B using operation X, you should be >>> creating object B from object A using the reverse of operation X, >>> otherwise there *will* be inconsistencies, and we don't want that. >>> >> +1 >> I agree with this >> > So my understanding is that you think a new verb should be created to > allow: 'Active' -> 'Stage' > I do not recall why this was not discussed or if it as already been > rejected. > > I like the idea and I think it could be useful to Support Engineer. > Now I am not sure we want to make 'easy' the action to 'unactivate' a > user (currently it requires two operations). > In your opinion, does it replace 'stageuser-add --from-delete' or > 'user-undel --to-stage' ? or is it an additional subcommand. > Also, activate/unactivate is not a NULL operation. Some values has > been changed (uid,gid,uniqueuiid...) and some values will be lost > (membership). > > About the verb, this is not because the previous action is 'activate' > that we should use 'unactivate'. For example, Thomas raised the point > that after 'user-del', 'user-restore' would have been more user > friendly than 'user-undel' > > Thanks > thierry > We had discussion off-list discussion, and result is following proposal: * remove 'stageuser-add --from-delete' * add new command: 'user-stage' the user-stage command will move both deleted or active users to staged area. $ user-stage replaces the stage-user --from-delete, keeps the same behavior $ user-stage this is stretch goal, nice to have, but I don't know how easy is to implement this For better visualization, here is link to our board screen https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg Thierry, do you agree with this? Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Wed Aug 12 10:45:47 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 12 Aug 2015 12:45:47 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55CB2164.8020203@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> <55CB2164.8020203@redhat.com> Message-ID: <55CB23DB.9010306@redhat.com> On 08/12/2015 12:35 PM, Martin Basti wrote: > > > On 08/11/2015 10:40 AM, thierry bordaz wrote: >> On 08/11/2015 09:32 AM, Martin Basti wrote: >>> On 11/08/15 09:17, Jan Cholasta wrote: >>>> On 5.8.2015 12:34, thierry bordaz wrote: >>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "thierry bordaz" >>>>>>>> To: "Jan Cholasta" >>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add >>>>>>>> --from-delete with >>>>>>>> user-undel --to-staged >>>>>>>> >>>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>>> >>>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>>> >>>>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>>>> prompted to >>>>>>>>>>>>> write name and surname. >>>>>>>>>>>>> >>>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>> >>>>>>>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>>> I would like to ask how to fix this issue, IMO this will >>>>>>>>>>>>> be huge >>>>>>>>>>>>> hack >>>>>>>>>>>>> in internal API. Or should we just document this bug as known >>>>>>>>>>>>> issue >>>>>>>>>>>>> (thierry wrote that this is not use case that should be used >>>>>>>>>>>>> often)? >>>>>>>>>>>>> >>>>>>>>>>>>> The best solution would be separate command, but this idea >>>>>>>>>>>>> was >>>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>>>>>>>> regarding the design" >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> as was mentioned before, we have issue with current >>>>>>>>>>>> internal API >>>>>>>>>>>> and the >>>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>>> >>>>>>>>>>>> We discussed this today, and we did not find a nice way how >>>>>>>>>>>> to fix >>>>>>>>>>>> it, >>>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>>> >>>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>>> * create new option for user-undel: used-undel --to-staged >>>>>>>>>>>> (or >>>>>>>>>>>> create >>>>>>>>>>>> new command) that will handle moving deleted users to staged >>>>>>>>>>>> area as >>>>>>>>>>>> --from-delete did. >>>>>>>>>>> Make it new command please. >>>>>>>>>>> >>>>>>>>>>>> Instead of stageuser-add and option --from-delete, which work >>>>>>>>>>>> totally >>>>>>>>>>>> different, the command user-undel does similar operation than >>>>>>>>>>>> stage-user >>>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>>> because it >>>>>>>>>>> does >>>>>>>>>>> something similar. >>>>>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>>>>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>>>>>> preserved >>>>>>>>>> to staged. The action is similar, but has slightly different >>>>>>>>>> specifics >>>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>>> 'stageuser-undel' >>>>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>>>> basically >>>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>>> user, not >>>>>>>>>> 'user-add --to-staged'. It would be in the same style as all the >>>>>>>>>> other >>>>>>>>>> commands concerning operations with users in staged container. >>>>>>>>> Well, user-undel is the opposite of user-del, and stageuser-undel >>>>>>>>> should be the opposite of stageuser-del. The stageuser-undel >>>>>>>>> you are >>>>>>>>> suggesting is not. >>>>>>>>> >>>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>>> user once >>>>>>>>> a staged user is created from it, but -undel behaves like that. >>>>>>>>> >>>>>>>>> I don't think the command should be limited to deleted users >>>>>>>>> only. >>>>>>>>> Active and deleted users share the same namespace, so it is an >>>>>>>>> arbitrary limitation. >>>>>>>> preserved users has been valid active user. In that sense >>>>>>>> active/preserved are managed by a same set of CLI >>>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>>> 'user'. So >>>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>>> 'user-undel >>>>>>>> --to-stage'. >>>>>>>> >>>>>>>> But then if we will make any incompatible change between >>>>>>>> "user-undel" >>>>>>>> and "user-undel --to-stage" we may hit this issue again. I >>>>>>>> agree with >>>>>>>> Honza, this should be a separate command. >>>>>>> What do you mean 'incompatible change' ? >>>>>>> >>>>>>> --to-stage option would only select a different container that the >>>>>>> 'Active' one ? >>>>>> >>>>>> That's not sufficient. The command should do the reverse of >>>>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>>>> modifications of the entry between them, not MODRDN like >>>>>> user-undel does. >>>>>> >>>>> That is a good point. Do we need to modify anything from a deleted >>>>> entry >>>>> to a add it in the stage container. >>>>> Already delete entry have been purged of several values (password, >>>>> krb >>>>> keys, membership,..) do you think of other attributes to remove ? >>>>> >>>>> IIRC the use case is a support engineer who activated too early an >>>>> entry. So you are right he wants to unactivate it. A question is does >>>>> the unactivation requires more modifications than the one did by >>>>> 'user-del --preserve'. Note that we can not retrieve the attribute >>>>> values when the entry was activated from stage. >>>> >>>> I don't know if any modifications are needed ATM (doesn't mean >>>> there can't be any in the future), but the point is that if you are >>>> creating object A from object B using operation X, you should be >>>> creating object B from object A using the reverse of operation X, >>>> otherwise there *will* be inconsistencies, and we don't want that. >>>> >>> +1 >>> I agree with this >>> >> So my understanding is that you think a new verb should be created to >> allow: 'Active' -> 'Stage' >> I do not recall why this was not discussed or if it as already been >> rejected. >> >> I like the idea and I think it could be useful to Support Engineer. >> Now I am not sure we want to make 'easy' the action to 'unactivate' a >> user (currently it requires two operations). >> In your opinion, does it replace 'stageuser-add --from-delete' or >> 'user-undel --to-stage' ? or is it an additional subcommand. >> Also, activate/unactivate is not a NULL operation. Some values has >> been changed (uid,gid,uniqueuiid...) and some values will be lost >> (membership). >> >> About the verb, this is not because the previous action is 'activate' >> that we should use 'unactivate'. For example, Thomas raised the point >> that after 'user-del', 'user-restore' would have been more user >> friendly than 'user-undel' >> >> Thanks >> thierry >> > We had discussion off-list discussion, and result is following proposal: > > * remove 'stageuser-add --from-delete' > * add new command: 'user-stage' > > the user-stage command will move both deleted or active users to > staged area. > $ user-stage > replaces the stage-user --from-delete, keeps the same behavior > > $ user-stage > this is stretch goal, nice to have, but I don't know how easy is to > implement this > > For better visualization, here is link to our board screen > https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg > > Thierry, do you agree with this? > Martin^2 Hello, I really like the idea (as well as the drawing) of having the same cli for both active/deleted user. About the exact verb 'user-stage', I am always bad at this exercise and it would be great to have Thomas ack on that. Just a question about the other verbs user-disable/user-enable. I know they are doing something different but do you think there is a risk of confusion for admin when he should do user-stage or user-disable ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Aug 12 10:59:38 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 12 Aug 2015 12:59:38 +0200 Subject: [Freeipa-devel] [PATCH] 908 adjust search so that it works for non-admin users Message-ID: <55CB271A.1060909@redhat.com> Non-admin user can now search for: - hosts - hostgroups - netgroups - servers - services (Fixes ACI issue where search returns nothing when user does't have read rights for an attribute in search_attributes. https://fedorahosted.org/freeipa/ticket/5167 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0908-adjust-search-so-that-it-works-for-non-admin-users.patch Type: text/x-patch Size: 4105 bytes Desc: not available URL: From pvoborni at redhat.com Wed Aug 12 11:00:23 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 12 Aug 2015 13:00:23 +0200 Subject: [Freeipa-devel] [PATCH] 909 validate mutually exclusive options in vault-add Message-ID: <55CB2747.5040100@redhat.com> https://fedorahosted.org/freeipa/ticket/5195 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0909-validate-mutually-exclusive-options-in-vault-add.patch Type: text/x-patch Size: 1322 bytes Desc: not available URL: From mkubik at redhat.com Wed Aug 12 11:10:50 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 12 Aug 2015 13:10:50 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55C8B81C.9000900@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> Message-ID: <55CB29BA.7050200@redhat.com> On 08/10/2015 04:41 PM, Jan Cholasta wrote: > Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: [Freeipa-devel] Unable to install bits from ipa-4-2 >> branch >> Date: Mon, 10 Aug 2015 15:55:35 +0200 >> From: Jan Cholasta >> To: Milan Kub?k >> CC: Martin Kosek >> >> >> >> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>> Hi list, >>>>>>>> >>>>>>>> I just noticed that the bits built from ipa-4-2 branch cannot be >>>>>>>> installed. >>>>>>>> The freeipa packages built have version such as >>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The version check in the spec file makes the server-dns package >>>>>>>> obsolete the >>>>>>>> server package from tha same build. >>>>>>>> The cause is the commit [1]. This issue blocks us from running >>>>>>>> tests >>>>>>>> on ipa-4-2 >>>>>>>> branch. >>>>>>>> >>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>> >>>>>>>> [1]: >>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Milan >>>>>>>> >>>>>>> Why does the spec calls for >>>>>>> >>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>> >>>>>>> and not for >>>>>>> >>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>> >>>>>>> ? Is that the root cause of these issues? >>>>>> >>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>> >>>>> I wonder how it could break the upgrade... >>>>> >>>> >>>> Patch attached. >>>> >>> This won't help as long as we build something like >>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >> >> Right. Updated patch attached. It will break updates from pre-server-dns >> git builds, but install should be fine. >> >> -- >> Jan Cholasta >> >> >> ACK, thanks. > > Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from the > freeipa-4.2 COPR. > > Updated patch attached. > Hi, thanks for the patch. It works as far as updating from 4.1, the copr build (correctly replaces freeipa-server package) as well as upgrade from earlier build from repository. If there are no objections, ACK from me. Milan From dkupka at redhat.com Wed Aug 12 11:15:42 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 12 Aug 2015 13:15:42 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55CB23DB.9010306@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> <55CB2164.8020203@redhat.com> <55CB23DB.9010306@redhat.com> Message-ID: <55CB2ADE.7090309@redhat.com> On 12/08/15 12:45, thierry bordaz wrote: > On 08/12/2015 12:35 PM, Martin Basti wrote: >> >> >> On 08/11/2015 10:40 AM, thierry bordaz wrote: >>> On 08/11/2015 09:32 AM, Martin Basti wrote: >>>> On 11/08/15 09:17, Jan Cholasta wrote: >>>>> On 5.8.2015 12:34, thierry bordaz wrote: >>>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: "thierry bordaz" >>>>>>>>> To: "Jan Cholasta" >>>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add >>>>>>>>> --from-delete with >>>>>>>>> user-undel --to-staged >>>>>>>>> >>>>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>>>> >>>>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>>>>> prompted to >>>>>>>>>>>>>> write name and surname. >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>>>> I would like to ask how to fix this issue, IMO this will >>>>>>>>>>>>>> be huge >>>>>>>>>>>>>> hack >>>>>>>>>>>>>> in internal API. Or should we just document this bug as known >>>>>>>>>>>>>> issue >>>>>>>>>>>>>> (thierry wrote that this is not use case that should be used >>>>>>>>>>>>>> often)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The best solution would be separate command, but this idea >>>>>>>>>>>>>> was >>>>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: question >>>>>>>>>>>>>> regarding the design" >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> as was mentioned before, we have issue with current >>>>>>>>>>>>> internal API >>>>>>>>>>>>> and the >>>>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>>>> >>>>>>>>>>>>> We discussed this today, and we did not find a nice way how >>>>>>>>>>>>> to fix >>>>>>>>>>>>> it, >>>>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>>>> >>>>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>>>> * create new option for user-undel: used-undel --to-staged (or >>>>>>>>>>>>> create >>>>>>>>>>>>> new command) that will handle moving deleted users to staged >>>>>>>>>>>>> area as >>>>>>>>>>>>> --from-delete did. >>>>>>>>>>>> Make it new command please. >>>>>>>>>>>> >>>>>>>>>>>>> Instead of stageuser-add and option --from-delete, which work >>>>>>>>>>>>> totally >>>>>>>>>>>>> different, the command user-undel does similar operation than >>>>>>>>>>>>> stage-user >>>>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>>>> because it >>>>>>>>>>>> does >>>>>>>>>>>> something similar. >>>>>>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' moves >>>>>>>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>>>>>>> preserved >>>>>>>>>>> to staged. The action is similar, but has slightly different >>>>>>>>>>> specifics >>>>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>>>> 'stageuser-undel' >>>>>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>>>>> basically >>>>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>>>> user, not >>>>>>>>>>> 'user-add --to-staged'. It would be in the same style as all the >>>>>>>>>>> other >>>>>>>>>>> commands concerning operations with users in staged container. >>>>>>>>>> Well, user-undel is the opposite of user-del, and stageuser-undel >>>>>>>>>> should be the opposite of stageuser-del. The stageuser-undel >>>>>>>>>> you are >>>>>>>>>> suggesting is not. >>>>>>>>>> >>>>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>>>> user once >>>>>>>>>> a staged user is created from it, but -undel behaves like that. >>>>>>>>>> >>>>>>>>>> I don't think the command should be limited to deleted users >>>>>>>>>> only. >>>>>>>>>> Active and deleted users share the same namespace, so it is an >>>>>>>>>> arbitrary limitation. >>>>>>>>> preserved users has been valid active user. In that sense >>>>>>>>> active/preserved are managed by a same set of CLI >>>>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>>>> 'user'. So >>>>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>>>> 'user-undel >>>>>>>>> --to-stage'. >>>>>>>>> >>>>>>>>> But then if we will make any incompatible change between >>>>>>>>> "user-undel" >>>>>>>>> and "user-undel --to-stage" we may hit this issue again. I >>>>>>>>> agree with >>>>>>>>> Honza, this should be a separate command. >>>>>>>> What do you mean 'incompatible change' ? >>>>>>>> >>>>>>>> --to-stage option would only select a different container that the >>>>>>>> 'Active' one ? >>>>>>> >>>>>>> That's not sufficient. The command should do the reverse of >>>>>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>>>>> modifications of the entry between them, not MODRDN like >>>>>>> user-undel does. >>>>>>> >>>>>> That is a good point. Do we need to modify anything from a deleted >>>>>> entry >>>>>> to a add it in the stage container. >>>>>> Already delete entry have been purged of several values (password, >>>>>> krb >>>>>> keys, membership,..) do you think of other attributes to remove ? >>>>>> >>>>>> IIRC the use case is a support engineer who activated too early an >>>>>> entry. So you are right he wants to unactivate it. A question is does >>>>>> the unactivation requires more modifications than the one did by >>>>>> 'user-del --preserve'. Note that we can not retrieve the attribute >>>>>> values when the entry was activated from stage. >>>>> >>>>> I don't know if any modifications are needed ATM (doesn't mean >>>>> there can't be any in the future), but the point is that if you are >>>>> creating object A from object B using operation X, you should be >>>>> creating object B from object A using the reverse of operation X, >>>>> otherwise there *will* be inconsistencies, and we don't want that. >>>>> >>>> +1 >>>> I agree with this >>>> >>> So my understanding is that you think a new verb should be created to >>> allow: 'Active' -> 'Stage' >>> I do not recall why this was not discussed or if it as already been >>> rejected. >>> >>> I like the idea and I think it could be useful to Support Engineer. >>> Now I am not sure we want to make 'easy' the action to 'unactivate' a >>> user (currently it requires two operations). >>> In your opinion, does it replace 'stageuser-add --from-delete' or >>> 'user-undel --to-stage' ? or is it an additional subcommand. >>> Also, activate/unactivate is not a NULL operation. Some values has >>> been changed (uid,gid,uniqueuiid...) and some values will be lost >>> (membership). >>> >>> About the verb, this is not because the previous action is 'activate' >>> that we should use 'unactivate'. For example, Thomas raised the point >>> that after 'user-del', 'user-restore' would have been more user >>> friendly than 'user-undel' >>> >>> Thanks >>> thierry >>> >> We had discussion off-list discussion, and result is following proposal: >> >> * remove 'stageuser-add --from-delete' >> * add new command: 'user-stage' >> >> the user-stage command will move both deleted or active users to >> staged area. >> $ user-stage >> replaces the stage-user --from-delete, keeps the same behavior >> >> $ user-stage >> this is stretch goal, nice to have, but I don't know how easy is to >> implement this >> >> For better visualization, here is link to our board screen >> https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg >> >> Thierry, do you agree with this? >> Martin^2 > > > Hello, > > I really like the idea (as well as the drawing) of having the same cli > for both active/deleted user. > About the exact verb 'user-stage', I am always bad at this exercise and > it would be great to have Thomas ack on that. > > Just a question about the other verbs user-disable/user-enable. I know > they are doing something different but do you think there is a risk of > confusion for admin when he should do user-stage or user-disable ? > > thanks > thierry > > > Adding Tomas to the loop. -- David Kupka From tcapek at redhat.com Wed Aug 12 12:08:59 2015 From: tcapek at redhat.com (Tomas Capek) Date: Wed, 12 Aug 2015 14:08:59 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55CB2ADE.7090309@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> <55CB2164.8020203@redhat.com> <55CB23DB.9010306@redhat.com> <55CB2ADE.7090309@redhat.com> Message-ID: <55CB375B.6080209@redhat.com> On 12/08/15 13:15, David Kupka wrote: > On 12/08/15 12:45, thierry bordaz wrote: >> On 08/12/2015 12:35 PM, Martin Basti wrote: >>> >>> >>> On 08/11/2015 10:40 AM, thierry bordaz wrote: >>>> On 08/11/2015 09:32 AM, Martin Basti wrote: >>>>> On 11/08/15 09:17, Jan Cholasta wrote: >>>>>> On 5.8.2015 12:34, thierry bordaz wrote: >>>>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "thierry bordaz" >>>>>>>>>> To: "Jan Cholasta" >>>>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add >>>>>>>>>> --from-delete with >>>>>>>>>> user-undel --to-staged >>>>>>>>>> >>>>>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>>>>> >>>>>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>>>>>> prompted to >>>>>>>>>>>>>>> write name and surname. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As the first name and last name are mandatory attributes of >>>>>>>>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>>>>> I would like to ask how to fix this issue, IMO this will >>>>>>>>>>>>>>> be huge >>>>>>>>>>>>>>> hack >>>>>>>>>>>>>>> in internal API. Or should we just document this bug as >>>>>>>>>>>>>>> known >>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>> (thierry wrote that this is not use case that should be >>>>>>>>>>>>>>> used >>>>>>>>>>>>>>> often)? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The best solution would be separate command, but this idea >>>>>>>>>>>>>>> was >>>>>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: >>>>>>>>>>>>>>> question >>>>>>>>>>>>>>> regarding the design" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> as was mentioned before, we have issue with current >>>>>>>>>>>>>> internal API >>>>>>>>>>>>>> and the >>>>>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We discussed this today, and we did not find a nice way how >>>>>>>>>>>>>> to fix >>>>>>>>>>>>>> it, >>>>>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>>>>> >>>>>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>>>>> +1 >>>>>>>>>>>>> >>>>>>>>>>>>>> * create new option for user-undel: used-undel >>>>>>>>>>>>>> --to-staged (or >>>>>>>>>>>>>> create >>>>>>>>>>>>>> new command) that will handle moving deleted users to staged >>>>>>>>>>>>>> area as >>>>>>>>>>>>>> --from-delete did. >>>>>>>>>>>>> Make it new command please. >>>>>>>>>>>>> >>>>>>>>>>>>>> Instead of stageuser-add and option --from-delete, which >>>>>>>>>>>>>> work >>>>>>>>>>>>>> totally >>>>>>>>>>>>>> different, the command user-undel does similar operation >>>>>>>>>>>>>> than >>>>>>>>>>>>>> stage-user >>>>>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>>>>> because it >>>>>>>>>>>>> does >>>>>>>>>>>>> something similar. >>>>>>>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' >>>>>>>>>>>> moves >>>>>>>>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>>>>>>>> preserved >>>>>>>>>>>> to staged. The action is similar, but has slightly different >>>>>>>>>>>> specifics >>>>>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>>>>> 'stageuser-undel' >>>>>>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>>>>>> basically >>>>>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>>>>> user, not >>>>>>>>>>>> 'user-add --to-staged'. It would be in the same style as >>>>>>>>>>>> all the >>>>>>>>>>>> other >>>>>>>>>>>> commands concerning operations with users in staged container. >>>>>>>>>>> Well, user-undel is the opposite of user-del, and >>>>>>>>>>> stageuser-undel >>>>>>>>>>> should be the opposite of stageuser-del. The stageuser-undel >>>>>>>>>>> you are >>>>>>>>>>> suggesting is not. >>>>>>>>>>> >>>>>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>>>>> user once >>>>>>>>>>> a staged user is created from it, but -undel behaves like that. >>>>>>>>>>> >>>>>>>>>>> I don't think the command should be limited to deleted users >>>>>>>>>>> only. >>>>>>>>>>> Active and deleted users share the same namespace, so it is an >>>>>>>>>>> arbitrary limitation. >>>>>>>>>> preserved users has been valid active user. In that sense >>>>>>>>>> active/preserved are managed by a same set of CLI >>>>>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>>>>> 'user'. So >>>>>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>>>>> 'user-undel >>>>>>>>>> --to-stage'. >>>>>>>>>> >>>>>>>>>> But then if we will make any incompatible change between >>>>>>>>>> "user-undel" >>>>>>>>>> and "user-undel --to-stage" we may hit this issue again. I >>>>>>>>>> agree with >>>>>>>>>> Honza, this should be a separate command. >>>>>>>>> What do you mean 'incompatible change' ? >>>>>>>>> >>>>>>>>> --to-stage option would only select a different container that >>>>>>>>> the >>>>>>>>> 'Active' one ? >>>>>>>> >>>>>>>> That's not sufficient. The command should do the reverse of >>>>>>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>>>>>> modifications of the entry between them, not MODRDN like >>>>>>>> user-undel does. >>>>>>>> >>>>>>> That is a good point. Do we need to modify anything from a deleted >>>>>>> entry >>>>>>> to a add it in the stage container. >>>>>>> Already delete entry have been purged of several values (password, >>>>>>> krb >>>>>>> keys, membership,..) do you think of other attributes to remove ? >>>>>>> >>>>>>> IIRC the use case is a support engineer who activated too early an >>>>>>> entry. So you are right he wants to unactivate it. A question is >>>>>>> does >>>>>>> the unactivation requires more modifications than the one did by >>>>>>> 'user-del --preserve'. Note that we can not retrieve the attribute >>>>>>> values when the entry was activated from stage. >>>>>> >>>>>> I don't know if any modifications are needed ATM (doesn't mean >>>>>> there can't be any in the future), but the point is that if you are >>>>>> creating object A from object B using operation X, you should be >>>>>> creating object B from object A using the reverse of operation X, >>>>>> otherwise there *will* be inconsistencies, and we don't want that. >>>>>> >>>>> +1 >>>>> I agree with this >>>>> >>>> So my understanding is that you think a new verb should be created to >>>> allow: 'Active' -> 'Stage' >>>> I do not recall why this was not discussed or if it as already been >>>> rejected. >>>> >>>> I like the idea and I think it could be useful to Support Engineer. >>>> Now I am not sure we want to make 'easy' the action to 'unactivate' a >>>> user (currently it requires two operations). >>>> In your opinion, does it replace 'stageuser-add --from-delete' or >>>> 'user-undel --to-stage' ? or is it an additional subcommand. >>>> Also, activate/unactivate is not a NULL operation. Some values has >>>> been changed (uid,gid,uniqueuiid...) and some values will be lost >>>> (membership). >>>> >>>> About the verb, this is not because the previous action is 'activate' >>>> that we should use 'unactivate'. For example, Thomas raised the point >>>> that after 'user-del', 'user-restore' would have been more user >>>> friendly than 'user-undel' >>>> >>>> Thanks >>>> thierry >>>> >>> We had discussion off-list discussion, and result is following >>> proposal: >>> >>> * remove 'stageuser-add --from-delete' >>> * add new command: 'user-stage' >>> >>> the user-stage command will move both deleted or active users to >>> staged area. >>> $ user-stage >>> replaces the stage-user --from-delete, keeps the same behavior >>> >>> $ user-stage >>> this is stretch goal, nice to have, but I don't know how easy is to >>> implement this >>> >>> For better visualization, here is link to our board screen >>> https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg >>> >>> Thierry, do you agree with this? >>> Martin^2 >> >> >> Hello, >> >> I really like the idea (as well as the drawing) of having the same cli >> for both active/deleted user. >> About the exact verb 'user-stage', I am always bad at this exercise and >> it would be great to have Thomas ack on that. >> >> Just a question about the other verbs user-disable/user-enable. I know >> they are doing something different but do you think there is a risk of >> confusion for admin when he should do user-stage or user-disable ? >> >> thanks >> thierry >> >> >> > > Adding Tomas to the loop. Hello everyone, I probably don't have all the information and perhaps cannot see all possible side effects but on the handover session for this feature, I was concerned that some commands did not match in GUI and in CLI (restore, undel). Also, from the UX perspective, I thought it would be more friendly to have symmetrical commands and not confuse users with two delete modes as in "do you want to mock-delete the user or delete delete it?" Therefore, I proposed to have two simple pairs of commands, also reflected in the UI: "add" and "delete" - for just adding and completely removing users "retire" and "restore" - for just putting a user to or taking it out of the user "archive" as for the "--from-delete" option , I think the proposed "user-stage" overlaps a little with the existing "stageuser-*" commands. As the command would move a user to the initial state of the lifecycle, be it an active or retired user, I'd try to emphasize the fact by proposing a similar but perhaps more cogent "user-restage". Do you think it would work? Tomas -- Tom?? ?apek tcapek at redhat.com IRC Nick: tcapek Team name: Customer Content Services (CCS) From jcholast at redhat.com Wed Aug 12 12:20:32 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 12 Aug 2015 14:20:32 +0200 Subject: [Freeipa-devel] [PATCH 471] ULC: Prevent preserved users from being assigned membership In-Reply-To: <55CB1E5F.7030407@redhat.com> References: <55CB1E5F.7030407@redhat.com> Message-ID: <55CB3A10.901@redhat.com> On 12.8.2015 12:22, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Fixed broken user_show on preserved user. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-471.1-ULC-Prevent-preserved-users-from-being-assigned-memb.patch Type: text/x-patch Size: 6000 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 12 12:22:20 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Aug 2015 14:22:20 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55CB375B.6080209@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> <55CB2164.8020203@redhat.com> <55CB23DB.9010306@redhat.com> <55CB2ADE.7090309@redhat.com> <55CB375B.6080209@redhat.com> Message-ID: <55CB3A7C.3010201@redhat.com> On 08/12/2015 02:08 PM, Tomas Capek wrote: > On 12/08/15 13:15, David Kupka wrote: >> On 12/08/15 12:45, thierry bordaz wrote: >>> On 08/12/2015 12:35 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/11/2015 10:40 AM, thierry bordaz wrote: >>>>> On 08/11/2015 09:32 AM, Martin Basti wrote: >>>>>> On 11/08/15 09:17, Jan Cholasta wrote: >>>>>>> On 5.8.2015 12:34, thierry bordaz wrote: >>>>>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>>>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "thierry bordaz" >>>>>>>>>>> To: "Jan Cholasta" >>>>>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add >>>>>>>>>>> --from-delete with >>>>>>>>>>> user-undel --to-staged >>>>>>>>>>> >>>>>>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>>>>>> >>>>>>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>>>>>>> prompted to >>>>>>>>>>>>>>>> write name and surname. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As the first name and last name are mandatory >>>>>>>>>>>>>>>> attributes of >>>>>>>>>>>>>>>> stageuser-add command, but they are not needed by when the >>>>>>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>>>>>> I would like to ask how to fix this issue, IMO this will >>>>>>>>>>>>>>>> be huge >>>>>>>>>>>>>>>> hack >>>>>>>>>>>>>>>> in internal API. Or should we just document this bug as >>>>>>>>>>>>>>>> known >>>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>>> (thierry wrote that this is not use case that should be >>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>> often)? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The best solution would be separate command, but this idea >>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: >>>>>>>>>>>>>>>> question >>>>>>>>>>>>>>>> regarding the design" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> as was mentioned before, we have issue with current >>>>>>>>>>>>>>> internal API >>>>>>>>>>>>>>> and the >>>>>>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We discussed this today, and we did not find a nice way how >>>>>>>>>>>>>>> to fix >>>>>>>>>>>>>>> it, >>>>>>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>>>>>> +1 >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * create new option for user-undel: used-undel >>>>>>>>>>>>>>> --to-staged (or >>>>>>>>>>>>>>> create >>>>>>>>>>>>>>> new command) that will handle moving deleted users to >>>>>>>>>>>>>>> staged >>>>>>>>>>>>>>> area as >>>>>>>>>>>>>>> --from-delete did. >>>>>>>>>>>>>> Make it new command please. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Instead of stageuser-add and option --from-delete, which >>>>>>>>>>>>>>> work >>>>>>>>>>>>>>> totally >>>>>>>>>>>>>>> different, the command user-undel does similar operation >>>>>>>>>>>>>>> than >>>>>>>>>>>>>>> stage-user >>>>>>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>>>>>> because it >>>>>>>>>>>>>> does >>>>>>>>>>>>>> something similar. >>>>>>>>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' >>>>>>>>>>>>> moves >>>>>>>>>>>>> preserved user to active, so the 'stageuser-undel' would move >>>>>>>>>>>>> preserved >>>>>>>>>>>>> to staged. The action is similar, but has slightly different >>>>>>>>>>>>> specifics >>>>>>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>>>>>> 'stageuser-undel' >>>>>>>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>>>>>>> basically >>>>>>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>>>>>> user, not >>>>>>>>>>>>> 'user-add --to-staged'. It would be in the same style as >>>>>>>>>>>>> all the >>>>>>>>>>>>> other >>>>>>>>>>>>> commands concerning operations with users in staged >>>>>>>>>>>>> container. >>>>>>>>>>>> Well, user-undel is the opposite of user-del, and >>>>>>>>>>>> stageuser-undel >>>>>>>>>>>> should be the opposite of stageuser-del. The stageuser-undel >>>>>>>>>>>> you are >>>>>>>>>>>> suggesting is not. >>>>>>>>>>>> >>>>>>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>>>>>> user once >>>>>>>>>>>> a staged user is created from it, but -undel behaves like >>>>>>>>>>>> that. >>>>>>>>>>>> >>>>>>>>>>>> I don't think the command should be limited to deleted users >>>>>>>>>>>> only. >>>>>>>>>>>> Active and deleted users share the same namespace, so it is an >>>>>>>>>>>> arbitrary limitation. >>>>>>>>>>> preserved users has been valid active user. In that sense >>>>>>>>>>> active/preserved are managed by a same set of CLI >>>>>>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>>>>>> 'user'. So >>>>>>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>>>>>> 'user-undel >>>>>>>>>>> --to-stage'. >>>>>>>>>>> >>>>>>>>>>> But then if we will make any incompatible change between >>>>>>>>>>> "user-undel" >>>>>>>>>>> and "user-undel --to-stage" we may hit this issue again. I >>>>>>>>>>> agree with >>>>>>>>>>> Honza, this should be a separate command. >>>>>>>>>> What do you mean 'incompatible change' ? >>>>>>>>>> >>>>>>>>>> --to-stage option would only select a different container >>>>>>>>>> that the >>>>>>>>>> 'Active' one ? >>>>>>>>> >>>>>>>>> That's not sufficient. The command should do the reverse of >>>>>>>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>>>>>>> modifications of the entry between them, not MODRDN like >>>>>>>>> user-undel does. >>>>>>>>> >>>>>>>> That is a good point. Do we need to modify anything from a deleted >>>>>>>> entry >>>>>>>> to a add it in the stage container. >>>>>>>> Already delete entry have been purged of several values (password, >>>>>>>> krb >>>>>>>> keys, membership,..) do you think of other attributes to remove ? >>>>>>>> >>>>>>>> IIRC the use case is a support engineer who activated too early an >>>>>>>> entry. So you are right he wants to unactivate it. A question >>>>>>>> is does >>>>>>>> the unactivation requires more modifications than the one did by >>>>>>>> 'user-del --preserve'. Note that we can not retrieve the attribute >>>>>>>> values when the entry was activated from stage. >>>>>>> >>>>>>> I don't know if any modifications are needed ATM (doesn't mean >>>>>>> there can't be any in the future), but the point is that if you are >>>>>>> creating object A from object B using operation X, you should be >>>>>>> creating object B from object A using the reverse of operation X, >>>>>>> otherwise there *will* be inconsistencies, and we don't want that. >>>>>>> >>>>>> +1 >>>>>> I agree with this >>>>>> >>>>> So my understanding is that you think a new verb should be created to >>>>> allow: 'Active' -> 'Stage' >>>>> I do not recall why this was not discussed or if it as already been >>>>> rejected. >>>>> >>>>> I like the idea and I think it could be useful to Support Engineer. >>>>> Now I am not sure we want to make 'easy' the action to 'unactivate' a >>>>> user (currently it requires two operations). >>>>> In your opinion, does it replace 'stageuser-add --from-delete' or >>>>> 'user-undel --to-stage' ? or is it an additional subcommand. >>>>> Also, activate/unactivate is not a NULL operation. Some values has >>>>> been changed (uid,gid,uniqueuiid...) and some values will be lost >>>>> (membership). >>>>> >>>>> About the verb, this is not because the previous action is 'activate' >>>>> that we should use 'unactivate'. For example, Thomas raised the point >>>>> that after 'user-del', 'user-restore' would have been more user >>>>> friendly than 'user-undel' >>>>> >>>>> Thanks >>>>> thierry >>>>> >>>> We had discussion off-list discussion, and result is following >>>> proposal: >>>> >>>> * remove 'stageuser-add --from-delete' >>>> * add new command: 'user-stage' >>>> >>>> the user-stage command will move both deleted or active users to >>>> staged area. >>>> $ user-stage >>>> replaces the stage-user --from-delete, keeps the same behavior >>>> >>>> $ user-stage >>>> this is stretch goal, nice to have, but I don't know how easy is to >>>> implement this >>>> >>>> For better visualization, here is link to our board screen >>>> https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg >>>> >>>> Thierry, do you agree with this? >>>> Martin^2 >>> >>> >>> Hello, >>> >>> I really like the idea (as well as the drawing) of having the same cli >>> for both active/deleted user. >>> About the exact verb 'user-stage', I am always bad at this exercise and >>> it would be great to have Thomas ack on that. >>> >>> Just a question about the other verbs user-disable/user-enable. I know >>> they are doing something different but do you think there is a risk of >>> confusion for admin when he should do user-stage or user-disable ? >>> >>> thanks >>> thierry >>> >>> >>> >> >> Adding Tomas to the loop. > Hello everyone, > > I probably don't have all the information and perhaps cannot see all > possible side effects but on the handover session for this feature, I > was concerned that some commands did not match in GUI and in CLI > (restore, undel). > > Also, from the UX perspective, I thought it would be more friendly to > have symmetrical commands and not confuse users with two delete modes > as in "do you want to mock-delete the user or delete delete it?" > > Therefore, I proposed to have two simple pairs of commands, also > reflected in the UI: > > "add" and "delete" - for just adding and completely removing users > > "retire" and "restore" - for just putting a user to or taking it out > of the user "archive" > Sounds good, but we will not change all commands. > as for the "--from-delete" option , I think the proposed "user-stage" > overlaps a little with the existing "stageuser-*" commands. As the > command would move a user to the initial state of the lifecycle, be it > an active or retired user, I'd try to emphasize the fact by proposing > a similar but perhaps more cogent "user-restage". > > Do you think it would work? How about case, when user was created via 'user-add', then 'user-restage' may confuse users, because that user hasn't been in stage area. Martin^2 > > Tomas > > From tcapek at redhat.com Wed Aug 12 12:47:43 2015 From: tcapek at redhat.com (Tomas Capek) Date: Wed, 12 Aug 2015 14:47:43 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55CB3A7C.3010201@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> <55CB2164.8020203@redhat.com> <55CB23DB.9010306@redhat.com> <55CB2ADE.7090309@redhat.com> <55CB375B.6080209@redhat.com> <55CB3A7C.3010201@redhat.com> Message-ID: <55CB406F.9030501@redhat.com> On 12/08/15 14:22, Martin Basti wrote: > > > On 08/12/2015 02:08 PM, Tomas Capek wrote: >> On 12/08/15 13:15, David Kupka wrote: >>> On 12/08/15 12:45, thierry bordaz wrote: >>>> On 08/12/2015 12:35 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/11/2015 10:40 AM, thierry bordaz wrote: >>>>>> On 08/11/2015 09:32 AM, Martin Basti wrote: >>>>>>> On 11/08/15 09:17, Jan Cholasta wrote: >>>>>>>> On 5.8.2015 12:34, thierry bordaz wrote: >>>>>>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>>>>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>>>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "thierry bordaz" >>>>>>>>>>>> To: "Jan Cholasta" >>>>>>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add >>>>>>>>>>>> --from-delete with >>>>>>>>>>>> user-undel --to-staged >>>>>>>>>>>> >>>>>>>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>>>>>>>> prompted to >>>>>>>>>>>>>>>>> write name and surname. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As the first name and last name are mandatory >>>>>>>>>>>>>>>>> attributes of >>>>>>>>>>>>>>>>> stageuser-add command, but they are not needed by when >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>>>>>>> I would like to ask how to fix this issue, IMO this will >>>>>>>>>>>>>>>>> be huge >>>>>>>>>>>>>>>>> hack >>>>>>>>>>>>>>>>> in internal API. Or should we just document this bug >>>>>>>>>>>>>>>>> as known >>>>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>>>> (thierry wrote that this is not use case that should >>>>>>>>>>>>>>>>> be used >>>>>>>>>>>>>>>>> often)? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The best solution would be separate command, but this >>>>>>>>>>>>>>>>> idea >>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: >>>>>>>>>>>>>>>>> question >>>>>>>>>>>>>>>>> regarding the design" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> as was mentioned before, we have issue with current >>>>>>>>>>>>>>>> internal API >>>>>>>>>>>>>>>> and the >>>>>>>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We discussed this today, and we did not find a nice way >>>>>>>>>>>>>>>> how >>>>>>>>>>>>>>>> to fix >>>>>>>>>>>>>>>> it, >>>>>>>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * create new option for user-undel: used-undel >>>>>>>>>>>>>>>> --to-staged (or >>>>>>>>>>>>>>>> create >>>>>>>>>>>>>>>> new command) that will handle moving deleted users to >>>>>>>>>>>>>>>> staged >>>>>>>>>>>>>>>> area as >>>>>>>>>>>>>>>> --from-delete did. >>>>>>>>>>>>>>> Make it new command please. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Instead of stageuser-add and option --from-delete, >>>>>>>>>>>>>>>> which work >>>>>>>>>>>>>>>> totally >>>>>>>>>>>>>>>> different, the command user-undel does similar >>>>>>>>>>>>>>>> operation than >>>>>>>>>>>>>>>> stage-user >>>>>>>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>>>>>>> because it >>>>>>>>>>>>>>> does >>>>>>>>>>>>>>> something similar. >>>>>>>>>>>>>> How about making it a 'stageuser-undel'? The 'user-undel' >>>>>>>>>>>>>> moves >>>>>>>>>>>>>> preserved user to active, so the 'stageuser-undel' would >>>>>>>>>>>>>> move >>>>>>>>>>>>>> preserved >>>>>>>>>>>>>> to staged. The action is similar, but has slightly different >>>>>>>>>>>>>> specifics >>>>>>>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>>>>>>> 'stageuser-undel' >>>>>>>>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>>>>>>>> basically >>>>>>>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>>>>>>> user, not >>>>>>>>>>>>>> 'user-add --to-staged'. It would be in the same style as >>>>>>>>>>>>>> all the >>>>>>>>>>>>>> other >>>>>>>>>>>>>> commands concerning operations with users in staged >>>>>>>>>>>>>> container. >>>>>>>>>>>>> Well, user-undel is the opposite of user-del, and >>>>>>>>>>>>> stageuser-undel >>>>>>>>>>>>> should be the opposite of stageuser-del. The stageuser-undel >>>>>>>>>>>>> you are >>>>>>>>>>>>> suggesting is not. >>>>>>>>>>>>> >>>>>>>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>>>>>>> user once >>>>>>>>>>>>> a staged user is created from it, but -undel behaves like >>>>>>>>>>>>> that. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think the command should be limited to deleted users >>>>>>>>>>>>> only. >>>>>>>>>>>>> Active and deleted users share the same namespace, so it >>>>>>>>>>>>> is an >>>>>>>>>>>>> arbitrary limitation. >>>>>>>>>>>> preserved users has been valid active user. In that sense >>>>>>>>>>>> active/preserved are managed by a same set of CLI >>>>>>>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>>>>>>> 'user'. So >>>>>>>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>>>>>>> 'user-undel >>>>>>>>>>>> --to-stage'. >>>>>>>>>>>> >>>>>>>>>>>> But then if we will make any incompatible change between >>>>>>>>>>>> "user-undel" >>>>>>>>>>>> and "user-undel --to-stage" we may hit this issue again. I >>>>>>>>>>>> agree with >>>>>>>>>>>> Honza, this should be a separate command. >>>>>>>>>>> What do you mean 'incompatible change' ? >>>>>>>>>>> >>>>>>>>>>> --to-stage option would only select a different container >>>>>>>>>>> that the >>>>>>>>>>> 'Active' one ? >>>>>>>>>> >>>>>>>>>> That's not sufficient. The command should do the reverse of >>>>>>>>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>>>>>>>> modifications of the entry between them, not MODRDN like >>>>>>>>>> user-undel does. >>>>>>>>>> >>>>>>>>> That is a good point. Do we need to modify anything from a >>>>>>>>> deleted >>>>>>>>> entry >>>>>>>>> to a add it in the stage container. >>>>>>>>> Already delete entry have been purged of several values >>>>>>>>> (password, >>>>>>>>> krb >>>>>>>>> keys, membership,..) do you think of other attributes to remove ? >>>>>>>>> >>>>>>>>> IIRC the use case is a support engineer who activated too >>>>>>>>> early an >>>>>>>>> entry. So you are right he wants to unactivate it. A question >>>>>>>>> is does >>>>>>>>> the unactivation requires more modifications than the one did by >>>>>>>>> 'user-del --preserve'. Note that we can not retrieve the >>>>>>>>> attribute >>>>>>>>> values when the entry was activated from stage. >>>>>>>> >>>>>>>> I don't know if any modifications are needed ATM (doesn't mean >>>>>>>> there can't be any in the future), but the point is that if you >>>>>>>> are >>>>>>>> creating object A from object B using operation X, you should be >>>>>>>> creating object B from object A using the reverse of operation X, >>>>>>>> otherwise there *will* be inconsistencies, and we don't want that. >>>>>>>> >>>>>>> +1 >>>>>>> I agree with this >>>>>>> >>>>>> So my understanding is that you think a new verb should be >>>>>> created to >>>>>> allow: 'Active' -> 'Stage' >>>>>> I do not recall why this was not discussed or if it as already been >>>>>> rejected. >>>>>> >>>>>> I like the idea and I think it could be useful to Support Engineer. >>>>>> Now I am not sure we want to make 'easy' the action to >>>>>> 'unactivate' a >>>>>> user (currently it requires two operations). >>>>>> In your opinion, does it replace 'stageuser-add --from-delete' or >>>>>> 'user-undel --to-stage' ? or is it an additional subcommand. >>>>>> Also, activate/unactivate is not a NULL operation. Some values has >>>>>> been changed (uid,gid,uniqueuiid...) and some values will be lost >>>>>> (membership). >>>>>> >>>>>> About the verb, this is not because the previous action is >>>>>> 'activate' >>>>>> that we should use 'unactivate'. For example, Thomas raised the >>>>>> point >>>>>> that after 'user-del', 'user-restore' would have been more user >>>>>> friendly than 'user-undel' >>>>>> >>>>>> Thanks >>>>>> thierry >>>>>> >>>>> We had discussion off-list discussion, and result is following >>>>> proposal: >>>>> >>>>> * remove 'stageuser-add --from-delete' >>>>> * add new command: 'user-stage' >>>>> >>>>> the user-stage command will move both deleted or active users to >>>>> staged area. >>>>> $ user-stage >>>>> replaces the stage-user --from-delete, keeps the same behavior >>>>> >>>>> $ user-stage >>>>> this is stretch goal, nice to have, but I don't know how easy is to >>>>> implement this >>>>> >>>>> For better visualization, here is link to our board screen >>>>> https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg >>>>> >>>>> Thierry, do you agree with this? >>>>> Martin^2 >>>> >>>> >>>> Hello, >>>> >>>> I really like the idea (as well as the drawing) of having the same cli >>>> for both active/deleted user. >>>> About the exact verb 'user-stage', I am always bad at this exercise >>>> and >>>> it would be great to have Thomas ack on that. >>>> >>>> Just a question about the other verbs user-disable/user-enable. I know >>>> they are doing something different but do you think there is a risk of >>>> confusion for admin when he should do user-stage or user-disable ? >>>> >>>> thanks >>>> thierry >>>> >>>> >>>> >>> >>> Adding Tomas to the loop. >> Hello everyone, >> >> I probably don't have all the information and perhaps cannot see >> all possible side effects but on the handover session for this >> feature, I was concerned that some commands did not match in GUI and >> in CLI (restore, undel). >> >> Also, from the UX perspective, I thought it would be more friendly to >> have symmetrical commands and not confuse users with two delete modes >> as in "do you want to mock-delete the user or delete delete it?" >> >> Therefore, I proposed to have two simple pairs of commands, also >> reflected in the UI: >> >> "add" and "delete" - for just adding and completely removing users >> >> "retire" and "restore" - for just putting a user to or taking it out >> of the user "archive" >> > Sounds good, but we will not change all commands. Sure, I made this proposal only for the user lifecycle feature. Perhaps some commands could be aliases if it would make it easier to introduce them... > >> as for the "--from-delete" option , I think the proposed "user-stage" >> overlaps a little with the existing "stageuser-*" commands. As the >> command would move a user to the initial state of the lifecycle, be >> it an active or retired user, I'd try to emphasize the fact by >> proposing a similar but perhaps more cogent "user-restage". >> >> Do you think it would work? > How about case, when user was created via 'user-add', then > 'user-restage' may confuse users, because that user hasn't been in > stage area. > I guess it depends on whether the user is aware of the lifecycle feature as the stage would be implied even if some users start as active. But we could add to the symmetry of the commands: *add - delete* (manipulates active or staged users) **activate - deactivate* *(between staged and active users)* retire - restore* (between active and archived users) *retire - restage *(between staged and archived users) Admittedly, both of the cases in the last pair seem weird and rare to be used. But if the "retire" action ultimately remains undefined for staged users, I think it would still be fine as "restage" pushes a user through two states back :-) Also, if we have the "deactivate" action for active users, I'd try to make it clear what are the practical differences between "retire" and "deactivate" in this setup. Cheers, Tomas > Martin^2 >> >> Tomas >> >> > -- Tom?? ?apek tcapek at redhat.com IRC Nick: tcapek Team name: Customer Content Services (CCS) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Aug 12 12:56:54 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 12 Aug 2015 14:56:54 +0200 Subject: [Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates Message-ID: <55CB4296.3020103@redhat.com> usercertificate attr was moved from "System Modify Users" to this new permission. https://fedorahosted.org/freeipa/ticket/5177 Note: hosts have permission "System: Manage Host Certificates", services don't have it but usercertificate is in "System: Modify Services". I would move it as well if usercertificate was not the only attr in "System: Modify Services". -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0910-add-permission-System-Manage-User-Certificates.patch Type: text/x-patch Size: 5310 bytes Desc: not available URL: From dkupka at redhat.com Wed Aug 12 13:02:25 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 12 Aug 2015 15:02:25 +0200 Subject: [Freeipa-devel] [PATCH 471] ULC: Prevent preserved users from being assigned membership In-Reply-To: <55CB1E5F.7030407@redhat.com> References: <55CB1E5F.7030407@redhat.com> Message-ID: <55CB43E1.3060501@redhat.com> On 12/08/15 12:22, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > Works for me, ACK. -- David Kupka From mbabinsk at redhat.com Wed Aug 12 13:42:55 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 12 Aug 2015 15:42:55 +0200 Subject: [Freeipa-devel] [PATCH 470] install: Fix server and replica install options In-Reply-To: <55CADF38.2070106@redhat.com> References: <55CADF38.2070106@redhat.com> Message-ID: <55CB4D5F.4040205@redhat.com> On 08/12/2015 07:52 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From tbabej at redhat.com Wed Aug 12 14:13:53 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:13:53 +0200 Subject: [Freeipa-devel] [PATCH] 908 adjust search so that it works for non-admin users In-Reply-To: <55CB271A.1060909@redhat.com> References: <55CB271A.1060909@redhat.com> Message-ID: <55CB54A1.4020201@redhat.com> On 08/12/2015 12:59 PM, Petr Vobornik wrote: > Non-admin user can now search for: > - hosts > - hostgroups > - netgroups > - servers > - services > > (Fixes ACI issue where search returns nothing when user does't have > read rights for an attribute in search_attributes. > > https://fedorahosted.org/freeipa/ticket/5167 > > ACK. From tbabej at redhat.com Wed Aug 12 14:17:36 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:17:36 +0200 Subject: [Freeipa-devel] [PATCH] 908 adjust search so that it works for non-admin users In-Reply-To: <55CB54A1.4020201@redhat.com> References: <55CB271A.1060909@redhat.com> <55CB54A1.4020201@redhat.com> Message-ID: <55CB5580.6090905@redhat.com> On 08/12/2015 04:13 PM, Tomas Babej wrote: > > > On 08/12/2015 12:59 PM, Petr Vobornik wrote: >> Non-admin user can now search for: >> - hosts >> - hostgroups >> - netgroups >> - servers >> - services >> >> (Fixes ACI issue where search returns nothing when user does't have >> read rights for an attribute in search_attributes. >> >> https://fedorahosted.org/freeipa/ticket/5167 >> >> > > ACK. > Pushed to master: 196ef09bd25d727865aee72a03d59f9930c65149cd Pushed to ipa-4-2: e37821af8026958e08f7354df3f84dd42f93d60f From tbabej at redhat.com Wed Aug 12 14:28:59 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:28:59 +0200 Subject: [Freeipa-devel] [PATCH] 909 validate mutually exclusive options in vault-add In-Reply-To: <55CB2747.5040100@redhat.com> References: <55CB2747.5040100@redhat.com> Message-ID: <55CB582B.8020200@redhat.com> On 08/12/2015 01:00 PM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/5195 > > I did a small grammar change "could" -> "can" in the error message. Otherwise ACK. From tbabej at redhat.com Wed Aug 12 14:31:50 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:31:50 +0200 Subject: [Freeipa-devel] [PATCH] 909 validate mutually exclusive options in vault-add In-Reply-To: <55CB582B.8020200@redhat.com> References: <55CB2747.5040100@redhat.com> <55CB582B.8020200@redhat.com> Message-ID: <55CB58D6.3040107@redhat.com> On 08/12/2015 04:28 PM, Tomas Babej wrote: > > > On 08/12/2015 01:00 PM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/5195 >> >> > > I did a small grammar change "could" -> "can" in the error message. > > Otherwise ACK. > Pushed to master: 7d7ffb62526595433412633c05af5af7909124c8 Pushed to ipa-4-2: dc0d4f73200065c209eb007a3be3ebd3d3b6dd64 From tbabej at redhat.com Wed Aug 12 14:38:57 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:38:57 +0200 Subject: [Freeipa-devel] [PATCH 0055] raise an exception when user tries to modify a local ID range In-Reply-To: <55C865CE.7040507@redhat.com> References: <55C4BF3D.2050901@redhat.com> <55C4C5FF.20908@redhat.com> <55C4CA13.9070409@redhat.com> <55C4CDF0.5050709@redhat.com> <55C865CE.7040507@redhat.com> Message-ID: <55CB5A81.8070208@redhat.com> On 08/10/2015 10:50 AM, Martin Babinsky wrote: > On 08/07/2015 05:25 PM, Tomas Babej wrote: >> >> >> On 08/07/2015 05:09 PM, Martin Babinsky wrote: >>> On 08/07/2015 04:51 PM, Tomas Babej wrote: >>>> >>>> >>>> On 08/07/2015 04:22 PM, Martin Babinsky wrote: >>>>> Short term fix for https://fedorahosted.org/freeipa/ticket/4826 >>>>> >>>>> >>>>> >>>> >>>> Hi, >>>> >>>> couple of minor issues: >>>> >>>> 1.) Please create a separate constant for the WARNING section, now this >>>> segment is copy-pasted at three different places in the plugin. >>>> >>>> 2.) It would be nice to fix the broken indentation in the help texts >>>> for >>>> ipa idrange-add/mod whlie poking at that part of the code. >>>> >>> How should these sections be indented (especially the warning parts)? >>> >> >> The section is indented using 4 spaces in "ipa help idrange-mod" (-add). >> I see no point in doing so, Additionally, being a separate block of >> text, it is not visually separated from the options block. >> >>>> 3.) 'ipa help idranges' does not produce any info, it error message >>>> needs to suggest 'ipa help idrange' >>>> >>>> Otherwise looks and works good. >>>> >>>> Tomas >>>> >>> >>> > > Attaching updated patch. I have tried to improve the visibility of the > warning message. > Thanks, much better now. ACK. From tbabej at redhat.com Wed Aug 12 14:39:54 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:39:54 +0200 Subject: [Freeipa-devel] [PATCH 0055] raise an exception when user tries to modify a local ID range In-Reply-To: <55CB5A81.8070208@redhat.com> References: <55C4BF3D.2050901@redhat.com> <55C4C5FF.20908@redhat.com> <55C4CA13.9070409@redhat.com> <55C4CDF0.5050709@redhat.com> <55C865CE.7040507@redhat.com> <55CB5A81.8070208@redhat.com> Message-ID: <55CB5ABA.4060004@redhat.com> On 08/12/2015 04:38 PM, Tomas Babej wrote: > > > On 08/10/2015 10:50 AM, Martin Babinsky wrote: >> On 08/07/2015 05:25 PM, Tomas Babej wrote: >>> >>> >>> On 08/07/2015 05:09 PM, Martin Babinsky wrote: >>>> On 08/07/2015 04:51 PM, Tomas Babej wrote: >>>>> >>>>> >>>>> On 08/07/2015 04:22 PM, Martin Babinsky wrote: >>>>>> Short term fix for https://fedorahosted.org/freeipa/ticket/4826 >>>>>> >>>>>> >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> couple of minor issues: >>>>> >>>>> 1.) Please create a separate constant for the WARNING section, now this >>>>> segment is copy-pasted at three different places in the plugin. >>>>> >>>>> 2.) It would be nice to fix the broken indentation in the help texts >>>>> for >>>>> ipa idrange-add/mod whlie poking at that part of the code. >>>>> >>>> How should these sections be indented (especially the warning parts)? >>>> >>> >>> The section is indented using 4 spaces in "ipa help idrange-mod" (-add). >>> I see no point in doing so, Additionally, being a separate block of >>> text, it is not visually separated from the options block. >>> >>>>> 3.) 'ipa help idranges' does not produce any info, it error message >>>>> needs to suggest 'ipa help idrange' >>>>> >>>>> Otherwise looks and works good. >>>>> >>>>> Tomas >>>>> >>>> >>>> >> >> Attaching updated patch. I have tried to improve the visibility of the >> warning message. >> > > Thanks, much better now. > > ACK. > Pushed to: master: 55feea500be1f4ae7bf02ef3c48377a6751ca71d ipa-4-2: 5738cdb1145f6bce7f31a6d29bd39ceadbe62c88 From tbabej at redhat.com Wed Aug 12 14:44:07 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:44:07 +0200 Subject: [Freeipa-devel] [PATCH 470] install: Fix server and replica install options In-Reply-To: <55CB4D5F.4040205@redhat.com> References: <55CADF38.2070106@redhat.com> <55CB4D5F.4040205@redhat.com> Message-ID: <55CB5BB7.7070406@redhat.com> On 08/12/2015 03:42 PM, Martin Babinsky wrote: > On 08/12/2015 07:52 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > > ACK > master: a651be3eec2a08bd2865b16b0eed767db69aab0f ipa-4-2: 8e1a9b49397ee9dbef9fce4b61277246ea65ca8d From tbabej at redhat.com Wed Aug 12 14:47:00 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 16:47:00 +0200 Subject: [Freeipa-devel] [PATCH 0359] adtrust-install: Correctly determine 4.2 FreeIPA servers In-Reply-To: <20150811145811.GS22106@redhat.com> References: <55CA01F7.6040100@redhat.com> <20150811145811.GS22106@redhat.com> Message-ID: <55CB5C64.9000004@redhat.com> On 08/11/2015 04:58 PM, Alexander Bokovoy wrote: > On Tue, 11 Aug 2015, Tomas Babej wrote: >> Hi, >> >> We need to detect a list of FreeIPA 4.2 (and above) servers, since >> only there is the required version of SSSD present. >> >> Since the maximum domain level for 4.2 is 0 (and not 1), we can filter >> for any value of ipaMaxDomainLevel / ipaMinDomainLevel attributes >> to generate the list. >> >> https://fedorahosted.org/freeipa/ticket/5199 > >> From 31bf121e4603bc1287eac88653ff48198c2f69c3 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Tue, 11 Aug 2015 16:05:32 +0200 >> Subject: [PATCH] adtrust-install: Correctly determine 4.2 FreeIPA servers >> >> We need to detect a list of FreeIPA 4.2 (and above) servers, since >> only there is the required version of SSSD present. >> >> Since the maximum domain level for 4.2 is 0 (and not 1), we can filter >> for any value of ipaMaxDomainLevel / ipaMinDomainLevel attributes >> to generate the list. >> >> https://fedorahosted.org/freeipa/ticket/5199 >> --- >> install/tools/ipa-adtrust-install | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/install/tools/ipa-adtrust-install >> b/install/tools/ipa-adtrust-install >> index >> 5340c31d16ed78da0cb39725d9ae93c76470b698..21e58dd9f25e82429ce8d0c776d1b512c2661809 >> 100755 >> --- a/install/tools/ipa-adtrust-install >> +++ b/install/tools/ipa-adtrust-install >> @@ -396,7 +396,7 @@ def main(): >> # Search only masters which have support for domain levels >> # because only these masters will have SSSD recent enough >> to support AD trust agents >> (entries_m, truncated) = smb.admin_conn.find_entries( >> - >> filter="(&(objectclass=ipaSupportedDomainLevelConfig)(!(ipaMaxDomainLevel=0)))", >> >> + >> filter="(&(objectclass=ipaSupportedDomainLevelConfig)(ipaMaxDomainLevel=*)(ipaMinDomainLevel=*))", >> >> base_dn=masters_dn, attrs_list=['cn'], >> scope=ldap.SCOPE_ONELEVEL) >> except errors.NotFound: >> pass > > ACK. I tested a manual version of this patch in the morning. > * master: 1fc21e980bb901bf71f7ee024cdbb15c1caec3a7 * ipa-4-2: ef192fb17be348c526029e8fa5165b9108e1f6da From mbasti at redhat.com Wed Aug 12 15:21:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Aug 2015 17:21:09 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55CB406F.9030501@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> <55CB2164.8020203@redhat.com> <55CB23DB.9010306@redhat.com> <55CB2ADE.7090309@redhat.com> <55CB375B.6080209@redhat.com> <55CB3A7C.3010201@redhat.com> <55CB406F.9030501@redhat.com> Message-ID: <55CB6465.9050903@redhat.com> On 08/12/2015 02:47 PM, Tomas Capek wrote: > On 12/08/15 14:22, Martin Basti wrote: >> >> >> On 08/12/2015 02:08 PM, Tomas Capek wrote: >>> On 12/08/15 13:15, David Kupka wrote: >>>> On 12/08/15 12:45, thierry bordaz wrote: >>>>> On 08/12/2015 12:35 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/11/2015 10:40 AM, thierry bordaz wrote: >>>>>>> On 08/11/2015 09:32 AM, Martin Basti wrote: >>>>>>>> On 11/08/15 09:17, Jan Cholasta wrote: >>>>>>>>> On 5.8.2015 12:34, thierry bordaz wrote: >>>>>>>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>>>>>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>>>>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: "thierry bordaz" >>>>>>>>>>>>> To: "Jan Cholasta" >>>>>>>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>>>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add >>>>>>>>>>>>> --from-delete with >>>>>>>>>>>>> user-undel --to-staged >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> However, I cannot fix this part of ticket, where user is >>>>>>>>>>>>>>>>>> prompted to >>>>>>>>>>>>>>>>>> write name and surname. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As the first name and last name are mandatory >>>>>>>>>>>>>>>>>> attributes of >>>>>>>>>>>>>>>>>> stageuser-add command, but they are not needed by >>>>>>>>>>>>>>>>>> when the >>>>>>>>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>>>>>>>> I would like to ask how to fix this issue, IMO this will >>>>>>>>>>>>>>>>>> be huge >>>>>>>>>>>>>>>>>> hack >>>>>>>>>>>>>>>>>> in internal API. Or should we just document this bug >>>>>>>>>>>>>>>>>> as known >>>>>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>>>>> (thierry wrote that this is not use case that should >>>>>>>>>>>>>>>>>> be used >>>>>>>>>>>>>>>>>> often)? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The best solution would be separate command, but this >>>>>>>>>>>>>>>>>> idea >>>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: >>>>>>>>>>>>>>>>>> question >>>>>>>>>>>>>>>>>> regarding the design" >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> as was mentioned before, we have issue with current >>>>>>>>>>>>>>>>> internal API >>>>>>>>>>>>>>>>> and the >>>>>>>>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We discussed this today, and we did not find a nice >>>>>>>>>>>>>>>>> way how >>>>>>>>>>>>>>>>> to fix >>>>>>>>>>>>>>>>> it, >>>>>>>>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * create new option for user-undel: used-undel >>>>>>>>>>>>>>>>> --to-staged (or >>>>>>>>>>>>>>>>> create >>>>>>>>>>>>>>>>> new command) that will handle moving deleted users to >>>>>>>>>>>>>>>>> staged >>>>>>>>>>>>>>>>> area as >>>>>>>>>>>>>>>>> --from-delete did. >>>>>>>>>>>>>>>> Make it new command please. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Instead of stageuser-add and option --from-delete, >>>>>>>>>>>>>>>>> which work >>>>>>>>>>>>>>>>> totally >>>>>>>>>>>>>>>>> different, the command user-undel does similar >>>>>>>>>>>>>>>>> operation than >>>>>>>>>>>>>>>>> stage-user >>>>>>>>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>>>>>>>> because it >>>>>>>>>>>>>>>> does >>>>>>>>>>>>>>>> something similar. >>>>>>>>>>>>>>> How about making it a 'stageuser-undel'? The >>>>>>>>>>>>>>> 'user-undel' moves >>>>>>>>>>>>>>> preserved user to active, so the 'stageuser-undel' would >>>>>>>>>>>>>>> move >>>>>>>>>>>>>>> preserved >>>>>>>>>>>>>>> to staged. The action is similar, but has slightly >>>>>>>>>>>>>>> different >>>>>>>>>>>>>>> specifics >>>>>>>>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>>>>>>>> 'stageuser-undel' >>>>>>>>>>>>>>> feels more natural than 'user-undel --to-staged' since it's >>>>>>>>>>>>>>> basically >>>>>>>>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>>>>>>>> user, not >>>>>>>>>>>>>>> 'user-add --to-staged'. It would be in the same style as >>>>>>>>>>>>>>> all the >>>>>>>>>>>>>>> other >>>>>>>>>>>>>>> commands concerning operations with users in staged >>>>>>>>>>>>>>> container. >>>>>>>>>>>>>> Well, user-undel is the opposite of user-del, and >>>>>>>>>>>>>> stageuser-undel >>>>>>>>>>>>>> should be the opposite of stageuser-del. The stageuser-undel >>>>>>>>>>>>>> you are >>>>>>>>>>>>>> suggesting is not. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>>>>>>>> user once >>>>>>>>>>>>>> a staged user is created from it, but -undel behaves like >>>>>>>>>>>>>> that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think the command should be limited to deleted users >>>>>>>>>>>>>> only. >>>>>>>>>>>>>> Active and deleted users share the same namespace, so it >>>>>>>>>>>>>> is an >>>>>>>>>>>>>> arbitrary limitation. >>>>>>>>>>>>> preserved users has been valid active user. In that sense >>>>>>>>>>>>> active/preserved are managed by a same set of CLI >>>>>>>>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>>>>>>>> 'user'. So >>>>>>>>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>>>>>>>> 'user-undel >>>>>>>>>>>>> --to-stage'. >>>>>>>>>>>>> >>>>>>>>>>>>> But then if we will make any incompatible change between >>>>>>>>>>>>> "user-undel" >>>>>>>>>>>>> and "user-undel --to-stage" we may hit this issue again. I >>>>>>>>>>>>> agree with >>>>>>>>>>>>> Honza, this should be a separate command. >>>>>>>>>>>> What do you mean 'incompatible change' ? >>>>>>>>>>>> >>>>>>>>>>>> --to-stage option would only select a different container >>>>>>>>>>>> that the >>>>>>>>>>>> 'Active' one ? >>>>>>>>>>> >>>>>>>>>>> That's not sufficient. The command should do the reverse of >>>>>>>>>>> stageuser-activate, which is ADD and DELETE, possibly with some >>>>>>>>>>> modifications of the entry between them, not MODRDN like >>>>>>>>>>> user-undel does. >>>>>>>>>>> >>>>>>>>>> That is a good point. Do we need to modify anything from a >>>>>>>>>> deleted >>>>>>>>>> entry >>>>>>>>>> to a add it in the stage container. >>>>>>>>>> Already delete entry have been purged of several values >>>>>>>>>> (password, >>>>>>>>>> krb >>>>>>>>>> keys, membership,..) do you think of other attributes to >>>>>>>>>> remove ? >>>>>>>>>> >>>>>>>>>> IIRC the use case is a support engineer who activated too >>>>>>>>>> early an >>>>>>>>>> entry. So you are right he wants to unactivate it. A question >>>>>>>>>> is does >>>>>>>>>> the unactivation requires more modifications than the one did by >>>>>>>>>> 'user-del --preserve'. Note that we can not retrieve the >>>>>>>>>> attribute >>>>>>>>>> values when the entry was activated from stage. >>>>>>>>> >>>>>>>>> I don't know if any modifications are needed ATM (doesn't mean >>>>>>>>> there can't be any in the future), but the point is that if >>>>>>>>> you are >>>>>>>>> creating object A from object B using operation X, you should be >>>>>>>>> creating object B from object A using the reverse of operation X, >>>>>>>>> otherwise there *will* be inconsistencies, and we don't want >>>>>>>>> that. >>>>>>>>> >>>>>>>> +1 >>>>>>>> I agree with this >>>>>>>> >>>>>>> So my understanding is that you think a new verb should be >>>>>>> created to >>>>>>> allow: 'Active' -> 'Stage' >>>>>>> I do not recall why this was not discussed or if it as already been >>>>>>> rejected. >>>>>>> >>>>>>> I like the idea and I think it could be useful to Support Engineer. >>>>>>> Now I am not sure we want to make 'easy' the action to >>>>>>> 'unactivate' a >>>>>>> user (currently it requires two operations). >>>>>>> In your opinion, does it replace 'stageuser-add --from-delete' or >>>>>>> 'user-undel --to-stage' ? or is it an additional subcommand. >>>>>>> Also, activate/unactivate is not a NULL operation. Some values has >>>>>>> been changed (uid,gid,uniqueuiid...) and some values will be lost >>>>>>> (membership). >>>>>>> >>>>>>> About the verb, this is not because the previous action is >>>>>>> 'activate' >>>>>>> that we should use 'unactivate'. For example, Thomas raised the >>>>>>> point >>>>>>> that after 'user-del', 'user-restore' would have been more user >>>>>>> friendly than 'user-undel' >>>>>>> >>>>>>> Thanks >>>>>>> thierry >>>>>>> >>>>>> We had discussion off-list discussion, and result is following >>>>>> proposal: >>>>>> >>>>>> * remove 'stageuser-add --from-delete' >>>>>> * add new command: 'user-stage' >>>>>> >>>>>> the user-stage command will move both deleted or active users to >>>>>> staged area. >>>>>> $ user-stage >>>>>> replaces the stage-user --from-delete, keeps the same behavior >>>>>> >>>>>> $ user-stage >>>>>> this is stretch goal, nice to have, but I don't know how easy is to >>>>>> implement this >>>>>> >>>>>> For better visualization, here is link to our board screen >>>>>> https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg >>>>>> >>>>>> Thierry, do you agree with this? >>>>>> Martin^2 >>>>> >>>>> >>>>> Hello, >>>>> >>>>> I really like the idea (as well as the drawing) of having the same >>>>> cli >>>>> for both active/deleted user. >>>>> About the exact verb 'user-stage', I am always bad at this >>>>> exercise and >>>>> it would be great to have Thomas ack on that. >>>>> >>>>> Just a question about the other verbs user-disable/user-enable. I >>>>> know >>>>> they are doing something different but do you think there is a >>>>> risk of >>>>> confusion for admin when he should do user-stage or user-disable ? >>>>> >>>>> thanks >>>>> thierry >>>>> >>>>> >>>>> >>>> >>>> Adding Tomas to the loop. >>> Hello everyone, >>> >>> I probably don't have all the information and perhaps cannot see >>> all possible side effects but on the handover session for this >>> feature, I was concerned that some commands did not match in GUI and >>> in CLI (restore, undel). >>> >>> Also, from the UX perspective, I thought it would be more friendly >>> to have symmetrical commands and not confuse users with two delete >>> modes as in "do you want to mock-delete the user or delete delete it?" >>> >>> Therefore, I proposed to have two simple pairs of commands, also >>> reflected in the UI: >>> >>> "add" and "delete" - for just adding and completely removing users >>> >>> "retire" and "restore" - for just putting a user to or taking it out >>> of the user "archive" >>> >> Sounds good, but we will not change all commands. > > Sure, I made this proposal only for the user lifecycle feature. > Perhaps some commands could be aliases if it would make it easier to > introduce them... > >> >>> as for the "--from-delete" option , I think the proposed >>> "user-stage" overlaps a little with the existing "stageuser-*" >>> commands. As the command would move a user to the initial state of >>> the lifecycle, be it an active or retired user, I'd try to emphasize >>> the fact by proposing a similar but perhaps more cogent "user-restage". >>> >>> Do you think it would work? >> How about case, when user was created via 'user-add', then >> 'user-restage' may confuse users, because that user hasn't been in >> stage area. >> > I guess it depends on whether the user is aware of the lifecycle > feature as the stage would be implied even if some users start as active. > > But we could add to the symmetry of the commands: > > *add - delete* (manipulates active or staged users) > **activate - deactivate* *(between staged and active users)* > retire - restore* (between active and archived users) > > *retire - restage *(between staged and archived users) We cannot change commands that already exist, it would be more pain than gain. > > Admittedly, both of the cases in the last pair seem weird and rare to > be used. But if the "retire" action ultimately remains undefined for > staged users, I think it would still be fine as "restage" pushes a > user through two states back :-) And I'm quite lost in what you wrote. We have user-* and stageuser-* commads > > Also, if we have the "deactivate" action for active users, I'd try to > make it clear what are the practical differences between "retire" and > "deactivate" in this setup. We have: activate: stageuser-activate deactivate: user-del --preserve retire: planned user-stage (active user) restore: user-undel (applies only to users) restage: planned user-stage (deleted user) staged->archived user: N/A > > Cheers, > Tomas > > > >> Martin^2 >>> >>> Tomas >>> >>> >> > > > -- > Tom?? ?apek > tcapek at redhat.com > IRC Nick: tcapek > Team name: Customer Content Services (CCS) -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Wed Aug 12 15:32:46 2015 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 12 Aug 2015 09:32:46 -0600 Subject: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit In-Reply-To: <55C9A56F.40007@redhat.com> References: <55B9D0FE.2090705@redhat.com> <55B9D327.7070806@redhat.com> <55C085BD.40402@redhat.com> <55C9A56F.40007@redhat.com> Message-ID: On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta wrote: > On 6.8.2015 21:43, Gabe Alford wrote: > >> Hello, >> >> Updated patch attached. >> >> - Time limit is -1 for unlimited. I found this >> https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html >> in reference to keeping the time limit as -1 for unlimited. >> > > This patch does two conflicting things: it coerces time limit of 0 to -1 > and at the same time prohibits the user to use 0 for time limit. We should > do just one of these and IMHO it should be the coercion of 0 to -1. > > Sure enough, testing time limit at 0 did not work for unlimited as well >> as appeared to have negative effects on IPA. >> > > This is because the time limit read from ipa config is not converted to > int in ldap2.find_entries(), so the coercion does not work. Fix this and 0 > will work just fine. > > Also, I believe that >> http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s >> specifies unlimited for time limit as -1. (Please correct me if I am >> wrong.) >> > > python-ldap is layers below our API and should not determine what we use > for unlimited time limit. I would prefer if we were self-consistent and use > 0 for both time limit and size limit. > A misunderstanding on my part as I thought it was higher up in the API for some reason. Updated patch attached. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0053-5-Standardize-minvalue-for-ipasearchrecordlimit-and-ip.patch Type: text/x-patch Size: 8513 bytes Desc: not available URL: From tbabej at redhat.com Wed Aug 12 16:10:24 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 18:10:24 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <55C8C5B1.9020604@redhat.com> References: <55BBAD13.8020308@redhat.com> <55BF2F5B.6000804@redhat.com> <55C8C5B1.9020604@redhat.com> Message-ID: <55CB6FF0.9090007@redhat.com> On 08/10/2015 05:39 PM, Petr Viktorin wrote: > On 08/03/2015 11:07 AM, Christian Heimes wrote: >> On 2015-07-31 19:14, Petr Viktorin wrote: >>> Hello, >>> Here is a batch of mostly mechanical changes: removing deprecated >>> features to prepare for Python 3. >> >> Out of curiosity, what tool did you use for patch 695-absolute-imports? >> Python-modernize adds from __future__ import absolute_imports and >> changes imports to explicit relative imports. > > I used modernize to find all the occurences, and fixed imports by hand. > Most of IPA uses absolute imports, as recommended by PEP 8. > >> In patch 693 you have removed test cases for CIDict.has_key(), but >> CIDict still provides the function. You should either keep the tests >> around or remove has_key() from CIDict. > > I haven't removed them: "test_haskey" is only skipped under Python 3. I > assumed that's enough to verify that `has_key` works well (i.e. the same > as `in`), so in the other tests I do use `in` instead. > > I'm attaching updated patches, under Python 3 they remove CIDict.has_key > a bit more formally. They're also rebased. > >> The rest looks good to me, but I haven't studied every change >> thoroughly. It's just too much. > > Anything I can do to help? Let's not sit on this for too long, it will a pain to rebase. I went through the gargatuan patches manually and did not discover any issues. Additionally, the patchset introduces no new unit-test failures. So I am inclined to ACK it, unless Christian has any objections. Tomas From cheimes at redhat.com Wed Aug 12 16:12:06 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 12 Aug 2015 18:12:06 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <55CB6FF0.9090007@redhat.com> References: <55BBAD13.8020308@redhat.com> <55BF2F5B.6000804@redhat.com> <55C8C5B1.9020604@redhat.com> <55CB6FF0.9090007@redhat.com> Message-ID: <55CB7056.90509@redhat.com> On 2015-08-12 18:10, Tomas Babej wrote: > > > On 08/10/2015 05:39 PM, Petr Viktorin wrote: >> On 08/03/2015 11:07 AM, Christian Heimes wrote: >>> On 2015-07-31 19:14, Petr Viktorin wrote: >>>> Hello, >>>> Here is a batch of mostly mechanical changes: removing deprecated >>>> features to prepare for Python 3. >>> >>> Out of curiosity, what tool did you use for patch 695-absolute-imports? >>> Python-modernize adds from __future__ import absolute_imports and >>> changes imports to explicit relative imports. >> >> I used modernize to find all the occurences, and fixed imports by hand. >> Most of IPA uses absolute imports, as recommended by PEP 8. >> >>> In patch 693 you have removed test cases for CIDict.has_key(), but >>> CIDict still provides the function. You should either keep the tests >>> around or remove has_key() from CIDict. >> >> I haven't removed them: "test_haskey" is only skipped under Python 3. I >> assumed that's enough to verify that `has_key` works well (i.e. the same >> as `in`), so in the other tests I do use `in` instead. >> >> I'm attaching updated patches, under Python 3 they remove CIDict.has_key >> a bit more formally. They're also rebased. >> >>> The rest looks good to me, but I haven't studied every change >>> thoroughly. It's just too much. >> >> Anything I can do to help? > > Let's not sit on this for too long, it will a pain to rebase. I went > through the gargatuan patches manually and did not discover any issues. > > Additionally, the patchset introduces no new unit-test failures. > > So I am inclined to ACK it, unless Christian has any objections. I've skimmed over the patches and didn't find any issues, too. pylint --py3k is going to complain about missing from __future__ import absolute_import lines. We can add them later, though. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From tbabej at redhat.com Wed Aug 12 16:16:44 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 18:16:44 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <55CB7056.90509@redhat.com> References: <55BBAD13.8020308@redhat.com> <55BF2F5B.6000804@redhat.com> <55C8C5B1.9020604@redhat.com> <55CB6FF0.9090007@redhat.com> <55CB7056.90509@redhat.com> Message-ID: <55CB716C.7080404@redhat.com> On 08/12/2015 06:12 PM, Christian Heimes wrote: > On 2015-08-12 18:10, Tomas Babej wrote: >> >> >> On 08/10/2015 05:39 PM, Petr Viktorin wrote: >>> On 08/03/2015 11:07 AM, Christian Heimes wrote: >>>> On 2015-07-31 19:14, Petr Viktorin wrote: >>>>> Hello, >>>>> Here is a batch of mostly mechanical changes: removing deprecated >>>>> features to prepare for Python 3. >>>> >>>> Out of curiosity, what tool did you use for patch 695-absolute-imports? >>>> Python-modernize adds from __future__ import absolute_imports and >>>> changes imports to explicit relative imports. >>> >>> I used modernize to find all the occurences, and fixed imports by hand. >>> Most of IPA uses absolute imports, as recommended by PEP 8. >>> >>>> In patch 693 you have removed test cases for CIDict.has_key(), but >>>> CIDict still provides the function. You should either keep the tests >>>> around or remove has_key() from CIDict. >>> >>> I haven't removed them: "test_haskey" is only skipped under Python 3. I >>> assumed that's enough to verify that `has_key` works well (i.e. the same >>> as `in`), so in the other tests I do use `in` instead. >>> >>> I'm attaching updated patches, under Python 3 they remove CIDict.has_key >>> a bit more formally. They're also rebased. >>> >>>> The rest looks good to me, but I haven't studied every change >>>> thoroughly. It's just too much. >>> >>> Anything I can do to help? >> >> Let's not sit on this for too long, it will a pain to rebase. I went >> through the gargatuan patches manually and did not discover any issues. >> >> Additionally, the patchset introduces no new unit-test failures. >> >> So I am inclined to ACK it, unless Christian has any objections. > > I've skimmed over the patches and didn't find any issues, too. > > pylint --py3k is going to complain about missing from __future__ import > absolute_import lines. We can add them later, though. > > Christian > > Either that, or we can simply ignore no-absolute-import (W1618). Thus ACK for the patchset. Tomas From tbabej at redhat.com Wed Aug 12 16:18:18 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 18:18:18 +0200 Subject: [Freeipa-devel] [PATCHES] 0691-0695 Modernization In-Reply-To: <55CB716C.7080404@redhat.com> References: <55BBAD13.8020308@redhat.com> <55BF2F5B.6000804@redhat.com> <55C8C5B1.9020604@redhat.com> <55CB6FF0.9090007@redhat.com> <55CB7056.90509@redhat.com> <55CB716C.7080404@redhat.com> Message-ID: <55CB71CA.7010907@redhat.com> On 08/12/2015 06:16 PM, Tomas Babej wrote: > > > On 08/12/2015 06:12 PM, Christian Heimes wrote: >> On 2015-08-12 18:10, Tomas Babej wrote: >>> >>> >>> On 08/10/2015 05:39 PM, Petr Viktorin wrote: >>>> On 08/03/2015 11:07 AM, Christian Heimes wrote: >>>>> On 2015-07-31 19:14, Petr Viktorin wrote: >>>>>> Hello, >>>>>> Here is a batch of mostly mechanical changes: removing deprecated >>>>>> features to prepare for Python 3. >>>>> >>>>> Out of curiosity, what tool did you use for patch 695-absolute-imports? >>>>> Python-modernize adds from __future__ import absolute_imports and >>>>> changes imports to explicit relative imports. >>>> >>>> I used modernize to find all the occurences, and fixed imports by hand. >>>> Most of IPA uses absolute imports, as recommended by PEP 8. >>>> >>>>> In patch 693 you have removed test cases for CIDict.has_key(), but >>>>> CIDict still provides the function. You should either keep the tests >>>>> around or remove has_key() from CIDict. >>>> >>>> I haven't removed them: "test_haskey" is only skipped under Python 3. I >>>> assumed that's enough to verify that `has_key` works well (i.e. the same >>>> as `in`), so in the other tests I do use `in` instead. >>>> >>>> I'm attaching updated patches, under Python 3 they remove CIDict.has_key >>>> a bit more formally. They're also rebased. >>>> >>>>> The rest looks good to me, but I haven't studied every change >>>>> thoroughly. It's just too much. >>>> >>>> Anything I can do to help? >>> >>> Let's not sit on this for too long, it will a pain to rebase. I went >>> through the gargatuan patches manually and did not discover any issues. >>> >>> Additionally, the patchset introduces no new unit-test failures. >>> >>> So I am inclined to ACK it, unless Christian has any objections. >> >> I've skimmed over the patches and didn't find any issues, too. >> >> pylint --py3k is going to complain about missing from __future__ import >> absolute_import lines. We can add them later, though. >> >> Christian >> >> > > Either that, or we can simply ignore no-absolute-import (W1618). > > Thus ACK for the patchset. > > Tomas > Pushed to master: 5435a8a32a2e88675e84d22d6f9b97e67f6f5264 From tbabej at redhat.com Wed Aug 12 16:24:01 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 18:24:01 +0200 Subject: [Freeipa-devel] [PATCH] 0031 certprofile: add profile format explanation In-Reply-To: <20150805041051.GN4843@dhcp-40-8.bne.redhat.com> References: <20150805041051.GN4843@dhcp-40-8.bne.redhat.com> Message-ID: <55CB7321.5050300@redhat.com> On 08/05/2015 06:10 AM, Fraser Tweedale wrote: > The attached patch addresses > https://fedorahosted.org/freeipa/ticket/5089 > > Thanks, > Fraser > > > ACK, thanks for the explanations. I gather this concludes the https://fedorahosted.org/freeipa/ticket/5089 ticket then? Tomas From tbabej at redhat.com Wed Aug 12 16:25:54 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 12 Aug 2015 18:25:54 +0200 Subject: [Freeipa-devel] [PATCH] 0031 certprofile: add profile format explanation In-Reply-To: <55CB7321.5050300@redhat.com> References: <20150805041051.GN4843@dhcp-40-8.bne.redhat.com> <55CB7321.5050300@redhat.com> Message-ID: <55CB7392.1020107@redhat.com> On 08/12/2015 06:24 PM, Tomas Babej wrote: > > > On 08/05/2015 06:10 AM, Fraser Tweedale wrote: >> The attached patch addresses >> https://fedorahosted.org/freeipa/ticket/5089 >> >> Thanks, >> Fraser >> >> >> > > ACK, thanks for the explanations. I gather this concludes the > https://fedorahosted.org/freeipa/ticket/5089 ticket then? > > Tomas > Ah, I just noticed you say so in the initial email. There was a previous note in the ticket about not closing, so I got confused by that, but it referred to a former commit. Pushed to: master: f6b32d8eea82d686ab3cf92153fa7e1f5ded70ac ipa-4-2: 5afe202d5bbe1481ee6472e9676b636b3afd380c From mrniranjan at fedoraproject.org Wed Aug 12 18:11:54 2015 From: mrniranjan at fedoraproject.org (Niranjan) Date: Wed, 12 Aug 2015 23:41:54 +0530 Subject: [Freeipa-devel] Query regarding pytest-multihost plugin Message-ID: <20150812181154.GA17331@mniranja.pnq.redhat.com> Greetings, I have a following query regarding pytest-multihost plugin. I am going through the current documentation of this plugin at [1] According example yaml file specified in documentation ssh_key_filename: ~/.ssh/id_rsa domains: - name: adomain.test type: test-a hosts: - name: master ip: 192.0.2.1 role: master - name: replica1 ip: 192.0.2.2 role: replica Does the plugin connect to hosts using the hostname given under "name" or does it user "hostname" parameter if specified . The documentation specifies hosts have : role, hostname, shortname, external_hostname and ip-address So what is the role of "name" parameter in the above example ? If i have the following yaml file: ssh_key_filename: ~/.ssh/id_rsa domains: - name: adomain.test type: test-a hosts: - name: master ip: 192.0.2.1 external_hostname: pki1.example.org role: master - name: replica1 ip: 192.0.2.2 role: replica external_hostname: pki2.example.org Does the plugin connect to hosts using external_hostname or does it try connecting to master.adomain.test and replica1.adomain.test, (currently this is the behaviour that i am seeing, it ignore external_hostname) 1.https://pypi.python.org/pypi/pytest-multihost Regards Niranjan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From ftweedal at redhat.com Thu Aug 13 03:28:36 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 13:28:36 +1000 Subject: [Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates In-Reply-To: <55CB4296.3020103@redhat.com> References: <55CB4296.3020103@redhat.com> Message-ID: <20150813032836.GO16439@dhcp-40-8.bne.redhat.com> On Wed, Aug 12, 2015 at 02:56:54PM +0200, Petr Vobornik wrote: > usercertificate attr was moved from "System Modify Users" to this > new permission. > > https://fedorahosted.org/freeipa/ticket/5177 > > Note: hosts have permission "System: Manage Host Certificates", services > don't have it but usercertificate is in "System: Modify Services". I would > move it as well if usercertificate was not the only attr in "System: Modify > Services". > New permission works as expected. What are the implications of removing userCertificate attribute from "Modify Users" ACI? Users could be relying on it given that there is (until now) no more fine-grained permission. Perhaps we should a) use update script to add the new permission to any roles that have the Modify Users permission, or b) not remove the userCertificate attribute from the ACI, or c) deem this change acceptable and leave the patch as-is, in which case: ACK Cheers, Fraser From ftweedal at redhat.com Thu Aug 13 03:46:01 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 13:46:01 +1000 Subject: [Freeipa-devel] [PATCH] 0030 Add permission for bypassing CA ACL enforcement In-Reply-To: <20150804052129.GG4843@dhcp-40-8.bne.redhat.com> References: <20150804052129.GG4843@dhcp-40-8.bne.redhat.com> Message-ID: <20150813034601.GP16439@dhcp-40-8.bne.redhat.com> On Tue, Aug 04, 2015 at 03:21:29PM +1000, Fraser Tweedale wrote: > The attached patch fixes > https://fedorahosted.org/freeipa/ticket/5099. > > Thanks, > Fraser Ping; this patch needs review. From ftweedal at redhat.com Thu Aug 13 05:54:01 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 15:54:01 +1000 Subject: [Freeipa-devel] [PATCH] 0038 cert-request: remove allowed extensions check Message-ID: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> The attached patch fixes https://fedorahosted.org/freeipa/ticket/5205 Thanks, Fraser -------------- next part -------------- From 7186acfbf70bb6963b8bb72bbda5fece3fb20dd2 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 13 Aug 2015 01:42:06 -0400 Subject: [PATCH] cert-request: remove allowed extensions check cert-request currently permits a limited number of request extensions; uncommon and esoteric extensions are prohibited and this limits the usefulness of custom profiles. The Dogtag profile has total control over what goes into the final certificate and has the option to reject request based on the request extensions present or their values, so there is little reason to restrict what extensions can be used in FreeIPA. Remove the check. Fixes: https://fedorahosted.org/freeipa/ticket/5205 --- ipalib/plugins/cert.py | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index c0b459d3817d59d535f70258e9a0da9a784d7094..21093fb936b1da82a5371be8050737d8c79e6f9d 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -306,15 +306,6 @@ class cert_request(VirtualCommand): ), ) - _allowed_extensions = { - '2.5.29.14': None, # Subject Key Identifier - '2.5.29.15': None, # Key Usage - '2.5.29.17': 'request certificate with subjectaltname', - '2.5.29.19': None, # Basic Constraints - '2.5.29.37': None, # Extended Key Usage - '1.2.840.10070.8.1': None, # IECUserRoles (DNP3 / IEC 62351-8) - } - def execute(self, csr, **kw): ca_enabled_check() @@ -369,12 +360,10 @@ class cert_request(VirtualCommand): raise errors.CertificateOperationError( error=_("Failure decoding Certificate Signing Request: %s") % e) - # host principals may bypass allowed ext check + # self-service and host principals may bypass SAN permission check if bind_principal != principal and bind_principal_type != HOST: - for ext in extensions: - operation = self._allowed_extensions.get(ext) - if operation: - self.check_access(operation) + if '2.5.29.17' in extensions: + self.check_access('request certificate with subjectaltname') dn = None principal_obj = None @@ -426,11 +415,6 @@ class cert_request(VirtualCommand): "any of user's email addresses") ) - for ext in extensions: - if ext not in self._allowed_extensions: - raise errors.ValidationError( - name='csr', error=_("extension %s is forbidden") % ext) - # We got this far so the principal entry exists, can we write it? if not ldap.can_write(dn, "usercertificate"): raise errors.ACIError(info=_("Insufficient 'write' privilege " -- 2.4.3 From dkupka at redhat.com Thu Aug 13 06:17:04 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 13 Aug 2015 08:17:04 +0200 Subject: [Freeipa-devel] [PATCH 0060] user-undel: Fix error messages. Message-ID: <55CC3660.70205@redhat.com> https://fedorahosted.org/freeipa/ticket/5207 Requires patch freeipa-jcholast-471.1. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0060-user-undel-Fix-error-messages.patch Type: text/x-patch Size: 2083 bytes Desc: not available URL: From ftweedal at redhat.com Thu Aug 13 06:36:01 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 16:36:01 +1000 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles Message-ID: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> The attached patch fixes https://fedorahosted.org/freeipa/ticket/5198 Thanks, Fraser -------------- next part -------------- From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 13 Aug 2015 02:32:54 -0400 Subject: [PATCH] Prohibit deletion of included profiles Deletion of included profiles, including the default profile, should not be allowed. Detect this case and raise an error. Also update the included profiles collection to use namedtuple, making it easier to access the various components. Fixes: https://fedorahosted.org/freeipa/ticket/5198 --- ipalib/plugins/certprofile.py | 13 +++++++++++-- ipapython/dogtag.py | 8 +++++--- 2 files changed, 16 insertions(+), 5 deletions(-) diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -3,6 +3,7 @@ # import re +from operator import attrgetter from ipalib import api, Bool, File, Str from ipalib import output, util @@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( from ipalib.request import context from ipalib import ngettext from ipalib.text import _ +from ipapython.dogtag import INCLUDED_PROFILES from ipapython.version import API_VERSION from ipalib import errors @@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): __doc__ = _("Delete a Certificate Profile.") msg_summary = _('Deleted profile "%(value)s"') - def execute(self, *args, **kwargs): + def pre_callback(self, ldap, dn, *keys, **options): ca_enabled_check() - return super(certprofile_del, self).execute(*args, **kwargs) + + if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): + raise errors.ValidationError(name='profile_id', + error=_("Included profile '%(profile_id)s' cannot be deleted") + % {'profile_id': keys[0]} + ) + + return dn def post_callback(self, ldap, dn, *keys, **options): with self.api.Backend.ra_certprofile as profile_api: diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 99bdf066d64d626af05d93953117909c5fbfb693..fc4154719e31eb32e28587ea89fb04ead14d282e 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -17,6 +17,7 @@ # along with this program. If not, see . # +import collections import os import httplib import xml.dom.minidom @@ -42,10 +43,11 @@ from ipapython.ipa_log_manager import * # the configured version. +Profile = collections.namedtuple('Profile', ['profile_id', 'description', 'store_issued']) + INCLUDED_PROFILES = { - # ( profile_id , description , store_issued) - (u'caIPAserviceCert', u'Standard profile for network services', True), - (u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), + Profile(u'caIPAserviceCert', u'Standard profile for network services', True), + Profile(u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), } DEFAULT_PROFILE = u'caIPAserviceCert' -- 2.4.3 From abokovoy at redhat.com Thu Aug 13 06:53:35 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Aug 2015 09:53:35 +0300 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles In-Reply-To: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> References: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> Message-ID: <20150813065335.GV22106@redhat.com> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >The attached patch fixes >https://fedorahosted.org/freeipa/ticket/5198 > >Thanks, >Fraser >From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 >From: Fraser Tweedale >Date: Thu, 13 Aug 2015 02:32:54 -0400 >Subject: [PATCH] Prohibit deletion of included profiles > >Deletion of included profiles, including the default profile, should >not be allowed. Detect this case and raise an error. > >Also update the included profiles collection to use namedtuple, >making it easier to access the various components. > >Fixes: https://fedorahosted.org/freeipa/ticket/5198 >--- > ipalib/plugins/certprofile.py | 13 +++++++++++-- > ipapython/dogtag.py | 8 +++++--- > 2 files changed, 16 insertions(+), 5 deletions(-) > >diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py >index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 >--- a/ipalib/plugins/certprofile.py >+++ b/ipalib/plugins/certprofile.py >@@ -3,6 +3,7 @@ > # > > import re >+from operator import attrgetter > > from ipalib import api, Bool, File, Str > from ipalib import output, util >@@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( > from ipalib.request import context > from ipalib import ngettext > from ipalib.text import _ >+from ipapython.dogtag import INCLUDED_PROFILES > from ipapython.version import API_VERSION > > from ipalib import errors >@@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): > __doc__ = _("Delete a Certificate Profile.") > msg_summary = _('Deleted profile "%(value)s"') > >- def execute(self, *args, **kwargs): >+ def pre_callback(self, ldap, dn, *keys, **options): > ca_enabled_check() >- return super(certprofile_del, self).execute(*args, **kwargs) >+ >+ if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): >+ raise errors.ValidationError(name='profile_id', >+ error=_("Included profile '%(profile_id)s' cannot be deleted") >+ % {'profile_id': keys[0]} >+ ) >+ >+ return dn I think you also want to protect the included profiles from renaming. And I would change 'Included profile ... cannot be deleted' to 'Predefined profile ... cannot be deleted'. > > def post_callback(self, ldap, dn, *keys, **options): > with self.api.Backend.ra_certprofile as profile_api: >diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py >index 99bdf066d64d626af05d93953117909c5fbfb693..fc4154719e31eb32e28587ea89fb04ead14d282e 100644 >--- a/ipapython/dogtag.py >+++ b/ipapython/dogtag.py >@@ -17,6 +17,7 @@ > # along with this program. If not, see . > # > >+import collections > import os > import httplib > import xml.dom.minidom >@@ -42,10 +43,11 @@ from ipapython.ipa_log_manager import * > # the configured version. > > >+Profile = collections.namedtuple('Profile', ['profile_id', 'description', 'store_issued']) >+ > INCLUDED_PROFILES = { >- # ( profile_id , description , store_issued) >- (u'caIPAserviceCert', u'Standard profile for network services', True), >- (u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), >+ Profile(u'caIPAserviceCert', u'Standard profile for network services', True), >+ Profile(u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), > } > > DEFAULT_PROFILE = u'caIPAserviceCert' >-- >2.4.3 > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy From msimacek at redhat.com Thu Aug 13 07:38:25 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Thu, 13 Aug 2015 09:38:25 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55BF1761.4090600@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> Message-ID: <55CC4971.5090105@redhat.com> On 2015-08-03 09:25, Jan Cholasta wrote: > Dne 31.7.2015 v 20:20 Simo Sorce napsal(a): >> On Fri, 2015-07-31 at 16:41 +0200, Michael ?im??ek wrote: >>> On 2015-07-31 07:52, Jan Cholasta wrote: >>>> Hi Michael, >>>> >>>> Dne 29.7.2015 v 10:09 Michael ?im??ek napsal(a): >>>>> Hi, >>>>> >>>>> this is the first attempt to port FreeIPA from deprecated >>>>> python3-incompatible python-krbV library to python-gssapi. The patch >>>>> depends on python-kerberos->python-gssapi patch [1] to apply cleanly, >>>>> but the overlap is small, so I think it can be at least partially >>>>> reviewed without it. >>>>> >>>>> Comments: >>>>> I removed Backend.krb and KRB5_CCache classes as they were wrappers >>>>> around krbV classes. I added few utility functions to krb_utils module >>>>> that perform part of its functionality (no need for classes, because >>>>> gssapi acquire calls don't pass any context objects, they wouldn't >>>>> have >>>>> any state). >>>>> >>>>> I merged the two different kinit_keytab functions. >>>>> >>>>> GSSAPI doesn't provide any method (that I'm aware of) to get default >>>>> ccache name. In most cases this is not needed as we can simply not >>>>> pass >>>>> any name and it will use the default. The ldap plugin had to be >>>>> adjusted >>>>> for this - the connect method now takes new use_gssapi argument, which >>>>> can turn on gssapi support without the need to supply explicit ccache >>>>> name. The only place where the ccache name is really needed is the >>>>> test >>>>> server, where I use system klist command to obtain it. >>>> >>>> I would prefer if the semantics were the same as in IPAdmin, i.e. >>>> GSSAPI >>>> is used by default if bind password is not specified, see >>>> IPAdmin.do_bind() in ipapython.ipaldap. >>> >>> Just to clarify, the current flow in ldap module is: >>> if ccache: # I added "or use_gssapi" here in this patch >>> gssapi_bind >>> elif autobind: >>> external_bind >>> else: >>> simple_bind >> >> I had to make this change as well for my replica promotion code, and >> incidentally used the same indicator "use_gssapi". >> >>> and you would like it to be changed into: >>> if bind_pw: >>> simple_bind >>> elif autobind: >>> external_bind >>> else: >>> gssapi_bind >>> >>> Is that correct? > > Actually this is what IPAdmin does: > > def do_bind(self, dm_password="", autobind=AUTOBIND_AUTO, > timeout=DEFAULT_TIMEOUT): > if dm_password: > self.do_simple_bind(bindpw=dm_password, timeout=timeout) > return > if autobind != AUTOBIND_DISABLED and os.getegid() == 0 and > self.ldapi: > try: > # autobind > pw_name = pwd.getpwuid(os.geteuid()).pw_name > self.do_external_bind(pw_name, timeout=timeout) > return > except errors.NotFound, e: > if autobind == AUTOBIND_ENABLED: > # autobind was required and failed, raise > # exception that it failed > raise > > #fall back > self.do_sasl_gssapi_bind(timeout=timeout) > >> >> I think this is what Jan wanted, but I am wondering if it is the right >> thing to do. In ipa we have basically 2 possible default approaches. >> One is to use GSSAPI, and one is to use LDAPI with external bind. >> >> The latter makes sense mostly only when running as root, so I am >> wondering, should the default change depending on whether we are root >> and we are connecting to the local LDAP server ? >> >> If this is a sensible option it means we have to preserver use_gssapi as >> we may need to force use of gssapi in some case even when we are root >> and connectiong to the local server (for example to test that the local >> ccache can successfully be used). >> >> Jan, >> what do you think ? > > I think GSSAPI should be the default and EXTERNAL should be opt-in, like > in IPAdmin, see above. > >> >>>> >>>>> >>>>> It's also not possible to directly get default realm name, what I >>>>> do is >>>>> importing nonexistent name, cannonicalizing it and extracting the >>>>> realm >>>>> from it. Which should work but is ugly. It would be better if we could >>>>> modify the places that use it to not need it at all, but it's mostly >>>>> used in ldap code and I don't understand that part of FreeIPA. >>>>> Alternative would be parsing /etc/krb.conf. >>>> >>>> You should use api.env.realm where possible. I think this should be >>>> most >>>> of the places where default realm is currently used, if not all of >>>> them. >>> >>> That would be great if all the usages could be replaced. How can I >>> determine where api.env.realm can be used? In particular, I'm unsure >>> about ipapython/config.py/__discover_config and >>> ipaserver/plugins/join.py. > > I would just remove the code from __discover_config. It is used to get > realm name in case it is not configured in /etc/ipa/default.conf, but it > is called only from ipa-compat-manage and ipa-nis-manage, which can be > run only on IPA server, and IPA server won't work if realm is not > configured. > > As for join.py, you can just return api.env.realm in get_realm(). > >> >> try: >> realm = api.env.realm >> except: >> realm = dirty gssapi trick ? > > Please don't, you should always be able to choose the correct one > instead of guessing. > Attaching new revision of the patch. Changes from the previous: - ldap2's connect now chooses the bind type same way as in ipaldap - get_default_realm usages replaced by api.env.realm - fixed missing third kinit attempt in trust-fetch-domains - removed rewrapping gssapi errors to ccache errors in krb_utils - updated some parts of exception handling Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-3-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 69772 bytes Desc: not available URL: From lkrispen at redhat.com Thu Aug 13 07:55:06 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 13 Aug 2015 09:55:06 +0200 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55C866D5.5040808@redhat.com> References: <55C866D5.5040808@redhat.com> Message-ID: <55CC4D5A.7030207@redhat.com> On 08/10/2015 10:54 AM, Oleg Fayans wrote: > Hi Ludwig, > > It seems the Design page for the topology plugin is a bit outdated. > 1. It still operates with the terms like plugin version > (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), > although it was generally agreed, that we do not use plugin version at > all. > > 2. The section > http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition > should be a bit clarified: > Does this mean, that if we prepare a replica from a master that has > domainlevel = 1, then the replica, that already had a domain level = 0 > will raise it? Do we support this scenario at all? > > 3. Segment directions. Currently there is no way to specify segment > direction using the cli `ipa topologysegment-add`. However the > direction is shown with `ipa topologysegment-find` and `ipa > topologysegment-show`, which leads to confusing of the users. We > probably should remove this info from the output at all and update the > design page accordingly. this is not true, in segment add youcan specify the direction: adding the segment: ------------- [root at vm-215 ~]# ipa topologysegment-add realm Left node: vm-112.abc.idm.lab.eng.brq.redhat.com Right node: vm-179.abc.idm.lab.eng.brq.redhat.com Connectivity [both]: left-right Segment name [vm-112.abc.idm.lab.eng.brq.redhat.com-to-vm-179.abc.idm.lab.eng.brq.redhat.com]: onedirect ------------------------- Added segment "onedirect" ------------------------- Segment name: onedirect Left node: vm-112.abc.idm.lab.eng.brq.redhat.com Right node: vm-179.abc.idm.lab.eng.brq.redhat.com Connectivity: left-right checking the segment: [root at vm-215 ~]# ipa topologysegment-find realm ------------------ ..... ------------------ Segment name: onedirect Left node: vm-112.abc.idm.lab.eng.brq.redhat.com Right node: vm-179.abc.idm.lab.eng.brq.redhat.com Connectivity: left-right ...... From ftweedal at redhat.com Thu Aug 13 07:57:54 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 17:57:54 +1000 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles In-Reply-To: <20150813065335.GV22106@redhat.com> References: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> <20150813065335.GV22106@redhat.com> Message-ID: <20150813075754.GU16439@dhcp-40-8.bne.redhat.com> On Thu, Aug 13, 2015 at 09:53:35AM +0300, Alexander Bokovoy wrote: > On Thu, 13 Aug 2015, Fraser Tweedale wrote: > >The attached patch fixes > >https://fedorahosted.org/freeipa/ticket/5198 > > > >Thanks, > >Fraser > > >From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 > >From: Fraser Tweedale > >Date: Thu, 13 Aug 2015 02:32:54 -0400 > >Subject: [PATCH] Prohibit deletion of included profiles > > > >Deletion of included profiles, including the default profile, should > >not be allowed. Detect this case and raise an error. > > > >Also update the included profiles collection to use namedtuple, > >making it easier to access the various components. > > > >Fixes: https://fedorahosted.org/freeipa/ticket/5198 > >--- > >ipalib/plugins/certprofile.py | 13 +++++++++++-- > >ipapython/dogtag.py | 8 +++++--- > >2 files changed, 16 insertions(+), 5 deletions(-) > > > >diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py > >index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 > >--- a/ipalib/plugins/certprofile.py > >+++ b/ipalib/plugins/certprofile.py > >@@ -3,6 +3,7 @@ > ># > > > >import re > >+from operator import attrgetter > > > >from ipalib import api, Bool, File, Str > >from ipalib import output, util > >@@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( > >from ipalib.request import context > >from ipalib import ngettext > >from ipalib.text import _ > >+from ipapython.dogtag import INCLUDED_PROFILES > >from ipapython.version import API_VERSION > > > >from ipalib import errors > >@@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): > > __doc__ = _("Delete a Certificate Profile.") > > msg_summary = _('Deleted profile "%(value)s"') > > > >- def execute(self, *args, **kwargs): > >+ def pre_callback(self, ldap, dn, *keys, **options): > > ca_enabled_check() > >- return super(certprofile_del, self).execute(*args, **kwargs) > >+ > >+ if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): > >+ raise errors.ValidationError(name='profile_id', > >+ error=_("Included profile '%(profile_id)s' cannot be deleted") > >+ % {'profile_id': keys[0]} > >+ ) > >+ > >+ return dn > I think you also want to protect the included profiles from renaming. > This is already the case. > And I would change 'Included profile ... cannot be deleted' to > 'Predefined profile ... cannot be deleted'. > Fair enough; updated patch attached. Cheers, Fraser -------------- next part -------------- From 4dd4e7c273a04e8b386c229959a99d6ec8e55c14 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Thu, 13 Aug 2015 02:32:54 -0400 Subject: [PATCH] Prohibit deletion of predefined profiles Deletion of predefined profiles, including the default profile, should not be allowed. Detect this case and raise an error. Also update the predefined profiles collection to use namedtuple, making it easier to access the various components. Fixes: https://fedorahosted.org/freeipa/ticket/5198 --- ipalib/plugins/certprofile.py | 13 +++++++++++-- ipapython/dogtag.py | 8 +++++--- 2 files changed, 16 insertions(+), 5 deletions(-) diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 1dd4f403ee4461b83c053eb36019a8896506bb81..007cc543406b7e5705fd7474f3685cd6a9ce6aca 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -3,6 +3,7 @@ # import re +from operator import attrgetter from ipalib import api, Bool, File, Str from ipalib import output, util @@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( from ipalib.request import context from ipalib import ngettext from ipalib.text import _ +from ipapython.dogtag import INCLUDED_PROFILES from ipapython.version import API_VERSION from ipalib import errors @@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): __doc__ = _("Delete a Certificate Profile.") msg_summary = _('Deleted profile "%(value)s"') - def execute(self, *args, **kwargs): + def pre_callback(self, ldap, dn, *keys, **options): ca_enabled_check() - return super(certprofile_del, self).execute(*args, **kwargs) + + if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): + raise errors.ValidationError(name='profile_id', + error=_("Predefined profile '%(profile_id)s' cannot be deleted") + % {'profile_id': keys[0]} + ) + + return dn def post_callback(self, ldap, dn, *keys, **options): with self.api.Backend.ra_certprofile as profile_api: diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 99bdf066d64d626af05d93953117909c5fbfb693..fc4154719e31eb32e28587ea89fb04ead14d282e 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -17,6 +17,7 @@ # along with this program. If not, see . # +import collections import os import httplib import xml.dom.minidom @@ -42,10 +43,11 @@ from ipapython.ipa_log_manager import * # the configured version. +Profile = collections.namedtuple('Profile', ['profile_id', 'description', 'store_issued']) + INCLUDED_PROFILES = { - # ( profile_id , description , store_issued) - (u'caIPAserviceCert', u'Standard profile for network services', True), - (u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), + Profile(u'caIPAserviceCert', u'Standard profile for network services', True), + Profile(u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), } DEFAULT_PROFILE = u'caIPAserviceCert' -- 2.4.3 From pvoborni at redhat.com Thu Aug 13 08:49:29 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Aug 2015 10:49:29 +0200 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55CC4D5A.7030207@redhat.com> References: <55C866D5.5040808@redhat.com> <55CC4D5A.7030207@redhat.com> Message-ID: <55CC5A19.2070305@redhat.com> On 08/13/2015 09:55 AM, Ludwig Krispenz wrote: > > On 08/10/2015 10:54 AM, Oleg Fayans wrote: >> Hi Ludwig, >> >> It seems the Design page for the topology plugin is a bit outdated. >> 1. It still operates with the terms like plugin version >> (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), >> although it was generally agreed, that we do not use plugin version at >> all. >> >> 2. The section >> http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition >> should be a bit clarified: >> Does this mean, that if we prepare a replica from a master that has >> domainlevel = 1, then the replica, that already had a domain level = 0 >> will raise it? Do we support this scenario at all? >> >> 3. Segment directions. Currently there is no way to specify segment >> direction using the cli `ipa topologysegment-add`. However the >> direction is shown with `ipa topologysegment-find` and `ipa >> topologysegment-show`, which leads to confusing of the users. We >> probably should remove this info from the output at all and update the >> design page accordingly. > this is not true, in segment add youcan specify the direction: > > adding the segment: > ------------- > [root at vm-215 ~]# ipa topologysegment-add realm > Left node: vm-112.abc.idm.lab.eng.brq.redhat.com > Right node: vm-179.abc.idm.lab.eng.brq.redhat.com > Connectivity [both]: left-right > Segment name > [vm-112.abc.idm.lab.eng.brq.redhat.com-to-vm-179.abc.idm.lab.eng.brq.redhat.com]: > onedirect > ------------------------- > Added segment "onedirect" > ------------------------- > Segment name: onedirect > Left node: vm-112.abc.idm.lab.eng.brq.redhat.com > Right node: vm-179.abc.idm.lab.eng.brq.redhat.com > Connectivity: left-right > > > checking the segment: > > [root at vm-215 ~]# ipa topologysegment-find realm > ------------------ > ..... > ------------------ > Segment name: onedirect > Left node: vm-112.abc.idm.lab.eng.brq.redhat.com > Right node: vm-179.abc.idm.lab.eng.brq.redhat.com > Connectivity: left-right > > ...... > This is a bug. Option "direction" was removed from -add and -mod commands on purpose. But CLI still incorrectly asks for the value and therefore allows to change the default "both". -- Petr Vobornik From abokovoy at redhat.com Thu Aug 13 09:01:09 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Aug 2015 12:01:09 +0300 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles In-Reply-To: <20150813075754.GU16439@dhcp-40-8.bne.redhat.com> References: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> <20150813065335.GV22106@redhat.com> <20150813075754.GU16439@dhcp-40-8.bne.redhat.com> Message-ID: <20150813090109.GW22106@redhat.com> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >On Thu, Aug 13, 2015 at 09:53:35AM +0300, Alexander Bokovoy wrote: >> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >> >The attached patch fixes >> >https://fedorahosted.org/freeipa/ticket/5198 >> > >> >Thanks, >> >Fraser >> >> >From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 >> >From: Fraser Tweedale >> >Date: Thu, 13 Aug 2015 02:32:54 -0400 >> >Subject: [PATCH] Prohibit deletion of included profiles >> > >> >Deletion of included profiles, including the default profile, should >> >not be allowed. Detect this case and raise an error. >> > >> >Also update the included profiles collection to use namedtuple, >> >making it easier to access the various components. >> > >> >Fixes: https://fedorahosted.org/freeipa/ticket/5198 >> >--- >> >ipalib/plugins/certprofile.py | 13 +++++++++++-- >> >ipapython/dogtag.py | 8 +++++--- >> >2 files changed, 16 insertions(+), 5 deletions(-) >> > >> >diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py >> >index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 >> >--- a/ipalib/plugins/certprofile.py >> >+++ b/ipalib/plugins/certprofile.py >> >@@ -3,6 +3,7 @@ >> ># >> > >> >import re >> >+from operator import attrgetter >> > >> >from ipalib import api, Bool, File, Str >> >from ipalib import output, util >> >@@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( >> >from ipalib.request import context >> >from ipalib import ngettext >> >from ipalib.text import _ >> >+from ipapython.dogtag import INCLUDED_PROFILES >> >from ipapython.version import API_VERSION >> > >> >from ipalib import errors >> >@@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): >> > __doc__ = _("Delete a Certificate Profile.") >> > msg_summary = _('Deleted profile "%(value)s"') >> > >> >- def execute(self, *args, **kwargs): >> >+ def pre_callback(self, ldap, dn, *keys, **options): >> > ca_enabled_check() >> >- return super(certprofile_del, self).execute(*args, **kwargs) >> >+ >> >+ if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): >> >+ raise errors.ValidationError(name='profile_id', >> >+ error=_("Included profile '%(profile_id)s' cannot be deleted") >> >+ % {'profile_id': keys[0]} >> >+ ) >> >+ >> >+ return dn >> I think you also want to protect the included profiles from renaming. >> >This is already the case. I'm also wondering about certprofile-mod changing the profile content and changing profileID there to point to existing profile. Would this affect CA operation? (ACK below for the current code). > >> And I would change 'Included profile ... cannot be deleted' to >> 'Predefined profile ... cannot be deleted'. >> >Fair enough; updated patch attached. > >Cheers, >Fraser >From 4dd4e7c273a04e8b386c229959a99d6ec8e55c14 Mon Sep 17 00:00:00 2001 >From: Fraser Tweedale >Date: Thu, 13 Aug 2015 02:32:54 -0400 >Subject: [PATCH] Prohibit deletion of predefined profiles > >Deletion of predefined profiles, including the default profile, >should not be allowed. Detect this case and raise an error. > >Also update the predefined profiles collection to use namedtuple, >making it easier to access the various components. > >Fixes: https://fedorahosted.org/freeipa/ticket/5198 >--- > ipalib/plugins/certprofile.py | 13 +++++++++++-- > ipapython/dogtag.py | 8 +++++--- > 2 files changed, 16 insertions(+), 5 deletions(-) > >diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py >index 1dd4f403ee4461b83c053eb36019a8896506bb81..007cc543406b7e5705fd7474f3685cd6a9ce6aca 100644 >--- a/ipalib/plugins/certprofile.py >+++ b/ipalib/plugins/certprofile.py >@@ -3,6 +3,7 @@ > # > > import re >+from operator import attrgetter > > from ipalib import api, Bool, File, Str > from ipalib import output, util >@@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( > from ipalib.request import context > from ipalib import ngettext > from ipalib.text import _ >+from ipapython.dogtag import INCLUDED_PROFILES > from ipapython.version import API_VERSION > > from ipalib import errors >@@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): > __doc__ = _("Delete a Certificate Profile.") > msg_summary = _('Deleted profile "%(value)s"') > >- def execute(self, *args, **kwargs): >+ def pre_callback(self, ldap, dn, *keys, **options): > ca_enabled_check() >- return super(certprofile_del, self).execute(*args, **kwargs) >+ >+ if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): >+ raise errors.ValidationError(name='profile_id', >+ error=_("Predefined profile '%(profile_id)s' cannot be deleted") >+ % {'profile_id': keys[0]} >+ ) >+ >+ return dn > > def post_callback(self, ldap, dn, *keys, **options): > with self.api.Backend.ra_certprofile as profile_api: >diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py >index 99bdf066d64d626af05d93953117909c5fbfb693..fc4154719e31eb32e28587ea89fb04ead14d282e 100644 >--- a/ipapython/dogtag.py >+++ b/ipapython/dogtag.py >@@ -17,6 +17,7 @@ > # along with this program. If not, see . > # > >+import collections > import os > import httplib > import xml.dom.minidom >@@ -42,10 +43,11 @@ from ipapython.ipa_log_manager import * > # the configured version. > > >+Profile = collections.namedtuple('Profile', ['profile_id', 'description', 'store_issued']) >+ > INCLUDED_PROFILES = { >- # ( profile_id , description , store_issued) >- (u'caIPAserviceCert', u'Standard profile for network services', True), >- (u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), >+ Profile(u'caIPAserviceCert', u'Standard profile for network services', True), >+ Profile(u'IECUserRoles', u'User profile that includes IECUserRoles extension from request', True), > } > > DEFAULT_PROFILE = u'caIPAserviceCert' >-- >2.4.3 > ACK. -- / Alexander Bokovoy From pvoborni at redhat.com Thu Aug 13 09:04:42 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Aug 2015 11:04:42 +0200 Subject: [Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates In-Reply-To: <20150813032836.GO16439@dhcp-40-8.bne.redhat.com> References: <55CB4296.3020103@redhat.com> <20150813032836.GO16439@dhcp-40-8.bne.redhat.com> Message-ID: <55CC5DAA.4000307@redhat.com> On 08/13/2015 05:28 AM, Fraser Tweedale wrote: > On Wed, Aug 12, 2015 at 02:56:54PM +0200, Petr Vobornik wrote: >> usercertificate attr was moved from "System Modify Users" to this >> new permission. >> >> https://fedorahosted.org/freeipa/ticket/5177 >> >> Note: hosts have permission "System: Manage Host Certificates", services >> don't have it but usercertificate is in "System: Modify Services". I would >> move it as well if usercertificate was not the only attr in "System: Modify >> Services". >> > New permission works as expected. > > What are the implications of removing userCertificate attribute from > "Modify Users" ACI? Users could be relying on it given that there > is (until now) no more fine-grained permission. I'm not sure what is the expected ACI upgrade behavior but applying this patch on installed server and running ipa-server-upgrade ends with userCertificate still in "System: Modify Users" permission - it eliminates your worry. The rest of users who still run IPA < 4.2 won't even notice. > > Perhaps we should > > a) use update script to add the new permission to any roles that > have the Modify Users permission, or > b) not remove the userCertificate attribute from the ACI, or > c) deem this change acceptable and leave the patch as-is, in which > case: ACK > > Cheers, > Fraser > -- Petr Vobornik From ftweedal at redhat.com Thu Aug 13 09:22:14 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 19:22:14 +1000 Subject: [Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates In-Reply-To: <55CC5DAA.4000307@redhat.com> References: <55CB4296.3020103@redhat.com> <20150813032836.GO16439@dhcp-40-8.bne.redhat.com> <55CC5DAA.4000307@redhat.com> Message-ID: <20150813092214.GY16439@dhcp-40-8.bne.redhat.com> On Thu, Aug 13, 2015 at 11:04:42AM +0200, Petr Vobornik wrote: > On 08/13/2015 05:28 AM, Fraser Tweedale wrote: > >On Wed, Aug 12, 2015 at 02:56:54PM +0200, Petr Vobornik wrote: > >>usercertificate attr was moved from "System Modify Users" to this > >>new permission. > >> > >>https://fedorahosted.org/freeipa/ticket/5177 > >> > >>Note: hosts have permission "System: Manage Host Certificates", services > >>don't have it but usercertificate is in "System: Modify Services". I would > >>move it as well if usercertificate was not the only attr in "System: Modify > >>Services". > >> > >New permission works as expected. > > > >What are the implications of removing userCertificate attribute from > >"Modify Users" ACI? Users could be relying on it given that there > >is (until now) no more fine-grained permission. > > I'm not sure what is the expected ACI upgrade behavior but applying this > patch on installed server and running ipa-server-upgrade ends with > userCertificate still in "System: Modify Users" permission - it eliminates > your worry. The rest of users who still run IPA < 4.2 won't even notice. > Ah, I see. This raises a different problem: different ACIs on different deployments, depending on when IPA was installed. Unless I am misunderstanding something, isn't that an undesirable situation? Thanks, Fraser > > > >Perhaps we should > > > >a) use update script to add the new permission to any roles that > > have the Modify Users permission, or > >b) not remove the userCertificate attribute from the ACI, or > >c) deem this change acceptable and leave the patch as-is, in which > > case: ACK > > > >Cheers, > >Fraser > > > -- > Petr Vobornik From ftweedal at redhat.com Thu Aug 13 09:27:54 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 19:27:54 +1000 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles In-Reply-To: <20150813090109.GW22106@redhat.com> References: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> <20150813065335.GV22106@redhat.com> <20150813075754.GU16439@dhcp-40-8.bne.redhat.com> <20150813090109.GW22106@redhat.com> Message-ID: <20150813092754.GZ16439@dhcp-40-8.bne.redhat.com> On Thu, Aug 13, 2015 at 12:01:09PM +0300, Alexander Bokovoy wrote: > On Thu, 13 Aug 2015, Fraser Tweedale wrote: > >On Thu, Aug 13, 2015 at 09:53:35AM +0300, Alexander Bokovoy wrote: > >>On Thu, 13 Aug 2015, Fraser Tweedale wrote: > >>>The attached patch fixes > >>>https://fedorahosted.org/freeipa/ticket/5198 > >>> > >>>Thanks, > >>>Fraser > >> > >>>From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 > >>>From: Fraser Tweedale > >>>Date: Thu, 13 Aug 2015 02:32:54 -0400 > >>>Subject: [PATCH] Prohibit deletion of included profiles > >>> > >>>Deletion of included profiles, including the default profile, should > >>>not be allowed. Detect this case and raise an error. > >>> > >>>Also update the included profiles collection to use namedtuple, > >>>making it easier to access the various components. > >>> > >>>Fixes: https://fedorahosted.org/freeipa/ticket/5198 > >>>--- > >>>ipalib/plugins/certprofile.py | 13 +++++++++++-- > >>>ipapython/dogtag.py | 8 +++++--- > >>>2 files changed, 16 insertions(+), 5 deletions(-) > >>> > >>>diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py > >>>index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 > >>>--- a/ipalib/plugins/certprofile.py > >>>+++ b/ipalib/plugins/certprofile.py > >>>@@ -3,6 +3,7 @@ > >>># > >>> > >>>import re > >>>+from operator import attrgetter > >>> > >>>from ipalib import api, Bool, File, Str > >>>from ipalib import output, util > >>>@@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( > >>>from ipalib.request import context > >>>from ipalib import ngettext > >>>from ipalib.text import _ > >>>+from ipapython.dogtag import INCLUDED_PROFILES > >>>from ipapython.version import API_VERSION > >>> > >>>from ipalib import errors > >>>@@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): > >>> __doc__ = _("Delete a Certificate Profile.") > >>> msg_summary = _('Deleted profile "%(value)s"') > >>> > >>>- def execute(self, *args, **kwargs): > >>>+ def pre_callback(self, ldap, dn, *keys, **options): > >>> ca_enabled_check() > >>>- return super(certprofile_del, self).execute(*args, **kwargs) > >>>+ > >>>+ if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): > >>>+ raise errors.ValidationError(name='profile_id', > >>>+ error=_("Included profile '%(profile_id)s' cannot be deleted") > >>>+ % {'profile_id': keys[0]} > >>>+ ) > >>>+ > >>>+ return dn > >>I think you also want to protect the included profiles from renaming. > >> > >This is already the case. > I'm also wondering about certprofile-mod changing the profile content > and changing profileID there to point to existing profile. Would this > affect CA operation? > Renaming profile / changing profile-id / pointing it to a different profile is not possible. Changing profile content *is* currently possible. Given that we have custom profiles now, there is an argument to be made that we should prevent profile-mod for updating the Dogtag configuration of predefined profiles. If we did that, we would probably also want to allow admins to change which is the default profile, i.e. changing the default to some custom profile they added. And if we did that, then perhaps we should let them specify a different default profile for users vs hosts/services! How deep does this rabbit hole go? :) If anyone else has thoughts please chime in! Cheers, Fraser From abokovoy at redhat.com Thu Aug 13 09:30:10 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Aug 2015 12:30:10 +0300 Subject: [Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates In-Reply-To: <20150813092214.GY16439@dhcp-40-8.bne.redhat.com> References: <55CB4296.3020103@redhat.com> <20150813032836.GO16439@dhcp-40-8.bne.redhat.com> <55CC5DAA.4000307@redhat.com> <20150813092214.GY16439@dhcp-40-8.bne.redhat.com> Message-ID: <20150813093010.GX22106@redhat.com> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >On Thu, Aug 13, 2015 at 11:04:42AM +0200, Petr Vobornik wrote: >> On 08/13/2015 05:28 AM, Fraser Tweedale wrote: >> >On Wed, Aug 12, 2015 at 02:56:54PM +0200, Petr Vobornik wrote: >> >>usercertificate attr was moved from "System Modify Users" to this >> >>new permission. >> >> >> >>https://fedorahosted.org/freeipa/ticket/5177 >> >> >> >>Note: hosts have permission "System: Manage Host Certificates", services >> >>don't have it but usercertificate is in "System: Modify Services". I would >> >>move it as well if usercertificate was not the only attr in "System: Modify >> >>Services". >> >> >> >New permission works as expected. >> > >> >What are the implications of removing userCertificate attribute from >> >"Modify Users" ACI? Users could be relying on it given that there >> >is (until now) no more fine-grained permission. >> >> I'm not sure what is the expected ACI upgrade behavior but applying this >> patch on installed server and running ipa-server-upgrade ends with >> userCertificate still in "System: Modify Users" permission - it eliminates >> your worry. The rest of users who still run IPA < 4.2 won't even notice. >> >Ah, I see. > >This raises a different problem: different ACIs on different >deployments, depending on when IPA was installed. Unless I am >misunderstanding something, isn't that an undesirable situation? We have precedent of upgrading ACIs via upgrade plugins. So this is something we need to design for and execute. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Aug 13 09:31:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Aug 2015 12:31:27 +0300 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles In-Reply-To: <20150813092754.GZ16439@dhcp-40-8.bne.redhat.com> References: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> <20150813065335.GV22106@redhat.com> <20150813075754.GU16439@dhcp-40-8.bne.redhat.com> <20150813090109.GW22106@redhat.com> <20150813092754.GZ16439@dhcp-40-8.bne.redhat.com> Message-ID: <20150813093127.GY22106@redhat.com> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >On Thu, Aug 13, 2015 at 12:01:09PM +0300, Alexander Bokovoy wrote: >> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >> >On Thu, Aug 13, 2015 at 09:53:35AM +0300, Alexander Bokovoy wrote: >> >>On Thu, 13 Aug 2015, Fraser Tweedale wrote: >> >>>The attached patch fixes >> >>>https://fedorahosted.org/freeipa/ticket/5198 >> >>> >> >>>Thanks, >> >>>Fraser >> >> >> >>>From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 >> >>>From: Fraser Tweedale >> >>>Date: Thu, 13 Aug 2015 02:32:54 -0400 >> >>>Subject: [PATCH] Prohibit deletion of included profiles >> >>> >> >>>Deletion of included profiles, including the default profile, should >> >>>not be allowed. Detect this case and raise an error. >> >>> >> >>>Also update the included profiles collection to use namedtuple, >> >>>making it easier to access the various components. >> >>> >> >>>Fixes: https://fedorahosted.org/freeipa/ticket/5198 >> >>>--- >> >>>ipalib/plugins/certprofile.py | 13 +++++++++++-- >> >>>ipapython/dogtag.py | 8 +++++--- >> >>>2 files changed, 16 insertions(+), 5 deletions(-) >> >>> >> >>>diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py >> >>>index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 >> >>>--- a/ipalib/plugins/certprofile.py >> >>>+++ b/ipalib/plugins/certprofile.py >> >>>@@ -3,6 +3,7 @@ >> >>># >> >>> >> >>>import re >> >>>+from operator import attrgetter >> >>> >> >>>from ipalib import api, Bool, File, Str >> >>>from ipalib import output, util >> >>>@@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( >> >>>from ipalib.request import context >> >>>from ipalib import ngettext >> >>>from ipalib.text import _ >> >>>+from ipapython.dogtag import INCLUDED_PROFILES >> >>>from ipapython.version import API_VERSION >> >>> >> >>>from ipalib import errors >> >>>@@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): >> >>> __doc__ = _("Delete a Certificate Profile.") >> >>> msg_summary = _('Deleted profile "%(value)s"') >> >>> >> >>>- def execute(self, *args, **kwargs): >> >>>+ def pre_callback(self, ldap, dn, *keys, **options): >> >>> ca_enabled_check() >> >>>- return super(certprofile_del, self).execute(*args, **kwargs) >> >>>+ >> >>>+ if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): >> >>>+ raise errors.ValidationError(name='profile_id', >> >>>+ error=_("Included profile '%(profile_id)s' cannot be deleted") >> >>>+ % {'profile_id': keys[0]} >> >>>+ ) >> >>>+ >> >>>+ return dn >> >>I think you also want to protect the included profiles from renaming. >> >> >> >This is already the case. >> I'm also wondering about certprofile-mod changing the profile content >> and changing profileID there to point to existing profile. Would this >> affect CA operation? >> >Renaming profile / changing profile-id / pointing it to a different >profile is not possible. > >Changing profile content *is* currently possible. Given that we >have custom profiles now, there is an argument to be made that we >should prevent profile-mod for updating the Dogtag configuration of >predefined profiles. > >If we did that, we would probably also want to allow admins to >change which is the default profile, i.e. changing the default to >some custom profile they added. > >And if we did that, then perhaps we should let them specify a >different default profile for users vs hosts/services! > >How deep does this rabbit hole go? :) All the above makes sense and should be done in terms of proper hardening and usability fixes. I don't think it is a bottomless hole, though, just a normal work we have to do to make certificate profiles nice and usable :) -- / Alexander Bokovoy From ftweedal at redhat.com Thu Aug 13 10:09:44 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 20:09:44 +1000 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles In-Reply-To: <20150813093127.GY22106@redhat.com> References: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> <20150813065335.GV22106@redhat.com> <20150813075754.GU16439@dhcp-40-8.bne.redhat.com> <20150813090109.GW22106@redhat.com> <20150813092754.GZ16439@dhcp-40-8.bne.redhat.com> <20150813093127.GY22106@redhat.com> Message-ID: <20150813100944.GA16439@dhcp-40-8.bne.redhat.com> On Thu, Aug 13, 2015 at 12:31:27PM +0300, Alexander Bokovoy wrote: > On Thu, 13 Aug 2015, Fraser Tweedale wrote: > >On Thu, Aug 13, 2015 at 12:01:09PM +0300, Alexander Bokovoy wrote: > >>On Thu, 13 Aug 2015, Fraser Tweedale wrote: > >>>On Thu, Aug 13, 2015 at 09:53:35AM +0300, Alexander Bokovoy wrote: > >>>>On Thu, 13 Aug 2015, Fraser Tweedale wrote: > >>>>>The attached patch fixes > >>>>>https://fedorahosted.org/freeipa/ticket/5198 > >>>>> > >>>>>Thanks, > >>>>>Fraser > >>>> > >>>>>From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 > >>>>>From: Fraser Tweedale > >>>>>Date: Thu, 13 Aug 2015 02:32:54 -0400 > >>>>>Subject: [PATCH] Prohibit deletion of included profiles > >>>>> > >>>>>Deletion of included profiles, including the default profile, should > >>>>>not be allowed. Detect this case and raise an error. > >>>>> > >>>>>Also update the included profiles collection to use namedtuple, > >>>>>making it easier to access the various components. > >>>>> > >>>>>Fixes: https://fedorahosted.org/freeipa/ticket/5198 > >>>>>--- > >>>>>ipalib/plugins/certprofile.py | 13 +++++++++++-- > >>>>>ipapython/dogtag.py | 8 +++++--- > >>>>>2 files changed, 16 insertions(+), 5 deletions(-) > >>>>> > >>>>>diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py > >>>>>index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 > >>>>>--- a/ipalib/plugins/certprofile.py > >>>>>+++ b/ipalib/plugins/certprofile.py > >>>>>@@ -3,6 +3,7 @@ > >>>>># > >>>>> > >>>>>import re > >>>>>+from operator import attrgetter > >>>>> > >>>>>from ipalib import api, Bool, File, Str > >>>>>from ipalib import output, util > >>>>>@@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( > >>>>>from ipalib.request import context > >>>>>from ipalib import ngettext > >>>>>from ipalib.text import _ > >>>>>+from ipapython.dogtag import INCLUDED_PROFILES > >>>>>from ipapython.version import API_VERSION > >>>>> > >>>>>from ipalib import errors > >>>>>@@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): > >>>>> __doc__ = _("Delete a Certificate Profile.") > >>>>> msg_summary = _('Deleted profile "%(value)s"') > >>>>> > >>>>>- def execute(self, *args, **kwargs): > >>>>>+ def pre_callback(self, ldap, dn, *keys, **options): > >>>>> ca_enabled_check() > >>>>>- return super(certprofile_del, self).execute(*args, **kwargs) > >>>>>+ > >>>>>+ if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): > >>>>>+ raise errors.ValidationError(name='profile_id', > >>>>>+ error=_("Included profile '%(profile_id)s' cannot be deleted") > >>>>>+ % {'profile_id': keys[0]} > >>>>>+ ) > >>>>>+ > >>>>>+ return dn > >>>>I think you also want to protect the included profiles from renaming. > >>>> > >>>This is already the case. > >>I'm also wondering about certprofile-mod changing the profile content > >>and changing profileID there to point to existing profile. Would this > >>affect CA operation? > >> > >Renaming profile / changing profile-id / pointing it to a different > >profile is not possible. > > > >Changing profile content *is* currently possible. Given that we > >have custom profiles now, there is an argument to be made that we > >should prevent profile-mod for updating the Dogtag configuration of > >predefined profiles. > > > >If we did that, we would probably also want to allow admins to > >change which is the default profile, i.e. changing the default to > >some custom profile they added. > > > >And if we did that, then perhaps we should let them specify a > >different default profile for users vs hosts/services! > > > >How deep does this rabbit hole go? :) > All the above makes sense and should be done in terms of proper > hardening and usability fixes. I don't think it is a bottomless hole, > though, just a normal work we have to do to make certificate profiles > nice and usable :) > Right; I'll file tickets for these explored regions of the hole, and leave the unexplored depths for another day. > -- > / Alexander Bokovoy From pvoborni at redhat.com Thu Aug 13 10:10:13 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Aug 2015 12:10:13 +0200 Subject: [Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client In-Reply-To: <55B134B6.1020209@redhat.com> References: <55B134B6.1020209@redhat.com> Message-ID: <55CC6D05.10207@redhat.com> On 07/23/2015 08:38 PM, Christian Heimes wrote: > The ipa vault commands now load the public keys in order to verify them. > The validation also prevents a user from accidentally sending her > private keys to the server. The patch fixes #5142 and #5142. > > $ ./ipa vault-add AsymmetricVault --desc "Asymmetric vault" --type > asymmetric --public-key-file mykey.pem > ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault > public key: Could not unserialize key data. > > https://fedorahosted.org/freeipa/ticket/5142 > https://fedorahosted.org/freeipa/ticket/5143 > ACK as fix for 5142. I don't think that it fixes 5143. The traceback is fixed therefore 5143 doesn't occur but if there was other traceback raised by `self.api.Command.vault_archive(*args, **opts)` then the vault added in `response = self.api.Command.vault_add_internal(*args, **options)` would be still created. -- Petr Vobornik From lkrispen at redhat.com Thu Aug 13 10:13:25 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 13 Aug 2015 12:13:25 +0200 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55CC5A19.2070305@redhat.com> References: <55C866D5.5040808@redhat.com> <55CC4D5A.7030207@redhat.com> <55CC5A19.2070305@redhat.com> Message-ID: <55CC6DC5.4090905@redhat.com> On 08/13/2015 10:49 AM, Petr Vobornik wrote: > On 08/13/2015 09:55 AM, Ludwig Krispenz wrote: >> >> On 08/10/2015 10:54 AM, Oleg Fayans wrote: >>> Hi Ludwig, >>> >>> It seems the Design page for the topology plugin is a bit outdated. >>> 1. It still operates with the terms like plugin version >>> (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), >>> >>> although it was generally agreed, that we do not use plugin version at >>> all. >>> >>> 2. The section >>> http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition >>> >>> should be a bit clarified: >>> Does this mean, that if we prepare a replica from a master that has >>> domainlevel = 1, then the replica, that already had a domain level = 0 >>> will raise it? Do we support this scenario at all? >>> >>> 3. Segment directions. Currently there is no way to specify segment >>> direction using the cli `ipa topologysegment-add`. However the >>> direction is shown with `ipa topologysegment-find` and `ipa >>> topologysegment-show`, which leads to confusing of the users. We >>> probably should remove this info from the output at all and update the >>> design page accordingly. >> this is not true, in segment add youcan specify the direction: >> >> adding the segment: >> ------------- >> [root at vm-215 ~]# ipa topologysegment-add realm >> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >> Connectivity [both]: left-right >> Segment name >> [vm-112.abc.idm.lab.eng.brq.redhat.com-to-vm-179.abc.idm.lab.eng.brq.redhat.com]: >> >> onedirect >> ------------------------- >> Added segment "onedirect" >> ------------------------- >> Segment name: onedirect >> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >> Connectivity: left-right >> >> >> checking the segment: >> >> [root at vm-215 ~]# ipa topologysegment-find realm >> ------------------ >> ..... >> ------------------ >> Segment name: onedirect >> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >> Connectivity: left-right >> >> ...... >> > > This is a bug. Option "direction" was removed from -add and -mod > commands on purpose. I thought it should only be removed from the mod, as it was not handled in the plugin, but I think initial creation of a one directional segment should be ok > But CLI still incorrectly asks for the value and therefore allows to > change the default "both". From cheimes at redhat.com Thu Aug 13 10:38:29 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 13 Aug 2015 12:38:29 +0200 Subject: [Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client In-Reply-To: <55CC6D05.10207@redhat.com> References: <55B134B6.1020209@redhat.com> <55CC6D05.10207@redhat.com> Message-ID: <55CC73A5.6010604@redhat.com> On 2015-08-13 12:10, Petr Vobornik wrote: > On 07/23/2015 08:38 PM, Christian Heimes wrote: >> The ipa vault commands now load the public keys in order to verify them. >> The validation also prevents a user from accidentally sending her >> private keys to the server. The patch fixes #5142 and #5142. >> >> $ ./ipa vault-add AsymmetricVault --desc "Asymmetric vault" --type >> asymmetric --public-key-file mykey.pem >> ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault >> public key: Could not unserialize key data. >> >> https://fedorahosted.org/freeipa/ticket/5142 >> https://fedorahosted.org/freeipa/ticket/5143 >> > > ACK as fix for 5142. > > I don't think that it fixes 5143. The traceback is fixed therefore 5143 > doesn't occur but if there was other traceback raised by > `self.api.Command.vault_archive(*args, **opts)` then the vault added in > `response = self.api.Command.vault_add_internal(*args, **options)` would > be still created. Yes, that is correct. There aren't any arguments that can lead to an exception. The arguments are either already validated by vault_add() or don't raise an error. Of course there are plenty of opportunities errors. The connection to the IPA or LDAP server could fail, NSS DB could be missing and so on. How should we handle an error in vault_archive? Is there another way then to delete the new vault all along? try: self.api.Command.vault_archive(*args, **opts) except Exception: log_error() self.api.Command.vault_del(*args, **opts) report_error() Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jcholast at redhat.com Thu Aug 13 10:55:39 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Aug 2015 12:55:39 +0200 Subject: [Freeipa-devel] [PATCH] 0038 cert-request: remove allowed extensions check In-Reply-To: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> References: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> Message-ID: <55CC77AB.9090706@redhat.com> Hi, On 13.8.2015 07:54, Fraser Tweedale wrote: > The attached patch fixes > https://fedorahosted.org/freeipa/ticket/5205 Simo wrote this some time ago in a (private) discussion about CSR extensions: On 23.1.2014 18:58, Simo Sorce wrote: > Regardless of which tool we use, I really think we need an API that will > list all the extensions, whether they are understood or not, and then we > need to proceed and check that only 'acceptable' extensions are passed > in. Dogtag will do extra validation for sure, but given IPA does access > control, then IPA needs to be sure of what it is checking. Simo, does this still hold? Fraser's patch removes the check. Is it OK or not? Honza -- Jan Cholasta From pvoborni at redhat.com Thu Aug 13 11:00:41 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Aug 2015 13:00:41 +0200 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55C9993E.9020604@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> <1438690803.20262.25.camel@willson.usersys.redhat.com> <55C0C371.5060000@redhat.com> <55C0DB02.8080306@redhat.com> <55C8F79E.8070405@redhat.com> <55C9993E.9020604@redhat.com> Message-ID: <55CC78D9.8080709@redhat.com> On 08/11/2015 08:42 AM, Jan Cholasta wrote: > On 10.8.2015 21:12, Endi Sukma Dewata wrote: >> On 8/4/2015 10:32 AM, Endi Sukma Dewata wrote: >>>>> Martin, I do not think going on with business as usual is the right >>>>> thing to do here. We know this is going to bite. >>>>> I suggest Endy adds a *new* API if making it backwards compatible is >>>>> not >>>>> possible. The era of bumping whole API version must stop, the sooner >>>>> the >>>>> better. >>>> >>>> My point is that we do not know yet how to do this kind of changes >>>> long term. >>>> So what I did not want to end up are 2 copy&pasted Vault plugins >>>> maintained >>>> forever, differing in just that. >>>> >>>> If you know how to do this without copypasting, I will be fine with >>>> that. >>> >>> We probably can do it like this: >>> * the old plugin continues to provide Vault 1.0 functionality >>> * the new plugin will be a proxy to the old plugin except for the parts >>> that have changed in Vault 1.1. >>> >>> Or the other way around: >>> * the new plugin will provide Vault 1.1 functionality >>> * the old plugin will be a proxy to the new plugin except for the parts >>> that needs to be maintained for Vault 1.0. >>> >>> The first option is probably safer. >>> >>> In any case, IPA 4.2.1 will only provide a single client for Vault 1.1, >>> but two services for Vault 1.0 and 1.1. >> >> A new patch #369-1 is attached. It has been rebased on top of #372 and >> #373 that fix the conflicting parameter while maintaining backward >> compatibility. > > I have modified the first version of the patch to maintain backward > compatibility and not require your patches #372 and #373. Should be much > easier to review. See attachment. > Jan approach seems better to me for 4.2.1. Endi, do you agree with the changes? Could we proceed with the review? -- Petr Vobornik From abokovoy at redhat.com Thu Aug 13 11:36:50 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Aug 2015 14:36:50 +0300 Subject: [Freeipa-devel] [PATCH] 0038 cert-request: remove allowed extensions check In-Reply-To: <55CC77AB.9090706@redhat.com> References: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> <55CC77AB.9090706@redhat.com> Message-ID: <20150813113650.GB22106@redhat.com> On Thu, 13 Aug 2015, Jan Cholasta wrote: >Hi, > >On 13.8.2015 07:54, Fraser Tweedale wrote: >>The attached patch fixes >>https://fedorahosted.org/freeipa/ticket/5205 > >Simo wrote this some time ago in a (private) discussion about CSR >extensions: > >On 23.1.2014 18:58, Simo Sorce wrote: >>Regardless of which tool we use, I really think we need an API that will >>list all the extensions, whether they are understood or not, and then we >>need to proceed and check that only 'acceptable' extensions are passed >>in. Dogtag will do extra validation for sure, but given IPA does access >>control, then IPA needs to be sure of what it is checking. > >Simo, does this still hold? Fraser's patch removes the check. Is it OK >or not? I don't see a contradiction. Nothing prevents us from actually verifying the certificate request against the certificate profile in IPA framework and listing the outcome. This does not require to hardcode actual extensions. -- / Alexander Bokovoy From mrniranjan at fedoraproject.org Thu Aug 13 11:55:01 2015 From: mrniranjan at fedoraproject.org (Niranjan) Date: Thu, 13 Aug 2015 17:25:01 +0530 Subject: [Freeipa-devel] [patch]-pytest-multihost-Return File Attributes to sftp.put Message-ID: <20150813115501.GA29739@mniranja.pnq.redhat.com> Greetings, This patch is regarding pytest-multihost plugin. Including a patch to return FileAttributes for sftp.put function used in the function. Current put_file function in transport.py in ParamikoTransport Class doesn't return any value. So when using this function it's not clear if the operation was sucessfull or not. Returning FileAttributes to put_file function helps in checking if operation was indeed succesful. Requesting feedback on the patch attached. Regards Niranjan -------------- next part -------------- From 5268b93efec39fc0c04f5bd022497143622e87b4 Mon Sep 17 00:00:00 2001 From: Niranjan MR Date: Thu, 13 Aug 2015 17:02:45 +0530 Subject: [PATCH] Return File Attributes to sftp.put This patch passes argument confirm=True to sftp.put function to return file attributes of destination file. Also put_file function now returns FileAttributes of type SFTPAttributes Signed-off-by: Niranjan MR --- pytest_multihost/transport.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/pytest_multihost/transport.py b/pytest_multihost/transport.py index 2b1ccbc32e8ed4b28e263d9bbe2df4bc2c8617de..206aeea6616cfb34bf421009f947145162e187cf 100644 --- a/pytest_multihost/transport.py +++ b/pytest_multihost/transport.py @@ -244,7 +244,8 @@ class ParamikoTransport(Transport): def put_file(self, localpath, remotepath): self.log.info('PUT %s', remotepath) - self.sftp.put(localpath, remotepath) + fileAttributes = self.sftp.put(localpath, remotepath,confirm=True) + return fileAttributes class OpenSSHTransport(Transport): -- 1.9.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From pvoborni at redhat.com Thu Aug 13 12:05:44 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Aug 2015 14:05:44 +0200 Subject: [Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client In-Reply-To: <55CC73A5.6010604@redhat.com> References: <55B134B6.1020209@redhat.com> <55CC6D05.10207@redhat.com> <55CC73A5.6010604@redhat.com> Message-ID: <55CC8818.6050300@redhat.com> On 08/13/2015 12:38 PM, Christian Heimes wrote: > On 2015-08-13 12:10, Petr Vobornik wrote: >> On 07/23/2015 08:38 PM, Christian Heimes wrote: >>> The ipa vault commands now load the public keys in order to verify them. >>> The validation also prevents a user from accidentally sending her >>> private keys to the server. The patch fixes #5142 and #5142. >>> >>> $ ./ipa vault-add AsymmetricVault --desc "Asymmetric vault" --type >>> asymmetric --public-key-file mykey.pem >>> ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault >>> public key: Could not unserialize key data. >>> >>> https://fedorahosted.org/freeipa/ticket/5142 >>> https://fedorahosted.org/freeipa/ticket/5143 >>> >> >> ACK as fix for 5142. >> >> I don't think that it fixes 5143. The traceback is fixed therefore 5143 >> doesn't occur but if there was other traceback raised by >> `self.api.Command.vault_archive(*args, **opts)` then the vault added in >> `response = self.api.Command.vault_add_internal(*args, **options)` would >> be still created. > > Yes, that is correct. There aren't any arguments that can lead to an > exception. The arguments are either already validated by vault_add() or > don't raise an error. > > Of course there are plenty of opportunities errors. The connection to > the IPA or LDAP server could fail, NSS DB could be missing and so on. > How should we handle an error in vault_archive? Is there another way > then to delete the new vault all along? > > try: > self.api.Command.vault_archive(*args, **opts) > except Exception: > log_error() > self.api.Command.vault_del(*args, **opts) > report_error() > > Christian > Imho this is the way. But it may fail because of the same root cause as vault_archive. That said I don't see #5142 as a priority and would defer it. -- Petr Vobornik From mbasti at redhat.com Thu Aug 13 12:09:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Aug 2015 14:09:23 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55C9B8DE.9060907@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> Message-ID: <55CC88F3.90305@redhat.com> On 08/11/2015 10:57 AM, Lenka Doudova wrote: > > > On 08/11/2015 10:06 AM, thierry bordaz wrote: >> On 08/04/2015 01:37 PM, Lenka Doudova wrote: >>> >>> >>> Dne 30.7.2015 v 16:10 Martin Basti napsal(a): >>>> On 30/07/15 16:09, Martin Basti wrote: >>>>> On 29/07/15 16:10, Martin Basti wrote: >>>>>> On 29/07/15 15:29, Lenka Doudova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> thanks a lot for the comments, will work on it tomorrow. >>>>>>> >>>>>>> Lenka >>>>>>> >>>>>>> Dne 29.7.2015 v 15:27 Martin Basti napsal(a): >>>>>>>> On 27/07/15 16:47, Lenka Doudova wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm attaching a patch with automated tests for stageuser >>>>>>>>> plugin (https://fedorahosted.org/freeipa/ticket/3813). The >>>>>>>>> user plugin test is affected as well (one class was added). >>>>>>>>> The tests seem a bit of a mess even to myself, but what with >>>>>>>>> the way freeipa behaves I didn't know how else to implement >>>>>>>>> them, but I'm eager to learn how to do it in a nicer way, if >>>>>>>>> someone has a better idea. >>>>>>>>> >>>>>>>>> Lenka >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I just applied patches: >>>>>>>> >>>>>>>> 1) Please remove whitespace errors >>>>>>>> $ git am >>>>>>>> freeipa-lryznaro-0002-Automated-test-for-stageuser-plugin.patch >>>>>>>> Applying: Automated test for stageuser plugin >>>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:110: >>>>>>>> trailing whitespace. >>>>>>>> """ Tracker class for staged user LDAP object >>>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:113: >>>>>>>> trailing whitespace. >>>>>>>> StageUserTracker object stores information about the user. >>>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:121: >>>>>>>> trailing whitespace. >>>>>>>> u'krbprincipalexpiration', u'usercertificate', u'dn', >>>>>>>> u'has_keytab', u'has_password', >>>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:122: >>>>>>>> trailing whitespace. >>>>>>>> u'street', u'postalcode', u'facsimiletelephonenumber', >>>>>>>> u'carlicense', >>>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:125: >>>>>>>> trailing whitespace. >>>>>>>> u'cn', u'ipauniqueid', u'objectclass', u'description', >>>>>>>> warning: squelched 50 whitespace errors >>>>>>>> warning: 55 lines add whitespace errors. >>>>>>>> >>>>>>>> 2) >>>>>>>> Please use new shorter format of license header >>>>>>>> >>>>>>>> 3) can you fix some of the most serious PEP8 errors >>>>>>>> $ git show -U0 | pep8 --diff | wc -l >>>>>>>> 198 >>>>>>>> >>>>>>>> 4) >>>>>>>> if options != None: >>>>>>>> >>>>>>>> Please use "options *is not* None" >>>>>>>> >>>>>>>> 5) >>>>>>>> For consistency it should be u'random' >>>>>>>> if key == 'random': >>>>>>>> self.attrs[u'randompassword'] = fuzzy_string >>>>>>>> >>>>>>>> Otherwise it looks good >>>>>>>> Martin^2 >>>>>>>> -- >>>>>>>> Martin Basti >>>>>>> >>>>>> And also fix this please >>>>>> >>>>>> ./make-lint >>>>>> ************* Module ipatests.test_xmlrpc.test_stageuser_plugin >>>>>> ipatests/test_xmlrpc/test_stageuser_plugin.py:337: >>>>>> [E0102(function-redefined), user2] function already defined line 44) >>>>>> >>>>>> -- >>>>>> Martin Basti >>>>>> >>>>>> >>>>> Ahoj, v patchi mas este uvedene svoje stare meno, mala by si v >>>>> gite nastavit redhat email >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>> Sorry for spam, you can safely ignore this. :) >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>> Attaching new patch - (hopefully) fixed the errors from the old one >>> + few test cases were added. >>> >>> Lenka >>> >>> >> >> >> Hello Lenka, >> >> This is a very impressive work and test framework. I have not >> understood all the details of the implementation so I just focus on >> the reading the tests body. >> The patch is looking great to me and I have really few minors comments. >> >> * About non existing stage user, you may try to activate a non >> existing one. Is it what TestStagedUser.test_activate does ? >> > No, it didn't occur to me to test activation of nonexistent user, I > can add it. >> >> * In test_create_attr, I can see that user6 is activated. How is >> checked that the specified values are preserved ? (sorry my >> python skill is still very low) >> > The values are checked - in the test itself, using > 'create_from_staged' I first copy attributes of stage user object to a > new active user object (just object, not the ipa user itself) and in > 'check_activate' I verify that values of ipa user correspond with > those taken from staged user >> >> * Many testcases >> (http://www.freeipa.org/page/V4/User_Life-Cycle_Management/Test_Plan#Test_case:_Try_to_search_for_a_nonexistent_user) >> are about creating a stage user with various attributes >> (initial,shell, homedir...). I found uid/gid, are the others >> implemented ? >> > Yes, all the options are implemented using parametrized fixture > 'stageduser2' + 'options_ok' list, tests are performed by > 'test_create_attr' method. These tests also contain activation check > (users can be activated and values are preserved). >> >> * In TestActive.test_delete_preserve, does check_delete check the >> active container or the stageuser container ? >> > check_delete just checks the result of 'user-del' command (it just > says that a certain user has been deleted). But after that, there is a > verification that the user is no longer in _active_ container > performed by running 'user-show' command with 'not found' as expected > result. >> >> * Does test_delete_preserved checks that the deleted entry has been >> permanently removed ? >> > If you mean whether there is a check like running 'user-show' command > and expecting 'not found', no, there is not. I haven't thought about > it. Can add. > >> * Is test_preserved_membership the test case for >> https://fedorahosted.org/freeipa/ticket/5170 ? >> > I'd say that partly - it just verifies if membership can be added to a > preserved user (expects failure of such attempt). > It does not check whether a user with thus successfully assigned > membership preserves it after 'user-undel' (but that is part of > TestPreserved.test_reactivate_preserved - the > 'check_attr_preservation' method verifies that reactivated user is > member of 'ipausers' group only). > > Lenka >> >> Thanks >> thierry >> > > > NACK syntax error, missing ')' -from ipatests.util import assert_equal, assert_not_equal, raises +from ipatests.util import ( + assert_equal, assert_not_equal, raises, assert_deepequal I cannot apply this patch, please check it -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheimes at redhat.com Thu Aug 13 12:12:21 2015 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 13 Aug 2015 14:12:21 +0200 Subject: [Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client In-Reply-To: <55CC8818.6050300@redhat.com> References: <55B134B6.1020209@redhat.com> <55CC6D05.10207@redhat.com> <55CC73A5.6010604@redhat.com> <55CC8818.6050300@redhat.com> Message-ID: <55CC89A5.30605@redhat.com> On 2015-08-13 14:05, Petr Vobornik wrote: > On 08/13/2015 12:38 PM, Christian Heimes wrote: >> On 2015-08-13 12:10, Petr Vobornik wrote: >>> On 07/23/2015 08:38 PM, Christian Heimes wrote: >>>> The ipa vault commands now load the public keys in order to verify >>>> them. >>>> The validation also prevents a user from accidentally sending her >>>> private keys to the server. The patch fixes #5142 and #5142. >>>> >>>> $ ./ipa vault-add AsymmetricVault --desc "Asymmetric vault" --type >>>> asymmetric --public-key-file mykey.pem >>>> ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault >>>> public key: Could not unserialize key data. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5142 >>>> https://fedorahosted.org/freeipa/ticket/5143 >>>> >>> >>> ACK as fix for 5142. >>> >>> I don't think that it fixes 5143. The traceback is fixed therefore 5143 >>> doesn't occur but if there was other traceback raised by >>> `self.api.Command.vault_archive(*args, **opts)` then the vault added in >>> `response = self.api.Command.vault_add_internal(*args, **options)` would >>> be still created. >> >> Yes, that is correct. There aren't any arguments that can lead to an >> exception. The arguments are either already validated by vault_add() or >> don't raise an error. >> >> Of course there are plenty of opportunities errors. The connection to >> the IPA or LDAP server could fail, NSS DB could be missing and so on. >> How should we handle an error in vault_archive? Is there another way >> then to delete the new vault all along? >> >> try: >> self.api.Command.vault_archive(*args, **opts) >> except Exception: >> log_error() >> self.api.Command.vault_del(*args, **opts) >> report_error() >> >> Christian >> > > Imho this is the way. But it may fail because of the same root cause as > vault_archive. > > That said I don't see #5142 as a priority and would defer it. I'd still like to see my patch for #5142 in RHEL, too. It prevents accidental exposure of private keys, too. In the test case the test uploads his private keys to the server. FreeIPA should not leak a user's private key. My patch prevents that, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Thu Aug 13 12:23:06 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Aug 2015 14:23:06 +0200 Subject: [Freeipa-devel] [patch]-pytest-multihost-Return File Attributes to sftp.put In-Reply-To: <20150813115501.GA29739@mniranja.pnq.redhat.com> References: <20150813115501.GA29739@mniranja.pnq.redhat.com> Message-ID: <55CC8C2A.5010804@redhat.com> On 08/13/2015 01:55 PM, Niranjan wrote: > Greetings, > > This patch is regarding pytest-multihost plugin. > Including a patch to return FileAttributes for sftp.put function > used in the function. > > Current put_file function in transport.py in ParamikoTransport Class doesn't > return any value. So when using this function it's not clear if the operation > was sucessfull or not. > > Returning FileAttributes to put_file function helps in checking if operation > was indeed succesful. > > Requesting feedback on the patch attached. > > Regards > Niranjan > > You mixed tabs and spaces, please use only spaces. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Aug 13 12:48:16 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 13 Aug 2015 14:48:16 +0200 Subject: [Freeipa-devel] [patch]-pytest-multihost-Return File Attributes to sftp.put In-Reply-To: <20150813115501.GA29739@mniranja.pnq.redhat.com> References: <20150813115501.GA29739@mniranja.pnq.redhat.com> Message-ID: <55CC9210.6030604@redhat.com> On 08/13/2015 01:55 PM, Niranjan wrote: > Greetings, > > This patch is regarding pytest-multihost plugin. > Including a patch to return FileAttributes for sftp.put function > used in the function. > > Current put_file function in transport.py in ParamikoTransport Class doesn't > return any value. So when using this function it's not clear if the operation > was sucessfull or not. > > Returning FileAttributes to put_file function helps in checking if operation > was indeed succesful. > > Requesting feedback on the patch attached. > > Regards > Niranjan > > > Note that ParamikoTransport is not the only kind of Transport class in the python-multihost. So using the FileAttributes to distinguish success/failure does not seem like the way to go. If you want to distinguish between a successful/unsuccessful put_file call, we should return a boolean value, or rather raise an exception. Cc-ing Petr to chime in. Tomas From mbasti at redhat.com Thu Aug 13 13:06:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Aug 2015 15:06:00 +0200 Subject: [Freeipa-devel] [PATCH] 371 Added support for changing vault encryption. In-Reply-To: <55BFF741.6080302@redhat.com> References: <55BFF741.6080302@redhat.com> Message-ID: <55CC9638.8060801@redhat.com> On 08/04/2015 01:20 AM, Endi Sukma Dewata wrote: > The vault-mod command has been modified to support changing vault > encryption attributes (i.e. type, password, public/private keys) > in addition to normal attributes (i.e. description). Changing the > encryption requires retrieving the stored secret with the old > attributes and rearchieving it with the new attributes. > > https://fedorahosted.org/freeipa/ticket/5176 > > > Hello, does this patch require any additional patches? I have current master branch and I cannot apply it. git am freeipa-edewata-0371-Added-support-for-changing-vault-encryption.patch -3 Applying: Added support for changing vault encryption. error: invalid object 100644 3b62822366a62c90f843a6293589c28383e782ef for 'ipalib/plugins/vault.py' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Aug 13 13:22:57 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 13 Aug 2015 15:22:57 +0200 Subject: [Freeipa-devel] [PATCHES 0056-0057] improve backing-up of DNSSEC-related files Message-ID: <55CC9A31.80705@redhat.com> PATCH 0056 just fixes a typo in ipaplatform/paths PATCH 0057 addresses https://fedorahosted.org/freeipa/ticket/5159 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0057-ipa-backup-archive-DNSSEC-zone-file-and-kasp.db.patch Type: text/x-patch Size: 959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0056-fix-typo-in-BasePathNamespace-member-pointing-to-ods.patch Type: text/x-patch Size: 2619 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Thu Aug 13 13:25:16 2015 From: mrniranjan at fedoraproject.org (Niranjan) Date: Thu, 13 Aug 2015 18:55:16 +0530 Subject: [Freeipa-devel] [patch]-pytest-multihost-Return File Attributes to sftp.put In-Reply-To: <55CC8C2A.5010804@redhat.com> References: <20150813115501.GA29739@mniranja.pnq.redhat.com> <55CC8C2A.5010804@redhat.com> Message-ID: <20150813132516.GA30959@mniranja.pnq.redhat.com> Martin Basti wrote: > > > On 08/13/2015 01:55 PM, Niranjan wrote: > >Greetings, > > > >This patch is regarding pytest-multihost plugin. > >Including a patch to return FileAttributes for sftp.put function > >used in the function. > > > >Current put_file function in transport.py in ParamikoTransport Class doesn't > >return any value. So when using this function it's not clear if the operation > >was sucessfull or not. > > > >Returning FileAttributes to put_file function helps in checking if operation > >was indeed succesful. > > > >Requesting feedback on the patch attached. > > > >Regards > >Niranjan > > > > > You mixed tabs and spaces, please use only spaces. Sure, will use spaces here after. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Thu Aug 13 13:26:03 2015 From: mrniranjan at fedoraproject.org (Niranjan) Date: Thu, 13 Aug 2015 18:56:03 +0530 Subject: [Freeipa-devel] [patch]-pytest-multihost-Return File Attributes to sftp.put In-Reply-To: <55CC9210.6030604@redhat.com> References: <20150813115501.GA29739@mniranja.pnq.redhat.com> <55CC9210.6030604@redhat.com> Message-ID: <20150813132603.GB30959@mniranja.pnq.redhat.com> Tomas Babej wrote: > > > On 08/13/2015 01:55 PM, Niranjan wrote: > > Greetings, > > > > This patch is regarding pytest-multihost plugin. > > Including a patch to return FileAttributes for sftp.put function > > used in the function. > > > > Current put_file function in transport.py in ParamikoTransport Class doesn't > > return any value. So when using this function it's not clear if the operation > > was sucessfull or not. > > > > Returning FileAttributes to put_file function helps in checking if operation > > was indeed succesful. > > > > Requesting feedback on the patch attached. > > > > Regards > > Niranjan > > > > > > > > Note that ParamikoTransport is not the only kind of Transport class in > the python-multihost. So using the FileAttributes to distinguish > success/failure does not seem like the way to go. > > If you want to distinguish between a successful/unsuccessful put_file > call, we should return a boolean value, or rather raise an exception. I agree, exception would be better approach. > > Cc-ing Petr to chime in. > > Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 13 13:38:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Aug 2015 15:38:01 +0200 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55C88F57.6000500@redhat.com> References: <55C88F57.6000500@redhat.com> Message-ID: <55CC9DB9.5000705@redhat.com> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: > Hi All, > > This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 > > Thanks, > Abhijeet Kasurde > > Hello, thank you for the patch 1) - except ValueError: + except EOFError, ValueError: Please use except (EOFError, ValueError): https://docs.python.org/2/tutorial/errors.html#handling-exceptions 2) I'm not sure if this code will work (I did not test it) I expect when stdin is closed, this will result into infinite loop, because raw_input will always return EOFError. while True: try: ret = raw_input("%s: " % prompt) if allow_empty or ret.strip(): return ret except EOFError: pass -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Aug 13 13:46:02 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 13 Aug 2015 23:46:02 +1000 Subject: [Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates In-Reply-To: <20150813093010.GX22106@redhat.com> References: <55CB4296.3020103@redhat.com> <20150813032836.GO16439@dhcp-40-8.bne.redhat.com> <55CC5DAA.4000307@redhat.com> <20150813092214.GY16439@dhcp-40-8.bne.redhat.com> <20150813093010.GX22106@redhat.com> Message-ID: <20150813134601.GB16439@dhcp-40-8.bne.redhat.com> On Thu, Aug 13, 2015 at 12:30:10PM +0300, Alexander Bokovoy wrote: > On Thu, 13 Aug 2015, Fraser Tweedale wrote: > >On Thu, Aug 13, 2015 at 11:04:42AM +0200, Petr Vobornik wrote: > >>On 08/13/2015 05:28 AM, Fraser Tweedale wrote: > >>>On Wed, Aug 12, 2015 at 02:56:54PM +0200, Petr Vobornik wrote: > >>>>usercertificate attr was moved from "System Modify Users" to this > >>>>new permission. > >>>> > >>>>https://fedorahosted.org/freeipa/ticket/5177 > >>>> > >>>>Note: hosts have permission "System: Manage Host Certificates", services > >>>>don't have it but usercertificate is in "System: Modify Services". I would > >>>>move it as well if usercertificate was not the only attr in "System: Modify > >>>>Services". > >>>> > >>>New permission works as expected. > >>> > >>>What are the implications of removing userCertificate attribute from > >>>"Modify Users" ACI? Users could be relying on it given that there > >>>is (until now) no more fine-grained permission. > >> > >>I'm not sure what is the expected ACI upgrade behavior but applying this > >>patch on installed server and running ipa-server-upgrade ends with > >>userCertificate still in "System: Modify Users" permission - it eliminates > >>your worry. The rest of users who still run IPA < 4.2 won't even notice. > >> > >Ah, I see. > > > >This raises a different problem: different ACIs on different > >deployments, depending on when IPA was installed. Unless I am > >misunderstanding something, isn't that an undesirable situation? > We have precedent of upgrading ACIs via upgrade plugins. > So this is something we need to design for and execute. > If we've done it before and the consensus is that it's a problem for another day, then I suppose it's an ACK from me. Cheers, Fraser From mbabinsk at redhat.com Thu Aug 13 13:48:37 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 13 Aug 2015 15:48:37 +0200 Subject: [Freeipa-devel] [PATCH] 0030 Add permission for bypassing CA ACL enforcement In-Reply-To: <20150813034601.GP16439@dhcp-40-8.bne.redhat.com> References: <20150804052129.GG4843@dhcp-40-8.bne.redhat.com> <20150813034601.GP16439@dhcp-40-8.bne.redhat.com> Message-ID: <55CCA035.7080806@redhat.com> On 08/13/2015 05:46 AM, Fraser Tweedale wrote: > On Tue, Aug 04, 2015 at 03:21:29PM +1000, Fraser Tweedale wrote: >> The attached patch fixes >> https://fedorahosted.org/freeipa/ticket/5099. >> >> Thanks, >> Fraser > > Ping; this patch needs review. > ACK -- Martin^3 Babinsky From mbasti at redhat.com Thu Aug 13 14:18:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Aug 2015 16:18:21 +0200 Subject: [Freeipa-devel] [PATCH] 374 Fixed vault container ownership. In-Reply-To: <55C8FF4E.5010107@redhat.com> References: <55C8FF4E.5010107@redhat.com> Message-ID: <55CCA72D.4060501@redhat.com> On 08/10/2015 09:45 PM, Endi Sukma Dewata wrote: > The vault-add command has been fixed such that if the user/service > private vault container does not exist yet it will be created and > owned by the user/service instead of the vault creator. > > https://fedorahosted.org/freeipa/ticket/5194 > > > I cannot apply this patch, are there any additional required patches? I have current ipa master branch git am freeipa-edewata-0374-Fixed-vault-container-ownership.patch -3 Applying: Fixed vault container ownership. error: invalid object 100644 427b1ea1588af2fb09a99181b8773abdf8099b8d for 'ipalib/plugins/vault.py' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Thu Aug 13 14:21:49 2015 From: alee at redhat.com (Ade Lee) Date: Thu, 13 Aug 2015 10:21:49 -0400 Subject: [Freeipa-devel] [PATCH] 0038 cert-request: remove allowed extensions check In-Reply-To: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> References: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> Message-ID: <1439475709.437.13.camel@redhat.com> Fraser, Continuing the discussion started previously, the question is whether IPA should check for the presence of certain extensions. There seem to be two kinds of problems which could be encountered here: 1. User could include a CSR which includes an extension that is not valid for the profile. 2. User could include data for an extension that is invalid. The original allowed extensions check attempted to address problem (1) by allowing only extensions that were valid for the small set of profiles used by IPA. Now that custom profiles are available, though, this is no longer sufficient. I do believe that it would be useful to provide the user with feedback if a particular extension is not supported by the profile when the CSR is submitted to IPA. This should most likely be a non-fatal notification, because the CA will end up ignoring the extension. With the Dogtag profile API, it is possible to enumerate the extensions that are included in a cert for a particular profile. Couldn't this data be used as the basis for this check? For problem (2), although some validation could be done in IPA, this is most probably something that should be left to Dogtag itself. I believ e the error reporting from Dogtag has been sufficiently improved so that these types of validation errors would be reported back to IPA. Ade On Thu, 2015-08-13 at 15:54 +1000, Fraser Tweedale wrote: > The attached patch fixes > https://fedorahosted.org/freeipa/ticket/5205 > > Thanks, > Fraser > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From abokovoy at redhat.com Thu Aug 13 14:29:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Aug 2015 17:29:43 +0300 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script Message-ID: <20150813142943.GF22106@redhat.com> Hi, see commit message for details. -- / Alexander Bokovoy -------------- next part -------------- From 96f4623730f764c73ce4544d0788e8782fecaa99 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 13 Aug 2015 17:18:57 +0300 Subject: [PATCH] trusts: harden trust-fetch-domains oddjobd-based script When ipa-getkeytab is used to fetch trusted domain object credentials, the fetched entry has always kvno 1. ipa-getkeytab always adds a key to keytab which means older key versions will be in the SSSD keytab and will confuse libkrb5 ccache initialization code as all kvno values are equal to 1. Wrong key is picked up then and kinit fails. To solve this problem, always remove existing /var/lib/sss/keytabs/forest.keytab before retrieving a new one. To make sure script's input cannot be used to define what should be removed (by passing a relative path), make sure we retrieve trusted forest name from LDAP. If it is not possible to retrieve, the script will issue an exception and quit. If abrtd is running, this will be recorded as a 'crash' and an attempt to use script by malicious user would be recorded as well in the abrtd journal. Solves https://bugzilla.redhat.com/show_bug.cgi?id=1250190 --- install/oddjob/com.redhat.idm.trust-fetch-domains | 29 +++++++++++++++++++---- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains b/install/oddjob/com.redhat.idm.trust-fetch-domains index e50c81e..6a2171d 100755 --- a/install/oddjob/com.redhat.idm.trust-fetch-domains +++ b/install/oddjob/com.redhat.idm.trust-fetch-domains @@ -41,6 +41,9 @@ def retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal): "-p", oneway_principal, "-k", oneway_keytab_name, "-r"] + if os.path.isfile(oneway_keytab_name): + os.unlink(oneway_keytab_name) + (stdout, stderr, retcode) = ipautil.run(getkeytab_args, env={'KRB5CCNAME': ccache_name, 'LANG': 'C'}, raiseonerr=False) @@ -111,7 +114,6 @@ from ipalib.plugins import trust # retrieve the keys to oneway_keytab_name. keytab_name = '/etc/samba/samba.keytab' -oneway_keytab_name = '/var/lib/sss/keytabs/' + trusted_domain + '.keytab' principal = str('cifs/' + api.env.host) @@ -137,10 +139,20 @@ else: old_ccache = os.environ.get('KRB5CCNAME') api.Backend.ldap2.connect(ccache) +# Retrieve own NetBIOS name and trusted forest's name. +# We use script's input to retrieve the trusted forest's name to sanitize input +# for file-level access as we might need to wipe out keytab in /var/lib/sss/keytabs own_trust_dn = DN(('cn', api.env.domain),('cn','ad'), ('cn', 'etc'), api.env.basedn) own_trust_entry = api.Backend.ldap2.get_entry(own_trust_dn, ['ipantflatname']) -own_trust_flatname = own_trust_entry['ipantflatname'][0].upper() +own_trust_flatname = own_trust_entry.single_value.get('ipantflatname').upper() +trusted_domain_dn = DN(('cn', trusted_domain.lower()), api.env.container_adtrusts, api.env.basedn) +trusted_domain_entry = api.Backend.ldap2.get_entry(trusted_domain_dn, ['cn']) +trusted_domain = trusted_domain_entry.single_value.get('cn').lower() +# At this point if we didn't find trusted forest name, an exception will be raised +# and script will quit. This is actually intended. + +oneway_keytab_name = '/var/lib/sss/keytabs/' + trusted_domain + '.keytab' oneway_principal = str('%s$@%s' % (own_trust_flatname, trusted_domain.upper())) # If keytab does not exist, retrieve it @@ -152,11 +164,18 @@ try: # The keytab may have stale key material (from older trust-add run) if not os.path.isfile(oneway_ccache_name): oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) + else: + oneway_ccache_check = KRB5_CCache(oneway_ccache_name) + if not oneway_ccache_check.credential_is_valid(oneway_principal): + # If credentials were invalid, obtain them again + oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) + else: + oneway_ccache = oneway_ccache_check.ccache except krbV.Krb5Error as e: # If there was failure on using keytab, assume it is stale and retrieve again retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal) -if oneway_ccache: +try: # There wasn existing ccache, validate its content oneway_ccache_check = KRB5_CCache(oneway_ccache_name) if not oneway_ccache_check.credential_is_valid(oneway_principal): @@ -164,7 +183,7 @@ if oneway_ccache: oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) else: oneway_ccache = oneway_ccache_check.ccache -else: +except krbV.Krb5Error as e: oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) # We are done: we have ccache with TDO credentials and can fetch domains @@ -193,7 +212,7 @@ if domains: dom['range_type'] = u'ipa-ad-trust' # Do not pass ipaserver.dcerpc.TrustInstance to trust.add_range # to force it using existing credentials cache - trust.add_range(None, range_name, dom['ipanttrusteddomainsid'], + trust.add_range(api, None, range_name, dom['ipanttrusteddomainsid'], trusted_domain, name, **dom) except errors.DuplicateEntry: # Ignore updating duplicate entries -- 2.4.3 From mbasti at redhat.com Thu Aug 13 14:42:00 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Aug 2015 16:42:00 +0200 Subject: [Freeipa-devel] [PATCH 471] ULC: Prevent preserved users from being assigned membership In-Reply-To: <55CB3A10.901@redhat.com> References: <55CB1E5F.7030407@redhat.com> <55CB3A10.901@redhat.com> Message-ID: <55CCACB8.60202@redhat.com> On 08/12/2015 02:20 PM, Jan Cholasta wrote: > On 12.8.2015 12:22, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Fixed broken user_show on preserved user. Updated patch attached. > > > Pushed to: master: 391ccabb9f0629b3d172d31cdab9067e4bd4e5dd ipa-4-2: cd81727d6243de2c613afec6dd0bf9a41c724354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 13 15:06:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Aug 2015 17:06:33 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55C9FA64.1030307@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> Message-ID: <55CCB279.9010200@redhat.com> On 08/11/2015 03:36 PM, Oleg Fayans wrote: > Hi Martin, > > On 08/11/2015 02:02 PM, Martin Basti wrote: >> NACK, comments inline. >> >> On 11/08/15 13:25, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Thanks for the review! >>> >>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>> Thank you for patch, I have a few nitpicks: >>>> >>>> 1) >>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>> +def create_segment(master, leftnode, rightnode): >>>>> + """create_segment(master, leftnode, rightnode) >>>> Why do you add the name of method in docstring? >>> My bad, fixed. >> >> still there >> >> + tokenize_topologies(command_output) >> + takes an output of `ipa topologysegment-find` and returns an >> array of >> > Fixed, sorry. >> >>>> >>>> >>>> 2) >>>> >>>> +def create_segment(master, leftnode, rightnode): >>>> + """create_segment(master, leftnode, rightnode) >>>> + creates a topology segment. The first argument is a node to >>>> run the >>>> command on >>>> + The first 3 arguments should be objects of class Host >>>> + Returns a hash object containing segment's name, leftnode, >>>> rightnode information >>>> + """ >>>> >>>> I would prefer to add assert there instead of just document that a >>>> Host >>>> object is needed >>>> assert(isinstance(master, Host)) >>>> ... >>> >>> Fixed. Created a decorator that checks the type of arguments >> >> This does not scale well. >> If we will want to add new argument that is not host object, you need >> change it again. > > Agreed. Modified the decorator so that you can specify a slice of > arguments to be checked and a class to compare to. This does scale :) >> >> This might be used as function with specified variables that have to be >> host objects >>> >>>> >>>> 3) >>>> +def destroy_segment(master, segment_name): >>>> + """ >>>> + destroy_segment(master, segment_name) >>>> + Destroys topology segment. First argument should be object of >>>> class >>>> Host >>>> >>>> Instead of description of params as first, second etc., you may use >>>> following: >>>> >>>> +def destroy_segment(master, segment_name): >>>> + """ >>>> + Destroys topology segment. >>>> + :param master: reference to master object of class Host >>>> + :param segment: name fo segment >>>> and eventually this in other methods >>>> + :returns: Lorem ipsum sit dolor mit amet >>>> + :raises NotFound: if segment is not found >>>> >>> Fixed >>>> >>>> 4) >>>> >>>> cls.replicas[:len(cls.replicas) - 1], >>>> >>>> I suggest cls.replicas[:-1] >>>> >>>> In [2]: a = [1, 2, 3, 4, 5] >>>> >>>> In [3]: a[:-1] >>>> Out[3]: [1, 2, 3, 4] >>>> >>> Fixed >>>> >>>> 5) >>>> Why re.findall() and then you just use the first result? >>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>> >>>> Isn't just re.search() enough? >>>> leftnode_re.search(value).group(1) >>> >>> in fact >>> leftnode_re.findall(string)[0] >>> and >>> leftnode_re.search(string).group(1), >>> Are equally bad from the readability point of view. The first one is >>> even shorter a bit, so why change? :) >> >> It depends on point of view, because when I reviewed it yesterday my >> brain raises exception that you are trying to add multiple values to >> single value attribute, because you used findall, I expected that you >> need multiple values, and then I saw that index [0] at the end, and I >> was pretty confused what are you trying to achieve. >> >> And because findall is not effective in case when you need to find just >> one occurrence. > > I got it. Fixed. > >> >> >>> >>>> >>>> >>>> Python 3 nitpick: >>>> I'm not sure if time when we should enforce python 2/3 compability >>>> already comes, but just for record: >>>> instead of open(file, 'r'), please use io.open(file, 'r') (import io >>>> before) >>>> >>> Done. >>>> >>>> >>>> >>> >> >> 1) >> >> +# >> >> empty comment here (several times) > > Removed >> > NACK you changed it wrong group() returns everything, you need use group(1) to return content in braces. From tbabej at redhat.com Thu Aug 13 15:10:03 2015 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 13 Aug 2015 17:10:03 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55CCB279.9010200@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> Message-ID: <55CCB34B.6080003@redhat.com> On 08/13/2015 05:06 PM, Martin Basti wrote: > > > On 08/11/2015 03:36 PM, Oleg Fayans wrote: >> Hi Martin, >> >> On 08/11/2015 02:02 PM, Martin Basti wrote: >>> NACK, comments inline. >>> >>> On 11/08/15 13:25, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review! >>>> >>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>> Thank you for patch, I have a few nitpicks: >>>>> >>>>> 1) >>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>> +def create_segment(master, leftnode, rightnode): >>>>>> + """create_segment(master, leftnode, rightnode) >>>>> Why do you add the name of method in docstring? >>>> My bad, fixed. >>> >>> still there >>> >>> + tokenize_topologies(command_output) >>> + takes an output of `ipa topologysegment-find` and returns an >>> array of >>> >> Fixed, sorry. >>> >>>>> >>>>> >>>>> 2) >>>>> >>>>> +def create_segment(master, leftnode, rightnode): >>>>> + """create_segment(master, leftnode, rightnode) >>>>> + creates a topology segment. The first argument is a node to >>>>> run the >>>>> command on >>>>> + The first 3 arguments should be objects of class Host >>>>> + Returns a hash object containing segment's name, leftnode, >>>>> rightnode information >>>>> + """ >>>>> >>>>> I would prefer to add assert there instead of just document that a >>>>> Host >>>>> object is needed >>>>> assert(isinstance(master, Host)) >>>>> ... >>>> >>>> Fixed. Created a decorator that checks the type of arguments >>> >>> This does not scale well. >>> If we will want to add new argument that is not host object, you need >>> change it again. >> >> Agreed. Modified the decorator so that you can specify a slice of >> arguments to be checked and a class to compare to. This does scale :) >>> >>> This might be used as function with specified variables that have to be >>> host objects >>>> >>>>> >>>>> 3) >>>>> +def destroy_segment(master, segment_name): >>>>> + """ >>>>> + destroy_segment(master, segment_name) >>>>> + Destroys topology segment. First argument should be object of >>>>> class >>>>> Host >>>>> >>>>> Instead of description of params as first, second etc., you may use >>>>> following: >>>>> >>>>> +def destroy_segment(master, segment_name): >>>>> + """ >>>>> + Destroys topology segment. >>>>> + :param master: reference to master object of class Host >>>>> + :param segment: name fo segment >>>>> and eventually this in other methods >>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>> + :raises NotFound: if segment is not found >>>>> >>>> Fixed >>>>> >>>>> 4) >>>>> >>>>> cls.replicas[:len(cls.replicas) - 1], >>>>> >>>>> I suggest cls.replicas[:-1] >>>>> >>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>> >>>>> In [3]: a[:-1] >>>>> Out[3]: [1, 2, 3, 4] >>>>> >>>> Fixed >>>>> >>>>> 5) >>>>> Why re.findall() and then you just use the first result? >>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>> >>>>> Isn't just re.search() enough? >>>>> leftnode_re.search(value).group(1) >>>> >>>> in fact >>>> leftnode_re.findall(string)[0] >>>> and >>>> leftnode_re.search(string).group(1), >>>> Are equally bad from the readability point of view. The first one is >>>> even shorter a bit, so why change? :) >>> >>> It depends on point of view, because when I reviewed it yesterday my >>> brain raises exception that you are trying to add multiple values to >>> single value attribute, because you used findall, I expected that you >>> need multiple values, and then I saw that index [0] at the end, and I >>> was pretty confused what are you trying to achieve. >>> >>> And because findall is not effective in case when you need to find just >>> one occurrence. >> >> I got it. Fixed. >> >>> >>> >>>> >>>>> >>>>> >>>>> Python 3 nitpick: >>>>> I'm not sure if time when we should enforce python 2/3 compability >>>>> already comes, but just for record: >>>>> instead of open(file, 'r'), please use io.open(file, 'r') (import io >>>>> before) >>>>> >>>> Done. >>>>> >>>>> >>>>> >>>> >>> >>> 1) >>> >>> +# >>> >>> empty comment here (several times) >> >> Removed >>> >> > > NACK > > you changed it wrong > > group() returns everything, you need use group(1) to return content in > braces. > I'd suggest using named groups in this case, it leads to clearer expressions. See: https://docs.python.org/2/library/re.html , (?P...) section. From edewata at redhat.com Thu Aug 13 15:24:06 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Aug 2015 10:24:06 -0500 Subject: [Freeipa-devel] [PATCH] 374 Fixed vault container ownership. In-Reply-To: <55CCA72D.4060501@redhat.com> References: <55C8FF4E.5010107@redhat.com> <55CCA72D.4060501@redhat.com> Message-ID: <55CCB696.80004@redhat.com> On 8/13/2015 9:18 AM, Martin Basti wrote: >> The vault-add command has been fixed such that if the user/service >> private vault container does not exist yet it will be created and >> owned by the user/service instead of the vault creator. >> >> https://fedorahosted.org/freeipa/ticket/5194 > > I cannot apply this patch, are there any additional required patches? > > I have current ipa master branch > > git am freeipa-edewata-0374-Fixed-vault-container-ownership.patch -3 > Applying: Fixed vault container ownership. > error: invalid object 100644 427b1ea1588af2fb09a99181b8773abdf8099b8d > for 'ipalib/plugins/vault.py' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. Rebased. This patch doesn't have any dependency. -- Endi S. Dewata -------------- next part -------------- >From da35d235bc8196062b208095aa904e3b7a1905e2 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Mon, 10 Aug 2015 20:57:58 +0200 Subject: [PATCH] Fixed vault container ownership. The vault-add command has been fixed such that if the user/service private vault container does not exist yet it will be created and owned by the user/service instead of the vault creator. https://fedorahosted.org/freeipa/ticket/5194 --- ipalib/plugins/vault.py | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 1150d5f3b8cd0001f24756548d7f280494161d19..9a2995ca04cb99b0be46076541cea2638bf3ca56 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -712,12 +712,33 @@ class vault_add_internal(LDAPCreate): else: owner_dn = self.api.Object.user.get_dn(name) + parent_dn = DN(*dn[1:]) + + container_dn = DN(self.api.Object.vault.container_dn, + self.api.env.basedn) + + services_dn = DN(('cn', 'services'), container_dn) + users_dn = DN(('cn', 'users'), container_dn) + + if dn.endswith(services_dn): + # service container should be owned by the service + service = parent_dn[0]['cn'] + parent_owner_dn = self.api.Object.service.get_dn(service) + + elif dn.endswith(users_dn): + # user container should be owned by the user + user = parent_dn[0]['cn'] + parent_owner_dn = self.api.Object.user.get_dn(user) + + else: + parent_owner_dn = owner_dn + try: - parent_dn = DN(*dn[1:]) - self.obj.create_container(parent_dn, owner_dn) + self.obj.create_container(parent_dn, parent_owner_dn) except errors.DuplicateEntry as e: pass + # vault should be owned by the creator entry_attrs['owner'] = owner_dn return dn -- 2.1.0 From edewata at redhat.com Thu Aug 13 16:23:59 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Aug 2015 11:23:59 -0500 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55CC78D9.8080709@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> <1438690803.20262.25.camel@willson.usersys.redhat.com> <55C0C371.5060000@redhat.com> <55C0DB02.8080306@redhat.com> <55C8F79E.8070405@redhat.com> <55C9993E.9020604@redhat.com> <55CC78D9.8080709@redhat.com> Message-ID: <55CCC49F.5000603@redhat.com> On 8/13/2015 6:00 AM, Petr Vobornik wrote: > On 08/11/2015 08:42 AM, Jan Cholasta wrote: >> On 10.8.2015 21:12, Endi Sukma Dewata wrote: >>> On 8/4/2015 10:32 AM, Endi Sukma Dewata wrote: >>>>>> Martin, I do not think going on with business as usual is the right >>>>>> thing to do here. We know this is going to bite. >>>>>> I suggest Endy adds a *new* API if making it backwards compatible is >>>>>> not >>>>>> possible. The era of bumping whole API version must stop, the sooner >>>>>> the >>>>>> better. >>>>> >>>>> My point is that we do not know yet how to do this kind of changes >>>>> long term. >>>>> So what I did not want to end up are 2 copy&pasted Vault plugins >>>>> maintained >>>>> forever, differing in just that. >>>>> >>>>> If you know how to do this without copypasting, I will be fine with >>>>> that. >>>> >>>> We probably can do it like this: >>>> * the old plugin continues to provide Vault 1.0 functionality >>>> * the new plugin will be a proxy to the old plugin except for the parts >>>> that have changed in Vault 1.1. >>>> >>>> Or the other way around: >>>> * the new plugin will provide Vault 1.1 functionality >>>> * the old plugin will be a proxy to the new plugin except for the parts >>>> that needs to be maintained for Vault 1.0. >>>> >>>> The first option is probably safer. >>>> >>>> In any case, IPA 4.2.1 will only provide a single client for Vault 1.1, >>>> but two services for Vault 1.0 and 1.1. >>> >>> A new patch #369-1 is attached. It has been rebased on top of #372 and >>> #373 that fix the conflicting parameter while maintaining backward >>> compatibility. >> >> I have modified the first version of the patch to maintain backward >> compatibility and not require your patches #372 and #373. Should be much >> easier to review. See attachment. > > Jan approach seems better to me for 4.2.1. Endi, do you agree with the > changes? Could we proceed with the review? Yes, please see the attached patch. I had to update it to remove buggy code and revised the docs. I also had to rebase my other patches to make sure they work with this patch. -- Endi S. Dewata -------------- next part -------------- >From c43df23159e5dafd47d5309b3b0f75de4870640b Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 11 Aug 2015 08:19:59 +0200 Subject: [PATCH] Added CLI param and ACL for vault service operations. The CLIs to manage vault owners and members have been modified to accept services with a new parameter. Due to name conflict, the existing 'service' parameter has been renamed to 'servicename'. A new ACL has been added to allow a service to create its own service container. https://fedorahosted.org/freeipa/ticket/5172 --- API.txt | 12 ++- VERSION | 4 +- install/share/vault.update | 1 + ipalib/plugins/vault.py | 179 +++++++++++++++++++++------------------------ 4 files changed, 95 insertions(+), 101 deletions(-) diff --git a/API.txt b/API.txt index 04f2f894f7667239d94a2a7278d0cc80704afeb5..9dbf86aedf2a1b62dabab21fb30bbceb2f0f237b 100644 --- a/API.txt +++ b/API.txt @@ -5434,13 +5434,14 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add_member -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') +option: Str('services', alwaysask=True, cli_name='services', csv=True, multivalue=True, required=False) option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) option: Str('username?', cli_name='user') @@ -5449,13 +5450,14 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_add_owner -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') +option: Str('services', alwaysask=True, cli_name='services', csv=True, multivalue=True, required=False) option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) option: Str('username?', cli_name='user') @@ -5547,13 +5549,14 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_remove_member -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') +option: Str('services', alwaysask=True, cli_name='services', csv=True, multivalue=True, required=False) option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) option: Str('username?', cli_name='user') @@ -5562,13 +5565,14 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_remove_owner -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('group*', alwaysask=True, cli_name='groups', csv=True) option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') +option: Str('services', alwaysask=True, cli_name='services', csv=True, multivalue=True, required=False) option: Flag('shared?', autofill=True, default=False) option: Str('user*', alwaysask=True, cli_name='users', csv=True) option: Str('username?', cli_name='user') diff --git a/VERSION b/VERSION index a3d586df47ab6a6136bd38c0151fe43876bf5ab3..c42bea06522dae55e1a89ff94ae394594086b467 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=148 -# Last change: ftweedal - add --out option to user-show +IPA_API_VERSION_MINOR=149 +# Last change: edewata - Added CLI param and ACL for vault service operations diff --git a/install/share/vault.update b/install/share/vault.update index 61a8940b544fbc839b931f337389ac35dc2d1ffa..14421b5189efe9b3d9491e845e74debca6e18941 100644 --- a/install/share/vault.update +++ b/install/share/vault.update @@ -8,6 +8,7 @@ default: objectClass: top default: objectClass: ipaVaultContainer default: cn: vaults default: aci: (target="ldap:///cn=*,cn=users,cn=vaults,cn=kra,$SUFFIX")(version 3.0; acl "Allow users to create private container"; allow (add) userdn = "ldap:///uid=($$attr.cn),cn=users,cn=accounts,$SUFFIX";) +default: aci: (target="ldap:///cn=*,cn=services,cn=vaults,cn=kra,$SUFFIX")(version 3.0; acl "Allow services to create private container"; allow (add) userdn = "ldap:///krbprincipalname=($$attr.cn)@$REALM,cn=services,cn=accounts,$SUFFIX";) default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Indirect container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#GROUPDN";) default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 9a2995ca04cb99b0be46076541cea2638bf3ca56..5d367b376ef41427ed983f3eafe120ed477018d2 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -44,7 +44,7 @@ from ipalib.crud import PKQuery, Retrieve, Update from ipalib.plugable import Registry from ipalib.plugins.baseldap import LDAPObject, LDAPCreate, LDAPDelete,\ LDAPSearch, LDAPUpdate, LDAPRetrieve, LDAPAddMember, LDAPRemoveMember,\ - pkey_to_value + LDAPModMember, pkey_to_value from ipalib.request import context from ipalib.plugins.user import split_principal from ipalib import _, ngettext @@ -93,122 +93,91 @@ The secret can only be retrieved using the private key. """) + _(""" EXAMPLES: """) + _(""" - List private vaults: + List vaults: ipa vault-find + [--user |--service |--shared] """) + _(""" - List service vaults: - ipa vault-find --service -""") + _(""" - List shared vaults: - ipa vault-find --shared -""") + _(""" - List user vaults: - ipa vault-find --user -""") + _(""" - Add a private vault: + Add a standard vault: ipa vault-add -""") + _(""" - Add a service vault: - ipa vault-add --service -""") + _(""" - Add a shared vault: - ipa vault-add --shared -""") + _(""" - Add a user vault: - ipa vault-add --user + [--user |--service |--shared] """) + _(""" Add a symmetric vault: - ipa vault-add --type symmetric --password-file password.txt + ipa vault-add + [--user |--service |--shared] + --type symmetric --password-file password.txt """) + _(""" Add an asymmetric vault: - ipa vault-add --type asymmetric --public-key-file public.pem + ipa vault-add + [--user |--service |--shared] + --type asymmetric --public-key-file public.pem """) + _(""" - Show a private vault: + Show a vault: ipa vault-show + [--user |--service |--shared] """) + _(""" - Show a service vault: - ipa vault-show --service + Modify a vault: + ipa vault-mod + [--user |--service |--shared] + --desc """) + _(""" - Show a shared vault: - ipa vault-show --shared -""") + _(""" - Show a user vault: - ipa vault-show --user -""") + _(""" - Modify a private vault: - ipa vault-mod --desc -""") + _(""" - Modify a service vault: - ipa vault-mod --service --desc -""") + _(""" - Modify a shared vault: - ipa vault-mod --shared --desc -""") + _(""" - Modify a user vault: - ipa vault-mod --user --desc -""") + _(""" - Delete a private vault: + Delete a vault: ipa vault-del -""") + _(""" - Delete a service vault: - ipa vault-del --service -""") + _(""" - Delete a shared vault: - ipa vault-del --shared -""") + _(""" - Delete a user vault: - ipa vault-del --user + [--user |--service |--shared] """) + _(""" Display vault configuration: ipa vaultconfig-show """) + _(""" - Archive data into private vault: - ipa vault-archive --in -""") + _(""" - Archive data into service vault: - ipa vault-archive --service --in -""") + _(""" - Archive data into shared vault: - ipa vault-archive --shared --in -""") + _(""" - Archive data into user vault: - ipa vault-archive --user --in + Archive data into standard vault: + ipa vault-archive + [--user |--service |--shared] + --in """) + _(""" Archive data into symmetric vault: - ipa vault-archive --in + ipa vault-archive + [--user |--service |--shared] + --in + --password-file password.txt """) + _(""" Archive data into asymmetric vault: - ipa vault-archive --in -""") + _(""" - Retrieve data from private vault: - ipa vault-retrieve --out -""") + _(""" - Retrieve data from service vault: - ipa vault-retrieve --service --out -""") + _(""" - Retrieve data from shared vault: - ipa vault-retrieve --shared --out -""") + _(""" - Retrieve data from user vault: - ipa vault-retrieve --user --out + ipa vault-archive + [--user |--service |--shared] + --in +""") + _(""" + Retrieve data from standard vault: + ipa vault-retrieve + [--user |--service |--shared] + --out """) + _(""" Retrieve data from symmetric vault: - ipa vault-retrieve --out data.bin + ipa vault-retrieve + [--user |--service |--shared] + --out + --password-file password.txt """) + _(""" Retrieve data from asymmetric vault: - ipa vault-retrieve --out data.bin --private-key-file private.pem + ipa vault-retrieve + [--user |--service |--shared] + --out --private-key-file private.pem """) + _(""" - Add a vault owner: - ipa vault-add-owner --users + Add vault owners: + ipa vault-add-owner + [--user |--service |--shared] + [--users ] [--groups ] [--services ] """) + _(""" - Delete a vault owner: - ipa vault-remove-owner --users + Delete vault owners: + ipa vault-remove-owner + [--user |--service |--shared] + [--users ] [--groups ] [--services ] """) + _(""" - Add a vault member: - ipa vault-add-member --users + Add vault members: + ipa vault-add-member + [--user |--service |--shared] + [--users ] [--groups ] [--services ] """) + _(""" - Delete a vault member: - ipa vault-remove-member --users + Delete vault members: + ipa vault-remove-member + [--user |--service |--shared] + [--users ] [--groups ] [--services ] """) @@ -285,8 +254,8 @@ class vault(LDAPObject): 'ipavaulttype', ] attribute_members = { - 'owner': ['user', 'group'], - 'member': ['user', 'group'], + 'owner': ['user', 'group', 'service'], + 'member': ['user', 'group', 'service'], } label = _('Vaults') @@ -340,6 +309,11 @@ class vault(LDAPObject): label=_('Owner groups'), flags=['no_create', 'no_update', 'no_search'], ), + Str( + 'owner_service?', + label=_('Owner services'), + flags=['no_create', 'no_update', 'no_search'], + ), ) def get_dn(self, *keys, **options): @@ -1440,8 +1414,23 @@ class vault_retrieve_internal(PKQuery): return response +class VaultModMember(LDAPModMember): + def get_options(self): + for param in super(VaultModMember, self).get_options(): + if param.name == 'service' and param not in vault_options: + param = param.clone_rename('services') + yield param + + def get_member_dns(self, **options): + if 'services' in options: + options['service'] = options.pop('services') + else: + options.pop('service', None) + return super(VaultModMember, self).get_member_dns(**options) + + @register() -class vault_add_owner(LDAPAddMember): +class vault_add_owner(VaultModMember, LDAPAddMember): __doc__ = _('Add owners to a vault.') takes_options = LDAPAddMember.takes_options + vault_options @@ -1465,7 +1454,7 @@ class vault_add_owner(LDAPAddMember): @register() -class vault_remove_owner(LDAPRemoveMember): +class vault_remove_owner(VaultModMember, LDAPRemoveMember): __doc__ = _('Remove owners from a vault.') takes_options = LDAPRemoveMember.takes_options + vault_options @@ -1489,14 +1478,14 @@ class vault_remove_owner(LDAPRemoveMember): @register() -class vault_add_member(LDAPAddMember): +class vault_add_member(VaultModMember, LDAPAddMember): __doc__ = _('Add members to a vault.') takes_options = LDAPAddMember.takes_options + vault_options @register() -class vault_remove_member(LDAPRemoveMember): +class vault_remove_member(VaultModMember, LDAPRemoveMember): __doc__ = _('Remove members from a vault.') takes_options = LDAPRemoveMember.takes_options + vault_options -- 2.1.0 From edewata at redhat.com Thu Aug 13 17:11:37 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Aug 2015 12:11:37 -0500 Subject: [Freeipa-devel] [PATCH] 371 Added support for changing vault encryption. In-Reply-To: <55CC9638.8060801@redhat.com> References: <55BFF741.6080302@redhat.com> <55CC9638.8060801@redhat.com> Message-ID: <55CCCFC9.1060504@redhat.com> On 8/13/2015 8:06 AM, Martin Basti wrote: >> The vault-mod command has been modified to support changing vault >> encryption attributes (i.e. type, password, public/private keys) >> in addition to normal attributes (i.e. description). Changing the >> encryption requires retrieving the stored secret with the old >> attributes and rearchieving it with the new attributes. >> >> https://fedorahosted.org/freeipa/ticket/5176 >> > Hello, does this patch require any additional patches? > > I have current master branch and I cannot apply it. > > git am > freeipa-edewata-0371-Added-support-for-changing-vault-encryption.patch -3 > Applying: Added support for changing vault encryption. > error: invalid object 100644 3b62822366a62c90f843a6293589c28383e782ef > for 'ipalib/plugins/vault.py' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > > > Martin^2 New patch attached. It requires patch #0369-3. -- Endi S. Dewata -------------- next part -------------- >From b06e859e51a177369c27c52bff8a70263aed59c0 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 31 Jul 2015 07:53:15 +0200 Subject: [PATCH] Added support for changing vault encryption. The vault-mod command has been modified to support changing vault encryption attributes (i.e. type, password, public/private keys) in addition to normal attributes (i.e. description). Changing the encryption requires retrieving the stored secret with the old attributes and rearchiving it with the new attributes. https://fedorahosted.org/freeipa/ticket/5176 --- API.txt | 27 +++- VERSION | 4 +- ipalib/plugins/vault.py | 232 ++++++++++++++++++++++++++-- ipatests/test_xmlrpc/test_vault_plugin.py | 246 ++++++++++++++++++++++++++++++ 4 files changed, 495 insertions(+), 14 deletions(-) diff --git a/API.txt b/API.txt index 9dbf86aedf2a1b62dabab21fb30bbceb2f0f237b..26f05cf9e1e27ec4f714bb34174e17972961bda2 100644 --- a/API.txt +++ b/API.txt @@ -5466,11 +5466,12 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?') option: Str('in?') +option: Flag('override_password?', autofill=True, default=False) option: Str('password?', cli_name='password') option: Str('password_file?', cli_name='password_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -5528,6 +5529,30 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod +args: 1,18,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('change_password?', autofill=True, default=False) +option: Str('description?', cli_name='desc') +option: Bytes('ipavaultpublickey?', cli_name='public_key') +option: Bytes('ipavaultsalt?', cli_name='salt') +option: Str('ipavaulttype?', cli_name='type') +option: Str('new_password?', cli_name='new_password') +option: Str('new_password_file?', cli_name='new_password_file') +option: Str('old_password?', cli_name='old_password') +option: Str('old_password_file?', cli_name='old_password_file') +option: Bytes('private_key?', cli_name='private_key') +option: Str('private_key_file?', cli_name='private_key_file') +option: Str('public_key_file?', cli_name='public_key_file') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_mod_internal args: 1,15,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') diff --git a/VERSION b/VERSION index c42bea06522dae55e1a89ff94ae394594086b467..feb9f4db92c7c7b95e9e5d5907b1f97e96b26886 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=149 -# Last change: edewata - Added CLI param and ACL for vault service operations +IPA_API_VERSION_MINOR=150 +# Last change: edewata - Added support for changing vault encryption. diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 5d367b376ef41427ed983f3eafe120ed477018d2..c9eb4378b5c40d4182a70b72ae785740492ac9cb 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -115,11 +115,37 @@ EXAMPLES: ipa vault-show [--user |--service |--shared] """) + _(""" - Modify a vault: + Modify vault description: ipa vault-mod [--user |--service |--shared] --desc """) + _(""" + Modify vault type: + ipa vault-mod + [--user |--service |--shared] + --type + [old password/private key] + [new password/public key] +""") + _(""" + Modify symmetric vault password: + ipa vault-mod + [--user |--service |--shared] + --change-password + ipa vault-mod + [--user |--service |--shared] + --old-password + --new-password + ipa vault-mod + [--user |--service |--shared] + --old-password-file + --new-password-file +""") + _(""" + Modify symmetric vault keys: + ipa vault-mod + [--user |--service |--shared] + --private-key-file + --public-key-file +""") + _(""" Delete a vault: ipa vault-del [--user |--service |--shared] @@ -442,7 +468,7 @@ class vault(LDAPObject): print ' ** Passwords do not match! **' - def get_existing_password(self, new=False): + def get_existing_password(self): """ Gets existing password from user. """ @@ -797,9 +823,183 @@ class vault_find(LDAPSearch): @register() -class vault_mod(LDAPUpdate): +class vault_mod(PKQuery, Local): __doc__ = _('Modify a vault.') + takes_options = vault_options + ( + Str( + 'description?', + cli_name='desc', + doc=_('Vault description'), + ), + Str( + 'ipavaulttype?', + cli_name='type', + doc=_('Vault type'), + ), + Bytes( + 'ipavaultsalt?', + cli_name='salt', + doc=_('Vault salt'), + ), + Flag( + 'change_password?', + doc=_('Change password'), + ), + Str( + 'old_password?', + cli_name='old_password', + doc=_('Old vault password'), + ), + Str( # TODO: use File parameter + 'old_password_file?', + cli_name='old_password_file', + doc=_('File containing the old vault password'), + ), + Str( + 'new_password?', + cli_name='new_password', + doc=_('New vault password'), + ), + Str( # TODO: use File parameter + 'new_password_file?', + cli_name='new_password_file', + doc=_('File containing the new vault password'), + ), + Bytes( + 'private_key?', + cli_name='private_key', + doc=_('Old vault private key'), + ), + Str( # TODO: use File parameter + 'private_key_file?', + cli_name='private_key_file', + doc=_('File containing the old vault private key'), + ), + Bytes( + 'ipavaultpublickey?', + cli_name='public_key', + doc=_('New vault public key'), + ), + Str( # TODO: use File parameter + 'public_key_file?', + cli_name='public_key_file', + doc=_('File containing the new vault public key'), + ), + ) + + has_output = output.standard_entry + + def forward(self, *args, **options): + + vault_type = options.pop('ipavaulttype', False) + salt = options.pop('ipavaultsalt', False) + change_password = options.pop('change_password', False) + + old_password = options.pop('old_password', None) + old_password_file = options.pop('old_password_file', None) + new_password = options.pop('new_password', None) + new_password_file = options.pop('new_password_file', None) + + old_private_key = options.pop('private_key', None) + old_private_key_file = options.pop('private_key_file', None) + new_public_key = options.pop('ipavaultpublickey', None) + new_public_key_file = options.pop('public_key_file', None) + + if self.api.env.in_server: + backend = self.api.Backend.ldap2 + else: + backend = self.api.Backend.rpcclient + if not backend.isconnected(): + backend.connect(ccache=krbV.default_context().default_ccache()) + + # determine the vault type based on parameters specified + if vault_type: + pass + + elif change_password or \ + new_password or new_password_file or salt: + vault_type = u'symmetric' + + elif new_public_key or new_public_key_file: + vault_type = u'asymmetric' + + # if vault type is specified, retrieve existing secret + if vault_type: + opts = options.copy() + opts.pop('description', None) + + opts['password'] = old_password + opts['password_file'] = old_password_file + opts['private_key'] = old_private_key + opts['private_key_file'] = old_private_key_file + + response = self.api.Command.vault_retrieve(*args, **opts) + data = response['result']['data'] + + opts = options.copy() + + # if vault type is specified, update crypto attributes + if vault_type: + opts['ipavaulttype'] = vault_type + + if vault_type == u'standard': + opts['ipavaultsalt'] = None + opts['ipavaultpublickey'] = None + + elif vault_type == u'symmetric': + if salt: + opts['ipavaultsalt'] = salt + else: + opts['ipavaultsalt'] = os.urandom(16) + + opts['ipavaultpublickey'] = None + + elif vault_type == u'asymmetric': + + # get new vault public key + if new_public_key and new_public_key_file: + raise errors.MutuallyExclusiveError( + reason=_('New public key specified multiple times')) + + elif new_public_key: + pass + + elif new_public_key_file: + new_public_key = validated_read('public_key_file', + new_public_key_file, + mode='rb') + + else: + raise errors.ValidationError( + name='ipavaultpublickey', + error=_('Missing new vault public key')) + + opts['ipavaultsalt'] = None + opts['ipavaultpublickey'] = new_public_key + + response = self.api.Command.vault_mod_internal(*args, **opts) + + # if vault type is specified, rearchive existing secret + if vault_type: + opts = options.copy() + opts.pop('description', None) + + opts['data'] = data + opts['password'] = new_password + opts['password_file'] = new_password_file + opts['override_password'] = True + + self.api.Command.vault_archive(*args, **opts) + + return response + + + at register() +class vault_mod_internal(LDAPUpdate): + + NO_CLI = True + takes_options = LDAPUpdate.takes_options + vault_options msg_summary = _('Modified vault "%(value)s"') @@ -912,6 +1112,10 @@ class vault_archive(PKQuery, Local): cli_name='password_file', doc=_('File containing the vault password'), ), + Flag( + 'override_password?', + doc=_('Override existing password'), + ), ) has_output = output.standard_entry @@ -926,6 +1130,8 @@ class vault_archive(PKQuery, Local): password = options.get('password') password_file = options.get('password_file') + override_password = options.pop('override_password', False) + # don't send these parameters to server if 'data' in options: del options['data'] @@ -980,15 +1186,19 @@ class vault_archive(PKQuery, Local): password = password.rstrip('\n') else: - password = self.obj.get_existing_password() + if override_password: + password = self.obj.get_new_password() + else: + password = self.obj.get_existing_password() - # verify password by retrieving existing data - opts = options.copy() - opts['password'] = password - try: - self.api.Command.vault_retrieve(*args, **opts) - except errors.NotFound: - pass + if not override_password: + # verify password by retrieving existing data + opts = options.copy() + opts['password'] = password + try: + self.api.Command.vault_retrieve(*args, **opts) + except errors.NotFound: + pass salt = vault['ipavaultsalt'][0] diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py index 03fb6ad0243867ee0e63f9a63b320a9da562e48d..077d9411b27a771e2c30c13215ffc08cfc6f7787 100644 --- a/ipatests/test_xmlrpc/test_vault_plugin.py +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -37,6 +37,7 @@ asymmetric_vault_name = u'asymmetric_test_vault' secret = ''.join(map(chr, xrange(0, 256))) password = u'password' +other_password = u'other_password' public_key = """ -----BEGIN PUBLIC KEY----- @@ -80,6 +81,48 @@ kUlCMj24a8XsShzYTWBIyW2ngvGe3pQ9PfjkUdm0LGZjYITCBvgOKw== -----END RSA PRIVATE KEY----- """ +other_public_key = """ +-----BEGIN PUBLIC KEY----- +MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv7E/QLVyKjrgDctZ50U7 +rmtL7Ks1QLoccp9WvZJ6WI1rYd0fX5FySS4dI6QTNZc6qww8NeNuZtkoxT9m1wkk +Rl/3wK7fWNLenH/+VHOaTQc20exg7ztfsO7JIsmKmigtticdR5C4jLfjcOp+WjLH +w3zrmrO5SIZ8njxMoDcQJa2vu/t281U/I7ti8ue09FSitIECU05vgmPS+MnXR8HK +PxXqrNkjl29mXNbPiByWwlse3Prwved9I7fwgpiHJqUBFudD/0tZ4DWyLG7t9wM1 +O8gRaRg1r+ENVpmMSvXo4+8+bR3rEYddD5zU7nKXafeuthXlXplae/8uZmCiSI63 +TwIDAQAB +-----END PUBLIC KEY----- +""" + +other_private_key = """ +-----BEGIN RSA PRIVATE KEY----- +MIIEpgIBAAKCAQEAv7E/QLVyKjrgDctZ50U7rmtL7Ks1QLoccp9WvZJ6WI1rYd0f +X5FySS4dI6QTNZc6qww8NeNuZtkoxT9m1wkkRl/3wK7fWNLenH/+VHOaTQc20exg +7ztfsO7JIsmKmigtticdR5C4jLfjcOp+WjLHw3zrmrO5SIZ8njxMoDcQJa2vu/t2 +81U/I7ti8ue09FSitIECU05vgmPS+MnXR8HKPxXqrNkjl29mXNbPiByWwlse3Prw +ved9I7fwgpiHJqUBFudD/0tZ4DWyLG7t9wM1O8gRaRg1r+ENVpmMSvXo4+8+bR3r +EYddD5zU7nKXafeuthXlXplae/8uZmCiSI63TwIDAQABAoIBAQCA+0GFR9F+isjx +Xy+qBpKmxLl8kKKvX8r+cSpLOkEqTlW/rqqKgnI0vVuL/L2UJKKsLvpghBxoBZyC +RCvtatBGrhIlS0UrHg/9m73Ek1hylfUUAQokTn4PrkwWJSgmm/xOATmZSs5ymNTn +yFCmXl69sdNR77YvD5bQXeBtOT+bKXy7yQ1TmYPwwSjL+WSlMV6ZfE3HNVmxPTpk +CTFS638cJblWk9MUIy8HIlhu6If2P4RnHr7ZGGivhREayvs0zXcAfqhIyFHruxSE +yYnmqH9paWjv5mP3YyLoKr+NUvvxnBr/9wCTt0TKgG8G6rpkHuPDLQni9wUGnew8 +QdMgFEohAoGBAPH4vaVB5gDVfvIqwJBsBLHpPq72GvxjrM/exD0jIIpXZxz9gCql +CmC5b1RS1uy8PMoc/RO4CE7UTLaTesciP6LjTD1RhH3rLLJO8/iVC1RXgMrCLHLm +ZQnDhIQGGNQxpvBjQy5ZOWat2dFxYhHN630IFPOtrWsOmJ5HsL1JrjzxAoGBAMrO +R1zNwQ42VbJS6AFshZVjmUV2h3REGh4zG/9IqL0Hz493hyCTGoDPLLXIbtkqNqzQ +XibSZ9RMVPKKTiNQTx91DTgh4Anz8xUr84tA2iAf3ayNWKi3Y3GhmP2EWp1qYeom +kV8Uq0lt4dHZuEo3LuqvbtbzlF9qUXqKS5qy6Tg/AoGBAKCp02o2HjzxhS/QeTmr +r1ZeE7PiTzrECAuh01TwzPtuW1XhcEdgfEqK9cPcmT5pIkflBZkhOcr1pdYYiI5O +TEigeY/BX6KoE251hALLG9GtpCN82DyWhAH+oy9ySOwj5793eTT+I2HtD1LE4SQH +QVQsmJTP/fS2pVl7KnwUvy9RAoGBAKzo2qchNewsHzx+uxgbsnkABfnXaP2T4sDE +yqYJCPTB6BFl02vOf9Y6zN/gF8JH333P2bY3xhaXTgXMLXqmSg+D+NVW7HEP8Lyo +UGj1zgN9p74qdODEGqETKiFb6vYzcW/1mhP6x18/tDz658k+611kXZge7O288+MK +bhNjXrx5AoGBAMox25PcxVgOjCd9+LdUcIOG6LQ971eCH1NKL9YAekICnwMrStbK +veCYju6ok4ZWnMiH8MR1jgC39RWtjJZwynCuPXUP2/vZkoVf1tCZyz7dSm8TdS/2 +5NdOHVy7+NQcEPSm7/FmXdpcR9ZSGAuxMBfnEUibdyz5LdJGnFUN/+HS +-----END RSA PRIVATE KEY----- +""" + class test_vault_plugin(Declarative): @@ -591,6 +634,47 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Change standard vault to symmetric vault', + 'command': ( + 'vault_mod', + [standard_vault_name], + { + 'ipavaulttype': u'symmetric', + 'new_password': password, + }, + ), + 'expected': { + 'value': standard_vault_name, + 'summary': u'Modified vault "%s"' % standard_vault_name, + 'result': { + 'cn': [standard_vault_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from standard vault converted to symmetric vault', + 'command': ( + 'vault_retrieve', + [standard_vault_name], + { + 'password': password, + }, + ), + 'expected': { + 'value': standard_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % standard_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Create symmetric vault', 'command': ( 'vault_add', @@ -653,6 +737,89 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Change symmetric vault password', + 'command': ( + 'vault_mod', + [symmetric_vault_name], + { + 'old_password': password, + 'new_password': other_password, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': u'Modified vault "%s"' % symmetric_vault_name, + 'result': { + 'cn': [symmetric_vault_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault with new password', + 'command': ( + 'vault_retrieve', + [symmetric_vault_name], + { + 'password': other_password, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { + 'desc': 'Change symmetric vault to asymmetric vault', + 'command': ( + 'vault_mod', + [symmetric_vault_name], + { + 'ipavaulttype': u'asymmetric', + 'old_password': other_password, + 'ipavaultpublickey': public_key, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': u'Modified vault "%s"' % symmetric_vault_name, + 'result': { + 'cn': [symmetric_vault_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault converted to asymmetric vault', + 'command': ( + 'vault_retrieve', + [symmetric_vault_name], + { + 'private_key': private_key, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Create asymmetric vault', 'command': ( 'vault_add', @@ -713,4 +880,83 @@ class test_vault_plugin(Declarative): }, }, + { + 'desc': 'Change asymmetric vault keys', + 'command': ( + 'vault_mod', + [asymmetric_vault_name], + { + 'private_key': private_key, + 'ipavaultpublickey': other_public_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': u'Modified vault "%s"' % asymmetric_vault_name, + 'result': { + 'cn': [asymmetric_vault_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [other_public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault with new keys', + 'command': ( + 'vault_retrieve', + [asymmetric_vault_name], + { + 'private_key': other_private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { + 'desc': 'Change asymmetric vault to standard vault', + 'command': ( + 'vault_mod', + [asymmetric_vault_name], + { + 'ipavaulttype': u'standard', + 'private_key': other_private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': u'Modified vault "%s"' % asymmetric_vault_name, + 'result': { + 'cn': [asymmetric_vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault converted to standard vault', + 'command': ( + 'vault_retrieve', + [asymmetric_vault_name], + {}, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + ] -- 2.1.0 From pvoborni at redhat.com Thu Aug 13 17:22:13 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Aug 2015 19:22:13 +0200 Subject: [Freeipa-devel] [PATCH 019] Asymmetric vault: validate public key in client In-Reply-To: <55CC89A5.30605@redhat.com> References: <55B134B6.1020209@redhat.com> <55CC6D05.10207@redhat.com> <55CC73A5.6010604@redhat.com> <55CC8818.6050300@redhat.com> <55CC89A5.30605@redhat.com> Message-ID: <55CCD245.5070109@redhat.com> On 08/13/2015 02:12 PM, Christian Heimes wrote: > On 2015-08-13 14:05, Petr Vobornik wrote: >> On 08/13/2015 12:38 PM, Christian Heimes wrote: >>> On 2015-08-13 12:10, Petr Vobornik wrote: >>>> On 07/23/2015 08:38 PM, Christian Heimes wrote: >>>>> The ipa vault commands now load the public keys in order to verify >>>>> them. >>>>> The validation also prevents a user from accidentally sending her >>>>> private keys to the server. The patch fixes #5142 and #5142. >>>>> >>>>> $ ./ipa vault-add AsymmetricVault --desc "Asymmetric vault" --type >>>>> asymmetric --public-key-file mykey.pem >>>>> ipa: ERROR: invalid 'ipavaultpublickey': Invalid or unsupported vault >>>>> public key: Could not unserialize key data. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5142 >>>>> https://fedorahosted.org/freeipa/ticket/5143 >>>>> >>>> >>>> ACK as fix for 5142. >>>> >>>> I don't think that it fixes 5143. The traceback is fixed therefore 5143 >>>> doesn't occur but if there was other traceback raised by >>>> `self.api.Command.vault_archive(*args, **opts)` then the vault added in >>>> `response = self.api.Command.vault_add_internal(*args, **options)` would >>>> be still created. >>> >>> Yes, that is correct. There aren't any arguments that can lead to an >>> exception. The arguments are either already validated by vault_add() or >>> don't raise an error. >>> >>> Of course there are plenty of opportunities errors. The connection to >>> the IPA or LDAP server could fail, NSS DB could be missing and so on. >>> How should we handle an error in vault_archive? Is there another way >>> then to delete the new vault all along? >>> >>> try: >>> self.api.Command.vault_archive(*args, **opts) >>> except Exception: >>> log_error() >>> self.api.Command.vault_del(*args, **opts) >>> report_error() >>> >>> Christian >>> >> >> Imho this is the way. But it may fail because of the same root cause as >> vault_archive. >> >> That said I don't see #5142 as a priority and would defer it. > > I'd still like to see my patch for #5142 in RHEL, too. It prevents > accidental exposure of private keys, too. In the test case the test > uploads his private keys to the server. FreeIPA should not leak a user's > private key. My patch prevents that, too. > Sorry, wrong number. I meant defer #5143. The patch for #5142 is OK. Pushed to: master: e4dff25838f7a2342779851bd68460080d77683b ipa-4-2: 06d68b447ff62b64a3a6e4a3c565fcf406a457ec -- Petr Vobornik From akasurde at redhat.com Fri Aug 14 04:57:08 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Fri, 14 Aug 2015 10:27:08 +0530 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55CC9DB9.5000705@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> Message-ID: <55CD7524.9080307@redhat.com> On 08/13/2015 07:08 PM, Martin Basti wrote: > > > On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >> Hi All, >> >> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 >> >> Thanks, >> Abhijeet Kasurde >> >> > > Hello, > > thank you for the patch > > 1) > - except ValueError: > + except EOFError, ValueError: > > Please use > except (EOFError, ValueError): > https://docs.python.org/2/tutorial/errors.html#handling-exceptions OK, I will include this. > 2) > I'm not sure if this code will work (I did not test it) > > I expect when stdin is closed, this will result into infinite loop, > because raw_input will always return EOFError. > > while True: > try: > ret = raw_input("%s: " % prompt) > if allow_empty or ret.strip(): > return ret > except EOFError: > pass > Could you please elaborate more on, so that I can include fix in this section of code? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Fri Aug 14 06:26:48 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 14 Aug 2015 08:26:48 +0200 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55CC6DC5.4090905@redhat.com> References: <55C866D5.5040808@redhat.com> <55CC4D5A.7030207@redhat.com> <55CC5A19.2070305@redhat.com> <55CC6DC5.4090905@redhat.com> Message-ID: <55CD8A28.2020907@redhat.com> The problem of current implementation of topologysegment-add is that it does not support '--connectivity' commandline option: $ ipa help topologysegment-add Usage: ipa [global-options] topologysegment-add TOPOLOGYSUFFIX NAME [options] Add a new segment. Options: -h, --help show this help message and exit --leftnode=STR Left replication node - an IPA server --rightnode=STR Right replication node - an IPA server --stripattrs=STR A space separated list of attributes which are removed from replication updates. --replattrs=STR Attributes that are not replicated to a consumer server during a fractional update. E.g., `(objectclass=*) $ EXCLUDE accountlockout memberof --replattrstotal=STR Attributes that are not replicated to a consumer server during a total update. E.g. (objectclass=*) $ EXCLUDE accountlockout --timeout=INT Number of seconds outbound LDAP operations waits for a response from the remote replica before timing out and failing --setattr=STR Set an attribute to a name/value pair. Format is attr=value. For multi-valued attributes, the command replaces the values already present. --addattr=STR Add an attribute/value pair. Format is attr=value. The attribute must be part of the schema. --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. But when you actually create a segment, it asks for connectivity interactively, which effectively blocks automation. On 08/13/2015 12:13 PM, Ludwig Krispenz wrote: > > On 08/13/2015 10:49 AM, Petr Vobornik wrote: >> On 08/13/2015 09:55 AM, Ludwig Krispenz wrote: >>> >>> On 08/10/2015 10:54 AM, Oleg Fayans wrote: >>>> Hi Ludwig, >>>> >>>> It seems the Design page for the topology plugin is a bit outdated. >>>> 1. It still operates with the terms like plugin version >>>> (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), >>>> >>>> although it was generally agreed, that we do not use plugin version at >>>> all. >>>> >>>> 2. The section >>>> http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition >>>> >>>> should be a bit clarified: >>>> Does this mean, that if we prepare a replica from a master that has >>>> domainlevel = 1, then the replica, that already had a domain level = 0 >>>> will raise it? Do we support this scenario at all? >>>> >>>> 3. Segment directions. Currently there is no way to specify segment >>>> direction using the cli `ipa topologysegment-add`. However the >>>> direction is shown with `ipa topologysegment-find` and `ipa >>>> topologysegment-show`, which leads to confusing of the users. We >>>> probably should remove this info from the output at all and update the >>>> design page accordingly. >>> this is not true, in segment add youcan specify the direction: >>> >>> adding the segment: >>> ------------- >>> [root at vm-215 ~]# ipa topologysegment-add realm >>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>> Connectivity [both]: left-right >>> Segment name >>> [vm-112.abc.idm.lab.eng.brq.redhat.com-to-vm-179.abc.idm.lab.eng.brq.redhat.com]: >>> >>> onedirect >>> ------------------------- >>> Added segment "onedirect" >>> ------------------------- >>> Segment name: onedirect >>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>> Connectivity: left-right >>> >>> >>> checking the segment: >>> >>> [root at vm-215 ~]# ipa topologysegment-find realm >>> ------------------ >>> ..... >>> ------------------ >>> Segment name: onedirect >>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>> Connectivity: left-right >>> >>> ...... >>> >> >> This is a bug. Option "direction" was removed from -add and -mod >> commands on purpose. > I thought it should only be removed from the mod, as it was not handled > in the plugin, but I think initial creation of a one directional segment > should be ok > >> But CLI still incorrectly asks for the value and therefore allows to >> change the default "both". > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pvoborni at redhat.com Fri Aug 14 07:25:06 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Aug 2015 09:25:06 +0200 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55CD8A28.2020907@redhat.com> References: <55C866D5.5040808@redhat.com> <55CC4D5A.7030207@redhat.com> <55CC5A19.2070305@redhat.com> <55CC6DC5.4090905@redhat.com> <55CD8A28.2020907@redhat.com> Message-ID: <55CD97D2.30708@redhat.com> On 08/14/2015 08:26 AM, Oleg Fayans wrote: > The problem of current implementation of topologysegment-add is that it > does not support '--connectivity' commandline option: > $ ipa help topologysegment-add > Usage: ipa [global-options] topologysegment-add TOPOLOGYSUFFIX NAME > [options] > > Add a new segment. > Options: > -h, --help show this help message and exit > --leftnode=STR Left replication node - an IPA server > --rightnode=STR Right replication node - an IPA server > --stripattrs=STR A space separated list of attributes which are > removed > from replication updates. > --replattrs=STR Attributes that are not replicated to a consumer > server during a fractional update. E.g., > `(objectclass=*) $ EXCLUDE accountlockout memberof > --replattrstotal=STR Attributes that are not replicated to a consumer > server during a total update. E.g. > (objectclass=*) $ > EXCLUDE accountlockout > --timeout=INT Number of seconds outbound LDAP operations > waits for a > response from the remote replica before timing > out and > failing > --setattr=STR Set an attribute to a name/value pair. Format is > attr=value. For multi-valued attributes, the > command > replaces the values already present. > --addattr=STR Add an attribute/value pair. Format is > attr=value. The > attribute must be part of the schema. > --all Retrieve and print all attributes from the server. > Affects command output. > --raw Print entries as stored on the server. Only > affects > output format. This is correct, see https://fedorahosted.org/freeipa/ticket/5061 > > But when you actually create a segment, it asks for connectivity > interactively, which effectively blocks automation. It should not ask, it's a bug, please file a ticket. > > > > On 08/13/2015 12:13 PM, Ludwig Krispenz wrote: >> >> On 08/13/2015 10:49 AM, Petr Vobornik wrote: >>> On 08/13/2015 09:55 AM, Ludwig Krispenz wrote: >>>> >>>> On 08/10/2015 10:54 AM, Oleg Fayans wrote: >>>>> Hi Ludwig, >>>>> >>>>> It seems the Design page for the topology plugin is a bit outdated. >>>>> 1. It still operates with the terms like plugin version >>>>> (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), >>>>> >>>>> >>>>> although it was generally agreed, that we do not use plugin version at >>>>> all. >>>>> >>>>> 2. The section >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition >>>>> >>>>> >>>>> should be a bit clarified: >>>>> Does this mean, that if we prepare a replica from a master that has >>>>> domainlevel = 1, then the replica, that already had a domain level = 0 >>>>> will raise it? Do we support this scenario at all? >>>>> >>>>> 3. Segment directions. Currently there is no way to specify segment >>>>> direction using the cli `ipa topologysegment-add`. However the >>>>> direction is shown with `ipa topologysegment-find` and `ipa >>>>> topologysegment-show`, which leads to confusing of the users. We >>>>> probably should remove this info from the output at all and update the >>>>> design page accordingly. >>>> this is not true, in segment add youcan specify the direction: >>>> >>>> adding the segment: >>>> ------------- >>>> [root at vm-215 ~]# ipa topologysegment-add realm >>>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>>> Connectivity [both]: left-right >>>> Segment name >>>> [vm-112.abc.idm.lab.eng.brq.redhat.com-to-vm-179.abc.idm.lab.eng.brq.redhat.com]: >>>> >>>> >>>> onedirect >>>> ------------------------- >>>> Added segment "onedirect" >>>> ------------------------- >>>> Segment name: onedirect >>>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>>> Connectivity: left-right >>>> >>>> >>>> checking the segment: >>>> >>>> [root at vm-215 ~]# ipa topologysegment-find realm >>>> ------------------ >>>> ..... >>>> ------------------ >>>> Segment name: onedirect >>>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>>> Connectivity: left-right >>>> >>>> ...... >>>> >>> >>> This is a bug. Option "direction" was removed from -add and -mod >>> commands on purpose. >> I thought it should only be removed from the mod, as it was not handled >> in the plugin, but I think initial creation of a one directional segment >> should be ok >> >>> But CLI still incorrectly asks for the value and therefore allows to >>> change the default "both". >> > -- Petr Vobornik From ofayans at redhat.com Fri Aug 14 08:44:22 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 14 Aug 2015 10:44:22 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55CCB279.9010200@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> Message-ID: <55CDAA66.4040808@redhat.com> Hi Martin, Already noticed that. Implemented the named groups as Tomas advised. Added the third test for http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica On 08/13/2015 05:06 PM, Martin Basti wrote: > > > On 08/11/2015 03:36 PM, Oleg Fayans wrote: >> Hi Martin, >> >> On 08/11/2015 02:02 PM, Martin Basti wrote: >>> NACK, comments inline. >>> >>> On 11/08/15 13:25, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review! >>>> >>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>> Thank you for patch, I have a few nitpicks: >>>>> >>>>> 1) >>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>> +def create_segment(master, leftnode, rightnode): >>>>>> + """create_segment(master, leftnode, rightnode) >>>>> Why do you add the name of method in docstring? >>>> My bad, fixed. >>> >>> still there >>> >>> + tokenize_topologies(command_output) >>> + takes an output of `ipa topologysegment-find` and returns an >>> array of >>> >> Fixed, sorry. >>> >>>>> >>>>> >>>>> 2) >>>>> >>>>> +def create_segment(master, leftnode, rightnode): >>>>> + """create_segment(master, leftnode, rightnode) >>>>> + creates a topology segment. The first argument is a node to >>>>> run the >>>>> command on >>>>> + The first 3 arguments should be objects of class Host >>>>> + Returns a hash object containing segment's name, leftnode, >>>>> rightnode information >>>>> + """ >>>>> >>>>> I would prefer to add assert there instead of just document that a >>>>> Host >>>>> object is needed >>>>> assert(isinstance(master, Host)) >>>>> ... >>>> >>>> Fixed. Created a decorator that checks the type of arguments >>> >>> This does not scale well. >>> If we will want to add new argument that is not host object, you need >>> change it again. >> >> Agreed. Modified the decorator so that you can specify a slice of >> arguments to be checked and a class to compare to. This does scale :) >>> >>> This might be used as function with specified variables that have to be >>> host objects >>>> >>>>> >>>>> 3) >>>>> +def destroy_segment(master, segment_name): >>>>> + """ >>>>> + destroy_segment(master, segment_name) >>>>> + Destroys topology segment. First argument should be object of >>>>> class >>>>> Host >>>>> >>>>> Instead of description of params as first, second etc., you may use >>>>> following: >>>>> >>>>> +def destroy_segment(master, segment_name): >>>>> + """ >>>>> + Destroys topology segment. >>>>> + :param master: reference to master object of class Host >>>>> + :param segment: name fo segment >>>>> and eventually this in other methods >>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>> + :raises NotFound: if segment is not found >>>>> >>>> Fixed >>>>> >>>>> 4) >>>>> >>>>> cls.replicas[:len(cls.replicas) - 1], >>>>> >>>>> I suggest cls.replicas[:-1] >>>>> >>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>> >>>>> In [3]: a[:-1] >>>>> Out[3]: [1, 2, 3, 4] >>>>> >>>> Fixed >>>>> >>>>> 5) >>>>> Why re.findall() and then you just use the first result? >>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>> >>>>> Isn't just re.search() enough? >>>>> leftnode_re.search(value).group(1) >>>> >>>> in fact >>>> leftnode_re.findall(string)[0] >>>> and >>>> leftnode_re.search(string).group(1), >>>> Are equally bad from the readability point of view. The first one is >>>> even shorter a bit, so why change? :) >>> >>> It depends on point of view, because when I reviewed it yesterday my >>> brain raises exception that you are trying to add multiple values to >>> single value attribute, because you used findall, I expected that you >>> need multiple values, and then I saw that index [0] at the end, and I >>> was pretty confused what are you trying to achieve. >>> >>> And because findall is not effective in case when you need to find just >>> one occurrence. >> >> I got it. Fixed. >> >>> >>> >>>> >>>>> >>>>> >>>>> Python 3 nitpick: >>>>> I'm not sure if time when we should enforce python 2/3 compability >>>>> already comes, but just for record: >>>>> instead of open(file, 'r'), please use io.open(file, 'r') (import io >>>>> before) >>>>> >>>> Done. >>>>> >>>>> >>>>> >>>> >>> >>> 1) >>> >>> +# >>> >>> empty comment here (several times) >> >> Removed >>> >> > > NACK > > you changed it wrong > > group() returns everything, you need use group(1) to return content in > braces. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.5-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 13558 bytes Desc: not available URL: From mbasti at redhat.com Fri Aug 14 09:04:26 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 11:04:26 +0200 Subject: [Freeipa-devel] [PATCH 0001] ipa-client-install: warn if IP address is used with --server option In-Reply-To: <55C9B3D5.4020902@redhat.com> References: <55C9B3D5.4020902@redhat.com> Message-ID: <55CDAF1A.8000805@redhat.com> On 08/11/2015 10:35 AM, Stanislav Laznicka wrote: > Hi, > > Attached is the patch that adds warning when an IP is passed to > --server in ipa-client-install > (https://fedorahosted.org/freeipa/ticket/4932). > > Standa > > ACK Pushed to: master: 592e437fc79e778cc96603a0f414c3456fcc9455 ipa-4-2: d55e10f4bda77c65663386a0748723df3518cb6d -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldoudova at redhat.com Fri Aug 14 09:04:26 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 14 Aug 2015 11:04:26 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55CC88F3.90305@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> Message-ID: <55CDAF1A.1040006@redhat.com> > NACK > > syntax error, missing ')' > -from ipatests.util import assert_equal, assert_not_equal, raises > +from ipatests.util import ( > + assert_equal, assert_not_equal, raises, assert_deepequal > > I cannot apply this patch, please check it Sorry for the error, corrected patch attached. I also added two testcases that Thierry proposed, and changed names of few methods (original ones were confusing). Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0002-3-Automated-test-for-stageuser-plugin.patch Type: text/x-patch Size: 54218 bytes Desc: not available URL: From mbasti at redhat.com Fri Aug 14 10:49:44 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 12:49:44 +0200 Subject: [Freeipa-devel] [PATCH 0059] dbus: Create empty dbus.Array with specified signature In-Reply-To: <55C8B1BC.8050002@redhat.com> References: <55C8B1BC.8050002@redhat.com> Message-ID: <55CDC7C8.4020308@redhat.com> On 08/10/2015 04:14 PM, David Kupka wrote: > I was installing freeipa-server earlier today and it failed with > "Unable to guess signature from empty list". > I was unable to reproduce it but there is now harm in explicitly > specifying the signature of the empty list to prevent this issue. > > > ACK Pushed to master: fe91c375d06b076c628e2e72cfdf48db54354444 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Aug 14 10:58:24 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 12:58:24 +0200 Subject: [Freeipa-devel] [PATCH] 910 add permission: System: Manage User Certificates In-Reply-To: <20150813134601.GB16439@dhcp-40-8.bne.redhat.com> References: <55CB4296.3020103@redhat.com> <20150813032836.GO16439@dhcp-40-8.bne.redhat.com> <55CC5DAA.4000307@redhat.com> <20150813092214.GY16439@dhcp-40-8.bne.redhat.com> <20150813093010.GX22106@redhat.com> <20150813134601.GB16439@dhcp-40-8.bne.redhat.com> Message-ID: <55CDC9D0.7050304@redhat.com> On 08/13/2015 03:46 PM, Fraser Tweedale wrote: > On Thu, Aug 13, 2015 at 12:30:10PM +0300, Alexander Bokovoy wrote: >> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >>> On Thu, Aug 13, 2015 at 11:04:42AM +0200, Petr Vobornik wrote: >>>> On 08/13/2015 05:28 AM, Fraser Tweedale wrote: >>>>> On Wed, Aug 12, 2015 at 02:56:54PM +0200, Petr Vobornik wrote: >>>>>> usercertificate attr was moved from "System Modify Users" to this >>>>>> new permission. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5177 >>>>>> >>>>>> Note: hosts have permission "System: Manage Host Certificates", services >>>>>> don't have it but usercertificate is in "System: Modify Services". I would >>>>>> move it as well if usercertificate was not the only attr in "System: Modify >>>>>> Services". >>>>>> >>>>> New permission works as expected. >>>>> >>>>> What are the implications of removing userCertificate attribute from >>>>> "Modify Users" ACI? Users could be relying on it given that there >>>>> is (until now) no more fine-grained permission. >>>> I'm not sure what is the expected ACI upgrade behavior but applying this >>>> patch on installed server and running ipa-server-upgrade ends with >>>> userCertificate still in "System: Modify Users" permission - it eliminates >>>> your worry. The rest of users who still run IPA < 4.2 won't even notice. >>>> >>> Ah, I see. >>> >>> This raises a different problem: different ACIs on different >>> deployments, depending on when IPA was installed. Unless I am >>> misunderstanding something, isn't that an undesirable situation? >> We have precedent of upgrading ACIs via upgrade plugins. >> So this is something we need to design for and execute. >> > If we've done it before and the consensus is that it's a problem for > another day, then I suppose it's an ACK from me. > > Cheers, > Fraser > Pushed to: master: 6b978d74ae36f377c2d4f2cae860ca79b102e3c0 ipa-4-2: 7a509980d24b2bd445633026e64db48bb4203ba0 From mbasti at redhat.com Fri Aug 14 11:49:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 13:49:13 +0200 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55CD7524.9080307@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> <55CD7524.9080307@redhat.com> Message-ID: <55CDD5B9.1050105@redhat.com> On 08/14/2015 06:57 AM, Abhijeet Kasurde wrote: > > On 08/13/2015 07:08 PM, Martin Basti wrote: >> >> >> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 >>> >>> Thanks, >>> Abhijeet Kasurde >>> >>> >> >> Hello, >> >> thank you for the patch >> >> 1) >> - except ValueError: >> + except EOFError, ValueError: >> >> Please use >> except (EOFError, ValueError): >> https://docs.python.org/2/tutorial/errors.html#handling-exceptions > OK, I will include this. >> 2) >> I'm not sure if this code will work (I did not test it) >> >> I expect when stdin is closed, this will result into infinite loop, >> because raw_input will always return EOFError. >> >> while True: >> try: >> ret = raw_input("%s: " % prompt) >> if allow_empty or ret.strip(): >> return ret >> except EOFError: >> pass >> > Could you please elaborate more on, so that I can include fix in this > section of code? If you receive EOF you cannot continue in while cycle because, it will return EOF every iteration forever. If EOF is received the while cycle must end, and appropriate action must be take. It depends on situation, if default value is present then default value should be used, or in case if empty value is allowed, empty string should be returned. In case there is no default value and empty value is not allowed, then an exception should be raised. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Fri Aug 14 11:55:23 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 14 Aug 2015 13:55:23 +0200 Subject: [Freeipa-devel] Topology Plugin design questions In-Reply-To: <55CD97D2.30708@redhat.com> References: <55C866D5.5040808@redhat.com> <55CC4D5A.7030207@redhat.com> <55CC5A19.2070305@redhat.com> <55CC6DC5.4090905@redhat.com> <55CD8A28.2020907@redhat.com> <55CD97D2.30708@redhat.com> Message-ID: <55CDD72B.3070301@redhat.com> Hi Petr, Ludwig, On 08/14/2015 09:25 AM, Petr Vobornik wrote: > On 08/14/2015 08:26 AM, Oleg Fayans wrote: >> The problem of current implementation of topologysegment-add is that it >> does not support '--connectivity' commandline option: >> $ ipa help topologysegment-add >> Usage: ipa [global-options] topologysegment-add TOPOLOGYSUFFIX NAME >> [options] >> >> Add a new segment. >> Options: >> -h, --help show this help message and exit >> --leftnode=STR Left replication node - an IPA server >> --rightnode=STR Right replication node - an IPA server >> --stripattrs=STR A space separated list of attributes which are >> removed >> from replication updates. >> --replattrs=STR Attributes that are not replicated to a consumer >> server during a fractional update. E.g., >> `(objectclass=*) $ EXCLUDE accountlockout >> memberof >> --replattrstotal=STR Attributes that are not replicated to a consumer >> server during a total update. E.g. >> (objectclass=*) $ >> EXCLUDE accountlockout >> --timeout=INT Number of seconds outbound LDAP operations >> waits for a >> response from the remote replica before timing >> out and >> failing >> --setattr=STR Set an attribute to a name/value pair. Format is >> attr=value. For multi-valued attributes, the >> command >> replaces the values already present. >> --addattr=STR Add an attribute/value pair. Format is >> attr=value. The >> attribute must be part of the schema. >> --all Retrieve and print all attributes from the >> server. >> Affects command output. >> --raw Print entries as stored on the server. Only >> affects >> output format. > > This is correct, see https://fedorahosted.org/freeipa/ticket/5061 > >> >> But when you actually create a segment, it asks for connectivity >> interactively, which effectively blocks automation. > > It should not ask, it's a bug, please file a ticket. Filed the following ticket: https://fedorahosted.org/freeipa/ticket/5222 > >> >> >> >> On 08/13/2015 12:13 PM, Ludwig Krispenz wrote: >>> >>> On 08/13/2015 10:49 AM, Petr Vobornik wrote: >>>> On 08/13/2015 09:55 AM, Ludwig Krispenz wrote: >>>>> >>>>> On 08/10/2015 10:54 AM, Oleg Fayans wrote: >>>>>> Hi Ludwig, >>>>>> >>>>>> It seems the Design page for the topology plugin is a bit outdated. >>>>>> 1. It still operates with the terms like plugin version >>>>>> (http://www.freeipa.org/page/V4/Manage_replication_topology#Check_for_modify_operation), >>>>>> >>>>>> >>>>>> >>>>>> although it was generally agreed, that we do not use plugin >>>>>> version at >>>>>> all. >>>>>> >>>>>> 2. The section >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology#Check_after_online_initializatition >>>>>> >>>>>> >>>>>> >>>>>> should be a bit clarified: >>>>>> Does this mean, that if we prepare a replica from a master that has >>>>>> domainlevel = 1, then the replica, that already had a domain level >>>>>> = 0 >>>>>> will raise it? Do we support this scenario at all? >>>>>> >>>>>> 3. Segment directions. Currently there is no way to specify segment >>>>>> direction using the cli `ipa topologysegment-add`. However the >>>>>> direction is shown with `ipa topologysegment-find` and `ipa >>>>>> topologysegment-show`, which leads to confusing of the users. We >>>>>> probably should remove this info from the output at all and update >>>>>> the >>>>>> design page accordingly. >>>>> this is not true, in segment add youcan specify the direction: >>>>> >>>>> adding the segment: >>>>> ------------- >>>>> [root at vm-215 ~]# ipa topologysegment-add realm >>>>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>>>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>>>> Connectivity [both]: left-right >>>>> Segment name >>>>> [vm-112.abc.idm.lab.eng.brq.redhat.com-to-vm-179.abc.idm.lab.eng.brq.redhat.com]: >>>>> >>>>> >>>>> >>>>> onedirect >>>>> ------------------------- >>>>> Added segment "onedirect" >>>>> ------------------------- >>>>> Segment name: onedirect >>>>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>>>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>>>> Connectivity: left-right >>>>> >>>>> >>>>> checking the segment: >>>>> >>>>> [root at vm-215 ~]# ipa topologysegment-find realm >>>>> ------------------ >>>>> ..... >>>>> ------------------ >>>>> Segment name: onedirect >>>>> Left node: vm-112.abc.idm.lab.eng.brq.redhat.com >>>>> Right node: vm-179.abc.idm.lab.eng.brq.redhat.com >>>>> Connectivity: left-right >>>>> >>>>> ...... >>>>> >>>> >>>> This is a bug. Option "direction" was removed from -add and -mod >>>> commands on purpose. >>> I thought it should only be removed from the mod, as it was not handled >>> in the plugin, but I think initial creation of a one directional segment >>> should be ok >>> >>>> But CLI still incorrectly asks for the value and therefore allows to >>>> change the default "both". >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Fri Aug 14 12:02:36 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 14:02:36 +0200 Subject: [Freeipa-devel] [PATCH] 0030 Add permission for bypassing CA ACL enforcement In-Reply-To: <55CCA035.7080806@redhat.com> References: <20150804052129.GG4843@dhcp-40-8.bne.redhat.com> <20150813034601.GP16439@dhcp-40-8.bne.redhat.com> <55CCA035.7080806@redhat.com> Message-ID: <55CDD8DC.9030609@redhat.com> On 08/13/2015 03:48 PM, Martin Babinsky wrote: > On 08/13/2015 05:46 AM, Fraser Tweedale wrote: >> On Tue, Aug 04, 2015 at 03:21:29PM +1000, Fraser Tweedale wrote: >>> The attached patch fixes >>> https://fedorahosted.org/freeipa/ticket/5099. >>> >>> Thanks, >>> Fraser >> >> Ping; this patch needs review. >> > > ACK > Pushed to: master: 6fa14fd21e664925268d80a2263c556b2bc35139 ipa-4-2: ef8f431c93b5587247eeb7de9e74d15e5fc6f616 From mbasti at redhat.com Fri Aug 14 15:18:07 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 17:18:07 +0200 Subject: [Freeipa-devel] [PATCH 0060] user-undel: Fix error messages. In-Reply-To: <55CC3660.70205@redhat.com> References: <55CC3660.70205@redhat.com> Message-ID: <55CE06AF.6060607@redhat.com> On 08/13/2015 08:17 AM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/5207 > > Requires patch freeipa-jcholast-471.1. > > NACK This patch causes internal server error ipa user-del user --preserve [Fri Aug 14 17:16:13.691565 2015] [wsgi:error] [pid 3210] ipa: ERROR: non-public: TypeError: %d format: a number is required, not str [Fri Aug 14 17:16:13.691605 2015] [wsgi:error] [pid 3210] Traceback (most recent call last): [Fri Aug 14 17:16:13.691610 2015] [wsgi:error] [pid 3210] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 347, in wsgi_execute [Fri Aug 14 17:16:13.691614 2015] [wsgi:error] [pid 3210] result = self.Command[name](*args, **options) [Fri Aug 14 17:16:13.691618 2015] [wsgi:error] [pid 3210] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 457, in __call__ [Fri Aug 14 17:16:13.691622 2015] [wsgi:error] [pid 3210] self.validate_output(ret, options['version']) [Fri Aug 14 17:16:13.691626 2015] [wsgi:error] [pid 3210] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 950, in validate_output [Fri Aug 14 17:16:13.691630 2015] [wsgi:error] [pid 3210] o.validate(self, value, version) [Fri Aug 14 17:16:13.691634 2015] [wsgi:error] [pid 3210] File "/usr/lib/python2.7/site-packages/ipalib/output.py", line 151, in validate [Fri Aug 14 17:16:13.691638 2015] [wsgi:error] [pid 3210] types[0], type(value), value)) [Fri Aug 14 17:16:13.691642 2015] [wsgi:error] [pid 3210] TypeError: %d format: a number is required, not str [Fri Aug 14 17:16:13.692063 2015] [wsgi:error] [pid 3210] ipa: INFO: [jsonserver_session] admin at EXAMPLE.COM: user_del((u'user',), continue=False, preserve=True, version=u'2.148'): TypeError (END) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Aug 14 15:31:02 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 17:31:02 +0200 Subject: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged In-Reply-To: <55CB6465.9050903@redhat.com> References: <55B0E154.7000907@redhat.com> <55B65565.7090409@redhat.com> <55B74AEB.3050000@redhat.com> <55B74D08.2010207@redhat.com> <55B75A9F.7090308@redhat.com> <55BF89EA.3050901@redhat.com> <1722330737.3490312.1438766871878.JavaMail.zimbra@redhat.com> <55C1DD9D.8000806@redhat.com> <55C1E1D6.1060104@redhat.com> <55C1E6BF.1060309@redhat.com> <55C9A17E.4040506@redhat.com> <55C9A516.2010603@redhat.com> <55C9B4E3.8050007@redhat.com> <55CB2164.8020203@redhat.com> <55CB23DB.9010306@redhat.com> <55CB2ADE.7090309@redhat.com> <55CB375B.6080209@redhat.com> <55CB3A7C.3010201@redhat.com> <55CB406F.9030501@redhat.com> <55CB6465.9050903@redhat.com> Message-ID: <55CE09B6.5050703@redhat.com> On 08/12/2015 05:21 PM, Martin Basti wrote: > > > On 08/12/2015 02:47 PM, Tomas Capek wrote: >> On 12/08/15 14:22, Martin Basti wrote: >>> >>> >>> On 08/12/2015 02:08 PM, Tomas Capek wrote: >>>> On 12/08/15 13:15, David Kupka wrote: >>>>> On 12/08/15 12:45, thierry bordaz wrote: >>>>>> On 08/12/2015 12:35 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/11/2015 10:40 AM, thierry bordaz wrote: >>>>>>>> On 08/11/2015 09:32 AM, Martin Basti wrote: >>>>>>>>> On 11/08/15 09:17, Jan Cholasta wrote: >>>>>>>>>> On 5.8.2015 12:34, thierry bordaz wrote: >>>>>>>>>>> On 08/05/2015 12:13 PM, Jan Cholasta wrote: >>>>>>>>>>>> Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): >>>>>>>>>>>>> On 08/05/2015 11:27 AM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>> From: "thierry bordaz" >>>>>>>>>>>>>> To: "Jan Cholasta" >>>>>>>>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>>>>>>>> Sent: Monday, August 3, 2015 5:34:02 PM >>>>>>>>>>>>>> Subject: Re: [Freeipa-devel] Replace stageuser-add >>>>>>>>>>>>>> --from-delete with >>>>>>>>>>>>>> user-undel --to-staged >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 07/28/2015 12:34 PM, Jan Cholasta wrote: >>>>>>>>>>>>>>> Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): >>>>>>>>>>>>>>>>> Dne 27.7.2015 v 17:59 Martin Basti napsal(a): >>>>>>>>>>>>>>>>>> On 23/07/15 14:43, Martin Basti wrote: >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I tried to fix #5145 and I partially succeeded. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> However, I cannot fix this part of ticket, where >>>>>>>>>>>>>>>>>>> user is >>>>>>>>>>>>>>>>>>> prompted to >>>>>>>>>>>>>>>>>>> write name and surname. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> $ ipa stageuser-add tuser --from-delete >>>>>>>>>>>>>>>>>>> First name: this will be ignored >>>>>>>>>>>>>>>>>>> Last name: this will be also ignored >>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>> Added stage user "tuser" >>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As the first name and last name are mandatory >>>>>>>>>>>>>>>>>>> attributes of >>>>>>>>>>>>>>>>>>> stageuser-add command, but they are not needed by >>>>>>>>>>>>>>>>>>> when the >>>>>>>>>>>>>>>>>>> --from-delete option is used. >>>>>>>>>>>>>>>>>>> I would like to ask how to fix this issue, IMO this >>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>> be huge >>>>>>>>>>>>>>>>>>> hack >>>>>>>>>>>>>>>>>>> in internal API. Or should we just document this bug >>>>>>>>>>>>>>>>>>> as known >>>>>>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>>>>>> (thierry wrote that this is not use case that should >>>>>>>>>>>>>>>>>>> be used >>>>>>>>>>>>>>>>>>> often)? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The best solution would be separate command, but >>>>>>>>>>>>>>>>>>> this idea >>>>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>>> rejected in thread "[Freeipa-devel] User life cycle: >>>>>>>>>>>>>>>>>>> question >>>>>>>>>>>>>>>>>>> regarding the design" >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> as was mentioned before, we have issue with current >>>>>>>>>>>>>>>>>> internal API >>>>>>>>>>>>>>>>>> and the >>>>>>>>>>>>>>>>>> stageuser-add --from-delete command. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We discussed this today, and we did not find a nice >>>>>>>>>>>>>>>>>> way how >>>>>>>>>>>>>>>>>> to fix >>>>>>>>>>>>>>>>>> it, >>>>>>>>>>>>>>>>>> so we propose this (which is IMO the best solution): >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * stageuser-add --from-delete should be deprecated >>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * create new option for user-undel: used-undel >>>>>>>>>>>>>>>>>> --to-staged (or >>>>>>>>>>>>>>>>>> create >>>>>>>>>>>>>>>>>> new command) that will handle moving deleted users to >>>>>>>>>>>>>>>>>> staged >>>>>>>>>>>>>>>>>> area as >>>>>>>>>>>>>>>>>> --from-delete did. >>>>>>>>>>>>>>>>> Make it new command please. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Instead of stageuser-add and option --from-delete, >>>>>>>>>>>>>>>>>> which work >>>>>>>>>>>>>>>>>> totally >>>>>>>>>>>>>>>>>> different, the command user-undel does similar >>>>>>>>>>>>>>>>>> operation than >>>>>>>>>>>>>>>>>> stage-user >>>>>>>>>>>>>>>>>> --from-delete, it just uses different container. >>>>>>>>>>>>>>>>> NACK on stuffing everything into a single command just >>>>>>>>>>>>>>>>> because it >>>>>>>>>>>>>>>>> does >>>>>>>>>>>>>>>>> something similar. >>>>>>>>>>>>>>>> How about making it a 'stageuser-undel'? The >>>>>>>>>>>>>>>> 'user-undel' moves >>>>>>>>>>>>>>>> preserved user to active, so the 'stageuser-undel' >>>>>>>>>>>>>>>> would move >>>>>>>>>>>>>>>> preserved >>>>>>>>>>>>>>>> to staged. The action is similar, but has slightly >>>>>>>>>>>>>>>> different >>>>>>>>>>>>>>>> specifics >>>>>>>>>>>>>>>> (which attributes are preserved etc.), and for me the >>>>>>>>>>>>>>>> 'stageuser-undel' >>>>>>>>>>>>>>>> feels more natural than 'user-undel --to-staged' since >>>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>> basically >>>>>>>>>>>>>>>> the same as there is 'stageuser-add' for creating a staged >>>>>>>>>>>>>>>> user, not >>>>>>>>>>>>>>>> 'user-add --to-staged'. It would be in the same style >>>>>>>>>>>>>>>> as all the >>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>> commands concerning operations with users in staged >>>>>>>>>>>>>>>> container. >>>>>>>>>>>>>>> Well, user-undel is the opposite of user-del, and >>>>>>>>>>>>>>> stageuser-undel >>>>>>>>>>>>>>> should be the opposite of stageuser-del. The >>>>>>>>>>>>>>> stageuser-undel >>>>>>>>>>>>>>> you are >>>>>>>>>>>>>>> suggesting is not. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also I'm not sure if we want to (always) remove the deleted >>>>>>>>>>>>>>> user once >>>>>>>>>>>>>>> a staged user is created from it, but -undel behaves >>>>>>>>>>>>>>> like that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't think the command should be limited to deleted >>>>>>>>>>>>>>> users >>>>>>>>>>>>>>> only. >>>>>>>>>>>>>>> Active and deleted users share the same namespace, so it >>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>> arbitrary limitation. >>>>>>>>>>>>>> preserved users has been valid active user. In that sense >>>>>>>>>>>>>> active/preserved are managed by a same set of CLI >>>>>>>>>>>>>> (user-find,user-del,user-show) because a preserved user is a >>>>>>>>>>>>>> 'user'. So >>>>>>>>>>>>>> I would vote for continuing with a 'user-*' commands and use >>>>>>>>>>>>>> 'user-undel >>>>>>>>>>>>>> --to-stage'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But then if we will make any incompatible change between >>>>>>>>>>>>>> "user-undel" >>>>>>>>>>>>>> and "user-undel --to-stage" we may hit this issue again. I >>>>>>>>>>>>>> agree with >>>>>>>>>>>>>> Honza, this should be a separate command. >>>>>>>>>>>>> What do you mean 'incompatible change' ? >>>>>>>>>>>>> >>>>>>>>>>>>> --to-stage option would only select a different container >>>>>>>>>>>>> that the >>>>>>>>>>>>> 'Active' one ? >>>>>>>>>>>> >>>>>>>>>>>> That's not sufficient. The command should do the reverse of >>>>>>>>>>>> stageuser-activate, which is ADD and DELETE, possibly with >>>>>>>>>>>> some >>>>>>>>>>>> modifications of the entry between them, not MODRDN like >>>>>>>>>>>> user-undel does. >>>>>>>>>>>> >>>>>>>>>>> That is a good point. Do we need to modify anything from a >>>>>>>>>>> deleted >>>>>>>>>>> entry >>>>>>>>>>> to a add it in the stage container. >>>>>>>>>>> Already delete entry have been purged of several values >>>>>>>>>>> (password, >>>>>>>>>>> krb >>>>>>>>>>> keys, membership,..) do you think of other attributes to >>>>>>>>>>> remove ? >>>>>>>>>>> >>>>>>>>>>> IIRC the use case is a support engineer who activated too >>>>>>>>>>> early an >>>>>>>>>>> entry. So you are right he wants to unactivate it. A >>>>>>>>>>> question is does >>>>>>>>>>> the unactivation requires more modifications than the one >>>>>>>>>>> did by >>>>>>>>>>> 'user-del --preserve'. Note that we can not retrieve the >>>>>>>>>>> attribute >>>>>>>>>>> values when the entry was activated from stage. >>>>>>>>>> >>>>>>>>>> I don't know if any modifications are needed ATM (doesn't mean >>>>>>>>>> there can't be any in the future), but the point is that if >>>>>>>>>> you are >>>>>>>>>> creating object A from object B using operation X, you should be >>>>>>>>>> creating object B from object A using the reverse of >>>>>>>>>> operation X, >>>>>>>>>> otherwise there *will* be inconsistencies, and we don't want >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>> +1 >>>>>>>>> I agree with this >>>>>>>>> >>>>>>>> So my understanding is that you think a new verb should be >>>>>>>> created to >>>>>>>> allow: 'Active' -> 'Stage' >>>>>>>> I do not recall why this was not discussed or if it as already >>>>>>>> been >>>>>>>> rejected. >>>>>>>> >>>>>>>> I like the idea and I think it could be useful to Support >>>>>>>> Engineer. >>>>>>>> Now I am not sure we want to make 'easy' the action to >>>>>>>> 'unactivate' a >>>>>>>> user (currently it requires two operations). >>>>>>>> In your opinion, does it replace 'stageuser-add --from-delete' or >>>>>>>> 'user-undel --to-stage' ? or is it an additional subcommand. >>>>>>>> Also, activate/unactivate is not a NULL operation. Some values has >>>>>>>> been changed (uid,gid,uniqueuiid...) and some values will be lost >>>>>>>> (membership). >>>>>>>> >>>>>>>> About the verb, this is not because the previous action is >>>>>>>> 'activate' >>>>>>>> that we should use 'unactivate'. For example, Thomas raised the >>>>>>>> point >>>>>>>> that after 'user-del', 'user-restore' would have been more user >>>>>>>> friendly than 'user-undel' >>>>>>>> >>>>>>>> Thanks >>>>>>>> thierry >>>>>>>> >>>>>>> We had discussion off-list discussion, and result is following >>>>>>> proposal: >>>>>>> >>>>>>> * remove 'stageuser-add --from-delete' >>>>>>> * add new command: 'user-stage' >>>>>>> >>>>>>> the user-stage command will move both deleted or active users to >>>>>>> staged area. >>>>>>> $ user-stage >>>>>>> replaces the stage-user --from-delete, keeps the same behavior >>>>>>> >>>>>>> $ user-stage >>>>>>> this is stretch goal, nice to have, but I don't know how easy is to >>>>>>> implement this >>>>>>> >>>>>>> For better visualization, here is link to our board screen >>>>>>> https://pvoborni.fedorapeople.org/images/user-lifecycle.jpg >>>>>>> >>>>>>> Thierry, do you agree with this? >>>>>>> Martin^2 >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> I really like the idea (as well as the drawing) of having the >>>>>> same cli >>>>>> for both active/deleted user. >>>>>> About the exact verb 'user-stage', I am always bad at this >>>>>> exercise and >>>>>> it would be great to have Thomas ack on that. >>>>>> >>>>>> Just a question about the other verbs user-disable/user-enable. I >>>>>> know >>>>>> they are doing something different but do you think there is a >>>>>> risk of >>>>>> confusion for admin when he should do user-stage or user-disable ? >>>>>> >>>>>> thanks >>>>>> thierry >>>>>> >>>>>> >>>>>> >>>>> >>>>> Adding Tomas to the loop. >>>> Hello everyone, >>>> >>>> I probably don't have all the information and perhaps cannot see >>>> all possible side effects but on the handover session for this >>>> feature, I was concerned that some commands did not match in GUI >>>> and in CLI (restore, undel). >>>> >>>> Also, from the UX perspective, I thought it would be more friendly >>>> to have symmetrical commands and not confuse users with two delete >>>> modes as in "do you want to mock-delete the user or delete delete it?" >>>> >>>> Therefore, I proposed to have two simple pairs of commands, also >>>> reflected in the UI: >>>> >>>> "add" and "delete" - for just adding and completely removing users >>>> >>>> "retire" and "restore" - for just putting a user to or taking it >>>> out of the user "archive" >>>> >>> Sounds good, but we will not change all commands. >> >> Sure, I made this proposal only for the user lifecycle feature. >> Perhaps some commands could be aliases if it would make it easier to >> introduce them... >> >>> >>>> as for the "--from-delete" option , I think the proposed >>>> "user-stage" overlaps a little with the existing "stageuser-*" >>>> commands. As the command would move a user to the initial state of >>>> the lifecycle, be it an active or retired user, I'd try to >>>> emphasize the fact by proposing a similar but perhaps more cogent >>>> "user-restage". >>>> >>>> Do you think it would work? >>> How about case, when user was created via 'user-add', then >>> 'user-restage' may confuse users, because that user hasn't been in >>> stage area. >>> >> I guess it depends on whether the user is aware of the lifecycle >> feature as the stage would be implied even if some users start as active. >> >> But we could add to the symmetry of the commands: >> >> *add - delete* (manipulates active or staged users) >> **activate - deactivate* *(between staged and active users)* >> retire - restore* (between active and archived users) >> >> *retire - restage *(between staged and archived users) > We cannot change commands that already exist, it would be more pain > than gain. > >> >> Admittedly, both of the cases in the last pair seem weird and rare to >> be used. But if the "retire" action ultimately remains undefined for >> staged users, I think it would still be fine as "restage" pushes a >> user through two states back :-) > And I'm quite lost in what you wrote. We have user-* and stageuser-* > commads >> >> Also, if we have the "deactivate" action for active users, I'd try to >> make it clear what are the practical differences between "retire" and >> "deactivate" in this setup. > We have: > activate: stageuser-activate > deactivate: user-del --preserve > retire: planned user-stage (active user) > restore: user-undel (applies only to users) > restage: planned user-stage (deleted user) > staged->archived user: N/A >> >> Cheers, >> Tomas >> >> >> >>> Martin^2 >>>> >>>> Tomas >>>> >>>> >>> >> >> >> -- >> Tom?? ?apek >> tcapek at redhat.com >> IRC Nick: tcapek >> Team name: Customer Content Services (CCS) > > > It looks like there is still no consensus about the name. I would like to name it 'user-stage', because we cannot change name of already implemented commands, there is no way to use naming schema that Tomas proposed. Is there any objections? I will send patch next week. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Aug 14 15:39:50 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 14 Aug 2015 17:39:50 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55CDAF1A.1040006@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> Message-ID: <55CE0BC6.7080208@redhat.com> On 08/14/2015 11:04 AM, Lenka Doudova wrote: >> NACK >> >> syntax error, missing ')' >> -from ipatests.util import assert_equal, assert_not_equal, raises >> +from ipatests.util import ( >> + assert_equal, assert_not_equal, raises, assert_deepequal >> >> I cannot apply this patch, please check it > > Sorry for the error, corrected patch attached. > I also added two testcases that Thierry proposed, and changed names of > few methods (original ones were confusing). > > Lenka I got this error ==================================================================================================== FAILURES ===================================================================================================== ____________________________________________________________________________________ TestPreserved.test_staged_from_preserved _____________________________________________________________________________________ self = , user = stageduser = def test_staged_from_preserved(self, user, stageduser): user.make_preserved_user() stageduser.ensure_missing() stageduser = StageUserTracker(user.uid, user.givenname, user.sn) stageduser.create_from_preserved(user) > command = user.make_create_command(from_delete=True) E TypeError: make_create_command() got an unexpected keyword argument 'from_delete' test_xmlrpc/test_stageuser_plugin.py:718: TypeError ---------------------------------------------------------------------------------------------- Captured stdout setup ---------------------------------------------------------------------------------------------- Ran command: ipalib.plugins.stageuser.stageuser_del()(u'suser1', version=u'2.148'): NotFound: suser1: stage user not found ---------------------------------------------------------------------------------------------- Captured stdout call ----------------------------------------------------------------------------------------------- Ran command: ipalib.plugins.user.user_add()(u'auser1', givenname=u'active', sn=u'user', version=u'2.148'): OK Ran command: ipalib.plugins.user.user_del()(u'auser1', preserve=True, no_preserve=False, version=u'2.148'): OK Martin^2 From ldoudova at redhat.com Fri Aug 14 16:32:32 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 14 Aug 2015 18:32:32 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55CE0BC6.7080208@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> Message-ID: <55CE1820.5060405@redhat.com> Yes, that is "correct" - it's malfunctioning behavior of the plugin - command 'stageuser-add --from-delete', which is discussed in another thread. I left this test case for so long as it's not fixed/changed. If the command remains and is fixed, the test case will be valid, if it's changed I'll fix the test case to reflect the new command. Lenka On 08/14/2015 05:39 PM, Martin Basti wrote: > > > On 08/14/2015 11:04 AM, Lenka Doudova wrote: >>> NACK >>> >>> syntax error, missing ')' >>> -from ipatests.util import assert_equal, assert_not_equal, raises >>> +from ipatests.util import ( >>> + assert_equal, assert_not_equal, raises, assert_deepequal >>> >>> I cannot apply this patch, please check it >> >> Sorry for the error, corrected patch attached. >> I also added two testcases that Thierry proposed, and changed names >> of few methods (original ones were confusing). >> >> Lenka > I got this error > > ==================================================================================================== > FAILURES > ===================================================================================================== > ____________________________________________________________________________________ > TestPreserved.test_staged_from_preserved > _____________________________________________________________________________________ > > self = object at 0x7ffb94811350>, user = > 0x7ffb949e7190> > stageduser = > 0x7ffb94811c50> > > def test_staged_from_preserved(self, user, stageduser): > user.make_preserved_user() > > stageduser.ensure_missing() > stageduser = StageUserTracker(user.uid, user.givenname, user.sn) > stageduser.create_from_preserved(user) > > command = user.make_create_command(from_delete=True) > E TypeError: make_create_command() got an unexpected keyword > argument 'from_delete' > > test_xmlrpc/test_stageuser_plugin.py:718: TypeError > ---------------------------------------------------------------------------------------------- > Captured stdout setup > ---------------------------------------------------------------------------------------------- > Ran command: ipalib.plugins.stageuser.stageuser_del()(u'suser1', > version=u'2.148'): NotFound: suser1: stage user not found > ---------------------------------------------------------------------------------------------- > Captured stdout call > ----------------------------------------------------------------------------------------------- > Ran command: ipalib.plugins.user.user_add()(u'auser1', > givenname=u'active', sn=u'user', version=u'2.148'): OK > Ran command: ipalib.plugins.user.user_del()(u'auser1', preserve=True, > no_preserve=False, version=u'2.148'): OK > > Martin^2 From pviktori at redhat.com Fri Aug 14 17:44:52 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Aug 2015 19:44:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization Message-ID: <55CE2914.3000709@redhat.com> Hello, These patches bring IPA another step towards compatibility with Python 3. Most of these were made by fixers from the "python-modernize" tool, but I reviewed and edited the results. Meanwhile, I'll be going on vacation for the next couple of weeks, so if only some of these are ACKed, please push them individually. I'll address any issues on the rest when I get back (assuming no one jumps in in the mean time). In case someone wants to continue this effort while I'm away, the fixers I haven't yet run are: lib2to3.fixes.fix_long lib2to3.fixes.fix_standarderror libmodernize.fixes.fix_imports_six libmodernize.fixes.fix_metaclass libmodernize.fixes.fix_unicode_type -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0696-Remove-use-of-sys.exc_value.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0697-Don-t-use-a-tuple-in-function-arguments.patch Type: text/x-patch Size: 910 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0698-Add-python-six-to-dependencies.patch Type: text/x-patch Size: 984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0699-Remove-the-unused-pygettext-script.patch Type: text/x-patch Size: 30062 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0700-Use-six.string_types-instead-of-basestring.patch Type: text/x-patch Size: 31191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0701-Use-Python3-compatible-dict-method-names.patch Type: text/x-patch Size: 70897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0702-Replace-filter-calls-with-list-comprehensions.patch Type: text/x-patch Size: 6514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0703-Use-six.moves.input-instead-of-raw_input.patch Type: text/x-patch Size: 2232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0704-Use-six.integer_types-instead-of-long-int.patch Type: text/x-patch Size: 3499 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0705-Replace-uses-of-map.patch Type: text/x-patch Size: 15209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0706-Use-next-function-on-iterators.patch Type: text/x-patch Size: 3481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0707-Use-the-print-function.patch Type: text/x-patch Size: 228679 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0708-Use-new-style-raise-syntax.patch Type: text/x-patch Size: 6956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0709-Use-six.reraise.patch Type: text/x-patch Size: 867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0710-Modernize-use-of-range.patch Type: text/x-patch Size: 17768 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0711-Convert-zip-result-to-list.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: From edewata at redhat.com Sun Aug 16 15:29:24 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 16 Aug 2015 10:29:24 -0500 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. Message-ID: <55D0AC54.6040401@redhat.com> The vault-add and vault-archive commands have been modified to optionally retrieve a secret from a source vault, then re-archive the secret into the new/existing target vault. https://fedorahosted.org/freeipa/ticket/5223 -- Endi S. Dewata -------------- next part -------------- From 604c206e861b35fc1ae30c7cd68a03e52fd83845 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Sat, 15 Aug 2015 16:17:47 +0200 Subject: [PATCH] Added mechanism to copy vault secrets. The vault-add and vault-archive commands have been modified to optionally retrieve a secret from a source vault, then re-archive the secret into the new/existing target vault. https://fedorahosted.org/freeipa/ticket/5223 --- API.txt | 20 ++- ipalib/plugins/vault.py | 195 ++++++++++++++++++++---------- ipatests/test_xmlrpc/test_vault_plugin.py | 152 ++++++++++++++++++++++- 3 files changed, 297 insertions(+), 70 deletions(-) diff --git a/API.txt b/API.txt index 26f05cf9e1e27ec4f714bb34174e17972961bda2..d86a40742728ddb9cf8db9358166f49f70a8bc00 100644 --- a/API.txt +++ b/API.txt @@ -5397,7 +5397,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,14,3 +args: 1,22,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -5411,6 +5411,14 @@ option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui option: Str('service?') option: Str('setattr*', cli_name='setattr', exclude='webui') option: Flag('shared?', autofill=True, default=False) +option: Str('source_password?') +option: Str('source_password_file?') +option: Bytes('source_private_key?') +option: Str('source_private_key_file?') +option: Str('source_service?') +option: Flag('source_shared?', autofill=True, default=False) +option: Str('source_user?') +option: Str('source_vault?') option: Str('username?', cli_name='user') option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) @@ -5466,7 +5474,7 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,11,3 +args: 1,19,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?') @@ -5477,6 +5485,14 @@ option: Str('password_file?', cli_name='password_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') option: Flag('shared?', autofill=True, default=False) +option: Str('source_password?') +option: Str('source_password_file?') +option: Bytes('source_private_key?') +option: Str('source_private_key_file?') +option: Str('source_service?') +option: Flag('source_shared?', autofill=True, default=False) +option: Str('source_user?') +option: Str('source_vault?') option: Str('username?', cli_name='user') option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index c9eb4378b5c40d4182a70b72ae785740492ac9cb..278ca5e9113396f3de6217ef0e4eaa9da7ddce9a 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -252,6 +252,74 @@ vault_options = ( ), ) +source_vault_options = ( + Str( + 'source_vault?', + doc=_('Name of the source service vault'), + ), + Str( + 'source_service?', + doc=_('Service name of the source service vault'), + ), + Flag( + 'source_shared?', + doc=_('Source shared vault'), + ), + Str( + 'source_user?', + doc=_('Username of the source user vault'), + ), + Str( + 'source_password?', + doc=_('Source vault password'), + ), + Str( # TODO: use File parameter + 'source_password_file?', + doc=_('File containing the source vault password'), + ), + Bytes( + 'source_private_key?', + doc=_('Source vault private key'), + ), + Str( # TODO: use File parameter + 'source_private_key_file?', + doc=_('File containing the source vault private key'), + ), +) + +vault_add_options = ( + Str( + 'description?', + cli_name='desc', + doc=_('Vault description'), + ), + Str( + 'ipavaulttype?', + cli_name='type', + doc=_('Vault type'), + ), + Str( + 'password?', + cli_name='password', + doc=_('Vault password'), + ), + Str( # TODO: use File parameter + 'password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), + Bytes( + 'ipavaultpublickey?', + cli_name='public_key', + doc=_('Vault public key'), + ), + Str( # TODO: use File parameter + 'public_key_file?', + cli_name='public_key_file', + doc=_('File containing the vault public key'), + ), +) + @register() class vault(LDAPObject): @@ -546,56 +614,27 @@ class vault(LDAPObject): class vault_add(PKQuery, Local): __doc__ = _('Create a new vault.') - takes_options = LDAPCreate.takes_options + vault_options + ( - Str( - 'description?', - cli_name='desc', - doc=_('Vault description'), - ), - Str( - 'ipavaulttype?', - cli_name='type', - doc=_('Vault type'), - ), - Str( - 'password?', - cli_name='password', - doc=_('Vault password'), - ), - Str( # TODO: use File parameter - 'password_file?', - cli_name='password_file', - doc=_('File containing the vault password'), - ), - Bytes( - 'ipavaultpublickey?', - cli_name='public_key', - doc=_('Vault public key'), - ), - Str( # TODO: use File parameter - 'public_key_file?', - cli_name='public_key_file', - doc=_('File containing the vault public key'), - ), - ) + takes_options = LDAPCreate.takes_options + vault_options + \ + source_vault_options + vault_add_options has_output = output.standard_entry def forward(self, *args, **options): vault_type = options.get('ipavaulttype', u'standard') - password = options.get('password') - password_file = options.get('password_file') + password = options.pop('password', None) + password_file = options.pop('password_file', None) public_key = options.get('ipavaultpublickey') - public_key_file = options.get('public_key_file') + public_key_file = options.pop('public_key_file', None) - # don't send these parameters to server - if 'password' in options: - del options['password'] - if 'password_file' in options: - del options['password_file'] - if 'public_key_file' in options: - del options['public_key_file'] + source_vault = options.pop('source_vault', None) + source_service = options.pop('source_service', None) + source_shared = options.pop('source_shared', None) + source_user = options.pop('source_user', None) + source_password = options.pop('source_password', None) + source_password_file = options.pop('source_password_file', None) + source_private_key = options.pop('source_private_key', None) + source_private_key_file = options.pop('source_private_key_file', None) if vault_type != u'symmetric' and (password or password_file): raise errors.MutuallyExclusiveError( @@ -672,6 +711,7 @@ class vault_add(PKQuery, Local): opts = options.copy() if 'description' in opts: del opts['description'] + if 'ipavaulttype' in opts: del opts['ipavaulttype'] @@ -682,7 +722,17 @@ class vault_add(PKQuery, Local): elif vault_type == u'asymmetric': del opts['ipavaultpublickey'] - # archive blank data + opts['source_vault'] = source_vault + opts['source_service'] = source_service + opts['source_shared'] = source_shared + opts['source_user'] = source_user + + opts['source_password'] = source_password + opts['source_password_file'] = source_password_file + opts['source_private_key'] = source_private_key + opts['source_private_key_file'] = source_private_key_file + + # archive initial data self.api.Command.vault_archive(*args, **opts) return response @@ -918,7 +968,7 @@ class vault_mod(PKQuery, Local): pass elif change_password or \ - new_password or new_password_file or salt: + new_password or new_password_file or salt: vault_type = u'symmetric' elif new_public_key or new_public_key_file: @@ -1093,7 +1143,7 @@ class vaultconfig_show(Retrieve): class vault_archive(PKQuery, Local): __doc__ = _('Archive data into a vault.') - takes_options = vault_options + ( + takes_options = vault_options + source_vault_options + ( Bytes( 'data?', doc=_('Binary data to archive'), @@ -1124,23 +1174,29 @@ class vault_archive(PKQuery, Local): name = args[-1] - data = options.get('data') - input_file = options.get('in') + data = options.pop('data', None) + input_file = options.pop('in', None) - password = options.get('password') - password_file = options.get('password_file') + source_vault = options.pop('source_vault', None) + source_service = options.pop('source_service', None) + source_shared = options.pop('source_shared', None) + source_user = options.pop('source_user', None) + source_password = options.pop('source_password', None) + source_password_file = options.pop('source_password_file', None) + source_private_key = options.pop('source_private_key', None) + source_private_key_file = options.pop('source_private_key_file', None) + + password = options.pop('password', None) + password_file = options.pop('password_file', None) override_password = options.pop('override_password', False) - # don't send these parameters to server - if 'data' in options: - del options['data'] - if 'in' in options: - del options['in'] - if 'password' in options: - del options['password'] - if 'password_file' in options: - del options['password_file'] + if self.api.env.in_server: + backend = self.api.Backend.ldap2 + else: + backend = self.api.Backend.rpcclient + if not backend.isconnected(): + backend.connect(ccache=krbV.default_context().default_ccache()) # get data if data and input_file: @@ -1150,16 +1206,25 @@ class vault_archive(PKQuery, Local): elif input_file: data = validated_read('in', input_file, mode='rb') + elif source_vault: + opts = {} + + opts['service'] = source_service + opts['shared'] = source_shared + opts['username'] = source_user + + opts['password'] = source_password + opts['password_file'] = source_password_file + opts['private_key'] = source_private_key + opts['private_key_file'] = source_private_key_file + + # retrieve data from source vault + response = self.api.Command.vault_retrieve(source_vault, **opts) + data = response['result']['data'] + elif not data: data = '' - if self.api.env.in_server: - backend = self.api.Backend.ldap2 - else: - backend = self.api.Backend.rpcclient - if not backend.isconnected(): - backend.connect(ccache=krbV.default_context().default_ccache()) - # retrieve vault info vault = self.api.Command.vault_show(*args, **options)['result'] diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py index 077d9411b27a771e2c30c13215ffc08cfc6f7787..6d8a7241f6f073f713c2aeedf507be55a72de691 100644 --- a/ipatests/test_xmlrpc/test_vault_plugin.py +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -33,6 +33,10 @@ standard_vault_name = u'standard_test_vault' symmetric_vault_name = u'symmetric_test_vault' asymmetric_vault_name = u'asymmetric_test_vault' +standard_vault_copy_name = u'standard_test_vault_copy' +symmetric_vault_copy_name = u'symmetric_test_vault_copy' +asymmetric_vault_copy_name = u'asymmetric_test_vault_copy' + # binary data from \x00 to \xff secret = ''.join(map(chr, xrange(0, 256))) @@ -147,6 +151,9 @@ class test_vault_plugin(Declarative): ('vault_del', [standard_vault_name], {'continue': True}), ('vault_del', [symmetric_vault_name], {'continue': True}), ('vault_del', [asymmetric_vault_name], {'continue': True}), + ('vault_del', [standard_vault_copy_name], {'continue': True}), + ('vault_del', [symmetric_vault_copy_name], {'continue': True}), + ('vault_del', [asymmetric_vault_copy_name], {'continue': True}), ] tests = [ @@ -634,6 +641,52 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy standard vault to symmetric vault', + 'command': ( + 'vault_add', + [standard_vault_copy_name], + { + 'ipavaulttype': u'symmetric', + 'password': password, + 'source_vault': standard_vault_name, + }, + ), + 'expected': { + 'value': standard_vault_copy_name, + 'summary': u'Added vault "%s"' % standard_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (standard_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [standard_vault_copy_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from standard vault copied to ' + 'symmetric vault', + 'command': ( + 'vault_retrieve', + [standard_vault_copy_name], + { + 'password': password, + }, + ), + 'expected': { + 'value': standard_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % standard_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change standard vault to symmetric vault', 'command': ( 'vault_mod', @@ -656,7 +709,8 @@ class test_vault_plugin(Declarative): }, { - 'desc': 'Retrieve secret from standard vault converted to symmetric vault', + 'desc': 'Retrieve secret from standard vault converted to ' + 'symmetric vault', 'command': ( 'vault_retrieve', [standard_vault_name], @@ -737,6 +791,53 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy symmetric vault to asymmetric vault', + 'command': ( + 'vault_add', + [symmetric_vault_copy_name], + { + 'ipavaulttype': u'asymmetric', + 'ipavaultpublickey': public_key, + 'source_vault': symmetric_vault_name, + 'source_password': password, + }, + ), + 'expected': { + 'value': symmetric_vault_copy_name, + 'summary': u'Added vault "%s"' % symmetric_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (symmetric_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [symmetric_vault_copy_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault copied to ' + 'asymmetric vault', + 'command': ( + 'vault_retrieve', + [symmetric_vault_copy_name], + { + 'private_key': private_key, + }, + ), + 'expected': { + 'value': symmetric_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change symmetric vault password', 'command': ( 'vault_mod', @@ -801,7 +902,8 @@ class test_vault_plugin(Declarative): }, { - 'desc': 'Retrieve secret from symmetric vault converted to asymmetric vault', + 'desc': 'Retrieve secret from symmetric vault converted to ' + 'asymmetric vault', 'command': ( 'vault_retrieve', [symmetric_vault_name], @@ -881,6 +983,49 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy asymmetric vault to standard vault', + 'command': ( + 'vault_add', + [asymmetric_vault_copy_name], + { + 'ipavaulttype': u'standard', + 'source_vault': asymmetric_vault_name, + 'source_private_key': private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_copy_name, + 'summary': u'Added vault "%s"' % asymmetric_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (asymmetric_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [asymmetric_vault_copy_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault copied to ' + 'standard vault', + 'command': ( + 'vault_retrieve', + [asymmetric_vault_copy_name], + {}, + ), + 'expected': { + 'value': asymmetric_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change asymmetric vault keys', 'command': ( 'vault_mod', @@ -943,7 +1088,8 @@ class test_vault_plugin(Declarative): }, { - 'desc': 'Retrieve secret from asymmetric vault converted to standard vault', + 'desc': 'Retrieve secret from asymmetric vault converted to ' + 'standard vault', 'command': ( 'vault_retrieve', [asymmetric_vault_name], -- 2.4.3 From jcholast at redhat.com Mon Aug 17 05:59:59 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Aug 2015 07:59:59 +0200 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <20150813142943.GF22106@redhat.com> References: <20150813142943.GF22106@redhat.com> Message-ID: <55D1785F.8050109@redhat.com> On 13.8.2015 16:29, Alexander Bokovoy wrote: > Hi, > > see commit message for details. Please file a ticket for this, or reopen #5182. -- Jan Cholasta From abokovoy at redhat.com Mon Aug 17 06:07:23 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Aug 2015 09:07:23 +0300 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <55D1785F.8050109@redhat.com> References: <20150813142943.GF22106@redhat.com> <55D1785F.8050109@redhat.com> Message-ID: <20150817060723.GM22106@redhat.com> On Mon, 17 Aug 2015, Jan Cholasta wrote: >On 13.8.2015 16:29, Alexander Bokovoy wrote: >>Hi, >> >>see commit message for details. > >Please file a ticket for this, or reopen #5182. I reopened #5182. -- / Alexander Bokovoy From jcholast at redhat.com Mon Aug 17 06:12:18 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Aug 2015 08:12:18 +0200 Subject: [Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations. In-Reply-To: <55CCC49F.5000603@redhat.com> References: <55BB8F38.1010808@redhat.com> <55BF18C2.1010808@redhat.com> <55BF8A9A.30907@redhat.com> <55BFC534.6010605@redhat.com> <55BFD107.4060105@redhat.com> <55C05612.5060604@redhat.com> <1438690803.20262.25.camel@willson.usersys.redhat.com> <55C0C371.5060000@redhat.com> <55C0DB02.8080306@redhat.com> <55C8F79E.8070405@redhat.com> <55C9993E.9020604@redhat.com> <55CC78D9.8080709@redhat.com> <55CCC49F.5000603@redhat.com> Message-ID: <55D17B42.10206@redhat.com> On 13.8.2015 18:23, Endi Sukma Dewata wrote: > On 8/13/2015 6:00 AM, Petr Vobornik wrote: >> On 08/11/2015 08:42 AM, Jan Cholasta wrote: >>> On 10.8.2015 21:12, Endi Sukma Dewata wrote: >>>> On 8/4/2015 10:32 AM, Endi Sukma Dewata wrote: >>>>>>> Martin, I do not think going on with business as usual is the right >>>>>>> thing to do here. We know this is going to bite. >>>>>>> I suggest Endy adds a *new* API if making it backwards compatible is >>>>>>> not >>>>>>> possible. The era of bumping whole API version must stop, the sooner >>>>>>> the >>>>>>> better. >>>>>> >>>>>> My point is that we do not know yet how to do this kind of changes >>>>>> long term. >>>>>> So what I did not want to end up are 2 copy&pasted Vault plugins >>>>>> maintained >>>>>> forever, differing in just that. >>>>>> >>>>>> If you know how to do this without copypasting, I will be fine with >>>>>> that. >>>>> >>>>> We probably can do it like this: >>>>> * the old plugin continues to provide Vault 1.0 functionality >>>>> * the new plugin will be a proxy to the old plugin except for the >>>>> parts >>>>> that have changed in Vault 1.1. >>>>> >>>>> Or the other way around: >>>>> * the new plugin will provide Vault 1.1 functionality >>>>> * the old plugin will be a proxy to the new plugin except for the >>>>> parts >>>>> that needs to be maintained for Vault 1.0. >>>>> >>>>> The first option is probably safer. >>>>> >>>>> In any case, IPA 4.2.1 will only provide a single client for Vault >>>>> 1.1, >>>>> but two services for Vault 1.0 and 1.1. >>>> >>>> A new patch #369-1 is attached. It has been rebased on top of #372 and >>>> #373 that fix the conflicting parameter while maintaining backward >>>> compatibility. >>> >>> I have modified the first version of the patch to maintain backward >>> compatibility and not require your patches #372 and #373. Should be much >>> easier to review. See attachment. >> >> Jan approach seems better to me for 4.2.1. Endi, do you agree with the >> changes? Could we proceed with the review? > > Yes, please see the attached patch. I had to update it to remove buggy > code and revised the docs. I also had to rebase my other patches to make > sure they work with this patch. Thanks, ACK. Fixed commit message (removed the mention of servicename) and pushed to: master: 0dd95a19ee87a04836f12ad4c1194ad31ac22b93 ipa-4-2: f2117475b8a49b37845529089ea2d5b48f27bfda -- Jan Cholasta From tbabej at redhat.com Mon Aug 17 06:51:22 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 17 Aug 2015 08:51:22 +0200 Subject: [Freeipa-devel] [PATCHES 0360-0361] winsync-migrate: Add PassSync warnings Message-ID: <55D1846A.9000702@redhat.com> Hi, the following pair of patches fixes: https://fedorahosted.org/freeipa/ticket/5162 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0360-winsync-migrate-Add-warning-about-passsync.patch Type: text/x-patch Size: 1426 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0361-winsync-migrate-Expand-the-man-page.patch Type: text/x-patch Size: 2089 bytes Desc: not available URL: From tbabej at redhat.com Mon Aug 17 06:56:53 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 17 Aug 2015 08:56:53 +0200 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <20150813142943.GF22106@redhat.com> References: <20150813142943.GF22106@redhat.com> Message-ID: <55D185B5.1050704@redhat.com> On 08/13/2015 04:29 PM, Alexander Bokovoy wrote: > Hi, > > see commit message for details. > > > Hi, code-wise this looks good to me. Unfortunately, I have not been able to verify in my setup that it fixes the issue in the linked BZ: $ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type ipa-ad-trust --admin Administrator --password ------------------------------------------------ Added Active Directory trust for realm "ad.test" ------------------------------------------------ Realm name: ad.test Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust direction: Trusting forest Trust type: Active Directory domain Trust status: Established and verified $ idrange-find ---------------- 2 ranges matched ---------------- Range name: AD.TEST_id_range First Posix ID of the range: 191200000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-1469936554-2294197481-461507924 Range type: Active Directory domain range Range name: IPA.TEST_id_range First Posix ID of the range: 695200000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range ---------------------------- Number of entries returned 2 ---------------------------- However, I have one child subdomain in the setup: $ ipa trustdomain-find Realm name: ad.test Domain name: ad.test Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 Domain enabled: True Domain name: sub.ad.test Domain NetBIOS name: SUB Domain Security Identifier: S-1-5-21-10134726-2575992721-4229914074 Domain enabled: True ---------------------------- Number of entries returned 2 ---------------------------- Tomas From abokovoy at redhat.com Mon Aug 17 07:03:40 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 17 Aug 2015 10:03:40 +0300 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <55D185B5.1050704@redhat.com> References: <20150813142943.GF22106@redhat.com> <55D185B5.1050704@redhat.com> Message-ID: <20150817070340.GN22106@redhat.com> On Mon, 17 Aug 2015, Tomas Babej wrote: > > >On 08/13/2015 04:29 PM, Alexander Bokovoy wrote: >> Hi, >> >> see commit message for details. >> >> >> > >Hi, > >code-wise this looks good to me. Unfortunately, I have not been able to >verify in my setup that it fixes the issue in the linked BZ: > >$ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type >ipa-ad-trust --admin Administrator --password >------------------------------------------------ >Added Active Directory trust for realm "ad.test" >------------------------------------------------ > Realm name: ad.test > Domain NetBIOS name: AD > Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 > SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, > S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, > S-1-1, S-1-0, S-1-5-19, S-1-5-18 > SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, > S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, > S-1-1, S-1-0, S-1-5-19, S-1-5-18 > Trust direction: Trusting forest > Trust type: Active Directory domain > Trust status: Established and verified > >$ idrange-find > >---------------- >2 ranges matched >---------------- > Range name: AD.TEST_id_range > First Posix ID of the range: 191200000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 0 > Domain SID of the trusted domain: S-1-5-21-1469936554-2294197481-461507924 > Range type: Active Directory domain range > > Range name: IPA.TEST_id_range > First Posix ID of the range: 695200000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 1000 > First RID of the secondary RID range: 100000000 > Range type: local domain range >---------------------------- >Number of entries returned 2 >---------------------------- > >However, I have one child subdomain in the setup: > >$ ipa trustdomain-find >Realm name: ad.test > Domain name: ad.test > Domain NetBIOS name: AD > Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 > Domain enabled: True > > Domain name: sub.ad.test > Domain NetBIOS name: SUB > Domain Security Identifier: S-1-5-21-10134726-2575992721-4229914074 > Domain enabled: True >---------------------------- >Number of entries returned 2 >---------------------------- Look for AVCs, if there are any. Also start abrtd and it should pick up any python exceptions in the helper as 'crashes'. -- / Alexander Bokovoy From jcholast at redhat.com Mon Aug 17 07:43:27 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Aug 2015 09:43:27 +0200 Subject: [Freeipa-devel] [PATCHES 472-473] vault: Fix param labels in output of vault owner commands Message-ID: <55D1909F.7090302@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-472-baseldap-Allow-overriding-member-param-label-in-LDAP.patch Type: text/x-patch Size: 1457 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-473-vault-Fix-param-labels-in-output-of-vault-owner-comm.patch Type: text/x-patch Size: 1962 bytes Desc: not available URL: From mkubik at redhat.com Mon Aug 17 07:53:18 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 17 Aug 2015 09:53:18 +0200 Subject: [Freeipa-devel] [patch 0011] Temporary workaround for [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C9F740.7060008@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> <55C99F7F.9060001@redhat.com> <55C9A83A.9070901@redhat.com> <55C9A9EA.8010907@redhat.com> <55C9F740.7060008@redhat.com> Message-ID: <55D192EE.8060409@redhat.com> On 08/11/2015 03:23 PM, Milan Kub?k wrote: > On 08/11/2015 09:53 AM, Jan Cholasta wrote: >> On 11.8.2015 09:46, Milan Kub?k wrote: >>> On 08/11/2015 09:08 AM, Jan Cholasta wrote: >>>> On 11.8.2015 09:00, Milan Kub?k wrote: >>>> >>>>> On 08/10/2015 06:22 PM, Milan Kub?k wrote: >>>>> >>>>>> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>>>>> >>>>>>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>>>>> >>>>>>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> this patch fixes problem described in the ticket [1] >>>>>>>>> >>>>>>>>> that caused the test run to fail completely at every other or so >>>>>>>>> run. >>>>>>>>> >>>>>>>>> I took the liberty to fix most of the pep8 issues while I was >>>>>>>>> at it. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> IMO this would be more robust: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> t = None >>>>>>>> >>>>>>>> try: >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> finally: >>>>>>>> >>>>>>>> del t >>>>>>>> >>>>>>>> nss.nss_shutdown() >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> By assigning a value to the variable at the beginning you make >>>>>>>> sure >>>>>>>> >>>>>>>> that the del statement will not fail. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thanks for the idea. It also removed the version check. >>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Milan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Self NACK. >>>>>> >>>>>> >>>>>> >>>>>> I have updated the fix for all of the leaks in that class. It >>>>>> seems to >>>>>> >>>>>> corrupt the database even when no init/shutdown was called. Just not >>>>>> >>>>>> so often. >>>>>> >>>>>> >>>>>> >>>>>> Milan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> NACK again. The problem is the reference counting. Even with this >>>>> patch, >>>>> >>>>> there seems to be at least one reference left after 't' is deleted >>>>> and >>>>> >>>>> nss.nss_shutdown races with the garbage collector. >>>>> >>>> >>>> >>>> Doesn't the PKCDDocument object also reference some NSS objects? It >>>> might be worth trying to delete it manually before nss_shutdown as >>>> well. >>>> >>>> >>>> >>>> >>>> >>> Yes, this patch doesn't work. There are still some references left. >>> >>> The problem may be on multiple places in here [1]. >>> >>> There may be a reference still bound to the doc label. >>> Another problem is that python 2 code: >>> >>> [x for x in [123, 456]] >>> >>> creates 2 references to 456 as the list used in the assert lives for >>> some time >>> before it is garbage collected even though it is not reachable, >>> holding a reference to the object labeled as t. >>> >>> I don't know how nss counts the references to its objects but I >>> think we >>> should ow I think >>> delete all the objects that use/are used by nss explicitly. This means >>> assigning the list >>> produced by the list comprehension a name as well and the delete it >>> when >>> it is not needed. >>> >>> I'll send the patch shortly. >>> >>> [1]: https://paste.fedoraproject.org/253748/92783071/ >> >> Given an assumption that all objects referenced only by local >> variables are deleted when a function returns, maybe this can be >> solved with: >> >> def nss_initialized(func): >> def decorated(*args, **kwargs): >> nss.nss_init_nodb() >> try: >> func(*args, **kwargs) >> finally: >> nss.nss_shutdown() >> return decorated >> >> ... >> >> class test_class(...): >> @nss_initialized >> def test_method(self): >> ... >> >> (OTOH and untested) >> > It seems that NSS decided the assumption doesn't hold. [1] > Plus, the decorator seems to change the execution order of the test > cases. > > [1]: https://paste.fedoraproject.org/253846/39299083/ > > Milan > Hi list, since I wasn't successful at solving this problem, I revert to the original plan and propose to take the otp import test out of the execution. The attached patch does this. By no means is this a solution to the problem. Therefore, I think the ticket should remain open. The priority of blocker can be dropped, though. I think 'critical' should be used. Cheers, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0011-ipatests-Take-otptoken-import-test-out-of-execution.patch Type: text/x-patch Size: 1358 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 17 08:23:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 17 Aug 2015 10:23:40 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55CB29BA.7050200@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> <55CB29BA.7050200@redhat.com> Message-ID: <55D19A0C.7040607@redhat.com> On 08/12/2015 01:10 PM, Milan Kub?k wrote: > On 08/10/2015 04:41 PM, Jan Cholasta wrote: >> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: Re: [Freeipa-devel] Unable to install bits from ipa-4-2 >>> branch >>> Date: Mon, 10 Aug 2015 15:55:35 +0200 >>> From: Jan Cholasta >>> To: Milan Kub?k >>> CC: Martin Kosek >>> >>> >>> >>> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>>> Hi list, >>>>>>>>> >>>>>>>>> I just noticed that the bits built from ipa-4-2 branch cannot be >>>>>>>>> installed. >>>>>>>>> The freeipa packages built have version such as >>>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The version check in the spec file makes the server-dns package >>>>>>>>> obsolete the >>>>>>>>> server package from tha same build. >>>>>>>>> The cause is the commit [1]. This issue blocks us from running >>>>>>>>> tests >>>>>>>>> on ipa-4-2 >>>>>>>>> branch. >>>>>>>>> >>>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>>> >>>>>>>>> [1]: >>>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Milan >>>>>>>>> >>>>>>>> Why does the spec calls for >>>>>>>> >>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>>> >>>>>>>> and not for >>>>>>>> >>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>>> >>>>>>>> ? Is that the root cause of these issues? >>>>>>> >>>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>>> >>>>>> I wonder how it could break the upgrade... >>>>>> >>>>> >>>>> Patch attached. >>>>> >>>> This won't help as long as we build something like >>>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >>> >>> Right. Updated patch attached. It will break updates from >>> pre-server-dns >>> git builds, but install should be fine. >>> >>> -- >>> Jan Cholasta >>> >>> >>> ACK, thanks. >> >> Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from the >> freeipa-4.2 COPR. >> >> Updated patch attached. >> > Hi, > > thanks for the patch. It works as far as updating from 4.1, the copr > build > (correctly replaces freeipa-server package) as well as upgrade from > earlier build from repository. > > If there are no objections, ACK from me. > > Milan > Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3 From tbabej at redhat.com Mon Aug 17 08:29:23 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 17 Aug 2015 10:29:23 +0200 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <20150817070340.GN22106@redhat.com> References: <20150813142943.GF22106@redhat.com> <55D185B5.1050704@redhat.com> <20150817070340.GN22106@redhat.com> Message-ID: <55D19B63.8020600@redhat.com> On 08/17/2015 09:03 AM, Alexander Bokovoy wrote: > On Mon, 17 Aug 2015, Tomas Babej wrote: >> >> >> On 08/13/2015 04:29 PM, Alexander Bokovoy wrote: >>> Hi, >>> >>> see commit message for details. >>> >>> >>> >> >> Hi, >> >> code-wise this looks good to me. Unfortunately, I have not been able to >> verify in my setup that it fixes the issue in the linked BZ: >> >> $ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type >> ipa-ad-trust --admin Administrator --password >> ------------------------------------------------ >> Added Active Directory trust for realm "ad.test" >> ------------------------------------------------ >> Realm name: ad.test >> Domain NetBIOS name: AD >> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >> SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >> SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >> Trust direction: Trusting forest >> Trust type: Active Directory domain >> Trust status: Established and verified >> >> $ idrange-find >> >> ---------------- >> 2 ranges matched >> ---------------- >> Range name: AD.TEST_id_range >> First Posix ID of the range: 191200000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 0 >> Domain SID of the trusted domain: >> S-1-5-21-1469936554-2294197481-461507924 >> Range type: Active Directory domain range >> >> Range name: IPA.TEST_id_range >> First Posix ID of the range: 695200000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 1000 >> First RID of the secondary RID range: 100000000 >> Range type: local domain range >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> However, I have one child subdomain in the setup: >> >> $ ipa trustdomain-find >> Realm name: ad.test >> Domain name: ad.test >> Domain NetBIOS name: AD >> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >> Domain enabled: True >> >> Domain name: sub.ad.test >> Domain NetBIOS name: SUB >> Domain Security Identifier: S-1-5-21-10134726-2575992721-4229914074 >> Domain enabled: True >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- > Look for AVCs, if there are any. > > Also start abrtd and it should pick up any python exceptions in the > helper as 'crashes'. > Right. Insufficient LDAP permissions caused the following backtrace in the oddjob helper: ipaldap.py:948:error_handler:ACIError: Insufficient access: Insufficient 'add' privilege to add the entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. Traceback (most recent call last): File "/usr/libexec/ipa/com.redhat.idm.trust-fetch-domains", line 216, in trusted_domain, name, **dom) File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line 347, in add_range ipanttrusteddomainsid=dom_sid) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, in run return self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1234, in execute self._exc_wrapper(keys, options, ldap.add_entry)(entry_attrs) File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1145, in wrapped return func(*call_args, **call_kwargs) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1442, in add_entry self.conn.add_s(str(entry.dn), attrs.items()) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 948, in error_handler raise errors.ACIError(info=info) ACIError: Insufficient access: Insufficient 'add' privilege to add the entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. Local variables in innermost frame: info: "Insufficient 'add' privilege to add the entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'." arg_desc: None self: ipaserver.plugins.ldap2.ldap2() e: INSUFFICIENT_ACCESS({'info': "Insufficient 'add' privilege to add the entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'.\n", 'desc': 'Insufficient access'},) desc: 'Insufficient access' From akasurde at redhat.com Mon Aug 17 09:11:13 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 17 Aug 2015 14:41:13 +0530 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55CDD5B9.1050105@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> <55CD7524.9080307@redhat.com> <55CDD5B9.1050105@redhat.com> Message-ID: <55D1A531.4020309@redhat.com> Hi All, Please find the update patch with review comments, On 08/14/2015 05:19 PM, Martin Basti wrote: > > > On 08/14/2015 06:57 AM, Abhijeet Kasurde wrote: >> >> On 08/13/2015 07:08 PM, Martin Basti wrote: >>> >>> >>> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >>>> Hi All, >>>> >>>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 >>>> >>>> Thanks, >>>> Abhijeet Kasurde >>>> >>>> >>> >>> Hello, >>> >>> thank you for the patch >>> >>> 1) >>> - except ValueError: >>> + except EOFError, ValueError: >>> >>> Please use >>> except (EOFError, ValueError): >>> https://docs.python.org/2/tutorial/errors.html#handling-exceptions >> OK, I will include this. >>> 2) >>> I'm not sure if this code will work (I did not test it) >>> >>> I expect when stdin is closed, this will result into infinite loop, >>> because raw_input will always return EOFError. >>> >>> while True: >>> try: >>> ret = raw_input("%s: " % prompt) >>> if allow_empty or ret.strip(): >>> return ret >>> except EOFError: >>> pass >>> >> Could you please elaborate more on, so that I can include fix in this >> section of code? > If you receive EOF you cannot continue in while cycle because, it will > return EOF every iteration forever. > > If EOF is received the while cycle must end, and appropriate action > must be take. > It depends on situation, if default value is present then default > value should be used, or in case if empty value is allowed, empty > string should be returned. > > In case there is no default value and empty value is not allowed, then > an exception should be raised. > > Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-2-try-except-block-in-ipautil.patch Type: text/x-patch Size: 3271 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Aug 17 10:25:25 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 17 Aug 2015 12:25:25 +0200 Subject: [Freeipa-devel] [PATCHES 0360-0361] winsync-migrate: Add PassSync warnings In-Reply-To: <55D1846A.9000702@redhat.com> References: <55D1846A.9000702@redhat.com> Message-ID: <55D1B695.9070103@redhat.com> On 08/17/2015 08:51 AM, Tomas Babej wrote: > Hi, > > the following pair of patches fixes: > > https://fedorahosted.org/freeipa/ticket/5162 > > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Mon Aug 17 10:39:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 17 Aug 2015 12:39:27 +0200 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55D1A531.4020309@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> <55CD7524.9080307@redhat.com> <55CDD5B9.1050105@redhat.com> <55D1A531.4020309@redhat.com> Message-ID: <55D1B9DF.4060109@redhat.com> On 08/17/2015 11:11 AM, Abhijeet Kasurde wrote: > Hi All, > > Please find the update patch with review comments, > > > On 08/14/2015 05:19 PM, Martin Basti wrote: >> >> >> On 08/14/2015 06:57 AM, Abhijeet Kasurde wrote: >>> >>> On 08/13/2015 07:08 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >>>>> Hi All, >>>>> >>>>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 >>>>> >>>>> Thanks, >>>>> Abhijeet Kasurde >>>>> >>>>> >>>> >>>> Hello, >>>> >>>> thank you for the patch >>>> >>>> 1) >>>> - except ValueError: >>>> + except EOFError, ValueError: >>>> >>>> Please use >>>> except (EOFError, ValueError): >>>> https://docs.python.org/2/tutorial/errors.html#handling-exceptions >>> OK, I will include this. >>>> 2) >>>> I'm not sure if this code will work (I did not test it) >>>> >>>> I expect when stdin is closed, this will result into infinite loop, >>>> because raw_input will always return EOFError. >>>> >>>> while True: >>>> try: >>>> ret = raw_input("%s: " % prompt) >>>> if allow_empty or ret.strip(): >>>> return ret >>>> except EOFError: >>>> pass >>>> >>> Could you please elaborate more on, so that I can include fix in >>> this section of code? >> If you receive EOF you cannot continue in while cycle because, it >> will return EOF every iteration forever. >> >> If EOF is received the while cycle must end, and appropriate action >> must be take. >> It depends on situation, if default value is present then default >> value should be used, or in case if empty value is allowed, empty >> string should be returned. >> >> In case there is no default value and empty value is not allowed, >> then an exception should be raised. >> >> Martin^2 > NACK There is still infinity loop. 1) + except EOFError: + if allow_empty: + return '' This will continue in while cycle if allow_empty=False, you need to raise exception there. 2) Why so complicated? just return default looks enough to me. + except EOFError: + if choice.lower()[0] == "y": + return True + elif choice.lower()[0] == "n": + return False 3) Remove this change please - def get_gsserror(e): -------------- next part -------------- An HTML attachment was scrubbed... URL: From akasurde at redhat.com Mon Aug 17 12:08:31 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Mon, 17 Aug 2015 17:38:31 +0530 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55D1B9DF.4060109@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> <55CD7524.9080307@redhat.com> <55CDD5B9.1050105@redhat.com> <55D1A531.4020309@redhat.com> <55D1B9DF.4060109@redhat.com> Message-ID: <55D1CEBF.3010405@redhat.com> Hi All, I have included all review comments. Please let me know your views. On 08/17/2015 04:09 PM, Martin Basti wrote: > > > On 08/17/2015 11:11 AM, Abhijeet Kasurde wrote: >> Hi All, >> >> Please find the update patch with review comments, >> >> >> On 08/14/2015 05:19 PM, Martin Basti wrote: >>> >>> >>> On 08/14/2015 06:57 AM, Abhijeet Kasurde wrote: >>>> >>>> On 08/13/2015 07:08 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >>>>>> Hi All, >>>>>> >>>>>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 >>>>>> >>>>>> Thanks, >>>>>> Abhijeet Kasurde >>>>>> >>>>>> >>>>> >>>>> Hello, >>>>> >>>>> thank you for the patch >>>>> >>>>> 1) >>>>> - except ValueError: >>>>> + except EOFError, ValueError: >>>>> >>>>> Please use >>>>> except (EOFError, ValueError): >>>>> https://docs.python.org/2/tutorial/errors.html#handling-exceptions >>>> OK, I will include this. >>>>> 2) >>>>> I'm not sure if this code will work (I did not test it) >>>>> >>>>> I expect when stdin is closed, this will result into infinite >>>>> loop, because raw_input will always return EOFError. >>>>> >>>>> while True: >>>>> try: >>>>> ret = raw_input("%s: " % prompt) >>>>> if allow_empty or ret.strip(): >>>>> return ret >>>>> except EOFError: >>>>> pass >>>>> >>>> Could you please elaborate more on, so that I can include fix in >>>> this section of code? >>> If you receive EOF you cannot continue in while cycle because, it >>> will return EOF every iteration forever. >>> >>> If EOF is received the while cycle must end, and appropriate action >>> must be take. >>> It depends on situation, if default value is present then default >>> value should be used, or in case if empty value is allowed, empty >>> string should be returned. >>> >>> In case there is no default value and empty value is not allowed, >>> then an exception should be raised. >>> >>> Martin^2 >> > NACK > > There is still infinity loop. > 1) > + except EOFError: > + if allow_empty: > + return '' > > This will continue in while cycle if allow_empty=False, you need to raise exception there. > > 2) > Why so complicated? just return default looks enough to me. > + except EOFError: > + if choice.lower()[0] == "y": > + return True > + elif choice.lower()[0] == "n": > + return False > 3) > Remove this change please > - > def get_gsserror(e): > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-3-try-except-block-in-ipautil.patch Type: text/x-patch Size: 2997 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Aug 17 12:41:13 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 17 Aug 2015 14:41:13 +0200 Subject: [Freeipa-devel] [PATCH 0356] trusts: Detect missing Samba instance In-Reply-To: <55C316C7.8060806@redhat.com> References: <55C316C7.8060806@redhat.com> Message-ID: <55D1D669.6000307@redhat.com> On 08/06/2015 10:11 AM, Tomas Babej wrote: > Hi, > > In the event of invocation of trust related commands, IPA server needs > to contact local Samba instance. This is not possible on servers that > merely act as AD trust agents, since they do not have Samba instance > running. > > Properly detect the absence of the Samba instance and output > user-friendly > message which includes list of servers that are capable of running > the command, if such exist. > > List of commands affected: > * ipa trust-add > * ipa trust-fetch-domains > * all of the trustdomain commands available via CLI > > https://fedorahosted.org/freeipa/ticket/5165 > > > ACK -- Martin^3 Babinsky From mbabinsk at redhat.com Mon Aug 17 12:58:36 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 17 Aug 2015 14:58:36 +0200 Subject: [Freeipa-devel] [PATCH 0357] trusts: Detect domain clash with IPA domain when adding a AD In-Reply-To: <55C320F6.4010009@redhat.com> References: <55C320F6.4010009@redhat.com> Message-ID: <55D1DA7C.5020708@redhat.com> On 08/06/2015 10:55 AM, Tomas Babej wrote: > Hi, > > When IPA is deployed in the same domain as AD, trust-add fails since > the names of the local domain and trusted domain ranges is the same > - it's always DOMAIN.NAME_id_range. > > When adding a trusted domain, we look for previous ranges for > this domain (which may have been left behind by previous trust > attempts). Since AD and IPA are in the same domain, we find > a local domain range, which does not have a SID. > > Detect such domain collisions early and bail out with an appropriate > error message. > > https://fedorahosted.org/freeipa/ticket/4549 > > > ACK -- Martin^3 Babinsky From dkupka at redhat.com Mon Aug 17 13:39:40 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 17 Aug 2015 15:39:40 +0200 Subject: [Freeipa-devel] [PATCH 0060] user-undel: Fix error messages. In-Reply-To: <55CE06AF.6060607@redhat.com> References: <55CC3660.70205@redhat.com> <55CE06AF.6060607@redhat.com> Message-ID: <55D1E41C.9020304@redhat.com> On 14/08/15 17:18, Martin Basti wrote: > > > On 08/13/2015 08:17 AM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/5207 >> >> Requires patch freeipa-jcholast-471.1. >> >> > > NACK > > This patch causes internal server error > > ipa user-del user --preserve > > [Fri Aug 14 17:16:13.691565 2015] [wsgi:error] [pid 3210] ipa: ERROR: > non-public: TypeError: %d format: a number is required, not str > [Fri Aug 14 17:16:13.691605 2015] [wsgi:error] [pid 3210] Traceback > (most recent call last): > [Fri Aug 14 17:16:13.691610 2015] [wsgi:error] [pid 3210] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 347, in > wsgi_execute > [Fri Aug 14 17:16:13.691614 2015] [wsgi:error] [pid 3210] result = > self.Command[name](*args, **options) > [Fri Aug 14 17:16:13.691618 2015] [wsgi:error] [pid 3210] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 457, in > __call__ > [Fri Aug 14 17:16:13.691622 2015] [wsgi:error] [pid 3210] > self.validate_output(ret, options['version']) > [Fri Aug 14 17:16:13.691626 2015] [wsgi:error] [pid 3210] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 950, in > validate_output > [Fri Aug 14 17:16:13.691630 2015] [wsgi:error] [pid 3210] > o.validate(self, value, version) > [Fri Aug 14 17:16:13.691634 2015] [wsgi:error] [pid 3210] File > "/usr/lib/python2.7/site-packages/ipalib/output.py", line 151, in validate > [Fri Aug 14 17:16:13.691638 2015] [wsgi:error] [pid 3210] types[0], > type(value), value)) > [Fri Aug 14 17:16:13.691642 2015] [wsgi:error] [pid 3210] TypeError: %d > format: a number is required, not str > [Fri Aug 14 17:16:13.692063 2015] [wsgi:error] [pid 3210] ipa: INFO: > [jsonserver_session] admin at EXAMPLE.COM: user_del((u'user',), > continue=False, preserve=True, version=u'2.148'): TypeError > (END) > > Thanks for catching this. Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0060.1-user-undel-Fix-error-messages.patch Type: text/x-patch Size: 1676 bytes Desc: not available URL: From npmccallum at redhat.com Mon Aug 17 14:06:17 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 17 Aug 2015 10:06:17 -0400 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55C8C68A.1010606@redhat.com> References: <55C8C68A.1010606@redhat.com> Message-ID: <1439820377.4823.12.camel@redhat.com> On Mon, 2015-08-10 at 17:43 +0200, Milan Kub?k wrote: > Hi all, > > this patch fixes problem described in the ticket [1] > that caused the test run to fail completely at every other or so run. > I took the liberty to fix most of the pep8 issues while I was at it. > > Thanks to Jan Cholasta for help with identifying this one. > > [1]: https://fedorahosted.org/freeipa/ticket/5192 I think the right answer is to move this to python-cryptography. We already have python-cryptography as a dependency. And in this case the crypto code is pretty well self-contained. Aside from nss database initialization, nss is only used in: * convertAlgorithm() (constants only) * XMLDecryptor (actual decryption code) The migration should be straightforward. It is probably a 1 day task. I could probably tackle it later this week. Should we do this? Nathaniel From rcritten at redhat.com Mon Aug 17 14:20:28 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Aug 2015 10:20:28 -0400 Subject: [Freeipa-devel] [PATCH] 1115 Use %license tag in spec file Message-ID: <55D1EDAC.2090609@redhat.com> Use %license instead of %doc in spec file to ship the license. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1115-license.patch Type: text/x-diff Size: 1898 bytes Desc: not available URL: From mkubik at redhat.com Mon Aug 17 14:44:24 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 17 Aug 2015 16:44:24 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55D19A0C.7040607@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> <55CB29BA.7050200@redhat.com> <55D19A0C.7040607@redhat.com> Message-ID: <55D1F348.5080205@redhat.com> On 08/17/2015 10:23 AM, Martin Basti wrote: > > > On 08/12/2015 01:10 PM, Milan Kub?k wrote: >> On 08/10/2015 04:41 PM, Jan Cholasta wrote: >>> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >>>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: Re: [Freeipa-devel] Unable to install bits from >>>> ipa-4-2 branch >>>> Date: Mon, 10 Aug 2015 15:55:35 +0200 >>>> From: Jan Cholasta >>>> To: Milan Kub?k >>>> CC: Martin Kosek >>>> >>>> >>>> >>>> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>>>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>>>> Hi list, >>>>>>>>>> >>>>>>>>>> I just noticed that the bits built from ipa-4-2 branch cannot be >>>>>>>>>> installed. >>>>>>>>>> The freeipa packages built have version such as >>>>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The version check in the spec file makes the server-dns package >>>>>>>>>> obsolete the >>>>>>>>>> server package from tha same build. >>>>>>>>>> The cause is the commit [1]. This issue blocks us from >>>>>>>>>> running tests >>>>>>>>>> on ipa-4-2 >>>>>>>>>> branch. >>>>>>>>>> >>>>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>>>> >>>>>>>>>> [1]: >>>>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Milan >>>>>>>>>> >>>>>>>>> Why does the spec calls for >>>>>>>>> >>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>>>> >>>>>>>>> and not for >>>>>>>>> >>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>>>> >>>>>>>>> ? Is that the root cause of these issues? >>>>>>>> >>>>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>>>> >>>>>>> I wonder how it could break the upgrade... >>>>>>> >>>>>> >>>>>> Patch attached. >>>>>> >>>>> This won't help as long as we build something like >>>>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >>>> >>>> Right. Updated patch attached. It will break updates from >>>> pre-server-dns >>>> git builds, but install should be fine. >>>> >>>> -- >>>> Jan Cholasta >>>> >>>> >>>> ACK, thanks. >>> >>> Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from the >>> freeipa-4.2 COPR. >>> >>> Updated patch attached. >>> >> Hi, >> >> thanks for the patch. It works as far as updating from 4.1, the copr >> build >> (correctly replaces freeipa-server package) as well as upgrade from >> earlier build from repository. >> >> If there are no objections, ACK from me. >> >> Milan >> > Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3 Ok, while checking this manually it seemed to work, the jenkins build names the package in a way that produces this error. The patch has no effect in automation, unfortunatelly. The build on jenkins adds the release version, when built manually, the name is xyz.4.2.0.DATE+hash-string. Error: package freeipa-server-dns-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 obsoletes freeipa-server <= 4.2.0.0 provided by freeipa-server-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 Late answer to Lukas, this is n:m scenario. I'm not sure what to do if one subpackage retains the original name, though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Mon Aug 17 14:47:45 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 17 Aug 2015 16:47:45 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55D1F348.5080205@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> <55CB29BA.7050200@redhat.com> <55D19A0C.7040607@redhat.com> <55D1F348.5080205@redhat.com> Message-ID: <55D1F411.3090107@redhat.com> On 08/17/2015 04:44 PM, Milan Kub?k wrote: > On 08/17/2015 10:23 AM, Martin Basti wrote: >> >> >> On 08/12/2015 01:10 PM, Milan Kub?k wrote: >>> On 08/10/2015 04:41 PM, Jan Cholasta wrote: >>>> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >>>>> >>>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: Re: [Freeipa-devel] Unable to install bits from >>>>> ipa-4-2 branch >>>>> Date: Mon, 10 Aug 2015 15:55:35 +0200 >>>>> From: Jan Cholasta >>>>> To: Milan Kub?k >>>>> CC: Martin Kosek >>>>> >>>>> >>>>> >>>>> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>>>>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>>>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>>>>> Hi list, >>>>>>>>>>> >>>>>>>>>>> I just noticed that the bits built from ipa-4-2 branch >>>>>>>>>>> cannot be >>>>>>>>>>> installed. >>>>>>>>>>> The freeipa packages built have version such as >>>>>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The version check in the spec file makes the server-dns package >>>>>>>>>>> obsolete the >>>>>>>>>>> server package from tha same build. >>>>>>>>>>> The cause is the commit [1]. This issue blocks us from >>>>>>>>>>> running tests >>>>>>>>>>> on ipa-4-2 >>>>>>>>>>> branch. >>>>>>>>>>> >>>>>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>>>>> >>>>>>>>>>> [1]: >>>>>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Milan >>>>>>>>>>> >>>>>>>>>> Why does the spec calls for >>>>>>>>>> >>>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>>>>> >>>>>>>>>> and not for >>>>>>>>>> >>>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>>>>> >>>>>>>>>> ? Is that the root cause of these issues? >>>>>>>>> >>>>>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>>>>> >>>>>>>> I wonder how it could break the upgrade... >>>>>>>> >>>>>>> >>>>>>> Patch attached. >>>>>>> >>>>>> This won't help as long as we build something like >>>>>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >>>>> >>>>> Right. Updated patch attached. It will break updates from >>>>> pre-server-dns >>>>> git builds, but install should be fine. >>>>> >>>>> -- >>>>> Jan Cholasta >>>>> >>>>> >>>>> ACK, thanks. >>>> >>>> Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from >>>> the freeipa-4.2 COPR. >>>> >>>> Updated patch attached. >>>> >>> Hi, >>> >>> thanks for the patch. It works as far as updating from 4.1, the copr >>> build >>> (correctly replaces freeipa-server package) as well as upgrade from >>> earlier build from repository. >>> >>> If there are no objections, ACK from me. >>> >>> Milan >>> >> Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3 > Ok, while checking this manually it seemed to work, the jenkins build > names the package in a way that produces this error. The patch has no > effect in automation, unfortunatelly. The build on jenkins adds the > release version, when built manually, the name is > xyz.4.2.0.DATE+hash-string. > > Error: package freeipa-server-dns-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 obsoletes freeipa-server <= 4.2.0.0 provided by freeipa-server-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 > > Late answer to Lukas, this is n:m scenario. I'm not sure what to do if one subpackage retains the original name, though. > > > That being said, I can change the schema by which jenkins marks release version on the rpms it builds. This will provide a hacky way around this issue by creating 4.2.0.2015... provided by the timestamp. Milan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Aug 17 15:09:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 17 Aug 2015 17:09:40 +0200 Subject: [Freeipa-devel] [PATCH 0357] trusts: Detect domain clash with IPA domain when adding a AD In-Reply-To: <55D1DA7C.5020708@redhat.com> References: <55C320F6.4010009@redhat.com> <55D1DA7C.5020708@redhat.com> Message-ID: <55D1F934.3000904@redhat.com> On 08/17/2015 02:58 PM, Martin Babinsky wrote: > On 08/06/2015 10:55 AM, Tomas Babej wrote: >> Hi, >> >> When IPA is deployed in the same domain as AD, trust-add fails since >> the names of the local domain and trusted domain ranges is the same >> - it's always DOMAIN.NAME_id_range. >> >> When adding a trusted domain, we look for previous ranges for >> this domain (which may have been left behind by previous trust >> attempts). Since AD and IPA are in the same domain, we find >> a local domain range, which does not have a SID. >> >> Detect such domain collisions early and bail out with an appropriate >> error message. >> >> https://fedorahosted.org/freeipa/ticket/4549 >> >> >> > ACK > Pushed to: master: 9ce074b36a54a450c91ac0151c345481da120290 ipa-4-2: 5fd2a893e65ba6cc888de930f76b2e48ba460b8d From mbasti at redhat.com Mon Aug 17 15:14:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 17 Aug 2015 17:14:58 +0200 Subject: [Freeipa-devel] [PATCH 0356] trusts: Detect missing Samba instance In-Reply-To: <55D1D669.6000307@redhat.com> References: <55C316C7.8060806@redhat.com> <55D1D669.6000307@redhat.com> Message-ID: <55D1FA72.6000408@redhat.com> On 08/17/2015 02:41 PM, Martin Babinsky wrote: > On 08/06/2015 10:11 AM, Tomas Babej wrote: >> Hi, >> >> In the event of invocation of trust related commands, IPA server needs >> to contact local Samba instance. This is not possible on servers that >> merely act as AD trust agents, since they do not have Samba instance >> running. >> >> Properly detect the absence of the Samba instance and output >> user-friendly >> message which includes list of servers that are capable of running >> the command, if such exist. >> >> List of commands affected: >> * ipa trust-add >> * ipa trust-fetch-domains >> * all of the trustdomain commands available via CLI >> >> https://fedorahosted.org/freeipa/ticket/5165 >> >> >> > ACK > Pushed to: master: 1f62ab72caacbdb8eb892173d72c81e984a9fe56 ipa-4-2: 91c9559eea9d16c9915d35cfed6b22b43bc19809 From pvoborni at redhat.com Mon Aug 17 15:52:15 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 17 Aug 2015 17:52:15 +0200 Subject: [Freeipa-devel] [PATCHES 0360-0361] winsync-migrate: Add PassSync warnings In-Reply-To: <55D1B695.9070103@redhat.com> References: <55D1846A.9000702@redhat.com> <55D1B695.9070103@redhat.com> Message-ID: <55D2032F.9000306@redhat.com> On 08/17/2015 12:25 PM, Martin Babinsky wrote: > On 08/17/2015 08:51 AM, Tomas Babej wrote: >> Hi, >> >> the following pair of patches fixes: >> >> https://fedorahosted.org/freeipa/ticket/5162 >> >> >> > ACK > Pushed to: master: 0f8ff007b4b0b4dfd22ede32f755621f7d325c82 ipa-4-2: 5a9a8e2b09ada28d4f9a32eb833ffdc30d099fd0 -- Petr Vobornik From mbasti at redhat.com Mon Aug 17 16:47:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 17 Aug 2015 18:47:29 +0200 Subject: [Freeipa-devel] [PATCHES 0056-0057] improve backing-up of DNSSEC-related files In-Reply-To: <55CC9A31.80705@redhat.com> References: <55CC9A31.80705@redhat.com> Message-ID: <55D21021.9050904@redhat.com> On 08/13/2015 03:22 PM, Martin Babinsky wrote: > PATCH 0056 just fixes a typo in ipaplatform/paths > > PATCH 0057 addresses > https://fedorahosted.org/freeipa/ticket/5159 > > ACK Pushed to: ipa-4-2: 73ab4859e0749aeb8bf68454d575f94123695877 master: 0d1f35b054f0373d24eb2fe1830f2cf90b539381 From mbasti at redhat.com Mon Aug 17 18:33:51 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 17 Aug 2015 20:33:51 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command Message-ID: <55D2290F.3030509@redhat.com> Hello, the 'user-stage' command replaces 'stageuser-add --from-delete' command. https://fedorahosted.org/freeipa/ticket/5041 Thierry can you check If I don't break everything, it works for me, but the one never knows. Honza can you please check the framework side? I use self.api.Object.stageuser.add.* in user command, I'm not sure if this is right way, but it works. Patch attached. I created it in hurry, I'm expecting NACK :D Just question at the end: should I implement way Active user -> stageuser? IMHO it would be implemented internally by calling 'user-del --preserve' inside 'user-stage'. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0297-Add-user-stage-command.patch Type: text/x-patch Size: 10680 bytes Desc: not available URL: From rharwood at redhat.com Mon Aug 17 19:10:22 2015 From: rharwood at redhat.com (Robbie Harwood) Date: Mon, 17 Aug 2015 15:10:22 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55CC4971.5090105@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> Message-ID: Michael ?im??ek writes: > Attaching new revision of the patch. Changes from the previous: > - ldap2's connect now chooses the bind type same way as in ipaldap > - get_default_realm usages replaced by api.env.realm > - fixed missing third kinit attempt in trust-fetch-domains > - removed rewrapping gssapi errors to ccache errors in krb_utils > - updated some parts of exception handling This patch doesn't seem to apply to master. Can you update it or indicate what you're patching against? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From simo at redhat.com Tue Aug 18 01:25:25 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Aug 2015 21:25:25 -0400 Subject: [Freeipa-devel] Regression in client-install [master] Message-ID: <1439861125.2990.13.camel@willson.usersys.redhat.com> I see a regression in the client install now that the python-kerberos -> python-gssapi patches have landed. Reverting that single patch makes the issue go away, is anyone else seeing this ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Tue Aug 18 06:55:41 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 18 Aug 2015 08:55:41 +0200 Subject: [Freeipa-devel] Regression in client-install [master] In-Reply-To: <1439861125.2990.13.camel@willson.usersys.redhat.com> References: <1439861125.2990.13.camel@willson.usersys.redhat.com> Message-ID: <55D2D6ED.5080507@redhat.com> On 08/18/2015 03:25 AM, Simo Sorce wrote: > I see a regression in the client install now that the python-kerberos -> > python-gssapi patches have landed. > Reverting that single patch makes the issue go away, is anyone else > seeing this ? > > Simo. > I believe you're talking about https://fedorahosted.org/freeipa/ticket/5225 I can confirm reverting the gssapi patch did solve the issue yesterday (this is obvious, since the exception originates in the python-gssapi code). Tomas From tbordaz at redhat.com Tue Aug 18 07:50:25 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 18 Aug 2015 09:50:25 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D2290F.3030509@redhat.com> References: <55D2290F.3030509@redhat.com> Message-ID: <55D2E3C1.2030404@redhat.com> On 08/17/2015 08:33 PM, Martin Basti wrote: > Hello, > > the 'user-stage' command replaces 'stageuser-add --from-delete' command. > https://fedorahosted.org/freeipa/ticket/5041 > > Thierry can you check If I don't break everything, it works for me, > but the one never knows. > > Honza can you please check the framework side? I use > self.api.Object.stageuser.add.* in user command, I'm not sure if this > is right way, but it works. > > Patch attached. I created it in hurry, I'm expecting NACK :D > > > Just question at the end: should I implement way Active user -> > stageuser? IMHO it would be implemented internally by calling > 'user-del --preserve' inside 'user-stage'. > > > Hi Martin, There is a small failure with VERSION (edewata pushed his patch first ;-) ) git apply -v /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch Checking patch API.txt... Checking patch VERSION... error: while searching for: # # ######################################################## IPA_API_VERSION_MAJOR=2 IPA_API_VERSION_MINOR=148 # Last change: ftweedal - add --out option to user-show error: patch failed: VERSION:90 error: VERSION: patch does not apply Checking patch ipalib/plugins/stageuser.py... Checking patch ipalib/plugins/user.py... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 18 07:55:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 09:55:12 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D2E3C1.2030404@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> Message-ID: <55D2E4E0.6010005@redhat.com> On 08/18/2015 09:50 AM, thierry bordaz wrote: > On 08/17/2015 08:33 PM, Martin Basti wrote: >> Hello, >> >> the 'user-stage' command replaces 'stageuser-add --from-delete' command. >> https://fedorahosted.org/freeipa/ticket/5041 >> >> Thierry can you check If I don't break everything, it works for me, >> but the one never knows. >> >> Honza can you please check the framework side? I use >> self.api.Object.stageuser.add.* in user command, I'm not sure if this >> is right way, but it works. >> >> Patch attached. I created it in hurry, I'm expecting NACK :D >> >> >> Just question at the end: should I implement way Active user -> >> stageuser? IMHO it would be implemented internally by calling >> 'user-del --preserve' inside 'user-stage'. >> >> >> > Hi Martin, > > There is a small failure with VERSION (edewata pushed his patch first > ;-) ) > > git apply -v /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch > Checking patch API.txt... > Checking patch VERSION... > error: while searching for: > # # > ######################################################## > IPA_API_VERSION_MAJOR=2 > IPA_API_VERSION_MINOR=148 > # Last change: ftweedal - add --out option to user-show > > error: patch failed: VERSION:90 > error: VERSION: patch does not apply > Checking patch ipalib/plugins/stageuser.py... > Checking patch ipalib/plugins/user.py... > > There is many pending patches that may change VERSION number, I will change it to right one before push. Does code looks good for you? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Tue Aug 18 07:55:06 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 18 Aug 2015 09:55:06 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D2E4E0.6010005@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> Message-ID: <55D2E4DA.9090106@redhat.com> On 08/18/2015 09:55 AM, Martin Basti wrote: > > > On 08/18/2015 09:50 AM, thierry bordaz wrote: >> On 08/17/2015 08:33 PM, Martin Basti wrote: >>> Hello, >>> >>> the 'user-stage' command replaces 'stageuser-add --from-delete' >>> command. >>> https://fedorahosted.org/freeipa/ticket/5041 >>> >>> Thierry can you check If I don't break everything, it works for me, >>> but the one never knows. >>> >>> Honza can you please check the framework side? I use >>> self.api.Object.stageuser.add.* in user command, I'm not sure if >>> this is right way, but it works. >>> >>> Patch attached. I created it in hurry, I'm expecting NACK :D >>> >>> >>> Just question at the end: should I implement way Active user -> >>> stageuser? IMHO it would be implemented internally by calling >>> 'user-del --preserve' inside 'user-stage'. >>> >>> >>> >> Hi Martin, >> >> There is a small failure with VERSION (edewata pushed his patch first >> ;-) ) >> >> git apply -v /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >> Checking patch API.txt... >> Checking patch VERSION... >> error: while searching for: >> # # >> ######################################################## >> IPA_API_VERSION_MAJOR=2 >> IPA_API_VERSION_MINOR=148 >> # Last change: ftweedal - add --out option to user-show >> >> error: patch failed: VERSION:90 >> error: VERSION: patch does not apply >> Checking patch ipalib/plugins/stageuser.py... >> Checking patch ipalib/plugins/user.py... >> >> > There is many pending patches that may change VERSION number, I will > change it to right one before push. > > Does code looks good for you? Yes it looks good, but I am still testing it. I will be back to you with my test results. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Tue Aug 18 07:59:05 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 18 Aug 2015 09:59:05 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D2E4E0.6010005@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> Message-ID: <55D2E5C9.7030703@redhat.com> On 08/18/2015 09:55 AM, Martin Basti wrote: > > > On 08/18/2015 09:50 AM, thierry bordaz wrote: >> On 08/17/2015 08:33 PM, Martin Basti wrote: >>> Hello, >>> >>> the 'user-stage' command replaces 'stageuser-add --from-delete' >>> command. >>> https://fedorahosted.org/freeipa/ticket/5041 >>> >>> Thierry can you check If I don't break everything, it works for me, >>> but the one never knows. >>> >>> Honza can you please check the framework side? I use >>> self.api.Object.stageuser.add.* in user command, I'm not sure if >>> this is right way, but it works. >>> >>> Patch attached. I created it in hurry, I'm expecting NACK :D >>> >>> >>> Just question at the end: should I implement way Active user -> >>> stageuser? IMHO it would be implemented internally by calling >>> 'user-del --preserve' inside 'user-stage'. >>> >>> >>> >> Hi Martin, >> >> There is a small failure with VERSION (edewata pushed his patch first >> ;-) ) >> >> git apply -v /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >> Checking patch API.txt... >> Checking patch VERSION... >> error: while searching for: >> # # >> ######################################################## >> IPA_API_VERSION_MAJOR=2 >> IPA_API_VERSION_MINOR=148 >> # Last change: ftweedal - add --out option to user-show >> >> error: patch failed: VERSION:90 >> error: VERSION: patch does not apply >> Checking patch ipalib/plugins/stageuser.py... >> Checking patch ipalib/plugins/user.py... >> >> > There is many pending patches that may change VERSION number, I will > change it to right one before push. > > Does code looks good for you? Hi Martin, Just a question, there is no additional permission. Did you test being 'admin' ? thanks theirry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 18 08:02:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 10:02:23 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D2E5C9.7030703@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> Message-ID: <55D2E68F.7080601@redhat.com> On 08/18/2015 09:59 AM, thierry bordaz wrote: > On 08/18/2015 09:55 AM, Martin Basti wrote: >> >> >> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>> Hello, >>>> >>>> the 'user-stage' command replaces 'stageuser-add --from-delete' >>>> command. >>>> https://fedorahosted.org/freeipa/ticket/5041 >>>> >>>> Thierry can you check If I don't break everything, it works for me, >>>> but the one never knows. >>>> >>>> Honza can you please check the framework side? I use >>>> self.api.Object.stageuser.add.* in user command, I'm not sure if >>>> this is right way, but it works. >>>> >>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>> >>>> >>>> Just question at the end: should I implement way Active user -> >>>> stageuser? IMHO it would be implemented internally by calling >>>> 'user-del --preserve' inside 'user-stage'. >>>> >>>> >>>> >>> Hi Martin, >>> >>> There is a small failure with VERSION (edewata pushed his patch >>> first ;-) ) >>> >>> git apply -v /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>> Checking patch API.txt... >>> Checking patch VERSION... >>> error: while searching for: >>> # # >>> ######################################################## >>> IPA_API_VERSION_MAJOR=2 >>> IPA_API_VERSION_MINOR=148 >>> # Last change: ftweedal - add --out option to user-show >>> >>> error: patch failed: VERSION:90 >>> error: VERSION: patch does not apply >>> Checking patch ipalib/plugins/stageuser.py... >>> Checking patch ipalib/plugins/user.py... >>> >>> >> There is many pending patches that may change VERSION number, I will >> change it to right one before push. >> >> Does code looks good for you? > Hi Martin, > > Just a question, there is no additional permission. Did you test being > 'admin' ? > > thanks > theirry No I didn't,. I preserver all permission, the original permissions should work. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From msimacek at redhat.com Tue Aug 18 08:11:47 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Tue, 18 Aug 2015 10:11:47 +0200 Subject: [Freeipa-devel] Regression in client-install [master] In-Reply-To: <55D2D6ED.5080507@redhat.com> References: <1439861125.2990.13.camel@willson.usersys.redhat.com> <55D2D6ED.5080507@redhat.com> Message-ID: <55D2E8C3.3070207@redhat.com> On 2015-08-18 08:55, Tomas Babej wrote: > On 08/18/2015 03:25 AM, Simo Sorce wrote: >> I see a regression in the client install now that the python-kerberos -> >> python-gssapi patches have landed. >> Reverting that single patch makes the issue go away, is anyone else >> seeing this ? >> >> Simo. >> > > I believe you're talking about https://fedorahosted.org/freeipa/ticket/5225 > > I can confirm reverting the gssapi patch did solve the issue yesterday > (this is obvious, since the exception originates in the python-gssapi code). > > Tomas > The bug has been reported and fixed upstream: https://github.com/pythongssapi/python-gssapi/issues/72. Updating the package in Fedora to latest upstream release should solve the problem. Please wait with reverting. Michael From msimacek at redhat.com Tue Aug 18 08:37:30 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Tue, 18 Aug 2015 10:37:30 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> Message-ID: <55D2EECA.7030808@redhat.com> On 2015-08-17 21:10, Robbie Harwood wrote: > Michael ?im??ek writes: > >> Attaching new revision of the patch. Changes from the previous: >> - ldap2's connect now chooses the bind type same way as in ipaldap >> - get_default_realm usages replaced by api.env.realm >> - fixed missing third kinit attempt in trust-fetch-domains >> - removed rewrapping gssapi errors to ccache errors in krb_utils >> - updated some parts of exception handling > > This patch doesn't seem to apply to master. Can you update it or > indicate what you're patching against? Thanks! > Attaching patch rebased on top of current master. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-4-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 69202 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 18 08:45:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 10:45:35 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55CE1820.5060405@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> Message-ID: <55D2F0AF.8020003@redhat.com> On 08/14/2015 06:32 PM, Lenka Doudova wrote: > Yes, that is "correct" - it's malfunctioning behavior of the plugin - > command 'stageuser-add --from-delete', which is discussed in another > thread. I left this test case for so long as it's not fixed/changed. > If the command remains and is fixed, the test case will be valid, if > it's changed I'll fix the test case to reflect the new command. > > Lenka > > On 08/14/2015 05:39 PM, Martin Basti wrote: >> >> >> On 08/14/2015 11:04 AM, Lenka Doudova wrote: >>>> NACK >>>> >>>> syntax error, missing ')' >>>> -from ipatests.util import assert_equal, assert_not_equal, raises >>>> +from ipatests.util import ( >>>> + assert_equal, assert_not_equal, raises, assert_deepequal >>>> >>>> I cannot apply this patch, please check it >>> >>> Sorry for the error, corrected patch attached. >>> I also added two testcases that Thierry proposed, and changed names >>> of few methods (original ones were confusing). >>> >>> Lenka >> I got this error >> >> ==================================================================================================== >> FAILURES >> ===================================================================================================== >> ____________________________________________________________________________________ >> TestPreserved.test_staged_from_preserved >> _____________________________________________________________________________________ >> >> self = > object at 0x7ffb94811350>, user = >> > 0x7ffb949e7190> >> stageduser = >> > at 0x7ffb94811c50> >> >> def test_staged_from_preserved(self, user, stageduser): >> user.make_preserved_user() >> >> stageduser.ensure_missing() >> stageduser = StageUserTracker(user.uid, user.givenname, user.sn) >> stageduser.create_from_preserved(user) >> > command = user.make_create_command(from_delete=True) >> E TypeError: make_create_command() got an unexpected keyword >> argument 'from_delete' >> >> test_xmlrpc/test_stageuser_plugin.py:718: TypeError >> ---------------------------------------------------------------------------------------------- >> Captured stdout setup >> ---------------------------------------------------------------------------------------------- >> Ran command: ipalib.plugins.stageuser.stageuser_del()(u'suser1', >> version=u'2.148'): NotFound: suser1: stage user not found >> ---------------------------------------------------------------------------------------------- >> Captured stdout call >> ----------------------------------------------------------------------------------------------- >> Ran command: ipalib.plugins.user.user_add()(u'auser1', >> givenname=u'active', sn=u'user', version=u'2.148'): OK >> Ran command: ipalib.plugins.user.user_del()(u'auser1', preserve=True, >> no_preserve=False, version=u'2.148'): OK >> >> Martin^2 > Okay then, please fix this error in a new patch. Patch for replacement of stageuser-add --from delete already landed in devel list (patch mbasti-0297) If you want to have this test in ipa-4-2 branch, please send rebased version. Current patch applies only on master. From abokovoy at redhat.com Tue Aug 18 08:52:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Aug 2015 11:52:52 +0300 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <55D19B63.8020600@redhat.com> References: <20150813142943.GF22106@redhat.com> <55D185B5.1050704@redhat.com> <20150817070340.GN22106@redhat.com> <55D19B63.8020600@redhat.com> Message-ID: <20150818085252.GU22106@redhat.com> On Mon, 17 Aug 2015, Tomas Babej wrote: > > >On 08/17/2015 09:03 AM, Alexander Bokovoy wrote: >> On Mon, 17 Aug 2015, Tomas Babej wrote: >>> >>> >>> On 08/13/2015 04:29 PM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> see commit message for details. >>>> >>>> >>>> >>> >>> Hi, >>> >>> code-wise this looks good to me. Unfortunately, I have not been able to >>> verify in my setup that it fixes the issue in the linked BZ: >>> >>> $ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type >>> ipa-ad-trust --admin Administrator --password >>> ------------------------------------------------ >>> Added Active Directory trust for realm "ad.test" >>> ------------------------------------------------ >>> Realm name: ad.test >>> Domain NetBIOS name: AD >>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>> SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>> SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>> Trust direction: Trusting forest >>> Trust type: Active Directory domain >>> Trust status: Established and verified >>> >>> $ idrange-find >>> >>> ---------------- >>> 2 ranges matched >>> ---------------- >>> Range name: AD.TEST_id_range >>> First Posix ID of the range: 191200000 >>> Number of IDs in the range: 200000 >>> First RID of the corresponding RID range: 0 >>> Domain SID of the trusted domain: >>> S-1-5-21-1469936554-2294197481-461507924 >>> Range type: Active Directory domain range >>> >>> Range name: IPA.TEST_id_range >>> First Posix ID of the range: 695200000 >>> Number of IDs in the range: 200000 >>> First RID of the corresponding RID range: 1000 >>> First RID of the secondary RID range: 100000000 >>> Range type: local domain range >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >>> >>> However, I have one child subdomain in the setup: >>> >>> $ ipa trustdomain-find >>> Realm name: ad.test >>> Domain name: ad.test >>> Domain NetBIOS name: AD >>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>> Domain enabled: True >>> >>> Domain name: sub.ad.test >>> Domain NetBIOS name: SUB >>> Domain Security Identifier: S-1-5-21-10134726-2575992721-4229914074 >>> Domain enabled: True >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >> Look for AVCs, if there are any. >> >> Also start abrtd and it should pick up any python exceptions in the >> helper as 'crashes'. >> > >Right. Insufficient LDAP permissions caused the following backtrace in >the oddjob helper: > >ipaldap.py:948:error_handler:ACIError: Insufficient access: Insufficient >'add' privilege to add the entry >'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. > >Traceback (most recent call last): > File "/usr/libexec/ipa/com.redhat.idm.trust-fetch-domains", line 216, >in > trusted_domain, name, **dom) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >347, in add_range > ipanttrusteddomainsid=dom_sid) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, >in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, >in run > return self.execute(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >line 1234, in execute > self._exc_wrapper(keys, options, ldap.add_entry)(entry_attrs) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >line 1145, in wrapped > return func(*call_args, **call_kwargs) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >1442, in add_entry > self.conn.add_s(str(entry.dn), attrs.items()) > File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ > self.gen.throw(type, value, traceback) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >948, in error_handler > raise errors.ACIError(info=info) >ACIError: Insufficient access: Insufficient 'add' privilege to add the >entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. > >Local variables in innermost frame: >info: "Insufficient 'add' privilege to add the entry >'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'." >arg_desc: None >self: ipaserver.plugins.ldap2.ldap2() >e: INSUFFICIENT_ACCESS({'info': "Insufficient 'add' privilege to add the >entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'.\n", >'desc': 'Insufficient access'},) >desc: 'Insufficient access' Updated patch attached. You can install freeipa from my COPR abbra/freeipa-oneway (you need mkosek/freeipa-master COPR for dependencies) to test. -- / Alexander Bokovoy -------------- next part -------------- From eb667407662906b609282b13f87129c80c058a9f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 13 Aug 2015 17:18:57 +0300 Subject: [PATCH] trusts: harden trust-fetch-domains oddjobd-based script When ipa-getkeytab is used to fetch trusted domain object credentials, the fetched entry has always kvno 1. ipa-getkeytab always adds a key to keytab which means older key versions will be in the SSSD keytab and will confuse libkrb5 ccache initialization code as all kvno values are equal to 1. Wrong key is picked up then and kinit fails. To solve this problem, always remove existing /var/lib/sss/keytabs/forest.keytab before retrieving a new one. To make sure script's input cannot be used to define what should be removed (by passing a relative path), make sure we retrieve trusted forest name from LDAP. If it is not possible to retrieve, the script will issue an exception and quit. If abrtd is running, this will be recorded as a 'crash' and an attempt to use script by malicious user would be recorded as well in the abrtd journal. Additionally, as com.redhat.idm.trust-fetch-domains will create ID ranges for the domains of the trusted forest if they don't exist, it needs permissions to do so. The permission should be granted only to cifs/ipa.master at IPA.REALM services which means they must have krbprincipalname=cifs/*@IPA.REALM,cn=services,... DN and be members of cn=adtrust agents,cn=sysaccounts,... group. Solves https://bugzilla.redhat.com/show_bug.cgi?id=1250190 Ticket https://fedorahosted.org/freeipa/ticket/5182 --- install/oddjob/com.redhat.idm.trust-fetch-domains | 29 +++++++++++++++++++---- install/updates/20-aci.update | 4 ++++ 2 files changed, 28 insertions(+), 5 deletions(-) diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains b/install/oddjob/com.redhat.idm.trust-fetch-domains index e50c81e..6a2171d 100755 --- a/install/oddjob/com.redhat.idm.trust-fetch-domains +++ b/install/oddjob/com.redhat.idm.trust-fetch-domains @@ -41,6 +41,9 @@ def retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal): "-p", oneway_principal, "-k", oneway_keytab_name, "-r"] + if os.path.isfile(oneway_keytab_name): + os.unlink(oneway_keytab_name) + (stdout, stderr, retcode) = ipautil.run(getkeytab_args, env={'KRB5CCNAME': ccache_name, 'LANG': 'C'}, raiseonerr=False) @@ -111,7 +114,6 @@ from ipalib.plugins import trust # retrieve the keys to oneway_keytab_name. keytab_name = '/etc/samba/samba.keytab' -oneway_keytab_name = '/var/lib/sss/keytabs/' + trusted_domain + '.keytab' principal = str('cifs/' + api.env.host) @@ -137,10 +139,20 @@ else: old_ccache = os.environ.get('KRB5CCNAME') api.Backend.ldap2.connect(ccache) +# Retrieve own NetBIOS name and trusted forest's name. +# We use script's input to retrieve the trusted forest's name to sanitize input +# for file-level access as we might need to wipe out keytab in /var/lib/sss/keytabs own_trust_dn = DN(('cn', api.env.domain),('cn','ad'), ('cn', 'etc'), api.env.basedn) own_trust_entry = api.Backend.ldap2.get_entry(own_trust_dn, ['ipantflatname']) -own_trust_flatname = own_trust_entry['ipantflatname'][0].upper() +own_trust_flatname = own_trust_entry.single_value.get('ipantflatname').upper() +trusted_domain_dn = DN(('cn', trusted_domain.lower()), api.env.container_adtrusts, api.env.basedn) +trusted_domain_entry = api.Backend.ldap2.get_entry(trusted_domain_dn, ['cn']) +trusted_domain = trusted_domain_entry.single_value.get('cn').lower() +# At this point if we didn't find trusted forest name, an exception will be raised +# and script will quit. This is actually intended. + +oneway_keytab_name = '/var/lib/sss/keytabs/' + trusted_domain + '.keytab' oneway_principal = str('%s$@%s' % (own_trust_flatname, trusted_domain.upper())) # If keytab does not exist, retrieve it @@ -152,11 +164,18 @@ try: # The keytab may have stale key material (from older trust-add run) if not os.path.isfile(oneway_ccache_name): oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) + else: + oneway_ccache_check = KRB5_CCache(oneway_ccache_name) + if not oneway_ccache_check.credential_is_valid(oneway_principal): + # If credentials were invalid, obtain them again + oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) + else: + oneway_ccache = oneway_ccache_check.ccache except krbV.Krb5Error as e: # If there was failure on using keytab, assume it is stale and retrieve again retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal) -if oneway_ccache: +try: # There wasn existing ccache, validate its content oneway_ccache_check = KRB5_CCache(oneway_ccache_name) if not oneway_ccache_check.credential_is_valid(oneway_principal): @@ -164,7 +183,7 @@ if oneway_ccache: oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) else: oneway_ccache = oneway_ccache_check.ccache -else: +except krbV.Krb5Error as e: oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, oneway_ccache_name) # We are done: we have ccache with TDO credentials and can fetch domains @@ -193,7 +212,7 @@ if domains: dom['range_type'] = u'ipa-ad-trust' # Do not pass ipaserver.dcerpc.TrustInstance to trust.add_range # to force it using existing credentials cache - trust.add_range(None, range_name, dom['ipanttrusteddomainsid'], + trust.add_range(api, None, range_name, dom['ipanttrusteddomainsid'], trusted_domain, name, **dom) except errors.DuplicateEntry: # Ignore updating duplicate entries diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index 0bdeeb6..cba1897 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -87,3 +87,7 @@ add:aci:(targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can # Hosts can add their own services dn: cn=services,cn=accounts,$SUFFIX add:aci: (target = "ldap:///krbprincipalname=*/($$dn)@$REALM,cn=services,cn=accounts,$SUFFIX")(targetfilter = "(objectClass=ipaKrbPrincipal)")(version 3.0;acl "Hosts can add own services"; allow(add) userdn="ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) + +# CIFS service on the master can manage ID ranges +dn: cn=ranges,cn=etc,$SUFFIX +add:aci: (target = "ldap:///cn=*,cn=ranges,cn=etc,$SUFFIX")(targetfilter = "(objectClass=ipaIDrange)")(version 3.0;acl "CIFS service can manage ID ranges for trust"; allow(all) userdn="ldap:///krbprincipalname=cifs/*@$REALM,cn=services,cn=accounts,$SUFFIX" and groupdn="ldap:///cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX";) -- 2.4.3 From pvoborni at redhat.com Tue Aug 18 09:18:18 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Aug 2015 11:18:18 +0200 Subject: [Freeipa-devel] [PATCHES 472-473] vault: Fix param labels in output of vault owner commands In-Reply-To: <55D1909F.7090302@redhat.com> References: <55D1909F.7090302@redhat.com> Message-ID: <55D2F85A.4030901@redhat.com> On 08/17/2015 09:43 AM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza > ACK, pushed to: master: * d2da0d89d194f198728b858800dfec447c5d9595 baseldap: Allow overriding member param label in LDAPModMember * d9e9e5088fe3e093e3291a5e8877e8651645fc61 vault: Fix param labels in output of vault owner commands ipa-4-2: * 649a1a7c65d5ba99183dd0437d9ab4f20fa05530 baseldap: Allow overriding member param label in LDAPModMember * f66d7043dc2f35bdc7f7f3774ecbc12046b7feef vault: Fix param labels in output of vault owner commands -- Petr Vobornik From tbordaz at redhat.com Tue Aug 18 09:32:28 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 18 Aug 2015 11:32:28 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D2E68F.7080601@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> Message-ID: <55D2FBAC.2030801@redhat.com> On 08/18/2015 10:02 AM, Martin Basti wrote: > > > On 08/18/2015 09:59 AM, thierry bordaz wrote: >> On 08/18/2015 09:55 AM, Martin Basti wrote: >>> >>> >>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>> Hello, >>>>> >>>>> the 'user-stage' command replaces 'stageuser-add --from-delete' >>>>> command. >>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>> >>>>> Thierry can you check If I don't break everything, it works for >>>>> me, but the one never knows. >>>>> >>>>> Honza can you please check the framework side? I use >>>>> self.api.Object.stageuser.add.* in user command, I'm not sure if >>>>> this is right way, but it works. >>>>> >>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>> >>>>> >>>>> Just question at the end: should I implement way Active user -> >>>>> stageuser? IMHO it would be implemented internally by calling >>>>> 'user-del --preserve' inside 'user-stage'. >>>>> >>>>> >>>>> >>>> Hi Martin, >>>> >>>> There is a small failure with VERSION (edewata pushed his patch >>>> first ;-) ) >>>> >>>> git apply -v /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>> Checking patch API.txt... >>>> Checking patch VERSION... >>>> error: while searching for: >>>> # # >>>> ######################################################## >>>> IPA_API_VERSION_MAJOR=2 >>>> IPA_API_VERSION_MINOR=148 >>>> # Last change: ftweedal - add --out option to user-show >>>> >>>> error: patch failed: VERSION:90 >>>> error: VERSION: patch does not apply >>>> Checking patch ipalib/plugins/stageuser.py... >>>> Checking patch ipalib/plugins/user.py... >>>> >>>> >>> There is many pending patches that may change VERSION number, I will >>> change it to right one before push. >>> >>> Does code looks good for you? >> Hi Martin, >> >> Just a question, there is no additional permission. Did you test >> being 'admin' ? >> >> thanks >> theirry > No I didn't,. > > I preserver all permission, the original permissions should work. > > Martin Hi Martin, Running a test script, I have an issue with ipa stageuser-add --first=t --last=b tb1 ipa: ERROR: an internal error has occurred [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] ipa: INFO: [jsonserver_kerb] stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', displayname=u't b', initials=u'tb', gecos=u't b', krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', random=False, all=False, raw=False, version=u'2.149', no_members=False): AttributeError [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] ipa: ERROR: non-public: AttributeError: 'DN' object has no attribute 'setdefault' [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] Traceback (most recent call last): [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 347, in wsgi_execute [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid 10485] result = self.Command[name](*args, **options) [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, in __call__ [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid 10485] ret = self.run(*args, **options) [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, in run [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid 10485] return self.execute(*args, **options) [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1227, in execute [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid 10485] *keys, **options) [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] File "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", line 373, in pre_callback [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid 10485] attrs_list, *keys, **options) [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] File "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", line 277, in set_default_values_pre_callback [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] entry_attrs.setdefault('description', []) [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] AttributeError: 'DN' object has no attribute 'setdefault' [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] ipa: INFO: [jsonserver_session] stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', displayname=u't b', initials=u'tb', gecos=u't b', krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', random=False, all=False, raw=False, version=u'2.149', no_members=False): AttributeError The new set_default_values_pre_callback, can not use the set_default function. It is not clear why. entry_attrs is one of pre_callback parameter. Should set_default_values_pre_callback be a subfonction of pre_callback ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Aug 18 09:37:10 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 11:37:10 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55D1F411.3090107@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> <55CB29BA.7050200@redhat.com> <55D19A0C.7040607@redhat.com> <55D1F348.5080205@redhat.com> <55D1F411.3090107@redhat.com> Message-ID: <55D2FCC6.3040806@redhat.com> On 17.8.2015 16:47, Milan Kub?k wrote: > On 08/17/2015 04:44 PM, Milan Kub?k wrote: >> On 08/17/2015 10:23 AM, Martin Basti wrote: >>> >>> >>> On 08/12/2015 01:10 PM, Milan Kub?k wrote: >>>> On 08/10/2015 04:41 PM, Jan Cholasta wrote: >>>>> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >>>>>> >>>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: Re: [Freeipa-devel] Unable to install bits from >>>>>> ipa-4-2 branch >>>>>> Date: Mon, 10 Aug 2015 15:55:35 +0200 >>>>>> From: Jan Cholasta >>>>>> To: Milan Kub?k >>>>>> CC: Martin Kosek >>>>>> >>>>>> >>>>>> >>>>>> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>>>>>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>>>>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>>>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>>>>>> Hi list, >>>>>>>>>>>> >>>>>>>>>>>> I just noticed that the bits built from ipa-4-2 branch >>>>>>>>>>>> cannot be >>>>>>>>>>>> installed. >>>>>>>>>>>> The freeipa packages built have version such as >>>>>>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The version check in the spec file makes the server-dns package >>>>>>>>>>>> obsolete the >>>>>>>>>>>> server package from tha same build. >>>>>>>>>>>> The cause is the commit [1]. This issue blocks us from >>>>>>>>>>>> running tests >>>>>>>>>>>> on ipa-4-2 >>>>>>>>>>>> branch. >>>>>>>>>>>> >>>>>>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>>>>>> >>>>>>>>>>>> [1]: >>>>>>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Milan >>>>>>>>>>>> >>>>>>>>>>> Why does the spec calls for >>>>>>>>>>> >>>>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>>>>>> >>>>>>>>>>> and not for >>>>>>>>>>> >>>>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>>>>>> >>>>>>>>>>> ? Is that the root cause of these issues? >>>>>>>>>> >>>>>>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>>>>>> >>>>>>>>> I wonder how it could break the upgrade... >>>>>>>>> >>>>>>>> >>>>>>>> Patch attached. >>>>>>>> >>>>>>> This won't help as long as we build something like >>>>>>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >>>>>> >>>>>> Right. Updated patch attached. It will break updates from >>>>>> pre-server-dns >>>>>> git builds, but install should be fine. >>>>>> >>>>>> -- >>>>>> Jan Cholasta >>>>>> >>>>>> >>>>>> ACK, thanks. >>>>> >>>>> Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from >>>>> the freeipa-4.2 COPR. >>>>> >>>>> Updated patch attached. >>>>> >>>> Hi, >>>> >>>> thanks for the patch. It works as far as updating from 4.1, the copr >>>> build >>>> (correctly replaces freeipa-server package) as well as upgrade from >>>> earlier build from repository. >>>> >>>> If there are no objections, ACK from me. >>>> >>>> Milan >>>> >>> Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3 >> Ok, while checking this manually it seemed to work, the jenkins build >> names the package in a way that produces this error. The patch has no >> effect in automation, unfortunatelly. The build on jenkins adds the >> release version, when built manually, the name is >> xyz.4.2.0.DATE+hash-string. >> >> Error: package freeipa-server-dns-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 obsoletes freeipa-server <= 4.2.0.0 provided by freeipa-server-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 >> >> Late answer to Lukas, this is n:m scenario. I'm not sure what to do if one subpackage retains the original name, though. >> >> >> > That being said, I can change the schema by which jenkins marks release > version on the rpms it builds. > This will provide a hacky way around this issue by creating > 4.2.0.2015... provided by the timestamp. This is the scheme used by "make rpms", so I'd say go for it. Otherwise, changing the "Obsoletes" line to: Obsoletes: %{name}-server <= 4.2.0.0-0.0 should fix it. -- Jan Cholasta From abokovoy at redhat.com Tue Aug 18 09:56:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Aug 2015 12:56:53 +0300 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <20150818085252.GU22106@redhat.com> References: <20150813142943.GF22106@redhat.com> <55D185B5.1050704@redhat.com> <20150817070340.GN22106@redhat.com> <55D19B63.8020600@redhat.com> <20150818085252.GU22106@redhat.com> Message-ID: <20150818095653.GW22106@redhat.com> On Tue, 18 Aug 2015, Alexander Bokovoy wrote: >On Mon, 17 Aug 2015, Tomas Babej wrote: >> >> >>On 08/17/2015 09:03 AM, Alexander Bokovoy wrote: >>>On Mon, 17 Aug 2015, Tomas Babej wrote: >>>> >>>> >>>>On 08/13/2015 04:29 PM, Alexander Bokovoy wrote: >>>>>Hi, >>>>> >>>>>see commit message for details. >>>>> >>>>> >>>>> >>>> >>>>Hi, >>>> >>>>code-wise this looks good to me. Unfortunately, I have not been able to >>>>verify in my setup that it fixes the issue in the linked BZ: >>>> >>>>$ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type >>>>ipa-ad-trust --admin Administrator --password >>>>------------------------------------------------ >>>>Added Active Directory trust for realm "ad.test" >>>>------------------------------------------------ >>>> Realm name: ad.test >>>> Domain NetBIOS name: AD >>>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>>> SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>>>S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>>>S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>>> SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>>>S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>>>S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>>> Trust direction: Trusting forest >>>> Trust type: Active Directory domain >>>> Trust status: Established and verified >>>> >>>>$ idrange-find >>>> >>>>---------------- >>>>2 ranges matched >>>>---------------- >>>> Range name: AD.TEST_id_range >>>> First Posix ID of the range: 191200000 >>>> Number of IDs in the range: 200000 >>>> First RID of the corresponding RID range: 0 >>>> Domain SID of the trusted domain: >>>>S-1-5-21-1469936554-2294197481-461507924 >>>> Range type: Active Directory domain range >>>> >>>> Range name: IPA.TEST_id_range >>>> First Posix ID of the range: 695200000 >>>> Number of IDs in the range: 200000 >>>> First RID of the corresponding RID range: 1000 >>>> First RID of the secondary RID range: 100000000 >>>> Range type: local domain range >>>>---------------------------- >>>>Number of entries returned 2 >>>>---------------------------- >>>> >>>>However, I have one child subdomain in the setup: >>>> >>>>$ ipa trustdomain-find >>>>Realm name: ad.test >>>> Domain name: ad.test >>>> Domain NetBIOS name: AD >>>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>>> Domain enabled: True >>>> >>>> Domain name: sub.ad.test >>>> Domain NetBIOS name: SUB >>>> Domain Security Identifier: S-1-5-21-10134726-2575992721-4229914074 >>>> Domain enabled: True >>>>---------------------------- >>>>Number of entries returned 2 >>>>---------------------------- >>>Look for AVCs, if there are any. >>> >>>Also start abrtd and it should pick up any python exceptions in the >>>helper as 'crashes'. >>> >> >>Right. Insufficient LDAP permissions caused the following backtrace in >>the oddjob helper: >> >>ipaldap.py:948:error_handler:ACIError: Insufficient access: Insufficient >>'add' privilege to add the entry >>'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. >> >>Traceback (most recent call last): >> File "/usr/libexec/ipa/com.redhat.idm.trust-fetch-domains", line 216, >>in >> trusted_domain, name, **dom) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >>347, in add_range >> ipanttrusteddomainsid=dom_sid) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, >>in __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, >>in run >> return self.execute(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>line 1234, in execute >> self._exc_wrapper(keys, options, ldap.add_entry)(entry_attrs) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>line 1145, in wrapped >> return func(*call_args, **call_kwargs) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>1442, in add_entry >> self.conn.add_s(str(entry.dn), attrs.items()) >> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >> self.gen.throw(type, value, traceback) >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>948, in error_handler >> raise errors.ACIError(info=info) >>ACIError: Insufficient access: Insufficient 'add' privilege to add the >>entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. >> >>Local variables in innermost frame: >>info: "Insufficient 'add' privilege to add the entry >>'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'." >>arg_desc: None >>self: ipaserver.plugins.ldap2.ldap2() >>e: INSUFFICIENT_ACCESS({'info': "Insufficient 'add' privilege to add the >>entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'.\n", >>'desc': 'Insufficient access'},) >>desc: 'Insufficient access' >Updated patch attached. > >You can install freeipa from my COPR abbra/freeipa-oneway (you need >mkosek/freeipa-master COPR for dependencies) to test. .. and use abbra/sssd-kkdcproxy for sssd git master -- you'll need it to allow SSSD to properly handle keytabs chowned to sssd:sssd by the helper. With abbra/freeipa-oneway, abbra/sssd-kkdcproxy, mkosek/freeipa-master COPR repos I get child AD domains working correctly with one-way trust. -- / Alexander Bokovoy From mkubik at redhat.com Tue Aug 18 10:14:30 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 18 Aug 2015 12:14:30 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55D2FCC6.3040806@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> <55CB29BA.7050200@redhat.com> <55D19A0C.7040607@redhat.com> <55D1F348.5080205@redhat.com> <55D1F411.3090107@redhat.com> <55D2FCC6.3040806@redhat.com> Message-ID: <55D30586.8030505@redhat.com> On 08/18/2015 11:37 AM, Jan Cholasta wrote: > On 17.8.2015 16:47, Milan Kub?k wrote: >> On 08/17/2015 04:44 PM, Milan Kub?k wrote: >>> On 08/17/2015 10:23 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/12/2015 01:10 PM, Milan Kub?k wrote: >>>>> On 08/10/2015 04:41 PM, Jan Cholasta wrote: >>>>>> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>> -------- Forwarded Message -------- >>>>>>> Subject: Re: [Freeipa-devel] Unable to install bits from >>>>>>> ipa-4-2 branch >>>>>>> Date: Mon, 10 Aug 2015 15:55:35 +0200 >>>>>>> From: Jan Cholasta >>>>>>> To: Milan Kub?k >>>>>>> CC: Martin Kosek >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>>>>>>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>>>>>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>>>>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>>>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>>>>>>> Hi list, >>>>>>>>>>>>> >>>>>>>>>>>>> I just noticed that the bits built from ipa-4-2 branch >>>>>>>>>>>>> cannot be >>>>>>>>>>>>> installed. >>>>>>>>>>>>> The freeipa packages built have version such as >>>>>>>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The version check in the spec file makes the server-dns >>>>>>>>>>>>> package >>>>>>>>>>>>> obsolete the >>>>>>>>>>>>> server package from tha same build. >>>>>>>>>>>>> The cause is the commit [1]. This issue blocks us from >>>>>>>>>>>>> running tests >>>>>>>>>>>>> on ipa-4-2 >>>>>>>>>>>>> branch. >>>>>>>>>>>>> >>>>>>>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>>>>>>> >>>>>>>>>>>>> [1]: >>>>>>>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Milan >>>>>>>>>>>>> >>>>>>>>>>>> Why does the spec calls for >>>>>>>>>>>> >>>>>>>>>>>> # upgrade path from monolithic -server to -server + >>>>>>>>>>>> -server-dns >>>>>>>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>>>>>>> >>>>>>>>>>>> and not for >>>>>>>>>>>> >>>>>>>>>>>> # upgrade path from monolithic -server to -server + >>>>>>>>>>>> -server-dns >>>>>>>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>>>>>>> >>>>>>>>>>>> ? Is that the root cause of these issues? >>>>>>>>>>> >>>>>>>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>>>>>>> >>>>>>>>>> I wonder how it could break the upgrade... >>>>>>>>>> >>>>>>>>> >>>>>>>>> Patch attached. >>>>>>>>> >>>>>>>> This won't help as long as we build something like >>>>>>>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >>>>>>> >>>>>>> Right. Updated patch attached. It will break updates from >>>>>>> pre-server-dns >>>>>>> git builds, but install should be fine. >>>>>>> >>>>>>> -- >>>>>>> Jan Cholasta >>>>>>> >>>>>>> >>>>>>> ACK, thanks. >>>>>> >>>>>> Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from >>>>>> the freeipa-4.2 COPR. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>> Hi, >>>>> >>>>> thanks for the patch. It works as far as updating from 4.1, the copr >>>>> build >>>>> (correctly replaces freeipa-server package) as well as upgrade from >>>>> earlier build from repository. >>>>> >>>>> If there are no objections, ACK from me. >>>>> >>>>> Milan >>>>> >>>> Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3 >>> Ok, while checking this manually it seemed to work, the jenkins build >>> names the package in a way that produces this error. The patch has no >>> effect in automation, unfortunatelly. The build on jenkins adds the >>> release version, when built manually, the name is >>> xyz.4.2.0.DATE+hash-string. >>> >>> Error: package >>> freeipa-server-dns-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 >>> obsoletes freeipa-server <= 4.2.0.0 provided by >>> freeipa-server-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 >>> >>> Late answer to Lukas, this is n:m scenario. I'm not sure what to do >>> if one subpackage retains the original name, though. >>> >>> >>> >> That being said, I can change the schema by which jenkins marks release >> version on the rpms it builds. >> This will provide a hacky way around this issue by creating >> 4.2.0.2015... provided by the timestamp. > > This is the scheme used by "make rpms", so I'd say go for it. > Otherwise, changing the "Obsoletes" line to: > > Obsoletes: %{name}-server <= 4.2.0.0-0.0 > > should fix it. > The released packages don't really use that much numbers. Just freeipa-component-MAJOR.MINOR.RELEASE-PKGREL.arch... First three defined by freeipa, -X by fedora. Therefore, I don't think we should use 4.2.0.0. In jenkins I have changed it to use IPA_VERSION_IS_GIT_SNAPSHOT=yes which changes the naming schema allowing this hack to work. The jobs weren't using the VERSION script this way before, however. From pvoborni at redhat.com Tue Aug 18 10:27:09 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Aug 2015 12:27:09 +0200 Subject: [Freeipa-devel] [PATCH] 374 Fixed vault container ownership. In-Reply-To: <55CCB696.80004@redhat.com> References: <55C8FF4E.5010107@redhat.com> <55CCA72D.4060501@redhat.com> <55CCB696.80004@redhat.com> Message-ID: <55D3087D.5070903@redhat.com> On 08/13/2015 05:24 PM, Endi Sukma Dewata wrote: > On 8/13/2015 9:18 AM, Martin Basti wrote: >>> The vault-add command has been fixed such that if the user/service >>> private vault container does not exist yet it will be created and >>> owned by the user/service instead of the vault creator. >>> >>> https://fedorahosted.org/freeipa/ticket/5194 >> >> I cannot apply this patch, are there any additional required patches? >> >> I have current ipa master branch >> >> git am freeipa-edewata-0374-Fixed-vault-container-ownership.patch -3 >> Applying: Fixed vault container ownership. >> error: invalid object 100644 427b1ea1588af2fb09a99181b8773abdf8099b8d >> for 'ipalib/plugins/vault.py' >> fatal: git-write-tree: error building trees >> Repository lacks necessary blobs to fall back on 3-way merge. >> Cannot fall back to three-way merge. > > Rebased. This patch doesn't have any dependency. > ACK Pushed to master: 419754b1c11139435ae5b5082a51026da0d5e730 Pushed to ipa-4-2: e110f6da2f42c4cd52ae73c7aad2421559da56a2 -- Petr Vobornik From pvoborni at redhat.com Tue Aug 18 10:38:21 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Aug 2015 12:38:21 +0200 Subject: [Freeipa-devel] [PATCH] 911 vault: normalize service principal in service vault, operations Message-ID: <55D30B1D.7060707@redhat.com> https://fedorahosted.org/freeipa/ticket/5233 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0911-vault-normalize-service-principal-in-service-vault-o.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: From jcholast at redhat.com Tue Aug 18 10:42:58 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 12:42:58 +0200 Subject: [Freeipa-devel] [PATCH] 911 vault: normalize service principal in service vault, operations In-Reply-To: <55D30B1D.7060707@redhat.com> References: <55D30B1D.7060707@redhat.com> Message-ID: <55D30C32.3050807@redhat.com> Hi, On 18.8.2015 12:38, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/5233 s/normalizer=lambda value: normalize_principal(value)/normalizer=normalize_principal/. Honza -- Jan Cholasta From pvoborni at redhat.com Tue Aug 18 10:52:35 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Aug 2015 12:52:35 +0200 Subject: [Freeipa-devel] [PATCH] 912 vault: validate vault type Message-ID: <55D30E73.7090308@redhat.com> https://fedorahosted.org/freeipa/ticket/5211 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0912-vault-validate-vault-type.patch Type: text/x-patch Size: 4973 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Aug 18 10:52:51 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 18 Aug 2015 12:52:51 +0200 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection Message-ID: <55D30E83.2030909@redhat.com> https://fedorahosted.org/freeipa/ticket/4838 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0058-ipa-restore-check-whether-DS-is-running-before-attem.patch Type: text/x-patch Size: 1140 bytes Desc: not available URL: From jcholast at redhat.com Tue Aug 18 10:56:35 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 12:56:35 +0200 Subject: [Freeipa-devel] [PATCH 474] install: Fix CA-less replica install Message-ID: <55D30F63.6@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-474-install-Fix-CA-less-replica-install.patch Type: text/x-patch Size: 1534 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 18 11:07:25 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Aug 2015 13:07:25 +0200 Subject: [Freeipa-devel] [PATCH] 911 vault: normalize service principal in service vault, operations In-Reply-To: <55D30C32.3050807@redhat.com> References: <55D30B1D.7060707@redhat.com> <55D30C32.3050807@redhat.com> Message-ID: <55D311ED.4050800@redhat.com> On 08/18/2015 12:42 PM, Jan Cholasta wrote: > Hi, > > On 18.8.2015 12:38, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/5233 > > s/normalizer=lambda value: > normalize_principal(value)/normalizer=normalize_principal/. > > Honza > Fixed, updated patch attached -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0911-1-vault-normalize-service-principal-in-service-vault-o.patch Type: text/x-patch Size: 1144 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 18 11:16:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Aug 2015 14:16:27 +0300 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection In-Reply-To: <55D30E83.2030909@redhat.com> References: <55D30E83.2030909@redhat.com> Message-ID: <20150818111627.GB22106@redhat.com> On Tue, 18 Aug 2015, Martin Babinsky wrote: >https://fedorahosted.org/freeipa/ticket/4838 > >-- >Martin^3 Babinsky >From d86aae6c3fef4dea1afbbdbacbc978afbbfa5fcf Mon Sep 17 00:00:00 2001 >From: Martin Babinsky >Date: Tue, 18 Aug 2015 12:47:46 +0200 >Subject: [PATCH] ipa-restore: check whether DS is running before attempting > connection > >https://fedorahosted.org/freeipa/ticket/4838 >--- > ipaserver/install/ipa_restore.py | 7 +++++++ > 1 file changed, 7 insertions(+) > >diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py >index 65cb49355a0567446debe9c367aa3c1bc5a12e1c..b69ea90001a6fd03d0fddde8844870d1aa9c3704 100644 >--- a/ipaserver/install/ipa_restore.py >+++ b/ipaserver/install/ipa_restore.py >@@ -410,6 +410,13 @@ class Restore(admintool.AdminTool): > ''' > Create an ldapi connection and bind to it using autobind as root. > ''' >+ instance_name = installutils.realm_to_serverid(api.env.realm) >+ >+ if not services.knownservices.dirsrv.is_running(instance_name): >+ raise admintool.ScriptError( >+ "directory server instance is not running/configured" >+ ) >+ > if self._conn is not None: > return self._conn > ACK. -- / Alexander Bokovoy From jcholast at redhat.com Tue Aug 18 11:29:33 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 13:29:33 +0200 Subject: [Freeipa-devel] [PATCH] 911 vault: normalize service principal in service vault, operations In-Reply-To: <55D311ED.4050800@redhat.com> References: <55D30B1D.7060707@redhat.com> <55D30C32.3050807@redhat.com> <55D311ED.4050800@redhat.com> Message-ID: <55D3171D.30203@redhat.com> On 18.8.2015 13:07, Petr Vobornik wrote: > On 08/18/2015 12:42 PM, Jan Cholasta wrote: >> Hi, >> >> On 18.8.2015 12:38, Petr Vobornik wrote: >>> https://fedorahosted.org/freeipa/ticket/5233 >> >> s/normalizer=lambda value: >> normalize_principal(value)/normalizer=normalize_principal/. >> >> Honza >> > > Fixed, updated patch attached > ACK. Pushed to: master: 76ab7d9bae1a1381af9e7ed51297b00823cce857 ipa-4-2: c38e8c3ceb63673815dcf4269b67075f4b10f5cb -- Jan Cholasta From jcholast at redhat.com Tue Aug 18 11:29:51 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 13:29:51 +0200 Subject: [Freeipa-devel] [PATCH] 912 vault: validate vault type In-Reply-To: <55D30E73.7090308@redhat.com> References: <55D30E73.7090308@redhat.com> Message-ID: <55D3172F.4060007@redhat.com> On 18.8.2015 12:52, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/5211 ACK. Pushed to: master: 6941f4eec70456c542fb565405eed02cceb54e10 ipa-4-2: c34b288a69e7859c5153e0f6e8e449ee8fe46eb4 -- Jan Cholasta From jcholast at redhat.com Tue Aug 18 11:36:53 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 13:36:53 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55D30586.8030505@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> <55CB29BA.7050200@redhat.com> <55D19A0C.7040607@redhat.com> <55D1F348.5080205@redhat.com> <55D1F411.3090107@redhat.com> <55D2FCC6.3040806@redhat.com> <55D30586.8030505@redhat.com> Message-ID: <55D318D5.7000804@redhat.com> On 18.8.2015 12:14, Milan Kub?k wrote: > On 08/18/2015 11:37 AM, Jan Cholasta wrote: >> On 17.8.2015 16:47, Milan Kub?k wrote: >>> On 08/17/2015 04:44 PM, Milan Kub?k wrote: >>>> On 08/17/2015 10:23 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/12/2015 01:10 PM, Milan Kub?k wrote: >>>>>> On 08/10/2015 04:41 PM, Jan Cholasta wrote: >>>>>>> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -------- Forwarded Message -------- >>>>>>>> Subject: Re: [Freeipa-devel] Unable to install bits from >>>>>>>> ipa-4-2 branch >>>>>>>> Date: Mon, 10 Aug 2015 15:55:35 +0200 >>>>>>>> From: Jan Cholasta >>>>>>>> To: Milan Kub?k >>>>>>>> CC: Martin Kosek >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>>>>>>>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>>>>>>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>>>>>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>>>>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>>>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>>>>>>>> Hi list, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I just noticed that the bits built from ipa-4-2 branch >>>>>>>>>>>>>> cannot be >>>>>>>>>>>>>> installed. >>>>>>>>>>>>>> The freeipa packages built have version such as >>>>>>>>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The version check in the spec file makes the server-dns >>>>>>>>>>>>>> package >>>>>>>>>>>>>> obsolete the >>>>>>>>>>>>>> server package from tha same build. >>>>>>>>>>>>>> The cause is the commit [1]. This issue blocks us from >>>>>>>>>>>>>> running tests >>>>>>>>>>>>>> on ipa-4-2 >>>>>>>>>>>>>> branch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1]: >>>>>>>>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Milan >>>>>>>>>>>>>> >>>>>>>>>>>>> Why does the spec calls for >>>>>>>>>>>>> >>>>>>>>>>>>> # upgrade path from monolithic -server to -server + >>>>>>>>>>>>> -server-dns >>>>>>>>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>>>>>>>> >>>>>>>>>>>>> and not for >>>>>>>>>>>>> >>>>>>>>>>>>> # upgrade path from monolithic -server to -server + >>>>>>>>>>>>> -server-dns >>>>>>>>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>>>>>>>> >>>>>>>>>>>>> ? Is that the root cause of these issues? >>>>>>>>>>>> >>>>>>>>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>>>>>>>> >>>>>>>>>>> I wonder how it could break the upgrade... >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Patch attached. >>>>>>>>>> >>>>>>>>> This won't help as long as we build something like >>>>>>>>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >>>>>>>> >>>>>>>> Right. Updated patch attached. It will break updates from >>>>>>>> pre-server-dns >>>>>>>> git builds, but install should be fine. >>>>>>>> >>>>>>>> -- >>>>>>>> Jan Cholasta >>>>>>>> >>>>>>>> >>>>>>>> ACK, thanks. >>>>>>> >>>>>>> Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from >>>>>>> the freeipa-4.2 COPR. >>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>> Hi, >>>>>> >>>>>> thanks for the patch. It works as far as updating from 4.1, the copr >>>>>> build >>>>>> (correctly replaces freeipa-server package) as well as upgrade from >>>>>> earlier build from repository. >>>>>> >>>>>> If there are no objections, ACK from me. >>>>>> >>>>>> Milan >>>>>> >>>>> Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3 >>>> Ok, while checking this manually it seemed to work, the jenkins build >>>> names the package in a way that produces this error. The patch has no >>>> effect in automation, unfortunatelly. The build on jenkins adds the >>>> release version, when built manually, the name is >>>> xyz.4.2.0.DATE+hash-string. >>>> >>>> Error: package >>>> freeipa-server-dns-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 >>>> obsoletes freeipa-server <= 4.2.0.0 provided by >>>> freeipa-server-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 >>>> >>>> Late answer to Lukas, this is n:m scenario. I'm not sure what to do >>>> if one subpackage retains the original name, though. >>>> >>>> >>>> >>> That being said, I can change the schema by which jenkins marks release >>> version on the rpms it builds. >>> This will provide a hacky way around this issue by creating >>> 4.2.0.2015... provided by the timestamp. >> >> This is the scheme used by "make rpms", so I'd say go for it. >> Otherwise, changing the "Obsoletes" line to: >> >> Obsoletes: %{name}-server <= 4.2.0.0-0.0 >> >> should fix it. >> > The released packages don't really use that much numbers. That doesn't matter, what matters is how the numbers are compared. > Just freeipa-component-MAJOR.MINOR.RELEASE-PKGREL.arch... First three > defined by freeipa, -X by fedora. Therefore, I don't think we should use > 4.2.0.0. The spec file is not used for Fedora, just for "make rpms". > > In jenkins I have changed it to use IPA_VERSION_IS_GIT_SNAPSHOT=yes > which changes the naming schema allowing this hack to work. The jobs > weren't using the VERSION script this way before, however. -- Jan Cholasta From mbasti at redhat.com Tue Aug 18 11:41:04 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 13:41:04 +0200 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection In-Reply-To: <20150818111627.GB22106@redhat.com> References: <55D30E83.2030909@redhat.com> <20150818111627.GB22106@redhat.com> Message-ID: <55D319D0.2010700@redhat.com> On 08/18/2015 01:16 PM, Alexander Bokovoy wrote: > On Tue, 18 Aug 2015, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/4838 >> >> -- >> Martin^3 Babinsky > >> From d86aae6c3fef4dea1afbbdbacbc978afbbfa5fcf Mon Sep 17 00:00:00 2001 >> From: Martin Babinsky >> Date: Tue, 18 Aug 2015 12:47:46 +0200 >> Subject: [PATCH] ipa-restore: check whether DS is running before >> attempting >> connection >> >> https://fedorahosted.org/freeipa/ticket/4838 >> --- >> ipaserver/install/ipa_restore.py | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/ipaserver/install/ipa_restore.py >> b/ipaserver/install/ipa_restore.py >> index >> 65cb49355a0567446debe9c367aa3c1bc5a12e1c..b69ea90001a6fd03d0fddde8844870d1aa9c3704 >> 100644 >> --- a/ipaserver/install/ipa_restore.py >> +++ b/ipaserver/install/ipa_restore.py >> @@ -410,6 +410,13 @@ class Restore(admintool.AdminTool): >> ''' >> Create an ldapi connection and bind to it using autobind as >> root. >> ''' >> + instance_name = installutils.realm_to_serverid(api.env.realm) >> + >> + if not services.knownservices.dirsrv.is_running(instance_name): >> + raise admintool.ScriptError( >> + "directory server instance is not running/configured" >> + ) >> + >> if self._conn is not None: >> return self._conn >> > ACK. > Pushed to: master: 31776755b47f44f894e4f2bb256aca1c5262b8a8 ipa-4-2: e4b8cffdb4e017874bb7f12a7ca362b927ead67a From jcholast at redhat.com Tue Aug 18 12:05:13 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 14:05:13 +0200 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection In-Reply-To: <55D319D0.2010700@redhat.com> References: <55D30E83.2030909@redhat.com> <20150818111627.GB22106@redhat.com> <55D319D0.2010700@redhat.com> Message-ID: <55D31F79.6070801@redhat.com> On 18.8.2015 13:41, Martin Basti wrote: > > > On 08/18/2015 01:16 PM, Alexander Bokovoy wrote: >> On Tue, 18 Aug 2015, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/4838 >>> >>> -- >>> Martin^3 Babinsky >> >>> From d86aae6c3fef4dea1afbbdbacbc978afbbfa5fcf Mon Sep 17 00:00:00 2001 >>> From: Martin Babinsky >>> Date: Tue, 18 Aug 2015 12:47:46 +0200 >>> Subject: [PATCH] ipa-restore: check whether DS is running before >>> attempting >>> connection >>> >>> https://fedorahosted.org/freeipa/ticket/4838 >>> --- >>> ipaserver/install/ipa_restore.py | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/ipaserver/install/ipa_restore.py >>> b/ipaserver/install/ipa_restore.py >>> index >>> 65cb49355a0567446debe9c367aa3c1bc5a12e1c..b69ea90001a6fd03d0fddde8844870d1aa9c3704 >>> 100644 >>> --- a/ipaserver/install/ipa_restore.py >>> +++ b/ipaserver/install/ipa_restore.py >>> @@ -410,6 +410,13 @@ class Restore(admintool.AdminTool): >>> ''' >>> Create an ldapi connection and bind to it using autobind as >>> root. >>> ''' >>> + instance_name = installutils.realm_to_serverid(api.env.realm) >>> + >>> + if not services.knownservices.dirsrv.is_running(instance_name): >>> + raise admintool.ScriptError( >>> + "directory server instance is not running/configured" >>> + ) >>> + >>> if self._conn is not None: >>> return self._conn >>> >> ACK. >> > Pushed to: > master: 31776755b47f44f894e4f2bb256aca1c5262b8a8 > ipa-4-2: e4b8cffdb4e017874bb7f12a7ca362b927ead67a > I didn't try, but I'm pretty sure this patch breaks ipa-restore on systems without IPA installed, which was not at all the point of the ticket - the point was to replace the "Unable to get connection, skipping disabling agreements: Unable to bind to LDAP server: [Errno 2] No such file or directory" error message with something meaningful in such a case. -- Jan Cholasta From abokovoy at redhat.com Tue Aug 18 12:18:14 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Aug 2015 15:18:14 +0300 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection In-Reply-To: <55D31F79.6070801@redhat.com> References: <55D30E83.2030909@redhat.com> <20150818111627.GB22106@redhat.com> <55D319D0.2010700@redhat.com> <55D31F79.6070801@redhat.com> Message-ID: <20150818121814.GC22106@redhat.com> On Tue, 18 Aug 2015, Jan Cholasta wrote: >On 18.8.2015 13:41, Martin Basti wrote: >> >> >>On 08/18/2015 01:16 PM, Alexander Bokovoy wrote: >>>On Tue, 18 Aug 2015, Martin Babinsky wrote: >>>>https://fedorahosted.org/freeipa/ticket/4838 >>>> >>>>-- >>>>Martin^3 Babinsky >>> >>>>From d86aae6c3fef4dea1afbbdbacbc978afbbfa5fcf Mon Sep 17 00:00:00 2001 >>>>From: Martin Babinsky >>>>Date: Tue, 18 Aug 2015 12:47:46 +0200 >>>>Subject: [PATCH] ipa-restore: check whether DS is running before >>>>attempting >>>>connection >>>> >>>>https://fedorahosted.org/freeipa/ticket/4838 >>>>--- >>>>ipaserver/install/ipa_restore.py | 7 +++++++ >>>>1 file changed, 7 insertions(+) >>>> >>>>diff --git a/ipaserver/install/ipa_restore.py >>>>b/ipaserver/install/ipa_restore.py >>>>index >>>>65cb49355a0567446debe9c367aa3c1bc5a12e1c..b69ea90001a6fd03d0fddde8844870d1aa9c3704 >>>>100644 >>>>--- a/ipaserver/install/ipa_restore.py >>>>+++ b/ipaserver/install/ipa_restore.py >>>>@@ -410,6 +410,13 @@ class Restore(admintool.AdminTool): >>>> ''' >>>> Create an ldapi connection and bind to it using autobind as >>>>root. >>>> ''' >>>>+ instance_name = installutils.realm_to_serverid(api.env.realm) >>>>+ >>>>+ if not services.knownservices.dirsrv.is_running(instance_name): >>>>+ raise admintool.ScriptError( >>>>+ "directory server instance is not running/configured" >>>>+ ) >>>>+ >>>> if self._conn is not None: >>>> return self._conn >>>> >>>ACK. >>> >>Pushed to: >>master: 31776755b47f44f894e4f2bb256aca1c5262b8a8 >>ipa-4-2: e4b8cffdb4e017874bb7f12a7ca362b927ead67a >> > >I didn't try, but I'm pretty sure this patch breaks ipa-restore on >systems without IPA installed, which was not at all the point of the >ticket - the point was to replace the "Unable to get connection, >skipping disabling agreements: Unable to bind to LDAP server: [Errno >2] No such file or directory" error message with something meaningful >in such a case. The code below 'if self._conn is not None:' is following: self._conn = ipaldap.IPAdmin(host=api.env.host, ldapi=True, protocol='ldapi', realm=api.env.realm) try: pw_name = pwd.getpwuid(os.geteuid()).pw_name self._conn.do_external_bind(pw_name) except Exception, e: raise admintool.ScriptError('Unable to bind to LDAP server: %s' % e) return self._conn So you'd get the same behavior as ipaldap.IPAdmin will attempt to connect to LDAP server (it calls ldap.initialize()) and try/except block will then fail. -- / Alexander Bokovoy From mbabinsk at redhat.com Tue Aug 18 12:24:10 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 18 Aug 2015 14:24:10 +0200 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection In-Reply-To: <55D31F79.6070801@redhat.com> References: <55D30E83.2030909@redhat.com> <20150818111627.GB22106@redhat.com> <55D319D0.2010700@redhat.com> <55D31F79.6070801@redhat.com> Message-ID: <55D323EA.5040603@redhat.com> On 08/18/2015 02:05 PM, Jan Cholasta wrote: > On 18.8.2015 13:41, Martin Basti wrote: >> >> >> On 08/18/2015 01:16 PM, Alexander Bokovoy wrote: >>> On Tue, 18 Aug 2015, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/4838 >>>> >>>> -- >>>> Martin^3 Babinsky >>> >>>> From d86aae6c3fef4dea1afbbdbacbc978afbbfa5fcf Mon Sep 17 00:00:00 2001 >>>> From: Martin Babinsky >>>> Date: Tue, 18 Aug 2015 12:47:46 +0200 >>>> Subject: [PATCH] ipa-restore: check whether DS is running before >>>> attempting >>>> connection >>>> >>>> https://fedorahosted.org/freeipa/ticket/4838 >>>> --- >>>> ipaserver/install/ipa_restore.py | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/ipaserver/install/ipa_restore.py >>>> b/ipaserver/install/ipa_restore.py >>>> index >>>> 65cb49355a0567446debe9c367aa3c1bc5a12e1c..b69ea90001a6fd03d0fddde8844870d1aa9c3704 >>>> >>>> 100644 >>>> --- a/ipaserver/install/ipa_restore.py >>>> +++ b/ipaserver/install/ipa_restore.py >>>> @@ -410,6 +410,13 @@ class Restore(admintool.AdminTool): >>>> ''' >>>> Create an ldapi connection and bind to it using autobind as >>>> root. >>>> ''' >>>> + instance_name = installutils.realm_to_serverid(api.env.realm) >>>> + >>>> + if not >>>> services.knownservices.dirsrv.is_running(instance_name): >>>> + raise admintool.ScriptError( >>>> + "directory server instance is not running/configured" >>>> + ) >>>> + >>>> if self._conn is not None: >>>> return self._conn >>>> >>> ACK. >>> >> Pushed to: >> master: 31776755b47f44f894e4f2bb256aca1c5262b8a8 >> ipa-4-2: e4b8cffdb4e017874bb7f12a7ca362b927ead67a >> > > I didn't try, but I'm pretty sure this patch breaks ipa-restore on > systems without IPA installed, which was not at all the point of the > ticket - the point was to replace the "Unable to get connection, > skipping disabling agreements: Unable to bind to LDAP server: [Errno 2] > No such file or directory" error message with something meaningful in > such a case. > I have just now tested ipa-restore without installed IPA master and it works just fine. The point of my patch was no not even try to connect to DS if the instance is not running/configured and raise an error telling this fact to the user, instead of timing out on connection and then raising a generic exception. So unless I missed something it should be ok. -- Martin^3 Babinsky From ssorce at redhat.com Tue Aug 18 12:39:57 2015 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Aug 2015 08:39:57 -0400 Subject: [Freeipa-devel] Regression in client-install [master] In-Reply-To: <55D2D6ED.5080507@redhat.com> References: <1439861125.2990.13.camel@willson.usersys.redhat.com> <55D2D6ED.5080507@redhat.com> Message-ID: <1439901597.2990.21.camel@willson.usersys.redhat.com> On Tue, 2015-08-18 at 08:55 +0200, Tomas Babej wrote: > On 08/18/2015 03:25 AM, Simo Sorce wrote: > > I see a regression in the client install now that the python-kerberos -> > > python-gssapi patches have landed. > > Reverting that single patch makes the issue go away, is anyone else > > seeing this ? > > > > Simo. > > > > I believe you're talking about https://fedorahosted.org/freeipa/ticket/5225 > > I can confirm reverting the gssapi patch did solve the issue yesterday > (this is obvious, since the exception originates in the python-gssapi code). No I had a completely different backtrace, my client install was correctly pinging the json endpoint and then complaining it couldn't find a negotiate response. Simo. From jcholast at redhat.com Tue Aug 18 12:51:54 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 14:51:54 +0200 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection In-Reply-To: <55D323EA.5040603@redhat.com> References: <55D30E83.2030909@redhat.com> <20150818111627.GB22106@redhat.com> <55D319D0.2010700@redhat.com> <55D31F79.6070801@redhat.com> <55D323EA.5040603@redhat.com> Message-ID: <55D32A6A.5020602@redhat.com> On 18.8.2015 14:24, Martin Babinsky wrote: > On 08/18/2015 02:05 PM, Jan Cholasta wrote: >> On 18.8.2015 13:41, Martin Basti wrote: >>> >>> >>> On 08/18/2015 01:16 PM, Alexander Bokovoy wrote: >>>> On Tue, 18 Aug 2015, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4838 >>>>> >>>>> -- >>>>> Martin^3 Babinsky >>>> >>>>> From d86aae6c3fef4dea1afbbdbacbc978afbbfa5fcf Mon Sep 17 00:00:00 2001 >>>>> From: Martin Babinsky >>>>> Date: Tue, 18 Aug 2015 12:47:46 +0200 >>>>> Subject: [PATCH] ipa-restore: check whether DS is running before >>>>> attempting >>>>> connection >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4838 >>>>> --- >>>>> ipaserver/install/ipa_restore.py | 7 +++++++ >>>>> 1 file changed, 7 insertions(+) >>>>> >>>>> diff --git a/ipaserver/install/ipa_restore.py >>>>> b/ipaserver/install/ipa_restore.py >>>>> index >>>>> 65cb49355a0567446debe9c367aa3c1bc5a12e1c..b69ea90001a6fd03d0fddde8844870d1aa9c3704 >>>>> >>>>> >>>>> 100644 >>>>> --- a/ipaserver/install/ipa_restore.py >>>>> +++ b/ipaserver/install/ipa_restore.py >>>>> @@ -410,6 +410,13 @@ class Restore(admintool.AdminTool): >>>>> ''' >>>>> Create an ldapi connection and bind to it using autobind as >>>>> root. >>>>> ''' >>>>> + instance_name = installutils.realm_to_serverid(api.env.realm) >>>>> + >>>>> + if not >>>>> services.knownservices.dirsrv.is_running(instance_name): >>>>> + raise admintool.ScriptError( >>>>> + "directory server instance is not running/configured" >>>>> + ) >>>>> + >>>>> if self._conn is not None: >>>>> return self._conn >>>>> >>>> ACK. >>>> >>> Pushed to: >>> master: 31776755b47f44f894e4f2bb256aca1c5262b8a8 >>> ipa-4-2: e4b8cffdb4e017874bb7f12a7ca362b927ead67a >>> >> >> I didn't try, but I'm pretty sure this patch breaks ipa-restore on >> systems without IPA installed, which was not at all the point of the >> ticket - the point was to replace the "Unable to get connection, >> skipping disabling agreements: Unable to bind to LDAP server: [Errno 2] >> No such file or directory" error message with something meaningful in >> such a case. >> > > I have just now tested ipa-restore without installed IPA master and it > works just fine. > > The point of my patch was no not even try to connect to DS if the > instance is not running/configured and raise an error telling this fact > to the user, instead of timing out on connection and then raising a > generic exception. > > So unless I missed something it should be ok. > I stand corrected. It was the ScriptError that made me suspicious. Sorry for the noise. -- Jan Cholasta From mbabinsk at redhat.com Tue Aug 18 12:56:22 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 18 Aug 2015 14:56:22 +0200 Subject: [Freeipa-devel] [PATCH 0058] ipa-restore: check whether DS is running before attempting connection In-Reply-To: <55D32A6A.5020602@redhat.com> References: <55D30E83.2030909@redhat.com> <20150818111627.GB22106@redhat.com> <55D319D0.2010700@redhat.com> <55D31F79.6070801@redhat.com> <55D323EA.5040603@redhat.com> <55D32A6A.5020602@redhat.com> Message-ID: <55D32B76.1010609@redhat.com> On 08/18/2015 02:51 PM, Jan Cholasta wrote: > On 18.8.2015 14:24, Martin Babinsky wrote: >> On 08/18/2015 02:05 PM, Jan Cholasta wrote: >>> On 18.8.2015 13:41, Martin Basti wrote: >>>> >>>> >>>> On 08/18/2015 01:16 PM, Alexander Bokovoy wrote: >>>>> On Tue, 18 Aug 2015, Martin Babinsky wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4838 >>>>>> >>>>>> -- >>>>>> Martin^3 Babinsky >>>>> >>>>>> From d86aae6c3fef4dea1afbbdbacbc978afbbfa5fcf Mon Sep 17 00:00:00 >>>>>> 2001 >>>>>> From: Martin Babinsky >>>>>> Date: Tue, 18 Aug 2015 12:47:46 +0200 >>>>>> Subject: [PATCH] ipa-restore: check whether DS is running before >>>>>> attempting >>>>>> connection >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4838 >>>>>> --- >>>>>> ipaserver/install/ipa_restore.py | 7 +++++++ >>>>>> 1 file changed, 7 insertions(+) >>>>>> >>>>>> diff --git a/ipaserver/install/ipa_restore.py >>>>>> b/ipaserver/install/ipa_restore.py >>>>>> index >>>>>> 65cb49355a0567446debe9c367aa3c1bc5a12e1c..b69ea90001a6fd03d0fddde8844870d1aa9c3704 >>>>>> >>>>>> >>>>>> >>>>>> 100644 >>>>>> --- a/ipaserver/install/ipa_restore.py >>>>>> +++ b/ipaserver/install/ipa_restore.py >>>>>> @@ -410,6 +410,13 @@ class Restore(admintool.AdminTool): >>>>>> ''' >>>>>> Create an ldapi connection and bind to it using autobind as >>>>>> root. >>>>>> ''' >>>>>> + instance_name = >>>>>> installutils.realm_to_serverid(api.env.realm) >>>>>> + >>>>>> + if not >>>>>> services.knownservices.dirsrv.is_running(instance_name): >>>>>> + raise admintool.ScriptError( >>>>>> + "directory server instance is not >>>>>> running/configured" >>>>>> + ) >>>>>> + >>>>>> if self._conn is not None: >>>>>> return self._conn >>>>>> >>>>> ACK. >>>>> >>>> Pushed to: >>>> master: 31776755b47f44f894e4f2bb256aca1c5262b8a8 >>>> ipa-4-2: e4b8cffdb4e017874bb7f12a7ca362b927ead67a >>>> >>> >>> I didn't try, but I'm pretty sure this patch breaks ipa-restore on >>> systems without IPA installed, which was not at all the point of the >>> ticket - the point was to replace the "Unable to get connection, >>> skipping disabling agreements: Unable to bind to LDAP server: [Errno 2] >>> No such file or directory" error message with something meaningful in >>> such a case. >>> >> >> I have just now tested ipa-restore without installed IPA master and it >> works just fine. >> >> The point of my patch was no not even try to connect to DS if the >> instance is not running/configured and raise an error telling this fact >> to the user, instead of timing out on connection and then raising a >> generic exception. >> >> So unless I missed something it should be ok. >> > > I stand corrected. > > It was the ScriptError that made me suspicious. > > Sorry for the noise. > Yeah in retrospect it was not the best exception to raise in this case. I was probably influenced by the fact that ScriptError gets thrown around so much in the ipa_restore code and got a bit lazy :). -- Martin^3 Babinsky From ssorce at redhat.com Tue Aug 18 12:56:47 2015 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 18 Aug 2015 08:56:47 -0400 Subject: [Freeipa-devel] Regression in client-install [master] In-Reply-To: <55D2E8C3.3070207@redhat.com> References: <1439861125.2990.13.camel@willson.usersys.redhat.com> <55D2D6ED.5080507@redhat.com> <55D2E8C3.3070207@redhat.com> Message-ID: <1439902607.2990.25.camel@willson.usersys.redhat.com> On Tue, 2015-08-18 at 10:11 +0200, Michael ?im??ek wrote: > > On 2015-08-18 08:55, Tomas Babej wrote: > > On 08/18/2015 03:25 AM, Simo Sorce wrote: > >> I see a regression in the client install now that the python-kerberos -> > >> python-gssapi patches have landed. > >> Reverting that single patch makes the issue go away, is anyone else > >> seeing this ? > >> > >> Simo. > >> > > > > I believe you're talking about https://fedorahosted.org/freeipa/ticket/5225 > > > > I can confirm reverting the gssapi patch did solve the issue yesterday > > (this is obvious, since the exception originates in the python-gssapi code). > > > > Tomas > > > > The bug has been reported and fixed upstream: > https://github.com/pythongssapi/python-gssapi/issues/72. Updating the > package in Fedora to latest upstream release should solve the problem. > Please wait with reverting. Please submit a patch to raise the minimum Requires, however I did not see the same bug, I will make sure I have the latest python-gssapi and retest. Simo. From mbasti at redhat.com Tue Aug 18 13:06:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 15:06:27 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D2FBAC.2030801@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> Message-ID: <55D32DD3.3050501@redhat.com> On 08/18/2015 11:32 AM, thierry bordaz wrote: > On 08/18/2015 10:02 AM, Martin Basti wrote: >> >> >> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>> Hello, >>>>>> >>>>>> the 'user-stage' command replaces 'stageuser-add --from-delete' >>>>>> command. >>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>> >>>>>> Thierry can you check If I don't break everything, it works for >>>>>> me, but the one never knows. >>>>>> >>>>>> Honza can you please check the framework side? I use >>>>>> self.api.Object.stageuser.add.* in user command, I'm not sure if >>>>>> this is right way, but it works. >>>>>> >>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>> >>>>>> >>>>>> Just question at the end: should I implement way Active user -> >>>>>> stageuser? IMHO it would be implemented internally by calling >>>>>> 'user-del --preserve' inside 'user-stage'. >>>>>> >>>>>> >>>>>> >>>>> Hi Martin, >>>>> >>>>> There is a small failure with VERSION (edewata pushed his patch >>>>> first ;-) ) >>>>> >>>>> git apply -v /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>> Checking patch API.txt... >>>>> Checking patch VERSION... >>>>> error: while searching for: >>>>> # # >>>>> ######################################################## >>>>> IPA_API_VERSION_MAJOR=2 >>>>> IPA_API_VERSION_MINOR=148 >>>>> # Last change: ftweedal - add --out option to user-show >>>>> >>>>> error: patch failed: VERSION:90 >>>>> error: VERSION: patch does not apply >>>>> Checking patch ipalib/plugins/stageuser.py... >>>>> Checking patch ipalib/plugins/user.py... >>>>> >>>>> >>>> There is many pending patches that may change VERSION number, I >>>> will change it to right one before push. >>>> >>>> Does code looks good for you? >>> Hi Martin, >>> >>> Just a question, there is no additional permission. Did you test >>> being 'admin' ? >>> >>> thanks >>> theirry >> No I didn't,. >> >> I preserver all permission, the original permissions should work. >> >> Martin > Hi Martin, > > Running a test script, I have an issue with > > ipa stageuser-add --first=t --last=b tb1 > ipa: ERROR: an internal error has occurred > > > [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] ipa: > INFO: [jsonserver_kerb] stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: > stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', > displayname=u't b', initials=u'tb', gecos=u't b', > krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', > random=False, all=False, raw=False, version=u'2.149', > no_members=False): AttributeError > [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] ipa: > ERROR: non-public: AttributeError: 'DN' object has no attribute > 'setdefault' > [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] > Traceback (most recent call last): > [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > 347, in wsgi_execute > [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid 10485] > result = self.Command[name](*args, **options) > [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, > in __call__ > [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid 10485] ret > = self.run(*args, **options) > [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, > in run > [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid 10485] > return self.execute(*args, **options) > [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", > line 1227, in execute > [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid 10485] > *keys, **options) > [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", > line 373, in pre_callback > [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid 10485] > attrs_list, *keys, **options) > [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", > line 277, in set_default_values_pre_callback > [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] > entry_attrs.setdefault('description', []) > [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] > AttributeError: 'DN' object has no attribute 'setdefault' > [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] ipa: > INFO: [jsonserver_session] > stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', > givenname=u't', sn=u'b', cn=u't b', displayname=u't b', > initials=u'tb', gecos=u't b', > krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', > random=False, all=False, raw=False, version=u'2.149', > no_members=False): AttributeError > > > The new set_default_values_pre_callback, can not use the set_default > function. It is not clear why. entry_attrs is one of pre_callback > parameter. > Should set_default_values_pre_callback be a subfonction of pre_callback ? > > > thanks > thierry Thank you, updated patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0297.2-Add-user-stage-command.patch Type: text/x-patch Size: 18978 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Aug 18 13:12:43 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 18 Aug 2015 15:12:43 +0200 Subject: [Freeipa-devel] [PATCH 474] install: Fix CA-less replica install In-Reply-To: <55D30F63.6@redhat.com> References: <55D30F63.6@redhat.com> Message-ID: <55D32F4B.9040202@redhat.com> On 08/18/2015 12:56 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK -- Martin^3 Babinsky From tbordaz at redhat.com Tue Aug 18 13:49:56 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 18 Aug 2015 15:49:56 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D32DD3.3050501@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> Message-ID: <55D33804.6000201@redhat.com> On 08/18/2015 03:06 PM, Martin Basti wrote: > > > On 08/18/2015 11:32 AM, thierry bordaz wrote: >> On 08/18/2015 10:02 AM, Martin Basti wrote: >>> >>> >>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>> Hello, >>>>>>> >>>>>>> the 'user-stage' command replaces 'stageuser-add --from-delete' >>>>>>> command. >>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>> >>>>>>> Thierry can you check If I don't break everything, it works for >>>>>>> me, but the one never knows. >>>>>>> >>>>>>> Honza can you please check the framework side? I use >>>>>>> self.api.Object.stageuser.add.* in user command, I'm not sure if >>>>>>> this is right way, but it works. >>>>>>> >>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>> >>>>>>> >>>>>>> Just question at the end: should I implement way Active user -> >>>>>>> stageuser? IMHO it would be implemented internally by calling >>>>>>> 'user-del --preserve' inside 'user-stage'. >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> There is a small failure with VERSION (edewata pushed his patch >>>>>> first ;-) ) >>>>>> >>>>>> git apply -v >>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>> Checking patch API.txt... >>>>>> Checking patch VERSION... >>>>>> error: while searching for: >>>>>> # # >>>>>> ######################################################## >>>>>> IPA_API_VERSION_MAJOR=2 >>>>>> IPA_API_VERSION_MINOR=148 >>>>>> # Last change: ftweedal - add --out option to user-show >>>>>> >>>>>> error: patch failed: VERSION:90 >>>>>> error: VERSION: patch does not apply >>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>> Checking patch ipalib/plugins/user.py... >>>>>> >>>>>> >>>>> There is many pending patches that may change VERSION number, I >>>>> will change it to right one before push. >>>>> >>>>> Does code looks good for you? >>>> Hi Martin, >>>> >>>> Just a question, there is no additional permission. Did you test >>>> being 'admin' ? >>>> >>>> thanks >>>> theirry >>> No I didn't,. >>> >>> I preserver all permission, the original permissions should work. >>> >>> Martin >> Hi Martin, >> >> Running a test script, I have an issue with >> >> ipa stageuser-add --first=t --last=b tb1 >> ipa: ERROR: an internal error has occurred >> >> >> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] ipa: >> INFO: [jsonserver_kerb] stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >> displayname=u't b', initials=u'tb', gecos=u't b', >> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >> random=False, all=False, raw=False, version=u'2.149', >> no_members=False): AttributeError >> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] ipa: >> ERROR: non-public: AttributeError: 'DN' object has no attribute >> 'setdefault' >> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >> Traceback (most recent call last): >> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >> 347, in wsgi_execute >> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid 10485] >> result = self.Command[name](*args, **options) >> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, >> in __call__ >> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid 10485] >> ret = self.run(*args, **options) >> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, >> in run >> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid 10485] >> return self.execute(*args, **options) >> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >> line 1227, in execute >> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid 10485] >> *keys, **options) >> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >> line 373, in pre_callback >> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid 10485] >> attrs_list, *keys, **options) >> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >> line 277, in set_default_values_pre_callback >> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >> entry_attrs.setdefault('description', []) >> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >> AttributeError: 'DN' object has no attribute 'setdefault' >> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] ipa: >> INFO: [jsonserver_session] >> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', >> givenname=u't', sn=u'b', cn=u't b', displayname=u't b', >> initials=u'tb', gecos=u't b', >> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >> random=False, all=False, raw=False, version=u'2.149', >> no_members=False): AttributeError >> >> >> The new set_default_values_pre_callback, can not use the set_default >> function. It is not clear why. entry_attrs is one of pre_callback >> parameter. >> Should set_default_values_pre_callback be a subfonction of pre_callback ? >> >> >> thanks >> thierry > > Thank you, > > updated patch attached. So far, tests are ok. Just one comment, the 'user-stage' command description is wrong, as it moves an active user into the staged area user-stage Move deleted user into staged area -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 18 14:04:29 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 16:04:29 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D33804.6000201@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> Message-ID: <55D33B6D.7050701@redhat.com> On 08/18/2015 03:49 PM, thierry bordaz wrote: > On 08/18/2015 03:06 PM, Martin Basti wrote: >> >> >> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> the 'user-stage' command replaces 'stageuser-add --from-delete' >>>>>>>> command. >>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>> >>>>>>>> Thierry can you check If I don't break everything, it works for >>>>>>>> me, but the one never knows. >>>>>>>> >>>>>>>> Honza can you please check the framework side? I use >>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not sure >>>>>>>> if this is right way, but it works. >>>>>>>> >>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>> >>>>>>>> >>>>>>>> Just question at the end: should I implement way Active user -> >>>>>>>> stageuser? IMHO it would be implemented internally by calling >>>>>>>> 'user-del --preserve' inside 'user-stage'. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> There is a small failure with VERSION (edewata pushed his patch >>>>>>> first ;-) ) >>>>>>> >>>>>>> git apply -v >>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>> Checking patch API.txt... >>>>>>> Checking patch VERSION... >>>>>>> error: while searching for: >>>>>>> # # >>>>>>> ######################################################## >>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>> >>>>>>> error: patch failed: VERSION:90 >>>>>>> error: VERSION: patch does not apply >>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>> >>>>>>> >>>>>> There is many pending patches that may change VERSION number, I >>>>>> will change it to right one before push. >>>>>> >>>>>> Does code looks good for you? >>>>> Hi Martin, >>>>> >>>>> Just a question, there is no additional permission. Did you test >>>>> being 'admin' ? >>>>> >>>>> thanks >>>>> theirry >>>> No I didn't,. >>>> >>>> I preserver all permission, the original permissions should work. >>>> >>>> Martin >>> Hi Martin, >>> >>> Running a test script, I have an issue with >>> >>> ipa stageuser-add --first=t --last=b tb1 >>> ipa: ERROR: an internal error has occurred >>> >>> >>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] ipa: >>> INFO: [jsonserver_kerb] stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>> displayname=u't b', initials=u'tb', gecos=u't b', >>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>> random=False, all=False, raw=False, version=u'2.149', >>> no_members=False): AttributeError >>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] ipa: >>> ERROR: non-public: AttributeError: 'DN' object has no attribute >>> 'setdefault' >>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>> Traceback (most recent call last): >>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>> line 347, in wsgi_execute >>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid 10485] >>> result = self.Command[name](*args, **options) >>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>> 443, in __call__ >>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid 10485] >>> ret = self.run(*args, **options) >>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>> 760, in run >>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid 10485] >>> return self.execute(*args, **options) >>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>> File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>> line 1227, in execute >>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid 10485] >>> *keys, **options) >>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>> File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>> line 373, in pre_callback >>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid 10485] >>> attrs_list, *keys, **options) >>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>> File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>> line 277, in set_default_values_pre_callback >>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>> entry_attrs.setdefault('description', []) >>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>> AttributeError: 'DN' object has no attribute 'setdefault' >>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] ipa: >>> INFO: [jsonserver_session] >>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', >>> givenname=u't', sn=u'b', cn=u't b', displayname=u't b', >>> initials=u'tb', gecos=u't b', >>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>> random=False, all=False, raw=False, version=u'2.149', >>> no_members=False): AttributeError >>> >>> >>> The new set_default_values_pre_callback, can not use the set_default >>> function. It is not clear why. entry_attrs is one of pre_callback >>> parameter. >>> Should set_default_values_pre_callback be a subfonction of >>> pre_callback ? >>> >>> >>> thanks >>> thierry >> >> Thank you, >> >> updated patch attached. > > So far, tests are ok. > Just one comment, the 'user-stage' command description is wrong, as it > moves an active user into the staged area > > user-stage Move deleted user into staged area No, it's not doing that. user-stage is replacement of stageuser-add --from-delete, it doesn't work for active users. The support to move active user to staged area is RFE, I did not implemented it yet, and I dont know if this will fit IPA 4.2 timeframe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkubik at redhat.com Tue Aug 18 14:06:42 2015 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 18 Aug 2015 16:06:42 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> Message-ID: <55D33BF2.2060307@redhat.com> On 08/11/2015 03:17 AM, Fraser Tweedale wrote: > On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: >> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>> Hi list, >>> >>> I'm sending the test plan [1] for certificate profiles and preliminary >>> patches for it. >>> The plan covers basic CRUD test and some corner cases. I'm open to more >>> suggestions. >>> >>> More complicated tests involving certificate profiles will require the >>> code (and tests) >>> for CA ACLs merged, so it's not there at the moment. >>> >>> There are some unfinished test cases in places I wasn't sure what the >>> result should be. >>> We need to iterate through these to fix it. >>> >>> >>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>> >>> Cheers, >>> Milan >> Hi all, >> >> have you had some time to look at the code and proposal? >> Today I want to write a basic CRUD test for the ACLs as well as a few test >> cases to check if the ACL is being enforced. It should make it into wiki >> today or by tomorrow. I'll send an update then. >> >> Cheers, >> Milan >> > Hi Milan, > > I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of > comments: > > - Test case: Import profile with incorrect values > - Expected result: refused with error. > - A simple way to provoke this condition is to add a number to > ``policyset.serverCertSet.list``. > - A similar test case should exist for certprofile-mod. > > - Test case: Delete default profile > - As discussed elsewhere, expected result should be failure. > I filed ticket #5198 to make it so :) > > I will review the patch soon. > > Cheers, > Fraser Hello, how is the review going? I'd like to have at least the tracker (patch 0008) reviewed (and merged :) if possible. It will be needed in CA ACL tests. Cheers, Milan From tbordaz at redhat.com Tue Aug 18 14:13:21 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 18 Aug 2015 16:13:21 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D33B6D.7050701@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> Message-ID: <55D33D81.301@redhat.com> On 08/18/2015 04:04 PM, Martin Basti wrote: > > > On 08/18/2015 03:49 PM, thierry bordaz wrote: >> On 08/18/2015 03:06 PM, Martin Basti wrote: >>> >>> >>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>> --from-delete' command. >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>> >>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>> for me, but the one never knows. >>>>>>>>> >>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not sure >>>>>>>>> if this is right way, but it works. >>>>>>>>> >>>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>>> >>>>>>>>> >>>>>>>>> Just question at the end: should I implement way Active user >>>>>>>>> -> stageuser? IMHO it would be implemented internally by >>>>>>>>> calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> There is a small failure with VERSION (edewata pushed his patch >>>>>>>> first ;-) ) >>>>>>>> >>>>>>>> git apply -v >>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>> Checking patch API.txt... >>>>>>>> Checking patch VERSION... >>>>>>>> error: while searching for: >>>>>>>> # # >>>>>>>> ######################################################## >>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>> >>>>>>>> error: patch failed: VERSION:90 >>>>>>>> error: VERSION: patch does not apply >>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>> >>>>>>>> >>>>>>> There is many pending patches that may change VERSION number, I >>>>>>> will change it to right one before push. >>>>>>> >>>>>>> Does code looks good for you? >>>>>> Hi Martin, >>>>>> >>>>>> Just a question, there is no additional permission. Did you test >>>>>> being 'admin' ? >>>>>> >>>>>> thanks >>>>>> theirry >>>>> No I didn't,. >>>>> >>>>> I preserver all permission, the original permissions should work. >>>>> >>>>> Martin >>>> Hi Martin, >>>> >>>> Running a test script, I have an issue with >>>> >>>> ipa stageuser-add --first=t --last=b tb1 >>>> ipa: ERROR: an internal error has occurred >>>> >>>> >>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] ipa: >>>> INFO: [jsonserver_kerb] >>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', >>>> givenname=u't', sn=u'b', cn=u't b', displayname=u't b', >>>> initials=u'tb', gecos=u't b', >>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>> random=False, all=False, raw=False, version=u'2.149', >>>> no_members=False): AttributeError >>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] ipa: >>>> ERROR: non-public: AttributeError: 'DN' object has no attribute >>>> 'setdefault' >>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>> Traceback (most recent call last): >>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>> line 347, in wsgi_execute >>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid 10485] >>>> result = self.Command[name](*args, **options) >>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>> line 443, in __call__ >>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid 10485] >>>> ret = self.run(*args, **options) >>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>> line 760, in run >>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid 10485] >>>> return self.execute(*args, **options) >>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>> File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>> line 1227, in execute >>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid 10485] >>>> *keys, **options) >>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>> File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>> line 373, in pre_callback >>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid 10485] >>>> attrs_list, *keys, **options) >>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>> File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>> line 277, in set_default_values_pre_callback >>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>> entry_attrs.setdefault('description', []) >>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] ipa: >>>> INFO: [jsonserver_session] >>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', >>>> givenname=u't', sn=u'b', cn=u't b', displayname=u't b', >>>> initials=u'tb', gecos=u't b', >>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>> random=False, all=False, raw=False, version=u'2.149', >>>> no_members=False): AttributeError >>>> >>>> >>>> The new set_default_values_pre_callback, can not use the >>>> set_default function. It is not clear why. entry_attrs is one of >>>> pre_callback parameter. >>>> Should set_default_values_pre_callback be a subfonction of >>>> pre_callback ? >>>> >>>> >>>> thanks >>>> thierry >>> >>> Thank you, >>> >>> updated patch attached. >> >> So far, tests are ok. >> Just one comment, the 'user-stage' command description is wrong, as >> it moves an active user into the staged area >> >> user-stage Move deleted user into staged area > No, it's not doing that. > > user-stage is replacement of stageuser-add --from-delete, it doesn't > work for active users. > The support to move active user to staged area is RFE, I did not > implemented it yet, and I dont know if this will fit IPA 4.2 timeframe Ok. thanks. Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. Running the tests being admin, there is no problem. I have a permission issue, when running as 'Stage administrator'. The 'delete' entry being moved to 'stage' container, we need the a special permission for it. [root at vm-141 ~]# ipa user-del ttest1 --preserve --------------------- Deleted user "ttest1" --------------------- [root at vm-141 ~]# ipa user-stage ttest1 ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to move an entry to 'cn=staged users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. [root at vm-141 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM Valid starting Expires Service principal 08/18/2015 15:45:43 08/19/2015 15:45:42 ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM 08/18/2015 15:45:42 08/19/2015 15:45:42 krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM [root at vm-141 ~]# kinit admin Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: [root at vm-141 ~]# ipa user-stage ttest1 ---------------------------- Staged user account "ttest1" ---------------------------- [root at vm-141 ~]# ipa stageuser-find ttest1 -------------- 1 user matched -------------- User login: ttest1 First name: t Last name: test1 Home directory: /home/ttest1 Login shell: /bin/sh Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com UID: 1814000011 GID: 1814000011 Password: False Kerberos keys available: False ---------------------------- Number of entries returned 1 ---------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Aug 18 14:24:56 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 16:24:56 +0200 Subject: [Freeipa-devel] [PATCH 474] install: Fix CA-less replica install In-Reply-To: <55D32F4B.9040202@redhat.com> References: <55D30F63.6@redhat.com> <55D32F4B.9040202@redhat.com> Message-ID: <55D34038.1020806@redhat.com> On 18.8.2015 15:12, Martin Babinsky wrote: > On 08/18/2015 12:56 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK > Thanks. The commit message was not correct so I fixed it. Pushed to: master: ff1e66375c8fd7ac036220b0f6d5cf206fa36a6a ipa-4-2: bfe937715236e71037f05885293afb3d1c8d2227 -- Jan Cholasta From tbordaz at redhat.com Tue Aug 18 15:34:47 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 18 Aug 2015 17:34:47 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D33D81.301@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> Message-ID: <55D35097.6010902@redhat.com> On 08/18/2015 04:13 PM, thierry bordaz wrote: > On 08/18/2015 04:04 PM, Martin Basti wrote: >> >> >> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>> --from-delete' command. >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>> >>>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>>> for me, but the one never knows. >>>>>>>>>> >>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not sure >>>>>>>>>> if this is right way, but it works. >>>>>>>>>> >>>>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just question at the end: should I implement way Active user >>>>>>>>>> -> stageuser? IMHO it would be implemented internally by >>>>>>>>>> calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>> patch first ;-) ) >>>>>>>>> >>>>>>>>> git apply -v >>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>> Checking patch API.txt... >>>>>>>>> Checking patch VERSION... >>>>>>>>> error: while searching for: >>>>>>>>> # # >>>>>>>>> ######################################################## >>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>>> >>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>> error: VERSION: patch does not apply >>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>> >>>>>>>>> >>>>>>>> There is many pending patches that may change VERSION number, I >>>>>>>> will change it to right one before push. >>>>>>>> >>>>>>>> Does code looks good for you? >>>>>>> Hi Martin, >>>>>>> >>>>>>> Just a question, there is no additional permission. Did you test >>>>>>> being 'admin' ? >>>>>>> >>>>>>> thanks >>>>>>> theirry >>>>>> No I didn't,. >>>>>> >>>>>> I preserver all permission, the original permissions should work. >>>>>> >>>>>> Martin >>>>> Hi Martin, >>>>> >>>>> Running a test script, I have an issue with >>>>> >>>>> ipa stageuser-add --first=t --last=b tb1 >>>>> ipa: ERROR: an internal error has occurred >>>>> >>>>> >>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>> ipa: INFO: [jsonserver_kerb] >>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', >>>>> givenname=u't', sn=u'b', cn=u't b', displayname=u't b', >>>>> initials=u'tb', gecos=u't b', >>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>> random=False, all=False, raw=False, version=u'2.149', >>>>> no_members=False): AttributeError >>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>> attribute 'setdefault' >>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>> Traceback (most recent call last): >>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>> line 347, in wsgi_execute >>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid 10485] >>>>> result = self.Command[name](*args, **options) >>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>> line 443, in __call__ >>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid 10485] >>>>> ret = self.run(*args, **options) >>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>> line 760, in run >>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid 10485] >>>>> return self.execute(*args, **options) >>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>> line 1227, in execute >>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid 10485] >>>>> *keys, **options) >>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", line >>>>> 373, in pre_callback >>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid 10485] >>>>> attrs_list, *keys, **options) >>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", line >>>>> 277, in set_default_values_pre_callback >>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>> entry_attrs.setdefault('description', []) >>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>> ipa: INFO: [jsonserver_session] >>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: stageuser_add(u'tb1', >>>>> givenname=u't', sn=u'b', cn=u't b', displayname=u't b', >>>>> initials=u'tb', gecos=u't b', >>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>> random=False, all=False, raw=False, version=u'2.149', >>>>> no_members=False): AttributeError >>>>> >>>>> >>>>> The new set_default_values_pre_callback, can not use the >>>>> set_default function. It is not clear why. entry_attrs is one of >>>>> pre_callback parameter. >>>>> Should set_default_values_pre_callback be a subfonction of >>>>> pre_callback ? >>>>> >>>>> >>>>> thanks >>>>> thierry >>>> >>>> Thank you, >>>> >>>> updated patch attached. >>> >>> So far, tests are ok. >>> Just one comment, the 'user-stage' command description is wrong, as >>> it moves an active user into the staged area >>> >>> user-stage Move deleted user into staged >>> area >> No, it's not doing that. >> >> user-stage is replacement of stageuser-add --from-delete, it doesn't >> work for active users. >> The support to move active user to staged area is RFE, I did not >> implemented it yet, and I dont know if this will fit IPA 4.2 timeframe > Ok. thanks. > Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. > > Running the tests being admin, there is no problem. > I have a permission issue, when running as 'Stage administrator'. The > 'delete' entry being moved to 'stage' container, we need the a special > permission for it. Hello, I tested this new permission to grant 'Stage user administrator' to do a 'user-stage'. Is it ok to add it to your patch ? thanks thierry > > [root at vm-141 ~]# ipa user-del ttest1 --preserve > --------------------- > Deleted user "ttest1" > --------------------- > > [root at vm-141 ~]# ipa user-stage ttest1 > ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to > move an entry to 'cn=staged > users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. > > [root at vm-141 ~]# klist > Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 > Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM > > Valid starting Expires Service principal > 08/18/2015 15:45:43 08/19/2015 15:45:42 > ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM > 08/18/2015 15:45:42 08/19/2015 15:45:42 > krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM > > [root at vm-141 ~]# kinit admin > Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: > [root at vm-141 ~]# ipa user-stage ttest1 > ---------------------------- > Staged user account "ttest1" > ---------------------------- > [root at vm-141 ~]# ipa stageuser-find ttest1 > -------------- > 1 user matched > -------------- > User login: ttest1 > First name: t > Last name: test1 > Home directory: /home/ttest1 > Login shell: /bin/sh > Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com > UID: 1814000011 > GID: 1814000011 > Password: False > Kerberos keys available: False > ---------------------------- > Number of entries returned 1 > ---------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-permission-for-user-stage.patch Type: text/x-patch Size: 3063 bytes Desc: not available URL: From tbabej at redhat.com Tue Aug 18 16:00:55 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 18 Aug 2015 18:00:55 +0200 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <20150818095653.GW22106@redhat.com> References: <20150813142943.GF22106@redhat.com> <55D185B5.1050704@redhat.com> <20150817070340.GN22106@redhat.com> <55D19B63.8020600@redhat.com> <20150818085252.GU22106@redhat.com> <20150818095653.GW22106@redhat.com> Message-ID: <55D356B7.7040708@redhat.com> On 08/18/2015 11:56 AM, Alexander Bokovoy wrote: > On Tue, 18 Aug 2015, Alexander Bokovoy wrote: >> On Mon, 17 Aug 2015, Tomas Babej wrote: >>> >>> >>> On 08/17/2015 09:03 AM, Alexander Bokovoy wrote: >>>> On Mon, 17 Aug 2015, Tomas Babej wrote: >>>>> >>>>> >>>>> On 08/13/2015 04:29 PM, Alexander Bokovoy wrote: >>>>>> Hi, >>>>>> >>>>>> see commit message for details. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> code-wise this looks good to me. Unfortunately, I have not been >>>>> able to >>>>> verify in my setup that it fixes the issue in the linked BZ: >>>>> >>>>> $ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type >>>>> ipa-ad-trust --admin Administrator --password >>>>> ------------------------------------------------ >>>>> Added Active Directory trust for realm "ad.test" >>>>> ------------------------------------------------ >>>>> Realm name: ad.test >>>>> Domain NetBIOS name: AD >>>>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>>>> SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>>>> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>>>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>>>> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>>>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>>>> SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>>>> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>>>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>>>> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>>>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>>>> Trust direction: Trusting forest >>>>> Trust type: Active Directory domain >>>>> Trust status: Established and verified >>>>> >>>>> $ idrange-find >>>>> >>>>> ---------------- >>>>> 2 ranges matched >>>>> ---------------- >>>>> Range name: AD.TEST_id_range >>>>> First Posix ID of the range: 191200000 >>>>> Number of IDs in the range: 200000 >>>>> First RID of the corresponding RID range: 0 >>>>> Domain SID of the trusted domain: >>>>> S-1-5-21-1469936554-2294197481-461507924 >>>>> Range type: Active Directory domain range >>>>> >>>>> Range name: IPA.TEST_id_range >>>>> First Posix ID of the range: 695200000 >>>>> Number of IDs in the range: 200000 >>>>> First RID of the corresponding RID range: 1000 >>>>> First RID of the secondary RID range: 100000000 >>>>> Range type: local domain range >>>>> ---------------------------- >>>>> Number of entries returned 2 >>>>> ---------------------------- >>>>> >>>>> However, I have one child subdomain in the setup: >>>>> >>>>> $ ipa trustdomain-find >>>>> Realm name: ad.test >>>>> Domain name: ad.test >>>>> Domain NetBIOS name: AD >>>>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>>>> Domain enabled: True >>>>> >>>>> Domain name: sub.ad.test >>>>> Domain NetBIOS name: SUB >>>>> Domain Security Identifier: S-1-5-21-10134726-2575992721-4229914074 >>>>> Domain enabled: True >>>>> ---------------------------- >>>>> Number of entries returned 2 >>>>> ---------------------------- >>>> Look for AVCs, if there are any. >>>> >>>> Also start abrtd and it should pick up any python exceptions in the >>>> helper as 'crashes'. >>>> >>> >>> Right. Insufficient LDAP permissions caused the following backtrace in >>> the oddjob helper: >>> >>> ipaldap.py:948:error_handler:ACIError: Insufficient access: Insufficient >>> 'add' privilege to add the entry >>> 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. >>> >>> Traceback (most recent call last): >>> File "/usr/libexec/ipa/com.redhat.idm.trust-fetch-domains", line 216, >>> in >>> trusted_domain, name, **dom) >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >>> 347, in add_range >>> ipanttrusteddomainsid=dom_sid) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, >>> in __call__ >>> ret = self.run(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, >>> in run >>> return self.execute(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>> line 1234, in execute >>> self._exc_wrapper(keys, options, ldap.add_entry)(entry_attrs) >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>> line 1145, in wrapped >>> return func(*call_args, **call_kwargs) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1442, in add_entry >>> self.conn.add_s(str(entry.dn), attrs.items()) >>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>> self.gen.throw(type, value, traceback) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 948, in error_handler >>> raise errors.ACIError(info=info) >>> ACIError: Insufficient access: Insufficient 'add' privilege to add the >>> entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. >>> >>> Local variables in innermost frame: >>> info: "Insufficient 'add' privilege to add the entry >>> 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'." >>> arg_desc: None >>> self: ipaserver.plugins.ldap2.ldap2() >>> e: INSUFFICIENT_ACCESS({'info': "Insufficient 'add' privilege to add the >>> entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'.\n", >>> 'desc': 'Insufficient access'},) >>> desc: 'Insufficient access' >> Updated patch attached. >> >> You can install freeipa from my COPR abbra/freeipa-oneway (you need >> mkosek/freeipa-master COPR for dependencies) to test. > .. and use abbra/sssd-kkdcproxy for sssd git master -- you'll need it to > allow SSSD to properly handle keytabs chowned to sssd:sssd by the > helper. > > With abbra/freeipa-oneway, abbra/sssd-kkdcproxy, mkosek/freeipa-master > COPR repos I get child AD domains working correctly with one-way trust. > > This works as expected, ID range for subdomain is added. $ ipa trust-add --type=ad ad.test --range-type ipa-ad-trust --admin Administrator --password ------------------------------------------------ Added Active Directory trust for realm "ad.test" ------------------------------------------------ Realm name: ad.test Domain NetBIOS name: AD ... Trust direction: Trusting forest Trust type: Active Directory domain Trust status: Established and verified $ ipa idrange-find ---------------- 3 ranges matched ---------------- Range name: AD.TEST_id_range ... Range type: Active Directory domain range Range name: IPA.TEST_id_range ... Range type: local domain range Range name: SUB.AD.TEST_id_range ... Range type: Active Directory domain range ---------------------------- Number of entries returned 3 ---------------------------- ACK Tomas From mbabinsk at redhat.com Tue Aug 18 16:41:38 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 18 Aug 2015 18:41:38 +0200 Subject: [Freeipa-devel] [PATCH 0059] improve the handling of krb5-related errors in dnssec daemons Message-ID: <55D36042.4020101@redhat.com> This patch fixes https://fedorahosted.org/freeipa/ticket/5229 and also improves the handling of Kerberos errors in other DNSSEC daemons. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0059-improve-the-handling-of-krb5-related-errors-in-dnsse.patch Type: text/x-patch Size: 3532 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 18 16:49:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 18:49:12 +0200 Subject: [Freeipa-devel] [PATCH] 0195 harden trust-fetch-domains oddjobd script In-Reply-To: <55D356B7.7040708@redhat.com> References: <20150813142943.GF22106@redhat.com> <55D185B5.1050704@redhat.com> <20150817070340.GN22106@redhat.com> <55D19B63.8020600@redhat.com> <20150818085252.GU22106@redhat.com> <20150818095653.GW22106@redhat.com> <55D356B7.7040708@redhat.com> Message-ID: <55D36208.5080803@redhat.com> On 08/18/2015 06:00 PM, Tomas Babej wrote: > > On 08/18/2015 11:56 AM, Alexander Bokovoy wrote: >> On Tue, 18 Aug 2015, Alexander Bokovoy wrote: >>> On Mon, 17 Aug 2015, Tomas Babej wrote: >>>> >>>> On 08/17/2015 09:03 AM, Alexander Bokovoy wrote: >>>>> On Mon, 17 Aug 2015, Tomas Babej wrote: >>>>>> >>>>>> On 08/13/2015 04:29 PM, Alexander Bokovoy wrote: >>>>>>> Hi, >>>>>>> >>>>>>> see commit message for details. >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi, >>>>>> >>>>>> code-wise this looks good to me. Unfortunately, I have not been >>>>>> able to >>>>>> verify in my setup that it fixes the issue in the linked BZ: >>>>>> >>>>>> $ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type >>>>>> ipa-ad-trust --admin Administrator --password >>>>>> ------------------------------------------------ >>>>>> Added Active Directory trust for realm "ad.test" >>>>>> ------------------------------------------------ >>>>>> Realm name: ad.test >>>>>> Domain NetBIOS name: AD >>>>>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>>>>> SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>>>>> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>>>>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>>>>> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>>>>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>>>>> SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, >>>>>> S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, >>>>>> S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, >>>>>> S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, >>>>>> S-1-1, S-1-0, S-1-5-19, S-1-5-18 >>>>>> Trust direction: Trusting forest >>>>>> Trust type: Active Directory domain >>>>>> Trust status: Established and verified >>>>>> >>>>>> $ idrange-find >>>>>> >>>>>> ---------------- >>>>>> 2 ranges matched >>>>>> ---------------- >>>>>> Range name: AD.TEST_id_range >>>>>> First Posix ID of the range: 191200000 >>>>>> Number of IDs in the range: 200000 >>>>>> First RID of the corresponding RID range: 0 >>>>>> Domain SID of the trusted domain: >>>>>> S-1-5-21-1469936554-2294197481-461507924 >>>>>> Range type: Active Directory domain range >>>>>> >>>>>> Range name: IPA.TEST_id_range >>>>>> First Posix ID of the range: 695200000 >>>>>> Number of IDs in the range: 200000 >>>>>> First RID of the corresponding RID range: 1000 >>>>>> First RID of the secondary RID range: 100000000 >>>>>> Range type: local domain range >>>>>> ---------------------------- >>>>>> Number of entries returned 2 >>>>>> ---------------------------- >>>>>> >>>>>> However, I have one child subdomain in the setup: >>>>>> >>>>>> $ ipa trustdomain-find >>>>>> Realm name: ad.test >>>>>> Domain name: ad.test >>>>>> Domain NetBIOS name: AD >>>>>> Domain Security Identifier: S-1-5-21-1469936554-2294197481-461507924 >>>>>> Domain enabled: True >>>>>> >>>>>> Domain name: sub.ad.test >>>>>> Domain NetBIOS name: SUB >>>>>> Domain Security Identifier: S-1-5-21-10134726-2575992721-4229914074 >>>>>> Domain enabled: True >>>>>> ---------------------------- >>>>>> Number of entries returned 2 >>>>>> ---------------------------- >>>>> Look for AVCs, if there are any. >>>>> >>>>> Also start abrtd and it should pick up any python exceptions in the >>>>> helper as 'crashes'. >>>>> >>>> Right. Insufficient LDAP permissions caused the following backtrace in >>>> the oddjob helper: >>>> >>>> ipaldap.py:948:error_handler:ACIError: Insufficient access: Insufficient >>>> 'add' privilege to add the entry >>>> 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. >>>> >>>> Traceback (most recent call last): >>>> File "/usr/libexec/ipa/com.redhat.idm.trust-fetch-domains", line 216, >>>> in >>>> trusted_domain, name, **dom) >>>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >>>> 347, in add_range >>>> ipanttrusteddomainsid=dom_sid) >>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, >>>> in __call__ >>>> ret = self.run(*args, **options) >>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 760, >>>> in run >>>> return self.execute(*args, **options) >>>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>> line 1234, in execute >>>> self._exc_wrapper(keys, options, ldap.add_entry)(entry_attrs) >>>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>> line 1145, in wrapped >>>> return func(*call_args, **call_kwargs) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1442, in add_entry >>>> self.conn.add_s(str(entry.dn), attrs.items()) >>>> File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ >>>> self.gen.throw(type, value, traceback) >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 948, in error_handler >>>> raise errors.ACIError(info=info) >>>> ACIError: Insufficient access: Insufficient 'add' privilege to add the >>>> entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'. >>>> >>>> Local variables in innermost frame: >>>> info: "Insufficient 'add' privilege to add the entry >>>> 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'." >>>> arg_desc: None >>>> self: ipaserver.plugins.ldap2.ldap2() >>>> e: INSUFFICIENT_ACCESS({'info': "Insufficient 'add' privilege to add the >>>> entry 'cn=SUB.AD.TEST_id_range,cn=ranges,cn=etc,dc=ipa,dc=test'.\n", >>>> 'desc': 'Insufficient access'},) >>>> desc: 'Insufficient access' >>> Updated patch attached. >>> >>> You can install freeipa from my COPR abbra/freeipa-oneway (you need >>> mkosek/freeipa-master COPR for dependencies) to test. >> .. and use abbra/sssd-kkdcproxy for sssd git master -- you'll need it to >> allow SSSD to properly handle keytabs chowned to sssd:sssd by the >> helper. >> >> With abbra/freeipa-oneway, abbra/sssd-kkdcproxy, mkosek/freeipa-master >> COPR repos I get child AD domains working correctly with one-way trust. >> >> > This works as expected, ID range for subdomain is added. > > $ ipa trust-add --type=ad ad.test --range-type ipa-ad-trust --admin > Administrator --password > ------------------------------------------------ > Added Active Directory trust for realm "ad.test" > ------------------------------------------------ > Realm name: ad.test > Domain NetBIOS name: AD > ... > Trust direction: Trusting forest > Trust type: Active Directory domain > Trust status: Established and verified > > $ ipa idrange-find > ---------------- > 3 ranges matched > ---------------- > Range name: AD.TEST_id_range > ... > Range type: Active Directory domain range > > Range name: IPA.TEST_id_range > ... > Range type: local domain range > > Range name: SUB.AD.TEST_id_range > ... > Range type: Active Directory domain range > ---------------------------- > Number of entries returned 3 > ---------------------------- > > > ACK > > > Tomas > Pushed to: master: 3692a1c57f5d404a61a01623ef732234ccbbdffd ipa-4-2: c30baa9bb9dfa5a5de7685e9203f3eae95dec22a From mbasti at redhat.com Tue Aug 18 17:05:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 19:05:19 +0200 Subject: [Freeipa-devel] [PATCH 0298] Server Upgrade: start DS before CA is started Message-ID: <55D365CF.7000508@redhat.com> https://fedorahosted.org/freeipa/ticket/5232 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0298-Server-Upgrade-Start-DS-before-CA-is-started.patch Type: text/x-patch Size: 2126 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 18 17:14:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 19:14:46 +0200 Subject: [Freeipa-devel] [PATCH 0298] Server Upgrade: start DS before CA is started In-Reply-To: <55D365CF.7000508@redhat.com> References: <55D365CF.7000508@redhat.com> Message-ID: <55D36806.4030608@redhat.com> On 08/18/2015 07:05 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5232 > > Patch attached. > > Self-NACK, I sent wrong patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Aug 18 17:21:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 19:21:08 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D35097.6010902@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> Message-ID: <55D36984.4010203@redhat.com> Thank you for the patch, I checked it, I just changed permission name to have all first letters in uppercase as others. Updated merged patch attached. On 08/18/2015 05:34 PM, thierry bordaz wrote: > On 08/18/2015 04:13 PM, thierry bordaz wrote: >> On 08/18/2015 04:04 PM, Martin Basti wrote: >>> >>> >>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>> --from-delete' command. >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>> >>>>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>> >>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>> >>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Just question at the end: should I implement way Active user >>>>>>>>>>> -> stageuser? IMHO it would be implemented internally by >>>>>>>>>>> calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>> patch first ;-) ) >>>>>>>>>> >>>>>>>>>> git apply -v >>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>> Checking patch API.txt... >>>>>>>>>> Checking patch VERSION... >>>>>>>>>> error: while searching for: >>>>>>>>>> # # >>>>>>>>>> ######################################################## >>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>>>> >>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>> >>>>>>>>>> >>>>>>>>> There is many pending patches that may change VERSION number, >>>>>>>>> I will change it to right one before push. >>>>>>>>> >>>>>>>>> Does code looks good for you? >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>> test being 'admin' ? >>>>>>>> >>>>>>>> thanks >>>>>>>> theirry >>>>>>> No I didn't,. >>>>>>> >>>>>>> I preserver all permission, the original permissions should work. >>>>>>> >>>>>>> Martin >>>>>> Hi Martin, >>>>>> >>>>>> Running a test script, I have an issue with >>>>>> >>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>> ipa: ERROR: an internal error has occurred >>>>>> >>>>>> >>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>>> ipa: INFO: [jsonserver_kerb] >>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>> no_members=False): AttributeError >>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>>> attribute 'setdefault' >>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>>> Traceback (most recent call last): >>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>> line 347, in wsgi_execute >>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>> 10485] result = self.Command[name](*args, **options) >>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>> line 443, in __call__ >>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>> 10485] ret = self.run(*args, **options) >>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>> line 760, in run >>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>> 10485] return self.execute(*args, **options) >>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line >>>>>> 1227, in execute >>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>> 10485] *keys, **options) >>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>> line 373, in pre_callback >>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>> 10485] attrs_list, *keys, **options) >>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>> line 277, in set_default_values_pre_callback >>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>>> entry_attrs.setdefault('description', []) >>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>>> ipa: INFO: [jsonserver_session] >>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>> no_members=False): AttributeError >>>>>> >>>>>> >>>>>> The new set_default_values_pre_callback, can not use the >>>>>> set_default function. It is not clear why. entry_attrs is one of >>>>>> pre_callback parameter. >>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>> pre_callback ? >>>>>> >>>>>> >>>>>> thanks >>>>>> thierry >>>>> >>>>> Thank you, >>>>> >>>>> updated patch attached. >>>> >>>> So far, tests are ok. >>>> Just one comment, the 'user-stage' command description is wrong, as >>>> it moves an active user into the staged area >>>> >>>> user-stage Move deleted user into >>>> staged area >>> No, it's not doing that. >>> >>> user-stage is replacement of stageuser-add --from-delete, it doesn't >>> work for active users. >>> The support to move active user to staged area is RFE, I did not >>> implemented it yet, and I dont know if this will fit IPA 4.2 timeframe >> Ok. thanks. >> Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. >> >> Running the tests being admin, there is no problem. >> I have a permission issue, when running as 'Stage administrator'. The >> 'delete' entry being moved to 'stage' container, we need the a >> special permission for it. > > Hello, > > I tested this new permission to grant 'Stage user administrator' to > do a 'user-stage'. > Is it ok to add it to your patch ? > > thanks > thierry >> >> [root at vm-141 ~]# ipa user-del ttest1 --preserve >> --------------------- >> Deleted user "ttest1" >> --------------------- >> >> [root at vm-141 ~]# ipa user-stage ttest1 >> ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to >> move an entry to 'cn=staged >> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >> >> [root at vm-141 ~]# klist >> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >> >> Valid starting Expires Service principal >> 08/18/2015 15:45:43 08/19/2015 15:45:42 >> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >> 08/18/2015 15:45:42 08/19/2015 15:45:42 >> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >> >> [root at vm-141 ~]# kinit admin >> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >> [root at vm-141 ~]# ipa user-stage ttest1 >> ---------------------------- >> Staged user account "ttest1" >> ---------------------------- >> [root at vm-141 ~]# ipa stageuser-find ttest1 >> -------------- >> 1 user matched >> -------------- >> User login: ttest1 >> First name: t >> Last name: test1 >> Home directory: /home/ttest1 >> Login shell: /bin/sh >> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >> UID: 1814000011 >> GID: 1814000011 >> Password: False >> Kerberos keys available: False >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0297.3-Add-user-stage-command.patch Type: text/x-patch Size: 21626 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 18 17:21:31 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Aug 2015 20:21:31 +0300 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <1439820377.4823.12.camel@redhat.com> References: <55C8C68A.1010606@redhat.com> <1439820377.4823.12.camel@redhat.com> Message-ID: <20150818172131.GF22106@redhat.com> On Mon, 17 Aug 2015, Nathaniel McCallum wrote: >On Mon, 2015-08-10 at 17:43 +0200, Milan Kub?k wrote: >> Hi all, >> >> this patch fixes problem described in the ticket [1] >> that caused the test run to fail completely at every other or so run. >> I took the liberty to fix most of the pep8 issues while I was at it. >> >> Thanks to Jan Cholasta for help with identifying this one. >> >> [1]: https://fedorahosted.org/freeipa/ticket/5192 > >I think the right answer is to move this to python-cryptography. > >We already have python-cryptography as a dependency. And in this case >the crypto code is pretty well self-contained. Aside from nss database >initialization, nss is only used in: >* convertAlgorithm() (constants only) >* XMLDecryptor (actual decryption code) > >The migration should be straightforward. It is probably a 1 day task. I >could probably tackle it later this week. > >Should we do this? I think we should -- for FreeIPA 4.3 or 4.4. -- / Alexander Bokovoy From mbasti at redhat.com Tue Aug 18 17:22:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 19:22:13 +0200 Subject: [Freeipa-devel] [PATCH 0298] Server Upgrade: start DS before CA is started In-Reply-To: <55D36806.4030608@redhat.com> References: <55D365CF.7000508@redhat.com> <55D36806.4030608@redhat.com> Message-ID: <55D369C5.5050404@redhat.com> On 08/18/2015 07:14 PM, Martin Basti wrote: > > > On 08/18/2015 07:05 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5232 >> >> Patch attached. >> >> > Self-NACK, I sent wrong patch > > The correct patch attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0298.2-Server-Upgrade-Start-DS-before-CA-is-started.patch Type: text/x-patch Size: 2093 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 18 17:28:40 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 19:28:40 +0200 Subject: [Freeipa-devel] [PATCH 0060] user-undel: Fix error messages. In-Reply-To: <55D1E41C.9020304@redhat.com> References: <55CC3660.70205@redhat.com> <55CE06AF.6060607@redhat.com> <55D1E41C.9020304@redhat.com> Message-ID: <55D36B48.5090001@redhat.com> On 08/17/2015 03:39 PM, David Kupka wrote: > On 14/08/15 17:18, Martin Basti wrote: >> >> >> On 08/13/2015 08:17 AM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/5207 >>> >>> Requires patch freeipa-jcholast-471.1. >>> >>> >> >> NACK >> >> This patch causes internal server error >> >> ipa user-del user --preserve >> >> [Fri Aug 14 17:16:13.691565 2015] [wsgi:error] [pid 3210] ipa: ERROR: >> non-public: TypeError: %d format: a number is required, not str >> [Fri Aug 14 17:16:13.691605 2015] [wsgi:error] [pid 3210] Traceback >> (most recent call last): >> [Fri Aug 14 17:16:13.691610 2015] [wsgi:error] [pid 3210] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 347, in >> wsgi_execute >> [Fri Aug 14 17:16:13.691614 2015] [wsgi:error] [pid 3210] result = >> self.Command[name](*args, **options) >> [Fri Aug 14 17:16:13.691618 2015] [wsgi:error] [pid 3210] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 457, in >> __call__ >> [Fri Aug 14 17:16:13.691622 2015] [wsgi:error] [pid 3210] >> self.validate_output(ret, options['version']) >> [Fri Aug 14 17:16:13.691626 2015] [wsgi:error] [pid 3210] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 950, in >> validate_output >> [Fri Aug 14 17:16:13.691630 2015] [wsgi:error] [pid 3210] >> o.validate(self, value, version) >> [Fri Aug 14 17:16:13.691634 2015] [wsgi:error] [pid 3210] File >> "/usr/lib/python2.7/site-packages/ipalib/output.py", line 151, in >> validate >> [Fri Aug 14 17:16:13.691638 2015] [wsgi:error] [pid 3210] types[0], >> type(value), value)) >> [Fri Aug 14 17:16:13.691642 2015] [wsgi:error] [pid 3210] TypeError: %d >> format: a number is required, not str >> [Fri Aug 14 17:16:13.692063 2015] [wsgi:error] [pid 3210] ipa: INFO: >> [jsonserver_session] admin at EXAMPLE.COM: user_del((u'user',), >> continue=False, preserve=True, version=u'2.148'): TypeError >> (END) >> >> > Thanks for catching this. Updated patch attached. > ACK Pushed to: master: 65b8c622070f61ad01a2a1706564911620b022bc ipa-4-2: 6005dfb5857af5ae46efd2984b06a9a35efb7917 From mbasti at redhat.com Tue Aug 18 17:45:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 19:45:14 +0200 Subject: [Freeipa-devel] [PATCH] 0039 Prohibit deletion of included profiles In-Reply-To: <20150813100944.GA16439@dhcp-40-8.bne.redhat.com> References: <20150813063601.GS16439@dhcp-40-8.bne.redhat.com> <20150813065335.GV22106@redhat.com> <20150813075754.GU16439@dhcp-40-8.bne.redhat.com> <20150813090109.GW22106@redhat.com> <20150813092754.GZ16439@dhcp-40-8.bne.redhat.com> <20150813093127.GY22106@redhat.com> <20150813100944.GA16439@dhcp-40-8.bne.redhat.com> Message-ID: <55D36F2A.1050302@redhat.com> On 08/13/2015 12:09 PM, Fraser Tweedale wrote: > On Thu, Aug 13, 2015 at 12:31:27PM +0300, Alexander Bokovoy wrote: >> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >>> On Thu, Aug 13, 2015 at 12:01:09PM +0300, Alexander Bokovoy wrote: >>>> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >>>>> On Thu, Aug 13, 2015 at 09:53:35AM +0300, Alexander Bokovoy wrote: >>>>>> On Thu, 13 Aug 2015, Fraser Tweedale wrote: >>>>>>> The attached patch fixes >>>>>>> https://fedorahosted.org/freeipa/ticket/5198 >>>>>>> >>>>>>> Thanks, >>>>>>> Fraser >>>>>> >From 0dd316bf0cbab7b6701bd69f142e82b30bee25b8 Mon Sep 17 00:00:00 2001 >>>>>>> From: Fraser Tweedale >>>>>>> Date: Thu, 13 Aug 2015 02:32:54 -0400 >>>>>>> Subject: [PATCH] Prohibit deletion of included profiles >>>>>>> >>>>>>> Deletion of included profiles, including the default profile, should >>>>>>> not be allowed. Detect this case and raise an error. >>>>>>> >>>>>>> Also update the included profiles collection to use namedtuple, >>>>>>> making it easier to access the various components. >>>>>>> >>>>>>> Fixes: https://fedorahosted.org/freeipa/ticket/5198 >>>>>>> --- >>>>>>> ipalib/plugins/certprofile.py | 13 +++++++++++-- >>>>>>> ipapython/dogtag.py | 8 +++++--- >>>>>>> 2 files changed, 16 insertions(+), 5 deletions(-) >>>>>>> >>>>>>> diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py >>>>>>> index 1dd4f403ee4461b83c053eb36019a8896506bb81..03bdd28728dc864adcd7305ddbff34a23405e78f 100644 >>>>>>> --- a/ipalib/plugins/certprofile.py >>>>>>> +++ b/ipalib/plugins/certprofile.py >>>>>>> @@ -3,6 +3,7 @@ >>>>>>> # >>>>>>> >>>>>>> import re >>>>>>> +from operator import attrgetter >>>>>>> >>>>>> >from ipalib import api, Bool, File, Str >>>>>> >from ipalib import output, util >>>>>>> @@ -14,6 +15,7 @@ from ipalib.plugins.baseldap import ( >>>>>> >from ipalib.request import context >>>>>> >from ipalib import ngettext >>>>>> >from ipalib.text import _ >>>>>>> +from ipapython.dogtag import INCLUDED_PROFILES >>>>>> >from ipapython.version import API_VERSION >>>>>> >from ipalib import errors >>>>>>> @@ -287,9 +289,16 @@ class certprofile_del(LDAPDelete): >>>>>>> __doc__ = _("Delete a Certificate Profile.") >>>>>>> msg_summary = _('Deleted profile "%(value)s"') >>>>>>> >>>>>>> - def execute(self, *args, **kwargs): >>>>>>> + def pre_callback(self, ldap, dn, *keys, **options): >>>>>>> ca_enabled_check() >>>>>>> - return super(certprofile_del, self).execute(*args, **kwargs) >>>>>>> + >>>>>>> + if keys[0] in map(attrgetter('profile_id'), INCLUDED_PROFILES): >>>>>>> + raise errors.ValidationError(name='profile_id', >>>>>>> + error=_("Included profile '%(profile_id)s' cannot be deleted") >>>>>>> + % {'profile_id': keys[0]} >>>>>>> + ) >>>>>>> + >>>>>>> + return dn >>>>>> I think you also want to protect the included profiles from renaming. >>>>>> >>>>> This is already the case. >>>> I'm also wondering about certprofile-mod changing the profile content >>>> and changing profileID there to point to existing profile. Would this >>>> affect CA operation? >>>> >>> Renaming profile / changing profile-id / pointing it to a different >>> profile is not possible. >>> >>> Changing profile content *is* currently possible. Given that we >>> have custom profiles now, there is an argument to be made that we >>> should prevent profile-mod for updating the Dogtag configuration of >>> predefined profiles. >>> >>> If we did that, we would probably also want to allow admins to >>> change which is the default profile, i.e. changing the default to >>> some custom profile they added. >>> >>> And if we did that, then perhaps we should let them specify a >>> different default profile for users vs hosts/services! >>> >>> How deep does this rabbit hole go? :) >> All the above makes sense and should be done in terms of proper >> hardening and usability fixes. I don't think it is a bottomless hole, >> though, just a normal work we have to do to make certificate profiles >> nice and usable :) >> > Right; I'll file tickets for these explored regions of the hole, and > leave the unexplored depths for another day. > >> -- >> / Alexander Bokovoy Pushed to: ipa-4-2: 9ca156c85919108d0c13718384dc196075364398 master: 27988f1b836874d6b1df0659bc95390636caeb78 From dkupka at redhat.com Tue Aug 18 18:02:49 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 18 Aug 2015 20:02:49 +0200 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <55BBA2ED.4050201@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> Message-ID: <55D37349.8090201@redhat.com> On 31/07/15 18:31, Martin Basti wrote: > On 28/07/15 09:52, David Kupka wrote: >> On 27/07/15 16:45, David Kupka wrote: >>> On 15/01/15 17:13, David Kupka wrote: >>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>> >>>>>>>>> Thank you for patch: >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>> - "Failed to connect to server '%s'.", >>>>>>>>> server) >>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>> + except CalledProcessError as e: >>>>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>>> >>>>>>>>> IMO the error message should be more specific, add there >>>>>>>>> something >>>>>>>>> like >>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>> >>>>>>>>> .replace() is not needed >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> + if len(ips) == 0: >>>>>>>>> >>>>>>>>> if not ips: >>>>>>>>> >>>>>>>>> is more pythonic by PEP8 >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>> >>>>>>> merciful NACK >>>>>>> >>>>>>> Thank you for the patch, unfortunately I hit one issue which needs >>>>>>> to be >>>>>>> resolved. >>>>>>> >>>>>>> If "sync PTR" is activated in zone settings, and reverse zone >>>>>>> doesn't >>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print >>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA records was >>>>>>> succesfully updated, only PTR records failed. >>>>>>> >>>>>>> Bind log: >>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at >>>>>>> 'vm-101.example.com' AAAA >>>>>>> >>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for >>>>>>> A/AAAA >>>>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>> for IP >>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>> >>>>>>> With IPv6 we have several addresses from different reverse zones and >>>>>>> this situation may happen often. >>>>>>> I suggest following: >>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>> fails, >>>>>>> user needs to read log, which addresses installer tried to update) >>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>> there >>>>>>> and print proper error message >>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>> particular >>>>>>> IP address. >>>>>>> >>>>>>> Any other suggestions are welcome. >>>>>>> >>>>>> >>>>>> After long discussion with DNS and UX guru I've implemented it this >>>>>> way: >>>>>> 1. Call nsupdate only once with all updates. >>>>>> 2. Verify that the expected records are resolvable. >>>>>> 3. If no print list of missing A/AAAA, list of missing PTR records >>>>>> and >>>>>> list to mismatched PTR record. >>>>>> >>>>>> As this is running inside client we can't much more and it's up to >>>>>> user >>>>>> to check what's rotten in his DNS setup. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> >>>>> One more change to behave well in -crazy- exotic environments that >>>>> resolves more PTR records for single IP. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> Yet another change to make language nerds and our UX guru happy :-) >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>> Rebased patch attached. >>> >>> >> Updated patch attached. >> > Just for record this patch is for dualstack/IPv6 support. > IMO this ticket also requires to fix ipa-join to support IPv6. > > I still have doubts to have multihomed support as default, this may be > unexpected change of ipa-client-install behavior. > I know, is hard to detect which addresses user want to register in IPA > without crystal ball, but it should not be impossible :-) . > > I propose following solution: > > To add new options: > --multihomed or --all-ip-address - all IP addresses from client will be > used > --ip-address - adress which will be registered on (IPA) DNS server > --ip-address-interface - interface from which address will be registered > > > 0) without any option specified, current behavior will be used + IPv6 > * detect which address is used to communicate with IPA server > * detect interface where this address belongs > * use ipv4 and all ipv6 addresses of this interface > * if --enable-dns-updates=true: configure SSSD as is configured now: > automatically detect which address is used + patched SSSD will also > updates proper IPv6 address > > 1) --multihomed or --all-ip-addresses (this is multihomed ticket) > * all adresses will be used > * if --enable-dns-updates=true: SSSD will be configured to send all > ip_addresses > > 2) --ip-address option specified: > * only specified addresses will be used (+ check if this addresses exist > locally) > * if --enable-dns-updates=true: ERROR dynamic updates may change this > address (user should choose static vs dynamic) > > 3) --ip-address-interface option specified: > * only addresses from specified interfaces will be used > * if --enable-dns-updates=true: SSSD will be configured to use these > interfaces to get addresses that will be dynamically updated on dns > > Modification of current patch should not be hard, we already have almost > everything implemented: > * method get_local_addresses should return dict {interface:[list of > addresses]}, this can be used in all of 4 cases. > * restore original function to detect IP address used to communicate > with IPA server > > I insist on 0) and 1), others may be stretch goal (easy to implement) > (It would be shame to not implemented multihomed support together with > this ticket, as it requires max 5 extra lines of code) > > Seems my proposal reasonable? > > What is you opinion Martin? Should we just use all addresses to be > registered, or try to keep old behavior as much as possible? > > Martin^2 > 0-2 implemented, IMO there is no real use-case for 3. It can be added later when/if there is need. Updated patch (+ rebase for ipa-4-2 branch) attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0035-9-client-Add-support-for-multiple-IP-addresses-during-.patch Type: text/x-patch Size: 14503 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0035-9-ipa42-client-Add-support-for-multiple-IP-addresses-during-.patch Type: text/x-patch Size: 14496 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 18 19:13:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 21:13:23 +0200 Subject: [Freeipa-devel] [PATCH 0059] improve the handling of krb5-related errors in dnssec daemons In-Reply-To: <55D36042.4020101@redhat.com> References: <55D36042.4020101@redhat.com> Message-ID: <55D383D3.7090307@redhat.com> On 08/18/2015 06:41 PM, Martin Babinsky wrote: > This patch fixes https://fedorahosted.org/freeipa/ticket/5229 and also > improves the handling of Kerberos errors in other DNSSEC daemons. > > -- > Martin^3 Babinsky > > Pushed to: ipa-4-2: a9f010fc286bee163601cbf0b512c6170501a1e9 master: 3506938a75cd189d137332f1f71ac469a9d6036e -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Aug 18 19:23:45 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 21:23:45 +0200 Subject: [Freeipa-devel] [PATCH 475] vault: Fix vault-find with criteria Message-ID: <55D38641.9000208@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-475-vault-Fix-vault-find-with-criteria.patch Type: text/x-patch Size: 799 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 18 19:44:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 21:44:37 +0200 Subject: [Freeipa-devel] [PATCH 0059] improve the handling of krb5-related errors in dnssec daemons In-Reply-To: <55D383D3.7090307@redhat.com> References: <55D36042.4020101@redhat.com> <55D383D3.7090307@redhat.com> Message-ID: <55D38B25.9020502@redhat.com> On 08/18/2015 09:13 PM, Martin Basti wrote: > > On 08/18/2015 06:41 PM, Martin Babinsky wrote: >> This patch fixes https://fedorahosted.org/freeipa/ticket/5229 and >> also improves the handling of Kerberos errors in other DNSSEC daemons. >> >> -- >> Martin^3 Babinsky >> >> > Pushed to: > ipa-4-2: a9f010fc286bee163601cbf0b512c6170501a1e9 > master: 3506938a75cd189d137332f1f71ac469a9d6036e > > > I forgot to write ACK, so ACK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Aug 18 19:48:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Aug 2015 21:48:29 +0200 Subject: [Freeipa-devel] [PATCH 476] vault: Add container information to vault command results Message-ID: <55D38C0D.2000107@redhat.com> Hi, the attached patch fixes part of . Christian is working on a fix for the other part of the ticket. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-476-vault-Add-container-information-to-vault-command-res.patch Type: text/x-patch Size: 3614 bytes Desc: not available URL: From mbasti at redhat.com Tue Aug 18 20:53:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Aug 2015 22:53:43 +0200 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <55D37349.8090201@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> <55D37349.8090201@redhat.com> Message-ID: <55D39B57.4040403@redhat.com> On 08/18/2015 08:02 PM, David Kupka wrote: > On 31/07/15 18:31, Martin Basti wrote: >> On 28/07/15 09:52, David Kupka wrote: >>> On 27/07/15 16:45, David Kupka wrote: >>>> On 15/01/15 17:13, David Kupka wrote: >>>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>>> >>>>>>>>>> Thank you for patch: >>>>>>>>>> >>>>>>>>>> 1) >>>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>>> - "Failed to connect to server '%s'.", >>>>>>>>>> server) >>>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>>> + except CalledProcessError as e: >>>>>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>>>> >>>>>>>>>> IMO the error message should be more specific, add there >>>>>>>>>> something >>>>>>>>>> like >>>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>>> >>>>>>>>>> .replace() is not needed >>>>>>>>>> >>>>>>>>>> 3) >>>>>>>>>> + if len(ips) == 0: >>>>>>>>>> >>>>>>>>>> if not ips: >>>>>>>>>> >>>>>>>>>> is more pythonic by PEP8 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>>> >>>>>>>> merciful NACK >>>>>>>> >>>>>>>> Thank you for the patch, unfortunately I hit one issue which needs >>>>>>>> to be >>>>>>>> resolved. >>>>>>>> >>>>>>>> If "sync PTR" is activated in zone settings, and reverse zone >>>>>>>> doesn't >>>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install >>>>>>>> print >>>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA records >>>>>>>> was >>>>>>>> succesfully updated, only PTR records failed. >>>>>>>> >>>>>>>> Bind log: >>>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an >>>>>>>> RR at >>>>>>>> 'vm-101.example.com' AAAA >>>>>>>> >>>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for >>>>>>>> A/AAAA >>>>>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>>> for IP >>>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>>> >>>>>>>> With IPv6 we have several addresses from different reverse >>>>>>>> zones and >>>>>>>> this situation may happen often. >>>>>>>> I suggest following: >>>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>>> fails, >>>>>>>> user needs to read log, which addresses installer tried to update) >>>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>>> there >>>>>>>> and print proper error message >>>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>>> particular >>>>>>>> IP address. >>>>>>>> >>>>>>>> Any other suggestions are welcome. >>>>>>>> >>>>>>> >>>>>>> After long discussion with DNS and UX guru I've implemented it this >>>>>>> way: >>>>>>> 1. Call nsupdate only once with all updates. >>>>>>> 2. Verify that the expected records are resolvable. >>>>>>> 3. If no print list of missing A/AAAA, list of missing PTR records >>>>>>> and >>>>>>> list to mismatched PTR record. >>>>>>> >>>>>>> As this is running inside client we can't much more and it's up to >>>>>>> user >>>>>>> to check what's rotten in his DNS setup. >>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> >>>>>> >>>>>> One more change to behave well in -crazy- exotic environments that >>>>>> resolves more PTR records for single IP. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> Yet another change to make language nerds and our UX guru happy :-) >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>> >>>> Rebased patch attached. >>>> >>>> >>> Updated patch attached. >>> >> Just for record this patch is for dualstack/IPv6 support. >> IMO this ticket also requires to fix ipa-join to support IPv6. >> >> I still have doubts to have multihomed support as default, this may be >> unexpected change of ipa-client-install behavior. >> I know, is hard to detect which addresses user want to register in IPA >> without crystal ball, but it should not be impossible :-) . >> >> I propose following solution: >> >> To add new options: >> --multihomed or --all-ip-address - all IP addresses from client will be >> used >> --ip-address - adress which will be registered on (IPA) DNS server >> --ip-address-interface - interface from which address will be registered >> >> >> 0) without any option specified, current behavior will be used + IPv6 >> * detect which address is used to communicate with IPA server >> * detect interface where this address belongs >> * use ipv4 and all ipv6 addresses of this interface >> * if --enable-dns-updates=true: configure SSSD as is configured now: >> automatically detect which address is used + patched SSSD will also >> updates proper IPv6 address >> >> 1) --multihomed or --all-ip-addresses (this is multihomed ticket) >> * all adresses will be used >> * if --enable-dns-updates=true: SSSD will be configured to send all >> ip_addresses >> >> 2) --ip-address option specified: >> * only specified addresses will be used (+ check if this addresses exist >> locally) >> * if --enable-dns-updates=true: ERROR dynamic updates may change this >> address (user should choose static vs dynamic) >> >> 3) --ip-address-interface option specified: >> * only addresses from specified interfaces will be used >> * if --enable-dns-updates=true: SSSD will be configured to use these >> interfaces to get addresses that will be dynamically updated on dns >> >> Modification of current patch should not be hard, we already have almost >> everything implemented: >> * method get_local_addresses should return dict {interface:[list of >> addresses]}, this can be used in all of 4 cases. >> * restore original function to detect IP address used to communicate >> with IPA server >> >> I insist on 0) and 1), others may be stretch goal (easy to implement) >> (It would be shame to not implemented multihomed support together with >> this ticket, as it requires max 5 extra lines of code) >> >> Seems my proposal reasonable? >> >> What is you opinion Martin? Should we just use all addresses to be >> registered, or try to keep old behavior as much as possible? >> >> Martin^2 >> > > 0-2 implemented, IMO there is no real use-case for 3. It can be added > later when/if there is need. > Updated patch (+ rebase for ipa-4-2 branch) attached. > ACK, I just modified typo in --ip-address help message before push. SSSD guys (Pavel CCed) will provide SSSD srpm that should go to our freeipa-master copr. Then we will bump required SSSD version in specfile. Pushed to ipa-4-2: ff34125bcaa99898859cb8ceefea88a4497959b3 Pushed to master: 8ba1392a3903894dda06c733bf37853c6cc3108c From mkosek at redhat.com Wed Aug 19 06:56:52 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 19 Aug 2015 08:56:52 +0200 Subject: [Freeipa-devel] [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <20150818172131.GF22106@redhat.com> References: <55C8C68A.1010606@redhat.com> <1439820377.4823.12.camel@redhat.com> <20150818172131.GF22106@redhat.com> Message-ID: <55D428B4.6040404@redhat.com> On 08/18/2015 07:21 PM, Alexander Bokovoy wrote: > On Mon, 17 Aug 2015, Nathaniel McCallum wrote: >> On Mon, 2015-08-10 at 17:43 +0200, Milan Kub?k wrote: >>> Hi all, >>> >>> this patch fixes problem described in the ticket [1] >>> that caused the test run to fail completely at every other or so run. >>> I took the liberty to fix most of the pep8 issues while I was at it. >>> >>> Thanks to Jan Cholasta for help with identifying this one. >>> >>> [1]: https://fedorahosted.org/freeipa/ticket/5192 >> >> I think the right answer is to move this to python-cryptography. >> >> We already have python-cryptography as a dependency. And in this case >> the crypto code is pretty well self-contained. Aside from nss database >> initialization, nss is only used in: >> * convertAlgorithm() (constants only) >> * XMLDecryptor (actual decryption code) >> >> The migration should be straightforward. It is probably a 1 day task. I >> could probably tackle it later this week. >> >> Should we do this? > I think we should -- for FreeIPA 4.3 or 4.4. That would we awesome Nathaniel! I remember too many bugs related to python-nss initialization and context leaks - if we get rid of those one for all, we are golden. From ofayans at redhat.com Wed Aug 19 07:00:49 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 19 Aug 2015 09:00:49 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55CDAA66.4040808@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> Message-ID: <55D429A1.3000605@redhat.com> Hi Martin, As discussed, here is a new version with pep8-related fixes On 08/14/2015 10:44 AM, Oleg Fayans wrote: > Hi Martin, > > Already noticed that. Implemented the named groups as Tomas advised. > Added the third test for > http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica > > > > > On 08/13/2015 05:06 PM, Martin Basti wrote: >> >> >> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>> NACK, comments inline. >>>> >>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Thanks for the review! >>>>> >>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>> Thank you for patch, I have a few nitpicks: >>>>>> >>>>>> 1) >>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>> Why do you add the name of method in docstring? >>>>> My bad, fixed. >>>> >>>> still there >>>> >>>> + tokenize_topologies(command_output) >>>> + takes an output of `ipa topologysegment-find` and returns an >>>> array of >>>> >>> Fixed, sorry. >>>> >>>>>> >>>>>> >>>>>> 2) >>>>>> >>>>>> +def create_segment(master, leftnode, rightnode): >>>>>> + """create_segment(master, leftnode, rightnode) >>>>>> + creates a topology segment. The first argument is a node to >>>>>> run the >>>>>> command on >>>>>> + The first 3 arguments should be objects of class Host >>>>>> + Returns a hash object containing segment's name, leftnode, >>>>>> rightnode information >>>>>> + """ >>>>>> >>>>>> I would prefer to add assert there instead of just document that a >>>>>> Host >>>>>> object is needed >>>>>> assert(isinstance(master, Host)) >>>>>> ... >>>>> >>>>> Fixed. Created a decorator that checks the type of arguments >>>> >>>> This does not scale well. >>>> If we will want to add new argument that is not host object, you need >>>> change it again. >>> >>> Agreed. Modified the decorator so that you can specify a slice of >>> arguments to be checked and a class to compare to. This does scale :) >>>> >>>> This might be used as function with specified variables that have to be >>>> host objects >>>>> >>>>>> >>>>>> 3) >>>>>> +def destroy_segment(master, segment_name): >>>>>> + """ >>>>>> + destroy_segment(master, segment_name) >>>>>> + Destroys topology segment. First argument should be object of >>>>>> class >>>>>> Host >>>>>> >>>>>> Instead of description of params as first, second etc., you may use >>>>>> following: >>>>>> >>>>>> +def destroy_segment(master, segment_name): >>>>>> + """ >>>>>> + Destroys topology segment. >>>>>> + :param master: reference to master object of class Host >>>>>> + :param segment: name fo segment >>>>>> and eventually this in other methods >>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>> + :raises NotFound: if segment is not found >>>>>> >>>>> Fixed >>>>>> >>>>>> 4) >>>>>> >>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>> >>>>>> I suggest cls.replicas[:-1] >>>>>> >>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>> >>>>>> In [3]: a[:-1] >>>>>> Out[3]: [1, 2, 3, 4] >>>>>> >>>>> Fixed >>>>>> >>>>>> 5) >>>>>> Why re.findall() and then you just use the first result? >>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>> >>>>>> Isn't just re.search() enough? >>>>>> leftnode_re.search(value).group(1) >>>>> >>>>> in fact >>>>> leftnode_re.findall(string)[0] >>>>> and >>>>> leftnode_re.search(string).group(1), >>>>> Are equally bad from the readability point of view. The first one is >>>>> even shorter a bit, so why change? :) >>>> >>>> It depends on point of view, because when I reviewed it yesterday my >>>> brain raises exception that you are trying to add multiple values to >>>> single value attribute, because you used findall, I expected that you >>>> need multiple values, and then I saw that index [0] at the end, and I >>>> was pretty confused what are you trying to achieve. >>>> >>>> And because findall is not effective in case when you need to find just >>>> one occurrence. >>> >>> I got it. Fixed. >>> >>>> >>>> >>>>> >>>>>> >>>>>> >>>>>> Python 3 nitpick: >>>>>> I'm not sure if time when we should enforce python 2/3 compability >>>>>> already comes, but just for record: >>>>>> instead of open(file, 'r'), please use io.open(file, 'r') (import io >>>>>> before) >>>>>> >>>>> Done. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> 1) >>>> >>>> +# >>>> >>>> empty comment here (several times) >>> >>> Removed >>>> >>> >> >> NACK >> >> you changed it wrong >> >> group() returns everything, you need use group(1) to return content in >> braces. > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.6-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 16724 bytes Desc: not available URL: From dkupka at redhat.com Wed Aug 19 07:21:36 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 19 Aug 2015 09:21:36 +0200 Subject: [Freeipa-devel] Subject: [PATCH 0061-2] Fix backup/restore (#5071) Message-ID: <55D42E80.3050909@redhat.com> https://fedorahosted.org/freeipa/ticket/5071 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0061-Add-etc-tmpfiles.d-dirsrv-serverid-.conf-to-backup.patch Type: text/x-patch Size: 1500 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0062-Backup-resore-authentication-control-configuration.patch Type: text/x-patch Size: 4829 bytes Desc: not available URL: From tbordaz at redhat.com Wed Aug 19 07:39:49 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 19 Aug 2015 09:39:49 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D36984.4010203@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> Message-ID: <55D432C5.1070801@redhat.com> Hi, It worked like a charm. I had a problem to commit it because of the VERSION stuff that changed. Except that (changing VERSION), the fix looks good to me thanks thierry On 08/18/2015 07:21 PM, Martin Basti wrote: > Thank you for the patch, I checked it, I just changed permission name > to have all first letters in uppercase as others. > Updated merged patch attached. > > On 08/18/2015 05:34 PM, thierry bordaz wrote: >> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>> >>>>>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>> >>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>> >>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>> user -> stageuser? IMHO it would be implemented internally >>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>> patch first ;-) ) >>>>>>>>>>> >>>>>>>>>>> git apply -v >>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>> error: while searching for: >>>>>>>>>>> # # >>>>>>>>>>> ######################################################## >>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>>>>> >>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> There is many pending patches that may change VERSION number, >>>>>>>>>> I will change it to right one before push. >>>>>>>>>> >>>>>>>>>> Does code looks good for you? >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>> test being 'admin' ? >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> theirry >>>>>>>> No I didn't,. >>>>>>>> >>>>>>>> I preserver all permission, the original permissions should work. >>>>>>>> >>>>>>>> Martin >>>>>>> Hi Martin, >>>>>>> >>>>>>> Running a test script, I have an issue with >>>>>>> >>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>> ipa: ERROR: an internal error has occurred >>>>>>> >>>>>>> >>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>> no_members=False): AttributeError >>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>>>> attribute 'setdefault' >>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>>>> Traceback (most recent call last): >>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>> line 347, in wsgi_execute >>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>> line 443, in __call__ >>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>> 10485] ret = self.run(*args, **options) >>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>> line 760, in run >>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>> 10485] return self.execute(*args, **options) >>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>> line 1227, in execute >>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>> 10485] *keys, **options) >>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>> line 373, in pre_callback >>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>> 10485] attrs_list, *keys, **options) >>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>> line 277, in set_default_values_pre_callback >>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>>>> entry_attrs.setdefault('description', []) >>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>>>> ipa: INFO: [jsonserver_session] >>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>> no_members=False): AttributeError >>>>>>> >>>>>>> >>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>> set_default function. It is not clear why. entry_attrs is one of >>>>>>> pre_callback parameter. >>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>> pre_callback ? >>>>>>> >>>>>>> >>>>>>> thanks >>>>>>> thierry >>>>>> >>>>>> Thank you, >>>>>> >>>>>> updated patch attached. >>>>> >>>>> So far, tests are ok. >>>>> Just one comment, the 'user-stage' command description is wrong, >>>>> as it moves an active user into the staged area >>>>> >>>>> user-stage Move deleted user into >>>>> staged area >>>> No, it's not doing that. >>>> >>>> user-stage is replacement of stageuser-add --from-delete, it >>>> doesn't work for active users. >>>> The support to move active user to staged area is RFE, I did not >>>> implemented it yet, and I dont know if this will fit IPA 4.2 timeframe >>> Ok. thanks. >>> Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. >>> >>> Running the tests being admin, there is no problem. >>> I have a permission issue, when running as 'Stage administrator'. >>> The 'delete' entry being moved to 'stage' container, we need the a >>> special permission for it. >> >> Hello, >> >> I tested this new permission to grant 'Stage user administrator' to >> do a 'user-stage'. >> Is it ok to add it to your patch ? >> >> thanks >> thierry >>> >>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>> --------------------- >>> Deleted user "ttest1" >>> --------------------- >>> >>> [root at vm-141 ~]# ipa user-stage ttest1 >>> ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to >>> move an entry to 'cn=staged >>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>> >>> [root at vm-141 ~]# klist >>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>> >>> Valid starting Expires Service principal >>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>> >>> [root at vm-141 ~]# kinit admin >>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>> [root at vm-141 ~]# ipa user-stage ttest1 >>> ---------------------------- >>> Staged user account "ttest1" >>> ---------------------------- >>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>> -------------- >>> 1 user matched >>> -------------- >>> User login: ttest1 >>> First name: t >>> Last name: test1 >>> Home directory: /home/ttest1 >>> Login shell: /bin/sh >>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>> UID: 1814000011 >>> GID: 1814000011 >>> Password: False >>> Kerberos keys available: False >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From preichl at redhat.com Wed Aug 19 07:47:38 2015 From: preichl at redhat.com (Pavel Reichl) Date: Wed, 19 Aug 2015 09:47:38 +0200 Subject: [Freeipa-devel] [PATCH] 0035 client: Update DNS with all available local IP addresses. In-Reply-To: <55D39B57.4040403@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> <55D37349.8090201@redhat.com> <55D39B57.4040403@redhat.com> Message-ID: <55D4349A.3050304@redhat.com> On 08/18/2015 10:53 PM, Martin Basti wrote: > > > On 08/18/2015 08:02 PM, David Kupka wrote: >> On 31/07/15 18:31, Martin Basti wrote: >>> On 28/07/15 09:52, David Kupka wrote: >>>> On 27/07/15 16:45, David Kupka wrote: >>>>> On 15/01/15 17:13, David Kupka wrote: >>>>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>>>> >>>>>>>>>>> Thank you for patch: >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>>>> - "Failed to connect to server '%s'.", >>>>>>>>>>> server) >>>>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>>>> + except CalledProcessError as e: >>>>>>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>>>>> >>>>>>>>>>> IMO the error message should be more specific, add there >>>>>>>>>>> something >>>>>>>>>>> like >>>>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>>>> >>>>>>>>>>> .replace() is not needed >>>>>>>>>>> >>>>>>>>>>> 3) >>>>>>>>>>> + if len(ips) == 0: >>>>>>>>>>> >>>>>>>>>>> if not ips: >>>>>>>>>>> >>>>>>>>>>> is more pythonic by PEP8 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>>>> >>>>>>>>> merciful NACK >>>>>>>>> >>>>>>>>> Thank you for the patch, unfortunately I hit one issue which >>>>>>>>> needs >>>>>>>>> to be >>>>>>>>> resolved. >>>>>>>>> >>>>>>>>> If "sync PTR" is activated in zone settings, and reverse zone >>>>>>>>> doesn't >>>>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install >>>>>>>>> print >>>>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA >>>>>>>>> records was >>>>>>>>> succesfully updated, only PTR records failed. >>>>>>>>> >>>>>>>>> Bind log: >>>>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an >>>>>>>>> RR at >>>>>>>>> 'vm-101.example.com' AAAA >>>>>>>>> >>>>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for >>>>>>>>> A/AAAA >>>>>>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>>>> for IP >>>>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>>>> >>>>>>>>> With IPv6 we have several addresses from different reverse >>>>>>>>> zones and >>>>>>>>> this situation may happen often. >>>>>>>>> I suggest following: >>>>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>>>> fails, >>>>>>>>> user needs to read log, which addresses installer tried to >>>>>>>>> update) >>>>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>>>> there >>>>>>>>> and print proper error message >>>>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>>>> particular >>>>>>>>> IP address. >>>>>>>>> >>>>>>>>> Any other suggestions are welcome. >>>>>>>>> >>>>>>>> >>>>>>>> After long discussion with DNS and UX guru I've implemented it >>>>>>>> this >>>>>>>> way: >>>>>>>> 1. Call nsupdate only once with all updates. >>>>>>>> 2. Verify that the expected records are resolvable. >>>>>>>> 3. If no print list of missing A/AAAA, list of missing PTR records >>>>>>>> and >>>>>>>> list to mismatched PTR record. >>>>>>>> >>>>>>>> As this is running inside client we can't much more and it's up to >>>>>>>> user >>>>>>>> to check what's rotten in his DNS setup. >>>>>>>> >>>>>>>> Updated patch attached. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> >>>>>>> >>>>>>> >>>>>>> One more change to behave well in -crazy- exotic environments that >>>>>>> resolves more PTR records for single IP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> >>>>>> Yet another change to make language nerds and our UX guru happy :-) >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> Rebased patch attached. >>>>> >>>>> >>>> Updated patch attached. >>>> >>> Just for record this patch is for dualstack/IPv6 support. >>> IMO this ticket also requires to fix ipa-join to support IPv6. >>> >>> I still have doubts to have multihomed support as default, this may be >>> unexpected change of ipa-client-install behavior. >>> I know, is hard to detect which addresses user want to register in IPA >>> without crystal ball, but it should not be impossible :-) . >>> >>> I propose following solution: >>> >>> To add new options: >>> --multihomed or --all-ip-address - all IP addresses from client will be >>> used >>> --ip-address - adress which will be registered on (IPA) DNS server >>> --ip-address-interface - interface from which address will be >>> registered >>> >>> >>> 0) without any option specified, current behavior will be used + IPv6 >>> * detect which address is used to communicate with IPA server >>> * detect interface where this address belongs >>> * use ipv4 and all ipv6 addresses of this interface >>> * if --enable-dns-updates=true: configure SSSD as is configured now: >>> automatically detect which address is used + patched SSSD will also >>> updates proper IPv6 address >>> >>> 1) --multihomed or --all-ip-addresses (this is multihomed ticket) >>> * all adresses will be used >>> * if --enable-dns-updates=true: SSSD will be configured to send all >>> ip_addresses >>> >>> 2) --ip-address option specified: >>> * only specified addresses will be used (+ check if this addresses >>> exist >>> locally) >>> * if --enable-dns-updates=true: ERROR dynamic updates may change this >>> address (user should choose static vs dynamic) >>> >>> 3) --ip-address-interface option specified: >>> * only addresses from specified interfaces will be used >>> * if --enable-dns-updates=true: SSSD will be configured to use these >>> interfaces to get addresses that will be dynamically updated on dns >>> >>> Modification of current patch should not be hard, we already have >>> almost >>> everything implemented: >>> * method get_local_addresses should return dict {interface:[list of >>> addresses]}, this can be used in all of 4 cases. >>> * restore original function to detect IP address used to communicate >>> with IPA server >>> >>> I insist on 0) and 1), others may be stretch goal (easy to implement) >>> (It would be shame to not implemented multihomed support together with >>> this ticket, as it requires max 5 extra lines of code) >>> >>> Seems my proposal reasonable? >>> >>> What is you opinion Martin? Should we just use all addresses to be >>> registered, or try to keep old behavior as much as possible? >>> >>> Martin^2 >>> >> >> 0-2 implemented, IMO there is no real use-case for 3. It can be added >> later when/if there is need. >> Updated patch (+ rebase for ipa-4-2 branch) attached. >> > > ACK, I just modified typo in --ip-address help message before push. > > SSSD guys (Pavel CCed) will provide SSSD srpm that should go to our > freeipa-master copr. Then we will bump required SSSD version in specfile. SRPM of today's master: https://preichl.fedorapeople.org/srpms/2015-08-19/sssd-1.13.1-0.fc22.src.rpm HTH > > Pushed to ipa-4-2: ff34125bcaa99898859cb8ceefea88a4497959b3 > Pushed to master: 8ba1392a3903894dda06c733bf37853c6cc3108c > From pvoborni at redhat.com Wed Aug 19 08:29:12 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Aug 2015 10:29:12 +0200 Subject: [Freeipa-devel] [PATCH 475] vault: Fix vault-find with criteria In-Reply-To: <55D38641.9000208@redhat.com> References: <55D38641.9000208@redhat.com> Message-ID: <55D43E58.5080108@redhat.com> On 08/18/2015 09:23 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > ACK Pushed to: master: 29cee7a4bc5a6d2506e7937c982339274fa0edb4 ipa-4-2: 9d32bcafab0f7fa35ae089bff0a5001e2406767d -- Petr Vobornik From jcholast at redhat.com Wed Aug 19 08:34:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 10:34:38 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D432C5.1070801@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> Message-ID: <55D43F9E.7080402@redhat.com> On 19.8.2015 09:39, thierry bordaz wrote: > Hi, > > It worked like a charm. > I had a problem to commit it because of the VERSION stuff that changed. > > Except that (changing VERSION), the fix looks good to me > > thanks > thierry > On 08/18/2015 07:21 PM, Martin Basti wrote: >> Thank you for the patch, I checked it, I just changed permission name >> to have all first letters in uppercase as others. >> Updated merged patch attached. >> >> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>> >>>>>>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>> >>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>> >>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented internally >>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>> >>>>>>>>>>>> git apply -v >>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>> error: while searching for: >>>>>>>>>>>> # # >>>>>>>>>>>> ######################################################## >>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>>>>>> >>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> There is many pending patches that may change VERSION number, >>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>> >>>>>>>>>>> Does code looks good for you? >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>>> test being 'admin' ? >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> theirry >>>>>>>>> No I didn't,. >>>>>>>>> >>>>>>>>> I preserver all permission, the original permissions should work. >>>>>>>>> >>>>>>>>> Martin >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Running a test script, I have an issue with >>>>>>>> >>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>> >>>>>>>> >>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>> no_members=False): AttributeError >>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>>>>> attribute 'setdefault' >>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>>>>> Traceback (most recent call last): >>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>> line 347, in wsgi_execute >>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>> line 443, in __call__ >>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>> line 760, in run >>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>> line 1227, in execute >>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>> 10485] *keys, **options) >>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>> line 373, in pre_callback >>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>> no_members=False): AttributeError >>>>>>>> >>>>>>>> >>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>> set_default function. It is not clear why. entry_attrs is one of >>>>>>>> pre_callback parameter. >>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>> pre_callback ? >>>>>>>> >>>>>>>> >>>>>>>> thanks >>>>>>>> thierry >>>>>>> >>>>>>> Thank you, >>>>>>> >>>>>>> updated patch attached. >>>>>> >>>>>> So far, tests are ok. >>>>>> Just one comment, the 'user-stage' command description is wrong, >>>>>> as it moves an active user into the staged area >>>>>> >>>>>> user-stage Move deleted user into >>>>>> staged area >>>>> No, it's not doing that. >>>>> >>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>> doesn't work for active users. >>>>> The support to move active user to staged area is RFE, I did not >>>>> implemented it yet, and I dont know if this will fit IPA 4.2 timeframe >>>> Ok. thanks. >>>> Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. >>>> >>>> Running the tests being admin, there is no problem. >>>> I have a permission issue, when running as 'Stage administrator'. >>>> The 'delete' entry being moved to 'stage' container, we need the a >>>> special permission for it. >>> >>> Hello, >>> >>> I tested this new permission to grant 'Stage user administrator' to >>> do a 'user-stage'. >>> Is it ok to add it to your patch ? >>> >>> thanks >>> thierry >>>> >>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>> --------------------- >>>> Deleted user "ttest1" >>>> --------------------- >>>> >>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to >>>> move an entry to 'cn=staged >>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>> >>>> [root at vm-141 ~]# klist >>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>> >>>> Valid starting Expires Service principal >>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>> >>>> [root at vm-141 ~]# kinit admin >>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>> ---------------------------- >>>> Staged user account "ttest1" >>>> ---------------------------- >>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>> -------------- >>>> 1 user matched >>>> -------------- >>>> User login: ttest1 >>>> First name: t >>>> Last name: test1 >>>> Home directory: /home/ttest1 >>>> Login shell: /bin/sh >>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>> UID: 1814000011 >>>> GID: 1814000011 >>>> Password: False >>>> Kerberos keys available: False >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> >>> >> > NACK. 1) Use ADD+DEL instead of MODRDN as we agreed before: . 2) You can't use the entry preparation code from stageuser-add in user-stage - it is supposed to normalize user input, not already normalized data from LDAP, and could lead to subtle and hard to track errors. Honza -- Jan Cholasta From mbasti at redhat.com Wed Aug 19 08:36:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Aug 2015 10:36:49 +0200 Subject: [Freeipa-devel] [PATCH] 0299 client: Update DNS with all available local IP addresses. In-Reply-To: <55D39B57.4040403@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> <55D37349.8090201@redhat.com> <55D39B57.4040403@redhat.com> Message-ID: <55D44021.9090203@redhat.com> On 08/18/2015 10:53 PM, Martin Basti wrote: > > > On 08/18/2015 08:02 PM, David Kupka wrote: >> On 31/07/15 18:31, Martin Basti wrote: >>> On 28/07/15 09:52, David Kupka wrote: >>>> On 27/07/15 16:45, David Kupka wrote: >>>>> On 15/01/15 17:13, David Kupka wrote: >>>>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>>>> >>>>>>>>>>> Thank you for patch: >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>>>> - "Failed to connect to server '%s'.", >>>>>>>>>>> server) >>>>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>>>> + except CalledProcessError as e: >>>>>>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>>>>> >>>>>>>>>>> IMO the error message should be more specific, add there >>>>>>>>>>> something >>>>>>>>>>> like >>>>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>>>> >>>>>>>>>>> .replace() is not needed >>>>>>>>>>> >>>>>>>>>>> 3) >>>>>>>>>>> + if len(ips) == 0: >>>>>>>>>>> >>>>>>>>>>> if not ips: >>>>>>>>>>> >>>>>>>>>>> is more pythonic by PEP8 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>>>> >>>>>>>>> merciful NACK >>>>>>>>> >>>>>>>>> Thank you for the patch, unfortunately I hit one issue which >>>>>>>>> needs >>>>>>>>> to be >>>>>>>>> resolved. >>>>>>>>> >>>>>>>>> If "sync PTR" is activated in zone settings, and reverse zone >>>>>>>>> doesn't >>>>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install >>>>>>>>> print >>>>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA >>>>>>>>> records was >>>>>>>>> succesfully updated, only PTR records failed. >>>>>>>>> >>>>>>>>> Bind log: >>>>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an >>>>>>>>> RR at >>>>>>>>> 'vm-101.example.com' AAAA >>>>>>>>> >>>>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for >>>>>>>>> A/AAAA >>>>>>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>>>> for IP >>>>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>>>> >>>>>>>>> With IPv6 we have several addresses from different reverse >>>>>>>>> zones and >>>>>>>>> this situation may happen often. >>>>>>>>> I suggest following: >>>>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>>>> fails, >>>>>>>>> user needs to read log, which addresses installer tried to >>>>>>>>> update) >>>>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>>>> there >>>>>>>>> and print proper error message >>>>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>>>> particular >>>>>>>>> IP address. >>>>>>>>> >>>>>>>>> Any other suggestions are welcome. >>>>>>>>> >>>>>>>> >>>>>>>> After long discussion with DNS and UX guru I've implemented it >>>>>>>> this >>>>>>>> way: >>>>>>>> 1. Call nsupdate only once with all updates. >>>>>>>> 2. Verify that the expected records are resolvable. >>>>>>>> 3. If no print list of missing A/AAAA, list of missing PTR records >>>>>>>> and >>>>>>>> list to mismatched PTR record. >>>>>>>> >>>>>>>> As this is running inside client we can't much more and it's up to >>>>>>>> user >>>>>>>> to check what's rotten in his DNS setup. >>>>>>>> >>>>>>>> Updated patch attached. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> >>>>>>> >>>>>>> >>>>>>> One more change to behave well in -crazy- exotic environments that >>>>>>> resolves more PTR records for single IP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> >>>>>> Yet another change to make language nerds and our UX guru happy :-) >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>> >>>>> Rebased patch attached. >>>>> >>>>> >>>> Updated patch attached. >>>> >>> Just for record this patch is for dualstack/IPv6 support. >>> IMO this ticket also requires to fix ipa-join to support IPv6. >>> >>> I still have doubts to have multihomed support as default, this may be >>> unexpected change of ipa-client-install behavior. >>> I know, is hard to detect which addresses user want to register in IPA >>> without crystal ball, but it should not be impossible :-) . >>> >>> I propose following solution: >>> >>> To add new options: >>> --multihomed or --all-ip-address - all IP addresses from client will be >>> used >>> --ip-address - adress which will be registered on (IPA) DNS server >>> --ip-address-interface - interface from which address will be >>> registered >>> >>> >>> 0) without any option specified, current behavior will be used + IPv6 >>> * detect which address is used to communicate with IPA server >>> * detect interface where this address belongs >>> * use ipv4 and all ipv6 addresses of this interface >>> * if --enable-dns-updates=true: configure SSSD as is configured now: >>> automatically detect which address is used + patched SSSD will also >>> updates proper IPv6 address >>> >>> 1) --multihomed or --all-ip-addresses (this is multihomed ticket) >>> * all adresses will be used >>> * if --enable-dns-updates=true: SSSD will be configured to send all >>> ip_addresses >>> >>> 2) --ip-address option specified: >>> * only specified addresses will be used (+ check if this addresses >>> exist >>> locally) >>> * if --enable-dns-updates=true: ERROR dynamic updates may change this >>> address (user should choose static vs dynamic) >>> >>> 3) --ip-address-interface option specified: >>> * only addresses from specified interfaces will be used >>> * if --enable-dns-updates=true: SSSD will be configured to use these >>> interfaces to get addresses that will be dynamically updated on dns >>> >>> Modification of current patch should not be hard, we already have >>> almost >>> everything implemented: >>> * method get_local_addresses should return dict {interface:[list of >>> addresses]}, this can be used in all of 4 cases. >>> * restore original function to detect IP address used to communicate >>> with IPA server >>> >>> I insist on 0) and 1), others may be stretch goal (easy to implement) >>> (It would be shame to not implemented multihomed support together with >>> this ticket, as it requires max 5 extra lines of code) >>> >>> Seems my proposal reasonable? >>> >>> What is you opinion Martin? Should we just use all addresses to be >>> registered, or try to keep old behavior as much as possible? >>> >>> Martin^2 >>> >> >> 0-2 implemented, IMO there is no real use-case for 3. It can be added >> later when/if there is need. >> Updated patch (+ rebase for ipa-4-2 branch) attached. >> > > ACK, I just modified typo in --ip-address help message before push. > > SSSD guys (Pavel CCed) will provide SSSD srpm that should go to our > freeipa-master copr. Then we will bump required SSSD version in specfile. > > Pushed to ipa-4-2: ff34125bcaa99898859cb8ceefea88a4497959b3 > Pushed to master: 8ba1392a3903894dda06c733bf37853c6cc3108c > Attached patch bumps required version of SSSD (available in freeipa-master copr) -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0299-Add-dependency-to-SSSD-1.13.1.patch Type: text/x-patch Size: 1170 bytes Desc: not available URL: From pvoborni at redhat.com Wed Aug 19 08:41:02 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Aug 2015 10:41:02 +0200 Subject: [Freeipa-devel] [PATCH 476] vault: Add container information to vault command results In-Reply-To: <55D38C0D.2000107@redhat.com> References: <55D38C0D.2000107@redhat.com> Message-ID: <55D4411E.6020801@redhat.com> On 08/18/2015 09:48 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes part of > . > > Christian is working on a fix for the other part of the ticket. > > Honza > > ACK Pushed to: master: 01dd951ddc0181b559eb3dd5ff0336c81e245628 ipa-4-2: cb575e6a16c3f1a001b13b96279ecd758c8783a1 -- Petr Vobornik From dkupka at redhat.com Wed Aug 19 08:44:16 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 19 Aug 2015 10:44:16 +0200 Subject: [Freeipa-devel] Subject: [PATCH 0061-2] Fix backup/restore (#5071) In-Reply-To: <55D42E80.3050909@redhat.com> References: <55D42E80.3050909@redhat.com> Message-ID: <55D441E0.6070809@redhat.com> On 19/08/15 09:21, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/5071 > Updated patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0061.1-Add-etc-tmpfiles.d-dirsrv-serverid-.conf-to-backup.patch Type: text/x-patch Size: 1518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0062.1-Backup-resore-authentication-control-configuration.patch Type: text/x-patch Size: 4823 bytes Desc: not available URL: From tbordaz at redhat.com Wed Aug 19 08:47:46 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 19 Aug 2015 10:47:46 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D43F9E.7080402@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> <55D43F9E.7080402@redhat.com> Message-ID: <55D442B2.3070404@redhat.com> On 08/19/2015 10:34 AM, Jan Cholasta wrote: > On 19.8.2015 09:39, thierry bordaz wrote: >> Hi, >> >> It worked like a charm. >> I had a problem to commit it because of the VERSION stuff that changed. >> >> Except that (changing VERSION), the fix looks good to me >> >> thanks >> thierry >> On 08/18/2015 07:21 PM, Martin Basti wrote: >>> Thank you for the patch, I checked it, I just changed permission name >>> to have all first letters in uppercase as others. >>> Updated merged patch attached. >>> >>> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented internally >>>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>>> >>>>>>>>>>>>> git apply -v >>>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>>> error: while searching for: >>>>>>>>>>>>> # # >>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>>>>>>> >>>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> There is many pending patches that may change VERSION number, >>>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>>> >>>>>>>>>>>> Does code looks good for you? >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>>>> test being 'admin' ? >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> theirry >>>>>>>>>> No I didn't,. >>>>>>>>>> >>>>>>>>>> I preserver all permission, the original permissions should >>>>>>>>>> work. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> Running a test script, I have an issue with >>>>>>>>> >>>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>>> >>>>>>>>> >>>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>> no_members=False): AttributeError >>>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>>>>>> attribute 'setdefault' >>>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>>>>>> Traceback (most recent call last): >>>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>>>>>> File >>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>>> line 347, in wsgi_execute >>>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>> line 443, in __call__ >>>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>> line 760, in run >>>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>>>>>> File >>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>>> line 1227, in execute >>>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>>> 10485] *keys, **options) >>>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>>>>>> File >>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>> line 373, in pre_callback >>>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>>>>>> File >>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>> no_members=False): AttributeError >>>>>>>>> >>>>>>>>> >>>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>>> set_default function. It is not clear why. entry_attrs is one of >>>>>>>>> pre_callback parameter. >>>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>>> pre_callback ? >>>>>>>>> >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> thierry >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> updated patch attached. >>>>>>> >>>>>>> So far, tests are ok. >>>>>>> Just one comment, the 'user-stage' command description is wrong, >>>>>>> as it moves an active user into the staged area >>>>>>> >>>>>>> user-stage Move deleted user into >>>>>>> staged area >>>>>> No, it's not doing that. >>>>>> >>>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>>> doesn't work for active users. >>>>>> The support to move active user to staged area is RFE, I did not >>>>>> implemented it yet, and I dont know if this will fit IPA 4.2 >>>>>> timeframe >>>>> Ok. thanks. >>>>> Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. >>>>> >>>>> Running the tests being admin, there is no problem. >>>>> I have a permission issue, when running as 'Stage administrator'. >>>>> The 'delete' entry being moved to 'stage' container, we need the a >>>>> special permission for it. >>>> >>>> Hello, >>>> >>>> I tested this new permission to grant 'Stage user administrator' to >>>> do a 'user-stage'. >>>> Is it ok to add it to your patch ? >>>> >>>> thanks >>>> thierry >>>>> >>>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>>> --------------------- >>>>> Deleted user "ttest1" >>>>> --------------------- >>>>> >>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to >>>>> move an entry to 'cn=staged >>>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>>> >>>>> >>>>> [root at vm-141 ~]# klist >>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>> >>>>> Valid starting Expires Service principal >>>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>> >>>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>> >>>>> [root at vm-141 ~]# kinit admin >>>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>> ---------------------------- >>>>> Staged user account "ttest1" >>>>> ---------------------------- >>>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>>> -------------- >>>>> 1 user matched >>>>> -------------- >>>>> User login: ttest1 >>>>> First name: t >>>>> Last name: test1 >>>>> Home directory: /home/ttest1 >>>>> Login shell: /bin/sh >>>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>>> UID: 1814000011 >>>>> GID: 1814000011 >>>>> Password: False >>>>> Kerberos keys available: False >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> >>>>> >>>> >>> >> > > NACK. > > 1) Use ADD+DEL instead of MODRDN as we agreed before: > . Hi, I have a slight preference doing MODRDN than ADD+DEL but I think it is for corner case. Before preserving a user, the user was active and could be updated. If the user gets updated on a replica (e.g. change its phonenumer) but for some reason the update is not immediately replicated, then a later 'user-del --preserve' + 'user-stage' will stage the user without the updated phonenumber. In addition, doing 2 ops rather than one costs more and is not atomic (more complex to handle failure). thank thierry > > 2) You can't use the entry preparation code from stageuser-add in > user-stage - it is supposed to normalize user input, not already > normalized data from LDAP, and could lead to subtle and hard to track > errors. > > Honza > From jcholast at redhat.com Wed Aug 19 08:57:06 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 10:57:06 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D442B2.3070404@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> <55D43F9E.7080402@redhat.com> <55D442B2.3070404@redhat.com> Message-ID: <55D444E2.9080806@redhat.com> On 19.8.2015 10:47, thierry bordaz wrote: > On 08/19/2015 10:34 AM, Jan Cholasta wrote: >> On 19.8.2015 09:39, thierry bordaz wrote: >>> Hi, >>> >>> It worked like a charm. >>> I had a problem to commit it because of the VERSION stuff that changed. >>> >>> Except that (changing VERSION), the fix looks good to me >>> >>> thanks >>> thierry >>> On 08/18/2015 07:21 PM, Martin Basti wrote: >>>> Thank you for the patch, I checked it, I just changed permission name >>>> to have all first letters in uppercase as others. >>>> Updated merged patch attached. >>>> >>>> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>>>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting NACK :D >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented internally >>>>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> git apply -v >>>>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>>>> error: while searching for: >>>>>>>>>>>>>> # # >>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>>>>>>>> >>>>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> There is many pending patches that may change VERSION number, >>>>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>>>> >>>>>>>>>>>>> Does code looks good for you? >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>>>>> test being 'admin' ? >>>>>>>>>>>> >>>>>>>>>>>> thanks >>>>>>>>>>>> theirry >>>>>>>>>>> No I didn't,. >>>>>>>>>>> >>>>>>>>>>> I preserver all permission, the original permissions should >>>>>>>>>>> work. >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> Running a test script, I have an issue with >>>>>>>>>> >>>>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>> no_members=False): AttributeError >>>>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>>>>>>> attribute 'setdefault' >>>>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>>>>>>> Traceback (most recent call last): >>>>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>>>>>>> File >>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>>>> line 347, in wsgi_execute >>>>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>> line 443, in __call__ >>>>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>> line 760, in run >>>>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>>>>>>> File >>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>>>> line 1227, in execute >>>>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>>>> 10485] *keys, **options) >>>>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>>>>>>> File >>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>> line 373, in pre_callback >>>>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>>>>>>> File >>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>> no_members=False): AttributeError >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>>>> set_default function. It is not clear why. entry_attrs is one of >>>>>>>>>> pre_callback parameter. >>>>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>>>> pre_callback ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> thanks >>>>>>>>>> thierry >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> >>>>>>>>> updated patch attached. >>>>>>>> >>>>>>>> So far, tests are ok. >>>>>>>> Just one comment, the 'user-stage' command description is wrong, >>>>>>>> as it moves an active user into the staged area >>>>>>>> >>>>>>>> user-stage Move deleted user into >>>>>>>> staged area >>>>>>> No, it's not doing that. >>>>>>> >>>>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>>>> doesn't work for active users. >>>>>>> The support to move active user to staged area is RFE, I did not >>>>>>> implemented it yet, and I dont know if this will fit IPA 4.2 >>>>>>> timeframe >>>>>> Ok. thanks. >>>>>> Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. >>>>>> >>>>>> Running the tests being admin, there is no problem. >>>>>> I have a permission issue, when running as 'Stage administrator'. >>>>>> The 'delete' entry being moved to 'stage' container, we need the a >>>>>> special permission for it. >>>>> >>>>> Hello, >>>>> >>>>> I tested this new permission to grant 'Stage user administrator' to >>>>> do a 'user-stage'. >>>>> Is it ok to add it to your patch ? >>>>> >>>>> thanks >>>>> thierry >>>>>> >>>>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>>>> --------------------- >>>>>> Deleted user "ttest1" >>>>>> --------------------- >>>>>> >>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to >>>>>> move an entry to 'cn=staged >>>>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>>>> >>>>>> >>>>>> [root at vm-141 ~]# klist >>>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>> >>>>>> Valid starting Expires Service principal >>>>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>> >>>>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>> >>>>>> [root at vm-141 ~]# kinit admin >>>>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>> ---------------------------- >>>>>> Staged user account "ttest1" >>>>>> ---------------------------- >>>>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>>>> -------------- >>>>>> 1 user matched >>>>>> -------------- >>>>>> User login: ttest1 >>>>>> First name: t >>>>>> Last name: test1 >>>>>> Home directory: /home/ttest1 >>>>>> Login shell: /bin/sh >>>>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>>>> UID: 1814000011 >>>>>> GID: 1814000011 >>>>>> Password: False >>>>>> Kerberos keys available: False >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> >>>>>> >>>>> >>>> >>> >> >> NACK. >> >> 1) Use ADD+DEL instead of MODRDN as we agreed before: >> . >> > > Hi, > > I have a slight preference doing MODRDN than ADD+DEL but I think it is > for corner case. > Before preserving a user, the user was active and could be updated. If > the user gets updated on a replica (e.g. change its phonenumer) but for > some reason the update is not immediately replicated, then a later > 'user-del --preserve' + 'user-stage' will stage the user without the > updated phonenumber. > > In addition, doing 2 ops rather than one costs more and is not atomic > (more complex to handle failure). The same problem exists for stageuser_activate, and unless you want to change it to use MODRDN as well, user_stage must use ADD+DEL. This was already discussed quite thoroughly and we reached the decision to use ADD+DEL, because it is consistent with the rest of the user code. I don't see a point in discussing this further and rehashing what was already said. > > thank > thierry >> >> 2) You can't use the entry preparation code from stageuser-add in >> user-stage - it is supposed to normalize user input, not already >> normalized data from LDAP, and could lead to subtle and hard to track >> errors. >> >> Honza >> > -- Jan Cholasta From jcholast at redhat.com Wed Aug 19 09:04:20 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 11:04:20 +0200 Subject: [Freeipa-devel] [PATCH 0298] Server Upgrade: start DS before CA is started In-Reply-To: <55D369C5.5050404@redhat.com> References: <55D365CF.7000508@redhat.com> <55D36806.4030608@redhat.com> <55D369C5.5050404@redhat.com> Message-ID: <55D44694.4010909@redhat.com> On 18.8.2015 19:22, Martin Basti wrote: > > > On 08/18/2015 07:14 PM, Martin Basti wrote: >> >> >> On 08/18/2015 07:05 PM, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5232 >>> >>> Patch attached. >>> >>> >> Self-NACK, I sent wrong patch >> >> > > The correct patch attached. Thanks, ACK. Pushed to: master: 9fe67dcf2b6c10ca4eebab1c573d101316f481cd ipa-4-2: 7924007a83a82674a495afe0e63a4bc85ab2a5ab -- Jan Cholasta From jcholast at redhat.com Wed Aug 19 09:06:33 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 11:06:33 +0200 Subject: [Freeipa-devel] [PATCH] 0299 client: Update DNS with all available local IP addresses. In-Reply-To: <55D44021.9090203@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> <55D37349.8090201@redhat.com> <55D39B57.4040403@redhat.com> <55D44021.9090203@redhat.com> Message-ID: <55D44719.5000306@redhat.com> On 19.8.2015 10:36, Martin Basti wrote: > > > On 08/18/2015 10:53 PM, Martin Basti wrote: >> >> >> On 08/18/2015 08:02 PM, David Kupka wrote: >>> On 31/07/15 18:31, Martin Basti wrote: >>>> On 28/07/15 09:52, David Kupka wrote: >>>>> On 27/07/15 16:45, David Kupka wrote: >>>>>> On 15/01/15 17:13, David Kupka wrote: >>>>>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>>>>> >>>>>>>>>>>> Thank you for patch: >>>>>>>>>>>> >>>>>>>>>>>> 1) >>>>>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>>>>> - "Failed to connect to server '%s'.", >>>>>>>>>>>> server) >>>>>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>>>>> + except CalledProcessError as e: >>>>>>>>>>>> + root_logger.error("Cannot update DNS records. %s" % e) >>>>>>>>>>>> >>>>>>>>>>>> IMO the error message should be more specific, add there >>>>>>>>>>>> something >>>>>>>>>>>> like >>>>>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>>>>> >>>>>>>>>>>> 2) >>>>>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>>>>> >>>>>>>>>>>> .replace() is not needed >>>>>>>>>>>> >>>>>>>>>>>> 3) >>>>>>>>>>>> + if len(ips) == 0: >>>>>>>>>>>> >>>>>>>>>>>> if not ips: >>>>>>>>>>>> >>>>>>>>>>>> is more pythonic by PEP8 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>>>>> >>>>>>>>>> merciful NACK >>>>>>>>>> >>>>>>>>>> Thank you for the patch, unfortunately I hit one issue which >>>>>>>>>> needs >>>>>>>>>> to be >>>>>>>>>> resolved. >>>>>>>>>> >>>>>>>>>> If "sync PTR" is activated in zone settings, and reverse zone >>>>>>>>>> doesn't >>>>>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install >>>>>>>>>> print >>>>>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA >>>>>>>>>> records was >>>>>>>>>> succesfully updated, only PTR records failed. >>>>>>>>>> >>>>>>>>>> Bind log: >>>>>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an >>>>>>>>>> RR at >>>>>>>>>> 'vm-101.example.com' AAAA >>>>>>>>>> >>>>>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for >>>>>>>>>> A/AAAA >>>>>>>>>> 'vm-101.example.com.' refused: unable to find active reverse zone >>>>>>>>>> for IP >>>>>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>>>>> >>>>>>>>>> With IPv6 we have several addresses from different reverse >>>>>>>>>> zones and >>>>>>>>>> this situation may happen often. >>>>>>>>>> I suggest following: >>>>>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>>>>> fails, >>>>>>>>>> user needs to read log, which addresses installer tried to >>>>>>>>>> update) >>>>>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>>>>> there >>>>>>>>>> and print proper error message >>>>>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>>>>> particular >>>>>>>>>> IP address. >>>>>>>>>> >>>>>>>>>> Any other suggestions are welcome. >>>>>>>>>> >>>>>>>>> >>>>>>>>> After long discussion with DNS and UX guru I've implemented it >>>>>>>>> this >>>>>>>>> way: >>>>>>>>> 1. Call nsupdate only once with all updates. >>>>>>>>> 2. Verify that the expected records are resolvable. >>>>>>>>> 3. If no print list of missing A/AAAA, list of missing PTR records >>>>>>>>> and >>>>>>>>> list to mismatched PTR record. >>>>>>>>> >>>>>>>>> As this is running inside client we can't much more and it's up to >>>>>>>>> user >>>>>>>>> to check what's rotten in his DNS setup. >>>>>>>>> >>>>>>>>> Updated patch attached. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-devel mailing list >>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> One more change to behave well in -crazy- exotic environments that >>>>>>>> resolves more PTR records for single IP. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> >>>>>>> >>>>>>> Yet another change to make language nerds and our UX guru happy :-) >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>> >>>>>> Rebased patch attached. >>>>>> >>>>>> >>>>> Updated patch attached. >>>>> >>>> Just for record this patch is for dualstack/IPv6 support. >>>> IMO this ticket also requires to fix ipa-join to support IPv6. >>>> >>>> I still have doubts to have multihomed support as default, this may be >>>> unexpected change of ipa-client-install behavior. >>>> I know, is hard to detect which addresses user want to register in IPA >>>> without crystal ball, but it should not be impossible :-) . >>>> >>>> I propose following solution: >>>> >>>> To add new options: >>>> --multihomed or --all-ip-address - all IP addresses from client will be >>>> used >>>> --ip-address - adress which will be registered on (IPA) DNS server >>>> --ip-address-interface - interface from which address will be >>>> registered >>>> >>>> >>>> 0) without any option specified, current behavior will be used + IPv6 >>>> * detect which address is used to communicate with IPA server >>>> * detect interface where this address belongs >>>> * use ipv4 and all ipv6 addresses of this interface >>>> * if --enable-dns-updates=true: configure SSSD as is configured now: >>>> automatically detect which address is used + patched SSSD will also >>>> updates proper IPv6 address >>>> >>>> 1) --multihomed or --all-ip-addresses (this is multihomed ticket) >>>> * all adresses will be used >>>> * if --enable-dns-updates=true: SSSD will be configured to send all >>>> ip_addresses >>>> >>>> 2) --ip-address option specified: >>>> * only specified addresses will be used (+ check if this addresses >>>> exist >>>> locally) >>>> * if --enable-dns-updates=true: ERROR dynamic updates may change this >>>> address (user should choose static vs dynamic) >>>> >>>> 3) --ip-address-interface option specified: >>>> * only addresses from specified interfaces will be used >>>> * if --enable-dns-updates=true: SSSD will be configured to use these >>>> interfaces to get addresses that will be dynamically updated on dns >>>> >>>> Modification of current patch should not be hard, we already have >>>> almost >>>> everything implemented: >>>> * method get_local_addresses should return dict {interface:[list of >>>> addresses]}, this can be used in all of 4 cases. >>>> * restore original function to detect IP address used to communicate >>>> with IPA server >>>> >>>> I insist on 0) and 1), others may be stretch goal (easy to implement) >>>> (It would be shame to not implemented multihomed support together with >>>> this ticket, as it requires max 5 extra lines of code) >>>> >>>> Seems my proposal reasonable? >>>> >>>> What is you opinion Martin? Should we just use all addresses to be >>>> registered, or try to keep old behavior as much as possible? >>>> >>>> Martin^2 >>>> >>> >>> 0-2 implemented, IMO there is no real use-case for 3. It can be added >>> later when/if there is need. >>> Updated patch (+ rebase for ipa-4-2 branch) attached. >>> >> >> ACK, I just modified typo in --ip-address help message before push. >> >> SSSD guys (Pavel CCed) will provide SSSD srpm that should go to our >> freeipa-master copr. Then we will bump required SSSD version in specfile. >> >> Pushed to ipa-4-2: ff34125bcaa99898859cb8ceefea88a4497959b3 >> Pushed to master: 8ba1392a3903894dda06c733bf37853c6cc3108c >> > Attached patch bumps required version of SSSD (available in > freeipa-master copr) ACK. Pushed to: master: 9fe67dcf2b6c10ca4eebab1c573d101316f481cd ipa-4-2: 7924007a83a82674a495afe0e63a4bc85ab2a5ab -- Jan Cholasta From mbasti at redhat.com Wed Aug 19 09:20:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Aug 2015 11:20:14 +0200 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <55D0AC54.6040401@redhat.com> References: <55D0AC54.6040401@redhat.com> Message-ID: <55D44A4E.7080805@redhat.com> On 08/16/2015 05:29 PM, Endi Sukma Dewata wrote: > The vault-add and vault-archive commands have been modified to > optionally retrieve a secret from a source vault, then re-archive > the secret into the new/existing target vault. > > https://fedorahosted.org/freeipa/ticket/5223 > > > I cannot apply this patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Aug 19 09:26:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Aug 2015 12:26:53 +0300 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55D2EECA.7030808@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> Message-ID: <20150819092653.GK22106@redhat.com> On Tue, 18 Aug 2015, Michael ?im??ek wrote: >On 2015-08-17 21:10, Robbie Harwood wrote: >>Michael ?im??ek writes: >> >>>Attaching new revision of the patch. Changes from the previous: >>>- ldap2's connect now chooses the bind type same way as in ipaldap >>>- get_default_realm usages replaced by api.env.realm >>>- fixed missing third kinit attempt in trust-fetch-domains >>>- removed rewrapping gssapi errors to ccache errors in krb_utils >>>- updated some parts of exception handling >> >>This patch doesn't seem to apply to master. Can you update it or >>indicate what you're patching against? Thanks! >> > >Attaching patch rebased on top of current master. My refactoring of com.redhat.idm.trust-fetch-domains went in yesterday so this patch will not apply anymore. Could you please rebase it? -- / Alexander Bokovoy From jcholast at redhat.com Wed Aug 19 09:55:45 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 11:55:45 +0200 Subject: [Freeipa-devel] [PATCH 0298] Server Upgrade: start DS before CA is started In-Reply-To: <55D44694.4010909@redhat.com> References: <55D365CF.7000508@redhat.com> <55D36806.4030608@redhat.com> <55D369C5.5050404@redhat.com> <55D44694.4010909@redhat.com> Message-ID: <55D452A1.6040406@redhat.com> On 19.8.2015 11:04, Jan Cholasta wrote: > On 18.8.2015 19:22, Martin Basti wrote: >> >> >> On 08/18/2015 07:14 PM, Martin Basti wrote: >>> >>> >>> On 08/18/2015 07:05 PM, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5232 >>>> >>>> Patch attached. >>>> >>>> >>> Self-NACK, I sent wrong patch >>> >>> >> >> The correct patch attached. > > Thanks, ACK. > > Pushed to: > master: 9fe67dcf2b6c10ca4eebab1c573d101316f481cd > ipa-4-2: 7924007a83a82674a495afe0e63a4bc85ab2a5ab Sorry, wrong information. Pushed to: master: 556e97bf23657cb11d93c7d8a37b5ed4840fdb7a ipa-4-2: 9cb6018367d958cdef03bef9780349b9651744a9 -- Jan Cholasta From mbasti at redhat.com Wed Aug 19 09:58:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Aug 2015 11:58:56 +0200 Subject: [Freeipa-devel] [PATCH] 371 Added support for changing vault encryption. In-Reply-To: <55CCCFC9.1060504@redhat.com> References: <55BFF741.6080302@redhat.com> <55CC9638.8060801@redhat.com> <55CCCFC9.1060504@redhat.com> Message-ID: <55D45360.4080003@redhat.com> On 08/13/2015 07:11 PM, Endi Sukma Dewata wrote: > On 8/13/2015 8:06 AM, Martin Basti wrote: >>> The vault-mod command has been modified to support changing vault >>> encryption attributes (i.e. type, password, public/private keys) >>> in addition to normal attributes (i.e. description). Changing the >>> encryption requires retrieving the stored secret with the old >>> attributes and rearchieving it with the new attributes. >>> >>> https://fedorahosted.org/freeipa/ticket/5176 >>> >> Hello, does this patch require any additional patches? >> >> I have current master branch and I cannot apply it. >> >> git am >> freeipa-edewata-0371-Added-support-for-changing-vault-encryption.patch -3 >> >> Applying: Added support for changing vault encryption. >> error: invalid object 100644 3b62822366a62c90f843a6293589c28383e782ef >> for 'ipalib/plugins/vault.py' >> fatal: git-write-tree: error building trees >> Repository lacks necessary blobs to fall back on 3-way merge. >> >> >> Martin^2 > > New patch attached. It requires patch #0369-3. > I cannot apply patch (and 369-3 was pushed) git am freeipa-edewata-0371-1-Added-support-for-changing-vault-encryption.patch -3 Applying: Added support for changing vault encryption. error: invalid object 100644 5d367b376ef41427ed983f3eafe120ed477018d2 for 'ipalib/plugins/vault.py' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. From dkupka at redhat.com Wed Aug 19 10:00:20 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 19 Aug 2015 12:00:20 +0200 Subject: [Freeipa-devel] Subject: [PATCH 0061-2] Fix backup/restore (#5071) In-Reply-To: <55D441E0.6070809@redhat.com> References: <55D42E80.3050909@redhat.com> <55D441E0.6070809@redhat.com> Message-ID: <55D453B4.6030506@redhat.com> On 19/08/15 10:44, David Kupka wrote: > On 19/08/15 09:21, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/5071 >> > Updated patches attached. > Removed copy-pasted returns. Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0062.2-Backup-resore-authentication-control-configuration.patch Type: text/x-patch Size: 4791 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 19 10:31:25 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 12:31:25 +0200 Subject: [Freeipa-devel] [PATCH] 0038 cert-request: remove allowed extensions check In-Reply-To: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> References: <20150813055400.GR16439@dhcp-40-8.bne.redhat.com> Message-ID: <55D45AFD.10707@redhat.com> On 13.8.2015 07:54, Fraser Tweedale wrote: > The attached patch fixes > https://fedorahosted.org/freeipa/ticket/5205 > > Thanks, > Fraser ACK. Pushed to: master: 02969d09d868907c6d2d5b2aee3089f2f5540dda ipa-4-2: 7723b3a677b7198bb59957c749d20053611bf32c Honza -- Jan Cholasta From dkupka at redhat.com Wed Aug 19 10:46:00 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 19 Aug 2015 12:46:00 +0200 Subject: [Freeipa-devel] [PATCH 0063] client: Update DNS with all available local IP addresses. In-Reply-To: <55D44719.5000306@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> <55D37349.8090201@redhat.com> <55D39B57.4040403@redhat.com> <55D44021.9090203@redhat.com> <55D44719.5000306@redhat.com> Message-ID: <55D45E68.10607@redhat.com> On 19/08/15 11:06, Jan Cholasta wrote: > On 19.8.2015 10:36, Martin Basti wrote: >> >> >> On 08/18/2015 10:53 PM, Martin Basti wrote: >>> >>> >>> On 08/18/2015 08:02 PM, David Kupka wrote: >>>> On 31/07/15 18:31, Martin Basti wrote: >>>>> On 28/07/15 09:52, David Kupka wrote: >>>>>> On 27/07/15 16:45, David Kupka wrote: >>>>>>> On 15/01/15 17:13, David Kupka wrote: >>>>>>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>>>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for patch: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) >>>>>>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>>>>>> - "Failed to connect to server >>>>>>>>>>>>> '%s'.", >>>>>>>>>>>>> server) >>>>>>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>>>>>> + except CalledProcessError as e: >>>>>>>>>>>>> + root_logger.error("Cannot update DNS records. %s" >>>>>>>>>>>>> % e) >>>>>>>>>>>>> >>>>>>>>>>>>> IMO the error message should be more specific, add there >>>>>>>>>>>>> something >>>>>>>>>>>>> like >>>>>>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>>>>>> >>>>>>>>>>>>> 2) >>>>>>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>>>>>> >>>>>>>>>>>>> .replace() is not needed >>>>>>>>>>>>> >>>>>>>>>>>>> 3) >>>>>>>>>>>>> + if len(ips) == 0: >>>>>>>>>>>>> >>>>>>>>>>>>> if not ips: >>>>>>>>>>>>> >>>>>>>>>>>>> is more pythonic by PEP8 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>>>>>> >>>>>>>>>>> merciful NACK >>>>>>>>>>> >>>>>>>>>>> Thank you for the patch, unfortunately I hit one issue which >>>>>>>>>>> needs >>>>>>>>>>> to be >>>>>>>>>>> resolved. >>>>>>>>>>> >>>>>>>>>>> If "sync PTR" is activated in zone settings, and reverse zone >>>>>>>>>>> doesn't >>>>>>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install >>>>>>>>>>> print >>>>>>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA >>>>>>>>>>> records was >>>>>>>>>>> succesfully updated, only PTR records failed. >>>>>>>>>>> >>>>>>>>>>> Bind log: >>>>>>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an >>>>>>>>>>> RR at >>>>>>>>>>> 'vm-101.example.com' AAAA >>>>>>>>>>> >>>>>>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for >>>>>>>>>>> A/AAAA >>>>>>>>>>> 'vm-101.example.com.' refused: unable to find active reverse >>>>>>>>>>> zone >>>>>>>>>>> for IP >>>>>>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>>>>>> >>>>>>>>>>> With IPv6 we have several addresses from different reverse >>>>>>>>>>> zones and >>>>>>>>>>> this situation may happen often. >>>>>>>>>>> I suggest following: >>>>>>>>>>> 1) Print list of addresses which will be updated. (Now if update >>>>>>>>>>> fails, >>>>>>>>>>> user needs to read log, which addresses installer tried to >>>>>>>>>>> update) >>>>>>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR record are >>>>>>>>>>> there >>>>>>>>>>> and print proper error message >>>>>>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>>>>>> particular >>>>>>>>>>> IP address. >>>>>>>>>>> >>>>>>>>>>> Any other suggestions are welcome. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> After long discussion with DNS and UX guru I've implemented it >>>>>>>>>> this >>>>>>>>>> way: >>>>>>>>>> 1. Call nsupdate only once with all updates. >>>>>>>>>> 2. Verify that the expected records are resolvable. >>>>>>>>>> 3. If no print list of missing A/AAAA, list of missing PTR >>>>>>>>>> records >>>>>>>>>> and >>>>>>>>>> list to mismatched PTR record. >>>>>>>>>> >>>>>>>>>> As this is running inside client we can't much more and it's >>>>>>>>>> up to >>>>>>>>>> user >>>>>>>>>> to check what's rotten in his DNS setup. >>>>>>>>>> >>>>>>>>>> Updated patch attached. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> One more change to behave well in -crazy- exotic environments that >>>>>>>>> resolves more PTR records for single IP. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-devel mailing list >>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>> >>>>>>>> >>>>>>>> Yet another change to make language nerds and our UX guru happy :-) >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>> >>>>>>> >>>>>>> Rebased patch attached. >>>>>>> >>>>>>> >>>>>> Updated patch attached. >>>>>> >>>>> Just for record this patch is for dualstack/IPv6 support. >>>>> IMO this ticket also requires to fix ipa-join to support IPv6. >>>>> >>>>> I still have doubts to have multihomed support as default, this may be >>>>> unexpected change of ipa-client-install behavior. >>>>> I know, is hard to detect which addresses user want to register in IPA >>>>> without crystal ball, but it should not be impossible :-) . >>>>> >>>>> I propose following solution: >>>>> >>>>> To add new options: >>>>> --multihomed or --all-ip-address - all IP addresses from client >>>>> will be >>>>> used >>>>> --ip-address - adress which will be registered on (IPA) DNS server >>>>> --ip-address-interface - interface from which address will be >>>>> registered >>>>> >>>>> >>>>> 0) without any option specified, current behavior will be used + IPv6 >>>>> * detect which address is used to communicate with IPA server >>>>> * detect interface where this address belongs >>>>> * use ipv4 and all ipv6 addresses of this interface >>>>> * if --enable-dns-updates=true: configure SSSD as is configured now: >>>>> automatically detect which address is used + patched SSSD will also >>>>> updates proper IPv6 address >>>>> >>>>> 1) --multihomed or --all-ip-addresses (this is multihomed ticket) >>>>> * all adresses will be used >>>>> * if --enable-dns-updates=true: SSSD will be configured to send all >>>>> ip_addresses >>>>> >>>>> 2) --ip-address option specified: >>>>> * only specified addresses will be used (+ check if this addresses >>>>> exist >>>>> locally) >>>>> * if --enable-dns-updates=true: ERROR dynamic updates may change this >>>>> address (user should choose static vs dynamic) >>>>> >>>>> 3) --ip-address-interface option specified: >>>>> * only addresses from specified interfaces will be used >>>>> * if --enable-dns-updates=true: SSSD will be configured to use these >>>>> interfaces to get addresses that will be dynamically updated on dns >>>>> >>>>> Modification of current patch should not be hard, we already have >>>>> almost >>>>> everything implemented: >>>>> * method get_local_addresses should return dict {interface:[list of >>>>> addresses]}, this can be used in all of 4 cases. >>>>> * restore original function to detect IP address used to communicate >>>>> with IPA server >>>>> >>>>> I insist on 0) and 1), others may be stretch goal (easy to implement) >>>>> (It would be shame to not implemented multihomed support together with >>>>> this ticket, as it requires max 5 extra lines of code) >>>>> >>>>> Seems my proposal reasonable? >>>>> >>>>> What is you opinion Martin? Should we just use all addresses to be >>>>> registered, or try to keep old behavior as much as possible? >>>>> >>>>> Martin^2 >>>>> >>>> >>>> 0-2 implemented, IMO there is no real use-case for 3. It can be added >>>> later when/if there is need. >>>> Updated patch (+ rebase for ipa-4-2 branch) attached. >>>> >>> >>> ACK, I just modified typo in --ip-address help message before push. >>> >>> SSSD guys (Pavel CCed) will provide SSSD srpm that should go to our >>> freeipa-master copr. Then we will bump required SSSD version in >>> specfile. >>> >>> Pushed to ipa-4-2: ff34125bcaa99898859cb8ceefea88a4497959b3 >>> Pushed to master: 8ba1392a3903894dda06c733bf37853c6cc3108c >>> >> Attached patch bumps required version of SSSD (available in >> freeipa-master copr) > > ACK. > > Pushed to: > master: 9fe67dcf2b6c10ca4eebab1c573d101316f481cd > ipa-4-2: 7924007a83a82674a495afe0e63a4bc85ab2a5ab > man page update. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0063-client-Add-description-of-ip-address-and-all-ip-addr.patch Type: text/x-patch Size: 1186 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 19 11:12:09 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Aug 2015 13:12:09 +0200 Subject: [Freeipa-devel] [PATCH 0063] client: Update DNS with all available local IP addresses. In-Reply-To: <55D45E68.10607@redhat.com> References: <54AD182D.2050803@redhat.com> <54AD4D91.3020101@redhat.com> <54AFDB04.7000902@redhat.com> <54B405BD.30100@redhat.com> <54B7A7EF.2020100@redhat.com> <54B7CD0B.7080008@redhat.com> <54B7E742.4060602@redhat.com> <55B64421.6080006@redhat.com> <55B734D4.3060003@redhat.com> <55BBA2ED.4050201@redhat.com> <55D37349.8090201@redhat.com> <55D39B57.4040403@redhat.com> <55D44021.9090203@redhat.com> <55D44719.5000306@redhat.com> <55D45E68.10607@redhat.com> Message-ID: <55D46489.5050804@redhat.com> On 08/19/2015 12:46 PM, David Kupka wrote: > On 19/08/15 11:06, Jan Cholasta wrote: >> On 19.8.2015 10:36, Martin Basti wrote: >>> >>> >>> On 08/18/2015 10:53 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/18/2015 08:02 PM, David Kupka wrote: >>>>> On 31/07/15 18:31, Martin Basti wrote: >>>>>> On 28/07/15 09:52, David Kupka wrote: >>>>>>> On 27/07/15 16:45, David Kupka wrote: >>>>>>>> On 15/01/15 17:13, David Kupka wrote: >>>>>>>>> On 01/15/2015 03:22 PM, David Kupka wrote: >>>>>>>>>> On 01/15/2015 12:43 PM, David Kupka wrote: >>>>>>>>>>> On 01/12/2015 06:34 PM, Martin Basti wrote: >>>>>>>>>>>> On 09/01/15 14:43, David Kupka wrote: >>>>>>>>>>>>> On 01/07/2015 04:15 PM, Martin Basti wrote: >>>>>>>>>>>>>> On 07/01/15 12:27, David Kupka wrote: >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4249 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for patch: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> - root_logger.error("Cannot update DNS records! " >>>>>>>>>>>>>> - "Failed to connect to server >>>>>>>>>>>>>> '%s'.", >>>>>>>>>>>>>> server) >>>>>>>>>>>>>> + ips = get_local_ipaddresses() >>>>>>>>>>>>>> + except CalledProcessError as e: >>>>>>>>>>>>>> + root_logger.error("Cannot update DNS records. %s" >>>>>>>>>>>>>> % e) >>>>>>>>>>>>>> >>>>>>>>>>>>>> IMO the error message should be more specific, add there >>>>>>>>>>>>>> something >>>>>>>>>>>>>> like >>>>>>>>>>>>>> "Unable to get local IP addresses". at least in log.debug() >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) >>>>>>>>>>>>>> + lines = ipresult[0].replace('\\', '').split('\n') >>>>>>>>>>>>>> >>>>>>>>>>>>>> .replace() is not needed >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) >>>>>>>>>>>>>> + if len(ips) == 0: >>>>>>>>>>>>>> >>>>>>>>>>>>>> if not ips: >>>>>>>>>>>>>> >>>>>>>>>>>>>> is more pythonic by PEP8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for catching these. Updated patch attached. >>>>>>>>>>>>> >>>>>>>>>>>> merciful NACK >>>>>>>>>>>> >>>>>>>>>>>> Thank you for the patch, unfortunately I hit one issue which >>>>>>>>>>>> needs >>>>>>>>>>>> to be >>>>>>>>>>>> resolved. >>>>>>>>>>>> >>>>>>>>>>>> If "sync PTR" is activated in zone settings, and reverse zone >>>>>>>>>>>> doesn't >>>>>>>>>>>> exists, nsupdate/BIND returns SERVFAIL and ipa-client-install >>>>>>>>>>>> print >>>>>>>>>>>> Error message, 'DNS update failed'. In fact, all A/AAAA >>>>>>>>>>>> records was >>>>>>>>>>>> succesfully updated, only PTR records failed. >>>>>>>>>>>> >>>>>>>>>>>> Bind log: >>>>>>>>>>>> named-pkcs11[28652]: updating zone 'example.com/IN': adding an >>>>>>>>>>>> RR at >>>>>>>>>>>> 'vm-101.example.com' AAAA >>>>>>>>>>>> >>>>>>>>>>>> named-pkcs11[28652]: PTR record synchronization (addition) for >>>>>>>>>>>> A/AAAA >>>>>>>>>>>> 'vm-101.example.com.' refused: unable to find active reverse >>>>>>>>>>>> zone >>>>>>>>>>>> for IP >>>>>>>>>>>> address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found >>>>>>>>>>>> >>>>>>>>>>>> With IPv6 we have several addresses from different reverse >>>>>>>>>>>> zones and >>>>>>>>>>>> this situation may happen often. >>>>>>>>>>>> I suggest following: >>>>>>>>>>>> 1) Print list of addresses which will be updated. (Now if >>>>>>>>>>>> update >>>>>>>>>>>> fails, >>>>>>>>>>>> user needs to read log, which addresses installer tried to >>>>>>>>>>>> update) >>>>>>>>>>>> 2) Split nsupdates per A/AAAA record. >>>>>>>>>>>> 3a) If failed, check with DNS query if A/AAAA and PTR >>>>>>>>>>>> record are >>>>>>>>>>>> there >>>>>>>>>>>> and print proper error message >>>>>>>>>>>> 3b) Just print A/AAAA (or PTR) record may not be updated for >>>>>>>>>>>> particular >>>>>>>>>>>> IP address. >>>>>>>>>>>> >>>>>>>>>>>> Any other suggestions are welcome. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After long discussion with DNS and UX guru I've implemented it >>>>>>>>>>> this >>>>>>>>>>> way: >>>>>>>>>>> 1. Call nsupdate only once with all updates. >>>>>>>>>>> 2. Verify that the expected records are resolvable. >>>>>>>>>>> 3. If no print list of missing A/AAAA, list of missing PTR >>>>>>>>>>> records >>>>>>>>>>> and >>>>>>>>>>> list to mismatched PTR record. >>>>>>>>>>> >>>>>>>>>>> As this is running inside client we can't much more and it's >>>>>>>>>>> up to >>>>>>>>>>> user >>>>>>>>>>> to check what's rotten in his DNS setup. >>>>>>>>>>> >>>>>>>>>>> Updated patch attached. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> One more change to behave well in -crazy- exotic environments >>>>>>>>>> that >>>>>>>>>> resolves more PTR records for single IP. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-devel mailing list >>>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yet another change to make language nerds and our UX guru >>>>>>>>> happy :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-devel mailing list >>>>>>>>> Freeipa-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>>>> >>>>>>>> >>>>>>>> Rebased patch attached. >>>>>>>> >>>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>> Just for record this patch is for dualstack/IPv6 support. >>>>>> IMO this ticket also requires to fix ipa-join to support IPv6. >>>>>> >>>>>> I still have doubts to have multihomed support as default, this >>>>>> may be >>>>>> unexpected change of ipa-client-install behavior. >>>>>> I know, is hard to detect which addresses user want to register >>>>>> in IPA >>>>>> without crystal ball, but it should not be impossible :-) . >>>>>> >>>>>> I propose following solution: >>>>>> >>>>>> To add new options: >>>>>> --multihomed or --all-ip-address - all IP addresses from client >>>>>> will be >>>>>> used >>>>>> --ip-address - adress which will be registered on (IPA) DNS server >>>>>> --ip-address-interface - interface from which address will be >>>>>> registered >>>>>> >>>>>> >>>>>> 0) without any option specified, current behavior will be used + >>>>>> IPv6 >>>>>> * detect which address is used to communicate with IPA server >>>>>> * detect interface where this address belongs >>>>>> * use ipv4 and all ipv6 addresses of this interface >>>>>> * if --enable-dns-updates=true: configure SSSD as is configured now: >>>>>> automatically detect which address is used + patched SSSD will also >>>>>> updates proper IPv6 address >>>>>> >>>>>> 1) --multihomed or --all-ip-addresses (this is multihomed ticket) >>>>>> * all adresses will be used >>>>>> * if --enable-dns-updates=true: SSSD will be configured to send all >>>>>> ip_addresses >>>>>> >>>>>> 2) --ip-address option specified: >>>>>> * only specified addresses will be used (+ check if this addresses >>>>>> exist >>>>>> locally) >>>>>> * if --enable-dns-updates=true: ERROR dynamic updates may change >>>>>> this >>>>>> address (user should choose static vs dynamic) >>>>>> >>>>>> 3) --ip-address-interface option specified: >>>>>> * only addresses from specified interfaces will be used >>>>>> * if --enable-dns-updates=true: SSSD will be configured to use these >>>>>> interfaces to get addresses that will be dynamically updated on dns >>>>>> >>>>>> Modification of current patch should not be hard, we already have >>>>>> almost >>>>>> everything implemented: >>>>>> * method get_local_addresses should return dict {interface:[list of >>>>>> addresses]}, this can be used in all of 4 cases. >>>>>> * restore original function to detect IP address used to communicate >>>>>> with IPA server >>>>>> >>>>>> I insist on 0) and 1), others may be stretch goal (easy to >>>>>> implement) >>>>>> (It would be shame to not implemented multihomed support together >>>>>> with >>>>>> this ticket, as it requires max 5 extra lines of code) >>>>>> >>>>>> Seems my proposal reasonable? >>>>>> >>>>>> What is you opinion Martin? Should we just use all addresses to be >>>>>> registered, or try to keep old behavior as much as possible? >>>>>> >>>>>> Martin^2 >>>>>> >>>>> >>>>> 0-2 implemented, IMO there is no real use-case for 3. It can be added >>>>> later when/if there is need. >>>>> Updated patch (+ rebase for ipa-4-2 branch) attached. >>>>> >>>> >>>> ACK, I just modified typo in --ip-address help message before push. >>>> >>>> SSSD guys (Pavel CCed) will provide SSSD srpm that should go to our >>>> freeipa-master copr. Then we will bump required SSSD version in >>>> specfile. >>>> >>>> Pushed to ipa-4-2: ff34125bcaa99898859cb8ceefea88a4497959b3 >>>> Pushed to master: 8ba1392a3903894dda06c733bf37853c6cc3108c >>>> >>> Attached patch bumps required version of SSSD (available in >>> freeipa-master copr) >> >> ACK. >> >> Pushed to: >> master: 9fe67dcf2b6c10ca4eebab1c573d101316f481cd >> ipa-4-2: 7924007a83a82674a495afe0e63a4bc85ab2a5ab >> > > man page update. ACK Pushed to: master: f160aa3d0a3f8714463c12dac1acc479d1e18a8d ipa-4-2: d0c41bd2f2d125fa591b13c602c125a2a112a6c7 From mbasti at redhat.com Wed Aug 19 11:38:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Aug 2015 13:38:46 +0200 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55D1CEBF.3010405@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> <55CD7524.9080307@redhat.com> <55CDD5B9.1050105@redhat.com> <55D1A531.4020309@redhat.com> <55D1B9DF.4060109@redhat.com> <55D1CEBF.3010405@redhat.com> Message-ID: <55D46AC6.9080803@redhat.com> On 08/17/2015 02:08 PM, Abhijeet Kasurde wrote: > Hi All, > > I have included all review comments. Please let me know your views. > > On 08/17/2015 04:09 PM, Martin Basti wrote: >> >> >> On 08/17/2015 11:11 AM, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> Please find the update patch with review comments, >>> >>> >>> On 08/14/2015 05:19 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/14/2015 06:57 AM, Abhijeet Kasurde wrote: >>>>> >>>>> On 08/13/2015 07:08 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/3406 >>>>>>> >>>>>>> Thanks, >>>>>>> Abhijeet Kasurde >>>>>>> >>>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> thank you for the patch >>>>>> >>>>>> 1) >>>>>> - except ValueError: >>>>>> + except EOFError, ValueError: >>>>>> >>>>>> Please use >>>>>> except (EOFError, ValueError): >>>>>> https://docs.python.org/2/tutorial/errors.html#handling-exceptions >>>>> OK, I will include this. >>>>>> 2) >>>>>> I'm not sure if this code will work (I did not test it) >>>>>> >>>>>> I expect when stdin is closed, this will result into infinite >>>>>> loop, because raw_input will always return EOFError. >>>>>> >>>>>> while True: >>>>>> try: >>>>>> ret = raw_input("%s: " % prompt) >>>>>> if allow_empty or ret.strip(): >>>>>> return ret >>>>>> except EOFError: >>>>>> pass >>>>>> >>>>> Could you please elaborate more on, so that I can include fix in >>>>> this section of code? >>>> If you receive EOF you cannot continue in while cycle because, it >>>> will return EOF every iteration forever. >>>> >>>> If EOF is received the while cycle must end, and appropriate action >>>> must be take. >>>> It depends on situation, if default value is present then default >>>> value should be used, or in case if empty value is allowed, empty >>>> string should be returned. >>>> >>>> In case there is no default value and empty value is not allowed, >>>> then an exception should be raised. >>>> >>>> Martin^2 >>> >> NACK >> >> There is still infinity loop. >> 1) >> + except EOFError: >> + if allow_empty: >> + return '' >> >> This will continue in while cycle if allow_empty=False, you need to raise exception there. >> >> 2) >> Why so complicated? just return default looks enough to me. >> + except EOFError: >> + if choice.lower()[0] == "y": >> + return True >> + elif choice.lower()[0] == "n": >> + return False >> 3) >> Remove this change please >> - >> def get_gsserror(e): >> > > > NACK 1) Your commit message does not reflect the changes you made in code. The patch just solves the EOFError not Value error or "various errors" 2) You removed if statement which should be there. I expected something like this in first case. while True: - ret = raw_input("%s: " % prompt) - if allow_empty or ret.strip(): - return ret + try: + ret = raw_input("%s: " % prompt) + if allow_empty or ret.strip(): + return ret + except EOFError: + if allow_empty: + return '' + raise RuntimeError("Failed to get user input") Thanks Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheimes at redhat.com Wed Aug 19 11:39:02 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 19 Aug 2015 13:39:02 +0200 Subject: [Freeipa-devel] [PATCH 023] Add flag to list all service and user vaults Message-ID: <55D46AD6.3070606@redhat.com> The vault-find plugin has two additional arguments to list all service vaults or user vaults. Since the name of a vault is only unique for a particular user or service, the commands also print the vault user or vault service. The virtual attributes were added in rev 01dd951ddc0181b559eb3dd5ff0336c81e245628. Example: $ ipa vault-find --users ---------------- 2 vaults matched ---------------- Vault name: myvault Type: standard Vault user: admin Vault name: UserVault Type: standard Vault user: admin ---------------------------- Number of entries returned 2 ---------------------------- $ ipa vault-find --services ---------------- 2 vaults matched ---------------- Vault name: myvault Type: standard Vault service: HTTP/ipatest.freeipa.local at FREEIPA.LOCAL Vault name: myvault Type: standard Vault service: ldap/ipatest.freeipa.local at FREEIPA.LOCAL ---------------------------- Number of entries returned 2 ---------------------------- https://fedorahosted.org/freeipa/ticket/5150 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0023-Add-flag-to-list-all-service-and-user-vaults.patch Type: text/x-patch Size: 3982 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From akasurde at redhat.com Wed Aug 19 11:49:54 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Wed, 19 Aug 2015 17:19:54 +0530 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55D46AC6.9080803@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> <55CD7524.9080307@redhat.com> <55CDD5B9.1050105@redhat.com> <55D1A531.4020309@redhat.com> <55D1B9DF.4060109@redhat.com> <55D1CEBF.3010405@redhat.com> <55D46AC6.9080803@redhat.com> Message-ID: <55D46D62.4070806@redhat.com> Hi All, Please find the latest patch with review comments included. Thanks Martin for your help and review comments. Thanks, Abhijeet Kasurde On 08/19/2015 05:08 PM, Martin Basti wrote: > > > On 08/17/2015 02:08 PM, Abhijeet Kasurde wrote: >> Hi All, >> >> I have included all review comments. Please let me know your views. >> >> On 08/17/2015 04:09 PM, Martin Basti wrote: >>> >>> >>> On 08/17/2015 11:11 AM, Abhijeet Kasurde wrote: >>>> Hi All, >>>> >>>> Please find the update patch with review comments, >>>> >>>> >>>> On 08/14/2015 05:19 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/14/2015 06:57 AM, Abhijeet Kasurde wrote: >>>>>> >>>>>> On 08/13/2015 07:08 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> This patch fixes bug - >>>>>>>> https://fedorahosted.org/freeipa/ticket/3406 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Abhijeet Kasurde >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> thank you for the patch >>>>>>> >>>>>>> 1) >>>>>>> - except ValueError: >>>>>>> + except EOFError, ValueError: >>>>>>> >>>>>>> Please use >>>>>>> except (EOFError, ValueError): >>>>>>> https://docs.python.org/2/tutorial/errors.html#handling-exceptions >>>>>> OK, I will include this. >>>>>>> 2) >>>>>>> I'm not sure if this code will work (I did not test it) >>>>>>> >>>>>>> I expect when stdin is closed, this will result into infinite >>>>>>> loop, because raw_input will always return EOFError. >>>>>>> >>>>>>> while True: >>>>>>> try: >>>>>>> ret = raw_input("%s: " % prompt) >>>>>>> if allow_empty or ret.strip(): >>>>>>> return ret >>>>>>> except EOFError: >>>>>>> pass >>>>>>> >>>>>> Could you please elaborate more on, so that I can include fix in >>>>>> this section of code? >>>>> If you receive EOF you cannot continue in while cycle because, it >>>>> will return EOF every iteration forever. >>>>> >>>>> If EOF is received the while cycle must end, and appropriate >>>>> action must be take. >>>>> It depends on situation, if default value is present then default >>>>> value should be used, or in case if empty value is allowed, empty >>>>> string should be returned. >>>>> >>>>> In case there is no default value and empty value is not allowed, >>>>> then an exception should be raised. >>>>> >>>>> Martin^2 >>>> >>> NACK >>> >>> There is still infinity loop. >>> 1) >>> + except EOFError: >>> + if allow_empty: >>> + return '' >>> >>> This will continue in while cycle if allow_empty=False, you need to raise exception there. >>> >>> 2) >>> Why so complicated? just return default looks enough to me. >>> + except EOFError: >>> + if choice.lower()[0] == "y": >>> + return True >>> + elif choice.lower()[0] == "n": >>> + return False >>> 3) >>> Remove this change please >>> - >>> def get_gsserror(e): >>> >> >> >> > NACK > > 1) > Your commit message does not reflect the changes you made in code. The > patch just solves the EOFError not Value error or "various errors" > > 2) > You removed if statement which should be there. I expected something > like this in first case. > while True: > - ret = raw_input("%s: " % prompt) > - if allow_empty or ret.strip(): > - return ret > + try: > + ret = raw_input("%s: " % prompt) > + if allow_empty or ret.strip(): > + return ret > + except EOFError: > + if allow_empty: > + return '' > + raise RuntimeError("Failed to get user input") > Thanks > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-4-try-except-block-in-ipautil.patch Type: text/x-patch Size: 3053 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Aug 19 11:52:38 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 19 Aug 2015 13:52:38 +0200 Subject: [Freeipa-devel] Subject: [PATCH 0061-2] Fix backup/restore (#5071) In-Reply-To: <55D453B4.6030506@redhat.com> References: <55D42E80.3050909@redhat.com> <55D441E0.6070809@redhat.com> <55D453B4.6030506@redhat.com> Message-ID: <55D46E06.7090507@redhat.com> On 08/19/2015 12:00 PM, David Kupka wrote: > On 19/08/15 10:44, David Kupka wrote: >> On 19/08/15 09:21, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/5071 >>> >> Updated patches attached. >> > Removed copy-pasted returns. Updated patch attached. > > > ACK -- Martin^3 Babinsky From jcholast at redhat.com Wed Aug 19 12:12:09 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 14:12:09 +0200 Subject: [Freeipa-devel] [PATCH 023] Add flag to list all service and user vaults In-Reply-To: <55D46AD6.3070606@redhat.com> References: <55D46AD6.3070606@redhat.com> Message-ID: <55D47299.2060802@redhat.com> Hi, On 19.8.2015 13:39, Christian Heimes wrote: > The vault-find plugin has two additional arguments to list all > service vaults or user vaults. Since the name of a vault is only unique > for a particular user or service, the commands also print the vault user > or vault service. The virtual attributes were added in rev > 01dd951ddc0181b559eb3dd5ff0336c81e245628. > > Example: > > $ ipa vault-find --users > ---------------- > 2 vaults matched > ---------------- > Vault name: myvault > Type: standard > Vault user: admin > > Vault name: UserVault > Type: standard > Vault user: admin > ---------------------------- > Number of entries returned 2 > ---------------------------- > > $ ipa vault-find --services > ---------------- > 2 vaults matched > ---------------- > Vault name: myvault > Type: standard > Vault service: HTTP/ipatest.freeipa.local at FREEIPA.LOCAL > > Vault name: myvault > Type: standard > Vault service: ldap/ipatest.freeipa.local at FREEIPA.LOCAL > ---------------------------- > Number of entries returned 2 > ---------------------------- > > https://fedorahosted.org/freeipa/ticket/5150 The new flags should be handled in vault_find's pre_callback instead of vault's get_dn, as they are exclusive to vault_find and worse yet, conflict with vault_{add,remove}_{owner,member}'s flags, leading to unwanted behavior: $ ipa vault-add-member --service testsvc/example.com testvault --services testsvc/example.com ipa: ERROR: Service(s), shared, and user(s) options cannot be specified simultaneously Honza -- Jan Cholasta From jcholast at redhat.com Wed Aug 19 12:13:19 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 14:13:19 +0200 Subject: [Freeipa-devel] Subject: [PATCH 0061-2] Fix backup/restore (#5071) In-Reply-To: <55D46E06.7090507@redhat.com> References: <55D42E80.3050909@redhat.com> <55D441E0.6070809@redhat.com> <55D453B4.6030506@redhat.com> <55D46E06.7090507@redhat.com> Message-ID: <55D472DF.10500@redhat.com> On 19.8.2015 13:52, Martin Babinsky wrote: > On 08/19/2015 12:00 PM, David Kupka wrote: >> On 19/08/15 10:44, David Kupka wrote: >>> On 19/08/15 09:21, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/5071 >>>> >>> Updated patches attached. >>> >> Removed copy-pasted returns. Updated patch attached. >> >> >> > ACK > Pushed to: master: db88985c0d4920191b840b5d04d133015293dbe0 ipa-4-2: 4fe994b11f7e5978c969626dedc593b7357b7fd2 -- Jan Cholasta From pvoborni at redhat.com Wed Aug 19 12:17:57 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Aug 2015 14:17:57 +0200 Subject: [Freeipa-devel] [PATCH 023] Add flag to list all service and user vaults In-Reply-To: <55D47299.2060802@redhat.com> References: <55D46AD6.3070606@redhat.com> <55D47299.2060802@redhat.com> Message-ID: <55D473F5.4090000@redhat.com> On 08/19/2015 02:12 PM, Jan Cholasta wrote: > Hi, > > On 19.8.2015 13:39, Christian Heimes wrote: >> The vault-find plugin has two additional arguments to list all >> service vaults or user vaults. Since the name of a vault is only unique >> for a particular user or service, the commands also print the vault user >> or vault service. The virtual attributes were added in rev >> 01dd951ddc0181b559eb3dd5ff0336c81e245628. >> >> Example: >> >> $ ipa vault-find --users >> ---------------- >> 2 vaults matched >> ---------------- >> Vault name: myvault >> Type: standard >> Vault user: admin >> >> Vault name: UserVault >> Type: standard >> Vault user: admin >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> $ ipa vault-find --services >> ---------------- >> 2 vaults matched >> ---------------- >> Vault name: myvault >> Type: standard >> Vault service: HTTP/ipatest.freeipa.local at FREEIPA.LOCAL >> >> Vault name: myvault >> Type: standard >> Vault service: ldap/ipatest.freeipa.local at FREEIPA.LOCAL >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> https://fedorahosted.org/freeipa/ticket/5150 > > The new flags should be handled in vault_find's pre_callback instead of > vault's get_dn, as they are exclusive to vault_find and worse yet, > conflict with vault_{add,remove}_{owner,member}'s flags, leading to > unwanted behavior: > > $ ipa vault-add-member --service testsvc/example.com testvault > --services testsvc/example.com > ipa: ERROR: Service(s), shared, and user(s) options cannot be specified > simultaneously > > Honza > Also you forgot to update API.txt and VERSION ./makeapi -- Petr Vobornik From cheimes at redhat.com Wed Aug 19 12:39:32 2015 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 19 Aug 2015 14:39:32 +0200 Subject: [Freeipa-devel] [PATCH 023] Add flag to list all service and user vaults In-Reply-To: <55D47299.2060802@redhat.com> References: <55D46AD6.3070606@redhat.com> <55D47299.2060802@redhat.com> Message-ID: <55D47904.8090804@redhat.com> On 2015-08-19 14:12, Jan Cholasta wrote: > The new flags should be handled in vault_find's pre_callback instead of > vault's get_dn, as they are exclusive to vault_find and worse yet, > conflict with vault_{add,remove}_{owner,member}'s flags, leading to > unwanted behavior: > > $ ipa vault-add-member --service testsvc/example.com testvault > --services testsvc/example.com > ipa: ERROR: Service(s), shared, and user(s) options cannot be specified > simultaneously Here is an updated patch. The new flags are now handled by the pre_callback method. I have regenerated API.txt, too. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0023-2-Add-flag-to-list-all-service-and-user-vaults.patch Type: text/x-patch Size: 5875 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jcholast at redhat.com Wed Aug 19 12:48:41 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Aug 2015 14:48:41 +0200 Subject: [Freeipa-devel] [PATCH 023] Add flag to list all service and user vaults In-Reply-To: <55D47904.8090804@redhat.com> References: <55D46AD6.3070606@redhat.com> <55D47299.2060802@redhat.com> <55D47904.8090804@redhat.com> Message-ID: <55D47B29.7020101@redhat.com> On 19.8.2015 14:39, Christian Heimes wrote: > On 2015-08-19 14:12, Jan Cholasta wrote: >> The new flags should be handled in vault_find's pre_callback instead of >> vault's get_dn, as they are exclusive to vault_find and worse yet, >> conflict with vault_{add,remove}_{owner,member}'s flags, leading to >> unwanted behavior: >> >> $ ipa vault-add-member --service testsvc/example.com testvault >> --services testsvc/example.com >> ipa: ERROR: Service(s), shared, and user(s) options cannot be specified >> simultaneously > > Here is an updated patch. The new flags are now handled by the > pre_callback method. I have regenerated API.txt, too. > > Christian > Thanks, ACK. Bumped VERSION and pushed to: master: 0abaf195dc3b0920d2439dd4ec6df61e0aadc4f9 ipa-4-2: 89c9feaf93299c96bb227b3705246193a1de1d82 Honza -- Jan Cholasta From mbabinsk at redhat.com Wed Aug 19 12:54:29 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 19 Aug 2015 14:54:29 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user Message-ID: <55D47C85.6050008@redhat.com> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from happening. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0060-raise-an-error-when-trying-to-preserve-an-already-pr.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: From ldoudova at redhat.com Wed Aug 19 13:40:06 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 19 Aug 2015 15:40:06 +0200 Subject: [Freeipa-devel] [PATCH 0003] TEST: Stageuser plugin In-Reply-To: <55D2F0AF.8020003@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> <55D2F0AF.8020003@redhat.com> Message-ID: <55D48736.7000302@redhat.com> Hi, I'm sending additional patch for stageuser plugin tests. It applies on top of 0002.3 patch sent earlier and reflects the change of 'stageuser-add --from-delete' command to 'user-stage'. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0003-Updated-automated-test-for-stageuser-plugin.patch Type: text/x-patch Size: 6529 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 19 13:45:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Aug 2015 15:45:48 +0200 Subject: [Freeipa-devel] [PATCH] Added try/except for error handling ipautil In-Reply-To: <55D46D62.4070806@redhat.com> References: <55C88F57.6000500@redhat.com> <55CC9DB9.5000705@redhat.com> <55CD7524.9080307@redhat.com> <55CDD5B9.1050105@redhat.com> <55D1A531.4020309@redhat.com> <55D1B9DF.4060109@redhat.com> <55D1CEBF.3010405@redhat.com> <55D46AC6.9080803@redhat.com> <55D46D62.4070806@redhat.com> Message-ID: <55D4888C.30401@redhat.com> On 08/19/2015 01:49 PM, Abhijeet Kasurde wrote: > Hi All, > > > Please find the latest patch with review comments included. > > Thanks Martin for your help and review comments. > > Thanks, > Abhijeet Kasurde > > On 08/19/2015 05:08 PM, Martin Basti wrote: >> >> >> On 08/17/2015 02:08 PM, Abhijeet Kasurde wrote: >>> Hi All, >>> >>> I have included all review comments. Please let me know your views. >>> >>> On 08/17/2015 04:09 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/17/2015 11:11 AM, Abhijeet Kasurde wrote: >>>>> Hi All, >>>>> >>>>> Please find the update patch with review comments, >>>>> >>>>> >>>>> On 08/14/2015 05:19 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/14/2015 06:57 AM, Abhijeet Kasurde wrote: >>>>>>> >>>>>>> On 08/13/2015 07:08 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/10/2015 01:47 PM, Abhijeet Kasurde wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> This patch fixes bug - >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3406 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Abhijeet Kasurde >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> thank you for the patch >>>>>>>> >>>>>>>> 1) >>>>>>>> - except ValueError: >>>>>>>> + except EOFError, ValueError: >>>>>>>> >>>>>>>> Please use >>>>>>>> except (EOFError, ValueError): >>>>>>>> https://docs.python.org/2/tutorial/errors.html#handling-exceptions >>>>>>> OK, I will include this. >>>>>>>> 2) >>>>>>>> I'm not sure if this code will work (I did not test it) >>>>>>>> >>>>>>>> I expect when stdin is closed, this will result into infinite >>>>>>>> loop, because raw_input will always return EOFError. >>>>>>>> >>>>>>>> while True: >>>>>>>> try: >>>>>>>> ret = raw_input("%s: " % prompt) >>>>>>>> if allow_empty or ret.strip(): >>>>>>>> return ret >>>>>>>> except EOFError: >>>>>>>> pass >>>>>>>> >>>>>>> Could you please elaborate more on, so that I can include fix in >>>>>>> this section of code? >>>>>> If you receive EOF you cannot continue in while cycle because, it >>>>>> will return EOF every iteration forever. >>>>>> >>>>>> If EOF is received the while cycle must end, and appropriate >>>>>> action must be take. >>>>>> It depends on situation, if default value is present then default >>>>>> value should be used, or in case if empty value is allowed, empty >>>>>> string should be returned. >>>>>> >>>>>> In case there is no default value and empty value is not allowed, >>>>>> then an exception should be raised. >>>>>> >>>>>> Martin^2 >>>>> >>>> NACK >>>> >>>> There is still infinity loop. >>>> 1) >>>> + except EOFError: >>>> + if allow_empty: >>>> + return '' >>>> >>>> This will continue in while cycle if allow_empty=False, you need to raise exception there. >>>> >>>> 2) >>>> Why so complicated? just return default looks enough to me. >>>> + except EOFError: >>>> + if choice.lower()[0] == "y": >>>> + return True >>>> + elif choice.lower()[0] == "n": >>>> + return False >>>> 3) >>>> Remove this change please >>>> - >>>> def get_gsserror(e): >>>> >>> >>> >>> >> NACK >> >> 1) >> Your commit message does not reflect the changes you made in code. >> The patch just solves the EOFError not Value error or "various errors" >> >> 2) >> You removed if statement which should be there. I expected something >> like this in first case. >> while True: >> - ret = raw_input("%s: " % prompt) >> - if allow_empty or ret.strip(): >> - return ret >> + try: >> + ret = raw_input("%s: " % prompt) >> + if allow_empty or ret.strip(): >> + return ret >> + except EOFError: >> + if allow_empty: >> + return '' >> + raise RuntimeError("Failed to get user input") >> Thanks >> Martin > ACK Pushed to master: 7c48621bb8e9efc47c68bb7b4af936da93325050 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Aug 19 14:17:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Aug 2015 16:17:48 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55D429A1.3000605@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> Message-ID: <55D4900C.5040509@redhat.com> I got this: https://paste.fedoraproject.org/256746/43999380/ On 08/19/2015 09:00 AM, Oleg Fayans wrote: > Hi Martin, > > As discussed, here is a new version with pep8-related fixes > > > On 08/14/2015 10:44 AM, Oleg Fayans wrote: >> Hi Martin, >> >> Already noticed that. Implemented the named groups as Tomas advised. >> Added the third test for >> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >> >> >> >> >> >> On 08/13/2015 05:06 PM, Martin Basti wrote: >>> >>> >>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>> NACK, comments inline. >>>>> >>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thanks for the review! >>>>>> >>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>> >>>>>>> 1) >>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>> Why do you add the name of method in docstring? >>>>>> My bad, fixed. >>>>> >>>>> still there >>>>> >>>>> + tokenize_topologies(command_output) >>>>> + takes an output of `ipa topologysegment-find` and returns an >>>>> array of >>>>> >>>> Fixed, sorry. >>>>> >>>>>>> >>>>>>> >>>>>>> 2) >>>>>>> >>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>> + creates a topology segment. The first argument is a node to >>>>>>> run the >>>>>>> command on >>>>>>> + The first 3 arguments should be objects of class Host >>>>>>> + Returns a hash object containing segment's name, leftnode, >>>>>>> rightnode information >>>>>>> + """ >>>>>>> >>>>>>> I would prefer to add assert there instead of just document that a >>>>>>> Host >>>>>>> object is needed >>>>>>> assert(isinstance(master, Host)) >>>>>>> ... >>>>>> >>>>>> Fixed. Created a decorator that checks the type of arguments >>>>> >>>>> This does not scale well. >>>>> If we will want to add new argument that is not host object, you need >>>>> change it again. >>>> >>>> Agreed. Modified the decorator so that you can specify a slice of >>>> arguments to be checked and a class to compare to. This does scale :) >>>>> >>>>> This might be used as function with specified variables that have >>>>> to be >>>>> host objects >>>>>> >>>>>>> >>>>>>> 3) >>>>>>> +def destroy_segment(master, segment_name): >>>>>>> + """ >>>>>>> + destroy_segment(master, segment_name) >>>>>>> + Destroys topology segment. First argument should be object of >>>>>>> class >>>>>>> Host >>>>>>> >>>>>>> Instead of description of params as first, second etc., you may use >>>>>>> following: >>>>>>> >>>>>>> +def destroy_segment(master, segment_name): >>>>>>> + """ >>>>>>> + Destroys topology segment. >>>>>>> + :param master: reference to master object of class Host >>>>>>> + :param segment: name fo segment >>>>>>> and eventually this in other methods >>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>> + :raises NotFound: if segment is not found >>>>>>> >>>>>> Fixed >>>>>>> >>>>>>> 4) >>>>>>> >>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>> >>>>>>> I suggest cls.replicas[:-1] >>>>>>> >>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>> >>>>>>> In [3]: a[:-1] >>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>> >>>>>> Fixed >>>>>>> >>>>>>> 5) >>>>>>> Why re.findall() and then you just use the first result? >>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>> >>>>>>> Isn't just re.search() enough? >>>>>>> leftnode_re.search(value).group(1) >>>>>> >>>>>> in fact >>>>>> leftnode_re.findall(string)[0] >>>>>> and >>>>>> leftnode_re.search(string).group(1), >>>>>> Are equally bad from the readability point of view. The first one is >>>>>> even shorter a bit, so why change? :) >>>>> >>>>> It depends on point of view, because when I reviewed it yesterday my >>>>> brain raises exception that you are trying to add multiple values to >>>>> single value attribute, because you used findall, I expected that you >>>>> need multiple values, and then I saw that index [0] at the end, and I >>>>> was pretty confused what are you trying to achieve. >>>>> >>>>> And because findall is not effective in case when you need to find >>>>> just >>>>> one occurrence. >>>> >>>> I got it. Fixed. >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Python 3 nitpick: >>>>>>> I'm not sure if time when we should enforce python 2/3 compability >>>>>>> already comes, but just for record: >>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>> (import io >>>>>>> before) >>>>>>> >>>>>> Done. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> 1) >>>>> >>>>> +# >>>>> >>>>> empty comment here (several times) >>>> >>>> Removed >>>>> >>>> >>> >>> NACK >>> >>> you changed it wrong >>> >>> group() returns everything, you need use group(1) to return content in >>> braces. >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Wed Aug 19 16:28:17 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 19 Aug 2015 18:28:17 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D47C85.6050008@redhat.com> References: <55D47C85.6050008@redhat.com> Message-ID: <55D4AEA1.9040507@redhat.com> On 08/19/2015 02:54 PM, Martin Babinsky wrote: > this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from > happening. > > > Actually, we (myself, mbasti, jcholast) found out that `user-del --preserve` could use some more usability improvements. This quick patch should fix both https://fedorahosted.org/freeipa/ticket/5234 and https://fedorahosted.org/freeipa/ticket/5236 and make user preservation operate on multiple arguments in a same way as plain deletion. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0060.1-improve-the-usability-of-ipa-user-del-preserve-comma.patch Type: text/x-patch Size: 7318 bytes Desc: not available URL: From edewata at redhat.com Thu Aug 20 06:59:56 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 20 Aug 2015 01:59:56 -0500 Subject: [Freeipa-devel] [PATCH] 371 Added support for changing vault encryption. In-Reply-To: <55D45360.4080003@redhat.com> References: <55BFF741.6080302@redhat.com> <55CC9638.8060801@redhat.com> <55CCCFC9.1060504@redhat.com> <55D45360.4080003@redhat.com> Message-ID: <55D57AEC.4030907@redhat.com> On 8/19/2015 4:58 AM, Martin Basti wrote: > On 08/13/2015 07:11 PM, Endi Sukma Dewata wrote: >> On 8/13/2015 8:06 AM, Martin Basti wrote: >>>> The vault-mod command has been modified to support changing vault >>>> encryption attributes (i.e. type, password, public/private keys) >>>> in addition to normal attributes (i.e. description). Changing the >>>> encryption requires retrieving the stored secret with the old >>>> attributes and rearchieving it with the new attributes. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5176 >>>> >>> Hello, does this patch require any additional patches? >>> >>> I have current master branch and I cannot apply it. >>> >>> git am >>> freeipa-edewata-0371-Added-support-for-changing-vault-encryption.patch -3 >>> >>> Applying: Added support for changing vault encryption. >>> error: invalid object 100644 3b62822366a62c90f843a6293589c28383e782ef >>> for 'ipalib/plugins/vault.py' >>> fatal: git-write-tree: error building trees >>> Repository lacks necessary blobs to fall back on 3-way merge. >>> >>> >>> Martin^2 >> >> New patch attached. It requires patch #0369-3. >> > I cannot apply patch (and 369-3 was pushed) > > git am > freeipa-edewata-0371-1-Added-support-for-changing-vault-encryption.patch -3 > Applying: Added support for changing vault encryption. > error: invalid object 100644 5d367b376ef41427ed983f3eafe120ed477018d2 > for 'ipalib/plugins/vault.py' > fatal: git-write-tree: error building trees > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. Rebased. -- Endi S. Dewata -------------- next part -------------- From 78d31f8201ab63ecfe93a3f126654a57e9c14d3f Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 31 Jul 2015 07:53:15 +0200 Subject: [PATCH] Added support for changing vault encryption. The vault-mod command has been modified to support changing vault encryption attributes (i.e. type, password, public/private keys) in addition to normal attributes (i.e. description). Changing the encryption requires retrieving the stored secret with the old attributes and rearchiving it with the new attributes. https://fedorahosted.org/freeipa/ticket/5176 --- API.txt | 27 +++- VERSION | 4 +- ipalib/plugins/vault.py | 231 +++++++++++++++++++++++++-- ipatests/test_xmlrpc/test_vault_plugin.py | 249 ++++++++++++++++++++++++++++++ 4 files changed, 497 insertions(+), 14 deletions(-) diff --git a/API.txt b/API.txt index f23d9a40c647a3c4d209419631794cd36e8e5e2f..749aa41d5cab60e4f2acf7486135ad066db7a8a6 100644 --- a/API.txt +++ b/API.txt @@ -5466,11 +5466,12 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?') option: Str('in?') +option: Flag('override_password?', autofill=True, default=False) option: Str('password?', cli_name='password') option: Str('password_file?', cli_name='password_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -5530,6 +5531,30 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod +args: 1,18,3 +arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('change_password?', autofill=True, default=False) +option: Str('description?', cli_name='desc') +option: Bytes('ipavaultpublickey?', cli_name='public_key') +option: Bytes('ipavaultsalt?', cli_name='salt') +option: Str('ipavaulttype?', cli_name='type') +option: Str('new_password?', cli_name='new_password') +option: Str('new_password_file?', cli_name='new_password_file') +option: Str('old_password?', cli_name='old_password') +option: Str('old_password_file?', cli_name='old_password_file') +option: Bytes('private_key?', cli_name='private_key') +option: Str('private_key_file?', cli_name='private_key_file') +option: Str('public_key_file?', cli_name='public_key_file') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('service?') +option: Flag('shared?', autofill=True, default=False) +option: Str('username?', cli_name='user') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_mod_internal args: 1,15,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') diff --git a/VERSION b/VERSION index 31a4af4a819415740e5c8db9259f934e13418cb5..941b5356378582d4d620896acdf5c284a4f66b8d 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=151 -# Last change: cheimes - Add flag to list all service and user vaults +IPA_API_VERSION_MINOR=152 +# Last change: edewata - Added support for changing vault encryption. diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 83dc085b5aadb4e2878e29d17449f0808cc7a9c2..54dbf94b7de53a218df38550daa5e21450d2b9bd 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -116,11 +116,37 @@ EXAMPLES: ipa vault-show [--user |--service |--shared] """) + _(""" - Modify a vault: + Modify vault description: ipa vault-mod [--user |--service |--shared] --desc """) + _(""" + Modify vault type: + ipa vault-mod + [--user |--service |--shared] + --type + [old password/private key] + [new password/public key] +""") + _(""" + Modify symmetric vault password: + ipa vault-mod + [--user |--service |--shared] + --change-password + ipa vault-mod + [--user |--service |--shared] + --old-password + --new-password + ipa vault-mod + [--user |--service |--shared] + --old-password-file + --new-password-file +""") + _(""" + Modify symmetric vault keys: + ipa vault-mod + [--user |--service |--shared] + --private-key-file + --public-key-file +""") + _(""" Delete a vault: ipa vault-del [--user |--service |--shared] @@ -457,7 +483,7 @@ class vault(LDAPObject): print ' ** Passwords do not match! **' - def get_existing_password(self, new=False): + def get_existing_password(self): """ Gets existing password from user. """ @@ -871,9 +897,182 @@ class vault_find(LDAPSearch): @register() -class vault_mod(LDAPUpdate): +class vault_mod(PKQuery, Local): __doc__ = _('Modify a vault.') + takes_options = vault_options + ( + Str( + 'description?', + cli_name='desc', + doc=_('Vault description'), + ), + Str( + 'ipavaulttype?', + cli_name='type', + doc=_('Vault type'), + ), + Bytes( + 'ipavaultsalt?', + cli_name='salt', + doc=_('Vault salt'), + ), + Flag( + 'change_password?', + doc=_('Change password'), + ), + Str( + 'old_password?', + cli_name='old_password', + doc=_('Old vault password'), + ), + Str( # TODO: use File parameter + 'old_password_file?', + cli_name='old_password_file', + doc=_('File containing the old vault password'), + ), + Str( + 'new_password?', + cli_name='new_password', + doc=_('New vault password'), + ), + Str( # TODO: use File parameter + 'new_password_file?', + cli_name='new_password_file', + doc=_('File containing the new vault password'), + ), + Bytes( + 'private_key?', + cli_name='private_key', + doc=_('Old vault private key'), + ), + Str( # TODO: use File parameter + 'private_key_file?', + cli_name='private_key_file', + doc=_('File containing the old vault private key'), + ), + Bytes( + 'ipavaultpublickey?', + cli_name='public_key', + doc=_('New vault public key'), + ), + Str( # TODO: use File parameter + 'public_key_file?', + cli_name='public_key_file', + doc=_('File containing the new vault public key'), + ), + ) + + has_output = output.standard_entry + + def forward(self, *args, **options): + + vault_type = options.pop('ipavaulttype', False) + salt = options.pop('ipavaultsalt', False) + change_password = options.pop('change_password', False) + + old_password = options.pop('old_password', None) + old_password_file = options.pop('old_password_file', None) + new_password = options.pop('new_password', None) + new_password_file = options.pop('new_password_file', None) + + old_private_key = options.pop('private_key', None) + old_private_key_file = options.pop('private_key_file', None) + new_public_key = options.pop('ipavaultpublickey', None) + new_public_key_file = options.pop('public_key_file', None) + + if self.api.env.in_server: + backend = self.api.Backend.ldap2 + else: + backend = self.api.Backend.rpcclient + if not backend.isconnected(): + backend.connect(ccache=krbV.default_context().default_ccache()) + + # determine the vault type based on parameters specified + if vault_type: + pass + + elif change_password or new_password or new_password_file or salt: + vault_type = u'symmetric' + + elif new_public_key or new_public_key_file: + vault_type = u'asymmetric' + + # if vault type is specified, retrieve existing secret + if vault_type: + opts = options.copy() + opts.pop('description', None) + + opts['password'] = old_password + opts['password_file'] = old_password_file + opts['private_key'] = old_private_key + opts['private_key_file'] = old_private_key_file + + response = self.api.Command.vault_retrieve(*args, **opts) + data = response['result']['data'] + + opts = options.copy() + + # if vault type is specified, update crypto attributes + if vault_type: + opts['ipavaulttype'] = vault_type + + if vault_type == u'standard': + opts['ipavaultsalt'] = None + opts['ipavaultpublickey'] = None + + elif vault_type == u'symmetric': + if salt: + opts['ipavaultsalt'] = salt + else: + opts['ipavaultsalt'] = os.urandom(16) + + opts['ipavaultpublickey'] = None + + elif vault_type == u'asymmetric': + + # get new vault public key + if new_public_key and new_public_key_file: + raise errors.MutuallyExclusiveError( + reason=_('New public key specified multiple times')) + + elif new_public_key: + pass + + elif new_public_key_file: + new_public_key = validated_read('public_key_file', + new_public_key_file, + mode='rb') + + else: + raise errors.ValidationError( + name='ipavaultpublickey', + error=_('Missing new vault public key')) + + opts['ipavaultsalt'] = None + opts['ipavaultpublickey'] = new_public_key + + response = self.api.Command.vault_mod_internal(*args, **opts) + + # if vault type is specified, rearchive existing secret + if vault_type: + opts = options.copy() + opts.pop('description', None) + + opts['data'] = data + opts['password'] = new_password + opts['password_file'] = new_password_file + opts['override_password'] = True + + self.api.Command.vault_archive(*args, **opts) + + return response + + + at register() +class vault_mod_internal(LDAPUpdate): + + NO_CLI = True + takes_options = LDAPUpdate.takes_options + vault_options msg_summary = _('Modified vault "%(value)s"') @@ -994,6 +1193,10 @@ class vault_archive(PKQuery, Local): cli_name='password_file', doc=_('File containing the vault password'), ), + Flag( + 'override_password?', + doc=_('Override existing password'), + ), ) has_output = output.standard_entry @@ -1008,6 +1211,8 @@ class vault_archive(PKQuery, Local): password = options.get('password') password_file = options.get('password_file') + override_password = options.pop('override_password', False) + # don't send these parameters to server if 'data' in options: del options['data'] @@ -1062,15 +1267,19 @@ class vault_archive(PKQuery, Local): password = password.rstrip('\n') else: - password = self.obj.get_existing_password() + if override_password: + password = self.obj.get_new_password() + else: + password = self.obj.get_existing_password() - # verify password by retrieving existing data - opts = options.copy() - opts['password'] = password - try: - self.api.Command.vault_retrieve(*args, **opts) - except errors.NotFound: - pass + if not override_password: + # verify password by retrieving existing data + opts = options.copy() + opts['password'] = password + try: + self.api.Command.vault_retrieve(*args, **opts) + except errors.NotFound: + pass salt = vault['ipavaultsalt'][0] diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py index 77c5154137bf440b38f4da225545c6aef5faabb6..483a47410c0d49b6a1e8b54047c280c243301d1b 100644 --- a/ipatests/test_xmlrpc/test_vault_plugin.py +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -37,6 +37,7 @@ asymmetric_vault_name = u'asymmetric_test_vault' secret = ''.join(map(chr, xrange(0, 256))) password = u'password' +other_password = u'other_password' public_key = """ -----BEGIN PUBLIC KEY----- @@ -80,6 +81,48 @@ kUlCMj24a8XsShzYTWBIyW2ngvGe3pQ9PfjkUdm0LGZjYITCBvgOKw== -----END RSA PRIVATE KEY----- """ +other_public_key = """ +-----BEGIN PUBLIC KEY----- +MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv7E/QLVyKjrgDctZ50U7 +rmtL7Ks1QLoccp9WvZJ6WI1rYd0fX5FySS4dI6QTNZc6qww8NeNuZtkoxT9m1wkk +Rl/3wK7fWNLenH/+VHOaTQc20exg7ztfsO7JIsmKmigtticdR5C4jLfjcOp+WjLH +w3zrmrO5SIZ8njxMoDcQJa2vu/t281U/I7ti8ue09FSitIECU05vgmPS+MnXR8HK +PxXqrNkjl29mXNbPiByWwlse3Prwved9I7fwgpiHJqUBFudD/0tZ4DWyLG7t9wM1 +O8gRaRg1r+ENVpmMSvXo4+8+bR3rEYddD5zU7nKXafeuthXlXplae/8uZmCiSI63 +TwIDAQAB +-----END PUBLIC KEY----- +""" + +other_private_key = """ +-----BEGIN RSA PRIVATE KEY----- +MIIEpgIBAAKCAQEAv7E/QLVyKjrgDctZ50U7rmtL7Ks1QLoccp9WvZJ6WI1rYd0f +X5FySS4dI6QTNZc6qww8NeNuZtkoxT9m1wkkRl/3wK7fWNLenH/+VHOaTQc20exg +7ztfsO7JIsmKmigtticdR5C4jLfjcOp+WjLHw3zrmrO5SIZ8njxMoDcQJa2vu/t2 +81U/I7ti8ue09FSitIECU05vgmPS+MnXR8HKPxXqrNkjl29mXNbPiByWwlse3Prw +ved9I7fwgpiHJqUBFudD/0tZ4DWyLG7t9wM1O8gRaRg1r+ENVpmMSvXo4+8+bR3r +EYddD5zU7nKXafeuthXlXplae/8uZmCiSI63TwIDAQABAoIBAQCA+0GFR9F+isjx +Xy+qBpKmxLl8kKKvX8r+cSpLOkEqTlW/rqqKgnI0vVuL/L2UJKKsLvpghBxoBZyC +RCvtatBGrhIlS0UrHg/9m73Ek1hylfUUAQokTn4PrkwWJSgmm/xOATmZSs5ymNTn +yFCmXl69sdNR77YvD5bQXeBtOT+bKXy7yQ1TmYPwwSjL+WSlMV6ZfE3HNVmxPTpk +CTFS638cJblWk9MUIy8HIlhu6If2P4RnHr7ZGGivhREayvs0zXcAfqhIyFHruxSE +yYnmqH9paWjv5mP3YyLoKr+NUvvxnBr/9wCTt0TKgG8G6rpkHuPDLQni9wUGnew8 +QdMgFEohAoGBAPH4vaVB5gDVfvIqwJBsBLHpPq72GvxjrM/exD0jIIpXZxz9gCql +CmC5b1RS1uy8PMoc/RO4CE7UTLaTesciP6LjTD1RhH3rLLJO8/iVC1RXgMrCLHLm +ZQnDhIQGGNQxpvBjQy5ZOWat2dFxYhHN630IFPOtrWsOmJ5HsL1JrjzxAoGBAMrO +R1zNwQ42VbJS6AFshZVjmUV2h3REGh4zG/9IqL0Hz493hyCTGoDPLLXIbtkqNqzQ +XibSZ9RMVPKKTiNQTx91DTgh4Anz8xUr84tA2iAf3ayNWKi3Y3GhmP2EWp1qYeom +kV8Uq0lt4dHZuEo3LuqvbtbzlF9qUXqKS5qy6Tg/AoGBAKCp02o2HjzxhS/QeTmr +r1ZeE7PiTzrECAuh01TwzPtuW1XhcEdgfEqK9cPcmT5pIkflBZkhOcr1pdYYiI5O +TEigeY/BX6KoE251hALLG9GtpCN82DyWhAH+oy9ySOwj5793eTT+I2HtD1LE4SQH +QVQsmJTP/fS2pVl7KnwUvy9RAoGBAKzo2qchNewsHzx+uxgbsnkABfnXaP2T4sDE +yqYJCPTB6BFl02vOf9Y6zN/gF8JH333P2bY3xhaXTgXMLXqmSg+D+NVW7HEP8Lyo +UGj1zgN9p74qdODEGqETKiFb6vYzcW/1mhP6x18/tDz658k+611kXZge7O288+MK +bhNjXrx5AoGBAMox25PcxVgOjCd9+LdUcIOG6LQ971eCH1NKL9YAekICnwMrStbK +veCYju6ok4ZWnMiH8MR1jgC39RWtjJZwynCuPXUP2/vZkoVf1tCZyz7dSm8TdS/2 +5NdOHVy7+NQcEPSm7/FmXdpcR9ZSGAuxMBfnEUibdyz5LdJGnFUN/+HS +-----END RSA PRIVATE KEY----- +""" + class test_vault_plugin(Declarative): @@ -591,6 +634,48 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Change standard vault to symmetric vault', + 'command': ( + 'vault_mod', + [standard_vault_name], + { + 'ipavaulttype': u'symmetric', + 'new_password': password, + }, + ), + 'expected': { + 'value': standard_vault_name, + 'summary': u'Modified vault "%s"' % standard_vault_name, + 'result': { + 'cn': [standard_vault_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from standard vault converted to ' + 'symmetric vault', + 'command': ( + 'vault_retrieve', + [standard_vault_name], + { + 'password': password, + }, + ), + 'expected': { + 'value': standard_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % standard_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Create symmetric vault', 'command': ( 'vault_add', @@ -653,6 +738,90 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Change symmetric vault password', + 'command': ( + 'vault_mod', + [symmetric_vault_name], + { + 'old_password': password, + 'new_password': other_password, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': u'Modified vault "%s"' % symmetric_vault_name, + 'result': { + 'cn': [symmetric_vault_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault with new password', + 'command': ( + 'vault_retrieve', + [symmetric_vault_name], + { + 'password': other_password, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { + 'desc': 'Change symmetric vault to asymmetric vault', + 'command': ( + 'vault_mod', + [symmetric_vault_name], + { + 'ipavaulttype': u'asymmetric', + 'old_password': other_password, + 'ipavaultpublickey': public_key, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': u'Modified vault "%s"' % symmetric_vault_name, + 'result': { + 'cn': [symmetric_vault_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault converted to ' + 'asymmetric vault', + 'command': ( + 'vault_retrieve', + [symmetric_vault_name], + { + 'private_key': private_key, + }, + ), + 'expected': { + 'value': symmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Create asymmetric vault', 'command': ( 'vault_add', @@ -713,4 +882,84 @@ class test_vault_plugin(Declarative): }, }, + { + 'desc': 'Change asymmetric vault keys', + 'command': ( + 'vault_mod', + [asymmetric_vault_name], + { + 'private_key': private_key, + 'ipavaultpublickey': other_public_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': u'Modified vault "%s"' % asymmetric_vault_name, + 'result': { + 'cn': [asymmetric_vault_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [other_public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault with new keys', + 'command': ( + 'vault_retrieve', + [asymmetric_vault_name], + { + 'private_key': other_private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + + { + 'desc': 'Change asymmetric vault to standard vault', + 'command': ( + 'vault_mod', + [asymmetric_vault_name], + { + 'ipavaulttype': u'standard', + 'private_key': other_private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': u'Modified vault "%s"' % asymmetric_vault_name, + 'result': { + 'cn': [asymmetric_vault_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault converted to ' + 'standard vault', + 'command': ( + 'vault_retrieve', + [asymmetric_vault_name], + {}, + ), + 'expected': { + 'value': asymmetric_vault_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_name, + 'result': { + 'data': secret, + }, + }, + }, + ] -- 2.4.3 From edewata at redhat.com Thu Aug 20 07:08:15 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 20 Aug 2015 02:08:15 -0500 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <55D44A4E.7080805@redhat.com> References: <55D0AC54.6040401@redhat.com> <55D44A4E.7080805@redhat.com> Message-ID: <55D57CDF.6070709@redhat.com> On 8/19/2015 4:20 AM, Martin Basti wrote: > On 08/16/2015 05:29 PM, Endi Sukma Dewata wrote: >> The vault-add and vault-archive commands have been modified to >> optionally retrieve a secret from a source vault, then re-archive >> the secret into the new/existing target vault. >> >> https://fedorahosted.org/freeipa/ticket/5223 >> >> >> > I cannot apply this patch. Rebased. It depends on patch #371-2. -- Endi S. Dewata -------------- next part -------------- >From 20ee7fa94d28239b7b0512db53c6b899baf8a62f Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Sat, 15 Aug 2015 16:17:47 +0200 Subject: [PATCH] Added mechanism to copy vault secrets. The vault-add and vault-archive commands have been modified to optionally retrieve a secret from a source vault, then re-archive the secret into the new/existing target vault. https://fedorahosted.org/freeipa/ticket/5223 --- API.txt | 20 +++- VERSION | 4 +- ipalib/plugins/vault.py | 193 ++++++++++++++++++++---------- ipatests/test_xmlrpc/test_vault_plugin.py | 143 ++++++++++++++++++++++ 4 files changed, 292 insertions(+), 68 deletions(-) diff --git a/API.txt b/API.txt index 749aa41d5cab60e4f2acf7486135ad066db7a8a6..3007bf31934d0b71dd104774ddbd1638cd12e8a3 100644 --- a/API.txt +++ b/API.txt @@ -5397,7 +5397,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,14,3 +args: 1,22,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -5411,6 +5411,14 @@ option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui option: Str('service?') option: Str('setattr*', cli_name='setattr', exclude='webui') option: Flag('shared?', autofill=True, default=False) +option: Str('source_password?') +option: Str('source_password_file?') +option: Bytes('source_private_key?') +option: Str('source_private_key_file?') +option: Str('source_service?') +option: Flag('source_shared?', autofill=True, default=False) +option: Str('source_user?') +option: Str('source_vault?') option: Str('username?', cli_name='user') option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) @@ -5466,7 +5474,7 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,11,3 +args: 1,19,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?') @@ -5477,6 +5485,14 @@ option: Str('password_file?', cli_name='password_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') option: Flag('shared?', autofill=True, default=False) +option: Str('source_password?') +option: Str('source_password_file?') +option: Bytes('source_private_key?') +option: Str('source_private_key_file?') +option: Str('source_service?') +option: Flag('source_shared?', autofill=True, default=False) +option: Str('source_user?') +option: Str('source_vault?') option: Str('username?', cli_name='user') option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) diff --git a/VERSION b/VERSION index 941b5356378582d4d620896acdf5c284a4f66b8d..19302efe7a36441b1ffef0d8db609f7be9a26c83 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=152 -# Last change: edewata - Added support for changing vault encryption. +IPA_API_VERSION_MINOR=153 +# Last change: edewata - Added mechanism to copy vault secrets. diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 54dbf94b7de53a218df38550daa5e21450d2b9bd..47610fee56069a85296445d4eda3c640f835ebcf 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -254,6 +254,74 @@ vault_options = ( ), ) +source_vault_options = ( + Str( + 'source_vault?', + doc=_('Name of the source service vault'), + ), + Str( + 'source_service?', + doc=_('Service name of the source service vault'), + ), + Flag( + 'source_shared?', + doc=_('Source shared vault'), + ), + Str( + 'source_user?', + doc=_('Username of the source user vault'), + ), + Str( + 'source_password?', + doc=_('Source vault password'), + ), + Str( # TODO: use File parameter + 'source_password_file?', + doc=_('File containing the source vault password'), + ), + Bytes( + 'source_private_key?', + doc=_('Source vault private key'), + ), + Str( # TODO: use File parameter + 'source_private_key_file?', + doc=_('File containing the source vault private key'), + ), +) + +vault_add_options = ( + Str( + 'description?', + cli_name='desc', + doc=_('Vault description'), + ), + Str( + 'ipavaulttype?', + cli_name='type', + doc=_('Vault type'), + ), + Str( + 'password?', + cli_name='password', + doc=_('Vault password'), + ), + Str( # TODO: use File parameter + 'password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), + Bytes( + 'ipavaultpublickey?', + cli_name='public_key', + doc=_('Vault public key'), + ), + Str( # TODO: use File parameter + 'public_key_file?', + cli_name='public_key_file', + doc=_('File containing the vault public key'), + ), +) + @register() class vault(LDAPObject): @@ -572,56 +640,27 @@ class vault(LDAPObject): class vault_add(PKQuery, Local): __doc__ = _('Create a new vault.') - takes_options = LDAPCreate.takes_options + vault_options + ( - Str( - 'description?', - cli_name='desc', - doc=_('Vault description'), - ), - Str( - 'ipavaulttype?', - cli_name='type', - doc=_('Vault type'), - ), - Str( - 'password?', - cli_name='password', - doc=_('Vault password'), - ), - Str( # TODO: use File parameter - 'password_file?', - cli_name='password_file', - doc=_('File containing the vault password'), - ), - Bytes( - 'ipavaultpublickey?', - cli_name='public_key', - doc=_('Vault public key'), - ), - Str( # TODO: use File parameter - 'public_key_file?', - cli_name='public_key_file', - doc=_('File containing the vault public key'), - ), - ) + takes_options = LDAPCreate.takes_options + vault_options + \ + source_vault_options + vault_add_options has_output = output.standard_entry def forward(self, *args, **options): vault_type = options.get('ipavaulttype', u'standard') - password = options.get('password') - password_file = options.get('password_file') + password = options.pop('password', None) + password_file = options.pop('password_file', None) public_key = options.get('ipavaultpublickey') - public_key_file = options.get('public_key_file') + public_key_file = options.pop('public_key_file', None) - # don't send these parameters to server - if 'password' in options: - del options['password'] - if 'password_file' in options: - del options['password_file'] - if 'public_key_file' in options: - del options['public_key_file'] + source_vault = options.pop('source_vault', None) + source_service = options.pop('source_service', None) + source_shared = options.pop('source_shared', None) + source_user = options.pop('source_user', None) + source_password = options.pop('source_password', None) + source_password_file = options.pop('source_password_file', None) + source_private_key = options.pop('source_private_key', None) + source_private_key_file = options.pop('source_private_key_file', None) if vault_type != u'symmetric' and (password or password_file): raise errors.MutuallyExclusiveError( @@ -711,6 +750,7 @@ class vault_add(PKQuery, Local): opts = options.copy() if 'description' in opts: del opts['description'] + if 'ipavaulttype' in opts: del opts['ipavaulttype'] @@ -721,7 +761,17 @@ class vault_add(PKQuery, Local): elif vault_type == u'asymmetric': del opts['ipavaultpublickey'] - # archive blank data + opts['source_vault'] = source_vault + opts['source_service'] = source_service + opts['source_shared'] = source_shared + opts['source_user'] = source_user + + opts['source_password'] = source_password + opts['source_password_file'] = source_password_file + opts['source_private_key'] = source_private_key + opts['source_private_key_file'] = source_private_key_file + + # archive initial data self.api.Command.vault_archive(*args, **opts) return response @@ -1174,7 +1224,7 @@ class vaultconfig_show(Retrieve): class vault_archive(PKQuery, Local): __doc__ = _('Archive data into a vault.') - takes_options = vault_options + ( + takes_options = vault_options + source_vault_options + ( Bytes( 'data?', doc=_('Binary data to archive'), @@ -1205,23 +1255,29 @@ class vault_archive(PKQuery, Local): name = args[-1] - data = options.get('data') - input_file = options.get('in') + data = options.pop('data', None) + input_file = options.pop('in', None) - password = options.get('password') - password_file = options.get('password_file') + source_vault = options.pop('source_vault', None) + source_service = options.pop('source_service', None) + source_shared = options.pop('source_shared', None) + source_user = options.pop('source_user', None) + source_password = options.pop('source_password', None) + source_password_file = options.pop('source_password_file', None) + source_private_key = options.pop('source_private_key', None) + source_private_key_file = options.pop('source_private_key_file', None) + + password = options.pop('password', None) + password_file = options.pop('password_file', None) override_password = options.pop('override_password', False) - # don't send these parameters to server - if 'data' in options: - del options['data'] - if 'in' in options: - del options['in'] - if 'password' in options: - del options['password'] - if 'password_file' in options: - del options['password_file'] + if self.api.env.in_server: + backend = self.api.Backend.ldap2 + else: + backend = self.api.Backend.rpcclient + if not backend.isconnected(): + backend.connect(ccache=krbV.default_context().default_ccache()) # get data if data and input_file: @@ -1231,16 +1287,25 @@ class vault_archive(PKQuery, Local): elif input_file: data = validated_read('in', input_file, mode='rb') + elif source_vault: + opts = {} + + opts['service'] = source_service + opts['shared'] = source_shared + opts['username'] = source_user + + opts['password'] = source_password + opts['password_file'] = source_password_file + opts['private_key'] = source_private_key + opts['private_key_file'] = source_private_key_file + + # retrieve data from source vault + response = self.api.Command.vault_retrieve(source_vault, **opts) + data = response['result']['data'] + elif not data: data = '' - if self.api.env.in_server: - backend = self.api.Backend.ldap2 - else: - backend = self.api.Backend.rpcclient - if not backend.isconnected(): - backend.connect(ccache=krbV.default_context().default_ccache()) - # retrieve vault info vault = self.api.Command.vault_show(*args, **options)['result'] diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py index 483a47410c0d49b6a1e8b54047c280c243301d1b..fe0cc6d1e050de2dfb08e064250f5343dbea9c73 100644 --- a/ipatests/test_xmlrpc/test_vault_plugin.py +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -33,6 +33,10 @@ standard_vault_name = u'standard_test_vault' symmetric_vault_name = u'symmetric_test_vault' asymmetric_vault_name = u'asymmetric_test_vault' +standard_vault_copy_name = u'standard_test_vault_copy' +symmetric_vault_copy_name = u'symmetric_test_vault_copy' +asymmetric_vault_copy_name = u'asymmetric_test_vault_copy' + # binary data from \x00 to \xff secret = ''.join(map(chr, xrange(0, 256))) @@ -147,6 +151,9 @@ class test_vault_plugin(Declarative): ('vault_del', [standard_vault_name], {'continue': True}), ('vault_del', [symmetric_vault_name], {'continue': True}), ('vault_del', [asymmetric_vault_name], {'continue': True}), + ('vault_del', [standard_vault_copy_name], {'continue': True}), + ('vault_del', [symmetric_vault_copy_name], {'continue': True}), + ('vault_del', [asymmetric_vault_copy_name], {'continue': True}), ] tests = [ @@ -634,6 +641,52 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy standard vault to symmetric vault', + 'command': ( + 'vault_add', + [standard_vault_copy_name], + { + 'ipavaulttype': u'symmetric', + 'password': password, + 'source_vault': standard_vault_name, + }, + ), + 'expected': { + 'value': standard_vault_copy_name, + 'summary': u'Added vault "%s"' % standard_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (standard_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [standard_vault_copy_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from standard vault copied to ' + 'symmetric vault', + 'command': ( + 'vault_retrieve', + [standard_vault_copy_name], + { + 'password': password, + }, + ), + 'expected': { + 'value': standard_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % standard_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change standard vault to symmetric vault', 'command': ( 'vault_mod', @@ -738,6 +791,53 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy symmetric vault to asymmetric vault', + 'command': ( + 'vault_add', + [symmetric_vault_copy_name], + { + 'ipavaulttype': u'asymmetric', + 'ipavaultpublickey': public_key, + 'source_vault': symmetric_vault_name, + 'source_password': password, + }, + ), + 'expected': { + 'value': symmetric_vault_copy_name, + 'summary': u'Added vault "%s"' % symmetric_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (symmetric_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [symmetric_vault_copy_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault copied to ' + 'asymmetric vault', + 'command': ( + 'vault_retrieve', + [symmetric_vault_copy_name], + { + 'private_key': private_key, + }, + ), + 'expected': { + 'value': symmetric_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change symmetric vault password', 'command': ( 'vault_mod', @@ -883,6 +983,49 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy asymmetric vault to standard vault', + 'command': ( + 'vault_add', + [asymmetric_vault_copy_name], + { + 'ipavaulttype': u'standard', + 'source_vault': asymmetric_vault_name, + 'source_private_key': private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_copy_name, + 'summary': u'Added vault "%s"' % asymmetric_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (asymmetric_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [asymmetric_vault_copy_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault copied to ' + 'standard vault', + 'command': ( + 'vault_retrieve', + [asymmetric_vault_copy_name], + {}, + ), + 'expected': { + 'value': asymmetric_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change asymmetric vault keys', 'command': ( 'vault_mod', -- 2.4.3 From ofayans at redhat.com Thu Aug 20 08:18:09 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 10:18:09 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL Message-ID: <55D58D41.6060006@redhat.com> Hi all, I am trying to run integration tests for dnssec in RHEL-7.2 The tests keep failing at the step of preparing the replica. I figured out, the ipa-replica-prepare with the standard parameters requests reverse zone info (does not do it in fedora) which causes the test to fail. Does anyone know why does it do it? We can, of course update our tests adding a --no-reverse option, but I'd like to know how come it behaves differently depending on the platform. The system is dell-pe1950-06.rhts.eng.brq.redhat.com The command looks like this: [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com Do you want to configure the reverse zone? [yes]: -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Aug 20 08:26:41 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 10:26:41 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55D4900C.5040509@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> Message-ID: <55D58F41.3020400@redhat.com> On 08/19/2015 04:17 PM, Martin Basti wrote: > I got this: > > https://paste.fedoraproject.org/256746/43999380/ FYI replica install failure. (I will retest it, but I'm pretty sure that it was clean VM, test for some reason install client first) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 295, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 319, in install_check sys.exit("IPA client is already configured on this system.\n" 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, exception: SystemExit: IPA client is already configured on this system. Please uninstall it first before configuring the replica, using 'ipa-client-install --uninstall'. 2015-08-19T14:14:15Z ERROR IPA client is already configured on this system. Please uninstall it first before configuring the replica, using 'ipa-client-install --uninstall'. > > On 08/19/2015 09:00 AM, Oleg Fayans wrote: >> Hi Martin, >> >> As discussed, here is a new version with pep8-related fixes >> >> >> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Already noticed that. Implemented the named groups as Tomas advised. >>> Added the third test for >>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>> >>> >>> >>> >>> >>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>> NACK, comments inline. >>>>>> >>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> Thanks for the review! >>>>>>> >>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>> >>>>>>>> 1) >>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>> Why do you add the name of method in docstring? >>>>>>> My bad, fixed. >>>>>> >>>>>> still there >>>>>> >>>>>> + tokenize_topologies(command_output) >>>>>> + takes an output of `ipa topologysegment-find` and >>>>>> returns an >>>>>> array of >>>>>> >>>>> Fixed, sorry. >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2) >>>>>>>> >>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>> + creates a topology segment. The first argument is a node to >>>>>>>> run the >>>>>>>> command on >>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>> + Returns a hash object containing segment's name, leftnode, >>>>>>>> rightnode information >>>>>>>> + """ >>>>>>>> >>>>>>>> I would prefer to add assert there instead of just document that a >>>>>>>> Host >>>>>>>> object is needed >>>>>>>> assert(isinstance(master, Host)) >>>>>>>> ... >>>>>>> >>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>> >>>>>> This does not scale well. >>>>>> If we will want to add new argument that is not host object, you >>>>>> need >>>>>> change it again. >>>>> >>>>> Agreed. Modified the decorator so that you can specify a slice of >>>>> arguments to be checked and a class to compare to. This does scale :) >>>>>> >>>>>> This might be used as function with specified variables that have >>>>>> to be >>>>>> host objects >>>>>>> >>>>>>>> >>>>>>>> 3) >>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>> + """ >>>>>>>> + destroy_segment(master, segment_name) >>>>>>>> + Destroys topology segment. First argument should be object of >>>>>>>> class >>>>>>>> Host >>>>>>>> >>>>>>>> Instead of description of params as first, second etc., you may >>>>>>>> use >>>>>>>> following: >>>>>>>> >>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>> + """ >>>>>>>> + Destroys topology segment. >>>>>>>> + :param master: reference to master object of class Host >>>>>>>> + :param segment: name fo segment >>>>>>>> and eventually this in other methods >>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>> + :raises NotFound: if segment is not found >>>>>>>> >>>>>>> Fixed >>>>>>>> >>>>>>>> 4) >>>>>>>> >>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>> >>>>>>>> I suggest cls.replicas[:-1] >>>>>>>> >>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>> >>>>>>>> In [3]: a[:-1] >>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>> >>>>>>> Fixed >>>>>>>> >>>>>>>> 5) >>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>> >>>>>>>> Isn't just re.search() enough? >>>>>>>> leftnode_re.search(value).group(1) >>>>>>> >>>>>>> in fact >>>>>>> leftnode_re.findall(string)[0] >>>>>>> and >>>>>>> leftnode_re.search(string).group(1), >>>>>>> Are equally bad from the readability point of view. The first >>>>>>> one is >>>>>>> even shorter a bit, so why change? :) >>>>>> >>>>>> It depends on point of view, because when I reviewed it >>>>>> yesterday my >>>>>> brain raises exception that you are trying to add multiple values to >>>>>> single value attribute, because you used findall, I expected that >>>>>> you >>>>>> need multiple values, and then I saw that index [0] at the end, >>>>>> and I >>>>>> was pretty confused what are you trying to achieve. >>>>>> >>>>>> And because findall is not effective in case when you need to >>>>>> find just >>>>>> one occurrence. >>>>> >>>>> I got it. Fixed. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Python 3 nitpick: >>>>>>>> I'm not sure if time when we should enforce python 2/3 compability >>>>>>>> already comes, but just for record: >>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>> (import io >>>>>>>> before) >>>>>>>> >>>>>>> Done. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> 1) >>>>>> >>>>>> +# >>>>>> >>>>>> empty comment here (several times) >>>>> >>>>> Removed >>>>>> >>>>> >>>> >>>> NACK >>>> >>>> you changed it wrong >>>> >>>> group() returns everything, you need use group(1) to return content in >>>> braces. >>> >>> >>> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Thu Aug 20 08:28:42 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 20 Aug 2015 10:28:42 +0200 Subject: [Freeipa-devel] [PATCH 0058] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55BB5CD3.5060603@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> Message-ID: <55D58FBA.6070105@redhat.com> On 31/07/15 13:32, Martin Basti wrote: > On 30/07/15 14:38, Martin Basti wrote: >> On 29/07/15 16:12, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/5087 >> NACK >> >> You forgot to update API.txt file Thanks for catching that. Updated patch attached. >> > I'm just curious, what is the reason to check if forward zone exists? > > IMO forwardzone must exists somewhere as the master zone. I don't think > we should check forwardzones, this may give too many false positive errors. AIUI if the zone exist somewhere and is resolvable there is no need to add it as a forward zone. If user for some reason want to do it he's hiding the original zone and we should not allow this (without --force). > > Martin^2 > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0058.1-dns-do-not-add-forward-zone-if-it-is-already-resolva.patch Type: text/x-patch Size: 7595 bytes Desc: not available URL: From tbordaz at redhat.com Thu Aug 20 09:05:20 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Aug 2015 11:05:20 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D4AEA1.9040507@redhat.com> References: <55D47C85.6050008@redhat.com> <55D4AEA1.9040507@redhat.com> Message-ID: <55D59850.1040602@redhat.com> On 08/19/2015 06:28 PM, Martin Babinsky wrote: > On 08/19/2015 02:54 PM, Martin Babinsky wrote: >> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from >> happening. >> >> >> > Actually, we (myself, mbasti, jcholast) found out that `user-del > --preserve` could use some more usability improvements. > > This quick patch should fix both > https://fedorahosted.org/freeipa/ticket/5234 and > https://fedorahosted.org/freeipa/ticket/5236 and make user > preservation operate on multiple arguments in a same way as plain > deletion. > > > Hi Martin, This is curious it is looking like in my test the fix does not prevent the deletion: [root at vm-141 freeipa]# ipa user-del ttest1 --preserve --------------------- Deleted user "ttest1" --------------------- [root at vm-141 freeipa]# ipa user-del ttest1 --preserve --------------------- Deleted user "ttest1" --------------------- [root at vm-141 freeipa]# ipa user-find ttest1 --preserve=true --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ---------------------------- [20/Aug/2015:11:00:33 +0200] conn=124 op=9 MODRDN dn="uid=ttest1,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" newrdn="uid=ttest1" newsuperior="cn=deleted users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" [20/Aug/2015:11:00:33 +0200] conn=124 op=9 RESULT err=0 tag=109 nentries=0 etime=0 ... [20/Aug/2015:11:00:44 +0200] conn=125 op=14 SRCH base="uid=ttest1,cn=deleted users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName" [20/Aug/2015:11:00:44 +0200] conn=125 op=14 RESULT err=0 tag=101 nentries=1 etime=0 [20/Aug/2015:11:00:44 +0200] conn=125 op=15 DEL dn="uid=ttest1,cn=deleted users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" [20/Aug/2015:11:00:44 +0200] conn=125 op=15 RESULT *err=0* tag=107 nentries=0 etime=0 ... [20/Aug/2015:11:00:57 +0200] conn=126 op=5 SRCH base="cn=deleted users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" scope=1 filter="(&(|(telephoneNumber=*ttest1*)(uid=*ttest1*)(title=*ttest1*)(sn=*ttest1*)(ou=*ttest1*)(givenName=*ttest1*))(objectClass=posixaccount))" attrs="telephoneNumber sshpubkeyfp uid title loginShell uidNumber gidNumber sn homeDirectory mail givenName nsAccountLock" [20/Aug/2015:11:00:57 +0200] conn=126 op=5 RESULT err=0 tag=101 *nentries=0* etime=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu Aug 20 09:12:43 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Aug 2015 11:12:43 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D59850.1040602@redhat.com> References: <55D47C85.6050008@redhat.com> <55D4AEA1.9040507@redhat.com> <55D59850.1040602@redhat.com> Message-ID: <55D59A0B.7000905@redhat.com> On 08/20/2015 11:05 AM, thierry bordaz wrote: > On 08/19/2015 06:28 PM, Martin Babinsky wrote: >> On 08/19/2015 02:54 PM, Martin Babinsky wrote: >>> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from >>> happening. >>> >>> >>> >> Actually, we (myself, mbasti, jcholast) found out that `user-del >> --preserve` could use some more usability improvements. >> >> This quick patch should fix both >> https://fedorahosted.org/freeipa/ticket/5234 and >> https://fedorahosted.org/freeipa/ticket/5236 and make user >> preservation operate on multiple arguments in a same way as plain >> deletion. >> >> >> > Hi Martin, > > This is curious it is looking like in my test the fix does not prevent > the deletion: > > [root at vm-141 freeipa]# ipa user-del ttest1 --preserve > --------------------- > Deleted user "ttest1" > --------------------- > [root at vm-141 freeipa]# ipa user-del ttest1 --preserve > --------------------- > Deleted user "ttest1" > --------------------- > [root at vm-141 freeipa]# ipa user-find ttest1 --preserve=true > --------------- > 0 users matched > --------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- > > > [20/Aug/2015:11:00:33 +0200] conn=124 op=9 MODRDN > dn="uid=ttest1,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > newrdn="uid=ttest1" newsuperior="cn=deleted > users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > [20/Aug/2015:11:00:33 +0200] conn=124 op=9 RESULT err=0 tag=109 > nentries=0 etime=0 > ... > [20/Aug/2015:11:00:44 +0200] conn=125 op=14 SRCH > base="uid=ttest1,cn=deleted > users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > scope=0 filter="(objectClass=*)" attrs="distinguishedName" > [20/Aug/2015:11:00:44 +0200] conn=125 op=14 RESULT err=0 tag=101 > nentries=1 etime=0 > [20/Aug/2015:11:00:44 +0200] conn=125 op=15 DEL > dn="uid=ttest1,cn=deleted > users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > [20/Aug/2015:11:00:44 +0200] conn=125 op=15 RESULT *err=0* tag=107 > nentries=0 etime=0 > ... > [20/Aug/2015:11:00:57 +0200] conn=126 op=5 SRCH base="cn=deleted > users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" > scope=1 > filter="(&(|(telephoneNumber=*ttest1*)(uid=*ttest1*)(title=*ttest1*)(sn=*ttest1*)(ou=*ttest1*)(givenName=*ttest1*))(objectClass=posixaccount))" > attrs="telephoneNumber sshpubkeyfp uid title loginShell uidNumber > gidNumber sn homeDirectory mail givenName nsAccountLock" > [20/Aug/2015:11:00:57 +0200] conn=126 op=5 RESULT err=0 tag=101 > *nentries=0* etime=0 > > > > > Hi Martin, Sorry I did a mistake in my tests.. retesting it -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 20 09:18:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 11:18:35 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55D58F41.3020400@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> Message-ID: <55D59B6B.8000606@redhat.com> On 08/20/2015 10:26 AM, Martin Basti wrote: > > > On 08/19/2015 04:17 PM, Martin Basti wrote: >> I got this: >> >> https://paste.fedoraproject.org/256746/43999380/ > FYI replica install failure. (I will retest it, but I'm pretty sure > that it was clean VM, test for some reason install client first) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 295, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 319, in install_check > sys.exit("IPA client is already configured on this system.\n" > > 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, > exception: SystemExit: IPA client is already configured on this system. > Please uninstall it first before configuring the replica, using > 'ipa-client-install --uninstall'. > 2015-08-19T14:14:15Z ERROR IPA client is already configured on this > system. > Please uninstall it first before configuring the replica, using > 'ipa-client-install --uninstall'. Confirm I got same error. > >> >> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> As discussed, here is a new version with pep8-related fixes >>> >>> >>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Already noticed that. Implemented the named groups as Tomas advised. >>>> Added the third test for >>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>> >>>> >>>> >>>> >>>> >>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>> NACK, comments inline. >>>>>>> >>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Thanks for the review! >>>>>>>> >>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>> Why do you add the name of method in docstring? >>>>>>>> My bad, fixed. >>>>>>> >>>>>>> still there >>>>>>> >>>>>>> + tokenize_topologies(command_output) >>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>> returns an >>>>>>> array of >>>>>>> >>>>>> Fixed, sorry. >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> >>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>> + creates a topology segment. The first argument is a node to >>>>>>>>> run the >>>>>>>>> command on >>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>> + Returns a hash object containing segment's name, leftnode, >>>>>>>>> rightnode information >>>>>>>>> + """ >>>>>>>>> >>>>>>>>> I would prefer to add assert there instead of just document >>>>>>>>> that a >>>>>>>>> Host >>>>>>>>> object is needed >>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>> ... >>>>>>>> >>>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>>> >>>>>>> This does not scale well. >>>>>>> If we will want to add new argument that is not host object, you >>>>>>> need >>>>>>> change it again. >>>>>> >>>>>> Agreed. Modified the decorator so that you can specify a slice of >>>>>> arguments to be checked and a class to compare to. This does >>>>>> scale :) >>>>>>> >>>>>>> This might be used as function with specified variables that >>>>>>> have to be >>>>>>> host objects >>>>>>>> >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>> + """ >>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>> object of >>>>>>>>> class >>>>>>>>> Host >>>>>>>>> >>>>>>>>> Instead of description of params as first, second etc., you >>>>>>>>> may use >>>>>>>>> following: >>>>>>>>> >>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>> + """ >>>>>>>>> + Destroys topology segment. >>>>>>>>> + :param master: reference to master object of class Host >>>>>>>>> + :param segment: name fo segment >>>>>>>>> and eventually this in other methods >>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>> >>>>>>>> Fixed >>>>>>>>> >>>>>>>>> 4) >>>>>>>>> >>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>> >>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>> >>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>> >>>>>>>>> In [3]: a[:-1] >>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>> >>>>>>>> Fixed >>>>>>>>> >>>>>>>>> 5) >>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>> >>>>>>>>> Isn't just re.search() enough? >>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>> >>>>>>>> in fact >>>>>>>> leftnode_re.findall(string)[0] >>>>>>>> and >>>>>>>> leftnode_re.search(string).group(1), >>>>>>>> Are equally bad from the readability point of view. The first >>>>>>>> one is >>>>>>>> even shorter a bit, so why change? :) >>>>>>> >>>>>>> It depends on point of view, because when I reviewed it >>>>>>> yesterday my >>>>>>> brain raises exception that you are trying to add multiple >>>>>>> values to >>>>>>> single value attribute, because you used findall, I expected >>>>>>> that you >>>>>>> need multiple values, and then I saw that index [0] at the end, >>>>>>> and I >>>>>>> was pretty confused what are you trying to achieve. >>>>>>> >>>>>>> And because findall is not effective in case when you need to >>>>>>> find just >>>>>>> one occurrence. >>>>>> >>>>>> I got it. Fixed. >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Python 3 nitpick: >>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>> compability >>>>>>>>> already comes, but just for record: >>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>> (import io >>>>>>>>> before) >>>>>>>>> >>>>>>>> Done. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> 1) >>>>>>> >>>>>>> +# >>>>>>> >>>>>>> empty comment here (several times) >>>>>> >>>>>> Removed >>>>>>> >>>>>> >>>>> >>>>> NACK >>>>> >>>>> you changed it wrong >>>>> >>>>> group() returns everything, you need use group(1) to return >>>>> content in >>>>> braces. >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Aug 20 09:27:55 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 20 Aug 2015 11:27:55 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D444E2.9080806@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> <55D43F9E.7080402@redhat.com> <55D442B2.3070404@redhat.com> <55D444E2.9080806@redhat.com> Message-ID: <55D59D9B.3060409@redhat.com> On 19.8.2015 10:57, Jan Cholasta wrote: > On 19.8.2015 10:47, thierry bordaz wrote: >> On 08/19/2015 10:34 AM, Jan Cholasta wrote: >>> On 19.8.2015 09:39, thierry bordaz wrote: >>>> Hi, >>>> >>>> It worked like a charm. >>>> I had a problem to commit it because of the VERSION stuff that changed. >>>> >>>> Except that (changing VERSION), the fix looks good to me >>>> >>>> thanks >>>> thierry >>>> On 08/18/2015 07:21 PM, Martin Basti wrote: >>>>> Thank you for the patch, I checked it, I just changed permission name >>>>> to have all first letters in uppercase as others. >>>>> Updated merged patch attached. >>>>> >>>>> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>>>>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>>>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thierry can you check If I don't break everything, it works >>>>>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting >>>>>>>>>>>>>>>> NACK :D >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented internally >>>>>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> git apply -v >>>>>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>>>>> error: while searching for: >>>>>>>>>>>>>>> # # >>>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>>>>> # Last change: ftweedal - add --out option to user-show >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> There is many pending patches that may change VERSION number, >>>>>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does code looks good for you? >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>>>>>> test being 'admin' ? >>>>>>>>>>>>> >>>>>>>>>>>>> thanks >>>>>>>>>>>>> theirry >>>>>>>>>>>> No I didn't,. >>>>>>>>>>>> >>>>>>>>>>>> I preserver all permission, the original permissions should >>>>>>>>>>>> work. >>>>>>>>>>>> >>>>>>>>>>>> Martin >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> Running a test script, I have an issue with >>>>>>>>>>> >>>>>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>>>>>>>> attribute 'setdefault' >>>>>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> File >>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>>>>> line 347, in wsgi_execute >>>>>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>> line 443, in __call__ >>>>>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>> line 760, in run >>>>>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> File >>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>>>>> line 1227, in execute >>>>>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>>>>> 10485] *keys, **options) >>>>>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> File >>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>> line 373, in pre_callback >>>>>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> File >>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>>>>> set_default function. It is not clear why. entry_attrs is one of >>>>>>>>>>> pre_callback parameter. >>>>>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>>>>> pre_callback ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> thierry >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> >>>>>>>>>> updated patch attached. >>>>>>>>> >>>>>>>>> So far, tests are ok. >>>>>>>>> Just one comment, the 'user-stage' command description is wrong, >>>>>>>>> as it moves an active user into the staged area >>>>>>>>> >>>>>>>>> user-stage Move deleted user into >>>>>>>>> staged area >>>>>>>> No, it's not doing that. >>>>>>>> >>>>>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>>>>> doesn't work for active users. >>>>>>>> The support to move active user to staged area is RFE, I did not >>>>>>>> implemented it yet, and I dont know if this will fit IPA 4.2 >>>>>>>> timeframe >>>>>>> Ok. thanks. >>>>>>> Sure user-stage (active->stage) will not fit into IPA 4.2 timeframe. >>>>>>> >>>>>>> Running the tests being admin, there is no problem. >>>>>>> I have a permission issue, when running as 'Stage administrator'. >>>>>>> The 'delete' entry being moved to 'stage' container, we need the a >>>>>>> special permission for it. >>>>>> >>>>>> Hello, >>>>>> >>>>>> I tested this new permission to grant 'Stage user administrator' to >>>>>> do a 'user-stage'. >>>>>> Is it ok to add it to your patch ? >>>>>> >>>>>> thanks >>>>>> thierry >>>>>>> >>>>>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>>>>> --------------------- >>>>>>> Deleted user "ttest1" >>>>>>> --------------------- >>>>>>> >>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to >>>>>>> move an entry to 'cn=staged >>>>>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>>>>> >>>>>>> >>>>>>> >>>>>>> [root at vm-141 ~]# klist >>>>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>>>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>> >>>>>>> Valid starting Expires Service principal >>>>>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>>>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>> >>>>>>> >>>>>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>>>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>> >>>>>>> [root at vm-141 ~]# kinit admin >>>>>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>> ---------------------------- >>>>>>> Staged user account "ttest1" >>>>>>> ---------------------------- >>>>>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>>>>> -------------- >>>>>>> 1 user matched >>>>>>> -------------- >>>>>>> User login: ttest1 >>>>>>> First name: t >>>>>>> Last name: test1 >>>>>>> Home directory: /home/ttest1 >>>>>>> Login shell: /bin/sh >>>>>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>>>>> UID: 1814000011 >>>>>>> GID: 1814000011 >>>>>>> Password: False >>>>>>> Kerberos keys available: False >>>>>>> ---------------------------- >>>>>>> Number of entries returned 1 >>>>>>> ---------------------------- >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> NACK. >>> >>> 1) Use ADD+DEL instead of MODRDN as we agreed before: >>> . >>> >>> >> >> Hi, >> >> I have a slight preference doing MODRDN than ADD+DEL but I think it is >> for corner case. >> Before preserving a user, the user was active and could be updated. If >> the user gets updated on a replica (e.g. change its phonenumer) but for >> some reason the update is not immediately replicated, then a later >> 'user-del --preserve' + 'user-stage' will stage the user without the >> updated phonenumber. >> >> In addition, doing 2 ops rather than one costs more and is not atomic >> (more complex to handle failure). > > The same problem exists for stageuser_activate, and unless you want to > change it to use MODRDN as well, user_stage must use ADD+DEL. > > This was already discussed quite thoroughly and we reached the decision > to use ADD+DEL, because it is consistent with the rest of the user code. > I don't see a point in discussing this further and rehashing what was > already said. > >> >> thank >> thierry >>> >>> 2) You can't use the entry preparation code from stageuser-add in >>> user-stage - it is supposed to normalize user input, not already >>> normalized data from LDAP, and could lead to subtle and hard to track >>> errors. >>> >>> Honza >>> >> > I have updated Martin's patch with fixes for the above. See attachment. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0297.4-Add-user-stage-command.patch Type: text/x-patch Size: 8898 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 20 09:33:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 11:33:48 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D58D41.6060006@redhat.com> References: <55D58D41.6060006@redhat.com> Message-ID: <55D59EFC.1000000@redhat.com> On 08/20/2015 10:18 AM, Oleg Fayans wrote: > Hi all, > > I am trying to run integration tests for dnssec in RHEL-7.2 > The tests keep failing at the step of preparing the replica. I figured > out, the ipa-replica-prepare with the standard parameters requests > reverse zone info (does not do it in fedora) which causes the test to > fail. > > Does anyone know why does it do it? We can, of course update our tests > adding a --no-reverse option, but I'd like to know how come it behaves > differently depending on the platform. > > The system is > dell-pe1950-06.rhts.eng.brq.redhat.com > > The command looks like this: > > [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' > --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com > Do you want to configure the reverse zone? [yes]: > Reverse zone is not needed for DNSSEC test, you can use --no-reverse option. Did you test fedora on the same machine? From ofayans at redhat.com Thu Aug 20 09:42:02 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 11:42:02 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D59EFC.1000000@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> Message-ID: <55D5A0EA.2070102@redhat.com> Hi Martin On 08/20/2015 11:33 AM, Martin Basti wrote: > > > On 08/20/2015 10:18 AM, Oleg Fayans wrote: >> Hi all, >> >> I am trying to run integration tests for dnssec in RHEL-7.2 >> The tests keep failing at the step of preparing the replica. I figured >> out, the ipa-replica-prepare with the standard parameters requests >> reverse zone info (does not do it in fedora) which causes the test to >> fail. >> >> Does anyone know why does it do it? We can, of course update our tests >> adding a --no-reverse option, but I'd like to know how come it behaves >> differently depending on the platform. >> >> The system is >> dell-pe1950-06.rhts.eng.brq.redhat.com >> >> The command looks like this: >> >> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >> Do you want to configure the reverse zone? [yes]: >> > Reverse zone is not needed for DNSSEC test, you can use --no-reverse > option. > > Did you test fedora on the same machine? No, it's a beaker-provisioned vm. I added a --no-reverse to the install_replica method in ipatests/test_integration/tasks.py. It fixed this particular issue. However, now the test fails at the step of ipa-replica-install: [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w '' --ip-address 10.34.54.25 /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg --setup-ca --setup-dns --forwarder 10.34.32.1 WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd ipa : ERROR Unable to resolve the IP address 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts and DNS name resolution -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From tbordaz at redhat.com Thu Aug 20 09:41:13 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Aug 2015 11:41:13 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D4AEA1.9040507@redhat.com> References: <55D47C85.6050008@redhat.com> <55D4AEA1.9040507@redhat.com> Message-ID: <55D5A0B9.8020908@redhat.com> On 08/19/2015 06:28 PM, Martin Babinsky wrote: > On 08/19/2015 02:54 PM, Martin Babinsky wrote: >> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from >> happening. >> >> >> > Actually, we (myself, mbasti, jcholast) found out that `user-del > --preserve` could use some more usability improvements. > > This quick patch should fix both > https://fedorahosted.org/freeipa/ticket/5234 and > https://fedorahosted.org/freeipa/ticket/5236 and make user > preservation operate on multiple arguments in a same way as plain > deletion. > > > Hi Martin, The tests are ok and the fix looks good to me. ACK thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu Aug 20 09:48:03 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 11:48:03 +0200 Subject: [Freeipa-devel] [PATCH 0003] Added PyYAML as a dependency for ipa-tests, fixed a replica preparation in RHEL Message-ID: <55D5A253.2070507@redhat.com> Fixed two failures of integration tests under RHEL: 1. PyYAML, needed for integration tests is not installed as a dependency 2. ipa-replica-prepare requests a reverse zone info under RHEL. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0003-Added-PyYAML-as-a-dependency-for-ipa-tests.patch Type: text/x-patch Size: 1618 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 20 09:52:54 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 11:52:54 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5A0EA.2070102@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> Message-ID: <55D5A376.6070100@redhat.com> On 08/20/2015 11:42 AM, Oleg Fayans wrote: > Hi Martin > > On 08/20/2015 11:33 AM, Martin Basti wrote: >> >> >> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>> Hi all, >>> >>> I am trying to run integration tests for dnssec in RHEL-7.2 >>> The tests keep failing at the step of preparing the replica. I figured >>> out, the ipa-replica-prepare with the standard parameters requests >>> reverse zone info (does not do it in fedora) which causes the test to >>> fail. >>> >>> Does anyone know why does it do it? We can, of course update our tests >>> adding a --no-reverse option, but I'd like to know how come it behaves >>> differently depending on the platform. >>> >>> The system is >>> dell-pe1950-06.rhts.eng.brq.redhat.com >>> >>> The command looks like this: >>> >>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>> Do you want to configure the reverse zone? [yes]: >>> >> Reverse zone is not needed for DNSSEC test, you can use --no-reverse >> option. >> >> Did you test fedora on the same machine? > No, it's a beaker-provisioned vm. > > I added a --no-reverse to the install_replica method in > ipatests/test_integration/tasks.py. It fixed this particular issue. > However, now the test fails at the step of ipa-replica-install: > > [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w > '' --ip-address 10.34.54.25 > /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg > --setup-ca --setup-dns --forwarder 10.34.32.1 > WARNING: conflicting time&date synchronization service 'chronyd' will > be disabled in favor of ntpd > > ipa : ERROR Unable to resolve the IP address > 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts and > DNS name resolution > Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP address of replica or master. From mbasti at redhat.com Thu Aug 20 10:01:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 12:01:21 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5A376.6070100@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> Message-ID: <55D5A571.8030701@redhat.com> On 08/20/2015 11:52 AM, Martin Basti wrote: > > > On 08/20/2015 11:42 AM, Oleg Fayans wrote: >> Hi Martin >> >> On 08/20/2015 11:33 AM, Martin Basti wrote: >>> >>> >>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>> Hi all, >>>> >>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>> The tests keep failing at the step of preparing the replica. I figured >>>> out, the ipa-replica-prepare with the standard parameters requests >>>> reverse zone info (does not do it in fedora) which causes the test to >>>> fail. >>>> >>>> Does anyone know why does it do it? We can, of course update our tests >>>> adding a --no-reverse option, but I'd like to know how come it behaves >>>> differently depending on the platform. >>>> >>>> The system is >>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>> >>>> The command looks like this: >>>> >>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>> Do you want to configure the reverse zone? [yes]: >>>> >>> Reverse zone is not needed for DNSSEC test, you can use --no-reverse >>> option. >>> >>> Did you test fedora on the same machine? >> No, it's a beaker-provisioned vm. >> >> I added a --no-reverse to the install_replica method in >> ipatests/test_integration/tasks.py. It fixed this particular issue. >> However, now the test fails at the step of ipa-replica-install: >> >> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >> '' --ip-address 10.34.54.25 >> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >> --setup-ca --setup-dns --forwarder 10.34.32.1 >> WARNING: conflicting time&date synchronization service 'chronyd' will >> be disabled in favor of ntpd >> >> ipa : ERROR Unable to resolve the IP address >> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >> and DNS name resolution >> > > Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP > address of replica or master. > > Does the resolv.conf point to master on replica? From mbabinsk at redhat.com Thu Aug 20 10:08:16 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 20 Aug 2015 12:08:16 +0200 Subject: [Freeipa-devel] [PATCH 0003] Added PyYAML as a dependency for ipa-tests, fixed a replica preparation in RHEL In-Reply-To: <55D5A253.2070507@redhat.com> References: <55D5A253.2070507@redhat.com> Message-ID: <55D5A710.9010903@redhat.com> On 08/20/2015 11:48 AM, Oleg Fayans wrote: > Fixed two failures of integration tests under RHEL: > 1. PyYAML, needed for integration tests is not installed as a dependency > 2. ipa-replica-prepare requests a reverse zone info under RHEL. > > > > Hi Oleg, it is a good practice to fix unrelated issues in separate patches, not a single one. Also, I am not sure PyYAML should be marked as required dependency. According to http://www.freeipa.org/page/Integration_testing_configuration the YAML/JSON configuration of tests is optional besides using environment variables. I might be better to handle the ImportError when IPATEST_YAML_CONFIG is set without PyYAML installed (see `ipatests/test_integration/env_config.py` line 110) and print some error message instructing the user to install the package. -- Martin^3 Babinsky From mbabinsk at redhat.com Thu Aug 20 10:11:28 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 20 Aug 2015 12:11:28 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D5A0B9.8020908@redhat.com> References: <55D47C85.6050008@redhat.com> <55D4AEA1.9040507@redhat.com> <55D5A0B9.8020908@redhat.com> Message-ID: <55D5A7D0.3040601@redhat.com> On 08/20/2015 11:41 AM, thierry bordaz wrote: > On 08/19/2015 06:28 PM, Martin Babinsky wrote: >> On 08/19/2015 02:54 PM, Martin Babinsky wrote: >>> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from >>> happening. >>> >>> >>> >> Actually, we (myself, mbasti, jcholast) found out that `user-del >> --preserve` could use some more usability improvements. >> >> This quick patch should fix both >> https://fedorahosted.org/freeipa/ticket/5234 and >> https://fedorahosted.org/freeipa/ticket/5236 and make user >> preservation operate on multiple arguments in a same way as plain >> deletion. >> >> >> > > Hi Martin, > > The tests are ok and the fix looks good to me. > > ACK > > thanks > thierry That's nice, but I have found some small nitpicks and will send an updated version. So self-NACK. -- Martin^3 Babinsky From msimacek at redhat.com Thu Aug 20 10:32:12 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Thu, 20 Aug 2015 12:32:12 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <20150819092653.GK22106@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> Message-ID: <55D5ACAC.7010001@redhat.com> On 2015-08-19 11:26, Alexander Bokovoy wrote: > On Tue, 18 Aug 2015, Michael ?im??ek wrote: >> On 2015-08-17 21:10, Robbie Harwood wrote: >>> Michael ?im??ek writes: >>> >>>> Attaching new revision of the patch. Changes from the previous: >>>> - ldap2's connect now chooses the bind type same way as in ipaldap >>>> - get_default_realm usages replaced by api.env.realm >>>> - fixed missing third kinit attempt in trust-fetch-domains >>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>> - updated some parts of exception handling >>> >>> This patch doesn't seem to apply to master. Can you update it or >>> indicate what you're patching against? Thanks! >>> >> >> Attaching patch rebased on top of current master. > My refactoring of com.redhat.idm.trust-fetch-domains went in yesterday > so this patch will not apply anymore. Could you please rebase it? > > Rebased on top of current master. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-5-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 69583 bytes Desc: not available URL: From ofayans at redhat.com Thu Aug 20 10:37:29 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 12:37:29 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5A571.8030701@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> Message-ID: <55D5ADE9.8000600@redhat.com> On 08/20/2015 12:01 PM, Martin Basti wrote: > > > On 08/20/2015 11:52 AM, Martin Basti wrote: >> >> >> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>> Hi Martin >>> >>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>> Hi all, >>>>> >>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>> The tests keep failing at the step of preparing the replica. I figured >>>>> out, the ipa-replica-prepare with the standard parameters requests >>>>> reverse zone info (does not do it in fedora) which causes the test to >>>>> fail. >>>>> >>>>> Does anyone know why does it do it? We can, of course update our tests >>>>> adding a --no-reverse option, but I'd like to know how come it behaves >>>>> differently depending on the platform. >>>>> >>>>> The system is >>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>> >>>>> The command looks like this: >>>>> >>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>> Do you want to configure the reverse zone? [yes]: >>>>> >>>> Reverse zone is not needed for DNSSEC test, you can use --no-reverse >>>> option. >>>> >>>> Did you test fedora on the same machine? >>> No, it's a beaker-provisioned vm. >>> >>> I added a --no-reverse to the install_replica method in >>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>> However, now the test fails at the step of ipa-replica-install: >>> >>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>> '' --ip-address 10.34.54.25 >>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>> WARNING: conflicting time&date synchronization service 'chronyd' will >>> be disabled in favor of ntpd >>> >>> ipa : ERROR Unable to resolve the IP address >>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>> and DNS name resolution >>> >> >> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >> address of replica or master. >> >> > Does the resolv.conf point to master on replica? It's an ip address of the replica. And yes, it does point to master's ip. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From msimacek at redhat.com Thu Aug 20 10:49:45 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Thu, 20 Aug 2015 12:49:45 +0200 Subject: [Freeipa-devel] Regression in client-install [master] In-Reply-To: <1439902607.2990.25.camel@willson.usersys.redhat.com> References: <1439861125.2990.13.camel@willson.usersys.redhat.com> <55D2D6ED.5080507@redhat.com> <55D2E8C3.3070207@redhat.com> <1439902607.2990.25.camel@willson.usersys.redhat.com> Message-ID: <55D5B0C9.9030402@redhat.com> On 2015-08-18 14:56, Simo Sorce wrote: > On Tue, 2015-08-18 at 10:11 +0200, Michael ?im??ek wrote: >> >> On 2015-08-18 08:55, Tomas Babej wrote: >>> On 08/18/2015 03:25 AM, Simo Sorce wrote: >>>> I see a regression in the client install now that the python-kerberos -> >>>> python-gssapi patches have landed. >>>> Reverting that single patch makes the issue go away, is anyone else >>>> seeing this ? >>>> >>>> Simo. >>>> >>> >>> I believe you're talking about https://fedorahosted.org/freeipa/ticket/5225 >>> >>> I can confirm reverting the gssapi patch did solve the issue yesterday >>> (this is obvious, since the exception originates in the python-gssapi code). >>> >>> Tomas >>> >> >> The bug has been reported and fixed upstream: >> https://github.com/pythongssapi/python-gssapi/issues/72. Updating the >> package in Fedora to latest upstream release should solve the problem. >> Please wait with reverting. > > Please submit a patch to raise the minimum Requires, however I did not > see the same bug, I will make sure I have the latest python-gssapi and > retest. > > Simo. > The package first needs to updated (or is it enough to build it in some Copr?). You're the maintainer of python-gssapi in Fedora, could you perform the update? [1] Did you have any progress with the testing? Could you attach the backtrace and describe how to reproduce the problem? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1254458 Michael From ofayans at redhat.com Thu Aug 20 10:51:17 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 12:51:17 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5ADE9.8000600@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> Message-ID: <55D5B125.5060604@redhat.com> Hi Martin, I guess, I know where is the problem. During replica-install the replica tries to resolve it's own ip to a hostname to check whether the dns is configured correctly. And fails, since we specified --no-reverse during the replica preparation on master. This looks like a bug to me. On 08/20/2015 12:37 PM, Oleg Fayans wrote: > > > On 08/20/2015 12:01 PM, Martin Basti wrote: >> >> >> On 08/20/2015 11:52 AM, Martin Basti wrote: >>> >>> >>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>> Hi Martin >>>> >>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>> Hi all, >>>>>> >>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>> The tests keep failing at the step of preparing the replica. I >>>>>> figured >>>>>> out, the ipa-replica-prepare with the standard parameters requests >>>>>> reverse zone info (does not do it in fedora) which causes the test to >>>>>> fail. >>>>>> >>>>>> Does anyone know why does it do it? We can, of course update our >>>>>> tests >>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>> behaves >>>>>> differently depending on the platform. >>>>>> >>>>>> The system is >>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>> >>>>>> The command looks like this: >>>>>> >>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>> Do you want to configure the reverse zone? [yes]: >>>>>> >>>>> Reverse zone is not needed for DNSSEC test, you can use --no-reverse >>>>> option. >>>>> >>>>> Did you test fedora on the same machine? >>>> No, it's a beaker-provisioned vm. >>>> >>>> I added a --no-reverse to the install_replica method in >>>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>>> However, now the test fails at the step of ipa-replica-install: >>>> >>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>> '' --ip-address 10.34.54.25 >>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>> be disabled in favor of ntpd >>>> >>>> ipa : ERROR Unable to resolve the IP address >>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>> and DNS name resolution >>>> >>> >>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>> address of replica or master. >>> >>> >> Does the resolv.conf point to master on replica? > It's an ip address of the replica. And yes, it does point to master's ip. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Aug 20 11:43:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 13:43:08 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5B125.5060604@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> Message-ID: <55D5BD4C.707@redhat.com> It could be, please file a bug. On 08/20/2015 12:51 PM, Oleg Fayans wrote: > Hi Martin, > > I guess, I know where is the problem. During replica-install the > replica tries to resolve it's own ip to a hostname to check whether > the dns is configured correctly. And fails, since we specified > --no-reverse during the replica preparation on master. > This looks like a bug to me. > > On 08/20/2015 12:37 PM, Oleg Fayans wrote: >> >> >> On 08/20/2015 12:01 PM, Martin Basti wrote: >>> >>> >>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>> Hi Martin >>>>> >>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>> figured >>>>>>> out, the ipa-replica-prepare with the standard parameters requests >>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>> test to >>>>>>> fail. >>>>>>> >>>>>>> Does anyone know why does it do it? We can, of course update our >>>>>>> tests >>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>> behaves >>>>>>> differently depending on the platform. >>>>>>> >>>>>>> The system is >>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>> >>>>>>> The command looks like this: >>>>>>> >>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>> >>>>>> Reverse zone is not needed for DNSSEC test, you can use --no-reverse >>>>>> option. >>>>>> >>>>>> Did you test fedora on the same machine? >>>>> No, it's a beaker-provisioned vm. >>>>> >>>>> I added a --no-reverse to the install_replica method in >>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>>>> However, now the test fails at the step of ipa-replica-install: >>>>> >>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>>> '' --ip-address 10.34.54.25 >>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>>> be disabled in favor of ntpd >>>>> >>>>> ipa : ERROR Unable to resolve the IP address >>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>>> and DNS name resolution >>>>> >>>> >>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>> address of replica or master. >>>> >>>> >>> Does the resolv.conf point to master on replica? >> It's an ip address of the replica. And yes, it does point to master's >> ip. >> > From mbabinsk at redhat.com Thu Aug 20 11:59:33 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 20 Aug 2015 13:59:33 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D5A7D0.3040601@redhat.com> References: <55D47C85.6050008@redhat.com> <55D4AEA1.9040507@redhat.com> <55D5A0B9.8020908@redhat.com> <55D5A7D0.3040601@redhat.com> Message-ID: <55D5C125.4030002@redhat.com> On 08/20/2015 12:11 PM, Martin Babinsky wrote: > On 08/20/2015 11:41 AM, thierry bordaz wrote: >> On 08/19/2015 06:28 PM, Martin Babinsky wrote: >>> On 08/19/2015 02:54 PM, Martin Babinsky wrote: >>>> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from >>>> happening. >>>> >>>> >>>> >>> Actually, we (myself, mbasti, jcholast) found out that `user-del >>> --preserve` could use some more usability improvements. >>> >>> This quick patch should fix both >>> https://fedorahosted.org/freeipa/ticket/5234 and >>> https://fedorahosted.org/freeipa/ticket/5236 and make user >>> preservation operate on multiple arguments in a same way as plain >>> deletion. >>> >>> >>> >> >> Hi Martin, >> >> The tests are ok and the fix looks good to me. >> >> ACK >> >> thanks >> thierry > > That's nice, but I have found some small nitpicks and will send an > updated version. > > So self-NACK. > Attaching updated patch. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0060.2-improve-the-usability-of-ipa-user-del-preserve-comma.patch Type: text/x-patch Size: 7324 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Aug 20 12:04:14 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 20 Aug 2015 14:04:14 +0200 Subject: [Freeipa-devel] [PATCHES 0061-0062] more user-del improvements Message-ID: <55D5C23E.4010207@redhat.com> Patch #61 cleans up the user preservation code a bit Patch #62 does some guerrila rectofaring Patches need my patch 60 to apply. https://fedorahosted.org/freeipa/ticket/5236 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0062-factor-out-the-user-preservation-to-separate-API-com.patch Type: text/x-patch Size: 5816 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0061-user-del-clean-up-the-user-preservation-code-path.patch Type: text/x-patch Size: 2887 bytes Desc: not available URL: From abokovoy at redhat.com Thu Aug 20 12:21:02 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Aug 2015 15:21:02 +0300 Subject: [Freeipa-devel] [PATCH] 0196 trusts: format Kerberos principal properly when fetching trust topology Message-ID: <20150820122102.GR22106@redhat.com> Hi, one more fix for the problem with trusts that Scott Poore found when verifying fixes to bug https://bugzilla.redhat.com/show_bug.cgi?id=1250190 Details are in the commit message. -- / Alexander Bokovoy -------------- next part -------------- From da76899a44af925223816d6e6b03336b457d8e2c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 20 Aug 2015 15:12:42 +0300 Subject: [PATCH 2/2] trusts: format Kerberos principal properly when fetching trust topology For bidirectional trust if we have AD administrator credentials, we should be using them with Kerberos authentication. If we don't have AD administrator credentials, we should be using HTTP/ipa.master at IPA.REALM credentials. This means we should ask formatting 'creds' object in Kerberos style. For one-way trust we'll be fetching trust topology as TDO object, authenticating with pre-created Kerberos credentials cache, so in all cases we do use Kerberos authentication to talk to Active Directory domain controllers over cross-forest trust link. Part of trust refactoring series. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1250190 Fixes: https://fedorahosted.org/freeipa/ticket/5182 --- ipalib/plugins/trust.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 5d04a2a..4e4e0b1 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1487,7 +1487,12 @@ class trustdomain_del(LDAPDelete): def fetch_domains_from_trust(myapi, trustinstance, trust_entry, **options): trust_name = trust_entry['cn'][0] - creds = generate_creds(trustinstance, style=CRED_STYLE_SAMBA, **options) + # We want to use Kerberos if we have admin credentials even with SMB calls + # as eventually use of NTLMSSP will be deprecated for trusted domain operations + # If admin credentials are missing, 'creds' will be None and fetch_domains + # will use HTTP/ipa.master at IPA.REALM principal, e.g. Kerberos authentication + # as well. + creds = generate_creds(trustinstance, style=CRED_STYLE_KERBEROS, **options) server = options.get('realm_server', None) domains = ipaserver.dcerpc.fetch_domains(myapi, trustinstance.local_flatname, -- 2.4.3 From mbasti at redhat.com Thu Aug 20 12:38:08 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 14:38:08 +0200 Subject: [Freeipa-devel] [Freeipa-users] Dns SOA MNAME not resolving from LDAP data In-Reply-To: References: <55D5C699.6080205@redhat.com> <55D5C8C0.80009@redhat.com> Message-ID: <55D5CA30.9040009@redhat.com> On 08/20/2015 02:35 PM, David Dejaeghere wrote: > Aha, > > Correct. But i never set this. This option seems to be set by default. > I verified this issue on multiple installs. It seems they all have > this option set by default? > > Can i safely change named.conf without fearing my modifications will > be lost on an update? > > Kind Regards, > > David (Adding freeipa-users back) I checked code, it is default. You can change named.conf, upgrade will not replace it. Martin > > 2015-08-20 14:32 GMT+02:00 Martin Basti >: > > > On 08/20/2015 02:22 PM, Martin Basti wrote: >> >> >> On 08/20/2015 01:48 PM, David Dejaeghere wrote: >>> Hi, >>> >>> I noticed that changing the authoritarive nameserver in FreeIPA >>> reflects correctly to its directory data but bind will not >>> resolve the soa record with the updated mname details. >>> >>> For example I add a zone test.be and change the >>> mname record. >>> >>> [root at ns02 ~]# ipa dnszone-add >>> Zone name: test.be >>> Zone name: test.be . >>> Active zone: TRUE >>> * Authoritative nameserver: ns02.tokiogroup.be >>> .* >>> Administrator e-mail address: hostmaster >>> SOA serial: 1440070999 >>> SOA refresh: 3600 >>> SOA retry: 900 >>> SOA expire: 1209600 >>> SOA minimum: 3600 >>> BIND update policy: grant TOKIOGROUP.BE >>> krb5-self * A; grant TOKIOGROUP.BE >>> krb5-self * AAAA; grant TOKIOGROUP.BE >>> krb5-self * >>> SSHFP; >>> Dynamic update: FALSE >>> Allow query: any; >>> Allow transfer: none; >>> [root at ns02 ~]# ipa dnszone-mod --nameserver >>> anaconda-ks.cfg .bash_logout .bashrc .ipa/ >>> .ssh/ >>> .bash_history .bash_profile .cshrc .pki/ >>> .tcshrc >>> >>> >>> [root at ns02 ~]# ipa dnszone-mod --name-server*ns7.tokiogroup.be >>> *. >>> Zone name: test.be >>> ipa: WARNING: Semantic of setting Authoritative nameserver was >>> changed. It is used only for setting the SOA MNAME attribute. >>> NS record(s) can be edited in zone apex - '@'. >>> Zone name: test.be . >>> Active zone: TRUE >>> *Authoritative nameserver: ns7.tokiogroup.be >>> .* >>> Administrator e-mail address: hostmaster >>> SOA serial: 1440071001 >>> SOA refresh: 3600 >>> SOA retry: 900 >>> SOA expire: 1209600 >>> SOA minimum: 3600 >>> Allow query: any; >>> Allow transfer: none; >>> >>> >>> [root at ns02 ~]# nslookup >>> > set q=SOA >>> > test.be >>> Server: 127.0.0.1 >>> Address: 127.0.0.1#53 >>> >>> test.be >>> *origin = ns02.tokiogroup.be * >>> mail addr = hostmaster.test.be >>> serial = 1440071001 >>> refresh = 3600 >>> retry = 900 >>> expire = 1209600 >>> minimum = 3600 >>> >>> As you can see the SOA record still shows the original default >>> value. >>> >>> Kind Regards, >>> >>> David Dejaeghere >>> >>> >> >> Thank you for this bug report. >> I opened bind-dyndb-ldap ticket >> https://fedorahosted.org/bind-dyndb-ldap/ticket/159 >> >> Martin >> >> > I maybe found why do you have this issue, > > do you have fake_mname configured in bind_dyndb_ldap section of > named.conf? > If yes then remove this option to use SOA MNAME from LDAP. > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu Aug 20 12:40:45 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 14:40:45 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5BD4C.707@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> Message-ID: <55D5CACD.20306@redhat.com> Done. https://fedorahosted.org/freeipa/ticket/5240 The initial question however is still unsolved: why does ipa-replica-prepare behaves differently on fedora and rhel? I thought, rhel host had more than one reverse zone, but it's not the case. On 08/20/2015 01:43 PM, Martin Basti wrote: > It could be, please file a bug. > > On 08/20/2015 12:51 PM, Oleg Fayans wrote: >> Hi Martin, >> >> I guess, I know where is the problem. During replica-install the >> replica tries to resolve it's own ip to a hostname to check whether >> the dns is configured correctly. And fails, since we specified >> --no-reverse during the replica preparation on master. >> This looks like a bug to me. >> >> On 08/20/2015 12:37 PM, Oleg Fayans wrote: >>> >>> >>> On 08/20/2015 12:01 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>>> Hi Martin >>>>>> >>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>>> figured >>>>>>>> out, the ipa-replica-prepare with the standard parameters requests >>>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>>> test to >>>>>>>> fail. >>>>>>>> >>>>>>>> Does anyone know why does it do it? We can, of course update our >>>>>>>> tests >>>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>>> behaves >>>>>>>> differently depending on the platform. >>>>>>>> >>>>>>>> The system is >>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>>> >>>>>>>> The command looks like this: >>>>>>>> >>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>> >>>>>>> Reverse zone is not needed for DNSSEC test, you can use --no-reverse >>>>>>> option. >>>>>>> >>>>>>> Did you test fedora on the same machine? >>>>>> No, it's a beaker-provisioned vm. >>>>>> >>>>>> I added a --no-reverse to the install_replica method in >>>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>>>>> However, now the test fails at the step of ipa-replica-install: >>>>>> >>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>>>> '' --ip-address 10.34.54.25 >>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>>>> be disabled in favor of ntpd >>>>>> >>>>>> ipa : ERROR Unable to resolve the IP address >>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>>>> and DNS name resolution >>>>>> >>>>> >>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>>> address of replica or master. >>>>> >>>>> >>>> Does the resolv.conf point to master on replica? >>> It's an ip address of the replica. And yes, it does point to master's >>> ip. >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Aug 20 12:46:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 14:46:22 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5CACD.20306@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> Message-ID: <55D5CC1E.9050202@redhat.com> On 08/20/2015 02:40 PM, Oleg Fayans wrote: > Done. https://fedorahosted.org/freeipa/ticket/5240 > > The initial question however is still unsolved: why does > ipa-replica-prepare behaves differently on fedora and rhel? I thought, > rhel host had more than one reverse zone, but it's not the case. Can you try fedora on the same machine? > > > On 08/20/2015 01:43 PM, Martin Basti wrote: >> It could be, please file a bug. >> >> On 08/20/2015 12:51 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> I guess, I know where is the problem. During replica-install the >>> replica tries to resolve it's own ip to a hostname to check whether >>> the dns is configured correctly. And fails, since we specified >>> --no-reverse during the replica preparation on master. >>> This looks like a bug to me. >>> >>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: >>>> >>>> >>>> On 08/20/2015 12:01 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>>>> Hi Martin >>>>>>> >>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>>>> figured >>>>>>>>> out, the ipa-replica-prepare with the standard parameters >>>>>>>>> requests >>>>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>>>> test to >>>>>>>>> fail. >>>>>>>>> >>>>>>>>> Does anyone know why does it do it? We can, of course update our >>>>>>>>> tests >>>>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>>>> behaves >>>>>>>>> differently depending on the platform. >>>>>>>>> >>>>>>>>> The system is >>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>>>> >>>>>>>>> The command looks like this: >>>>>>>>> >>>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>> >>>>>>>> Reverse zone is not needed for DNSSEC test, you can use >>>>>>>> --no-reverse >>>>>>>> option. >>>>>>>> >>>>>>>> Did you test fedora on the same machine? >>>>>>> No, it's a beaker-provisioned vm. >>>>>>> >>>>>>> I added a --no-reverse to the install_replica method in >>>>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>>>>>> However, now the test fails at the step of ipa-replica-install: >>>>>>> >>>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>>>>> '' --ip-address 10.34.54.25 >>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>>>> >>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' >>>>>>> will >>>>>>> be disabled in favor of ntpd >>>>>>> >>>>>>> ipa : ERROR Unable to resolve the IP address >>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>>>>> and DNS name resolution >>>>>>> >>>>>> >>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>>>> address of replica or master. >>>>>> >>>>>> >>>>> Does the resolv.conf point to master on replica? >>>> It's an ip address of the replica. And yes, it does point to master's >>>> ip. >>>> >>> >> > From ofayans at redhat.com Thu Aug 20 13:01:19 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 15:01:19 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5CC1E.9050202@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> <55D5CC1E.9050202@redhat.com> Message-ID: <55D5CF9F.4000902@redhat.com> On 08/20/2015 02:46 PM, Martin Basti wrote: > > > On 08/20/2015 02:40 PM, Oleg Fayans wrote: >> Done. https://fedorahosted.org/freeipa/ticket/5240 >> >> The initial question however is still unsolved: why does >> ipa-replica-prepare behaves differently on fedora and rhel? I thought, >> rhel host had more than one reverse zone, but it's not the case. > Can you try fedora on the same machine? I guess, I can create a new fedora-based vm and install official package there. >> >> >> On 08/20/2015 01:43 PM, Martin Basti wrote: >>> It could be, please file a bug. >>> >>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> I guess, I know where is the problem. During replica-install the >>>> replica tries to resolve it's own ip to a hostname to check whether >>>> the dns is configured correctly. And fails, since we specified >>>> --no-reverse during the replica preparation on master. >>>> This looks like a bug to me. >>>> >>>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: >>>>> >>>>> >>>>> On 08/20/2015 12:01 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>>>>> Hi Martin >>>>>>>> >>>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>>>>> figured >>>>>>>>>> out, the ipa-replica-prepare with the standard parameters >>>>>>>>>> requests >>>>>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>>>>> test to >>>>>>>>>> fail. >>>>>>>>>> >>>>>>>>>> Does anyone know why does it do it? We can, of course update our >>>>>>>>>> tests >>>>>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>>>>> behaves >>>>>>>>>> differently depending on the platform. >>>>>>>>>> >>>>>>>>>> The system is >>>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>>>>> >>>>>>>>>> The command looks like this: >>>>>>>>>> >>>>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>>> >>>>>>>>> Reverse zone is not needed for DNSSEC test, you can use >>>>>>>>> --no-reverse >>>>>>>>> option. >>>>>>>>> >>>>>>>>> Did you test fedora on the same machine? >>>>>>>> No, it's a beaker-provisioned vm. >>>>>>>> >>>>>>>> I added a --no-reverse to the install_replica method in >>>>>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>>>>>>> However, now the test fails at the step of ipa-replica-install: >>>>>>>> >>>>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>>>>>> '' --ip-address 10.34.54.25 >>>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>>>>> >>>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' >>>>>>>> will >>>>>>>> be disabled in favor of ntpd >>>>>>>> >>>>>>>> ipa : ERROR Unable to resolve the IP address >>>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>>>>>> and DNS name resolution >>>>>>>> >>>>>>> >>>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>>>>> address of replica or master. >>>>>>> >>>>>>> >>>>>> Does the resolv.conf point to master on replica? >>>>> It's an ip address of the replica. And yes, it does point to master's >>>>> ip. >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Aug 20 13:09:10 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 15:09:10 +0200 Subject: [Freeipa-devel] [Freeipa-users] Dns SOA MNAME not resolving from LDAP data In-Reply-To: References: <55D5C699.6080205@redhat.com> <55D5C8C0.80009@redhat.com> <55D5CA30.9040009@redhat.com> Message-ID: <55D5D176.3090907@redhat.com> On 08/20/2015 02:46 PM, David Dejaeghere wrote: > confirmed working. > Does this default value make any sense if this value is changeable in > the UI and using the IPA client? > > Kind Regards, > > David IMHO (I'm not 100% sure) IPA DNS are master servers, which contains only authoritative zones. Each DNS server contains the same copy of zones synchronized with LDAP database, and each server is authoritative for that zone (multimaster DNS topology). So there is no reason to have listed different server than IPA DNS as authoritative servers. This works for majority users. This also works as fallback (on local network only without caching) when one replica is down, the one of IPA DNS servers left, may act as authoritative servers (primary master for DDNS). I agree that this is tricky (I forgot about fake_mname too) for users who want to change it, we may show warning for user or somehow let him know that fake_mname is used. Martin > > 2015-08-20 14:38 GMT+02:00 Martin Basti >: > > > > On 08/20/2015 02:35 PM, David Dejaeghere wrote: >> Aha, >> >> Correct. But i never set this. This option seems to be set by >> default. >> I verified this issue on multiple installs. It seems they all >> have this option set by default? >> >> Can i safely change named.conf without fearing my modifications >> will be lost on an update? >> >> Kind Regards, >> >> David > (Adding freeipa-users back) > > I checked code, it is default. > > You can change named.conf, upgrade will not replace it. > > Martin > >> >> 2015-08-20 14:32 GMT+02:00 Martin Basti > >: >> >> >> On 08/20/2015 02:22 PM, Martin Basti wrote: >>> >>> >>> On 08/20/2015 01:48 PM, David Dejaeghere wrote: >>>> Hi, >>>> >>>> I noticed that changing the authoritarive nameserver in >>>> FreeIPA reflects correctly to its directory data but bind >>>> will not resolve the soa record with the updated mname details. >>>> >>>> For example I add a zone test.be and >>>> change the mname record. >>>> >>>> [root at ns02 ~]# ipa dnszone-add >>>> Zone name: test.be >>>> Zone name: test.be . >>>> Active zone: TRUE >>>> * Authoritative nameserver: ns02.tokiogroup.be >>>> .* >>>> Administrator e-mail address: hostmaster >>>> SOA serial: 1440070999 >>>> SOA refresh: 3600 >>>> SOA retry: 900 >>>> SOA expire: 1209600 >>>> SOA minimum: 3600 >>>> BIND update policy: grant TOKIOGROUP.BE >>>> krb5-self * A; grant TOKIOGROUP.BE >>>> krb5-self * AAAA; grant >>>> TOKIOGROUP.BE krb5-self * >>>> SSHFP; >>>> Dynamic update: FALSE >>>> Allow query: any; >>>> Allow transfer: none; >>>> [root at ns02 ~]# ipa dnszone-mod --nameserver >>>> anaconda-ks.cfg .bash_logout .bashrc .ipa/ .ssh/ >>>> .bash_history .bash_profile .cshrc .pki/ .tcshrc >>>> >>>> >>>> [root at ns02 ~]# ipa dnszone-mod >>>> --name-server*ns7.tokiogroup.be *. >>>> Zone name: test.be >>>> ipa: WARNING: Semantic of setting Authoritative nameserver >>>> was changed. It is used only for setting the SOA MNAME >>>> attribute. >>>> NS record(s) can be edited in zone apex - '@'. >>>> Zone name: test.be . >>>> Active zone: TRUE >>>> *Authoritative nameserver: ns7.tokiogroup.be >>>> .* >>>> Administrator e-mail address: hostmaster >>>> SOA serial: 1440071001 >>>> SOA refresh: 3600 >>>> SOA retry: 900 >>>> SOA expire: 1209600 >>>> SOA minimum: 3600 >>>> Allow query: any; >>>> Allow transfer: none; >>>> >>>> >>>> [root at ns02 ~]# nslookup >>>> > set q=SOA >>>> > test.be >>>> Server: 127.0.0.1 >>>> Address: 127.0.0.1#53 >>>> >>>> test.be >>>> *origin = ns02.tokiogroup.be * >>>> mail addr = hostmaster.test.be >>>> >>>> serial = 1440071001 >>>> refresh = 3600 >>>> retry = 900 >>>> expire = 1209600 >>>> minimum = 3600 >>>> >>>> As you can see the SOA record still shows the original >>>> default value. >>>> >>>> Kind Regards, >>>> >>>> David Dejaeghere >>>> >>>> >>> >>> Thank you for this bug report. >>> I opened bind-dyndb-ldap ticket >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/159 >>> >>> Martin >>> >>> >> I maybe found why do you have this issue, >> >> do you have fake_mname configured in bind_dyndb_ldap section >> of named.conf? >> If yes then remove this option to use SOA MNAME from LDAP. >> >> Martin >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Aug 20 13:10:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 15:10:35 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5CF9F.4000902@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> <55D5CC1E.9050202@redhat.com> <55D5CF9F.4000902@redhat.com> Message-ID: <55D5D1CB.6020205@redhat.com> On 08/20/2015 03:01 PM, Oleg Fayans wrote: > > > On 08/20/2015 02:46 PM, Martin Basti wrote: >> >> >> On 08/20/2015 02:40 PM, Oleg Fayans wrote: >>> Done. https://fedorahosted.org/freeipa/ticket/5240 >>> >>> The initial question however is still unsolved: why does >>> ipa-replica-prepare behaves differently on fedora and rhel? I thought, >>> rhel host had more than one reverse zone, but it's not the case. >> Can you try fedora on the same machine? > I guess, I can create a new fedora-based vm and install official > package there. Okay because I think it is caused by different enviroment. > >>> >>> >>> On 08/20/2015 01:43 PM, Martin Basti wrote: >>>> It could be, please file a bug. >>>> >>>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> I guess, I know where is the problem. During replica-install the >>>>> replica tries to resolve it's own ip to a hostname to check whether >>>>> the dns is configured correctly. And fails, since we specified >>>>> --no-reverse during the replica preparation on master. >>>>> This looks like a bug to me. >>>>> >>>>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: >>>>>> >>>>>> >>>>>> On 08/20/2015 12:01 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>>>>>> Hi Martin >>>>>>>>> >>>>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>>>>>> figured >>>>>>>>>>> out, the ipa-replica-prepare with the standard parameters >>>>>>>>>>> requests >>>>>>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>>>>>> test to >>>>>>>>>>> fail. >>>>>>>>>>> >>>>>>>>>>> Does anyone know why does it do it? We can, of course update >>>>>>>>>>> our >>>>>>>>>>> tests >>>>>>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>>>>>> behaves >>>>>>>>>>> differently depending on the platform. >>>>>>>>>>> >>>>>>>>>>> The system is >>>>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>>>>>> >>>>>>>>>>> The command looks like this: >>>>>>>>>>> >>>>>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>>>> >>>>>>>>>> Reverse zone is not needed for DNSSEC test, you can use >>>>>>>>>> --no-reverse >>>>>>>>>> option. >>>>>>>>>> >>>>>>>>>> Did you test fedora on the same machine? >>>>>>>>> No, it's a beaker-provisioned vm. >>>>>>>>> >>>>>>>>> I added a --no-reverse to the install_replica method in >>>>>>>>> ipatests/test_integration/tasks.py. It fixed this particular >>>>>>>>> issue. >>>>>>>>> However, now the test fails at the step of ipa-replica-install: >>>>>>>>> >>>>>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p >>>>>>>>> '' -w >>>>>>>>> '' --ip-address 10.34.54.25 >>>>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>>>>>> >>>>>>>>> >>>>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' >>>>>>>>> will >>>>>>>>> be disabled in favor of ntpd >>>>>>>>> >>>>>>>>> ipa : ERROR Unable to resolve the IP address >>>>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check >>>>>>>>> /etc/hosts >>>>>>>>> and DNS name resolution >>>>>>>>> >>>>>>>> >>>>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>>>>>> address of replica or master. >>>>>>>> >>>>>>>> >>>>>>> Does the resolv.conf point to master on replica? >>>>>> It's an ip address of the replica. And yes, it does point to >>>>>> master's >>>>>> ip. >>>>>> >>>>> >>>> >>> >> > From pvoborni at redhat.com Thu Aug 20 13:11:46 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Aug 2015 15:11:46 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5CC1E.9050202@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> <55D5CC1E.9050202@redhat.com> Message-ID: <55D5D212.5070900@redhat.com> On 08/20/2015 02:46 PM, Martin Basti wrote: > > > On 08/20/2015 02:40 PM, Oleg Fayans wrote: >> Done. https://fedorahosted.org/freeipa/ticket/5240 >> >> The initial question however is still unsolved: why does >> ipa-replica-prepare behaves differently on fedora and rhel? I thought, >> rhel host had more than one reverse zone, but it's not the case. > Can you try fedora on the same machine? Are you sure that both systems has the same configuration. E.g. one could have only IPv4 but the other also IPv6? >> >> >> On 08/20/2015 01:43 PM, Martin Basti wrote: >>> It could be, please file a bug. >>> >>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> I guess, I know where is the problem. During replica-install the >>>> replica tries to resolve it's own ip to a hostname to check whether >>>> the dns is configured correctly. And fails, since we specified >>>> --no-reverse during the replica preparation on master. >>>> This looks like a bug to me. Why is that a bug? Where should ipa-replica-prepare put a SRV record if no reverse zone is created? I.e. if I do not want to add them by ipa-replica-prepare e.g. because they are not managed in IPA then they have to be added to DNS server(whatever server it is) by other means. >>>> >>>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: >>>>> >>>>> >>>>> On 08/20/2015 12:01 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>>>>> Hi Martin >>>>>>>> >>>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>>>>> figured >>>>>>>>>> out, the ipa-replica-prepare with the standard parameters >>>>>>>>>> requests >>>>>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>>>>> test to >>>>>>>>>> fail. >>>>>>>>>> >>>>>>>>>> Does anyone know why does it do it? We can, of course update our >>>>>>>>>> tests >>>>>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>>>>> behaves >>>>>>>>>> differently depending on the platform. >>>>>>>>>> >>>>>>>>>> The system is >>>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>>>>> >>>>>>>>>> The command looks like this: >>>>>>>>>> >>>>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>>> >>>>>>>>> Reverse zone is not needed for DNSSEC test, you can use >>>>>>>>> --no-reverse >>>>>>>>> option. >>>>>>>>> >>>>>>>>> Did you test fedora on the same machine? >>>>>>>> No, it's a beaker-provisioned vm. >>>>>>>> >>>>>>>> I added a --no-reverse to the install_replica method in >>>>>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>>>>>>> However, now the test fails at the step of ipa-replica-install: >>>>>>>> >>>>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>>>>>> '' --ip-address 10.34.54.25 >>>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>>>>> >>>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' >>>>>>>> will >>>>>>>> be disabled in favor of ntpd >>>>>>>> >>>>>>>> ipa : ERROR Unable to resolve the IP address >>>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>>>>>> and DNS name resolution >>>>>>>> >>>>>>> >>>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>>>>> address of replica or master. >>>>>>> >>>>>>> >>>>>> Does the resolv.conf point to master on replica? >>>>> It's an ip address of the replica. And yes, it does point to master's >>>>> ip. >>>>> >>>> >>> >> > -- Petr Vobornik From simo at redhat.com Thu Aug 20 13:19:27 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Aug 2015 09:19:27 -0400 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5D212.5070900@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> <55D5CC1E.9050202@redhat.com> <55D5D212.5070900@redhat.com> Message-ID: <1440076767.2990.82.camel@willson.usersys.redhat.com> On Thu, 2015-08-20 at 15:11 +0200, Petr Vobornik wrote: > On 08/20/2015 02:46 PM, Martin Basti wrote: > > > > > > On 08/20/2015 02:40 PM, Oleg Fayans wrote: > >> Done. https://fedorahosted.org/freeipa/ticket/5240 > >> > >> The initial question however is still unsolved: why does > >> ipa-replica-prepare behaves differently on fedora and rhel? I thought, > >> rhel host had more than one reverse zone, but it's not the case. Not sure why the difference but you can pass --no-host-dns to ipa-replica-install, it should skip the reverse zone check. We may want to add a ticket to make the reverse check just a warning, installation should not fail, but the default is to stop in unattended mode unfortunately. > > Can you try fedora on the same machine? > > Are you sure that both systems has the same configuration. E.g. one > could have only IPv4 but the other also IPv6? > > >> > >> > >> On 08/20/2015 01:43 PM, Martin Basti wrote: > >>> It could be, please file a bug. > >>> > >>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: > >>>> Hi Martin, > >>>> > >>>> I guess, I know where is the problem. During replica-install the > >>>> replica tries to resolve it's own ip to a hostname to check whether > >>>> the dns is configured correctly. And fails, since we specified > >>>> --no-reverse during the replica preparation on master. > >>>> This looks like a bug to me. > > Why is that a bug? Where should ipa-replica-prepare put a SRV record if > no reverse zone is created? SRV records are not stored in the reverse zone, we should work just fine w/o a reverse zone. > I.e. if I do not want to add them by ipa-replica-prepare e.g. because > they are not managed in IPA then they have to be added to DNS > server(whatever server it is) by other means. We *should* be able to work fine w/o reverse zones or with reverse zones that point to bogus names. I think this is something we SHOULD test because it is a normal network condition in some organizations (because they can't control reverse). If something fails if reverse is wrong/missing we need to fix it, because relying on reverse resolution is broken (vs security) anyway and we should not. Simo. > > > >>>> > >>>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: > >>>>> > >>>>> > >>>>> On 08/20/2015 12:01 PM, Martin Basti wrote: > >>>>>> > >>>>>> > >>>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: > >>>>>>> > >>>>>>> > >>>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: > >>>>>>>> Hi Martin > >>>>>>>> > >>>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 > >>>>>>>>>> The tests keep failing at the step of preparing the replica. I > >>>>>>>>>> figured > >>>>>>>>>> out, the ipa-replica-prepare with the standard parameters > >>>>>>>>>> requests > >>>>>>>>>> reverse zone info (does not do it in fedora) which causes the > >>>>>>>>>> test to > >>>>>>>>>> fail. > >>>>>>>>>> > >>>>>>>>>> Does anyone know why does it do it? We can, of course update our > >>>>>>>>>> tests > >>>>>>>>>> adding a --no-reverse option, but I'd like to know how come it > >>>>>>>>>> behaves > >>>>>>>>>> differently depending on the platform. > >>>>>>>>>> > >>>>>>>>>> The system is > >>>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com > >>>>>>>>>> > >>>>>>>>>> The command looks like this: > >>>>>>>>>> > >>>>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' > >>>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com > >>>>>>>>>> Do you want to configure the reverse zone? [yes]: > >>>>>>>>>> > >>>>>>>>> Reverse zone is not needed for DNSSEC test, you can use > >>>>>>>>> --no-reverse > >>>>>>>>> option. > >>>>>>>>> > >>>>>>>>> Did you test fedora on the same machine? > >>>>>>>> No, it's a beaker-provisioned vm. > >>>>>>>> > >>>>>>>> I added a --no-reverse to the install_replica method in > >>>>>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. > >>>>>>>> However, now the test fails at the step of ipa-replica-install: > >>>>>>>> > >>>>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w > >>>>>>>> '' --ip-address 10.34.54.25 > >>>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg > >>>>>>>> > >>>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 > >>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' > >>>>>>>> will > >>>>>>>> be disabled in favor of ntpd > >>>>>>>> > >>>>>>>> ipa : ERROR Unable to resolve the IP address > >>>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts > >>>>>>>> and DNS name resolution > >>>>>>>> > >>>>>>> > >>>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP > >>>>>>> address of replica or master. > >>>>>>> > >>>>>>> > >>>>>> Does the resolv.conf point to master on replica? > >>>>> It's an ip address of the replica. And yes, it does point to master's > >>>>> ip. > >>>>> > >>>> > >>> > >> > > > > > -- > Petr Vobornik > -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Aug 20 13:36:15 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Aug 2015 15:36:15 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <1440076767.2990.82.camel@willson.usersys.redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> <55D5CC1E.9050202@redhat.com> <55D5D212.5070900@redhat.com> <1440076767.2990.82.camel@willson.usersys.redhat.com> Message-ID: <55D5D7CF.6040608@redhat.com> On 08/20/2015 03:19 PM, Simo Sorce wrote: > On Thu, 2015-08-20 at 15:11 +0200, Petr Vobornik wrote: >> On 08/20/2015 02:46 PM, Martin Basti wrote: >>> >>> >>> On 08/20/2015 02:40 PM, Oleg Fayans wrote: >>>> Done. https://fedorahosted.org/freeipa/ticket/5240 >>>> >>>> The initial question however is still unsolved: why does >>>> ipa-replica-prepare behaves differently on fedora and rhel? I thought, >>>> rhel host had more than one reverse zone, but it's not the case. > > Not sure why the difference but you can pass --no-host-dns to > ipa-replica-install, it should skip the reverse zone check. > We may want to add a ticket to make the reverse check just a warning, > installation should not fail, but the default is to stop in unattended > mode unfortunately. > >>> Can you try fedora on the same machine? >> >> Are you sure that both systems has the same configuration. E.g. one >> could have only IPv4 but the other also IPv6? >> >>>> >>>> >>>> On 08/20/2015 01:43 PM, Martin Basti wrote: >>>>> It could be, please file a bug. >>>>> >>>>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> I guess, I know where is the problem. During replica-install the >>>>>> replica tries to resolve it's own ip to a hostname to check whether >>>>>> the dns is configured correctly. And fails, since we specified >>>>>> --no-reverse during the replica preparation on master. >>>>>> This looks like a bug to me. >> >> Why is that a bug? Where should ipa-replica-prepare put a SRV record if >> no reverse zone is created? > > SRV records are not stored in the reverse zone, we should work just fine > w/o a reverse zone. Sorry, I meant PTR > >> I.e. if I do not want to add them by ipa-replica-prepare e.g. because >> they are not managed in IPA then they have to be added to DNS >> server(whatever server it is) by other means. > > We *should* be able to work fine w/o reverse zones or with reverse zones > that point to bogus names. > I think this is something we SHOULD test because it is a normal network > condition in some organizations (because they can't control reverse). > If something fails if reverse is wrong/missing we need to fix it, > because relying on reverse resolution is broken (vs security) anyway and > we should not. > > Simo. > -- Petr Vobornik From ofayans at redhat.com Thu Aug 20 13:39:02 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 15:39:02 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <55D5D212.5070900@redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> <55D5CC1E.9050202@redhat.com> <55D5D212.5070900@redhat.com> Message-ID: <55D5D876.9070201@redhat.com> On 08/20/2015 03:11 PM, Petr Vobornik wrote: > On 08/20/2015 02:46 PM, Martin Basti wrote: >> >> >> On 08/20/2015 02:40 PM, Oleg Fayans wrote: >>> Done. https://fedorahosted.org/freeipa/ticket/5240 >>> >>> The initial question however is still unsolved: why does >>> ipa-replica-prepare behaves differently on fedora and rhel? I thought, >>> rhel host had more than one reverse zone, but it's not the case. >> Can you try fedora on the same machine? > > Are you sure that both systems has the same configuration. E.g. one > could have only IPv4 but the other also IPv6? Initially they had different configuration: RHEL system had ipv6 additionally. I disabled it to check, whether this was the reason and it did not help. > >>> >>> >>> On 08/20/2015 01:43 PM, Martin Basti wrote: >>>> It could be, please file a bug. >>>> >>>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> I guess, I know where is the problem. During replica-install the >>>>> replica tries to resolve it's own ip to a hostname to check whether >>>>> the dns is configured correctly. And fails, since we specified >>>>> --no-reverse during the replica preparation on master. >>>>> This looks like a bug to me. > > Why is that a bug? Where should ipa-replica-prepare put a SRV record if > no reverse zone is created? > > I.e. if I do not want to add them by ipa-replica-prepare e.g. because > they are not managed in IPA then they have to be added to DNS > server(whatever server it is) by other means. Sounds reasonable. Then the only thing to find out is why ipa-replica-prepare requests reverse-zone in RHEL > > > >>>>> >>>>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: >>>>>> >>>>>> >>>>>> On 08/20/2015 12:01 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>>>>>> Hi Martin >>>>>>>>> >>>>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>>>>>> figured >>>>>>>>>>> out, the ipa-replica-prepare with the standard parameters >>>>>>>>>>> requests >>>>>>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>>>>>> test to >>>>>>>>>>> fail. >>>>>>>>>>> >>>>>>>>>>> Does anyone know why does it do it? We can, of course update our >>>>>>>>>>> tests >>>>>>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>>>>>> behaves >>>>>>>>>>> differently depending on the platform. >>>>>>>>>>> >>>>>>>>>>> The system is >>>>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>>>>>> >>>>>>>>>>> The command looks like this: >>>>>>>>>>> >>>>>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>>>> >>>>>>>>>> Reverse zone is not needed for DNSSEC test, you can use >>>>>>>>>> --no-reverse >>>>>>>>>> option. >>>>>>>>>> >>>>>>>>>> Did you test fedora on the same machine? >>>>>>>>> No, it's a beaker-provisioned vm. >>>>>>>>> >>>>>>>>> I added a --no-reverse to the install_replica method in >>>>>>>>> ipatests/test_integration/tasks.py. It fixed this particular >>>>>>>>> issue. >>>>>>>>> However, now the test fails at the step of ipa-replica-install: >>>>>>>>> >>>>>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>>>>>>> '' --ip-address 10.34.54.25 >>>>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>>>>>> >>>>>>>>> >>>>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' >>>>>>>>> will >>>>>>>>> be disabled in favor of ntpd >>>>>>>>> >>>>>>>>> ipa : ERROR Unable to resolve the IP address >>>>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>>>>>>> and DNS name resolution >>>>>>>>> >>>>>>>> >>>>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>>>>>> address of replica or master. >>>>>>>> >>>>>>>> >>>>>>> Does the resolv.conf point to master on replica? >>>>>> It's an ip address of the replica. And yes, it does point to master's >>>>>> ip. >>>>>> >>>>> >>>> >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ofayans at redhat.com Thu Aug 20 13:42:33 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 20 Aug 2015 15:42:33 +0200 Subject: [Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL In-Reply-To: <1440076767.2990.82.camel@willson.usersys.redhat.com> References: <55D58D41.6060006@redhat.com> <55D59EFC.1000000@redhat.com> <55D5A0EA.2070102@redhat.com> <55D5A376.6070100@redhat.com> <55D5A571.8030701@redhat.com> <55D5ADE9.8000600@redhat.com> <55D5B125.5060604@redhat.com> <55D5BD4C.707@redhat.com> <55D5CACD.20306@redhat.com> <55D5CC1E.9050202@redhat.com> <55D5D212.5070900@redhat.com> <1440076767.2990.82.camel@willson.usersys.redhat.com> Message-ID: <55D5D949.2040708@redhat.com> On 08/20/2015 03:19 PM, Simo Sorce wrote: > On Thu, 2015-08-20 at 15:11 +0200, Petr Vobornik wrote: >> On 08/20/2015 02:46 PM, Martin Basti wrote: >>> >>> >>> On 08/20/2015 02:40 PM, Oleg Fayans wrote: >>>> Done. https://fedorahosted.org/freeipa/ticket/5240 >>>> >>>> The initial question however is still unsolved: why does >>>> ipa-replica-prepare behaves differently on fedora and rhel? I thought, >>>> rhel host had more than one reverse zone, but it's not the case. > > Not sure why the difference but you can pass --no-host-dns to > ipa-replica-install, it should skip the reverse zone check. > We may want to add a ticket to make the reverse check just a warning, > installation should not fail, but the default is to stop in unattended > mode unfortunately. OK, so, I can temporarily add this hack and create a separate ticket requesting to turn an error into a warning if reverse address resolution fails during replica installation, right? The problem is that this issue blocks execution of integration tests in RHEL, which is one of the top-priority tasks for Downstream QE team > >>> Can you try fedora on the same machine? >> >> Are you sure that both systems has the same configuration. E.g. one >> could have only IPv4 but the other also IPv6? >> >>>> >>>> >>>> On 08/20/2015 01:43 PM, Martin Basti wrote: >>>>> It could be, please file a bug. >>>>> >>>>> On 08/20/2015 12:51 PM, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> I guess, I know where is the problem. During replica-install the >>>>>> replica tries to resolve it's own ip to a hostname to check whether >>>>>> the dns is configured correctly. And fails, since we specified >>>>>> --no-reverse during the replica preparation on master. >>>>>> This looks like a bug to me. >> >> Why is that a bug? Where should ipa-replica-prepare put a SRV record if >> no reverse zone is created? > > SRV records are not stored in the reverse zone, we should work just fine > w/o a reverse zone. > >> I.e. if I do not want to add them by ipa-replica-prepare e.g. because >> they are not managed in IPA then they have to be added to DNS >> server(whatever server it is) by other means. > > We *should* be able to work fine w/o reverse zones or with reverse zones > that point to bogus names. > I think this is something we SHOULD test because it is a normal network > condition in some organizations (because they can't control reverse). > If something fails if reverse is wrong/missing we need to fix it, > because relying on reverse resolution is broken (vs security) anyway and > we should not. > > Simo. > >> >> >>>>>> >>>>>> On 08/20/2015 12:37 PM, Oleg Fayans wrote: >>>>>>> >>>>>>> >>>>>>> On 08/20/2015 12:01 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/20/2015 11:52 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/20/2015 11:42 AM, Oleg Fayans wrote: >>>>>>>>>> Hi Martin >>>>>>>>>> >>>>>>>>>> On 08/20/2015 11:33 AM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/20/2015 10:18 AM, Oleg Fayans wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I am trying to run integration tests for dnssec in RHEL-7.2 >>>>>>>>>>>> The tests keep failing at the step of preparing the replica. I >>>>>>>>>>>> figured >>>>>>>>>>>> out, the ipa-replica-prepare with the standard parameters >>>>>>>>>>>> requests >>>>>>>>>>>> reverse zone info (does not do it in fedora) which causes the >>>>>>>>>>>> test to >>>>>>>>>>>> fail. >>>>>>>>>>>> >>>>>>>>>>>> Does anyone know why does it do it? We can, of course update our >>>>>>>>>>>> tests >>>>>>>>>>>> adding a --no-reverse option, but I'd like to know how come it >>>>>>>>>>>> behaves >>>>>>>>>>>> differently depending on the platform. >>>>>>>>>>>> >>>>>>>>>>>> The system is >>>>>>>>>>>> dell-pe1950-06.rhts.eng.brq.redhat.com >>>>>>>>>>>> >>>>>>>>>>>> The command looks like this: >>>>>>>>>>>> >>>>>>>>>>>> [root at dell-pe1950-06 ~]# ipa-replica-prepare -p '' >>>>>>>>>>>> --ip-address 10.34.54.25 dell-pe1950-05.rhts.eng.brq.redhat.com >>>>>>>>>>>> Do you want to configure the reverse zone? [yes]: >>>>>>>>>>>> >>>>>>>>>>> Reverse zone is not needed for DNSSEC test, you can use >>>>>>>>>>> --no-reverse >>>>>>>>>>> option. >>>>>>>>>>> >>>>>>>>>>> Did you test fedora on the same machine? >>>>>>>>>> No, it's a beaker-provisioned vm. >>>>>>>>>> >>>>>>>>>> I added a --no-reverse to the install_replica method in >>>>>>>>>> ipatests/test_integration/tasks.py. It fixed this particular issue. >>>>>>>>>> However, now the test fails at the step of ipa-replica-install: >>>>>>>>>> >>>>>>>>>> [root at dell-pe1950-05 ~]# ipa-replica-install -U -p '' -w >>>>>>>>>> '' --ip-address 10.34.54.25 >>>>>>>>>> /var/lib/ipa/replica-info-dell-pe1950-05.rhts.eng.brq.redhat.com.gpg >>>>>>>>>> >>>>>>>>>> --setup-ca --setup-dns --forwarder 10.34.32.1 >>>>>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' >>>>>>>>>> will >>>>>>>>>> be disabled in favor of ntpd >>>>>>>>>> >>>>>>>>>> ipa : ERROR Unable to resolve the IP address >>>>>>>>>> 2620:52:0:2236:215:c5ff:fef3:e54f to a host name, check /etc/hosts >>>>>>>>>> and DNS name resolution >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hmm, this is interesting, is 2620:52:0:2236:215:c5ff:fef3:e54f IP >>>>>>>>> address of replica or master. >>>>>>>>> >>>>>>>>> >>>>>>>> Does the resolv.conf point to master on replica? >>>>>>> It's an ip address of the replica. And yes, it does point to master's >>>>>>> ip. >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Petr Vobornik >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Thu Aug 20 13:48:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 15:48:23 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55CE1820.5060405@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> Message-ID: <55D5DAA7.5030309@redhat.com> On 08/14/2015 06:32 PM, Lenka Doudova wrote: > Yes, that is "correct" - it's malfunctioning behavior of the plugin - > command 'stageuser-add --from-delete', which is discussed in another > thread. I left this test case for so long as it's not fixed/changed. > If the command remains and is fixed, the test case will be valid, if > it's changed I'll fix the test case to reflect the new command. > > Lenka > > On 08/14/2015 05:39 PM, Martin Basti wrote: >> >> >> On 08/14/2015 11:04 AM, Lenka Doudova wrote: >>>> NACK >>>> >>>> syntax error, missing ')' >>>> -from ipatests.util import assert_equal, assert_not_equal, raises >>>> +from ipatests.util import ( >>>> + assert_equal, assert_not_equal, raises, assert_deepequal >>>> >>>> I cannot apply this patch, please check it >>> >>> Sorry for the error, corrected patch attached. >>> I also added two testcases that Thierry proposed, and changed names >>> of few methods (original ones were confusing). >>> >>> Lenka >> I got this error >> >> ==================================================================================================== >> FAILURES >> ===================================================================================================== >> ____________________________________________________________________________________ >> TestPreserved.test_staged_from_preserved >> _____________________________________________________________________________________ >> >> self = > object at 0x7ffb94811350>, user = >> > 0x7ffb949e7190> >> stageduser = >> > at 0x7ffb94811c50> >> >> def test_staged_from_preserved(self, user, stageduser): >> user.make_preserved_user() >> >> stageduser.ensure_missing() >> stageduser = StageUserTracker(user.uid, user.givenname, user.sn) >> stageduser.create_from_preserved(user) >> > command = user.make_create_command(from_delete=True) >> E TypeError: make_create_command() got an unexpected keyword >> argument 'from_delete' >> >> test_xmlrpc/test_stageuser_plugin.py:718: TypeError >> ---------------------------------------------------------------------------------------------- >> Captured stdout setup >> ---------------------------------------------------------------------------------------------- >> Ran command: ipalib.plugins.stageuser.stageuser_del()(u'suser1', >> version=u'2.148'): NotFound: suser1: stage user not found >> ---------------------------------------------------------------------------------------------- >> Captured stdout call >> ----------------------------------------------------------------------------------------------- >> Ran command: ipalib.plugins.user.user_add()(u'auser1', >> givenname=u'active', sn=u'user', version=u'2.148'): OK >> Ran command: ipalib.plugins.user.user_del()(u'auser1', preserve=True, >> no_preserve=False, version=u'2.148'): OK >> >> Martin^2 > ACK I cannot apply your patch on top of ipa-4-2 branch, can you send rebased version for ipa-4-2 branch? From mbasti at redhat.com Thu Aug 20 14:56:49 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 16:56:49 +0200 Subject: [Freeipa-devel] [patch 0011] Temporary workaround for [patch 0010] Python list comprehension leak breaking the test execution In-Reply-To: <55D192EE.8060409@redhat.com> References: <55C8C68A.1010606@redhat.com> <55C8C929.5050806@redhat.com> <55C8CB13.7080201@redhat.com> <55C8CFC4.5080004@redhat.com> <55C99DAB.2020500@redhat.com> <55C99F7F.9060001@redhat.com> <55C9A83A.9070901@redhat.com> <55C9A9EA.8010907@redhat.com> <55C9F740.7060008@redhat.com> <55D192EE.8060409@redhat.com> Message-ID: <55D5EAB1.2020000@redhat.com> On 08/17/2015 09:53 AM, Milan Kub?k wrote: > On 08/11/2015 03:23 PM, Milan Kub?k wrote: >> On 08/11/2015 09:53 AM, Jan Cholasta wrote: >>> On 11.8.2015 09:46, Milan Kub?k wrote: >>>> On 08/11/2015 09:08 AM, Jan Cholasta wrote: >>>>> On 11.8.2015 09:00, Milan Kub?k wrote: >>>>> >>>>>> On 08/10/2015 06:22 PM, Milan Kub?k wrote: >>>>>> >>>>>>> On 08/10/2015 06:02 PM, Milan Kub?k wrote: >>>>>>> >>>>>>>> On 08/10/2015 05:54 PM, Jan Cholasta wrote: >>>>>>>> >>>>>>>>> On 10.8.2015 17:43, Milan Kub?k wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> this patch fixes problem described in the ticket [1] >>>>>>>>>> >>>>>>>>>> that caused the test run to fail completely at every other or so >>>>>>>>>> run. >>>>>>>>>> >>>>>>>>>> I took the liberty to fix most of the pep8 issues while I was >>>>>>>>>> at it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks to Jan Cholasta for help with identifying this one. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> IMO this would be more robust: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> t = None >>>>>>>>> >>>>>>>>> try: >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> finally: >>>>>>>>> >>>>>>>>> del t >>>>>>>>> >>>>>>>>> nss.nss_shutdown() >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> By assigning a value to the variable at the beginning you make >>>>>>>>> sure >>>>>>>>> >>>>>>>>> that the del statement will not fail. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks for the idea. It also removed the version check. >>>>>>>> >>>>>>>> Updated patch attached. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Milan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Self NACK. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have updated the fix for all of the leaks in that class. It >>>>>>> seems to >>>>>>> >>>>>>> corrupt the database even when no init/shutdown was called. Just >>>>>>> not >>>>>>> >>>>>>> so often. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Milan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> NACK again. The problem is the reference counting. Even with this >>>>>> patch, >>>>>> >>>>>> there seems to be at least one reference left after 't' is >>>>>> deleted and >>>>>> >>>>>> nss.nss_shutdown races with the garbage collector. >>>>>> >>>>> >>>>> >>>>> Doesn't the PKCDDocument object also reference some NSS objects? It >>>>> might be worth trying to delete it manually before nss_shutdown as >>>>> well. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Yes, this patch doesn't work. There are still some references left. >>>> >>>> The problem may be on multiple places in here [1]. >>>> >>>> There may be a reference still bound to the doc label. >>>> Another problem is that python 2 code: >>>> >>>> [x for x in [123, 456]] >>>> >>>> creates 2 references to 456 as the list used in the assert lives for >>>> some time >>>> before it is garbage collected even though it is not reachable, >>>> holding a reference to the object labeled as t. >>>> >>>> I don't know how nss counts the references to its objects but I >>>> think we >>>> should ow I think >>>> delete all the objects that use/are used by nss explicitly. This means >>>> assigning the list >>>> produced by the list comprehension a name as well and the delete it >>>> when >>>> it is not needed. >>>> >>>> I'll send the patch shortly. >>>> >>>> [1]: https://paste.fedoraproject.org/253748/92783071/ >>> >>> Given an assumption that all objects referenced only by local >>> variables are deleted when a function returns, maybe this can be >>> solved with: >>> >>> def nss_initialized(func): >>> def decorated(*args, **kwargs): >>> nss.nss_init_nodb() >>> try: >>> func(*args, **kwargs) >>> finally: >>> nss.nss_shutdown() >>> return decorated >>> >>> ... >>> >>> class test_class(...): >>> @nss_initialized >>> def test_method(self): >>> ... >>> >>> (OTOH and untested) >>> >> It seems that NSS decided the assumption doesn't hold. [1] >> Plus, the decorator seems to change the execution order of the test >> cases. >> >> [1]: https://paste.fedoraproject.org/253846/39299083/ >> >> Milan >> > Hi list, > > since I wasn't successful at solving this problem, I revert to the > original plan > and propose to take the otp import test out of the execution. The > attached patch > does this. > > By no means is this a solution to the problem. Therefore, I think the > ticket should remain open. > The priority of blocker can be dropped, though. I think 'critical' > should be used. > > Cheers, > Milan > > > ACK Pushed to: master: d8b9125895758cbc33821c176f3e5a05654dbee4 ipa-4-2: 57b07070f0b16f7e0099282d6a78f22c6af00793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From msimacek at redhat.com Thu Aug 20 15:11:08 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Thu, 20 Aug 2015 17:11:08 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55D5ACAC.7010001@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> Message-ID: <55D5EE0C.5060302@redhat.com> On 2015-08-20 12:32, Michael ?im??ek wrote: > > > On 2015-08-19 11:26, Alexander Bokovoy wrote: >> On Tue, 18 Aug 2015, Michael ?im??ek wrote: >>> On 2015-08-17 21:10, Robbie Harwood wrote: >>>> Michael ?im??ek writes: >>>> >>>>> Attaching new revision of the patch. Changes from the previous: >>>>> - ldap2's connect now chooses the bind type same way as in ipaldap >>>>> - get_default_realm usages replaced by api.env.realm >>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>> - updated some parts of exception handling >>>> >>>> This patch doesn't seem to apply to master. Can you update it or >>>> indicate what you're patching against? Thanks! >>>> >>> >>> Attaching patch rebased on top of current master. >> My refactoring of com.redhat.idm.trust-fetch-domains went in yesterday >> so this patch will not apply anymore. Could you please rebase it? >> >> > > Rebased on top of current master. > > Michael > > One of the commits reintroduced krbV dependency that I didn't notice. Attaching updated revision. Only changes against previous revision are in files daemons/dnssec/ipa-dnskeysync-replica and daemons/dnssec/ipa-ods-exporter. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-6-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 71334 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 20 15:21:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 20 Aug 2015 17:21:42 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D59D9B.3060409@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> <55D43F9E.7080402@redhat.com> <55D442B2.3070404@redhat.com> <55D444E2.9080806@redhat.com> <55D59D9B.3060409@redhat.com> Message-ID: <55D5F086.7090202@redhat.com> On 08/20/2015 11:27 AM, Jan Cholasta wrote: > On 19.8.2015 10:57, Jan Cholasta wrote: >> On 19.8.2015 10:47, thierry bordaz wrote: >>> On 08/19/2015 10:34 AM, Jan Cholasta wrote: >>>> On 19.8.2015 09:39, thierry bordaz wrote: >>>>> Hi, >>>>> >>>>> It worked like a charm. >>>>> I had a problem to commit it because of the VERSION stuff that >>>>> changed. >>>>> >>>>> Except that (changing VERSION), the fix looks good to me >>>>> >>>>> thanks >>>>> thierry >>>>> On 08/18/2015 07:21 PM, Martin Basti wrote: >>>>>> Thank you for the patch, I checked it, I just changed permission >>>>>> name >>>>>> to have all first letters in uppercase as others. >>>>>> Updated merged patch attached. >>>>>> >>>>>> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>>>>>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>>>>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thierry can you check If I don't break everything, it >>>>>>>>>>>>>>>>> works >>>>>>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting >>>>>>>>>>>>>>>>> NACK :D >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented >>>>>>>>>>>>>>>>> internally >>>>>>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> git apply -v >>>>>>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>>>>>> error: while searching for: >>>>>>>>>>>>>>>> # # >>>>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>>>>>> # Last change: ftweedal - add --out option to >>>>>>>>>>>>>>>> user-show >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is many pending patches that may change VERSION >>>>>>>>>>>>>>> number, >>>>>>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does code looks good for you? >>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>>>>>>> test being 'admin' ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks >>>>>>>>>>>>>> theirry >>>>>>>>>>>>> No I didn't,. >>>>>>>>>>>>> >>>>>>>>>>>>> I preserver all permission, the original permissions should >>>>>>>>>>>>> work. >>>>>>>>>>>>> >>>>>>>>>>>>> Martin >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> Running a test script, I have an issue with >>>>>>>>>>>> >>>>>>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid 10486] >>>>>>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object has no >>>>>>>>>>>> attribute 'setdefault' >>>>>>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> File >>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>>>>>> line 347, in wsgi_execute >>>>>>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> File >>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>> line 443, in __call__ >>>>>>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> File >>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>> line 760, in run >>>>>>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> File >>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>>>>>> line 1227, in execute >>>>>>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>>>>>> 10485] *keys, **options) >>>>>>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> File >>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>> >>>>>>>>>>>> line 373, in pre_callback >>>>>>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> File >>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>> >>>>>>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid 10485] >>>>>>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>>>>>> set_default function. It is not clear why. entry_attrs is >>>>>>>>>>>> one of >>>>>>>>>>>> pre_callback parameter. >>>>>>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>>>>>> pre_callback ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> thanks >>>>>>>>>>>> thierry >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> >>>>>>>>>>> updated patch attached. >>>>>>>>>> >>>>>>>>>> So far, tests are ok. >>>>>>>>>> Just one comment, the 'user-stage' command description is wrong, >>>>>>>>>> as it moves an active user into the staged area >>>>>>>>>> >>>>>>>>>> user-stage Move deleted user into >>>>>>>>>> staged area >>>>>>>>> No, it's not doing that. >>>>>>>>> >>>>>>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>>>>>> doesn't work for active users. >>>>>>>>> The support to move active user to staged area is RFE, I did not >>>>>>>>> implemented it yet, and I dont know if this will fit IPA 4.2 >>>>>>>>> timeframe >>>>>>>> Ok. thanks. >>>>>>>> Sure user-stage (active->stage) will not fit into IPA 4.2 >>>>>>>> timeframe. >>>>>>>> >>>>>>>> Running the tests being admin, there is no problem. >>>>>>>> I have a permission issue, when running as 'Stage administrator'. >>>>>>>> The 'delete' entry being moved to 'stage' container, we need the a >>>>>>>> special permission for it. >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I tested this new permission to grant 'Stage user >>>>>>> administrator' to >>>>>>> do a 'user-stage'. >>>>>>> Is it ok to add it to your patch ? >>>>>>> >>>>>>> thanks >>>>>>> thierry >>>>>>>> >>>>>>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>>>>>> --------------------- >>>>>>>> Deleted user "ttest1" >>>>>>>> --------------------- >>>>>>>> >>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' privilege to >>>>>>>> move an entry to 'cn=staged >>>>>>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [root at vm-141 ~]# klist >>>>>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>>>>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>> >>>>>>>> Valid starting Expires Service principal >>>>>>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>>>>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>>>>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>> >>>>>>>> >>>>>>>> [root at vm-141 ~]# kinit admin >>>>>>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>> ---------------------------- >>>>>>>> Staged user account "ttest1" >>>>>>>> ---------------------------- >>>>>>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>>>>>> -------------- >>>>>>>> 1 user matched >>>>>>>> -------------- >>>>>>>> User login: ttest1 >>>>>>>> First name: t >>>>>>>> Last name: test1 >>>>>>>> Home directory: /home/ttest1 >>>>>>>> Login shell: /bin/sh >>>>>>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>>>>>> UID: 1814000011 >>>>>>>> GID: 1814000011 >>>>>>>> Password: False >>>>>>>> Kerberos keys available: False >>>>>>>> ---------------------------- >>>>>>>> Number of entries returned 1 >>>>>>>> ---------------------------- >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> NACK. >>>> >>>> 1) Use ADD+DEL instead of MODRDN as we agreed before: >>>> . >>>> >>>> >>>> >>> >>> Hi, >>> >>> I have a slight preference doing MODRDN than ADD+DEL but I think it is >>> for corner case. >>> Before preserving a user, the user was active and could be updated. If >>> the user gets updated on a replica (e.g. change its phonenumer) but for >>> some reason the update is not immediately replicated, then a later >>> 'user-del --preserve' + 'user-stage' will stage the user without the >>> updated phonenumber. >>> >>> In addition, doing 2 ops rather than one costs more and is not atomic >>> (more complex to handle failure). >> >> The same problem exists for stageuser_activate, and unless you want to >> change it to use MODRDN as well, user_stage must use ADD+DEL. >> >> This was already discussed quite thoroughly and we reached the decision >> to use ADD+DEL, because it is consistent with the rest of the user code. >> I don't see a point in discussing this further and rehashing what was >> already said. >> >>> >>> thank >>> thierry >>>> >>>> 2) You can't use the entry preparation code from stageuser-add in >>>> user-stage - it is supposed to normalize user input, not already >>>> normalized data from LDAP, and could lead to subtle and hard to track >>>> errors. >>>> >>>> Honza >>>> >>> >> > > I have updated Martin's patch with fixes for the above. See attachment. > > > LGTM, what do you think thierry? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu Aug 20 16:00:41 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Aug 2015 18:00:41 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D5F086.7090202@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> <55D43F9E.7080402@redhat.com> <55D442B2.3070404@redhat.com> <55D444E2.9080806@redhat.com> <55D59D9B.3060409@redhat.com> <55D5F086.7090202@redhat.com> Message-ID: <55D5F9A9.9010606@redhat.com> On 08/20/2015 05:21 PM, Martin Basti wrote: > > > On 08/20/2015 11:27 AM, Jan Cholasta wrote: >> On 19.8.2015 10:57, Jan Cholasta wrote: >>> On 19.8.2015 10:47, thierry bordaz wrote: >>>> On 08/19/2015 10:34 AM, Jan Cholasta wrote: >>>>> On 19.8.2015 09:39, thierry bordaz wrote: >>>>>> Hi, >>>>>> >>>>>> It worked like a charm. >>>>>> I had a problem to commit it because of the VERSION stuff that >>>>>> changed. >>>>>> >>>>>> Except that (changing VERSION), the fix looks good to me >>>>>> >>>>>> thanks >>>>>> thierry >>>>>> On 08/18/2015 07:21 PM, Martin Basti wrote: >>>>>>> Thank you for the patch, I checked it, I just changed permission >>>>>>> name >>>>>>> to have all first letters in uppercase as others. >>>>>>> Updated merged patch attached. >>>>>>> >>>>>>> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>>>>>>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>>>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thierry can you check If I don't break everything, it >>>>>>>>>>>>>>>>>> works >>>>>>>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting >>>>>>>>>>>>>>>>>> NACK :D >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented >>>>>>>>>>>>>>>>>> internally >>>>>>>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> git apply -v >>>>>>>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>>>>>>> error: while searching for: >>>>>>>>>>>>>>>>> # # >>>>>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>>>>>>> # Last change: ftweedal - add --out option to >>>>>>>>>>>>>>>>> user-show >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is many pending patches that may change VERSION >>>>>>>>>>>>>>>> number, >>>>>>>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Does code looks good for you? >>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>>>>>>>> test being 'admin' ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks >>>>>>>>>>>>>>> theirry >>>>>>>>>>>>>> No I didn't,. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I preserver all permission, the original permissions should >>>>>>>>>>>>>> work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Martin >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> Running a test script, I have an issue with >>>>>>>>>>>>> >>>>>>>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10486] >>>>>>>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object >>>>>>>>>>>>> has no >>>>>>>>>>>>> attribute 'setdefault' >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>>>>>>> line 347, in wsgi_execute >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>>> line 443, in __call__ >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>>> line 760, in run >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>>>>>>> >>>>>>>>>>>>> line 1227, in execute >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] *keys, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>>> >>>>>>>>>>>>> line 373, in pre_callback >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>>> >>>>>>>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>>>>>>> set_default function. It is not clear why. entry_attrs is >>>>>>>>>>>>> one of >>>>>>>>>>>>> pre_callback parameter. >>>>>>>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>>>>>>> pre_callback ? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> thanks >>>>>>>>>>>>> thierry >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> >>>>>>>>>>>> updated patch attached. >>>>>>>>>>> >>>>>>>>>>> So far, tests are ok. >>>>>>>>>>> Just one comment, the 'user-stage' command description is >>>>>>>>>>> wrong, >>>>>>>>>>> as it moves an active user into the staged area >>>>>>>>>>> >>>>>>>>>>> user-stage Move deleted user into >>>>>>>>>>> staged area >>>>>>>>>> No, it's not doing that. >>>>>>>>>> >>>>>>>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>>>>>>> doesn't work for active users. >>>>>>>>>> The support to move active user to staged area is RFE, I did not >>>>>>>>>> implemented it yet, and I dont know if this will fit IPA 4.2 >>>>>>>>>> timeframe >>>>>>>>> Ok. thanks. >>>>>>>>> Sure user-stage (active->stage) will not fit into IPA 4.2 >>>>>>>>> timeframe. >>>>>>>>> >>>>>>>>> Running the tests being admin, there is no problem. >>>>>>>>> I have a permission issue, when running as 'Stage administrator'. >>>>>>>>> The 'delete' entry being moved to 'stage' container, we need >>>>>>>>> the a >>>>>>>>> special permission for it. >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I tested this new permission to grant 'Stage user >>>>>>>> administrator' to >>>>>>>> do a 'user-stage'. >>>>>>>> Is it ok to add it to your patch ? >>>>>>>> >>>>>>>> thanks >>>>>>>> thierry >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>>>>>>> --------------------- >>>>>>>>> Deleted user "ttest1" >>>>>>>>> --------------------- >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' >>>>>>>>> privilege to >>>>>>>>> move an entry to 'cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# klist >>>>>>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>>>>>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>> >>>>>>>>> Valid starting Expires Service principal >>>>>>>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>>>>>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>>>>>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>> >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# kinit admin >>>>>>>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>>> ---------------------------- >>>>>>>>> Staged user account "ttest1" >>>>>>>>> ---------------------------- >>>>>>>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>>>>>>> -------------- >>>>>>>>> 1 user matched >>>>>>>>> -------------- >>>>>>>>> User login: ttest1 >>>>>>>>> First name: t >>>>>>>>> Last name: test1 >>>>>>>>> Home directory: /home/ttest1 >>>>>>>>> Login shell: /bin/sh >>>>>>>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>>>>>>> UID: 1814000011 >>>>>>>>> GID: 1814000011 >>>>>>>>> Password: False >>>>>>>>> Kerberos keys available: False >>>>>>>>> ---------------------------- >>>>>>>>> Number of entries returned 1 >>>>>>>>> ---------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> NACK. >>>>> >>>>> 1) Use ADD+DEL instead of MODRDN as we agreed before: >>>>> . >>>>> >>>>> >>>>> >>>> >>>> Hi, >>>> >>>> I have a slight preference doing MODRDN than ADD+DEL but I think it is >>>> for corner case. >>>> Before preserving a user, the user was active and could be updated. If >>>> the user gets updated on a replica (e.g. change its phonenumer) but >>>> for >>>> some reason the update is not immediately replicated, then a later >>>> 'user-del --preserve' + 'user-stage' will stage the user without the >>>> updated phonenumber. >>>> >>>> In addition, doing 2 ops rather than one costs more and is not atomic >>>> (more complex to handle failure). >>> >>> The same problem exists for stageuser_activate, and unless you want to >>> change it to use MODRDN as well, user_stage must use ADD+DEL. >>> >>> This was already discussed quite thoroughly and we reached the decision >>> to use ADD+DEL, because it is consistent with the rest of the user >>> code. >>> I don't see a point in discussing this further and rehashing what was >>> already said. >>> >>>> >>>> thank >>>> thierry >>>>> >>>>> 2) You can't use the entry preparation code from stageuser-add in >>>>> user-stage - it is supposed to normalize user input, not already >>>>> normalized data from LDAP, and could lead to subtle and hard to track >>>>> errors. >>>>> >>>>> Honza >>>>> >>>> >>> >> >> I have updated Martin's patch with fixes for the above. See attachment. >> >> >> > LGTM, > > what do you think thierry? > > > I have to go outside for 45min, I will test it when I will be back.. sorry for the delay -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu Aug 20 17:17:46 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 20 Aug 2015 19:17:46 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D5F086.7090202@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> <55D43F9E.7080402@redhat.com> <55D442B2.3070404@redhat.com> <55D444E2.9080806@redhat.com> <55D59D9B.3060409@redhat.com> <55D5F086.7090202@redhat.com> Message-ID: <55D60BBA.2050304@redhat.com> On 08/20/2015 05:21 PM, Martin Basti wrote: > > > On 08/20/2015 11:27 AM, Jan Cholasta wrote: >> On 19.8.2015 10:57, Jan Cholasta wrote: >>> On 19.8.2015 10:47, thierry bordaz wrote: >>>> On 08/19/2015 10:34 AM, Jan Cholasta wrote: >>>>> On 19.8.2015 09:39, thierry bordaz wrote: >>>>>> Hi, >>>>>> >>>>>> It worked like a charm. >>>>>> I had a problem to commit it because of the VERSION stuff that >>>>>> changed. >>>>>> >>>>>> Except that (changing VERSION), the fix looks good to me >>>>>> >>>>>> thanks >>>>>> thierry >>>>>> On 08/18/2015 07:21 PM, Martin Basti wrote: >>>>>>> Thank you for the patch, I checked it, I just changed permission >>>>>>> name >>>>>>> to have all first letters in uppercase as others. >>>>>>> Updated merged patch attached. >>>>>>> >>>>>>> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>>>>>>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>>>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thierry can you check If I don't break everything, it >>>>>>>>>>>>>>>>>> works >>>>>>>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm not >>>>>>>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting >>>>>>>>>>>>>>>>>> NACK :D >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented >>>>>>>>>>>>>>>>>> internally >>>>>>>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is a small failure with VERSION (edewata pushed his >>>>>>>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> git apply -v >>>>>>>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>>>>>>> error: while searching for: >>>>>>>>>>>>>>>>> # # >>>>>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>>>>>>> # Last change: ftweedal - add --out option to >>>>>>>>>>>>>>>>> user-show >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is many pending patches that may change VERSION >>>>>>>>>>>>>>>> number, >>>>>>>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Does code looks good for you? >>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just a question, there is no additional permission. Did you >>>>>>>>>>>>>>> test being 'admin' ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks >>>>>>>>>>>>>>> theirry >>>>>>>>>>>>>> No I didn't,. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I preserver all permission, the original permissions should >>>>>>>>>>>>>> work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Martin >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> Running a test script, I have an issue with >>>>>>>>>>>>> >>>>>>>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10486] >>>>>>>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object >>>>>>>>>>>>> has no >>>>>>>>>>>>> attribute 'setdefault' >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>>>>>>> line 347, in wsgi_execute >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>>> line 443, in __call__ >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>>> line 760, in run >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>>>>>>> >>>>>>>>>>>>> line 1227, in execute >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] *keys, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>>> >>>>>>>>>>>>> line 373, in pre_callback >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> File >>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>>> >>>>>>>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> AttributeError: 'DN' object has no attribute 'setdefault' >>>>>>>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid >>>>>>>>>>>>> 10485] >>>>>>>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't b', >>>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>>>>>>> set_default function. It is not clear why. entry_attrs is >>>>>>>>>>>>> one of >>>>>>>>>>>>> pre_callback parameter. >>>>>>>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>>>>>>> pre_callback ? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> thanks >>>>>>>>>>>>> thierry >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> >>>>>>>>>>>> updated patch attached. >>>>>>>>>>> >>>>>>>>>>> So far, tests are ok. >>>>>>>>>>> Just one comment, the 'user-stage' command description is >>>>>>>>>>> wrong, >>>>>>>>>>> as it moves an active user into the staged area >>>>>>>>>>> >>>>>>>>>>> user-stage Move deleted user into >>>>>>>>>>> staged area >>>>>>>>>> No, it's not doing that. >>>>>>>>>> >>>>>>>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>>>>>>> doesn't work for active users. >>>>>>>>>> The support to move active user to staged area is RFE, I did not >>>>>>>>>> implemented it yet, and I dont know if this will fit IPA 4.2 >>>>>>>>>> timeframe >>>>>>>>> Ok. thanks. >>>>>>>>> Sure user-stage (active->stage) will not fit into IPA 4.2 >>>>>>>>> timeframe. >>>>>>>>> >>>>>>>>> Running the tests being admin, there is no problem. >>>>>>>>> I have a permission issue, when running as 'Stage administrator'. >>>>>>>>> The 'delete' entry being moved to 'stage' container, we need >>>>>>>>> the a >>>>>>>>> special permission for it. >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I tested this new permission to grant 'Stage user >>>>>>>> administrator' to >>>>>>>> do a 'user-stage'. >>>>>>>> Is it ok to add it to your patch ? >>>>>>>> >>>>>>>> thanks >>>>>>>> thierry >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>>>>>>> --------------------- >>>>>>>>> Deleted user "ttest1" >>>>>>>>> --------------------- >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' >>>>>>>>> privilege to >>>>>>>>> move an entry to 'cn=staged >>>>>>>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# klist >>>>>>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>>>>>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>> >>>>>>>>> Valid starting Expires Service principal >>>>>>>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>>>>>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>>>>>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>> >>>>>>>>> >>>>>>>>> [root at vm-141 ~]# kinit admin >>>>>>>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>>> ---------------------------- >>>>>>>>> Staged user account "ttest1" >>>>>>>>> ---------------------------- >>>>>>>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>>>>>>> -------------- >>>>>>>>> 1 user matched >>>>>>>>> -------------- >>>>>>>>> User login: ttest1 >>>>>>>>> First name: t >>>>>>>>> Last name: test1 >>>>>>>>> Home directory: /home/ttest1 >>>>>>>>> Login shell: /bin/sh >>>>>>>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>>>>>>> UID: 1814000011 >>>>>>>>> GID: 1814000011 >>>>>>>>> Password: False >>>>>>>>> Kerberos keys available: False >>>>>>>>> ---------------------------- >>>>>>>>> Number of entries returned 1 >>>>>>>>> ---------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> NACK. >>>>> >>>>> 1) Use ADD+DEL instead of MODRDN as we agreed before: >>>>> . >>>>> >>>>> >>>>> >>>> >>>> Hi, >>>> >>>> I have a slight preference doing MODRDN than ADD+DEL but I think it is >>>> for corner case. >>>> Before preserving a user, the user was active and could be updated. If >>>> the user gets updated on a replica (e.g. change its phonenumer) but >>>> for >>>> some reason the update is not immediately replicated, then a later >>>> 'user-del --preserve' + 'user-stage' will stage the user without the >>>> updated phonenumber. >>>> >>>> In addition, doing 2 ops rather than one costs more and is not atomic >>>> (more complex to handle failure). >>> >>> The same problem exists for stageuser_activate, and unless you want to >>> change it to use MODRDN as well, user_stage must use ADD+DEL. >>> >>> This was already discussed quite thoroughly and we reached the decision >>> to use ADD+DEL, because it is consistent with the rest of the user >>> code. >>> I don't see a point in discussing this further and rehashing what was >>> already said. >>> >>>> >>>> thank >>>> thierry >>>>> >>>>> 2) You can't use the entry preparation code from stageuser-add in >>>>> user-stage - it is supposed to normalize user input, not already >>>>> normalized data from LDAP, and could lead to subtle and hard to track >>>>> errors. >>>>> >>>>> Honza >>>>> >>>> >>> >> >> I have updated Martin's patch with fixes for the above. See attachment. >> >> >> > LGTM, > > what do you think thierry? > > > Hi, It works like a charm and regarding the fix looks great as well. ACK thanks theirry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rharwood at redhat.com Thu Aug 20 18:42:29 2015 From: rharwood at redhat.com (Robbie Harwood) Date: Thu, 20 Aug 2015 14:42:29 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55D5EE0C.5060302@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> Message-ID: Michael ?im??ek writes: > On 2015-08-20 12:32, Michael ?im??ek wrote: > >>>>> Michael ?im??ek writes: >>>>> >>>>>> Attaching new revision of the patch. Changes from the previous: >>>>>> - ldap2's connect now chooses the bind type same way as in ipaldap >>>>>> - get_default_realm usages replaced by api.env.realm >>>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>>> - updated some parts of exception handling >> >> Rebased on top of current master. > > One of the commits reintroduced krbV dependency that I didn't notice. > Attaching updated revision. Only changes against previous revision are > in files daemons/dnssec/ipa-dnskeysync-replica and > daemons/dnssec/ipa-ods-exporter. This is much better, thanks! I've got some comments inline. > +except gssapi.exceptions.GSSError: > # If there was failure on using keytab, assume it is stale and retrieve again > retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal) This code still bothers me a bit, but I think fixing it is probably beyond the scope of a python-gssapi port. > + try: > + creds = get_credentials(name=name, ccache_name=ccache_name) > + # property access would raise exception if expired > + if creds.lifetime > 0: > + return creds > + except gssapi.exceptions.ExpiredCredentialsError: > + return None Per rfc2744, lifetime is unsigned. It's not immediately clear what will happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in that case? > # Setup LDAP connection > try: > - ctx = krbV.default_context() > - ccache = ctx.default_ccache() > - api.Backend.ldap2.connect(ccache) > + api.Backend.ldap2.connect() > cls.ldap = api.Backend.ldap2 > - except krbV.Krb5Error as e: > + except gssapi.exceptions.GSSError: > sys.exit("Must have Kerberos credentials to migrate Winsync users.") Can you log the error here? The other places GSSError is being caught are doing a great job of either filtering-and-raising or logging-and-exiting, so thanks for fixing those. > +# Ugly hack for test purposes only. GSSAPI has no way to get default ccache > +# name, but we don't need it outside test server > +def get_default_ccache_name(): > + try: > + out = check_output(['klist']) > + except CalledProcessError: > + raise RuntimeError("Default ccache not found. Did you kinit?") > + match = re.match(r'^Ticket cache:\s*(\S+)', out) > + if not match: > + raise RuntimeError("Cannot obtain ccache name") > + return match.group(1) Yup, this is still ugly. Ah well, it's only test code. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From simo at redhat.com Thu Aug 20 20:41:30 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Aug 2015 16:41:30 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> Message-ID: <1440103290.24710.17.camel@willson.usersys.redhat.com> On Thu, 2015-08-20 at 14:42 -0400, Robbie Harwood wrote: > Michael ?im??ek writes: > > > On 2015-08-20 12:32, Michael ?im??ek wrote: > > > >>>>> Michael ?im??ek writes: > >>>>> > >>>>>> Attaching new revision of the patch. Changes from the previous: > >>>>>> - ldap2's connect now chooses the bind type same way as in ipaldap > >>>>>> - get_default_realm usages replaced by api.env.realm > >>>>>> - fixed missing third kinit attempt in trust-fetch-domains > >>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils > >>>>>> - updated some parts of exception handling > >> > >> Rebased on top of current master. > > > > One of the commits reintroduced krbV dependency that I didn't notice. > > Attaching updated revision. Only changes against previous revision are > > in files daemons/dnssec/ipa-dnskeysync-replica and > > daemons/dnssec/ipa-ods-exporter. > > This is much better, thanks! I've got some comments inline. > > > +except gssapi.exceptions.GSSError: > > # If there was failure on using keytab, assume it is stale and retrieve again > > retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal) > > This code still bothers me a bit, but I think fixing it is probably > beyond the scope of a python-gssapi port. > > > + try: > > + creds = get_credentials(name=name, ccache_name=ccache_name) > > + # property access would raise exception if expired > > + if creds.lifetime > 0: > > + return creds > > + except gssapi.exceptions.ExpiredCredentialsError: > > + return None > > Per rfc2744, lifetime is unsigned. It's not immediately clear what will > happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in > that case? Lifetime == 0 means the credentials are expired, it should never be returned but if it were we'd have to raise ourself gssapi.exceptions.ExpiredCredentialsError > > # Setup LDAP connection > > try: > > - ctx = krbV.default_context() > > - ccache = ctx.default_ccache() > > - api.Backend.ldap2.connect(ccache) > > + api.Backend.ldap2.connect() > > cls.ldap = api.Backend.ldap2 > > - except krbV.Krb5Error as e: > > + except gssapi.exceptions.GSSError: > > sys.exit("Must have Kerberos credentials to migrate Winsync users.") > > Can you log the error here? The other places GSSError is being caught > are doing a great job of either filtering-and-raising or > logging-and-exiting, so thanks for fixing those. > > > +# Ugly hack for test purposes only. GSSAPI has no way to get default ccache > > +# name, but we don't need it outside test server > > +def get_default_ccache_name(): > > + try: > > + out = check_output(['klist']) > > + except CalledProcessError: > > + raise RuntimeError("Default ccache not found. Did you kinit?") > > + match = re.match(r'^Ticket cache:\s*(\S+)', out) > > + if not match: > > + raise RuntimeError("Cannot obtain ccache name") > > + return match.group(1) > > Yup, this is still ugly. Ah well, it's only test code. Well turns out there is a gssapi_krb5 extension to get a ccache name: gss_krb5_ccache_name() Robbie, do you think we should expose it in python-gssapi if available ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rharwood at redhat.com Thu Aug 20 21:42:55 2015 From: rharwood at redhat.com (Robbie Harwood) Date: Thu, 20 Aug 2015 17:42:55 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <1440103290.24710.17.camel@willson.usersys.redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <1440103290.24710.17.camel@willson.usersys.redhat.com> Message-ID: Simo Sorce writes: > On Thu, 2015-08-20 at 14:42 -0400, Robbie Harwood wrote: >> Michael ?im??ek writes: >> >>> On 2015-08-20 12:32, Michael ?im??ek wrote: >>> >>>>>>> Michael ?im??ek writes: >>>>>>> >>>>>>>> Attaching new revision of the patch. Changes from the previous: >>>>>>>> - ldap2's connect now chooses the bind type same way as in ipaldap >>>>>>>> - get_default_realm usages replaced by api.env.realm >>>>>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>>>>> - updated some parts of exception handling >>>> >>>> Rebased on top of current master. >>> >>> One of the commits reintroduced krbV dependency that I didn't notice. >>> Attaching updated revision. Only changes against previous revision are >>> in files daemons/dnssec/ipa-dnskeysync-replica and >>> daemons/dnssec/ipa-ods-exporter. >> >> This is much better, thanks! I've got some comments inline. >> >>> +# Ugly hack for test purposes only. GSSAPI has no way to get default ccache >>> +# name, but we don't need it outside test server >>> +def get_default_ccache_name(): >>> + try: >>> + out = check_output(['klist']) >>> + except CalledProcessError: >>> + raise RuntimeError("Default ccache not found. Did you kinit?") >>> + match = re.match(r'^Ticket cache:\s*(\S+)', out) >>> + if not match: >>> + raise RuntimeError("Cannot obtain ccache name") >>> + return match.group(1) >> >> Yup, this is still ugly. Ah well, it's only test code. > > Well turns out there is a gssapi_krb5 extension to get a ccache name: > gss_krb5_ccache_name() > > Robbie, > do you think we should expose it in python-gssapi if available ? It doesn't seem dangerous, so I see no reason not to. It's on our giant "eventually" list[0], so we'd definitely be open to it. I do not have the cycles for this right now, though I've opened a bug for it[1]. [0]: https://github.com/pythongssapi/python-gssapi/issues/48 [1]: https://github.com/pythongssapi/python-gssapi/issues/75 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From tbabej at redhat.com Fri Aug 21 06:57:05 2015 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 21 Aug 2015 08:57:05 +0200 Subject: [Freeipa-devel] [PATCH 0003] Added PyYAML as a dependency for ipa-tests, fixed a replica preparation in RHEL In-Reply-To: <55D5A710.9010903@redhat.com> References: <55D5A253.2070507@redhat.com> <55D5A710.9010903@redhat.com> Message-ID: <55D6CBC1.9070205@redhat.com> On 08/20/2015 12:08 PM, Martin Babinsky wrote: > On 08/20/2015 11:48 AM, Oleg Fayans wrote: >> Fixed two failures of integration tests under RHEL: >> 1. PyYAML, needed for integration tests is not installed as a dependency >> 2. ipa-replica-prepare requests a reverse zone info under RHEL. >> >> >> >> > > Hi Oleg, > > it is a good practice to fix unrelated issues in separate patches, not a > single one. > > Also, I am not sure PyYAML should be marked as required dependency. > According to http://www.freeipa.org/page/Integration_testing_configuration > the YAML/JSON configuration of tests is optional besides using > environment variables. > > I might be better to handle the ImportError when IPATEST_YAML_CONFIG is > set without PyYAML installed (see > `ipatests/test_integration/env_config.py` line 110) and print some error > message instructing the user to install the package. > This is correct, YAML is not a required dependency, environment variables can be used as a substitute. Tomas From tbordaz at redhat.com Fri Aug 21 08:37:01 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 21 Aug 2015 10:37:01 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D5C125.4030002@redhat.com> References: <55D47C85.6050008@redhat.com> <55D4AEA1.9040507@redhat.com> <55D5A0B9.8020908@redhat.com> <55D5A7D0.3040601@redhat.com> <55D5C125.4030002@redhat.com> Message-ID: <55D6E32D.4030204@redhat.com> On 08/20/2015 01:59 PM, Martin Babinsky wrote: > On 08/20/2015 12:11 PM, Martin Babinsky wrote: >> On 08/20/2015 11:41 AM, thierry bordaz wrote: >>> On 08/19/2015 06:28 PM, Martin Babinsky wrote: >>>> On 08/19/2015 02:54 PM, Martin Babinsky wrote: >>>>> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 from >>>>> happening. >>>>> >>>>> >>>>> >>>> Actually, we (myself, mbasti, jcholast) found out that `user-del >>>> --preserve` could use some more usability improvements. >>>> >>>> This quick patch should fix both >>>> https://fedorahosted.org/freeipa/ticket/5234 and >>>> https://fedorahosted.org/freeipa/ticket/5236 and make user >>>> preservation operate on multiple arguments in a same way as plain >>>> deletion. >>>> >>>> >>>> >>> >>> Hi Martin, >>> >>> The tests are ok and the fix looks good to me. >>> >>> ACK >>> >>> thanks >>> thierry >> >> That's nice, but I have found some small nitpicks and will send an >> updated version. >> >> So self-NACK. >> > Attaching updated patch. > This is working fine. ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Fri Aug 21 08:45:28 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 21 Aug 2015 10:45:28 +0200 Subject: [Freeipa-devel] [PATCH 0003] Added PyYAML as a dependency for ipa-tests, fixed a replica preparation in RHEL In-Reply-To: <55D6CBC1.9070205@redhat.com> References: <55D5A253.2070507@redhat.com> <55D5A710.9010903@redhat.com> <55D6CBC1.9070205@redhat.com> Message-ID: <55D6E528.70304@redhat.com> Agreed. Please, disregard this patch. On 08/21/2015 08:57 AM, Tomas Babej wrote: > > > On 08/20/2015 12:08 PM, Martin Babinsky wrote: >> On 08/20/2015 11:48 AM, Oleg Fayans wrote: >>> Fixed two failures of integration tests under RHEL: >>> 1. PyYAML, needed for integration tests is not installed as a dependency >>> 2. ipa-replica-prepare requests a reverse zone info under RHEL. >>> >>> >>> >>> >> >> Hi Oleg, >> >> it is a good practice to fix unrelated issues in separate patches, not a >> single one. >> >> Also, I am not sure PyYAML should be marked as required dependency. >> According to http://www.freeipa.org/page/Integration_testing_configuration >> the YAML/JSON configuration of tests is optional besides using >> environment variables. >> >> I might be better to handle the ImportError when IPATEST_YAML_CONFIG is >> set without PyYAML installed (see >> `ipatests/test_integration/env_config.py` line 110) and print some error >> message instructing the user to install the package. >> > > This is correct, YAML is not a required dependency, environment > variables can be used as a substitute. > > Tomas > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ofayans at redhat.com Fri Aug 21 08:52:22 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 21 Aug 2015 10:52:22 +0200 Subject: [Freeipa-devel] [PATCH] small fixes related to running dnssec tests in RHEL Message-ID: <55D6E6C6.7070807@redhat.com> Hi list, Here are the the fixes for https://fedorahosted.org/freeipa/ticket/5240 plus pep8-related fixes, plus created a user-friendly error message at import error. obsoletes my previous patch -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0003-Added-a-user-friendly-output-to-an-import-error.patch Type: text/x-patch Size: 1097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0004-Fixed-pep8-related-issues.patch Type: text/x-patch Size: 4757 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0005-Temporary-fix-for-ticket-5240.patch Type: text/x-patch Size: 1476 bytes Desc: not available URL: From slaznick at redhat.com Fri Aug 21 09:26:49 2015 From: slaznick at redhat.com (Stanislav Laznicka) Date: Fri, 21 Aug 2015 11:26:49 +0200 Subject: [Freeipa-devel] [Update] Time-Based Account Policies Message-ID: <55D6EED9.3080604@redhat.com> Hi all, I have been working on the changes regarding the time-based policies that were proposed earlier this month on this mailing list. The minor change was the addition of the 'dayofyear' and 'weekofyear' language keywords and their functionality. A rather major change was the addition of a behavior similar to the one of the iCalendar recurrence rules. The minor change is obvious, let me elaborate on the bigger one. It was implemented as I proposed earlier on this list. Language-wise, it works like this: repeat=[-]+ where takes the form of YYYYMMDD, date1 is the starting date, date2 is the ending date and is optional. The after '+' denotes the length of each repetition and is one of d/w/m/y which stands for daily/weekly/monthly/yearly. Therefore, "+1d" means every day (from the starting day), "+2w" every other week etc. The limits set by the 'repeat' keyword can be extended/limited similarly as in iCalendar using the current language, e.g. 'dayofweek' can be used to extend ranges in weekly/monthly/yearly from one certain day in week/month/year for a set of these days but it limits the days applicable in daily mode. For more information, see either http://tools.ietf.org/html/rfc5545#section-3.3.10 or, preferably, the code (sssd - 0004 patch, the check_repeat function). I should also mention that the COUNT feature from iCalendar is not implemented for reasons I stated in my last mail (https://www.redhat.com/archives/freeipa-devel/2015-August/msg00075.html). I would also like to ask someone from SSSD to have at least a brief look at the code I am posting now, especially the changes in patches 1,2 and 4. I wonder if I should make a separate post on sssd-devel for that. If you have any notes or suggestions on the current state of the time rules, please, let me know. Many thanks, Standa Laznicka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0001-Added-time-based-policies-types-to-LDAP-schema.patch Type: text/x-patch Size: 3072 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0002-Added-methods-for-setting-time-based-policies.patch Type: text/x-patch Size: 31309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0003-Created-basic-UI-for-setting-time-policies-at-HBAC-r.patch Type: text/x-patch Size: 17682 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0004-Added-the-repeat-keyword.patch Type: text/x-patch Size: 4215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd-stlaz-0001-Added-caching-of-time-policies-for-IPA-HBAC-rules.patch Type: text/x-patch Size: 11566 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd-stlaz-0002-Added-evaluation-of-time-policies-in-HBAC-objects.patch Type: text/x-patch Size: 21959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd-stlaz-0003-Added-Python-bindings-for-FreeIPA-time-policies.patch Type: text/x-patch Size: 34653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd-stlaz-0004-IPA-Added-the-repeat-keyword-functionality.patch Type: text/x-patch Size: 25696 bytes Desc: not available URL: From mbasti at redhat.com Fri Aug 21 10:30:35 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 21 Aug 2015 12:30:35 +0200 Subject: [Freeipa-devel] [PATCH 0297] ULC: add user-stage command In-Reply-To: <55D60BBA.2050304@redhat.com> References: <55D2290F.3030509@redhat.com> <55D2E3C1.2030404@redhat.com> <55D2E4E0.6010005@redhat.com> <55D2E5C9.7030703@redhat.com> <55D2E68F.7080601@redhat.com> <55D2FBAC.2030801@redhat.com> <55D32DD3.3050501@redhat.com> <55D33804.6000201@redhat.com> <55D33B6D.7050701@redhat.com> <55D33D81.301@redhat.com> <55D35097.6010902@redhat.com> <55D36984.4010203@redhat.com> <55D432C5.1070801@redhat.com> <55D43F9E.7080402@redhat.com> <55D442B2.3070404@redhat.com> <55D444E2.9080806@redhat.com> <55D59D9B.3060409@redhat.com> <55D5F086.7090202@redhat.com> <55D60BBA.2050304@redhat.com> Message-ID: <55D6FDCB.5010401@redhat.com> On 08/20/2015 07:17 PM, thierry bordaz wrote: > On 08/20/2015 05:21 PM, Martin Basti wrote: >> >> >> On 08/20/2015 11:27 AM, Jan Cholasta wrote: >>> On 19.8.2015 10:57, Jan Cholasta wrote: >>>> On 19.8.2015 10:47, thierry bordaz wrote: >>>>> On 08/19/2015 10:34 AM, Jan Cholasta wrote: >>>>>> On 19.8.2015 09:39, thierry bordaz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> It worked like a charm. >>>>>>> I had a problem to commit it because of the VERSION stuff that >>>>>>> changed. >>>>>>> >>>>>>> Except that (changing VERSION), the fix looks good to me >>>>>>> >>>>>>> thanks >>>>>>> thierry >>>>>>> On 08/18/2015 07:21 PM, Martin Basti wrote: >>>>>>>> Thank you for the patch, I checked it, I just changed >>>>>>>> permission name >>>>>>>> to have all first letters in uppercase as others. >>>>>>>> Updated merged patch attached. >>>>>>>> >>>>>>>> On 08/18/2015 05:34 PM, thierry bordaz wrote: >>>>>>>>> On 08/18/2015 04:13 PM, thierry bordaz wrote: >>>>>>>>>> On 08/18/2015 04:04 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/18/2015 03:49 PM, thierry bordaz wrote: >>>>>>>>>>>> On 08/18/2015 03:06 PM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/18/2015 11:32 AM, thierry bordaz wrote: >>>>>>>>>>>>>> On 08/18/2015 10:02 AM, Martin Basti wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08/18/2015 09:59 AM, thierry bordaz wrote: >>>>>>>>>>>>>>>> On 08/18/2015 09:55 AM, Martin Basti wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 08/18/2015 09:50 AM, thierry bordaz wrote: >>>>>>>>>>>>>>>>>> On 08/17/2015 08:33 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> the 'user-stage' command replaces 'stageuser-add >>>>>>>>>>>>>>>>>>> --from-delete' command. >>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5041 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thierry can you check If I don't break everything, >>>>>>>>>>>>>>>>>>> it works >>>>>>>>>>>>>>>>>>> for me, but the one never knows. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Honza can you please check the framework side? I use >>>>>>>>>>>>>>>>>>> self.api.Object.stageuser.add.* in user command, I'm >>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> sure if this is right way, but it works. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Patch attached. I created it in hurry, I'm expecting >>>>>>>>>>>>>>>>>>> NACK :D >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Just question at the end: should I implement way Active >>>>>>>>>>>>>>>>>>> user -> stageuser? IMHO it would be implemented >>>>>>>>>>>>>>>>>>> internally >>>>>>>>>>>>>>>>>>> by calling 'user-del --preserve' inside 'user-stage'. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There is a small failure with VERSION (edewata pushed >>>>>>>>>>>>>>>>>> his >>>>>>>>>>>>>>>>>> patch first ;-) ) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> git apply -v >>>>>>>>>>>>>>>>>> /tmp/freeipa-mbasti-0297-Add-user-stage-command.patch >>>>>>>>>>>>>>>>>> Checking patch API.txt... >>>>>>>>>>>>>>>>>> Checking patch VERSION... >>>>>>>>>>>>>>>>>> error: while searching for: >>>>>>>>>>>>>>>>>> # # >>>>>>>>>>>>>>>>>> ######################################################## >>>>>>>>>>>>>>>>>> IPA_API_VERSION_MAJOR=2 >>>>>>>>>>>>>>>>>> IPA_API_VERSION_MINOR=148 >>>>>>>>>>>>>>>>>> # Last change: ftweedal - add --out option to >>>>>>>>>>>>>>>>>> user-show >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> error: patch failed: VERSION:90 >>>>>>>>>>>>>>>>>> error: VERSION: patch does not apply >>>>>>>>>>>>>>>>>> Checking patch ipalib/plugins/stageuser.py... >>>>>>>>>>>>>>>>>> Checking patch ipalib/plugins/user.py... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is many pending patches that may change VERSION >>>>>>>>>>>>>>>>> number, >>>>>>>>>>>>>>>>> I will change it to right one before push. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does code looks good for you? >>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Just a question, there is no additional permission. Did >>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>> test being 'admin' ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks >>>>>>>>>>>>>>>> theirry >>>>>>>>>>>>>>> No I didn't,. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I preserver all permission, the original permissions should >>>>>>>>>>>>>>> work. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Martin >>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Running a test script, I have an issue with >>>>>>>>>>>>>> >>>>>>>>>>>>>> ipa stageuser-add --first=t --last=b tb1 >>>>>>>>>>>>>> ipa: ERROR: an internal error has occurred >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [Tue Aug 18 11:16:56.440658 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10486] >>>>>>>>>>>>>> ipa: INFO: [jsonserver_kerb] >>>>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't >>>>>>>>>>>>>> b', >>>>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198021 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> ipa: ERROR: non-public: AttributeError: 'DN' object >>>>>>>>>>>>>> has no >>>>>>>>>>>>>> attribute 'setdefault' >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198053 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198058 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> File >>>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", >>>>>>>>>>>>>> line 347, in wsgi_execute >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198062 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] result = self.Command[name](*args, **options) >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198066 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> File >>>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>>>> line 443, in __call__ >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198070 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] ret = self.run(*args, **options) >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198081 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> File >>>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", >>>>>>>>>>>>>> line 760, in run >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198133 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] return self.execute(*args, **options) >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198139 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> File >>>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", >>>>>>>>>>>>>> >>>>>>>>>>>>>> line 1227, in execute >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198144 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] *keys, **options) >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198147 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> File >>>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>>>> >>>>>>>>>>>>>> line 373, in pre_callback >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198151 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] attrs_list, *keys, **options) >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198155 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> File >>>>>>>>>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/stageuser.py", >>>>>>>>>>>>>> >>>>>>>>>>>>>> line 277, in set_default_values_pre_callback >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198159 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> entry_attrs.setdefault('description', []) >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.198163 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> AttributeError: 'DN' object has no attribute >>>>>>>>>>>>>> 'setdefault' >>>>>>>>>>>>>> [Tue Aug 18 11:21:25.199276 2015] [wsgi:error] [pid >>>>>>>>>>>>>> 10485] >>>>>>>>>>>>>> ipa: INFO: [jsonserver_session] >>>>>>>>>>>>>> stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>>>>>> stageuser_add(u'tb1', givenname=u't', sn=u'b', cn=u't >>>>>>>>>>>>>> b', >>>>>>>>>>>>>> displayname=u't b', initials=u'tb', gecos=u't b', >>>>>>>>>>>>>> krbprincipalname=u'tb1 at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM', >>>>>>>>>>>>>> random=False, all=False, raw=False, version=u'2.149', >>>>>>>>>>>>>> no_members=False): AttributeError >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The new set_default_values_pre_callback, can not use the >>>>>>>>>>>>>> set_default function. It is not clear why. entry_attrs is >>>>>>>>>>>>>> one of >>>>>>>>>>>>>> pre_callback parameter. >>>>>>>>>>>>>> Should set_default_values_pre_callback be a subfonction of >>>>>>>>>>>>>> pre_callback ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks >>>>>>>>>>>>>> thierry >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> >>>>>>>>>>>>> updated patch attached. >>>>>>>>>>>> >>>>>>>>>>>> So far, tests are ok. >>>>>>>>>>>> Just one comment, the 'user-stage' command description is >>>>>>>>>>>> wrong, >>>>>>>>>>>> as it moves an active user into the staged area >>>>>>>>>>>> >>>>>>>>>>>> user-stage Move deleted user into >>>>>>>>>>>> staged area >>>>>>>>>>> No, it's not doing that. >>>>>>>>>>> >>>>>>>>>>> user-stage is replacement of stageuser-add --from-delete, it >>>>>>>>>>> doesn't work for active users. >>>>>>>>>>> The support to move active user to staged area is RFE, I did >>>>>>>>>>> not >>>>>>>>>>> implemented it yet, and I dont know if this will fit IPA 4.2 >>>>>>>>>>> timeframe >>>>>>>>>> Ok. thanks. >>>>>>>>>> Sure user-stage (active->stage) will not fit into IPA 4.2 >>>>>>>>>> timeframe. >>>>>>>>>> >>>>>>>>>> Running the tests being admin, there is no problem. >>>>>>>>>> I have a permission issue, when running as 'Stage >>>>>>>>>> administrator'. >>>>>>>>>> The 'delete' entry being moved to 'stage' container, we need >>>>>>>>>> the a >>>>>>>>>> special permission for it. >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I tested this new permission to grant 'Stage user >>>>>>>>> administrator' to >>>>>>>>> do a 'user-stage'. >>>>>>>>> Is it ok to add it to your patch ? >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> thierry >>>>>>>>>> >>>>>>>>>> [root at vm-141 ~]# ipa user-del ttest1 --preserve >>>>>>>>>> --------------------- >>>>>>>>>> Deleted user "ttest1" >>>>>>>>>> --------------------- >>>>>>>>>> >>>>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>>>> ipa: ERROR: Insufficient access: Insufficient 'moddn' >>>>>>>>>> privilege to >>>>>>>>>> move an entry to 'cn=staged >>>>>>>>>> users,cn=accounts,cn=provisioning,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [root at vm-141 ~]# klist >>>>>>>>>> Ticket cache: KEYRING:persistent:0:krb_ccache_hw3P667 >>>>>>>>>> Default principal: stageadm at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>>> >>>>>>>>>> Valid starting Expires Service principal >>>>>>>>>> 08/18/2015 15:45:43 08/19/2015 15:45:42 >>>>>>>>>> ldap/vm-141.abc.idm.lab.eng.brq.redhat.com at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 08/18/2015 15:45:42 08/19/2015 15:45:42 >>>>>>>>>> krbtgt/ABC.IDM.LAB.ENG.BRQ.REDHAT.COM at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [root at vm-141 ~]# kinit admin >>>>>>>>>> Password for admin at ABC.IDM.LAB.ENG.BRQ.REDHAT.COM: >>>>>>>>>> [root at vm-141 ~]# ipa user-stage ttest1 >>>>>>>>>> ---------------------------- >>>>>>>>>> Staged user account "ttest1" >>>>>>>>>> ---------------------------- >>>>>>>>>> [root at vm-141 ~]# ipa stageuser-find ttest1 >>>>>>>>>> -------------- >>>>>>>>>> 1 user matched >>>>>>>>>> -------------- >>>>>>>>>> User login: ttest1 >>>>>>>>>> First name: t >>>>>>>>>> Last name: test1 >>>>>>>>>> Home directory: /home/ttest1 >>>>>>>>>> Login shell: /bin/sh >>>>>>>>>> Email address: ttest1 at abc.idm.lab.eng.brq.redhat.com >>>>>>>>>> UID: 1814000011 >>>>>>>>>> GID: 1814000011 >>>>>>>>>> Password: False >>>>>>>>>> Kerberos keys available: False >>>>>>>>>> ---------------------------- >>>>>>>>>> Number of entries returned 1 >>>>>>>>>> ---------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> NACK. >>>>>> >>>>>> 1) Use ADD+DEL instead of MODRDN as we agreed before: >>>>>> . >>>>>> >>>>>> >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> I have a slight preference doing MODRDN than ADD+DEL but I think >>>>> it is >>>>> for corner case. >>>>> Before preserving a user, the user was active and could be >>>>> updated. If >>>>> the user gets updated on a replica (e.g. change its phonenumer) >>>>> but for >>>>> some reason the update is not immediately replicated, then a later >>>>> 'user-del --preserve' + 'user-stage' will stage the user without the >>>>> updated phonenumber. >>>>> >>>>> In addition, doing 2 ops rather than one costs more and is not atomic >>>>> (more complex to handle failure). >>>> >>>> The same problem exists for stageuser_activate, and unless you want to >>>> change it to use MODRDN as well, user_stage must use ADD+DEL. >>>> >>>> This was already discussed quite thoroughly and we reached the >>>> decision >>>> to use ADD+DEL, because it is consistent with the rest of the user >>>> code. >>>> I don't see a point in discussing this further and rehashing what was >>>> already said. >>>> >>>>> >>>>> thank >>>>> thierry >>>>>> >>>>>> 2) You can't use the entry preparation code from stageuser-add in >>>>>> user-stage - it is supposed to normalize user input, not already >>>>>> normalized data from LDAP, and could lead to subtle and hard to >>>>>> track >>>>>> errors. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>> >>> >>> I have updated Martin's patch with fixes for the above. See attachment. >>> >>> >>> >> LGTM, >> >> what do you think thierry? >> >> >> > Hi, > > It works like a charm and regarding the fix looks great as well. > > ACK > > thanks > theirry Thanks Pushed to: master: fb98e77104cee4fb23223a25128e75d88cfe5ba8 ipa-4-2: 6b8623848e46dec074cd2894c9fbcd0eb47d3247 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Aug 21 10:55:38 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Aug 2015 12:55:38 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55CE2914.3000709@redhat.com> References: <55CE2914.3000709@redhat.com> Message-ID: <55D703AA.7010406@redhat.com> On 08/14/2015 07:44 PM, Petr Viktorin wrote: > Hello, > These patches bring IPA another step towards compatibility with Python 3. > > Most of these were made by fixers from the "python-modernize" tool, but > I reviewed and edited the results. Here are the patches rebased to current master. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0696.2-Remove-use-of-sys.exc_value.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0697.2-Don-t-use-a-tuple-in-function-arguments.patch Type: text/x-patch Size: 910 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0698.2-Add-python-six-to-dependencies.patch Type: text/x-patch Size: 984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0699.2-Remove-the-unused-pygettext-script.patch Type: text/x-patch Size: 30062 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0700.2-Use-six.string_types-instead-of-basestring.patch Type: text/x-patch Size: 31182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0701.2-Use-Python3-compatible-dict-method-names.patch Type: text/x-patch Size: 70902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0702.2-Replace-filter-calls-with-list-comprehensions.patch Type: text/x-patch Size: 6514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0703.2-Use-six.moves.input-instead-of-raw_input.patch Type: text/x-patch Size: 3100 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0704.2-Use-six.integer_types-instead-of-long-int.patch Type: text/x-patch Size: 3499 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0705.2-Replace-uses-of-map.patch Type: text/x-patch Size: 15209 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0706.2-Use-next-function-on-iterators.patch Type: text/x-patch Size: 3481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0707.2-Use-the-print-function.patch Type: text/x-patch Size: 228671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0708.2-Use-new-style-raise-syntax.patch Type: text/x-patch Size: 6956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0709.2-Use-six.reraise.patch Type: text/x-patch Size: 867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0710.2-Modernize-use-of-range.patch Type: text/x-patch Size: 17768 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0711.2-Convert-zip-result-to-list.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: From cheimes at redhat.com Fri Aug 21 12:50:48 2015 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 21 Aug 2015 14:50:48 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55D703AA.7010406@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> Message-ID: <55D71EA8.4040002@redhat.com> On 2015-08-21 12:55, Petr Viktorin wrote: > On 08/14/2015 07:44 PM, Petr Viktorin wrote: >> Hello, >> These patches bring IPA another step towards compatibility with Python 3. >> >> Most of these were made by fixers from the "python-modernize" tool, but >> I reviewed and edited the results. > > Here are the patches rebased to current master. 0696.2-Remove-use-of-sys.exc_value ACK 0697.2-Don-t-use-a-tuple-in-function-arguments I prefer operator.itemgetter() over the hard-to-read lambda expression key=lambda k_v: (k_v[1], k_v[0]). >>> import operator >>> example = dict(a=3, ba=2, b=2, c=1) >>> sorted(example.items(), key=operator.itemgetter(1, 0)) [('c', 1), ('b', 2), ('ba', 2), ('a', 3)] 0698.2-Add-python-six-to-dependencies ACK 0699.2-Remove-the-unused-pygettext-script ACK 0700.2-Use-six.string_types-instead-of-basestring LGTM, but I need to have a closer look at some places. I noticed a couple of asserts that should be "if ... raise ValueError" instead. python -o disables asserts. 0701.2-Use-Python3-compatible-dict-method-names NACK Why are you replacing iteritems() with items() instead of using six.iteritems()? Please use sorted(reference) instead of sorted(reference.keys()), set(tree) instead of set(tree.keys()) and list(somedict) instead of list(somedict.keys()), too. The keys() call is unnecessary and frowned upon. 0702.2-Replace-filter-calls-with-list-comprehensions In Python 2 list comprehensions leak the internal loop variable. It might be better to write a generator expression with list() instead of [] list comprehension. 0703.2-Use-six.moves.input-instead-of-raw_input ACK The code is fine, but pylint won't like it. For Dogtag I had to disable pylint warnings W0622 and F0401. 0704.2-Use-six.integer_types-instead-of-long-int ACK hint: For type checks you can also use the numbers module. 0705.2-Replace-uses-of-map See comment for 0702 706.2-Use-next-function-on-iterators ACK 0707.2-Use-the-print-function LGTM There are too many chances to review. Let's hope the automatic conversion tool did its job correctly. 0708.2-Use-new-style-raise-syntax ACK 0709.2-Use-six.reraise ACK 0710.2-Modernize-use-of-range NACK Please use six.moves.range. It defaults to xrange() in Python 2. I also see a couple of additional opportunities for enumerate(): for i in range(len(kw['attrs'])): kw['attrs'][i] = unicode(kw['attrs'][i]) for i, s in enumerate(kw['attrs']): kw['attrs'][i] = unicode(s) 0711.2-Convert-zip-result-to-list ACK The code isn't beautiful but it's just a test. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From msimacek at redhat.com Fri Aug 21 13:52:21 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Fri, 21 Aug 2015 15:52:21 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> Message-ID: <55D72D15.3010901@redhat.com> On 2015-08-20 20:42, Robbie Harwood wrote: > Michael ?im??ek writes: > >> On 2015-08-20 12:32, Michael ?im??ek wrote: >> >>>>>> Michael ?im??ek writes: >>>>>> >>>>>>> Attaching new revision of the patch. Changes from the previous: >>>>>>> - ldap2's connect now chooses the bind type same way as in ipaldap >>>>>>> - get_default_realm usages replaced by api.env.realm >>>>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>>>> - updated some parts of exception handling >>> >>> Rebased on top of current master. >> >> One of the commits reintroduced krbV dependency that I didn't notice. >> Attaching updated revision. Only changes against previous revision are >> in files daemons/dnssec/ipa-dnskeysync-replica and >> daemons/dnssec/ipa-ods-exporter. > > This is much better, thanks! I've got some comments inline. > >> +except gssapi.exceptions.GSSError: >> # If there was failure on using keytab, assume it is stale and retrieve again >> retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal) > > This code still bothers me a bit, but I think fixing it is probably > beyond the scope of a python-gssapi port. The code catches all GSSAPI exceptions and retries to do the same thing with different keytab. So if there was a problem unrelated to keytab, the same exception will be raised again. Nothing will be ignored silently. > >> + try: >> + creds = get_credentials(name=name, ccache_name=ccache_name) >> + # property access would raise exception if expired >> + if creds.lifetime > 0: >> + return creds >> + except gssapi.exceptions.ExpiredCredentialsError: >> + return None > > Per rfc2744, lifetime is unsigned. It's not immediately clear what will > happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in > that case? I think the check is probably redundant, gssapi raises exception upon inquiring expired credentials. In trust-fetch-domains I just access the lifetime in try-except without using the value, so I could do the same here. It would be nice if gssapi provided some 'is_valid' or 'is_expired' method, so I wouldn't need to rely on side-effects of property access, which is hard to read and confuses pylint. > >> # Setup LDAP connection >> try: >> - ctx = krbV.default_context() >> - ccache = ctx.default_ccache() >> - api.Backend.ldap2.connect(ccache) >> + api.Backend.ldap2.connect() >> cls.ldap = api.Backend.ldap2 >> - except krbV.Krb5Error as e: >> + except gssapi.exceptions.GSSError: >> sys.exit("Must have Kerberos credentials to migrate Winsync users.") > > Can you log the error here? The other places GSSError is being caught > are doing a great job of either filtering-and-raising or > logging-and-exiting, so thanks for fixing those. Yes, I'll update it in next revision of the patch. > >> +# Ugly hack for test purposes only. GSSAPI has no way to get default ccache >> +# name, but we don't need it outside test server >> +def get_default_ccache_name(): >> + try: >> + out = check_output(['klist']) >> + except CalledProcessError: >> + raise RuntimeError("Default ccache not found. Did you kinit?") >> + match = re.match(r'^Ticket cache:\s*(\S+)', out) >> + if not match: >> + raise RuntimeError("Cannot obtain ccache name") >> + return match.group(1) > > Yup, this is still ugly. Ah well, it's only test code. > I was trying to modify the code to not need the variable and just use the default, but it is used for manipulating it as a file - in production it is always defined by mod_auth_gssapi. So I'd keep this as is. From david.dejaeghere at gmail.com Thu Aug 20 12:46:11 2015 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Thu, 20 Aug 2015 14:46:11 +0200 Subject: [Freeipa-devel] [Freeipa-users] Dns SOA MNAME not resolving from LDAP data In-Reply-To: <55D5CA30.9040009@redhat.com> References: <55D5C699.6080205@redhat.com> <55D5C8C0.80009@redhat.com> <55D5CA30.9040009@redhat.com> Message-ID: confirmed working. Does this default value make any sense if this value is changeable in the UI and using the IPA client? Kind Regards, David 2015-08-20 14:38 GMT+02:00 Martin Basti : > > > On 08/20/2015 02:35 PM, David Dejaeghere wrote: > > Aha, > > Correct. But i never set this. This option seems to be set by default. > I verified this issue on multiple installs. It seems they all have this > option set by default? > > Can i safely change named.conf without fearing my modifications will be > lost on an update? > > Kind Regards, > > David > > (Adding freeipa-users back) > > I checked code, it is default. > > You can change named.conf, upgrade will not replace it. > > Martin > > > 2015-08-20 14:32 GMT+02:00 Martin Basti : > >> >> On 08/20/2015 02:22 PM, Martin Basti wrote: >> >> >> >> On 08/20/2015 01:48 PM, David Dejaeghere wrote: >> >> Hi, >> >> I noticed that changing the authoritarive nameserver in FreeIPA reflects >> correctly to its directory data but bind will not resolve the soa record >> with the updated mname details. >> >> For example I add a zone test.be and change the mname record. >> >> [root at ns02 ~]# ipa dnszone-add >> Zone name: test.be >> Zone name: test.be. >> Active zone: TRUE >> * Authoritative nameserver: ns02.tokiogroup.be >> .* >> Administrator e-mail address: hostmaster >> SOA serial: 1440070999 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> BIND update policy: grant TOKIOGROUP.BE krb5-self * A; grant >> TOKIOGROUP.BE krb5-self * AAAA; grant TOKIOGROUP.BE krb5-self * >> SSHFP; >> Dynamic update: FALSE >> Allow query: any; >> Allow transfer: none; >> [root at ns02 ~]# ipa dnszone-mod --nameserver >> anaconda-ks.cfg .bash_logout .bashrc .ipa/ .ssh/ >> .bash_history .bash_profile .cshrc .pki/ >> .tcshrc >> >> >> [root at ns02 ~]# ipa dnszone-mod --name-server* ns7.tokiogroup.be >> *. >> Zone name: test.be >> ipa: WARNING: Semantic of setting Authoritative nameserver was changed. >> It is used only for setting the SOA MNAME attribute. >> NS record(s) can be edited in zone apex - '@'. >> Zone name: test.be. >> Active zone: TRUE >> *Authoritative nameserver: ns7.tokiogroup.be >> .* >> Administrator e-mail address: hostmaster >> SOA serial: 1440071001 >> SOA refresh: 3600 >> SOA retry: 900 >> SOA expire: 1209600 >> SOA minimum: 3600 >> Allow query: any; >> Allow transfer: none; >> >> >> [root at ns02 ~]# nslookup >> > set q=SOA >> > test.be >> Server: 127.0.0.1 >> Address: 127.0.0.1#53 >> >> test.be >> * origin = ns02.tokiogroup.be * >> mail addr = hostmaster.test.be >> serial = 1440071001 >> refresh = 3600 >> retry = 900 >> expire = 1209600 >> minimum = 3600 >> >> As you can see the SOA record still shows the original default value. >> >> Kind Regards, >> >> David Dejaeghere >> >> >> >> Thank you for this bug report. >> I opened bind-dyndb-ldap ticket >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/159 >> >> Martin >> >> >> I maybe found why do you have this issue, >> >> do you have fake_mname configured in bind_dyndb_ldap section of >> named.conf? >> If yes then remove this option to use SOA MNAME from LDAP. >> >> Martin >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Fri Aug 21 14:25:09 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 21 Aug 2015 16:25:09 +0200 Subject: [Freeipa-devel] conflict in the 4.2 packages freeipa-server and freeipa-server-dns Message-ID: <55D734C5.5010502@redhat.com> $ yum install freeipa-*.rpm Yum command has been deprecated, redirecting to '/usr/bin/dnf install freeipa-admintools-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm freeipa-client-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm freeipa-debuginfo-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm freeipa-python-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm freeipa-server-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm freeipa-server-dns-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm freeipa-server-trust-ad-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm freeipa-tests-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm'. See 'man dnf' and 'man yum2dnf' for more information. To transfer transaction metadata from yum to DNF, run: 'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate' Last metadata expiration check performed 0:00:39 ago on Fri Aug 21 09:48:30 2015. Error: package freeipa-server-dns-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64 obsoletes freeipa-server <= 4.2.0.0 provided by freeipa-server-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Fri Aug 21 14:34:12 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 21 Aug 2015 16:34:12 +0200 Subject: [Freeipa-devel] conflict in the 4.2 packages freeipa-server and freeipa-server-dns In-Reply-To: <55D734C5.5010502@redhat.com> References: <55D734C5.5010502@redhat.com> Message-ID: <55D736E4.5040701@redhat.com> On 08/21/2015 04:25 PM, Oleg Fayans wrote: > $ yum install freeipa-*.rpm > Yum command has been deprecated, redirecting to '/usr/bin/dnf install > freeipa-admintools-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm > freeipa-client-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm > freeipa-debuginfo-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm > freeipa-python-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm > freeipa-server-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm > freeipa-server-dns-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm > freeipa-server-trust-ad-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm > freeipa-tests-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64.rpm'. > See 'man dnf' and 'man yum2dnf' for more information. > To transfer transaction metadata from yum to DNF, run: > 'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate' > > Last metadata expiration check performed 0:00:39 ago on Fri Aug 21 > 09:48:30 2015. > Error: package > freeipa-server-dns-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64 > obsoletes freeipa-server <= 4.2.0.0 provided by > freeipa-server-4.2.0-20150821123735Zjenkins41git6b86238.fc22.x86_64 > This is already being discussed in the following thread: https://www.redhat.com/archives/freeipa-devel/2015-August/msg00085.html -- Martin^3 Babinsky From simo at redhat.com Fri Aug 21 14:34:48 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 21 Aug 2015 10:34:48 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55D72D15.3010901@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> Message-ID: <1440167688.2340.20.camel@willson.usersys.redhat.com> On Fri, 2015-08-21 at 15:52 +0200, Michael ?im??ek wrote: > > On 2015-08-20 20:42, Robbie Harwood wrote: > > Michael ?im??ek writes: > > > >> On 2015-08-20 12:32, Michael ?im??ek wrote: > >> > >>>>>> Michael ?im??ek writes: > >>>>>> > >>>>>>> Attaching new revision of the patch. Changes from the previous: > >>>>>>> - ldap2's connect now chooses the bind type same way as in ipaldap > >>>>>>> - get_default_realm usages replaced by api.env.realm > >>>>>>> - fixed missing third kinit attempt in trust-fetch-domains > >>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils > >>>>>>> - updated some parts of exception handling > >>> > >>> Rebased on top of current master. > >> > >> One of the commits reintroduced krbV dependency that I didn't notice. > >> Attaching updated revision. Only changes against previous revision are > >> in files daemons/dnssec/ipa-dnskeysync-replica and > >> daemons/dnssec/ipa-ods-exporter. > > > > This is much better, thanks! I've got some comments inline. > > > >> +except gssapi.exceptions.GSSError: > >> # If there was failure on using keytab, assume it is stale and retrieve again > >> retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal) > > > > This code still bothers me a bit, but I think fixing it is probably > > beyond the scope of a python-gssapi port. > > The code catches all GSSAPI exceptions and retries to do the same thing > with different keytab. So if there was a problem unrelated to keytab, > the same exception will be raised again. Nothing will be ignored silently. > > > > >> + try: > >> + creds = get_credentials(name=name, ccache_name=ccache_name) > >> + # property access would raise exception if expired > >> + if creds.lifetime > 0: > >> + return creds > >> + except gssapi.exceptions.ExpiredCredentialsError: > >> + return None > > > > Per rfc2744, lifetime is unsigned. It's not immediately clear what will > > happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in > > that case? > > I think the check is probably redundant, gssapi raises exception upon > inquiring expired credentials. In trust-fetch-domains I just access the > lifetime in try-except without using the value, so I could do the same > here. It would be nice if gssapi provided some 'is_valid' or > 'is_expired' method, so I wouldn't need to rely on side-effects of > property access, which is hard to read and confuses pylint. Inquiring the credentials *is* the method to check if they are valid or expired, what don't you like about it? The fact it raises when they are expired ? > > > >> # Setup LDAP connection > >> try: > >> - ctx = krbV.default_context() > >> - ccache = ctx.default_ccache() > >> - api.Backend.ldap2.connect(ccache) > >> + api.Backend.ldap2.connect() > >> cls.ldap = api.Backend.ldap2 > >> - except krbV.Krb5Error as e: > >> + except gssapi.exceptions.GSSError: > >> sys.exit("Must have Kerberos credentials to migrate Winsync users.") > > > > Can you log the error here? The other places GSSError is being caught > > are doing a great job of either filtering-and-raising or > > logging-and-exiting, so thanks for fixing those. > > Yes, I'll update it in next revision of the patch. > > > > >> +# Ugly hack for test purposes only. GSSAPI has no way to get default ccache > >> +# name, but we don't need it outside test server > >> +def get_default_ccache_name(): > >> + try: > >> + out = check_output(['klist']) > >> + except CalledProcessError: > >> + raise RuntimeError("Default ccache not found. Did you kinit?") > >> + match = re.match(r'^Ticket cache:\s*(\S+)', out) > >> + if not match: > >> + raise RuntimeError("Cannot obtain ccache name") > >> + return match.group(1) > > > > Yup, this is still ugly. Ah well, it's only test code. > > > > I was trying to modify the code to not need the variable and just use > the default, but it is used for manipulating it as a file - in > production it is always defined by mod_auth_gssapi. So I'd keep this as is. Ideally we use export_cred/store_cred and not manipulate files directly, but with memcache in the picture we have to compromise anyway, oh well ... Simo. -- Simo Sorce * Red Hat, Inc * New York From msimacek at redhat.com Fri Aug 21 15:13:50 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Fri, 21 Aug 2015 17:13:50 +0200 Subject: [Freeipa-devel] [PATCH 0003] Bump python-gssapi version to 1.1.2 Message-ID: <55D7402E.2050702@redhat.com> python-gssapi had a bug in exception handling that caused exceptions to be shadowed by LookupError. The new version should fix the problem. https://fedorahosted.org/freeipa/ticket/5225 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0003-1-Bump-python-gssapi-version-to-1.1.2.patch Type: text/x-patch Size: 1219 bytes Desc: not available URL: From simo at redhat.com Fri Aug 21 15:24:11 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 21 Aug 2015 11:24:11 -0400 Subject: [Freeipa-devel] [PATCH 0003] Bump python-gssapi version to 1.1.2 In-Reply-To: <55D7402E.2050702@redhat.com> References: <55D7402E.2050702@redhat.com> Message-ID: <1440170651.2340.31.camel@willson.usersys.redhat.com> On Fri, 2015-08-21 at 17:13 +0200, Michael ?im??ek wrote: > python-gssapi had a bug in exception handling that caused exceptions to > be shadowed by LookupError. The new version should fix the problem. > > https://fedorahosted.org/freeipa/ticket/5225 ACK. Simo. -- Simo Sorce * Red Hat, Inc * New York From rharwood at redhat.com Fri Aug 21 16:16:31 2015 From: rharwood at redhat.com (Robbie Harwood) Date: Fri, 21 Aug 2015 12:16:31 -0400 Subject: [Freeipa-devel] [PATCH 0003] Bump python-gssapi version to 1.1.2 In-Reply-To: <55D7402E.2050702@redhat.com> References: <55D7402E.2050702@redhat.com> Message-ID: Michael ?im??ek writes: > python-gssapi had a bug in exception handling that caused exceptions to > be shadowed by LookupError. The new version should fix the problem. > > https://fedorahosted.org/freeipa/ticket/5225 Yes, exactly. Looks good! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From edewata at redhat.com Fri Aug 21 23:46:37 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 21 Aug 2015 18:46:37 -0500 Subject: [Freeipa-devel] [PATCH] 376 Removed clear text passwords from KRA install log. Message-ID: <55D7B85D.1090708@redhat.com> The ipa-kra-install tool has been modified to use password files instead of clear text passwords when invoking pki tool such that the passwords are no longer visible in ipaserver-kra-install.log. https://fedorahosted.org/freeipa/ticket/5246 -- Endi S. Dewata -------------- next part -------------- From 545de89d5b8992469335415d209b6f04be6918ed Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Sat, 22 Aug 2015 01:14:16 +0200 Subject: [PATCH] Removed clear text passwords from KRA install log. The ipa-kra-install tool has been modified to use password files instead of clear text passwords when invoking pki tool such that the passwords are no longer visible in ipaserver-kra-install.log. https://fedorahosted.org/freeipa/ticket/5246 --- ipaplatform/base/paths.py | 2 ++ ipaserver/install/krainstance.py | 16 ++++++++-------- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index 0dd3c7fda3020264a1ace8f2d13557cfddf18c2d..5c8f25d6ef85fab2b9b30a660cd1c0360dbe9931 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -343,6 +343,8 @@ class BasePathNamespace(object): SLAPD_INSTANCE_SOCKET_TEMPLATE = "/var/run/slapd-%s.socket" ALL_SLAPD_INSTANCE_SOCKETS = "/var/run/slapd-*.socket" ADMIN_CERT_PATH = '/root/.dogtag/pki-tomcat/ca_admin.cert' + KRA_NSSDB_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/password.conf" + KRA_PKCS12_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/pkcs12_password.conf" ENTROPY_AVAIL = '/proc/sys/kernel/random/entropy_avail' LDIF2DB = '/usr/sbin/ldif2db' DB2LDIF = '/usr/sbin/db2ldif' diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index fa50c3dec897d63b9d3522d196054163f7b3369a..e5cdbf5e7714603041e3f0156e87311994175b18 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -275,16 +275,16 @@ class KRAInstance(DogtagInstance): # import CA certificate into temporary security database args = ["/usr/bin/pki", "-d", self.agent_db, - "-c", self.admin_password, + "-C", paths.KRA_NSSDB_PASSWORD_FILE, "client-cert-import", "--pkcs12", paths.KRACERT_P12, - "--pkcs12-password", self.admin_password] + "--pkcs12-password-file", paths.KRA_PKCS12_PASSWORD_FILE] ipautil.run(args) # trust CA certificate args = ["/usr/bin/pki", "-d", self.agent_db, - "-c", self.admin_password, + "-C", paths.KRA_NSSDB_PASSWORD_FILE, "client-cert-mod", "Certificate Authority - %s" % api.env.realm, "--trust", "CT,c,"] ipautil.run(args) @@ -292,16 +292,16 @@ class KRAInstance(DogtagInstance): # import Dogtag admin certificate into temporary security database args = ["/usr/bin/pki", "-d", self.agent_db, - "-c", self.admin_password, + "-C", paths.KRA_NSSDB_PASSWORD_FILE, "client-cert-import", "--pkcs12", paths.DOGTAG_ADMIN_P12, - "--pkcs12-password", self.admin_password] + "--pkcs12-password-file", paths.KRA_PKCS12_PASSWORD_FILE] ipautil.run(args) # as Dogtag admin, create ipakra user in KRA args = ["/usr/bin/pki", "-d", self.agent_db, - "-c", self.admin_password, + "-C", paths.KRA_NSSDB_PASSWORD_FILE, "-n", "ipa-ca-agent", "kra-user-add", "ipakra", "--fullName", "IPA KRA User"] @@ -310,7 +310,7 @@ class KRAInstance(DogtagInstance): # as Dogtag admin, add ipakra into KRA agents group args = ["/usr/bin/pki", "-d", self.agent_db, - "-c", self.admin_password, + "-C", paths.KRA_NSSDB_PASSWORD_FILE, "-n", "ipa-ca-agent", "kra-user-membership-add", "ipakra", "Data Recovery Manager Agents"] ipautil.run(args) @@ -330,7 +330,7 @@ class KRAInstance(DogtagInstance): # as Dogtag admin, upload and assign ipaCert to ipakra args = ["/usr/bin/pki", "-d", self.agent_db, - "-c", self.admin_password, + "-C", paths.KRA_NSSDB_PASSWORD_FILE, "-n", "ipa-ca-agent", "kra-user-cert-add", "ipakra", "--input", filename] -- 2.4.3 From abokovoy at redhat.com Sat Aug 22 06:17:48 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 22 Aug 2015 09:17:48 +0300 Subject: [Freeipa-devel] [PATCH] 376 Removed clear text passwords from KRA install log. In-Reply-To: <55D7B85D.1090708@redhat.com> References: <55D7B85D.1090708@redhat.com> Message-ID: <20150822061748.GL22106@redhat.com> On Fri, 21 Aug 2015, Endi Sukma Dewata wrote: >The ipa-kra-install tool has been modified to use password files >instead of clear text passwords when invoking pki tool such that >the passwords are no longer visible in ipaserver-kra-install.log. > >https://fedorahosted.org/freeipa/ticket/5246 > >-- >Endi S. Dewata >From 545de89d5b8992469335415d209b6f04be6918ed Mon Sep 17 00:00:00 2001 >From: "Endi S. Dewata" >Date: Sat, 22 Aug 2015 01:14:16 +0200 >Subject: [PATCH] Removed clear text passwords from KRA install log. > >The ipa-kra-install tool has been modified to use password files >instead of clear text passwords when invoking pki tool such that >the passwords are no longer visible in ipaserver-kra-install.log. > >https://fedorahosted.org/freeipa/ticket/5246 >--- > ipaplatform/base/paths.py | 2 ++ > ipaserver/install/krainstance.py | 16 ++++++++-------- > 2 files changed, 10 insertions(+), 8 deletions(-) > >diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py >index 0dd3c7fda3020264a1ace8f2d13557cfddf18c2d..5c8f25d6ef85fab2b9b30a660cd1c0360dbe9931 100644 >--- a/ipaplatform/base/paths.py >+++ b/ipaplatform/base/paths.py >@@ -343,6 +343,8 @@ class BasePathNamespace(object): > SLAPD_INSTANCE_SOCKET_TEMPLATE = "/var/run/slapd-%s.socket" > ALL_SLAPD_INSTANCE_SOCKETS = "/var/run/slapd-*.socket" > ADMIN_CERT_PATH = '/root/.dogtag/pki-tomcat/ca_admin.cert' >+ KRA_NSSDB_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/password.conf" >+ KRA_PKCS12_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/pkcs12_password.conf" ACK. For the record, these files are created by pki-spawn early in the creation of security databases for CA deployment. The second file isnt created if CA is deployed with HSM option (the databases are in hardware then) but then the first one is created for HSM and thus both of them are in use. We don't support deployment with HSM backend yet, but the code covers both cases. In future it would be good to actually source these values from /etc/pki/default.cfg: pki_client_password_conf=%(pki_client_subsystem_dir)s/password.conf pki_client_pkcs12_password_conf=%(pki_client_subsystem_dir)s/pkcs12_password.conf but right now this would mean need to use dogtag's Python helpers from pki.server.deployment.pkiparser.PKIConfigParser.read_pki_configuration_file() to do actual sourcing of the config file but right now PKIConfigParser use assumes it is actually parsing the command line options/arguments before using its methods: >>> from pki.server.deployment.pkiparser import PKIConfigParser >>> cfg = PKIConfigParser('IPA CA', '') >>> cfg.init_config() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 196, in init_config 'pki_subsystem_type': config.pki_subsystem.lower(), AttributeError: 'NoneType' object has no attribute 'lower' >>> -- / Alexander Bokovoy From msimacek at redhat.com Sun Aug 23 20:15:44 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Sun, 23 Aug 2015 22:15:44 +0200 Subject: [Freeipa-devel] [PATCH 0003] Bump python-gssapi version to 1.1.2 In-Reply-To: <55D7402E.2050702@redhat.com> References: <55D7402E.2050702@redhat.com> Message-ID: <55DA29F0.6040401@redhat.com> On 2015-08-21 17:13, Michael ?im??ek wrote: > python-gssapi had a bug in exception handling that caused exceptions to > be shadowed by LookupError. The new version should fix the problem. > > https://fedorahosted.org/freeipa/ticket/5225 > > I accidentally based it on top of unmerged patch. Attaching the same patch based on current master. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0003-2-Bump-python-gssapi-version-to-1.1.2.patch Type: text/x-patch Size: 1192 bytes Desc: not available URL: From msimacek at redhat.com Sun Aug 23 21:27:43 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Sun, 23 Aug 2015 23:27:43 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55D72D15.3010901@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> Message-ID: <55DA3ACF.9010504@redhat.com> On 2015-08-21 15:52, Michael ?im??ek wrote: > > > On 2015-08-20 20:42, Robbie Harwood wrote: >> Michael ?im??ek writes: >> >>> On 2015-08-20 12:32, Michael ?im??ek wrote: >>> >>>>>>> Michael ?im??ek writes: >>>>>>> >>>>>>>> Attaching new revision of the patch. Changes from the previous: >>>>>>>> - ldap2's connect now chooses the bind type same way as in ipaldap >>>>>>>> - get_default_realm usages replaced by api.env.realm >>>>>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>>>>> - updated some parts of exception handling >>>> >>>> Rebased on top of current master. >>> >>> One of the commits reintroduced krbV dependency that I didn't notice. >>> Attaching updated revision. Only changes against previous revision are >>> in files daemons/dnssec/ipa-dnskeysync-replica and >>> daemons/dnssec/ipa-ods-exporter. >> >> This is much better, thanks! I've got some comments inline. >> >>> +except gssapi.exceptions.GSSError: >>> # If there was failure on using keytab, assume it is stale and >>> retrieve again >>> retrieve_keytab(api, ccache_name, oneway_keytab_name, >>> oneway_principal) >> >> This code still bothers me a bit, but I think fixing it is probably >> beyond the scope of a python-gssapi port. > > The code catches all GSSAPI exceptions and retries to do the same thing > with different keytab. So if there was a problem unrelated to keytab, > the same exception will be raised again. Nothing will be ignored silently. > >> >>> + try: >>> + creds = get_credentials(name=name, ccache_name=ccache_name) >>> + # property access would raise exception if expired >>> + if creds.lifetime > 0: >>> + return creds >>> + except gssapi.exceptions.ExpiredCredentialsError: >>> + return None >> >> Per rfc2744, lifetime is unsigned. It's not immediately clear what will >> happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in >> that case? > > I think the check is probably redundant, gssapi raises exception upon > inquiring expired credentials. In trust-fetch-domains I just access the > lifetime in try-except without using the value, so I could do the same > here. It would be nice if gssapi provided some 'is_valid' or > 'is_expired' method, so I wouldn't need to rely on side-effects of > property access, which is hard to read and confuses pylint. > >> >>> # Setup LDAP connection >>> try: >>> - ctx = krbV.default_context() >>> - ccache = ctx.default_ccache() >>> - api.Backend.ldap2.connect(ccache) >>> + api.Backend.ldap2.connect() >>> cls.ldap = api.Backend.ldap2 >>> - except krbV.Krb5Error as e: >>> + except gssapi.exceptions.GSSError: >>> sys.exit("Must have Kerberos credentials to migrate >>> Winsync users.") >> >> Can you log the error here? The other places GSSError is being caught >> are doing a great job of either filtering-and-raising or >> logging-and-exiting, so thanks for fixing those. > > Yes, I'll update it in next revision of the patch. > >> >>> +# Ugly hack for test purposes only. GSSAPI has no way to get default >>> ccache >>> +# name, but we don't need it outside test server >>> +def get_default_ccache_name(): >>> + try: >>> + out = check_output(['klist']) >>> + except CalledProcessError: >>> + raise RuntimeError("Default ccache not found. Did you kinit?") >>> + match = re.match(r'^Ticket cache:\s*(\S+)', out) >>> + if not match: >>> + raise RuntimeError("Cannot obtain ccache name") >>> + return match.group(1) >> >> Yup, this is still ugly. Ah well, it's only test code. >> > > I was trying to modify the code to not need the variable and just use > the default, but it is used for manipulating it as a file - in > production it is always defined by mod_auth_gssapi. So I'd keep this as is. > Next revision of the patch. Changes from previous rev: printing exception in ipa_winsync_migrate and more thorough dealing with credentials expiration in krb_utils and trust-fetch-domains. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-7-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 71940 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 24 05:50:42 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Aug 2015 07:50:42 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55D71EA8.4040002@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> Message-ID: <55DAB0B2.8050300@redhat.com> On 21.8.2015 14:50, Christian Heimes wrote: > On 2015-08-21 12:55, Petr Viktorin wrote: >> On 08/14/2015 07:44 PM, Petr Viktorin wrote: >>> Hello, >>> These patches bring IPA another step towards compatibility with Python 3. >>> >>> Most of these were made by fixers from the "python-modernize" tool, but >>> I reviewed and edited the results. >> >> Here are the patches rebased to current master. > > 0696.2-Remove-use-of-sys.exc_value > ACK > > > 0697.2-Don-t-use-a-tuple-in-function-arguments > I prefer operator.itemgetter() over the hard-to-read lambda expression > key=lambda k_v: (k_v[1], k_v[0]). >>>> import operator >>>> example = dict(a=3, ba=2, b=2, c=1) >>>> sorted(example.items(), key=operator.itemgetter(1, 0)) > [('c', 1), ('b', 2), ('ba', 2), ('a', 3)] > > > 0698.2-Add-python-six-to-dependencies > ACK > > > 0699.2-Remove-the-unused-pygettext-script > ACK > > > 0700.2-Use-six.string_types-instead-of-basestring > LGTM, but I need to have a closer look at some places. > I noticed a couple of asserts that should be "if ... raise ValueError" > instead. python -o disables asserts. > > > 0701.2-Use-Python3-compatible-dict-method-names > NACK > Why are you replacing iteritems() with items() instead of using > six.iteritems()? > Please use sorted(reference) instead of sorted(reference.keys()), > set(tree) instead of set(tree.keys()) and list(somedict) instead of > list(somedict.keys()), too. The keys() call is unnecessary and frowned upon. > > > 0702.2-Replace-filter-calls-with-list-comprehensions > In Python 2 list comprehensions leak the internal loop variable. It > might be better to write a generator expression with list() instead of > [] list comprehension. > > > 0703.2-Use-six.moves.input-instead-of-raw_input > ACK > The code is fine, but pylint won't like it. For Dogtag I had to disable > pylint warnings W0622 and F0401. > > > 0704.2-Use-six.integer_types-instead-of-long-int > ACK > hint: For type checks you can also use the numbers module. > > > 0705.2-Replace-uses-of-map > See comment for 0702 > > > 706.2-Use-next-function-on-iterators > ACK These are generator objects in ipapython/install/core.py. I'm not sure what the usual convention is, but I would think that the gen.next() calls should be replaced with gen.send(None) instead of next(gen), so that the generators are accessed consistently using methods (gen.send()/gen.throw()/gen.close()). > > > 0707.2-Use-the-print-function > LGTM > There are too many chances to review. Let's hope the automatic > conversion tool did its job correctly. > > > 0708.2-Use-new-style-raise-syntax > ACK > > > 0709.2-Use-six.reraise > ACK Instead of calling six.reraise from raise_exc_info, could you replace the two occurences of raise_exc_info(exc_info) with six.reraise(*exc_info) and remove raise_exc_info? > > > 0710.2-Modernize-use-of-range > NACK > Please use six.moves.range. It defaults to xrange() in Python 2. I also > see a couple of additional opportunities for enumerate(): > > for i in range(len(kw['attrs'])): > kw['attrs'][i] = unicode(kw['attrs'][i]) > > for i, s in enumerate(kw['attrs']): > kw['attrs'][i] = unicode(s) > > > 0711.2-Convert-zip-result-to-list > ACK > The code isn't beautiful but it's just a test. > > > > -- Jan Cholasta From jcholast at redhat.com Mon Aug 24 06:04:18 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Aug 2015 08:04:18 +0200 Subject: [Freeipa-devel] [PATCH 0003] Bump python-gssapi version to 1.1.2 In-Reply-To: <55DA29F0.6040401@redhat.com> References: <55D7402E.2050702@redhat.com> <55DA29F0.6040401@redhat.com> Message-ID: <55DAB3E2.2030509@redhat.com> On 23.8.2015 22:15, Michael ?im??ek wrote: > On 2015-08-21 17:13, Michael ?im??ek wrote: >> python-gssapi had a bug in exception handling that caused exceptions to >> be shadowed by LookupError. The new version should fix the problem. >> >> https://fedorahosted.org/freeipa/ticket/5225 >> >> > > I accidentally based it on top of unmerged patch. Attaching the same > patch based on current master. Pushed to master: 584788a91ac14577d75f5e1651ed8cdeb80a6d6c -- Jan Cholasta From jcholast at redhat.com Mon Aug 24 06:48:30 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Aug 2015 08:48:30 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DAB0B2.8050300@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> Message-ID: <55DABE3E.6070305@redhat.com> On 24.8.2015 07:50, Jan Cholasta wrote: > On 21.8.2015 14:50, Christian Heimes wrote: >> On 2015-08-21 12:55, Petr Viktorin wrote: >>> On 08/14/2015 07:44 PM, Petr Viktorin wrote: >>>> Hello, >>>> These patches bring IPA another step towards compatibility with >>>> Python 3. >>>> >>>> Most of these were made by fixers from the "python-modernize" tool, but >>>> I reviewed and edited the results. >>> >>> Here are the patches rebased to current master. >> >> 0696.2-Remove-use-of-sys.exc_value >> ACK >> >> >> 0697.2-Don-t-use-a-tuple-in-function-arguments >> I prefer operator.itemgetter() over the hard-to-read lambda expression >> key=lambda k_v: (k_v[1], k_v[0]). >>>>> import operator >>>>> example = dict(a=3, ba=2, b=2, c=1) >>>>> sorted(example.items(), key=operator.itemgetter(1, 0)) >> [('c', 1), ('b', 2), ('ba', 2), ('a', 3)] >> >> >> 0698.2-Add-python-six-to-dependencies >> ACK >> >> >> 0699.2-Remove-the-unused-pygettext-script >> ACK >> >> >> 0700.2-Use-six.string_types-instead-of-basestring >> LGTM, but I need to have a closer look at some places. >> I noticed a couple of asserts that should be "if ... raise ValueError" >> instead. python -o disables asserts. It seems you missed a few "basestring"s in ipapython/dn.py. >> >> >> 0701.2-Use-Python3-compatible-dict-method-names >> NACK >> Why are you replacing iteritems() with items() instead of using >> six.iteritems()? >> Please use sorted(reference) instead of sorted(reference.keys()), >> set(tree) instead of set(tree.keys()) and list(somedict) instead of >> list(somedict.keys()), too. The keys() call is unnecessary and frowned >> upon. >> >> >> 0702.2-Replace-filter-calls-with-list-comprehensions >> In Python 2 list comprehensions leak the internal loop variable. It >> might be better to write a generator expression with list() instead of >> [] list comprehension. >> >> >> 0703.2-Use-six.moves.input-instead-of-raw_input >> ACK >> The code is fine, but pylint won't like it. For Dogtag I had to disable >> pylint warnings W0622 and F0401. >> >> >> 0704.2-Use-six.integer_types-instead-of-long-int >> ACK >> hint: For type checks you can also use the numbers module. There are still some "(int, long)"s in ipalib/parameters.py, ipalib/rpc.py, ipalib/util.py, ipapython/cookie.py, ipapython/dn.py and ipapython/ipaldap.py Also, there are bare "long"s in ipapython/install/cli.py, ipaserver/dcerpc.py, ipaserver/install/ipa_otptoken_import.py and ipatests/test_ipalib/test_parameters.py. >> >> >> 0705.2-Replace-uses-of-map >> See comment for 0702 It seems you missed a few "map()"s in ipalib/plugins/certprofile.py, ipalib/plugins/dns.py, ipalib/plugins/sudorule.py and ipatests/test_xmlrpc/test_add_remove_cert_cmd.py. >> >> >> 706.2-Use-next-function-on-iterators >> ACK > > These are generator objects in ipapython/install/core.py. I'm not sure > what the usual convention is, but I would think that the gen.next() > calls should be replaced with gen.send(None) instead of next(gen), so > that the generators are accessed consistently using methods > (gen.send()/gen.throw()/gen.close()). > >> >> >> 0707.2-Use-the-print-function >> LGTM >> There are too many chances to review. Let's hope the automatic >> conversion tool did its job correctly. I see some print statements in ipapython/dn.py. >> >> >> 0708.2-Use-new-style-raise-syntax >> ACK >> >> >> 0709.2-Use-six.reraise >> ACK > > Instead of calling six.reraise from raise_exc_info, could you replace > the two occurences of raise_exc_info(exc_info) with > six.reraise(*exc_info) and remove raise_exc_info? > >> >> >> 0710.2-Modernize-use-of-range >> NACK >> Please use six.moves.range. It defaults to xrange() in Python 2. I also >> see a couple of additional opportunities for enumerate(): >> >> for i in range(len(kw['attrs'])): >> kw['attrs'][i] = unicode(kw['attrs'][i]) >> >> for i, s in enumerate(kw['attrs']): >> kw['attrs'][i] = unicode(s) >> >> >> 0711.2-Convert-zip-result-to-list >> ACK >> The code isn't beautiful but it's just a test. >> >> >> >> > > -- Jan Cholasta From ofayans at redhat.com Mon Aug 24 08:06:06 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 24 Aug 2015 10:06:06 +0200 Subject: [Freeipa-devel] Unable to install bits from ipa-4-2 branch In-Reply-To: <55D2FCC6.3040806@redhat.com> References: <55C8AD57.7060206@redhat.com> <55C8AF47.4050201@redhat.com> <55C8B81C.9000900@redhat.com> <55CB29BA.7050200@redhat.com> <55D19A0C.7040607@redhat.com> <55D1F348.5080205@redhat.com> <55D1F411.3090107@redhat.com> <55D2FCC6.3040806@redhat.com> Message-ID: <55DAD06E.2010904@redhat.com> Hi, On 08/18/2015 11:37 AM, Jan Cholasta wrote: > On 17.8.2015 16:47, Milan Kub?k wrote: >> On 08/17/2015 04:44 PM, Milan Kub?k wrote: >>> On 08/17/2015 10:23 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/12/2015 01:10 PM, Milan Kub?k wrote: >>>>> On 08/10/2015 04:41 PM, Jan Cholasta wrote: >>>>>> Dne 10.8.2015 v 16:03 Milan Kub?k napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>> -------- Forwarded Message -------- >>>>>>> Subject: Re: [Freeipa-devel] Unable to install bits from >>>>>>> ipa-4-2 branch >>>>>>> Date: Mon, 10 Aug 2015 15:55:35 +0200 >>>>>>> From: Jan Cholasta >>>>>>> To: Milan Kub?k >>>>>>> CC: Martin Kosek >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dne 10.8.2015 v 15:31 Milan Kub?k napsal(a): >>>>>>>> On 08/10/2015 03:22 PM, Jan Cholasta wrote: >>>>>>>>> Dne 7.8.2015 v 09:17 Martin Kosek napsal(a): >>>>>>>>>> On 08/07/2015 08:46 AM, Jan Cholasta wrote: >>>>>>>>>>> Dne 7.8.2015 v 08:44 Martin Kosek napsal(a): >>>>>>>>>>>> On 08/06/2015 05:26 PM, Milan Kub?k wrote: >>>>>>>>>>>>> Hi list, >>>>>>>>>>>>> >>>>>>>>>>>>> I just noticed that the bits built from ipa-4-2 branch >>>>>>>>>>>>> cannot be >>>>>>>>>>>>> installed. >>>>>>>>>>>>> The freeipa packages built have version such as >>>>>>>>>>>>> freeipa-server-dns-4.2.0-0.20150806083844Zjenkins9git2812242.fc22.x86_64 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The version check in the spec file makes the server-dns >>>>>>>>>>>>> package >>>>>>>>>>>>> obsolete the >>>>>>>>>>>>> server package from tha same build. >>>>>>>>>>>>> The cause is the commit [1]. This issue blocks us from >>>>>>>>>>>>> running tests >>>>>>>>>>>>> on ipa-4-2 >>>>>>>>>>>>> branch. >>>>>>>>>>>>> >>>>>>>>>>>>> Should we bump the minor version on this branch to 4.2.1? >>>>>>>>>>>>> >>>>>>>>>>>>> [1]: >>>>>>>>>>>>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=f555fe95dba9ec453fa10f160089dcc5404f724a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Milan >>>>>>>>>>>>> >>>>>>>>>>>> Why does the spec calls for >>>>>>>>>>>> >>>>>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>>>>> Obsoletes: %{name}-server <= 4.2.0 >>>>>>>>>>>> >>>>>>>>>>>> and not for >>>>>>>>>>>> >>>>>>>>>>>> # upgrade path from monolithic -server to -server + -server-dns >>>>>>>>>>>> Obsoletes: %{name}-server < 4.2.0 >>>>>>>>>>>> >>>>>>>>>>>> ? Is that the root cause of these issues? >>>>>>>>>>> >>>>>>>>>>> AFAIK this would break updates from 4.2.0 to 4.2.1. >>>>>>>>>> >>>>>>>>>> I wonder how it could break the upgrade... >>>>>>>>>> >>>>>>>>> >>>>>>>>> Patch attached. >>>>>>>>> >>>>>>>> This won't help as long as we build something like >>>>>>>> freeipa-server-dns-4.2.0-0.20150810111037Zjenkins11gitad6a87e >>>>>>> >>>>>>> Right. Updated patch attached. It will break updates from >>>>>>> pre-server-dns >>>>>>> git builds, but install should be fine. >>>>>>> >>>>>>> -- >>>>>>> Jan Cholasta >>>>>>> >>>>>>> >>>>>>> ACK, thanks. >>>>>> >>>>>> Self-NACK, as this also breaks updates from freeipa-4.2.0-0 from >>>>>> the freeipa-4.2 COPR. >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>> Hi, >>>>> >>>>> thanks for the patch. It works as far as updating from 4.1, the copr >>>>> build >>>>> (correctly replaces freeipa-server package) as well as upgrade from >>>>> earlier build from repository. >>>>> >>>>> If there are no objections, ACK from me. >>>>> >>>>> Milan >>>>> >>>> Pushed to ipa-4-2: 5d5240b9db3b9e6f29351c65272a363b253cd2d3 >>> Ok, while checking this manually it seemed to work, the jenkins build >>> names the package in a way that produces this error. The patch has no >>> effect in automation, unfortunatelly. The build on jenkins adds the >>> release version, when built manually, the name is >>> xyz.4.2.0.DATE+hash-string. >>> >>> Error: package >>> freeipa-server-dns-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 >>> obsoletes freeipa-server <= 4.2.0.0 provided by >>> freeipa-server-4.2.0-0.20150817084102Zjenkins28git5d5240b.fc22.x86_64 >>> >>> Late answer to Lukas, this is n:m scenario. I'm not sure what to do >>> if one subpackage retains the original name, though. >>> >>> >>> >> That being said, I can change the schema by which jenkins marks release >> version on the rpms it builds. >> This will provide a hacky way around this issue by creating >> 4.2.0.2015... provided by the timestamp. > > This is the scheme used by "make rpms", so I'd say go for it. Otherwise, > changing the "Obsoletes" line to: > > Obsoletes: %{name}-server <= 4.2.0.0-0.0 > > should fix it. > The problem is still observed. I am not sure how can we change the naming scheme of the packages (freeipa-4.2.0-2015* to freeipa-4.2.0.2015*). Could we implement the change in freeipa.spec.in, proposed by Jan? I mean, "Obsoletes: %{name}-server <= 4.2.0.0-0.0" -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From tbabej at redhat.com Mon Aug 24 08:44:26 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 24 Aug 2015 10:44:26 +0200 Subject: [Freeipa-devel] [PATCH] 0196 trusts: format Kerberos principal properly when fetching trust topology In-Reply-To: <20150820122102.GR22106@redhat.com> References: <20150820122102.GR22106@redhat.com> Message-ID: <55DAD96A.9010601@redhat.com> On 08/20/2015 02:21 PM, Alexander Bokovoy wrote: > Hi, > > one more fix for the problem with trusts that Scott Poore found when > verifying fixes to bug https://bugzilla.redhat.com/show_bug.cgi?id=1250190 > > Details are in the commit message. > > > ACK, this fixes the issue in case of two-way trusts. $ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type ipa-ad-trust --admin Administrator --password --two-way=TRUE ------------------------------------------------ Added Active Directory trust for realm "ad.test" ------------------------------------------------ Realm name: ad.test Domain NetBIOS name: AD ... Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified $ ipa idrange-find ---------------- 3 ranges matched ---------------- Range name: AD.TEST_id_range ... Range type: Active Directory domain range Range name: IPA.TEST_id_range ... Range type: local domain range Range name: SUB.AD.TEST_id_range ... Range type: Active Directory domain range ---------------------------- Number of entries returned 3 ---------------------------- Tomas From ldoudova at redhat.com Mon Aug 24 10:14:41 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 24 Aug 2015 12:14:41 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55D5DAA7.5030309@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> <55D5DAA7.5030309@redhat.com> Message-ID: <55DAEE91.40508@redhat.com> On 08/20/2015 03:48 PM, Martin Basti wrote: > > > On 08/14/2015 06:32 PM, Lenka Doudova wrote: >> Yes, that is "correct" - it's malfunctioning behavior of the plugin - >> command 'stageuser-add --from-delete', which is discussed in another >> thread. I left this test case for so long as it's not fixed/changed. >> If the command remains and is fixed, the test case will be valid, if >> it's changed I'll fix the test case to reflect the new command. >> >> Lenka >> >> On 08/14/2015 05:39 PM, Martin Basti wrote: >>> >>> >>> On 08/14/2015 11:04 AM, Lenka Doudova wrote: >>>>> NACK >>>>> >>>>> syntax error, missing ')' >>>>> -from ipatests.util import assert_equal, assert_not_equal, raises >>>>> +from ipatests.util import ( >>>>> + assert_equal, assert_not_equal, raises, assert_deepequal >>>>> >>>>> I cannot apply this patch, please check it >>>> >>>> Sorry for the error, corrected patch attached. >>>> I also added two testcases that Thierry proposed, and changed names >>>> of few methods (original ones were confusing). >>>> >>>> Lenka >>> I got this error >>> >>> ==================================================================================================== >>> FAILURES >>> ===================================================================================================== >>> ____________________________________________________________________________________ >>> TestPreserved.test_staged_from_preserved >>> _____________________________________________________________________________________ >>> >>> self = >> object at 0x7ffb94811350>, user = >>> >> 0x7ffb949e7190> >>> stageduser = >>> >> at 0x7ffb94811c50> >>> >>> def test_staged_from_preserved(self, user, stageduser): >>> user.make_preserved_user() >>> >>> stageduser.ensure_missing() >>> stageduser = StageUserTracker(user.uid, user.givenname, >>> user.sn) >>> stageduser.create_from_preserved(user) >>> > command = user.make_create_command(from_delete=True) >>> E TypeError: make_create_command() got an unexpected keyword >>> argument 'from_delete' >>> >>> test_xmlrpc/test_stageuser_plugin.py:718: TypeError >>> ---------------------------------------------------------------------------------------------- >>> Captured stdout setup >>> ---------------------------------------------------------------------------------------------- >>> Ran command: ipalib.plugins.stageuser.stageuser_del()(u'suser1', >>> version=u'2.148'): NotFound: suser1: stage user not found >>> ---------------------------------------------------------------------------------------------- >>> Captured stdout call >>> ----------------------------------------------------------------------------------------------- >>> Ran command: ipalib.plugins.user.user_add()(u'auser1', >>> givenname=u'active', sn=u'user', version=u'2.148'): OK >>> Ran command: ipalib.plugins.user.user_del()(u'auser1', >>> preserve=True, no_preserve=False, version=u'2.148'): OK >>> >>> Martin^2 >> > ACK > > I cannot apply your patch on top of ipa-4-2 branch, can you send > rebased version for ipa-4-2 branch? Attached. Applying works for me on ipa-4-2 branch, so I hope I finally got it right... Also this patch combines my previous patches 0002.3 + 0003. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0002.4-Automated-test-for-stageuser-plugin.patch Type: text/x-patch Size: 55828 bytes Desc: not available URL: From jcholast at redhat.com Mon Aug 24 10:30:04 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Aug 2015 12:30:04 +0200 Subject: [Freeipa-devel] [PATCH] 0196 trusts: format Kerberos principal properly when fetching trust topology In-Reply-To: <55DAD96A.9010601@redhat.com> References: <20150820122102.GR22106@redhat.com> <55DAD96A.9010601@redhat.com> Message-ID: <55DAF22C.9080004@redhat.com> On 24.8.2015 10:44, Tomas Babej wrote: > > > On 08/20/2015 02:21 PM, Alexander Bokovoy wrote: >> Hi, >> >> one more fix for the problem with trusts that Scott Poore found when >> verifying fixes to bug https://bugzilla.redhat.com/show_bug.cgi?id=1250190 >> >> Details are in the commit message. >> >> >> > > ACK, this fixes the issue in case of two-way trusts. > > $ echo Secret123456 | ipa trust-add --type=ad ad.test --range-type > ipa-ad-trust --admin Administrator --password --two-way=TRUE > ------------------------------------------------ > Added Active Directory trust for realm "ad.test" > ------------------------------------------------ > Realm name: ad.test > Domain NetBIOS name: AD > ... > Trust direction: Two-way trust > Trust type: Active Directory domain > Trust status: Established and verified > > $ ipa idrange-find > ---------------- > 3 ranges matched > ---------------- > Range name: AD.TEST_id_range > ... > Range type: Active Directory domain range > > Range name: IPA.TEST_id_range > ... > Range type: local domain range > > Range name: SUB.AD.TEST_id_range > ... > Range type: Active Directory domain range > ---------------------------- > Number of entries returned 3 > ---------------------------- > > Tomas > Pushed to: master: 1255dbf2fde068787d711c1fb60946a254d1782c ipa-4-2: e13a5ed26e96436d4a7ebb2329f7f9666581008d -- Jan Cholasta From ofayans at redhat.com Mon Aug 24 10:55:56 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 24 Aug 2015 12:55:56 +0200 Subject: [Freeipa-devel] [PATCH 0006] Fixed installation failures Message-ID: <55DAF83C.3030407@redhat.com> Hi all. The current issue [1] effectively blocks testing of 4.2 branch. Here is (one of the possible) solution, that proved to work. [1] https://www.redhat.com/archives/freeipa-devel/2015-August/msg00085.html -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0006-Fixed-installation-failure.patch Type: text/x-patch Size: 1151 bytes Desc: not available URL: From ofayans at redhat.com Mon Aug 24 11:28:22 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 24 Aug 2015 13:28:22 +0200 Subject: [Freeipa-devel] [PATCH] small fixes related to running dnssec tests in RHEL In-Reply-To: <55D6E6C6.7070807@redhat.com> References: <55D6E6C6.7070807@redhat.com> Message-ID: <55DAFFD6.5040904@redhat.com> Hi, Could anyone review this. We are really blocked with testing on RHEL and Patch 0005 fixes it. Thank you. On 08/21/2015 10:52 AM, Oleg Fayans wrote: > Hi list, > > Here are the the fixes for https://fedorahosted.org/freeipa/ticket/5240 > plus pep8-related fixes, plus created a user-friendly error message at > import error. > obsoletes my previous patch > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ldoudova at redhat.com Mon Aug 24 12:14:20 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 24 Aug 2015 14:14:20 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55DAEE91.40508@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> <55D5DAA7.5030309@redhat.com> <55DAEE91.40508@redhat.com> Message-ID: <55DB0A9C.5060509@redhat.com> ... and adding a patch version applicable for master branch Lenka On 08/24/2015 12:14 PM, Lenka Doudova wrote: > > > On 08/20/2015 03:48 PM, Martin Basti wrote: >> >> >> On 08/14/2015 06:32 PM, Lenka Doudova wrote: >>> Yes, that is "correct" - it's malfunctioning behavior of the plugin >>> - command 'stageuser-add --from-delete', which is discussed in >>> another thread. I left this test case for so long as it's not >>> fixed/changed. If the command remains and is fixed, the test case >>> will be valid, if it's changed I'll fix the test case to reflect the >>> new command. >>> >>> Lenka >>> >>> On 08/14/2015 05:39 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/14/2015 11:04 AM, Lenka Doudova wrote: >>>>>> NACK >>>>>> >>>>>> syntax error, missing ')' >>>>>> -from ipatests.util import assert_equal, assert_not_equal, raises >>>>>> +from ipatests.util import ( >>>>>> + assert_equal, assert_not_equal, raises, assert_deepequal >>>>>> >>>>>> I cannot apply this patch, please check it >>>>> >>>>> Sorry for the error, corrected patch attached. >>>>> I also added two testcases that Thierry proposed, and changed >>>>> names of few methods (original ones were confusing). >>>>> >>>>> Lenka >>>> I got this error >>>> >>>> ==================================================================================================== >>>> FAILURES >>>> ===================================================================================================== >>>> ____________________________________________________________________________________ >>>> TestPreserved.test_staged_from_preserved >>>> _____________________________________________________________________________________ >>>> >>>> self = >>> object at 0x7ffb94811350>, user = >>>> >>> 0x7ffb949e7190> >>>> stageduser = >>>> >>> at 0x7ffb94811c50> >>>> >>>> def test_staged_from_preserved(self, user, stageduser): >>>> user.make_preserved_user() >>>> >>>> stageduser.ensure_missing() >>>> stageduser = StageUserTracker(user.uid, user.givenname, >>>> user.sn) >>>> stageduser.create_from_preserved(user) >>>> > command = user.make_create_command(from_delete=True) >>>> E TypeError: make_create_command() got an unexpected keyword >>>> argument 'from_delete' >>>> >>>> test_xmlrpc/test_stageuser_plugin.py:718: TypeError >>>> ---------------------------------------------------------------------------------------------- >>>> Captured stdout setup >>>> ---------------------------------------------------------------------------------------------- >>>> Ran command: ipalib.plugins.stageuser.stageuser_del()(u'suser1', >>>> version=u'2.148'): NotFound: suser1: stage user not found >>>> ---------------------------------------------------------------------------------------------- >>>> Captured stdout call >>>> ----------------------------------------------------------------------------------------------- >>>> Ran command: ipalib.plugins.user.user_add()(u'auser1', >>>> givenname=u'active', sn=u'user', version=u'2.148'): OK >>>> Ran command: ipalib.plugins.user.user_del()(u'auser1', >>>> preserve=True, no_preserve=False, version=u'2.148'): OK >>>> >>>> Martin^2 >>> >> ACK >> >> I cannot apply your patch on top of ipa-4-2 branch, can you send >> rebased version for ipa-4-2 branch? > > Attached. Applying works for me on ipa-4-2 branch, so I hope I finally > got it right... > Also this patch combines my previous patches 0002.3 + 0003. > Lenka > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-lryznaro-0002.4-Automated-test-for-stageuser-plugin.patch Type: text/x-patch Size: 56023 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 24 12:36:01 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 14:36:01 +0200 Subject: [Freeipa-devel] [PATCH] small fixes related to running dnssec tests in RHEL In-Reply-To: <55DAFFD6.5040904@redhat.com> References: <55D6E6C6.7070807@redhat.com> <55DAFFD6.5040904@redhat.com> Message-ID: <55DB0FB1.6060905@redhat.com> On 08/24/2015 01:28 PM, Oleg Fayans wrote: > Hi, > > Could anyone review this. We are really blocked with testing on RHEL > and Patch 0005 fixes it. Thank you. > > On 08/21/2015 10:52 AM, Oleg Fayans wrote: >> Hi list, >> >> Here are the the fixes for https://fedorahosted.org/freeipa/ticket/5240 >> plus pep8-related fixes, plus created a user-friendly error message at >> import error. >> obsoletes my previous patch >> >> >> > PATCH 0003 ACK PATCH 0004 I don't know I dont think that this change is needed, we enforce pep8 only for new code, those kind of random changes make git blame hard to read. PATCH 0005 NACK If this is workaround for DNSSEC, it should be done only for DNSSEC test not globally for all tests. From jcholast at redhat.com Mon Aug 24 12:50:01 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 24 Aug 2015 14:50:01 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DA3ACF.9010504@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> Message-ID: <55DB12F9.30209@redhat.com> On 23.8.2015 23:27, Michael ?im??ek wrote: > > > On 2015-08-21 15:52, Michael ?im??ek wrote: >> >> >> On 2015-08-20 20:42, Robbie Harwood wrote: >>> Michael ?im??ek writes: >>> >>>> On 2015-08-20 12:32, Michael ?im??ek wrote: >>>> >>>>>>>> Michael ?im??ek writes: >>>>>>>> >>>>>>>>> Attaching new revision of the patch. Changes from the previous: >>>>>>>>> - ldap2's connect now chooses the bind type same way as in ipaldap >>>>>>>>> - get_default_realm usages replaced by api.env.realm >>>>>>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>>>>>> - updated some parts of exception handling >>>>> >>>>> Rebased on top of current master. >>>> >>>> One of the commits reintroduced krbV dependency that I didn't notice. >>>> Attaching updated revision. Only changes against previous revision are >>>> in files daemons/dnssec/ipa-dnskeysync-replica and >>>> daemons/dnssec/ipa-ods-exporter. >>> >>> This is much better, thanks! I've got some comments inline. >>> >>>> +except gssapi.exceptions.GSSError: >>>> # If there was failure on using keytab, assume it is stale and >>>> retrieve again >>>> retrieve_keytab(api, ccache_name, oneway_keytab_name, >>>> oneway_principal) >>> >>> This code still bothers me a bit, but I think fixing it is probably >>> beyond the scope of a python-gssapi port. >> >> The code catches all GSSAPI exceptions and retries to do the same thing >> with different keytab. So if there was a problem unrelated to keytab, >> the same exception will be raised again. Nothing will be ignored >> silently. >> >>> >>>> + try: >>>> + creds = get_credentials(name=name, ccache_name=ccache_name) >>>> + # property access would raise exception if expired >>>> + if creds.lifetime > 0: >>>> + return creds >>>> + except gssapi.exceptions.ExpiredCredentialsError: >>>> + return None >>> >>> Per rfc2744, lifetime is unsigned. It's not immediately clear what will >>> happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in >>> that case? >> >> I think the check is probably redundant, gssapi raises exception upon >> inquiring expired credentials. In trust-fetch-domains I just access the >> lifetime in try-except without using the value, so I could do the same >> here. It would be nice if gssapi provided some 'is_valid' or >> 'is_expired' method, so I wouldn't need to rely on side-effects of >> property access, which is hard to read and confuses pylint. >> >>> >>>> # Setup LDAP connection >>>> try: >>>> - ctx = krbV.default_context() >>>> - ccache = ctx.default_ccache() >>>> - api.Backend.ldap2.connect(ccache) >>>> + api.Backend.ldap2.connect() >>>> cls.ldap = api.Backend.ldap2 >>>> - except krbV.Krb5Error as e: >>>> + except gssapi.exceptions.GSSError: >>>> sys.exit("Must have Kerberos credentials to migrate >>>> Winsync users.") >>> >>> Can you log the error here? The other places GSSError is being caught >>> are doing a great job of either filtering-and-raising or >>> logging-and-exiting, so thanks for fixing those. >> >> Yes, I'll update it in next revision of the patch. >> >>> >>>> +# Ugly hack for test purposes only. GSSAPI has no way to get default >>>> ccache >>>> +# name, but we don't need it outside test server >>>> +def get_default_ccache_name(): >>>> + try: >>>> + out = check_output(['klist']) >>>> + except CalledProcessError: >>>> + raise RuntimeError("Default ccache not found. Did you kinit?") >>>> + match = re.match(r'^Ticket cache:\s*(\S+)', out) >>>> + if not match: >>>> + raise RuntimeError("Cannot obtain ccache name") >>>> + return match.group(1) >>> >>> Yup, this is still ugly. Ah well, it's only test code. >>> >> >> I was trying to modify the code to not need the variable and just use >> the default, but it is used for manipulating it as a file - in >> production it is always defined by mod_auth_gssapi. So I'd keep this >> as is. >> > > > Next revision of the patch. Changes from previous rev: printing > exception in ipa_winsync_migrate and more thorough dealing with > credentials expiration in krb_utils and trust-fetch-domains. 1) There is a merge conflict in freeipa.spec.in, please rebase the patch on top of current master. 2) pylint fails with: ************* Module ipa-ods-exporter daemons/dnssec/ipa-ods-exporter:23: [E0611(no-name-in-module), ] No name 'GSSError' in module 'gssapi') ************* Module ipa-dnskeysync-replica daemons/dnssec/ipa-dnskeysync-replica:15: [E0611(no-name-in-module), ] No name 'GSSError' in module 'gssapi') Both failures are caused by "from gssapi import GSSError" statement, which should read "from gssapi.exceptions import GSSError". 3) ipa-adtrust-install fails with: admin password: Unrecognized error during check of admin rights: admin at abc.idm.lab.eng.brq.redhat.com: user not found Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" call where a "user-show admin" call should be. 4) ipa-client-automount fails with: Failed to obtain host TGT: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639111): Bad format in credentials cache Honza -- Jan Cholasta From ofayans at redhat.com Mon Aug 24 13:08:57 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 24 Aug 2015 15:08:57 +0200 Subject: [Freeipa-devel] [PATCH] small fixes related to running dnssec tests in RHEL In-Reply-To: <55DB0FB1.6060905@redhat.com> References: <55D6E6C6.7070807@redhat.com> <55DAFFD6.5040904@redhat.com> <55DB0FB1.6060905@redhat.com> Message-ID: <55DB1769.5080404@redhat.com> Hi Martin, On 08/24/2015 02:36 PM, Martin Basti wrote: > > > On 08/24/2015 01:28 PM, Oleg Fayans wrote: >> Hi, >> >> Could anyone review this. We are really blocked with testing on RHEL >> and Patch 0005 fixes it. Thank you. >> >> On 08/21/2015 10:52 AM, Oleg Fayans wrote: >>> Hi list, >>> >>> Here are the the fixes for https://fedorahosted.org/freeipa/ticket/5240 >>> plus pep8-related fixes, plus created a user-friendly error message at >>> import error. >>> obsoletes my previous patch >>> >>> >>> >> > > > PATCH 0003 > ACK > > PATCH 0004 > I don't know > I dont think that this change is needed, we enforce pep8 only for new > code, those kind of random changes make git blame hard to read. > > PATCH 0005 > NACK > > If this is workaround for DNSSEC, it should be done only for DNSSEC test > not globally for all tests. It's not only about dnssec: all integration tests are broken in RHEL due to the fact that ipa-replica-prepare behaves differently in RHEL than in Fedora, which causes the tests (desined on fedora) to fail at the step of replica installation. Once we find out the reason of this, we can revert this change, but for now we really, REALLY need a quick fix to move on. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbasti at redhat.com Mon Aug 24 13:14:18 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 15:14:18 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55DB0A9C.5060509@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> <55D5DAA7.5030309@redhat.com> <55DAEE91.40508@redhat.com> <55DB0A9C.5060509@redhat.com> Message-ID: <55DB18AA.9040406@redhat.com> NACK You have unmerged changes in the patch On 08/24/2015 02:14 PM, Lenka Doudova wrote: > from ipatests.test_xmlrpc import objectclasses > +<<<<<<< HEAD > from ipatests.test_xmlrpc.xmlrpc_test import ( > Declarative, fuzzy_digits, fuzzy_uuid, fuzzy_set_ci, add_sid, add_oc) > +======= > +from xmlrpc_test import (Declarative, fuzzy_digits, fuzzy_uuid, fuzzy_set_ci, > + add_sid, add_oc, XMLRPC_test, raises_exact) > +>>>>>>> Automated test for stageuser plugin > from ipapython.dn import DN From mbasti at redhat.com Mon Aug 24 13:38:30 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 15:38:30 +0200 Subject: [Freeipa-devel] [PATCH 0300] DNSSEC: fix forwardzone forwarders check Message-ID: <55DB1E56.7000307@redhat.com> https://fedorahosted.org/freeipa/ticket/5179 patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0300-DNSSEC-fix-forward-zone-forwarders-checks.patch Type: text/x-patch Size: 2011 bytes Desc: not available URL: From ldoudova at redhat.com Mon Aug 24 14:07:08 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Mon, 24 Aug 2015 16:07:08 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55DB18AA.9040406@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> <55D5DAA7.5030309@redhat.com> <55DAEE91.40508@redhat.com> <55DB0A9C.5060509@redhat.com> <55DB18AA.9040406@redhat.com> Message-ID: <55DB250C.6090606@redhat.com> Attached. Lenka On 08/24/2015 03:14 PM, Martin Basti wrote: > NACK > > You have unmerged changes in the patch > > On 08/24/2015 02:14 PM, Lenka Doudova wrote: >> from ipatests.test_xmlrpc import objectclasses >> +<<<<<<< HEAD >> from ipatests.test_xmlrpc.xmlrpc_test import ( >> Declarative, fuzzy_digits, fuzzy_uuid, fuzzy_set_ci, add_sid, >> add_oc) >> +======= >> +from xmlrpc_test import (Declarative, fuzzy_digits, fuzzy_uuid, >> fuzzy_set_ci, >> + add_sid, add_oc, XMLRPC_test, raises_exact) >> +>>>>>>> Automated test for stageuser plugin >> from ipapython.dn import DN > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-lryznaro-0002.4-Automated-test-for-stageuser-plugin.patch Type: text/x-patch Size: 55815 bytes Desc: not available URL: From mbasti at redhat.com Mon Aug 24 14:30:48 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 16:30:48 +0200 Subject: [Freeipa-devel] [PATCH] small fixes related to running dnssec tests in RHEL In-Reply-To: <55DB1769.5080404@redhat.com> References: <55D6E6C6.7070807@redhat.com> <55DAFFD6.5040904@redhat.com> <55DB0FB1.6060905@redhat.com> <55DB1769.5080404@redhat.com> Message-ID: <55DB2A98.6070609@redhat.com> On 08/24/2015 03:08 PM, Oleg Fayans wrote: > Hi Martin, > > On 08/24/2015 02:36 PM, Martin Basti wrote: >> >> >> On 08/24/2015 01:28 PM, Oleg Fayans wrote: >>> Hi, >>> >>> Could anyone review this. We are really blocked with testing on RHEL >>> and Patch 0005 fixes it. Thank you. >>> >>> On 08/21/2015 10:52 AM, Oleg Fayans wrote: >>>> Hi list, >>>> >>>> Here are the the fixes for >>>> https://fedorahosted.org/freeipa/ticket/5240 >>>> plus pep8-related fixes, plus created a user-friendly error message at >>>> import error. >>>> obsoletes my previous patch >>>> >>>> >>>> >>> >> >> >> PATCH 0003 >> ACK >> >> PATCH 0004 >> I don't know >> I dont think that this change is needed, we enforce pep8 only for new >> code, those kind of random changes make git blame hard to read. >> >> PATCH 0005 >> NACK >> >> If this is workaround for DNSSEC, it should be done only for DNSSEC test >> not globally for all tests. > > It's not only about dnssec: all integration tests are broken in RHEL > due to the fact that ipa-replica-prepare behaves differently in RHEL > than in Fedora, which causes the tests (desined on fedora) to fail at > the step of replica installation. Once we find out the reason of this, > we can revert this change, but for now we really, REALLY need a quick > fix to move on. > > IMO it is caused by different environment where tests are running, the particular code is same for RHEL and fedora. I will push it to unblock testing. From mbasti at redhat.com Mon Aug 24 14:32:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 16:32:47 +0200 Subject: [Freeipa-devel] [PATCH] small fixes related to running dnssec tests in RHEL In-Reply-To: <55DB0FB1.6060905@redhat.com> References: <55D6E6C6.7070807@redhat.com> <55DAFFD6.5040904@redhat.com> <55DB0FB1.6060905@redhat.com> Message-ID: <55DB2B0F.2090403@redhat.com> On 08/24/2015 02:36 PM, Martin Basti wrote: > > > On 08/24/2015 01:28 PM, Oleg Fayans wrote: >> Hi, >> >> Could anyone review this. We are really blocked with testing on RHEL >> and Patch 0005 fixes it. Thank you. >> >> On 08/21/2015 10:52 AM, Oleg Fayans wrote: >>> Hi list, >>> >>> Here are the the fixes for https://fedorahosted.org/freeipa/ticket/5240 >>> plus pep8-related fixes, plus created a user-friendly error message at >>> import error. >>> obsoletes my previous patch >>> >>> >>> >> > > > PATCH 0003 > ACK > > PATCH 0004 > I don't know > I dont think that this change is needed, we enforce pep8 only for new > code, those kind of random changes make git blame hard to read. > > PATCH 0005 > NACK > > If this is workaround for DNSSEC, it should be done only for DNSSEC > test not globally for all tests. > 0003: Pushed to: master: b93137c1964690cc6c20ad5e187aa70cc414554c ipa-4-2: 74c0bcce237faaba700ade6377753783d6a2a9bf 0005: Pushed to: master: b202afbcc0fe8cd1291784a3d261fce59b5646fd ipa-4-2: aa381746610bb280a906f6d73edd20877da1877d From mbasti at redhat.com Mon Aug 24 14:35:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 16:35:47 +0200 Subject: [Freeipa-devel] [PATCH 0006] Fixed installation failures In-Reply-To: <55DAF83C.3030407@redhat.com> References: <55DAF83C.3030407@redhat.com> Message-ID: <55DB2BC3.5000201@redhat.com> On 08/24/2015 12:55 PM, Oleg Fayans wrote: > Hi all. The current issue [1] effectively blocks testing of 4.2 > branch. Here is (one of the possible) solution, that proved to work. > > [1] > https://www.redhat.com/archives/freeipa-devel/2015-August/msg00085.html > > > The patch needs rebase for ipa-4-2 branch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Aug 24 14:51:31 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 16:51:31 +0200 Subject: [Freeipa-devel] [PATCH 0058] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55D58FBA.6070105@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> Message-ID: <55DB2F73.6050608@redhat.com> On 08/20/2015 10:28 AM, David Kupka wrote: > On 31/07/15 13:32, Martin Basti wrote: >> On 30/07/15 14:38, Martin Basti wrote: >>> On 29/07/15 16:12, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/5087 >>> NACK >>> >>> You forgot to update API.txt file > > Thanks for catching that. Updated patch attached. > >>> >> I'm just curious, what is the reason to check if forward zone exists? >> >> IMO forwardzone must exists somewhere as the master zone. I don't think >> we should check forwardzones, this may give too many false positive >> errors. > > AIUI if the zone exist somewhere and is resolvable there is no need to > add it as a forward zone. If user for some reason want to do it he's > hiding the original zone and we should not allow this (without --force). > Note: Petr2 agreed with David's solution LGTM, works as expected, but this patch prevents users to add conflicting zones via webUI (there is no --force field). We should improve webUI together with this patch. Martin^2 >> >> Martin^2 >> > From mbasti at redhat.com Mon Aug 24 14:59:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 24 Aug 2015 16:59:25 +0200 Subject: [Freeipa-devel] [PATCH 020] Change internal rsa_(public|private)_key variable names In-Reply-To: <1438093681.18261.12.camel@willson.usersys.redhat.com> References: <55B78F50.6070303@redhat.com> <1438093681.18261.12.camel@willson.usersys.redhat.com> Message-ID: <55DB314D.7010201@redhat.com> On 07/28/2015 04:28 PM, Simo Sorce wrote: > On Tue, 2015-07-28 at 16:18 +0200, Christian Heimes wrote: >> In two places the vault plugin refers to rsa public or rsa private key >> although the code can handle just any kind of asymmetric algorithms, >> e.g. ECDSA. The patch just renames the occurences to avoid more >> confusion in the future. > LGTM. > Simo. > ACK Pushed to: master: cee5d9007e7db84f24bc8e387ec7ff784495ab9f ipa-4-2: 5f557686ffbbfd738e9d4f440a91a68fd421bad6 From msimacek at redhat.com Mon Aug 24 15:18:30 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Mon, 24 Aug 2015 17:18:30 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DB12F9.30209@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> Message-ID: <55DB35C6.4000503@redhat.com> On 2015-08-24 14:50, Jan Cholasta wrote: > On 23.8.2015 23:27, Michael ?im??ek wrote: >> >> >> On 2015-08-21 15:52, Michael ?im??ek wrote: >>> >>> >>> On 2015-08-20 20:42, Robbie Harwood wrote: >>>> Michael ?im??ek writes: >>>> >>>>> On 2015-08-20 12:32, Michael ?im??ek wrote: >>>>> >>>>>>>>> Michael ?im??ek writes: >>>>>>>>> >>>>>>>>>> Attaching new revision of the patch. Changes from the previous: >>>>>>>>>> - ldap2's connect now chooses the bind type same way as in >>>>>>>>>> ipaldap >>>>>>>>>> - get_default_realm usages replaced by api.env.realm >>>>>>>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>>>>>>> - updated some parts of exception handling >>>>>> >>>>>> Rebased on top of current master. >>>>> >>>>> One of the commits reintroduced krbV dependency that I didn't notice. >>>>> Attaching updated revision. Only changes against previous revision are >>>>> in files daemons/dnssec/ipa-dnskeysync-replica and >>>>> daemons/dnssec/ipa-ods-exporter. >>>> >>>> This is much better, thanks! I've got some comments inline. >>>> >>>>> +except gssapi.exceptions.GSSError: >>>>> # If there was failure on using keytab, assume it is stale and >>>>> retrieve again >>>>> retrieve_keytab(api, ccache_name, oneway_keytab_name, >>>>> oneway_principal) >>>> >>>> This code still bothers me a bit, but I think fixing it is probably >>>> beyond the scope of a python-gssapi port. >>> >>> The code catches all GSSAPI exceptions and retries to do the same thing >>> with different keytab. So if there was a problem unrelated to keytab, >>> the same exception will be raised again. Nothing will be ignored >>> silently. >>> >>>> >>>>> + try: >>>>> + creds = get_credentials(name=name, ccache_name=ccache_name) >>>>> + # property access would raise exception if expired >>>>> + if creds.lifetime > 0: >>>>> + return creds >>>>> + except gssapi.exceptions.ExpiredCredentialsError: >>>>> + return None >>>> >>>> Per rfc2744, lifetime is unsigned. It's not immediately clear what >>>> will >>>> happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in >>>> that case? >>> >>> I think the check is probably redundant, gssapi raises exception upon >>> inquiring expired credentials. In trust-fetch-domains I just access the >>> lifetime in try-except without using the value, so I could do the same >>> here. It would be nice if gssapi provided some 'is_valid' or >>> 'is_expired' method, so I wouldn't need to rely on side-effects of >>> property access, which is hard to read and confuses pylint. >>> >>>> >>>>> # Setup LDAP connection >>>>> try: >>>>> - ctx = krbV.default_context() >>>>> - ccache = ctx.default_ccache() >>>>> - api.Backend.ldap2.connect(ccache) >>>>> + api.Backend.ldap2.connect() >>>>> cls.ldap = api.Backend.ldap2 >>>>> - except krbV.Krb5Error as e: >>>>> + except gssapi.exceptions.GSSError: >>>>> sys.exit("Must have Kerberos credentials to migrate >>>>> Winsync users.") >>>> >>>> Can you log the error here? The other places GSSError is being caught >>>> are doing a great job of either filtering-and-raising or >>>> logging-and-exiting, so thanks for fixing those. >>> >>> Yes, I'll update it in next revision of the patch. >>> >>>> >>>>> +# Ugly hack for test purposes only. GSSAPI has no way to get default >>>>> ccache >>>>> +# name, but we don't need it outside test server >>>>> +def get_default_ccache_name(): >>>>> + try: >>>>> + out = check_output(['klist']) >>>>> + except CalledProcessError: >>>>> + raise RuntimeError("Default ccache not found. Did you >>>>> kinit?") >>>>> + match = re.match(r'^Ticket cache:\s*(\S+)', out) >>>>> + if not match: >>>>> + raise RuntimeError("Cannot obtain ccache name") >>>>> + return match.group(1) >>>> >>>> Yup, this is still ugly. Ah well, it's only test code. >>>> >>> >>> I was trying to modify the code to not need the variable and just use >>> the default, but it is used for manipulating it as a file - in >>> production it is always defined by mod_auth_gssapi. So I'd keep this >>> as is. >>> >> >> >> Next revision of the patch. Changes from previous rev: printing >> exception in ipa_winsync_migrate and more thorough dealing with >> credentials expiration in krb_utils and trust-fetch-domains. > > 1) There is a merge conflict in freeipa.spec.in, please rebase the patch > on top of current master. > Done. > > 2) pylint fails with: > > ************* Module ipa-ods-exporter > daemons/dnssec/ipa-ods-exporter:23: [E0611(no-name-in-module), ] No name > 'GSSError' in module 'gssapi') > ************* Module ipa-dnskeysync-replica > daemons/dnssec/ipa-dnskeysync-replica:15: [E0611(no-name-in-module), ] > No name 'GSSError' in module 'gssapi') > > Both failures are caused by "from gssapi import GSSError" statement, > which should read "from gssapi.exceptions import GSSError". > Fixed. > > 3) ipa-adtrust-install fails with: > > admin password: > > Unrecognized error during check of admin rights: > admin at abc.idm.lab.eng.brq.redhat.com: user not found > > Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" > call where a "user-show admin" call should be. > Fixed. python-gssapi has a display_as method that could pull the name from it, but it doesn't work in current version, therefore using partition to split on '@' > > 4) ipa-client-automount fails with: > > Failed to obtain host TGT: Major (851968): Unspecified GSS failure. > Minor code may provide more information, Minor (2529639111): Bad format > in credentials cache > gssapi apparently refuses to accept empty file as ccache. In order to not create a race condition / security hole by deleting and recreating the temp file, I changed it to use per-process kernel keyring (I believe non-persistent keyring should be available on all supported platforms). Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-8-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 73861 bytes Desc: not available URL: From pviktori at redhat.com Mon Aug 24 15:31:08 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 24 Aug 2015 17:31:08 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DABE3E.6070305@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> Message-ID: <55DB38BC.50907@redhat.com> On 08/24/2015 08:48 AM, Jan Cholasta wrote: > On 24.8.2015 07:50, Jan Cholasta wrote: >> On 21.8.2015 14:50, Christian Heimes wrote: >>> On 2015-08-21 12:55, Petr Viktorin wrote: >>>> On 08/14/2015 07:44 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> These patches bring IPA another step towards compatibility with >>>>> Python 3. >>>>> >>>>> Most of these were made by fixers from the "python-modernize" tool, >>>>> but >>>>> I reviewed and edited the results. >>>> >>>> Here are the patches rebased to current master. >>> >>> 0696.2-Remove-use-of-sys.exc_value >>> ACK >>> >>> >>> 0697.2-Don-t-use-a-tuple-in-function-arguments >>> I prefer operator.itemgetter() over the hard-to-read lambda expression >>> key=lambda k_v: (k_v[1], k_v[0]). >>>>>> import operator >>>>>> example = dict(a=3, ba=2, b=2, c=1) >>>>>> sorted(example.items(), key=operator.itemgetter(1, 0)) >>> [('c', 1), ('b', 2), ('ba', 2), ('a', 3)] Sure. >>> >>> >>> 0698.2-Add-python-six-to-dependencies >>> ACK >>> >>> >>> 0699.2-Remove-the-unused-pygettext-script >>> ACK >>> >>> >>> 0700.2-Use-six.string_types-instead-of-basestring >>> LGTM, but I need to have a closer look at some places. >>> I noticed a couple of asserts that should be "if ... raise ValueError" >>> instead. python -o disables asserts. > > It seems you missed a few "basestring"s in ipapython/dn.py. Oops. Added. >>> 0701.2-Use-Python3-compatible-dict-method-names >>> NACK >>> Why are you replacing iteritems() with items() instead of using >>> six.iteritems()? It looks cleaner, and it will be easier to clean up after six is dropped. Also, the performance difference is negligible if the whole thing is iterated over. (On small dicts, which are the majority of what iteritems was used on, items() is actually a bit faster on my machine.) >>> Please use sorted(reference) instead of sorted(reference.keys()), >>> set(tree) instead of set(tree.keys()) and list(somedict) instead of >>> list(somedict.keys()), too. The keys() call is unnecessary and frowned >>> upon. I wouldn't always frown upon it; sometimes making it clear that you're operating on a dict makes the code more readable. But, I've made the changes. >>> 0702.2-Replace-filter-calls-with-list-comprehensions >>> In Python 2 list comprehensions leak the internal loop variable. It >>> might be better to write a generator expression with list() instead of >>> [] list comprehension. Well, that just is (and always has been) something to watch out for in Python 2. I don't think it's a good reason for more verbose syntax. >>> 0703.2-Use-six.moves.input-instead-of-raw_input >>> ACK >>> The code is fine, but pylint won't like it. For Dogtag I had to disable >>> pylint warnings W0622 and F0401. Hm. For some reason, make-lint works fine on this code (f21, pylint 1.3.1). It fails on gssapi, but in code these patches don't touch. It may be a problem with my setup, let me know if it is. >>> 0704.2-Use-six.integer_types-instead-of-long-int >>> ACK >>> hint: For type checks you can also use the numbers module. > > There are still some "(int, long)"s in ipalib/parameters.py, > ipalib/rpc.py, ipalib/util.py, ipapython/cookie.py, ipapython/dn.py and > ipapython/ipaldap.py Changed, thanks. > Also, there are bare "long"s in ipapython/install/cli.py, > ipaserver/dcerpc.py, ipaserver/install/ipa_otptoken_import.py and > ipatests/test_ipalib/test_parameters.py. Right, but that's for another patch. >>> 0705.2-Replace-uses-of-map >>> See comment for 0702 > > It seems you missed a few "map()"s in ipalib/plugins/certprofile.py, > ipalib/plugins/dns.py, ipalib/plugins/sudorule.py and > ipatests/test_xmlrpc/test_add_remove_cert_cmd.py. Thanks, added. >>> 706.2-Use-next-function-on-iterators >>> ACK >> >> These are generator objects in ipapython/install/core.py. I'm not sure >> what the usual convention is, That depends on whether you want to "get the next item" or "send None to the generator". I think in this case it's the former. >> but I would think that the gen.next() >> calls should be replaced with gen.send(None) instead of next(gen), so >> that the generators are accessed consistently using methods >> (gen.send()/gen.throw()/gen.close()). I don't see any send() calls except one used to implement "yield from" itself. How often do you see send/throw/close used? >>> 0707.2-Use-the-print-function >>> LGTM >>> There are too many chances to review. Let's hope the automatic >>> conversion tool did its job correctly. > > I see some print statements in ipapython/dn.py. Right, changed >>> 0708.2-Use-new-style-raise-syntax >>> ACK >>> >>> >>> 0709.2-Use-six.reraise >>> ACK >> >> Instead of calling six.reraise from raise_exc_info, could you replace >> the two occurences of raise_exc_info(exc_info) with >> six.reraise(*exc_info) and remove raise_exc_info? Right. >>> 0710.2-Modernize-use-of-range >>> NACK >>> Please use six.moves.range. It defaults to xrange() in Python 2. Why? What is the benefit of xrange in these situations? Like with iteritems in 0701, when iterating over the whole thing, the performance difference is negligible. I don't think a few microseconds outside of tight loops are worth the verbosity. >>> I also >>> see a couple of additional opportunities for enumerate(): >>> >>> for i in range(len(kw['attrs'])): >>> kw['attrs'][i] = unicode(kw['attrs'][i]) >>> >>> for i, s in enumerate(kw['attrs']): >>> kw['attrs'][i] = unicode(s) That one can be cleaned up a lot more: - kw['attrs'] = list(a.target['targetattr']['expression']) - for i in range(len(kw['attrs'])): - kw['attrs'][i] = unicode(kw['attrs'][i]) - kw['attrs'] = tuple(kw['attrs']) + kw['attrs'] = [unicode(a) + for a in a.target['targetattr']['expression']] It wasn't the point of this patch, but I've made the change. >>> 0711.2-Convert-zip-result-to-list >>> ACK >>> The code isn't beautiful but it's just a test. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0696.3-Remove-use-of-sys.exc_value.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0697.3-Don-t-use-a-tuple-in-function-arguments.patch Type: text/x-patch Size: 907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0698.3-Add-python-six-to-dependencies.patch Type: text/x-patch Size: 984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0699.3-Remove-the-unused-pygettext-script.patch Type: text/x-patch Size: 30062 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0700.3-Use-six.string_types-instead-of-basestring.patch Type: text/x-patch Size: 35447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0701.3-Use-Python3-compatible-dict-method-names.patch Type: text/x-patch Size: 73506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0702.3-Replace-filter-calls-with-list-comprehensions.patch Type: text/x-patch Size: 6514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0703.3-Use-six.moves.input-instead-of-raw_input.patch Type: text/x-patch Size: 3100 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0704.3-Use-six.integer_types-instead-of-long-int.patch Type: text/x-patch Size: 8301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0705.3-Replace-uses-of-map.patch Type: text/x-patch Size: 18739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0706.3-Use-next-function-on-iterators.patch Type: text/x-patch Size: 3481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0707.3-Use-the-print-function.patch Type: text/x-patch Size: 229327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0708.3-Use-new-style-raise-syntax.patch Type: text/x-patch Size: 6956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0709.3-Use-six.reraise.patch Type: text/x-patch Size: 1892 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0710.3-Modernize-use-of-range.patch Type: text/x-patch Size: 18006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0711.3-Convert-zip-result-to-list.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: From simo at redhat.com Mon Aug 24 15:49:28 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 24 Aug 2015 11:49:28 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DB35C6.4000503@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> Message-ID: <1440431368.3305.19.camel@willson.usersys.redhat.com> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: > On 2015-08-24 14:50, Jan Cholasta wrote: > > On 23.8.2015 23:27, Michael ?im??ek wrote: > >> > >> > >> On 2015-08-21 15:52, Michael ?im??ek wrote: > >>> > >>> > >>> On 2015-08-20 20:42, Robbie Harwood wrote: > >>>> Michael ?im??ek writes: > >>>> > >>>>> On 2015-08-20 12:32, Michael ?im??ek wrote: > >>>>> > >>>>>>>>> Michael ?im??ek writes: > >>>>>>>>> > >>>>>>>>>> Attaching new revision of the patch. Changes from the previous: > >>>>>>>>>> - ldap2's connect now chooses the bind type same way as in > >>>>>>>>>> ipaldap > >>>>>>>>>> - get_default_realm usages replaced by api.env.realm > >>>>>>>>>> - fixed missing third kinit attempt in trust-fetch-domains > >>>>>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils > >>>>>>>>>> - updated some parts of exception handling > >>>>>> > >>>>>> Rebased on top of current master. > >>>>> > >>>>> One of the commits reintroduced krbV dependency that I didn't notice. > >>>>> Attaching updated revision. Only changes against previous revision are > >>>>> in files daemons/dnssec/ipa-dnskeysync-replica and > >>>>> daemons/dnssec/ipa-ods-exporter. > >>>> > >>>> This is much better, thanks! I've got some comments inline. > >>>> > >>>>> +except gssapi.exceptions.GSSError: > >>>>> # If there was failure on using keytab, assume it is stale and > >>>>> retrieve again > >>>>> retrieve_keytab(api, ccache_name, oneway_keytab_name, > >>>>> oneway_principal) > >>>> > >>>> This code still bothers me a bit, but I think fixing it is probably > >>>> beyond the scope of a python-gssapi port. > >>> > >>> The code catches all GSSAPI exceptions and retries to do the same thing > >>> with different keytab. So if there was a problem unrelated to keytab, > >>> the same exception will be raised again. Nothing will be ignored > >>> silently. > >>> > >>>> > >>>>> + try: > >>>>> + creds = get_credentials(name=name, ccache_name=ccache_name) > >>>>> + # property access would raise exception if expired > >>>>> + if creds.lifetime > 0: > >>>>> + return creds > >>>>> + except gssapi.exceptions.ExpiredCredentialsError: > >>>>> + return None > >>>> > >>>> Per rfc2744, lifetime is unsigned. It's not immediately clear what > >>>> will > >>>> happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in > >>>> that case? > >>> > >>> I think the check is probably redundant, gssapi raises exception upon > >>> inquiring expired credentials. In trust-fetch-domains I just access the > >>> lifetime in try-except without using the value, so I could do the same > >>> here. It would be nice if gssapi provided some 'is_valid' or > >>> 'is_expired' method, so I wouldn't need to rely on side-effects of > >>> property access, which is hard to read and confuses pylint. > >>> > >>>> > >>>>> # Setup LDAP connection > >>>>> try: > >>>>> - ctx = krbV.default_context() > >>>>> - ccache = ctx.default_ccache() > >>>>> - api.Backend.ldap2.connect(ccache) > >>>>> + api.Backend.ldap2.connect() > >>>>> cls.ldap = api.Backend.ldap2 > >>>>> - except krbV.Krb5Error as e: > >>>>> + except gssapi.exceptions.GSSError: > >>>>> sys.exit("Must have Kerberos credentials to migrate > >>>>> Winsync users.") > >>>> > >>>> Can you log the error here? The other places GSSError is being caught > >>>> are doing a great job of either filtering-and-raising or > >>>> logging-and-exiting, so thanks for fixing those. > >>> > >>> Yes, I'll update it in next revision of the patch. > >>> > >>>> > >>>>> +# Ugly hack for test purposes only. GSSAPI has no way to get default > >>>>> ccache > >>>>> +# name, but we don't need it outside test server > >>>>> +def get_default_ccache_name(): > >>>>> + try: > >>>>> + out = check_output(['klist']) > >>>>> + except CalledProcessError: > >>>>> + raise RuntimeError("Default ccache not found. Did you > >>>>> kinit?") > >>>>> + match = re.match(r'^Ticket cache:\s*(\S+)', out) > >>>>> + if not match: > >>>>> + raise RuntimeError("Cannot obtain ccache name") > >>>>> + return match.group(1) > >>>> > >>>> Yup, this is still ugly. Ah well, it's only test code. > >>>> > >>> > >>> I was trying to modify the code to not need the variable and just use > >>> the default, but it is used for manipulating it as a file - in > >>> production it is always defined by mod_auth_gssapi. So I'd keep this > >>> as is. > >>> > >> > >> > >> Next revision of the patch. Changes from previous rev: printing > >> exception in ipa_winsync_migrate and more thorough dealing with > >> credentials expiration in krb_utils and trust-fetch-domains. > > > > 1) There is a merge conflict in freeipa.spec.in, please rebase the patch > > on top of current master. > > > > Done. > > > > > 2) pylint fails with: > > > > ************* Module ipa-ods-exporter > > daemons/dnssec/ipa-ods-exporter:23: [E0611(no-name-in-module), ] No name > > 'GSSError' in module 'gssapi') > > ************* Module ipa-dnskeysync-replica > > daemons/dnssec/ipa-dnskeysync-replica:15: [E0611(no-name-in-module), ] > > No name 'GSSError' in module 'gssapi') > > > > Both failures are caused by "from gssapi import GSSError" statement, > > which should read "from gssapi.exceptions import GSSError". > > > > Fixed. > > > > > 3) ipa-adtrust-install fails with: > > > > admin password: > > > > Unrecognized error during check of admin rights: > > admin at abc.idm.lab.eng.brq.redhat.com: user not found > > > > Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" > > call where a "user-show admin" call should be. > > > > Fixed. python-gssapi has a display_as method that could pull the name > from it, but it doesn't work in current version, therefore using > partition to split on '@' > > > > > 4) ipa-client-automount fails with: > > > > Failed to obtain host TGT: Major (851968): Unspecified GSS failure. > > Minor code may provide more information, Minor (2529639111): Bad format > > in credentials cache > > > > gssapi apparently refuses to accept empty file as ccache. In order to > not create a race condition / security hole by deleting and recreating > the temp file, I changed it to use per-process kernel keyring (I believe > non-persistent keyring should be available on all supported platforms). Ypu can create a temp directory in tmp where only the user has access to, then you can have a file within it. This way you can still use a file w/o having to create it, w/o race condition, but with compatibility to file ccaches in case the kernel/krb5 libs are not built with keyring support. Simo. -- Simo Sorce * Red Hat, Inc * New York From msimacek at redhat.com Mon Aug 24 16:23:22 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Mon, 24 Aug 2015 18:23:22 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <1440431368.3305.19.camel@willson.usersys.redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> Message-ID: <55DB44FA.2030402@redhat.com> On 2015-08-24 17:49, Simo Sorce wrote: > On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >> On 2015-08-24 14:50, Jan Cholasta wrote: >>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>> >>>> >>>> On 2015-08-21 15:52, Michael ?im??ek wrote: >>>>> >>>>> >>>>> On 2015-08-20 20:42, Robbie Harwood wrote: >>>>>> Michael ?im??ek writes: >>>>>> >>>>>>> On 2015-08-20 12:32, Michael ?im??ek wrote: >>>>>>> >>>>>>>>>>> Michael ?im??ek writes: >>>>>>>>>>> >>>>>>>>>>>> Attaching new revision of the patch. Changes from the previous: >>>>>>>>>>>> - ldap2's connect now chooses the bind type same way as in >>>>>>>>>>>> ipaldap >>>>>>>>>>>> - get_default_realm usages replaced by api.env.realm >>>>>>>>>>>> - fixed missing third kinit attempt in trust-fetch-domains >>>>>>>>>>>> - removed rewrapping gssapi errors to ccache errors in krb_utils >>>>>>>>>>>> - updated some parts of exception handling >>>>>>>> >>>>>>>> Rebased on top of current master. >>>>>>> >>>>>>> One of the commits reintroduced krbV dependency that I didn't notice. >>>>>>> Attaching updated revision. Only changes against previous revision are >>>>>>> in files daemons/dnssec/ipa-dnskeysync-replica and >>>>>>> daemons/dnssec/ipa-ods-exporter. >>>>>> >>>>>> This is much better, thanks! I've got some comments inline. >>>>>> >>>>>>> +except gssapi.exceptions.GSSError: >>>>>>> # If there was failure on using keytab, assume it is stale and >>>>>>> retrieve again >>>>>>> retrieve_keytab(api, ccache_name, oneway_keytab_name, >>>>>>> oneway_principal) >>>>>> >>>>>> This code still bothers me a bit, but I think fixing it is probably >>>>>> beyond the scope of a python-gssapi port. >>>>> >>>>> The code catches all GSSAPI exceptions and retries to do the same thing >>>>> with different keytab. So if there was a problem unrelated to keytab, >>>>> the same exception will be raised again. Nothing will be ignored >>>>> silently. >>>>> >>>>>> >>>>>>> + try: >>>>>>> + creds = get_credentials(name=name, ccache_name=ccache_name) >>>>>>> + # property access would raise exception if expired >>>>>>> + if creds.lifetime > 0: >>>>>>> + return creds >>>>>>> + except gssapi.exceptions.ExpiredCredentialsError: >>>>>>> + return None >>>>>> >>>>>> Per rfc2744, lifetime is unsigned. It's not immediately clear what >>>>>> will >>>>>> happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in >>>>>> that case? >>>>> >>>>> I think the check is probably redundant, gssapi raises exception upon >>>>> inquiring expired credentials. In trust-fetch-domains I just access the >>>>> lifetime in try-except without using the value, so I could do the same >>>>> here. It would be nice if gssapi provided some 'is_valid' or >>>>> 'is_expired' method, so I wouldn't need to rely on side-effects of >>>>> property access, which is hard to read and confuses pylint. >>>>> >>>>>> >>>>>>> # Setup LDAP connection >>>>>>> try: >>>>>>> - ctx = krbV.default_context() >>>>>>> - ccache = ctx.default_ccache() >>>>>>> - api.Backend.ldap2.connect(ccache) >>>>>>> + api.Backend.ldap2.connect() >>>>>>> cls.ldap = api.Backend.ldap2 >>>>>>> - except krbV.Krb5Error as e: >>>>>>> + except gssapi.exceptions.GSSError: >>>>>>> sys.exit("Must have Kerberos credentials to migrate >>>>>>> Winsync users.") >>>>>> >>>>>> Can you log the error here? The other places GSSError is being caught >>>>>> are doing a great job of either filtering-and-raising or >>>>>> logging-and-exiting, so thanks for fixing those. >>>>> >>>>> Yes, I'll update it in next revision of the patch. >>>>> >>>>>> >>>>>>> +# Ugly hack for test purposes only. GSSAPI has no way to get default >>>>>>> ccache >>>>>>> +# name, but we don't need it outside test server >>>>>>> +def get_default_ccache_name(): >>>>>>> + try: >>>>>>> + out = check_output(['klist']) >>>>>>> + except CalledProcessError: >>>>>>> + raise RuntimeError("Default ccache not found. Did you >>>>>>> kinit?") >>>>>>> + match = re.match(r'^Ticket cache:\s*(\S+)', out) >>>>>>> + if not match: >>>>>>> + raise RuntimeError("Cannot obtain ccache name") >>>>>>> + return match.group(1) >>>>>> >>>>>> Yup, this is still ugly. Ah well, it's only test code. >>>>>> >>>>> >>>>> I was trying to modify the code to not need the variable and just use >>>>> the default, but it is used for manipulating it as a file - in >>>>> production it is always defined by mod_auth_gssapi. So I'd keep this >>>>> as is. >>>>> >>>> >>>> >>>> Next revision of the patch. Changes from previous rev: printing >>>> exception in ipa_winsync_migrate and more thorough dealing with >>>> credentials expiration in krb_utils and trust-fetch-domains. >>> >>> 1) There is a merge conflict in freeipa.spec.in, please rebase the patch >>> on top of current master. >>> >> >> Done. >> >>> >>> 2) pylint fails with: >>> >>> ************* Module ipa-ods-exporter >>> daemons/dnssec/ipa-ods-exporter:23: [E0611(no-name-in-module), ] No name >>> 'GSSError' in module 'gssapi') >>> ************* Module ipa-dnskeysync-replica >>> daemons/dnssec/ipa-dnskeysync-replica:15: [E0611(no-name-in-module), ] >>> No name 'GSSError' in module 'gssapi') >>> >>> Both failures are caused by "from gssapi import GSSError" statement, >>> which should read "from gssapi.exceptions import GSSError". >>> >> >> Fixed. >> >>> >>> 3) ipa-adtrust-install fails with: >>> >>> admin password: >>> >>> Unrecognized error during check of admin rights: >>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>> >>> Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" >>> call where a "user-show admin" call should be. >>> >> >> Fixed. python-gssapi has a display_as method that could pull the name >> from it, but it doesn't work in current version, therefore using >> partition to split on '@' >> >>> >>> 4) ipa-client-automount fails with: >>> >>> Failed to obtain host TGT: Major (851968): Unspecified GSS failure. >>> Minor code may provide more information, Minor (2529639111): Bad format >>> in credentials cache >>> >> >> gssapi apparently refuses to accept empty file as ccache. In order to >> not create a race condition / security hole by deleting and recreating >> the temp file, I changed it to use per-process kernel keyring (I believe >> non-persistent keyring should be available on all supported platforms). > > Ypu can create a temp directory in tmp where only the user has access > to, then you can have a file within it. This way you can still use a > file w/o having to create it, w/o race condition, but with compatibility > to file ccaches in case the kernel/krb5 libs are not built with keyring > support. > Done. Attaching new revision that uses mkdtemp. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-9-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 72269 bytes Desc: not available URL: From simo at redhat.com Mon Aug 24 17:51:22 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 24 Aug 2015 13:51:22 -0400 Subject: [Freeipa-devel] kra an ca instance installation Message-ID: <1440438682.3305.25.camel@willson.usersys.redhat.com> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in ipaserver/install when you always need both files to do anything around installation of the ca ? Is there a motivation ? Or can I simply provide a patch to remove the ca.py and kra.py files an unify all code in the proper *instance.py file ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rharwood at redhat.com Mon Aug 24 18:29:18 2015 From: rharwood at redhat.com (Robbie Harwood) Date: Mon, 24 Aug 2015 14:29:18 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DB44FA.2030402@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> Message-ID: Michael ?im??ek writes: > On 2015-08-24 17:49, Simo Sorce wrote: > >> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >> >>> On 2015-08-24 14:50, Jan Cholasta wrote: >>> >>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>> >>>> 3) ipa-adtrust-install fails with: >>>> >>>> admin password: >>>> >>>> Unrecognized error during check of admin rights: >>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>> >>>> Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" >>>> call where a "user-show admin" call should be. >>> >>> Fixed. python-gssapi has a display_as method that could pull the name >>> from it, but it doesn't work in current version, therefore using >>> partition to split on '@' It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: > - user = api.Command.user_show(unicode(principal[0]))['result'] > + user = api.Command.user_show(principal.partition('@')[0])['result'] is working around a bug in specific Kerberos versions. If people are okay with merging such code, then I guess this is fine; I would personally not do so because there is not a clear point at which it can be removed. At the very least, we should wait until we see what versions of krb5 MIT is going to fix. Otherwise, looks good. [0]: https://github.com/pythongssapi/python-gssapi/issues/79 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From edewata at redhat.com Mon Aug 24 23:37:01 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Aug 2015 18:37:01 -0500 Subject: [Freeipa-devel] Adding client-side functionality in Vault Message-ID: <55DBAA9D.80703@redhat.com> Hi, Recently I posted the following patches which are still pending review: * 371-2: Added support for changing vault encryption. * 375-1: Added mechanism to copy vault secrets. Here are the tickets: * https://fedorahosted.org/freeipa/ticket/5176 * https://fedorahosted.org/freeipa/ticket/5223 These patches add new functionality to the following commands: * vault-mod: changing vault encryption * vault-archive: copying a secret from a vault into an existing vault * vault-add: copying a secret from a vault into a new vault The changes are quite similar. In order to change the vault encryption or to copy the vault secret, the old secret has to be retrieved with the old encryption parameters, then the secret will be rearchived with the new encryption parameters. The thing is these operations have to be done on the client side since the encryption/decryption is done using a key only known to the client. This also means that even if the server is upgraded, someone using an old client will not be able to utilize the new functionality unless the client is upgraded too. Also, the old vault-mod actually has a bug because it will update the vault encryption attributes without rearchiving the secret. Should we require old clients to upgrade? Or should we continue to accept old clients, but the buggy operation will now be rejected? Is this considered breaking backward compatibility? Thanks. -- Endi S. Dewata From ftweedal at redhat.com Tue Aug 25 00:35:53 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 25 Aug 2015 10:35:53 +1000 Subject: [Freeipa-devel] [PATCH] 0040 certprofile: prevent rename (modrdn) Message-ID: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> The attached patch fixes https://fedorahosted.org/freeipa/ticket/5247. Thanks, Fraser -------------- next part -------------- From 2cb4ab6eeedccc3471ed9bf983add4687ecd5c1a Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 24 Aug 2015 20:25:10 -0400 Subject: [PATCH] certprofile: prevent rename (modrdn) Fixes: https://fedorahosted.org/freeipa/ticket/5247 --- ipalib/plugins/certprofile.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 007cc543406b7e5705fd7474f3685cd6a9ce6aca..a0ffa38608400860994c771e4eba81304ead27be 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -323,8 +323,9 @@ class certprofile_mod(LDAPUpdate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): ca_enabled_check() # Once a profile id is set it cannot be changed - if 'cn' in entry_attrs: - raise errors.ACIError(info=_('cn is immutable')) + if 'rename' in options or 'cn' in entry_attrs: + raise errors.ProtectedEntryError(label='certprofile', key=keys[0], + reason=_('Certificate profiles cannot be renamed')) if 'file' in options: with self.api.Backend.ra_certprofile as profile_api: profile_api.disable_profile(keys[0]) -- 2.4.3 From abokovoy at redhat.com Tue Aug 25 05:35:59 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 08:35:59 +0300 Subject: [Freeipa-devel] Adding client-side functionality in Vault In-Reply-To: <55DBAA9D.80703@redhat.com> References: <55DBAA9D.80703@redhat.com> Message-ID: <20150825053559.GP22106@redhat.com> On Mon, 24 Aug 2015, Endi Sukma Dewata wrote: >Hi, > >Recently I posted the following patches which are still pending review: >* 371-2: Added support for changing vault encryption. >* 375-1: Added mechanism to copy vault secrets. > >Here are the tickets: >* https://fedorahosted.org/freeipa/ticket/5176 >* https://fedorahosted.org/freeipa/ticket/5223 > >These patches add new functionality to the following commands: >* vault-mod: changing vault encryption >* vault-archive: copying a secret from a vault into an existing vault >* vault-add: copying a secret from a vault into a new vault > >The changes are quite similar. In order to change the vault encryption >or to copy the vault secret, the old secret has to be retrieved with >the old encryption parameters, then the secret will be rearchived with >the new encryption parameters. > >The thing is these operations have to be done on the client side since >the encryption/decryption is done using a key only known to the >client. This also means that even if the server is upgraded, someone >using an old client will not be able to utilize the new functionality >unless the client is upgraded too. Also, the old vault-mod actually >has a bug because it will update the vault encryption attributes >without rearchiving the secret. > >Should we require old clients to upgrade? Or should we continue to >accept old clients, but the buggy operation will now be rejected? Is >this considered breaking backward compatibility? We don't really have old clients for vaults yet as we only released FreeIPA 4.2 into an experimental COPR repository. I think it is OK to include these patches to fix incompatibility now rather than releasing 4.2.1 without them and then dealing with the incompatibility later. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Aug 25 05:37:11 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 08:37:11 +0300 Subject: [Freeipa-devel] [PATCH] 0040 certprofile: prevent rename (modrdn) In-Reply-To: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> References: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> Message-ID: <20150825053711.GQ22106@redhat.com> On Tue, 25 Aug 2015, Fraser Tweedale wrote: >The attached patch fixes >https://fedorahosted.org/freeipa/ticket/5247. > >Thanks, >Fraser >From 2cb4ab6eeedccc3471ed9bf983add4687ecd5c1a Mon Sep 17 00:00:00 2001 >From: Fraser Tweedale >Date: Mon, 24 Aug 2015 20:25:10 -0400 >Subject: [PATCH] certprofile: prevent rename (modrdn) > >Fixes: https://fedorahosted.org/freeipa/ticket/5247 >--- > ipalib/plugins/certprofile.py | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > >diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py >index 007cc543406b7e5705fd7474f3685cd6a9ce6aca..a0ffa38608400860994c771e4eba81304ead27be 100644 >--- a/ipalib/plugins/certprofile.py >+++ b/ipalib/plugins/certprofile.py >@@ -323,8 +323,9 @@ class certprofile_mod(LDAPUpdate): > def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): > ca_enabled_check() > # Once a profile id is set it cannot be changed >- if 'cn' in entry_attrs: >- raise errors.ACIError(info=_('cn is immutable')) >+ if 'rename' in options or 'cn' in entry_attrs: >+ raise errors.ProtectedEntryError(label='certprofile', key=keys[0], >+ reason=_('Certificate profiles cannot be renamed')) > if 'file' in options: > with self.api.Backend.ra_certprofile as profile_api: > profile_api.disable_profile(keys[0]) ACK -- / Alexander Bokovoy From dkupka at redhat.com Tue Aug 25 08:37:37 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 25 Aug 2015 10:37:37 +0200 Subject: [Freeipa-devel] [PATCH 0058] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55DB2F73.6050608@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> Message-ID: <55DC2951.60508@redhat.com> On 24/08/15 16:51, Martin Basti wrote: > > > On 08/20/2015 10:28 AM, David Kupka wrote: >> On 31/07/15 13:32, Martin Basti wrote: >>> On 30/07/15 14:38, Martin Basti wrote: >>>> On 29/07/15 16:12, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5087 >>>> NACK >>>> >>>> You forgot to update API.txt file >> >> Thanks for catching that. Updated patch attached. >> >>>> >>> I'm just curious, what is the reason to check if forward zone exists? >>> >>> IMO forwardzone must exists somewhere as the master zone. I don't think >>> we should check forwardzones, this may give too many false positive >>> errors. >> >> AIUI if the zone exist somewhere and is resolvable there is no need to >> add it as a forward zone. If user for some reason want to do it he's >> hiding the original zone and we should not allow this (without --force). >> > Note: Petr2 agreed with David's solution > > LGTM, works as expected, but this patch prevents users to add > conflicting zones via webUI (there is no --force field). > We should improve webUI together with this patch. > > Martin^2 > >>> >>> Martin^2 >>> >> > The '--force' option was not in WebUI before even though it was in API. IMO we should not expose '--force' options in WebUI at all. -- David Kupka From jcholast at redhat.com Tue Aug 25 09:25:04 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 11:25:04 +0200 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <1440438682.3305.25.camel@willson.usersys.redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> Message-ID: <55DC3470.2050507@redhat.com> On 24.8.2015 19:51, Simo Sorce wrote: > Why do we have cainstance.py and ca.py and krainstance.py and kra.py in > ipaserver/install when you always need both files to do anything around > installation of the ca ? > > Is there a motivation ? > Or can I simply provide a patch to remove the ca.py and kra.py files an > unify all code in the proper *instance.py file ? ca.py and kra.py are the proper files ready to be migrated to the new install framework, cainstance.py and krainstance.py will be removed. -- Jan Cholasta From jcholast at redhat.com Tue Aug 25 09:34:28 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 11:34:28 +0200 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <55DC3470.2050507@redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> Message-ID: <55DC36A4.5000201@redhat.com> On 25.8.2015 11:25, Jan Cholasta wrote: > On 24.8.2015 19:51, Simo Sorce wrote: >> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in >> ipaserver/install when you always need both files to do anything around >> installation of the ca ? >> >> Is there a motivation ? >> Or can I simply provide a patch to remove the ca.py and kra.py files an >> unify all code in the proper *instance.py file ? > > ca.py and kra.py are the proper files ready to be migrated to the new > install framework, cainstance.py and krainstance.py will be removed. ... once the migration is done. (Hit send button too fast.) The motivation is that *instance.py do not provide a uniform interface, have a lot of redundant and duplicate stuff and are generally unfit for any further extension. Honza -- Jan Cholasta From mbasti at redhat.com Tue Aug 25 09:47:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Aug 2015 11:47:12 +0200 Subject: [Freeipa-devel] [PATCH 0060] raise an error when trying to preserve an already preserved user In-Reply-To: <55D6E32D.4030204@redhat.com> References: <55D47C85.6050008@redhat.com> <55D4AEA1.9040507@redhat.com> <55D5A0B9.8020908@redhat.com> <55D5A7D0.3040601@redhat.com> <55D5C125.4030002@redhat.com> <55D6E32D.4030204@redhat.com> Message-ID: <55DC39A0.7030907@redhat.com> On 08/21/2015 10:37 AM, thierry bordaz wrote: > On 08/20/2015 01:59 PM, Martin Babinsky wrote: >> On 08/20/2015 12:11 PM, Martin Babinsky wrote: >>> On 08/20/2015 11:41 AM, thierry bordaz wrote: >>>> On 08/19/2015 06:28 PM, Martin Babinsky wrote: >>>>> On 08/19/2015 02:54 PM, Martin Babinsky wrote: >>>>>> this patch prevents https://fedorahosted.org/freeipa/ticket/5234 >>>>>> from >>>>>> happening. >>>>>> >>>>>> >>>>>> >>>>> Actually, we (myself, mbasti, jcholast) found out that `user-del >>>>> --preserve` could use some more usability improvements. >>>>> >>>>> This quick patch should fix both >>>>> https://fedorahosted.org/freeipa/ticket/5234 and >>>>> https://fedorahosted.org/freeipa/ticket/5236 and make user >>>>> preservation operate on multiple arguments in a same way as plain >>>>> deletion. >>>>> >>>>> >>>>> >>>> >>>> Hi Martin, >>>> >>>> The tests are ok and the fix looks good to me. >>>> >>>> ACK >>>> >>>> thanks >>>> thierry >>> >>> That's nice, but I have found some small nitpicks and will send an >>> updated version. >>> >>> So self-NACK. >>> >> Attaching updated patch. >> > > This is working fine. > > ACK > > Pushed to: master: c6299a8cfde7d4e4bb9a50e3cf6406667cee0a6f ipa-4-2: 361a4fb4100824b27b777c27c329d50361ba69f4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Aug 25 10:03:06 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 12:03:06 +0200 Subject: [Freeipa-devel] [PATCH] 0040 certprofile: prevent rename (modrdn) In-Reply-To: <20150825053711.GQ22106@redhat.com> References: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> <20150825053711.GQ22106@redhat.com> Message-ID: <55DC3D5A.9060202@redhat.com> On 08/25/2015 07:37 AM, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Fraser Tweedale wrote: >> The attached patch fixes >> https://fedorahosted.org/freeipa/ticket/5247. >> >> Thanks, >> Fraser > >> From 2cb4ab6eeedccc3471ed9bf983add4687ecd5c1a Mon Sep 17 00:00:00 2001 >> From: Fraser Tweedale >> Date: Mon, 24 Aug 2015 20:25:10 -0400 >> Subject: [PATCH] certprofile: prevent rename (modrdn) >> >> Fixes: https://fedorahosted.org/freeipa/ticket/5247 >> --- >> ipalib/plugins/certprofile.py | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/ipalib/plugins/certprofile.py >> b/ipalib/plugins/certprofile.py >> index >> 007cc543406b7e5705fd7474f3685cd6a9ce6aca..a0ffa38608400860994c771e4eba81304ead27be >> 100644 >> --- a/ipalib/plugins/certprofile.py >> +++ b/ipalib/plugins/certprofile.py >> @@ -323,8 +323,9 @@ class certprofile_mod(LDAPUpdate): >> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >> **options): >> ca_enabled_check() >> # Once a profile id is set it cannot be changed >> - if 'cn' in entry_attrs: >> - raise errors.ACIError(info=_('cn is immutable')) >> + if 'rename' in options or 'cn' in entry_attrs: >> + raise errors.ProtectedEntryError(label='certprofile', >> key=keys[0], >> + reason=_('Certificate profiles cannot be renamed')) >> if 'file' in options: >> with self.api.Backend.ra_certprofile as profile_api: >> profile_api.disable_profile(keys[0]) > ACK can't we fix it by removing `rdn_is_primary_key = True`? That would also remove the --rename option. Yes it's an API change but if rename is forbidden than the option should not be even there, just the result error will different. -- Petr Vobornik From jcholast at redhat.com Tue Aug 25 10:13:14 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 12:13:14 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> Message-ID: <55DC3FBA.3060902@redhat.com> On 24.8.2015 20:29, Robbie Harwood wrote: > Michael ?im??ek writes: > >> On 2015-08-24 17:49, Simo Sorce wrote: >> >>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>> >>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>> >>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>> >>>>> 3) ipa-adtrust-install fails with: >>>>> >>>>> admin password: >>>>> >>>>> Unrecognized error during check of admin rights: >>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>> >>>>> Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" >>>>> call where a "user-show admin" call should be. >>>> >>>> Fixed. python-gssapi has a display_as method that could pull the name >>>> from it, but it doesn't work in current version, therefore using >>>> partition to split on '@' > > It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: > >> - user = api.Command.user_show(unicode(principal[0]))['result'] >> + user = api.Command.user_show(principal.partition('@')[0])['result'] > > is working around a bug in specific Kerberos versions. If people are > okay with merging such code, then I guess this is fine; I would > personally not do so because there is not a clear point at which it can > be removed. At the very least, we should wait until we see what > versions of krb5 MIT is going to fix. The principal comes from krb_utils.get_principal(). Are you saying that after MIT Krb5 is fixed, this function will not return a principal anymore? If so, it needs to be fixed to use some different interface to return a principal even after MIT Krb5 is fixed, we don't want a function called get_principal to *not* return a principal. > > Otherwise, looks good. > > [0]: https://github.com/pythongssapi/python-gssapi/issues/79 > -- Jan Cholasta From msimacek at redhat.com Tue Aug 25 10:21:55 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Tue, 25 Aug 2015 12:21:55 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DC3FBA.3060902@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC3FBA.3060902@redhat.com> Message-ID: <55DC41C3.5040308@redhat.com> On 2015-08-25 12:13, Jan Cholasta wrote: > On 24.8.2015 20:29, Robbie Harwood wrote: >> Michael ?im??ek writes: >> >>> On 2015-08-24 17:49, Simo Sorce wrote: >>> >>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>> >>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>> >>>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>>> >>>>>> 3) ipa-adtrust-install fails with: >>>>>> >>>>>> admin password: >>>>>> >>>>>> Unrecognized error during check of admin rights: >>>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>>> >>>>>> Apparently there is a "user-show >>>>>> admin at abc.idm.lab.eng.brq.redhat.com" >>>>>> call where a "user-show admin" call should be. >>>>> >>>>> Fixed. python-gssapi has a display_as method that could pull the name >>>>> from it, but it doesn't work in current version, therefore using >>>>> partition to split on '@' >> >> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >> >>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>> + user = >>> api.Command.user_show(principal.partition('@')[0])['result'] >> >> is working around a bug in specific Kerberos versions. If people are >> okay with merging such code, then I guess this is fine; I would >> personally not do so because there is not a clear point at which it can >> be removed. At the very least, we should wait until we see what >> versions of krb5 MIT is going to fix. > > The principal comes from krb_utils.get_principal(). Are you saying that > after MIT Krb5 is fixed, this function will not return a principal > anymore? If so, it needs to be fixed to use some different interface to > return a principal even after MIT Krb5 is fixed, we don't want a > function called get_principal to *not* return a principal. > No, get_principal won't change. Robbie doesn't like the principal.partition('@'), which could maybe be replaced by call to display_as (on a gssapi.Name object that would be obtained in some other way). But display_as doesn't work. I'm saying maybe replaced, because I'm getting "operation not supported" from kerberos when trying to excercise the not-buggy code path of display_as. >> >> Otherwise, looks good. >> >> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >> > From msimacek at redhat.com Tue Aug 25 10:23:25 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Tue, 25 Aug 2015 12:23:25 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> Message-ID: <55DC421D.8000908@redhat.com> On 2015-08-24 20:29, Robbie Harwood wrote: > Michael ?im??ek writes: > >> On 2015-08-24 17:49, Simo Sorce wrote: >> >>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>> >>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>> >>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>> >>>>> 3) ipa-adtrust-install fails with: >>>>> >>>>> admin password: >>>>> >>>>> Unrecognized error during check of admin rights: >>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>> >>>>> Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" >>>>> call where a "user-show admin" call should be. >>>> >>>> Fixed. python-gssapi has a display_as method that could pull the name >>>> from it, but it doesn't work in current version, therefore using >>>> partition to split on '@' > > It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: > >> - user = api.Command.user_show(unicode(principal[0]))['result'] >> + user = api.Command.user_show(principal.partition('@')[0])['result'] > > is working around a bug in specific Kerberos versions. If people are > okay with merging such code, then I guess this is fine; I would > personally not do so because there is not a clear point at which it can > be removed. At the very least, we should wait until we see what > versions of krb5 MIT is going to fix. > > Otherwise, looks good. > > [0]: https://github.com/pythongssapi/python-gssapi/issues/79 > python-krbV migration is blocking support for Python 3. The bug doesn't have any fix upstream yet and there are two bugs actually, the second one is in python-gssapi, which I've just reported [1]. Waiting for two bugs to be fixed could be detrimental to py3 migration as we don't have much time left. And I'm no longer sure that display_as could be used at all, as I'm getting "operation not supported" on inputs that don't trigger any of the bugs. I don't think parsing a string is a big problem. When there will be a different solution available, I'll submit a new patch. I'm tracking python-gssapi's issues on github and I won't dissapear after this is merged. I digged into implementation of krbV.Principal and discovered that principal[0] actually returns only the first component (ipa users should have only one, but better be safe). Attaching adjusted patch that deals with it. (Side note: krbV.Principal.__getitem__ is marked as 'Internal function, do not use', so the previous code was also a workaround) [1] https://github.com/pythongssapi/python-gssapi/issues/81 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-msimacek-0002-10-Port-from-python-krbV-to-python-gssapi.patch Type: text/x-patch Size: 72287 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 25 10:38:50 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 13:38:50 +0300 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DC421D.8000908@redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> Message-ID: <20150825103850.GS22106@redhat.com> On Tue, 25 Aug 2015, Michael ?im??ek wrote: > > >On 2015-08-24 20:29, Robbie Harwood wrote: >>Michael ?im??ek writes: >> >>>On 2015-08-24 17:49, Simo Sorce wrote: >>> >>>>On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>> >>>>>On 2015-08-24 14:50, Jan Cholasta wrote: >>>>> >>>>>>On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>>> >>>>>>3) ipa-adtrust-install fails with: >>>>>> >>>>>>admin password: >>>>>> >>>>>>Unrecognized error during check of admin rights: >>>>>>admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>>> >>>>>>Apparently there is a "user-show admin at abc.idm.lab.eng.brq.redhat.com" >>>>>>call where a "user-show admin" call should be. >>>>> >>>>>Fixed. python-gssapi has a display_as method that could pull the name >>>>>from it, but it doesn't work in current version, therefore using >>>>>partition to split on '@' >> >>It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >> >>>- user = api.Command.user_show(unicode(principal[0]))['result'] >>>+ user = api.Command.user_show(principal.partition('@')[0])['result'] >> >>is working around a bug in specific Kerberos versions. If people are >>okay with merging such code, then I guess this is fine; I would >>personally not do so because there is not a clear point at which it can >>be removed. At the very least, we should wait until we see what >>versions of krb5 MIT is going to fix. >> >>Otherwise, looks good. >> >>[0]: https://github.com/pythongssapi/python-gssapi/issues/79 >> > >python-krbV migration is blocking support for Python 3. The bug >doesn't have any fix upstream yet and there are two bugs actually, the >second one is in python-gssapi, which I've just reported [1]. Waiting >for two bugs to be fixed could be detrimental to py3 migration as we >don't have much time left. And I'm no longer sure that display_as I don't buy this. We have plenty of time for solving these bugs. Remember, that Samba DCE RPC bindings aren't migrated to Python 3 either and will not be before release of Samba 4.4. For Samba 4.3 it is simply too late. So we are still far away from full Python3 migration for FreeIPA and waiting for solving these two bugs is OK. >could be used at all, as I'm getting "operation not supported" on >inputs that don't trigger any of the bugs. I don't think parsing a >string is a big problem. When there will be a different solution >available, I'll submit a new patch. I'm tracking python-gssapi's >issues on github and I won't dissapear after this is merged. Sure. It is not about you disappearing any time soon, we need to solve migration issues properly rather than hurrying up for whatever reasons. -- / Alexander Bokovoy From cheimes at redhat.com Tue Aug 25 10:39:25 2015 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 25 Aug 2015 12:39:25 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DB38BC.50907@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> Message-ID: <55DC45DD.1040907@redhat.com> On 2015-08-24 17:31, Petr Viktorin wrote: >>>> 0701.2-Use-Python3-compatible-dict-method-names >>>> NACK >>>> Why are you replacing iteritems() with items() instead of using >>>> six.iteritems()? > > It looks cleaner, and it will be easier to clean up after six is dropped. > Also, the performance difference is negligible if the whole thing is > iterated over. (On small dicts, which are the majority of what iteritems > was used on, items() is actually a bit faster on my machine.) Right, for small dicts the speed difference is negligible and favors the items() over iteritems(). For medium sized and large dicts the iterators are faster and consume less memory. I'm preferring iterator methods everywhere because I don't have to worry about dict sizes. >>>> 0710.2-Modernize-use-of-range >>>> NACK >>>> Please use six.moves.range. It defaults to xrange() in Python 2. > > Why? What is the benefit of xrange in these situations? > > Like with iteritems in 0701, when iterating over the whole thing, the > performance difference is negligible. I don't think a few microseconds > outside of tight loops are worth the verbosity. It's the same reasoning as in 0701. As long as you have a small range, it doesn't make a difference. For large ranges the additional memory usage can be problematic. In all above cases the iterator methods and generator functions are a safer choice. A malicious user can abuse the non-iterative methods for DoS attacks. As long as the input can't be controlled by a user and the range/dict/set/list is small, the non-iterative methods are fine. You have to verify every location, though. I'm usually too busy with other stuff (aka lazy) to verify these preconditions... Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From abokovoy at redhat.com Tue Aug 25 10:39:42 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 13:39:42 +0300 Subject: [Freeipa-devel] [PATCH] 0040 certprofile: prevent rename (modrdn) In-Reply-To: <55DC3D5A.9060202@redhat.com> References: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> <20150825053711.GQ22106@redhat.com> <55DC3D5A.9060202@redhat.com> Message-ID: <20150825103942.GT22106@redhat.com> On Tue, 25 Aug 2015, Petr Vobornik wrote: >On 08/25/2015 07:37 AM, Alexander Bokovoy wrote: >>On Tue, 25 Aug 2015, Fraser Tweedale wrote: >>>The attached patch fixes >>>https://fedorahosted.org/freeipa/ticket/5247. >>> >>>Thanks, >>>Fraser >> >>>From 2cb4ab6eeedccc3471ed9bf983add4687ecd5c1a Mon Sep 17 00:00:00 2001 >>>From: Fraser Tweedale >>>Date: Mon, 24 Aug 2015 20:25:10 -0400 >>>Subject: [PATCH] certprofile: prevent rename (modrdn) >>> >>>Fixes: https://fedorahosted.org/freeipa/ticket/5247 >>>--- >>>ipalib/plugins/certprofile.py | 5 +++-- >>>1 file changed, 3 insertions(+), 2 deletions(-) >>> >>>diff --git a/ipalib/plugins/certprofile.py >>>b/ipalib/plugins/certprofile.py >>>index >>>007cc543406b7e5705fd7474f3685cd6a9ce6aca..a0ffa38608400860994c771e4eba81304ead27be >>>100644 >>>--- a/ipalib/plugins/certprofile.py >>>+++ b/ipalib/plugins/certprofile.py >>>@@ -323,8 +323,9 @@ class certprofile_mod(LDAPUpdate): >>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >>>**options): >>> ca_enabled_check() >>> # Once a profile id is set it cannot be changed >>>- if 'cn' in entry_attrs: >>>- raise errors.ACIError(info=_('cn is immutable')) >>>+ if 'rename' in options or 'cn' in entry_attrs: >>>+ raise errors.ProtectedEntryError(label='certprofile', >>>key=keys[0], >>>+ reason=_('Certificate profiles cannot be renamed')) >>> if 'file' in options: >>> with self.api.Backend.ra_certprofile as profile_api: >>> profile_api.disable_profile(keys[0]) >>ACK > >can't we fix it by removing `rdn_is_primary_key = True`? > >That would also remove the --rename option. Yes it's an API change but >if rename is forbidden than the option should not be even there, just >the result error will different. Well, that is another option, yes. Perhaps even a better one -- we have plenty of places where rdn_is_primary_key is not actually used. -- / Alexander Bokovoy From msimacek at redhat.com Tue Aug 25 10:46:46 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Tue, 25 Aug 2015 12:46:46 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <20150825103850.GS22106@redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> Message-ID: <55DC4796.9020303@redhat.com> On 2015-08-25 12:38, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Michael ?im??ek wrote: >> >> >> On 2015-08-24 20:29, Robbie Harwood wrote: >>> Michael ?im??ek writes: >>> >>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>> >>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>> >>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>> >>>>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>>>> >>>>>>> 3) ipa-adtrust-install fails with: >>>>>>> >>>>>>> admin password: >>>>>>> >>>>>>> Unrecognized error during check of admin rights: >>>>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>>>> >>>>>>> Apparently there is a "user-show >>>>>>> admin at abc.idm.lab.eng.brq.redhat.com" >>>>>>> call where a "user-show admin" call should be. >>>>>> >>>>>> Fixed. python-gssapi has a display_as method that could pull the name >>>>>> from it, but it doesn't work in current version, therefore using >>>>>> partition to split on '@' >>> >>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>> >>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>> + user = >>>> api.Command.user_show(principal.partition('@')[0])['result'] >>> >>> is working around a bug in specific Kerberos versions. If people are >>> okay with merging such code, then I guess this is fine; I would >>> personally not do so because there is not a clear point at which it can >>> be removed. At the very least, we should wait until we see what >>> versions of krb5 MIT is going to fix. >>> >>> Otherwise, looks good. >>> >>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>> >> >> python-krbV migration is blocking support for Python 3. The bug >> doesn't have any fix upstream yet and there are two bugs actually, the >> second one is in python-gssapi, which I've just reported [1]. Waiting >> for two bugs to be fixed could be detrimental to py3 migration as we >> don't have much time left. And I'm no longer sure that display_as > I don't buy this. > > We have plenty of time for solving these bugs. Remember, that Samba > DCE RPC bindings aren't migrated to Python 3 either and will not be > before release of Samba 4.4. For Samba 4.3 it is simply too late. > > So we are still far away from full Python3 migration for FreeIPA and > waiting for solving these two bugs is OK. > If fixing them solves anything at all. I planned to use display_as(NameType.user), but when trying it on Name object with name_type set (which doesn't trigger the segfault), it doesn't seem to work either. I get: gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The operation or option is not available or unsupported, Minor (0): Unknown error Robbie, can you clarify whether display_as could be actually used to get the first component of the principal reliably? >> could be used at all, as I'm getting "operation not supported" on >> inputs that don't trigger any of the bugs. I don't think parsing a >> string is a big problem. When there will be a different solution >> available, I'll submit a new patch. I'm tracking python-gssapi's >> issues on github and I won't dissapear after this is merged. > Sure. It is not about you disappearing any time soon, we need to solve > migration issues properly rather than hurrying up for whatever reasons. > From pvoborni at redhat.com Tue Aug 25 10:59:48 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 12:59:48 +0200 Subject: [Freeipa-devel] Adding client-side functionality in Vault In-Reply-To: <20150825053559.GP22106@redhat.com> References: <55DBAA9D.80703@redhat.com> <20150825053559.GP22106@redhat.com> Message-ID: <55DC4AA4.5070602@redhat.com> On 08/25/2015 07:35 AM, Alexander Bokovoy wrote: > On Mon, 24 Aug 2015, Endi Sukma Dewata wrote: >> Hi, >> >> Recently I posted the following patches which are still pending review: >> * 371-2: Added support for changing vault encryption. >> * 375-1: Added mechanism to copy vault secrets. >> >> Here are the tickets: >> * https://fedorahosted.org/freeipa/ticket/5176 >> * https://fedorahosted.org/freeipa/ticket/5223 >> >> These patches add new functionality to the following commands: >> * vault-mod: changing vault encryption >> * vault-archive: copying a secret from a vault into an existing vault >> * vault-add: copying a secret from a vault into a new vault >> >> The changes are quite similar. In order to change the vault encryption >> or to copy the vault secret, the old secret has to be retrieved with >> the old encryption parameters, then the secret will be rearchived with >> the new encryption parameters. >> >> The thing is these operations have to be done on the client side since >> the encryption/decryption is done using a key only known to the >> client. This also means that even if the server is upgraded, someone >> using an old client will not be able to utilize the new functionality >> unless the client is upgraded too. Also, the old vault-mod actually >> has a bug because it will update the vault encryption attributes >> without rearchiving the secret. >> >> Should we require old clients to upgrade? Or should we continue to >> accept old clients, but the buggy operation will now be rejected? Is >> this considered breaking backward compatibility? > We don't really have old clients for vaults yet as we only released > FreeIPA 4.2 into an experimental COPR repository. > > I think it is OK to include these patches to fix incompatibility now > rather than releasing 4.2.1 without them and then dealing with the > incompatibility later. Also the changes in vault-archive and vault-add are enhancements which AFAIK requires new options to be used. I.e. will be ignored by old clients therefore it doesn't matter when that's added. vault-mod should be fixed ASAP. -- Petr Vobornik From jcholast at redhat.com Tue Aug 25 11:10:30 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 13:10:30 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DC41C3.5040308@redhat.com> References: <55B88A4A.9070601@redhat.com> <55BB0D04.4030904@redhat.com> <55BB8927.1080608@redhat.com> <1438366844.24296.27.camel@willson.usersys.redhat.com> <55BF1761.4090600@redhat.com> <55CC4971.5090105@redhat.com> <55D2EECA.7030808@redhat.com> <20150819092653.GK22106@redhat.com> <55D5ACAC.7010001@redhat.com> <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC3FBA.3060902@redhat.com> <55DC41C3.5040308@redhat.com> Message-ID: <55DC4D26.6050304@redhat.com> On 25.8.2015 12:21, Michael ?im??ek wrote: > > > On 2015-08-25 12:13, Jan Cholasta wrote: >> On 24.8.2015 20:29, Robbie Harwood wrote: >>> Michael ?im??ek writes: >>> >>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>> >>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>> >>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>> >>>>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>>>> >>>>>>> 3) ipa-adtrust-install fails with: >>>>>>> >>>>>>> admin password: >>>>>>> >>>>>>> Unrecognized error during check of admin rights: >>>>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>>>> >>>>>>> Apparently there is a "user-show >>>>>>> admin at abc.idm.lab.eng.brq.redhat.com" >>>>>>> call where a "user-show admin" call should be. >>>>>> >>>>>> Fixed. python-gssapi has a display_as method that could pull the name >>>>>> from it, but it doesn't work in current version, therefore using >>>>>> partition to split on '@' >>> >>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>> >>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>> + user = >>>> api.Command.user_show(principal.partition('@')[0])['result'] >>> >>> is working around a bug in specific Kerberos versions. If people are >>> okay with merging such code, then I guess this is fine; I would >>> personally not do so because there is not a clear point at which it can >>> be removed. At the very least, we should wait until we see what >>> versions of krb5 MIT is going to fix. >> >> The principal comes from krb_utils.get_principal(). Are you saying that >> after MIT Krb5 is fixed, this function will not return a principal >> anymore? If so, it needs to be fixed to use some different interface to >> return a principal even after MIT Krb5 is fixed, we don't want a >> function called get_principal to *not* return a principal. >> > > No, get_principal won't change. Robbie doesn't like the > principal.partition('@'), which could maybe be replaced by call to > display_as (on a gssapi.Name object that would be obtained in some other > way). But display_as doesn't work. I'm saying maybe replaced, because > I'm getting "operation not supported" from kerberos when trying to > excercise the not-buggy code path of display_as. We use "principal.split('@')" in different parts of IPA, so IMO it's OK. -- Jan Cholasta From mbasti at redhat.com Tue Aug 25 11:24:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Aug 2015 13:24:38 +0200 Subject: [Freeipa-devel] [PATCH 0002] TEST: Stageuser plugin In-Reply-To: <55DB250C.6090606@redhat.com> References: <55B64351.5020001@redhat.com> <55B64495.30309@redhat.com> <55B8D4B4.8090303@redhat.com> <55B8D552.8040306@redhat.com> <55B8DED8.90909@redhat.com> <55BA2FFE.6010400@redhat.com> <55BA3051.2070703@redhat.com> <55C0A40A.8080606@redhat.com> <55C9AD03.3070107@redhat.com> <55C9B8DE.9060907@redhat.com> <55CC88F3.90305@redhat.com> <55CDAF1A.1040006@redhat.com> <55CE0BC6.7080208@redhat.com> <55CE1820.5060405@redhat.com> <55D5DAA7.5030309@redhat.com> <55DAEE91.40508@redhat.com> <55DB0A9C.5060509@redhat.com> <55DB18AA.9040406@redhat.com> <55DB250C.6090606@redhat.com> Message-ID: <55DC5076.5070709@redhat.com> On 08/24/2015 04:07 PM, Lenka Doudova wrote: > Attached. > Lenka > > On 08/24/2015 03:14 PM, Martin Basti wrote: >> NACK >> >> You have unmerged changes in the patch >> >> On 08/24/2015 02:14 PM, Lenka Doudova wrote: >>> from ipatests.test_xmlrpc import objectclasses >>> +<<<<<<< HEAD >>> from ipatests.test_xmlrpc.xmlrpc_test import ( >>> Declarative, fuzzy_digits, fuzzy_uuid, fuzzy_set_ci, add_sid, >>> add_oc) >>> +======= >>> +from xmlrpc_test import (Declarative, fuzzy_digits, fuzzy_uuid, >>> fuzzy_set_ci, >>> + add_sid, add_oc, XMLRPC_test, raises_exact) >>> +>>>>>>> Automated test for stageuser plugin >>> from ipapython.dn import DN >> > Patch that was pushed today breaks one of your test, please fix it in new patch. E assert 'no such entry' == 'puser1: user not found' E + where 'no such entry' = NotFound(u'no such entry',).strerror E + and 'puser1: user not found' = NotFound(u'puser1: user not found',).strerror ACK Pushed to ipa-4-2: b648d124b570cbacc7d8f7d5df2976352cdba1ba Pushed to master: a14c4b5001b09002ae5a6ef239fe9050c7de96f9 Martin^2 From pviktori at redhat.com Tue Aug 25 11:49:05 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Aug 2015 13:49:05 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <20150825103850.GS22106@redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> Message-ID: <55DC5631.8000406@redhat.com> On 08/25/2015 12:38 PM, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Michael ?im??ek wrote: >> >> >> On 2015-08-24 20:29, Robbie Harwood wrote: >>> Michael ?im??ek writes: >>> >>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>> >>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>> >>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>> >>>>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>>>> >>>>>>> 3) ipa-adtrust-install fails with: >>>>>>> >>>>>>> admin password: >>>>>>> >>>>>>> Unrecognized error during check of admin rights: >>>>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>>>> >>>>>>> Apparently there is a "user-show >>>>>>> admin at abc.idm.lab.eng.brq.redhat.com" >>>>>>> call where a "user-show admin" call should be. >>>>>> >>>>>> Fixed. python-gssapi has a display_as method that could pull the name >>>>>> from it, but it doesn't work in current version, therefore using >>>>>> partition to split on '@' >>> >>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>> >>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>> + user = >>>> api.Command.user_show(principal.partition('@')[0])['result'] >>> >>> is working around a bug in specific Kerberos versions. If people are >>> okay with merging such code, then I guess this is fine; I would >>> personally not do so because there is not a clear point at which it can >>> be removed. At the very least, we should wait until we see what >>> versions of krb5 MIT is going to fix. >>> >>> Otherwise, looks good. >>> >>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>> >> >> python-krbV migration is blocking support for Python 3. The bug >> doesn't have any fix upstream yet and there are two bugs actually, the >> second one is in python-gssapi, which I've just reported [1]. Waiting >> for two bugs to be fixed could be detrimental to py3 migration as we >> don't have much time left. And I'm no longer sure that display_as > I don't buy this. > > We have plenty of time for solving these bugs. Remember, that Samba > DCE RPC bindings aren't migrated to Python 3 either and will not be > before release of Samba 4.4. For Samba 4.3 it is simply too late. That is no no reason to delay our ability to start testing Python3 support in FreeIPA. Only trusts depend on Samba. Most of FreeIPA does not. -- Petr Viktorin From ftweedal at redhat.com Tue Aug 25 11:49:05 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 25 Aug 2015 21:49:05 +1000 Subject: [Freeipa-devel] [PATCH] 0040 certprofile: prevent rename (modrdn) In-Reply-To: <20150825103942.GT22106@redhat.com> References: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> <20150825053711.GQ22106@redhat.com> <55DC3D5A.9060202@redhat.com> <20150825103942.GT22106@redhat.com> Message-ID: <20150825114905.GD15011@dhcp-40-8.bne.redhat.com> On Tue, Aug 25, 2015 at 01:39:42PM +0300, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Petr Vobornik wrote: > >On 08/25/2015 07:37 AM, Alexander Bokovoy wrote: > >>On Tue, 25 Aug 2015, Fraser Tweedale wrote: > >>>The attached patch fixes > >>>https://fedorahosted.org/freeipa/ticket/5247. > >>> > >>>Thanks, > >>>Fraser > >> > >>>From 2cb4ab6eeedccc3471ed9bf983add4687ecd5c1a Mon Sep 17 00:00:00 2001 > >>>From: Fraser Tweedale > >>>Date: Mon, 24 Aug 2015 20:25:10 -0400 > >>>Subject: [PATCH] certprofile: prevent rename (modrdn) > >>> > >>>Fixes: https://fedorahosted.org/freeipa/ticket/5247 > >>>--- > >>>ipalib/plugins/certprofile.py | 5 +++-- > >>>1 file changed, 3 insertions(+), 2 deletions(-) > >>> > >>>diff --git a/ipalib/plugins/certprofile.py > >>>b/ipalib/plugins/certprofile.py > >>>index > >>>007cc543406b7e5705fd7474f3685cd6a9ce6aca..a0ffa38608400860994c771e4eba81304ead27be > >>>100644 > >>>--- a/ipalib/plugins/certprofile.py > >>>+++ b/ipalib/plugins/certprofile.py > >>>@@ -323,8 +323,9 @@ class certprofile_mod(LDAPUpdate): > >>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, > >>>**options): > >>> ca_enabled_check() > >>> # Once a profile id is set it cannot be changed > >>>- if 'cn' in entry_attrs: > >>>- raise errors.ACIError(info=_('cn is immutable')) > >>>+ if 'rename' in options or 'cn' in entry_attrs: > >>>+ raise errors.ProtectedEntryError(label='certprofile', > >>>key=keys[0], > >>>+ reason=_('Certificate profiles cannot be renamed')) > >>> if 'file' in options: > >>> with self.api.Backend.ra_certprofile as profile_api: > >>> profile_api.disable_profile(keys[0]) > >>ACK > > > >can't we fix it by removing `rdn_is_primary_key = True`? > > > >That would also remove the --rename option. Yes it's an API change but if > >rename is forbidden than the option should not be even there, just the > >result error will different. > Well, that is another option, yes. Perhaps even a better one -- we have > plenty of places where rdn_is_primary_key is not actually used. > I filed a ticket for this: https://fedorahosted.org/freeipa/ticket/5254 There are a bunch of commands that have this situation - not just certprofile - so if we're going to break API in one place IMO we should do them all at once. From jcholast at redhat.com Tue Aug 25 11:52:34 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 13:52:34 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DC4796.9020303@redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> <55DC4796.9020303@redhat.com> Message-ID: <55DC5702.5030506@redhat.com> On 25.8.2015 12:46, Michael ?im??ek wrote: > > > On 2015-08-25 12:38, Alexander Bokovoy wrote: >> On Tue, 25 Aug 2015, Michael ?im??ek wrote: >>> >>> >>> On 2015-08-24 20:29, Robbie Harwood wrote: >>>> Michael ?im??ek writes: >>>> >>>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>>> >>>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>>> >>>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>>> >>>>>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>>>>> >>>>>>>> 3) ipa-adtrust-install fails with: >>>>>>>> >>>>>>>> admin password: >>>>>>>> >>>>>>>> Unrecognized error during check of admin rights: >>>>>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>>>>> >>>>>>>> Apparently there is a "user-show >>>>>>>> admin at abc.idm.lab.eng.brq.redhat.com" >>>>>>>> call where a "user-show admin" call should be. >>>>>>> >>>>>>> Fixed. python-gssapi has a display_as method that could pull the >>>>>>> name >>>>>>> from it, but it doesn't work in current version, therefore using >>>>>>> partition to split on '@' >>>> >>>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>>> >>>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>>> + user = >>>>> api.Command.user_show(principal.partition('@')[0])['result'] >>>> >>>> is working around a bug in specific Kerberos versions. If people are >>>> okay with merging such code, then I guess this is fine; I would >>>> personally not do so because there is not a clear point at which it can >>>> be removed. At the very least, we should wait until we see what >>>> versions of krb5 MIT is going to fix. >>>> >>>> Otherwise, looks good. >>>> >>>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>>> >>> >>> python-krbV migration is blocking support for Python 3. The bug >>> doesn't have any fix upstream yet and there are two bugs actually, the >>> second one is in python-gssapi, which I've just reported [1]. Waiting >>> for two bugs to be fixed could be detrimental to py3 migration as we >>> don't have much time left. And I'm no longer sure that display_as >> I don't buy this. >> >> We have plenty of time for solving these bugs. Remember, that Samba >> DCE RPC bindings aren't migrated to Python 3 either and will not be >> before release of Samba 4.4. For Samba 4.3 it is simply too late. >> >> So we are still far away from full Python3 migration for FreeIPA and >> waiting for solving these two bugs is OK. >> > > If fixing them solves anything at all. I planned to use > display_as(NameType.user), but when trying it on Name object with > name_type set (which doesn't trigger the segfault), it doesn't seem to > work either. I get: > gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The > operation or option is not available or unsupported, Minor (0): Unknown > error > > Robbie, can you clarify whether display_as could be actually used to get > the first component of the principal reliably? As I have written in the other thread, we use "principal.split('@')" in other parts of IPA, so "principal.partition('@')" should be OK as well. This patch works for me, so ACK. Unless there are any further objections, I would like to push it. > >>> could be used at all, as I'm getting "operation not supported" on >>> inputs that don't trigger any of the bugs. I don't think parsing a >>> string is a big problem. When there will be a different solution >>> available, I'll submit a new patch. I'm tracking python-gssapi's >>> issues on github and I won't dissapear after this is merged. >> Sure. It is not about you disappearing any time soon, we need to solve >> migration issues properly rather than hurrying up for whatever reasons. >> -- Jan Cholasta From abokovoy at redhat.com Tue Aug 25 12:15:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 15:15:27 +0300 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DC5631.8000406@redhat.com> References: <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> <55DC5631.8000406@redhat.com> Message-ID: <20150825121527.GU22106@redhat.com> On Tue, 25 Aug 2015, Petr Viktorin wrote: >On 08/25/2015 12:38 PM, Alexander Bokovoy wrote: >> On Tue, 25 Aug 2015, Michael ?im??ek wrote: >>> >>> >>> On 2015-08-24 20:29, Robbie Harwood wrote: >>>> Michael ?im??ek writes: >>>> >>>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>>> >>>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>>> >>>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>>> >>>>>>>> On 23.8.2015 23:27, Michael ?im??ek wrote: >>>>>>>> >>>>>>>> 3) ipa-adtrust-install fails with: >>>>>>>> >>>>>>>> admin password: >>>>>>>> >>>>>>>> Unrecognized error during check of admin rights: >>>>>>>> admin at abc.idm.lab.eng.brq.redhat.com: user not found >>>>>>>> >>>>>>>> Apparently there is a "user-show >>>>>>>> admin at abc.idm.lab.eng.brq.redhat.com" >>>>>>>> call where a "user-show admin" call should be. >>>>>>> >>>>>>> Fixed. python-gssapi has a display_as method that could pull the name >>>>>>> from it, but it doesn't work in current version, therefore using >>>>>>> partition to split on '@' >>>> >>>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>>> >>>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>>> + user = >>>>> api.Command.user_show(principal.partition('@')[0])['result'] >>>> >>>> is working around a bug in specific Kerberos versions. If people are >>>> okay with merging such code, then I guess this is fine; I would >>>> personally not do so because there is not a clear point at which it can >>>> be removed. At the very least, we should wait until we see what >>>> versions of krb5 MIT is going to fix. >>>> >>>> Otherwise, looks good. >>>> >>>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>>> >>> >>> python-krbV migration is blocking support for Python 3. The bug >>> doesn't have any fix upstream yet and there are two bugs actually, the >>> second one is in python-gssapi, which I've just reported [1]. Waiting >>> for two bugs to be fixed could be detrimental to py3 migration as we >>> don't have much time left. And I'm no longer sure that display_as >> I don't buy this. >> >> We have plenty of time for solving these bugs. Remember, that Samba >> DCE RPC bindings aren't migrated to Python 3 either and will not be >> before release of Samba 4.4. For Samba 4.3 it is simply too late. > >That is no no reason to delay our ability to start testing Python3 >support in FreeIPA. You can test that without deploying IPA as a part of a distribution. >Only trusts depend on Samba. Most of FreeIPA does not. Just demonstrate via COPR repo that you can actually provide packages this way and they do work. Let me be clear: I don't want to see feature set crippled in Fedora release because of Python 3 switch, for the sake of switching to Python 3 only. The work on migration can and should continue but not at an expense of dropping off sizeable part of our functionality. -- / Alexander Bokovoy From jcholast at redhat.com Tue Aug 25 12:18:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 14:18:29 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy Message-ID: <55DC5D15.7020002@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-477-spec-file-Add-Requires-pre-on-selinux-policy.patch Type: text/x-patch Size: 875 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 25 12:23:01 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 15:23:01 +0300 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DC5D15.7020002@redhat.com> References: <55DC5D15.7020002@redhat.com> Message-ID: <20150825122301.GV22106@redhat.com> On Tue, 25 Aug 2015, Jan Cholasta wrote: >Hi, > >the attached patch fixes . > >Honza > >-- >Jan Cholasta >From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >From: Jan Cholasta >Date: Tue, 25 Aug 2015 14:14:25 +0200 >Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy > >This prevents ipa-server-upgrade failures on SELinux AVCs because of old >selinux-policy version. > >https://fedorahosted.org/freeipa/ticket/5256 >--- > freeipa.spec.in | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index cba91fe..fd73cda 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -139,6 +139,7 @@ Requires: systemd-units >= 38 > Requires(pre): shadow-utils > Requires(pre): systemd-units > Requires(post): systemd-units >+Requires(pre): selinux-policy >= %{selinux_policy_version} > Requires: selinux-policy >= %{selinux_policy_version} > Requires(post): selinux-policy-base > Requires: slapi-nis >= 0.54.2-1 If we have it in Requires(pre), we don't need it in Requires, as Requires(pre) is a superset of guarantees that Requires gives you. Requires(pre) ensures that selinux-policy of specific version is installed before pre scripts of freeipa-server would run, be it in the same transaction or in a previous one. -- / Alexander Bokovoy From jcholast at redhat.com Tue Aug 25 12:27:29 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 14:27:29 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150825122301.GV22106@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> Message-ID: <55DC5F31.6070208@redhat.com> On 25.8.2015 14:23, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> -- >> Jan Cholasta > >> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >> From: Jan Cholasta >> Date: Tue, 25 Aug 2015 14:14:25 +0200 >> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >> >> This prevents ipa-server-upgrade failures on SELinux AVCs because of old >> selinux-policy version. >> >> https://fedorahosted.org/freeipa/ticket/5256 >> --- >> freeipa.spec.in | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index cba91fe..fd73cda 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >> Requires(pre): shadow-utils >> Requires(pre): systemd-units >> Requires(post): systemd-units >> +Requires(pre): selinux-policy >= %{selinux_policy_version} >> Requires: selinux-policy >= %{selinux_policy_version} >> Requires(post): selinux-policy-base >> Requires: slapi-nis >= 0.54.2-1 > If we have it in Requires(pre), we don't need it in Requires, as > Requires(pre) is a superset of guarantees that Requires gives you. Martin (CCed) told me Requires(pre) does not imply Requires. > > Requires(pre) ensures that selinux-policy of specific version is > installed before pre scripts of freeipa-server would run, be it in the > same transaction or in a previous one. > Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) be changed to Required(posttrans)? -- Jan Cholasta From dkupka at redhat.com Tue Aug 25 12:39:07 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 25 Aug 2015 14:39:07 +0200 Subject: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55DC2951.60508@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> <55DC2951.60508@redhat.com> Message-ID: <55DC61EB.4050205@redhat.com> On 25/08/15 10:37, David Kupka wrote: > On 24/08/15 16:51, Martin Basti wrote: >> >> >> On 08/20/2015 10:28 AM, David Kupka wrote: >>> On 31/07/15 13:32, Martin Basti wrote: >>>> On 30/07/15 14:38, Martin Basti wrote: >>>>> On 29/07/15 16:12, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5087 >>>>> NACK >>>>> >>>>> You forgot to update API.txt file >>> >>> Thanks for catching that. Updated patch attached. >>> >>>>> >>>> I'm just curious, what is the reason to check if forward zone exists? >>>> >>>> IMO forwardzone must exists somewhere as the master zone. I don't think >>>> we should check forwardzones, this may give too many false positive >>>> errors. >>> >>> AIUI if the zone exist somewhere and is resolvable there is no need to >>> add it as a forward zone. If user for some reason want to do it he's >>> hiding the original zone and we should not allow this (without --force). >>> >> Note: Petr2 agreed with David's solution >> >> LGTM, works as expected, but this patch prevents users to add >> conflicting zones via webUI (there is no --force field). >> We should improve webUI together with this patch. >> >> Martin^2 >> >>>> >>>> Martin^2 >>>> >>> >> > > The '--force' option was not in WebUI before even though it was in API. > IMO we should not expose '--force' options in WebUI at all. > Added similar options to ipa-{server,dns}-install and reworked the patch to not duplicate the code. Updated patch and one new attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0058.2-dns-do-not-add-forward-zone-if-it-is-already-resolva.patch Type: text/x-patch Size: 7598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0064-dns-Check-if-domain-already-exists.patch Type: text/x-patch Size: 3834 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 25 12:50:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 15:50:04 +0300 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DC5F31.6070208@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> Message-ID: <20150825125004.GW22106@redhat.com> On Tue, 25 Aug 2015, Jan Cholasta wrote: >On 25.8.2015 14:23, Alexander Bokovoy wrote: >>On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>Hi, >>> >>>the attached patch fixes . >>> >>>Honza >>> >>>-- >>>Jan Cholasta >> >>>From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>From: Jan Cholasta >>>Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>> >>>This prevents ipa-server-upgrade failures on SELinux AVCs because of old >>>selinux-policy version. >>> >>>https://fedorahosted.org/freeipa/ticket/5256 >>>--- >>>freeipa.spec.in | 1 + >>>1 file changed, 1 insertion(+) >>> >>>diff --git a/freeipa.spec.in b/freeipa.spec.in >>>index cba91fe..fd73cda 100644 >>>--- a/freeipa.spec.in >>>+++ b/freeipa.spec.in >>>@@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>Requires(pre): shadow-utils >>>Requires(pre): systemd-units >>>Requires(post): systemd-units >>>+Requires(pre): selinux-policy >= %{selinux_policy_version} >>>Requires: selinux-policy >= %{selinux_policy_version} >>>Requires(post): selinux-policy-base >>>Requires: slapi-nis >= 0.54.2-1 >>If we have it in Requires(pre), we don't need it in Requires, as >>Requires(pre) is a superset of guarantees that Requires gives you. > >Martin (CCed) told me Requires(pre) does not imply Requires. See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): ---------------- Since the only way out of a dependency loop is to snip the loop somewhere, rpm uses hints from Requires: dependencies to distinguish co-requisite (these are not needed to install, only to use, a package) from pre-requisite (these are guaranteed to be installed before the package that includes the dependency) relations. ---------------- >> >>Requires(pre) ensures that selinux-policy of specific version is >>installed before pre scripts of freeipa-server would run, be it in the >>same transaction or in a previous one. >> > >Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >be changed to Required(posttrans)? I don't think there is posttrans target. Perhaps, we can just make sure Requires(post) is enough. -- / Alexander Bokovoy From pviktori at redhat.com Tue Aug 25 13:05:25 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Aug 2015 15:05:25 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DC45DD.1040907@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> <55DC45DD.1040907@redhat.com> Message-ID: <55DC6815.9090804@redhat.com> On 08/25/2015 12:39 PM, Christian Heimes wrote: > On 2015-08-24 17:31, Petr Viktorin wrote: >>>>> 0701.2-Use-Python3-compatible-dict-method-names >>>>> NACK >>>>> Why are you replacing iteritems() with items() instead of using >>>>> six.iteritems()? >> >> It looks cleaner, and it will be easier to clean up after six is dropped. >> Also, the performance difference is negligible if the whole thing is >> iterated over. (On small dicts, which are the majority of what iteritems >> was used on, items() is actually a bit faster on my machine.) > > Right, for small dicts the speed difference is negligible and favors the > items() over iteritems(). For medium sized and large dicts the iterators > are faster and consume less memory. > > I'm preferring iterator methods everywhere because I don't have to worry > about dict sizes. > >>>>> 0710.2-Modernize-use-of-range >>>>> NACK >>>>> Please use six.moves.range. It defaults to xrange() in Python 2. >> >> Why? What is the benefit of xrange in these situations? >> >> Like with iteritems in 0701, when iterating over the whole thing, the >> performance difference is negligible. I don't think a few microseconds >> outside of tight loops are worth the verbosity. > > It's the same reasoning as in 0701. As long as you have a small range, > it doesn't make a difference. For large ranges the additional memory > usage can be problematic. > > In all above cases the iterator methods and generator functions are a > safer choice. A malicious user can abuse the non-iterative methods for > DoS attacks. As long as the input can't be controlled by a user and the > range/dict/set/list is small, the non-iterative methods are fine. You > have to verify every location, though. Keep in mind that for dicts, all the data is in memory already (in the dict). Are you worried about DoS from an extra list of references to existing objects? > I'm usually too busy with other stuff (aka lazy) to verify these > preconditions... I changed one questionable use of range. The other ones are: ipalib/plugins/dns.py: for i in range(len(relative_record_name) (max. ~255, verified by DNSName) ipaserver/install/dnskeysyncinstance.py: for _ in range(0, 16)) (16) ipaserver/install/ipa_otptoken_import.py: for i in range(1, blocks + 1): (about 7) ipaserver/install/ipa_otptoken_import.py: for k in range(mac.digest_size): (16) ipatests/data.py: for d in range(256)) (256) Plus tests, where it's rarely above 10. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0710.4-Modernize-use-of-range.patch Type: text/x-patch Size: 18052 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0711.4-Convert-zip-result-to-list.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: From simo at redhat.com Tue Aug 25 13:37:50 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Aug 2015 09:37:50 -0400 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <55DC36A4.5000201@redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> <55DC36A4.5000201@redhat.com> Message-ID: <1440509870.8138.13.camel@willson.usersys.redhat.com> On Tue, 2015-08-25 at 11:34 +0200, Jan Cholasta wrote: > On 25.8.2015 11:25, Jan Cholasta wrote: > > On 24.8.2015 19:51, Simo Sorce wrote: > >> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in > >> ipaserver/install when you always need both files to do anything around > >> installation of the ca ? > >> > >> Is there a motivation ? > >> Or can I simply provide a patch to remove the ca.py and kra.py files an > >> unify all code in the proper *instance.py file ? > > > > ca.py and kra.py are the proper files ready to be migrated to the new > > install framework, cainstance.py and krainstance.py will be removed. > > ... once the migration is done. (Hit send button too fast.) > > The motivation is that *instance.py do not provide a uniform interface, > have a lot of redundant and duplicate stuff and are generally unfit for > any further extension. I have been changing only the instance files, so we are going in different directions. I do not really care what file we are going into, but there is a lot of code in the installer now that does not tell the user a step is being done, while instances do that through the step interface. The step interface is also a very good way to let someone that read the code see what is going on and follow each step. Are you proposing to stop going through the instances steps ? I found the current way kra and ca installation is setup basically a regression, it took me a *lot* longer that it should be needed to follow through all the steps that are really taken. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Aug 25 13:52:21 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 15:52:21 +0200 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <1440509870.8138.13.camel@willson.usersys.redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> <55DC36A4.5000201@redhat.com> <1440509870.8138.13.camel@willson.usersys.redhat.com> Message-ID: <55DC7315.4010900@redhat.com> On 25.8.2015 15:37, Simo Sorce wrote: > On Tue, 2015-08-25 at 11:34 +0200, Jan Cholasta wrote: >> On 25.8.2015 11:25, Jan Cholasta wrote: >>> On 24.8.2015 19:51, Simo Sorce wrote: >>>> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in >>>> ipaserver/install when you always need both files to do anything around >>>> installation of the ca ? >>>> >>>> Is there a motivation ? >>>> Or can I simply provide a patch to remove the ca.py and kra.py files an >>>> unify all code in the proper *instance.py file ? >>> >>> ca.py and kra.py are the proper files ready to be migrated to the new >>> install framework, cainstance.py and krainstance.py will be removed. >> >> ... once the migration is done. (Hit send button too fast.) >> >> The motivation is that *instance.py do not provide a uniform interface, >> have a lot of redundant and duplicate stuff and are generally unfit for >> any further extension. > > I have been changing only the instance files, so we are going in > different directions. I don't see how, {ca,kra}instance.py code is called from {ca,kra}.py. {ca,kra}.py contains all the code that is actually needed to install CA/KRA that is not in {ca,kra}instance.py and was previously scattered around ipa-{server,replica,ca,kra}-install. > > I do not really care what file we are going into, but there is a lot of > code in the installer now that does not tell the user a step is being > done, while instances do that through the step interface. This code was always there, we only moved it to a single location. See git history. > > The step interface is also a very good way to let someone that read the > code see what is going on and follow each step. > > Are you proposing to stop going through the instances steps ? I found > the current way kra and ca installation is setup basically a regression, > it took me a *lot* longer that it should be needed to follow through all > the steps that are really taken. Again, we only moved the code around, and I don't think we created any regressions. > > Simo. > -- Jan Cholasta From pspacek at redhat.com Tue Aug 25 14:06:06 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Aug 2015 16:06:06 +0200 Subject: [Freeipa-devel] Wiki Access In-Reply-To: <55B934C3.6030101@fedoraproject.org> References: <55B930A1.7080207@fedoraproject.org> <55B93352.1040908@redhat.com> <55B934C3.6030101@fedoraproject.org> Message-ID: <55DC764E.1060901@redhat.com> On 29.7.2015 22:17, Dan Mossor wrote: > On 07/29/2015 03:10 PM, Rob Crittenden wrote: >> Dan Mossor wrote: >>> Greetings FreeIPA devs. I just wanted to express my sincere thank you >>> for all y'all do - FreeIPA is an awesome product that just keeps getting >>> better and better. >>> >>> One area where y'all desparately need help with, however, is in >>> documentation. I recently had to rescue a co-worker from following a >>> document that was no longer applicable[0], and in researching how to fix >>> it I found your Wiki TODO list [1]. >>> >>> I would like to ask for editor access to the FreeIPA wiki so I can >>> contribute back some of the knowledge I've gleaned from the user list, >>> IRC channel, and copious amounts of research I've been doing in >>> deploying FreeIPA at my workplace. >>> >>> Regards, >>> Dan "danofsatx" Mossor >>> >>> [0] >>> http://www.freeipa.org/page/Active_Directory_trust_setup#On_IPA_server >>> [1] http://www.freeipa.org/page/Wiki_TODO >> >> You should just need a FAS account, >> https://admin.fedoraproject.org/accounts/user/new if you don't already >> have one. >> >> rob > I've got one - I just didn't see the login link on the bottom of the page. > > Incidentally, this simply points out yet another area that needs correction in > the wiki, as it states to email the freeipa-devel list to request access. Thanks for catching it! Fix landed on http://www.freeipa.org/page/Contribute#Documentation . Are you okay with the text? -- Petr^2 Spacek From simo at redhat.com Tue Aug 25 14:09:34 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Aug 2015 10:09:34 -0400 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <55DC7315.4010900@redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> <55DC36A4.5000201@redhat.com> <1440509870.8138.13.camel@willson.usersys.redhat.com> <55DC7315.4010900@redhat.com> Message-ID: <1440511774.8138.21.camel@willson.usersys.redhat.com> On Tue, 2015-08-25 at 15:52 +0200, Jan Cholasta wrote: > On 25.8.2015 15:37, Simo Sorce wrote: > > On Tue, 2015-08-25 at 11:34 +0200, Jan Cholasta wrote: > >> On 25.8.2015 11:25, Jan Cholasta wrote: > >>> On 24.8.2015 19:51, Simo Sorce wrote: > >>>> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in > >>>> ipaserver/install when you always need both files to do anything around > >>>> installation of the ca ? > >>>> > >>>> Is there a motivation ? > >>>> Or can I simply provide a patch to remove the ca.py and kra.py files an > >>>> unify all code in the proper *instance.py file ? > >>> > >>> ca.py and kra.py are the proper files ready to be migrated to the new > >>> install framework, cainstance.py and krainstance.py will be removed. > >> > >> ... once the migration is done. (Hit send button too fast.) > >> > >> The motivation is that *instance.py do not provide a uniform interface, > >> have a lot of redundant and duplicate stuff and are generally unfit for > >> any further extension. > > > > I have been changing only the instance files, so we are going in > > different directions. > > I don't see how, {ca,kra}instance.py code is called from {ca,kra}.py. > {ca,kra}.py contains all the code that is actually needed to install > CA/KRA that is not in {ca,kra}instance.py and was previously scattered > around ipa-{server,replica,ca,kra}-install. > > > > > I do not really care what file we are going into, but there is a lot of > > code in the installer now that does not tell the user a step is being > > done, while instances do that through the step interface. > > This code was always there, we only moved it to a single location. See > git history. > > > > > The step interface is also a very good way to let someone that read the > > code see what is going on and follow each step. > > > > Are you proposing to stop going through the instances steps ? I found > > the current way kra and ca installation is setup basically a regression, > > it took me a *lot* longer that it should be needed to follow through all > > the steps that are really taken. > > Again, we only moved the code around, and I don't think we created any > regressions. Ok, so the plan is just to move the CAInstance class and code *as is* from cainstance.py to ca.py ? I guess I am confused about what is your plan around this exactly. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Aug 25 14:19:05 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Aug 2015 10:19:05 -0400 Subject: [Freeipa-devel] [PATCH] 0040 certprofile: prevent rename (modrdn) In-Reply-To: <20150825114905.GD15011@dhcp-40-8.bne.redhat.com> References: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> <20150825053711.GQ22106@redhat.com> <55DC3D5A.9060202@redhat.com> <20150825103942.GT22106@redhat.com> <20150825114905.GD15011@dhcp-40-8.bne.redhat.com> Message-ID: <1440512345.8138.22.camel@willson.usersys.redhat.com> On Tue, 2015-08-25 at 21:49 +1000, Fraser Tweedale wrote: > On Tue, Aug 25, 2015 at 01:39:42PM +0300, Alexander Bokovoy wrote: > > On Tue, 25 Aug 2015, Petr Vobornik wrote: > > >On 08/25/2015 07:37 AM, Alexander Bokovoy wrote: > > >>On Tue, 25 Aug 2015, Fraser Tweedale wrote: > > >>>The attached patch fixes > > >>>https://fedorahosted.org/freeipa/ticket/5247. > > >>> > > >>>Thanks, > > >>>Fraser > > >> > > >>>From 2cb4ab6eeedccc3471ed9bf983add4687ecd5c1a Mon Sep 17 00:00:00 2001 > > >>>From: Fraser Tweedale > > >>>Date: Mon, 24 Aug 2015 20:25:10 -0400 > > >>>Subject: [PATCH] certprofile: prevent rename (modrdn) > > >>> > > >>>Fixes: https://fedorahosted.org/freeipa/ticket/5247 > > >>>--- > > >>>ipalib/plugins/certprofile.py | 5 +++-- > > >>>1 file changed, 3 insertions(+), 2 deletions(-) > > >>> > > >>>diff --git a/ipalib/plugins/certprofile.py > > >>>b/ipalib/plugins/certprofile.py > > >>>index > > >>>007cc543406b7e5705fd7474f3685cd6a9ce6aca..a0ffa38608400860994c771e4eba81304ead27be > > >>>100644 > > >>>--- a/ipalib/plugins/certprofile.py > > >>>+++ b/ipalib/plugins/certprofile.py > > >>>@@ -323,8 +323,9 @@ class certprofile_mod(LDAPUpdate): > > >>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, > > >>>**options): > > >>> ca_enabled_check() > > >>> # Once a profile id is set it cannot be changed > > >>>- if 'cn' in entry_attrs: > > >>>- raise errors.ACIError(info=_('cn is immutable')) > > >>>+ if 'rename' in options or 'cn' in entry_attrs: > > >>>+ raise errors.ProtectedEntryError(label='certprofile', > > >>>key=keys[0], > > >>>+ reason=_('Certificate profiles cannot be renamed')) > > >>> if 'file' in options: > > >>> with self.api.Backend.ra_certprofile as profile_api: > > >>> profile_api.disable_profile(keys[0]) > > >>ACK > > > > > >can't we fix it by removing `rdn_is_primary_key = True`? > > > > > >That would also remove the --rename option. Yes it's an API change but if > > >rename is forbidden than the option should not be even there, just the > > >result error will different. > > Well, that is another option, yes. Perhaps even a better one -- we have > > plenty of places where rdn_is_primary_key is not actually used. > > > I filed a ticket for this: https://fedorahosted.org/freeipa/ticket/5254 > > There are a bunch of commands that have this situation - not just > certprofile - so if we're going to break API in one place IMO we > should do them all at once. Why do we need to break the API ? Just deny it. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Aug 25 14:22:31 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 16:22:31 +0200 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <1440511774.8138.21.camel@willson.usersys.redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> <55DC36A4.5000201@redhat.com> <1440509870.8138.13.camel@willson.usersys.redhat.com> <55DC7315.4010900@redhat.com> <1440511774.8138.21.camel@willson.usersys.redhat.com> Message-ID: <55DC7A27.5000000@redhat.com> On 25.8.2015 16:09, Simo Sorce wrote: > On Tue, 2015-08-25 at 15:52 +0200, Jan Cholasta wrote: >> On 25.8.2015 15:37, Simo Sorce wrote: >>> On Tue, 2015-08-25 at 11:34 +0200, Jan Cholasta wrote: >>>> On 25.8.2015 11:25, Jan Cholasta wrote: >>>>> On 24.8.2015 19:51, Simo Sorce wrote: >>>>>> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in >>>>>> ipaserver/install when you always need both files to do anything around >>>>>> installation of the ca ? >>>>>> >>>>>> Is there a motivation ? >>>>>> Or can I simply provide a patch to remove the ca.py and kra.py files an >>>>>> unify all code in the proper *instance.py file ? >>>>> >>>>> ca.py and kra.py are the proper files ready to be migrated to the new >>>>> install framework, cainstance.py and krainstance.py will be removed. >>>> >>>> ... once the migration is done. (Hit send button too fast.) >>>> >>>> The motivation is that *instance.py do not provide a uniform interface, >>>> have a lot of redundant and duplicate stuff and are generally unfit for >>>> any further extension. >>> >>> I have been changing only the instance files, so we are going in >>> different directions. >> >> I don't see how, {ca,kra}instance.py code is called from {ca,kra}.py. >> {ca,kra}.py contains all the code that is actually needed to install >> CA/KRA that is not in {ca,kra}instance.py and was previously scattered >> around ipa-{server,replica,ca,kra}-install. >> >>> >>> I do not really care what file we are going into, but there is a lot of >>> code in the installer now that does not tell the user a step is being >>> done, while instances do that through the step interface. >> >> This code was always there, we only moved it to a single location. See >> git history. >> >>> >>> The step interface is also a very good way to let someone that read the >>> code see what is going on and follow each step. >>> >>> Are you proposing to stop going through the instances steps ? I found >>> the current way kra and ca installation is setup basically a regression, >>> it took me a *lot* longer that it should be needed to follow through all >>> the steps that are really taken. >> >> Again, we only moved the code around, and I don't think we created any >> regressions. > > Ok, so the plan is just to move the CAInstance class and code *as is* > from cainstance.py to ca.py ?I guess I am confused about what is your > plan around this exactly. The code in CAInstance will be gradually migrated to a new class in ca.py which uses the new install framework. We started with the top-level ipa-server-install and ipa-replica-install code, which is still not done, but you can see it for reference on how it will look like (ipaserver/install/server/*.py, especially the classes at the bottom of the files). -- Jan Cholasta From jcholast at redhat.com Tue Aug 25 14:37:50 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Aug 2015 16:37:50 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150825125004.GW22106@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> Message-ID: <55DC7DBE.4030605@redhat.com> On 25.8.2015 14:50, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Jan Cholasta wrote: >> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>>> >>>> -- >>>> Jan Cholasta >>> >>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>> From: Jan Cholasta >>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>> >>>> This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>> old >>>> selinux-policy version. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5256 >>>> --- >>>> freeipa.spec.in | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>> index cba91fe..fd73cda 100644 >>>> --- a/freeipa.spec.in >>>> +++ b/freeipa.spec.in >>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>> Requires(pre): shadow-utils >>>> Requires(pre): systemd-units >>>> Requires(post): systemd-units >>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>> Requires: selinux-policy >= %{selinux_policy_version} >>>> Requires(post): selinux-policy-base >>>> Requires: slapi-nis >= 0.54.2-1 >>> If we have it in Requires(pre), we don't need it in Requires, as >>> Requires(pre) is a superset of guarantees that Requires gives you. >> >> Martin (CCed) told me Requires(pre) does not imply Requires. > See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): > ---------------- > Since the only way out of a dependency loop is to snip the loop > somewhere, rpm uses hints from Requires: dependencies to distinguish > co-requisite (these are not needed to install, only to use, a package) > from pre-requisite (these are guaranteed to be installed before the > package that includes the dependency) relations. > ---------------- > >>> >>> Requires(pre) ensures that selinux-policy of specific version is >>> installed before pre scripts of freeipa-server would run, be it in the >>> same transaction or in a previous one. >>> >> >> Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >> be changed to Required(posttrans)? > I don't think there is posttrans target. Perhaps, we can just make sure > Requires(post) is enough. OK, let's try that. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-477.1-spec-file-Add-Requires-pre-on-selinux-policy.patch Type: text/x-patch Size: 924 bytes Desc: not available URL: From pspacek at redhat.com Tue Aug 25 14:44:32 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Aug 2015 16:44:32 +0200 Subject: [Freeipa-devel] [PATCH 0300] DNSSEC: fix forwardzone forwarders check In-Reply-To: <55DB1E56.7000307@redhat.com> References: <55DB1E56.7000307@redhat.com> Message-ID: <55DC7F50.9030601@redhat.com> On 24.8.2015 15:38, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5179 > > patch attached ACK, good catch! -- Petr^2 Spacek From mbasti at redhat.com Tue Aug 25 14:51:39 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Aug 2015 16:51:39 +0200 Subject: [Freeipa-devel] [PATCH] 371 Added support for changing vault encryption. In-Reply-To: <55D57AEC.4030907@redhat.com> References: <55BFF741.6080302@redhat.com> <55CC9638.8060801@redhat.com> <55CCCFC9.1060504@redhat.com> <55D45360.4080003@redhat.com> <55D57AEC.4030907@redhat.com> Message-ID: <55DC80FB.1000306@redhat.com> On 08/20/2015 08:59 AM, Endi Sukma Dewata wrote: > On 8/19/2015 4:58 AM, Martin Basti wrote: >> On 08/13/2015 07:11 PM, Endi Sukma Dewata wrote: >>> On 8/13/2015 8:06 AM, Martin Basti wrote: >>>>> The vault-mod command has been modified to support changing vault >>>>> encryption attributes (i.e. type, password, public/private keys) >>>>> in addition to normal attributes (i.e. description). Changing the >>>>> encryption requires retrieving the stored secret with the old >>>>> attributes and rearchieving it with the new attributes. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5176 >>>>> >>>> Hello, does this patch require any additional patches? >>>> >>>> I have current master branch and I cannot apply it. >>>> >>>> git am >>>> freeipa-edewata-0371-Added-support-for-changing-vault-encryption.patch >>>> -3 >>>> >>>> Applying: Added support for changing vault encryption. >>>> error: invalid object 100644 3b62822366a62c90f843a6293589c28383e782ef >>>> for 'ipalib/plugins/vault.py' >>>> fatal: git-write-tree: error building trees >>>> Repository lacks necessary blobs to fall back on 3-way merge. >>>> >>>> >>>> Martin^2 >>> >>> New patch attached. It requires patch #0369-3. >>> >> I cannot apply patch (and 369-3 was pushed) >> >> git am >> freeipa-edewata-0371-1-Added-support-for-changing-vault-encryption.patch >> -3 >> Applying: Added support for changing vault encryption. >> error: invalid object 100644 5d367b376ef41427ed983f3eafe120ed477018d2 >> for 'ipalib/plugins/vault.py' >> fatal: git-write-tree: error building trees >> Repository lacks necessary blobs to fall back on 3-way merge. >> Cannot fall back to three-way merge. > > Rebased. > ACK works as expected. This is optional nitpick, we can fix it later: 1) This should be asymmetric vault not symmetric + Modify symmetric vault keys: + ipa vault-mod + [--user |--service |--shared] + --private-key-file + --public-key-file From pvoborni at redhat.com Tue Aug 25 14:54:42 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 16:54:42 +0200 Subject: [Freeipa-devel] [PATCH] 913 fix missing information in object metadata Message-ID: <55DC81B2.4080109@redhat.com> Missing 'required' values in takes_params causes Web UI to treat required fields as optional. Regression caused by ba0a1c6b33e2519a48754602413c8379fb1f0ff1 https://fedorahosted.org/freeipa/ticket/5258 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0913-fix-missing-information-in-object-metadata.patch Type: text/x-patch Size: 1700 bytes Desc: not available URL: From pspacek at redhat.com Tue Aug 25 15:08:30 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Aug 2015 17:08:30 +0200 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <559D6455.4040704@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> Message-ID: <55DC84EE.4010102@redhat.com> On 8.7.2015 19:56, Rich Megginson wrote: > On 07/08/2015 10:11 AM, Petr Spacek wrote: >> Assuming that Designate wants to own DNS and be Primary Master, it would be >> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >> alongside their own JSON API. >> >> The JSON API is superset of DNS UPDATE protocol because it allows to add zones >> but still, standard protocol would mean that standard client (possibly guest >> OS inside VM) can update its records without any OpenStack dependency, which >> is very much desirable. >> >> The use case here is to allow the guest OS to publish it's SSH key (which was >> generated inside the VM after first boot) to prevent Man in the middle >> attacks. The same goes for all other sorts of DANE/DNSSEC data or service >> discovery using DNS, where a guest/container running a distributed service can >> publish it's existence in DNS. >> >> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >> widely supported, too. >> >> So DNS UPDATE is my biggest wish :-) >> > Ok. There was a Designate blueprint for such a feature, but I can't find it > and neither can the Designate guys. There is a mention of nsupdate in the > minidns blueprint, but that's about it. The fact that Designate upstream > can't find the bp suggests that this is not a high priority for them and will > not likely implement it on their own i.e. we would have to contribute this > feature. > > If Designate had such a feature, how would this help us integrate FreeIPA with > Designate? It would greatly simplify integration with FreeIPA. There is a plan to support DNS updates as described in RFC 2136 to push updates from FreeIPA servers to external DNS servers, so we could use the same code to integrate with AD & Designate at the same time. (I'm sorry for the delay, it somehow slipped through the cracks.) -- Petr^2 Spacek From mkosek at redhat.com Tue Aug 25 15:12:36 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Aug 2015 17:12:36 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DC7DBE.4030605@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> Message-ID: <55DC85E4.5090709@redhat.com> On 08/25/2015 04:37 PM, Jan Cholasta wrote: > On 25.8.2015 14:50, Alexander Bokovoy wrote: >> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>>> >>>>> -- >>>>> Jan Cholasta >>>> >>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>>> From: Jan Cholasta >>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>> >>>>> This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>>> old >>>>> selinux-policy version. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>> --- >>>>> freeipa.spec.in | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>> index cba91fe..fd73cda 100644 >>>>> --- a/freeipa.spec.in >>>>> +++ b/freeipa.spec.in >>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>> Requires(pre): shadow-utils >>>>> Requires(pre): systemd-units >>>>> Requires(post): systemd-units >>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>> Requires(post): selinux-policy-base >>>>> Requires: slapi-nis >= 0.54.2-1 >>>> If we have it in Requires(pre), we don't need it in Requires, as >>>> Requires(pre) is a superset of guarantees that Requires gives you. >>> >>> Martin (CCed) told me Requires(pre) does not imply Requires. >> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >> ---------------- >> Since the only way out of a dependency loop is to snip the loop >> somewhere, rpm uses hints from Requires: dependencies to distinguish >> co-requisite (these are not needed to install, only to use, a package) >> from pre-requisite (these are guaranteed to be installed before the >> package that includes the dependency) relations. >> ---------------- >> >>>> >>>> Requires(pre) ensures that selinux-policy of specific version is >>>> installed before pre scripts of freeipa-server would run, be it in the >>>> same transaction or in a previous one. >>>> >>> >>> Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >>> be changed to Required(posttrans)? >> I don't think there is posttrans target. Perhaps, we can just make sure >> Requires(post) is enough. > > OK, let's try that. Updated patch attached. > Will this really make a difference? I thought the problem is caused by selinux-policy being installed after freeipa-server package upgrade. We already have Requires on selinux-policy, so I am not sure what is actually changed by this patch. From pvoborni at redhat.com Tue Aug 25 15:19:06 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 17:19:06 +0200 Subject: [Freeipa-devel] [PATCH] 914 webui: add option to establish bidirectional trust Message-ID: <55DC876A.9010207@redhat.com> https://fedorahosted.org/freeipa/ticket/5259 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0914-webui-add-option-to-establish-bidirectional-trust.patch Type: text/x-patch Size: 1561 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 25 15:37:12 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 18:37:12 +0300 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DC85E4.5090709@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> Message-ID: <20150825153711.GZ22106@redhat.com> On Tue, 25 Aug 2015, Martin Kosek wrote: >On 08/25/2015 04:37 PM, Jan Cholasta wrote: >> On 25.8.2015 14:50, Alexander Bokovoy wrote: >>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patch fixes >>>>>> . >>>>>> >>>>>> Honza >>>>>> >>>>>> -- >>>>>> Jan Cholasta >>>>> >>>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>>>> From: Jan Cholasta >>>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>> >>>>>> This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>>>> old >>>>>> selinux-policy version. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>>> --- >>>>>> freeipa.spec.in | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>> index cba91fe..fd73cda 100644 >>>>>> --- a/freeipa.spec.in >>>>>> +++ b/freeipa.spec.in >>>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>> Requires(pre): shadow-utils >>>>>> Requires(pre): systemd-units >>>>>> Requires(post): systemd-units >>>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>>> Requires(post): selinux-policy-base >>>>>> Requires: slapi-nis >= 0.54.2-1 >>>>> If we have it in Requires(pre), we don't need it in Requires, as >>>>> Requires(pre) is a superset of guarantees that Requires gives you. >>>> >>>> Martin (CCed) told me Requires(pre) does not imply Requires. >>> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>> ---------------- >>> Since the only way out of a dependency loop is to snip the loop >>> somewhere, rpm uses hints from Requires: dependencies to distinguish >>> co-requisite (these are not needed to install, only to use, a package) >>> from pre-requisite (these are guaranteed to be installed before the >>> package that includes the dependency) relations. >>> ---------------- >>> >>>>> >>>>> Requires(pre) ensures that selinux-policy of specific version is >>>>> installed before pre scripts of freeipa-server would run, be it in the >>>>> same transaction or in a previous one. >>>>> >>>> >>>> Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >>>> be changed to Required(posttrans)? >>> I don't think there is posttrans target. Perhaps, we can just make sure >>> Requires(post) is enough. >> >> OK, let's try that. Updated patch attached. >> > >Will this really make a difference? I thought the problem is caused by >selinux-policy being installed after freeipa-server package upgrade. We already >have Requires on selinux-policy, so I am not sure what is actually changed by >this patch. The change is that with Requires(pre) or Requires(post) we are guaranteed that selinux-policy is installed and available before our pre or post scriptlets are run. With Requires only we are not guaranteed to be installed after selinux-policy, only that it would be available as part of the same transaction we are installed in. We don't really need to have Requires(pre) because we don't rely on selinux-policy being available in pre scriptlet. Forcing Requires(pre) doesn't help anyone else (rpm/yum/dnf need to solve dependency loops and we are only complicating with Requires(pre) if we don't actually need it). Thus, choosing Require(post) is more correct from distribution point of view. -- / Alexander Bokovoy From mbasti at redhat.com Tue Aug 25 15:38:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 25 Aug 2015 17:38:55 +0200 Subject: [Freeipa-devel] [PATCH 0300] DNSSEC: fix forwardzone forwarders check In-Reply-To: <55DC7F50.9030601@redhat.com> References: <55DB1E56.7000307@redhat.com> <55DC7F50.9030601@redhat.com> Message-ID: <55DC8C0F.4070800@redhat.com> On 08/25/2015 04:44 PM, Petr Spacek wrote: > On 24.8.2015 15:38, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5179 >> >> patch attached > ACK, good catch! > Thanks Pushed to: master: b4daa45baad9dca020540ecde1b1e7a9b98b1995 ipa-4-2: 32fedf03ebb0c8798cad0145e7adde58e4e9d09c From simo at redhat.com Tue Aug 25 15:50:48 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Aug 2015 11:50:48 -0400 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <55DC7A27.5000000@redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> <55DC36A4.5000201@redhat.com> <1440509870.8138.13.camel@willson.usersys.redhat.com> <55DC7315.4010900@redhat.com> <1440511774.8138.21.camel@willson.usersys.redhat.com> <55DC7A27.5000000@redhat.com> Message-ID: <1440517848.8138.32.camel@willson.usersys.redhat.com> On Tue, 2015-08-25 at 16:22 +0200, Jan Cholasta wrote: > On 25.8.2015 16:09, Simo Sorce wrote: > > On Tue, 2015-08-25 at 15:52 +0200, Jan Cholasta wrote: > >> On 25.8.2015 15:37, Simo Sorce wrote: > >>> On Tue, 2015-08-25 at 11:34 +0200, Jan Cholasta wrote: > >>>> On 25.8.2015 11:25, Jan Cholasta wrote: > >>>>> On 24.8.2015 19:51, Simo Sorce wrote: > >>>>>> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in > >>>>>> ipaserver/install when you always need both files to do anything around > >>>>>> installation of the ca ? > >>>>>> > >>>>>> Is there a motivation ? > >>>>>> Or can I simply provide a patch to remove the ca.py and kra.py files an > >>>>>> unify all code in the proper *instance.py file ? > >>>>> > >>>>> ca.py and kra.py are the proper files ready to be migrated to the new > >>>>> install framework, cainstance.py and krainstance.py will be removed. > >>>> > >>>> ... once the migration is done. (Hit send button too fast.) > >>>> > >>>> The motivation is that *instance.py do not provide a uniform interface, > >>>> have a lot of redundant and duplicate stuff and are generally unfit for > >>>> any further extension. > >>> > >>> I have been changing only the instance files, so we are going in > >>> different directions. > >> > >> I don't see how, {ca,kra}instance.py code is called from {ca,kra}.py. > >> {ca,kra}.py contains all the code that is actually needed to install > >> CA/KRA that is not in {ca,kra}instance.py and was previously scattered > >> around ipa-{server,replica,ca,kra}-install. > >> > >>> > >>> I do not really care what file we are going into, but there is a lot of > >>> code in the installer now that does not tell the user a step is being > >>> done, while instances do that through the step interface. > >> > >> This code was always there, we only moved it to a single location. See > >> git history. > >> > >>> > >>> The step interface is also a very good way to let someone that read the > >>> code see what is going on and follow each step. > >>> > >>> Are you proposing to stop going through the instances steps ? I found > >>> the current way kra and ca installation is setup basically a regression, > >>> it took me a *lot* longer that it should be needed to follow through all > >>> the steps that are really taken. > >> > >> Again, we only moved the code around, and I don't think we created any > >> regressions. > > > > Ok, so the plan is just to move the CAInstance class and code *as is* > > from cainstance.py to ca.py ?I guess I am confused about what is your > > plan around this exactly. > > The code in CAInstance will be gradually migrated to a new class in > ca.py which uses the new install framework. We started with the > top-level ipa-server-install and ipa-replica-install code, which is > still not done, but you can see it for reference on how it will look > like (ipaserver/install/server/*.py, especially the classes at the > bottom of the files). Well I had to modify server/replicainstall.py quite radically, I had to create a new set of promote_check and promote functions there. So we are back to duplicated code, sorry (no way around it). However the functions in server/replicainstall.py still use the instances mostly for all components *except* for kra and ca where there is really confusing code calling unnecessarily instances multiple times and fooling around with stuff. I do not really understand what you mean by migrating from CAInstance to what's in server/*install.py because in there all instances are used for the individual components, so I am now scratching my head. The code in ca.py especially is really confusing, I rewrote it once to eliminate duplications then decided to simply not touch it in my branch (and threw away the modifications) because it is too confusing and I did not want to risk regressions. So I created a simple create_replica() function in the CA instance that does all that is needed. I guess I will just keep ignoring the confusion and try to come up with something that "works" but I'd really like to understand what is the endgame there. If you want to replace instances (why?), what will you replace it with ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Tue Aug 25 16:29:15 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 18:29:15 +0200 Subject: [Freeipa-devel] [PATCH] 915 vault: change default vault type to symmetric Message-ID: <55DC97DB.6080003@redhat.com> https://fedorahosted.org/freeipa/ticket/5251 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0915-vault-change-default-vault-type-to-symmetric.patch Type: text/x-patch Size: 6155 bytes Desc: not available URL: From rharwood at redhat.com Tue Aug 25 16:43:53 2015 From: rharwood at redhat.com (Robbie Harwood) Date: Tue, 25 Aug 2015 12:43:53 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DC5702.5030506@redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> <55DC4796.9020303@redhat.com> <55DC5702.5030506@redhat.com> Message-ID: Jan Cholasta writes: > On 25.8.2015 12:46, Michael ?im??ek wrote: >> On 2015-08-25 12:38, Alexander Bokovoy wrote: >>> On Tue, 25 Aug 2015, Michael ?im??ek wrote: >>>> On 2015-08-24 20:29, Robbie Harwood wrote: >>>>> Michael ?im??ek writes: >>>>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>>>> >>>>>>>> Fixed. python-gssapi has a display_as method that could pull the >>>>>>>> name >>>>>>>> from it, but it doesn't work in current version, therefore using >>>>>>>> partition to split on '@' >>>>> >>>>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>>>> >>>>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>>>> + user = >>>>>> api.Command.user_show(principal.partition('@')[0])['result'] >>>>> >>>>> is working around a bug in specific Kerberos versions. If people are >>>>> okay with merging such code, then I guess this is fine; I would >>>>> personally not do so because there is not a clear point at which it can >>>>> be removed. At the very least, we should wait until we see what >>>>> versions of krb5 MIT is going to fix. >>>>> >>>>> Otherwise, looks good. >>>>> >>>>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>>>> >>>> >>>> python-krbV migration is blocking support for Python 3. The bug >>>> doesn't have any fix upstream yet and there are two bugs actually, the >>>> second one is in python-gssapi, which I've just reported [1]. Waiting >>>> for two bugs to be fixed could be detrimental to py3 migration as we >>>> don't have much time left. And I'm no longer sure that display_as >>> >>> I don't buy this. >>> >>> We have plenty of time for solving these bugs. Remember, that Samba >>> DCE RPC bindings aren't migrated to Python 3 either and will not be >>> before release of Samba 4.4. For Samba 4.3 it is simply too late. >>> >>> So we are still far away from full Python3 migration for FreeIPA and >>> waiting for solving these two bugs is OK. >> >> If fixing them solves anything at all. I planned to use >> display_as(NameType.user), but when trying it on Name object with >> name_type set (which doesn't trigger the segfault), it doesn't seem to >> work either. I get: >> gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The >> operation or option is not available or unsupported, Minor (0): Unknown >> error >> >> Robbie, can you clarify whether display_as could be actually used to get >> the first component of the principal reliably? display_as should behave in accordance with its docs; anything else is a bug report, which you filed. I don't know what you're asking me for beyond that. > As I have written in the other thread, we use "principal.split('@')" in > other parts of IPA, so "principal.partition('@')" should be OK as well. > > This patch works for me, so ACK. > > Unless there are any further objections, I would like to push it. I think the newest iteration of this > user = api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result'] is even worse, but if it is decided to merge, then hopefully we can be rid of it quickly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 25 17:14:09 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 19:14:09 +0200 Subject: [Freeipa-devel] [PATCH] 371 Added support for changing vault encryption. In-Reply-To: <55DC80FB.1000306@redhat.com> References: <55BFF741.6080302@redhat.com> <55CC9638.8060801@redhat.com> <55CCCFC9.1060504@redhat.com> <55D45360.4080003@redhat.com> <55D57AEC.4030907@redhat.com> <55DC80FB.1000306@redhat.com> Message-ID: <55DCA261.6000301@redhat.com> On 08/25/2015 04:51 PM, Martin Basti wrote: > > > On 08/20/2015 08:59 AM, Endi Sukma Dewata wrote: >> On 8/19/2015 4:58 AM, Martin Basti wrote: >>> On 08/13/2015 07:11 PM, Endi Sukma Dewata wrote: >>>> On 8/13/2015 8:06 AM, Martin Basti wrote: >>>>>> The vault-mod command has been modified to support changing vault >>>>>> encryption attributes (i.e. type, password, public/private keys) >>>>>> in addition to normal attributes (i.e. description). Changing the >>>>>> encryption requires retrieving the stored secret with the old >>>>>> attributes and rearchieving it with the new attributes. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5176 >>>>>> >>>>> Hello, does this patch require any additional patches? >>>>> >>>>> I have current master branch and I cannot apply it. >>>>> >>>>> git am >>>>> freeipa-edewata-0371-Added-support-for-changing-vault-encryption.patch >>>>> -3 >>>>> >>>>> Applying: Added support for changing vault encryption. >>>>> error: invalid object 100644 3b62822366a62c90f843a6293589c28383e782ef >>>>> for 'ipalib/plugins/vault.py' >>>>> fatal: git-write-tree: error building trees >>>>> Repository lacks necessary blobs to fall back on 3-way merge. >>>>> >>>>> >>>>> Martin^2 >>>> >>>> New patch attached. It requires patch #0369-3. >>>> >>> I cannot apply patch (and 369-3 was pushed) >>> >>> git am >>> freeipa-edewata-0371-1-Added-support-for-changing-vault-encryption.patch >>> -3 >>> Applying: Added support for changing vault encryption. >>> error: invalid object 100644 5d367b376ef41427ed983f3eafe120ed477018d2 >>> for 'ipalib/plugins/vault.py' >>> fatal: git-write-tree: error building trees >>> Repository lacks necessary blobs to fall back on 3-way merge. >>> Cannot fall back to three-way merge. >> >> Rebased. >> > ACK works as expected. > > This is optional nitpick, we can fix it later: > > 1) > This should be asymmetric vault not symmetric > + Modify symmetric vault keys: > + ipa vault-mod > + [--user |--service |--shared] > + --private-key-file > + --public-key-file > Rebased, nitpick fixed. Pushed to: master: e46d9236d19f714b67fdf2865f19146c3016f46d ipa-4-2: d4969ede51e6098e962ff660daf13e8c61d4ac28 -- Petr Vobornik From pvoborni at redhat.com Tue Aug 25 17:21:26 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 19:21:26 +0200 Subject: [Freeipa-devel] [PATCH] 915 vault: change default vault type to symmetric In-Reply-To: <55DC97DB.6080003@redhat.com> References: <55DC97DB.6080003@redhat.com> Message-ID: <55DCA416.6040908@redhat.com> On 08/25/2015 06:29 PM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/5251 > > Attaching new rebased version with help text amended. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0915-1-vault-change-default-vault-type-to-symmetric.patch Type: text/x-patch Size: 6397 bytes Desc: not available URL: From pvoborni at redhat.com Tue Aug 25 18:04:55 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Aug 2015 20:04:55 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands Message-ID: <55DCAE47.5080500@redhat.com> adds commands: * vaultcontainer-show [--service |--user ] * vaultcontainer-add-owner [--service |--user ] [--users ] [--groups ] [--services ] * vaultcontainer-remove-owner [--service |--user ] [--users ] [--groups ] [--services ] https://fedorahosted.org/freeipa/ticket/5250 Use cases: 1. When user/service is deleted, associated vault container looses owner. There was no API command to set the owner. 2. Change owner of container by admin to manage access. Show command was added to show current owners. Find command was not added, should it be? -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0916-vault-add-vault-container-commands.patch Type: text/x-patch Size: 10157 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 25 18:25:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Aug 2015 20:25:16 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150825153711.GZ22106@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> Message-ID: <55DCB30C.7070907@redhat.com> On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Martin Kosek wrote: >> On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>> On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the attached patch fixes >>>>>>> . >>>>>>> >>>>>>> Honza >>>>>>> >>>>>>> -- >>>>>>> Jan Cholasta >>>>>> >>>>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>>>>> From: Jan Cholasta >>>>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>> >>>>>>> This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>>>>> old >>>>>>> selinux-policy version. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>>>> --- >>>>>>> freeipa.spec.in | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>> index cba91fe..fd73cda 100644 >>>>>>> --- a/freeipa.spec.in >>>>>>> +++ b/freeipa.spec.in >>>>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>> Requires(pre): shadow-utils >>>>>>> Requires(pre): systemd-units >>>>>>> Requires(post): systemd-units >>>>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>>>> Requires(post): selinux-policy-base >>>>>>> Requires: slapi-nis >= 0.54.2-1 >>>>>> If we have it in Requires(pre), we don't need it in Requires, as >>>>>> Requires(pre) is a superset of guarantees that Requires gives you. >>>>> >>>>> Martin (CCed) told me Requires(pre) does not imply Requires. >>>> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>> ---------------- >>>> Since the only way out of a dependency loop is to snip the loop >>>> somewhere, rpm uses hints from Requires: dependencies to distinguish >>>> co-requisite (these are not needed to install, only to use, a package) >>>> from pre-requisite (these are guaranteed to be installed before the >>>> package that includes the dependency) relations. >>>> ---------------- >>>> >>>>>> >>>>>> Requires(pre) ensures that selinux-policy of specific version is >>>>>> installed before pre scripts of freeipa-server would run, be it in the >>>>>> same transaction or in a previous one. >>>>>> >>>>> >>>>> Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >>>>> be changed to Required(posttrans)? >>>> I don't think there is posttrans target. Perhaps, we can just make sure >>>> Requires(post) is enough. >>> >>> OK, let's try that. Updated patch attached. >>> >> >> Will this really make a difference? I thought the problem is caused by >> selinux-policy being installed after freeipa-server package upgrade. We already >> have Requires on selinux-policy, so I am not sure what is actually changed by >> this patch. > The change is that with Requires(pre) or Requires(post) we are > guaranteed that selinux-policy is installed and available before our pre > or post scriptlets are run. With Requires only we are not guaranteed to > be installed after selinux-policy, only that it would be available as > part of the same transaction we are installed in. > > We don't really need to have Requires(pre) because we don't rely on > selinux-policy being available in pre scriptlet. Forcing Requires(pre) > doesn't help anyone else (rpm/yum/dnf need to solve dependency loops and > we are only complicating with Requires(pre) if we don't actually need > it). Thus, choosing Require(post) is more correct from distribution > point of view. Sure, but given that FreeIPA upgrade is run in the posttrans phase: %posttrans server # This must be run in posttrans so that updates from previous # execution that may no longer be shipped are not applied. /usr/sbin/ipa-server-upgrade --quiet >/dev/null || : I am now not sure how Requires(pre) or Requires(post) help here, in all cases, the right selinux-policy should be there before all the posttrans scripts are being run. Maybe the new selinux-policy is required for certmonger itself or some other event during upgrade? From simo at redhat.com Tue Aug 25 18:40:15 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Aug 2015 14:40:15 -0400 Subject: [Freeipa-devel] [PATCHES] Replica Promotion #2888 In-Reply-To: <1438641823.20262.16.camel@willson.usersys.redhat.com> References: <1438641823.20262.16.camel@willson.usersys.redhat.com> Message-ID: <1440528015.8138.48.camel@willson.usersys.redhat.com> On Mon, 2015-08-03 at 18:43 -0400, Simo Sorce wrote: > Hello freeipa-devel, > > this patcheset implement the main piece of the replica promotion > feature. > > It first introduces the custodia modules, custodia is a service that > allows to securely transfer secrets between FreeIPA instances, using > asymetric crypto and LDAP published keys to insure confidentiality. > > These patches intentionally duplicate some code in the installer in > order to avoid regression in the "classic" installer code path, in the > hope that the promotion functionality will not unintentionally break the > classic prepare/install code paths. > > To use test this patchset you need the jwcrypto and custodia python > packages. Jwcrypto ins in fedora rawhide already (built today for f22 > too) and Custodia is under review. I prepared two copr repositories for > now so people can build. > Use dnf copr enable simo/jwcrypto and dnf copr enable simo/custodia on > your devel VMs to get the proper packages (dnf install custodia will > suffice to drag in all dependencies). > > To test do NOT follow the usual path of creating a replica file on the > master server with the ipa-replica-prepare tool. > Instead prepare a machine and run: > ipa-client-install > ipa-replica-install --promote > > That should be it. > > You can optionally test the --setup-dns install option, but --setup-ca > and --seyup-kra do not work yet. > > If you kinit admin right after the client install, you'll be asked no > passwords. > > Note that you need to raise the domain level to 1 before you can use the > replica promotion code as it is intended to be used with the topology > plugin activated. > > This patchset depends on the previous one sent last week. > > Cheers, > Simo. > FYI I am withdrawing this patchset. I have worked with Ludwig and Petr and greatly improved and fixes this original patchset and changed it considerably in the process, we'll soon propose a new patchset instead. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Aug 25 18:43:59 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Aug 2015 14:43:59 -0400 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <1438788289.20262.40.camel@willson.usersys.redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> Message-ID: <1440528239.8138.51.camel@willson.usersys.redhat.com> On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: > On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: > > Hi, > > > > Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): > > > I've been carrying these patches in my tree for a while, I think it is > > > time to put them in master as they stand on their own. > > > > > > Simo. > > > > Patch 530: ACK > > > > Patch 531: ACK > > > > Patch 532: > > > > The methods should be static methods: > > > > @staticmethod > > def setOption(name, value): > > ... > > Care to explain why ? > @staticmethod is not used anywhere else in that file. Rebased patches on master, made requested change +1 more patch. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-530-2-Remove-custom-utility-function-from-krbinstance.patch Type: text/x-patch Size: 2293 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-531-2-Move-sasl-mappings-creation-to-dsinstance.patch Type: text/x-patch Size: 6981 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-532-2-Simplify-adding-options-in-ipachangeconf.patch Type: text/x-patch Size: 1318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-533-2-Insure-the-admin_conn-is-disconnected-on-stop.patch Type: text/x-patch Size: 1226 bytes Desc: not available URL: From msimacek at redhat.com Tue Aug 25 18:45:27 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Tue, 25 Aug 2015 20:45:27 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> <55DC4796.9020303@redhat.com> <55DC5702.5030506@redhat.com> Message-ID: <55DCB7C7.5010403@redhat.com> On 2015-08-25 18:43, Robbie Harwood wrote: > Jan Cholasta writes: > >> On 25.8.2015 12:46, Michael ?im??ek wrote: >>> On 2015-08-25 12:38, Alexander Bokovoy wrote: >>>> On Tue, 25 Aug 2015, Michael ?im??ek wrote: >>>>> On 2015-08-24 20:29, Robbie Harwood wrote: >>>>>> Michael ?im??ek writes: >>>>>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>>>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>>>>> >>>>>>>>> Fixed. python-gssapi has a display_as method that could pull the >>>>>>>>> name >>>>>>>>> from it, but it doesn't work in current version, therefore using >>>>>>>>> partition to split on '@' >>>>>> >>>>>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>>>>> >>>>>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>>>>> + user = >>>>>>> api.Command.user_show(principal.partition('@')[0])['result'] >>>>>> >>>>>> is working around a bug in specific Kerberos versions. If people are >>>>>> okay with merging such code, then I guess this is fine; I would >>>>>> personally not do so because there is not a clear point at which it can >>>>>> be removed. At the very least, we should wait until we see what >>>>>> versions of krb5 MIT is going to fix. >>>>>> >>>>>> Otherwise, looks good. >>>>>> >>>>>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>>>>> >>>>> >>>>> python-krbV migration is blocking support for Python 3. The bug >>>>> doesn't have any fix upstream yet and there are two bugs actually, the >>>>> second one is in python-gssapi, which I've just reported [1]. Waiting >>>>> for two bugs to be fixed could be detrimental to py3 migration as we >>>>> don't have much time left. And I'm no longer sure that display_as >>>> >>>> I don't buy this. >>>> >>>> We have plenty of time for solving these bugs. Remember, that Samba >>>> DCE RPC bindings aren't migrated to Python 3 either and will not be >>>> before release of Samba 4.4. For Samba 4.3 it is simply too late. >>>> >>>> So we are still far away from full Python3 migration for FreeIPA and >>>> waiting for solving these two bugs is OK. >>> >>> If fixing them solves anything at all. I planned to use >>> display_as(NameType.user), but when trying it on Name object with >>> name_type set (which doesn't trigger the segfault), it doesn't seem to >>> work either. I get: >>> gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The >>> operation or option is not available or unsupported, Minor (0): Unknown >>> error >>> >>> Robbie, can you clarify whether display_as could be actually used to get >>> the first component of the principal reliably? > > display_as should behave in accordance with its docs; anything else is a > bug report, which you filed. I don't know what you're asking me for > beyond that. > Why I mentioned display_as at all is that I initially assumed it could be used for this, but it was only an assumption because I couldn't get around the segfault. Later on, the cause of the segfault was found and I was able to try the method and I found out that it probably cannot be used for this purpose (i. e. extracting the first component of the principal) regardless of the two bugs. How I thought it would be used: import gssapi cred = gssapi.Credentials() user = cred.name.display_as(gssapi.NameType.user) What I got: gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The operation or option is not available or unsupported, Minor (0): Unknown error This seems more like the method is not intended to be used this way. So I'm asking you whether it is a bug or whether there is another way to do it. Otherwise display_as cannot be used here. >> As I have written in the other thread, we use "principal.split('@')" in >> other parts of IPA, so "principal.partition('@')" should be OK as well. >> >> This patch works for me, so ACK. >> >> Unless there are any further objections, I would like to push it. > > I think the newest iteration of this > >> user = api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result'] > > is even worse, but if it is decided to merge, then hopefully we can be > rid of it quickly. It is splitting a string of known format in a way that is used in other places of freeipa. What is specifically so bad about it? What do you suggest as an alternative? From ofayans at redhat.com Tue Aug 25 18:59:21 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 25 Aug 2015 20:59:21 +0200 Subject: [Freeipa-devel] dnssec tests fail due to KeyError at is_record_signed method Message-ID: <55DCBB09.6090804@redhat.com> Hi Martin, As I was running the dnssec integration tests, I noticed that 4 out of 5 tests fail with the assumption of the dns zone being signed. Here is the stdout of the tests: http://pastebin.test.redhat.com/307944 The failure occurs in the is_record_signed method: it catches KeyError calling the ans.response.find_rrset method (line 37 at test_integration/test_dnssec.py). Could you take a look at it? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From abokovoy at redhat.com Tue Aug 25 18:59:47 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 21:59:47 +0300 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DCB30C.7070907@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> Message-ID: <20150825185947.GA22106@redhat.com> On Tue, 25 Aug 2015, Martin Kosek wrote: >On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>On Tue, 25 Aug 2015, Martin Kosek wrote: >>>On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>Hi, >>>>>>>> >>>>>>>>the attached patch fixes >>>>>>>>. >>>>>>>> >>>>>>>>Honza >>>>>>>> >>>>>>>>-- >>>>>>>>Jan Cholasta >>>>>>> >>>>>>>>From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>>>>>>From: Jan Cholasta >>>>>>>>Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>>> >>>>>>>>This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>>>>>>old >>>>>>>>selinux-policy version. >>>>>>>> >>>>>>>>https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>--- >>>>>>>>freeipa.spec.in | 1 + >>>>>>>>1 file changed, 1 insertion(+) >>>>>>>> >>>>>>>>diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>index cba91fe..fd73cda 100644 >>>>>>>>--- a/freeipa.spec.in >>>>>>>>+++ b/freeipa.spec.in >>>>>>>>@@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>Requires(pre): shadow-utils >>>>>>>>Requires(pre): systemd-units >>>>>>>>Requires(post): systemd-units >>>>>>>>+Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>Requires(post): selinux-policy-base >>>>>>>>Requires: slapi-nis >= 0.54.2-1 >>>>>>>If we have it in Requires(pre), we don't need it in Requires, as >>>>>>>Requires(pre) is a superset of guarantees that Requires gives you. >>>>>> >>>>>>Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>>>---------------- >>>>>Since the only way out of a dependency loop is to snip the loop >>>>>somewhere, rpm uses hints from Requires: dependencies to distinguish >>>>>co-requisite (these are not needed to install, only to use, a package) >>>>>from pre-requisite (these are guaranteed to be installed before the >>>>>package that includes the dependency) relations. >>>>>---------------- >>>>> >>>>>>> >>>>>>>Requires(pre) ensures that selinux-policy of specific version is >>>>>>>installed before pre scripts of freeipa-server would run, be it in the >>>>>>>same transaction or in a previous one. >>>>>>> >>>>>> >>>>>>Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >>>>>>be changed to Required(posttrans)? >>>>>I don't think there is posttrans target. Perhaps, we can just make sure >>>>>Requires(post) is enough. >>>> >>>>OK, let's try that. Updated patch attached. >>>> >>> >>>Will this really make a difference? I thought the problem is caused by >>>selinux-policy being installed after freeipa-server package upgrade. We already >>>have Requires on selinux-policy, so I am not sure what is actually changed by >>>this patch. >>The change is that with Requires(pre) or Requires(post) we are >>guaranteed that selinux-policy is installed and available before our pre >>or post scriptlets are run. With Requires only we are not guaranteed to >>be installed after selinux-policy, only that it would be available as >>part of the same transaction we are installed in. >> >>We don't really need to have Requires(pre) because we don't rely on >>selinux-policy being available in pre scriptlet. Forcing Requires(pre) >>doesn't help anyone else (rpm/yum/dnf need to solve dependency loops and >>we are only complicating with Requires(pre) if we don't actually need >>it). Thus, choosing Require(post) is more correct from distribution >>point of view. > >Sure, but given that FreeIPA upgrade is run in the posttrans phase: > >%posttrans server ># This must be run in posttrans so that updates from previous ># execution that may no longer be shipped are not applied. >/usr/sbin/ipa-server-upgrade --quiet >/dev/null || : > >I am now not sure how Requires(pre) or Requires(post) help here, in >all cases, the right selinux-policy should be there before all the >posttrans scripts are being run. I've looked at the rpm source code and here is the list of all supported requires/dependencies types: https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 Requires(posttrans) is there so we could use this one too but it was added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, for example, as they are only up to 4.11. >Maybe the new selinux-policy is required for certmonger itself or some >other event during upgrade? No, I don't think so. However, we cannot set Requires(posttrans), thus we should be using closest target before it, i.e. Requires(post). -- / Alexander Bokovoy From simo at redhat.com Tue Aug 25 19:00:42 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 25 Aug 2015 15:00:42 -0400 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DCB7C7.5010403@redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> <55DC4796.9020303@redhat.com> <55DC5702.5030506@redhat.com> <55DCB7C7.5010403@redhat.com> Message-ID: <1440529242.8138.53.camel@willson.usersys.redhat.com> On Tue, 2015-08-25 at 20:45 +0200, Michael ?im??ek wrote: > > On 2015-08-25 18:43, Robbie Harwood wrote: > > Jan Cholasta writes: > > > >> On 25.8.2015 12:46, Michael ?im??ek wrote: > >>> On 2015-08-25 12:38, Alexander Bokovoy wrote: > >>>> On Tue, 25 Aug 2015, Michael ?im??ek wrote: > >>>>> On 2015-08-24 20:29, Robbie Harwood wrote: > >>>>>> Michael ?im??ek writes: > >>>>>>> On 2015-08-24 17:49, Simo Sorce wrote: > >>>>>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: > >>>>>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: > >>>>>>>>> > >>>>>>>>> Fixed. python-gssapi has a display_as method that could pull the > >>>>>>>>> name > >>>>>>>>> from it, but it doesn't work in current version, therefore using > >>>>>>>>> partition to split on '@' > >>>>>> > >>>>>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: > >>>>>> > >>>>>>> - user = api.Command.user_show(unicode(principal[0]))['result'] > >>>>>>> + user = > >>>>>>> api.Command.user_show(principal.partition('@')[0])['result'] > >>>>>> > >>>>>> is working around a bug in specific Kerberos versions. If people are > >>>>>> okay with merging such code, then I guess this is fine; I would > >>>>>> personally not do so because there is not a clear point at which it can > >>>>>> be removed. At the very least, we should wait until we see what > >>>>>> versions of krb5 MIT is going to fix. > >>>>>> > >>>>>> Otherwise, looks good. > >>>>>> > >>>>>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 > >>>>>> > >>>>> > >>>>> python-krbV migration is blocking support for Python 3. The bug > >>>>> doesn't have any fix upstream yet and there are two bugs actually, the > >>>>> second one is in python-gssapi, which I've just reported [1]. Waiting > >>>>> for two bugs to be fixed could be detrimental to py3 migration as we > >>>>> don't have much time left. And I'm no longer sure that display_as > >>>> > >>>> I don't buy this. > >>>> > >>>> We have plenty of time for solving these bugs. Remember, that Samba > >>>> DCE RPC bindings aren't migrated to Python 3 either and will not be > >>>> before release of Samba 4.4. For Samba 4.3 it is simply too late. > >>>> > >>>> So we are still far away from full Python3 migration for FreeIPA and > >>>> waiting for solving these two bugs is OK. > >>> > >>> If fixing them solves anything at all. I planned to use > >>> display_as(NameType.user), but when trying it on Name object with > >>> name_type set (which doesn't trigger the segfault), it doesn't seem to > >>> work either. I get: > >>> gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The > >>> operation or option is not available or unsupported, Minor (0): Unknown > >>> error > >>> > >>> Robbie, can you clarify whether display_as could be actually used to get > >>> the first component of the principal reliably? > > > > display_as should behave in accordance with its docs; anything else is a > > bug report, which you filed. I don't know what you're asking me for > > beyond that. > > > > Why I mentioned display_as at all is that I initially assumed it could > be used for this, but it was only an assumption because I couldn't get > around the segfault. Later on, the cause of the segfault was found and I > was able to try the method and I found out that it probably cannot be > used for this purpose (i. e. extracting the first component of the > principal) regardless of the two bugs. How I thought it would be used: > import gssapi > cred = gssapi.Credentials() > user = cred.name.display_as(gssapi.NameType.user) > > What I got: > gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The > operation or option is not available or unsupported, Minor (0): Unknown > error > > This seems more like the method is not intended to be used this way. So > I'm asking you whether it is a bug or whether there is another way to do > it. Otherwise display_as cannot be used here. > > >> As I have written in the other thread, we use "principal.split('@')" in > >> other parts of IPA, so "principal.partition('@')" should be OK as well. > >> > >> This patch works for me, so ACK. > >> > >> Unless there are any further objections, I would like to push it. > > > > I think the newest iteration of this > > > >> user = api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result'] > > > > is even worse, but if it is decided to merge, then hopefully we can be > > rid of it quickly. > > It is splitting a string of known format in a way that is used in other > places of freeipa. What is specifically so bad about it? What do you > suggest as an alternative? Given display_as() currently does not work for you go ahead with this code. We'll revisit display_as later once we figure out more about the bug that makes it fail. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Aug 25 19:06:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Aug 2015 21:06:01 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150825185947.GA22106@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> Message-ID: <55DCBC99.3030605@redhat.com> On 08/25/2015 08:59 PM, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Martin Kosek wrote: >> On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>> On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>> On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the attached patch fixes >>>>>>>>> . >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jan Cholasta >>>>>>>> >>>>>>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>>>>>>> From: Jan Cholasta >>>>>>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>>>> >>>>>>>>> This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>>>>>>> old >>>>>>>>> selinux-policy version. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>> --- >>>>>>>>> freeipa.spec.in | 1 + >>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>> >>>>>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>> index cba91fe..fd73cda 100644 >>>>>>>>> --- a/freeipa.spec.in >>>>>>>>> +++ b/freeipa.spec.in >>>>>>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>> Requires(pre): shadow-utils >>>>>>>>> Requires(pre): systemd-units >>>>>>>>> Requires(post): systemd-units >>>>>>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>> Requires(post): selinux-policy-base >>>>>>>>> Requires: slapi-nis >= 0.54.2-1 >>>>>>>> If we have it in Requires(pre), we don't need it in Requires, as >>>>>>>> Requires(pre) is a superset of guarantees that Requires gives you. >>>>>>> >>>>>>> Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>>>> ---------------- >>>>>> Since the only way out of a dependency loop is to snip the loop >>>>>> somewhere, rpm uses hints from Requires: dependencies to distinguish >>>>>> co-requisite (these are not needed to install, only to use, a package) >>>>>> from pre-requisite (these are guaranteed to be installed before the >>>>>> package that includes the dependency) relations. >>>>>> ---------------- >>>>>> >>>>>>>> >>>>>>>> Requires(pre) ensures that selinux-policy of specific version is >>>>>>>> installed before pre scripts of freeipa-server would run, be it in the >>>>>>>> same transaction or in a previous one. >>>>>>>> >>>>>>> >>>>>>> Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >>>>>>> be changed to Required(posttrans)? >>>>>> I don't think there is posttrans target. Perhaps, we can just make sure >>>>>> Requires(post) is enough. >>>>> >>>>> OK, let's try that. Updated patch attached. >>>>> >>>> >>>> Will this really make a difference? I thought the problem is caused by >>>> selinux-policy being installed after freeipa-server package upgrade. We >>>> already >>>> have Requires on selinux-policy, so I am not sure what is actually changed by >>>> this patch. >>> The change is that with Requires(pre) or Requires(post) we are >>> guaranteed that selinux-policy is installed and available before our pre >>> or post scriptlets are run. With Requires only we are not guaranteed to >>> be installed after selinux-policy, only that it would be available as >>> part of the same transaction we are installed in. >>> >>> We don't really need to have Requires(pre) because we don't rely on >>> selinux-policy being available in pre scriptlet. Forcing Requires(pre) >>> doesn't help anyone else (rpm/yum/dnf need to solve dependency loops and >>> we are only complicating with Requires(pre) if we don't actually need >>> it). Thus, choosing Require(post) is more correct from distribution >>> point of view. >> >> Sure, but given that FreeIPA upgrade is run in the posttrans phase: >> >> %posttrans server >> # This must be run in posttrans so that updates from previous >> # execution that may no longer be shipped are not applied. >> /usr/sbin/ipa-server-upgrade --quiet >/dev/null || : >> >> I am now not sure how Requires(pre) or Requires(post) help here, in all >> cases, the right selinux-policy should be there before all the posttrans >> scripts are being run. > I've looked at the rpm source code and here is the list of all supported > requires/dependencies types: > https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 > > > Requires(posttrans) is there so we could use this one too but it was > added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, for > example, as they are only up to 4.11. >> Maybe the new selinux-policy is required for certmonger itself or some other >> event during upgrade? > No, I don't think so. However, we cannot set Requires(posttrans), thus > we should be using closest target before it, i.e. Requires(post). Thank you, but I think I still did not get an answer for my question. IIUC, the rough rpm process with regards to freeipa-server package upgrade, it should be in this order: _ | v RPM installs some dependencies of freeipa-server | V RPM installs "Requires(pre)" of freeipa-server freeipa-server pre scriptlet runs | v RPM installs freeipa-server | v RPM installs "Requires(post)" of freeipa-server freeipa-server post scriptlet runs | v RPM installs some dependencies of freeipa-server | v RPM executes posttrans scriptlets, including "ipa-server-upgrade". My question is, if all the magic happens in the last step, how does adding (pre) or (post) Requires help, given we already have the "normal" Requires? From rcritten at redhat.com Tue Aug 25 19:12:38 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Aug 2015 15:12:38 -0400 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DCBC99.3030605@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> <55DCBC99.3030605@redhat.com> Message-ID: <55DCBE26.6000704@redhat.com> Martin Kosek wrote: > On 08/25/2015 08:59 PM, Alexander Bokovoy wrote: >> On Tue, 25 Aug 2015, Martin Kosek wrote: >>> On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>> On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>>> On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> the attached patch fixes >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jan Cholasta >>>>>>>>> >>>>>>>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 >>>>>>>>>> 00:00:00 2001 >>>>>>>>>> From: Jan Cholasta >>>>>>>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>>>>> >>>>>>>>>> This prevents ipa-server-upgrade failures on SELinux AVCs >>>>>>>>>> because of >>>>>>>>>> old >>>>>>>>>> selinux-policy version. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>>> --- >>>>>>>>>> freeipa.spec.in | 1 + >>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>> >>>>>>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>>> index cba91fe..fd73cda 100644 >>>>>>>>>> --- a/freeipa.spec.in >>>>>>>>>> +++ b/freeipa.spec.in >>>>>>>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>>> Requires(pre): shadow-utils >>>>>>>>>> Requires(pre): systemd-units >>>>>>>>>> Requires(post): systemd-units >>>>>>>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>>> Requires(post): selinux-policy-base >>>>>>>>>> Requires: slapi-nis >= 0.54.2-1 >>>>>>>>> If we have it in Requires(pre), we don't need it in Requires, as >>>>>>>>> Requires(pre) is a superset of guarantees that Requires gives you. >>>>>>>> >>>>>>>> Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>>> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>>>>> ---------------- >>>>>>> Since the only way out of a dependency loop is to snip the loop >>>>>>> somewhere, rpm uses hints from Requires: dependencies to distinguish >>>>>>> co-requisite (these are not needed to install, only to use, a >>>>>>> package) >>>>>>> from pre-requisite (these are guaranteed to be installed before the >>>>>>> package that includes the dependency) relations. >>>>>>> ---------------- >>>>>>> >>>>>>>>> >>>>>>>>> Requires(pre) ensures that selinux-policy of specific version is >>>>>>>>> installed before pre scripts of freeipa-server would run, be it >>>>>>>>> in the >>>>>>>>> same transaction or in a previous one. >>>>>>>>> >>>>>>>> >>>>>>>> Hmm, ipa-server-upgrade is run in posttrans. Should the >>>>>>>> Requires(pre) >>>>>>>> be changed to Required(posttrans)? >>>>>>> I don't think there is posttrans target. Perhaps, we can just >>>>>>> make sure >>>>>>> Requires(post) is enough. >>>>>> >>>>>> OK, let's try that. Updated patch attached. >>>>>> >>>>> >>>>> Will this really make a difference? I thought the problem is caused by >>>>> selinux-policy being installed after freeipa-server package >>>>> upgrade. We >>>>> already >>>>> have Requires on selinux-policy, so I am not sure what is actually >>>>> changed by >>>>> this patch. >>>> The change is that with Requires(pre) or Requires(post) we are >>>> guaranteed that selinux-policy is installed and available before our >>>> pre >>>> or post scriptlets are run. With Requires only we are not guaranteed to >>>> be installed after selinux-policy, only that it would be available as >>>> part of the same transaction we are installed in. >>>> >>>> We don't really need to have Requires(pre) because we don't rely on >>>> selinux-policy being available in pre scriptlet. Forcing Requires(pre) >>>> doesn't help anyone else (rpm/yum/dnf need to solve dependency loops >>>> and >>>> we are only complicating with Requires(pre) if we don't actually need >>>> it). Thus, choosing Require(post) is more correct from distribution >>>> point of view. >>> >>> Sure, but given that FreeIPA upgrade is run in the posttrans phase: >>> >>> %posttrans server >>> # This must be run in posttrans so that updates from previous >>> # execution that may no longer be shipped are not applied. >>> /usr/sbin/ipa-server-upgrade --quiet >/dev/null || : >>> >>> I am now not sure how Requires(pre) or Requires(post) help here, in all >>> cases, the right selinux-policy should be there before all the posttrans >>> scripts are being run. >> I've looked at the rpm source code and here is the list of all supported >> requires/dependencies types: >> https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 >> >> >> >> Requires(posttrans) is there so we could use this one too but it was >> added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, for >> example, as they are only up to 4.11. >>> Maybe the new selinux-policy is required for certmonger itself or >>> some other >>> event during upgrade? >> No, I don't think so. However, we cannot set Requires(posttrans), thus >> we should be using closest target before it, i.e. Requires(post). > > Thank you, but I think I still did not get an answer for my question. > > IIUC, the rough rpm process with regards to freeipa-server package > upgrade, it should be in this order: > > _ > | > v > RPM installs some dependencies of freeipa-server > | > V > RPM installs "Requires(pre)" of freeipa-server > freeipa-server pre scriptlet runs > | > v > RPM installs freeipa-server > | > v > RPM installs "Requires(post)" of freeipa-server > freeipa-server post scriptlet runs > | > v > RPM installs some dependencies of freeipa-server > | > v > RPM executes posttrans scriptlets, including "ipa-server-upgrade". > > > My question is, if all the magic happens in the last step, how does > adding (pre) or (post) Requires help, given we already have the "normal" > Requires? > I don't think Requires implies that it be installed before any given package, it just needs to be installed *with* that package in the same transaction. The (pre/post/whatever) specifies when you want some other package installated in relationship to this package. The 2.x or 3.x spec file may provide some insights because IIRC we still carried our own SELinux policy then and needed the base policies installed first. rob From abokovoy at redhat.com Tue Aug 25 19:22:42 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Aug 2015 22:22:42 +0300 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DCBC99.3030605@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> <55DCBC99.3030605@redhat.com> Message-ID: <20150825192242.GC22106@redhat.com> On Tue, 25 Aug 2015, Martin Kosek wrote: >On 08/25/2015 08:59 PM, Alexander Bokovoy wrote: >>On Tue, 25 Aug 2015, Martin Kosek wrote: >>>On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>>>On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>>On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>>>On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>>>On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>>>On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>>Hi, >>>>>>>>>> >>>>>>>>>>the attached patch fixes >>>>>>>>>>. >>>>>>>>>> >>>>>>>>>>Honza >>>>>>>>>> >>>>>>>>>>-- >>>>>>>>>>Jan Cholasta >>>>>>>>> >>>>>>>>>>From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>>>>>>>>From: Jan Cholasta >>>>>>>>>>Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>>>Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>>>>> >>>>>>>>>>This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>>>>>>>>old >>>>>>>>>>selinux-policy version. >>>>>>>>>> >>>>>>>>>>https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>>>--- >>>>>>>>>>freeipa.spec.in | 1 + >>>>>>>>>>1 file changed, 1 insertion(+) >>>>>>>>>> >>>>>>>>>>diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>>>index cba91fe..fd73cda 100644 >>>>>>>>>>--- a/freeipa.spec.in >>>>>>>>>>+++ b/freeipa.spec.in >>>>>>>>>>@@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>>>Requires(pre): shadow-utils >>>>>>>>>>Requires(pre): systemd-units >>>>>>>>>>Requires(post): systemd-units >>>>>>>>>>+Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>>>Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>>>Requires(post): selinux-policy-base >>>>>>>>>>Requires: slapi-nis >= 0.54.2-1 >>>>>>>>>If we have it in Requires(pre), we don't need it in Requires, as >>>>>>>>>Requires(pre) is a superset of guarantees that Requires gives you. >>>>>>>> >>>>>>>>Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>>>See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>>>>>---------------- >>>>>>>Since the only way out of a dependency loop is to snip the loop >>>>>>>somewhere, rpm uses hints from Requires: dependencies to distinguish >>>>>>>co-requisite (these are not needed to install, only to use, a package) >>>>>>>from pre-requisite (these are guaranteed to be installed before the >>>>>>>package that includes the dependency) relations. >>>>>>>---------------- >>>>>>> >>>>>>>>> >>>>>>>>>Requires(pre) ensures that selinux-policy of specific version is >>>>>>>>>installed before pre scripts of freeipa-server would run, be it in the >>>>>>>>>same transaction or in a previous one. >>>>>>>>> >>>>>>>> >>>>>>>>Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >>>>>>>>be changed to Required(posttrans)? >>>>>>>I don't think there is posttrans target. Perhaps, we can just make sure >>>>>>>Requires(post) is enough. >>>>>> >>>>>>OK, let's try that. Updated patch attached. >>>>>> >>>>> >>>>>Will this really make a difference? I thought the problem is caused by >>>>>selinux-policy being installed after freeipa-server package upgrade. We >>>>>already >>>>>have Requires on selinux-policy, so I am not sure what is actually changed by >>>>>this patch. >>>>The change is that with Requires(pre) or Requires(post) we are >>>>guaranteed that selinux-policy is installed and available before our pre >>>>or post scriptlets are run. With Requires only we are not guaranteed to >>>>be installed after selinux-policy, only that it would be available as >>>>part of the same transaction we are installed in. >>>> >>>>We don't really need to have Requires(pre) because we don't rely on >>>>selinux-policy being available in pre scriptlet. Forcing Requires(pre) >>>>doesn't help anyone else (rpm/yum/dnf need to solve dependency loops and >>>>we are only complicating with Requires(pre) if we don't actually need >>>>it). Thus, choosing Require(post) is more correct from distribution >>>>point of view. >>> >>>Sure, but given that FreeIPA upgrade is run in the posttrans phase: >>> >>>%posttrans server >>># This must be run in posttrans so that updates from previous >>># execution that may no longer be shipped are not applied. >>>/usr/sbin/ipa-server-upgrade --quiet >/dev/null || : >>> >>>I am now not sure how Requires(pre) or Requires(post) help here, in all >>>cases, the right selinux-policy should be there before all the posttrans >>>scripts are being run. >>I've looked at the rpm source code and here is the list of all supported >>requires/dependencies types: >>https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 >> >> >>Requires(posttrans) is there so we could use this one too but it was >>added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, for >>example, as they are only up to 4.11. >>>Maybe the new selinux-policy is required for certmonger itself or some other >>>event during upgrade? >>No, I don't think so. However, we cannot set Requires(posttrans), thus >>we should be using closest target before it, i.e. Requires(post). > >Thank you, but I think I still did not get an answer for my question. > >IIUC, the rough rpm process with regards to freeipa-server package >upgrade, it should be in this order: > >_ >| >v >RPM installs some dependencies of freeipa-server >| >V >RPM installs "Requires(pre)" of freeipa-server >freeipa-server pre scriptlet runs >| >v >RPM installs freeipa-server >| >v >RPM installs "Requires(post)" of freeipa-server >freeipa-server post scriptlet runs >| >v >RPM installs some dependencies of freeipa-server >| >v >RPM executes posttrans scriptlets, including "ipa-server-upgrade". The flow above is not correct. Each scriptlet of the package is executed when package is installed. In particular, there is no period of waiting until end of whole transaction to start executing %posttrans scriptlet of a specific package. RPM only guarantees you that %posttrans scriptlet is executed as the last thing of this package intall, after all %post/%postun scriptlets were executed for this package and all triggers for affected packages were executed. This does not guarantee that selinux-policy processing would be before freeipa-server processing unless we explicitly ask for the ordering via Requires() tag. The order of processing packages is affected by Requires() tag, but processing of each single package is still sequential. >My question is, if all the magic happens in the last step, how does >adding (pre) or (post) Requires help, given we already have the >"normal" Requires? Because with Requires nothing guarantees selinux-policy is installed before freeipa-server in the same transaction, we have to use Requires() that would ensure we have the selinux-policy installation/upgrade completed by the time that stage is reached in freeipa-server installation/upgrade process. In reality Requires(pre) is often enough too but not recommended as it also could cause loop breaking issues. -- / Alexander Bokovoy From mkosek at redhat.com Tue Aug 25 19:25:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 25 Aug 2015 21:25:25 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150825192242.GC22106@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> <55DCBC99.3030605@redhat.com> <20150825192242.GC22106@redhat.com> Message-ID: <55DCC125.30109@redhat.com> On 08/25/2015 09:22 PM, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Martin Kosek wrote: >> On 08/25/2015 08:59 PM, Alexander Bokovoy wrote: >>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>> On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>>>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>>> On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>>>> On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> the attached patch fixes >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jan Cholasta >>>>>>>>>> >>>>>>>>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 >>>>>>>>>>> From: Jan Cholasta >>>>>>>>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>>>>>> >>>>>>>>>>> This prevents ipa-server-upgrade failures on SELinux AVCs because of >>>>>>>>>>> old >>>>>>>>>>> selinux-policy version. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>>>> --- >>>>>>>>>>> freeipa.spec.in | 1 + >>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>> >>>>>>>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>>>> index cba91fe..fd73cda 100644 >>>>>>>>>>> --- a/freeipa.spec.in >>>>>>>>>>> +++ b/freeipa.spec.in >>>>>>>>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>>>> Requires(pre): shadow-utils >>>>>>>>>>> Requires(pre): systemd-units >>>>>>>>>>> Requires(post): systemd-units >>>>>>>>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>>>> Requires(post): selinux-policy-base >>>>>>>>>>> Requires: slapi-nis >= 0.54.2-1 >>>>>>>>>> If we have it in Requires(pre), we don't need it in Requires, as >>>>>>>>>> Requires(pre) is a superset of guarantees that Requires gives you. >>>>>>>>> >>>>>>>>> Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>>>> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>>>>>> ---------------- >>>>>>>> Since the only way out of a dependency loop is to snip the loop >>>>>>>> somewhere, rpm uses hints from Requires: dependencies to distinguish >>>>>>>> co-requisite (these are not needed to install, only to use, a package) >>>>>>>> from pre-requisite (these are guaranteed to be installed before the >>>>>>>> package that includes the dependency) relations. >>>>>>>> ---------------- >>>>>>>> >>>>>>>>>> >>>>>>>>>> Requires(pre) ensures that selinux-policy of specific version is >>>>>>>>>> installed before pre scripts of freeipa-server would run, be it in the >>>>>>>>>> same transaction or in a previous one. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hmm, ipa-server-upgrade is run in posttrans. Should the Requires(pre) >>>>>>>>> be changed to Required(posttrans)? >>>>>>>> I don't think there is posttrans target. Perhaps, we can just make sure >>>>>>>> Requires(post) is enough. >>>>>>> >>>>>>> OK, let's try that. Updated patch attached. >>>>>>> >>>>>> >>>>>> Will this really make a difference? I thought the problem is caused by >>>>>> selinux-policy being installed after freeipa-server package upgrade. We >>>>>> already >>>>>> have Requires on selinux-policy, so I am not sure what is actually >>>>>> changed by >>>>>> this patch. >>>>> The change is that with Requires(pre) or Requires(post) we are >>>>> guaranteed that selinux-policy is installed and available before our pre >>>>> or post scriptlets are run. With Requires only we are not guaranteed to >>>>> be installed after selinux-policy, only that it would be available as >>>>> part of the same transaction we are installed in. >>>>> >>>>> We don't really need to have Requires(pre) because we don't rely on >>>>> selinux-policy being available in pre scriptlet. Forcing Requires(pre) >>>>> doesn't help anyone else (rpm/yum/dnf need to solve dependency loops and >>>>> we are only complicating with Requires(pre) if we don't actually need >>>>> it). Thus, choosing Require(post) is more correct from distribution >>>>> point of view. >>>> >>>> Sure, but given that FreeIPA upgrade is run in the posttrans phase: >>>> >>>> %posttrans server >>>> # This must be run in posttrans so that updates from previous >>>> # execution that may no longer be shipped are not applied. >>>> /usr/sbin/ipa-server-upgrade --quiet >/dev/null || : >>>> >>>> I am now not sure how Requires(pre) or Requires(post) help here, in all >>>> cases, the right selinux-policy should be there before all the posttrans >>>> scripts are being run. >>> I've looked at the rpm source code and here is the list of all supported >>> requires/dependencies types: >>> https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 >>> >>> >>> >>> Requires(posttrans) is there so we could use this one too but it was >>> added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, for >>> example, as they are only up to 4.11. >>>> Maybe the new selinux-policy is required for certmonger itself or some other >>>> event during upgrade? >>> No, I don't think so. However, we cannot set Requires(posttrans), thus >>> we should be using closest target before it, i.e. Requires(post). >> >> Thank you, but I think I still did not get an answer for my question. >> >> IIUC, the rough rpm process with regards to freeipa-server package upgrade, >> it should be in this order: >> >> _ >> | >> v >> RPM installs some dependencies of freeipa-server >> | >> V >> RPM installs "Requires(pre)" of freeipa-server >> freeipa-server pre scriptlet runs >> | >> v >> RPM installs freeipa-server >> | >> v >> RPM installs "Requires(post)" of freeipa-server >> freeipa-server post scriptlet runs >> | >> v >> RPM installs some dependencies of freeipa-server >> | >> v >> RPM executes posttrans scriptlets, including "ipa-server-upgrade". > The flow above is not correct. Each scriptlet of the package is executed > when package is installed. In particular, there is no period of waiting > until end of whole transaction to start executing %posttrans scriptlet of > a specific package. RPM only guarantees you that %posttrans scriptlet is > executed as the last thing of this package intall, after all > %post/%postun scriptlets were executed for this package and all triggers > for affected packages were executed. Ah, so this was the key misunderstanding I was having. I thought that all posttrans scripts for all packages are run in the end. > > This does not guarantee that selinux-policy processing would be before > freeipa-server processing unless we explicitly ask for the ordering via > Requires() tag. The order of processing packages is affected by > Requires() tag, but processing of each single package is still > sequential. > >> My question is, if all the magic happens in the last step, how does adding >> (pre) or (post) Requires help, given we already have the "normal" Requires? > Because with Requires nothing guarantees selinux-policy is > installed before freeipa-server in the same transaction, we have to use > Requires() that would ensure we have the selinux-policy > installation/upgrade completed by the time that stage is reached in > freeipa-server installation/upgrade process. In reality Requires(pre) is > often enough too but not recommended as it also could cause loop > breaking issues. > Thanks for the explanation. If this is the case, the patch should be OK as is indeed and Requires on post should be enough. From jcholast at redhat.com Wed Aug 26 06:03:47 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 08:03:47 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DCC125.30109@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> <55DCBC99.3030605@redhat.com> <20150825192242.GC22106@redhat.com> <55DCC125.30109@redhat.com> Message-ID: <55DD56C3.4020306@redhat.com> On 25.8.2015 21:25, Martin Kosek wrote: > On 08/25/2015 09:22 PM, Alexander Bokovoy wrote: >> On Tue, 25 Aug 2015, Martin Kosek wrote: >>> On 08/25/2015 08:59 PM, Alexander Bokovoy wrote: >>>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>> On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>>>> On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>>>>> On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> the attached patch fixes >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> Honza >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Jan Cholasta >>>>>>>>>>> >>>>>>>>>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 >>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>> From: Jan Cholasta >>>>>>>>>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>>>>> Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>>>>>>> >>>>>>>>>>>> This prevents ipa-server-upgrade failures on SELinux AVCs >>>>>>>>>>>> because of >>>>>>>>>>>> old >>>>>>>>>>>> selinux-policy version. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>>>>> --- >>>>>>>>>>>> freeipa.spec.in | 1 + >>>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>>>>> index cba91fe..fd73cda 100644 >>>>>>>>>>>> --- a/freeipa.spec.in >>>>>>>>>>>> +++ b/freeipa.spec.in >>>>>>>>>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>>>>> Requires(pre): shadow-utils >>>>>>>>>>>> Requires(pre): systemd-units >>>>>>>>>>>> Requires(post): systemd-units >>>>>>>>>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>>>>> Requires(post): selinux-policy-base >>>>>>>>>>>> Requires: slapi-nis >= 0.54.2-1 >>>>>>>>>>> If we have it in Requires(pre), we don't need it in Requires, as >>>>>>>>>>> Requires(pre) is a superset of guarantees that Requires gives >>>>>>>>>>> you. >>>>>>>>>> >>>>>>>>>> Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>>>>> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>>>>>>> ---------------- >>>>>>>>> Since the only way out of a dependency loop is to snip the loop >>>>>>>>> somewhere, rpm uses hints from Requires: dependencies to >>>>>>>>> distinguish >>>>>>>>> co-requisite (these are not needed to install, only to use, a >>>>>>>>> package) >>>>>>>>> from pre-requisite (these are guaranteed to be installed before >>>>>>>>> the >>>>>>>>> package that includes the dependency) relations. >>>>>>>>> ---------------- >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Requires(pre) ensures that selinux-policy of specific version is >>>>>>>>>>> installed before pre scripts of freeipa-server would run, be >>>>>>>>>>> it in the >>>>>>>>>>> same transaction or in a previous one. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hmm, ipa-server-upgrade is run in posttrans. Should the >>>>>>>>>> Requires(pre) >>>>>>>>>> be changed to Required(posttrans)? >>>>>>>>> I don't think there is posttrans target. Perhaps, we can just >>>>>>>>> make sure >>>>>>>>> Requires(post) is enough. >>>>>>>> >>>>>>>> OK, let's try that. Updated patch attached. >>>>>>>> >>>>>>> >>>>>>> Will this really make a difference? I thought the problem is >>>>>>> caused by >>>>>>> selinux-policy being installed after freeipa-server package >>>>>>> upgrade. We >>>>>>> already >>>>>>> have Requires on selinux-policy, so I am not sure what is actually >>>>>>> changed by >>>>>>> this patch. >>>>>> The change is that with Requires(pre) or Requires(post) we are >>>>>> guaranteed that selinux-policy is installed and available before >>>>>> our pre >>>>>> or post scriptlets are run. With Requires only we are not >>>>>> guaranteed to >>>>>> be installed after selinux-policy, only that it would be available as >>>>>> part of the same transaction we are installed in. >>>>>> >>>>>> We don't really need to have Requires(pre) because we don't rely on >>>>>> selinux-policy being available in pre scriptlet. Forcing >>>>>> Requires(pre) >>>>>> doesn't help anyone else (rpm/yum/dnf need to solve dependency >>>>>> loops and >>>>>> we are only complicating with Requires(pre) if we don't actually need >>>>>> it). Thus, choosing Require(post) is more correct from distribution >>>>>> point of view. >>>>> >>>>> Sure, but given that FreeIPA upgrade is run in the posttrans phase: >>>>> >>>>> %posttrans server >>>>> # This must be run in posttrans so that updates from previous >>>>> # execution that may no longer be shipped are not applied. >>>>> /usr/sbin/ipa-server-upgrade --quiet >/dev/null || : >>>>> >>>>> I am now not sure how Requires(pre) or Requires(post) help here, in >>>>> all >>>>> cases, the right selinux-policy should be there before all the >>>>> posttrans >>>>> scripts are being run. >>>> I've looked at the rpm source code and here is the list of all >>>> supported >>>> requires/dependencies types: >>>> https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 >>>> >>>> >>>> >>>> >>>> Requires(posttrans) is there so we could use this one too but it was >>>> added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, >>>> for >>>> example, as they are only up to 4.11. >>>>> Maybe the new selinux-policy is required for certmonger itself or >>>>> some other >>>>> event during upgrade? >>>> No, I don't think so. However, we cannot set Requires(posttrans), thus >>>> we should be using closest target before it, i.e. Requires(post). >>> >>> Thank you, but I think I still did not get an answer for my question. >>> >>> IIUC, the rough rpm process with regards to freeipa-server package >>> upgrade, >>> it should be in this order: >>> >>> _ >>> | >>> v >>> RPM installs some dependencies of freeipa-server >>> | >>> V >>> RPM installs "Requires(pre)" of freeipa-server >>> freeipa-server pre scriptlet runs >>> | >>> v >>> RPM installs freeipa-server >>> | >>> v >>> RPM installs "Requires(post)" of freeipa-server >>> freeipa-server post scriptlet runs >>> | >>> v >>> RPM installs some dependencies of freeipa-server >>> | >>> v >>> RPM executes posttrans scriptlets, including "ipa-server-upgrade". >> The flow above is not correct. Each scriptlet of the package is executed >> when package is installed. In particular, there is no period of waiting >> until end of whole transaction to start executing %posttrans scriptlet of >> a specific package. RPM only guarantees you that %posttrans scriptlet is >> executed as the last thing of this package intall, after all >> %post/%postun scriptlets were executed for this package and all triggers >> for affected packages were executed. > > Ah, so this was the key misunderstanding I was having. I thought that > all posttrans scripts for all packages are run in the end. > >> >> This does not guarantee that selinux-policy processing would be before >> freeipa-server processing unless we explicitly ask for the ordering via >> Requires() tag. The order of processing packages is affected by >> Requires() tag, but processing of each single package is still >> sequential. >> >>> My question is, if all the magic happens in the last step, how does >>> adding >>> (pre) or (post) Requires help, given we already have the "normal" >>> Requires? >> Because with Requires nothing guarantees selinux-policy is >> installed before freeipa-server in the same transaction, we have to use >> Requires() that would ensure we have the selinux-policy >> installation/upgrade completed by the time that stage is reached in >> freeipa-server installation/upgrade process. In reality Requires(pre) is >> often enough too but not recommended as it also could cause loop >> breaking issues. >> > > Thanks for the explanation. If this is the case, the patch should be OK > as is indeed and Requires on post should be enough. OK. Is this an ACK? -- Jan Cholasta From abokovoy at redhat.com Wed Aug 26 06:16:49 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Aug 2015 09:16:49 +0300 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DD56C3.4020306@redhat.com> References: <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> <55DCBC99.3030605@redhat.com> <20150825192242.GC22106@redhat.com> <55DCC125.30109@redhat.com> <55DD56C3.4020306@redhat.com> Message-ID: <20150826061649.GE22106@redhat.com> On Wed, 26 Aug 2015, Jan Cholasta wrote: >On 25.8.2015 21:25, Martin Kosek wrote: >>On 08/25/2015 09:22 PM, Alexander Bokovoy wrote: >>>On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>On 08/25/2015 08:59 PM, Alexander Bokovoy wrote: >>>>>On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>>>On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>>>>>>On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>>>>>On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>>>>>>On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>>>>>>On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>>>On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>>>>>>On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>>>>>Hi, >>>>>>>>>>>>> >>>>>>>>>>>>>the attached patch fixes >>>>>>>>>>>>>. >>>>>>>>>>>>> >>>>>>>>>>>>>Honza >>>>>>>>>>>>> >>>>>>>>>>>>>-- >>>>>>>>>>>>>Jan Cholasta >>>>>>>>>>>> >>>>>>>>>>>>>From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 >>>>>>>>>>>>>00:00:00 2001 >>>>>>>>>>>>>From: Jan Cholasta >>>>>>>>>>>>>Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>>>>>>Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy >>>>>>>>>>>>> >>>>>>>>>>>>>This prevents ipa-server-upgrade failures on SELinux AVCs >>>>>>>>>>>>>because of >>>>>>>>>>>>>old >>>>>>>>>>>>>selinux-policy version. >>>>>>>>>>>>> >>>>>>>>>>>>>https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>>>>>>--- >>>>>>>>>>>>>freeipa.spec.in | 1 + >>>>>>>>>>>>>1 file changed, 1 insertion(+) >>>>>>>>>>>>> >>>>>>>>>>>>>diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>>>>>>index cba91fe..fd73cda 100644 >>>>>>>>>>>>>--- a/freeipa.spec.in >>>>>>>>>>>>>+++ b/freeipa.spec.in >>>>>>>>>>>>>@@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>>>>>>Requires(pre): shadow-utils >>>>>>>>>>>>>Requires(pre): systemd-units >>>>>>>>>>>>>Requires(post): systemd-units >>>>>>>>>>>>>+Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>>>>>>Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>>>>>>Requires(post): selinux-policy-base >>>>>>>>>>>>>Requires: slapi-nis >= 0.54.2-1 >>>>>>>>>>>>If we have it in Requires(pre), we don't need it in Requires, as >>>>>>>>>>>>Requires(pre) is a superset of guarantees that Requires gives >>>>>>>>>>>>you. >>>>>>>>>>> >>>>>>>>>>>Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>>>>>>See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >>>>>>>>>>---------------- >>>>>>>>>>Since the only way out of a dependency loop is to snip the loop >>>>>>>>>>somewhere, rpm uses hints from Requires: dependencies to >>>>>>>>>>distinguish >>>>>>>>>>co-requisite (these are not needed to install, only to use, a >>>>>>>>>>package) >>>>>>>>>>from pre-requisite (these are guaranteed to be installed before >>>>>>>>>>the >>>>>>>>>>package that includes the dependency) relations. >>>>>>>>>>---------------- >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>Requires(pre) ensures that selinux-policy of specific version is >>>>>>>>>>>>installed before pre scripts of freeipa-server would run, be >>>>>>>>>>>>it in the >>>>>>>>>>>>same transaction or in a previous one. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Hmm, ipa-server-upgrade is run in posttrans. Should the >>>>>>>>>>>Requires(pre) >>>>>>>>>>>be changed to Required(posttrans)? >>>>>>>>>>I don't think there is posttrans target. Perhaps, we can just >>>>>>>>>>make sure >>>>>>>>>>Requires(post) is enough. >>>>>>>>> >>>>>>>>>OK, let's try that. Updated patch attached. >>>>>>>>> >>>>>>>> >>>>>>>>Will this really make a difference? I thought the problem is >>>>>>>>caused by >>>>>>>>selinux-policy being installed after freeipa-server package >>>>>>>>upgrade. We >>>>>>>>already >>>>>>>>have Requires on selinux-policy, so I am not sure what is actually >>>>>>>>changed by >>>>>>>>this patch. >>>>>>>The change is that with Requires(pre) or Requires(post) we are >>>>>>>guaranteed that selinux-policy is installed and available before >>>>>>>our pre >>>>>>>or post scriptlets are run. With Requires only we are not >>>>>>>guaranteed to >>>>>>>be installed after selinux-policy, only that it would be available as >>>>>>>part of the same transaction we are installed in. >>>>>>> >>>>>>>We don't really need to have Requires(pre) because we don't rely on >>>>>>>selinux-policy being available in pre scriptlet. Forcing >>>>>>>Requires(pre) >>>>>>>doesn't help anyone else (rpm/yum/dnf need to solve dependency >>>>>>>loops and >>>>>>>we are only complicating with Requires(pre) if we don't actually need >>>>>>>it). Thus, choosing Require(post) is more correct from distribution >>>>>>>point of view. >>>>>> >>>>>>Sure, but given that FreeIPA upgrade is run in the posttrans phase: >>>>>> >>>>>>%posttrans server >>>>>># This must be run in posttrans so that updates from previous >>>>>># execution that may no longer be shipped are not applied. >>>>>>/usr/sbin/ipa-server-upgrade --quiet >/dev/null || : >>>>>> >>>>>>I am now not sure how Requires(pre) or Requires(post) help here, in >>>>>>all >>>>>>cases, the right selinux-policy should be there before all the >>>>>>posttrans >>>>>>scripts are being run. >>>>>I've looked at the rpm source code and here is the list of all >>>>>supported >>>>>requires/dependencies types: >>>>>https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 >>>>> >>>>> >>>>> >>>>> >>>>>Requires(posttrans) is there so we could use this one too but it was >>>>>added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, >>>>>for >>>>>example, as they are only up to 4.11. >>>>>>Maybe the new selinux-policy is required for certmonger itself or >>>>>>some other >>>>>>event during upgrade? >>>>>No, I don't think so. However, we cannot set Requires(posttrans), thus >>>>>we should be using closest target before it, i.e. Requires(post). >>>> >>>>Thank you, but I think I still did not get an answer for my question. >>>> >>>>IIUC, the rough rpm process with regards to freeipa-server package >>>>upgrade, >>>>it should be in this order: >>>> >>>>_ >>>>| >>>>v >>>>RPM installs some dependencies of freeipa-server >>>>| >>>>V >>>>RPM installs "Requires(pre)" of freeipa-server >>>>freeipa-server pre scriptlet runs >>>>| >>>>v >>>>RPM installs freeipa-server >>>>| >>>>v >>>>RPM installs "Requires(post)" of freeipa-server >>>>freeipa-server post scriptlet runs >>>>| >>>>v >>>>RPM installs some dependencies of freeipa-server >>>>| >>>>v >>>>RPM executes posttrans scriptlets, including "ipa-server-upgrade". >>>The flow above is not correct. Each scriptlet of the package is executed >>>when package is installed. In particular, there is no period of waiting >>>until end of whole transaction to start executing %posttrans scriptlet of >>>a specific package. RPM only guarantees you that %posttrans scriptlet is >>>executed as the last thing of this package intall, after all >>>%post/%postun scriptlets were executed for this package and all triggers >>>for affected packages were executed. >> >>Ah, so this was the key misunderstanding I was having. I thought that >>all posttrans scripts for all packages are run in the end. >> >>> >>>This does not guarantee that selinux-policy processing would be before >>>freeipa-server processing unless we explicitly ask for the ordering via >>>Requires() tag. The order of processing packages is affected by >>>Requires() tag, but processing of each single package is still >>>sequential. >>> >>>>My question is, if all the magic happens in the last step, how does >>>>adding >>>>(pre) or (post) Requires help, given we already have the "normal" >>>>Requires? >>>Because with Requires nothing guarantees selinux-policy is >>>installed before freeipa-server in the same transaction, we have to use >>>Requires() that would ensure we have the selinux-policy >>>installation/upgrade completed by the time that stage is reached in >>>freeipa-server installation/upgrade process. In reality Requires(pre) is >>>often enough too but not recommended as it also could cause loop >>>breaking issues. >>> >> >>Thanks for the explanation. If this is the case, the patch should be OK >>as is indeed and Requires on post should be enough. > >OK. Is this an ACK? At least from my side it is ACK. -- / Alexander Bokovoy From jcholast at redhat.com Wed Aug 26 06:20:11 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 08:20:11 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150826061649.GE22106@redhat.com> References: <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> <55DCBC99.3030605@redhat.com> <20150825192242.GC22106@redhat.com> <55DCC125.30109@redhat.com> <55DD56C3.4020306@redhat.com> <20150826061649.GE22106@redhat.com> Message-ID: <55DD5A9B.9030301@redhat.com> On 26.8.2015 08:16, Alexander Bokovoy wrote: > On Wed, 26 Aug 2015, Jan Cholasta wrote: >> On 25.8.2015 21:25, Martin Kosek wrote: >>> On 08/25/2015 09:22 PM, Alexander Bokovoy wrote: >>>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>> On 08/25/2015 08:59 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>>>> On 08/25/2015 05:37 PM, Alexander Bokovoy wrote: >>>>>>>> On Tue, 25 Aug 2015, Martin Kosek wrote: >>>>>>>>> On 08/25/2015 04:37 PM, Jan Cholasta wrote: >>>>>>>>>> On 25.8.2015 14:50, Alexander Bokovoy wrote: >>>>>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>>>> On 25.8.2015 14:23, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Tue, 25 Aug 2015, Jan Cholasta wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> the attached patch fixes >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>>> Honza >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Jan Cholasta >>>>>>>>>>>>> >>>>>>>>>>>>>> From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 >>>>>>>>>>>>>> 00:00:00 2001 >>>>>>>>>>>>>> From: Jan Cholasta >>>>>>>>>>>>>> Date: Tue, 25 Aug 2015 14:14:25 +0200 >>>>>>>>>>>>>> Subject: [PATCH] spec file: Add Requires(pre) on >>>>>>>>>>>>>> selinux-policy >>>>>>>>>>>>>> >>>>>>>>>>>>>> This prevents ipa-server-upgrade failures on SELinux AVCs >>>>>>>>>>>>>> because of >>>>>>>>>>>>>> old >>>>>>>>>>>>>> selinux-policy version. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5256 >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> freeipa.spec.in | 1 + >>>>>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>>>>>>>>>> index cba91fe..fd73cda 100644 >>>>>>>>>>>>>> --- a/freeipa.spec.in >>>>>>>>>>>>>> +++ b/freeipa.spec.in >>>>>>>>>>>>>> @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 >>>>>>>>>>>>>> Requires(pre): shadow-utils >>>>>>>>>>>>>> Requires(pre): systemd-units >>>>>>>>>>>>>> Requires(post): systemd-units >>>>>>>>>>>>>> +Requires(pre): selinux-policy >= %{selinux_policy_version} >>>>>>>>>>>>>> Requires: selinux-policy >= %{selinux_policy_version} >>>>>>>>>>>>>> Requires(post): selinux-policy-base >>>>>>>>>>>>>> Requires: slapi-nis >= 0.54.2-1 >>>>>>>>>>>>> If we have it in Requires(pre), we don't need it in >>>>>>>>>>>>> Requires, as >>>>>>>>>>>>> Requires(pre) is a superset of guarantees that Requires gives >>>>>>>>>>>>> you. >>>>>>>>>>>> >>>>>>>>>>>> Martin (CCed) told me Requires(pre) does not imply Requires. >>>>>>>>>>> See http://rpm.org/api/4.4.2.2/tsort.html (available since >>>>>>>>>>> 2007): >>>>>>>>>>> ---------------- >>>>>>>>>>> Since the only way out of a dependency loop is to snip the loop >>>>>>>>>>> somewhere, rpm uses hints from Requires: dependencies to >>>>>>>>>>> distinguish >>>>>>>>>>> co-requisite (these are not needed to install, only to use, a >>>>>>>>>>> package) >>>>>>>>>>> from pre-requisite (these are guaranteed to be installed before >>>>>>>>>>> the >>>>>>>>>>> package that includes the dependency) relations. >>>>>>>>>>> ---------------- >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Requires(pre) ensures that selinux-policy of specific >>>>>>>>>>>>> version is >>>>>>>>>>>>> installed before pre scripts of freeipa-server would run, be >>>>>>>>>>>>> it in the >>>>>>>>>>>>> same transaction or in a previous one. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hmm, ipa-server-upgrade is run in posttrans. Should the >>>>>>>>>>>> Requires(pre) >>>>>>>>>>>> be changed to Required(posttrans)? >>>>>>>>>>> I don't think there is posttrans target. Perhaps, we can just >>>>>>>>>>> make sure >>>>>>>>>>> Requires(post) is enough. >>>>>>>>>> >>>>>>>>>> OK, let's try that. Updated patch attached. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Will this really make a difference? I thought the problem is >>>>>>>>> caused by >>>>>>>>> selinux-policy being installed after freeipa-server package >>>>>>>>> upgrade. We >>>>>>>>> already >>>>>>>>> have Requires on selinux-policy, so I am not sure what is actually >>>>>>>>> changed by >>>>>>>>> this patch. >>>>>>>> The change is that with Requires(pre) or Requires(post) we are >>>>>>>> guaranteed that selinux-policy is installed and available before >>>>>>>> our pre >>>>>>>> or post scriptlets are run. With Requires only we are not >>>>>>>> guaranteed to >>>>>>>> be installed after selinux-policy, only that it would be >>>>>>>> available as >>>>>>>> part of the same transaction we are installed in. >>>>>>>> >>>>>>>> We don't really need to have Requires(pre) because we don't rely on >>>>>>>> selinux-policy being available in pre scriptlet. Forcing >>>>>>>> Requires(pre) >>>>>>>> doesn't help anyone else (rpm/yum/dnf need to solve dependency >>>>>>>> loops and >>>>>>>> we are only complicating with Requires(pre) if we don't actually >>>>>>>> need >>>>>>>> it). Thus, choosing Require(post) is more correct from distribution >>>>>>>> point of view. >>>>>>> >>>>>>> Sure, but given that FreeIPA upgrade is run in the posttrans phase: >>>>>>> >>>>>>> %posttrans server >>>>>>> # This must be run in posttrans so that updates from previous >>>>>>> # execution that may no longer be shipped are not applied. >>>>>>> /usr/sbin/ipa-server-upgrade --quiet >/dev/null || : >>>>>>> >>>>>>> I am now not sure how Requires(pre) or Requires(post) help here, in >>>>>>> all >>>>>>> cases, the right selinux-policy should be there before all the >>>>>>> posttrans >>>>>>> scripts are being run. >>>>>> I've looked at the rpm source code and here is the list of all >>>>>> supported >>>>>> requires/dependencies types: >>>>>> https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/build/rpmfc.c#L1056 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Requires(posttrans) is there so we could use this one too but it was >>>>>> added only in 4.12-alpha which means it is missing in RHEL/CentOS 7, >>>>>> for >>>>>> example, as they are only up to 4.11. >>>>>>> Maybe the new selinux-policy is required for certmonger itself or >>>>>>> some other >>>>>>> event during upgrade? >>>>>> No, I don't think so. However, we cannot set Requires(posttrans), >>>>>> thus >>>>>> we should be using closest target before it, i.e. Requires(post). >>>>> >>>>> Thank you, but I think I still did not get an answer for my question. >>>>> >>>>> IIUC, the rough rpm process with regards to freeipa-server package >>>>> upgrade, >>>>> it should be in this order: >>>>> >>>>> _ >>>>> | >>>>> v >>>>> RPM installs some dependencies of freeipa-server >>>>> | >>>>> V >>>>> RPM installs "Requires(pre)" of freeipa-server >>>>> freeipa-server pre scriptlet runs >>>>> | >>>>> v >>>>> RPM installs freeipa-server >>>>> | >>>>> v >>>>> RPM installs "Requires(post)" of freeipa-server >>>>> freeipa-server post scriptlet runs >>>>> | >>>>> v >>>>> RPM installs some dependencies of freeipa-server >>>>> | >>>>> v >>>>> RPM executes posttrans scriptlets, including "ipa-server-upgrade". >>>> The flow above is not correct. Each scriptlet of the package is >>>> executed >>>> when package is installed. In particular, there is no period of waiting >>>> until end of whole transaction to start executing %posttrans >>>> scriptlet of >>>> a specific package. RPM only guarantees you that %posttrans >>>> scriptlet is >>>> executed as the last thing of this package intall, after all >>>> %post/%postun scriptlets were executed for this package and all >>>> triggers >>>> for affected packages were executed. >>> >>> Ah, so this was the key misunderstanding I was having. I thought that >>> all posttrans scripts for all packages are run in the end. >>> >>>> >>>> This does not guarantee that selinux-policy processing would be before >>>> freeipa-server processing unless we explicitly ask for the ordering via >>>> Requires() tag. The order of processing packages is affected by >>>> Requires() tag, but processing of each single package is still >>>> sequential. >>>> >>>>> My question is, if all the magic happens in the last step, how does >>>>> adding >>>>> (pre) or (post) Requires help, given we already have the "normal" >>>>> Requires? >>>> Because with Requires nothing guarantees selinux-policy is >>>> installed before freeipa-server in the same transaction, we have to use >>>> Requires() that would ensure we have the selinux-policy >>>> installation/upgrade completed by the time that stage is reached in >>>> freeipa-server installation/upgrade process. In reality >>>> Requires(pre) is >>>> often enough too but not recommended as it also could cause loop >>>> breaking issues. >>>> >>> >>> Thanks for the explanation. If this is the case, the patch should be OK >>> as is indeed and Requires on post should be enough. >> >> OK. Is this an ACK? > At least from my side it is ACK. Thanks for the review. Pushed to: master: aebb72e1fb144939285380a6a9261c4d4177195e ipa-4-2: 94adf097ec22b8b71ba339a9619c891f4d515ecd -- Jan Cholasta From jcholast at redhat.com Wed Aug 26 07:06:51 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 09:06:51 +0200 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <1440517848.8138.32.camel@willson.usersys.redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> <55DC36A4.5000201@redhat.com> <1440509870.8138.13.camel@willson.usersys.redhat.com> <55DC7315.4010900@redhat.com> <1440511774.8138.21.camel@willson.usersys.redhat.com> <55DC7A27.5000000@redhat.com> <1440517848.8138.32.camel@willson.usersys.redhat.com> Message-ID: <55DD658B.2040908@redhat.com> On 25.8.2015 17:50, Simo Sorce wrote: > On Tue, 2015-08-25 at 16:22 +0200, Jan Cholasta wrote: >> On 25.8.2015 16:09, Simo Sorce wrote: >>> On Tue, 2015-08-25 at 15:52 +0200, Jan Cholasta wrote: >>>> On 25.8.2015 15:37, Simo Sorce wrote: >>>>> On Tue, 2015-08-25 at 11:34 +0200, Jan Cholasta wrote: >>>>>> On 25.8.2015 11:25, Jan Cholasta wrote: >>>>>>> On 24.8.2015 19:51, Simo Sorce wrote: >>>>>>>> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in >>>>>>>> ipaserver/install when you always need both files to do anything around >>>>>>>> installation of the ca ? >>>>>>>> >>>>>>>> Is there a motivation ? >>>>>>>> Or can I simply provide a patch to remove the ca.py and kra.py files an >>>>>>>> unify all code in the proper *instance.py file ? >>>>>>> >>>>>>> ca.py and kra.py are the proper files ready to be migrated to the new >>>>>>> install framework, cainstance.py and krainstance.py will be removed. >>>>>> >>>>>> ... once the migration is done. (Hit send button too fast.) >>>>>> >>>>>> The motivation is that *instance.py do not provide a uniform interface, >>>>>> have a lot of redundant and duplicate stuff and are generally unfit for >>>>>> any further extension. >>>>> >>>>> I have been changing only the instance files, so we are going in >>>>> different directions. >>>> >>>> I don't see how, {ca,kra}instance.py code is called from {ca,kra}.py. >>>> {ca,kra}.py contains all the code that is actually needed to install >>>> CA/KRA that is not in {ca,kra}instance.py and was previously scattered >>>> around ipa-{server,replica,ca,kra}-install. >>>> >>>>> >>>>> I do not really care what file we are going into, but there is a lot of >>>>> code in the installer now that does not tell the user a step is being >>>>> done, while instances do that through the step interface. >>>> >>>> This code was always there, we only moved it to a single location. See >>>> git history. >>>> >>>>> >>>>> The step interface is also a very good way to let someone that read the >>>>> code see what is going on and follow each step. >>>>> >>>>> Are you proposing to stop going through the instances steps ? I found >>>>> the current way kra and ca installation is setup basically a regression, >>>>> it took me a *lot* longer that it should be needed to follow through all >>>>> the steps that are really taken. >>>> >>>> Again, we only moved the code around, and I don't think we created any >>>> regressions. >>> >>> Ok, so the plan is just to move the CAInstance class and code *as is* >>> from cainstance.py to ca.py ?I guess I am confused about what is your >>> plan around this exactly. >> >> The code in CAInstance will be gradually migrated to a new class in >> ca.py which uses the new install framework. We started with the >> top-level ipa-server-install and ipa-replica-install code, which is >> still not done, but you can see it for reference on how it will look >> like (ipaserver/install/server/*.py, especially the classes at the >> bottom of the files). > > Well I had to modify server/replicainstall.py quite radically, I had to > create a new set of promote_check and promote functions there. So we are > back to duplicated code, sorry (no way around it). It's OK, there is still a lot of duplicate code in server/replica install anyway, we deduplicated only the CA, KRA and DNS install code so far. > > However the functions in server/replicainstall.py still use the > instances mostly for all components *except* for kra and ca where there > is really confusing code calling unnecessarily instances multiple times > and fooling around with stuff. If you think there are unnecessary calls I think you are reading the code wrong. > I do not really understand what you mean > by migrating from CAInstance to what's in server/*install.py because in > there all instances are used for the individual components, so I am now > scratching my head. What I mean is that the code to install a component will be wrapped in a class similar to Server or Replica classes in these files. There will still be steps like in CAInstance, but the rest will be different. I don't think you have seen the PoC from 5 months ago: . > > The code in ca.py especially is really confusing, I rewrote it once to > eliminate duplications then decided to simply not touch it in my branch > (and threw away the modifications) because it is too confusing and I did > not want to risk regressions. So I created a simple create_replica() > function in the CA instance that does all that is needed. Before ca.py, you would have to rewrite the same confusing code in ipa-server-install, ipa-replica-install and ipa-ca-install. I don't see how that's better. > > I guess I will just keep ignoring the confusion and try to come up with > something that "works" but I'd really like to understand what is the > endgame there. If you want to replace instances (why?), what will you > replace it with ? With something that does not mix install with service management, maximizes code reuse and makes related code colocated, provides introspection on configuration options, allows componentization and idempotent execution. See the PoC linked above. > > Simo. > -- Jan Cholasta From jpazdziora at redhat.com Wed Aug 26 07:40:03 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 26 Aug 2015 09:40:03 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150825192242.GC22106@redhat.com> References: <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <55DC7DBE.4030605@redhat.com> <55DC85E4.5090709@redhat.com> <20150825153711.GZ22106@redhat.com> <55DCB30C.7070907@redhat.com> <20150825185947.GA22106@redhat.com> <55DCBC99.3030605@redhat.com> <20150825192242.GC22106@redhat.com> Message-ID: <20150826074003.GE24631@redhat.com> On Tue, Aug 25, 2015 at 10:22:42PM +0300, Alexander Bokovoy wrote: > > The flow above is not correct. Each scriptlet of the package is executed > when package is installed. In particular, there is no period of waiting > until end of whole transaction to start executing %posttrans scriptlet of > a specific package. RPM only guarantees you that %posttrans scriptlet is > executed as the last thing of this package intall, after all > %post/%postun scriptlets were executed for this package and all triggers > for affected packages were executed. This went against my undertanding of %posttrans, so I asked rpm maintainer and he confirmed that %posttrans scriptlets are executed as the last thing in the transaction. I might be misunderstanding what you say but I'd say that there actually is a period of waiting / postponing execution of %posttrans scriptlets of all packages until the end of the transaction. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Wed Aug 26 07:40:53 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 09:40:53 +0200 Subject: [Freeipa-devel] dnssec tests fail due to KeyError at is_record_signed method In-Reply-To: <55DCBB09.6090804@redhat.com> References: <55DCBB09.6090804@redhat.com> Message-ID: <55DD6D85.4050708@redhat.com> On 08/25/2015 08:59 PM, Oleg Fayans wrote: > Hi Martin, > > As I was running the dnssec integration tests, I noticed that 4 out of > 5 tests fail with the assumption of the dns zone being signed. > > Here is the stdout of the tests: > http://pastebin.test.redhat.com/307944 > > The failure occurs in the is_record_signed method: it catches KeyError > calling the ans.response.find_rrset method (line 37 at > test_integration/test_dnssec.py). Could you take a look at it? > Thanks I will take a look From jcholast at redhat.com Wed Aug 26 07:42:01 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 09:42:01 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <1440529242.8138.53.camel@willson.usersys.redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> <55DC4796.9020303@redhat.com> <55DC5702.5030506@redhat.com> <55DCB7C7.5010403@redhat.com> <1440529242.8138.53.camel@willson.usersys.redhat.com> Message-ID: <55DD6DC9.7060301@redhat.com> On 25.8.2015 21:00, Simo Sorce wrote: > On Tue, 2015-08-25 at 20:45 +0200, Michael ?im??ek wrote: >> >> On 2015-08-25 18:43, Robbie Harwood wrote: >>> Jan Cholasta writes: >>> >>>> On 25.8.2015 12:46, Michael ?im??ek wrote: >>>>> On 2015-08-25 12:38, Alexander Bokovoy wrote: >>>>>> On Tue, 25 Aug 2015, Michael ?im??ek wrote: >>>>>>> On 2015-08-24 20:29, Robbie Harwood wrote: >>>>>>>> Michael ?im??ek writes: >>>>>>>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>>>>>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>>>>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>>>>>>> >>>>>>>>>>> Fixed. python-gssapi has a display_as method that could pull the >>>>>>>>>>> name >>>>>>>>>>> from it, but it doesn't work in current version, therefore using >>>>>>>>>>> partition to split on '@' >>>>>>>> >>>>>>>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. So this: >>>>>>>> >>>>>>>>> - user = api.Command.user_show(unicode(principal[0]))['result'] >>>>>>>>> + user = >>>>>>>>> api.Command.user_show(principal.partition('@')[0])['result'] >>>>>>>> >>>>>>>> is working around a bug in specific Kerberos versions. If people are >>>>>>>> okay with merging such code, then I guess this is fine; I would >>>>>>>> personally not do so because there is not a clear point at which it can >>>>>>>> be removed. At the very least, we should wait until we see what >>>>>>>> versions of krb5 MIT is going to fix. >>>>>>>> >>>>>>>> Otherwise, looks good. >>>>>>>> >>>>>>>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>>>>>>> >>>>>>> >>>>>>> python-krbV migration is blocking support for Python 3. The bug >>>>>>> doesn't have any fix upstream yet and there are two bugs actually, the >>>>>>> second one is in python-gssapi, which I've just reported [1]. Waiting >>>>>>> for two bugs to be fixed could be detrimental to py3 migration as we >>>>>>> don't have much time left. And I'm no longer sure that display_as >>>>>> >>>>>> I don't buy this. >>>>>> >>>>>> We have plenty of time for solving these bugs. Remember, that Samba >>>>>> DCE RPC bindings aren't migrated to Python 3 either and will not be >>>>>> before release of Samba 4.4. For Samba 4.3 it is simply too late. >>>>>> >>>>>> So we are still far away from full Python3 migration for FreeIPA and >>>>>> waiting for solving these two bugs is OK. >>>>> >>>>> If fixing them solves anything at all. I planned to use >>>>> display_as(NameType.user), but when trying it on Name object with >>>>> name_type set (which doesn't trigger the segfault), it doesn't seem to >>>>> work either. I get: >>>>> gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The >>>>> operation or option is not available or unsupported, Minor (0): Unknown >>>>> error >>>>> >>>>> Robbie, can you clarify whether display_as could be actually used to get >>>>> the first component of the principal reliably? >>> >>> display_as should behave in accordance with its docs; anything else is a >>> bug report, which you filed. I don't know what you're asking me for >>> beyond that. >>> >> >> Why I mentioned display_as at all is that I initially assumed it could >> be used for this, but it was only an assumption because I couldn't get >> around the segfault. Later on, the cause of the segfault was found and I >> was able to try the method and I found out that it probably cannot be >> used for this purpose (i. e. extracting the first component of the >> principal) regardless of the two bugs. How I thought it would be used: >> import gssapi >> cred = gssapi.Credentials() >> user = cred.name.display_as(gssapi.NameType.user) >> >> What I got: >> gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The >> operation or option is not available or unsupported, Minor (0): Unknown >> error >> >> This seems more like the method is not intended to be used this way. So >> I'm asking you whether it is a bug or whether there is another way to do >> it. Otherwise display_as cannot be used here. >> >>>> As I have written in the other thread, we use "principal.split('@')" in >>>> other parts of IPA, so "principal.partition('@')" should be OK as well. >>>> >>>> This patch works for me, so ACK. >>>> >>>> Unless there are any further objections, I would like to push it. >>> >>> I think the newest iteration of this >>> >>>> user = api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result'] >>> >>> is even worse, but if it is decided to merge, then hopefully we can be >>> rid of it quickly. >> >> It is splitting a string of known format in a way that is used in other >> places of freeipa. What is specifically so bad about it? What do you >> suggest as an alternative? > > Given display_as() currently does not work for you go ahead with this > code. We'll revisit display_as later once we figure out more about the > bug that makes it fail. OK. Pushed to master: aad73fad601f576dd83b758f4448839b4e8e87df -- Jan Cholasta From jcholast at redhat.com Wed Aug 26 07:47:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 09:47:38 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DC6815.9090804@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> <55DC45DD.1040907@redhat.com> <55DC6815.9090804@redhat.com> Message-ID: <55DD6F1A.8080205@redhat.com> On 25.8.2015 15:05, Petr Viktorin wrote: > On 08/25/2015 12:39 PM, Christian Heimes wrote: >> On 2015-08-24 17:31, Petr Viktorin wrote: >>>>>> 0701.2-Use-Python3-compatible-dict-method-names >>>>>> NACK >>>>>> Why are you replacing iteritems() with items() instead of using >>>>>> six.iteritems()? >>> >>> It looks cleaner, and it will be easier to clean up after six is dropped. >>> Also, the performance difference is negligible if the whole thing is >>> iterated over. (On small dicts, which are the majority of what iteritems >>> was used on, items() is actually a bit faster on my machine.) >> >> Right, for small dicts the speed difference is negligible and favors the >> items() over iteritems(). For medium sized and large dicts the iterators >> are faster and consume less memory. >> >> I'm preferring iterator methods everywhere because I don't have to worry >> about dict sizes. >> >>>>>> 0710.2-Modernize-use-of-range >>>>>> NACK >>>>>> Please use six.moves.range. It defaults to xrange() in Python 2. >>> >>> Why? What is the benefit of xrange in these situations? >>> >>> Like with iteritems in 0701, when iterating over the whole thing, the >>> performance difference is negligible. I don't think a few microseconds >>> outside of tight loops are worth the verbosity. >> >> It's the same reasoning as in 0701. As long as you have a small range, >> it doesn't make a difference. For large ranges the additional memory >> usage can be problematic. >> >> In all above cases the iterator methods and generator functions are a >> safer choice. A malicious user can abuse the non-iterative methods for >> DoS attacks. As long as the input can't be controlled by a user and the >> range/dict/set/list is small, the non-iterative methods are fine. You >> have to verify every location, though. > > Keep in mind that for dicts, all the data is in memory already (in the > dict). Are you worried about DoS from an extra list of references to > existing objects? > >> I'm usually too busy with other stuff (aka lazy) to verify these >> preconditions... > > I changed one questionable use of range. The other ones are: > > ipalib/plugins/dns.py: for i in range(len(relative_record_name) > (max. ~255, verified by DNSName) > > ipaserver/install/dnskeysyncinstance.py: for _ in range(0, 16)) > (16) > > ipaserver/install/ipa_otptoken_import.py: for i in range(1, blocks + 1): > (about 7) > > ipaserver/install/ipa_otptoken_import.py: for k in range(mac.digest_size): > (16) > > ipatests/data.py: for d in range(256)) > (256) > > Plus tests, where it's rarely above 10. > I have just pushed Michael's python-krbV removal patch, which conflicts with your patches. Could you please rebase them on top of current master? -- Jan Cholasta From jpazdziora at redhat.com Wed Aug 26 08:02:33 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 26 Aug 2015 10:02:33 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150825125004.GW22106@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> Message-ID: <20150826080233.GA24416@redhat.com> On Tue, Aug 25, 2015 at 03:50:04PM +0300, Alexander Bokovoy wrote: > On Tue, 25 Aug 2015, Jan Cholasta wrote: > > On 25.8.2015 14:23, Alexander Bokovoy wrote: > > > On Tue, 25 Aug 2015, Jan Cholasta wrote: > > > > +Requires(pre): selinux-policy >= %{selinux_policy_version} > > > > Requires: selinux-policy >= %{selinux_policy_version} > > > > > > If we have it in Requires(pre), we don't need it in Requires, as > > > Requires(pre) is a superset of guarantees that Requires gives you. > > > > Martin (CCed) told me Requires(pre) does not imply Requires. > > See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): > ---------------- > Since the only way out of a dependency loop is to snip the loop > somewhere, rpm uses hints from Requires: dependencies to distinguish > co-requisite (these are not needed to install, only to use, a package) > from pre-requisite (these are guaranteed to be installed before the > package that includes the dependency) relations. However, this section seems to only apply to loop resolution. Note that http://www.rpm.org/wiki/PackagerDocs/MoreOnDependencies says about Requires(pre) * It ensures that the package providing /usr/sbin/useradd is installed before this package. In presence of dependency loops, scriptlet dependencies are the only way to ensure correct install order. * If there are no other dependencies on the package providing /usr/sbin/useradd, that package is permitted to be removed from the system after installation(!) It's a fairly common mistake to replace legacy PreReq dependencies with Requires(pre), but this is not the same, due to the latter point above! So I'd say that Requires(pre) does not imply Requires and if we only do Requires(pre): selinux-policy >= %{selinux_policy_version}, after the installation, anybody can downgrade the selinux-policy package. Heck, even in that ipa-server upgrading transaction, there could be a selinux-policy downgrade operation, which would leave the newer version for ipa-server's pre but install older version of selinux-policy after it's done with ipa-server. Yes, it's just a theoretical situation but we should not shortcut Requires with Requires(pre), it might teach people reading the .spec files bad habits. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Wed Aug 26 08:15:16 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 26 Aug 2015 10:15:16 +0200 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <55DC5D15.7020002@redhat.com> References: <55DC5D15.7020002@redhat.com> Message-ID: <20150826081516.GB24416@redhat.com> On Tue, Aug 25, 2015 at 02:18:29PM +0200, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > -- > Jan Cholasta > From 216be8de30747f80f490d4e91a7cca4af3e767d6 Mon Sep 17 00:00:00 2001 > From: Jan Cholasta > Date: Tue, 25 Aug 2015 14:14:25 +0200 > Subject: [PATCH] spec file: Add Requires(pre) on selinux-policy > > This prevents ipa-server-upgrade failures on SELinux AVCs because of old > selinux-policy version. > > https://fedorahosted.org/freeipa/ticket/5256 > --- > freeipa.spec.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/freeipa.spec.in b/freeipa.spec.in > index cba91fe..fd73cda 100644 > --- a/freeipa.spec.in > +++ b/freeipa.spec.in > @@ -139,6 +139,7 @@ Requires: systemd-units >= 38 > Requires(pre): shadow-utils > Requires(pre): systemd-units > Requires(post): systemd-units > +Requires(pre): selinux-policy >= %{selinux_policy_version} What is the core issue with https://fedorahosted.org/freeipa/ticket/5256 ? I undestand that we need new selinux-policy, but what does that policy change? I ask because if it's about labelling of files installed by rpm, the (pre) might not help because rpm did not reload the file contexts mid-transaction https://bugzilla.redhat.com/show_bug.cgi?id=505066#c9 and I'm not sure things have changed since RHEL 5. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Wed Aug 26 08:37:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 10:37:22 +0200 Subject: [Freeipa-devel] [PATCH 0301] Fix lint error related to python3 migration Message-ID: <55DD7AC2.60602@redhat.com> Master branch is broken, this patch fixes it. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0301-Fix-lint-error-cause-by-python3-migration.patch Type: text/x-patch Size: 879 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 26 08:43:54 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 10:43:54 +0200 Subject: [Freeipa-devel] [PATCH 0301] Fix lint error related to python3 migration In-Reply-To: <55DD7AC2.60602@redhat.com> References: <55DD7AC2.60602@redhat.com> Message-ID: <55DD7C4A.7000804@redhat.com> On 26.8.2015 10:37, Martin Basti wrote: > Master branch is broken, this patch fixes it. > > Patch attached. This is not a pylint error, but an actual bug. -- Jan Cholasta From mbasti at redhat.com Wed Aug 26 08:44:45 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 10:44:45 +0200 Subject: [Freeipa-devel] [PATCH 0301] Fix lint error related to python3 migration In-Reply-To: <55DD7C4A.7000804@redhat.com> References: <55DD7AC2.60602@redhat.com> <55DD7C4A.7000804@redhat.com> Message-ID: <55DD7C7D.9040008@redhat.com> On 08/26/2015 10:43 AM, Jan Cholasta wrote: > On 26.8.2015 10:37, Martin Basti wrote: >> Master branch is broken, this patch fixes it. >> >> Patch attached. > > This is not a pylint error, but an actual bug. > Sorry, I used wrong words, because It was detected by pylint. From pspacek at redhat.com Wed Aug 26 08:51:27 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Aug 2015 10:51:27 +0200 Subject: [Freeipa-devel] [PATCH 0051] IPA server and replica installers can accept options from config file In-Reply-To: <55B9CA71.6010304@redhat.com> References: <55B8A8E0.404@redhat.com> <55B8B82D.7010309@redhat.com> <55B8ED95.5040208@redhat.com> <55B8F4B3.1000904@redhat.com> <55B9CA71.6010304@redhat.com> Message-ID: <55DD7E0F.1060304@redhat.com> On 30.7.2015 08:55, Jan Cholasta wrote: > Dne 29.7.2015 v 17:43 Petr Vobornik napsal(a): >> On 07/29/2015 05:13 PM, Martin Babinsky wrote: >>> On 07/29/2015 01:25 PM, Jan Cholasta wrote: >>>> Dne 29.7.2015 v 12:20 Martin Babinsky napsal(a): >>>>> Initial attempt to implement >>>>> https://fedorahosted.org/freeipa/ticket/4517 >>>>> >>>>> Some points to discuss: >>>>> >>>>> 1.) name of the config entries: currently the option names are derived >>>>> from CLI options but have underscores in them instead of dashes. Maybe >>>>> keeping the CLI option names also for config entries will make it >>>>> easier >>>>> for the user to transfer their CLI options from scripts to config >>>>> files. >>>> >>>> NACK. There is no point in generating config names from CLI names, which >>>> are generated from knob names - use knob names directly. >>>> >>> The problem is that in some cases the cli_name does not map directly to >>> knob name, leading in different naming of CLI options and config >>> entries, confusion and mayhem. > > What works for CLI may not work for config files and vice versa. For example, > this works for CLI: > > --no-ntp > --no-forwarders > --forwarder 1.2.3.4 --forwarder 5.6.7.8 > > but this works better in config file: > > ntp = False > forwarders = > forwarders = 1.2.3.4, 5.6.7.8 Personally I would say that Honza's approach is more eye-candy but IMHO *not* more usable - and I prefer usability. Alexander's approach requires no other documentation that `ipa-server-install --help` or even better just copy&pasting arguments users already have in scripts to a file. In this case I believe that using anything incompatible with CLI arguments is not worth because it requires yet another layer of documentation to make it usable. BTW GnuPG does the very same thing as Alexander mentioned with .gnupg/gpg.conf, i.e. the config file simply accepts all options from command line, with the same names and parameters - and that that is it. Petr^2 Spacek >>> These are some offenders from `ipaserver/install/server.py`: >>> http://fpaste.org/249424/18226114/ >>> >>> On the other hand, this can be an incentive to finally put an end to >>> inconsistent option/knob naming across server/replica/etc. installers. > > Yes please. > >> >> If the names are different than cli names, then they should be made >> discoverable somehow or be documented. > > IMHO documenting them is easy. > >> >>>>> >>>>> 2.) Config sections: there is currently only one valid section named >>>>> '[global]' in accordance with the format of 'default.conf'. Should we >>>>> have separate sections equivalent to option groups in CLI (e.g. >>>>> [basic], >>>>> [certificate system], [dns])? >>>> >>>> No, because they would have to be maintained forever. For example, some >>>> options are in wrong sections and we wouldn't be able to move them. >>>> >>> I'm also more inclined to a single section, at least for now since we >>> are pressed for time with this RFE. >>> >>> That's not to say that we should ditch Alexander's idea about separate >>> sections with overrides for different hosts. We should consider it as a >>> future enhancement to this feature once the basic plumbing is in place. > > Right. > >>>>> >>>>> 3.) Handling of unattended mode when specifying a config file: >>>>> Currently there is no connection between --config-file and unattended >>>>> mode. So when you run ipa-server-install using config file, you still >>>>> get asked for missing stuff. Should '--config-file' automatically imply >>>>> '--unattended'? >>>> >>>> The behavior should be the same as if you specified the options on the >>>> command line. So no, --config-file should not imply --unattended. >>>> >>> That sound reasonable. the code behaves this way already so no changes >>> here. >>> >>>>> >>>>> There are probably other issues to discuss. Feel free to write >>>>> email/ping me on IRC. >>>>> >>>> >>>> (I haven't looked at the patch yet.) >>>> >>> Please take a look at it ASAP. I am on PTO tomorrow and on Friday, but I >>> will find time to work at it in the evening if you send me you comments. > > 1) IMO the option should be in the top-level option section, not in a separate > group (use "parser.add_option()"). > > Also maybe rename it to --config, AFAIK that's what is usually used. > > A short name ("-c"?) would be nice too. > > Nitpick: if the option is named --config-file, dest should be "config_file", > to make it easier to look it up in the code. > > > 2) Please don't duplicate the knob retrieval code, store knobs in a list and > pass that as an argument to parse_config_file. > > > 3) I'm not sure about using newline as a list separator. I don't know about > other IPA components, but SSSD in particular uses commas, maybe we should be > consistent with that? > > > 4) Booleans should be assignable either True or False, i.e. do not use > _parse_knob to parse them. > > > Honza From mbasti at redhat.com Wed Aug 26 08:57:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 10:57:21 +0200 Subject: [Freeipa-devel] [PATCH] 915 vault: change default vault type to symmetric In-Reply-To: <55DCA416.6040908@redhat.com> References: <55DC97DB.6080003@redhat.com> <55DCA416.6040908@redhat.com> Message-ID: <55DD7F71.4000501@redhat.com> On 08/25/2015 07:21 PM, Petr Vobornik wrote: > On 08/25/2015 06:29 PM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/5251 >> >> > > Attaching new rebased version with help text amended. > > ACK Pushed to: master: 19dd2ed758210e859a5b0085de558cf13ba09104 ipa-4-2: e247babc1ad211f7c939029cfb57eb6f4fbd79ab -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Aug 26 09:01:20 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 26 Aug 2015 12:01:20 +0300 Subject: [Freeipa-devel] [PATCH 477] spec file: Add Requires(pre) on selinux-policy In-Reply-To: <20150826080233.GA24416@redhat.com> References: <55DC5D15.7020002@redhat.com> <20150825122301.GV22106@redhat.com> <55DC5F31.6070208@redhat.com> <20150825125004.GW22106@redhat.com> <20150826080233.GA24416@redhat.com> Message-ID: <20150826090120.GH22106@redhat.com> On Wed, 26 Aug 2015, Jan Pazdziora wrote: >On Tue, Aug 25, 2015 at 03:50:04PM +0300, Alexander Bokovoy wrote: >> On Tue, 25 Aug 2015, Jan Cholasta wrote: >> > On 25.8.2015 14:23, Alexander Bokovoy wrote: >> > > On Tue, 25 Aug 2015, Jan Cholasta wrote: >> > > > +Requires(pre): selinux-policy >= %{selinux_policy_version} >> > > > Requires: selinux-policy >= %{selinux_policy_version} >> > > >> > > If we have it in Requires(pre), we don't need it in Requires, as >> > > Requires(pre) is a superset of guarantees that Requires gives you. >> > >> > Martin (CCed) told me Requires(pre) does not imply Requires. >> >> See http://rpm.org/api/4.4.2.2/tsort.html (available since 2007): >> ---------------- >> Since the only way out of a dependency loop is to snip the loop >> somewhere, rpm uses hints from Requires: dependencies to distinguish >> co-requisite (these are not needed to install, only to use, a package) >> from pre-requisite (these are guaranteed to be installed before the >> package that includes the dependency) relations. > >However, this section seems to only apply to loop resolution. Note >that > > http://www.rpm.org/wiki/PackagerDocs/MoreOnDependencies > >says about Requires(pre) > > * It ensures that the package providing /usr/sbin/useradd is > installed before this package. In presence of dependency > loops, scriptlet dependencies are the only way to ensure > correct install order. > * If there are no other dependencies on the package providing > /usr/sbin/useradd, that package is permitted to be removed > from the system after installation(!) > > It's a fairly common mistake to replace legacy PreReq > dependencies with Requires(pre), but this is not the > same, due to the latter point above! > >So I'd say that Requires(pre) does not imply Requires and if we only >do Requires(pre): selinux-policy >= %{selinux_policy_version}, after >the installation, anybody can downgrade the selinux-policy package. >Heck, even in that ipa-server upgrading transaction, there could be >a selinux-policy downgrade operation, which would leave the newer >version for ipa-server's pre but install older version of >selinux-policy after it's done with ipa-server. > >Yes, it's just a theoretical situation but we should not shortcut >Requires with Requires(pre), it might teach people reading the .spec >files bad habits. Well, in that case having both Requires and Requires(post) is a necessity, it seems. -- / Alexander Bokovoy From msimacek at redhat.com Wed Aug 26 09:19:09 2015 From: msimacek at redhat.com (=?UTF-8?B?TWljaGFlbCDFoGltw6HEjWVr?=) Date: Wed, 26 Aug 2015 11:19:09 +0200 Subject: [Freeipa-devel] [PATCH 0301] Fix lint error related to python3 migration In-Reply-To: <55DD7C4A.7000804@redhat.com> References: <55DD7AC2.60602@redhat.com> <55DD7C4A.7000804@redhat.com> Message-ID: <55DD848D.3060907@redhat.com> On 2015-08-26 10:43, Jan Cholasta wrote: > On 26.8.2015 10:37, Martin Basti wrote: >> Master branch is broken, this patch fixes it. >> >> Patch attached. > > This is not a pylint error, but an actual bug. > Yes, commit e46d9236d19f714b67fdf2865f19146c3016f46d (yesterday evening) added another reference to krbV after my patch for migration from krbV was reviewed. This patch looks ok to me, I'd just change the commit message (to "Remove leftover krbV reference" or something like that). Thanks, Michael From tbabej at redhat.com Wed Aug 26 09:28:59 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 26 Aug 2015 11:28:59 +0200 Subject: [Freeipa-devel] [PATCH] 914 webui: add option to establish bidirectional trust In-Reply-To: <55DC876A.9010207@redhat.com> References: <55DC876A.9010207@redhat.com> Message-ID: <55DD86DB.2010802@redhat.com> On 08/25/2015 05:19 PM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/5259 > > ACK. From ofayans at redhat.com Wed Aug 26 09:44:10 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 26 Aug 2015 11:44:10 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55D59B6B.8000606@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> Message-ID: <55DD8A6A.4060506@redhat.com> Hi Martin, On 08/20/2015 11:18 AM, Martin Basti wrote: > > > On 08/20/2015 10:26 AM, Martin Basti wrote: >> >> >> On 08/19/2015 04:17 PM, Martin Basti wrote: >>> I got this: >>> >>> https://paste.fedoraproject.org/256746/43999380/ >> FYI replica install failure. (I will retest it, but I'm pretty sure >> that it was clean VM, test for some reason install client first) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >> line 295, in decorated >> func(installer) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >> line 319, in install_check >> sys.exit("IPA client is already configured on this system.\n" >> >> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >> exception: SystemExit: IPA client is already configured on this system. >> Please uninstall it first before configuring the replica, using >> 'ipa-client-install --uninstall'. >> 2015-08-19T14:14:15Z ERROR IPA client is already configured on this >> system. >> Please uninstall it first before configuring the replica, using >> 'ipa-client-install --uninstall'. > Confirm I got same error. Fixed. It was a regex error. >> >>> >>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> As discussed, here is a new version with pep8-related fixes >>>> >>>> >>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Already noticed that. Implemented the named groups as Tomas advised. >>>>> Added the third test for >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>> NACK, comments inline. >>>>>>>> >>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> Thanks for the review! >>>>>>>>> >>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>> >>>>>>>>>> 1) >>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>> My bad, fixed. >>>>>>>> >>>>>>>> still there >>>>>>>> >>>>>>>> + tokenize_topologies(command_output) >>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>> returns an >>>>>>>> array of >>>>>>>> >>>>>>> Fixed, sorry. >>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) >>>>>>>>>> >>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>> + creates a topology segment. The first argument is a node to >>>>>>>>>> run the >>>>>>>>>> command on >>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>> + Returns a hash object containing segment's name, leftnode, >>>>>>>>>> rightnode information >>>>>>>>>> + """ >>>>>>>>>> >>>>>>>>>> I would prefer to add assert there instead of just document >>>>>>>>>> that a >>>>>>>>>> Host >>>>>>>>>> object is needed >>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>> ... >>>>>>>>> >>>>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>>>> >>>>>>>> This does not scale well. >>>>>>>> If we will want to add new argument that is not host object, you >>>>>>>> need >>>>>>>> change it again. >>>>>>> >>>>>>> Agreed. Modified the decorator so that you can specify a slice of >>>>>>> arguments to be checked and a class to compare to. This does >>>>>>> scale :) >>>>>>>> >>>>>>>> This might be used as function with specified variables that >>>>>>>> have to be >>>>>>>> host objects >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) >>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>> + """ >>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>> object of >>>>>>>>>> class >>>>>>>>>> Host >>>>>>>>>> >>>>>>>>>> Instead of description of params as first, second etc., you >>>>>>>>>> may use >>>>>>>>>> following: >>>>>>>>>> >>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>> + """ >>>>>>>>>> + Destroys topology segment. >>>>>>>>>> + :param master: reference to master object of class Host >>>>>>>>>> + :param segment: name fo segment >>>>>>>>>> and eventually this in other methods >>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>> >>>>>>>>> Fixed >>>>>>>>>> >>>>>>>>>> 4) >>>>>>>>>> >>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>> >>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>> >>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>> >>>>>>>>>> In [3]: a[:-1] >>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>> >>>>>>>>> Fixed >>>>>>>>>> >>>>>>>>>> 5) >>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>> >>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>> >>>>>>>>> in fact >>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>> and >>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>> Are equally bad from the readability point of view. The first >>>>>>>>> one is >>>>>>>>> even shorter a bit, so why change? :) >>>>>>>> >>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>> yesterday my >>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>> values to >>>>>>>> single value attribute, because you used findall, I expected >>>>>>>> that you >>>>>>>> need multiple values, and then I saw that index [0] at the end, >>>>>>>> and I >>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>> >>>>>>>> And because findall is not effective in case when you need to >>>>>>>> find just >>>>>>>> one occurrence. >>>>>>> >>>>>>> I got it. Fixed. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Python 3 nitpick: >>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>> compability >>>>>>>>>> already comes, but just for record: >>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>> (import io >>>>>>>>>> before) >>>>>>>>>> >>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> 1) >>>>>>>> >>>>>>>> +# >>>>>>>> >>>>>>>> empty comment here (several times) >>>>>>> >>>>>>> Removed >>>>>>>> >>>>>>> >>>>>> >>>>>> NACK >>>>>> >>>>>> you changed it wrong >>>>>> >>>>>> group() returns everything, you need use group(1) to return >>>>>> content in >>>>>> braces. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.7-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 16450 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 26 09:48:28 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 11:48:28 +0200 Subject: [Freeipa-devel] [PATCH 0051] IPA server and replica installers can accept options from config file In-Reply-To: <55DD7E0F.1060304@redhat.com> References: <55B8A8E0.404@redhat.com> <55B8B82D.7010309@redhat.com> <55B8ED95.5040208@redhat.com> <55B8F4B3.1000904@redhat.com> <55B9CA71.6010304@redhat.com> <55DD7E0F.1060304@redhat.com> Message-ID: <55DD8B6C.706@redhat.com> On 26.8.2015 10:51, Petr Spacek wrote: > On 30.7.2015 08:55, Jan Cholasta wrote: >> Dne 29.7.2015 v 17:43 Petr Vobornik napsal(a): >>> On 07/29/2015 05:13 PM, Martin Babinsky wrote: >>>> On 07/29/2015 01:25 PM, Jan Cholasta wrote: >>>>> Dne 29.7.2015 v 12:20 Martin Babinsky napsal(a): >>>>>> Initial attempt to implement >>>>>> https://fedorahosted.org/freeipa/ticket/4517 >>>>>> >>>>>> Some points to discuss: >>>>>> >>>>>> 1.) name of the config entries: currently the option names are derived >>>>>> from CLI options but have underscores in them instead of dashes. Maybe >>>>>> keeping the CLI option names also for config entries will make it >>>>>> easier >>>>>> for the user to transfer their CLI options from scripts to config >>>>>> files. >>>>> >>>>> NACK. There is no point in generating config names from CLI names, which >>>>> are generated from knob names - use knob names directly. >>>>> >>>> The problem is that in some cases the cli_name does not map directly to >>>> knob name, leading in different naming of CLI options and config >>>> entries, confusion and mayhem. >> >> What works for CLI may not work for config files and vice versa. For example, >> this works for CLI: >> >> --no-ntp >> --no-forwarders >> --forwarder 1.2.3.4 --forwarder 5.6.7.8 >> >> but this works better in config file: >> >> ntp = False >> forwarders = >> forwarders = 1.2.3.4, 5.6.7.8 > > Personally I would say that Honza's approach is more eye-candy but IMHO *not* > more usable - and I prefer usability. Alexander's approach requires no other > documentation that `ipa-server-install --help` or even better just > copy&pasting arguments users already have in scripts to a file. > > In this case I believe that using anything incompatible with CLI arguments is > not worth because it requires yet another layer of documentation to make it > usable. > > BTW GnuPG does the very same thing as Alexander mentioned with > .gnupg/gpg.conf, i.e. the config file simply accepts all options from command > line, with the same names and parameters - and that that is it. Sorry, but no. The installers are supposed to be callable from many different kinds of often incompatible environments. How exactly would you imagine e.g. a Python API to look like given it should use the same conventions as CLI? Like this: server_install(['no_ntp', ('forwarder', '1.2.3.4'), ('forwarder', '5.6.7.8')]) ? I would very much prefer if it looked like this: server_install(ntp=False, forwarders=['1.2.3.4', '5.6.7.8']) which is pretty much the same I suggested for config files and better reflects the semantics of setting configuration options. > > Petr^2 Spacek > >>>> These are some offenders from `ipaserver/install/server.py`: >>>> http://fpaste.org/249424/18226114/ >>>> >>>> On the other hand, this can be an incentive to finally put an end to >>>> inconsistent option/knob naming across server/replica/etc. installers. >> >> Yes please. >> >>> >>> If the names are different than cli names, then they should be made >>> discoverable somehow or be documented. >> >> IMHO documenting them is easy. >> >>> >>>>>> >>>>>> 2.) Config sections: there is currently only one valid section named >>>>>> '[global]' in accordance with the format of 'default.conf'. Should we >>>>>> have separate sections equivalent to option groups in CLI (e.g. >>>>>> [basic], >>>>>> [certificate system], [dns])? >>>>> >>>>> No, because they would have to be maintained forever. For example, some >>>>> options are in wrong sections and we wouldn't be able to move them. >>>>> >>>> I'm also more inclined to a single section, at least for now since we >>>> are pressed for time with this RFE. >>>> >>>> That's not to say that we should ditch Alexander's idea about separate >>>> sections with overrides for different hosts. We should consider it as a >>>> future enhancement to this feature once the basic plumbing is in place. >> >> Right. >> >>>>>> >>>>>> 3.) Handling of unattended mode when specifying a config file: >>>>>> Currently there is no connection between --config-file and unattended >>>>>> mode. So when you run ipa-server-install using config file, you still >>>>>> get asked for missing stuff. Should '--config-file' automatically imply >>>>>> '--unattended'? >>>>> >>>>> The behavior should be the same as if you specified the options on the >>>>> command line. So no, --config-file should not imply --unattended. >>>>> >>>> That sound reasonable. the code behaves this way already so no changes >>>> here. >>>> >>>>>> >>>>>> There are probably other issues to discuss. Feel free to write >>>>>> email/ping me on IRC. >>>>>> >>>>> >>>>> (I haven't looked at the patch yet.) >>>>> >>>> Please take a look at it ASAP. I am on PTO tomorrow and on Friday, but I >>>> will find time to work at it in the evening if you send me you comments. >> >> 1) IMO the option should be in the top-level option section, not in a separate >> group (use "parser.add_option()"). >> >> Also maybe rename it to --config, AFAIK that's what is usually used. >> >> A short name ("-c"?) would be nice too. >> >> Nitpick: if the option is named --config-file, dest should be "config_file", >> to make it easier to look it up in the code. >> >> >> 2) Please don't duplicate the knob retrieval code, store knobs in a list and >> pass that as an argument to parse_config_file. >> >> >> 3) I'm not sure about using newline as a list separator. I don't know about >> other IPA components, but SSSD in particular uses commas, maybe we should be >> consistent with that? >> >> >> 4) Booleans should be assignable either True or False, i.e. do not use >> _parse_knob to parse them. >> >> >> Honza > -- Jan Cholasta From tbabej at redhat.com Wed Aug 26 09:50:23 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 26 Aug 2015 11:50:23 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DD8A6A.4060506@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> Message-ID: <55DD8BDF.6050202@redhat.com> On 08/26/2015 11:44 AM, Oleg Fayans wrote: > Hi Martin, > > On 08/20/2015 11:18 AM, Martin Basti wrote: >> >> >> On 08/20/2015 10:26 AM, Martin Basti wrote: >>> >>> >>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>> I got this: >>>> >>>> https://paste.fedoraproject.org/256746/43999380/ >>> FYI replica install failure. (I will retest it, but I'm pretty sure >>> that it was clean VM, test for some reason install client first) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> >>> line 295, in decorated >>> func(installer) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>> >>> line 319, in install_check >>> sys.exit("IPA client is already configured on this system.\n" >>> >>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >>> exception: SystemExit: IPA client is already configured on this system. >>> Please uninstall it first before configuring the replica, using >>> 'ipa-client-install --uninstall'. >>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on this >>> system. >>> Please uninstall it first before configuring the replica, using >>> 'ipa-client-install --uninstall'. >> Confirm I got same error. > Fixed. It was a regex error. > >>> >>>> >>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> As discussed, here is a new version with pep8-related fixes >>>>> >>>>> >>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Already noticed that. Implemented the named groups as Tomas advised. >>>>>> Added the third test for >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>> NACK, comments inline. >>>>>>>>> >>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> Thanks for the review! >>>>>>>>>> >>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>> My bad, fixed. >>>>>>>>> >>>>>>>>> still there >>>>>>>>> >>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>> returns an >>>>>>>>> array of >>>>>>>>> >>>>>>>> Fixed, sorry. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2) >>>>>>>>>>> >>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>> + creates a topology segment. The first argument is a node to >>>>>>>>>>> run the >>>>>>>>>>> command on >>>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>>> + Returns a hash object containing segment's name, leftnode, >>>>>>>>>>> rightnode information >>>>>>>>>>> + """ >>>>>>>>>>> >>>>>>>>>>> I would prefer to add assert there instead of just document >>>>>>>>>>> that a >>>>>>>>>>> Host >>>>>>>>>>> object is needed >>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>>>>> >>>>>>>>> This does not scale well. >>>>>>>>> If we will want to add new argument that is not host object, you >>>>>>>>> need >>>>>>>>> change it again. >>>>>>>> >>>>>>>> Agreed. Modified the decorator so that you can specify a slice of >>>>>>>> arguments to be checked and a class to compare to. This does >>>>>>>> scale :) >>>>>>>>> >>>>>>>>> This might be used as function with specified variables that >>>>>>>>> have to be >>>>>>>>> host objects >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3) >>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>> + """ >>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>> object of >>>>>>>>>>> class >>>>>>>>>>> Host >>>>>>>>>>> >>>>>>>>>>> Instead of description of params as first, second etc., you >>>>>>>>>>> may use >>>>>>>>>>> following: >>>>>>>>>>> >>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>> + """ >>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>> + :param master: reference to master object of class Host >>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>> and eventually this in other methods >>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>> >>>>>>>>>> Fixed >>>>>>>>>>> >>>>>>>>>>> 4) >>>>>>>>>>> >>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>> >>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>> >>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>> >>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>> >>>>>>>>>> Fixed >>>>>>>>>>> >>>>>>>>>>> 5) >>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>> >>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>> >>>>>>>>>> in fact >>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>> and >>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>> Are equally bad from the readability point of view. The first >>>>>>>>>> one is >>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>> >>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>> yesterday my >>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>> values to >>>>>>>>> single value attribute, because you used findall, I expected >>>>>>>>> that you >>>>>>>>> need multiple values, and then I saw that index [0] at the end, >>>>>>>>> and I >>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>> >>>>>>>>> And because findall is not effective in case when you need to >>>>>>>>> find just >>>>>>>>> one occurrence. >>>>>>>> >>>>>>>> I got it. Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>> compability >>>>>>>>>>> already comes, but just for record: >>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>>> (import io >>>>>>>>>>> before) >>>>>>>>>>> >>>>>>>>>> Done. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> >>>>>>>>> +# >>>>>>>>> >>>>>>>>> empty comment here (several times) >>>>>>>> >>>>>>>> Removed >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> NACK >>>>>>> >>>>>>> you changed it wrong >>>>>>> >>>>>>> group() returns everything, you need use group(1) to return >>>>>>> content in >>>>>>> braces. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > > Please, do not use third-party URL shorteners from within our source code. Tomas From ofayans at redhat.com Wed Aug 26 09:54:07 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 26 Aug 2015 11:54:07 +0200 Subject: [Freeipa-devel] [PATCH 0006] Fixed installation failures In-Reply-To: <55DD71A9.2060905@redhat.com> References: <55DAF83C.3030407@redhat.com> <55DB2BC3.5000201@redhat.com> <55DC9AC6.8020207@redhat.com> <55DD71A9.2060905@redhat.com> Message-ID: <55DD8CBF.1010502@redhat.com> Hi Martin, On 08/26/2015 09:58 AM, Martin Basti wrote: > > > On 08/25/2015 06:41 PM, Oleg Fayans wrote: >> Hi Martin, >> >> On 08/24/2015 04:35 PM, Martin Basti wrote: >>> >>> >>> On 08/24/2015 12:55 PM, Oleg Fayans wrote: >>>> Hi all. The current issue [1] effectively blocks testing of 4.2 >>>> branch. Here is (one of the possible) solution, that proved to work. >>>> >>>> [1] >>>> https://www.redhat.com/archives/freeipa-devel/2015-August/msg00085.html >>>> >>>> >>>> >>> The patch needs rebase for ipa-4-2 branch. >> What is the best way to do it? >> git checkout --track origin/ipa-4-2 >> And then commit the same changes again? >> >> > I usually do cherrypick, or just apply patch on top of ipa-4-2 branch > with threeway merge (git am -3 option) > > I had discussion, yesterday, with Honza, and maybe this is not the > correct fix. > We are in hurry today with RHEL 7.2, but later I may send updated patch Cool, I'll wait then. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pspacek at redhat.com Wed Aug 26 10:00:50 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 26 Aug 2015 12:00:50 +0200 Subject: [Freeipa-devel] [PATCH 0051] IPA server and replica installers can accept options from config file In-Reply-To: <55DD8B6C.706@redhat.com> References: <55B8A8E0.404@redhat.com> <55B8B82D.7010309@redhat.com> <55B8ED95.5040208@redhat.com> <55B8F4B3.1000904@redhat.com> <55B9CA71.6010304@redhat.com> <55DD7E0F.1060304@redhat.com> <55DD8B6C.706@redhat.com> Message-ID: <55DD8E52.1000901@redhat.com> On 26.8.2015 11:48, Jan Cholasta wrote: > On 26.8.2015 10:51, Petr Spacek wrote: >> On 30.7.2015 08:55, Jan Cholasta wrote: >>> Dne 29.7.2015 v 17:43 Petr Vobornik napsal(a): >>>> On 07/29/2015 05:13 PM, Martin Babinsky wrote: >>>>> On 07/29/2015 01:25 PM, Jan Cholasta wrote: >>>>>> Dne 29.7.2015 v 12:20 Martin Babinsky napsal(a): >>>>>>> Initial attempt to implement >>>>>>> https://fedorahosted.org/freeipa/ticket/4517 >>>>>>> >>>>>>> Some points to discuss: >>>>>>> >>>>>>> 1.) name of the config entries: currently the option names are derived >>>>>>> from CLI options but have underscores in them instead of dashes. Maybe >>>>>>> keeping the CLI option names also for config entries will make it >>>>>>> easier >>>>>>> for the user to transfer their CLI options from scripts to config >>>>>>> files. >>>>>> >>>>>> NACK. There is no point in generating config names from CLI names, which >>>>>> are generated from knob names - use knob names directly. >>>>>> >>>>> The problem is that in some cases the cli_name does not map directly to >>>>> knob name, leading in different naming of CLI options and config >>>>> entries, confusion and mayhem. >>> >>> What works for CLI may not work for config files and vice versa. For example, >>> this works for CLI: >>> >>> --no-ntp >>> --no-forwarders >>> --forwarder 1.2.3.4 --forwarder 5.6.7.8 >>> >>> but this works better in config file: >>> >>> ntp = False >>> forwarders = >>> forwarders = 1.2.3.4, 5.6.7.8 >> >> Personally I would say that Honza's approach is more eye-candy but IMHO *not* >> more usable - and I prefer usability. Alexander's approach requires no other >> documentation that `ipa-server-install --help` or even better just >> copy&pasting arguments users already have in scripts to a file. >> >> In this case I believe that using anything incompatible with CLI arguments is >> not worth because it requires yet another layer of documentation to make it >> usable. >> >> BTW GnuPG does the very same thing as Alexander mentioned with >> .gnupg/gpg.conf, i.e. the config file simply accepts all options from command >> line, with the same names and parameters - and that that is it. > > Sorry, but no. The installers are supposed to be callable from many different > kinds of often incompatible environments. How exactly would you imagine e.g. a > Python API to look like given it should use the same conventions as CLI? Like > this: > > server_install(['no_ntp', ('forwarder', '1.2.3.4'), ('forwarder', > '5.6.7.8')]) > > ? I would very much prefer if it looked like this: > > server_install(ntp=False, forwarders=['1.2.3.4', '5.6.7.8']) > > which is pretty much the same I suggested for config files and better reflects > the semantics of setting configuration options. I'm just saying that: 1. API & user-interface on CLI are not the same, so there is no need to strictly use the same names in API and CLI (which we apparently do not do, compare --help and internal knobs). 2. User interface self-consistency (CLI options vs. configuration file) is more important that consistency between config file and API. Petr^2 Spacek >>>>> These are some offenders from `ipaserver/install/server.py`: >>>>> http://fpaste.org/249424/18226114/ >>>>> >>>>> On the other hand, this can be an incentive to finally put an end to >>>>> inconsistent option/knob naming across server/replica/etc. installers. >>> >>> Yes please. >>> >>>> >>>> If the names are different than cli names, then they should be made >>>> discoverable somehow or be documented. >>> >>> IMHO documenting them is easy. >>> >>>> >>>>>>> >>>>>>> 2.) Config sections: there is currently only one valid section named >>>>>>> '[global]' in accordance with the format of 'default.conf'. Should we >>>>>>> have separate sections equivalent to option groups in CLI (e.g. >>>>>>> [basic], >>>>>>> [certificate system], [dns])? >>>>>> >>>>>> No, because they would have to be maintained forever. For example, some >>>>>> options are in wrong sections and we wouldn't be able to move them. >>>>>> >>>>> I'm also more inclined to a single section, at least for now since we >>>>> are pressed for time with this RFE. >>>>> >>>>> That's not to say that we should ditch Alexander's idea about separate >>>>> sections with overrides for different hosts. We should consider it as a >>>>> future enhancement to this feature once the basic plumbing is in place. >>> >>> Right. >>> >>>>>>> >>>>>>> 3.) Handling of unattended mode when specifying a config file: >>>>>>> Currently there is no connection between --config-file and unattended >>>>>>> mode. So when you run ipa-server-install using config file, you still >>>>>>> get asked for missing stuff. Should '--config-file' automatically imply >>>>>>> '--unattended'? >>>>>> >>>>>> The behavior should be the same as if you specified the options on the >>>>>> command line. So no, --config-file should not imply --unattended. >>>>>> >>>>> That sound reasonable. the code behaves this way already so no changes >>>>> here. >>>>> >>>>>>> >>>>>>> There are probably other issues to discuss. Feel free to write >>>>>>> email/ping me on IRC. >>>>>>> >>>>>> >>>>>> (I haven't looked at the patch yet.) >>>>>> >>>>> Please take a look at it ASAP. I am on PTO tomorrow and on Friday, but I >>>>> will find time to work at it in the evening if you send me you comments. >>> >>> 1) IMO the option should be in the top-level option section, not in a separate >>> group (use "parser.add_option()"). >>> >>> Also maybe rename it to --config, AFAIK that's what is usually used. >>> >>> A short name ("-c"?) would be nice too. >>> >>> Nitpick: if the option is named --config-file, dest should be "config_file", >>> to make it easier to look it up in the code. >>> >>> >>> 2) Please don't duplicate the knob retrieval code, store knobs in a list and >>> pass that as an argument to parse_config_file. >>> >>> >>> 3) I'm not sure about using newline as a list separator. I don't know about >>> other IPA components, but SSSD in particular uses commas, maybe we should be >>> consistent with that? >>> >>> >>> 4) Booleans should be assignable either True or False, i.e. do not use >>> _parse_knob to parse them. From mbasti at redhat.com Wed Aug 26 10:13:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 12:13:22 +0200 Subject: [Freeipa-devel] [PATCH 0301] Fix: Remove leftover krbV reference In-Reply-To: <55DD848D.3060907@redhat.com> References: <55DD7AC2.60602@redhat.com> <55DD7C4A.7000804@redhat.com> <55DD848D.3060907@redhat.com> Message-ID: <55DD9142.3090801@redhat.com> On 08/26/2015 11:19 AM, Michael ?im??ek wrote: > > > On 2015-08-26 10:43, Jan Cholasta wrote: >> On 26.8.2015 10:37, Martin Basti wrote: >>> Master branch is broken, this patch fixes it. >>> >>> Patch attached. >> >> This is not a pylint error, but an actual bug. >> > > Yes, commit e46d9236d19f714b67fdf2865f19146c3016f46d (yesterday > evening) added another reference to krbV after my patch for migration > from krbV was reviewed. This patch looks ok to me, I'd just change the > commit message (to "Remove leftover krbV reference" or something like > that). > > Thanks, > Michael Fixed. updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0301.2-Fix-Remove-leftover-krbV-reference.patch Type: text/x-patch Size: 873 bytes Desc: not available URL: From pviktori at redhat.com Wed Aug 26 10:15:44 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Aug 2015 12:15:44 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DD6F1A.8080205@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> <55DC45DD.1040907@redhat.com> <55DC6815.9090804@redhat.com> <55DD6F1A.8080205@redhat.com> Message-ID: <55DD91D0.7040109@redhat.com> On 08/26/2015 09:47 AM, Jan Cholasta wrote: > On 25.8.2015 15:05, Petr Viktorin wrote: >> On 08/25/2015 12:39 PM, Christian Heimes wrote: >>> On 2015-08-24 17:31, Petr Viktorin wrote: >>>>>>> 0701.2-Use-Python3-compatible-dict-method-names >>>>>>> NACK >>>>>>> Why are you replacing iteritems() with items() instead of using >>>>>>> six.iteritems()? >>>> >>>> It looks cleaner, and it will be easier to clean up after six is >>>> dropped. >>>> Also, the performance difference is negligible if the whole thing is >>>> iterated over. (On small dicts, which are the majority of what >>>> iteritems >>>> was used on, items() is actually a bit faster on my machine.) >>> >>> Right, for small dicts the speed difference is negligible and favors the >>> items() over iteritems(). For medium sized and large dicts the iterators >>> are faster and consume less memory. >>> >>> I'm preferring iterator methods everywhere because I don't have to worry >>> about dict sizes. >>> >>>>>>> 0710.2-Modernize-use-of-range >>>>>>> NACK >>>>>>> Please use six.moves.range. It defaults to xrange() in Python 2. >>>> >>>> Why? What is the benefit of xrange in these situations? >>>> >>>> Like with iteritems in 0701, when iterating over the whole thing, the >>>> performance difference is negligible. I don't think a few microseconds >>>> outside of tight loops are worth the verbosity. >>> >>> It's the same reasoning as in 0701. As long as you have a small range, >>> it doesn't make a difference. For large ranges the additional memory >>> usage can be problematic. >>> >>> In all above cases the iterator methods and generator functions are a >>> safer choice. A malicious user can abuse the non-iterative methods for >>> DoS attacks. As long as the input can't be controlled by a user and the >>> range/dict/set/list is small, the non-iterative methods are fine. You >>> have to verify every location, though. >> >> Keep in mind that for dicts, all the data is in memory already (in the >> dict). Are you worried about DoS from an extra list of references to >> existing objects? >> >>> I'm usually too busy with other stuff (aka lazy) to verify these >>> preconditions... >> >> I changed one questionable use of range. The other ones are: >> >> ipalib/plugins/dns.py: for i in range(len(relative_record_name) >> (max. ~255, verified by DNSName) >> >> ipaserver/install/dnskeysyncinstance.py: for _ in range(0, 16)) >> (16) >> >> ipaserver/install/ipa_otptoken_import.py: for i in range(1, blocks + 1): >> (about 7) >> >> ipaserver/install/ipa_otptoken_import.py: for k in >> range(mac.digest_size): >> (16) >> >> ipatests/data.py: for d in range(256)) >> (256) >> >> Plus tests, where it's rarely above 10. >> > > I have just pushed Michael's python-krbV removal patch, which conflicts > with your patches. Could you please rebase them on top of current master? > Sure, here they are. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0696.5-Remove-use-of-sys.exc_value.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0697.5-Don-t-use-a-tuple-in-function-arguments.patch Type: text/x-patch Size: 907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0698.5-Add-python-six-to-dependencies.patch Type: text/x-patch Size: 984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0699.5-Remove-the-unused-pygettext-script.patch Type: text/x-patch Size: 30062 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0700.5-Use-six.string_types-instead-of-basestring.patch Type: text/x-patch Size: 35449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0701.5-Use-Python3-compatible-dict-method-names.patch Type: text/x-patch Size: 73485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0702.5-Replace-filter-calls-with-list-comprehensions.patch Type: text/x-patch Size: 6514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0703.5-Use-six.moves.input-instead-of-raw_input.patch Type: text/x-patch Size: 3100 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0704.5-Use-six.integer_types-instead-of-long-int.patch Type: text/x-patch Size: 8301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0705.5-Replace-uses-of-map.patch Type: text/x-patch Size: 18773 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0706.5-Use-next-function-on-iterators.patch Type: text/x-patch Size: 3481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0707.5-Use-the-print-function.patch Type: text/x-patch Size: 229158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0708.5-Use-new-style-raise-syntax.patch Type: text/x-patch Size: 6956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0709.5-Use-six.reraise.patch Type: text/x-patch Size: 1892 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0710.5-Modernize-use-of-range.patch Type: text/x-patch Size: 18088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0711.5-Convert-zip-result-to-list.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: From jcholast at redhat.com Wed Aug 26 10:44:16 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 12:44:16 +0200 Subject: [Freeipa-devel] [PATCH 0051] IPA server and replica installers can accept options from config file In-Reply-To: <55DD8E52.1000901@redhat.com> References: <55B8A8E0.404@redhat.com> <55B8B82D.7010309@redhat.com> <55B8ED95.5040208@redhat.com> <55B8F4B3.1000904@redhat.com> <55B9CA71.6010304@redhat.com> <55DD7E0F.1060304@redhat.com> <55DD8B6C.706@redhat.com> <55DD8E52.1000901@redhat.com> Message-ID: <55DD9880.4010903@redhat.com> On 26.8.2015 12:00, Petr Spacek wrote: > On 26.8.2015 11:48, Jan Cholasta wrote: >> On 26.8.2015 10:51, Petr Spacek wrote: >>> On 30.7.2015 08:55, Jan Cholasta wrote: >>>> Dne 29.7.2015 v 17:43 Petr Vobornik napsal(a): >>>>> On 07/29/2015 05:13 PM, Martin Babinsky wrote: >>>>>> On 07/29/2015 01:25 PM, Jan Cholasta wrote: >>>>>>> Dne 29.7.2015 v 12:20 Martin Babinsky napsal(a): >>>>>>>> Initial attempt to implement >>>>>>>> https://fedorahosted.org/freeipa/ticket/4517 >>>>>>>> >>>>>>>> Some points to discuss: >>>>>>>> >>>>>>>> 1.) name of the config entries: currently the option names are derived >>>>>>>> from CLI options but have underscores in them instead of dashes. Maybe >>>>>>>> keeping the CLI option names also for config entries will make it >>>>>>>> easier >>>>>>>> for the user to transfer their CLI options from scripts to config >>>>>>>> files. >>>>>>> >>>>>>> NACK. There is no point in generating config names from CLI names, which >>>>>>> are generated from knob names - use knob names directly. >>>>>>> >>>>>> The problem is that in some cases the cli_name does not map directly to >>>>>> knob name, leading in different naming of CLI options and config >>>>>> entries, confusion and mayhem. >>>> >>>> What works for CLI may not work for config files and vice versa. For example, >>>> this works for CLI: >>>> >>>> --no-ntp >>>> --no-forwarders >>>> --forwarder 1.2.3.4 --forwarder 5.6.7.8 >>>> >>>> but this works better in config file: >>>> >>>> ntp = False >>>> forwarders = >>>> forwarders = 1.2.3.4, 5.6.7.8 >>> >>> Personally I would say that Honza's approach is more eye-candy but IMHO *not* >>> more usable - and I prefer usability. Alexander's approach requires no other >>> documentation that `ipa-server-install --help` or even better just >>> copy&pasting arguments users already have in scripts to a file. >>> >>> In this case I believe that using anything incompatible with CLI arguments is >>> not worth because it requires yet another layer of documentation to make it >>> usable. >>> >>> BTW GnuPG does the very same thing as Alexander mentioned with >>> .gnupg/gpg.conf, i.e. the config file simply accepts all options from command >>> line, with the same names and parameters - and that that is it. >> >> Sorry, but no. The installers are supposed to be callable from many different >> kinds of often incompatible environments. How exactly would you imagine e.g. a >> Python API to look like given it should use the same conventions as CLI? Like >> this: >> >> server_install(['no_ntp', ('forwarder', '1.2.3.4'), ('forwarder', >> '5.6.7.8')]) >> >> ? I would very much prefer if it looked like this: >> >> server_install(ntp=False, forwarders=['1.2.3.4', '5.6.7.8']) >> >> which is pretty much the same I suggested for config files and better reflects >> the semantics of setting configuration options. > > I'm just saying that: > 1. API & user-interface on CLI are not the same, so there is no need to > strictly use the same names in API and CLI (which we apparently do not do, > compare --help and internal knobs). > > 2. User interface self-consistency (CLI options vs. configuration file) is > more important that consistency between config file and API. User interface is not necessarily only CLI and config files and I would prefer not to mutilate the user interface in general with CLI specifics. If you want 100% CLI compatibility you can do the following and don't bother with any new code in IPA at all: $ echo --no-ntp >options $ echo --forwarder 1.2.3.4 >>options $ echo --forwarder 5.6.7.8 >>options $ ipa-server-install $(cat options) Interface consistency is important in any case, and providing it in one place just to sacrifice it in other place does not really improve anything. > > Petr^2 Spacek > >>>>>> These are some offenders from `ipaserver/install/server.py`: >>>>>> http://fpaste.org/249424/18226114/ >>>>>> >>>>>> On the other hand, this can be an incentive to finally put an end to >>>>>> inconsistent option/knob naming across server/replica/etc. installers. >>>> >>>> Yes please. >>>> >>>>> >>>>> If the names are different than cli names, then they should be made >>>>> discoverable somehow or be documented. >>>> >>>> IMHO documenting them is easy. >>>> >>>>> >>>>>>>> >>>>>>>> 2.) Config sections: there is currently only one valid section named >>>>>>>> '[global]' in accordance with the format of 'default.conf'. Should we >>>>>>>> have separate sections equivalent to option groups in CLI (e.g. >>>>>>>> [basic], >>>>>>>> [certificate system], [dns])? >>>>>>> >>>>>>> No, because they would have to be maintained forever. For example, some >>>>>>> options are in wrong sections and we wouldn't be able to move them. >>>>>>> >>>>>> I'm also more inclined to a single section, at least for now since we >>>>>> are pressed for time with this RFE. >>>>>> >>>>>> That's not to say that we should ditch Alexander's idea about separate >>>>>> sections with overrides for different hosts. We should consider it as a >>>>>> future enhancement to this feature once the basic plumbing is in place. >>>> >>>> Right. >>>> >>>>>>>> >>>>>>>> 3.) Handling of unattended mode when specifying a config file: >>>>>>>> Currently there is no connection between --config-file and unattended >>>>>>>> mode. So when you run ipa-server-install using config file, you still >>>>>>>> get asked for missing stuff. Should '--config-file' automatically imply >>>>>>>> '--unattended'? >>>>>>> >>>>>>> The behavior should be the same as if you specified the options on the >>>>>>> command line. So no, --config-file should not imply --unattended. >>>>>>> >>>>>> That sound reasonable. the code behaves this way already so no changes >>>>>> here. >>>>>> >>>>>>>> >>>>>>>> There are probably other issues to discuss. Feel free to write >>>>>>>> email/ping me on IRC. >>>>>>>> >>>>>>> >>>>>>> (I haven't looked at the patch yet.) >>>>>>> >>>>>> Please take a look at it ASAP. I am on PTO tomorrow and on Friday, but I >>>>>> will find time to work at it in the evening if you send me you comments. >>>> >>>> 1) IMO the option should be in the top-level option section, not in a separate >>>> group (use "parser.add_option()"). >>>> >>>> Also maybe rename it to --config, AFAIK that's what is usually used. >>>> >>>> A short name ("-c"?) would be nice too. >>>> >>>> Nitpick: if the option is named --config-file, dest should be "config_file", >>>> to make it easier to look it up in the code. >>>> >>>> >>>> 2) Please don't duplicate the knob retrieval code, store knobs in a list and >>>> pass that as an argument to parse_config_file. >>>> >>>> >>>> 3) I'm not sure about using newline as a list separator. I don't know about >>>> other IPA components, but SSSD in particular uses commas, maybe we should be >>>> consistent with that? >>>> >>>> >>>> 4) Booleans should be assignable either True or False, i.e. do not use >>>> _parse_knob to parse them. -- Jan Cholasta From jcholast at redhat.com Wed Aug 26 10:53:28 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 12:53:28 +0200 Subject: [Freeipa-devel] [PATCH 0301] Fix: Remove leftover krbV reference In-Reply-To: <55DD9142.3090801@redhat.com> References: <55DD7AC2.60602@redhat.com> <55DD7C4A.7000804@redhat.com> <55DD848D.3060907@redhat.com> <55DD9142.3090801@redhat.com> Message-ID: <55DD9AA8.4010407@redhat.com> On 26.8.2015 12:13, Martin Basti wrote: > > > On 08/26/2015 11:19 AM, Michael ?im??ek wrote: >> >> >> On 2015-08-26 10:43, Jan Cholasta wrote: >>> On 26.8.2015 10:37, Martin Basti wrote: >>>> Master branch is broken, this patch fixes it. >>>> >>>> Patch attached. >>> >>> This is not a pylint error, but an actual bug. >>> >> >> Yes, commit e46d9236d19f714b67fdf2865f19146c3016f46d (yesterday >> evening) added another reference to krbV after my patch for migration >> from krbV was reviewed. This patch looks ok to me, I'd just change the >> commit message (to "Remove leftover krbV reference" or something like >> that). >> >> Thanks, >> Michael > > Fixed. > > updated patch attached. ACK. Pushed to master: 14a87632e5df30dd2b44a1ca49e6b308d2249c70 -- Jan Cholasta From mbasti at redhat.com Wed Aug 26 11:02:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 13:02:33 +0200 Subject: [Freeipa-devel] [PATCH] 913 fix missing information in object metadata In-Reply-To: <55DC81B2.4080109@redhat.com> References: <55DC81B2.4080109@redhat.com> Message-ID: <55DD9CC9.7000204@redhat.com> On 08/25/2015 04:54 PM, Petr Vobornik wrote: > Missing 'required' values in takes_params causes Web UI to treat required > fields as optional. > > Regression caused by ba0a1c6b33e2519a48754602413c8379fb1f0ff1 > > https://fedorahosted.org/freeipa/ticket/5258 > > ACK Pushed to: master: d01f18d4417e3073f31981dedfc8a200b3a42eb9 ipa-4-2: 42e8ab8c39c24fa9dca2d7a6dc4f75b7ae6e8b9a -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Aug 26 11:06:17 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 13:06:17 +0200 Subject: [Freeipa-devel] [PATCH] 914 webui: add option to establish bidirectional trust In-Reply-To: <55DD86DB.2010802@redhat.com> References: <55DC876A.9010207@redhat.com> <55DD86DB.2010802@redhat.com> Message-ID: <55DD9DA9.1080902@redhat.com> On 08/26/2015 11:28 AM, Tomas Babej wrote: > > On 08/25/2015 05:19 PM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/5259 >> >> > ACK. > Pushed to: master: d7b096486e05defc1de2cc3c9f5582061b8e4060 ipa-4-2: b1f1dcaab3c2b4799ef12a417a9998d7556496af From pvoborni at redhat.com Wed Aug 26 11:22:38 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Aug 2015 13:22:38 +0200 Subject: [Freeipa-devel] [PATCH] 916 vault: add vault container commands In-Reply-To: <55DCAE47.5080500@redhat.com> References: <55DCAE47.5080500@redhat.com> Message-ID: <55DDA17E.9050403@redhat.com> On 08/25/2015 08:04 PM, Petr Vobornik wrote: > adds commands: > * vaultcontainer-show [--service |--user ] > * vaultcontainer-add-owner > [--service |--user ] > [--users ] [--groups ] [--services ] > * vaultcontainer-remove-owner > [--service |--user ] > [--users ] [--groups ] [--services ] > > https://fedorahosted.org/freeipa/ticket/5250 > > Use cases: > 1. When user/service is deleted, associated vault container looses > owner. There was no API command to set the owner. > 2. Change owner of container by admin to manage access. > > Show command was added to show current owners. > > Find command was not added, should it be? > > There is also a design for vault container ownership handling created by Endi - it's for future Vault 2.0. http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner This patch has a different API than the proposed - different way of specifying the container. The design page uses path e.g. /users/foobar. This patch uses the same way as vaults e.g. --user=foobar. This means that the implementation in this patch cannot manage ownership of parent vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX. Do we want to go with this approach in 4.2? Attaching also new path which removes setting of owner which doesn't exist so that integrity is OK and that it is consistent with removing of user. Updated patch attached - output fix. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0918-vault-set-vaultcontainer-owner-only-if-exists.patch Type: text/x-patch Size: 1363 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0916-1-vault-add-vault-container-commands.patch Type: text/x-patch Size: 10066 bytes Desc: not available URL: From pvoborni at redhat.com Wed Aug 26 11:24:45 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Aug 2015 13:24:45 +0200 Subject: [Freeipa-devel] [PATCH] 919 vault: fix vault tests after default type change Message-ID: <55DDA1FD.7020809@redhat.com> vault test should no longer hang on interactive prompt. Doesn't fix other issues in vault tests. https://fedorahosted.org/freeipa/ticket/5251 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0919-vault-fix-vault-tests-after-default-type-change.patch Type: text/x-patch Size: 2167 bytes Desc: not available URL: From pvoborni at redhat.com Wed Aug 26 11:52:20 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Aug 2015 13:52:20 +0200 Subject: [Freeipa-devel] [PATCH] 376 Removed clear text passwords from KRA install log. In-Reply-To: <20150822061748.GL22106@redhat.com> References: <55D7B85D.1090708@redhat.com> <20150822061748.GL22106@redhat.com> Message-ID: <55DDA874.9060506@redhat.com> On 08/22/2015 08:17 AM, Alexander Bokovoy wrote: > On Fri, 21 Aug 2015, Endi Sukma Dewata wrote: >> The ipa-kra-install tool has been modified to use password files >> instead of clear text passwords when invoking pki tool such that >> the passwords are no longer visible in ipaserver-kra-install.log. >> >> https://fedorahosted.org/freeipa/ticket/5246 >> >> -- >> Endi S. Dewata > >> From 545de89d5b8992469335415d209b6f04be6918ed Mon Sep 17 00:00:00 2001 >> From: "Endi S. Dewata" >> Date: Sat, 22 Aug 2015 01:14:16 +0200 >> Subject: [PATCH] Removed clear text passwords from KRA install log. >> >> The ipa-kra-install tool has been modified to use password files >> instead of clear text passwords when invoking pki tool such that >> the passwords are no longer visible in ipaserver-kra-install.log. >> >> https://fedorahosted.org/freeipa/ticket/5246 >> --- >> ipaplatform/base/paths.py | 2 ++ >> ipaserver/install/krainstance.py | 16 ++++++++-------- >> 2 files changed, 10 insertions(+), 8 deletions(-) >> >> diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py >> index >> 0dd3c7fda3020264a1ace8f2d13557cfddf18c2d..5c8f25d6ef85fab2b9b30a660cd1c0360dbe9931 >> 100644 >> --- a/ipaplatform/base/paths.py >> +++ b/ipaplatform/base/paths.py >> @@ -343,6 +343,8 @@ class BasePathNamespace(object): >> SLAPD_INSTANCE_SOCKET_TEMPLATE = "/var/run/slapd-%s.socket" >> ALL_SLAPD_INSTANCE_SOCKETS = "/var/run/slapd-*.socket" >> ADMIN_CERT_PATH = '/root/.dogtag/pki-tomcat/ca_admin.cert' >> + KRA_NSSDB_PASSWORD_FILE = >> "/root/.dogtag/pki-tomcat/kra/password.conf" >> + KRA_PKCS12_PASSWORD_FILE = >> "/root/.dogtag/pki-tomcat/kra/pkcs12_password.conf" > ACK. Pushed to: master: 8676364ae8260a5894b0b0c2af8e81b10aeaba6b ipa-4-2: 4e474c5a20b91d4eed75f514f801b40f1f291e65 > > For the record, these files are created by pki-spawn early in the > creation of security databases for CA deployment. The second file isnt > created > if CA is deployed with HSM option (the databases are in hardware then) but > then the first one is created for HSM and thus both of them are in use. > > We don't support deployment with HSM backend yet, but the code covers > both cases. > > In future it would be good to actually source these values from > /etc/pki/default.cfg: > > pki_client_password_conf=%(pki_client_subsystem_dir)s/password.conf > pki_client_pkcs12_password_conf=%(pki_client_subsystem_dir)s/pkcs12_password.conf > but right now this would mean need to use dogtag's Python helpers from > pki.server.deployment.pkiparser.PKIConfigParser.read_pki_configuration_file() > to do > actual sourcing of the config file but right now PKIConfigParser use > assumes it is actually parsing the command line options/arguments before > using its methods: >>>> from pki.server.deployment.pkiparser import PKIConfigParser >>>> cfg = PKIConfigParser('IPA CA', '') >>>> cfg.init_config() > Traceback (most recent call last): > File "", line 1, in > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", > line 196, in init_config > 'pki_subsystem_type': config.pki_subsystem.lower(), > AttributeError: 'NoneType' object has no attribute 'lower' >>>> > -- Petr Vobornik From pvoborni at redhat.com Wed Aug 26 11:55:50 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Aug 2015 13:55:50 +0200 Subject: [Freeipa-devel] [PATCH] 0040 certprofile: prevent rename (modrdn) In-Reply-To: <1440512345.8138.22.camel@willson.usersys.redhat.com> References: <20150825003553.GA15011@dhcp-40-8.bne.redhat.com> <20150825053711.GQ22106@redhat.com> <55DC3D5A.9060202@redhat.com> <20150825103942.GT22106@redhat.com> <20150825114905.GD15011@dhcp-40-8.bne.redhat.com> <1440512345.8138.22.camel@willson.usersys.redhat.com> Message-ID: <55DDA946.6030800@redhat.com> On 08/25/2015 04:19 PM, Simo Sorce wrote: > On Tue, 2015-08-25 at 21:49 +1000, Fraser Tweedale wrote: >> On Tue, Aug 25, 2015 at 01:39:42PM +0300, Alexander Bokovoy wrote: >>> On Tue, 25 Aug 2015, Petr Vobornik wrote: >>>> On 08/25/2015 07:37 AM, Alexander Bokovoy wrote: >>>>> On Tue, 25 Aug 2015, Fraser Tweedale wrote: >>>>>> The attached patch fixes >>>>>> https://fedorahosted.org/freeipa/ticket/5247. >>>>>> >>>>>> Thanks, >>>>>> Fraser >>>>> >>>>> >From 2cb4ab6eeedccc3471ed9bf983add4687ecd5c1a Mon Sep 17 00:00:00 2001 >>>>>> From: Fraser Tweedale >>>>>> Date: Mon, 24 Aug 2015 20:25:10 -0400 >>>>>> Subject: [PATCH] certprofile: prevent rename (modrdn) >>>>>> >>>>>> Fixes: https://fedorahosted.org/freeipa/ticket/5247 >>>>>> --- >>>>>> ipalib/plugins/certprofile.py | 5 +++-- >>>>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/ipalib/plugins/certprofile.py >>>>>> b/ipalib/plugins/certprofile.py >>>>>> index >>>>>> 007cc543406b7e5705fd7474f3685cd6a9ce6aca..a0ffa38608400860994c771e4eba81304ead27be >>>>>> 100644 >>>>>> --- a/ipalib/plugins/certprofile.py >>>>>> +++ b/ipalib/plugins/certprofile.py >>>>>> @@ -323,8 +323,9 @@ class certprofile_mod(LDAPUpdate): >>>>>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >>>>>> **options): >>>>>> ca_enabled_check() >>>>>> # Once a profile id is set it cannot be changed >>>>>> - if 'cn' in entry_attrs: >>>>>> - raise errors.ACIError(info=_('cn is immutable')) >>>>>> + if 'rename' in options or 'cn' in entry_attrs: >>>>>> + raise errors.ProtectedEntryError(label='certprofile', >>>>>> key=keys[0], >>>>>> + reason=_('Certificate profiles cannot be renamed')) >>>>>> if 'file' in options: >>>>>> with self.api.Backend.ra_certprofile as profile_api: >>>>>> profile_api.disable_profile(keys[0]) >>>>> ACK >>>> >>>> can't we fix it by removing `rdn_is_primary_key = True`? >>>> >>>> That would also remove the --rename option. Yes it's an API change but if >>>> rename is forbidden than the option should not be even there, just the >>>> result error will different. >>> Well, that is another option, yes. Perhaps even a better one -- we have >>> plenty of places where rdn_is_primary_key is not actually used. >>> >> I filed a ticket for this: https://fedorahosted.org/freeipa/ticket/5254 >> >> There are a bunch of commands that have this situation - not just >> certprofile - so if we're going to break API in one place IMO we >> should do them all at once. > > Why do we need to break the API ? > Just deny it. > > Simo. > > OK, original patch pushed to: master: 5c7d6a6a31daca8bf92d85d8c1895279be84c888 ipa-4-2: d943bf09799e6faf2dd83f630bcfd6f99575c5c8 -- Petr Vobornik From mbasti at redhat.com Wed Aug 26 12:04:43 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 14:04:43 +0200 Subject: [Freeipa-devel] [PATCH] 919 vault: fix vault tests after default type change In-Reply-To: <55DDA1FD.7020809@redhat.com> References: <55DDA1FD.7020809@redhat.com> Message-ID: <55DDAB5B.8070504@redhat.com> On 08/26/2015 01:24 PM, Petr Vobornik wrote: > vault test should no longer hang on interactive prompt. Doesn't fix > other issues in vault tests. > > https://fedorahosted.org/freeipa/ticket/5251 ACK Pushed to: master: 9b0a01930bcefda1f37d7de147fed0856c28296f ipa-4-2: 91de475fd9d4499c05052e74bd2918569da4f269 From dkupka at redhat.com Wed Aug 26 12:13:38 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 26 Aug 2015 14:13:38 +0200 Subject: [Freeipa-devel] [PATCH 0065] vault: Limit size of data stored in vault Message-ID: <55DDAD72.8030509@redhat.com> https://fedorahosted.org/freeipa/ticket/5231 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0065-vault-Limit-size-of-data-stored-in-vault.patch Type: text/x-patch Size: 2661 bytes Desc: not available URL: From simo at redhat.com Wed Aug 26 12:48:04 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Aug 2015 08:48:04 -0400 Subject: [Freeipa-devel] kra an ca instance installation In-Reply-To: <55DD658B.2040908@redhat.com> References: <1440438682.3305.25.camel@willson.usersys.redhat.com> <55DC3470.2050507@redhat.com> <55DC36A4.5000201@redhat.com> <1440509870.8138.13.camel@willson.usersys.redhat.com> <55DC7315.4010900@redhat.com> <1440511774.8138.21.camel@willson.usersys.redhat.com> <55DC7A27.5000000@redhat.com> <1440517848.8138.32.camel@willson.usersys.redhat.com> <55DD658B.2040908@redhat.com> Message-ID: <1440593284.8138.68.camel@willson.usersys.redhat.com> On Wed, 2015-08-26 at 09:06 +0200, Jan Cholasta wrote: > On 25.8.2015 17:50, Simo Sorce wrote: > > On Tue, 2015-08-25 at 16:22 +0200, Jan Cholasta wrote: > >> On 25.8.2015 16:09, Simo Sorce wrote: > >>> On Tue, 2015-08-25 at 15:52 +0200, Jan Cholasta wrote: > >>>> On 25.8.2015 15:37, Simo Sorce wrote: > >>>>> On Tue, 2015-08-25 at 11:34 +0200, Jan Cholasta wrote: > >>>>>> On 25.8.2015 11:25, Jan Cholasta wrote: > >>>>>>> On 24.8.2015 19:51, Simo Sorce wrote: > >>>>>>>> Why do we have cainstance.py and ca.py and krainstance.py and kra.py in > >>>>>>>> ipaserver/install when you always need both files to do anything around > >>>>>>>> installation of the ca ? > >>>>>>>> > >>>>>>>> Is there a motivation ? > >>>>>>>> Or can I simply provide a patch to remove the ca.py and kra.py files an > >>>>>>>> unify all code in the proper *instance.py file ? > >>>>>>> > >>>>>>> ca.py and kra.py are the proper files ready to be migrated to the new > >>>>>>> install framework, cainstance.py and krainstance.py will be removed. > >>>>>> > >>>>>> ... once the migration is done. (Hit send button too fast.) > >>>>>> > >>>>>> The motivation is that *instance.py do not provide a uniform interface, > >>>>>> have a lot of redundant and duplicate stuff and are generally unfit for > >>>>>> any further extension. > >>>>> > >>>>> I have been changing only the instance files, so we are going in > >>>>> different directions. > >>>> > >>>> I don't see how, {ca,kra}instance.py code is called from {ca,kra}.py. > >>>> {ca,kra}.py contains all the code that is actually needed to install > >>>> CA/KRA that is not in {ca,kra}instance.py and was previously scattered > >>>> around ipa-{server,replica,ca,kra}-install. > >>>> > >>>>> > >>>>> I do not really care what file we are going into, but there is a lot of > >>>>> code in the installer now that does not tell the user a step is being > >>>>> done, while instances do that through the step interface. > >>>> > >>>> This code was always there, we only moved it to a single location. See > >>>> git history. > >>>> > >>>>> > >>>>> The step interface is also a very good way to let someone that read the > >>>>> code see what is going on and follow each step. > >>>>> > >>>>> Are you proposing to stop going through the instances steps ? I found > >>>>> the current way kra and ca installation is setup basically a regression, > >>>>> it took me a *lot* longer that it should be needed to follow through all > >>>>> the steps that are really taken. > >>>> > >>>> Again, we only moved the code around, and I don't think we created any > >>>> regressions. > >>> > >>> Ok, so the plan is just to move the CAInstance class and code *as is* > >>> from cainstance.py to ca.py ?I guess I am confused about what is your > >>> plan around this exactly. > >> > >> The code in CAInstance will be gradually migrated to a new class in > >> ca.py which uses the new install framework. We started with the > >> top-level ipa-server-install and ipa-replica-install code, which is > >> still not done, but you can see it for reference on how it will look > >> like (ipaserver/install/server/*.py, especially the classes at the > >> bottom of the files). > > > > Well I had to modify server/replicainstall.py quite radically, I had to > > create a new set of promote_check and promote functions there. So we are > > back to duplicated code, sorry (no way around it). > > It's OK, there is still a lot of duplicate code in server/replica > install anyway, we deduplicated only the CA, KRA and DNS install code so > far. > > > > > However the functions in server/replicainstall.py still use the > > instances mostly for all components *except* for kra and ca where there > > is really confusing code calling unnecessarily instances multiple times > > and fooling around with stuff. > > If you think there are unnecessary calls I think you are reading the > code wrong. > > > I do not really understand what you mean > > by migrating from CAInstance to what's in server/*install.py because in > > there all instances are used for the individual components, so I am now > > scratching my head. > > What I mean is that the code to install a component will be wrapped in a > class similar to Server or Replica classes in these files. There will > still be steps like in CAInstance, but the rest will be different. I > don't think you have seen the PoC from 5 months ago: > . I had not seen this, thanks. > > > > The code in ca.py especially is really confusing, I rewrote it once to > > eliminate duplications then decided to simply not touch it in my branch > > (and threw away the modifications) because it is too confusing and I did > > not want to risk regressions. So I created a simple create_replica() > > function in the CA instance that does all that is needed. > > Before ca.py, you would have to rewrite the same confusing code in > ipa-server-install, ipa-replica-install and ipa-ca-install. I don't see > how that's better. > > > > > I guess I will just keep ignoring the confusion and try to come up with > > something that "works" but I'd really like to understand what is the > > endgame there. If you want to replace instances (why?), what will you > > replace it with ? > > With something that does not mix install with service management, > maximizes code reuse and makes related code colocated, provides > introspection on configuration options, allows componentization and > idempotent execution. See the PoC linked above. Ok, I'll ask more questions as they come and if needed, thanks for explaining. Simo. -- Simo Sorce * Red Hat, Inc * New York From ofayans at redhat.com Wed Aug 26 12:53:14 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 26 Aug 2015 14:53:14 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DD8BDF.6050202@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> <55DD8BDF.6050202@redhat.com> Message-ID: <55DDB6BA.7060102@redhat.com> Hi, No more short links :) On 08/26/2015 11:50 AM, Tomas Babej wrote: > > > On 08/26/2015 11:44 AM, Oleg Fayans wrote: >> Hi Martin, >> >> On 08/20/2015 11:18 AM, Martin Basti wrote: >>> >>> >>> On 08/20/2015 10:26 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>>> I got this: >>>>> >>>>> https://paste.fedoraproject.org/256746/43999380/ >>>> FYI replica install failure. (I will retest it, but I'm pretty sure >>>> that it was clean VM, test for some reason install client first) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>> >>>> line 295, in decorated >>>> func(installer) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>> >>>> line 319, in install_check >>>> sys.exit("IPA client is already configured on this system.\n" >>>> >>>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >>>> exception: SystemExit: IPA client is already configured on this system. >>>> Please uninstall it first before configuring the replica, using >>>> 'ipa-client-install --uninstall'. >>>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on this >>>> system. >>>> Please uninstall it first before configuring the replica, using >>>> 'ipa-client-install --uninstall'. >>> Confirm I got same error. >> Fixed. It was a regex error. >> >>>> >>>>> >>>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> As discussed, here is a new version with pep8-related fixes >>>>>> >>>>>> >>>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> Already noticed that. Implemented the named groups as Tomas advised. >>>>>>> Added the third test for >>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>>> NACK, comments inline. >>>>>>>>>> >>>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> Thanks for the review! >>>>>>>>>>> >>>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>>> >>>>>>>>>>>> 1) >>>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>>> My bad, fixed. >>>>>>>>>> >>>>>>>>>> still there >>>>>>>>>> >>>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>>> returns an >>>>>>>>>> array of >>>>>>>>>> >>>>>>>>> Fixed, sorry. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) >>>>>>>>>>>> >>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>> + creates a topology segment. The first argument is a node to >>>>>>>>>>>> run the >>>>>>>>>>>> command on >>>>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>>>> + Returns a hash object containing segment's name, leftnode, >>>>>>>>>>>> rightnode information >>>>>>>>>>>> + """ >>>>>>>>>>>> >>>>>>>>>>>> I would prefer to add assert there instead of just document >>>>>>>>>>>> that a >>>>>>>>>>>> Host >>>>>>>>>>>> object is needed >>>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>>>>>> >>>>>>>>>> This does not scale well. >>>>>>>>>> If we will want to add new argument that is not host object, you >>>>>>>>>> need >>>>>>>>>> change it again. >>>>>>>>> >>>>>>>>> Agreed. Modified the decorator so that you can specify a slice of >>>>>>>>> arguments to be checked and a class to compare to. This does >>>>>>>>> scale :) >>>>>>>>>> >>>>>>>>>> This might be used as function with specified variables that >>>>>>>>>> have to be >>>>>>>>>> host objects >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3) >>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>> + """ >>>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>>> object of >>>>>>>>>>>> class >>>>>>>>>>>> Host >>>>>>>>>>>> >>>>>>>>>>>> Instead of description of params as first, second etc., you >>>>>>>>>>>> may use >>>>>>>>>>>> following: >>>>>>>>>>>> >>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>> + """ >>>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>>> + :param master: reference to master object of class Host >>>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>>> and eventually this in other methods >>>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>>> >>>>>>>>>>> Fixed >>>>>>>>>>>> >>>>>>>>>>>> 4) >>>>>>>>>>>> >>>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>>> >>>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>>> >>>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>>> >>>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>>> >>>>>>>>>>> Fixed >>>>>>>>>>>> >>>>>>>>>>>> 5) >>>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>>> >>>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>>> >>>>>>>>>>> in fact >>>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>>> and >>>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>>> Are equally bad from the readability point of view. The first >>>>>>>>>>> one is >>>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>>> >>>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>>> yesterday my >>>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>>> values to >>>>>>>>>> single value attribute, because you used findall, I expected >>>>>>>>>> that you >>>>>>>>>> need multiple values, and then I saw that index [0] at the end, >>>>>>>>>> and I >>>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>>> >>>>>>>>>> And because findall is not effective in case when you need to >>>>>>>>>> find just >>>>>>>>>> one occurrence. >>>>>>>>> >>>>>>>>> I got it. Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>>> compability >>>>>>>>>>>> already comes, but just for record: >>>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>>>> (import io >>>>>>>>>>>> before) >>>>>>>>>>>> >>>>>>>>>>> Done. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1) >>>>>>>>>> >>>>>>>>>> +# >>>>>>>>>> >>>>>>>>>> empty comment here (several times) >>>>>>>>> >>>>>>>>> Removed >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> NACK >>>>>>>> >>>>>>>> you changed it wrong >>>>>>>> >>>>>>>> group() returns everything, you need use group(1) to return >>>>>>>> content in >>>>>>>> braces. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > > Please, do not use third-party URL shorteners from within our source code. > > Tomas > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.8-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 16992 bytes Desc: not available URL: From dkupka at redhat.com Wed Aug 26 13:16:28 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 26 Aug 2015 15:16:28 +0200 Subject: [Freeipa-devel] [PATCH 0066] ipactl: Do not start/stop/restart single service multiple times Message-ID: <55DDBC2C.7040807@redhat.com> https://fedorahosted.org/freeipa/ticket/5248 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0066-ipactl-Do-not-start-stop-restart-single-service-mult.patch Type: text/x-patch Size: 2669 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 26 13:29:14 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 15:29:14 +0200 Subject: [Freeipa-devel] import krbV error Message-ID: <55DDBF2A.2020104@redhat.com> I got following error during rpm install. 2015-08-26T13:25:40Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2015-08-26T13:25:40Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 44, in run api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 651, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 365, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 529, in load_plugins self.import_plugins(module) File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 567, in import_plugins module = importlib.import_module(name) File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) File "/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py", line 30, in import krbV 2015-08-26T13:25:40Z DEBUG The ipa-server-upgrade command failed, exception: ImportError: No module named krbV 2015-08-26T13:25:40Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: ImportError: No module named krbV From mbasti at redhat.com Wed Aug 26 13:31:47 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 15:31:47 +0200 Subject: [Freeipa-devel] import krbV error In-Reply-To: <55DDBF2A.2020104@redhat.com> References: <55DDBF2A.2020104@redhat.com> Message-ID: <55DDBFC3.3060400@redhat.com> On 08/26/2015 03:29 PM, Martin Basti wrote: > I got following error during rpm install. > > 2015-08-26T13:25:40Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > 2015-08-26T13:25:40Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, > in execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > line 44, in run > api.finalize() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line > 651, in finalize > self.__do_if_not_done('load_plugins') > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line > 365, in __do_if_not_done > getattr(self, name)() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line > 529, in load_plugins > self.import_plugins(module) > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line > 567, in import_plugins > module = importlib.import_module(name) > File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in > import_module > __import__(name) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py", > line 30, in > import krbV > > 2015-08-26T13:25:40Z DEBUG The ipa-server-upgrade command failed, > exception: ImportError: No module named krbV > 2015-08-26T13:25:40Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > ImportError: No module named krbV > You can ignore this, error is probably on my side. From jcholast at redhat.com Wed Aug 26 13:33:01 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 26 Aug 2015 15:33:01 +0200 Subject: [Freeipa-devel] import krbV error In-Reply-To: <55DDBF2A.2020104@redhat.com> References: <55DDBF2A.2020104@redhat.com> Message-ID: <55DDC00D.3020202@redhat.com> On 26.8.2015 15:29, Martin Basti wrote: > I got following error during rpm install. > > 2015-08-26T13:25:40Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > 2015-08-26T13:25:40Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > line 44, in run > api.finalize() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 651, > in finalize > self.__do_if_not_done('load_plugins') > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 365, > in __do_if_not_done > getattr(self, name)() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 529, > in load_plugins > self.import_plugins(module) > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 567, > in import_plugins > module = importlib.import_module(name) > File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in > import_module > __import__(name) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py", > line 30, in > import krbV > > 2015-08-26T13:25:40Z DEBUG The ipa-server-upgrade command failed, > exception: ImportError: No module named krbV > 2015-08-26T13:25:40Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > ImportError: No module named krbV > ipalib/plugins/kerberos.py was removed in git master. I guess that on your system it is a leftover from previous install. Remove the file and everything should be fine. -- Jan Cholasta From pvoborni at redhat.com Wed Aug 26 13:45:59 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Aug 2015 15:45:59 +0200 Subject: [Freeipa-devel] [PATCH 0065] vault: Limit size of data stored in vault In-Reply-To: <55DDAD72.8030509@redhat.com> References: <55DDAD72.8030509@redhat.com> Message-ID: <55DDC317.1070005@redhat.com> On 08/26/2015 02:13 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/5231 > > Attaching updated patch. With changes discussed offline. Not related to the patch: This patch limits the size to 1MB instead of proposed 10MB. Testing showed that even 10MB raises a MemoryError in archive_encrypted_data which is AFAIK a KraClient method - Endi, this sounds as something which should be also handled in PKI. Especially when it happens the subsequent vault-archive command ends with HTTPError: 503 Server Error: Service Unavailable. After restart of pki, subsequent vault-archive with 1M file took about 4mins (in vault_retrieve_internal). Next archive command with 1M file took "only" 18s. 10k file took 9s. Why is it so slow? -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0065-2-vault-Limit-size-of-data-stored-in-vault.patch Type: text/x-patch Size: 2081 bytes Desc: not available URL: From dkupka at redhat.com Wed Aug 26 13:56:41 2015 From: dkupka at redhat.com (David Kupka) Date: Wed, 26 Aug 2015 15:56:41 +0200 Subject: [Freeipa-devel] [PATCH 0065] vault: Limit size of data stored in vault In-Reply-To: <55DDC317.1070005@redhat.com> References: <55DDAD72.8030509@redhat.com> <55DDC317.1070005@redhat.com> Message-ID: <55DDC599.7060600@redhat.com> On 26/08/15 15:45, Petr Vobornik wrote: > On 08/26/2015 02:13 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/5231 >> >> > > Attaching updated patch. With changes discussed offline. Changes works for me, ACK. > > Not related to the patch: > This patch limits the size to 1MB instead of proposed 10MB. Testing > showed that even 10MB raises a MemoryError in archive_encrypted_data > which is AFAIK a KraClient method - Endi, this sounds as something which > should be also handled in PKI. > > Especially when it happens the subsequent vault-archive command ends > with HTTPError: 503 Server Error: Service Unavailable. After restart of > pki, subsequent vault-archive with 1M file took about 4mins (in > vault_retrieve_internal). Next archive command with 1M file took "only" > 18s. > > 10k file took 9s. > > Why is it so slow? -- David Kupka From pvoborni at redhat.com Wed Aug 26 14:15:28 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Aug 2015 16:15:28 +0200 Subject: [Freeipa-devel] [PATCH 0065] vault: Limit size of data stored in vault In-Reply-To: <55DDC599.7060600@redhat.com> References: <55DDAD72.8030509@redhat.com> <55DDC317.1070005@redhat.com> <55DDC599.7060600@redhat.com> Message-ID: <55DDCA00.40501@redhat.com> On 08/26/2015 03:56 PM, David Kupka wrote: > On 26/08/15 15:45, Petr Vobornik wrote: >> On 08/26/2015 02:13 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/5231 >>> >>> >> >> Attaching updated patch. With changes discussed offline. > > Changes works for me, ACK. (with the changes it is also ACK from me) Pushed to: master: 02ab34c60b5e624ef0653a473316633a5618b07c ipa-4-2: 9fc82bc66992eaa5daeed80e366e10986a8583d8 > >> >> Not related to the patch: >> This patch limits the size to 1MB instead of proposed 10MB. Testing >> showed that even 10MB raises a MemoryError in archive_encrypted_data >> which is AFAIK a KraClient method - Endi, this sounds as something which >> should be also handled in PKI. >> >> Especially when it happens the subsequent vault-archive command ends >> with HTTPError: 503 Server Error: Service Unavailable. After restart of >> pki, subsequent vault-archive with 1M file took about 4mins (in >> vault_retrieve_internal). Next archive command with 1M file took "only" >> 18s. >> >> 10k file took 9s. >> >> Why is it so slow? > > -- Petr Vobornik From ldoudova at redhat.com Wed Aug 26 14:29:55 2015 From: ldoudova at redhat.com (Lenka Doudova) Date: Wed, 26 Aug 2015 16:29:55 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Fix user tracker to reflect new user-del message Message-ID: <55DDCD63.3030802@redhat.com> Fix for user tracker in ipatests/test_xmlrpc/test_user_plugin.py so that it reflects recently changed message of user-del command. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lryznaro-0004-Fix-user-tracker-to-reflect-new-user-del-message.patch Type: text/x-patch Size: 923 bytes Desc: not available URL: From mbasti at redhat.com Wed Aug 26 15:42:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 17:42:13 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DDB6BA.7060102@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> <55DD8BDF.6050202@redhat.com> <55DDB6BA.7060102@redhat.com> Message-ID: <55DDDE55.7010903@redhat.com> On 08/26/2015 02:53 PM, Oleg Fayans wrote: > Hi, > > No more short links :) > > On 08/26/2015 11:50 AM, Tomas Babej wrote: >> >> >> On 08/26/2015 11:44 AM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> On 08/20/2015 11:18 AM, Martin Basti wrote: >>>> >>>> >>>> On 08/20/2015 10:26 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>>>> I got this: >>>>>> >>>>>> https://paste.fedoraproject.org/256746/43999380/ >>>>> FYI replica install failure. (I will retest it, but I'm pretty sure >>>>> that it was clean VM, test for some reason install client first) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>> >>>>> >>>>> line 295, in decorated >>>>> func(installer) >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>> >>>>> >>>>> line 319, in install_check >>>>> sys.exit("IPA client is already configured on this system.\n" >>>>> >>>>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >>>>> exception: SystemExit: IPA client is already configured on this >>>>> system. >>>>> Please uninstall it first before configuring the replica, using >>>>> 'ipa-client-install --uninstall'. >>>>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on this >>>>> system. >>>>> Please uninstall it first before configuring the replica, using >>>>> 'ipa-client-install --uninstall'. >>>> Confirm I got same error. >>> Fixed. It was a regex error. >>> >>>>> >>>>>> >>>>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> As discussed, here is a new version with pep8-related fixes >>>>>>> >>>>>>> >>>>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Already noticed that. Implemented the named groups as Tomas >>>>>>>> advised. >>>>>>>> Added the third test for >>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>>>> NACK, comments inline. >>>>>>>>>>> >>>>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the review! >>>>>>>>>>>> >>>>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) >>>>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>>>> My bad, fixed. >>>>>>>>>>> >>>>>>>>>>> still there >>>>>>>>>>> >>>>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>>>> returns an >>>>>>>>>>> array of >>>>>>>>>>> >>>>>>>>>> Fixed, sorry. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2) >>>>>>>>>>>>> >>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>> + creates a topology segment. The first argument is a >>>>>>>>>>>>> node to >>>>>>>>>>>>> run the >>>>>>>>>>>>> command on >>>>>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>>>>> + Returns a hash object containing segment's name, >>>>>>>>>>>>> leftnode, >>>>>>>>>>>>> rightnode information >>>>>>>>>>>>> + """ >>>>>>>>>>>>> >>>>>>>>>>>>> I would prefer to add assert there instead of just document >>>>>>>>>>>>> that a >>>>>>>>>>>>> Host >>>>>>>>>>>>> object is needed >>>>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>>>>>>> >>>>>>>>>>> This does not scale well. >>>>>>>>>>> If we will want to add new argument that is not host object, >>>>>>>>>>> you >>>>>>>>>>> need >>>>>>>>>>> change it again. >>>>>>>>>> >>>>>>>>>> Agreed. Modified the decorator so that you can specify a >>>>>>>>>> slice of >>>>>>>>>> arguments to be checked and a class to compare to. This does >>>>>>>>>> scale :) >>>>>>>>>>> >>>>>>>>>>> This might be used as function with specified variables that >>>>>>>>>>> have to be >>>>>>>>>>> host objects >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 3) >>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>> + """ >>>>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>>>> object of >>>>>>>>>>>>> class >>>>>>>>>>>>> Host >>>>>>>>>>>>> >>>>>>>>>>>>> Instead of description of params as first, second etc., you >>>>>>>>>>>>> may use >>>>>>>>>>>>> following: >>>>>>>>>>>>> >>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>> + """ >>>>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>>>> + :param master: reference to master object of class Host >>>>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>>>> and eventually this in other methods >>>>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>>>> >>>>>>>>>>>> Fixed >>>>>>>>>>>>> >>>>>>>>>>>>> 4) >>>>>>>>>>>>> >>>>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>>>> >>>>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>>>> >>>>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>>>> >>>>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>>>> >>>>>>>>>>>> Fixed >>>>>>>>>>>>> >>>>>>>>>>>>> 5) >>>>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>>>> >>>>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>>>> >>>>>>>>>>>> in fact >>>>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>>>> and >>>>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>>>> Are equally bad from the readability point of view. The first >>>>>>>>>>>> one is >>>>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>>>> >>>>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>>>> yesterday my >>>>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>>>> values to >>>>>>>>>>> single value attribute, because you used findall, I expected >>>>>>>>>>> that you >>>>>>>>>>> need multiple values, and then I saw that index [0] at the end, >>>>>>>>>>> and I >>>>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>>>> >>>>>>>>>>> And because findall is not effective in case when you need to >>>>>>>>>>> find just >>>>>>>>>>> one occurrence. >>>>>>>>>> >>>>>>>>>> I got it. Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>>>> compability >>>>>>>>>>>>> already comes, but just for record: >>>>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>>>>> (import io >>>>>>>>>>>>> before) >>>>>>>>>>>>> >>>>>>>>>>>> Done. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1) >>>>>>>>>>> >>>>>>>>>>> +# >>>>>>>>>>> >>>>>>>>>>> empty comment here (several times) >>>>>>>>>> >>>>>>>>>> Removed >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> NACK >>>>>>>>> >>>>>>>>> you changed it wrong >>>>>>>>> >>>>>>>>> group() returns everything, you need use group(1) to return >>>>>>>>> content in >>>>>>>>> braces. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> Please, do not use third-party URL shorteners from within our source >> code. >> >> Tomas >> > I received 2 errors ___________________________________________________________________________________ TestTopologyOptions.test_add_remove_segment ___________________________________________________________________________________ self = def test_add_remove_segment(self): """ Make sure a topology segment can be manually created and deleted with the influence on the real topology Testcase http://www.freeipa.org/page/V4/Manage_replication_topology/ Test_plan#Test_case:_Basic_CRUD_test """ tasks.kinit_admin(self.master) # Install the second replica tasks.install_replica(self.master, self.replicas[1], setup_ca=False, setup_dns=False) # turn a star into a ring segment, err = tasks.create_segment(self.master, self.replicas[0], > self.replicas[1]) E TypeError: 'NoneType' object is not iterable test_integration/test_topology.py:102: TypeError Maybe tasks.create_segment returns None? In [3]: a, b = None --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 a, b = None TypeError: 'NoneType' object is not iterable -------------- self = , raiseonerr = True def wait(self, raiseonerr=True): """Wait for the remote process to exit Raises an excption if the exit code is not 0, unless raiseonerr is true. """ if self._done: return self.returncode self._end_process() self._done = True if raiseonerr and self.returncode: self.log.error('Exit code: %s', self.returncode) > raise subprocess.CalledProcessError(self.returncode, self.argv) E CalledProcessError: Command '['ipa', 'topologysegment-del', 'realm', 'vm-152.abc.idm.lab.eng.brq.redhat.com-to-vm-160.abc.idm.lab.eng.brq.redhat.com']' returned non-zero exit status 2 From pvoborni at redhat.com Wed Aug 26 15:44:03 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Aug 2015 17:44:03 +0200 Subject: [Freeipa-devel] [PATCH 0066] ipactl: Do not start/stop/restart single service multiple times In-Reply-To: <55DDBC2C.7040807@redhat.com> References: <55DDBC2C.7040807@redhat.com> Message-ID: <55DDDEC3.5040405@redhat.com> On 08/26/2015 03:16 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/5248 > > ACK Pushed to: master: 59cc54b6dce29e32e81bfaad25ff13794092d782 ipa-4-2: 21cdcbd9a6b6a82d39d40b91a64d4d9b4d7e4e7d -- Petr Vobornik From tbabej at redhat.com Wed Aug 26 15:49:29 2015 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 26 Aug 2015 17:49:29 +0200 Subject: [Freeipa-devel] [PATCH 0066] ipactl: Do not start/stop/restart single service multiple times In-Reply-To: <55DDBC2C.7040807@redhat.com> References: <55DDBC2C.7040807@redhat.com> Message-ID: <55DDE009.8010404@redhat.com> On 08/26/2015 03:16 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/5248 > > +def deduplicate(lst): + new_lst = [] + s = set(lst) + for i in lst: + if i in s: + s.remove(i) + new_lst.append(i) + + return new_lst + Imho, this method deserves a docstring or at least a comment. It is not entrirely clear from the name, that its job is to remove the duplicates while preserving the order of the entries. Anyway, deduplication can be implemented in a more readable way: >>> from collections import OrderedDict >>> sample_list = [3,2,1,2,1,5,3] >>> OrderedDict.fromkeys(sample_list).keys() [3, 2, 1, 5] Tomas From mbasti at redhat.com Wed Aug 26 15:53:46 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Aug 2015 17:53:46 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DDDE55.7010903@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> <55DD8BDF.6050202@redhat.com> <55DDB6BA.7060102@redhat.com> <55DDDE55.7010903@redhat.com> Message-ID: <55DDE10A.8030704@redhat.com> On 08/26/2015 05:42 PM, Martin Basti wrote: > > > On 08/26/2015 02:53 PM, Oleg Fayans wrote: >> Hi, >> >> No more short links :) >> >> On 08/26/2015 11:50 AM, Tomas Babej wrote: >>> >>> >>> On 08/26/2015 11:44 AM, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> On 08/20/2015 11:18 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/20/2015 10:26 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>>>>> I got this: >>>>>>> >>>>>>> https://paste.fedoraproject.org/256746/43999380/ >>>>>> FYI replica install failure. (I will retest it, but I'm pretty sure >>>>>> that it was clean VM, test for some reason install client first) >>>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>> >>>>>> >>>>>> line 295, in decorated >>>>>> func(installer) >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>> >>>>>> >>>>>> line 319, in install_check >>>>>> sys.exit("IPA client is already configured on this system.\n" >>>>>> >>>>>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >>>>>> exception: SystemExit: IPA client is already configured on this >>>>>> system. >>>>>> Please uninstall it first before configuring the replica, using >>>>>> 'ipa-client-install --uninstall'. >>>>>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on this >>>>>> system. >>>>>> Please uninstall it first before configuring the replica, using >>>>>> 'ipa-client-install --uninstall'. >>>>> Confirm I got same error. >>>> Fixed. It was a regex error. >>>> >>>>>> >>>>>>> >>>>>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> As discussed, here is a new version with pep8-related fixes >>>>>>>> >>>>>>>> >>>>>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> Already noticed that. Implemented the named groups as Tomas >>>>>>>>> advised. >>>>>>>>> Added the third test for >>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>>>>> NACK, comments inline. >>>>>>>>>>>> >>>>>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the review! >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>>>>> My bad, fixed. >>>>>>>>>>>> >>>>>>>>>>>> still there >>>>>>>>>>>> >>>>>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>>>>> returns an >>>>>>>>>>>> array of >>>>>>>>>>>> >>>>>>>>>>> Fixed, sorry. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) >>>>>>>>>>>>>> >>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>> + creates a topology segment. The first argument is a >>>>>>>>>>>>>> node to >>>>>>>>>>>>>> run the >>>>>>>>>>>>>> command on >>>>>>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>>>>>> + Returns a hash object containing segment's name, >>>>>>>>>>>>>> leftnode, >>>>>>>>>>>>>> rightnode information >>>>>>>>>>>>>> + """ >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would prefer to add assert there instead of just document >>>>>>>>>>>>>> that a >>>>>>>>>>>>>> Host >>>>>>>>>>>>>> object is needed >>>>>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>>>>>>>> >>>>>>>>>>>> This does not scale well. >>>>>>>>>>>> If we will want to add new argument that is not host >>>>>>>>>>>> object, you >>>>>>>>>>>> need >>>>>>>>>>>> change it again. >>>>>>>>>>> >>>>>>>>>>> Agreed. Modified the decorator so that you can specify a >>>>>>>>>>> slice of >>>>>>>>>>> arguments to be checked and a class to compare to. This does >>>>>>>>>>> scale :) >>>>>>>>>>>> >>>>>>>>>>>> This might be used as function with specified variables that >>>>>>>>>>>> have to be >>>>>>>>>>>> host objects >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) >>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>> + """ >>>>>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>>>>> object of >>>>>>>>>>>>>> class >>>>>>>>>>>>>> Host >>>>>>>>>>>>>> >>>>>>>>>>>>>> Instead of description of params as first, second etc., you >>>>>>>>>>>>>> may use >>>>>>>>>>>>>> following: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>> + """ >>>>>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>>>>> + :param master: reference to master object of class Host >>>>>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>>>>> and eventually this in other methods >>>>>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>>>>> >>>>>>>>>>>>> Fixed >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4) >>>>>>>>>>>>>> >>>>>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>>>>> >>>>>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>>>>> >>>>>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>>>>> >>>>>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>>>>> >>>>>>>>>>>>> Fixed >>>>>>>>>>>>>> >>>>>>>>>>>>>> 5) >>>>>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>>>>> >>>>>>>>>>>>> in fact >>>>>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>>>>> and >>>>>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>>>>> Are equally bad from the readability point of view. The first >>>>>>>>>>>>> one is >>>>>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>>>>> >>>>>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>>>>> yesterday my >>>>>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>>>>> values to >>>>>>>>>>>> single value attribute, because you used findall, I expected >>>>>>>>>>>> that you >>>>>>>>>>>> need multiple values, and then I saw that index [0] at the >>>>>>>>>>>> end, >>>>>>>>>>>> and I >>>>>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>>>>> >>>>>>>>>>>> And because findall is not effective in case when you need to >>>>>>>>>>>> find just >>>>>>>>>>>> one occurrence. >>>>>>>>>>> >>>>>>>>>>> I got it. Fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>>>>> compability >>>>>>>>>>>>>> already comes, but just for record: >>>>>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>>>>>> (import io >>>>>>>>>>>>>> before) >>>>>>>>>>>>>> >>>>>>>>>>>>> Done. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1) >>>>>>>>>>>> >>>>>>>>>>>> +# >>>>>>>>>>>> >>>>>>>>>>>> empty comment here (several times) >>>>>>>>>>> >>>>>>>>>>> Removed >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NACK >>>>>>>>>> >>>>>>>>>> you changed it wrong >>>>>>>>>> >>>>>>>>>> group() returns everything, you need use group(1) to return >>>>>>>>>> content in >>>>>>>>>> braces. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> Please, do not use third-party URL shorteners from within our source >>> code. >>> >>> Tomas >>> >> > > I received 2 errors > > ___________________________________________________________________________________ > TestTopologyOptions.test_add_remove_segment > ___________________________________________________________________________________ > > self = object at 0x7f6ab95b3110> > > def test_add_remove_segment(self): > """ > Make sure a topology segment can be manually created and > deleted > with the influence on the real topology > Testcase > http://www.freeipa.org/page/V4/Manage_replication_topology/ > Test_plan#Test_case:_Basic_CRUD_test > """ > tasks.kinit_admin(self.master) > # Install the second replica > tasks.install_replica(self.master, self.replicas[1], > setup_ca=False, > setup_dns=False) > # turn a star into a ring > segment, err = tasks.create_segment(self.master, > self.replicas[0], > > self.replicas[1]) > E TypeError: 'NoneType' object is not iterable > > test_integration/test_topology.py:102: TypeError > > Maybe tasks.create_segment returns None? > In [3]: a, b = None > --------------------------------------------------------------------------- > > TypeError Traceback (most recent call > last) > in () > ----> 1 a, b = None > > TypeError: 'NoneType' object is not iterable > > > -------------- > > self = 0x7f399b9ea710>, raiseonerr = True > > def wait(self, raiseonerr=True): > """Wait for the remote process to exit > > Raises an excption if the exit code is not 0, unless > raiseonerr is > true. > """ > if self._done: > return self.returncode > > self._end_process() > > self._done = True > > if raiseonerr and self.returncode: > self.log.error('Exit code: %s', self.returncode) > > raise subprocess.CalledProcessError(self.returncode, > self.argv) > E CalledProcessError: Command '['ipa', > 'topologysegment-del', 'realm', > 'vm-152.abc.idm.lab.eng.brq.redhat.com-to-vm-160.abc.idm.lab.eng.brq.redhat.com']' > returned non-zero exit status 2 > Honza found where the problem is. def check_arguments_are(slice, instanceof): ... def wrapper(func): def wrapped(*args): for i in args[slice[0]:slice[1]]: assert isinstance(i, instanceof), "Wrong type: %s: %s" % (i, type(i)) func(*args) return wrapped return wrapper there should be return func(*args) otherwise None will be always returned From rmeggins at redhat.com Wed Aug 26 18:09:21 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Aug 2015 12:09:21 -0600 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55DC84EE.4010102@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> Message-ID: <55DE00D1.9050805@redhat.com> On 08/25/2015 09:08 AM, Petr Spacek wrote: > On 8.7.2015 19:56, Rich Megginson wrote: >> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>> Assuming that Designate wants to own DNS and be Primary Master, it would be >>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>> alongside their own JSON API. >>> >>> The JSON API is superset of DNS UPDATE protocol because it allows to add zones >>> but still, standard protocol would mean that standard client (possibly guest >>> OS inside VM) can update its records without any OpenStack dependency, which >>> is very much desirable. >>> >>> The use case here is to allow the guest OS to publish it's SSH key (which was >>> generated inside the VM after first boot) to prevent Man in the middle >>> attacks. I'm working on a different approach for guest OS registration. This involves a Nova hook/plugin: * build_instance pre-hook to generate an OTP and call ipa host-add with the OTP - add OTP to new host metadata - add ipa-client-registration script to new host cloud-init * new instance calls script - will wait for OTP to become available in metadata, then call ipa-client-install with OTP * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with new IP https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova >>> The same goes for all other sorts of DANE/DNSSEC data or service >>> discovery using DNS, where a guest/container running a distributed service can >>> publish it's existence in DNS. >>> >>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>> widely supported, too. >>> >>> So DNS UPDATE is my biggest wish :-) >>> >> Ok. There was a Designate blueprint for such a feature, but I can't find it >> and neither can the Designate guys. There is a mention of nsupdate in the >> minidns blueprint, but that's about it. The fact that Designate upstream >> can't find the bp suggests that this is not a high priority for them and will >> not likely implement it on their own i.e. we would have to contribute this >> feature. >> >> If Designate had such a feature, how would this help us integrate FreeIPA with >> Designate? > It would greatly simplify integration with FreeIPA. There is a plan to support > DNS updates as described in RFC 2136 to push updates from FreeIPA servers to > external DNS servers, so we could use the same code to integrate with AD & > Designate at the same time. > > (I'm sorry for the delay, it somehow slipped through the cracks.) > For Designate for our use cases, we want IPA to be the authoritative source of DNS data. When a client wants to read data from Designate, that data should somehow come from IPA. I don't think Designate has any sort of proxy or pass-through feature, so the data would have be sync'd from IPA. If IPA supports being a server for AXFR/IXFR, Designate could be changed to support AXFR/IXFR client side, then would just be a slave of IPA. If IPA does not support zone transfers, then we would need some sort of initial sync of data from IPA to Designate (I wrote such a script for Designate (https://github.com/openstack/designate/blob/master/contrib/ipaextractor.py). Then, perhaps some sort of proxy/service that would poll for changes (syncrepl?) in IPA, then submit those changes to Designate (using Designate REST API, or DNS UPDATE when Designate mDNS supports it). When a client wants to update data in Designate, we need to somehow get that data into IPA. The only way Designate pushes data out currently is via AXFR, which doesn't work for IPA to be a direct slave of Designate. What might work is to have an "agent" that gets the AXFR, then somehow converts that into IPA updates. This would only work if the volume of updates is fairly low. If Designate supported IXFR it would be much better. From simo at redhat.com Wed Aug 26 21:27:12 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 26 Aug 2015 17:27:12 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches Message-ID: <1440624432.8138.130.camel@willson.usersys.redhat.com> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 and introduces a number of required changes and dependencies to achieve this goal. This work requires the custodia project to securely transfer keys between ipa servers. This work is not 100% complete, it still misses the ability to install kra instances and the ability to install a CA (via ipa-ca-install) with externally signed certs. However it is massive enough that warrants review and pushing, the resat of the changes can be applied later as this work should not disrupt the classic install methods. In order to build my previous patches (530-533) are needed as well as a number of updated components. I used the following coprs for testing: simo/jwcrypto simo/custodia abbra/sssd-kkdcproxy (for sssd 1.13.1) lkrispen/389-ds-current (for 389 > 1.3.4.4) vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) mkosek/freeipa-4.2-fedora-22 (misc) fedora/updates-testing (python-gssapi 1.1.2) Ludwig's copr is necessary to have a functional DNA plugin in replicas, eventually his patches should be committed in 389-ds-base 1.3.4.4 when it will be released. We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 that may cause installation issues in some case (re-install of a replica). The domain must be raised to level 1 in order to use replica promotion. In order to promote a replica the server must be first joined as a regular client to the domain. This is the flow I usually use for testing: # ipa-client-install # kinit admin # ipa-replica-install --promote --setup-ca These patches are also available in this git tree rebnase on current master: https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-534-2-Remove-unused-arguments.patch Type: text/x-patch Size: 6816 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-535-2-Simplify-the-install_replica_ca-function.patch Type: text/x-patch Size: 2025 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-536-2-IPA-Custodia-Daemon.patch Type: text/x-patch Size: 23478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-537-2-Add-Custodia-Client-code.patch Type: text/x-patch Size: 4464 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-538-2-Install-ipa-custodia-with-the-rest-of-ipa.patch Type: text/x-patch Size: 17407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-539-2-Require-a-DS-version-that-has-working-DNA-plugin.patch Type: text/x-patch Size: 1666 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-540-2-Implement-replica-promotion-functionality.patch Type: text/x-patch Size: 56061 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-541-2-Change-DNS-installer-code-to-use-passed-in-api.patch Type: text/x-patch Size: 18821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-542-2-Allow-ipa-replica-conncheck-to-use-default-creds.patch Type: text/x-patch Size: 9892 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-543-2-Add-function-to-extract-CA-certs-for-install.patch Type: text/x-patch Size: 4415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-544-2-topology-manage-ca-replication-agreements.patch Type: text/x-patch Size: 7303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-545-2-enable-topology-plugin-on-upgrade.patch Type: text/x-patch Size: 4554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-546-2-topology-plugin-configuration-workaround.patch Type: text/x-patch Size: 1927 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-547-2-handle-multiple-managed-suffixes.patch Type: text/x-patch Size: 28232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-548-2-Allow-to-setup-the-CA-when-promoting-a-replica.patch Type: text/x-patch Size: 29801 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-549-2-Make-checks-for-existing-credentials-reusable.patch Type: text/x-patch Size: 8359 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-550-2-Add-low-level-helper-to-get-domain-level.patch Type: text/x-patch Size: 1309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-551-2-Allow-ipa-ca-install-to-use-the-new-promotion-code.patch Type: text/x-patch Size: 7811 bytes Desc: not available URL: From edewata at redhat.com Wed Aug 26 23:47:58 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 26 Aug 2015 18:47:58 -0500 Subject: [Freeipa-devel] [PATCH] 375 Added mechanism to copy vault secrets. In-Reply-To: <55D57CDF.6070709@redhat.com> References: <55D0AC54.6040401@redhat.com> <55D44A4E.7080805@redhat.com> <55D57CDF.6070709@redhat.com> Message-ID: <55DE502E.3030200@redhat.com> On 8/20/2015 2:08 AM, Endi Sukma Dewata wrote: > On 8/19/2015 4:20 AM, Martin Basti wrote: >> On 08/16/2015 05:29 PM, Endi Sukma Dewata wrote: >>> The vault-add and vault-archive commands have been modified to >>> optionally retrieve a secret from a source vault, then re-archive >>> the secret into the new/existing target vault. >>> >>> https://fedorahosted.org/freeipa/ticket/5223 >>> >>> >>> >> I cannot apply this patch. > > Rebased. It depends on patch #371-2. Rebased due to other changes in vault. -- Endi S. Dewata -------------- next part -------------- >From 676b2043a390e6e68772837cf46e222aeda9da78 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Sat, 15 Aug 2015 16:17:47 +0200 Subject: [PATCH] Added mechanism to copy vault secrets. The vault-add and vault-archive commands have been modified to optionally retrieve a secret from a source vault, then re-archive the secret into the new/existing target vault. https://fedorahosted.org/freeipa/ticket/5223 --- API.txt | 20 ++- VERSION | 4 +- ipalib/plugins/vault.py | 213 ++++++++++++++++++++---------- ipatests/test_xmlrpc/test_vault_plugin.py | 143 ++++++++++++++++++++ 4 files changed, 306 insertions(+), 74 deletions(-) diff --git a/API.txt b/API.txt index afd5017bee2bc1eed54497ccd504b92619ff7a58..c883271af4ff84f82c623208567f114265c3ce60 100644 --- a/API.txt +++ b/API.txt @@ -5405,7 +5405,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,14,3 +args: 1,22,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -5419,6 +5419,14 @@ option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui option: Str('service?') option: Str('setattr*', cli_name='setattr', exclude='webui') option: Flag('shared?', autofill=True, default=False) +option: Str('source_password?') +option: Str('source_password_file?') +option: Bytes('source_private_key?') +option: Str('source_private_key_file?') +option: Str('source_service?') +option: Flag('source_shared?', autofill=True, default=False) +option: Str('source_user?') +option: Str('source_vault?') option: Str('username?', cli_name='user') option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) @@ -5474,7 +5482,7 @@ output: Output('completed', , None) output: Output('failed', , None) output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,11,3 +args: 1,19,3 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('data?') @@ -5485,6 +5493,14 @@ option: Str('password_file?', cli_name='password_file') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('service?') option: Flag('shared?', autofill=True, default=False) +option: Str('source_password?') +option: Str('source_password_file?') +option: Bytes('source_private_key?') +option: Str('source_private_key_file?') +option: Str('source_service?') +option: Flag('source_shared?', autofill=True, default=False) +option: Str('source_user?') +option: Str('source_vault?') option: Str('username?', cli_name='user') option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) diff --git a/VERSION b/VERSION index d3073e52ee022cc08b74953222a5040929ded60f..e3cfaa91f03fc6f4d9f5084809a8f74af333c8ef 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=154 -# Last change: pvoborni - change default vault type to 'symmetric' +IPA_API_VERSION_MINOR=155 +# Last change: edewata - Added mechanism to copy vault secrets. diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index ff6c22c646e9784b2fa1a6464f0749cb1ce86b50..a625746ab067d915e71504e971eefb0d0222ff77 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -255,6 +255,78 @@ vault_options = ( ), ) +source_vault_options = ( + Str( + 'source_vault?', + doc=_('Name of the source service vault'), + ), + Str( + 'source_service?', + doc=_('Service name of the source service vault'), + ), + Flag( + 'source_shared?', + doc=_('Source shared vault'), + ), + Str( + 'source_user?', + doc=_('Username of the source user vault'), + ), + Str( + 'source_password?', + doc=_('Source vault password'), + ), + Str( # TODO: use File parameter + 'source_password_file?', + doc=_('File containing the source vault password'), + ), + Bytes( + 'source_private_key?', + doc=_('Source vault private key'), + ), + Str( # TODO: use File parameter + 'source_private_key_file?', + doc=_('File containing the source vault private key'), + ), +) + +vault_add_options = ( + Str( + 'description?', + cli_name='desc', + doc=_('Vault description'), + ), + StrEnum( + 'ipavaulttype?', + cli_name='type', + label=_('Type'), + doc=_('Vault type'), + values=(u'standard', u'symmetric', u'asymmetric', ), + default=u'symmetric', + autofill=True, + ), + Str( + 'password?', + cli_name='password', + doc=_('Vault password'), + ), + Str( # TODO: use File parameter + 'password_file?', + cli_name='password_file', + doc=_('File containing the vault password'), + ), + Bytes( + 'ipavaultpublickey?', + cli_name='public_key', + doc=_('Vault public key'), + ), + Str( # TODO: use File parameter + 'public_key_file?', + cli_name='public_key_file', + doc=_('File containing the vault public key'), + ), +) + @register() class vault(LDAPObject): @@ -573,60 +645,28 @@ class vault(LDAPObject): class vault_add(PKQuery, Local): __doc__ = _('Create a new vault.') - takes_options = LDAPCreate.takes_options + vault_options + ( - Str( - 'description?', - cli_name='desc', - doc=_('Vault description'), - ), - StrEnum( - 'ipavaulttype?', - cli_name='type', - label=_('Type'), - doc=_('Vault type'), - values=(u'standard', u'symmetric', u'asymmetric', ), - default=u'symmetric', - autofill=True, - ), - Str( - 'password?', - cli_name='password', - doc=_('Vault password'), - ), - Str( # TODO: use File parameter - 'password_file?', - cli_name='password_file', - doc=_('File containing the vault password'), - ), - Bytes( - 'ipavaultpublickey?', - cli_name='public_key', - doc=_('Vault public key'), - ), - Str( # TODO: use File parameter - 'public_key_file?', - cli_name='public_key_file', - doc=_('File containing the vault public key'), - ), - ) + takes_options = LDAPCreate.takes_options + vault_options + \ + source_vault_options + vault_add_options has_output = output.standard_entry def forward(self, *args, **options): vault_type = options.get('ipavaulttype') - password = options.get('password') - password_file = options.get('password_file') + + source_vault = options.pop('source_vault', None) + source_service = options.pop('source_service', None) + source_shared = options.pop('source_shared', None) + source_user = options.pop('source_user', None) + source_password = options.pop('source_password', None) + source_password_file = options.pop('source_password_file', None) + source_private_key = options.pop('source_private_key', None) + source_private_key_file = options.pop('source_private_key_file', None) + + password = options.pop('password', None) + password_file = options.pop('password_file', None) public_key = options.get('ipavaultpublickey') - public_key_file = options.get('public_key_file') - - # don't send these parameters to server - if 'password' in options: - del options['password'] - if 'password_file' in options: - del options['password_file'] - if 'public_key_file' in options: - del options['public_key_file'] + public_key_file = options.pop('public_key_file', None) if vault_type != u'symmetric' and (password or password_file): raise errors.MutuallyExclusiveError( @@ -726,7 +766,17 @@ class vault_add(PKQuery, Local): elif vault_type == u'asymmetric': del opts['ipavaultpublickey'] - # archive blank data + opts['source_vault'] = source_vault + opts['source_service'] = source_service + opts['source_shared'] = source_shared + opts['source_user'] = source_user + + opts['source_password'] = source_password + opts['source_password_file'] = source_password_file + opts['source_private_key'] = source_private_key + opts['source_private_key_file'] = source_private_key_file + + # archive initial data self.api.Command.vault_archive(*args, **opts) return response @@ -1179,7 +1229,7 @@ class vaultconfig_show(Retrieve): class vault_archive(PKQuery, Local): __doc__ = _('Archive data into a vault.') - takes_options = vault_options + ( + takes_options = vault_options + source_vault_options + ( Bytes( 'data?', doc=_('Binary data to archive'), @@ -1210,26 +1260,40 @@ class vault_archive(PKQuery, Local): name = args[-1] - data = options.get('data') - input_file = options.get('in') + data = options.pop('data', None) + input_file = options.pop('in', None) - password = options.get('password') - password_file = options.get('password_file') + source_vault = options.pop('source_vault', None) + source_service = options.pop('source_service', None) + source_shared = options.pop('source_shared', None) + source_user = options.pop('source_user', None) + source_password = options.pop('source_password', None) + source_password_file = options.pop('source_password_file', None) + source_private_key = options.pop('source_private_key', None) + source_private_key_file = options.pop('source_private_key_file', None) + + password = options.pop('password', None) + password_file = options.pop('password_file', None) override_password = options.pop('override_password', False) - # don't send these parameters to server - if 'data' in options: - del options['data'] - if 'in' in options: - del options['in'] - if 'password' in options: - del options['password'] - if 'password_file' in options: - del options['password_file'] + if self.api.env.in_server: + backend = self.api.Backend.ldap2 + else: + backend = self.api.Backend.rpcclient + if not backend.isconnected(): + backend.connect() # get data - if data and input_file: + counter = 0 + if data: + counter = counter + 1 + if input_file: + counter = counter + 1 + if source_vault: + counter = counter + 1 + + if counter > 1: raise errors.MutuallyExclusiveError( reason=_('Input data specified multiple times')) @@ -1254,16 +1318,25 @@ class vault_archive(PKQuery, Local): % {'limit': MAX_VAULT_DATA_SIZE}) data = validated_read('in', input_file, mode='rb') + elif source_vault: + opts = {} + + opts['service'] = source_service + opts['shared'] = source_shared + opts['username'] = source_user + + opts['password'] = source_password + opts['password_file'] = source_password_file + opts['private_key'] = source_private_key + opts['private_key_file'] = source_private_key_file + + # retrieve data from source vault + response = self.api.Command.vault_retrieve(source_vault, **opts) + data = response['result']['data'] + else: data = '' - if self.api.env.in_server: - backend = self.api.Backend.ldap2 - else: - backend = self.api.Backend.rpcclient - if not backend.isconnected(): - backend.connect() - # retrieve vault info vault = self.api.Command.vault_show(*args, **options)['result'] diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py index 495512dac687afaee0c94c620c2b504df424c246..d69bd6725f01255f621d50aff558c2a2718e0e60 100644 --- a/ipatests/test_xmlrpc/test_vault_plugin.py +++ b/ipatests/test_xmlrpc/test_vault_plugin.py @@ -33,6 +33,10 @@ standard_vault_name = u'standard_test_vault' symmetric_vault_name = u'symmetric_test_vault' asymmetric_vault_name = u'asymmetric_test_vault' +standard_vault_copy_name = u'standard_test_vault_copy' +symmetric_vault_copy_name = u'symmetric_test_vault_copy' +asymmetric_vault_copy_name = u'asymmetric_test_vault_copy' + # binary data from \x00 to \xff secret = ''.join(map(chr, xrange(0, 256))) @@ -147,6 +151,9 @@ class test_vault_plugin(Declarative): ('vault_del', [standard_vault_name], {'continue': True}), ('vault_del', [symmetric_vault_name], {'continue': True}), ('vault_del', [asymmetric_vault_name], {'continue': True}), + ('vault_del', [standard_vault_copy_name], {'continue': True}), + ('vault_del', [symmetric_vault_copy_name], {'continue': True}), + ('vault_del', [asymmetric_vault_copy_name], {'continue': True}), ] tests = [ @@ -641,6 +648,52 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy standard vault to symmetric vault', + 'command': ( + 'vault_add', + [standard_vault_copy_name], + { + 'ipavaulttype': u'symmetric', + 'password': password, + 'source_vault': standard_vault_name, + }, + ), + 'expected': { + 'value': standard_vault_copy_name, + 'summary': u'Added vault "%s"' % standard_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (standard_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [standard_vault_copy_name], + 'ipavaulttype': [u'symmetric'], + 'ipavaultsalt': [fuzzy_string], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from standard vault copied to ' + 'symmetric vault', + 'command': ( + 'vault_retrieve', + [standard_vault_copy_name], + { + 'password': password, + }, + ), + 'expected': { + 'value': standard_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % standard_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change standard vault to symmetric vault', 'command': ( 'vault_mod', @@ -745,6 +798,53 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy symmetric vault to asymmetric vault', + 'command': ( + 'vault_add', + [symmetric_vault_copy_name], + { + 'ipavaulttype': u'asymmetric', + 'ipavaultpublickey': public_key, + 'source_vault': symmetric_vault_name, + 'source_password': password, + }, + ), + 'expected': { + 'value': symmetric_vault_copy_name, + 'summary': u'Added vault "%s"' % symmetric_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (symmetric_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [symmetric_vault_copy_name], + 'ipavaulttype': [u'asymmetric'], + 'ipavaultpublickey': [public_key], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from symmetric vault copied to ' + 'asymmetric vault', + 'command': ( + 'vault_retrieve', + [symmetric_vault_copy_name], + { + 'private_key': private_key, + }, + ), + 'expected': { + 'value': symmetric_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % symmetric_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change symmetric vault password', 'command': ( 'vault_mod', @@ -890,6 +990,49 @@ class test_vault_plugin(Declarative): }, { + 'desc': 'Copy asymmetric vault to standard vault', + 'command': ( + 'vault_add', + [asymmetric_vault_copy_name], + { + 'ipavaulttype': u'standard', + 'source_vault': asymmetric_vault_name, + 'source_private_key': private_key, + }, + ), + 'expected': { + 'value': asymmetric_vault_copy_name, + 'summary': u'Added vault "%s"' % asymmetric_vault_copy_name, + 'result': { + 'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s' + % (asymmetric_vault_copy_name, api.env.basedn), + 'objectclass': [u'top', u'ipaVault'], + 'cn': [asymmetric_vault_copy_name], + 'ipavaulttype': [u'standard'], + 'owner_user': [u'admin'], + }, + }, + }, + + { + 'desc': 'Retrieve secret from asymmetric vault copied to ' + 'standard vault', + 'command': ( + 'vault_retrieve', + [asymmetric_vault_copy_name], + {}, + ), + 'expected': { + 'value': asymmetric_vault_copy_name, + 'summary': 'Retrieved data from vault "%s"' + % asymmetric_vault_copy_name, + 'result': { + 'data': secret, + }, + }, + }, + + { 'desc': 'Change asymmetric vault keys', 'command': ( 'vault_mod', -- 2.4.3 From akasurde at redhat.com Thu Aug 27 05:07:25 2015 From: akasurde at redhat.com (Abhijeet Kasurde) Date: Thu, 27 Aug 2015 10:37:25 +0530 Subject: [Freeipa-devel] [PATCH] Updated no of legacy permission in ipatests Message-ID: <55DE9B0D.6030101@redhat.com> Hi All, This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264 Thanks, Abhijeet Kasurde -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akasurde-0001-Updated-no-of-legacy-permission-in-ipatests.patch Type: text/x-patch Size: 1291 bytes Desc: not available URL: From jcholast at redhat.com Thu Aug 27 05:49:21 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 07:49:21 +0200 Subject: [Freeipa-devel] [PATCHES 478-479] cert renewal: KRA agent certificate update Message-ID: <55DEA4E1.5010908@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-478-cert-renewal-Include-KRA-users-in-Dogtag-LDAP-update.patch Type: text/x-patch Size: 1767 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-479-cert-renewal-Automatically-update-KRA-agent-PEM-file.patch Type: text/x-patch Size: 1489 bytes Desc: not available URL: From jcholast at redhat.com Thu Aug 27 05:56:21 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 07:56:21 +0200 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <1440528239.8138.51.camel@willson.usersys.redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <1440528239.8138.51.camel@willson.usersys.redhat.com> Message-ID: <55DEA685.1090407@redhat.com> On 25.8.2015 20:43, Simo Sorce wrote: > On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: >> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): >>>> I've been carrying these patches in my tree for a while, I think it is >>>> time to put them in master as they stand on their own. >>>> >>>> Simo. >>> >>> Patch 530: ACK >>> >>> Patch 531: ACK >>> >>> Patch 532: >>> >>> The methods should be static methods: >>> >>> @staticmethod >>> def setOption(name, value): >>> ... >> >> Care to explain why ? >> @staticmethod is not used anywhere else in that file. > > Rebased patches on master, made requested change +1 more patch. > > Simo. > Patch 532: ACK Patch 533: ACK Pushed to master: f57b687241fbc92d1138507210e87e9de465c507 Honza -- Jan Cholasta From dkupka at redhat.com Thu Aug 27 06:07:50 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 27 Aug 2015 08:07:50 +0200 Subject: [Freeipa-devel] [PATCH 0066] ipactl: Do not start/stop/restart single service multiple times In-Reply-To: <55DDE009.8010404@redhat.com> References: <55DDBC2C.7040807@redhat.com> <55DDE009.8010404@redhat.com> Message-ID: <55DEA936.4040709@redhat.com> On 26/08/15 17:49, Tomas Babej wrote: > > > On 08/26/2015 03:16 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/5248 >> >> > > +def deduplicate(lst): > + new_lst = [] > + s = set(lst) > + for i in lst: > + if i in s: > + s.remove(i) > + new_lst.append(i) > + > + return new_lst > + > > Imho, this method deserves a docstring or at least a comment. It is not > entrirely clear from the name, that its job is to remove the duplicates > while preserving the order of the entries. > You're right, line or two could not hurt. Patch attached. > Anyway, deduplication can be implemented in a more readable way: > >>>> from collections import OrderedDict >>>> sample_list = [3,2,1,2,1,5,3] >>>> OrderedDict.fromkeys(sample_list).keys() > [3, 2, 1, 5] I know about this approach and it does not seem much more readable to me. I just chosen few more lines instead of an import. > > Tomas > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0067-comment-Add-Documentation-string-to-deduplicate-func.patch Type: text/x-patch Size: 844 bytes Desc: not available URL: From jcholast at redhat.com Thu Aug 27 07:07:30 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 09:07:30 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DD91D0.7040109@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> <55DC45DD.1040907@redhat.com> <55DC6815.9090804@redhat.com> <55DD6F1A.8080205@redhat.com> <55DD91D0.7040109@redhat.com> Message-ID: <55DEB732.5040600@redhat.com> On 26.8.2015 12:15, Petr Viktorin wrote: > On 08/26/2015 09:47 AM, Jan Cholasta wrote: >> On 25.8.2015 15:05, Petr Viktorin wrote: >>> On 08/25/2015 12:39 PM, Christian Heimes wrote: >>>> On 2015-08-24 17:31, Petr Viktorin wrote: >>>>>>>> 0701.2-Use-Python3-compatible-dict-method-names >>>>>>>> NACK >>>>>>>> Why are you replacing iteritems() with items() instead of using >>>>>>>> six.iteritems()? >>>>> >>>>> It looks cleaner, and it will be easier to clean up after six is >>>>> dropped. >>>>> Also, the performance difference is negligible if the whole thing is >>>>> iterated over. (On small dicts, which are the majority of what >>>>> iteritems >>>>> was used on, items() is actually a bit faster on my machine.) >>>> >>>> Right, for small dicts the speed difference is negligible and favors the >>>> items() over iteritems(). For medium sized and large dicts the iterators >>>> are faster and consume less memory. >>>> >>>> I'm preferring iterator methods everywhere because I don't have to worry >>>> about dict sizes. >>>> >>>>>>>> 0710.2-Modernize-use-of-range >>>>>>>> NACK >>>>>>>> Please use six.moves.range. It defaults to xrange() in Python 2. >>>>> >>>>> Why? What is the benefit of xrange in these situations? >>>>> >>>>> Like with iteritems in 0701, when iterating over the whole thing, the >>>>> performance difference is negligible. I don't think a few microseconds >>>>> outside of tight loops are worth the verbosity. >>>> >>>> It's the same reasoning as in 0701. As long as you have a small range, >>>> it doesn't make a difference. For large ranges the additional memory >>>> usage can be problematic. >>>> >>>> In all above cases the iterator methods and generator functions are a >>>> safer choice. A malicious user can abuse the non-iterative methods for >>>> DoS attacks. As long as the input can't be controlled by a user and the >>>> range/dict/set/list is small, the non-iterative methods are fine. You >>>> have to verify every location, though. >>> >>> Keep in mind that for dicts, all the data is in memory already (in the >>> dict). Are you worried about DoS from an extra list of references to >>> existing objects? >>> >>>> I'm usually too busy with other stuff (aka lazy) to verify these >>>> preconditions... >>> >>> I changed one questionable use of range. The other ones are: >>> >>> ipalib/plugins/dns.py: for i in range(len(relative_record_name) >>> (max. ~255, verified by DNSName) >>> >>> ipaserver/install/dnskeysyncinstance.py: for _ in range(0, 16)) >>> (16) >>> >>> ipaserver/install/ipa_otptoken_import.py: for i in range(1, blocks + 1): >>> (about 7) >>> >>> ipaserver/install/ipa_otptoken_import.py: for k in >>> range(mac.digest_size): >>> (16) >>> >>> ipatests/data.py: for d in range(256)) >>> (256) >>> >>> Plus tests, where it's rarely above 10. >>> >> >> I have just pushed Michael's python-krbV removal patch, which conflicts >> with your patches. Could you please rebase them on top of current master? >> > > Sure, here they are. > > Patches 696-699: ACK Patch 700: There are some error messages which contain basestring. Do we want to fix these as well? Patch 701: Since we are using python-six, shouldn't "six.PY2" be used instead of "sys.version_info < (3, 0)"? Patches 702-709: ACK Patch 710: There are some "xrange"s in ipapython/p11helper.py and ipatests/test_xmlrpc/test_add_remove_cert_cmd.py. Patch 711: ACK -- Jan Cholasta From pspacek at redhat.com Thu Aug 27 08:27:33 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Aug 2015 10:27:33 +0200 Subject: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org In-Reply-To: <20150715074450.GL4218@redhat.com> References: <55A532DF.7070302@redhat.com> <55A53D93.4050201@redhat.com> <20150715074450.GL4218@redhat.com> Message-ID: <55DEC9F5.4070302@redhat.com> On 15.7.2015 09:44, Jan Pazdziora wrote: > On Tue, Jul 14, 2015 at 12:49:23PM -0400, John Dennis wrote: >> On 07/14/2015 12:03 PM, Petr Spacek wrote: >>> Hello, >>> >>> Is anyone using repos >>> https://jdennis.fedorapeople.org/ipa-devel/ >>> ? >>> >>> AFAIK nobody in Brno is seriously using it but I'm not sure about people >>> outside the Brno. >>> >>> Could we use COPR instead and get out of builder business? Upcoming lab >>> maintenance window could be a good time to do that. >> >> I would love to get out of the builder business and I suspect Nalin would as >> well [1]. The question came up in our Monday meeting as well. Nobody seem to >> know if anyone was using these builds and why we weren't using COPR. The > > The Fedora infra admins should be able to provide HTTP logs for the > repo, if you needs some numbers about potential usage. That is a good idea! I got logs from Fedora admins and as far as I can tell, in the last month there were only 7 RPM downloads and nothing else. The 7 hits I found was for /ipa-devel/rhel/6/x86_64/os/sssd-1.13.1-0.20150813T1121Zgit137d5dd.el6.i686.rpm and other packages from the same version. I did not find any hits for IPA packages at all. All the remaining traffic (except the 7 RPM hits) was from repo data refreshes: - 83 % is RHEL 5 repodata - 13 % is RHEL 6 repodata - remaining ~ 4 % of noise is Fedora repodata It seems to me that we can get out the builder business completely and decommission ipa-devel and replace it with COPR. Do you agree? John? Nathaniel? Stephen? Anyone? :-) -- Petr^2 Spacek From abokovoy at redhat.com Thu Aug 27 08:34:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Aug 2015 11:34:22 +0300 Subject: [Freeipa-devel] [PATCHES 478-479] cert renewal: KRA agent certificate update In-Reply-To: <55DEA4E1.5010908@redhat.com> References: <55DEA4E1.5010908@redhat.com> Message-ID: <20150827083422.GM22106@redhat.com> On Thu, 27 Aug 2015, Jan Cholasta wrote: > Hi, > > the attached patches fix . ACK to both patches. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Aug 27 08:34:52 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Aug 2015 11:34:52 +0300 Subject: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org In-Reply-To: <55DEC9F5.4070302@redhat.com> References: <55A532DF.7070302@redhat.com> <55A53D93.4050201@redhat.com> <20150715074450.GL4218@redhat.com> <55DEC9F5.4070302@redhat.com> Message-ID: <20150827083452.GN22106@redhat.com> On Thu, 27 Aug 2015, Petr Spacek wrote: >On 15.7.2015 09:44, Jan Pazdziora wrote: >> On Tue, Jul 14, 2015 at 12:49:23PM -0400, John Dennis wrote: >>> On 07/14/2015 12:03 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> Is anyone using repos >>>> https://jdennis.fedorapeople.org/ipa-devel/ >>>> ? >>>> >>>> AFAIK nobody in Brno is seriously using it but I'm not sure about people >>>> outside the Brno. >>>> >>>> Could we use COPR instead and get out of builder business? Upcoming lab >>>> maintenance window could be a good time to do that. >>> >>> I would love to get out of the builder business and I suspect Nalin would as >>> well [1]. The question came up in our Monday meeting as well. Nobody seem to >>> know if anyone was using these builds and why we weren't using COPR. The >> >> The Fedora infra admins should be able to provide HTTP logs for the >> repo, if you needs some numbers about potential usage. > >That is a good idea! I got logs from Fedora admins and as far as I can tell, >in the last month there were only 7 RPM downloads and nothing else. > >The 7 hits I found was for >/ipa-devel/rhel/6/x86_64/os/sssd-1.13.1-0.20150813T1121Zgit137d5dd.el6.i686.rpm and >other packages from the same version. > >I did not find any hits for IPA packages at all. All the remaining traffic >(except the 7 RPM hits) was from repo data refreshes: >- 83 % is RHEL 5 repodata >- 13 % is RHEL 6 repodata >- remaining ~ 4 % of noise is Fedora repodata > >It seems to me that we can get out the builder business completely and >decommission ipa-devel and replace it with COPR. > >Do you agree? John? Nathaniel? Stephen? Anyone? :-) Yes, I think we can decommission this repository thanks to COPR infrastructure. -- / Alexander Bokovoy From jcholast at redhat.com Thu Aug 27 09:05:48 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 11:05:48 +0200 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <55DEA685.1090407@redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <1440528239.8138.51.camel@willson.usersys.redhat.com> <55DEA685.1090407@redhat.com> Message-ID: <55DED2EC.4070008@redhat.com> On 27.8.2015 07:56, Jan Cholasta wrote: > On 25.8.2015 20:43, Simo Sorce wrote: >> On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: >>> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): >>>>> I've been carrying these patches in my tree for a while, I think it is >>>>> time to put them in master as they stand on their own. >>>>> >>>>> Simo. >>>> >>>> Patch 530: ACK >>>> >>>> Patch 531: ACK >>>> >>>> Patch 532: >>>> >>>> The methods should be static methods: >>>> >>>> @staticmethod >>>> def setOption(name, value): >>>> ... >>> >>> Care to explain why ? >>> @staticmethod is not used anywhere else in that file. >> >> Rebased patches on master, made requested change +1 more patch. >> >> Simo. >> > > Patch 532: ACK > > Patch 533: ACK > > Pushed to master: f57b687241fbc92d1138507210e87e9de465c507 > > Honza > Actually, there is a problem with patch 531: SASL mapping are added only on replica. The attached patch fixes it. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-480-install-Fix-SASL-mappings-not-added-in-ipa-server-in.patch Type: text/x-patch Size: 1558 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 27 10:17:02 2015 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 27 Aug 2015 12:17:02 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DEB732.5040600@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> <55DC45DD.1040907@redhat.com> <55DC6815.9090804@redhat.com> <55DD6F1A.8080205@redhat.com> <55DD91D0.7040109@redhat.com> <55DEB732.5040600@redhat.com> Message-ID: <55DEE39E.8030203@redhat.com> On 08/27/2015 09:07 AM, Jan Cholasta wrote: > On 26.8.2015 12:15, Petr Viktorin wrote: >> On 08/26/2015 09:47 AM, Jan Cholasta wrote: >>> On 25.8.2015 15:05, Petr Viktorin wrote: >>>> On 08/25/2015 12:39 PM, Christian Heimes wrote: >>>>> On 2015-08-24 17:31, Petr Viktorin wrote: >>>>>>>>> 0701.2-Use-Python3-compatible-dict-method-names >>>>>>>>> NACK >>>>>>>>> Why are you replacing iteritems() with items() instead of using >>>>>>>>> six.iteritems()? >>>>>> >>>>>> It looks cleaner, and it will be easier to clean up after six is >>>>>> dropped. >>>>>> Also, the performance difference is negligible if the whole thing is >>>>>> iterated over. (On small dicts, which are the majority of what >>>>>> iteritems >>>>>> was used on, items() is actually a bit faster on my machine.) >>>>> >>>>> Right, for small dicts the speed difference is negligible and >>>>> favors the >>>>> items() over iteritems(). For medium sized and large dicts the >>>>> iterators >>>>> are faster and consume less memory. >>>>> >>>>> I'm preferring iterator methods everywhere because I don't have to >>>>> worry >>>>> about dict sizes. >>>>> >>>>>>>>> 0710.2-Modernize-use-of-range >>>>>>>>> NACK >>>>>>>>> Please use six.moves.range. It defaults to xrange() in Python 2. >>>>>> >>>>>> Why? What is the benefit of xrange in these situations? >>>>>> >>>>>> Like with iteritems in 0701, when iterating over the whole thing, the >>>>>> performance difference is negligible. I don't think a few >>>>>> microseconds >>>>>> outside of tight loops are worth the verbosity. >>>>> >>>>> It's the same reasoning as in 0701. As long as you have a small range, >>>>> it doesn't make a difference. For large ranges the additional memory >>>>> usage can be problematic. >>>>> >>>>> In all above cases the iterator methods and generator functions are a >>>>> safer choice. A malicious user can abuse the non-iterative methods for >>>>> DoS attacks. As long as the input can't be controlled by a user and >>>>> the >>>>> range/dict/set/list is small, the non-iterative methods are fine. You >>>>> have to verify every location, though. >>>> >>>> Keep in mind that for dicts, all the data is in memory already (in the >>>> dict). Are you worried about DoS from an extra list of references to >>>> existing objects? >>>> >>>>> I'm usually too busy with other stuff (aka lazy) to verify these >>>>> preconditions... >>>> >>>> I changed one questionable use of range. The other ones are: >>>> >>>> ipalib/plugins/dns.py: for i in range(len(relative_record_name) >>>> (max. ~255, verified by DNSName) >>>> >>>> ipaserver/install/dnskeysyncinstance.py: for _ in range(0, 16)) >>>> (16) >>>> >>>> ipaserver/install/ipa_otptoken_import.py: for i in range(1, blocks + >>>> 1): >>>> (about 7) >>>> >>>> ipaserver/install/ipa_otptoken_import.py: for k in >>>> range(mac.digest_size): >>>> (16) >>>> >>>> ipatests/data.py: for d in range(256)) >>>> (256) >>>> >>>> Plus tests, where it's rarely above 10. >>>> >>> >>> I have just pushed Michael's python-krbV removal patch, which conflicts >>> with your patches. Could you please rebase them on top of current >>> master? >>> >> >> Sure, here they are. >> >> > > Patches 696-699: ACK > > Patch 700: There are some error messages which contain basestring. Do we > want to fix these as well? No, I think it's okay as a term. When Python 2 is dropped it can be shortened to str. > Patch 701: Since we are using python-six, shouldn't "six.PY2" be used > instead of "sys.version_info < (3, 0)"? Right, it looks a bit better. > Patches 702-709: ACK > > Patch 710: There are some "xrange"s in ipapython/p11helper.py and > ipatests/test_xmlrpc/test_add_remove_cert_cmd.py. Thanks, fixed. > Patch 711: ACK > -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0696.6-Remove-use-of-sys.exc_value.patch Type: text/x-patch Size: 2529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0697.6-Don-t-use-a-tuple-in-function-arguments.patch Type: text/x-patch Size: 907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0698.6-Add-python-six-to-dependencies.patch Type: text/x-patch Size: 984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0699.6-Remove-the-unused-pygettext-script.patch Type: text/x-patch Size: 30062 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0700.6-Use-six.string_types-instead-of-basestring.patch Type: text/x-patch Size: 35449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0701.6-Use-Python3-compatible-dict-method-names.patch Type: text/x-patch Size: 74109 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0702.6-Replace-filter-calls-with-list-comprehensions.patch Type: text/x-patch Size: 6514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0703.6-Use-six.moves.input-instead-of-raw_input.patch Type: text/x-patch Size: 3100 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0704.6-Use-six.integer_types-instead-of-long-int.patch Type: text/x-patch Size: 8301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0705.6-Replace-uses-of-map.patch Type: text/x-patch Size: 18773 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0706.6-Use-next-function-on-iterators.patch Type: text/x-patch Size: 3481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0707.6-Use-the-print-function.patch Type: text/x-patch Size: 229158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0708.6-Use-new-style-raise-syntax.patch Type: text/x-patch Size: 6956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0709.6-Use-six.reraise.patch Type: text/x-patch Size: 1892 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0710.6-Modernize-use-of-range.patch Type: text/x-patch Size: 20463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0711.6-Convert-zip-result-to-list.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 27 10:25:30 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Aug 2015 12:25:30 +0200 Subject: [Freeipa-devel] [PATCH] 0004 Fix user tracker to reflect new user-del message In-Reply-To: <55DDCD63.3030802@redhat.com> References: <55DDCD63.3030802@redhat.com> Message-ID: <55DEE59A.90506@redhat.com> On 08/26/2015 04:29 PM, Lenka Doudova wrote: > Fix for user tracker in ipatests/test_xmlrpc/test_user_plugin.py so > that it reflects recently changed message of user-del command. > > Lenka > > Thank you, ACK Pushed to: master: a78e75120990341434e92b370cd3386fd1f8fed3 ipa-4-2: f5dcb03a1c003557371be52597aba7900b0ac345 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Aug 27 11:14:35 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Aug 2015 13:14:35 +0200 Subject: [Freeipa-devel] ipa-client-install domain autodiscovery - try _kerberos first? Message-ID: <55DEF11B.2070109@redhat.com> Hello, while investigating a problem reported on ipa-users, I found out that check_domain() method in ipaclient/ipadiscovery.py checks _ldap._tcp SRV record first. This seems to be based on assumption that IPA client is in the same DNS sub-tree as the main IPA domain. IMHO it would be better to find _kerberos TXT record in client's domain (or its parent domains) and then check _ldap._tcp SRV records in domain pointed to by _kerberos record. Do you agree? Am I missing something? Side note: ipadiscovery.py could be re-used in ipa-server-install as mechanism to detect attempts to install IPA into a DNS domain which is already occupied by another IPA, or AD, or something else. -- Petr^2 Spacek From abokovoy at redhat.com Thu Aug 27 11:31:05 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 27 Aug 2015 14:31:05 +0300 Subject: [Freeipa-devel] ipa-client-install domain autodiscovery - try _kerberos first? In-Reply-To: <55DEF11B.2070109@redhat.com> References: <55DEF11B.2070109@redhat.com> Message-ID: <20150827113105.GO22106@redhat.com> On Thu, 27 Aug 2015, Petr Spacek wrote: >Hello, > >while investigating a problem reported on ipa-users, I found out that >check_domain() method in ipaclient/ipadiscovery.py checks _ldap._tcp SRV >record first. > >This seems to be based on assumption that IPA client is in the same DNS >sub-tree as the main IPA domain. > >IMHO it would be better to find _kerberos TXT record in client's domain (or >its parent domains) and then check _ldap._tcp SRV records in domain pointed to >by _kerberos record. > >Do you agree? Am I missing something? Yes, you should be using _kerberos TXT record first and then follow domain derived from the realm. However, this would not work for non-FQDN REALMs (for example, Kerberos realm IPA). In that case you would have KDC explicitly defined in the krb5.conf, though. >Side note: >ipadiscovery.py could be re-used in ipa-server-install as mechanism to detect >attempts to install IPA into a DNS domain which is already occupied by another >IPA, or AD, or something else. Correct and makes sense. -- / Alexander Bokovoy From dkupka at redhat.com Thu Aug 27 11:43:57 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 27 Aug 2015 13:43:57 +0200 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <55DED2EC.4070008@redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <1440528239.8138.51.camel@willson.usersys.redhat.com> <55DEA685.1090407@redhat.com> <55DED2EC.4070008@redhat.com> Message-ID: <55DEF7FD.8040208@redhat.com> On 27/08/15 11:05, Jan Cholasta wrote: > On 27.8.2015 07:56, Jan Cholasta wrote: >> On 25.8.2015 20:43, Simo Sorce wrote: >>> On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: >>>> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): >>>>>> I've been carrying these patches in my tree for a while, I think >>>>>> it is >>>>>> time to put them in master as they stand on their own. >>>>>> >>>>>> Simo. >>>>> >>>>> Patch 530: ACK >>>>> >>>>> Patch 531: ACK >>>>> >>>>> Patch 532: >>>>> >>>>> The methods should be static methods: >>>>> >>>>> @staticmethod >>>>> def setOption(name, value): >>>>> ... >>>> >>>> Care to explain why ? >>>> @staticmethod is not used anywhere else in that file. >>> >>> Rebased patches on master, made requested change +1 more patch. >>> >>> Simo. >>> >> >> Patch 532: ACK >> >> Patch 533: ACK >> >> Pushed to master: f57b687241fbc92d1138507210e87e9de465c507 >> >> Honza >> > > Actually, there is a problem with patch 531: SASL mapping are added only > on replica. > > The attached patch fixes it. > > > Works for me, ACK. -- David Kupka From jdennis at redhat.com Thu Aug 27 12:20:18 2015 From: jdennis at redhat.com (John Dennis) Date: Thu, 27 Aug 2015 08:20:18 -0400 Subject: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org In-Reply-To: <55DEC9F5.4070302@redhat.com> References: <55A532DF.7070302@redhat.com> <55A53D93.4050201@redhat.com> <20150715074450.GL4218@redhat.com> <55DEC9F5.4070302@redhat.com> Message-ID: <55DF0082.5040305@redhat.com> On 08/27/2015 04:27 AM, Petr Spacek wrote: > On 15.7.2015 09:44, Jan Pazdziora wrote: >> On Tue, Jul 14, 2015 at 12:49:23PM -0400, John Dennis wrote: >>> On 07/14/2015 12:03 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> Is anyone using repos >>>> https://jdennis.fedorapeople.org/ipa-devel/ >>>> ? >>>> >>>> AFAIK nobody in Brno is seriously using it but I'm not sure about people >>>> outside the Brno. >>>> >>>> Could we use COPR instead and get out of builder business? Upcoming lab >>>> maintenance window could be a good time to do that. >>> >>> I would love to get out of the builder business and I suspect Nalin would as >>> well [1]. The question came up in our Monday meeting as well. Nobody seem to >>> know if anyone was using these builds and why we weren't using COPR. The >> >> The Fedora infra admins should be able to provide HTTP logs for the >> repo, if you needs some numbers about potential usage. > > That is a good idea! I got logs from Fedora admins and as far as I can tell, > in the last month there were only 7 RPM downloads and nothing else. > > The 7 hits I found was for > /ipa-devel/rhel/6/x86_64/os/sssd-1.13.1-0.20150813T1121Zgit137d5dd.el6.i686.rpm and > other packages from the same version. > > I did not find any hits for IPA packages at all. All the remaining traffic > (except the 7 RPM hits) was from repo data refreshes: > - 83 % is RHEL 5 repodata > - 13 % is RHEL 6 repodata > - remaining ~ 4 % of noise is Fedora repodata > > It seems to me that we can get out the builder business completely and > decommission ipa-devel and replace it with COPR. > > Do you agree? John? Nathaniel? Stephen? Anyone? :-) Yes, I agree. Do we have a cut off date when I can stop the service? -- John From dkupka at redhat.com Thu Aug 27 12:22:47 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 27 Aug 2015 14:22:47 +0200 Subject: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55DC61EB.4050205@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> <55DC2951.60508@redhat.com> <55DC61EB.4050205@redhat.com> Message-ID: <55DF0117.3010800@redhat.com> On 25/08/15 14:39, David Kupka wrote: > On 25/08/15 10:37, David Kupka wrote: >> On 24/08/15 16:51, Martin Basti wrote: >>> >>> >>> On 08/20/2015 10:28 AM, David Kupka wrote: >>>> On 31/07/15 13:32, Martin Basti wrote: >>>>> On 30/07/15 14:38, Martin Basti wrote: >>>>>> On 29/07/15 16:12, David Kupka wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5087 >>>>>> NACK >>>>>> >>>>>> You forgot to update API.txt file >>>> >>>> Thanks for catching that. Updated patch attached. >>>> >>>>>> >>>>> I'm just curious, what is the reason to check if forward zone exists? >>>>> >>>>> IMO forwardzone must exists somewhere as the master zone. I don't >>>>> think >>>>> we should check forwardzones, this may give too many false positive >>>>> errors. >>>> >>>> AIUI if the zone exist somewhere and is resolvable there is no need to >>>> add it as a forward zone. If user for some reason want to do it he's >>>> hiding the original zone and we should not allow this (without >>>> --force). >>>> >>> Note: Petr2 agreed with David's solution >>> >>> LGTM, works as expected, but this patch prevents users to add >>> conflicting zones via webUI (there is no --force field). >>> We should improve webUI together with this patch. >>> >>> Martin^2 >>> >>>>> >>>>> Martin^2 >>>>> >>>> >>> >> >> The '--force' option was not in WebUI before even though it was in API. >> IMO we should not expose '--force' options in WebUI at all. >> > > Added similar options to ipa-{server,dns}-install and reworked the patch > to not duplicate the code. > Updated patch and one new attached. > > > Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0058.3-dns-do-not-add-forward-zone-if-it-is-already-resolva.patch Type: text/x-patch Size: 7577 bytes Desc: not available URL: From simo at redhat.com Thu Aug 27 12:34:24 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 27 Aug 2015 08:34:24 -0400 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <55DED2EC.4070008@redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <1440528239.8138.51.camel@willson.usersys.redhat.com> <55DEA685.1090407@redhat.com> <55DED2EC.4070008@redhat.com> Message-ID: <1440678864.8138.137.camel@willson.usersys.redhat.com> On Thu, 2015-08-27 at 11:05 +0200, Jan Cholasta wrote: > On 27.8.2015 07:56, Jan Cholasta wrote: > > On 25.8.2015 20:43, Simo Sorce wrote: > >> On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: > >>> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: > >>>> Hi, > >>>> > >>>> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): > >>>>> I've been carrying these patches in my tree for a while, I think it is > >>>>> time to put them in master as they stand on their own. > >>>>> > >>>>> Simo. > >>>> > >>>> Patch 530: ACK > >>>> > >>>> Patch 531: ACK > >>>> > >>>> Patch 532: > >>>> > >>>> The methods should be static methods: > >>>> > >>>> @staticmethod > >>>> def setOption(name, value): > >>>> ... > >>> > >>> Care to explain why ? > >>> @staticmethod is not used anywhere else in that file. > >> > >> Rebased patches on master, made requested change +1 more patch. > >> > >> Simo. > >> > > > > Patch 532: ACK > > > > Patch 533: ACK > > > > Pushed to master: f57b687241fbc92d1138507210e87e9de465c507 > > > > Honza > > > > Actually, there is a problem with patch 531: SASL mapping are added only > on replica. > > The attached patch fixes it. > This will break the promotion code, which needs to add the real sasl mappings later in the process. Can you leave the step in the non-common part of the setup for both server and replica installs ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Thu Aug 27 13:54:01 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 15:54:01 +0200 Subject: [Freeipa-devel] [PATCHES 478-479] cert renewal: KRA agent certificate update In-Reply-To: <20150827083422.GM22106@redhat.com> References: <55DEA4E1.5010908@redhat.com> <20150827083422.GM22106@redhat.com> Message-ID: <55DF1679.4070709@redhat.com> On 27.8.2015 10:34, Alexander Bokovoy wrote: > On Thu, 27 Aug 2015, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . > ACK to both patches. > Thanks. Pushed to: master: e9a76c3d126367f72e353919ecbff45bed3abaaf ipa-4-2: cea66362621f6ab6219a689c2da4025c37f496bb -- Jan Cholasta From jcholast at redhat.com Thu Aug 27 14:00:37 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 16:00:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0696-0710 More modernization In-Reply-To: <55DEE39E.8030203@redhat.com> References: <55CE2914.3000709@redhat.com> <55D703AA.7010406@redhat.com> <55D71EA8.4040002@redhat.com> <55DAB0B2.8050300@redhat.com> <55DABE3E.6070305@redhat.com> <55DB38BC.50907@redhat.com> <55DC45DD.1040907@redhat.com> <55DC6815.9090804@redhat.com> <55DD6F1A.8080205@redhat.com> <55DD91D0.7040109@redhat.com> <55DEB732.5040600@redhat.com> <55DEE39E.8030203@redhat.com> Message-ID: <55DF1805.5040608@redhat.com> On 27.8.2015 12:17, Petr Viktorin wrote: > On 08/27/2015 09:07 AM, Jan Cholasta wrote: >> On 26.8.2015 12:15, Petr Viktorin wrote: >>> On 08/26/2015 09:47 AM, Jan Cholasta wrote: >>>> On 25.8.2015 15:05, Petr Viktorin wrote: >>>>> On 08/25/2015 12:39 PM, Christian Heimes wrote: >>>>>> On 2015-08-24 17:31, Petr Viktorin wrote: >>>>>>>>>> 0701.2-Use-Python3-compatible-dict-method-names >>>>>>>>>> NACK >>>>>>>>>> Why are you replacing iteritems() with items() instead of using >>>>>>>>>> six.iteritems()? >>>>>>> >>>>>>> It looks cleaner, and it will be easier to clean up after six is >>>>>>> dropped. >>>>>>> Also, the performance difference is negligible if the whole thing is >>>>>>> iterated over. (On small dicts, which are the majority of what >>>>>>> iteritems >>>>>>> was used on, items() is actually a bit faster on my machine.) >>>>>> >>>>>> Right, for small dicts the speed difference is negligible and >>>>>> favors the >>>>>> items() over iteritems(). For medium sized and large dicts the >>>>>> iterators >>>>>> are faster and consume less memory. >>>>>> >>>>>> I'm preferring iterator methods everywhere because I don't have to >>>>>> worry >>>>>> about dict sizes. >>>>>> >>>>>>>>>> 0710.2-Modernize-use-of-range >>>>>>>>>> NACK >>>>>>>>>> Please use six.moves.range. It defaults to xrange() in Python 2. >>>>>>> >>>>>>> Why? What is the benefit of xrange in these situations? >>>>>>> >>>>>>> Like with iteritems in 0701, when iterating over the whole thing, the >>>>>>> performance difference is negligible. I don't think a few >>>>>>> microseconds >>>>>>> outside of tight loops are worth the verbosity. >>>>>> >>>>>> It's the same reasoning as in 0701. As long as you have a small range, >>>>>> it doesn't make a difference. For large ranges the additional memory >>>>>> usage can be problematic. >>>>>> >>>>>> In all above cases the iterator methods and generator functions are a >>>>>> safer choice. A malicious user can abuse the non-iterative methods for >>>>>> DoS attacks. As long as the input can't be controlled by a user and >>>>>> the >>>>>> range/dict/set/list is small, the non-iterative methods are fine. You >>>>>> have to verify every location, though. >>>>> >>>>> Keep in mind that for dicts, all the data is in memory already (in the >>>>> dict). Are you worried about DoS from an extra list of references to >>>>> existing objects? >>>>> >>>>>> I'm usually too busy with other stuff (aka lazy) to verify these >>>>>> preconditions... >>>>> >>>>> I changed one questionable use of range. The other ones are: >>>>> >>>>> ipalib/plugins/dns.py: for i in range(len(relative_record_name) >>>>> (max. ~255, verified by DNSName) >>>>> >>>>> ipaserver/install/dnskeysyncinstance.py: for _ in range(0, 16)) >>>>> (16) >>>>> >>>>> ipaserver/install/ipa_otptoken_import.py: for i in range(1, blocks + >>>>> 1): >>>>> (about 7) >>>>> >>>>> ipaserver/install/ipa_otptoken_import.py: for k in >>>>> range(mac.digest_size): >>>>> (16) >>>>> >>>>> ipatests/data.py: for d in range(256)) >>>>> (256) >>>>> >>>>> Plus tests, where it's rarely above 10. >>>>> >>>> >>>> I have just pushed Michael's python-krbV removal patch, which conflicts >>>> with your patches. Could you please rebase them on top of current >>>> master? >>>> >>> >>> Sure, here they are. >>> >>> >> >> Patches 696-699: ACK >> >> Patch 700: There are some error messages which contain basestring. Do we >> want to fix these as well? > > No, I think it's okay as a term. When Python 2 is dropped it can be > shortened to str. > >> Patch 701: Since we are using python-six, shouldn't "six.PY2" be used >> instead of "sys.version_info < (3, 0)"? > > Right, it looks a bit better. > >> Patches 702-709: ACK >> >> Patch 710: There are some "xrange"s in ipapython/p11helper.py and >> ipatests/test_xmlrpc/test_add_remove_cert_cmd.py. > > Thanks, fixed. > >> Patch 711: ACK >> > Thanks, ACK. Christian, if you don't have any objections, I will push the patches. -- Jan Cholasta From jcholast at redhat.com Thu Aug 27 14:02:03 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 16:02:03 +0200 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <1440678864.8138.137.camel@willson.usersys.redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <1440528239.8138.51.camel@willson.usersys.redhat.com> <55DEA685.1090407@redhat.com> <55DED2EC.4070008@redhat.com> <1440678864.8138.137.camel@willson.usersys.redhat.com> Message-ID: <55DF185B.2020806@redhat.com> On 27.8.2015 14:34, Simo Sorce wrote: > On Thu, 2015-08-27 at 11:05 +0200, Jan Cholasta wrote: >> On 27.8.2015 07:56, Jan Cholasta wrote: >>> On 25.8.2015 20:43, Simo Sorce wrote: >>>> On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: >>>>> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): >>>>>>> I've been carrying these patches in my tree for a while, I think it is >>>>>>> time to put them in master as they stand on their own. >>>>>>> >>>>>>> Simo. >>>>>> >>>>>> Patch 530: ACK >>>>>> >>>>>> Patch 531: ACK >>>>>> >>>>>> Patch 532: >>>>>> >>>>>> The methods should be static methods: >>>>>> >>>>>> @staticmethod >>>>>> def setOption(name, value): >>>>>> ... >>>>> >>>>> Care to explain why ? >>>>> @staticmethod is not used anywhere else in that file. >>>> >>>> Rebased patches on master, made requested change +1 more patch. >>>> >>>> Simo. >>>> >>> >>> Patch 532: ACK >>> >>> Patch 533: ACK >>> >>> Pushed to master: f57b687241fbc92d1138507210e87e9de465c507 >>> >>> Honza >>> >> >> Actually, there is a problem with patch 531: SASL mapping are added only >> on replica. >> >> The attached patch fixes it. >> > > This will break the promotion code, which needs to add the real sasl > mappings later in the process. > > Can you leave the step in the non-common part of the setup for both > server and replica installs ? OK, here you go. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-480.1-install-Fix-SASL-mappings-not-added-in-ipa-server-in.patch Type: text/x-patch Size: 914 bytes Desc: not available URL: From simo at redhat.com Thu Aug 27 14:02:53 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 27 Aug 2015 10:02:53 -0400 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <55DF185B.2020806@redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <1440528239.8138.51.camel@willson.usersys.redhat.com> <55DEA685.1090407@redhat.com> <55DED2EC.4070008@redhat.com> <1440678864.8138.137.camel@willson.usersys.redhat.com> <55DF185B.2020806@redhat.com> Message-ID: <1440684173.8138.141.camel@willson.usersys.redhat.com> On Thu, 2015-08-27 at 16:02 +0200, Jan Cholasta wrote: > On 27.8.2015 14:34, Simo Sorce wrote: > > On Thu, 2015-08-27 at 11:05 +0200, Jan Cholasta wrote: > >> On 27.8.2015 07:56, Jan Cholasta wrote: > >>> On 25.8.2015 20:43, Simo Sorce wrote: > >>>> On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: > >>>>> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): > >>>>>>> I've been carrying these patches in my tree for a while, I think it is > >>>>>>> time to put them in master as they stand on their own. > >>>>>>> > >>>>>>> Simo. > >>>>>> > >>>>>> Patch 530: ACK > >>>>>> > >>>>>> Patch 531: ACK > >>>>>> > >>>>>> Patch 532: > >>>>>> > >>>>>> The methods should be static methods: > >>>>>> > >>>>>> @staticmethod > >>>>>> def setOption(name, value): > >>>>>> ... > >>>>> > >>>>> Care to explain why ? > >>>>> @staticmethod is not used anywhere else in that file. > >>>> > >>>> Rebased patches on master, made requested change +1 more patch. > >>>> > >>>> Simo. > >>>> > >>> > >>> Patch 532: ACK > >>> > >>> Patch 533: ACK > >>> > >>> Pushed to master: f57b687241fbc92d1138507210e87e9de465c507 > >>> > >>> Honza > >>> > >> > >> Actually, there is a problem with patch 531: SASL mapping are added only > >> on replica. > >> > >> The attached patch fixes it. > >> > > > > This will break the promotion code, which needs to add the real sasl > > mappings later in the process. > > > > Can you leave the step in the non-common part of the setup for both > > server and replica installs ? > > OK, here you go. > LGTM Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Thu Aug 27 14:05:38 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 27 Aug 2015 16:05:38 +0200 Subject: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work In-Reply-To: <1440684173.8138.141.camel@willson.usersys.redhat.com> References: <1438339605.24296.4.camel@willson.usersys.redhat.com> <55C1AB44.9020807@redhat.com> <1438788289.20262.40.camel@willson.usersys.redhat.com> <1440528239.8138.51.camel@willson.usersys.redhat.com> <55DEA685.1090407@redhat.com> <55DED2EC.4070008@redhat.com> <1440678864.8138.137.camel@willson.usersys.redhat.com> <55DF185B.2020806@redhat.com> <1440684173.8138.141.camel@willson.usersys.redhat.com> Message-ID: <55DF1932.3000006@redhat.com> On 27.8.2015 16:02, Simo Sorce wrote: > On Thu, 2015-08-27 at 16:02 +0200, Jan Cholasta wrote: >> On 27.8.2015 14:34, Simo Sorce wrote: >>> On Thu, 2015-08-27 at 11:05 +0200, Jan Cholasta wrote: >>>> On 27.8.2015 07:56, Jan Cholasta wrote: >>>>> On 25.8.2015 20:43, Simo Sorce wrote: >>>>>> On Wed, 2015-08-05 at 11:24 -0400, Simo Sorce wrote: >>>>>>> On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): >>>>>>>>> I've been carrying these patches in my tree for a while, I think it is >>>>>>>>> time to put them in master as they stand on their own. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>> >>>>>>>> Patch 530: ACK >>>>>>>> >>>>>>>> Patch 531: ACK >>>>>>>> >>>>>>>> Patch 532: >>>>>>>> >>>>>>>> The methods should be static methods: >>>>>>>> >>>>>>>> @staticmethod >>>>>>>> def setOption(name, value): >>>>>>>> ... >>>>>>> >>>>>>> Care to explain why ? >>>>>>> @staticmethod is not used anywhere else in that file. >>>>>> >>>>>> Rebased patches on master, made requested change +1 more patch. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> Patch 532: ACK >>>>> >>>>> Patch 533: ACK >>>>> >>>>> Pushed to master: f57b687241fbc92d1138507210e87e9de465c507 >>>>> >>>>> Honza >>>>> >>>> >>>> Actually, there is a problem with patch 531: SASL mapping are added only >>>> on replica. >>>> >>>> The attached patch fixes it. >>>> >>> >>> This will break the promotion code, which needs to add the real sasl >>> mappings later in the process. >>> >>> Can you leave the step in the non-common part of the setup for both >>> server and replica installs ? >> >> OK, here you go. >> > > LGTM > > Simo. > Pushed to master: 0914cb663e6ea72628776e79d93f20bf979c7b68 -- Jan Cholasta From ofayans at redhat.com Thu Aug 27 15:41:00 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 27 Aug 2015 17:41:00 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DDE10A.8030704@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> <55DD8BDF.6050202@redhat.com> <55DDB6BA.7060102@redhat.com> <55DDDE55.7010903@redhat.com> <55DDE10A.8030704@redhat.com> Message-ID: <55DF2F8C.6080106@redhat.com> Hi, I am sorry I have missed that. Fixed. The test fails now due to this bug: https://fedorahosted.org/freeipa/ticket/5222 The test output is attached together with the updated patch On 08/26/2015 05:53 PM, Martin Basti wrote: > > > On 08/26/2015 05:42 PM, Martin Basti wrote: >> >> >> On 08/26/2015 02:53 PM, Oleg Fayans wrote: >>> Hi, >>> >>> No more short links :) >>> >>> On 08/26/2015 11:50 AM, Tomas Babej wrote: >>>> >>>> >>>> On 08/26/2015 11:44 AM, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> On 08/20/2015 11:18 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08/20/2015 10:26 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>>>>>> I got this: >>>>>>>> >>>>>>>> https://paste.fedoraproject.org/256746/43999380/ >>>>>>> FYI replica install failure. (I will retest it, but I'm pretty sure >>>>>>> that it was clean VM, test for some reason install client first) >>>>>>> >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>> >>>>>>> >>>>>>> line 295, in decorated >>>>>>> func(installer) >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>> >>>>>>> >>>>>>> line 319, in install_check >>>>>>> sys.exit("IPA client is already configured on this system.\n" >>>>>>> >>>>>>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >>>>>>> exception: SystemExit: IPA client is already configured on this >>>>>>> system. >>>>>>> Please uninstall it first before configuring the replica, using >>>>>>> 'ipa-client-install --uninstall'. >>>>>>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on this >>>>>>> system. >>>>>>> Please uninstall it first before configuring the replica, using >>>>>>> 'ipa-client-install --uninstall'. >>>>>> Confirm I got same error. >>>>> Fixed. It was a regex error. >>>>> >>>>>>> >>>>>>>> >>>>>>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> As discussed, here is a new version with pep8-related fixes >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> Already noticed that. Implemented the named groups as Tomas >>>>>>>>>> advised. >>>>>>>>>> Added the third test for >>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>>>>>> NACK, comments inline. >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the review! >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>>>>>> My bad, fixed. >>>>>>>>>>>>> >>>>>>>>>>>>> still there >>>>>>>>>>>>> >>>>>>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>>>>>> returns an >>>>>>>>>>>>> array of >>>>>>>>>>>>> >>>>>>>>>>>> Fixed, sorry. >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>> + creates a topology segment. The first argument is a >>>>>>>>>>>>>>> node to >>>>>>>>>>>>>>> run the >>>>>>>>>>>>>>> command on >>>>>>>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>>>>>>> + Returns a hash object containing segment's name, >>>>>>>>>>>>>>> leftnode, >>>>>>>>>>>>>>> rightnode information >>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would prefer to add assert there instead of just document >>>>>>>>>>>>>>> that a >>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>> object is needed >>>>>>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fixed. Created a decorator that checks the type of arguments >>>>>>>>>>>>> >>>>>>>>>>>>> This does not scale well. >>>>>>>>>>>>> If we will want to add new argument that is not host >>>>>>>>>>>>> object, you >>>>>>>>>>>>> need >>>>>>>>>>>>> change it again. >>>>>>>>>>>> >>>>>>>>>>>> Agreed. Modified the decorator so that you can specify a >>>>>>>>>>>> slice of >>>>>>>>>>>> arguments to be checked and a class to compare to. This does >>>>>>>>>>>> scale :) >>>>>>>>>>>>> >>>>>>>>>>>>> This might be used as function with specified variables that >>>>>>>>>>>>> have to be >>>>>>>>>>>>> host objects >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>>>>>> object of >>>>>>>>>>>>>>> class >>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Instead of description of params as first, second etc., you >>>>>>>>>>>>>>> may use >>>>>>>>>>>>>>> following: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>>>>>> + :param master: reference to master object of class Host >>>>>>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>>>>>> and eventually this in other methods >>>>>>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>>>>>> >>>>>>>>>>>>>> in fact >>>>>>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>>>>>> and >>>>>>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>>>>>> Are equally bad from the readability point of view. The first >>>>>>>>>>>>>> one is >>>>>>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>>>>>> >>>>>>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>>>>>> yesterday my >>>>>>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>>>>>> values to >>>>>>>>>>>>> single value attribute, because you used findall, I expected >>>>>>>>>>>>> that you >>>>>>>>>>>>> need multiple values, and then I saw that index [0] at the >>>>>>>>>>>>> end, >>>>>>>>>>>>> and I >>>>>>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>>>>>> >>>>>>>>>>>>> And because findall is not effective in case when you need to >>>>>>>>>>>>> find just >>>>>>>>>>>>> one occurrence. >>>>>>>>>>>> >>>>>>>>>>>> I got it. Fixed. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>>>>>> compability >>>>>>>>>>>>>>> already comes, but just for record: >>>>>>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>>>>>>> (import io >>>>>>>>>>>>>>> before) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1) >>>>>>>>>>>>> >>>>>>>>>>>>> +# >>>>>>>>>>>>> >>>>>>>>>>>>> empty comment here (several times) >>>>>>>>>>>> >>>>>>>>>>>> Removed >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> NACK >>>>>>>>>>> >>>>>>>>>>> you changed it wrong >>>>>>>>>>> >>>>>>>>>>> group() returns everything, you need use group(1) to return >>>>>>>>>>> content in >>>>>>>>>>> braces. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> Please, do not use third-party URL shorteners from within our source >>>> code. >>>> >>>> Tomas >>>> >>> >> >> I received 2 errors >> >> ___________________________________________________________________________________ >> TestTopologyOptions.test_add_remove_segment >> ___________________________________________________________________________________ >> >> >> self = > object at 0x7f6ab95b3110> >> >> def test_add_remove_segment(self): >> """ >> Make sure a topology segment can be manually created and >> deleted >> with the influence on the real topology >> Testcase >> http://www.freeipa.org/page/V4/Manage_replication_topology/ >> Test_plan#Test_case:_Basic_CRUD_test >> """ >> tasks.kinit_admin(self.master) >> # Install the second replica >> tasks.install_replica(self.master, self.replicas[1], >> setup_ca=False, >> setup_dns=False) >> # turn a star into a ring >> segment, err = tasks.create_segment(self.master, >> self.replicas[0], >> > self.replicas[1]) >> E TypeError: 'NoneType' object is not iterable >> >> test_integration/test_topology.py:102: TypeError >> >> Maybe tasks.create_segment returns None? >> In [3]: a, b = None >> --------------------------------------------------------------------------- >> >> TypeError Traceback (most recent call >> last) >> in () >> ----> 1 a, b = None >> >> TypeError: 'NoneType' object is not iterable >> >> >> -------------- >> >> self = > 0x7f399b9ea710>, raiseonerr = True >> >> def wait(self, raiseonerr=True): >> """Wait for the remote process to exit >> >> Raises an excption if the exit code is not 0, unless >> raiseonerr is >> true. >> """ >> if self._done: >> return self.returncode >> >> self._end_process() >> >> self._done = True >> >> if raiseonerr and self.returncode: >> self.log.error('Exit code: %s', self.returncode) >> > raise subprocess.CalledProcessError(self.returncode, >> self.argv) >> E CalledProcessError: Command '['ipa', >> 'topologysegment-del', 'realm', >> 'vm-152.abc.idm.lab.eng.brq.redhat.com-to-vm-160.abc.idm.lab.eng.brq.redhat.com']' >> returned non-zero exit status 2 >> > Honza found where the problem is. > > def check_arguments_are(slice, instanceof): > ... > def wrapper(func): > def wrapped(*args): > for i in args[slice[0]:slice[1]]: > assert isinstance(i, instanceof), "Wrong type: %s: %s" > % (i, type(i)) > func(*args) > return wrapped > return wrapper > > there should be > return func(*args) > > otherwise None will be always returned > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- ============================= test session starts ============================== platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 plugins: multihost, sourceorder collected 3 items test_integration/test_topology.py .FF =================================== FAILURES =================================== _________________ TestTopologyOptions.test_add_remove_segment __________________ self = def test_add_remove_segment(self): """ Make sure a topology segment can be manually created and deleted with the influence on the real topology Testcase http://www.freeipa.org/page/V4/Manage_replication_topology/ Test_plan#Test_case:_Basic_CRUD_test """ tasks.kinit_admin(self.master) # Install the second replica tasks.install_replica(self.master, self.replicas[1], setup_ca=False, setup_dns=False) # turn a star into a ring segment, err = tasks.create_segment(self.master, self.replicas[0], self.replicas[1]) > assert err == "", err E AssertionError: ipa: ERROR: Could not get Connectivity interactively E E assert 'ipa: ERROR: ...teractively\n' == '' E - ipa: ERROR: Could not get Connectivity interactively test_integration/test_topology.py:103: AssertionError _____________ TestTopologyOptions.test_remove_the_only_connection ______________ self = def test_remove_the_only_connection(self): """ Testcase: http://www.freeipa.org/page/V4/Manage_replication_topology/ Test_plan#Test_case: _Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica """ text = "Removal of Segment disconnects topology" error1 = "The system should not have let you remove the segment" error2 = "Wrong error message thrown during segment removal: \"%s\"" replicas = (self.replicas[0].hostname, self.replicas[1].hostname) returncode, error = tasks.destroy_segment(self.master, "%s-to-%s" % replicas) assert returncode != 0, error1 > assert error.count(text) == 1, error2 % error E AssertionError: Wrong error message thrown during segment removal: "ipa: ERROR: f22replica1.pesen.net-to-f22replica2.pesen.net: segment not found E " E assert 0 == 1 E + where 0 = ('Removal of Segment disconnects topology') E + where = 'ipa: ERROR: f22replica1.pesen.net-to-f22replica2.pesen.net: segment not found\n'.count test_integration/test_topology.py:142: AssertionError ==================== 2 failed, 1 passed in 1801.27 seconds ===================== -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.9-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 9103 bytes Desc: not available URL: From mbasti at redhat.com Thu Aug 27 16:27:38 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Aug 2015 18:27:38 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DF2F8C.6080106@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> <55DD8BDF.6050202@redhat.com> <55DDB6BA.7060102@redhat.com> <55DDDE55.7010903@redhat.com> <55DDE10A.8030704@redhat.com> <55DF2F8C.6080106@redhat.com> Message-ID: <55DF3A7A.10503@redhat.com> On 08/27/2015 05:41 PM, Oleg Fayans wrote: > Hi, > > I am sorry I have missed that. > Fixed. The test fails now due to this bug: > > https://fedorahosted.org/freeipa/ticket/5222 > > The test output is attached together with the updated patch > > On 08/26/2015 05:53 PM, Martin Basti wrote: >> >> >> On 08/26/2015 05:42 PM, Martin Basti wrote: >>> >>> >>> On 08/26/2015 02:53 PM, Oleg Fayans wrote: >>>> Hi, >>>> >>>> No more short links :) >>>> >>>> On 08/26/2015 11:50 AM, Tomas Babej wrote: >>>>> >>>>> >>>>> On 08/26/2015 11:44 AM, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> On 08/20/2015 11:18 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08/20/2015 10:26 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>>>>>>> I got this: >>>>>>>>> >>>>>>>>> https://paste.fedoraproject.org/256746/43999380/ >>>>>>>> FYI replica install failure. (I will retest it, but I'm pretty >>>>>>>> sure >>>>>>>> that it was clean VM, test for some reason install client first) >>>>>>>> >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> line 295, in decorated >>>>>>>> func(installer) >>>>>>>> File >>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> line 319, in install_check >>>>>>>> sys.exit("IPA client is already configured on this system.\n" >>>>>>>> >>>>>>>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >>>>>>>> exception: SystemExit: IPA client is already configured on this >>>>>>>> system. >>>>>>>> Please uninstall it first before configuring the replica, using >>>>>>>> 'ipa-client-install --uninstall'. >>>>>>>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on >>>>>>>> this >>>>>>>> system. >>>>>>>> Please uninstall it first before configuring the replica, using >>>>>>>> 'ipa-client-install --uninstall'. >>>>>>> Confirm I got same error. >>>>>> Fixed. It was a regex error. >>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> As discussed, here is a new version with pep8-related fixes >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> Already noticed that. Implemented the named groups as Tomas >>>>>>>>>>> advised. >>>>>>>>>>> Added the third test for >>>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>>>>>>> NACK, comments inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the review! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>>>>>>> My bad, fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> still there >>>>>>>>>>>>>> >>>>>>>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>>>>>>> returns an >>>>>>>>>>>>>> array of >>>>>>>>>>>>>> >>>>>>>>>>>>> Fixed, sorry. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>>> + creates a topology segment. The first argument is a >>>>>>>>>>>>>>>> node to >>>>>>>>>>>>>>>> run the >>>>>>>>>>>>>>>> command on >>>>>>>>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>>>>>>>> + Returns a hash object containing segment's name, >>>>>>>>>>>>>>>> leftnode, >>>>>>>>>>>>>>>> rightnode information >>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would prefer to add assert there instead of just >>>>>>>>>>>>>>>> document >>>>>>>>>>>>>>>> that a >>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>> object is needed >>>>>>>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fixed. Created a decorator that checks the type of >>>>>>>>>>>>>>> arguments >>>>>>>>>>>>>> >>>>>>>>>>>>>> This does not scale well. >>>>>>>>>>>>>> If we will want to add new argument that is not host >>>>>>>>>>>>>> object, you >>>>>>>>>>>>>> need >>>>>>>>>>>>>> change it again. >>>>>>>>>>>>> >>>>>>>>>>>>> Agreed. Modified the decorator so that you can specify a >>>>>>>>>>>>> slice of >>>>>>>>>>>>> arguments to be checked and a class to compare to. This does >>>>>>>>>>>>> scale :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> This might be used as function with specified variables that >>>>>>>>>>>>>> have to be >>>>>>>>>>>>>> host objects >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>>>>>>> object of >>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Instead of description of params as first, second etc., >>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>> may use >>>>>>>>>>>>>>>> following: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>>>>>>> + :param master: reference to master object of class >>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>>>>>>> and eventually this in other methods >>>>>>>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in fact >>>>>>>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>>>>>>> Are equally bad from the readability point of view. The >>>>>>>>>>>>>>> first >>>>>>>>>>>>>>> one is >>>>>>>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>>>>>>> yesterday my >>>>>>>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>>>>>>> values to >>>>>>>>>>>>>> single value attribute, because you used findall, I expected >>>>>>>>>>>>>> that you >>>>>>>>>>>>>> need multiple values, and then I saw that index [0] at the >>>>>>>>>>>>>> end, >>>>>>>>>>>>>> and I >>>>>>>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And because findall is not effective in case when you >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> find just >>>>>>>>>>>>>> one occurrence. >>>>>>>>>>>>> >>>>>>>>>>>>> I got it. Fixed. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>>>>>>> compability >>>>>>>>>>>>>>>> already comes, but just for record: >>>>>>>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>>>>>>>> (import io >>>>>>>>>>>>>>>> before) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> >>>>>>>>>>>>>> +# >>>>>>>>>>>>>> >>>>>>>>>>>>>> empty comment here (several times) >>>>>>>>>>>>> >>>>>>>>>>>>> Removed >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> NACK >>>>>>>>>>>> >>>>>>>>>>>> you changed it wrong >>>>>>>>>>>> >>>>>>>>>>>> group() returns everything, you need use group(1) to return >>>>>>>>>>>> content in >>>>>>>>>>>> braces. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Please, do not use third-party URL shorteners from within our source >>>>> code. >>>>> >>>>> Tomas >>>>> >>>> >>> >>> I received 2 errors >>> >>> ___________________________________________________________________________________ >>> >>> TestTopologyOptions.test_add_remove_segment >>> ___________________________________________________________________________________ >>> >>> >>> >>> self = >> object at 0x7f6ab95b3110> >>> >>> def test_add_remove_segment(self): >>> """ >>> Make sure a topology segment can be manually created and >>> deleted >>> with the influence on the real topology >>> Testcase >>> http://www.freeipa.org/page/V4/Manage_replication_topology/ >>> Test_plan#Test_case:_Basic_CRUD_test >>> """ >>> tasks.kinit_admin(self.master) >>> # Install the second replica >>> tasks.install_replica(self.master, self.replicas[1], >>> setup_ca=False, >>> setup_dns=False) >>> # turn a star into a ring >>> segment, err = tasks.create_segment(self.master, >>> self.replicas[0], >>> > self.replicas[1]) >>> E TypeError: 'NoneType' object is not iterable >>> >>> test_integration/test_topology.py:102: TypeError >>> >>> Maybe tasks.create_segment returns None? >>> In [3]: a, b = None >>> --------------------------------------------------------------------------- >>> >>> >>> TypeError Traceback (most recent call >>> last) >>> in () >>> ----> 1 a, b = None >>> >>> TypeError: 'NoneType' object is not iterable >>> >>> >>> -------------- >>> >>> self = >> 0x7f399b9ea710>, raiseonerr = True >>> >>> def wait(self, raiseonerr=True): >>> """Wait for the remote process to exit >>> >>> Raises an excption if the exit code is not 0, unless >>> raiseonerr is >>> true. >>> """ >>> if self._done: >>> return self.returncode >>> >>> self._end_process() >>> >>> self._done = True >>> >>> if raiseonerr and self.returncode: >>> self.log.error('Exit code: %s', self.returncode) >>> > raise subprocess.CalledProcessError(self.returncode, >>> self.argv) >>> E CalledProcessError: Command '['ipa', >>> 'topologysegment-del', 'realm', >>> 'vm-152.abc.idm.lab.eng.brq.redhat.com-to-vm-160.abc.idm.lab.eng.brq.redhat.com']' >>> >>> returned non-zero exit status 2 >>> >> Honza found where the problem is. >> >> def check_arguments_are(slice, instanceof): >> ... >> def wrapper(func): >> def wrapped(*args): >> for i in args[slice[0]:slice[1]]: >> assert isinstance(i, instanceof), "Wrong type: %s: %s" >> % (i, type(i)) >> func(*args) >> return wrapped >> return wrapper >> >> there should be >> return func(*args) >> >> otherwise None will be always returned >> > It looks nice, but I miss the integration test in the patch. From ofayans at redhat.com Thu Aug 27 17:21:03 2015 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 27 Aug 2015 19:21:03 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DF3A7A.10503@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> <55DD8BDF.6050202@redhat.com> <55DDB6BA.7060102@redhat.com> <55DDDE55.7010903@redhat.com> <55DDE10A.8030704@redhat.com> <55DF2F8C.6080106@redhat.com> <55DF3A7A.10503@redhat.com> Message-ID: <55DF46FF.4070502@redhat.com> Hi Martin, My bad, forgot to do git add. On 08/27/2015 06:27 PM, Martin Basti wrote: > > > On 08/27/2015 05:41 PM, Oleg Fayans wrote: >> Hi, >> >> I am sorry I have missed that. >> Fixed. The test fails now due to this bug: >> >> https://fedorahosted.org/freeipa/ticket/5222 >> >> The test output is attached together with the updated patch >> >> On 08/26/2015 05:53 PM, Martin Basti wrote: >>> >>> >>> On 08/26/2015 05:42 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/26/2015 02:53 PM, Oleg Fayans wrote: >>>>> Hi, >>>>> >>>>> No more short links :) >>>>> >>>>> On 08/26/2015 11:50 AM, Tomas Babej wrote: >>>>>> >>>>>> >>>>>> On 08/26/2015 11:44 AM, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> On 08/20/2015 11:18 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08/20/2015 10:26 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>>>>>>>> I got this: >>>>>>>>>> >>>>>>>>>> https://paste.fedoraproject.org/256746/43999380/ >>>>>>>>> FYI replica install failure. (I will retest it, but I'm pretty >>>>>>>>> sure >>>>>>>>> that it was clean VM, test for some reason install client first) >>>>>>>>> >>>>>>>>> File >>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> line 295, in decorated >>>>>>>>> func(installer) >>>>>>>>> File >>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> line 319, in install_check >>>>>>>>> sys.exit("IPA client is already configured on this system.\n" >>>>>>>>> >>>>>>>>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command failed, >>>>>>>>> exception: SystemExit: IPA client is already configured on this >>>>>>>>> system. >>>>>>>>> Please uninstall it first before configuring the replica, using >>>>>>>>> 'ipa-client-install --uninstall'. >>>>>>>>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on >>>>>>>>> this >>>>>>>>> system. >>>>>>>>> Please uninstall it first before configuring the replica, using >>>>>>>>> 'ipa-client-install --uninstall'. >>>>>>>> Confirm I got same error. >>>>>>> Fixed. It was a regex error. >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>>>>>>>> Hi Martin, >>>>>>>>>>> >>>>>>>>>>> As discussed, here is a new version with pep8-related fixes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> Already noticed that. Implemented the named groups as Tomas >>>>>>>>>>>> advised. >>>>>>>>>>>> Added the third test for >>>>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>>>>>>>> NACK, comments inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for the review! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>>>>>>>> My bad, fixed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> still there >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>>>>>>>> returns an >>>>>>>>>>>>>>> array of >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Fixed, sorry. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>>>> + creates a topology segment. The first argument is a >>>>>>>>>>>>>>>>> node to >>>>>>>>>>>>>>>>> run the >>>>>>>>>>>>>>>>> command on >>>>>>>>>>>>>>>>> + The first 3 arguments should be objects of class Host >>>>>>>>>>>>>>>>> + Returns a hash object containing segment's name, >>>>>>>>>>>>>>>>> leftnode, >>>>>>>>>>>>>>>>> rightnode information >>>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I would prefer to add assert there instead of just >>>>>>>>>>>>>>>>> document >>>>>>>>>>>>>>>>> that a >>>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>>> object is needed >>>>>>>>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fixed. Created a decorator that checks the type of >>>>>>>>>>>>>>>> arguments >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This does not scale well. >>>>>>>>>>>>>>> If we will want to add new argument that is not host >>>>>>>>>>>>>>> object, you >>>>>>>>>>>>>>> need >>>>>>>>>>>>>>> change it again. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Agreed. Modified the decorator so that you can specify a >>>>>>>>>>>>>> slice of >>>>>>>>>>>>>> arguments to be checked and a class to compare to. This does >>>>>>>>>>>>>> scale :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This might be used as function with specified variables that >>>>>>>>>>>>>>> have to be >>>>>>>>>>>>>>> host objects >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>>>>>>>> object of >>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Instead of description of params as first, second etc., >>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>> may use >>>>>>>>>>>>>>>>> following: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>>>>>>>> + :param master: reference to master object of class >>>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>>>>>>>> and eventually this in other methods >>>>>>>>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in fact >>>>>>>>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>>>>>>>> Are equally bad from the readability point of view. The >>>>>>>>>>>>>>>> first >>>>>>>>>>>>>>>> one is >>>>>>>>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>>>>>>>> yesterday my >>>>>>>>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>>>>>>>> values to >>>>>>>>>>>>>>> single value attribute, because you used findall, I expected >>>>>>>>>>>>>>> that you >>>>>>>>>>>>>>> need multiple values, and then I saw that index [0] at the >>>>>>>>>>>>>>> end, >>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And because findall is not effective in case when you >>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>> find just >>>>>>>>>>>>>>> one occurrence. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I got it. Fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>>>>>>>> compability >>>>>>>>>>>>>>>>> already comes, but just for record: >>>>>>>>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, 'r') >>>>>>>>>>>>>>>>> (import io >>>>>>>>>>>>>>>>> before) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +# >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> empty comment here (several times) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Removed >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> NACK >>>>>>>>>>>>> >>>>>>>>>>>>> you changed it wrong >>>>>>>>>>>>> >>>>>>>>>>>>> group() returns everything, you need use group(1) to return >>>>>>>>>>>>> content in >>>>>>>>>>>>> braces. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Please, do not use third-party URL shorteners from within our source >>>>>> code. >>>>>> >>>>>> Tomas >>>>>> >>>>> >>>> >>>> I received 2 errors >>>> >>>> ___________________________________________________________________________________ >>>> >>>> TestTopologyOptions.test_add_remove_segment >>>> ___________________________________________________________________________________ >>>> >>>> >>>> >>>> self = >>> object at 0x7f6ab95b3110> >>>> >>>> def test_add_remove_segment(self): >>>> """ >>>> Make sure a topology segment can be manually created and >>>> deleted >>>> with the influence on the real topology >>>> Testcase >>>> http://www.freeipa.org/page/V4/Manage_replication_topology/ >>>> Test_plan#Test_case:_Basic_CRUD_test >>>> """ >>>> tasks.kinit_admin(self.master) >>>> # Install the second replica >>>> tasks.install_replica(self.master, self.replicas[1], >>>> setup_ca=False, >>>> setup_dns=False) >>>> # turn a star into a ring >>>> segment, err = tasks.create_segment(self.master, >>>> self.replicas[0], >>>> > self.replicas[1]) >>>> E TypeError: 'NoneType' object is not iterable >>>> >>>> test_integration/test_topology.py:102: TypeError >>>> >>>> Maybe tasks.create_segment returns None? >>>> In [3]: a, b = None >>>> --------------------------------------------------------------------------- >>>> >>>> >>>> TypeError Traceback (most recent call >>>> last) >>>> in () >>>> ----> 1 a, b = None >>>> >>>> TypeError: 'NoneType' object is not iterable >>>> >>>> >>>> -------------- >>>> >>>> self = >>> 0x7f399b9ea710>, raiseonerr = True >>>> >>>> def wait(self, raiseonerr=True): >>>> """Wait for the remote process to exit >>>> >>>> Raises an excption if the exit code is not 0, unless >>>> raiseonerr is >>>> true. >>>> """ >>>> if self._done: >>>> return self.returncode >>>> >>>> self._end_process() >>>> >>>> self._done = True >>>> >>>> if raiseonerr and self.returncode: >>>> self.log.error('Exit code: %s', self.returncode) >>>> > raise subprocess.CalledProcessError(self.returncode, >>>> self.argv) >>>> E CalledProcessError: Command '['ipa', >>>> 'topologysegment-del', 'realm', >>>> 'vm-152.abc.idm.lab.eng.brq.redhat.com-to-vm-160.abc.idm.lab.eng.brq.redhat.com']' >>>> >>>> returned non-zero exit status 2 >>>> >>> Honza found where the problem is. >>> >>> def check_arguments_are(slice, instanceof): >>> ... >>> def wrapper(func): >>> def wrapped(*args): >>> for i in args[slice[0]:slice[1]]: >>> assert isinstance(i, instanceof), "Wrong type: %s: %s" >>> % (i, type(i)) >>> func(*args) >>> return wrapped >>> return wrapper >>> >>> there should be >>> return func(*args) >>> >>> otherwise None will be always returned >>> >> > It looks nice, but I miss the integration test in the patch. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0002.10-Integration-tests-topology-plugin.patch Type: text/x-patch Size: 16901 bytes Desc: not available URL: From edewata at redhat.com Thu Aug 27 19:41:35 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 27 Aug 2015 14:41:35 -0500 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. Message-ID: <55DF67EF.6020905@redhat.com> The CA and KRA installation code has been modified to use LDAPI to create the CA and KRA agents directly in the CA and KRA database. This way it's no longer necessary to use the Directory Manager password or CA and KRA admin certificate. https://fedorahosted.org/freeipa/ticket/5257 -- Endi S. Dewata -------------- next part -------------- From 45af6d4f9a8ebc9bbd2856d7bf3af48520996dad Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Thu, 27 Aug 2015 06:44:29 +0200 Subject: [PATCH] Using LDAPI to setup CA and KRA agents. The CA and KRA installation code has been modified to use LDAPI to create the CA and KRA agents directly in the CA and KRA database. This way it's no longer necessary to use the Directory Manager password or CA and KRA admin certificate. https://fedorahosted.org/freeipa/ticket/5257 --- ipaplatform/base/paths.py | 2 - ipaserver/install/cainstance.py | 49 ++++++++++------- ipaserver/install/krainstance.py | 113 +++++++++++++++------------------------ 3 files changed, 72 insertions(+), 92 deletions(-) diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index 5c8f25d6ef85fab2b9b30a660cd1c0360dbe9931..0dd3c7fda3020264a1ace8f2d13557cfddf18c2d 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -343,8 +343,6 @@ class BasePathNamespace(object): SLAPD_INSTANCE_SOCKET_TEMPLATE = "/var/run/slapd-%s.socket" ALL_SLAPD_INSTANCE_SOCKETS = "/var/run/slapd-*.socket" ADMIN_CERT_PATH = '/root/.dogtag/pki-tomcat/ca_admin.cert' - KRA_NSSDB_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/password.conf" - KRA_PKCS12_PASSWORD_FILE = "/root/.dogtag/pki-tomcat/kra/pkcs12_password.conf" ENTROPY_AVAIL = '/proc/sys/kernel/random/entropy_avail' LDIF2DB = '/usr/sbin/ldif2db' DB2LDIF = '/usr/sbin/db2ldif' diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index ecd9300036353426097d929918be974cbbb5c69d..bec39419363f1ade0130465d3b70e1c5540b6006 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -904,17 +904,26 @@ class CAInstance(DogtagInstance): self.configure_agent_renewal() def __configure_ra(self): - # Create an RA user in the CA LDAP server and add that user to - # the appropriate groups so it can issue certificates without - # manual intervention. - conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) - conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) + """ + Create CA agent, assign a certificate, and add the user to + the appropriate groups for accessing CA services. + """ - decoded = base64.b64decode(self.ra_cert) + # get ipaCert certificate + cert_data = base64.b64decode(self.ra_cert) + cert = x509.load_certificate(cert_data, x509.DER) - entry_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) - entry = conn.make_entry( - entry_dn, + # connect to CA database + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) + if not conn.isconnected(): + conn.connect(autobind=True) + + # create ipara user with ipaCert certificate + user_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) + conn.create( + dn=user_dn, objectClass=['top', 'person', 'organizationalPerson', 'inetOrgPerson', 'cmsuser'], uid=["ipara"], @@ -922,23 +931,23 @@ class CAInstance(DogtagInstance): cn=["ipara"], usertype=["agentType"], userstate=["1"], - userCertificate=[decoded], + userCertificate=[cert_data], description=['2;%s;%s;%s' % ( - str(self.requestId), + cert.serial_number, DN(('CN', 'Certificate Authority'), self.subject_base), DN(('CN', 'IPA RA'), self.subject_base))]) - conn.add_entry(entry) + # add ipara user to Certificate Manager Agents group + group_dn = DN(('cn', 'Certificate Manager Agents'), ('ou', 'groups'), + self.basedn) + conn.add_entry_to_group(user_dn, group_dn, 'uniqueMember') - dn = DN(('cn', 'Certificate Manager Agents'), ('ou', 'groups'), self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) + # add ipara user to Registration Manager Agents group + group_dn = DN(('cn', 'Registration Manager Agents'), ('ou', 'groups'), + self.basedn) + conn.add_entry_to_group(user_dn, group_dn, 'uniqueMember') - dn = DN(('cn', 'Registration Manager Agents'), ('ou', 'groups'), self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) - - conn.unbind() + conn.disconnect() def __configure_profiles_acl(self): """Allow the Certificate Manager Agents group to modify profiles.""" diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index e5cdbf5e7714603041e3f0156e87311994175b18..b57858d51ae7b3ddb629c7e0e519e5d7b54f6a0b 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -25,17 +25,21 @@ import sys import tempfile from ipalib import api +from ipalib import x509 from ipaplatform import services from ipaplatform.paths import paths +from ipapython import certdb from ipapython import dogtag from ipapython import ipautil from ipapython.dn import DN from ipaserver.install import certs from ipaserver.install import cainstance +from ipaserver.install import installutils from ipaserver.install import ldapupdate from ipaserver.install import service from ipaserver.install.dogtaginstance import DogtagInstance from ipaserver.install.dogtaginstance import DEFAULT_DSPORT, PKI_USER +from ipaserver.plugins import ldap2 from ipapython.ipa_log_manager import log_mgr # When IPA is installed with DNS support, this CNAME should hold all IPA @@ -111,8 +115,8 @@ class KRAInstance(DogtagInstance): self.step("configuring KRA instance", self.__spawn_instance) if not self.clone: - self.step("add RA user to KRA agent group", - self.__add_ra_user_to_agent_group) + self.step("create KRA agent", + self.__create_kra_agent) self.step("restarting KRA", self.restart_instance) self.step("configure certmonger for renewals", self.configure_certmonger_renewal) @@ -267,77 +271,46 @@ class KRAInstance(DogtagInstance): self.log.debug("completed creating KRA instance") - def __add_ra_user_to_agent_group(self): + def __create_kra_agent(self): """ - Add RA agent created for CA to KRA agent group. + Create KRA agent, assign a certificate, and add the user to + the appropriate groups for accessing KRA services. """ - # import CA certificate into temporary security database - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "client-cert-import", - "--pkcs12", paths.KRACERT_P12, - "--pkcs12-password-file", paths.KRA_PKCS12_PASSWORD_FILE] - ipautil.run(args) - - # trust CA certificate - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "client-cert-mod", "Certificate Authority - %s" % api.env.realm, - "--trust", "CT,c,"] - ipautil.run(args) - - # import Dogtag admin certificate into temporary security database - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "client-cert-import", - "--pkcs12", paths.DOGTAG_ADMIN_P12, - "--pkcs12-password-file", paths.KRA_PKCS12_PASSWORD_FILE] - ipautil.run(args) - - # as Dogtag admin, create ipakra user in KRA - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "-n", "ipa-ca-agent", - "kra-user-add", "ipakra", - "--fullName", "IPA KRA User"] - ipautil.run(args) - - # as Dogtag admin, add ipakra into KRA agents group - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "-n", "ipa-ca-agent", - "kra-user-membership-add", "ipakra", "Data Recovery Manager Agents"] - ipautil.run(args) - - # assign ipaCert to ipakra - (file, filename) = tempfile.mkstemp() - os.close(file) - try: - # export ipaCert without private key - args = ["/usr/bin/pki", - "-d", paths.HTTPD_ALIAS_DIR, - "-C", paths.ALIAS_PWDFILE_TXT, - "client-cert-show", "ipaCert", - "--cert", filename] - ipautil.run(args) - - # as Dogtag admin, upload and assign ipaCert to ipakra - args = ["/usr/bin/pki", - "-d", self.agent_db, - "-C", paths.KRA_NSSDB_PASSWORD_FILE, - "-n", "ipa-ca-agent", - "kra-user-cert-add", "ipakra", - "--input", filename] - ipautil.run(args) - - finally: - os.remove(filename) + # get ipaCert certificate + with certdb.NSSDatabase(paths.HTTPD_ALIAS_DIR) as ipa_nssdb: + cert_data = ipa_nssdb.get_cert("ipaCert") + cert = x509.load_certificate(cert_data, x509.DER) + + # connect to KRA database + server_id = installutils.realm_to_serverid(api.env.realm) + dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id + conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) + if not conn.isconnected(): + conn.connect(autobind=True) + + # create ipakra user with ipaCert certificate + user_dn = DN(('uid', "ipakra"), ('ou', 'people'), self.basedn) + conn.create( + dn=user_dn, + objectClass=['top', 'person', 'organizationalPerson', + 'inetOrgPerson', 'cmsuser'], + uid=["ipakra"], + sn=["IPA KRA User"], + cn=["IPA KRA User"], + usertype=["undefined"], + userCertificate=[cert_data], + description=['2;%s;%s;%s' % ( + cert.serial_number, + DN(('CN', 'Certificate Authority'), self.subject_base), + DN(('CN', 'IPA RA'), self.subject_base))]) + + # add ipakra user to Data Recovery Manager Agents group + group_dn = DN(('cn', 'Data Recovery Manager Agents'), ('ou', 'groups'), + self.basedn) + conn.add_entry_to_group(user_dn, group_dn, 'uniqueMember') + + conn.disconnect() def __add_vault_container(self): sub_dict = { -- 2.4.3 From pspacek at redhat.com Fri Aug 28 08:03:38 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 28 Aug 2015 10:03:38 +0200 Subject: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55DF0117.3010800@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> <55DC2951.60508@redhat.com> <55DC61EB.4050205@redhat.com> <55DF0117.3010800@redhat.com> Message-ID: <55E015DA.902@redhat.com> On 27.8.2015 14:22, David Kupka wrote: > @@ -2101,11 +2101,25 @@ class DNSZoneBase(LDAPObject): > > class DNSZoneBase_add(LDAPCreate): > > + takes_options = LDAPCreate.takes_options + ( > + Flag('force', > + label=_('Force'), > + doc=_('Force DNS zone creation.') > + ), > + Flag('skip_overlap_check', > + doc=_('Force DNS zone creation even if it will overlap with ' > + 'existing zone.') > + ), > + ) > + > has_output_params = LDAPCreate.has_output_params + dnszone_output_params > > def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): > assert isinstance(dn, DN) > > + if options['force']: > + options['skip_overlap_check'] = True > + > try: > entry = ldap.get_entry(dn) > except errors.NotFound: > @@ -2120,6 +2134,12 @@ class DNSZoneBase_add(LDAPCreate): > > entry_attrs['idnszoneactive'] = 'TRUE' > > + if not options['skip_overlap_check']: > + try: > + check_zone_overlap(keys[-1]) > + except RuntimeError as e: > + raise errors.InvocationError(e.message) > + > return dn > > > @@ -2673,9 +2693,9 @@ class dnszone_add(DNSZoneBase_add): > __doc__ = _('Create new DNS zone (SOA record).') > > takes_options = DNSZoneBase_add.takes_options + ( > - Flag('force', > - label=_('Force'), > - doc=_('Force DNS zone creation even if nameserver is not resolvable.'), > + Flag('skip_nameserver_check', > + doc=_('Force DNS zone creation even if nameserver is not ' > + 'resolvable.') > ), > > # Deprecated > @@ -2699,6 +2719,9 @@ class dnszone_add(DNSZoneBase_add): > def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): > assert isinstance(dn, DN) > > + if options['force']: > + options['skip_nameserver_check'] = True Why is it in DNSZoneBase_add.pre_callback? Shouldn't the equation force = (skip_nameserver_check + skip_nameserver_check) be handled in parameter parsing & validation? (Again, I do not know the IPA framework :-)) > + > dn = super(dnszone_add, self).pre_callback( > ldap, dn, entry_attrs, attrs_list, *keys, **options) > > @@ -2713,7 +2736,7 @@ class dnszone_add(DNSZoneBase_add): > error=_("Nameserver for reverse zone cannot be a relative DNS name")) > > # verify if user specified server is resolvable > - if not options['force']: > + if not options['skip_nameserver_check']: > check_ns_rec_resolvable(keys[0], entry_attrs['idnssoamname']) > # show warning about --name-server option > context.show_warning_nameserver_option = True > diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py > index d959bb369d946217acd080e78483cc9013dda4c7..18f477d4fb6620090b7073689c8df51b65a8307a 100644 > --- a/ipapython/ipautil.py > +++ b/ipapython/ipautil.py > @@ -924,6 +924,20 @@ def host_exists(host): > else: > return True > > +def check_zone_overlap(zone): > + if resolver.zone_for_name(zone) == zone: > + try: > + ns = [ans.to_text() for ans in resolver.query(zone, 'NS')] > + except DNSException as e: > + root_logger.debug("Failed to resolve nameserver(s) for domain" > + " {0}: {1}".format(zone, e)) > + ns = [] > + > + msg = u"DNS zone {0} already exists".format(zone) Nitpick: I would say "already exists in DNS" to make it absolutely clear. Just 'already exists' might be confusing because ipa dnszone-show will say that the zone does not exist ... > + if ns: > + msg += u" and is handled by server(s): {0}".format(', '.join(ns)) > + raise RuntimeError(msg) > + > def get_ipa_basedn(conn): > """ > Get base DN of IPA suffix in given LDAP server. -- Petr^2 Spacek From rkuska at redhat.com Fri Aug 28 08:48:33 2015 From: rkuska at redhat.com (Robert Kuska) Date: Fri, 28 Aug 2015 04:48:33 -0400 (EDT) Subject: [Freeipa-devel] COPR repo for python3 dependencies of freeipa In-Reply-To: <121533864.14754395.1440751227544.JavaMail.zimbra@redhat.com> Message-ID: <1839823599.14756165.1440751713910.JavaMail.zimbra@redhat.com> Hello everyone, I've managed to build pki-core with python3 along with its dependencies (python3-nss and python3-pyldap), folks interested in testing freeipa with python3 may grab my repo at: https://copr.fedoraproject.org/coprs/rkuska/ipa_python3/ To enable repo within Fedora type: sudo dnf copr enable rkuska/ipa_python3 Full matrix of availability of package x fedora_release: https://copr.fedoraproject.org/coprs/rkuska/ipa_python3/monitor/ Regards Robert Kuska {rkuska} From mbasti at redhat.com Fri Aug 28 11:36:30 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 28 Aug 2015 13:36:30 +0200 Subject: [Freeipa-devel] [PATCH 0058, 0064] dns: do not add (forward)zone if it is already resolvable. In-Reply-To: <55E015DA.902@redhat.com> References: <55B8DF32.70208@redhat.com> <55BA1ABC.8020108@redhat.com> <55BB5CD3.5060603@redhat.com> <55D58FBA.6070105@redhat.com> <55DB2F73.6050608@redhat.com> <55DC2951.60508@redhat.com> <55DC61EB.4050205@redhat.com> <55DF0117.3010800@redhat.com> <55E015DA.902@redhat.com> Message-ID: <55E047BE.5000507@redhat.com> On 08/28/2015 10:03 AM, Petr Spacek wrote: > On 27.8.2015 14:22, David Kupka wrote: >> @@ -2101,11 +2101,25 @@ class DNSZoneBase(LDAPObject): >> >> class DNSZoneBase_add(LDAPCreate): >> >> + takes_options = LDAPCreate.takes_options + ( >> + Flag('force', >> + label=_('Force'), >> + doc=_('Force DNS zone creation.') >> + ), >> + Flag('skip_overlap_check', >> + doc=_('Force DNS zone creation even if it will overlap with ' >> + 'existing zone.') >> + ), >> + ) >> + >> has_output_params = LDAPCreate.has_output_params + dnszone_output_params >> >> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): >> assert isinstance(dn, DN) >> >> + if options['force']: >> + options['skip_overlap_check'] = True >> + >> try: >> entry = ldap.get_entry(dn) >> except errors.NotFound: >> @@ -2120,6 +2134,12 @@ class DNSZoneBase_add(LDAPCreate): >> >> entry_attrs['idnszoneactive'] = 'TRUE' >> >> + if not options['skip_overlap_check']: >> + try: >> + check_zone_overlap(keys[-1]) >> + except RuntimeError as e: >> + raise errors.InvocationError(e.message) >> + >> return dn >> >> >> @@ -2673,9 +2693,9 @@ class dnszone_add(DNSZoneBase_add): >> __doc__ = _('Create new DNS zone (SOA record).') >> >> takes_options = DNSZoneBase_add.takes_options + ( >> - Flag('force', >> - label=_('Force'), >> - doc=_('Force DNS zone creation even if nameserver is not resolvable.'), >> + Flag('skip_nameserver_check', >> + doc=_('Force DNS zone creation even if nameserver is not ' >> + 'resolvable.') >> ), >> >> # Deprecated >> @@ -2699,6 +2719,9 @@ class dnszone_add(DNSZoneBase_add): >> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): >> assert isinstance(dn, DN) >> >> + if options['force']: >> + options['skip_nameserver_check'] = True > Why is it in DNSZoneBase_add.pre_callback? > > Shouldn't the equation force = (skip_nameserver_check + skip_nameserver_check) > be handled in parameter parsing & validation? (Again, I do not know the IPA > framework :-)) > >> + >> dn = super(dnszone_add, self).pre_callback( >> ldap, dn, entry_attrs, attrs_list, *keys, **options) >> >> @@ -2713,7 +2736,7 @@ class dnszone_add(DNSZoneBase_add): >> error=_("Nameserver for reverse zone cannot be a relative DNS name")) >> >> # verify if user specified server is resolvable >> - if not options['force']: >> + if not options['skip_nameserver_check']: >> check_ns_rec_resolvable(keys[0], entry_attrs['idnssoamname']) >> # show warning about --name-server option >> context.show_warning_nameserver_option = True >> diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py >> index d959bb369d946217acd080e78483cc9013dda4c7..18f477d4fb6620090b7073689c8df51b65a8307a 100644 >> --- a/ipapython/ipautil.py >> +++ b/ipapython/ipautil.py >> @@ -924,6 +924,20 @@ def host_exists(host): >> else: >> return True >> >> +def check_zone_overlap(zone): >> + if resolver.zone_for_name(zone) == zone: >> + try: >> + ns = [ans.to_text() for ans in resolver.query(zone, 'NS')] >> + except DNSException as e: >> + root_logger.debug("Failed to resolve nameserver(s) for domain" >> + " {0}: {1}".format(zone, e)) >> + ns = [] >> + >> + msg = u"DNS zone {0} already exists".format(zone) > Nitpick: I would say "already exists in DNS" to make it absolutely clear. Just > 'already exists' might be confusing because ipa dnszone-show will say that the > zone does not exist ... > >> + if ns: >> + msg += u" and is handled by server(s): {0}".format(', '.join(ns)) >> + raise RuntimeError(msg) >> + >> def get_ipa_basedn(conn): >> """ >> Get base DN of IPA suffix in given LDAP server. 0064 NACK ipa-replica-install should have the --skip-overlap-check too, because any replica can be the first DNS server. 0064+0058 Can be the options --allow-zone-overlap and --skip-overlap-check merged into an one name, to have just one name for same thing? From mbasti at redhat.com Fri Aug 28 14:13:19 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 28 Aug 2015 16:13:19 +0200 Subject: [Freeipa-devel] [PATCH] First part of integration tests for Topology Plugin In-Reply-To: <55DF46FF.4070502@redhat.com> References: <55C842B7.6030503@redhat.com> <55C855A6.5050004@redhat.com> <55C8857E.7070802@redhat.com> <55C8DAA8.70702@redhat.com> <55C9DBBA.1090805@redhat.com> <55C9E466.4060503@redhat.com> <55C9FA64.1030307@redhat.com> <55CCB279.9010200@redhat.com> <55CDAA66.4040808@redhat.com> <55D429A1.3000605@redhat.com> <55D4900C.5040509@redhat.com> <55D58F41.3020400@redhat.com> <55D59B6B.8000606@redhat.com> <55DD8A6A.4060506@redhat.com> <55DD8BDF.6050202@redhat.com> <55DDB6BA.7060102@redhat.com> <55DDDE55.7010903@redhat.com> <55DDE10A.8030704@redhat.com> <55DF2F8C.6080106@redhat.com> <55DF3A7A.10503@redhat.com> <55DF46FF.4070502@redhat.com> Message-ID: <55E06C7F.109@redhat.com> On 08/27/2015 07:21 PM, Oleg Fayans wrote: > Hi Martin, > > My bad, forgot to do git add. > > > On 08/27/2015 06:27 PM, Martin Basti wrote: >> >> >> On 08/27/2015 05:41 PM, Oleg Fayans wrote: >>> Hi, >>> >>> I am sorry I have missed that. >>> Fixed. The test fails now due to this bug: >>> >>> https://fedorahosted.org/freeipa/ticket/5222 >>> >>> The test output is attached together with the updated patch >>> >>> On 08/26/2015 05:53 PM, Martin Basti wrote: >>>> >>>> >>>> On 08/26/2015 05:42 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08/26/2015 02:53 PM, Oleg Fayans wrote: >>>>>> Hi, >>>>>> >>>>>> No more short links :) >>>>>> >>>>>> On 08/26/2015 11:50 AM, Tomas Babej wrote: >>>>>>> >>>>>>> >>>>>>> On 08/26/2015 11:44 AM, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> On 08/20/2015 11:18 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/20/2015 10:26 AM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/19/2015 04:17 PM, Martin Basti wrote: >>>>>>>>>>> I got this: >>>>>>>>>>> >>>>>>>>>>> https://paste.fedoraproject.org/256746/43999380/ >>>>>>>>>> FYI replica install failure. (I will retest it, but I'm pretty >>>>>>>>>> sure >>>>>>>>>> that it was clean VM, test for some reason install client first) >>>>>>>>>> >>>>>>>>>> File >>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> line 295, in decorated >>>>>>>>>> func(installer) >>>>>>>>>> File >>>>>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> line 319, in install_check >>>>>>>>>> sys.exit("IPA client is already configured on this >>>>>>>>>> system.\n" >>>>>>>>>> >>>>>>>>>> 2015-08-19T14:14:15Z DEBUG The ipa-replica-install command >>>>>>>>>> failed, >>>>>>>>>> exception: SystemExit: IPA client is already configured on this >>>>>>>>>> system. >>>>>>>>>> Please uninstall it first before configuring the replica, using >>>>>>>>>> 'ipa-client-install --uninstall'. >>>>>>>>>> 2015-08-19T14:14:15Z ERROR IPA client is already configured on >>>>>>>>>> this >>>>>>>>>> system. >>>>>>>>>> Please uninstall it first before configuring the replica, using >>>>>>>>>> 'ipa-client-install --uninstall'. >>>>>>>>> Confirm I got same error. >>>>>>>> Fixed. It was a regex error. >>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/19/2015 09:00 AM, Oleg Fayans wrote: >>>>>>>>>>>> Hi Martin, >>>>>>>>>>>> >>>>>>>>>>>> As discussed, here is a new version with pep8-related fixes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/14/2015 10:44 AM, Oleg Fayans wrote: >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> Already noticed that. Implemented the named groups as Tomas >>>>>>>>>>>>> advised. >>>>>>>>>>>>> Added the third test for >>>>>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/Test_plan#Test_case:_Removal_of_a_topology_segment_is_allowed_only_if_there_is_at_least_one_more_segment_connecting_the_given_replica >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/13/2015 05:06 PM, Martin Basti wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/11/2015 03:36 PM, Oleg Fayans wrote: >>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08/11/2015 02:02 PM, Martin Basti wrote: >>>>>>>>>>>>>>>> NACK, comments inline. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/08/15 13:25, Oleg Fayans wrote: >>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for the review! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 08/10/2015 07:08 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>> Thank you for patch, I have a few nitpicks: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>> On 10/08/15 13:05, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>>>>> Why do you add the name of method in docstring? >>>>>>>>>>>>>>>>> My bad, fixed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> still there >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + tokenize_topologies(command_output) >>>>>>>>>>>>>>>> + takes an output of `ipa topologysegment-find` and >>>>>>>>>>>>>>>> returns an >>>>>>>>>>>>>>>> array of >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fixed, sorry. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> +def create_segment(master, leftnode, rightnode): >>>>>>>>>>>>>>>>>> + """create_segment(master, leftnode, rightnode) >>>>>>>>>>>>>>>>>> + creates a topology segment. The first argument is a >>>>>>>>>>>>>>>>>> node to >>>>>>>>>>>>>>>>>> run the >>>>>>>>>>>>>>>>>> command on >>>>>>>>>>>>>>>>>> + The first 3 arguments should be objects of class >>>>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>>>> + Returns a hash object containing segment's name, >>>>>>>>>>>>>>>>>> leftnode, >>>>>>>>>>>>>>>>>> rightnode information >>>>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I would prefer to add assert there instead of just >>>>>>>>>>>>>>>>>> document >>>>>>>>>>>>>>>>>> that a >>>>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>>>> object is needed >>>>>>>>>>>>>>>>>> assert(isinstance(master, Host)) >>>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fixed. Created a decorator that checks the type of >>>>>>>>>>>>>>>>> arguments >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This does not scale well. >>>>>>>>>>>>>>>> If we will want to add new argument that is not host >>>>>>>>>>>>>>>> object, you >>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>> change it again. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Agreed. Modified the decorator so that you can specify a >>>>>>>>>>>>>>> slice of >>>>>>>>>>>>>>> arguments to be checked and a class to compare to. This >>>>>>>>>>>>>>> does >>>>>>>>>>>>>>> scale :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This might be used as function with specified variables >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> have to be >>>>>>>>>>>>>>>> host objects >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>>>> + destroy_segment(master, segment_name) >>>>>>>>>>>>>>>>>> + Destroys topology segment. First argument should be >>>>>>>>>>>>>>>>>> object of >>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Instead of description of params as first, second etc., >>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>> may use >>>>>>>>>>>>>>>>>> following: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> +def destroy_segment(master, segment_name): >>>>>>>>>>>>>>>>>> + """ >>>>>>>>>>>>>>>>>> + Destroys topology segment. >>>>>>>>>>>>>>>>>> + :param master: reference to master object of class >>>>>>>>>>>>>>>>>> Host >>>>>>>>>>>>>>>>>> + :param segment: name fo segment >>>>>>>>>>>>>>>>>> and eventually this in other methods >>>>>>>>>>>>>>>>>> + :returns: Lorem ipsum sit dolor mit amet >>>>>>>>>>>>>>>>>> + :raises NotFound: if segment is not found >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> cls.replicas[:len(cls.replicas) - 1], >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I suggest cls.replicas[:-1] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In [2]: a = [1, 2, 3, 4, 5] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In [3]: a[:-1] >>>>>>>>>>>>>>>>>> Out[3]: [1, 2, 3, 4] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fixed >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>>> Why re.findall() and then you just use the first result? >>>>>>>>>>>>>>>>>> 'leftnode': self.leftnode_re.findall(i)[0] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Isn't just re.search() enough? >>>>>>>>>>>>>>>>>> leftnode_re.search(value).group(1) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> in fact >>>>>>>>>>>>>>>>> leftnode_re.findall(string)[0] >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> leftnode_re.search(string).group(1), >>>>>>>>>>>>>>>>> Are equally bad from the readability point of view. The >>>>>>>>>>>>>>>>> first >>>>>>>>>>>>>>>>> one is >>>>>>>>>>>>>>>>> even shorter a bit, so why change? :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It depends on point of view, because when I reviewed it >>>>>>>>>>>>>>>> yesterday my >>>>>>>>>>>>>>>> brain raises exception that you are trying to add multiple >>>>>>>>>>>>>>>> values to >>>>>>>>>>>>>>>> single value attribute, because you used findall, I >>>>>>>>>>>>>>>> expected >>>>>>>>>>>>>>>> that you >>>>>>>>>>>>>>>> need multiple values, and then I saw that index [0] at the >>>>>>>>>>>>>>>> end, >>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>> was pretty confused what are you trying to achieve. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And because findall is not effective in case when you >>>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>>> find just >>>>>>>>>>>>>>>> one occurrence. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I got it. Fixed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Python 3 nitpick: >>>>>>>>>>>>>>>>>> I'm not sure if time when we should enforce python 2/3 >>>>>>>>>>>>>>>>>> compability >>>>>>>>>>>>>>>>>> already comes, but just for record: >>>>>>>>>>>>>>>>>> instead of open(file, 'r'), please use io.open(file, >>>>>>>>>>>>>>>>>> 'r') >>>>>>>>>>>>>>>>>> (import io >>>>>>>>>>>>>>>>>> before) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +# >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> empty comment here (several times) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Removed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> NACK >>>>>>>>>>>>>> >>>>>>>>>>>>>> you changed it wrong >>>>>>>>>>>>>> >>>>>>>>>>>>>> group() returns everything, you need use group(1) to return >>>>>>>>>>>>>> content in >>>>>>>>>>>>>> braces. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Please, do not use third-party URL shorteners from within our >>>>>>> source >>>>>>> code. >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>> >>>>> >>>>> I received 2 errors >>>>> >>>>> ___________________________________________________________________________________ >>>>> >>>>> >>>>> TestTopologyOptions.test_add_remove_segment >>>>> ___________________________________________________________________________________ >>>>> >>>>> >>>>> >>>>> >>>>> self = >>>> object at 0x7f6ab95b3110> >>>>> >>>>> def test_add_remove_segment(self): >>>>> """ >>>>> Make sure a topology segment can be manually created and >>>>> deleted >>>>> with the influence on the real topology >>>>> Testcase >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology/ >>>>> Test_plan#Test_case:_Basic_CRUD_test >>>>> """ >>>>> tasks.kinit_admin(self.master) >>>>> # Install the second replica >>>>> tasks.install_replica(self.master, self.replicas[1], >>>>> setup_ca=False, >>>>> setup_dns=False) >>>>> # turn a star into a ring >>>>> segment, err = tasks.create_segment(self.master, >>>>> self.replicas[0], >>>>> > self.replicas[1]) >>>>> E TypeError: 'NoneType' object is not iterable >>>>> >>>>> test_integration/test_topology.py:102: TypeError >>>>> >>>>> Maybe tasks.create_segment returns None? >>>>> In [3]: a, b = None >>>>> --------------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> TypeError Traceback (most recent call >>>>> last) >>>>> in () >>>>> ----> 1 a, b = None >>>>> >>>>> TypeError: 'NoneType' object is not iterable >>>>> >>>>> >>>>> -------------- >>>>> >>>>> self = >>>> 0x7f399b9ea710>, raiseonerr = True >>>>> >>>>> def wait(self, raiseonerr=True): >>>>> """Wait for the remote process to exit >>>>> >>>>> Raises an excption if the exit code is not 0, unless >>>>> raiseonerr is >>>>> true. >>>>> """ >>>>> if self._done: >>>>> return self.returncode >>>>> >>>>> self._end_process() >>>>> >>>>> self._done = True >>>>> >>>>> if raiseonerr and self.returncode: >>>>> self.log.error('Exit code: %s', self.returncode) >>>>> > raise subprocess.CalledProcessError(self.returncode, >>>>> self.argv) >>>>> E CalledProcessError: Command '['ipa', >>>>> 'topologysegment-del', 'realm', >>>>> 'vm-152.abc.idm.lab.eng.brq.redhat.com-to-vm-160.abc.idm.lab.eng.brq.redhat.com']' >>>>> >>>>> >>>>> returned non-zero exit status 2 >>>>> >>>> Honza found where the problem is. >>>> >>>> def check_arguments_are(slice, instanceof): >>>> ... >>>> def wrapper(func): >>>> def wrapped(*args): >>>> for i in args[slice[0]:slice[1]]: >>>> assert isinstance(i, instanceof), "Wrong type: %s: >>>> %s" >>>> % (i, type(i)) >>>> func(*args) >>>> return wrapped >>>> return wrapper >>>> >>>> there should be >>>> return func(*args) >>>> >>>> otherwise None will be always returned >>>> >>> >> It looks nice, but I miss the integration test in the patch. > ACK Pushed to master: c7408f67f6cff7bd3ac14b7661472898f8e7dd73 From pspacek at redhat.com Mon Aug 31 07:35:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 31 Aug 2015 09:35:52 +0200 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55DE00D1.9050805@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> Message-ID: <55E403D8.9030505@redhat.com> On 26.8.2015 20:09, Rich Megginson wrote: > On 08/25/2015 09:08 AM, Petr Spacek wrote: >> On 8.7.2015 19:56, Rich Megginson wrote: >>> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>>> Assuming that Designate wants to own DNS and be Primary Master, it would be >>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>>> alongside their own JSON API. >>>> >>>> The JSON API is superset of DNS UPDATE protocol because it allows to add >>>> zones >>>> but still, standard protocol would mean that standard client (possibly guest >>>> OS inside VM) can update its records without any OpenStack dependency, which >>>> is very much desirable. >>>> >>>> The use case here is to allow the guest OS to publish it's SSH key (which was >>>> generated inside the VM after first boot) to prevent Man in the middle >>>> attacks. > > I'm working on a different approach for guest OS registration. This involves > a Nova hook/plugin: > * build_instance pre-hook to generate an OTP and call ipa host-add with the > OTP - add OTP to new host metadata - add ipa-client-registration script to new > host cloud-init > * new instance calls script - will wait for OTP to become available in > metadata, then call ipa-client-install with OTP > * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with new IP BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. ipa-client-install is using DNS UPDATE today. > https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova > >>>> The same goes for all other sorts of DANE/DNSSEC data or service >>>> discovery using DNS, where a guest/container running a distributed service >>>> can >>>> publish it's existence in DNS. >>>> >>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>>> widely supported, too. >>>> >>>> So DNS UPDATE is my biggest wish :-) >>>> >>> Ok. There was a Designate blueprint for such a feature, but I can't find it >>> and neither can the Designate guys. There is a mention of nsupdate in the >>> minidns blueprint, but that's about it. The fact that Designate upstream >>> can't find the bp suggests that this is not a high priority for them and will >>> not likely implement it on their own i.e. we would have to contribute this >>> feature. >>> >>> If Designate had such a feature, how would this help us integrate FreeIPA with >>> Designate? >> It would greatly simplify integration with FreeIPA. There is a plan to support >> DNS updates as described in RFC 2136 to push updates from FreeIPA servers to >> external DNS servers, so we could use the same code to integrate with AD & >> Designate at the same time. >> >> (I'm sorry for the delay, it somehow slipped through the cracks.) >> > > For Designate for our use cases, we want IPA to be the authoritative source of > DNS data. Why? In my eyes it is additional complexity for no obvious benefit. DNS is built around assumption that there is only one authoritative source of data and as far as I can tell all attempts to bend this assumption did not end well. In my eyes IPA should have ability to integrate with whatever DNS server admin wants to use, using standard protocols. What is the benefit of the other approach? Petr^2 Spacek > When a client wants to read data from Designate, that data should somehow come > from IPA. I don't think Designate has any sort of proxy or pass-through > feature, so the data would have be sync'd from IPA. If IPA supports being a > server for AXFR/IXFR, Designate could be changed to support AXFR/IXFR client > side, then would just be a slave of IPA. If IPA does not support zone > transfers, then we would need some sort of initial sync of data from IPA to > Designate (I wrote such a script for Designate > (https://github.com/openstack/designate/blob/master/contrib/ipaextractor.py). > Then, perhaps some sort of proxy/service that would poll for changes > (syncrepl?) in IPA, then submit those changes to Designate (using Designate > REST API, or DNS UPDATE when Designate mDNS supports it). > > When a client wants to update data in Designate, we need to somehow get that > data into IPA. The only way Designate pushes data out currently is via AXFR, > which doesn't work for IPA to be a direct slave of Designate. What might work > is to have an "agent" that gets the AXFR, then somehow converts that into IPA > updates. This would only work if the volume of updates is fairly low. If > Designate supported IXFR it would be much better. From mbasti at redhat.com Mon Aug 31 08:51:42 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 31 Aug 2015 10:51:42 +0200 Subject: [Freeipa-devel] [PATCH 0291, 0292] Limit max age of replication changelog In-Reply-To: <55BB30D9.7010004@redhat.com> References: <55AD0976.4070402@redhat.com> <55AD129D.8020608@redhat.com> <55AD1857.8090209@redhat.com> <55AD26EB.5030303@redhat.com> <55AD2A09.9070101@redhat.com> <55AFB0CE.3020508@redhat.com> <55BA2321.4070201@redhat.com> <55BA2A05.2050900@redhat.com> <55BB30D9.7010004@redhat.com> Message-ID: <55E4159E.3040900@redhat.com> On 07/31/2015 10:24 AM, Martin Basti wrote: > On 30/07/15 15:43, Ludwig Krispenz wrote: >> >> On 07/30/2015 03:14 PM, Martin Basti wrote: >>> On 22/07/15 17:03, Martin Basti wrote: >>>> On 20/07/15 19:04, Mark Reynolds wrote: >>>>> >>>>> >>>>> On 07/20/2015 12:50 PM, Martin Basti wrote: >>>>>> On 20/07/15 17:48, Petr Vobornik wrote: >>>>>>> On 07/20/2015 05:24 PM, Rob Crittenden wrote: >>>>>>>> Martin Basti wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5086 >>>>>>>>> >>>>>>>>> Patch attached. >>>>>>>> >>>>>>>> Is this going to be a shock on upgrades for people who until >>>>>>>> now may be >>>>>>>> relying on the fact that there is no limit? >>>>>>> >>>>>>> Not making any point, but have to note: Ludwig raised a question >>>>>>> on users list but there was no feedback from users. >>>>>>> >>>>>>> https://www.redhat.com/archives/freeipa-users/2015-July/msg00022.html >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Should there be a way for an admin to manage this, via the >>>>>>>> config module >>>>>>>> perhaps? >>>>>>>> >>>>>>>> IMHO this is a significant change and red flags need to be >>>>>>>> raised so >>>>>>>> users are aware of it. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> IIUC there is purge delay 7 days, so if changelog max age is 7 or >>>>>> more days, it will not break replication. >>>>>> The issue is if somebody uses changelog for different purpose, >>>>>> right? >>>>> Well the replication changelog can not be used for anything else >>>>> but the multimaster replication plugin. If a customer increased >>>>> the replication purge delay you could potentially run into issues, >>>>> but again this only comes into play when a replica is down for a >>>>> very long time. I'm not sure if IPA even provides the option to >>>>> adjust the replication purge delay, but that doesn't mean a >>>>> customer can not adjust these settings on their own. >>>>> >>>>> Mark >>>>> >>>> >>>> I'm attaching new patch, that modifies behavior of 'addifnew' >>>> keyword in update files. >>>> addifnew will no create new entry if doesn't exist. >>>> This is required for proper working of patch 292 >>>> >>>> Rob are you okay with these patches, as Mark wrote, changelog is >>>> used only for replication plugins, so it should not cause any >>>> issues to users. >>>> >>>> Martin^2 >>>> >>>> >>>> >>> >>> These patches are ready to be reviewed. >>> I'm just not sure if would be better to have replication changelog >>> max age 8days, just to be sure. >>> Should I explicitly set purge delay to 7days, or are we fine with >>> 7days as default? >> I think 7d is a quite common setting, so it should be ok > 7 days for changelog max age, or for purge delay, or for both? > Should I explicitly set purge delay then? > > I'm thinking about the case when admin changed purge delay before > upgrade, IMO I should check this value and set same value for > changelog max age or don't upgrade changelog. > > I changed my mind, I don't think that is worth it to do this check, because user can change it anyway and break replication. Maybe, if it is easy to implement, there might be startup check in DS to print warning if changelog max age and purge delay contain not compatible values. If there is no objections, this patch can be reviewed. > > Martin^2 >>> -- >>> Martin Basti >>> >>> >> >> >> > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Aug 31 10:24:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 31 Aug 2015 12:24:13 +0200 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55D33BF2.2060307@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> Message-ID: <55E42B4D.7090004@redhat.com> On 08/18/2015 04:06 PM, Milan Kub?k wrote: > On 08/11/2015 03:17 AM, Fraser Tweedale wrote: >> On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: >>> On 08/05/2015 02:57 PM, Milan Kub?k wrote: >>>> Hi list, >>>> >>>> I'm sending the test plan [1] for certificate profiles and preliminary >>>> patches for it. >>>> The plan covers basic CRUD test and some corner cases. I'm open to >>>> more >>>> suggestions. >>>> >>>> More complicated tests involving certificate profiles will require the >>>> code (and tests) >>>> for CA ACLs merged, so it's not there at the moment. >>>> >>>> There are some unfinished test cases in places I wasn't sure what the >>>> result should be. >>>> We need to iterate through these to fix it. >>>> >>>> >>>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan >>>> >>>> Cheers, >>>> Milan >>> Hi all, >>> >>> have you had some time to look at the code and proposal? >>> Today I want to write a basic CRUD test for the ACLs as well as a >>> few test >>> cases to check if the ACL is being enforced. It should make it into >>> wiki >>> today or by tomorrow. I'll send an update then. >>> >>> Cheers, >>> Milan >>> >> Hi Milan, >> >> I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of >> comments: >> >> - Test case: Import profile with incorrect values >> - Expected result: refused with error. >> - A simple way to provoke this condition is to add a number to >> ``policyset.serverCertSet.list``. >> - A similar test case should exist for certprofile-mod. >> >> - Test case: Delete default profile >> - As discussed elsewhere, expected result should be failure. >> I filed ticket #5198 to make it so :) >> >> I will review the patch soon. >> >> Cheers, >> Fraser > Hello, > > how is the review going? I'd like to have at least the tracker (patch > 0008) > reviewed (and merged :) if possible. It will be needed in CA ACL tests. > > Cheers, > Milan > Fraser, do you review this patchset? From dkupka at redhat.com Mon Aug 31 10:51:58 2015 From: dkupka at redhat.com (David Kupka) Date: Mon, 31 Aug 2015 12:51:58 +0200 Subject: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi In-Reply-To: <55DD6DC9.7060301@redhat.com> References: <55D5EE0C.5060302@redhat.com> <55D72D15.3010901@redhat.com> <55DA3ACF.9010504@redhat.com> <55DB12F9.30209@redhat.com> <55DB35C6.4000503@redhat.com> <1440431368.3305.19.camel@willson.usersys.redhat.com> <55DB44FA.2030402@redhat.com> <55DC421D.8000908@redhat.com> <20150825103850.GS22106@redhat.com> <55DC4796.9020303@redhat.com> <55DC5702.5030506@redhat.com> <55DCB7C7.5010403@redhat.com> <1440529242.8138.53.camel@willson.usersys.redhat.com> <55DD6DC9.7060301@redhat.com> Message-ID: <55E431CE.2070302@redhat.com> On 26/08/15 09:42, Jan Cholasta wrote: > On 25.8.2015 21:00, Simo Sorce wrote: >> On Tue, 2015-08-25 at 20:45 +0200, Michael ?im??ek wrote: >>> >>> On 2015-08-25 18:43, Robbie Harwood wrote: >>>> Jan Cholasta writes: >>>> >>>>> On 25.8.2015 12:46, Michael ?im??ek wrote: >>>>>> On 2015-08-25 12:38, Alexander Bokovoy wrote: >>>>>>> On Tue, 25 Aug 2015, Michael ?im??ek wrote: >>>>>>>> On 2015-08-24 20:29, Robbie Harwood wrote: >>>>>>>>> Michael ?im??ek writes: >>>>>>>>>> On 2015-08-24 17:49, Simo Sorce wrote: >>>>>>>>>>> On Mon, 2015-08-24 at 17:18 +0200, Michael ?im??ek wrote: >>>>>>>>>>>> On 2015-08-24 14:50, Jan Cholasta wrote: >>>>>>>>>>>> >>>>>>>>>>>> Fixed. python-gssapi has a display_as method that could pull >>>>>>>>>>>> the >>>>>>>>>>>> name >>>>>>>>>>>> from it, but it doesn't work in current version, therefore >>>>>>>>>>>> using >>>>>>>>>>>> partition to split on '@' >>>>>>>>> >>>>>>>>> It's actually a bug in MIT Krb5, as we noted in your bug[0]. >>>>>>>>> So this: >>>>>>>>> >>>>>>>>>> - user = >>>>>>>>>> api.Command.user_show(unicode(principal[0]))['result'] >>>>>>>>>> + user = >>>>>>>>>> api.Command.user_show(principal.partition('@')[0])['result'] >>>>>>>>> >>>>>>>>> is working around a bug in specific Kerberos versions. If >>>>>>>>> people are >>>>>>>>> okay with merging such code, then I guess this is fine; I would >>>>>>>>> personally not do so because there is not a clear point at >>>>>>>>> which it can >>>>>>>>> be removed. At the very least, we should wait until we see what >>>>>>>>> versions of krb5 MIT is going to fix. >>>>>>>>> >>>>>>>>> Otherwise, looks good. >>>>>>>>> >>>>>>>>> [0]: https://github.com/pythongssapi/python-gssapi/issues/79 >>>>>>>>> >>>>>>>> >>>>>>>> python-krbV migration is blocking support for Python 3. The bug >>>>>>>> doesn't have any fix upstream yet and there are two bugs >>>>>>>> actually, the >>>>>>>> second one is in python-gssapi, which I've just reported [1]. >>>>>>>> Waiting >>>>>>>> for two bugs to be fixed could be detrimental to py3 migration >>>>>>>> as we >>>>>>>> don't have much time left. And I'm no longer sure that display_as >>>>>>> >>>>>>> I don't buy this. >>>>>>> >>>>>>> We have plenty of time for solving these bugs. Remember, that Samba >>>>>>> DCE RPC bindings aren't migrated to Python 3 either and will not be >>>>>>> before release of Samba 4.4. For Samba 4.3 it is simply too late. >>>>>>> >>>>>>> So we are still far away from full Python3 migration for FreeIPA and >>>>>>> waiting for solving these two bugs is OK. >>>>>> >>>>>> If fixing them solves anything at all. I planned to use >>>>>> display_as(NameType.user), but when trying it on Name object with >>>>>> name_type set (which doesn't trigger the segfault), it doesn't >>>>>> seem to >>>>>> work either. I get: >>>>>> gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The >>>>>> operation or option is not available or unsupported, Minor (0): >>>>>> Unknown >>>>>> error >>>>>> >>>>>> Robbie, can you clarify whether display_as could be actually used >>>>>> to get >>>>>> the first component of the principal reliably? >>>> >>>> display_as should behave in accordance with its docs; anything else >>>> is a >>>> bug report, which you filed. I don't know what you're asking me for >>>> beyond that. >>>> >>> >>> Why I mentioned display_as at all is that I initially assumed it could >>> be used for this, but it was only an assumption because I couldn't get >>> around the segfault. Later on, the cause of the segfault was found and I >>> was able to try the method and I found out that it probably cannot be >>> used for this purpose (i. e. extracting the first component of the >>> principal) regardless of the two bugs. How I thought it would be used: >>> import gssapi >>> cred = gssapi.Credentials() >>> user = cred.name.display_as(gssapi.NameType.user) >>> >>> What I got: >>> gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The >>> operation or option is not available or unsupported, Minor (0): Unknown >>> error >>> >>> This seems more like the method is not intended to be used this way. So >>> I'm asking you whether it is a bug or whether there is another way to do >>> it. Otherwise display_as cannot be used here. >>> >>>>> As I have written in the other thread, we use >>>>> "principal.split('@')" in >>>>> other parts of IPA, so "principal.partition('@')" should be OK as >>>>> well. >>>>> >>>>> This patch works for me, so ACK. >>>>> >>>>> Unless there are any further objections, I would like to push it. >>>> >>>> I think the newest iteration of this >>>> >>>>> user = >>>>> api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result'] >>>>> >>>> >>>> is even worse, but if it is decided to merge, then hopefully we can be >>>> rid of it quickly. >>> >>> It is splitting a string of known format in a way that is used in other >>> places of freeipa. What is specifically so bad about it? What do you >>> suggest as an alternative? >> >> Given display_as() currently does not work for you go ahead with this >> code. We'll revisit display_as later once we figure out more about the >> bug that makes it fail. > > OK. > > Pushed to master: aad73fad601f576dd83b758f4448839b4e8e87df > I think this patch is causing tracebacks when expired or missing kerberos ticket (https://fedorahosted.org/freeipa/ticket/5272). -- David Kupka From mbasti at redhat.com Mon Aug 31 11:18:24 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 31 Aug 2015 13:18:24 +0200 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55DF67EF.6020905@redhat.com> References: <55DF67EF.6020905@redhat.com> Message-ID: <55E43800.20903@redhat.com> On 08/27/2015 09:41 PM, Endi Sukma Dewata wrote: > The CA and KRA installation code has been modified to use LDAPI > to create the CA and KRA agents directly in the CA and KRA > database. This way it's no longer necessary to use the Directory > Manager password or CA and KRA admin certificate. > > https://fedorahosted.org/freeipa/ticket/5257 > > > Thank you. 1) Can you use following code instead of direct call of ldap2.ldap2()? if not api.Backend.ldap2.is_connected(): api.Backend.ldap2.connect(autobind=True) conn = api.Backend.ldap2 2) Patch needs rebase to master branch. 3) + user_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) + conn.create( + dn=user_dn, can you use add entry() instead of create()? We don't use native python-ldap, but rather ipaldap methods -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Aug 31 11:29:33 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 31 Aug 2015 13:29:33 +0200 Subject: [Freeipa-devel] [PATCH] 1115 Use %license tag in spec file In-Reply-To: <55D1EDAC.2090609@redhat.com> References: <55D1EDAC.2090609@redhat.com> Message-ID: <55E43A9D.1040704@redhat.com> On 08/17/2015 04:20 PM, Rob Crittenden wrote: > Use %license instead of %doc in spec file to ship the license. > > rob > > ACK Pushed to: master: 7ed51586ca8ccaafab6bb11bb5161dc25800fddf ipa-4-2: 30cfae7823d1a77438bab94726139f9764456a88 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon Aug 31 12:45:53 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 31 Aug 2015 14:45:53 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1440624432.8138.130.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> Message-ID: <55E44C81.6010306@redhat.com> On 08/26/2015 11:27 PM, Simo Sorce wrote: > This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > and introduces a number of required changes and dependencies to achieve > this goal. > This work requires the custodia project to securely transfer keys > between ipa servers. > > This work is not 100% complete, it still misses the ability to install > kra instances and the ability to install a CA (via ipa-ca-install) with > externally signed certs. > > However it is massive enough that warrants review and pushing, the resat > of the changes can be applied later as this work should not disrupt the > classic install methods. > > In order to build my previous patches (530-533) are needed as well as a > number of updated components. > > I used the following coprs for testing: > simo/jwcrypto > simo/custodia > abbra/sssd-kkdcproxy (for sssd 1.13.1) > lkrispen/389-ds-current (for 389 > 1.3.4.4) > vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > mkosek/freeipa-4.2-fedora-22 (misc) > fedora/updates-testing (python-gssapi 1.1.2) > > Ludwig's copr is necessary to have a functional DNA plugin in replicas, > eventually his patches should be committed in 389-ds-base 1.3.4.4 when > it will be released. > > We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > that may cause installation issues in some case (re-install of a > replica). > > The domain must be raised to level 1 in order to use replica promotion. > > In order to promote a replica the server must be first joined as a > regular client to the domain. > > This is the flow I usually use for testing: > > # ipa-client-install > # kinit admin > # ipa-replica-install --promote --setup-ca > etc...> > > These patches are also available in this git tree rebnase on current > master: > https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > Simo. > > > I'm running in a issue when upgrading RPMs: 2015-08-31T10:53:32Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 48, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1596, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1508, in upgrade_configuration custodia.upgrade_instance() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 57, in upgrade_instance self.__gen_keys() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 51, in __gen_keys KeyStore.generate_server_keys() File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in generate_server_keys ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in set_key conn.modify_s(dn, mods) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 364, in modify_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 465, in result resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469, in result2 resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in _ldap_call result = func(*args,**kwargs) 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, exception: NO_SUCH_OBJECT: {'desc': 'No such object'} 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT No such object From mbasti at redhat.com Mon Aug 31 12:52:21 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 31 Aug 2015 14:52:21 +0200 Subject: [Freeipa-devel] [PATCH 0302] DNSSEC: remove "DNSSEC is experimental" warnings Message-ID: <55E44E05.8080603@redhat.com> https://fedorahosted.org/freeipa/ticket/5265 Patch attached. Should I remove also message class "DNSSECWarning" which is not used now, or just keep it there because ti has already registered error code? Martin^2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0302-DNSSEC-remove-DNSSEC-is-experimental-warnings.patch Type: text/x-patch Size: 3320 bytes Desc: not available URL: From simo at redhat.com Mon Aug 31 12:56:43 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 31 Aug 2015 08:56:43 -0400 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <55E44C81.6010306@redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> Message-ID: <1441025803.28131.48.camel@willson.usersys.redhat.com> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: > > On 08/26/2015 11:27 PM, Simo Sorce wrote: > > This patchset implements https://fedorahosted.org/freeipa/ticket/2888 > > and introduces a number of required changes and dependencies to achieve > > this goal. > > This work requires the custodia project to securely transfer keys > > between ipa servers. > > > > This work is not 100% complete, it still misses the ability to install > > kra instances and the ability to install a CA (via ipa-ca-install) with > > externally signed certs. > > > > However it is massive enough that warrants review and pushing, the resat > > of the changes can be applied later as this work should not disrupt the > > classic install methods. > > > > In order to build my previous patches (530-533) are needed as well as a > > number of updated components. > > > > I used the following coprs for testing: > > simo/jwcrypto > > simo/custodia > > abbra/sssd-kkdcproxy (for sssd 1.13.1) > > lkrispen/389-ds-current (for 389 > 1.3.4.4) > > vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) > > mkosek/freeipa-4.2-fedora-22 (misc) > > fedora/updates-testing (python-gssapi 1.1.2) > > > > Ludwig's copr is necessary to have a functional DNA plugin in replicas, > > eventually his patches should be committed in 389-ds-base 1.3.4.4 when > > it will be released. > > > > We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 > > that may cause installation issues in some case (re-install of a > > replica). > > > > The domain must be raised to level 1 in order to use replica promotion. > > > > In order to promote a replica the server must be first joined as a > > regular client to the domain. > > > > This is the flow I usually use for testing: > > > > # ipa-client-install > > # kinit admin > > # ipa-replica-install --promote --setup-ca > > > etc...> > > > > These patches are also available in this git tree rebnase on current > > master: > > https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review > > > > Simo. > > > > > > > > I'm running in a issue when upgrading RPMs: What version are you upgrading from ? Also do you have logs telling which update is failing ? I can guess it is the topology stuff but that would be surprising. Simo. > 2015-08-31T10:53:32Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > line 48, in run > server.upgrade() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1596, in upgrade > upgrade_configuration() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1508, in upgrade_configuration > custodia.upgrade_instance() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > 57, in upgrade_instance > self.__gen_keys() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line > 51, in __gen_keys > KeyStore.generate_server_keys() > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in > generate_server_keys > ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in > set_key > conn.modify_s(dn, mods) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 364, in modify_s > return self.result(msgid,all=1,timeout=self.timeout) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 465, in result > resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 469, in result2 > resp_type, resp_data, resp_msgid, resp_ctrls = > self.result3(msgid,all,timeout) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 476, in result3 > resp_ctrl_classes=resp_ctrl_classes > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 483, in result4 > ldap_result = > self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line > 106, in _ldap_call > result = func(*args,**kwargs) > > 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed, > exception: NO_SUCH_OBJECT: {'desc': 'No such object'} > 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT > No such object -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Mon Aug 31 13:25:24 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 31 Aug 2015 23:25:24 +1000 Subject: [Freeipa-devel] cert profiles - test plan + patches In-Reply-To: <55E42B4D.7090004@redhat.com> References: <55C2082C.6090907@redhat.com> <55C8709F.7030500@redhat.com> <20150811011719.GB16439@dhcp-40-8.bne.redhat.com> <55D33BF2.2060307@redhat.com> <55E42B4D.7090004@redhat.com> Message-ID: <20150831132524.GE5879@dhcp-40-8.bne.redhat.com> On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote: > > > On 08/18/2015 04:06 PM, Milan Kub?k wrote: > >On 08/11/2015 03:17 AM, Fraser Tweedale wrote: > >>On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kub?k wrote: > >>>On 08/05/2015 02:57 PM, Milan Kub?k wrote: > >>>>Hi list, > >>>> > >>>>I'm sending the test plan [1] for certificate profiles and preliminary > >>>>patches for it. > >>>>The plan covers basic CRUD test and some corner cases. I'm open to > >>>>more > >>>>suggestions. > >>>> > >>>>More complicated tests involving certificate profiles will require the > >>>>code (and tests) > >>>>for CA ACLs merged, so it's not there at the moment. > >>>> > >>>>There are some unfinished test cases in places I wasn't sure what the > >>>>result should be. > >>>>We need to iterate through these to fix it. > >>>> > >>>> > >>>>[1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan > >>>> > >>>>Cheers, > >>>>Milan > >>>Hi all, > >>> > >>>have you had some time to look at the code and proposal? > >>>Today I want to write a basic CRUD test for the ACLs as well as a few > >>>test > >>>cases to check if the ACL is being enforced. It should make it into > >>>wiki > >>>today or by tomorrow. I'll send an update then. > >>> > >>>Cheers, > >>>Milan > >>> > >>Hi Milan, > >> > >>I have reviewed the V4/Certificate_Profiles/Test_Plan. Couple of > >>comments: > >> > >>- Test case: Import profile with incorrect values > >> - Expected result: refused with error. > >> - A simple way to provoke this condition is to add a number to > >> ``policyset.serverCertSet.list``. > >> - A similar test case should exist for certprofile-mod. > >> > >>- Test case: Delete default profile > >> - As discussed elsewhere, expected result should be failure. > >> I filed ticket #5198 to make it so :) > >> > >>I will review the patch soon. > >> > >>Cheers, > >>Fraser > >Hello, > > > >how is the review going? I'd like to have at least the tracker (patch > >0008) > > reviewed (and merged :) if possible. It will be needed in CA ACL tests. > > > >Cheers, > >Milan > > > > Fraser, do you review this patchset? This fell off my radar, sorry! I eyeballed it a while back and everything seemed fine; I have not (successfully) run the tests yet though. I will complete the review tomorrow. Thanks, Fraser From npmccallum at redhat.com Mon Aug 31 13:26:22 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 31 Aug 2015 09:26:22 -0400 Subject: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org In-Reply-To: <55DEC9F5.4070302@redhat.com> References: <55A532DF.7070302@redhat.com> <55A53D93.4050201@redhat.com> <20150715074450.GL4218@redhat.com> <55DEC9F5.4070302@redhat.com> Message-ID: <1441027582.7711.3.camel@redhat.com> On Thu, 2015-08-27 at 10:27 +0200, Petr Spacek wrote: > On 15.7.2015 09:44, Jan Pazdziora wrote: > > On Tue, Jul 14, 2015 at 12:49:23PM -0400, John Dennis wrote: > > > On 07/14/2015 12:03 PM, Petr Spacek wrote: > > > > Hello, > > > > > > > > Is anyone using repos > > > > https://jdennis.fedorapeople.org/ipa-devel/ > > > > ? > > > > > > > > AFAIK nobody in Brno is seriously using it but I'm not sure > > > > about people > > > > outside the Brno. > > > > > > > > Could we use COPR instead and get out of builder business? > > > > Upcoming lab > > > > maintenance window could be a good time to do that. > > > > > > I would love to get out of the builder business and I suspect > > > Nalin would as > > > well [1]. The question came up in our Monday meeting as well. > > > Nobody seem to > > > know if anyone was using these builds and why we weren't using > > > COPR. The > > > > The Fedora infra admins should be able to provide HTTP logs for the > > repo, if you needs some numbers about potential usage. > > That is a good idea! I got logs from Fedora admins and as far as I > can tell, > in the last month there were only 7 RPM downloads and nothing else. > > The 7 hits I found was for > /ipa-devel/rhel/6/x86_64/os/sssd-1.13.1- > 0.20150813T1121Zgit137d5dd.el6.i686.rpm and > other packages from the same version. > > I did not find any hits for IPA packages at all. All the remaining > traffic > (except the 7 RPM hits) was from repo data refreshes: > - 83 % is RHEL 5 repodata > - 13 % is RHEL 6 repodata > - remaining ~ 4 % of noise is Fedora repodata > > It seems to me that we can get out the builder business completely > and > decommission ipa-devel and replace it with COPR. > > Do you agree? John? Nathaniel? Stephen? Anyone? :-) I'm not using it. Let's kill it. :) From sgallagh at redhat.com Mon Aug 31 13:36:20 2015 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 31 Aug 2015 09:36:20 -0400 Subject: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org In-Reply-To: <55DF0082.5040305@redhat.com> References: <55A532DF.7070302@redhat.com> <55A53D93.4050201@redhat.com> <20150715074450.GL4218@redhat.com> <55DEC9F5.4070302@redhat.com> <55DF0082.5040305@redhat.com> Message-ID: <1441028180.4524.10.camel@redhat.com> On Thu, 2015-08-27 at 08:20 -0400, John Dennis wrote: > On 08/27/2015 04:27 AM, Petr Spacek wrote: > > On 15.7.2015 09:44, Jan Pazdziora wrote: > > > On Tue, Jul 14, 2015 at 12:49:23PM -0400, John Dennis wrote: > > > > On 07/14/2015 12:03 PM, Petr Spacek wrote: > > > > > Hello, > > > > > > > > > > Is anyone using repos > > > > > https://jdennis.fedorapeople.org/ipa-devel/ > > > > > ? > > > > > > > > > > AFAIK nobody in Brno is seriously using it but I'm not sure > > > > > about people > > > > > outside the Brno. > > > > > > > > > > Could we use COPR instead and get out of builder business? > > > > > Upcoming lab > > > > > maintenance window could be a good time to do that. > > > > > > > > I would love to get out of the builder business and I suspect > > > > Nalin would as > > > > well [1]. The question came up in our Monday meeting as well. > > > > Nobody seem to > > > > know if anyone was using these builds and why we weren't using > > > > COPR. The > > > > > > The Fedora infra admins should be able to provide HTTP logs for > > > the > > > repo, if you needs some numbers about potential usage. > > > > That is a good idea! I got logs from Fedora admins and as far as I > > can tell, > > in the last month there were only 7 RPM downloads and nothing else. > > > > The 7 hits I found was for > > /ipa-devel/rhel/6/x86_64/os/sssd-1.13.1- > > 0.20150813T1121Zgit137d5dd.el6.i686.rpm and > > other packages from the same version. > > > > I did not find any hits for IPA packages at all. All the remaining > > traffic > > (except the 7 RPM hits) was from repo data refreshes: > > - 83 % is RHEL 5 repodata > > - 13 % is RHEL 6 repodata > > - remaining ~ 4 % of noise is Fedora repodata > > > > It seems to me that we can get out the builder business completely > > and > > decommission ipa-devel and replace it with COPR. > > > > Do you agree? John? Nathaniel? Stephen? Anyone? :-) > > Yes, I agree. Do we have a cut off date when I can stop the service? > Given that the traffic was so small, it looks likely that only a single person is still using it. Probably safe to just kill it off and wait for that person to ask where to go. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From tbabej at redhat.com Mon Aug 31 13:54:38 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 31 Aug 2015 15:54:38 +0200 Subject: [Freeipa-devel] [PATCHSET] Replica promotion patches In-Reply-To: <1441025803.28131.48.camel@willson.usersys.redhat.com> References: <1440624432.8138.130.camel@willson.usersys.redhat.com> <55E44C81.6010306@redhat.com> <1441025803.28131.48.camel@willson.usersys.redhat.com> Message-ID: <55E45C9E.3010906@redhat.com> On 08/31/2015 02:56 PM, Simo Sorce wrote: > On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote: >> >> On 08/26/2015 11:27 PM, Simo Sorce wrote: >>> This patchset implements https://fedorahosted.org/freeipa/ticket/2888 >>> and introduces a number of required changes and dependencies to achieve >>> this goal. >>> This work requires the custodia project to securely transfer keys >>> between ipa servers. >>> >>> This work is not 100% complete, it still misses the ability to install >>> kra instances and the ability to install a CA (via ipa-ca-install) with >>> externally signed certs. >>> >>> However it is massive enough that warrants review and pushing, the resat >>> of the changes can be applied later as this work should not disrupt the >>> classic install methods. >>> >>> In order to build my previous patches (530-533) are needed as well as a >>> number of updated components. >>> >>> I used the following coprs for testing: >>> simo/jwcrypto >>> simo/custodia >>> abbra/sssd-kkdcproxy (for sssd 1.13.1) >>> lkrispen/389-ds-current (for 389 > 1.3.4.4) >>> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) >>> mkosek/freeipa-4.2-fedora-22 (misc) >>> fedora/updates-testing (python-gssapi 1.1.2) >>> >>> Ludwig's copr is necessary to have a functional DNA plugin in replicas, >>> eventually his patches should be committed in 389-ds-base 1.3.4.4 when >>> it will be released. >>> >>> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 >>> that may cause installation issues in some case (re-install of a >>> replica). >>> >>> The domain must be raised to level 1 in order to use replica promotion. >>> >>> In order to promote a replica the server must be first joined as a >>> regular client to the domain. >>> >>> This is the flow I usually use for testing: >>> >>> # ipa-client-install >>> # kinit admin >>> # ipa-replica-install --promote --setup-ca >>> >> etc...> >>> >>> These patches are also available in this git tree rebnase on current >>> master: >>> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review >>> >>> Simo. >>> >>> >>> >> >> I'm running in a issue when upgrading RPMs: > > What version are you upgrading from ? > > Also do you have logs telling which update is failing ? I can guess it > is the topology stuff but that would be surprising. > > Simo. > It was a master devel machine with some wear&tear on it, clean 4.2. install does not blow up on upgrade for me. Will investigate further. From mbasti at redhat.com Mon Aug 31 14:53:06 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 31 Aug 2015 16:53:06 +0200 Subject: [Freeipa-devel] dnssec tests fail due to KeyError at is_record_signed method In-Reply-To: <55DCBB09.6090804@redhat.com> References: <55DCBB09.6090804@redhat.com> Message-ID: <55E46A52.1090501@redhat.com> On 08/25/2015 08:59 PM, Oleg Fayans wrote: > Hi Martin, > > As I was running the dnssec integration tests, I noticed that 4 out of > 5 tests fail with the assumption of the dns zone being signed. > > Here is the stdout of the tests: > http://pastebin.test.redhat.com/307944 > > The failure occurs in the is_record_signed method: it catches KeyError > calling the ans.response.find_rrset method (line 37 at > test_integration/test_dnssec.py). Could you take a look at it? > Related ticket. https://fedorahosted.org/freeipa/ticket/5273 This happens mainly on re-installed systems From simo at redhat.com Mon Aug 31 15:08:00 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 31 Aug 2015 11:08:00 -0400 Subject: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org In-Reply-To: <1441028180.4524.10.camel@redhat.com> References: <55A532DF.7070302@redhat.com> <55A53D93.4050201@redhat.com> <20150715074450.GL4218@redhat.com> <55DEC9F5.4070302@redhat.com> <55DF0082.5040305@redhat.com> <1441028180.4524.10.camel@redhat.com> Message-ID: <1441033680.28131.55.camel@willson.usersys.redhat.com> On Mon, 2015-08-31 at 09:36 -0400, Stephen Gallagher wrote: > On Thu, 2015-08-27 at 08:20 -0400, John Dennis wrote: > > On 08/27/2015 04:27 AM, Petr Spacek wrote: > > > On 15.7.2015 09:44, Jan Pazdziora wrote: > > > > On Tue, Jul 14, 2015 at 12:49:23PM -0400, John Dennis wrote: > > > > > On 07/14/2015 12:03 PM, Petr Spacek wrote: > > > > > > Hello, > > > > > > > > > > > > Is anyone using repos > > > > > > https://jdennis.fedorapeople.org/ipa-devel/ > > > > > > ? > > > > > > > > > > > > AFAIK nobody in Brno is seriously using it but I'm not sure > > > > > > about people > > > > > > outside the Brno. > > > > > > > > > > > > Could we use COPR instead and get out of builder business? > > > > > > Upcoming lab > > > > > > maintenance window could be a good time to do that. > > > > > > > > > > I would love to get out of the builder business and I suspect > > > > > Nalin would as > > > > > well [1]. The question came up in our Monday meeting as well. > > > > > Nobody seem to > > > > > know if anyone was using these builds and why we weren't using > > > > > COPR. The > > > > > > > > The Fedora infra admins should be able to provide HTTP logs for > > > > the > > > > repo, if you needs some numbers about potential usage. > > > > > > That is a good idea! I got logs from Fedora admins and as far as I > > > can tell, > > > in the last month there were only 7 RPM downloads and nothing else. > > > > > > The 7 hits I found was for > > > /ipa-devel/rhel/6/x86_64/os/sssd-1.13.1- > > > 0.20150813T1121Zgit137d5dd.el6.i686.rpm and > > > other packages from the same version. > > > > > > I did not find any hits for IPA packages at all. All the remaining > > > traffic > > > (except the 7 RPM hits) was from repo data refreshes: > > > - 83 % is RHEL 5 repodata > > > - 13 % is RHEL 6 repodata > > > - remaining ~ 4 % of noise is Fedora repodata > > > > > > It seems to me that we can get out the builder business completely > > > and > > > decommission ipa-devel and replace it with COPR. > > > > > > Do you agree? John? Nathaniel? Stephen? Anyone? :-) > > > > Yes, I agree. Do we have a cut off date when I can stop the service? > > > > > Given that the traffic was so small, it looks likely that only a > single person is still using it. Probably safe to just kill it off and > wait for that person to ask where to go. It may be one of my VMs, if so I will just change stuff, ok to kill for me. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Mon Aug 31 15:08:48 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 31 Aug 2015 11:08:48 -0400 Subject: [Freeipa-devel] [PATCH 0086] Migrate OTP import script to python-cryptography Message-ID: <1441033728.7711.15.camel@redhat.com> https://fedorahosted.org/freeipa/ticket/5192 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0086-Migrate-OTP-import-script-to-python-cryptography.patch Type: text/x-patch Size: 14209 bytes Desc: not available URL: From pvoborni at redhat.com Mon Aug 31 15:24:40 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 31 Aug 2015 17:24:40 +0200 Subject: [Freeipa-devel] [PATCH] 920 webui: improve performance of search in association dialog Message-ID: <55E471B8.2020904@redhat.com> By adding no_members option to commands which supports it. It then skips memberof procession on the server side. https://fedorahosted.org/freeipa/ticket/5271 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0920-webui-improve-performance-of-search-in-association-d.patch Type: text/x-patch Size: 1927 bytes Desc: not available URL: From mkosek at redhat.com Mon Aug 31 16:05:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 31 Aug 2015 18:05:31 +0200 Subject: [Freeipa-devel] [PATCH 0302] DNSSEC: remove "DNSSEC is experimental" warnings In-Reply-To: <55E44E05.8080603@redhat.com> References: <55E44E05.8080603@redhat.com> Message-ID: <55E47B4B.5040800@redhat.com> On 08/31/2015 02:52 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5265 > > Patch attached. > > Should I remove also message class "DNSSECWarning" which is not used now, or > just keep it there because ti has already registered error code? > > Martin^2 > > Just for the record, I added more pointers to why we think DNSSEC is now more stabilized to the ticket - this is an important information that should warrant removal of the warning messages. From rmeggins at redhat.com Mon Aug 31 16:15:47 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 31 Aug 2015 10:15:47 -0600 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55E403D8.9030505@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> Message-ID: <55E47DB3.1060907@redhat.com> On 08/31/2015 01:35 AM, Petr Spacek wrote: > On 26.8.2015 20:09, Rich Megginson wrote: >> On 08/25/2015 09:08 AM, Petr Spacek wrote: >>> On 8.7.2015 19:56, Rich Megginson wrote: >>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>>>> Assuming that Designate wants to own DNS and be Primary Master, it would be >>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>>>> alongside their own JSON API. >>>>> >>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add >>>>> zones >>>>> but still, standard protocol would mean that standard client (possibly guest >>>>> OS inside VM) can update its records without any OpenStack dependency, which >>>>> is very much desirable. >>>>> >>>>> The use case here is to allow the guest OS to publish it's SSH key (which was >>>>> generated inside the VM after first boot) to prevent Man in the middle >>>>> attacks. >> I'm working on a different approach for guest OS registration. This involves >> a Nova hook/plugin: >> * build_instance pre-hook to generate an OTP and call ipa host-add with the >> OTP - add OTP to new host metadata - add ipa-client-registration script to new >> host cloud-init >> * new instance calls script - will wait for OTP to become available in >> metadata, then call ipa-client-install with OTP >> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with new IP > BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. > ipa-client-install is using DNS UPDATE today. I already have to support the IPA JSON REST interface with kerberos credentials to do the host add, so it is easy to support dsrecord-add. > >> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova >> >>>>> The same goes for all other sorts of DANE/DNSSEC data or service >>>>> discovery using DNS, where a guest/container running a distributed service >>>>> can >>>>> publish it's existence in DNS. >>>>> >>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>>>> widely supported, too. >>>>> >>>>> So DNS UPDATE is my biggest wish :-) >>>>> >>>> Ok. There was a Designate blueprint for such a feature, but I can't find it >>>> and neither can the Designate guys. There is a mention of nsupdate in the >>>> minidns blueprint, but that's about it. The fact that Designate upstream >>>> can't find the bp suggests that this is not a high priority for them and will >>>> not likely implement it on their own i.e. we would have to contribute this >>>> feature. >>>> >>>> If Designate had such a feature, how would this help us integrate FreeIPA with >>>> Designate? >>> It would greatly simplify integration with FreeIPA. There is a plan to support >>> DNS updates as described in RFC 2136 to push updates from FreeIPA servers to >>> external DNS servers, so we could use the same code to integrate with AD & >>> Designate at the same time. >>> >>> (I'm sorry for the delay, it somehow slipped through the cracks.) >>> >> For Designate for our use cases, we want IPA to be the authoritative source of >> DNS data. > Why? In my eyes it is additional complexity for no obvious benefit. DNS is > built around assumption that there is only one authoritative source of data > and as far as I can tell all attempts to bend this assumption did not end well. But what about users/operators who want to integrate OpenStack with their existing DNS deployment (e.g. IPA or AD)? Will they allow converting their IPA/AD DNS to be a replica of Designate? This seems to be the obverse of most of the ways OpenStack is integrated into existing deployments. For example, for Keystone Identity, you don't configure Keystone to be the authoritative source of data for identity, then configure IPA or AD to be a replica of Keystone. You configure Keystone to use IPA/AD for its identity information. > > In my eyes IPA should have ability to integrate with whatever DNS server admin > wants to use, using standard protocols. Does this mean the best way to support Designate will be to change IPA DNS so that it can be a replica of Designate, and get its data via AXFR from Designate? > > What is the benefit of the other approach? > > Petr^2 Spacek > > >> When a client wants to read data from Designate, that data should somehow come >> from IPA. I don't think Designate has any sort of proxy or pass-through >> feature, so the data would have be sync'd from IPA. If IPA supports being a >> server for AXFR/IXFR, Designate could be changed to support AXFR/IXFR client >> side, then would just be a slave of IPA. If IPA does not support zone >> transfers, then we would need some sort of initial sync of data from IPA to >> Designate (I wrote such a script for Designate >> (https://github.com/openstack/designate/blob/master/contrib/ipaextractor.py). >> Then, perhaps some sort of proxy/service that would poll for changes >> (syncrepl?) in IPA, then submit those changes to Designate (using Designate >> REST API, or DNS UPDATE when Designate mDNS supports it). >> >> When a client wants to update data in Designate, we need to somehow get that >> data into IPA. The only way Designate pushes data out currently is via AXFR, >> which doesn't work for IPA to be a direct slave of Designate. What might work >> is to have an "agent" that gets the AXFR, then somehow converts that into IPA >> updates. This would only work if the volume of updates is fairly low. If >> Designate supported IXFR it would be much better. From pspacek at redhat.com Mon Aug 31 16:50:47 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 31 Aug 2015 18:50:47 +0200 Subject: [Freeipa-devel] [PATCH 0053-0056] DNSSEC: Fix deadlocks & export to LDAP Message-ID: <55E485E7.4070803@redhat.com> Hello, Attached patch set should fix the deadlock you discovered + few more issues I spotted when testing the original patch. Known problems (more patches needed): - /etc/opendnssec/zonelist.xml should be restored during server uninstall - ccache for ipa-ods-exporter should be removed during server uninstall - timestamps in .private key files do not reflect (?) current key state in OpenDNSSEC database (I will look into this tomorrow.) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0053-DNSSEC-prevent-ipa-ods-exporter-from-looping-after-s.patch Type: text/x-patch Size: 1500 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0054-DNSSEC-Fix-deadlock-in-ipa-ods-exporter-ods-enforcer.patch Type: text/x-patch Size: 3080 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0055-DNSSEC-Fix-HSM-synchronization-in-ipa-dnskeysyncd-wh.patch Type: text/x-patch Size: 823 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0056-DNSSEC-Fix-key-metadata-export.patch Type: text/x-patch Size: 1138 bytes Desc: not available URL: From simo at redhat.com Mon Aug 31 17:00:11 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 31 Aug 2015 13:00:11 -0400 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <55E47DB3.1060907@redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> Message-ID: <1441040411.28131.70.camel@willson.usersys.redhat.com> On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: > On 08/31/2015 01:35 AM, Petr Spacek wrote: > > On 26.8.2015 20:09, Rich Megginson wrote: > >> On 08/25/2015 09:08 AM, Petr Spacek wrote: > >>> On 8.7.2015 19:56, Rich Megginson wrote: > >>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: > >>>>> Assuming that Designate wants to own DNS and be Primary Master, it would be > >>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) > >>>>> alongside their own JSON API. > >>>>> > >>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add > >>>>> zones > >>>>> but still, standard protocol would mean that standard client (possibly guest > >>>>> OS inside VM) can update its records without any OpenStack dependency, which > >>>>> is very much desirable. > >>>>> > >>>>> The use case here is to allow the guest OS to publish it's SSH key (which was > >>>>> generated inside the VM after first boot) to prevent Man in the middle > >>>>> attacks. > >> I'm working on a different approach for guest OS registration. This involves > >> a Nova hook/plugin: > >> * build_instance pre-hook to generate an OTP and call ipa host-add with the > >> OTP - add OTP to new host metadata - add ipa-client-registration script to new > >> host cloud-init > >> * new instance calls script - will wait for OTP to become available in > >> metadata, then call ipa-client-install with OTP > >> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with new IP > > BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. > > ipa-client-install is using DNS UPDATE today. > > I already have to support the IPA JSON REST interface with kerberos > credentials to do the host add, so it is easy to support dsrecord-add. > > > > >> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova > >> > >>>>> The same goes for all other sorts of DANE/DNSSEC data or service > >>>>> discovery using DNS, where a guest/container running a distributed service > >>>>> can > >>>>> publish it's existence in DNS. > >>>>> > >>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is > >>>>> widely supported, too. > >>>>> > >>>>> So DNS UPDATE is my biggest wish :-) > >>>>> > >>>> Ok. There was a Designate blueprint for such a feature, but I can't find it > >>>> and neither can the Designate guys. There is a mention of nsupdate in the > >>>> minidns blueprint, but that's about it. The fact that Designate upstream > >>>> can't find the bp suggests that this is not a high priority for them and will > >>>> not likely implement it on their own i.e. we would have to contribute this > >>>> feature. > >>>> > >>>> If Designate had such a feature, how would this help us integrate FreeIPA with > >>>> Designate? > >>> It would greatly simplify integration with FreeIPA. There is a plan to support > >>> DNS updates as described in RFC 2136 to push updates from FreeIPA servers to > >>> external DNS servers, so we could use the same code to integrate with AD & > >>> Designate at the same time. > >>> > >>> (I'm sorry for the delay, it somehow slipped through the cracks.) > >>> > >> For Designate for our use cases, we want IPA to be the authoritative source of > >> DNS data. > > Why? In my eyes it is additional complexity for no obvious benefit. DNS is > > built around assumption that there is only one authoritative source of data > > and as far as I can tell all attempts to bend this assumption did not end well. > > But what about users/operators who want to integrate OpenStack with > their existing DNS deployment (e.g. IPA or AD)? Will they allow > converting their IPA/AD DNS to be a replica of Designate? No, they would not want to, or have no permissions to do so. But that shouldn't be a big issue, designate will probably be made to manage a completely unrelated namespace. > This seems to > be the obverse of most of the ways OpenStack is integrated into existing > deployments. For example, for Keystone Identity, you don't configure > Keystone to be the authoritative source of data for identity, then > configure IPA or AD to be a replica of Keystone. You configure Keystone > to use IPA/AD for its identity information. Indeed. > > > > In my eyes IPA should have ability to integrate with whatever DNS server admin > > wants to use, using standard protocols. > > Does this mean the best way to support Designate will be to change IPA > DNS so that it can be a replica of Designate, and get its data via AXFR > from Designate? No, we should probably just make it possible for IPA to talk to designate to add the necessary records. If Designate is in use, the IPA DNS will not be in use and turned off. It makes little to no sense to replicate stuff out of designate if we are not the master server. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Mon Aug 31 20:15:25 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 31 Aug 2015 15:15:25 -0500 Subject: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents. In-Reply-To: <55E43800.20903@redhat.com> References: <55DF67EF.6020905@redhat.com> <55E43800.20903@redhat.com> Message-ID: <55E4B5DD.5060206@redhat.com> On 8/31/2015 6:18 AM, Martin Basti wrote: > > > On 08/27/2015 09:41 PM, Endi Sukma Dewata wrote: >> The CA and KRA installation code has been modified to use LDAPI >> to create the CA and KRA agents directly in the CA and KRA >> database. This way it's no longer necessary to use the Directory >> Manager password or CA and KRA admin certificate. >> >> https://fedorahosted.org/freeipa/ticket/5257 >> >> >> > > Thank you. > > 1) Can you use following code instead of direct call of ldap2.ldap2()? > > if not api.Backend.ldap2.is_connected(): > api.Backend.ldap2.connect(autobind=True) > > conn = api.Backend.ldap2 It's actually isconnected() instead of is_connected(), but even so, the proposed code doesn't work: ipa.ipapython.install.cli.install_tool(Server): DEBUG The ipa-server-install command failed, exception: TypeError: 'ldap2' object is not callable ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object is not callable > 2) Patch needs rebase to master branch. The original patch does apply cleanly to master. Did you see a conflict? > 3) > + user_dn = DN(('uid', "ipara"), ('ou', 'People'), self.basedn) > + conn.create( > + dn=user_dn, > > can you use add entry() instead of create()? We don't use native > python-ldap, but rather ipaldap methods It's actually calling the ldap2.create() defined in ipaserver/plugins/ldap2.py, which calls add_entry(). So my original patch still stands. -- Endi S. Dewata From rmeggins at redhat.com Mon Aug 31 22:42:34 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 31 Aug 2015 16:42:34 -0600 Subject: [Freeipa-devel] How to support Designate? In-Reply-To: <1441040411.28131.70.camel@willson.usersys.redhat.com> References: <5593FC83.8030504@redhat.com> <559402F9.1000708@redhat.com> <5594034B.9040706@redhat.com> <559CFBF6.6000109@redhat.com> <559D3D6A.5020106@redhat.com> <559D4BB8.6080407@redhat.com> <559D6455.4040704@redhat.com> <55DC84EE.4010102@redhat.com> <55DE00D1.9050805@redhat.com> <55E403D8.9030505@redhat.com> <55E47DB3.1060907@redhat.com> <1441040411.28131.70.camel@willson.usersys.redhat.com> Message-ID: <55E4D85A.7080600@redhat.com> On 08/31/2015 11:00 AM, Simo Sorce wrote: > On Mon, 2015-08-31 at 10:15 -0600, Rich Megginson wrote: >> On 08/31/2015 01:35 AM, Petr Spacek wrote: >>> On 26.8.2015 20:09, Rich Megginson wrote: >>>> On 08/25/2015 09:08 AM, Petr Spacek wrote: >>>>> On 8.7.2015 19:56, Rich Megginson wrote: >>>>>> On 07/08/2015 10:11 AM, Petr Spacek wrote: >>>>>>> Assuming that Designate wants to own DNS and be Primary Master, it would be >>>>>>> awesome if they could support standard DNS UPDATE protocol (RFC 2136) >>>>>>> alongside their own JSON API. >>>>>>> >>>>>>> The JSON API is superset of DNS UPDATE protocol because it allows to add >>>>>>> zones >>>>>>> but still, standard protocol would mean that standard client (possibly guest >>>>>>> OS inside VM) can update its records without any OpenStack dependency, which >>>>>>> is very much desirable. >>>>>>> >>>>>>> The use case here is to allow the guest OS to publish it's SSH key (which was >>>>>>> generated inside the VM after first boot) to prevent Man in the middle >>>>>>> attacks. >>>> I'm working on a different approach for guest OS registration. This involves >>>> a Nova hook/plugin: >>>> * build_instance pre-hook to generate an OTP and call ipa host-add with the >>>> OTP - add OTP to new host metadata - add ipa-client-registration script to new >>>> host cloud-init >>>> * new instance calls script - will wait for OTP to become available in >>>> metadata, then call ipa-client-install with OTP >>>> * Floating IP is assigned to VM - Nova hook will call dnsrecord-add with new IP >>> BTW dnsrecord-add can be omitted if standard DNS UPDATE is supported. >>> ipa-client-install is using DNS UPDATE today. >> I already have to support the IPA JSON REST interface with kerberos >> credentials to do the host add, so it is easy to support dsrecord-add. >> >>>> https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova >>>> >>>>>>> The same goes for all other sorts of DANE/DNSSEC data or service >>>>>>> discovery using DNS, where a guest/container running a distributed service >>>>>>> can >>>>>>> publish it's existence in DNS. >>>>>>> >>>>>>> DNS UPDATE supports GSS(API) for authentication via RFC 3007 and that is >>>>>>> widely supported, too. >>>>>>> >>>>>>> So DNS UPDATE is my biggest wish :-) >>>>>>> >>>>>> Ok. There was a Designate blueprint for such a feature, but I can't find it >>>>>> and neither can the Designate guys. There is a mention of nsupdate in the >>>>>> minidns blueprint, but that's about it. The fact that Designate upstream >>>>>> can't find the bp suggests that this is not a high priority for them and will >>>>>> not likely implement it on their own i.e. we would have to contribute this >>>>>> feature. >>>>>> >>>>>> If Designate had such a feature, how would this help us integrate FreeIPA with >>>>>> Designate? >>>>> It would greatly simplify integration with FreeIPA. There is a plan to support >>>>> DNS updates as described in RFC 2136 to push updates from FreeIPA servers to >>>>> external DNS servers, so we could use the same code to integrate with AD & >>>>> Designate at the same time. >>>>> >>>>> (I'm sorry for the delay, it somehow slipped through the cracks.) >>>>> >>>> For Designate for our use cases, we want IPA to be the authoritative source of >>>> DNS data. >>> Why? In my eyes it is additional complexity for no obvious benefit. DNS is >>> built around assumption that there is only one authoritative source of data >>> and as far as I can tell all attempts to bend this assumption did not end well. >> But what about users/operators who want to integrate OpenStack with >> their existing DNS deployment (e.g. IPA or AD)? Will they allow >> converting their IPA/AD DNS to be a replica of Designate? > No, they would not want to, or have no permissions to do so. > But that shouldn't be a big issue, designate will probably be made to > manage a completely unrelated namespace. > >> This seems to >> be the obverse of most of the ways OpenStack is integrated into existing >> deployments. For example, for Keystone Identity, you don't configure >> Keystone to be the authoritative source of data for identity, then >> configure IPA or AD to be a replica of Keystone. You configure Keystone >> to use IPA/AD for its identity information. > Indeed. > >>> In my eyes IPA should have ability to integrate with whatever DNS server admin >>> wants to use, using standard protocols. >> Does this mean the best way to support Designate will be to change IPA >> DNS so that it can be a replica of Designate, and get its data via AXFR >> from Designate? > No, we should probably just make it possible for IPA to talk to > designate to add the necessary records. If Designate is in use, the IPA > DNS will not be in use and turned off. Then why use IPA at all? Would be much simpler for the user to stand up a PowerDNS or BIND9 which are supported out of the box. > > It makes little to no sense to replicate stuff out of designate if we > are not the master server. > > Simo. >