From jcholast at redhat.com Mon Feb 1 08:03:09 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 1 Feb 2016 09:03:09 +0100 Subject: [Freeipa-devel] [PATCH 0013-0021] Coverity patches In-Reply-To: <56AB7BFD.1020308@redhat.com> References: <56AB6E03.2030601@redhat.com> <56AB7BF0.9030008@redhat.com> <56AB7BFD.1020308@redhat.com> Message-ID: <56AF113D.20804@redhat.com> Hi, On 29.1.2016 15:49, Martin Basti wrote: > > > On 29.01.2016 15:49, Stanislav Laznicka wrote: >> Reworded the commits so that they better reflect what's going on in those. >> >> On 01/29/2016 02:49 PM, Stanislav Laznicka wrote: >>> Hello, >>> >>> I made some patches based on the Coverity report from 18.1.2016. >>> >>> Cheers, >>> Standa >>> >>> >> >> >> > NACK, see my previous email I don't think this deserves 9 patches, 1 would be sufficient enough. Patch 0013: 1) I think this unreachable return is intentional, as indicated by the comment: - #we shouldn't get here - return [UNKNOWN_ERROR] 2) How is this dead code? - if options.mode == 'validate_pot' or options.mode == 'validate_po': + if options.mode in ('validate_pot', 'validate_po'): - elif options.mode == 'create_test' or 'test_gettext': + elif options.mode in ('create_test', 'test_gettext'): Patch 0014-0015: LGTM Patch 0016: The original code is in fact correct. Patch 0017: This will break Python 3. The two branches are performing the same action, but with different data types. Patch 0018: LGTM Patch 0019: IMO the original code is better (None has a __class__ too, you know). Patch 0020: LGTM Patch 0021: Please use the original error messages (there are no requests being added to D-Bus, but to certmonger). Honza -- Jan Cholasta From mbasti at redhat.com Mon Feb 1 09:25:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Feb 2016 10:25:13 +0100 Subject: [Freeipa-devel] [PATCH 0411] upgrade: log to ipaupgrade.log if ipa is not installed In-Reply-To: <56AB4929.3030003@redhat.com> References: <56AB3550.6020409@redhat.com> <56AB4929.3030003@redhat.com> Message-ID: <56AF2479.7060506@redhat.com> On 29.01.2016 12:12, Martin Kosek wrote: > On 01/29/2016 10:48 AM, Martin Basti wrote: >> Missing record in ipaupgrade.log that upgrade failed because IPA is not >> installed, causes harder time to debugging upgrade from log. >> >> Patch attached. > I am thinking that in these general catch-all clauses, it could be also useful > to print the stack trace in the DEBUG log, especially for the cases when the > exception is re-raised to some general one, like here: > > try: > data_upgrade.create_instance() > ... > except RuntimeError: > raise RuntimeError('IPA upgrade failed.', 1) > It is already logged to DEBUG log in data_upgrade instance. From ofayans at redhat.com Mon Feb 1 10:52:00 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 1 Feb 2016 11:52:00 +0100 Subject: [Freeipa-devel] [TEST][Patch 0021] Fixed recent replica installation issues in the lab In-Reply-To: <56AB45BB.3070102@redhat.com> References: <56A0D223.2060702@redhat.com> <56A0FC2C.2010004@redhat.com> <56A87E93.9030302@redhat.com> <56A898E5.9060202@redhat.com> <56AB45BB.3070102@redhat.com> Message-ID: <56AF38D0.8010004@redhat.com> Hi Petr, Please find the new version of the patch attached. Comments are inline On 01/29/2016 11:58 AM, Petr Spacek wrote: > On 27.1.2016 11:16, Oleg Fayans wrote: >> Sorry, trailing whitespace detected. This version passes lint >> >> On 01/27/2016 09:23 AM, Oleg Fayans wrote: >>>> Hi, >>>> >>>> On 01/21/2016 04:41 PM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> On 21.1.2016 13:42, Oleg Fayans wrote: >>>>>>>> freeipa-ofayans-0021-Removed-ip-address-option-from-replica-installation.patch >>>>>>>> >>>>>>>> >>>>>>>> From d7ab06a4dcddb919fda351b983d478f1b6968578 Mon Sep 17 00:00:00 2001 >>>>>>>> From: Oleg Fayans >>>>>>>> Date: Thu, 21 Jan 2016 13:30:02 +0100 >>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>> >>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>>> >>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>> master >>>>>>>> --- >>>>>>>> ipatests/test_integration/tasks.py | 19 ++++++++++++------- >>>>>>>> 1 file changed, 12 insertions(+), 7 deletions(-) >>>>>>>> >>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..43ef78b0c55deed24a0444f0ac6c38ddb2517481 100644 >>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>> @@ -69,6 +69,8 @@ def prepare_reverse_zone(host, ip): >>>>>>>> host.run_command(["ipa", >>>>>>>> "dnszone-add", >>>>>>>> zone], raiseonerr=False) >>>>>>>> + return zone >>>>>>>> + >>>>>>>> >>>>>>>> def prepare_host(host): >>>>>>>> if isinstance(host, Host): >>>>>>>> @@ -319,11 +321,8 @@ def domainlevel(host): >>>>>>>> def replica_prepare(master, replica): >>>>>>>> apply_common_fixes(replica) >>>>>>>> fix_apache_semaphores(replica) >>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>> - master.run_command(['ipa-replica-prepare', >>>>>>>> - '-p', replica.config.dirman_password, >>>>>>>> - '--ip-address', replica.ip, >>>>>>>> - replica.hostname]) >>>>>>>> + master.run_command(['ipa-replica-prepare', '-p', replica.config.dirman_password, >>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>> >>>>>> I guess that you will need --ip-address option in cases where master's reverse >>>>>> record does not exist (yet). >>>> And yo were right. Fixed >>>> >>>>>> >>>>>> I would recommend you to test this in libvirt or somewhere without revere >>>>>> records, I suspect that it might blow up. >>>>>> >>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>> @@ -339,8 +338,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>> # and replica installation would fail >>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>> '-p', replica.config.dirman_password, >>>>>>>> - '-w', replica.config.admin_password, >>>>>>>> - '--ip-address', replica.ip] >>>>>>>> + '-w', replica.config.admin_password] >>>>>>>> if setup_ca: >>>>>>>> args.append('--setup-ca') >>>>>>>> if setup_dns: >>>>>>>> @@ -380,6 +378,13 @@ def install_client(master, client, extra_args=()): >>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>> >>>>>>>> apply_common_fixes(client) >>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>> + allow_sync_ptr(master) >>>>>>>> + zone = prepare_reverse_zone(master, client.ip) >>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>> >>>>>> I'm not a big fan of ignoring exceptions here, it might be better to >>>>>> encapsulate the first command with try: except: and run the zone-mod only if >>>>>> the add worked as expected. >>>>>> >>>>>> Also, logging an message that reverse zone was not added might be a good idea. >>>> Agreed. Done. >>>> >>>>>> >>>>>> HTH >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>> >>>>>>>> >>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>> '--domain', client.domain.name, >>>>>> >>>> >>>> >>>> >> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. >> >> >> freeipa-ofayans-0021.2-Removed-ip-address-option-from-replica-installation.patch >> >> >> From e70daf4ed9dfbac7e8ea75cb8e9ab0f2af12ad48 Mon Sep 17 00:00:00 2001 >> From: Oleg Fayans >> Date: Wed, 27 Jan 2016 11:09:03 +0100 >> Subject: [PATCH] Removed --ip-address option from replica installation >> >> Explicitly specifying ip-address of the replica messes up with the current >> bind-dyndb-ldap logic, causing reverse zone not to be created. > > NACK > > The commit message and logic is incorrect. In fact it has nothing to do with > bind-dyndb-ldap. Either: > a] The zone already exists somewhere so you should not create it in IPA, and > this --ip-address option is invalid. > b] The zone does not exist yet and then --ip-address option is required. > > I do not see any logic around >> '--ip-address', replica.ip, The explicit ip-address passing was removed (that's the main point of this patch) > thus the NACK. > > > In other words, network setup is job for a provisioning system. IPA needs to > respect whatever the provisioning system did or did not do. > > Feel free to ask if something is unclear. > > (other comments inline) > > >> >> Enabled reverse-zone creation for the clients residing in different subnet from >> master >> --- >> ipatests/test_integration/tasks.py | 20 +++++++++++++++----- >> 1 file changed, 15 insertions(+), 5 deletions(-) >> >> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..b8b7fcfcbbb1dc672349119bbbb4cdbbd68c54ec 100644 >> --- a/ipatests/test_integration/tasks.py >> +++ b/ipatests/test_integration/tasks.py >> @@ -66,9 +66,13 @@ def check_arguments_are(slice, instanceof): >> >> def prepare_reverse_zone(host, ip): >> zone = get_reverse_zone_default(ip) >> - host.run_command(["ipa", >> + result = host.run_command(["ipa", >> "dnszone-add", >> zone], raiseonerr=False) >> + if result.returncode > 0: >> + log.warn(result.stderr_text) >> + return zone, result.returncode >> + >> >> def prepare_host(host): >> if isinstance(host, Host): >> @@ -319,11 +323,10 @@ def domainlevel(host): >> def replica_prepare(master, replica): >> apply_common_fixes(replica) >> fix_apache_semaphores(replica) >> - prepare_reverse_zone(master, replica.ip) >> master.run_command(['ipa-replica-prepare', >> '-p', replica.config.dirman_password, >> '--ip-address', replica.ip, >> - replica.hostname]) >> + '--auto-reverse', replica.hostname]) >> replica_bundle = master.get_file_contents( >> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >> replica_filename = get_replica_filename(replica) >> @@ -339,8 +342,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >> # and replica installation would fail >> args = ['ipa-replica-install', '-U', >> '-p', replica.config.dirman_password, >> - '-w', replica.config.admin_password, >> - '--ip-address', replica.ip] >> + '-w', replica.config.admin_password] >> if setup_ca: >> args.append('--setup-ca') >> if setup_dns: >> @@ -380,6 +382,14 @@ def install_client(master, client, extra_args=()): >> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >> >> apply_common_fixes(client) >> + # Now, for the situations where a client resides in a different subnet from >> + # master, we need to explicitly tell master to create a reverse zone for >> + # the client and enable dynamic updates for this zone. >> + allow_sync_ptr(master) >> + zone, error = prepare_reverse_zone(master, client.ip) >> + if not error: >> + master.run_command(["ipa", "dnszone-mod", zone, >> + "--dynamic-update=TRUE"], raiseonerr=False) > > I believe that this call to dnszone-mod should use raiseonerr=True so you know > that environment was not configured to accept dynamic updates. Agreed. Fixed. > >> >> client.run_command(['ipa-client-install', '-U', >> '--domain', client.domain.name, >> -- 2.4.3 > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0021.3-Removed-ip-address-option-from-replica-installation.patch Type: text/x-patch Size: 2440 bytes Desc: not available URL: From pspacek at redhat.com Mon Feb 1 11:11:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 1 Feb 2016 12:11:02 +0100 Subject: [Freeipa-devel] [PATCH 0013-0021] Coverity patches In-Reply-To: <56AF113D.20804@redhat.com> References: <56AB6E03.2030601@redhat.com> <56AB7BF0.9030008@redhat.com> <56AB7BFD.1020308@redhat.com> <56AF113D.20804@redhat.com> Message-ID: <56AF3D46.5060901@redhat.com> On 1.2.2016 09:03, Jan Cholasta wrote: > Hi, > > On 29.1.2016 15:49, Martin Basti wrote: >> >> >> On 29.01.2016 15:49, Stanislav Laznicka wrote: >>> Reworded the commits so that they better reflect what's going on in those. >>> >>> On 01/29/2016 02:49 PM, Stanislav Laznicka wrote: >>>> Hello, >>>> >>>> I made some patches based on the Coverity report from 18.1.2016. >>>> >>>> Cheers, >>>> Standa >>>> >>>> >>> >>> >>> >> NACK, see my previous email > > I don't think this deserves 9 patches, 1 would be sufficient enough. I would rather have it is separate patches as these fixes are largely not related. It will make bisecting easier. > Patch 0013: > > 1) I think this unreachable return is intentional, as indicated by the comment: > > - #we shouldn't get here > - return [UNKNOWN_ERROR] I would use assert False, "we shouldn't get here" neither we nor Coverity are confused when we hit the code path one day. UNKNOWN_ERROR would pop up somewhere else and it will be harder to find out why the hell the code behaves as mad. Traceback will clearly indicate that there is a problem with the 'switch'. Petr^2 Spacek > 2) How is this dead code? > > - if options.mode == 'validate_pot' or options.mode == 'validate_po': > + if options.mode in ('validate_pot', 'validate_po'): > > - elif options.mode == 'create_test' or 'test_gettext': > + elif options.mode in ('create_test', 'test_gettext'): > > > > Patch 0014-0015: LGTM > > > Patch 0016: The original code is in fact correct. > > > Patch 0017: This will break Python 3. The two branches are performing the same > action, but with different data types. > > > Patch 0018: LGTM > > > Patch 0019: IMO the original code is better (None has a __class__ too, you know). > > > Patch 0020: LGTM > > > Patch 0021: Please use the original error messages (there are no requests > being added to D-Bus, but to certmonger). > > > Honza From ofayans at redhat.com Mon Feb 1 11:21:53 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 1 Feb 2016 12:21:53 +0100 Subject: [Freeipa-devel] [TEST][Patch 0023] Updated connect/disconnect replica to work on both domain levels Message-ID: <56AF3FD1.4010107@redhat.com> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0023-Updated-connect-disconnect-replica-to-work-with-both-domainlevels.patch Type: text/x-patch Size: 2218 bytes Desc: not available URL: From pspacek at redhat.com Mon Feb 1 11:47:16 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 1 Feb 2016 12:47:16 +0100 Subject: [Freeipa-devel] [TEST][Patch 0021] Fixed recent replica installation issues in the lab In-Reply-To: <56AF38D0.8010004@redhat.com> References: <56A0D223.2060702@redhat.com> <56A0FC2C.2010004@redhat.com> <56A87E93.9030302@redhat.com> <56A898E5.9060202@redhat.com> <56AB45BB.3070102@redhat.com> <56AF38D0.8010004@redhat.com> Message-ID: <56AF45C4.9040404@redhat.com> On 1.2.2016 11:52, Oleg Fayans wrote: > Hi Petr, > > Please find the new version of the patch attached. Comments are inline > > On 01/29/2016 11:58 AM, Petr Spacek wrote: >> On 27.1.2016 11:16, Oleg Fayans wrote: >>> Sorry, trailing whitespace detected. This version passes lint >>> >>> On 01/27/2016 09:23 AM, Oleg Fayans wrote: >>>>> Hi, >>>>> >>>>> On 01/21/2016 04:41 PM, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> On 21.1.2016 13:42, Oleg Fayans wrote: >>>>>>>>> freeipa-ofayans-0021-Removed-ip-address-option-from-replica-installation.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> From d7ab06a4dcddb919fda351b983d478f1b6968578 Mon Sep 17 00:00:00 2001 >>>>>>>>> From: Oleg Fayans >>>>>>>>> Date: Thu, 21 Jan 2016 13:30:02 +0100 >>>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>>> >>>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>>>> >>>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>>> master >>>>>>>>> --- >>>>>>>>> ipatests/test_integration/tasks.py | 19 ++++++++++++------- >>>>>>>>> 1 file changed, 12 insertions(+), 7 deletions(-) >>>>>>>>> >>>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..43ef78b0c55deed24a0444f0ac6c38ddb2517481 100644 >>>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>>> @@ -69,6 +69,8 @@ def prepare_reverse_zone(host, ip): >>>>>>>>> host.run_command(["ipa", >>>>>>>>> "dnszone-add", >>>>>>>>> zone], raiseonerr=False) >>>>>>>>> + return zone >>>>>>>>> + >>>>>>>>> >>>>>>>>> def prepare_host(host): >>>>>>>>> if isinstance(host, Host): >>>>>>>>> @@ -319,11 +321,8 @@ def domainlevel(host): >>>>>>>>> def replica_prepare(master, replica): >>>>>>>>> apply_common_fixes(replica) >>>>>>>>> fix_apache_semaphores(replica) >>>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>>> - master.run_command(['ipa-replica-prepare', >>>>>>>>> - '-p', replica.config.dirman_password, >>>>>>>>> - '--ip-address', replica.ip, >>>>>>>>> - replica.hostname]) >>>>>>>>> + master.run_command(['ipa-replica-prepare', '-p', replica.config.dirman_password, >>>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>> >>>>>>> I guess that you will need --ip-address option in cases where master's reverse >>>>>>> record does not exist (yet). >>>>> And yo were right. Fixed >>>>> >>>>>>> >>>>>>> I would recommend you to test this in libvirt or somewhere without revere >>>>>>> records, I suspect that it might blow up. >>>>>>> >>>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>>> @@ -339,8 +338,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>>> # and replica installation would fail >>>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>>> '-p', replica.config.dirman_password, >>>>>>>>> - '-w', replica.config.admin_password, >>>>>>>>> - '--ip-address', replica.ip] >>>>>>>>> + '-w', replica.config.admin_password] >>>>>>>>> if setup_ca: >>>>>>>>> args.append('--setup-ca') >>>>>>>>> if setup_dns: >>>>>>>>> @@ -380,6 +378,13 @@ def install_client(master, client, extra_args=()): >>>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>>> >>>>>>>>> apply_common_fixes(client) >>>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>>> + allow_sync_ptr(master) >>>>>>>>> + zone = prepare_reverse_zone(master, client.ip) >>>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>>> >>>>>>> I'm not a big fan of ignoring exceptions here, it might be better to >>>>>>> encapsulate the first command with try: except: and run the zone-mod only if >>>>>>> the add worked as expected. >>>>>>> >>>>>>> Also, logging an message that reverse zone was not added might be a good idea. >>>>> Agreed. Done. >>>>> >>>>>>> >>>>>>> HTH >>>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>>> '--domain', client.domain.name, >>>>>>> >>>>> >>>>> >>>>> >>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. >>> >>> >>> freeipa-ofayans-0021.2-Removed-ip-address-option-from-replica-installation.patch >>> >>> >>> From e70daf4ed9dfbac7e8ea75cb8e9ab0f2af12ad48 Mon Sep 17 00:00:00 2001 >>> From: Oleg Fayans >>> Date: Wed, 27 Jan 2016 11:09:03 +0100 >>> Subject: [PATCH] Removed --ip-address option from replica installation >>> >>> Explicitly specifying ip-address of the replica messes up with the current >>> bind-dyndb-ldap logic, causing reverse zone not to be created. >> >> NACK >> >> The commit message and logic is incorrect. In fact it has nothing to do with >> bind-dyndb-ldap. Either: >> a] The zone already exists somewhere so you should not create it in IPA, and >> this --ip-address option is invalid. >> b] The zone does not exist yet and then --ip-address option is required. >> >> I do not see any logic around >>> '--ip-address', replica.ip, > > The explicit ip-address passing was removed (that's the main point of > this patch) Sure, but it cannot be done unconditionally (without additional logic). >> thus the NACK. >> >> >> In other words, network setup is job for a provisioning system. IPA needs to >> respect whatever the provisioning system did or did not do. Let me rephrase it: If IPA DNS manages the zone with replica FQDN or associated reverse zone, we need the --ip-address option. If IPA does not manage any of these, we do not need --ip-address option. >> Feel free to ask if something is unclear. Petr^2 Spacek >> (other comments inline) >> >> >>> >>> Enabled reverse-zone creation for the clients residing in different subnet from >>> master >>> --- >>> ipatests/test_integration/tasks.py | 20 +++++++++++++++----- >>> 1 file changed, 15 insertions(+), 5 deletions(-) >>> >>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..b8b7fcfcbbb1dc672349119bbbb4cdbbd68c54ec 100644 >>> --- a/ipatests/test_integration/tasks.py >>> +++ b/ipatests/test_integration/tasks.py >>> @@ -66,9 +66,13 @@ def check_arguments_are(slice, instanceof): >>> >>> def prepare_reverse_zone(host, ip): >>> zone = get_reverse_zone_default(ip) >>> - host.run_command(["ipa", >>> + result = host.run_command(["ipa", >>> "dnszone-add", >>> zone], raiseonerr=False) >>> + if result.returncode > 0: >>> + log.warn(result.stderr_text) >>> + return zone, result.returncode >>> + >>> >>> def prepare_host(host): >>> if isinstance(host, Host): >>> @@ -319,11 +323,10 @@ def domainlevel(host): >>> def replica_prepare(master, replica): >>> apply_common_fixes(replica) >>> fix_apache_semaphores(replica) >>> - prepare_reverse_zone(master, replica.ip) >>> master.run_command(['ipa-replica-prepare', >>> '-p', replica.config.dirman_password, >>> '--ip-address', replica.ip, >>> - replica.hostname]) >>> + '--auto-reverse', replica.hostname]) >>> replica_bundle = master.get_file_contents( >>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>> replica_filename = get_replica_filename(replica) >>> @@ -339,8 +342,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>> # and replica installation would fail >>> args = ['ipa-replica-install', '-U', >>> '-p', replica.config.dirman_password, >>> - '-w', replica.config.admin_password, >>> - '--ip-address', replica.ip] >>> + '-w', replica.config.admin_password] >>> if setup_ca: >>> args.append('--setup-ca') >>> if setup_dns: >>> @@ -380,6 +382,14 @@ def install_client(master, client, extra_args=()): >>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>> >>> apply_common_fixes(client) >>> + # Now, for the situations where a client resides in a different subnet from >>> + # master, we need to explicitly tell master to create a reverse zone for >>> + # the client and enable dynamic updates for this zone. >>> + allow_sync_ptr(master) >>> + zone, error = prepare_reverse_zone(master, client.ip) >>> + if not error: >>> + master.run_command(["ipa", "dnszone-mod", zone, >>> + "--dynamic-update=TRUE"], raiseonerr=False) >> >> I believe that this call to dnszone-mod should use raiseonerr=True so you know >> that environment was not configured to accept dynamic updates. > > Agreed. Fixed. > >> >>> >>> client.run_command(['ipa-client-install', '-U', >>> '--domain', client.domain.name, >>> -- 2.4.3 >> >> > -- Petr^2 Spacek From mbasti at redhat.com Mon Feb 1 12:30:24 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Feb 2016 13:30:24 +0100 Subject: [Freeipa-devel] [PATCH 562-563] Fix ipa-sam to use the getkeytab control instead of the setkeytab control In-Reply-To: <20160114090127.GV4316@redhat.com> References: <1449162855.3445.3.camel@redhat.com> <20160114072422.GS4316@redhat.com> <56976257.3040002@redhat.com> <20160114090127.GV4316@redhat.com> Message-ID: <56AF4FE0.4020705@redhat.com> On 14.01.2016 10:01, Alexander Bokovoy wrote: > On Thu, 14 Jan 2016, Martin Basti wrote: >> >> >> On 14.01.2016 08:24, Alexander Bokovoy wrote: >>> On Thu, 03 Dec 2015, Simo Sorce wrote: >>>> The first patch is preparatory and is needed in general now that we >>>> want >>>> top allow alias and use krbCanonicalName as the canonical name when >>>> multiple values are avilable in krbPrincipalName. >>>> >>>> The second patch changes slightly how the interdomain trust account is >>>> created so that the getkeytab control can generate the proper key >>>> (with >>>> the right salt) for interop reasons with AD. The change should be >>>> upgrade safe because keys are generate at account creation so older >>>> accounts lacking the alias won't be a problem. >>>> >>>> Fixes ##5495 >>> This patchset seems to fall through cracks -- it was ACKed but not >>> committed. >> IIRC all simo's ACKed patches which haven't been pushed depend on >> simo's patch 560, which has no ACK >> >> If not then, patches need rebase, they have missing blobs > no, 560 is unrelated. > Pushed to: master: f9ed0b6ff8bf7e59de5450200d9fc5ad6e05299c ipa-4-3: 7e09456d8b80eabb87bb2cf595904b5cc740af8e From mbabinsk at redhat.com Mon Feb 1 12:55:46 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 1 Feb 2016 13:55:46 +0100 Subject: [Freeipa-devel] [PATCH 0132] always start certmonger during IPA server configuration upgrade Message-ID: <56AF55D2.40701@redhat.com> https://fedorahosted.org/freeipa/ticket/5655 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0132-always-start-certmonger-during-IPA-server-configurat.patch Type: text/x-patch Size: 2779 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0132-always-start-certmonger-during-IPA-server-configurat.patch Type: text/x-patch Size: 2775 bytes Desc: not available URL: From mbasti at redhat.com Mon Feb 1 13:18:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Feb 2016 14:18:29 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56A771B8.1000803@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> Message-ID: <56AF5B25.6000706@redhat.com> On 26.01.2016 14:16, Martin Basti wrote: > > > On 20.01.2016 14:38, Jan Cholasta wrote: >> Hi, >> >> On 19.1.2016 13:43, Martin Basti wrote: >>> New pylint version will broke our custom make-lint script again, >>> attached patch migrates make-lint to: >>> * config file >>> * pylint plugin >>> which are supported by pylint and should not have regular compatibility >>> issues >>> >>> to test new approach run ./make-lint2 >>> >>> Advantages: >>> * compatibility with pylint >>> * works on both pylint-1.4.3-3.fc23.noarch and >>> pylint-1.5.2-1.fc24.noarch >>> * pylint plugin works in different way than the previous custom >>> checker. >>> Missing ("dynamic") attributes are added to abstract syntax tree >>> instead >>> of ignoring them and all their sub-members. This makes check better, >>> pylint can detect more typos in tests configurations, api, env, etc.. >>> >>> Disadvantages: >>> * any new attribute in api, test config, etc.. must be added to >>> definition of missing members (pylint plugin) - this should not happen >>> too often >> >> 1) Please "mv pylint_plugins/fix_ipa_members.py pylint_plugins.py" >> and "rm -rf pylint_plugins/", no need for this redundant directory >> structure. >> >> 2) Rename pylintrc to freeipa.pylintrc so you have to always specify >> it explicitly with --rcfile. >> >> 3) Use the load-plugins directive in freeipa.pylintrc to load the >> plugins rather than --load-plugins. >> >> 4) Instead of running pylint twice, run it only once with both normal >> and Python 3 checks enabled: >> >> [MESSAGE CONTROL] >> enable=all,python3 >> disable=...,no-absolute-import >> >>> >>> >>> Q&TODO: >>> * make-lint: should it be just bash script or rather python script? >> >> IMO neither, it should be a make target (make lint). >> >>> * add dynamic detection of python files to be checked >> >> You can use "find . -type f -executable ! -path \*/.\* ! -name >> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >> >>> * should I keep the current options from original make-lint? >> >> No, but allow pylint options to be overridable (make lint >> PYLINTFLAGS="--disable=python3") >> >>> * several false positive errors I haven't been able to fix in plugin >>> yet, in worst case they can be locally disabled: >> >> Disable them locally. >> >> Honza >> > Updated patch attached. > > Please note that make-lint script has been removed, to execute lint > check use 'make lint' > > Updated patch attached: * fixes recently added error * fixes PEP8 * cleanup of pylint config file Patch is only for master branch, for 4.3 and 4.2 I will send different patches when this will be acked -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0407.3-make-lint-use-config-file-and-plugin-for-pylint.patch Type: text/x-patch Size: 26623 bytes Desc: not available URL: From jcholast at redhat.com Mon Feb 1 13:24:05 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 1 Feb 2016 14:24:05 +0100 Subject: [Freeipa-devel] [PATCH 0013-0021] Coverity patches In-Reply-To: <56AF3D46.5060901@redhat.com> References: <56AB6E03.2030601@redhat.com> <56AB7BF0.9030008@redhat.com> <56AB7BFD.1020308@redhat.com> <56AF113D.20804@redhat.com> <56AF3D46.5060901@redhat.com> Message-ID: <56AF5C75.9050409@redhat.com> On 1.2.2016 12:11, Petr Spacek wrote: > On 1.2.2016 09:03, Jan Cholasta wrote: >> Hi, >> >> On 29.1.2016 15:49, Martin Basti wrote: >>> >>> >>> On 29.01.2016 15:49, Stanislav Laznicka wrote: >>>> Reworded the commits so that they better reflect what's going on in those. >>>> >>>> On 01/29/2016 02:49 PM, Stanislav Laznicka wrote: >>>>> Hello, >>>>> >>>>> I made some patches based on the Coverity report from 18.1.2016. >>>>> >>>>> Cheers, >>>>> Standa >>>>> >>>>> >>>> >>>> >>>> >>> NACK, see my previous email >> >> I don't think this deserves 9 patches, 1 would be sufficient enough. > > I would rather have it is separate patches as these fixes are largely not > related. It will make bisecting easier. Most of the fixes are cosmetic, which makes them related, and the rest are small isolated changes, so in reality it would hardly make bisecting easier and only increase the overhead. In the past we usually had put such fixes into a single patch and AFAIK nobody complained so far. > > >> Patch 0013: >> >> 1) I think this unreachable return is intentional, as indicated by the comment: >> >> - #we shouldn't get here >> - return [UNKNOWN_ERROR] > > I would use > assert False, "we shouldn't get here" > neither we nor Coverity are confused when we hit the code path one day. > > UNKNOWN_ERROR would pop up somewhere else and it will be harder to find out > why the hell the code behaves as mad. Traceback will clearly indicate that > there is a problem with the 'switch'. Sure, my point is that returning None is no better than returning UNKNOWN_ERROR. > > Petr^2 Spacek > >> 2) How is this dead code? >> >> - if options.mode == 'validate_pot' or options.mode == 'validate_po': >> + if options.mode in ('validate_pot', 'validate_po'): >> >> - elif options.mode == 'create_test' or 'test_gettext': >> + elif options.mode in ('create_test', 'test_gettext'): >> >> >> >> Patch 0014-0015: LGTM Actually scratch that, patch 0015 breaks correct code. >> >> >> Patch 0016: The original code is in fact correct. >> >> >> Patch 0017: This will break Python 3. The two branches are performing the same >> action, but with different data types. >> >> >> Patch 0018: LGTM >> >> >> Patch 0019: IMO the original code is better (None has a __class__ too, you know). >> >> >> Patch 0020: LGTM >> >> >> Patch 0021: Please use the original error messages (there are no requests >> being added to D-Bus, but to certmonger). >> >> >> Honza > -- Jan Cholasta From mbasti at redhat.com Mon Feb 1 13:45:05 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Feb 2016 14:45:05 +0100 Subject: [Freeipa-devel] [PATCH 542] replica install: validate DS and HTTP server certificates In-Reply-To: <56A87B92.2030101@redhat.com> References: <56A5CEE7.5050806@redhat.com> <56A87B92.2030101@redhat.com> Message-ID: <56AF6161.7040309@redhat.com> On 27.01.2016 09:10, Martin Babinsky wrote: > On 01/25/2016 08:29 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > You may need to rebase the patch on top of ipa-4-2, otherwise ACK. > Pushed to: master: 465ce82a4d098c4c419913f30a1a028afc7ae445 ipa-4-3: 15357aea39eb9e496439e4ef711b97616ef7ee9a ipa-4-2: c2ade68df88e440cd969bede298f0c1feae59fcc From mbasti at redhat.com Mon Feb 1 13:54:20 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Feb 2016 14:54:20 +0100 Subject: [Freeipa-devel] [PATCH 0132] always start certmonger during IPA server configuration upgrade In-Reply-To: <56AF55D2.40701@redhat.com> References: <56AF55D2.40701@redhat.com> Message-ID: <56AF638C.3010801@redhat.com> On 01.02.2016 13:55, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5655 > > > LGTM, works for me, tested on both ca-less server and CA-full server. Because patch is touching certmonger I would like to get final ACK from Honza. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Feb 1 14:15:27 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Feb 2016 15:15:27 +0100 Subject: [Freeipa-devel] [PATCH 0126-0127] reset openldap client config to point to freshly promote replica In-Reply-To: <56AB9C07.7040408@redhat.com> References: <56967E77.8000604@redhat.com> <5696826C.2050300@redhat.com> <5697CD04.3010709@redhat.com> <569F4808.8070100@redhat.com> <56AB1C5C.8020708@redhat.com> <56AB9C07.7040408@redhat.com> Message-ID: <56AF687F.60006@redhat.com> On 29.01.2016 18:06, Martin Basti wrote: > > > On 29.01.2016 09:01, Martin Babinsky wrote: >> On 01/20/2016 09:40 AM, Martin Babinsky wrote: >>> On 01/14/2016 05:29 PM, Martin Babinsky wrote: >>>> On 01/13/2016 05:59 PM, Rob Crittenden wrote: >>>>> Martin Babinsky wrote: >>>>>> fixes https://fedorahosted.org/freeipa/ticket/5584 >>>>>> >>>>>> In order to ensure consistent behavior with ipa-client-install, I >>>>>> opted >>>>>> to reuse the configure_openldap_conf() function and restoring the >>>>>> config >>>>>> from client sysrestore before modifying it. >>>>>> >>>>>> If you think this approach is not optimal please propose an >>>>>> alternative >>>>>> solution. >>>>> >>>>> You could also just do an action set on URI to change the value, >>>>> right? >>>>> It would need a new function but it would be very small. >>>>> >>>>> If you do end up keeping this I'd want a new commit message for >>>>> moving >>>>> the code to include why you're moving it (to avoid the need to >>>>> deference >>>>> the ticket). >>>>> >>>>> rob >>>>> >>>> >>>> Here's the patch that implements the change in URI directive. Please >>>> keep in mind that we not only have to change the URI to point to >>>> ourselves, we also have to do it in a way consistent with >>>> ipa-client-install, i.e. leave a comment with new URI if it was >>>> already >>>> set by third party. >>>> >>>> Plain 'addifnotset' directive will not do, however, because then we >>>> end >>>> up with two comments, one original, and one pointing to ourselves. >>>> Plain >>>> 'set' may rewrite the URI set by user and thus we would have to >>>> test its >>>> value anyway. >>>> >>>> The correct handling of these cases coupled with a way >>>> IPAChangeConf is >>>> written results in a solution presented here. >>>> >>>> The fact that it is not much shorter than configure_openldap_conf >>>> and is >>>> additionally pretty ugly (a fact at least partially caused by me not >>>> being very fluent in IPAChangeConf usage) led me to the conclusion >>>> that >>>> restoring original ldap.conf and reusing already wirrten code for >>>> reediting it anew with replica as URI is actually not that bad idea. >>>> >>>> >>>> >>> >>> Bump for review/discussion. >>> >> Another bump. >> > Works for me, ACK > Pushed to: master: 23f5edb4be08b359c6acd8a18a5e23c3dd784136 ipa-4-3: c61bc48de6a75a948adad2032bd69d96007be444 From mbasti at redhat.com Mon Feb 1 15:06:17 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 1 Feb 2016 16:06:17 +0100 Subject: [Freeipa-devel] [TEST][Patch 0023] Updated connect/disconnect replica to work on both domain levels In-Reply-To: <56AF3FD1.4010107@redhat.com> References: <56AF3FD1.4010107@redhat.com> Message-ID: <56AF7469.4050302@redhat.com> On 01.02.2016 12:21, Oleg Fayans wrote: > > ACK Pushed to: master: aa30199e0b6002aeb8c01e2561a3d55fe3f1ceb5 ipa-4-3: a8775de8aaca56a2f589d5aebe957f78ffc66c16 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Feb 1 17:22:01 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 1 Feb 2016 18:22:01 +0100 Subject: [Freeipa-devel] [PATCH 154] ipa-kdb: map_groups() consider all results In-Reply-To: <20160105185533.GK6480@p.redhat.com> References: <20160105185533.GK6480@p.redhat.com> Message-ID: <20160201172201.GE3824@hendrix.redhat.com> On Tue, Jan 05, 2016 at 07:55:33PM +0100, Sumit Bose wrote: > Hi, > > to find out to which local group a external user is mapped we do a > dereference search over the external groups with the SIDs related to the > external user. If a SID is mapped to more than one external group we > currently consider only the first returned match. With this patch all > results are taken into account. This makes sure all expected local group > memberships are added to the PAC which resolves > https://fedorahosted.org/freeipa/ticket/5573. I tested with an AD user who was a member of several IPA external groups. All groups were displayed. We also have positive feedback from several users who applied this patch. The code looks good to me as well, Sumit explained some parts I didn't understand on IRC. ACK from me.. From abokovoy at redhat.com Tue Feb 2 08:21:15 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 2 Feb 2016 10:21:15 +0200 Subject: [Freeipa-devel] [PATCH 154] ipa-kdb: map_groups() consider all results In-Reply-To: <20160201172201.GE3824@hendrix.redhat.com> References: <20160105185533.GK6480@p.redhat.com> <20160201172201.GE3824@hendrix.redhat.com> Message-ID: <20160202082115.GL23415@redhat.com> On Mon, 01 Feb 2016, Jakub Hrozek wrote: >On Tue, Jan 05, 2016 at 07:55:33PM +0100, Sumit Bose wrote: >> Hi, >> >> to find out to which local group a external user is mapped we do a >> dereference search over the external groups with the SIDs related to the >> external user. If a SID is mapped to more than one external group we >> currently consider only the first returned match. With this patch all >> results are taken into account. This makes sure all expected local group >> memberships are added to the PAC which resolves >> https://fedorahosted.org/freeipa/ticket/5573. > >I tested with an AD user who was a member of several IPA external groups. All >groups were displayed. We also have positive feedback from several users >who applied this patch. > >The code looks good to me as well, Sumit explained some parts I didn't >understand on IRC. > >ACK from me.. ... and ACK from me too. -- / Alexander Bokovoy From jcholast at redhat.com Tue Feb 2 08:33:16 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 2 Feb 2016 09:33:16 +0100 Subject: [Freeipa-devel] [PATCH 0132] always start certmonger during IPA server configuration upgrade In-Reply-To: <56AF638C.3010801@redhat.com> References: <56AF55D2.40701@redhat.com> <56AF638C.3010801@redhat.com> Message-ID: <56B069CC.7030808@redhat.com> On 1.2.2016 14:54, Martin Basti wrote: > > > On 01.02.2016 13:55, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5655 >> >> >> > > LGTM, works for me, tested on both ca-less server and CA-full server. > > Because patch is touching certmonger I would like to get final ACK from > Honza. This is suspicious: - if is_ca_enabled(): - http.configure_certmonger_renewal_guard() + http.configure_certmonger_renewal_guard() Why is it necessary? -- Jan Cholasta From lslebodn at redhat.com Tue Feb 2 08:36:38 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 2 Feb 2016 09:36:38 +0100 Subject: [Freeipa-devel] [PATCH] CONFIGURE: Replace obsolete macros Message-ID: <20160202083637.GA11351@mail.corp.redhat.com> ehlo, The AC_PROG_LIBTOOL macro is obsoleted by since libtool-2.0 which is already in rhel6+ https://fedorahosted.org/FedoraReview/wiki/AutoTools simple patch is attached LS -------------- next part -------------- >From 079fbfa32cb7c70d76828d96f1db3ed05e7e10c0 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Tue, 2 Feb 2016 09:09:03 +0100 Subject: [PATCH] CONFIGURE: Replace obsolete macros The AC_PROG_LIBTOOL macro is obsoleted by since libtool-2.0 which is already in rhel6+ https://fedorahosted.org/FedoraReview/wiki/AutoTools --- asn1/configure.ac | 2 +- client/configure.ac | 3 +-- daemons/configure.ac | 2 +- install/configure.ac | 1 - 4 files changed, 3 insertions(+), 5 deletions(-) diff --git a/asn1/configure.ac b/asn1/configure.ac index c3e398ea20d4112ed8308ba5eb822ab22d256436..c0209142821482b1e76c8eac3d9179224847ff38 100644 --- a/asn1/configure.ac +++ b/asn1/configure.ac @@ -6,7 +6,7 @@ AC_INIT([ipa-server], AC_CONFIG_HEADERS([config.h]) AC_PROG_CC_C99 -AC_PROG_LIBTOOL +LT_INIT AM_INIT_AUTOMAKE([foreign]) diff --git a/client/configure.ac b/client/configure.ac index 8e3a71f7b4c08f4c608606bd8f3ef846daeb9a4c..58f23afa71e9d377afd52c26b6e4c1dfb7b404a6 100644 --- a/client/configure.ac +++ b/client/configure.ac @@ -3,8 +3,7 @@ m4_include(version.m4) AC_INIT([ipa-client], IPA_VERSION, [https://hosted.fedoraproject.org/projects/freeipa/newticket]) -LT_INIT() -AC_PROG_LIBTOOL +LT_INIT AC_CONFIG_HEADERS([config.h]) AC_CONFIG_SUBDIRS([../asn1]) diff --git a/daemons/configure.ac b/daemons/configure.ac index f2eebee51a0b5fd0648c835fd1f44667c5e49068..2a1f6aa8a24188c9b5f2d12fc25dbab079c2247c 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -14,7 +14,7 @@ AM_MAINTAINER_MODE AC_PROG_CC_C99 AC_STDC_HEADERS AC_DISABLE_STATIC -AC_PROG_LIBTOOL +LT_INIT AC_HEADER_STDC diff --git a/install/configure.ac b/install/configure.ac index cf19758a1e24c0682db954bf910120dbd31a05fa..b5f77bf8c737a437fe78ec5bfdc95599fce99760 100644 --- a/install/configure.ac +++ b/install/configure.ac @@ -13,7 +13,6 @@ AM_MAINTAINER_MODE #AC_PROG_CC #AC_STDC_HEADERS #AC_DISABLE_STATIC -#AC_PROG_LIBTOOL #AC_HEADER_STDC -- 2.5.0 From mbabinsk at redhat.com Tue Feb 2 10:41:21 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 2 Feb 2016 11:41:21 +0100 Subject: [Freeipa-devel] [PATCH 0132] always start certmonger during IPA server configuration upgrade In-Reply-To: <56B069CC.7030808@redhat.com> References: <56AF55D2.40701@redhat.com> <56AF638C.3010801@redhat.com> <56B069CC.7030808@redhat.com> Message-ID: <56B087D1.5000009@redhat.com> On 02/02/2016 09:33 AM, Jan Cholasta wrote: > On 1.2.2016 14:54, Martin Basti wrote: >> >> >> On 01.02.2016 13:55, Martin Babinsky wrote: >>> https://fedorahosted.org/freeipa/ticket/5655 >>> >>> >>> >> >> LGTM, works for me, tested on both ca-less server and CA-full server. >> >> Because patch is touching certmonger I would like to get final ACK from >> Honza. > > This is suspicious: > > - if is_ca_enabled(): > - http.configure_certmonger_renewal_guard() > + http.configure_certmonger_renewal_guard() > > Why is it necessary? > I don't know, you tell me: b9ae7690489368ead9f4983d386fa210dc265dfa -- Martin^3 Babinsky From jcholast at redhat.com Tue Feb 2 10:46:56 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 2 Feb 2016 11:46:56 +0100 Subject: [Freeipa-devel] [PATCH 0132] always start certmonger during IPA server configuration upgrade In-Reply-To: <56B087D1.5000009@redhat.com> References: <56AF55D2.40701@redhat.com> <56AF638C.3010801@redhat.com> <56B069CC.7030808@redhat.com> <56B087D1.5000009@redhat.com> Message-ID: <56B08920.6010503@redhat.com> On 2.2.2016 11:41, Martin Babinsky wrote: > On 02/02/2016 09:33 AM, Jan Cholasta wrote: >> On 1.2.2016 14:54, Martin Basti wrote: >>> >>> >>> On 01.02.2016 13:55, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5655 >>>> >>>> >>>> >>> >>> LGTM, works for me, tested on both ca-less server and CA-full server. >>> >>> Because patch is touching certmonger I would like to get final ACK from >>> Honza. >> >> This is suspicious: >> >> - if is_ca_enabled(): >> - http.configure_certmonger_renewal_guard() >> + http.configure_certmonger_renewal_guard() >> >> Why is it necessary? >> > > I don't know, you tell me: > b9ae7690489368ead9f4983d386fa210dc265dfa What I meant is why is the change necessary, not why is the original code necessary. -- Jan Cholasta From jcholast at redhat.com Tue Feb 2 11:18:47 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 2 Feb 2016 12:18:47 +0100 Subject: [Freeipa-devel] [PATCH 0132] always start certmonger during IPA server configuration upgrade In-Reply-To: <56B08920.6010503@redhat.com> References: <56AF55D2.40701@redhat.com> <56AF638C.3010801@redhat.com> <56B069CC.7030808@redhat.com> <56B087D1.5000009@redhat.com> <56B08920.6010503@redhat.com> Message-ID: <56B09097.6060603@redhat.com> On 2.2.2016 11:46, Jan Cholasta wrote: > On 2.2.2016 11:41, Martin Babinsky wrote: >> On 02/02/2016 09:33 AM, Jan Cholasta wrote: >>> On 1.2.2016 14:54, Martin Basti wrote: >>>> >>>> >>>> On 01.02.2016 13:55, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5655 >>>>> >>>>> >>>>> >>>> >>>> LGTM, works for me, tested on both ca-less server and CA-full server. >>>> >>>> Because patch is touching certmonger I would like to get final ACK from >>>> Honza. >>> >>> This is suspicious: >>> >>> - if is_ca_enabled(): >>> - http.configure_certmonger_renewal_guard() >>> + http.configure_certmonger_renewal_guard() >>> >>> Why is it necessary? >>> >> >> I don't know, you tell me: >> b9ae7690489368ead9f4983d386fa210dc265dfa > > What I meant is why is the change necessary, not why is the original > code necessary. Ah, the original code didn't have the condition. LGTM then. -- Jan Cholasta From mbasti at redhat.com Tue Feb 2 11:23:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 2 Feb 2016 12:23:43 +0100 Subject: [Freeipa-devel] [PATCH 0011-0012][RFE] ipa-replica-manage: automatically clean dangling RUVs In-Reply-To: <56AB17E8.4060804@redhat.com> References: <5673F1F9.2030403@redhat.com> <56964AB1.1010902@redhat.com> <56975994.6040604@redhat.com> <5697AF06.3070805@redhat.com> <5697B7CD.6050607@redhat.com> <5697BBBA.60503@redhat.com> <5697C5E3.2010307@redhat.com> <5698EA71.2040105@redhat.com> <56A21F17.40406@redhat.com> <56A64223.4030809@redhat.com> <56A7B365.6090608@redhat.com> <56AB17E8.4060804@redhat.com> Message-ID: <56B091BF.1030506@redhat.com> On 29.01.2016 08:42, Stanislav Laznicka wrote: > On 01/26/2016 06:56 PM, Martin Basti wrote: >> >> >> On 25.01.2016 16:41, Stanislav Laznicka wrote: >>> Hi, >>> >>> Worked those comments into the code. Also added a bit different info >>> message in clean_ruv with ca=True (ipa-replica-manage:430). >>> >>> Also adding stepst to reproduce: >>> 1. Create a master and some replica (3 replicas is a good solution - >>> 1 with CA, 1 without, 1 to be dangling (with CA)) >>> 2. Change domain level to 0 and ipactl restart >>> 3. Remove the "dangling-to-be" replica from masters.ipa.etc and from >>> both ipaca and domain subtrees in mapping tree.config >>> 4. Try to remove the dangling ruvs with the command >>> >>> Cheers, >>> Standa >>> >>> >>> On 01/22/2016 01:22 PM, Martin Basti wrote: >>>> Hello, >>>> >>>> I have a few comments >>>> >>>> PATCH Automatically detect and remove dangling RUVs >>>> >>>> 1) >>>> + # get the Directory Manager password >>>> + if options.dirman_passwd: >>>> + dirman_passwd = options.dirman_passwd >>>> + else: >>>> + dirman_passwd = installutils.read_password('Directory >>>> Manager', >>>> + confirm=False, validate=False, retry=False) >>>> + if dirman_passwd is None: >>>> + sys.exit('Directory Manager password is required') >>>> + >>>> + options.dirman_passwd = dirman_passwd >>>> >>>> IMO you need only else branch here >>>> >>>> if not options.dirman_password: >>>> dirman_passwd = installutils.read_password('Directory Manager', >>>> confirm=False, validate=False, retry=False) >>>> if dirman_passwd is None: >>>> sys.exit('Directory Manager password is required') >>>> options.dirman_passwd = dirman_passwd >>>> >>>> >>>> 2) >>>> We should use new formatting in new code (more times in code) >>>> >>>> + sys.exit( >>>> + "Failed to get data from '%s' while trying to list >>>> replicas: %s" % >>>> + (host, e) >>>> + ) >>>> >>>> sys.exit( >>>> "Failed to get data from '{host}' while trying to list >>>> replicas: {e}".format( >>>> host=host, e=e >>>> ) >>>> ) >>>> >>>> 3) >>>> + # get all masters >>>> + masters_dn = DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', >>>> 'etc'), >>>> + ipautil.realm_to_suffix(realm)) >>>> >>>> IMO you should use constants: >>>> masters_dn = DN(api.env.container_masters, api.env.basedn) >>>> >>>> 4) >>>> + # Get realm string for config tree >>>> + s = realm.split('.') >>>> + s = ['dc={dc},'.format(dc=x.lower()) for x in s] >>>> + realm_config = DN(('cn', ''.join(s)[0:-1])) >>>> >>>> Can be api.env.basedn used instead of this block of code? >>>> >>>> 5) >>>> + masters = [x.single_value['cn'] for x in masters] >>>> .... >>>> + for master in masters: >>>> >>>> is there any reason why not iterate over the keys in info dict? >>>> >>>> for master_name, master_data/values/whatever in info.items(): >>>> master_data['online'] = True >>>> >>>> Looks better than: info[master]['online'] = True >>>> >>>> 6) >>>> I asked python gurus, for empty lists and dicts, please use [] and >>>> {} instead of list() and dict() >>>> It is preferred and faster. >>>> >>>> 7) >>>> + if(info[master]['ca']): >>>> + entry = conn.get_entry(csreplica_dn) >>>> + csruv = (master, >>>> entry.single_value.get('nsDS5ReplicaID')) >>>> + if csruv not in csruvs: >>>> + csruvs.append(csruv) >>>> >>>> I dont like too much adding tuples into list and then doing search >>>> there, but it is as designed >>>> >>>> However can you use set() instead of list when the purpose of >>>> variable is only testing existence? >>>> >>>> related to: >>>> csruvs >>>> ruvs >>>> offlines >>>> clean_list >>>> cleaned >>>> >>>> 8) >>>> conn in finally block may be undefined >>>> >>>> 9) >>>> unused local variables >>>> >>>> clean_list >>>> entry on line 570 >>>> >>>> 10) >>>> optional, comment what keys means in info structure >>>> >>> >> Hello, >> >> 1) >> I accept your silence as the following code cannot use nothing from >> api.env >> + # Get realm string for config tree >> + s = realm.split('.') >> + s = ['dc={dc},'.format(dc=x.lower()) for x in s] >> + realm_config = DN(('cn', ''.join(s)[0:-1])) >> >> but then please use: >> s = ['dc={dc}'.format(dc=x.lower()) for x in s] >> realm_config = DN(('cn', ','.join(s))) >> >> But I still think that api.env.basedn can be used, because it >> contains the same format as you need >> realm_config = DN(('cn', api.env.basedn)) >> > Sorry, forgot to mention that in the last email. However, turns out > you are right. I didn't think DN works like this but it does, so this > is now in it. >> 2) nitpick >> ca_dn = DN(('cn', 'ca'), DN(master.dn)) >> >> AFAIK can be just >> >> ca_dn = DN(('cn', 'ca'), master.dn) >> > My bad, fixed. >> 3) uber nitpick >> This is PEP8 valid, but somehow inconsistent with the rest of code >> and it hit my eyes >> >> print('\t\tid: {id}, hostname: {host}' >> .format(id=csruv[1], host=csruv[0]) >> ) >> >> we use in code >> >> print( >> something1, >> something2 >> ) >> >> or >> >> print(something1, >> something2) >> > And that shouldn't be there anymore, too :) >> Otherwise LGTM > ACK Pushed to: ipa-4-3: 44018142747e933f7d680c8d7bacfbd883ffddf6 master: c8eabaff9ef49d3f51b02d613c25c09bf155bb3c -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Feb 2 11:31:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 2 Feb 2016 12:31:11 +0100 Subject: [Freeipa-devel] [PATCH 0132] always start certmonger during IPA server configuration upgrade In-Reply-To: <56B09097.6060603@redhat.com> References: <56AF55D2.40701@redhat.com> <56AF638C.3010801@redhat.com> <56B069CC.7030808@redhat.com> <56B087D1.5000009@redhat.com> <56B08920.6010503@redhat.com> <56B09097.6060603@redhat.com> Message-ID: <56B0937F.2010708@redhat.com> On 02.02.2016 12:18, Jan Cholasta wrote: > On 2.2.2016 11:46, Jan Cholasta wrote: >> On 2.2.2016 11:41, Martin Babinsky wrote: >>> On 02/02/2016 09:33 AM, Jan Cholasta wrote: >>>> On 1.2.2016 14:54, Martin Basti wrote: >>>>> >>>>> >>>>> On 01.02.2016 13:55, Martin Babinsky wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5655 >>>>>> >>>>>> >>>>>> >>>>> >>>>> LGTM, works for me, tested on both ca-less server and CA-full server. >>>>> >>>>> Because patch is touching certmonger I would like to get final ACK >>>>> from >>>>> Honza. >>>> >>>> This is suspicious: >>>> >>>> - if is_ca_enabled(): >>>> - http.configure_certmonger_renewal_guard() >>>> + http.configure_certmonger_renewal_guard() >>>> >>>> Why is it necessary? >>>> >>> >>> I don't know, you tell me: >>> b9ae7690489368ead9f4983d386fa210dc265dfa >> >> What I meant is why is the change necessary, not why is the original >> code necessary. > > Ah, the original code didn't have the condition. LGTM then. > LGTM + LGTM = ACK :) Pushed to: master: 612f4aa9003658f9a494ec327d50ec5a0592f7b4 ipa-4-3: d99552a8a9f855a7c5e00c4b0736061e05d6ed31 ipa-4-2: 3664efa31edf0dff6dd3410e2eccd12c9cd25782 From slaznick at redhat.com Tue Feb 2 12:36:01 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Tue, 2 Feb 2016 13:36:01 +0100 Subject: [Freeipa-devel] [PATCH 0022-23] Coverity patches In-Reply-To: <56AF5C75.9050409@redhat.com> References: <56AB6E03.2030601@redhat.com> <56AB7BF0.9030008@redhat.com> <56AB7BFD.1020308@redhat.com> <56AF113D.20804@redhat.com> <56AF3D46.5060901@redhat.com> <56AF5C75.9050409@redhat.com> Message-ID: <56B0A2B1.8040507@redhat.com> On 02/01/2016 02:24 PM, Jan Cholasta wrote: > On 1.2.2016 12:11, Petr Spacek wrote: >> On 1.2.2016 09:03, Jan Cholasta wrote: >>> Hi, >>> >>> On 29.1.2016 15:49, Martin Basti wrote: >>>> >>>> >>>> On 29.01.2016 15:49, Stanislav Laznicka wrote: >>>>> Reworded the commits so that they better reflect what's going on >>>>> in those. >>>>> >>>>> On 01/29/2016 02:49 PM, Stanislav Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> I made some patches based on the Coverity report from 18.1.2016. >>>>>> >>>>>> Cheers, >>>>>> Standa >>>>>> >>>>> >>>> NACK, see my previous email >>> >>> I don't think this deserves 9 patches, 1 would be sufficient enough. >> >> I would rather have it is separate patches as these fixes are largely >> not >> related. It will make bisecting easier. > > Most of the fixes are cosmetic, which makes them related, and the rest > are small isolated changes, so in reality it would hardly make > bisecting easier and only increase the overhead. In the past we > usually had put such fixes into a single patch and AFAIK nobody > complained so far. > Squeezed the changes into two new patches, then. One for the very cosmetic changes, one for possible bugs. >> >> >>> Patch 0013: >>> >>> 1) I think this unreachable return is intentional, as indicated by >>> the comment: >>> >>> - #we shouldn't get here >>> - return [UNKNOWN_ERROR] >> >> I would use >> assert False, "we shouldn't get here" >> neither we nor Coverity are confused when we hit the code path one day. >> >> UNKNOWN_ERROR would pop up somewhere else and it will be harder to >> find out >> why the hell the code behaves as mad. Traceback will clearly indicate >> that >> there is a problem with the 'switch'. > > Sure, my point is that returning None is no better than returning > UNKNOWN_ERROR. > Added assert as suggested. There should still be no way of getting to it, though. >> >> Petr^2 Spacek >> >>> 2) How is this dead code? >>> >>> - if options.mode == 'validate_pot' or options.mode == >>> 'validate_po': >>> + if options.mode in ('validate_pot', 'validate_po'): >>> >>> - elif options.mode == 'create_test' or 'test_gettext': >>> + elif options.mode in ('create_test', 'test_gettext'): >>> >>> >>> >>> Patch 0014-0015: LGTM > > Actually scratch that, patch 0015 breaks correct code. > The dead code appears in the 'else' branch as the latter of these two conditions always evaluates to True. The first condition change is just a cosmetic one so that both of the conditions look the same. Also removed the changes made in patch 0015. >>> >>> >>> Patch 0016: The original code is in fact correct. >>> Point taken, removed the change. >>> >>> Patch 0017: This will break Python 3. The two branches are >>> performing the same >>> action, but with different data types. >>> This might undergo further investigation in the future as there is no way how "bytes" instance could become an argument of this function (as suggested). Not even the newest Python 3 patches from pviktori mention this code. >>> >>> Patch 0018: LGTM >>> >>> >>> Patch 0019: IMO the original code is better (None has a __class__ >>> too, you know). >>> Made it more "Coverity friendly" yet nice enough modification. >>> >>> Patch 0020: LGTM >>> It seems that there actually is a check that checks whether the input is correct. It is called ad-hoc but that might be the test feature. Therefore just added an assert so that Coverity does not complain. >>> >>> Patch 0021: Please use the original error messages (there are no >>> requests >>> being added to D-Bus, but to certmonger). >>> >>> >>> Honza >> > Added error messages that reflect the situation better, then. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0022-Cosmetic-changes-to-the-code.patch Type: text/x-patch Size: 4137 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0023-Fixes-minor-issues.patch Type: text/x-patch Size: 3747 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Feb 2 14:36:25 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 2 Feb 2016 15:36:25 +0100 Subject: [Freeipa-devel] [PATCH 0133] re-add missing fixture import to the CA ACL plugin test Message-ID: <56B0BEE9.1050204@redhat.com> This was causing some of the CA ACL plugin tests to fail/error. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0133-re-add-missing-fixture-import-to-the-CA-ACL-plugin-t.patch Type: text/x-patch Size: 1027 bytes Desc: not available URL: From mkubik at redhat.com Tue Feb 2 14:48:41 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 2 Feb 2016 15:48:41 +0100 Subject: [Freeipa-devel] [PATCH 0133] re-add missing fixture import to the CA ACL plugin test In-Reply-To: <56B0BEE9.1050204@redhat.com> References: <56B0BEE9.1050204@redhat.com> Message-ID: <56B0C1C9.9050802@redhat.com> On 02/02/2016 03:36 PM, Martin Babinsky wrote: > This was causing some of the CA ACL plugin tests to fail/error. > Possible NACK. This is not an officially supported way how to reuse fixtures. [1] I was working on a fix, that would contain all of the needed fixtures in the module that requires them. See patch attached. However, this way kind of breaks DRY principle. The official conftest.py way is not practical for us, though. [1]: http://pytest.org/latest/fixture.html#using-fixtures-from-classes-modules-or-projects -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0032-ipatests-Add-missing-certificate-profile-fixture.patch Type: text/x-patch Size: 1468 bytes Desc: not available URL: From mbasti at redhat.com Tue Feb 2 14:53:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 2 Feb 2016 15:53:13 +0100 Subject: [Freeipa-devel] [PATCH] typo in service Message-ID: <56B0C2D9.8050800@redhat.com> I acked&pushed patch attached to ticket: https://fedorahosted.org/freeipa/ticket/5659 Pushed to master: d85d70947361abd3822b8f42fa3de16e26e87d57 Martin^2 From pspacek at redhat.com Tue Feb 2 16:23:17 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 2 Feb 2016 17:23:17 +0100 Subject: [Freeipa-devel] [PATCH 0085] Fix ipa-adtrust-install to always generate SRV records with FQDN Message-ID: <56B0D7F5.30709@redhat.com> Hello, Fix ipa-adtrust-install to always generate SRV records with FQDNs Previous code failed in following setup: * IPA domain = ipa.example.com * IPA master = vm1.example.com * IPA replica = vm2.example.com https://fedorahosted.org/freeipa/ticket/5663 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0085-Fix-ipa-adtrust-install-to-always-generate-SRV-recor.patch Type: text/x-patch Size: 1754 bytes Desc: not available URL: From lslebodn at redhat.com Tue Feb 2 16:28:28 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 2 Feb 2016 17:28:28 +0100 Subject: [Freeipa-devel] [PATCH] IPA-SAM: Fix build with samba 4.4 In-Reply-To: <20160129111218.GD24839@mail.corp.redhat.com> References: <20160129111218.GD24839@mail.corp.redhat.com> Message-ID: <20160202162827.GF28330@mail.corp.redhat.com> On (29/01/16 12:12), Lukas Slebodnik wrote: >ehlo, > >attached patch shoudl fix build on fedora-24. >It blocks static analysis scan. > >Even though it unblock build on fedora-24 >the solution is not ideal. It's possible that some changes >need to be done in samba side as well. >(missing prototypes for trim_string, smb_xstrdup > >LS >>From f9057ca98557094a4db84ac072ee9efd02a4ff79 Mon Sep 17 00:00:00 2001 >From: Lukas Slebodnik >Date: Fri, 29 Jan 2016 10:40:18 +0100 >Subject: [PATCH 1/3] IPA-SAM: Fix build with samba 4.4 > >samba_util.h is not shipped with samba-4.4 >and it was indirectly included by "ndr.h" > >Some functions have prototypes in different header file >"util/talloc_stack.h" and other does not have declarations >in other header file. But they are still part of libsamba-util.so > >sh$ objdump -T /usr/lib64/libsamba-util.so.0.0.1 | grep -E "trim_s|xstrdup" >0000000000022200 g DF .text 000000000000001f SAMBA_UTIL_0.0.1 smb_xstrdup >00000000000223b0 g DF .text 000000000000019d SAMBA_UTIL_0.0.1 trim_string > >ipa_sam.c: In function 'ldapsam_uid_to_sid': >ipa_sam.c:836:24: warning: implicit declaration of function 'talloc_stackframe' > [-Wimplicit-function-declaration] > TALLOC_CTX *tmp_ctx = talloc_stackframe(); > ^ >ipa_sam.c: In function 'pdb_init_ipasam': >ipa_sam.c:4493:2: warning: implicit declaration of function 'trim_string' > [-Wimplicit-function-declaration] > trim_string( uri, "\"", "\"" ); > ^ >ipa_sam.c:4580:26: warning: implicit declaration of function 'smb_xstrdup' > [-Wimplicit-function-declaration] > ldap_state->domain_dn = smb_xstrdup(dn); > ^ >--- > daemons/ipa-sam/ipa_sam.c | 6 ++++++ > 1 file changed, 6 insertions(+) > >diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c >index 7274d600b532f1066661e8a614a47eea7632ed70..871775b0a19e9c273652ff7a0b497d86bb866aa6 100644 >--- a/daemons/ipa-sam/ipa_sam.c >+++ b/daemons/ipa-sam/ipa_sam.c >@@ -19,6 +19,12 @@ > #include > #include > #include >+#include >+ >+#ifndef _SAMBA_UTIL_H_ >+bool trim_string(char *s, const char *front, const char *back); >+char *smb_xstrdup(const char *s); >+#endif Bump, it would be good to unblock static analysis scans. LS From abokovoy at redhat.com Tue Feb 2 16:54:15 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 2 Feb 2016 18:54:15 +0200 Subject: [Freeipa-devel] [PATCH] IPA-SAM: Fix build with samba 4.4 In-Reply-To: <20160202162827.GF28330@mail.corp.redhat.com> References: <20160129111218.GD24839@mail.corp.redhat.com> <20160202162827.GF28330@mail.corp.redhat.com> Message-ID: <20160202165415.GD22179@redhat.com> On Tue, 02 Feb 2016, Lukas Slebodnik wrote: >On (29/01/16 12:12), Lukas Slebodnik wrote: >>ehlo, >> >>attached patch shoudl fix build on fedora-24. >>It blocks static analysis scan. >> >>Even though it unblock build on fedora-24 >>the solution is not ideal. It's possible that some changes >>need to be done in samba side as well. >>(missing prototypes for trim_string, smb_xstrdup >> >>LS > >>>From f9057ca98557094a4db84ac072ee9efd02a4ff79 Mon Sep 17 00:00:00 2001 >>From: Lukas Slebodnik >>Date: Fri, 29 Jan 2016 10:40:18 +0100 >>Subject: [PATCH 1/3] IPA-SAM: Fix build with samba 4.4 >> >>samba_util.h is not shipped with samba-4.4 >>and it was indirectly included by "ndr.h" >> >>Some functions have prototypes in different header file >>"util/talloc_stack.h" and other does not have declarations >>in other header file. But they are still part of libsamba-util.so >> >>sh$ objdump -T /usr/lib64/libsamba-util.so.0.0.1 | grep -E "trim_s|xstrdup" >>0000000000022200 g DF .text 000000000000001f SAMBA_UTIL_0.0.1 smb_xstrdup >>00000000000223b0 g DF .text 000000000000019d SAMBA_UTIL_0.0.1 trim_string >> >>ipa_sam.c: In function 'ldapsam_uid_to_sid': >>ipa_sam.c:836:24: warning: implicit declaration of function 'talloc_stackframe' >> [-Wimplicit-function-declaration] >> TALLOC_CTX *tmp_ctx = talloc_stackframe(); >> ^ >>ipa_sam.c: In function 'pdb_init_ipasam': >>ipa_sam.c:4493:2: warning: implicit declaration of function 'trim_string' >> [-Wimplicit-function-declaration] >> trim_string( uri, "\"", "\"" ); >> ^ >>ipa_sam.c:4580:26: warning: implicit declaration of function 'smb_xstrdup' >> [-Wimplicit-function-declaration] >> ldap_state->domain_dn = smb_xstrdup(dn); >> ^ >>--- >> daemons/ipa-sam/ipa_sam.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >>diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c >>index 7274d600b532f1066661e8a614a47eea7632ed70..871775b0a19e9c273652ff7a0b497d86bb866aa6 100644 >>--- a/daemons/ipa-sam/ipa_sam.c >>+++ b/daemons/ipa-sam/ipa_sam.c >>@@ -19,6 +19,12 @@ >> #include >> #include >> #include >>+#include >>+ >>+#ifndef _SAMBA_UTIL_H_ >>+bool trim_string(char *s, const char *front, const char *back); >>+char *smb_xstrdup(const char *s); >>+#endif >Bump, >it would be good to unblock static analysis scans. Yes, ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Feb 2 16:55:13 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 2 Feb 2016 18:55:13 +0200 Subject: [Freeipa-devel] [PATCH 0085] Fix ipa-adtrust-install to always generate SRV records with FQDN In-Reply-To: <56B0D7F5.30709@redhat.com> References: <56B0D7F5.30709@redhat.com> Message-ID: <20160202165513.GE22179@redhat.com> On Tue, 02 Feb 2016, Petr Spacek wrote: >Hello, > >Fix ipa-adtrust-install to always generate SRV records with FQDNs > >Previous code failed in following setup: >* IPA domain = ipa.example.com >* IPA master = vm1.example.com >* IPA replica = vm2.example.com > >https://fedorahosted.org/freeipa/ticket/5663 > >-- >Petr^2 Spacek >From d4d13e003b9fb7153e27691d67246b0dfa4b51ac Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Tue, 2 Feb 2016 17:20:21 +0100 >Subject: [PATCH] Fix ipa-adtrust-install to always generate SRV records with > FQDNs > >Previous code failed in following setup: >* IPA domain = ipa.example.com >* IPA master = vm1.example.com >* IPA replica = vm2.example.com > >https://fedorahosted.org/freeipa/ticket/5663 >--- > ipaserver/install/adtrustinstance.py | 9 ++------- > 1 file changed, 2 insertions(+), 7 deletions(-) > >diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py >index 118f848cf33c3126d42ccda555a8308f52d2c390..9e7e001f7c505d09d5a61164399e9ed256ae9865 100644 >--- a/ipaserver/install/adtrustinstance.py >+++ b/ipaserver/install/adtrustinstance.py >@@ -571,12 +571,7 @@ class ADTRUSTInstance(service.Service): > """ > > zone = self.domain_name >- host, host_domain = self.fqdn.split(".", 1) >- >- if normalize_zone(zone) == normalize_zone(host_domain): >- host_in_rr = host >- else: >- host_in_rr = normalize_zone(self.fqdn) >+ host_in_rr = normalize_zone(self.fqdn) > > priority = 0 > >@@ -707,7 +702,7 @@ class ADTRUSTInstance(service.Service): > # this is CIFS service of a different host in our > # REALM, we need to remember it to announce via > # SRV records for _msdcs >- self.cifs_hosts.append(fqdn.split(".")[0]) >+ self.cifs_hosts.append(normalize_zone(fqdn)) > > except Exception as e: > root_logger.critical("Checking replicas for cifs principals failed with error '%s'" % e) >-- >2.5.0 > ACK. -- / Alexander Bokovoy From pvoborni at redhat.com Tue Feb 2 17:16:05 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 2 Feb 2016 18:16:05 +0100 Subject: [Freeipa-devel] [PATCH 154] ipa-kdb: map_groups() consider all results In-Reply-To: <20160202082115.GL23415@redhat.com> References: <20160105185533.GK6480@p.redhat.com> <20160201172201.GE3824@hendrix.redhat.com> <20160202082115.GL23415@redhat.com> Message-ID: <56B0E455.2040608@redhat.com> On 02/02/2016 09:21 AM, Alexander Bokovoy wrote: > On Mon, 01 Feb 2016, Jakub Hrozek wrote: >> On Tue, Jan 05, 2016 at 07:55:33PM +0100, Sumit Bose wrote: >>> Hi, >>> >>> to find out to which local group a external user is mapped we do a >>> dereference search over the external groups with the SIDs related to the >>> external user. If a SID is mapped to more than one external group we >>> currently consider only the first returned match. With this patch all >>> results are taken into account. This makes sure all expected local group >>> memberships are added to the PAC which resolves >>> https://fedorahosted.org/freeipa/ticket/5573. >> >> I tested with an AD user who was a member of several IPA external >> groups. All >> groups were displayed. We also have positive feedback from several users >> who applied this patch. >> >> The code looks good to me as well, Sumit explained some parts I didn't >> understand on IRC. >> >> ACK from me.. > ... and ACK from me too. Pushed to: master: 348c400484cafe4969c3fa0c9f0c6f6e150df821 ipa-4-3: d6e81749c3d5904cfae59921802895b6cff528ff ipa-4-2: d70c86f71a405984db24947a8e1c0caebdc499c8 -- Petr Vobornik From pvoborni at redhat.com Tue Feb 2 17:22:00 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 2 Feb 2016 18:22:00 +0100 Subject: [Freeipa-devel] [PATCH 0085] Fix ipa-adtrust-install to always generate SRV records with FQDN In-Reply-To: <20160202165513.GE22179@redhat.com> References: <56B0D7F5.30709@redhat.com> <20160202165513.GE22179@redhat.com> Message-ID: <56B0E5B8.201@redhat.com> On 02/02/2016 05:55 PM, Alexander Bokovoy wrote: > On Tue, 02 Feb 2016, Petr Spacek wrote: >> Hello, >> >> Fix ipa-adtrust-install to always generate SRV records with FQDNs >> >> Previous code failed in following setup: >> * IPA domain = ipa.example.com >> * IPA master = vm1.example.com >> * IPA replica = vm2.example.com >> >> https://fedorahosted.org/freeipa/ticket/5663 >> >> -- >> Petr^2 Spacek > >> From d4d13e003b9fb7153e27691d67246b0dfa4b51ac Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Tue, 2 Feb 2016 17:20:21 +0100 >> Subject: [PATCH] Fix ipa-adtrust-install to always generate SRV >> records with >> FQDNs >> >> Previous code failed in following setup: >> * IPA domain = ipa.example.com >> * IPA master = vm1.example.com >> * IPA replica = vm2.example.com >> >> https://fedorahosted.org/freeipa/ticket/5663 >> --- >> ipaserver/install/adtrustinstance.py | 9 ++------- >> 1 file changed, 2 insertions(+), 7 deletions(-) >> >> diff --git a/ipaserver/install/adtrustinstance.py >> b/ipaserver/install/adtrustinstance.py >> index >> 118f848cf33c3126d42ccda555a8308f52d2c390..9e7e001f7c505d09d5a61164399e9ed256ae9865 >> 100644 >> --- a/ipaserver/install/adtrustinstance.py >> +++ b/ipaserver/install/adtrustinstance.py >> @@ -571,12 +571,7 @@ class ADTRUSTInstance(service.Service): >> """ >> >> zone = self.domain_name >> - host, host_domain = self.fqdn.split(".", 1) >> - >> - if normalize_zone(zone) == normalize_zone(host_domain): >> - host_in_rr = host >> - else: >> - host_in_rr = normalize_zone(self.fqdn) >> + host_in_rr = normalize_zone(self.fqdn) >> >> priority = 0 >> >> @@ -707,7 +702,7 @@ class ADTRUSTInstance(service.Service): >> # this is CIFS service of a different host >> in our >> # REALM, we need to remember it to >> announce via >> # SRV records for _msdcs >> - self.cifs_hosts.append(fqdn.split(".")[0]) >> + self.cifs_hosts.append(normalize_zone(fqdn)) >> >> except Exception as e: >> root_logger.critical("Checking replicas for cifs >> principals failed with error '%s'" % e) >> -- >> 2.5.0 >> > ACK. Pushed to: master: 72e4a360fc0a31dd53d257350b3f490cc3ed07e4 ipa-4-3: 0256f6be1d241645cc974b0bfb5767de8aa2a6fc -- Petr Vobornik From pvoborni at redhat.com Tue Feb 2 17:36:15 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 2 Feb 2016 18:36:15 +0100 Subject: [Freeipa-devel] [PATCH] IPA-SAM: Fix build with samba 4.4 In-Reply-To: <20160202165415.GD22179@redhat.com> References: <20160129111218.GD24839@mail.corp.redhat.com> <20160202162827.GF28330@mail.corp.redhat.com> <20160202165415.GD22179@redhat.com> Message-ID: <56B0E90F.4090907@redhat.com> On 02/02/2016 05:54 PM, Alexander Bokovoy wrote: > On Tue, 02 Feb 2016, Lukas Slebodnik wrote: >> On (29/01/16 12:12), Lukas Slebodnik wrote: >>> ehlo, >>> >>> attached patch shoudl fix build on fedora-24. >>> It blocks static analysis scan. >>> >>> Even though it unblock build on fedora-24 >>> the solution is not ideal. It's possible that some changes >>> need to be done in samba side as well. >>> (missing prototypes for trim_string, smb_xstrdup >>> >>> LS >> >>>> From f9057ca98557094a4db84ac072ee9efd02a4ff79 Mon Sep 17 00:00:00 2001 >>> From: Lukas Slebodnik >>> Date: Fri, 29 Jan 2016 10:40:18 +0100 >>> Subject: [PATCH 1/3] IPA-SAM: Fix build with samba 4.4 >>> >>> samba_util.h is not shipped with samba-4.4 >>> and it was indirectly included by "ndr.h" >>> >>> Some functions have prototypes in different header file >>> "util/talloc_stack.h" and other does not have declarations >>> in other header file. But they are still part of libsamba-util.so >>> >>> sh$ objdump -T /usr/lib64/libsamba-util.so.0.0.1 | grep -E >>> "trim_s|xstrdup" >>> 0000000000022200 g DF .text 000000000000001f SAMBA_UTIL_0.0.1 >>> smb_xstrdup >>> 00000000000223b0 g DF .text 000000000000019d SAMBA_UTIL_0.0.1 >>> trim_string >>> >>> ipa_sam.c: In function 'ldapsam_uid_to_sid': >>> ipa_sam.c:836:24: warning: implicit declaration of function >>> 'talloc_stackframe' >>> [-Wimplicit-function-declaration] >>> TALLOC_CTX *tmp_ctx = talloc_stackframe(); >>> ^ >>> ipa_sam.c: In function 'pdb_init_ipasam': >>> ipa_sam.c:4493:2: warning: implicit declaration of function >>> 'trim_string' >>> [-Wimplicit-function-declaration] >>> trim_string( uri, "\"", "\"" ); >>> ^ >>> ipa_sam.c:4580:26: warning: implicit declaration of function >>> 'smb_xstrdup' >>> [-Wimplicit-function-declaration] >>> ldap_state->domain_dn = smb_xstrdup(dn); >>> ^ >>> --- >>> daemons/ipa-sam/ipa_sam.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c >>> index >>> 7274d600b532f1066661e8a614a47eea7632ed70..871775b0a19e9c273652ff7a0b497d86bb866aa6 >>> 100644 >>> --- a/daemons/ipa-sam/ipa_sam.c >>> +++ b/daemons/ipa-sam/ipa_sam.c >>> @@ -19,6 +19,12 @@ >>> #include >>> #include >>> #include >>> +#include >>> + >>> +#ifndef _SAMBA_UTIL_H_ >>> +bool trim_string(char *s, const char *front, const char *back); >>> +char *smb_xstrdup(const char *s); >>> +#endif >> Bump, >> it would be good to unblock static analysis scans. > Yes, ACK. Pushed to: master: 017b343e13bbfdd0d9951417be8dac4614cb1416 ipa-4-3: 69cc457504306ec1f90d844efa1e4b422564f06d -- Petr Vobornik From pvoborni at redhat.com Tue Feb 2 17:46:17 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 2 Feb 2016 18:46:17 +0100 Subject: [Freeipa-devel] [PATCH] 0003 webui: Issue New Certificate dialogs validates data In-Reply-To: <56AB37AC.1080006@redhat.com> References: <1126773777.16508720.1453726505512.JavaMail.zimbra@redhat.com> <56AA5DC1.6050200@redhat.com> <56AB37AC.1080006@redhat.com> Message-ID: <56B0EB69.4000206@redhat.com> On 01/29/2016 10:58 AM, Pavel Vomacka wrote: > > > On 01/28/2016 07:28 PM, Petr Vobornik wrote: >> Hi, there are few issues, NACK. >> >> 1. this patch uses tabs instead of spaces, previous was correct > Fixed. >> >> 2. code which focuses first invalid field could be replaced by: >> widget_mod.focus_invalid(that); > The old loop is replaced by this method. >> >> 3. there is a convention that field and widget names uses the same >> name as the param, therefore 'textarea_cert' should be 'csr'. There is >> no convention for messages in html widget but it might be better to >> use a name reflecting purpose and not implementation. Instead of >> 'message_html_widget' use 'instructions' or just 'message' - >> consistent with spec option. >> > Fixed. I chose 'message' instead of 'message_html_widget'. >> Also I've filed: https://fedorahosted.org/freeipa/ticket/5652 > Pavel Vomacka > > ACK Pushed to master: fb3b7f7d93060d42e9cc79768f72e0b2d4b0481f -- Petr Vobornik From dkupka at redhat.com Wed Feb 3 09:19:51 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 3 Feb 2016 10:19:51 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56AF5B25.6000706@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> <56AF5B25.6000706@redhat.com> Message-ID: <56B1C637.1000403@redhat.com> On 01/02/16 14:18, Martin Basti wrote: > > > On 26.01.2016 14:16, Martin Basti wrote: >> >> >> On 20.01.2016 14:38, Jan Cholasta wrote: >>> Hi, >>> >>> On 19.1.2016 13:43, Martin Basti wrote: >>>> New pylint version will broke our custom make-lint script again, >>>> attached patch migrates make-lint to: >>>> * config file >>>> * pylint plugin >>>> which are supported by pylint and should not have regular compatibility >>>> issues >>>> >>>> to test new approach run ./make-lint2 >>>> >>>> Advantages: >>>> * compatibility with pylint >>>> * works on both pylint-1.4.3-3.fc23.noarch and >>>> pylint-1.5.2-1.fc24.noarch >>>> * pylint plugin works in different way than the previous custom >>>> checker. >>>> Missing ("dynamic") attributes are added to abstract syntax tree >>>> instead >>>> of ignoring them and all their sub-members. This makes check better, >>>> pylint can detect more typos in tests configurations, api, env, etc.. >>>> >>>> Disadvantages: >>>> * any new attribute in api, test config, etc.. must be added to >>>> definition of missing members (pylint plugin) - this should not happen >>>> too often >>> >>> 1) Please "mv pylint_plugins/fix_ipa_members.py pylint_plugins.py" >>> and "rm -rf pylint_plugins/", no need for this redundant directory >>> structure. >>> >>> 2) Rename pylintrc to freeipa.pylintrc so you have to always specify >>> it explicitly with --rcfile. >>> >>> 3) Use the load-plugins directive in freeipa.pylintrc to load the >>> plugins rather than --load-plugins. >>> >>> 4) Instead of running pylint twice, run it only once with both normal >>> and Python 3 checks enabled: >>> >>> [MESSAGE CONTROL] >>> enable=all,python3 >>> disable=...,no-absolute-import >>> >>>> >>>> >>>> Q&TODO: >>>> * make-lint: should it be just bash script or rather python script? >>> >>> IMO neither, it should be a make target (make lint). >>> >>>> * add dynamic detection of python files to be checked >>> >>> You can use "find . -type f -executable ! -path \*/.\* ! -name >>> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >>> >>>> * should I keep the current options from original make-lint? >>> >>> No, but allow pylint options to be overridable (make lint >>> PYLINTFLAGS="--disable=python3") >>> >>>> * several false positive errors I haven't been able to fix in plugin >>>> yet, in worst case they can be locally disabled: >>> >>> Disable them locally. >>> >>> Honza >>> >> Updated patch attached. >> >> Please note that make-lint script has been removed, to execute lint >> check use 'make lint' >> >> > > Updated patch attached: > * fixes recently added error > * fixes PEP8 > * cleanup of pylint config file > > Patch is only for master branch, for 4.3 and 4.2 I will send different > patches when this will be acked > > Could you please add an extensive comment to the 4-lines-long find command? I can after a while (and with the help of man page) decode what it does so it would definitely help to have it described. Otherwise it looks good to me. -- David Kupka From ofayans at redhat.com Wed Feb 3 09:22:42 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 3 Feb 2016 10:22:42 +0100 Subject: [Freeipa-devel] [TEST][Patch 0022] small refactoring in integration tests due to BZ 1303095 In-Reply-To: <56AB80BE.4090604@redhat.com> References: <56AB80BE.4090604@redhat.com> Message-ID: <56B1C6E2.60106@redhat.com> Guys, can anyone take a look at this? On 01/29/2016 04:09 PM, Oleg Fayans wrote: > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pspacek at redhat.com Wed Feb 3 13:19:08 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 3 Feb 2016 14:19:08 +0100 Subject: [Freeipa-devel] [TEST][Patch 0022] small refactoring in integration tests due to BZ 1303095 In-Reply-To: <56B1C6E2.60106@redhat.com> References: <56AB80BE.4090604@redhat.com> <56B1C6E2.60106@redhat.com> Message-ID: <56B1FE4C.4080600@redhat.com> On 3.2.2016 10:22, Oleg Fayans wrote: > Guys, can anyone take a look at this? The commit message does not explain why you are setting search path. I have to say that I do not like touching resolv.conf, as stated many times earlier. Why the test has to reconfigure the host and cannot use values provided by the provisioning system? -- Petr^2 Spacek From lslebodn at redhat.com Wed Feb 3 13:30:37 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 3 Feb 2016 14:30:37 +0100 Subject: [Freeipa-devel] [PATCH] IPA-SAM: Fix build with samba 4.4 In-Reply-To: <20160129175913.GC21804@redhat.com> References: <20160129111218.GD24839@mail.corp.redhat.com> <20160129113147.GF24839@mail.corp.redhat.com> <20160129175913.GC21804@redhat.com> Message-ID: <20160203133037.GB2962@mail.corp.redhat.com> On (29/01/16 19:59), Alexander Bokovoy wrote: >On Fri, 29 Jan 2016, Lukas Slebodnik wrote: >>On (29/01/16 12:12), Lukas Slebodnik wrote: >>>ehlo, >>> >>>attached patch shoudl fix build on fedora-24. >>>It blocks static analysis scan. >>> >>>Even though it unblock build on fedora-24 >>>the solution is not ideal. It's possible that some changes >>>need to be done in samba side as well. >>>(missing prototypes for trim_string, smb_xstrdup >>> >>>LS >> >>BTW there is also another issue in IPA-SAM. >>The value of macro LDAP_PAGE_SIZE has changed >>and therefore there is a warning. >> >>ipa_sam.c:114:0: warning: "LDAP_PAGE_SIZE" redefined >>#define LDAP_PAGE_SIZE 1024 >>^ >>In file included from /usr/include/samba-4.0/smbldap.h:24:0, >> from ipa_sam.c:31: >>/usr/include/samba-4.0/smb_ldap.h:81:0: note: this is the location of the previous definition >>#define LDAP_PAGE_SIZE 1000 >This is something we should fix. I'll look at it once in Brno. Here is a related change in samba https://github.com/samba-team/samba/commit/8c2609f3186d40afb5954737dc174ce190cd368a LS From cheimes at redhat.com Wed Feb 3 14:35:08 2016 From: cheimes at redhat.com (Christian Heimes) Date: Wed, 3 Feb 2016 15:35:08 +0100 Subject: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites In-Reply-To: <56AB71BF.9070009@redhat.com> References: <56A0F78F.4060407@redhat.com> <56A21343.2090607@redhat.com> <56A9D59F.4020204@redhat.com> <56AB6C2A.2040604@redhat.com> <56AB71BF.9070009@redhat.com> Message-ID: <56B2101C.3020008@redhat.com> On 2016-01-29 15:05, Martin Basti wrote: > > > On 29.01.2016 14:42, Christian Heimes wrote: >> On 2016-01-28 09:47, Martin Basti wrote: >>> >>> On 22.01.2016 12:32, Martin Kosek wrote: >>>> On 01/21/2016 04:21 PM, Christian Heimes wrote: >>>>> The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf >>>>> has been modernized. Insecure or less secure algorithms such as RC4, >>>>> DES and 3DES are removed. Perfect forward secrecy suites with >>>>> ephemeral >>>>> ECDH key exchange have been added. IE 8 on Windows XP is no longer >>>>> supported. >>>>> >>>>> The list of enabled cipher suites has been generated with the script >>>>> contrib/nssciphersuite/nssciphersuite.py. >>>>> >>>>> The supported suites are currently: >>>>> >>>>> TLS_RSA_WITH_AES_128_CBC_SHA256 >>>>> TLS_RSA_WITH_AES_256_CBC_SHA256 >>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA >>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA >>>>> TLS_RSA_WITH_AES_128_GCM_SHA256 >>>>> TLS_RSA_WITH_AES_128_CBC_SHA >>>>> TLS_RSA_WITH_AES_256_GCM_SHA384 >>>>> TLS_RSA_WITH_AES_256_CBC_SHA >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5589 >>>> Thanks for the patch! I updated the ticket to make sure this change is >>>> release notes. >>>> >>> Hello, >>> >>> I'm not sure if I'm the right person to do review on this, but I will >>> try :-) >>> >>> 1) >>> Your patch adds whitespace error >>> >>> Applying: Modernize mod_nss's cipher suites >>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:52: new blank >>> line at EOF. >>> + >>> warning: 1 line adds whitespace errors. >>> >>> >>> 2) >>> +import urllib.request # pylint: disable=E0611 >>> >>> Please specify pylint disabled check by name >>> >>> 3) >>> +def update_mod_nss_cipher_suite(http): >>> >>> in this upgrade, is there any possibility that ciphers might be upgraded >>> again in future? (IMO yes). >>> >>> I think, it can be better to store revision of change instead of boolean >>> >>> LAST_REVISION = 1 >>> >>> if revision >= LAST_REVISION: >>> return >>> >>> sysupgrade.set_upgrade_state('nss.conf', 'cipher_suite_revision', >>> LAST_REVISION) >> Thanks for the review. I have addressed the problems. Instead of a >> revision number I'm using a date string. The sysupgrade module only >> stores str and bool. With a date-based revision it's easy to see when >> the cipher suite was checked last time. >> >> Christian >> > > Thanks > > 1) Pylint :-) > + with urllib.request.urlopen(SOURCE) as r: # pylint: disable=E1101 Thanks! It was easier to change the import to get rid of the second pylint stanza. > 2) > + if revision == httpinstance.NSS_CIPHER_REVISION: > > may happen a case where just comparation with '==' can cause a issues > (docker world)? Should not be there rather '>='? Makes sense, I've changed the comparison operator to >=. This may still override user settings, though. > > 3) > + root_logger.info("Cipher suite already updated") > > Sorry that I did not noticed earlier, this should be just debug level, > IMO this message is not so important, it will cause only mess on output > (we already have plenty of unneeded info messages in upgrade, they will > be fixed once) Fine with me :) Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0030-3-Modernize-mod_nss-s-cipher-suites.patch Type: text/x-patch Size: 12022 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 pvomacka at redhat.com Wed Feb 3 14:37:02 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 3 Feb 2016 15:37:02 +0100 Subject: [Freeipa-devel] [PATCH] 0004 webui: topology graph: Add pan and zoom functionality Message-ID: <56B2108E.2@redhat.com> Hello, I'm sending a patch for review. This patch adds pan and zoom functionality to the topology graph. The page remembers old position and size of the graph. So, it keeps these settings after refreshing the page. The patch is in atachement. Pavel Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0004-Add-pan-and-zoom-functionality-to-the-topology-graph.patch Type: text/x-patch Size: 6268 bytes Desc: not available URL: From ofayans at redhat.com Thu Feb 4 07:49:51 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 4 Feb 2016 08:49:51 +0100 Subject: [Freeipa-devel] [TEST][Patch 0022] small refactoring in integration tests due to BZ 1303095 In-Reply-To: <56B1FE4C.4080600@redhat.com> References: <56AB80BE.4090604@redhat.com> <56B1C6E2.60106@redhat.com> <56B1FE4C.4080600@redhat.com> Message-ID: <56B3029F.70001@redhat.com> Hi Petr, On 02/03/2016 02:19 PM, Petr Spacek wrote: > On 3.2.2016 10:22, Oleg Fayans wrote: >> Guys, can anyone take a look at this? > > The commit message does not explain why you are setting search path. Fixed. > > I have to say that I do not like touching resolv.conf, as stated many times > earlier. Why the test has to reconfigure the host and cannot use values > provided by the provisioning system? This patch exactly removes this messing around with nameservers in resolv.conf It introduces the possibility to put ipa domain in the search directive of resolv.conf so that we could test service autodiscovery during client installation. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0022.1-Moved-NM-configuration-calls-to-the-IntegrationTest.patch Type: text/x-patch Size: 3592 bytes Desc: not available URL: From jcholast at redhat.com Thu Feb 4 08:40:17 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 4 Feb 2016 09:40:17 +0100 Subject: [Freeipa-devel] [PATCH 544] replica promotion: fix AVC denials in remote connection check Message-ID: <56B30E71.7080909@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-544-replica-promotion-fix-AVC-denials-in-remote-connecti.patch Type: text/x-patch Size: 2491 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Feb 4 10:18:21 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 4 Feb 2016 11:18:21 +0100 Subject: [Freeipa-devel] [PATCH 544] replica promotion: fix AVC denials in remote connection check In-Reply-To: <56B30E71.7080909@redhat.com> References: <56B30E71.7080909@redhat.com> Message-ID: <56B3256D.5080303@redhat.com> On 02/04/2016 09:40 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > Connection check for replica/CA install now works in enforcing mode, ACK. -- Martin^3 Babinsky From ofayans at redhat.com Thu Feb 4 12:49:36 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 4 Feb 2016 13:49:36 +0100 Subject: [Freeipa-devel] [TEST][Patch 0021] Fixed recent replica installation issues in the lab In-Reply-To: <56AF45C4.9040404@redhat.com> References: <56A0D223.2060702@redhat.com> <56A0FC2C.2010004@redhat.com> <56A87E93.9030302@redhat.com> <56A898E5.9060202@redhat.com> <56AB45BB.3070102@redhat.com> <56AF38D0.8010004@redhat.com> <56AF45C4.9040404@redhat.com> Message-ID: <56B348E0.70301@redhat.com> Hi Petr, An updated patch is attached. Please see my comment inline. On 02/01/2016 12:47 PM, Petr Spacek wrote: > On 1.2.2016 11:52, Oleg Fayans wrote: >> Hi Petr, >> >> Please find the new version of the patch attached. Comments are inline >> >> On 01/29/2016 11:58 AM, Petr Spacek wrote: >>> On 27.1.2016 11:16, Oleg Fayans wrote: >>>> Sorry, trailing whitespace detected. This version passes lint >>>> >>>> On 01/27/2016 09:23 AM, Oleg Fayans wrote: >>>>>> Hi, >>>>>> >>>>>> On 01/21/2016 04:41 PM, Petr Spacek wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> On 21.1.2016 13:42, Oleg Fayans wrote: >>>>>>>>>> freeipa-ofayans-0021-Removed-ip-address-option-from-replica-installation.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From d7ab06a4dcddb919fda351b983d478f1b6968578 Mon Sep 17 00:00:00 2001 >>>>>>>>>> From: Oleg Fayans >>>>>>>>>> Date: Thu, 21 Jan 2016 13:30:02 +0100 >>>>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>>>> >>>>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>>>>> >>>>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>>>> master >>>>>>>>>> --- >>>>>>>>>> ipatests/test_integration/tasks.py | 19 ++++++++++++------- >>>>>>>>>> 1 file changed, 12 insertions(+), 7 deletions(-) >>>>>>>>>> >>>>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..43ef78b0c55deed24a0444f0ac6c38ddb2517481 100644 >>>>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>>>> @@ -69,6 +69,8 @@ def prepare_reverse_zone(host, ip): >>>>>>>>>> host.run_command(["ipa", >>>>>>>>>> "dnszone-add", >>>>>>>>>> zone], raiseonerr=False) >>>>>>>>>> + return zone >>>>>>>>>> + >>>>>>>>>> >>>>>>>>>> def prepare_host(host): >>>>>>>>>> if isinstance(host, Host): >>>>>>>>>> @@ -319,11 +321,8 @@ def domainlevel(host): >>>>>>>>>> def replica_prepare(master, replica): >>>>>>>>>> apply_common_fixes(replica) >>>>>>>>>> fix_apache_semaphores(replica) >>>>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>>>> - master.run_command(['ipa-replica-prepare', >>>>>>>>>> - '-p', replica.config.dirman_password, >>>>>>>>>> - '--ip-address', replica.ip, >>>>>>>>>> - replica.hostname]) >>>>>>>>>> + master.run_command(['ipa-replica-prepare', '-p', replica.config.dirman_password, >>>>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>>> >>>>>>>> I guess that you will need --ip-address option in cases where master's reverse >>>>>>>> record does not exist (yet). >>>>>> And yo were right. Fixed >>>>>> >>>>>>>> >>>>>>>> I would recommend you to test this in libvirt or somewhere without revere >>>>>>>> records, I suspect that it might blow up. >>>>>>>> >>>>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>>>> @@ -339,8 +338,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>>>> # and replica installation would fail >>>>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>>>> '-p', replica.config.dirman_password, >>>>>>>>>> - '-w', replica.config.admin_password, >>>>>>>>>> - '--ip-address', replica.ip] >>>>>>>>>> + '-w', replica.config.admin_password] >>>>>>>>>> if setup_ca: >>>>>>>>>> args.append('--setup-ca') >>>>>>>>>> if setup_dns: >>>>>>>>>> @@ -380,6 +378,13 @@ def install_client(master, client, extra_args=()): >>>>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>>>> >>>>>>>>>> apply_common_fixes(client) >>>>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>>>> + allow_sync_ptr(master) >>>>>>>>>> + zone = prepare_reverse_zone(master, client.ip) >>>>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>>>> >>>>>>>> I'm not a big fan of ignoring exceptions here, it might be better to >>>>>>>> encapsulate the first command with try: except: and run the zone-mod only if >>>>>>>> the add worked as expected. >>>>>>>> >>>>>>>> Also, logging an message that reverse zone was not added might be a good idea. >>>>>> Agreed. Done. >>>>>> >>>>>>>> >>>>>>>> HTH >>>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>>>> '--domain', client.domain.name, >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. >>>> >>>> >>>> freeipa-ofayans-0021.2-Removed-ip-address-option-from-replica-installation.patch >>>> >>>> >>>> From e70daf4ed9dfbac7e8ea75cb8e9ab0f2af12ad48 Mon Sep 17 00:00:00 2001 >>>> From: Oleg Fayans >>>> Date: Wed, 27 Jan 2016 11:09:03 +0100 >>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>> >>>> Explicitly specifying ip-address of the replica messes up with the current >>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>> >>> NACK >>> >>> The commit message and logic is incorrect. In fact it has nothing to do with >>> bind-dyndb-ldap. Either: >>> a] The zone already exists somewhere so you should not create it in IPA, and >>> this --ip-address option is invalid. >>> b] The zone does not exist yet and then --ip-address option is required. >>> >>> I do not see any logic around >>>> '--ip-address', replica.ip, >> >> The explicit ip-address passing was removed (that's the main point of >> this patch) > > Sure, but it cannot be done unconditionally (without additional logic). Fair point. Implemented a check whether ipa master is authoritative for the client's domain. > >>> thus the NACK. >>> >>> >>> In other words, network setup is job for a provisioning system. IPA needs to >>> respect whatever the provisioning system did or did not do. > > Let me rephrase it: > If IPA DNS manages the zone with replica FQDN or associated reverse zone, we > need the --ip-address option. > > If IPA does not manage any of these, we do not need --ip-address option. > >>> Feel free to ask if something is unclear. > > Petr^2 Spacek > >>> (other comments inline) >>> >>> >>>> >>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>> master >>>> --- >>>> ipatests/test_integration/tasks.py | 20 +++++++++++++++----- >>>> 1 file changed, 15 insertions(+), 5 deletions(-) >>>> >>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..b8b7fcfcbbb1dc672349119bbbb4cdbbd68c54ec 100644 >>>> --- a/ipatests/test_integration/tasks.py >>>> +++ b/ipatests/test_integration/tasks.py >>>> @@ -66,9 +66,13 @@ def check_arguments_are(slice, instanceof): >>>> >>>> def prepare_reverse_zone(host, ip): >>>> zone = get_reverse_zone_default(ip) >>>> - host.run_command(["ipa", >>>> + result = host.run_command(["ipa", >>>> "dnszone-add", >>>> zone], raiseonerr=False) >>>> + if result.returncode > 0: >>>> + log.warn(result.stderr_text) >>>> + return zone, result.returncode >>>> + >>>> >>>> def prepare_host(host): >>>> if isinstance(host, Host): >>>> @@ -319,11 +323,10 @@ def domainlevel(host): >>>> def replica_prepare(master, replica): >>>> apply_common_fixes(replica) >>>> fix_apache_semaphores(replica) >>>> - prepare_reverse_zone(master, replica.ip) >>>> master.run_command(['ipa-replica-prepare', >>>> '-p', replica.config.dirman_password, >>>> '--ip-address', replica.ip, >>>> - replica.hostname]) >>>> + '--auto-reverse', replica.hostname]) >>>> replica_bundle = master.get_file_contents( >>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>> replica_filename = get_replica_filename(replica) >>>> @@ -339,8 +342,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>> # and replica installation would fail >>>> args = ['ipa-replica-install', '-U', >>>> '-p', replica.config.dirman_password, >>>> - '-w', replica.config.admin_password, >>>> - '--ip-address', replica.ip] >>>> + '-w', replica.config.admin_password] >>>> if setup_ca: >>>> args.append('--setup-ca') >>>> if setup_dns: >>>> @@ -380,6 +382,14 @@ def install_client(master, client, extra_args=()): >>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>> >>>> apply_common_fixes(client) >>>> + # Now, for the situations where a client resides in a different subnet from >>>> + # master, we need to explicitly tell master to create a reverse zone for >>>> + # the client and enable dynamic updates for this zone. >>>> + allow_sync_ptr(master) >>>> + zone, error = prepare_reverse_zone(master, client.ip) >>>> + if not error: >>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>> >>> I believe that this call to dnszone-mod should use raiseonerr=True so you know >>> that environment was not configured to accept dynamic updates. >> >> Agreed. Fixed. >> >>> >>>> >>>> client.run_command(['ipa-client-install', '-U', >>>> '--domain', client.domain.name, >>>> -- 2.4.3 >>> >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0021.4-Removed-ip-address-option-from-replica-installation.patch Type: text/x-patch Size: 4107 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 4 13:07:59 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 4 Feb 2016 14:07:59 +0100 Subject: [Freeipa-devel] [TEST][Patch 0021] Fixed recent replica installation issues in the lab In-Reply-To: <56B348E0.70301@redhat.com> References: <56A0D223.2060702@redhat.com> <56A0FC2C.2010004@redhat.com> <56A87E93.9030302@redhat.com> <56A898E5.9060202@redhat.com> <56AB45BB.3070102@redhat.com> <56AF38D0.8010004@redhat.com> <56AF45C4.9040404@redhat.com> <56B348E0.70301@redhat.com> Message-ID: <56B34D2F.5040708@redhat.com> On 04.02.2016 13:49, Oleg Fayans wrote: > Hi Petr, > > An updated patch is attached. Please see my comment inline. > > On 02/01/2016 12:47 PM, Petr Spacek wrote: >> On 1.2.2016 11:52, Oleg Fayans wrote: >>> Hi Petr, >>> >>> Please find the new version of the patch attached. Comments are inline >>> >>> On 01/29/2016 11:58 AM, Petr Spacek wrote: >>>> On 27.1.2016 11:16, Oleg Fayans wrote: >>>>> Sorry, trailing whitespace detected. This version passes lint >>>>> >>>>> On 01/27/2016 09:23 AM, Oleg Fayans wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 01/21/2016 04:41 PM, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> On 21.1.2016 13:42, Oleg Fayans wrote: >>>>>>>>>>> freeipa-ofayans-0021-Removed-ip-address-option-from-replica-installation.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> From d7ab06a4dcddb919fda351b983d478f1b6968578 Mon Sep 17 00:00:00 2001 >>>>>>>>>>> From: Oleg Fayans >>>>>>>>>>> Date: Thu, 21 Jan 2016 13:30:02 +0100 >>>>>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>>>>> >>>>>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>>>>>> >>>>>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>>>>> master >>>>>>>>>>> --- >>>>>>>>>>> ipatests/test_integration/tasks.py | 19 ++++++++++++------- >>>>>>>>>>> 1 file changed, 12 insertions(+), 7 deletions(-) >>>>>>>>>>> >>>>>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..43ef78b0c55deed24a0444f0ac6c38ddb2517481 100644 >>>>>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>>>>> @@ -69,6 +69,8 @@ def prepare_reverse_zone(host, ip): >>>>>>>>>>> host.run_command(["ipa", >>>>>>>>>>> "dnszone-add", >>>>>>>>>>> zone], raiseonerr=False) >>>>>>>>>>> + return zone >>>>>>>>>>> + >>>>>>>>>>> >>>>>>>>>>> def prepare_host(host): >>>>>>>>>>> if isinstance(host, Host): >>>>>>>>>>> @@ -319,11 +321,8 @@ def domainlevel(host): >>>>>>>>>>> def replica_prepare(master, replica): >>>>>>>>>>> apply_common_fixes(replica) >>>>>>>>>>> fix_apache_semaphores(replica) >>>>>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>>>>> - master.run_command(['ipa-replica-prepare', >>>>>>>>>>> - '-p', replica.config.dirman_password, >>>>>>>>>>> - '--ip-address', replica.ip, >>>>>>>>>>> - replica.hostname]) >>>>>>>>>>> + master.run_command(['ipa-replica-prepare', '-p', replica.config.dirman_password, >>>>>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>>>> I guess that you will need --ip-address option in cases where master's reverse >>>>>>>>> record does not exist (yet). >>>>>>> And yo were right. Fixed >>>>>>> >>>>>>>>> I would recommend you to test this in libvirt or somewhere without revere >>>>>>>>> records, I suspect that it might blow up. >>>>>>>>> >>>>>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>>>>> @@ -339,8 +338,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>>>>> # and replica installation would fail >>>>>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>>>>> '-p', replica.config.dirman_password, >>>>>>>>>>> - '-w', replica.config.admin_password, >>>>>>>>>>> - '--ip-address', replica.ip] >>>>>>>>>>> + '-w', replica.config.admin_password] >>>>>>>>>>> if setup_ca: >>>>>>>>>>> args.append('--setup-ca') >>>>>>>>>>> if setup_dns: >>>>>>>>>>> @@ -380,6 +378,13 @@ def install_client(master, client, extra_args=()): >>>>>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>>>>> >>>>>>>>>>> apply_common_fixes(client) >>>>>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>>>>> + allow_sync_ptr(master) >>>>>>>>>>> + zone = prepare_reverse_zone(master, client.ip) >>>>>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>>>>> I'm not a big fan of ignoring exceptions here, it might be better to >>>>>>>>> encapsulate the first command with try: except: and run the zone-mod only if >>>>>>>>> the add worked as expected. >>>>>>>>> >>>>>>>>> Also, logging an message that reverse zone was not added might be a good idea. >>>>>>> Agreed. Done. >>>>>>> >>>>>>>>> HTH >>>>>>>>> >>>>>>>>> Petr^2 Spacek >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>>>>> '--domain', client.domain.name, >>>>>>> >>>>>>> >>>>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. >>>>> >>>>> >>>>> freeipa-ofayans-0021.2-Removed-ip-address-option-from-replica-installation.patch >>>>> >>>>> >>>>> From e70daf4ed9dfbac7e8ea75cb8e9ab0f2af12ad48 Mon Sep 17 00:00:00 2001 >>>>> From: Oleg Fayans >>>>> Date: Wed, 27 Jan 2016 11:09:03 +0100 >>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>> >>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>> NACK >>>> >>>> The commit message and logic is incorrect. In fact it has nothing to do with >>>> bind-dyndb-ldap. Either: >>>> a] The zone already exists somewhere so you should not create it in IPA, and >>>> this --ip-address option is invalid. >>>> b] The zone does not exist yet and then --ip-address option is required. >>>> >>>> I do not see any logic around >>>>> '--ip-address', replica.ip, >>> The explicit ip-address passing was removed (that's the main point of >>> this patch) >> Sure, but it cannot be done unconditionally (without additional logic). > Fair point. Implemented a check whether ipa master is authoritative for > the client's domain. > >>>> thus the NACK. >>>> >>>> >>>> In other words, network setup is job for a provisioning system. IPA needs to >>>> respect whatever the provisioning system did or did not do. >> Let me rephrase it: >> If IPA DNS manages the zone with replica FQDN or associated reverse zone, we >> need the --ip-address option. >> >> If IPA does not manage any of these, we do not need --ip-address option. >> >>>> Feel free to ask if something is unclear. >> Petr^2 Spacek >> >>>> (other comments inline) >>>> >>>> >>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>> master >>>>> --- >>>>> ipatests/test_integration/tasks.py | 20 +++++++++++++++----- >>>>> 1 file changed, 15 insertions(+), 5 deletions(-) >>>>> >>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..b8b7fcfcbbb1dc672349119bbbb4cdbbd68c54ec 100644 >>>>> --- a/ipatests/test_integration/tasks.py >>>>> +++ b/ipatests/test_integration/tasks.py >>>>> @@ -66,9 +66,13 @@ def check_arguments_are(slice, instanceof): >>>>> >>>>> def prepare_reverse_zone(host, ip): >>>>> zone = get_reverse_zone_default(ip) >>>>> - host.run_command(["ipa", >>>>> + result = host.run_command(["ipa", >>>>> "dnszone-add", >>>>> zone], raiseonerr=False) >>>>> + if result.returncode > 0: >>>>> + log.warn(result.stderr_text) >>>>> + return zone, result.returncode >>>>> + >>>>> >>>>> def prepare_host(host): >>>>> if isinstance(host, Host): >>>>> @@ -319,11 +323,10 @@ def domainlevel(host): >>>>> def replica_prepare(master, replica): >>>>> apply_common_fixes(replica) >>>>> fix_apache_semaphores(replica) >>>>> - prepare_reverse_zone(master, replica.ip) >>>>> master.run_command(['ipa-replica-prepare', >>>>> '-p', replica.config.dirman_password, >>>>> '--ip-address', replica.ip, >>>>> - replica.hostname]) >>>>> + '--auto-reverse', replica.hostname]) >>>>> replica_bundle = master.get_file_contents( >>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>> replica_filename = get_replica_filename(replica) >>>>> @@ -339,8 +342,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>> # and replica installation would fail >>>>> args = ['ipa-replica-install', '-U', >>>>> '-p', replica.config.dirman_password, >>>>> - '-w', replica.config.admin_password, >>>>> - '--ip-address', replica.ip] >>>>> + '-w', replica.config.admin_password] >>>>> if setup_ca: >>>>> args.append('--setup-ca') >>>>> if setup_dns: >>>>> @@ -380,6 +382,14 @@ def install_client(master, client, extra_args=()): >>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>> >>>>> apply_common_fixes(client) >>>>> + # Now, for the situations where a client resides in a different subnet from >>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>> + # the client and enable dynamic updates for this zone. >>>>> + allow_sync_ptr(master) >>>>> + zone, error = prepare_reverse_zone(master, client.ip) >>>>> + if not error: >>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>> I believe that this call to dnszone-mod should use raiseonerr=True so you know >>>> that environment was not configured to accept dynamic updates. >>> Agreed. Fixed. >>> >>>>> >>>>> client.run_command(['ipa-client-install', '-U', >>>>> '--domain', client.domain.name, >>>>> -- 2.4.3 >>>> >> > > > + log.warn(result.stderr_text) warn is deprecated, please use log.warning instead Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofayans at redhat.com Thu Feb 4 14:38:15 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 4 Feb 2016 15:38:15 +0100 Subject: [Freeipa-devel] [TEST][Patch 0021] Fixed recent replica installation issues in the lab In-Reply-To: <56B34D2F.5040708@redhat.com> References: <56A0D223.2060702@redhat.com> <56A0FC2C.2010004@redhat.com> <56A87E93.9030302@redhat.com> <56A898E5.9060202@redhat.com> <56AB45BB.3070102@redhat.com> <56AF38D0.8010004@redhat.com> <56AF45C4.9040404@redhat.com> <56B348E0.70301@redhat.com> <56B34D2F.5040708@redhat.com> Message-ID: <56B36257.2020003@redhat.com> Hi, On 02/04/2016 02:07 PM, Martin Basti wrote: > > > On 04.02.2016 13:49, Oleg Fayans wrote: >> Hi Petr, >> >> An updated patch is attached. Please see my comment inline. >> >> On 02/01/2016 12:47 PM, Petr Spacek wrote: >>> On 1.2.2016 11:52, Oleg Fayans wrote: >>>> Hi Petr, >>>> >>>> Please find the new version of the patch attached. Comments are inline >>>> >>>> On 01/29/2016 11:58 AM, Petr Spacek wrote: >>>>> On 27.1.2016 11:16, Oleg Fayans wrote: >>>>>> Sorry, trailing whitespace detected. This version passes lint >>>>>> >>>>>> On 01/27/2016 09:23 AM, Oleg Fayans wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 01/21/2016 04:41 PM, Petr Spacek wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> On 21.1.2016 13:42, Oleg Fayans wrote: >>>>>>>>>>>> freeipa-ofayans-0021-Removed-ip-address-option-from-replica-installation.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From d7ab06a4dcddb919fda351b983d478f1b6968578 Mon Sep 17 00:00:00 2001 >>>>>>>>>>>> From: Oleg Fayans >>>>>>>>>>>> Date: Thu, 21 Jan 2016 13:30:02 +0100 >>>>>>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>>>>>> >>>>>>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>>>>>>> >>>>>>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>>>>>> master >>>>>>>>>>>> --- >>>>>>>>>>>> ipatests/test_integration/tasks.py | 19 ++++++++++++------- >>>>>>>>>>>> 1 file changed, 12 insertions(+), 7 deletions(-) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..43ef78b0c55deed24a0444f0ac6c38ddb2517481 100644 >>>>>>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>>>>>> @@ -69,6 +69,8 @@ def prepare_reverse_zone(host, ip): >>>>>>>>>>>> host.run_command(["ipa", >>>>>>>>>>>> "dnszone-add", >>>>>>>>>>>> zone], raiseonerr=False) >>>>>>>>>>>> + return zone >>>>>>>>>>>> + >>>>>>>>>>>> >>>>>>>>>>>> def prepare_host(host): >>>>>>>>>>>> if isinstance(host, Host): >>>>>>>>>>>> @@ -319,11 +321,8 @@ def domainlevel(host): >>>>>>>>>>>> def replica_prepare(master, replica): >>>>>>>>>>>> apply_common_fixes(replica) >>>>>>>>>>>> fix_apache_semaphores(replica) >>>>>>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>>>>>> - master.run_command(['ipa-replica-prepare', >>>>>>>>>>>> - '-p', replica.config.dirman_password, >>>>>>>>>>>> - '--ip-address', replica.ip, >>>>>>>>>>>> - replica.hostname]) >>>>>>>>>>>> + master.run_command(['ipa-replica-prepare', '-p', replica.config.dirman_password, >>>>>>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>>>>> I guess that you will need --ip-address option in cases where master's reverse >>>>>>>>>> record does not exist (yet). >>>>>>>> And yo were right. Fixed >>>>>>>> >>>>>>>>>> I would recommend you to test this in libvirt or somewhere without revere >>>>>>>>>> records, I suspect that it might blow up. >>>>>>>>>> >>>>>>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>>>>>> @@ -339,8 +338,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>>>>>> # and replica installation would fail >>>>>>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>>>>>> '-p', replica.config.dirman_password, >>>>>>>>>>>> - '-w', replica.config.admin_password, >>>>>>>>>>>> - '--ip-address', replica.ip] >>>>>>>>>>>> + '-w', replica.config.admin_password] >>>>>>>>>>>> if setup_ca: >>>>>>>>>>>> args.append('--setup-ca') >>>>>>>>>>>> if setup_dns: >>>>>>>>>>>> @@ -380,6 +378,13 @@ def install_client(master, client, extra_args=()): >>>>>>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>>>>>> >>>>>>>>>>>> apply_common_fixes(client) >>>>>>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>>>>>> + allow_sync_ptr(master) >>>>>>>>>>>> + zone = prepare_reverse_zone(master, client.ip) >>>>>>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>>>>>> I'm not a big fan of ignoring exceptions here, it might be better to >>>>>>>>>> encapsulate the first command with try: except: and run the zone-mod only if >>>>>>>>>> the add worked as expected. >>>>>>>>>> >>>>>>>>>> Also, logging an message that reverse zone was not added might be a good idea. >>>>>>>> Agreed. Done. >>>>>>>> >>>>>>>>>> HTH >>>>>>>>>> >>>>>>>>>> Petr^2 Spacek >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>>>>>> '--domain', client.domain.name, >>>>>>>> >>>>>>>> >>>>>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. >>>>>> >>>>>> >>>>>> freeipa-ofayans-0021.2-Removed-ip-address-option-from-replica-installation.patch >>>>>> >>>>>> >>>>>> From e70daf4ed9dfbac7e8ea75cb8e9ab0f2af12ad48 Mon Sep 17 00:00:00 2001 >>>>>> From: Oleg Fayans >>>>>> Date: Wed, 27 Jan 2016 11:09:03 +0100 >>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>> >>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>> NACK >>>>> >>>>> The commit message and logic is incorrect. In fact it has nothing to do with >>>>> bind-dyndb-ldap. Either: >>>>> a] The zone already exists somewhere so you should not create it in IPA, and >>>>> this --ip-address option is invalid. >>>>> b] The zone does not exist yet and then --ip-address option is required. >>>>> >>>>> I do not see any logic around >>>>>> '--ip-address', replica.ip, >>>> The explicit ip-address passing was removed (that's the main point of >>>> this patch) >>> Sure, but it cannot be done unconditionally (without additional logic). >> Fair point. Implemented a check whether ipa master is authoritative for >> the client's domain. >> >>>>> thus the NACK. >>>>> >>>>> >>>>> In other words, network setup is job for a provisioning system. IPA needs to >>>>> respect whatever the provisioning system did or did not do. >>> Let me rephrase it: >>> If IPA DNS manages the zone with replica FQDN or associated reverse zone, we >>> need the --ip-address option. >>> >>> If IPA does not manage any of these, we do not need --ip-address option. >>> >>>>> Feel free to ask if something is unclear. >>> Petr^2 Spacek >>> >>>>> (other comments inline) >>>>> >>>>> >>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>> master >>>>>> --- >>>>>> ipatests/test_integration/tasks.py | 20 +++++++++++++++----- >>>>>> 1 file changed, 15 insertions(+), 5 deletions(-) >>>>>> >>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..b8b7fcfcbbb1dc672349119bbbb4cdbbd68c54ec 100644 >>>>>> --- a/ipatests/test_integration/tasks.py >>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>> @@ -66,9 +66,13 @@ def check_arguments_are(slice, instanceof): >>>>>> >>>>>> def prepare_reverse_zone(host, ip): >>>>>> zone = get_reverse_zone_default(ip) >>>>>> - host.run_command(["ipa", >>>>>> + result = host.run_command(["ipa", >>>>>> "dnszone-add", >>>>>> zone], raiseonerr=False) >>>>>> + if result.returncode > 0: >>>>>> + log.warn(result.stderr_text) >>>>>> + return zone, result.returncode >>>>>> + >>>>>> >>>>>> def prepare_host(host): >>>>>> if isinstance(host, Host): >>>>>> @@ -319,11 +323,10 @@ def domainlevel(host): >>>>>> def replica_prepare(master, replica): >>>>>> apply_common_fixes(replica) >>>>>> fix_apache_semaphores(replica) >>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>> master.run_command(['ipa-replica-prepare', >>>>>> '-p', replica.config.dirman_password, >>>>>> '--ip-address', replica.ip, >>>>>> - replica.hostname]) >>>>>> + '--auto-reverse', replica.hostname]) >>>>>> replica_bundle = master.get_file_contents( >>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>> replica_filename = get_replica_filename(replica) >>>>>> @@ -339,8 +342,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>> # and replica installation would fail >>>>>> args = ['ipa-replica-install', '-U', >>>>>> '-p', replica.config.dirman_password, >>>>>> - '-w', replica.config.admin_password, >>>>>> - '--ip-address', replica.ip] >>>>>> + '-w', replica.config.admin_password] >>>>>> if setup_ca: >>>>>> args.append('--setup-ca') >>>>>> if setup_dns: >>>>>> @@ -380,6 +382,14 @@ def install_client(master, client, extra_args=()): >>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>> >>>>>> apply_common_fixes(client) >>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>> + # the client and enable dynamic updates for this zone. >>>>>> + allow_sync_ptr(master) >>>>>> + zone, error = prepare_reverse_zone(master, client.ip) >>>>>> + if not error: >>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>> I believe that this call to dnszone-mod should use raiseonerr=True so you know >>>>> that environment was not configured to accept dynamic updates. >>>> Agreed. Fixed. >>>> >>>>>> >>>>>> client.run_command(['ipa-client-install', '-U', >>>>>> '--domain', client.domain.name, >>>>>> -- 2.4.3 >>>>> >>> >> >> > >> + log.warn(result.stderr_text) > > warn is deprecated, please use log.warning instead Fixed > > Martin^2 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0021.5-Removed-ip-address-option-from-replica-installation.patch Type: text/x-patch Size: 4110 bytes Desc: not available URL: From pspacek at redhat.com Thu Feb 4 14:43:51 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 4 Feb 2016 15:43:51 +0100 Subject: [Freeipa-devel] [TEST][Patch 0021] Fixed recent replica installation issues in the lab In-Reply-To: <56B36257.2020003@redhat.com> References: <56A0D223.2060702@redhat.com> <56A0FC2C.2010004@redhat.com> <56A87E93.9030302@redhat.com> <56A898E5.9060202@redhat.com> <56AB45BB.3070102@redhat.com> <56AF38D0.8010004@redhat.com> <56AF45C4.9040404@redhat.com> <56B348E0.70301@redhat.com> <56B34D2F.5040708@redhat.com> <56B36257.2020003@redhat.com> Message-ID: <56B363A7.2090905@redhat.com> On 4.2.2016 15:38, Oleg Fayans wrote: > Hi, > > On 02/04/2016 02:07 PM, Martin Basti wrote: >> >> >> On 04.02.2016 13:49, Oleg Fayans wrote: >>> Hi Petr, >>> >>> An updated patch is attached. Please see my comment inline. >>> >>> On 02/01/2016 12:47 PM, Petr Spacek wrote: >>>> On 1.2.2016 11:52, Oleg Fayans wrote: >>>>> Hi Petr, >>>>> >>>>> Please find the new version of the patch attached. Comments are inline >>>>> >>>>> On 01/29/2016 11:58 AM, Petr Spacek wrote: >>>>>> On 27.1.2016 11:16, Oleg Fayans wrote: >>>>>>> Sorry, trailing whitespace detected. This version passes lint >>>>>>> >>>>>>> On 01/27/2016 09:23 AM, Oleg Fayans wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 01/21/2016 04:41 PM, Petr Spacek wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> On 21.1.2016 13:42, Oleg Fayans wrote: >>>>>>>>>>>>> freeipa-ofayans-0021-Removed-ip-address-option-from-replica-installation.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> From d7ab06a4dcddb919fda351b983d478f1b6968578 Mon Sep 17 00:00:00 2001 >>>>>>>>>>>>> From: Oleg Fayans >>>>>>>>>>>>> Date: Thu, 21 Jan 2016 13:30:02 +0100 >>>>>>>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>>>>>>> >>>>>>>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>>>>>>>> >>>>>>>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>>>>>>> master >>>>>>>>>>>>> --- >>>>>>>>>>>>> ipatests/test_integration/tasks.py | 19 ++++++++++++------- >>>>>>>>>>>>> 1 file changed, 12 insertions(+), 7 deletions(-) >>>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..43ef78b0c55deed24a0444f0ac6c38ddb2517481 100644 >>>>>>>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>>>>>>> @@ -69,6 +69,8 @@ def prepare_reverse_zone(host, ip): >>>>>>>>>>>>> host.run_command(["ipa", >>>>>>>>>>>>> "dnszone-add", >>>>>>>>>>>>> zone], raiseonerr=False) >>>>>>>>>>>>> + return zone >>>>>>>>>>>>> + >>>>>>>>>>>>> >>>>>>>>>>>>> def prepare_host(host): >>>>>>>>>>>>> if isinstance(host, Host): >>>>>>>>>>>>> @@ -319,11 +321,8 @@ def domainlevel(host): >>>>>>>>>>>>> def replica_prepare(master, replica): >>>>>>>>>>>>> apply_common_fixes(replica) >>>>>>>>>>>>> fix_apache_semaphores(replica) >>>>>>>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>>>>>>> - master.run_command(['ipa-replica-prepare', >>>>>>>>>>>>> - '-p', replica.config.dirman_password, >>>>>>>>>>>>> - '--ip-address', replica.ip, >>>>>>>>>>>>> - replica.hostname]) >>>>>>>>>>>>> + master.run_command(['ipa-replica-prepare', '-p', replica.config.dirman_password, >>>>>>>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>>>>>> I guess that you will need --ip-address option in cases where master's reverse >>>>>>>>>>> record does not exist (yet). >>>>>>>>> And yo were right. Fixed >>>>>>>>> >>>>>>>>>>> I would recommend you to test this in libvirt or somewhere without revere >>>>>>>>>>> records, I suspect that it might blow up. >>>>>>>>>>> >>>>>>>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>>>>>>> @@ -339,8 +338,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>>>>>>> # and replica installation would fail >>>>>>>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>>>>>>> '-p', replica.config.dirman_password, >>>>>>>>>>>>> - '-w', replica.config.admin_password, >>>>>>>>>>>>> - '--ip-address', replica.ip] >>>>>>>>>>>>> + '-w', replica.config.admin_password] >>>>>>>>>>>>> if setup_ca: >>>>>>>>>>>>> args.append('--setup-ca') >>>>>>>>>>>>> if setup_dns: >>>>>>>>>>>>> @@ -380,6 +378,13 @@ def install_client(master, client, extra_args=()): >>>>>>>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>>>>>>> >>>>>>>>>>>>> apply_common_fixes(client) >>>>>>>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>>>>>>> + allow_sync_ptr(master) >>>>>>>>>>>>> + zone = prepare_reverse_zone(master, client.ip) >>>>>>>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>>>>>>> I'm not a big fan of ignoring exceptions here, it might be better to >>>>>>>>>>> encapsulate the first command with try: except: and run the zone-mod only if >>>>>>>>>>> the add worked as expected. >>>>>>>>>>> >>>>>>>>>>> Also, logging an message that reverse zone was not added might be a good idea. >>>>>>>>> Agreed. Done. >>>>>>>>> >>>>>>>>>>> HTH >>>>>>>>>>> >>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>>>>>>> '--domain', client.domain.name, >>>>>>>>> >>>>>>>>> >>>>>>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. >>>>>>> >>>>>>> >>>>>>> freeipa-ofayans-0021.2-Removed-ip-address-option-from-replica-installation.patch >>>>>>> >>>>>>> >>>>>>> From e70daf4ed9dfbac7e8ea75cb8e9ab0f2af12ad48 Mon Sep 17 00:00:00 2001 >>>>>>> From: Oleg Fayans >>>>>>> Date: Wed, 27 Jan 2016 11:09:03 +0100 >>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>> >>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>> NACK >>>>>> >>>>>> The commit message and logic is incorrect. In fact it has nothing to do with >>>>>> bind-dyndb-ldap. Either: >>>>>> a] The zone already exists somewhere so you should not create it in IPA, and >>>>>> this --ip-address option is invalid. >>>>>> b] The zone does not exist yet and then --ip-address option is required. >>>>>> >>>>>> I do not see any logic around >>>>>>> '--ip-address', replica.ip, >>>>> The explicit ip-address passing was removed (that's the main point of >>>>> this patch) >>>> Sure, but it cannot be done unconditionally (without additional logic). >>> Fair point. Implemented a check whether ipa master is authoritative for >>> the client's domain. >>> >>>>>> thus the NACK. >>>>>> >>>>>> >>>>>> In other words, network setup is job for a provisioning system. IPA needs to >>>>>> respect whatever the provisioning system did or did not do. >>>> Let me rephrase it: >>>> If IPA DNS manages the zone with replica FQDN or associated reverse zone, we >>>> need the --ip-address option. >>>> >>>> If IPA does not manage any of these, we do not need --ip-address option. >>>> >>>>>> Feel free to ask if something is unclear. >>>> Petr^2 Spacek >>>> >>>>>> (other comments inline) >>>>>> >>>>>> >>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>> master >>>>>>> --- >>>>>>> ipatests/test_integration/tasks.py | 20 +++++++++++++++----- >>>>>>> 1 file changed, 15 insertions(+), 5 deletions(-) >>>>>>> >>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..b8b7fcfcbbb1dc672349119bbbb4cdbbd68c54ec 100644 >>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>> @@ -66,9 +66,13 @@ def check_arguments_are(slice, instanceof): >>>>>>> >>>>>>> def prepare_reverse_zone(host, ip): >>>>>>> zone = get_reverse_zone_default(ip) >>>>>>> - host.run_command(["ipa", >>>>>>> + result = host.run_command(["ipa", >>>>>>> "dnszone-add", >>>>>>> zone], raiseonerr=False) >>>>>>> + if result.returncode > 0: >>>>>>> + log.warn(result.stderr_text) >>>>>>> + return zone, result.returncode >>>>>>> + >>>>>>> >>>>>>> def prepare_host(host): >>>>>>> if isinstance(host, Host): >>>>>>> @@ -319,11 +323,10 @@ def domainlevel(host): >>>>>>> def replica_prepare(master, replica): >>>>>>> apply_common_fixes(replica) >>>>>>> fix_apache_semaphores(replica) >>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>> master.run_command(['ipa-replica-prepare', >>>>>>> '-p', replica.config.dirman_password, >>>>>>> '--ip-address', replica.ip, >>>>>>> - replica.hostname]) >>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>> replica_bundle = master.get_file_contents( >>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>> replica_filename = get_replica_filename(replica) >>>>>>> @@ -339,8 +342,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>> # and replica installation would fail >>>>>>> args = ['ipa-replica-install', '-U', >>>>>>> '-p', replica.config.dirman_password, >>>>>>> - '-w', replica.config.admin_password, >>>>>>> - '--ip-address', replica.ip] >>>>>>> + '-w', replica.config.admin_password] >>>>>>> if setup_ca: >>>>>>> args.append('--setup-ca') >>>>>>> if setup_dns: >>>>>>> @@ -380,6 +382,14 @@ def install_client(master, client, extra_args=()): >>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>> >>>>>>> apply_common_fixes(client) >>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>> + allow_sync_ptr(master) >>>>>>> + zone, error = prepare_reverse_zone(master, client.ip) >>>>>>> + if not error: >>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>> I believe that this call to dnszone-mod should use raiseonerr=True so you know >>>>>> that environment was not configured to accept dynamic updates. >>>>> Agreed. Fixed. >>>>> >>>>>>> >>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>> '--domain', client.domain.name, >>>>>>> -- 2.4.3 >>>>>> >>>> >>> >>> >> >>> + log.warn(result.stderr_text) >> >> warn is deprecated, please use log.warning instead > > Fixed I'm still not big fan of this, but never mind. ACK -- Petr^2 Spacek From mbasti at redhat.com Thu Feb 4 14:54:10 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 4 Feb 2016 15:54:10 +0100 Subject: [Freeipa-devel] [TEST][Patch 0021] Fixed recent replica installation issues in the lab In-Reply-To: <56B363A7.2090905@redhat.com> References: <56A0D223.2060702@redhat.com> <56A0FC2C.2010004@redhat.com> <56A87E93.9030302@redhat.com> <56A898E5.9060202@redhat.com> <56AB45BB.3070102@redhat.com> <56AF38D0.8010004@redhat.com> <56AF45C4.9040404@redhat.com> <56B348E0.70301@redhat.com> <56B34D2F.5040708@redhat.com> <56B36257.2020003@redhat.com> <56B363A7.2090905@redhat.com> Message-ID: <56B36612.8040709@redhat.com> On 04.02.2016 15:43, Petr Spacek wrote: > On 4.2.2016 15:38, Oleg Fayans wrote: >> Hi, >> >> On 02/04/2016 02:07 PM, Martin Basti wrote: >>> >>> On 04.02.2016 13:49, Oleg Fayans wrote: >>>> Hi Petr, >>>> >>>> An updated patch is attached. Please see my comment inline. >>>> >>>> On 02/01/2016 12:47 PM, Petr Spacek wrote: >>>>> On 1.2.2016 11:52, Oleg Fayans wrote: >>>>>> Hi Petr, >>>>>> >>>>>> Please find the new version of the patch attached. Comments are inline >>>>>> >>>>>> On 01/29/2016 11:58 AM, Petr Spacek wrote: >>>>>>> On 27.1.2016 11:16, Oleg Fayans wrote: >>>>>>>> Sorry, trailing whitespace detected. This version passes lint >>>>>>>> >>>>>>>> On 01/27/2016 09:23 AM, Oleg Fayans wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 01/21/2016 04:41 PM, Petr Spacek wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> On 21.1.2016 13:42, Oleg Fayans wrote: >>>>>>>>>>>>>> freeipa-ofayans-0021-Removed-ip-address-option-from-replica-installation.patch >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> From d7ab06a4dcddb919fda351b983d478f1b6968578 Mon Sep 17 00:00:00 2001 >>>>>>>>>>>>>> From: Oleg Fayans >>>>>>>>>>>>>> Date: Thu, 21 Jan 2016 13:30:02 +0100 >>>>>>>>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>>>>>>>> >>>>>>>>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>>>>>>>> master >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> ipatests/test_integration/tasks.py | 19 ++++++++++++------- >>>>>>>>>>>>>> 1 file changed, 12 insertions(+), 7 deletions(-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..43ef78b0c55deed24a0444f0ac6c38ddb2517481 100644 >>>>>>>>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>>>>>>>> @@ -69,6 +69,8 @@ def prepare_reverse_zone(host, ip): >>>>>>>>>>>>>> host.run_command(["ipa", >>>>>>>>>>>>>> "dnszone-add", >>>>>>>>>>>>>> zone], raiseonerr=False) >>>>>>>>>>>>>> + return zone >>>>>>>>>>>>>> + >>>>>>>>>>>>>> >>>>>>>>>>>>>> def prepare_host(host): >>>>>>>>>>>>>> if isinstance(host, Host): >>>>>>>>>>>>>> @@ -319,11 +321,8 @@ def domainlevel(host): >>>>>>>>>>>>>> def replica_prepare(master, replica): >>>>>>>>>>>>>> apply_common_fixes(replica) >>>>>>>>>>>>>> fix_apache_semaphores(replica) >>>>>>>>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>>>>>>>> - master.run_command(['ipa-replica-prepare', >>>>>>>>>>>>>> - '-p', replica.config.dirman_password, >>>>>>>>>>>>>> - '--ip-address', replica.ip, >>>>>>>>>>>>>> - replica.hostname]) >>>>>>>>>>>>>> + master.run_command(['ipa-replica-prepare', '-p', replica.config.dirman_password, >>>>>>>>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>>>>>>> I guess that you will need --ip-address option in cases where master's reverse >>>>>>>>>>>> record does not exist (yet). >>>>>>>>>> And yo were right. Fixed >>>>>>>>>> >>>>>>>>>>>> I would recommend you to test this in libvirt or somewhere without revere >>>>>>>>>>>> records, I suspect that it might blow up. >>>>>>>>>>>> >>>>>>>>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>>>>>>>> @@ -339,8 +338,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>>>>>>>> # and replica installation would fail >>>>>>>>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>>>>>>>> '-p', replica.config.dirman_password, >>>>>>>>>>>>>> - '-w', replica.config.admin_password, >>>>>>>>>>>>>> - '--ip-address', replica.ip] >>>>>>>>>>>>>> + '-w', replica.config.admin_password] >>>>>>>>>>>>>> if setup_ca: >>>>>>>>>>>>>> args.append('--setup-ca') >>>>>>>>>>>>>> if setup_dns: >>>>>>>>>>>>>> @@ -380,6 +378,13 @@ def install_client(master, client, extra_args=()): >>>>>>>>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>>>>>>>> >>>>>>>>>>>>>> apply_common_fixes(client) >>>>>>>>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>>>>>>>> + allow_sync_ptr(master) >>>>>>>>>>>>>> + zone = prepare_reverse_zone(master, client.ip) >>>>>>>>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>>>>>>>> I'm not a big fan of ignoring exceptions here, it might be better to >>>>>>>>>>>> encapsulate the first command with try: except: and run the zone-mod only if >>>>>>>>>>>> the add worked as expected. >>>>>>>>>>>> >>>>>>>>>>>> Also, logging an message that reverse zone was not added might be a good idea. >>>>>>>>>> Agreed. Done. >>>>>>>>>> >>>>>>>>>>>> HTH >>>>>>>>>>>> >>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>>>>>>>> '--domain', client.domain.name, >>>>>>>>>> >>>>>>>> -- Oleg Fayans Quality Engineer FreeIPA team RedHat. >>>>>>>> >>>>>>>> >>>>>>>> freeipa-ofayans-0021.2-Removed-ip-address-option-from-replica-installation.patch >>>>>>>> >>>>>>>> >>>>>>>> From e70daf4ed9dfbac7e8ea75cb8e9ab0f2af12ad48 Mon Sep 17 00:00:00 2001 >>>>>>>> From: Oleg Fayans >>>>>>>> Date: Wed, 27 Jan 2016 11:09:03 +0100 >>>>>>>> Subject: [PATCH] Removed --ip-address option from replica installation >>>>>>>> >>>>>>>> Explicitly specifying ip-address of the replica messes up with the current >>>>>>>> bind-dyndb-ldap logic, causing reverse zone not to be created. >>>>>>> NACK >>>>>>> >>>>>>> The commit message and logic is incorrect. In fact it has nothing to do with >>>>>>> bind-dyndb-ldap. Either: >>>>>>> a] The zone already exists somewhere so you should not create it in IPA, and >>>>>>> this --ip-address option is invalid. >>>>>>> b] The zone does not exist yet and then --ip-address option is required. >>>>>>> >>>>>>> I do not see any logic around >>>>>>>> '--ip-address', replica.ip, >>>>>> The explicit ip-address passing was removed (that's the main point of >>>>>> this patch) >>>>> Sure, but it cannot be done unconditionally (without additional logic). >>>> Fair point. Implemented a check whether ipa master is authoritative for >>>> the client's domain. >>>> >>>>>>> thus the NACK. >>>>>>> >>>>>>> >>>>>>> In other words, network setup is job for a provisioning system. IPA needs to >>>>>>> respect whatever the provisioning system did or did not do. >>>>> Let me rephrase it: >>>>> If IPA DNS manages the zone with replica FQDN or associated reverse zone, we >>>>> need the --ip-address option. >>>>> >>>>> If IPA does not manage any of these, we do not need --ip-address option. >>>>> >>>>>>> Feel free to ask if something is unclear. >>>>> Petr^2 Spacek >>>>> >>>>>>> (other comments inline) >>>>>>> >>>>>>> >>>>>>>> Enabled reverse-zone creation for the clients residing in different subnet from >>>>>>>> master >>>>>>>> --- >>>>>>>> ipatests/test_integration/tasks.py | 20 +++++++++++++++----- >>>>>>>> 1 file changed, 15 insertions(+), 5 deletions(-) >>>>>>>> >>>>>>>> diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py >>>>>>>> index 6eb55501389c72b4c7aaa599fd4852d7e8f1f3c2..b8b7fcfcbbb1dc672349119bbbb4cdbbd68c54ec 100644 >>>>>>>> --- a/ipatests/test_integration/tasks.py >>>>>>>> +++ b/ipatests/test_integration/tasks.py >>>>>>>> @@ -66,9 +66,13 @@ def check_arguments_are(slice, instanceof): >>>>>>>> >>>>>>>> def prepare_reverse_zone(host, ip): >>>>>>>> zone = get_reverse_zone_default(ip) >>>>>>>> - host.run_command(["ipa", >>>>>>>> + result = host.run_command(["ipa", >>>>>>>> "dnszone-add", >>>>>>>> zone], raiseonerr=False) >>>>>>>> + if result.returncode > 0: >>>>>>>> + log.warn(result.stderr_text) >>>>>>>> + return zone, result.returncode >>>>>>>> + >>>>>>>> >>>>>>>> def prepare_host(host): >>>>>>>> if isinstance(host, Host): >>>>>>>> @@ -319,11 +323,10 @@ def domainlevel(host): >>>>>>>> def replica_prepare(master, replica): >>>>>>>> apply_common_fixes(replica) >>>>>>>> fix_apache_semaphores(replica) >>>>>>>> - prepare_reverse_zone(master, replica.ip) >>>>>>>> master.run_command(['ipa-replica-prepare', >>>>>>>> '-p', replica.config.dirman_password, >>>>>>>> '--ip-address', replica.ip, >>>>>>>> - replica.hostname]) >>>>>>>> + '--auto-reverse', replica.hostname]) >>>>>>>> replica_bundle = master.get_file_contents( >>>>>>>> paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname) >>>>>>>> replica_filename = get_replica_filename(replica) >>>>>>>> @@ -339,8 +342,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False, >>>>>>>> # and replica installation would fail >>>>>>>> args = ['ipa-replica-install', '-U', >>>>>>>> '-p', replica.config.dirman_password, >>>>>>>> - '-w', replica.config.admin_password, >>>>>>>> - '--ip-address', replica.ip] >>>>>>>> + '-w', replica.config.admin_password] >>>>>>>> if setup_ca: >>>>>>>> args.append('--setup-ca') >>>>>>>> if setup_dns: >>>>>>>> @@ -380,6 +382,14 @@ def install_client(master, client, extra_args=()): >>>>>>>> client.collect_log(paths.IPACLIENT_INSTALL_LOG) >>>>>>>> >>>>>>>> apply_common_fixes(client) >>>>>>>> + # Now, for the situations where a client resides in a different subnet from >>>>>>>> + # master, we need to explicitly tell master to create a reverse zone for >>>>>>>> + # the client and enable dynamic updates for this zone. >>>>>>>> + allow_sync_ptr(master) >>>>>>>> + zone, error = prepare_reverse_zone(master, client.ip) >>>>>>>> + if not error: >>>>>>>> + master.run_command(["ipa", "dnszone-mod", zone, >>>>>>>> + "--dynamic-update=TRUE"], raiseonerr=False) >>>>>>> I believe that this call to dnszone-mod should use raiseonerr=True so you know >>>>>>> that environment was not configured to accept dynamic updates. >>>>>> Agreed. Fixed. >>>>>> >>>>>>>> >>>>>>>> client.run_command(['ipa-client-install', '-U', >>>>>>>> '--domain', client.domain.name, >>>>>>>> -- 2.4.3 >>>> >>>> + log.warn(result.stderr_text) >>> warn is deprecated, please use log.warning instead >> Fixed > I'm still not big fan of this, but never mind. ACK > > Pushed to: master: 42d364427606e39486645e4064ca16940b2f8837 ipa-4-3: 91bd73455c244932486889d32bcf9352f1c038a4 From pspacek at redhat.com Thu Feb 4 17:21:45 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 4 Feb 2016 18:21:45 +0100 Subject: [Freeipa-devel] Locations design v2 - please review In-Reply-To: <56B23BE0.4000207@redhat.com> References: <56B23BE0.4000207@redhat.com> Message-ID: <56B388A9.5090206@redhat.com> On 3.2.2016 18:41, Petr Spacek wrote: > Hello, > > I've updated the design page > http://www.freeipa.org/page/V4/DNS_Location_Mechanism > > Namely it now contains 'Version 2'. Okay, here is the idea how we can make it flexible: http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation -- Petr^2 Spacek From tscherf at redhat.com Sun Feb 7 20:40:50 2016 From: tscherf at redhat.com (Thorsten Scherf) Date: Sun, 7 Feb 2016 21:40:50 +0100 Subject: [Freeipa-devel] [PATCH 0001] ipa-server-certinstall should not tell certmonger to track 3rd party certificates In-Reply-To: <5695F2F1.7030307@redhat.com> References: <20151215132144.GI25566@tscherf.redhat.com> <5695F2F1.7030307@redhat.com> Message-ID: <20160207204050.GD13989@tscherf.redhat.com> On [Wed, 13.01.2016 07:47], Jan Cholasta wrote: >Hi Thorsten, > >thanks for the patch, but unfortunately it isn't as simple as this - >if the provided certificate was issued by our CA, we should still >track it. > >As part of installer improvements in 4.4, we plan to always track all >certificates, even 3rd party ones (this way we can have the same >certmonger configuration everywhere, plus the user will be at least >warned when the certificate is about to expire), which will also fix >this issue. > >Does that sound OK? Yes, when the user gets a warning for certs which have been issued by 3rd party CAs in case they are going to expire, then it indeed does make sense to have them tracked by certmonger. Cheers, Thorsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From mbasti at redhat.com Tue Feb 9 10:14:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Feb 2016 11:14:47 +0100 Subject: [Freeipa-devel] [wiki] please review: domain levels overview page Message-ID: <56B9BC17.3030504@redhat.com> Hello, I prepared page for keeping the information about domain levels, what are features, which version introduced the particular domain level. http://www.freeipa.org/page/Domain_Levels Martin^2 From mbasti at redhat.com Tue Feb 9 10:28:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Feb 2016 11:28:25 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56B1C637.1000403@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> <56AF5B25.6000706@redhat.com> <56B1C637.1000403@redhat.com> Message-ID: <56B9BF49.60501@redhat.com> On 03.02.2016 10:19, David Kupka wrote: > On 01/02/16 14:18, Martin Basti wrote: >> >> >> On 26.01.2016 14:16, Martin Basti wrote: >>> >>> >>> On 20.01.2016 14:38, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 19.1.2016 13:43, Martin Basti wrote: >>>>> New pylint version will broke our custom make-lint script again, >>>>> attached patch migrates make-lint to: >>>>> * config file >>>>> * pylint plugin >>>>> which are supported by pylint and should not have regular >>>>> compatibility >>>>> issues >>>>> >>>>> to test new approach run ./make-lint2 >>>>> >>>>> Advantages: >>>>> * compatibility with pylint >>>>> * works on both pylint-1.4.3-3.fc23.noarch and >>>>> pylint-1.5.2-1.fc24.noarch >>>>> * pylint plugin works in different way than the previous custom >>>>> checker. >>>>> Missing ("dynamic") attributes are added to abstract syntax tree >>>>> instead >>>>> of ignoring them and all their sub-members. This makes check better, >>>>> pylint can detect more typos in tests configurations, api, env, etc.. >>>>> >>>>> Disadvantages: >>>>> * any new attribute in api, test config, etc.. must be added to >>>>> definition of missing members (pylint plugin) - this should not >>>>> happen >>>>> too often >>>> >>>> 1) Please "mv pylint_plugins/fix_ipa_members.py pylint_plugins.py" >>>> and "rm -rf pylint_plugins/", no need for this redundant directory >>>> structure. >>>> >>>> 2) Rename pylintrc to freeipa.pylintrc so you have to always specify >>>> it explicitly with --rcfile. >>>> >>>> 3) Use the load-plugins directive in freeipa.pylintrc to load the >>>> plugins rather than --load-plugins. >>>> >>>> 4) Instead of running pylint twice, run it only once with both normal >>>> and Python 3 checks enabled: >>>> >>>> [MESSAGE CONTROL] >>>> enable=all,python3 >>>> disable=...,no-absolute-import >>>> >>>>> >>>>> >>>>> Q&TODO: >>>>> * make-lint: should it be just bash script or rather python script? >>>> >>>> IMO neither, it should be a make target (make lint). >>>> >>>>> * add dynamic detection of python files to be checked >>>> >>>> You can use "find . -type f -executable ! -path \*/.\* ! -name >>>> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >>>> >>>>> * should I keep the current options from original make-lint? >>>> >>>> No, but allow pylint options to be overridable (make lint >>>> PYLINTFLAGS="--disable=python3") >>>> >>>>> * several false positive errors I haven't been able to fix in plugin >>>>> yet, in worst case they can be locally disabled: >>>> >>>> Disable them locally. >>>> >>>> Honza >>>> >>> Updated patch attached. >>> >>> Please note that make-lint script has been removed, to execute lint >>> check use 'make lint' >>> >>> >> >> Updated patch attached: >> * fixes recently added error >> * fixes PEP8 >> * cleanup of pylint config file >> >> Patch is only for master branch, for 4.3 and 4.2 I will send different >> patches when this will be acked >> >> > > Could you please add an extensive comment to the 4-lines-long find > command? I can after a while (and with the help of man page) decode > what it does so it would definitely help to have it described. > Otherwise it looks good to me. > Updated patch attached, only for master, patches for 4.2, 4.3 will follow if this one will be ACKed -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0407.4-make-lint-use-config-file-and-plugin-for-pylint.patch Type: text/x-patch Size: 26712 bytes Desc: not available URL: From ftweedal at redhat.com Tue Feb 9 11:07:53 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 9 Feb 2016 21:07:53 +1000 Subject: [Freeipa-devel] [wiki] please review: domain levels overview page In-Reply-To: <56B9BC17.3030504@redhat.com> References: <56B9BC17.3030504@redhat.com> Message-ID: <20160209110753.GH12524@dhcp-40-8.bne.redhat.com> On Tue, Feb 09, 2016 at 11:14:47AM +0100, Martin Basti wrote: > Hello, > > I prepared page for keeping the information about domain levels, what are > features, which version introduced the particular domain level. > > http://www.freeipa.org/page/Domain_Levels > > Martin^2 > Thanks, it is a useful summary. Suggestion: in `Features' section, if you are only going to link to design page, I would just remove that section and directly link the design page from the `Current domain levels' table. (OTOH, if it is planned to expand these sections then it is fine). Cheers, Fraser From mbasti at redhat.com Tue Feb 9 12:07:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 9 Feb 2016 13:07:00 +0100 Subject: [Freeipa-devel] [wiki] please review: domain levels overview page In-Reply-To: <20160209110753.GH12524@dhcp-40-8.bne.redhat.com> References: <56B9BC17.3030504@redhat.com> <20160209110753.GH12524@dhcp-40-8.bne.redhat.com> Message-ID: <56B9D664.9000901@redhat.com> On 09.02.2016 12:07, Fraser Tweedale wrote: > On Tue, Feb 09, 2016 at 11:14:47AM +0100, Martin Basti wrote: >> Hello, >> >> I prepared page for keeping the information about domain levels, what are >> features, which version introduced the particular domain level. >> >> http://www.freeipa.org/page/Domain_Levels >> >> Martin^2 >> > Thanks, it is a useful summary. > > Suggestion: in `Features' section, if you are only going to link to > design page, I would just remove that section and directly link the > design page from the `Current domain levels' table. (OTOH, if it is > planned to expand these sections then it is fine). I plan to add there links to howto or documentation (but I/somebody have to write it first :) ) > > Cheers, > Fraser From mkubik at redhat.com Tue Feb 9 13:37:49 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 9 Feb 2016 14:37:49 +0100 Subject: [Freeipa-devel] [patch 0032] ipatests: add missing certprofile fixture Message-ID: <56B9EBAD.7090804@redhat.com> Fixes the CA ACL tests broken by removed import. This patch doesn't rely on undocumented behavior of pytest. The patch invalidates patch 133 by Martin Babinsky. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0032-ipatests-Add-missing-certificate-profile-fixture.patch Type: text/x-patch Size: 1468 bytes Desc: not available URL: From dkupka at redhat.com Tue Feb 9 14:26:17 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 9 Feb 2016 15:26:17 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56B9BF49.60501@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> <56AF5B25.6000706@redhat.com> <56B1C637.1000403@redhat.com> <56B9BF49.60501@redhat.com> Message-ID: <56B9F709.5060303@redhat.com> On 09/02/16 11:28, Martin Basti wrote: > > > On 03.02.2016 10:19, David Kupka wrote: >> On 01/02/16 14:18, Martin Basti wrote: >>> >>> >>> On 26.01.2016 14:16, Martin Basti wrote: >>>> >>>> >>>> On 20.01.2016 14:38, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 19.1.2016 13:43, Martin Basti wrote: >>>>>> New pylint version will broke our custom make-lint script again, >>>>>> attached patch migrates make-lint to: >>>>>> * config file >>>>>> * pylint plugin >>>>>> which are supported by pylint and should not have regular >>>>>> compatibility >>>>>> issues >>>>>> >>>>>> to test new approach run ./make-lint2 >>>>>> >>>>>> Advantages: >>>>>> * compatibility with pylint >>>>>> * works on both pylint-1.4.3-3.fc23.noarch and >>>>>> pylint-1.5.2-1.fc24.noarch >>>>>> * pylint plugin works in different way than the previous custom >>>>>> checker. >>>>>> Missing ("dynamic") attributes are added to abstract syntax tree >>>>>> instead >>>>>> of ignoring them and all their sub-members. This makes check better, >>>>>> pylint can detect more typos in tests configurations, api, env, etc.. >>>>>> >>>>>> Disadvantages: >>>>>> * any new attribute in api, test config, etc.. must be added to >>>>>> definition of missing members (pylint plugin) - this should not >>>>>> happen >>>>>> too often >>>>> >>>>> 1) Please "mv pylint_plugins/fix_ipa_members.py pylint_plugins.py" >>>>> and "rm -rf pylint_plugins/", no need for this redundant directory >>>>> structure. >>>>> >>>>> 2) Rename pylintrc to freeipa.pylintrc so you have to always specify >>>>> it explicitly with --rcfile. >>>>> >>>>> 3) Use the load-plugins directive in freeipa.pylintrc to load the >>>>> plugins rather than --load-plugins. >>>>> >>>>> 4) Instead of running pylint twice, run it only once with both normal >>>>> and Python 3 checks enabled: >>>>> >>>>> [MESSAGE CONTROL] >>>>> enable=all,python3 >>>>> disable=...,no-absolute-import >>>>> >>>>>> >>>>>> >>>>>> Q&TODO: >>>>>> * make-lint: should it be just bash script or rather python script? >>>>> >>>>> IMO neither, it should be a make target (make lint). >>>>> >>>>>> * add dynamic detection of python files to be checked >>>>> >>>>> You can use "find . -type f -executable ! -path \*/.\* ! -name >>>>> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >>>>> >>>>>> * should I keep the current options from original make-lint? >>>>> >>>>> No, but allow pylint options to be overridable (make lint >>>>> PYLINTFLAGS="--disable=python3") >>>>> >>>>>> * several false positive errors I haven't been able to fix in plugin >>>>>> yet, in worst case they can be locally disabled: >>>>> >>>>> Disable them locally. >>>>> >>>>> Honza >>>>> >>>> Updated patch attached. >>>> >>>> Please note that make-lint script has been removed, to execute lint >>>> check use 'make lint' >>>> >>>> >>> >>> Updated patch attached: >>> * fixes recently added error >>> * fixes PEP8 >>> * cleanup of pylint config file >>> >>> Patch is only for master branch, for 4.3 and 4.2 I will send different >>> patches when this will be acked >>> >>> >> >> Could you please add an extensive comment to the 4-lines-long find >> command? I can after a while (and with the help of man page) decode >> what it does so it would definitely help to have it described. >> Otherwise it looks good to me. >> > Updated patch attached, only for master, patches for 4.2, 4.3 will > follow if this one will be ACKed The comment is probably sufficient, thanks. Also works for me on current master, ACK. -- David Kupka From pspacek at redhat.com Tue Feb 9 14:48:07 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 9 Feb 2016 15:48:07 +0100 Subject: [Freeipa-devel] FreeIPA Cloud/Openstack Configuration? In-Reply-To: <56ADD65B.9010804@runlevelone.net> References: <56ADD65B.9010804@runlevelone.net> Message-ID: <56B9FC27.1070105@redhat.com> On 31.1.2016 10:39, Dan Lavu wrote: > I started playing around with Openstack and was installing FreeIPA on a tenant > network and I wanted to replicate to a server on provider network or another > network entirely. If you are not familiar with Openstack, a lot of cloud > implementations will have a virtual private network that is entirely isolated > from the outside world until an IP is attached to the guest. So this had me > thinking about best practices and cloud implementations using FreeIPA. I can't > seem to find a lot documentation on this. So the complication I've come across > is that the tenant network is not route-able by default, but you can attach a > floating-IP which is route-able to the external FreeIPA server but the host > entries are going to differ. For clarification in the below diagram, (if this > diagram doesn't show up, it is attached). > > openstack_networks > > idm2, has the local IP of 192.168.50.13 and has a floating ip 0f 192.168.73.7, > but on the guest 192.168.73.7 is not known at all, for it to be route-able it > does some source natting using neutron and openvswitch. So during the > installation, it's not possible to use the external IP because the installer > will indicate the IP doesn't exist or is not route-able. > > So I ultimately installed FreeIPA using the internal address and modified the A > record to point to the floating external IP address. Lastly modified the host > file to have the name resolve to the internal address. I feel like there is a > cleaner way of doing this. Now it gets even more complicated if different > hostnames are used, since IPA does a URL rewrite and I'm sure there are other > name dependencies I'm unaware of. > > So my questions are, do we have a documentation about installation FreeIPA on a > cloud platform to serve external hosts? > > Do we have any instructions on adding another name to the FreeIPA server > certificate? (I know we have steps for client hosts) I can see this being > resolved by having idm2 access requests for two domains, i.e. 192.168.73.0/24 > company.com and 192.168.50.0/24 cloud.company.com. > > Is there any other solutions? I can tell you how I'm installing IPA in OpenStack, but it is a hack: 1) Assign a floating IP to the VM 2) Configure hostname inside the VM to match the externally visible one 3) Temporarily assign floating IP address to loopback inside the VM 4) Run IPA installer 5) Remove the floating address from the loopback > Is this something that we need to address? Yeah, we should, but I have no idea how IPA can detect its floating IP address ... -- Petr^2 Spacek From mkubik at redhat.com Tue Feb 9 15:06:38 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 9 Feb 2016 16:06:38 +0100 Subject: [Freeipa-devel] [patch 0032] ipatests: add missing certprofile fixture In-Reply-To: <56B9EBAD.7090804@redhat.com> References: <56B9EBAD.7090804@redhat.com> Message-ID: <56BA007E.9000405@redhat.com> On 02/09/2016 02:37 PM, Milan Kub?k wrote: > Fixes the CA ACL tests broken by removed import. This patch doesn't > rely on undocumented behavior of pytest. > > The patch invalidates patch 133 by Martin Babinsky. > > > Patch updated with trac link -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0032-1-ipatests-Add-missing-certificate-profile-fixture.patch Type: text/x-patch Size: 1513 bytes Desc: not available URL: From mkubik at redhat.com Tue Feb 9 15:19:36 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Tue, 9 Feb 2016 16:19:36 +0100 Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin In-Reply-To: <1320714330.19162635.1453974171503.JavaMail.zimbra@redhat.com> References: <20151120135636.71171d5c@vor2.netbox.priv> <5665B88E.4000507@redhat.com> <20151209190102.1bb8fc07@vor2.netbox.priv> <1914334378.4564827.1452602733244.JavaMail.zimbra@redhat.com> <1760221088.11921867.1452868707220.JavaMail.zimbra@redhat.com> <569CD602.1030604@redhat.com> <1869235561.17372506.1453716664538.JavaMail.zimbra@redhat.com> <56A7B34E.2050906@redhat.com> <1320714330.19162635.1453974171503.JavaMail.zimbra@redhat.com> Message-ID: <56BA0388.7040307@redhat.com> On 01/28/2016 10:42 AM, Filip Skola wrote: > > ----- Original Message ----- >> On 01/25/2016 11:11 AM, Filip Skola wrote: >>> ----- Original Message ----- >>>> On 01/15/2016 03:38 PM, Filip Skola wrote: >>>>> Hi, >>>>> >>>>> sending rebased patch. >>>>> >>>>> F. >>>>> >>>>> ----- Original Message ----- >>>>>> Hello, >>>>>> >>>>>> sorry for delays. The patch no longer applies to master. Rebase it, >>>>>> please. >>>>>> >>>>>> Milan >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Filip ?kola" >>>>>> To: "Milan Kub?k" >>>>>> Cc: freeipa-devel at redhat.com >>>>>> Sent: Wednesday, 9 December, 2015 7:01:02 PM >>>>>> Subject: Re: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin >>>>>> >>>>>> On Mon, 7 Dec 2015 17:49:18 +0100 >>>>>> Milan Kub?k wrote: >>>>>> >>>>>>> On 12/03/2015 08:15 PM, Filip ?kola wrote: >>>>>>>> On Mon, 30 Nov 2015 17:18:30 +0100 >>>>>>>> Milan Kub?k wrote: >>>>>>>> >>>>>>>>> On 11/23/2015 04:42 PM, Filip ?kola wrote: >>>>>>>>>> Sending updated patch. >>>>>>>>>> >>>>>>>>>> F. >>>>>>>>>> >>>>>>>>>> On Mon, 23 Nov 2015 14:59:34 +0100 >>>>>>>>>> Filip ?kola wrote: >>>>>>>>>> >>>>>>>>>>> Found couple of issues (broke some dependencies). >>>>>>>>>>> >>>>>>>>>>> NACK >>>>>>>>>>> >>>>>>>>>>> F. >>>>>>>>>>> >>>>>>>>>>> On Fri, 20 Nov 2015 13:56:36 +0100 >>>>>>>>>>> Filip ?kola wrote: >>>>>>>>>>> >>>>>>>>>>>> Another one. >>>>>>>>>>>> >>>>>>>>>>>> F. >>>>>>>>> Hi, the tests look good. Few remarks, though. >>>>>>>>> >>>>>>>>> 1. Please, use the shortes copyright notice in new modules. >>>>>>>>> >>>>>>>>> # >>>>>>>>> # Copyright (C) 2015 FreeIPA Contributors see COPYING for >>>>>>>>> license # >>>>>>>>> >>>>>>>>> 2. The tests `test_group_remove_group_from_protected_group` and >>>>>>>>> `test_group_full_set_of_objectclass_not_available_post_detach` >>>>>>>>> were not ported. Please, include them in the patch. >>>>>>>>> >>>>>>>>> Also, for less hassle, please rebase your patches on top of >>>>>>>>> freeipa-mkubik-0025-3-Separated-Tracker-implementations-into-standalone-pa.patch >>>>>>>>> Which changes the location of tracker implementations and prevents >>>>>>>>> circular imports. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> these cases are there, in corresponding classes. They are marked >>>>>>>> with the original comments. (However I can move them to separate >>>>>>>> class if desirable.) >>>>>>>> >>>>>>>> The copyright notice is changed. Also included a few changes in the >>>>>>>> test with user without private group. >>>>>>>> >>>>>>>> Filip >>>>>>> NACK >>>>>>> >>>>>>> linter: >>>>>>> ************* Module tracker.group_plugin >>>>>>> ipatests/test_xmlrpc/tracker/group_plugin.py:257: >>>>>>> [E0102(function-redefined), GroupTracker.check_remove_member] method >>>>>>> already defined line 253) >>>>>>> >>>>>>> Probably a leftover after the rebase made on top of my patch. Please >>>>>>> fix it. You can check youch changes by make-lint script before >>>>>>> sending them. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>> Hi, >>>>>> >>>>>> I learned to use make-lint! >>>>>> >>>>>> Thanks, >>>>>> F. >>>>>> >>>> Hello, >>>> >>>> NACK, pylint doesn't seem to like the way the fixtures are imported >>>> (pytest does a lot of runtime magic) [1]. >>>> One possible solution would be [2]. Though, I don't think this would be >>>> a good idea in our environment. I suggest to create the fixtures on per >>>> module basis. >>>> >>>> >>>> [1]: http://fpaste.org/311949/53118942/ >>>> [2]: >>>> https://pytest.org/latest/fixture.html#using-fixtures-from-classes-modules-or-projects >>>> >>>> -- >>>> Milan Kubik >>>> >>>> >>> Hi, >>> >>> the fixtures were copied into corresponding module. Please note that this >>> patch has a dependence on my patch 0001 (user plugin). >>> >>> Filip >> Linter: >> ************* Module ipatests.test_xmlrpc.tracker.group_plugin >> W:100,26: Calling a dict.iter*() method (dict-iter-method) >> >> please use dict.items >> >> -- >> Milan Kubik >> >> > Hi, sorry. This has been fixed in this patch. > > Filip ACK, thanks for the patience. :) -- Milan Kubik From pviktori at redhat.com Tue Feb 9 17:02:19 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 9 Feb 2016 18:02:19 +0100 Subject: [Freeipa-devel] [PATCHES] 0761-0769 More Python3 fixes In-Reply-To: <56AB25FC.5090505@redhat.com> References: <56A90086.30600@redhat.com> <56AB21F5.40902@redhat.com> <56AB25FC.5090505@redhat.com> Message-ID: <56BA1B9B.4040903@redhat.com> On 01/29/2016 09:42 AM, Jan Cholasta wrote: > On 29.1.2016 09:25, Jan Cholasta wrote: >> Hi, >> >> On 27.1.2016 18:38, Petr Viktorin wrote: >>> Hello, >>> >>> Here is a mixed bag of Python 3 fixes. >>> They fix some tests, and they should enable you to use `python3 >>> /usr/bin/ipa`. >> >> Patch 761: >> >> 1) The "invalid 'my_number': " bit comes from IPA itself, shouldn't we >> check at least that? Fixed >> Patch 762: >> >> 1) We should handle UnicodeError here as well, in addition to TypeError: >> >> if k.lower() == 'negotiate': >> try: >> - token = base64.b64decode(v) >> + token = base64.b64decode(v.encode('ascii')) >> break >> # b64decode raises TypeError on invalid input >> except TypeError: Fixed >> 2) I would prefer if the encoding was specified explicitly here: >> >> + response = json_decode_binary(json.loads(response.decode())) Fixed >> Patch 763: >> >> 1) >> >> + altname = altname Fixed >> 2) Nitpick, but could you please: >> >> - if isinstance(name_or_oid, unicode): >> - name_or_oid = name_or_oid.encode('utf-8') >> + if six.PY2: >> + if isinstance(name_or_oid, unicode): >> + name_or_oid = name_or_oid.encode('utf-8') >> >> This way it's more visible that this is a py2-only thing. Sure >> Patch 764: LGTM >> >> >> Patch 765: >> >> 1) >> >> +import tempfile >> +import tempfile Fixed. >> Patch 766-767: LGTM >> >> >> Patch 768: >> >> 1) Only binascii.Error should be handled in int_to_bytes, the try-except >> block is there just to handle odd-length strings. That's there for Python 2, where unhexlify raises TypeError. >> 2) I think you can just remove the library_path.encode(), it's there >> because the original C code did the same thing, but don't think it's >> necessary. OK >> Patch 769: LGTM > > Also, could you please reference > in the patches? Sure. Thanks for the review! Updated patches attached. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0761.2-test_parameters-Ignore-specific-error-message.patch Type: text/x-patch Size: 1305 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0762.2-Fix-bytes-string-handling-in-rpc.patch Type: text/x-patch Size: 2598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0763.2-ipaldap-ldapupdate-Encoding-fixes-for-Python-3.patch Type: text/x-patch Size: 3004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0764.2-ipautil.run-kernel_keyring-Encoding-fixes-for-Python.patch Type: text/x-patch Size: 2971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0765.2-tests-Use-absolute-imports.patch Type: text/x-patch Size: 1827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0766.2-ipautil-Use-mode-w-in-write_tmp_file.patch Type: text/x-patch Size: 868 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0767.2-test_util-str-bytes-check-fixes-for-Python-3.patch Type: text/x-patch Size: 1894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0768.2-p11helper-Port-to-Python-3.patch Type: text/x-patch Size: 1664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0769.2-cli-Don-t-encode-decode-for-stdin-stdout-on-Python-3.patch Type: text/x-patch Size: 2195 bytes Desc: not available URL: From dkupka at redhat.com Wed Feb 10 07:51:51 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 10 Feb 2016 08:51:51 +0100 Subject: [Freeipa-devel] [PATCH] CI: Add simple replication test in 2-connected topology. Message-ID: <56BAEC17.7050406@redhat.com> This topology should be closer to the ones in real world than our current ones. But it is still impractical and (hopefully) no one has such deployment. If some user could share his/her deployment topology I will be happy to create generator based on it. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0081-CI-Add-2-connected-topology-generator.patch Type: text/x-patch Size: 2533 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0082-CI-Add-simple-replication-test-in-2-connected-topolo.patch Type: text/x-patch Size: 1531 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0083-CI-Add-test-for-2-connected-topology-generator.patch Type: text/x-patch Size: 1158 bytes Desc: not available URL: From mkubik at redhat.com Wed Feb 10 08:17:15 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 10 Feb 2016 09:17:15 +0100 Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin In-Reply-To: <56BA0388.7040307@redhat.com> References: <20151120135636.71171d5c@vor2.netbox.priv> <5665B88E.4000507@redhat.com> <20151209190102.1bb8fc07@vor2.netbox.priv> <1914334378.4564827.1452602733244.JavaMail.zimbra@redhat.com> <1760221088.11921867.1452868707220.JavaMail.zimbra@redhat.com> <569CD602.1030604@redhat.com> <1869235561.17372506.1453716664538.JavaMail.zimbra@redhat.com> <56A7B34E.2050906@redhat.com> <1320714330.19162635.1453974171503.JavaMail.zimbra@redhat.com> <56BA0388.7040307@redhat.com> Message-ID: <56BAF20B.3080305@redhat.com> On 02/09/2016 04:19 PM, Milan Kub?k wrote: > On 01/28/2016 10:42 AM, Filip Skola wrote: >> >> ----- Original Message ----- >>> On 01/25/2016 11:11 AM, Filip Skola wrote: >>>> ----- Original Message ----- >>>>> On 01/15/2016 03:38 PM, Filip Skola wrote: >>>>>> Hi, >>>>>> >>>>>> sending rebased patch. >>>>>> >>>>>> F. >>>>>> >>>>>> ----- Original Message ----- >>>>>>> Hello, >>>>>>> >>>>>>> sorry for delays. The patch no longer applies to master. Rebase it, >>>>>>> please. >>>>>>> >>>>>>> Milan >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Filip ?kola" >>>>>>> To: "Milan Kub?k" >>>>>>> Cc: freeipa-devel at redhat.com >>>>>>> Sent: Wednesday, 9 December, 2015 7:01:02 PM >>>>>>> Subject: Re: [Freeipa-devel] [PATCH 0002] Refactor >>>>>>> test_group_plugin >>>>>>> >>>>>>> On Mon, 7 Dec 2015 17:49:18 +0100 >>>>>>> Milan Kub?k wrote: >>>>>>> >>>>>>>> On 12/03/2015 08:15 PM, Filip ?kola wrote: >>>>>>>>> On Mon, 30 Nov 2015 17:18:30 +0100 >>>>>>>>> Milan Kub?k wrote: >>>>>>>>> >>>>>>>>>> On 11/23/2015 04:42 PM, Filip ?kola wrote: >>>>>>>>>>> Sending updated patch. >>>>>>>>>>> >>>>>>>>>>> F. >>>>>>>>>>> >>>>>>>>>>> On Mon, 23 Nov 2015 14:59:34 +0100 >>>>>>>>>>> Filip ?kola wrote: >>>>>>>>>>> >>>>>>>>>>>> Found couple of issues (broke some dependencies). >>>>>>>>>>>> >>>>>>>>>>>> NACK >>>>>>>>>>>> >>>>>>>>>>>> F. >>>>>>>>>>>> >>>>>>>>>>>> On Fri, 20 Nov 2015 13:56:36 +0100 >>>>>>>>>>>> Filip ?kola wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Another one. >>>>>>>>>>>>> >>>>>>>>>>>>> F. >>>>>>>>>> Hi, the tests look good. Few remarks, though. >>>>>>>>>> >>>>>>>>>> 1. Please, use the shortes copyright notice in new modules. >>>>>>>>>> >>>>>>>>>> # >>>>>>>>>> # Copyright (C) 2015 FreeIPA Contributors see >>>>>>>>>> COPYING for >>>>>>>>>> license # >>>>>>>>>> >>>>>>>>>> 2. The tests `test_group_remove_group_from_protected_group` and >>>>>>>>>> `test_group_full_set_of_objectclass_not_available_post_detach` >>>>>>>>>> were not ported. Please, include them in the patch. >>>>>>>>>> >>>>>>>>>> Also, for less hassle, please rebase your patches on top of >>>>>>>>>> freeipa-mkubik-0025-3-Separated-Tracker-implementations-into-standalone-pa.patch >>>>>>>>>> >>>>>>>>>> Which changes the location of tracker implementations and >>>>>>>>>> prevents >>>>>>>>>> circular imports. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> these cases are there, in corresponding classes. They are marked >>>>>>>>> with the original comments. (However I can move them to separate >>>>>>>>> class if desirable.) >>>>>>>>> >>>>>>>>> The copyright notice is changed. Also included a few changes >>>>>>>>> in the >>>>>>>>> test with user without private group. >>>>>>>>> >>>>>>>>> Filip >>>>>>>> NACK >>>>>>>> >>>>>>>> linter: >>>>>>>> ************* Module tracker.group_plugin >>>>>>>> ipatests/test_xmlrpc/tracker/group_plugin.py:257: >>>>>>>> [E0102(function-redefined), GroupTracker.check_remove_member] >>>>>>>> method >>>>>>>> already defined line 253) >>>>>>>> >>>>>>>> Probably a leftover after the rebase made on top of my patch. >>>>>>>> Please >>>>>>>> fix it. You can check youch changes by make-lint script before >>>>>>>> sending them. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I learned to use make-lint! >>>>>>> >>>>>>> Thanks, >>>>>>> F. >>>>>>> >>>>> Hello, >>>>> >>>>> NACK, pylint doesn't seem to like the way the fixtures are imported >>>>> (pytest does a lot of runtime magic) [1]. >>>>> One possible solution would be [2]. Though, I don't think this >>>>> would be >>>>> a good idea in our environment. I suggest to create the fixtures >>>>> on per >>>>> module basis. >>>>> >>>>> >>>>> [1]: http://fpaste.org/311949/53118942/ >>>>> [2]: >>>>> https://pytest.org/latest/fixture.html#using-fixtures-from-classes-modules-or-projects >>>>> >>>>> >>>>> -- >>>>> Milan Kubik >>>>> >>>>> >>>> Hi, >>>> >>>> the fixtures were copied into corresponding module. Please note >>>> that this >>>> patch has a dependence on my patch 0001 (user plugin). >>>> >>>> Filip >>> Linter: >>> ************* Module ipatests.test_xmlrpc.tracker.group_plugin >>> W:100,26: Calling a dict.iter*() method (dict-iter-method) >>> >>> please use dict.items >>> >>> -- >>> Milan Kubik >>> >>> >> Hi, sorry. This has been fixed in this patch. >> >> Filip > ACK, thanks for the patience. :) > Sorry, there are some other things I need clarified. NACK. Mail will follow later. -- Milan Kubik From mkubik at redhat.com Wed Feb 10 08:21:15 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 10 Feb 2016 09:21:15 +0100 Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin In-Reply-To: <56BAF20B.3080305@redhat.com> References: <20151120135636.71171d5c@vor2.netbox.priv> <5665B88E.4000507@redhat.com> <20151209190102.1bb8fc07@vor2.netbox.priv> <1914334378.4564827.1452602733244.JavaMail.zimbra@redhat.com> <1760221088.11921867.1452868707220.JavaMail.zimbra@redhat.com> <569CD602.1030604@redhat.com> <1869235561.17372506.1453716664538.JavaMail.zimbra@redhat.com> <56A7B34E.2050906@redhat.com> <1320714330.19162635.1453974171503.JavaMail.zimbra@redhat.com> <56BA0388.7040307@redhat.com> <56BAF20B.3080305@redhat.com> Message-ID: <56BAF2FB.5050100@redhat.com> On 02/10/2016 09:17 AM, Milan Kub?k wrote: > On 02/09/2016 04:19 PM, Milan Kub?k wrote: >> On 01/28/2016 10:42 AM, Filip Skola wrote: >>> >>> ----- Original Message ----- >>>> On 01/25/2016 11:11 AM, Filip Skola wrote: >>>>> ----- Original Message ----- >>>>>> On 01/15/2016 03:38 PM, Filip Skola wrote: >>>>>>> Hi, >>>>>>> >>>>>>> sending rebased patch. >>>>>>> >>>>>>> F. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Hello, >>>>>>>> >>>>>>>> sorry for delays. The patch no longer applies to master. Rebase >>>>>>>> it, >>>>>>>> please. >>>>>>>> >>>>>>>> Milan >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Filip ?kola" >>>>>>>> To: "Milan Kub?k" >>>>>>>> Cc: freeipa-devel at redhat.com >>>>>>>> Sent: Wednesday, 9 December, 2015 7:01:02 PM >>>>>>>> Subject: Re: [Freeipa-devel] [PATCH 0002] Refactor >>>>>>>> test_group_plugin >>>>>>>> >>>>>>>> On Mon, 7 Dec 2015 17:49:18 +0100 >>>>>>>> Milan Kub?k wrote: >>>>>>>> >>>>>>>>> On 12/03/2015 08:15 PM, Filip ?kola wrote: >>>>>>>>>> On Mon, 30 Nov 2015 17:18:30 +0100 >>>>>>>>>> Milan Kub?k wrote: >>>>>>>>>> >>>>>>>>>>> On 11/23/2015 04:42 PM, Filip ?kola wrote: >>>>>>>>>>>> Sending updated patch. >>>>>>>>>>>> >>>>>>>>>>>> F. >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 23 Nov 2015 14:59:34 +0100 >>>>>>>>>>>> Filip ?kola wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Found couple of issues (broke some dependencies). >>>>>>>>>>>>> >>>>>>>>>>>>> NACK >>>>>>>>>>>>> >>>>>>>>>>>>> F. >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, 20 Nov 2015 13:56:36 +0100 >>>>>>>>>>>>> Filip ?kola wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Another one. >>>>>>>>>>>>>> >>>>>>>>>>>>>> F. >>>>>>>>>>> Hi, the tests look good. Few remarks, though. >>>>>>>>>>> >>>>>>>>>>> 1. Please, use the shortes copyright notice in new modules. >>>>>>>>>>> >>>>>>>>>>> # >>>>>>>>>>> # Copyright (C) 2015 FreeIPA Contributors see >>>>>>>>>>> COPYING for >>>>>>>>>>> license # >>>>>>>>>>> >>>>>>>>>>> 2. The tests `test_group_remove_group_from_protected_group` and >>>>>>>>>>> `test_group_full_set_of_objectclass_not_available_post_detach` >>>>>>>>>>> were not ported. Please, include them in the patch. >>>>>>>>>>> >>>>>>>>>>> Also, for less hassle, please rebase your patches on top of >>>>>>>>>>> freeipa-mkubik-0025-3-Separated-Tracker-implementations-into-standalone-pa.patch >>>>>>>>>>> >>>>>>>>>>> Which changes the location of tracker implementations and >>>>>>>>>>> prevents >>>>>>>>>>> circular imports. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> these cases are there, in corresponding classes. They are marked >>>>>>>>>> with the original comments. (However I can move them to separate >>>>>>>>>> class if desirable.) >>>>>>>>>> >>>>>>>>>> The copyright notice is changed. Also included a few changes >>>>>>>>>> in the >>>>>>>>>> test with user without private group. >>>>>>>>>> >>>>>>>>>> Filip >>>>>>>>> NACK >>>>>>>>> >>>>>>>>> linter: >>>>>>>>> ************* Module tracker.group_plugin >>>>>>>>> ipatests/test_xmlrpc/tracker/group_plugin.py:257: >>>>>>>>> [E0102(function-redefined), GroupTracker.check_remove_member] >>>>>>>>> method >>>>>>>>> already defined line 253) >>>>>>>>> >>>>>>>>> Probably a leftover after the rebase made on top of my patch. >>>>>>>>> Please >>>>>>>>> fix it. You can check youch changes by make-lint script before >>>>>>>>> sending them. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I learned to use make-lint! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> F. >>>>>>>> >>>>>> Hello, >>>>>> >>>>>> NACK, pylint doesn't seem to like the way the fixtures are imported >>>>>> (pytest does a lot of runtime magic) [1]. >>>>>> One possible solution would be [2]. Though, I don't think this >>>>>> would be >>>>>> a good idea in our environment. I suggest to create the fixtures >>>>>> on per >>>>>> module basis. >>>>>> >>>>>> >>>>>> [1]: http://fpaste.org/311949/53118942/ >>>>>> [2]: >>>>>> https://pytest.org/latest/fixture.html#using-fixtures-from-classes-modules-or-projects >>>>>> >>>>>> >>>>>> -- >>>>>> Milan Kubik >>>>>> >>>>>> >>>>> Hi, >>>>> >>>>> the fixtures were copied into corresponding module. Please note >>>>> that this >>>>> patch has a dependence on my patch 0001 (user plugin). >>>>> >>>>> Filip >>>> Linter: >>>> ************* Module ipatests.test_xmlrpc.tracker.group_plugin >>>> W:100,26: Calling a dict.iter*() method (dict-iter-method) >>>> >>>> please use dict.items >>>> >>>> -- >>>> Milan Kubik >>>> >>>> >>> Hi, sorry. This has been fixed in this patch. >>> >>> Filip >> ACK, thanks for the patience. :) >> > Sorry, there are some other things I need clarified. NACK. > Mail will follow later. > What is the purpose of `make_fixture_detach` in your patches? They are not used anywhere and the finalizer does nothing. -- Milan Kubik From mbabinsk at redhat.com Thu Feb 11 09:00:52 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 11 Feb 2016 10:00:52 +0100 Subject: [Freeipa-devel] [patch 0032] ipatests: add missing certprofile fixture In-Reply-To: <56BA007E.9000405@redhat.com> References: <56B9EBAD.7090804@redhat.com> <56BA007E.9000405@redhat.com> Message-ID: <56BC4DC4.5070407@redhat.com> On 02/09/2016 04:06 PM, Milan Kub?k wrote: > On 02/09/2016 02:37 PM, Milan Kub?k wrote: >> Fixes the CA ACL tests broken by removed import. This patch doesn't >> rely on undocumented behavior of pytest. >> >> The patch invalidates patch 133 by Martin Babinsky. >> >> >> > Patch updated with trac link > > -- > Milan Kubik > > > ACK I guess, although copypasta makes me very sad. Why do you think the conftest.py approach is not practical for us? -- Martin^3 Babinsky From mbasti at redhat.com Thu Feb 11 09:45:48 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 10:45:48 +0100 Subject: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites In-Reply-To: <56B2101C.3020008@redhat.com> References: <56A0F78F.4060407@redhat.com> <56A21343.2090607@redhat.com> <56A9D59F.4020204@redhat.com> <56AB6C2A.2040604@redhat.com> <56AB71BF.9070009@redhat.com> <56B2101C.3020008@redhat.com> Message-ID: <56BC584C.6060500@redhat.com> On 03.02.2016 15:35, Christian Heimes wrote: > On 2016-01-29 15:05, Martin Basti wrote: >> >> On 29.01.2016 14:42, Christian Heimes wrote: >>> On 2016-01-28 09:47, Martin Basti wrote: >>>> On 22.01.2016 12:32, Martin Kosek wrote: >>>>> On 01/21/2016 04:21 PM, Christian Heimes wrote: >>>>>> The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf >>>>>> has been modernized. Insecure or less secure algorithms such as RC4, >>>>>> DES and 3DES are removed. Perfect forward secrecy suites with >>>>>> ephemeral >>>>>> ECDH key exchange have been added. IE 8 on Windows XP is no longer >>>>>> supported. >>>>>> >>>>>> The list of enabled cipher suites has been generated with the script >>>>>> contrib/nssciphersuite/nssciphersuite.py. >>>>>> >>>>>> The supported suites are currently: >>>>>> >>>>>> TLS_RSA_WITH_AES_128_CBC_SHA256 >>>>>> TLS_RSA_WITH_AES_256_CBC_SHA256 >>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA >>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA >>>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >>>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >>>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA >>>>>> TLS_RSA_WITH_AES_128_GCM_SHA256 >>>>>> TLS_RSA_WITH_AES_128_CBC_SHA >>>>>> TLS_RSA_WITH_AES_256_GCM_SHA384 >>>>>> TLS_RSA_WITH_AES_256_CBC_SHA >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5589 >>>>> Thanks for the patch! I updated the ticket to make sure this change is >>>>> release notes. >>>>> >>>> Hello, >>>> >>>> I'm not sure if I'm the right person to do review on this, but I will >>>> try :-) >>>> >>>> 1) >>>> Your patch adds whitespace error >>>> >>>> Applying: Modernize mod_nss's cipher suites >>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:52: new blank >>>> line at EOF. >>>> + >>>> warning: 1 line adds whitespace errors. >>>> >>>> >>>> 2) >>>> +import urllib.request # pylint: disable=E0611 >>>> >>>> Please specify pylint disabled check by name >>>> >>>> 3) >>>> +def update_mod_nss_cipher_suite(http): >>>> >>>> in this upgrade, is there any possibility that ciphers might be upgraded >>>> again in future? (IMO yes). >>>> >>>> I think, it can be better to store revision of change instead of boolean >>>> >>>> LAST_REVISION = 1 >>>> >>>> if revision >= LAST_REVISION: >>>> return >>>> >>>> sysupgrade.set_upgrade_state('nss.conf', 'cipher_suite_revision', >>>> LAST_REVISION) >>> Thanks for the review. I have addressed the problems. Instead of a >>> revision number I'm using a date string. The sysupgrade module only >>> stores str and bool. With a date-based revision it's easy to see when >>> the cipher suite was checked last time. >>> >>> Christian >>> >> Thanks >> >> 1) Pylint :-) >> + with urllib.request.urlopen(SOURCE) as r: # pylint: disable=E1101 > Thanks! It was easier to change the import to get rid of the second > pylint stanza. > >> 2) >> + if revision == httpinstance.NSS_CIPHER_REVISION: >> >> may happen a case where just comparation with '==' can cause a issues >> (docker world)? Should not be there rather '>='? > Makes sense, I've changed the comparison operator to >=. This may still > override user settings, though. > >> 3) >> + root_logger.info("Cipher suite already updated") >> >> Sorry that I did not noticed earlier, this should be just debug level, >> IMO this message is not so important, it will cause only mess on output >> (we already have plenty of unneeded info messages in upgrade, they will >> be fixed once) > Fine with me :) > > Christian ACK Pushed to: master: 5ac3a3cee534a16db86c541b9beff4939f03410e ipa-4-3: c3496a4a4893c75789bdf0c617e46923361fb43b From mbasti at redhat.com Thu Feb 11 10:08:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 11:08:56 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56B9F709.5060303@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> <56AF5B25.6000706@redhat.com> <56B1C637.1000403@redhat.com> <56B9BF49.60501@redhat.com> <56B9F709.5060303@redhat.com> Message-ID: <56BC5DB8.2030503@redhat.com> On 09.02.2016 15:26, David Kupka wrote: > On 09/02/16 11:28, Martin Basti wrote: >> >> >> On 03.02.2016 10:19, David Kupka wrote: >>> On 01/02/16 14:18, Martin Basti wrote: >>>> >>>> >>>> On 26.01.2016 14:16, Martin Basti wrote: >>>>> >>>>> >>>>> On 20.01.2016 14:38, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 19.1.2016 13:43, Martin Basti wrote: >>>>>>> New pylint version will broke our custom make-lint script again, >>>>>>> attached patch migrates make-lint to: >>>>>>> * config file >>>>>>> * pylint plugin >>>>>>> which are supported by pylint and should not have regular >>>>>>> compatibility >>>>>>> issues >>>>>>> >>>>>>> to test new approach run ./make-lint2 >>>>>>> >>>>>>> Advantages: >>>>>>> * compatibility with pylint >>>>>>> * works on both pylint-1.4.3-3.fc23.noarch and >>>>>>> pylint-1.5.2-1.fc24.noarch >>>>>>> * pylint plugin works in different way than the previous custom >>>>>>> checker. >>>>>>> Missing ("dynamic") attributes are added to abstract syntax tree >>>>>>> instead >>>>>>> of ignoring them and all their sub-members. This makes check >>>>>>> better, >>>>>>> pylint can detect more typos in tests configurations, api, env, >>>>>>> etc.. >>>>>>> >>>>>>> Disadvantages: >>>>>>> * any new attribute in api, test config, etc.. must be added to >>>>>>> definition of missing members (pylint plugin) - this should not >>>>>>> happen >>>>>>> too often >>>>>> >>>>>> 1) Please "mv pylint_plugins/fix_ipa_members.py pylint_plugins.py" >>>>>> and "rm -rf pylint_plugins/", no need for this redundant directory >>>>>> structure. >>>>>> >>>>>> 2) Rename pylintrc to freeipa.pylintrc so you have to always specify >>>>>> it explicitly with --rcfile. >>>>>> >>>>>> 3) Use the load-plugins directive in freeipa.pylintrc to load the >>>>>> plugins rather than --load-plugins. >>>>>> >>>>>> 4) Instead of running pylint twice, run it only once with both >>>>>> normal >>>>>> and Python 3 checks enabled: >>>>>> >>>>>> [MESSAGE CONTROL] >>>>>> enable=all,python3 >>>>>> disable=...,no-absolute-import >>>>>> >>>>>>> >>>>>>> >>>>>>> Q&TODO: >>>>>>> * make-lint: should it be just bash script or rather python script? >>>>>> >>>>>> IMO neither, it should be a make target (make lint). >>>>>> >>>>>>> * add dynamic detection of python files to be checked >>>>>> >>>>>> You can use "find . -type f -executable ! -path \*/.\* ! -name >>>>>> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >>>>>> >>>>>>> * should I keep the current options from original make-lint? >>>>>> >>>>>> No, but allow pylint options to be overridable (make lint >>>>>> PYLINTFLAGS="--disable=python3") >>>>>> >>>>>>> * several false positive errors I haven't been able to fix in >>>>>>> plugin >>>>>>> yet, in worst case they can be locally disabled: >>>>>> >>>>>> Disable them locally. >>>>>> >>>>>> Honza >>>>>> >>>>> Updated patch attached. >>>>> >>>>> Please note that make-lint script has been removed, to execute lint >>>>> check use 'make lint' >>>>> >>>>> >>>> >>>> Updated patch attached: >>>> * fixes recently added error >>>> * fixes PEP8 >>>> * cleanup of pylint config file >>>> >>>> Patch is only for master branch, for 4.3 and 4.2 I will send different >>>> patches when this will be acked >>>> >>>> >>> >>> Could you please add an extensive comment to the 4-lines-long find >>> command? I can after a while (and with the help of man page) decode >>> what it does so it would definitely help to have it described. >>> Otherwise it looks good to me. >>> >> Updated patch attached, only for master, patches for 4.2, 4.3 will >> follow if this one will be ACKed > > The comment is probably sufficient, thanks. > Also works for me on current master, ACK. > Pushed to master: 2ce8921fe69ed58871f8e33e3899ad80dcc28c0e Patches for 4.2 and 4.3 will follow From ldoudova at redhat.com Thu Feb 11 10:13:20 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 11 Feb 2016 11:13:20 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0009] WebUI tests fix Message-ID: <56BC5EC0.7000608@redhat.com> Hi all, most of webUI tests fail with AssertionError: Can't click on checkbox label: table.table Message: Element is not clickable at point (37, 340.3999938964844). Other element would receive the click: The problem seems to be that the tests attempt to click on a checkbox label that is no longer there. Since the checkbox is clickable directly, I changed the code accordingly. Most of the tests should now proceed successfully. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0009-WebUI-tests-fix-failing-tests.patch Type: text/x-patch Size: 1349 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 11 10:15:59 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 11:15:59 +0100 Subject: [Freeipa-devel] INFO: changes to pylint Message-ID: <56BC5F5F.3070808@redhat.com> Please note that current implementation of pylint check has been changed due to upcoming changes in pylint 1.5.x ./make-lint command has been removed To do lint check, please use * make lint * Details https://fedorahosted.org/freeipa/ticket/5615 From pvomacka at redhat.com Thu Feb 11 11:31:17 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 11 Feb 2016 12:31:17 +0100 Subject: [Freeipa-devel] [PATCH] 0005 webui: topology graph: canvas resizes itself according to the window size Message-ID: <56BC7105.3020609@redhat.com> Hello, The canvas of the graph had static size. This patch fixes this issue and from now the graph canvas is resized according to the window size. Pavel Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0005-Resize-topology-graph-canvas-according-to-the-window.patch Type: text/x-patch Size: 2731 bytes Desc: not available URL: From mkubik at redhat.com Thu Feb 11 13:08:39 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 11 Feb 2016 14:08:39 +0100 Subject: [Freeipa-devel] [patch 0032] ipatests: add missing certprofile fixture In-Reply-To: <56BC4DC4.5070407@redhat.com> References: <56B9EBAD.7090804@redhat.com> <56BA007E.9000405@redhat.com> <56BC4DC4.5070407@redhat.com> Message-ID: <56BC87D7.6080206@redhat.com> On 02/11/2016 10:00 AM, Martin Babinsky wrote: > On 02/09/2016 04:06 PM, Milan Kub?k wrote: >> On 02/09/2016 02:37 PM, Milan Kub?k wrote: >>> Fixes the CA ACL tests broken by removed import. This patch doesn't >>> rely on undocumented behavior of pytest. >>> >>> The patch invalidates patch 133 by Martin Babinsky. >>> >>> >>> >> Patch updated with trac link >> >> -- >> Milan Kubik >> >> >> > ACK I guess, although copypasta makes me very sad. > > Why do you think the conftest.py approach is not practical for us? > I think introducing new file to hold shared fixtures is not worth managing it and it also hides (by the virtue of pytest's working) from where the fixture comes. I think it is better in our case to have all fixtures the test uses in its module, even though it looks like copy-pasting. If I had renamed the entry for the test only, would it still been considered copy-paste? Anyway, patch for ipa-4-3 attached. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-ipa43-0032-1-ipatests-Add-missing-certificate-profile-fixture.patch Type: text/x-patch Size: 1589 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Feb 11 13:12:23 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 11 Feb 2016 14:12:23 +0100 Subject: [Freeipa-devel] [patch 0032] ipatests: add missing certprofile fixture In-Reply-To: <56BC87D7.6080206@redhat.com> References: <56B9EBAD.7090804@redhat.com> <56BA007E.9000405@redhat.com> <56BC4DC4.5070407@redhat.com> <56BC87D7.6080206@redhat.com> Message-ID: <56BC88B7.6010909@redhat.com> On 02/11/2016 02:08 PM, Milan Kub?k wrote: > On 02/11/2016 10:00 AM, Martin Babinsky wrote: >> On 02/09/2016 04:06 PM, Milan Kub?k wrote: >>> On 02/09/2016 02:37 PM, Milan Kub?k wrote: >>>> Fixes the CA ACL tests broken by removed import. This patch doesn't >>>> rely on undocumented behavior of pytest. >>>> >>>> The patch invalidates patch 133 by Martin Babinsky. >>>> >>>> >>>> >>> Patch updated with trac link >>> >>> -- >>> Milan Kubik >>> >>> >>> >> ACK I guess, although copypasta makes me very sad. >> >> Why do you think the conftest.py approach is not practical for us? >> > I think introducing new file to hold shared fixtures is not worth > managing it and it also hides (by the virtue of pytest's working) from > where the fixture comes. I think it is better in our case to have all > fixtures the test uses in its module, even though it looks like > copy-pasting. If I had renamed the entry for the test only, would it > still been considered copy-paste? > > Anyway, patch for ipa-4-3 attached. > > ACK to both. -- Martin^3 Babinsky From mbasti at redhat.com Thu Feb 11 13:16:30 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 14:16:30 +0100 Subject: [Freeipa-devel] [patch 0032] ipatests: add missing certprofile fixture In-Reply-To: <56BC88B7.6010909@redhat.com> References: <56B9EBAD.7090804@redhat.com> <56BA007E.9000405@redhat.com> <56BC4DC4.5070407@redhat.com> <56BC87D7.6080206@redhat.com> <56BC88B7.6010909@redhat.com> Message-ID: <56BC89AE.2070403@redhat.com> On 11.02.2016 14:12, Martin Babinsky wrote: > On 02/11/2016 02:08 PM, Milan Kub?k wrote: >> On 02/11/2016 10:00 AM, Martin Babinsky wrote: >>> On 02/09/2016 04:06 PM, Milan Kub?k wrote: >>>> On 02/09/2016 02:37 PM, Milan Kub?k wrote: >>>>> Fixes the CA ACL tests broken by removed import. This patch doesn't >>>>> rely on undocumented behavior of pytest. >>>>> >>>>> The patch invalidates patch 133 by Martin Babinsky. >>>>> >>>>> >>>>> >>>> Patch updated with trac link >>>> >>>> -- >>>> Milan Kubik >>>> >>>> >>>> >>> ACK I guess, although copypasta makes me very sad. >>> >>> Why do you think the conftest.py approach is not practical for us? >>> >> I think introducing new file to hold shared fixtures is not worth >> managing it and it also hides (by the virtue of pytest's working) from >> where the fixture comes. I think it is better in our case to have all >> fixtures the test uses in its module, even though it looks like >> copy-pasting. If I had renamed the entry for the test only, would it >> still been considered copy-paste? >> >> Anyway, patch for ipa-4-3 attached. >> >> > ACK to both. Pushed to master: 87ee451c7d9b311192893b2a2c82d8d757281fa6 Pushed to ipa-4-3: 8aec20124d415daeea3764294224fea47f8e7b0a From amarecek at redhat.com Thu Feb 11 13:21:52 2016 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Thu, 11 Feb 2016 08:21:52 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin In-Reply-To: <1415364427.17513799.1453733845873.JavaMail.zimbra@redhat.com> References: <1415364427.17513799.1453733845873.JavaMail.zimbra@redhat.com> Message-ID: <1464040446.19836563.1455196912586.JavaMail.zimbra@redhat.com> NACK. "create_sudocmd" and "delete_sudocmd" should be placed in Tracker. So this patch should create the tracker as well. ----- Original Message ----- > From: "Filip Skola" > To: freeipa-devel at redhat.com > Sent: Monday, January 25, 2016 3:57:25 PM > Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin > > Hello, > > attaching refactored sudocmd_plugin. > > Filip > -- > 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 amarecek at redhat.com Thu Feb 11 13:23:14 2016 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Thu, 11 Feb 2016 08:23:14 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, create SudoCmdGroupTracker In-Reply-To: <1667642851.19197845.1453981757248.JavaMail.zimbra@redhat.com> References: <1667642851.19197845.1453981757248.JavaMail.zimbra@redhat.com> Message-ID: <289487922.19837303.1455196994918.JavaMail.zimbra@redhat.com> NACK. "create_sudocmd" and "delete_sudocmd" should be imported from Tracker, not from the previous test (sudocmd_plugin). - alich - ----- Original Message ----- > From: "Filip Skola" > To: freeipa-devel at redhat.com > Sent: Thursday, January 28, 2016 12:49:17 PM > Subject: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, create SudoCmdGroupTracker > > Hi, > > sending the next sudo patch. This one depends on the previous one > (sudocmd_plugin). > > Filip > > -- > 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 mkosek at redhat.com Thu Feb 11 13:43:56 2016 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Feb 2016 14:43:56 +0100 Subject: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites In-Reply-To: <56BC584C.6060500@redhat.com> References: <56A0F78F.4060407@redhat.com> <56A21343.2090607@redhat.com> <56A9D59F.4020204@redhat.com> <56AB6C2A.2040604@redhat.com> <56AB71BF.9070009@redhat.com> <56B2101C.3020008@redhat.com> <56BC584C.6060500@redhat.com> Message-ID: <56BC901C.1040907@redhat.com> On 02/11/2016 10:45 AM, Martin Basti wrote: > > > On 03.02.2016 15:35, Christian Heimes wrote: >> On 2016-01-29 15:05, Martin Basti wrote: >>> >>> On 29.01.2016 14:42, Christian Heimes wrote: >>>> On 2016-01-28 09:47, Martin Basti wrote: >>>>> On 22.01.2016 12:32, Martin Kosek wrote: >>>>>> On 01/21/2016 04:21 PM, Christian Heimes wrote: >>>>>>> The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf >>>>>>> has been modernized. Insecure or less secure algorithms such as RC4, >>>>>>> DES and 3DES are removed. Perfect forward secrecy suites with >>>>>>> ephemeral >>>>>>> ECDH key exchange have been added. IE 8 on Windows XP is no longer >>>>>>> supported. >>>>>>> >>>>>>> The list of enabled cipher suites has been generated with the script >>>>>>> contrib/nssciphersuite/nssciphersuite.py. >>>>>>> >>>>>>> The supported suites are currently: >>>>>>> >>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA256 >>>>>>> TLS_RSA_WITH_AES_256_CBC_SHA256 >>>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA >>>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >>>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA >>>>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>>>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >>>>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >>>>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA >>>>>>> TLS_RSA_WITH_AES_128_GCM_SHA256 >>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA >>>>>>> TLS_RSA_WITH_AES_256_GCM_SHA384 >>>>>>> TLS_RSA_WITH_AES_256_CBC_SHA >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5589 >>>>>> Thanks for the patch! I updated the ticket to make sure this change is >>>>>> release notes. >>>>>> >>>>> Hello, >>>>> >>>>> I'm not sure if I'm the right person to do review on this, but I will >>>>> try :-) >>>>> >>>>> 1) >>>>> Your patch adds whitespace error >>>>> >>>>> Applying: Modernize mod_nss's cipher suites >>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:52: new blank >>>>> line at EOF. >>>>> + >>>>> warning: 1 line adds whitespace errors. >>>>> >>>>> >>>>> 2) >>>>> +import urllib.request # pylint: disable=E0611 >>>>> >>>>> Please specify pylint disabled check by name >>>>> >>>>> 3) >>>>> +def update_mod_nss_cipher_suite(http): >>>>> >>>>> in this upgrade, is there any possibility that ciphers might be upgraded >>>>> again in future? (IMO yes). >>>>> >>>>> I think, it can be better to store revision of change instead of boolean >>>>> >>>>> LAST_REVISION = 1 >>>>> >>>>> if revision >= LAST_REVISION: >>>>> return >>>>> >>>>> sysupgrade.set_upgrade_state('nss.conf', 'cipher_suite_revision', >>>>> LAST_REVISION) >>>> Thanks for the review. I have addressed the problems. Instead of a >>>> revision number I'm using a date string. The sysupgrade module only >>>> stores str and bool. With a date-based revision it's easy to see when >>>> the cipher suite was checked last time. >>>> >>>> Christian >>>> >>> Thanks >>> >>> 1) Pylint :-) >>> + with urllib.request.urlopen(SOURCE) as r: # pylint: disable=E1101 >> Thanks! It was easier to change the import to get rid of the second >> pylint stanza. >> >>> 2) >>> + if revision == httpinstance.NSS_CIPHER_REVISION: >>> >>> may happen a case where just comparation with '==' can cause a issues >>> (docker world)? Should not be there rather '>='? >> Makes sense, I've changed the comparison operator to >=. This may still >> override user settings, though. >> >>> 3) >>> + root_logger.info("Cipher suite already updated") >>> >>> Sorry that I did not noticed earlier, this should be just debug level, >>> IMO this message is not so important, it will cause only mess on output >>> (we already have plenty of unneeded info messages in upgrade, they will >>> be fixed once) >> Fine with me :) >> >> Christian > ACK > > Pushed to: > master: 5ac3a3cee534a16db86c541b9beff4939f03410e > ipa-4-3: c3496a4a4893c75789bdf0c617e46923361fb43b > Very cool! Thanks guys! Looking forward to deploying FreeIPA 4.3.1 on the FreeIPA public demo :-) From mbabinsk at redhat.com Thu Feb 11 17:34:15 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 11 Feb 2016 18:34:15 +0100 Subject: [Freeipa-devel] [PATCH 0411] upgrade: log to ipaupgrade.log if ipa is not installed In-Reply-To: <56AB3550.6020409@redhat.com> References: <56AB3550.6020409@redhat.com> Message-ID: <56BCC617.8050409@redhat.com> On 01/29/2016 10:48 AM, Martin Basti wrote: > Missing record in ipaupgrade.log that upgrade failed because IPA is not > installed, causes harder time to debugging upgrade from log. > > Patch attached. > > ACK. -- Martin^3 Babinsky From mbasti at redhat.com Thu Feb 11 17:41:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 18:41:58 +0100 Subject: [Freeipa-devel] [PATCH 544] replica promotion: fix AVC denials in remote connection check In-Reply-To: <56B3256D.5080303@redhat.com> References: <56B30E71.7080909@redhat.com> <56B3256D.5080303@redhat.com> Message-ID: <56BCC7E6.20008@redhat.com> On 04.02.2016 11:18, Martin Babinsky wrote: > On 02/04/2016 09:40 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > Connection check for replica/CA install now works in enforcing mode, ACK. > Pushed to: master: b3411dc985c26146c91c2733ebdc0c098ec22266 ipa-4-3: a0c06038f44ec450eb0dca0e789a71b97def3abc From mbasti at redhat.com Thu Feb 11 17:45:05 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 18:45:05 +0100 Subject: [Freeipa-devel] [PATCH 0411] upgrade: log to ipaupgrade.log if ipa is not installed In-Reply-To: <56BCC617.8050409@redhat.com> References: <56AB3550.6020409@redhat.com> <56BCC617.8050409@redhat.com> Message-ID: <56BCC8A1.10201@redhat.com> On 11.02.2016 18:34, Martin Babinsky wrote: > On 01/29/2016 10:48 AM, Martin Basti wrote: >> Missing record in ipaupgrade.log that upgrade failed because IPA is not >> installed, causes harder time to debugging upgrade from log. >> >> Patch attached. >> >> > ACK. > Pushed to master: 0ea7433d09e24904a06d6ed02c9a89b1ea4bbc43 From mbasti at redhat.com Thu Feb 11 17:47:16 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Feb 2016 18:47:16 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56BC5DB8.2030503@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> <56AF5B25.6000706@redhat.com> <56B1C637.1000403@redhat.com> <56B9BF49.60501@redhat.com> <56B9F709.5060303@redhat.com> <56BC5DB8.2030503@redhat.com> Message-ID: <56BCC924.5050500@redhat.com> On 11.02.2016 11:08, Martin Basti wrote: > > > On 09.02.2016 15:26, David Kupka wrote: >> On 09/02/16 11:28, Martin Basti wrote: >>> >>> >>> On 03.02.2016 10:19, David Kupka wrote: >>>> On 01/02/16 14:18, Martin Basti wrote: >>>>> >>>>> >>>>> On 26.01.2016 14:16, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 20.01.2016 14:38, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 19.1.2016 13:43, Martin Basti wrote: >>>>>>>> New pylint version will broke our custom make-lint script again, >>>>>>>> attached patch migrates make-lint to: >>>>>>>> * config file >>>>>>>> * pylint plugin >>>>>>>> which are supported by pylint and should not have regular >>>>>>>> compatibility >>>>>>>> issues >>>>>>>> >>>>>>>> to test new approach run ./make-lint2 >>>>>>>> >>>>>>>> Advantages: >>>>>>>> * compatibility with pylint >>>>>>>> * works on both pylint-1.4.3-3.fc23.noarch and >>>>>>>> pylint-1.5.2-1.fc24.noarch >>>>>>>> * pylint plugin works in different way than the previous custom >>>>>>>> checker. >>>>>>>> Missing ("dynamic") attributes are added to abstract syntax tree >>>>>>>> instead >>>>>>>> of ignoring them and all their sub-members. This makes check >>>>>>>> better, >>>>>>>> pylint can detect more typos in tests configurations, api, env, >>>>>>>> etc.. >>>>>>>> >>>>>>>> Disadvantages: >>>>>>>> * any new attribute in api, test config, etc.. must be added to >>>>>>>> definition of missing members (pylint plugin) - this should not >>>>>>>> happen >>>>>>>> too often >>>>>>> >>>>>>> 1) Please "mv pylint_plugins/fix_ipa_members.py pylint_plugins.py" >>>>>>> and "rm -rf pylint_plugins/", no need for this redundant directory >>>>>>> structure. >>>>>>> >>>>>>> 2) Rename pylintrc to freeipa.pylintrc so you have to always >>>>>>> specify >>>>>>> it explicitly with --rcfile. >>>>>>> >>>>>>> 3) Use the load-plugins directive in freeipa.pylintrc to load the >>>>>>> plugins rather than --load-plugins. >>>>>>> >>>>>>> 4) Instead of running pylint twice, run it only once with both >>>>>>> normal >>>>>>> and Python 3 checks enabled: >>>>>>> >>>>>>> [MESSAGE CONTROL] >>>>>>> enable=all,python3 >>>>>>> disable=...,no-absolute-import >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Q&TODO: >>>>>>>> * make-lint: should it be just bash script or rather python >>>>>>>> script? >>>>>>> >>>>>>> IMO neither, it should be a make target (make lint). >>>>>>> >>>>>>>> * add dynamic detection of python files to be checked >>>>>>> >>>>>>> You can use "find . -type f -executable ! -path \*/.\* ! -name >>>>>>> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >>>>>>> >>>>>>>> * should I keep the current options from original make-lint? >>>>>>> >>>>>>> No, but allow pylint options to be overridable (make lint >>>>>>> PYLINTFLAGS="--disable=python3") >>>>>>> >>>>>>>> * several false positive errors I haven't been able to fix in >>>>>>>> plugin >>>>>>>> yet, in worst case they can be locally disabled: >>>>>>> >>>>>>> Disable them locally. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> Please note that make-lint script has been removed, to execute lint >>>>>> check use 'make lint' >>>>>> >>>>>> >>>>> >>>>> Updated patch attached: >>>>> * fixes recently added error >>>>> * fixes PEP8 >>>>> * cleanup of pylint config file >>>>> >>>>> Patch is only for master branch, for 4.3 and 4.2 I will send >>>>> different >>>>> patches when this will be acked >>>>> >>>>> >>>> >>>> Could you please add an extensive comment to the 4-lines-long find >>>> command? I can after a while (and with the help of man page) decode >>>> what it does so it would definitely help to have it described. >>>> Otherwise it looks good to me. >>>> >>> Updated patch attached, only for master, patches for 4.2, 4.3 will >>> follow if this one will be ACKed >> >> The comment is probably sufficient, thanks. >> Also works for me on current master, ACK. >> > Pushed to master: 2ce8921fe69ed58871f8e33e3899ad80dcc28c0e > > Patches for 4.2 and 4.3 will follow > Patches for 4.2, 4.3 attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbasti-0407-make-lint-use-config-file-and-plugin-for-pylint.patch Type: text/x-patch Size: 25166 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-3-mbasti-0407-make-lint-use-config-file-and-plugin-for-pylint.patch Type: text/x-patch Size: 24019 bytes Desc: not available URL: From dkupka at redhat.com Fri Feb 12 09:18:01 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 12 Feb 2016 10:18:01 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56BCC924.5050500@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> <56AF5B25.6000706@redhat.com> <56B1C637.1000403@redhat.com> <56B9BF49.60501@redhat.com> <56B9F709.5060303@redhat.com> <56BC5DB8.2030503@redhat.com> <56BCC924.5050500@redhat.com> Message-ID: <56BDA349.80605@redhat.com> On 11/02/16 18:47, Martin Basti wrote: > > > On 11.02.2016 11:08, Martin Basti wrote: >> >> >> On 09.02.2016 15:26, David Kupka wrote: >>> On 09/02/16 11:28, Martin Basti wrote: >>>> >>>> >>>> On 03.02.2016 10:19, David Kupka wrote: >>>>> On 01/02/16 14:18, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 26.01.2016 14:16, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 20.01.2016 14:38, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 19.1.2016 13:43, Martin Basti wrote: >>>>>>>>> New pylint version will broke our custom make-lint script again, >>>>>>>>> attached patch migrates make-lint to: >>>>>>>>> * config file >>>>>>>>> * pylint plugin >>>>>>>>> which are supported by pylint and should not have regular >>>>>>>>> compatibility >>>>>>>>> issues >>>>>>>>> >>>>>>>>> to test new approach run ./make-lint2 >>>>>>>>> >>>>>>>>> Advantages: >>>>>>>>> * compatibility with pylint >>>>>>>>> * works on both pylint-1.4.3-3.fc23.noarch and >>>>>>>>> pylint-1.5.2-1.fc24.noarch >>>>>>>>> * pylint plugin works in different way than the previous custom >>>>>>>>> checker. >>>>>>>>> Missing ("dynamic") attributes are added to abstract syntax tree >>>>>>>>> instead >>>>>>>>> of ignoring them and all their sub-members. This makes check >>>>>>>>> better, >>>>>>>>> pylint can detect more typos in tests configurations, api, env, >>>>>>>>> etc.. >>>>>>>>> >>>>>>>>> Disadvantages: >>>>>>>>> * any new attribute in api, test config, etc.. must be added to >>>>>>>>> definition of missing members (pylint plugin) - this should not >>>>>>>>> happen >>>>>>>>> too often >>>>>>>> >>>>>>>> 1) Please "mv pylint_plugins/fix_ipa_members.py pylint_plugins.py" >>>>>>>> and "rm -rf pylint_plugins/", no need for this redundant directory >>>>>>>> structure. >>>>>>>> >>>>>>>> 2) Rename pylintrc to freeipa.pylintrc so you have to always >>>>>>>> specify >>>>>>>> it explicitly with --rcfile. >>>>>>>> >>>>>>>> 3) Use the load-plugins directive in freeipa.pylintrc to load the >>>>>>>> plugins rather than --load-plugins. >>>>>>>> >>>>>>>> 4) Instead of running pylint twice, run it only once with both >>>>>>>> normal >>>>>>>> and Python 3 checks enabled: >>>>>>>> >>>>>>>> [MESSAGE CONTROL] >>>>>>>> enable=all,python3 >>>>>>>> disable=...,no-absolute-import >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Q&TODO: >>>>>>>>> * make-lint: should it be just bash script or rather python >>>>>>>>> script? >>>>>>>> >>>>>>>> IMO neither, it should be a make target (make lint). >>>>>>>> >>>>>>>>> * add dynamic detection of python files to be checked >>>>>>>> >>>>>>>> You can use "find . -type f -executable ! -path \*/.\* ! -name >>>>>>>> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >>>>>>>> >>>>>>>>> * should I keep the current options from original make-lint? >>>>>>>> >>>>>>>> No, but allow pylint options to be overridable (make lint >>>>>>>> PYLINTFLAGS="--disable=python3") >>>>>>>> >>>>>>>>> * several false positive errors I haven't been able to fix in >>>>>>>>> plugin >>>>>>>>> yet, in worst case they can be locally disabled: >>>>>>>> >>>>>>>> Disable them locally. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>>> Please note that make-lint script has been removed, to execute lint >>>>>>> check use 'make lint' >>>>>>> >>>>>>> >>>>>> >>>>>> Updated patch attached: >>>>>> * fixes recently added error >>>>>> * fixes PEP8 >>>>>> * cleanup of pylint config file >>>>>> >>>>>> Patch is only for master branch, for 4.3 and 4.2 I will send >>>>>> different >>>>>> patches when this will be acked >>>>>> >>>>>> >>>>> >>>>> Could you please add an extensive comment to the 4-lines-long find >>>>> command? I can after a while (and with the help of man page) decode >>>>> what it does so it would definitely help to have it described. >>>>> Otherwise it looks good to me. >>>>> >>>> Updated patch attached, only for master, patches for 4.2, 4.3 will >>>> follow if this one will be ACKed >>> >>> The comment is probably sufficient, thanks. >>> Also works for me on current master, ACK. >>> >> Pushed to master: 2ce8921fe69ed58871f8e33e3899ad80dcc28c0e >> >> Patches for 4.2 and 4.3 will follow >> > Patches for 4.2, 4.3 attached > > Works for me, ACK. -- David Kupka From mbasti at redhat.com Fri Feb 12 09:26:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Feb 2016 10:26:36 +0100 Subject: [Freeipa-devel] [PATCH 0407] make lint: migration to config file and pylint plugin due pylint 1.5.2 In-Reply-To: <56BDA349.80605@redhat.com> References: <569E2F8A.5090905@redhat.com> <569F8DEC.6090701@redhat.com> <56A771B8.1000803@redhat.com> <56AF5B25.6000706@redhat.com> <56B1C637.1000403@redhat.com> <56B9BF49.60501@redhat.com> <56B9F709.5060303@redhat.com> <56BC5DB8.2030503@redhat.com> <56BCC924.5050500@redhat.com> <56BDA349.80605@redhat.com> Message-ID: <56BDA54C.2020105@redhat.com> On 12.02.2016 10:18, David Kupka wrote: > On 11/02/16 18:47, Martin Basti wrote: >> >> >> On 11.02.2016 11:08, Martin Basti wrote: >>> >>> >>> On 09.02.2016 15:26, David Kupka wrote: >>>> On 09/02/16 11:28, Martin Basti wrote: >>>>> >>>>> >>>>> On 03.02.2016 10:19, David Kupka wrote: >>>>>> On 01/02/16 14:18, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 26.01.2016 14:16, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 20.01.2016 14:38, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 19.1.2016 13:43, Martin Basti wrote: >>>>>>>>>> New pylint version will broke our custom make-lint script again, >>>>>>>>>> attached patch migrates make-lint to: >>>>>>>>>> * config file >>>>>>>>>> * pylint plugin >>>>>>>>>> which are supported by pylint and should not have regular >>>>>>>>>> compatibility >>>>>>>>>> issues >>>>>>>>>> >>>>>>>>>> to test new approach run ./make-lint2 >>>>>>>>>> >>>>>>>>>> Advantages: >>>>>>>>>> * compatibility with pylint >>>>>>>>>> * works on both pylint-1.4.3-3.fc23.noarch and >>>>>>>>>> pylint-1.5.2-1.fc24.noarch >>>>>>>>>> * pylint plugin works in different way than the previous custom >>>>>>>>>> checker. >>>>>>>>>> Missing ("dynamic") attributes are added to abstract syntax tree >>>>>>>>>> instead >>>>>>>>>> of ignoring them and all their sub-members. This makes check >>>>>>>>>> better, >>>>>>>>>> pylint can detect more typos in tests configurations, api, env, >>>>>>>>>> etc.. >>>>>>>>>> >>>>>>>>>> Disadvantages: >>>>>>>>>> * any new attribute in api, test config, etc.. must be added to >>>>>>>>>> definition of missing members (pylint plugin) - this should not >>>>>>>>>> happen >>>>>>>>>> too often >>>>>>>>> >>>>>>>>> 1) Please "mv pylint_plugins/fix_ipa_members.py >>>>>>>>> pylint_plugins.py" >>>>>>>>> and "rm -rf pylint_plugins/", no need for this redundant >>>>>>>>> directory >>>>>>>>> structure. >>>>>>>>> >>>>>>>>> 2) Rename pylintrc to freeipa.pylintrc so you have to always >>>>>>>>> specify >>>>>>>>> it explicitly with --rcfile. >>>>>>>>> >>>>>>>>> 3) Use the load-plugins directive in freeipa.pylintrc to load the >>>>>>>>> plugins rather than --load-plugins. >>>>>>>>> >>>>>>>>> 4) Instead of running pylint twice, run it only once with both >>>>>>>>> normal >>>>>>>>> and Python 3 checks enabled: >>>>>>>>> >>>>>>>>> [MESSAGE CONTROL] >>>>>>>>> enable=all,python3 >>>>>>>>> disable=...,no-absolute-import >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Q&TODO: >>>>>>>>>> * make-lint: should it be just bash script or rather python >>>>>>>>>> script? >>>>>>>>> >>>>>>>>> IMO neither, it should be a make target (make lint). >>>>>>>>> >>>>>>>>>> * add dynamic detection of python files to be checked >>>>>>>>> >>>>>>>>> You can use "find . -type f -executable ! -path \*/.\* ! -name >>>>>>>>> \*.py\* -exec grep -lsm1 '^#!.*\bpython' \{\} \;". >>>>>>>>> >>>>>>>>>> * should I keep the current options from original make-lint? >>>>>>>>> >>>>>>>>> No, but allow pylint options to be overridable (make lint >>>>>>>>> PYLINTFLAGS="--disable=python3") >>>>>>>>> >>>>>>>>>> * several false positive errors I haven't been able to fix in >>>>>>>>>> plugin >>>>>>>>>> yet, in worst case they can be locally disabled: >>>>>>>>> >>>>>>>>> Disable them locally. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> Updated patch attached. >>>>>>>> >>>>>>>> Please note that make-lint script has been removed, to execute >>>>>>>> lint >>>>>>>> check use 'make lint' >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Updated patch attached: >>>>>>> * fixes recently added error >>>>>>> * fixes PEP8 >>>>>>> * cleanup of pylint config file >>>>>>> >>>>>>> Patch is only for master branch, for 4.3 and 4.2 I will send >>>>>>> different >>>>>>> patches when this will be acked >>>>>>> >>>>>>> >>>>>> >>>>>> Could you please add an extensive comment to the 4-lines-long find >>>>>> command? I can after a while (and with the help of man page) decode >>>>>> what it does so it would definitely help to have it described. >>>>>> Otherwise it looks good to me. >>>>>> >>>>> Updated patch attached, only for master, patches for 4.2, 4.3 will >>>>> follow if this one will be ACKed >>>> >>>> The comment is probably sufficient, thanks. >>>> Also works for me on current master, ACK. >>>> >>> Pushed to master: 2ce8921fe69ed58871f8e33e3899ad80dcc28c0e >>> >>> Patches for 4.2 and 4.3 will follow >>> >> Patches for 4.2, 4.3 attached >> >> > Works for me, ACK. > Pushed to ipa-4-3: 6dff0e4ad44c8e1bf0add0149d01bff963192f7a Pushed to ipa-4-2: f2245901e1d717ea8de98d751400838bd8bf1a71 From dkupka at redhat.com Fri Feb 12 09:50:16 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 12 Feb 2016 10:50:16 +0100 Subject: [Freeipa-devel] [PATCH] CI: Add simple replication test in 2-connected topology. In-Reply-To: <56BAEC17.7050406@redhat.com> References: <56BAEC17.7050406@redhat.com> Message-ID: <56BDAAD8.9050304@redhat.com> On 10/02/16 08:51, David Kupka wrote: > This topology should be closer to the ones in real world than our > current ones. But it is still impractical and (hopefully) no one has > such deployment. > If some user could share his/her deployment topology I will be happy to > create generator based on it. > Updated patches attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0081.1-CI-Add-2-connected-topology-generator.patch Type: text/x-patch Size: 2576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0082.1-CI-Add-simple-replication-test-in-2-connected-topolo.patch Type: text/x-patch Size: 1531 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0083.1-CI-Add-test-for-2-connected-topology-generator.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: From dkupka at redhat.com Fri Feb 12 09:59:43 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 12 Feb 2016 10:59:43 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology Message-ID: <56BDAD0F.6070706@redhat.com> Sending one more topology test. This one creates a M groups consisting N (N>=2) servers. First two servers in each group are used to connect with nearest four groups and also with the other servers inside the group (when N>2). Servers inside the group (not connecting to other groups) are connected with each other. The patch set needs freeipa-dkupka-8{1,2,3} applied. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0084-CI-Add-double-circle-topology.patch Type: text/x-patch Size: 2603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0085-CI-Add-replication-test-utilizing-double-circle-topo.patch Type: text/x-patch Size: 1547 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0086-CI-Add-test-for-double-circle-topology-generator.patch Type: text/x-patch Size: 2013 bytes Desc: not available URL: From cheimes at redhat.com Fri Feb 12 11:34:34 2016 From: cheimes at redhat.com (Christian Heimes) Date: Fri, 12 Feb 2016 12:34:34 +0100 Subject: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites In-Reply-To: <56BC901C.1040907@redhat.com> References: <56A0F78F.4060407@redhat.com> <56A21343.2090607@redhat.com> <56A9D59F.4020204@redhat.com> <56AB6C2A.2040604@redhat.com> <56AB71BF.9070009@redhat.com> <56B2101C.3020008@redhat.com> <56BC584C.6060500@redhat.com> <56BC901C.1040907@redhat.com> Message-ID: <56BDC34A.9040203@redhat.com> On 2016-02-11 14:43, Martin Kosek wrote: >> Pushed to: >> master: 5ac3a3cee534a16db86c541b9beff4939f03410e >> ipa-4-3: c3496a4a4893c75789bdf0c617e46923361fb43b >> > > Very cool! Thanks guys! Looking forward to deploying FreeIPA 4.3.1 on the > FreeIPA public demo :-) I have to change the cipher list again in the near future. During DevConf.CZ Bob pointed out some issues with key sizes in post quantum crypto world [1]. Rob and I are working on a patch for mod_nss for finite field ephemeral DH key exchange. Once the patch has landed, I'll update the cipher list to support also kDHE. Christian [1] https://devconfcz2016.sched.org/event/5m21/post-quantum-crypo-what-is-it-and-do-we-need-it -------------- 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 Fri Feb 12 12:03:18 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 12 Feb 2016 13:03:18 +0100 Subject: [Freeipa-devel] [PATCH] CI: Add simple replication test in 2-connected topology. In-Reply-To: <56BDAAD8.9050304@redhat.com> References: <56BAEC17.7050406@redhat.com> <56BDAAD8.9050304@redhat.com> Message-ID: <56BDCA06.7060208@redhat.com> On 02/12/2016 10:50 AM, David Kupka wrote: > On 10/02/16 08:51, David Kupka wrote: >> This topology should be closer to the ones in real world than our >> current ones. But it is still impractical and (hopefully) no one has >> such deployment. >> If some user could share his/her deployment topology I will be happy to >> create generator based on it. >> > Updated patches attached. > ACK. Thanks for providing more complicated topologies. -- Milan Kubik From mkubik at redhat.com Fri Feb 12 12:03:37 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 12 Feb 2016 13:03:37 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56BDAD0F.6070706@redhat.com> References: <56BDAD0F.6070706@redhat.com> Message-ID: <56BDCA19.1040405@redhat.com> On 02/12/2016 10:59 AM, David Kupka wrote: > Sending one more topology test. This one creates a M groups consisting > N (N>=2) servers. > First two servers in each group are used to connect with nearest four > groups and also with the other servers inside the group (when N>2). > Servers inside the group (not connecting to other groups) are > connected with each other. > > The patch set needs freeipa-dkupka-8{1,2,3} applied. > ACK -- Milan Kubik From pvomacka at redhat.com Fri Feb 12 12:15:16 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 12 Feb 2016 13:15:16 +0100 Subject: [Freeipa-devel] [PATCH] 0004 webui: topology graph: Add pan and zoom functionality In-Reply-To: <56B2108E.2@redhat.com> References: <56B2108E.2@redhat.com> Message-ID: <56BDCCD4.9000506@redhat.com> On 02/03/2016 03:37 PM, Pavel Vomacka wrote: > Hello, > > I'm sending a patch for review. This patch adds pan and zoom > functionality to the topology graph. The page remembers old position > and size of the graph. So, it keeps these settings after refreshing > the page. > > The patch is in atachement. > > Pavel Vomacka > > Hello, I found one small bug during developing another features so I'm sending a new patch. There were situations when you turned off the fixed state of node by doubleclick but the node stayed at the same place. This behaviour was caused by missing layout.resume() in the dragended event handler. I also forgot to add a link to the ticket. So, here it is: https://fedorahosted.org/freeipa/ticket/5502 . The new patch is in atachement. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0004-2-Add-pan-and-zoom-functionality-to-the-topology-graph.patch Type: text/x-patch Size: 6313 bytes Desc: not available URL: From pvomacka at redhat.com Fri Feb 12 12:52:54 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 12 Feb 2016 13:52:54 +0100 Subject: [Freeipa-devel] [PATCH] 0005 webui: topology graph: canvas resizes itself according to the window size In-Reply-To: <56BC7105.3020609@redhat.com> References: <56BC7105.3020609@redhat.com> Message-ID: <56BDD5A6.8010108@redhat.com> On 02/11/2016 12:31 PM, Pavel Vomacka wrote: > Hello, > > The canvas of the graph had static size. This patch fixes this issue > and from now the graph canvas is resized according to the window size. > > Pavel Vomacka > > Because of changes in previous patch I'm sending also this one again. Plus I fixed some jslint warnings. And again a link to the ticket: https://fedorahosted.org/freeipa/ticket/5647 . -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0005-2-Resize-topology-graph-canvas-according-to-window-siz.patch Type: text/x-patch Size: 2731 bytes Desc: not available URL: From mkubik at redhat.com Fri Feb 12 15:03:25 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Fri, 12 Feb 2016 16:03:25 +0100 Subject: [Freeipa-devel] [TEST][Patch 0022] small refactoring in integration tests due to BZ 1303095 In-Reply-To: <56B3029F.70001@redhat.com> References: <56AB80BE.4090604@redhat.com> <56B1C6E2.60106@redhat.com> <56B1FE4C.4080600@redhat.com> <56B3029F.70001@redhat.com> Message-ID: <56BDF43D.70503@redhat.com> On 02/04/2016 08:49 AM, Oleg Fayans wrote: > Hi Petr, > > On 02/03/2016 02:19 PM, Petr Spacek wrote: >> On 3.2.2016 10:22, Oleg Fayans wrote: >>> Guys, can anyone take a look at this? >> The commit message does not explain why you are setting search path. > Fixed. > >> I have to say that I do not like touching resolv.conf, as stated many times >> earlier. Why the test has to reconfigure the host and cannot use values >> provided by the provisioning system? > This patch exactly removes this messing around with nameservers in > resolv.conf > It introduces the possibility to put ipa domain in the search directive > of resolv.conf so that we could test service autodiscovery during client > installation. > > > I just verified that the tampering with resolv.conf is not needed (libvirt and ovirt/rhev). I think this is an artifact from the whole issue of "let's use improvised domain names, what can go wrong" approach that was uncovered by the enforced DNS checks. I think we can defer the networking configuration to provisioning system. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Feb 12 15:52:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Feb 2016 16:52:23 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56BDCA19.1040405@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> Message-ID: <56BDFFB7.6040003@redhat.com> On 12.02.2016 13:03, Milan Kub?k wrote: > On 02/12/2016 10:59 AM, David Kupka wrote: >> Sending one more topology test. This one creates a M groups >> consisting N (N>=2) servers. >> First two servers in each group are used to connect with nearest four >> groups and also with the other servers inside the group (when N>2). >> Servers inside the group (not connecting to other groups) are >> connected with each other. >> >> The patch set needs freeipa-dkupka-8{1,2,3} applied. >> > ACK > I cannot apply patches, please rebase [mbasti at dhcp129-96 freeipa-devel]$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 Applying: CI: Add '2-connected' topology generator. Applying: CI: Add simple replication test in 2-connected topology. Applying: CI: Add test for 2-connected topology generator. Applying: CI: Add double circle topology. Applying: CI: Add replication test utilizing double-circle topology. Applying: CI: Add test for double-circle topology generator. error: invalid object 100644 e12d141391840cc7f9150a178875393a96dd469b for 'ipatests/test_integration/test_topologies.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. Patch failed at 0006 CI: Add test for double-circle topology generator. The copy of the patch that failed is found in: /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Martin^2 From mbasti at redhat.com Fri Feb 12 15:57:52 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Feb 2016 16:57:52 +0100 Subject: [Freeipa-devel] [PATCH] CI: Add simple replication test in 2-connected topology. In-Reply-To: <56BDCA06.7060208@redhat.com> References: <56BAEC17.7050406@redhat.com> <56BDAAD8.9050304@redhat.com> <56BDCA06.7060208@redhat.com> Message-ID: <56BE0100.80708@redhat.com> On 12.02.2016 13:03, Milan Kub?k wrote: > On 02/12/2016 10:50 AM, David Kupka wrote: >> On 10/02/16 08:51, David Kupka wrote: >>> This topology should be closer to the ones in real world than our >>> current ones. But it is still impractical and (hopefully) no one has >>> such deployment. >>> If some user could share his/her deployment topology I will be happy to >>> create generator based on it. >>> >> Updated patches attached. >> > ACK. Thanks for providing more complicated topologies. > Pushed to: master: 2541b5fcbf32444b45ea640653d45f244d040be2 ipa-4-3: 65d1709426d66f024c73fe5b1e3f3273be25615f From spoore at redhat.com Fri Feb 12 20:23:44 2016 From: spoore at redhat.com (Scott Poore) Date: Fri, 12 Feb 2016 15:23:44 -0500 (EST) Subject: [Freeipa-devel] [pytest-multihost-devel][PATCH] Add reset_connection to BaseHost class In-Reply-To: <937220896.25498149.1455308435851.JavaMail.zimbra@redhat.com> Message-ID: <1986616790.25498810.1455308624207.JavaMail.zimbra@redhat.com> Hi, Please review attached patch for pytest-multihost plugin. Fixes: https://fedorahosted.org/python-pytest-multihost/ticket/4 Thanks, Scott -- Scott Poore Senior Quality Assurance Engineer Red Hat, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: pytest-multihost-spoore-0001-Add-reset_connection-to-BaseHost-class.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: From pvomacka at redhat.com Mon Feb 15 15:20:04 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Mon, 15 Feb 2016 16:20:04 +0100 Subject: [Freeipa-devel] [PATCH] 0005 webui: topology graph: canvas resizes itself according to the window size In-Reply-To: <56BDD5A6.8010108@redhat.com> References: <56BC7105.3020609@redhat.com> <56BDD5A6.8010108@redhat.com> Message-ID: <56C1ECA4.2070900@redhat.com> On 02/12/2016 01:52 PM, Pavel Vomacka wrote: > > > On 02/11/2016 12:31 PM, Pavel Vomacka wrote: >> Hello, >> >> The canvas of the graph had static size. This patch fixes this issue >> and from now the graph canvas is resized according to the window size. >> >> Pavel Vomacka >> >> > Because of changes in previous patch I'm sending also this one again. > Plus I fixed some jslint warnings. > > And again a link to the ticket: > https://fedorahosted.org/freeipa/ticket/5647 . > > -- > Pavel^3 Vomacka > > And another change in the code. This patch adds checking whether a svg element even exists. And don't add 'col-sm-12' class to the svg element any more. This class just added useless paddings to the element. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0005-3-Resize-topology-graph-canvas-according-to-window-siz.patch Type: text/x-patch Size: 2900 bytes Desc: not available URL: From mkubik at redhat.com Mon Feb 15 15:37:40 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 15 Feb 2016 16:37:40 +0100 Subject: [Freeipa-devel] [patch 0033] spec file: update the python-polib dependency name to python2-polib Message-ID: <56C1F0C4.7060707@redhat.com> Reflect the updated name of the package. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0033-spec-file-update-the-python-polib-dependency-name-to.patch Type: text/x-patch Size: 1262 bytes Desc: not available URL: From mkubik at redhat.com Mon Feb 15 15:59:02 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 15 Feb 2016 16:59:02 +0100 Subject: [Freeipa-devel] [patch 0034] ipatests: extend permission plugin test with new expected output Message-ID: <56C1F5C6.2090708@redhat.com> Patch attached. Applies on ipa-4-3 as well. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0034-ipatests-extend-permission-plugin-test-with-new-expe.patch Type: text/x-patch Size: 1839 bytes Desc: not available URL: From pvoborni at redhat.com Mon Feb 15 16:00:34 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 15 Feb 2016 17:00:34 +0100 Subject: [Freeipa-devel] [patch 0033] spec file: update the python-polib dependency name to python2-polib In-Reply-To: <56C1F0C4.7060707@redhat.com> References: <56C1F0C4.7060707@redhat.com> Message-ID: <56C1F622.3000602@redhat.com> On 02/15/2016 04:37 PM, Milan Kub?k wrote: > Reflect the updated name of the package. > Seems to me as a packaging bug in python-polib. It should use python_provide macro to handle the transition. -- Petr Vobornik From mkubik at redhat.com Mon Feb 15 16:01:23 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Mon, 15 Feb 2016 17:01:23 +0100 Subject: [Freeipa-devel] [patch 0033] spec file: update the python-polib dependency name to python2-polib In-Reply-To: <56C1F622.3000602@redhat.com> References: <56C1F0C4.7060707@redhat.com> <56C1F622.3000602@redhat.com> Message-ID: <56C1F653.1000908@redhat.com> On 02/15/2016 05:00 PM, Petr Vobornik wrote: > On 02/15/2016 04:37 PM, Milan Kub?k wrote: >> Reflect the updated name of the package. >> > > Seems to me as a packaging bug in python-polib. It should use > python_provide macro to handle the transition. I will open a bug against it, then. -- Milan Kubik From lslebodn at redhat.com Mon Feb 15 16:39:20 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 15 Feb 2016 17:39:20 +0100 Subject: [Freeipa-devel] [patch 0033] spec file: update the python-polib dependency name to python2-polib In-Reply-To: <56C1F622.3000602@redhat.com> References: <56C1F0C4.7060707@redhat.com> <56C1F622.3000602@redhat.com> Message-ID: <20160215163920.GM25417@mail.corp.redhat.com> On (15/02/16 17:00), Petr Vobornik wrote: >On 02/15/2016 04:37 PM, Milan Kub?k wrote: >>Reflect the updated name of the package. >> > >Seems to me as a packaging bug in python-polib. It should use python_provide >macro to handle the transition. There is not a bug in python-polib sh# rpm -q python2-polib python2-polib-1.0.7-2.fc23.noarch sh# rpm -q --provides python2-polib python-polib = 1.0.7-2.fc23 python2-polib = 1.0.7-2.fc23 However it is a change in behaviour in dnf/yum. You can see more details in BZ1291850 or better BZ1096506. This a readon why "dnf builddep" will try to remove package. (it's not downgrade from dnf point of view) sh# dnf builddep freeipa.spec Last metadata expiration check performed 0:17:37 ago on Mon Feb 15 16:19:14 2016. Package python-setuptools-18.0.1-2.fc23.noarch is already installed, skipping. Package systemd-222-10.fc23.x86_64 is already installed, skipping. Package systemd-222-10.fc23.x86_64 is already installed, skipping. Error: installed package python2-polib-1.0.7-2.fc23.noarch obsoletes python-polib < 1.0.7-2.fc23 provided by python-polib-1.0.3-6.fc23.noarch (try to add '--allowerasing' to command line to replace conflicting packages) You might try to file a dnf BZ but mine 1291850 was two tiles closed as not a but and then closed as a duplicate of another bug. IMHO the simplest solution would to push the patch with better explanation in's a workaround. LSommit message becuase it's a workaround. LS From ldoudova at redhat.com Tue Feb 16 09:10:11 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 16 Feb 2016 10:10:11 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0009] WebUI tests fix In-Reply-To: <56BC5EC0.7000608@redhat.com> References: <56BC5EC0.7000608@redhat.com> Message-ID: <56C2E773.8070304@redhat.com> On 02/11/2016 11:13 AM, Lenka Doudova wrote: > Hi all, > > most of webUI tests fail with > > AssertionError: Can't click on checkbox label: table.table > Message: Element is not clickable at point (37, 340.3999938964844). > Other element would receive the click: > type="checkbox"> > > > The problem seems to be that the tests attempt to click on a checkbox > label that is no longer there. Since the checkbox is clickable > directly, I changed the code accordingly. Most of the tests should now > proceed successfully. > > Lenka > > Attaching updated patch with minor fix. Lenka -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0009.2-WebUI-tests-fix-failing-tests.patch Type: text/x-patch Size: 1328 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Feb 16 13:23:38 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 16 Feb 2016 14:23:38 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements Message-ID: <56C322DA.9040105@redhat.com> Hi list, WARNING: huge brain dump ahead. During investigation of https://fedorahosted.org/freeipa/ticket/4305 me and Petr Spaced (CC'ed) came to a conclusion that the IPA realm autodiscovery code used by ipa-client-install is so convoluted, complex and hard to understand that the cost of fixing a bug/adding a behavioral change (there are some other tickets dealing with ipadiscovery, e.g. see https://fedorahosted.org/freeipa/ticket/5270 https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher that a more large-scale rewrite of the module and related codebase. Since we plan to do some general refactoring work anyway, I would like to discuss the possible course of action we may take to tackle this issue. I would like to present the following options we have been discussing so far: 1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") We may take the existing IPADiscovery class and try rewrite it in order to get a more concise and deterministic code, which will: * rely more on python-dns and answers provided by resolver (e.g. we are directly parsing resolv.conf for available domains when we can ask the resolver to get domains for us) * be more pythonic (replace error codes with thrown exceptions, clean up numerous C-isms etc.) * not try to outsmart user when server/realm/domain is specified beforehand. Currently, even if you specify all three options, there is still some DNS discovery performed, hence bug #4305. I think that one you specify server(s), not magic should be performed and the discovery process should be reduced to checking whether they are IPA servers and pull all other info (like realm) from them. This may be a considerable effort requiring some time to implement and get right, but IMHO still comparable to the time spent iteratively placing 'if' statements into the existing code and hoping to not break anything. I would even argue it is not worth the effort because we can 2.) Use realmd dbus interface to do DNS discovery I have attached aquick and dirty script I have slapped together to leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm discovery for us. This has a lot of appeal to me since we are leveraging existing codebase for DNS discovery and will have to handle only cases when the user manually specifies a list of IPA servers for the client. This however pulls in realmd as a (potentially circular) dependency for ipa client, and when we find bug in the discovery code, we will have to poke upstream (Stef or Sumit I think) to fix it. So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: 3.) Split out IPA discovery portion of realmd to a separate C library shared between IPA and realmd may be best. Both projects will have shared codebase (maintained either by us or realmd devs), which can be reused also by other people to create their own discovery/enrollment solution. This would however require sustained and concerted efforts of both teams to create the library and possibly rewrite realmd to accommodate this change. There may be some other options viable for us, if so please mention them in a reply. Also please correct any piece of information I got wrong. TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix it. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: realmd_discovery.py Type: text/x-python Size: 1354 bytes Desc: not available URL: From jcholast at redhat.com Wed Feb 17 09:43:38 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Feb 2016 10:43:38 +0100 Subject: [Freeipa-devel] [PATCHES] 0761-0769 More Python3 fixes In-Reply-To: <56BA1B9B.4040903@redhat.com> References: <56A90086.30600@redhat.com> <56AB21F5.40902@redhat.com> <56AB25FC.5090505@redhat.com> <56BA1B9B.4040903@redhat.com> Message-ID: <56C440CA.8020607@redhat.com> On 9.2.2016 18:02, Petr Viktorin wrote: > On 01/29/2016 09:42 AM, Jan Cholasta wrote: >> On 29.1.2016 09:25, Jan Cholasta wrote: >>> Hi, >>> >>> On 27.1.2016 18:38, Petr Viktorin wrote: >>>> Hello, >>>> >>>> Here is a mixed bag of Python 3 fixes. >>>> They fix some tests, and they should enable you to use `python3 >>>> /usr/bin/ipa`. >>> >>> Patch 761: >>> >>> 1) The "invalid 'my_number': " bit comes from IPA itself, shouldn't we >>> check at least that? > > Fixed > >>> Patch 762: >>> >>> 1) We should handle UnicodeError here as well, in addition to TypeError: >>> >>> if k.lower() == 'negotiate': >>> try: >>> - token = base64.b64decode(v) >>> + token = base64.b64decode(v.encode('ascii')) >>> break >>> # b64decode raises TypeError on invalid input >>> except TypeError: > > Fixed > >>> 2) I would prefer if the encoding was specified explicitly here: >>> >>> + response = json_decode_binary(json.loads(response.decode())) > > Fixed > >>> Patch 763: >>> >>> 1) >>> >>> + altname = altname > > Fixed > >>> 2) Nitpick, but could you please: >>> >>> - if isinstance(name_or_oid, unicode): >>> - name_or_oid = name_or_oid.encode('utf-8') >>> + if six.PY2: >>> + if isinstance(name_or_oid, unicode): >>> + name_or_oid = name_or_oid.encode('utf-8') >>> >>> This way it's more visible that this is a py2-only thing. > > Sure > >>> Patch 764: LGTM >>> >>> >>> Patch 765: >>> >>> 1) >>> >>> +import tempfile >>> +import tempfile > > Fixed. > >>> Patch 766-767: LGTM >>> >>> >>> Patch 768: >>> >>> 1) Only binascii.Error should be handled in int_to_bytes, the try-except >>> block is there just to handle odd-length strings. > > That's there for Python 2, where unhexlify raises TypeError. > >>> 2) I think you can just remove the library_path.encode(), it's there >>> because the original C code did the same thing, but don't think it's >>> necessary. > > OK > >>> Patch 769: LGTM >> >> Also, could you please reference >> in the patches? > > Sure. > > Thanks for the review! Updated patches attached. Thanks, ACK. Pushed to: master: d1252cfb8ef613e290a23e0e9cabd9d135a129ca ipa-4-3: c8c2a6d33815b478c1d6ec402eaa2f56d0fe61b7 -- Jan Cholasta From jcholast at redhat.com Wed Feb 17 09:52:18 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Feb 2016 10:52:18 +0100 Subject: [Freeipa-devel] [PATCHES] 0761-0769 More Python3 fixes In-Reply-To: <56C440CA.8020607@redhat.com> References: <56A90086.30600@redhat.com> <56AB21F5.40902@redhat.com> <56AB25FC.5090505@redhat.com> <56BA1B9B.4040903@redhat.com> <56C440CA.8020607@redhat.com> Message-ID: <56C442D2.5090802@redhat.com> On 17.2.2016 10:43, Jan Cholasta wrote: > On 9.2.2016 18:02, Petr Viktorin wrote: >> On 01/29/2016 09:42 AM, Jan Cholasta wrote: >>> On 29.1.2016 09:25, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 27.1.2016 18:38, Petr Viktorin wrote: >>>>> Hello, >>>>> >>>>> Here is a mixed bag of Python 3 fixes. >>>>> They fix some tests, and they should enable you to use `python3 >>>>> /usr/bin/ipa`. >>>> >>>> Patch 761: >>>> >>>> 1) The "invalid 'my_number': " bit comes from IPA itself, shouldn't we >>>> check at least that? >> >> Fixed >> >>>> Patch 762: >>>> >>>> 1) We should handle UnicodeError here as well, in addition to >>>> TypeError: >>>> >>>> if k.lower() == 'negotiate': >>>> try: >>>> - token = base64.b64decode(v) >>>> + token = base64.b64decode(v.encode('ascii')) >>>> break >>>> # b64decode raises TypeError on invalid input >>>> except TypeError: >> >> Fixed >> >>>> 2) I would prefer if the encoding was specified explicitly here: >>>> >>>> + response = >>>> json_decode_binary(json.loads(response.decode())) >> >> Fixed >> >>>> Patch 763: >>>> >>>> 1) >>>> >>>> + altname = altname >> >> Fixed >> >>>> 2) Nitpick, but could you please: >>>> >>>> - if isinstance(name_or_oid, unicode): >>>> - name_or_oid = name_or_oid.encode('utf-8') >>>> + if six.PY2: >>>> + if isinstance(name_or_oid, unicode): >>>> + name_or_oid = name_or_oid.encode('utf-8') >>>> >>>> This way it's more visible that this is a py2-only thing. >> >> Sure >> >>>> Patch 764: LGTM >>>> >>>> >>>> Patch 765: >>>> >>>> 1) >>>> >>>> +import tempfile >>>> +import tempfile >> >> Fixed. >> >>>> Patch 766-767: LGTM >>>> >>>> >>>> Patch 768: >>>> >>>> 1) Only binascii.Error should be handled in int_to_bytes, the >>>> try-except >>>> block is there just to handle odd-length strings. >> >> That's there for Python 2, where unhexlify raises TypeError. >> >>>> 2) I think you can just remove the library_path.encode(), it's there >>>> because the original C code did the same thing, but don't think it's >>>> necessary. >> >> OK >> >>>> Patch 769: LGTM >>> >>> Also, could you please reference >>> in the patches? >> >> Sure. >> >> Thanks for the review! Updated patches attached. > > Thanks, ACK. > > Pushed to: > master: d1252cfb8ef613e290a23e0e9cabd9d135a129ca > ipa-4-3: c8c2a6d33815b478c1d6ec402eaa2f56d0fe61b7 I screwed up. The attached patch fixes that. Pushed under the one-liner rule to ipa-4-3: 5ff41fa3091235aaf48e855b0c3ede0154a58dfc -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-545-test_ipagetkeytab-fix-missing-import.patch Type: text/x-patch Size: 927 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 17 13:49:12 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Feb 2016 14:49:12 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements Message-ID: <56C47A58.6050207@redhat.com> https://fedorahosted.org/freeipa/ticket/5631 Patch attached (for master, 4.3, 4.2) -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbasti-0413-fix-permission-Read-Replication-Agreements.patch Type: text/x-patch Size: 19788 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0413-fix-permission-Read-Replication-Agreements.patch Type: text/x-patch Size: 19739 bytes Desc: not available URL: From pvomacka at redhat.com Wed Feb 17 15:50:00 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 17 Feb 2016 16:50:00 +0100 Subject: [Freeipa-devel] [PATCH] 0006 webui: topology graph: Nodes are switched to fixed state after initial animation Message-ID: <56C496A8.3000606@redhat.com> Hello, The position of nodes were different after each reload. The attached patch changes it. The nodes are set as fixed after initial animation. Even if someone releases the node by double-clicking then after animation the node is set as fixed. And the same behavior for new added nodes to the graph (i.e. new client) - after initial animation, which allows node to find proper position, the node is set as fixed, too. The patch also fixes one minor bug which is, I guess, related to this bug. In a situation where the node is set as fixed (no matter how - manually or automatically) then the page is reloaded or refreshed, then the initial animation runs. If after all these steps someone tries to release the node by double-clicking the state of the node is set to not fixed, but a layout animation is not run. This is the reason why there is layout.resume() in dblclick listener. If you think that there should be another ticket for this minor bug, let me know. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0006-Nodes-stay-fixed-after-initial-animation.patch Type: text/x-patch Size: 1811 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 17 15:54:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Feb 2016 16:54:15 +0100 Subject: [Freeipa-devel] [PATCH 0414] py3: remove usage of iteritems Message-ID: <56C497A7.20309@redhat.com> https://fedorahosted.org/freeipa/ticket/5623 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0414-Py3-do-not-use-dict.iteritems.patch Type: text/x-patch Size: 1469 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 17 17:02:45 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Feb 2016 18:02:45 +0100 Subject: [Freeipa-devel] [PATCH 0415] Pylint: disable new pylint checks Message-ID: <56C4A7B5.80809@redhat.com> https://fedorahosted.org/freeipa/ticket/5615 Disable unwanted or false positive checks. New checks cannot be disabled inline because pylint < 1.5 will report them as errors, thus must be disable globally until we decide to move completely to pytlint 1.5 (Fedora 25?) Patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbasti-0415-Disable-new-pylint-checks.patch Type: text/x-patch Size: 1280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-3-mbasti-0415-Disable-new-pylint-checks.patch Type: text/x-patch Size: 1258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0415-Disable-new-pylint-checks.patch Type: text/x-patch Size: 1249 bytes Desc: not available URL: From pvoborni at redhat.com Wed Feb 17 17:29:20 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 17 Feb 2016 18:29:20 +0100 Subject: [Freeipa-devel] [PATCH] 0005 webui: topology graph: canvas resizes itself according to the window size In-Reply-To: <56C1ECA4.2070900@redhat.com> References: <56BC7105.3020609@redhat.com> <56BDD5A6.8010108@redhat.com> <56C1ECA4.2070900@redhat.com> Message-ID: <56C4ADF0.4080702@redhat.com> On 02/15/2016 04:20 PM, Pavel Vomacka wrote: > > > On 02/12/2016 01:52 PM, Pavel Vomacka wrote: >> >> >> On 02/11/2016 12:31 PM, Pavel Vomacka wrote: >>> Hello, >>> >>> The canvas of the graph had static size. This patch fixes this issue >>> and from now the graph canvas is resized according to the window size. >>> >>> Pavel Vomacka >>> >>> >> Because of changes in previous patch I'm sending also this one again. >> Plus I fixed some jslint warnings. >> >> And again a link to the ticket: >> https://fedorahosted.org/freeipa/ticket/5647 . >> >> -- >> Pavel^3 Vomacka >> >> > And another change in the code. This patch adds checking whether a svg > element even exists. And don't add 'col-sm-12' class to the svg element > any more. This class just added useless paddings to the element. > > -- > Pavel^3 Vomacka > Hi, thanks for the patch. 1. I don't like the fact that the resize handler registered in initialize method is active forever, even when viewing other facets. 2. The code will probably fail if there is other svg element present on the page. $('svg') searches for all svg elements in DOM, such search is usually slow and undeterministic. It is better to use a stored reference(if possible) or limit the search to some parent element, e.g. TopoGraph can store and then use its container. Would be funny if there were 2 graphs. 3. Why is there the toFixed(1) call? Or more specifically on that position? It hides the fact that toFixed transforms Number to String and then '-' operator with Number on the right casts it back to Number. 4. width could be just: this._svg.parent().width() 5. Your approach for bottom padding works well but I don't like that the component assumes that there is some col-sm-12 element on a page whose right padding is actually equal to space on the left of the svg. #1 and #5 makes me think that the resize logic should be moved topology facet. Something like: * register resize handler on facet's 'show' event * unregister resize handler on facet's 'hide' event (will solve #1) * on window resize, compute the size in topology facet, call new .resize(width, height) method of TopoGraph Then, we wouldn't have to search whole DOM for 'svg' elements to check if page is visible. The bottom padding can be obtained by: parseInt(this.content.css('paddingLeft')) where 'this' is facet. -- Petr Vobornik From dkupka at redhat.com Thu Feb 18 09:10:24 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Feb 2016 10:10:24 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <569E51E6.6060005@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> Message-ID: <56C58A80.1030402@redhat.com> On 19/01/16 16:10, David Kupka wrote: > On 19/01/16 14:38, Jan Cholasta wrote: >> On 19.1.2016 14:26, Martin Kosek wrote: >>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>> >>>> Thanks for the patch. I've fixed the path in specfile and removed >>>> unused import >>>> but otherwise it works, ACK. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5586 >>> >>> Won't this break existing certmonger requests depending on the old path? >> >> It will, I don't see any upgrade code. >> >>> >>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "auditSigningCert >>> cert-pki-ca" >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "ocspSigningCert >>> cert-pki-ca" >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "subsystemCert >>> cert-pki-ca" >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "caSigningCert >>> cert-pki-ca" >>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "Server-Cert >>> cert-pki-ca" >>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv RHEL72 >>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>> >> >> > > You're right it will break the upgrade. I haven't noticed that > Server-Cert for DS and HTTPD are not handled by > certificate_renewal_update (ipaserver.install.server.upgrade) where all > the other trackings are stopped and then configured again with the > paths.CERTMONGER_COMMAND_TEMPLATE already updated. > > Thanks for the catch. > I've updated Timo's patch little more and added start_tracking_certificates() for dsinstance and httpinstance. Now the upgrade works as expected. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0087.0-dsinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 1501 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0088.0-httpinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 1092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0011.1-Move-freeipa-certmonger-helpers-to-libexecdir.patch Type: text/x-patch Size: 8353 bytes Desc: not available URL: From dkupka at redhat.com Thu Feb 18 09:10:36 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Feb 2016 10:10:36 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <569E51E6.6060005@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> Message-ID: <56C58A8C.3050200@redhat.com> On 19/01/16 16:10, David Kupka wrote: > On 19/01/16 14:38, Jan Cholasta wrote: >> On 19.1.2016 14:26, Martin Kosek wrote: >>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>> >>>> Thanks for the patch. I've fixed the path in specfile and removed >>>> unused import >>>> but otherwise it works, ACK. >>>> >>>> https://fedorahosted.org/freeipa/ticket/5586 >>> >>> Won't this break existing certmonger requests depending on the old path? >> >> It will, I don't see any upgrade code. >> >>> >>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "auditSigningCert >>> cert-pki-ca" >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "ocspSigningCert >>> cert-pki-ca" >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "subsystemCert >>> cert-pki-ca" >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "caSigningCert >>> cert-pki-ca" >>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>> "Server-Cert >>> cert-pki-ca" >>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv RHEL72 >>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>> >> >> > > You're right it will break the upgrade. I haven't noticed that > Server-Cert for DS and HTTPD are not handled by > certificate_renewal_update (ipaserver.install.server.upgrade) where all > the other trackings are stopped and then configured again with the > paths.CERTMONGER_COMMAND_TEMPLATE already updated. > > Thanks for the catch. > I've updated Timo's patch little more and added start_tracking_certificates() for dsinstance and httpinstance. Now the upgrade works as expected. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0087.0-dsinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 1501 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0088.0-httpinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 1092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0011.1-Move-freeipa-certmonger-helpers-to-libexecdir.patch Type: text/x-patch Size: 8353 bytes Desc: not available URL: From dkupka at redhat.com Thu Feb 18 09:14:50 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 18 Feb 2016 10:14:50 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56BDFFB7.6040003@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> <56BDFFB7.6040003@redhat.com> Message-ID: <56C58B8A.8080801@redhat.com> On 12/02/16 16:52, Martin Basti wrote: > > > On 12.02.2016 13:03, Milan Kub?k wrote: >> On 02/12/2016 10:59 AM, David Kupka wrote: >>> Sending one more topology test. This one creates a M groups >>> consisting N (N>=2) servers. >>> First two servers in each group are used to connect with nearest four >>> groups and also with the other servers inside the group (when N>2). >>> Servers inside the group (not connecting to other groups) are >>> connected with each other. >>> >>> The patch set needs freeipa-dkupka-8{1,2,3} applied. >>> >> ACK >> > I cannot apply patches, please rebase > > [mbasti at dhcp129-96 freeipa-devel]$ git checkout master > Switched to branch 'master' > Your branch is up-to-date with 'origin/master'. > [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 > Applying: CI: Add '2-connected' topology generator. > Applying: CI: Add simple replication test in 2-connected topology. > Applying: CI: Add test for 2-connected topology generator. > Applying: CI: Add double circle topology. > Applying: CI: Add replication test utilizing double-circle topology. > Applying: CI: Add test for double-circle topology generator. > error: invalid object 100644 e12d141391840cc7f9150a178875393a96dd469b > for 'ipatests/test_integration/test_topologies.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. > Patch failed at 0006 CI: Add test for double-circle topology generator. > The copy of the patch that failed is found in: > /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > > Martin^2 Git fails to apply patches because wrong version of freeipa-dkupka-008{1,2,3} was pushed. Attached patches should fix it. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0089.0-CI-Fix-pep8-errors-in-2-connected-topology-generator.patch Type: text/x-patch Size: 1627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0090.0-CI-add-empty-topology-test-for-2-connected-topology-.patch Type: text/x-patch Size: 770 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Feb 18 09:32:57 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 18 Feb 2016 10:32:57 +0100 Subject: [Freeipa-devel] [PATCH 0134] CI tests: use old schema when testing hostmask-based sudo rules Message-ID: <56C58FC9.9070901@redhat.com> https://fedorahosted.org/freeipa/ticket/5625 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0134-CI-tests-use-old-schema-when-testing-hostmask-based-.patch Type: text/x-patch Size: 5096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0134-CI-tests-use-old-schema-when-testing-hostmask-based-.patch Type: text/x-patch Size: 5068 bytes Desc: not available URL: From mkosek at redhat.com Thu Feb 18 11:33:40 2016 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Feb 2016 12:33:40 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56C58A8C.3050200@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> Message-ID: <56C5AC14.50706@redhat.com> On 02/18/2016 10:10 AM, David Kupka wrote: > From 9952937f207f9a0afae8211276f1b7d7e762fd4e Mon Sep 17 00:00:00 2001 > From: Timo Aaltonen > Date: Tue, 19 Jan 2016 12:37:56 +0100 > Subject: [PATCH] Move freeipa certmonger helpers to libexecdir. > > The scripts in this directory are simple python scripts, nothing arch-specific > in them. Having them under libexec would simplify the code a bit too, since > there would be no need to worry about lib vs lib64 (which also cause trouble > on Debian). Isn't this the patch which moves our scripts in different location and thus breaks existing certmonger tracking requests *after upgrade*? From mkubik at redhat.com Thu Feb 18 14:52:02 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 18 Feb 2016 15:52:02 +0100 Subject: [Freeipa-devel] [patch 0034] ipatests: extend permission plugin test with new expected output In-Reply-To: <56C1F5C6.2090708@redhat.com> References: <56C1F5C6.2090708@redhat.com> Message-ID: <56C5DA92.4090805@redhat.com> On 02/15/2016 04:59 PM, Milan Kub?k wrote: > Patch attached. Applies on ipa-4-3 as well. > > > Updated version of patch fixes test_old_permission_plugin as well. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0034-1-ipatests-extend-permission-plugin-test-with-new-expe.patch Type: text/x-patch Size: 3265 bytes Desc: not available URL: From pvoborni at redhat.com Thu Feb 18 14:56:06 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Feb 2016 15:56:06 +0100 Subject: [Freeipa-devel] [PATCH] 946 webui: fixed showing of success message after password change on login In-Reply-To: <569FC71A.2020705@redhat.com> References: <569FC71A.2020705@redhat.com> Message-ID: <56C5DB86.60809@redhat.com> On 01/20/2016 06:42 PM, Petr Vobornik wrote: > similar issue and cause as in https://fedorahosted.org/freeipa/ticket/5567 > > root cause is that binding triggers validation which clears messages in > validation summary. Maybe it could be refactored in a future to not use > the same validation summary field for API calls and fields. > > If you think it is actually ticket #5567 (could be in some point of > view) then feel free to push also to 4.2 and 4.3 branch. > > bump for review -- Petr Vobornik From pvoborni at redhat.com Thu Feb 18 14:56:17 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Feb 2016 15:56:17 +0100 Subject: [Freeipa-devel] [PATCH] 947 webui: use API call ca_is_enabled instead of enable_ra env variable. In-Reply-To: <569FCBC2.6020100@redhat.com> References: <569FCBC2.6020100@redhat.com> Message-ID: <56C5DB91.6070202@redhat.com> On 01/20/2016 07:02 PM, Petr Vobornik wrote: > To be consistent with backend code. > > https://fedorahosted.org/freeipa/ticket/5622 > > bump for review -- Petr Vobornik From pvomacka at redhat.com Thu Feb 18 14:58:52 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 18 Feb 2016 15:58:52 +0100 Subject: [Freeipa-devel] [PATCH] 946 webui: fixed showing of success message after password change on login In-Reply-To: <56C5DB86.60809@redhat.com> References: <569FC71A.2020705@redhat.com> <56C5DB86.60809@redhat.com> Message-ID: <56C5DC2C.4010208@redhat.com> On 02/18/2016 03:56 PM, Petr Vobornik wrote: > On 01/20/2016 06:42 PM, Petr Vobornik wrote: >> similar issue and cause as in >> https://fedorahosted.org/freeipa/ticket/5567 >> >> root cause is that binding triggers validation which clears messages in >> validation summary. Maybe it could be refactored in a future to not use >> the same validation summary field for API calls and fields. >> >> If you think it is actually ticket #5567 (could be in some point of >> view) then feel free to push also to 4.2 and 4.3 branch. >> >> > > bump for review Ack. Works as expected. -- Pavel^3 Vomacka From pvomacka at redhat.com Thu Feb 18 14:59:43 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 18 Feb 2016 15:59:43 +0100 Subject: [Freeipa-devel] [PATCH] 947 webui: use API call ca_is_enabled instead of enable_ra env variable. In-Reply-To: <56C5DB91.6070202@redhat.com> References: <569FCBC2.6020100@redhat.com> <56C5DB91.6070202@redhat.com> Message-ID: <56C5DC5F.2010205@redhat.com> On 02/18/2016 03:56 PM, Petr Vobornik wrote: > On 01/20/2016 07:02 PM, Petr Vobornik wrote: >> To be consistent with backend code. >> >> https://fedorahosted.org/freeipa/ticket/5622 >> >> > > bump for review > Ack. -- Pavel^3 Vomacka From tjaalton at ubuntu.com Thu Feb 18 16:41:47 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 18 Feb 2016 18:41:47 +0200 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56C5AC14.50706@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56C5AC14.50706@redhat.com> Message-ID: <56C5F44B.8090108@ubuntu.com> 18.02.2016, 13:33, Martin Kosek kirjoitti: > On 02/18/2016 10:10 AM, David Kupka wrote: >> From 9952937f207f9a0afae8211276f1b7d7e762fd4e Mon Sep 17 00:00:00 2001 >> From: Timo Aaltonen >> Date: Tue, 19 Jan 2016 12:37:56 +0100 >> Subject: [PATCH] Move freeipa certmonger helpers to libexecdir. >> >> The scripts in this directory are simple python scripts, nothing arch-specific >> in them. Having them under libexec would simplify the code a bit too, since >> there would be no need to worry about lib vs lib64 (which also cause trouble >> on Debian). > > Isn't this the patch which moves our scripts in different location and thus > breaks existing certmonger tracking requests *after upgrade*? Yes, there are two solutions that I can think of - add symlinks /usr/lib{,64}/certmonger -> /usr/libexec/certmonger - modify existing tracking requests to use the new path the first might suffice with a transition period? -- t From tjaalton at ubuntu.com Thu Feb 18 16:51:05 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 18 Feb 2016 18:51:05 +0200 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56C5F44B.8090108@ubuntu.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56C5AC14.50706@redhat.com> <56C5F44B.8090108@ubuntu.com> Message-ID: <56C5F679.2050101@ubuntu.com> 18.02.2016, 18:41, Timo Aaltonen kirjoitti: > 18.02.2016, 13:33, Martin Kosek kirjoitti: >> On 02/18/2016 10:10 AM, David Kupka wrote: >>> From 9952937f207f9a0afae8211276f1b7d7e762fd4e Mon Sep 17 00:00:00 2001 >>> From: Timo Aaltonen >>> Date: Tue, 19 Jan 2016 12:37:56 +0100 >>> Subject: [PATCH] Move freeipa certmonger helpers to libexecdir. >>> >>> The scripts in this directory are simple python scripts, nothing arch-specific >>> in them. Having them under libexec would simplify the code a bit too, since >>> there would be no need to worry about lib vs lib64 (which also cause trouble >>> on Debian). >> >> Isn't this the patch which moves our scripts in different location and thus >> breaks existing certmonger tracking requests *after upgrade*? > > Yes, there are two solutions that I can think of > > - add symlinks /usr/lib{,64}/certmonger -> /usr/libexec/certmonger > - modify existing tracking requests to use the new path > > the first might suffice with a transition period? also, I assumed certmonger would move it's own scripts.. if not, just symlink the ipa ones not the whole dir. -- t From tjaalton at ubuntu.com Thu Feb 18 17:11:48 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 18 Feb 2016 19:11:48 +0200 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56C5F679.2050101@ubuntu.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56C5AC14.50706@redhat.com> <56C5F44B.8090108@ubuntu.com> <56C5F679.2050101@ubuntu.com> Message-ID: <56C5FB54.4020604@ubuntu.com> 18.02.2016, 18:51, Timo Aaltonen kirjoitti: > 18.02.2016, 18:41, Timo Aaltonen kirjoitti: >> 18.02.2016, 13:33, Martin Kosek kirjoitti: >>> On 02/18/2016 10:10 AM, David Kupka wrote: >>>> From 9952937f207f9a0afae8211276f1b7d7e762fd4e Mon Sep 17 00:00:00 2001 >>>> From: Timo Aaltonen >>>> Date: Tue, 19 Jan 2016 12:37:56 +0100 >>>> Subject: [PATCH] Move freeipa certmonger helpers to libexecdir. >>>> >>>> The scripts in this directory are simple python scripts, nothing arch-specific >>>> in them. Having them under libexec would simplify the code a bit too, since >>>> there would be no need to worry about lib vs lib64 (which also cause trouble >>>> on Debian). >>> >>> Isn't this the patch which moves our scripts in different location and thus >>> breaks existing certmonger tracking requests *after upgrade*? >> >> Yes, there are two solutions that I can think of >> >> - add symlinks /usr/lib{,64}/certmonger -> /usr/libexec/certmonger >> - modify existing tracking requests to use the new path >> >> the first might suffice with a transition period? > > also, I assumed certmonger would move it's own scripts.. if not, just > symlink the ipa ones not the whole dir. Riiight, especially as the certmonger helpers are native binaries, so those won't move :) I hope to continue on porting 4.3 soon and revisit this again.. -- t From pvoborni at redhat.com Thu Feb 18 17:21:04 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 18 Feb 2016 18:21:04 +0100 Subject: [Freeipa-devel] [PATCH] 0004 webui: topology graph: Add pan and zoom functionality In-Reply-To: <56B2108E.2@redhat.com> References: <56B2108E.2@redhat.com> Message-ID: <56C5FD80.70007@redhat.com> On 02/03/2016 03:37 PM, Pavel Vomacka wrote: > Hello, > > I'm sending a patch for review. This patch adds pan and zoom > functionality to the topology graph. The page remembers old position and > size of the graph. So, it keeps these settings after refreshing the page. > > The patch is in atachement. > > Pavel Vomacka > > 1. if node.fixed should be number then, we can store number in local storage as well(only as string, e.g. num + '') instead of 'true' so that we make the logic more straightforward/consistent. 2. following lines are too long: .attr("transform", "translate(" + d3.event.translate + ")scale(" + d3.event.scale + ")"); .attr('transform', 'translate(' + trans.translate + ')scale(' + trans.scale + ')'); 3. 'svg_' prefix for translate and scale keys is too generic, would use e.g. topo_graph -- Petr Vobornik From pspacek at redhat.com Fri Feb 19 07:58:41 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Feb 2016 08:58:41 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56B388A9.5090206@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> Message-ID: <56C6CB31.7080005@redhat.com> On 4.2.2016 18:21, Petr Spacek wrote: > On 3.2.2016 18:41, Petr Spacek wrote: >> Hello, >> >> I've updated the design page >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >> >> Namely it now contains 'Version 2'. > > Okay, here is the idea how we can make it flexible: > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation Hello, I'm thinking about LDAP schema for DNS locations. Purpose ======= * Allow admins to define any number of locations. * 1 DNS server advertises at most 1 location. * 1 location generally contains set of services with different priorities and weights (in DNS SRV terms). * Express server & service priority for each defined location in a way which is granular and flexible and ad the same time easy to manage. Proposal ======== a) Container for locations -------------------------- cn=locations,cn=ipa,cn=etc,dc=example,dc=com b) 1 location ------------- Attributes: 2.16.840.1.113730.3.8.5.32 idnsLocationMember Server/service assigned to a DNS Location. Usually used to define 'main' servers for that location. Should it point to service DNs to be sure we have smooth upgrade to containers? 2.16.840.1.113730.3.8.5.33 idnsBackupLocation Pointer to another location. Sucks in all servers from that location as one group with the same priority. Easy to use with _default location where all 'other' servers are used as backup. These two attributes use sub-type priority and relativeweight. This is the only way I could express all the information without need for separate objects. Object classes: 2.16.840.1.113730.3.8.6.7 idnsLocation MAY ( idnsLocationMember $ idnsBackupLocation ) 1st example: Location CZ: - servers czserver1, czserver2 - priority=1 - relative weight = 50 % each - if both CZ servers fail, use servers in location UK as backup (priority 2) - if all CZ and UK servers fail, use servers in location US as backup (priority 3) - servers on the other continent are used only as option of last resort DN: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com objectClass: idnsLocation idnsLocationMember;priority1;relativeweight50: cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com idnsLocationMember;priority1;relativeweight50: cn=czserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com Location UK: - servers ukserver1, ukserver2 - priority=1 - server ukserver1 is a new beefy machine so it can handle 3 times more load than ukserver2, thus relative weights 75 % and 25 % - if both UK servers fail, use servers in location CZ as backup (priority 2) - if all CZ and UK servers fail, use servers in location US as backup (priority 3) - servers on the other continent are used only as option of last resort DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com objectClass: idnsLocation idnsLocationMember;priority1;relativeweight3: cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com idnsLocationMember;priority1;relativeweight1: cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com Location US: - servers usserver1, usserver2 - priority=1 - relative weight = 50 % each - if both US servers fail, use servers in location CZ and UK as backup (priority 2) - it is over ocean anyway, so US clients will not make any difference between CZ and UK locations DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com objectClass: idnsLocation idnsLocationMember;priority1;relativeweight50: cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com idnsLocationMember;priority1;relativeweight50: cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com idnsBackupLocation;priority2: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com Resulting DNS SRV records (generated by FreeIPA framework). Please note that only numbers in SRV records matter only relatively. Priorities work as group, weights are relative only inside the group. Absolute values above are used only in algorithm which generates SRV records: Location CZ: _kerberos._udp SRV 1 50 czserver1 _kerberos._udp SRV 1 50 czserver2 _kerberos._udp SRV 2 75 ukserver1 _kerberos._udp SRV 2 25 ukserver1 _kerberos._udp SRV 3 50 usserver1 _kerberos._udp SRV 3 50 usserver2 Location UK: _kerberos._udp SRV 1 75 ukserver1 _kerberos._udp SRV 1 25 ukserver1 _kerberos._udp SRV 2 50 czserver1 _kerberos._udp SRV 2 50 czserver2 _kerberos._udp SRV 3 50 usserver1 _kerberos._udp SRV 3 50 usserver2 Location US: _kerberos._udp SRV 1 50 usserver1 _kerberos._udp SRV 1 50 usserver2 _kerberos._udp SRV 2 250 czserver1 _kerberos._udp SRV 2 250 czserver2 _kerberos._udp SRV 2 375 ukserver1 _kerberos._udp SRV 2 125 ukserver1 2nd example: - 10 locations with 4 servers each - we want to have use only 1 server from each location as backup so clients will not spend a lot of time while attempting to contact cut-off branch (e.g. when remote WAN link is down) -> use only idnsLocationMember attribute instead of idnsBackupLocation attribute Fancier combinations are possible with this schema. I assume that fancy things will be necessary later on if/when IPA supports large topologies. c) Assigning DNS servers to locations: Each DNS server can advertise at most 1 location as 'default' to its clients. Attributes: 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation Pointer to a idnsLocation object. On DNS service object / external server. Single-valued. Example: DN: cn=DNS,cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com idnsAdvertisedLocation: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com When we start integrating with external DNS we will need a special object to represent external DNS servers. We can deal with that later on. d) User interface This is the hardest thing. First rough idea can be seen on http://www.freeipa.org/page/V4/DNS_Location_Mechanism#UI I would think about CLI when we agree on WebUI, IMHO it will be easier. What do you think? I'm waiting for your comments ;-) -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 19 08:11:27 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Feb 2016 09:11:27 +0100 Subject: [Freeipa-devel] Design: Automatic Empty Zone handling in bind-dyndb-ldap In-Reply-To: <56950946.9030703@redhat.com> References: <568FDC52.4050704@redhat.com> <568FEE66.8010600@redhat.com> <5695087B.5010408@redhat.com> <56950946.9030703@redhat.com> Message-ID: <56C6CE2F.9020009@redhat.com> On 12.1.2016 15:10, Martin Basti wrote: > > > On 12.01.2016 15:06, Petr Spacek wrote: >> On 8.1.2016 18:14, Martin Basti wrote: >>> >>> On 08.01.2016 16:57, Petr Spacek wrote: >>>> Hello, >>>> >>>> recent improvements in FreeIPA 4.3.0 (finally) prevent FreeIPA installer from >>>> creating made-up DNS reverse zones, which already exist on some other DNS >>>> server. >>>> >>>> This change uncovered a well-hidden automatic empty zones in BIND 9.9+, which >>>> is now causing problem to users. >>>> >>>> It seems that this can be fixed by change to the code which handles forward >>>> DNS zones. Short design document with necessary background is available on: >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones >>>> >>>> >>>> Please be so kind and review it ASAP, so I can write the patch quickly and >>>> make life of our QE guys easier. >>>> >>>> Have a nice Friday. >>>> >>> Hello, >>> >>> IIUC, the differences between default bind behaviour and bind-dyndb-ldap >>> behaviour are: >>> >>> * disable automatic empty zone when policy is 'first' or 'only', instead of >>> just 'only' >>> I liked it more than default behaviour of named, but could be this somehow >>> unexpected by users, or they will be happy that it works better (?) than in >>> named? >> I hope users will appreciate it :-) >> >>> * bind-dyndb-ldap will not recreate automate empty zone >>> IMO this should not harm at all >>> >>> so design LGTM, I will thinking about it over this weekend >> Did you find any problem? >> >> >> Petr^2 Spacek > > My mind did not pop out any issue during weekend. > It should work :) I was discussing this further with BIND upstream and Mark Andrews do not like it. IMHO we should respect his opinion and do that same what BIND 9.11 is going to do. For this reason I've updated design page https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones with the new approach. Please review it again. It contains new sections Configuration and Upgrade. Thank you! -- Petr^2 Spacek From mbasti at redhat.com Fri Feb 19 09:40:52 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 19 Feb 2016 10:40:52 +0100 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins Message-ID: <56C6E324.2090509@redhat.com> WIP patch attached https://fedorahosted.org/freeipa/ticket/5665 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0416-WIP-fix-upgrade-sidgen-and-extdom.patch Type: text/x-patch Size: 10226 bytes Desc: not available URL: From pvoborni at redhat.com Fri Feb 19 09:51:53 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Feb 2016 10:51:53 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0009] WebUI tests fix In-Reply-To: <56C2E773.8070304@redhat.com> References: <56BC5EC0.7000608@redhat.com> <56C2E773.8070304@redhat.com> Message-ID: <56C6E5B9.7020004@redhat.com> On 02/16/2016 10:10 AM, Lenka Doudova wrote: > > > On 02/11/2016 11:13 AM, Lenka Doudova wrote: >> Hi all, >> >> most of webUI tests fail with >> >> AssertionError: Can't click on checkbox label: table.table >> Message: Element is not clickable at point (37, 340.3999938964844). >> Other element would receive the click: >> > type="checkbox"> >> >> >> The problem seems to be that the tests attempt to click on a checkbox >> label that is no longer there. Since the checkbox is clickable >> directly, I changed the code accordingly. Most of the tests should now >> proceed successfully. >> >> Lenka >> >> > > Attaching updated patch with minor fix. > > Lenka > > would ACK but the commit message is so generic that it doesn't say anything. Also the description in the mail should be in commit message to be usable in a future. -- Petr Vobornik From abokovoy at redhat.com Fri Feb 19 10:12:26 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Feb 2016 12:12:26 +0200 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56C6E324.2090509@redhat.com> References: <56C6E324.2090509@redhat.com> Message-ID: <20160219101226.GQ4492@redhat.com> On Fri, 19 Feb 2016, Martin Basti wrote: >WIP patch attached > >https://fedorahosted.org/freeipa/ticket/5665 > Comments inline. >+ # we need to run sidgen task >+ sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >+ "cn=config") >+ sidgen_tasks_attr = { >+ "objectclass": ["top", "extensibleObject"], >+ "cn": ["sidgen"], >+ "delay": [0], >+ "nsslapd-basedn": [self.api.env.basedn], >+ } May be you are better to name this task more uniquely? Something like 'cn=generate domain sid,cn=...'? >+ >+ task_entry = ldap.make_entry(sidgen_task_dn, >+ **sidgen_tasks_attr) >+ try: >+ ldap.add_entry(task_entry) >+ except errors.DuplicateEntry: >+ self.log.debug("sidgen task already created") >+ else: >+ self.log.debug("sidgen task has been created") There could be multiple tasks running in parallel, that's why it could be good to use a different and unique name. >+ # we have to check all trusts domains which have been added after the >+ # upgrade that caused bug was done. >+ >+ base_dn = DN(self.api.env.container_adtrusts, self.api.env.basedn) >+ trust_domain_entries, truncated = ldap.find_entries( >+ base_dn=base_dn, >+ scope=ldap.SCOPE_ONELEVEL, >+ attrs_list=[attr_name, "cn"], >+ ) >+ >+ if truncated: >+ self.log.warning("update_sids: Search results were truncated") >+ >+ for entry in trust_domain_entries: >+ if entry.single_value[attr_name] is None: >+ domain = entry.single_value["cn"] >+ self.log.error( >+ "Your trust to %s is broken. Please re-create it by " >+ "running 'ipa trust-add' again", domain) >+ >+ sysupgrade.set_upgrade_state('sidgen', 'update_sids', False) >+ return False, () This part looks fine. Basically, a similar check needs to be added to trust_find, trust_show, and may be trust_add. -- / Alexander Bokovoy From dkupka at redhat.com Fri Feb 19 12:00:03 2016 From: dkupka at redhat.com (David Kupka) Date: Fri, 19 Feb 2016 13:00:03 +0100 Subject: [Freeipa-devel] [PATCH 0415] Pylint: disable new pylint checks In-Reply-To: <56C4A7B5.80809@redhat.com> References: <56C4A7B5.80809@redhat.com> Message-ID: <56C703C3.80209@redhat.com> On 17/02/16 18:02, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5615 > > Disable unwanted or false positive checks. > > New checks cannot be disabled inline because pylint < 1.5 will report > them as errors, thus must be disable globally until we decide to move > completely to pytlint 1.5 (Fedora 25?) > > Patches attached. > > Works for me, ACK. All tree branches tested on F23 with pylint 1.4.3-3 -- David Kupka From pviktori at redhat.com Fri Feb 19 12:50:50 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Feb 2016 13:50:50 +0100 Subject: [Freeipa-devel] [PATCH] 0770 Switch /usr/bin/ipa to Python 3 Message-ID: <56C70FAA.4010606@redhat.com> Is it time yet? This patch switches /usr/bin/ipa to Python 3 for - the in-tree ./ipa command - RPMs, when built with_python3 -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0770-Switch-usr-bin-ipa-to-Python-3.patch Type: text/x-patch Size: 2189 bytes Desc: not available URL: From pspacek at redhat.com Fri Feb 19 12:55:12 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Feb 2016 13:55:12 +0100 Subject: [Freeipa-devel] [PATCH 0390] Fix build with GCC 4.9+ Message-ID: <56C710B0.3020005@redhat.com> Hello, Fix build with GCC 4.9+. GCC 4.9+ is too aggressive when optimizing functions with nonnull attributes. This removes most of asserts() in the plugin. GCC 6 adds warnings for these cases. We are disabling the unwanted condition pruning by adding -fno-delete-null-pointer-checks argument. BIND 9 did the same in its commit 603a78708343f063b44affb882ef93bb19a5142a. Additionally we silence warnings to prevent build failures when -Werror is used. https://bugzilla.redhat.com/show_bug.cgi?id=1307346 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0390-Fix-build-with-GCC-4.9.patch Type: text/x-patch Size: 2712 bytes Desc: not available URL: From ofayans at redhat.com Fri Feb 19 13:11:22 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 19 Feb 2016 14:11:22 +0100 Subject: [Freeipa-devel] [TEST][Patch 0022] small refactoring in integration tests due to BZ 1303095 In-Reply-To: <56BDF43D.70503@redhat.com> References: <56AB80BE.4090604@redhat.com> <56B1C6E2.60106@redhat.com> <56B1FE4C.4080600@redhat.com> <56B3029F.70001@redhat.com> <56BDF43D.70503@redhat.com> Message-ID: <56C7147A.1090407@redhat.com> Hi Milan, On 02/12/2016 04:03 PM, Milan Kub?k wrote: > On 02/04/2016 08:49 AM, Oleg Fayans wrote: >> Hi Petr, >> >> On 02/03/2016 02:19 PM, Petr Spacek wrote: >>> On 3.2.2016 10:22, Oleg Fayans wrote: >>>> Guys, can anyone take a look at this? >>> The commit message does not explain why you are setting search path. >> Fixed. >> >>> I have to say that I do not like touching resolv.conf, as stated many times >>> earlier. Why the test has to reconfigure the host and cannot use values >>> provided by the provisioning system? >> This patch exactly removes this messing around with nameservers in >> resolv.conf >> It introduces the possibility to put ipa domain in the search directive >> of resolv.conf so that we could test service autodiscovery during client >> installation. >> >> >> > I just verified that the tampering with resolv.conf is not needed > (libvirt and ovirt/rhev). I think this is an artifact from the whole > issue of "let's use improvised domain names, what can go wrong" approach > that was uncovered by the enforced DNS checks. I think we can defer the > networking configuration to provisioning system. Agreed. The latest patch gets rid of all resolv.conf related manipulations. The tests work (where not affected by https://fedorahosted.org/bind-dyndb-ldap/ticket/160) > > -- > Milan Kubik > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0022.2-Removed-messing-around-with-resolv.conf.patch Type: text/x-patch Size: 3289 bytes Desc: not available URL: From ldoudova at redhat.com Fri Feb 19 13:53:37 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Fri, 19 Feb 2016 14:53:37 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0009] WebUI tests fix In-Reply-To: <56C6E5B9.7020004@redhat.com> References: <56BC5EC0.7000608@redhat.com> <56C2E773.8070304@redhat.com> <56C6E5B9.7020004@redhat.com> Message-ID: <56C71E61.6090107@redhat.com> On 02/19/2016 10:51 AM, Petr Vobornik wrote: > On 02/16/2016 10:10 AM, Lenka Doudova wrote: >> >> >> On 02/11/2016 11:13 AM, Lenka Doudova wrote: >>> Hi all, >>> >>> most of webUI tests fail with >>> >>> AssertionError: Can't click on checkbox label: table.table >>> Message: Element is not clickable at point (37, 340.3999938964844). >>> Other element would receive the click: >>> >> type="checkbox"> >>> >>> >>> The problem seems to be that the tests attempt to click on a checkbox >>> label that is no longer there. Since the checkbox is clickable >>> directly, I changed the code accordingly. Most of the tests should now >>> proceed successfully. >>> >>> Lenka >>> >>> >> >> Attaching updated patch with minor fix. >> >> Lenka >> >> > > would ACK but the commit message is so generic that it doesn't say > anything. > > Also the description in the mail should be in commit message to be > usable in a future. Fix attached, hope this is better. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0009.3-WebUI-tests-fix-failing-of-tests-due-to-unclicable-l.patch Type: text/x-patch Size: 1772 bytes Desc: not available URL: From pvoborni at redhat.com Fri Feb 19 13:57:18 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 19 Feb 2016 14:57:18 +0100 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins In-Reply-To: <20160219101226.GQ4492@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> Message-ID: <56C71F3E.4080102@redhat.com> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: > On Fri, 19 Feb 2016, Martin Basti wrote: >> WIP patch attached >> >> https://fedorahosted.org/freeipa/ticket/5665 >> > Comments inline. > >> + # we need to run sidgen task >> + sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >> + "cn=config") >> + sidgen_tasks_attr = { >> + "objectclass": ["top", "extensibleObject"], >> + "cn": ["sidgen"], >> + "delay": [0], >> + "nsslapd-basedn": [self.api.env.basedn], >> + } > May be you are better to name this task more uniquely? > Something like 'cn=generate domain sid,cn=...'? > >> + >> + task_entry = ldap.make_entry(sidgen_task_dn, >> + **sidgen_tasks_attr) >> + try: >> + ldap.add_entry(task_entry) >> + except errors.DuplicateEntry: >> + self.log.debug("sidgen task already created") >> + else: >> + self.log.debug("sidgen task has been created") > There could be multiple tasks running in parallel, that's why it could > be good to use a different and unique name. > >> + # we have to check all trusts domains which have been added >> after the >> + # upgrade that caused bug was done. >> + >> + base_dn = DN(self.api.env.container_adtrusts, >> self.api.env.basedn) >> + trust_domain_entries, truncated = ldap.find_entries( >> + base_dn=base_dn, >> + scope=ldap.SCOPE_ONELEVEL, >> + attrs_list=[attr_name, "cn"], >> + ) >> + >> + if truncated: >> + self.log.warning("update_sids: Search results were >> truncated") >> + >> + for entry in trust_domain_entries: >> + if entry.single_value[attr_name] is None: >> + domain = entry.single_value["cn"] >> + self.log.error( >> + "Your trust to %s is broken. Please re-create it >> by " >> + "running 'ipa trust-add' again", domain) >> + >> + sysupgrade.set_upgrade_state('sidgen', 'update_sids', False) >> + return False, () > This part looks fine. Basically, a similar check needs to be added to > trust_find, trust_show, and may be trust_add. > Why trust-add? I'm not a big fan of cluttering existing commands(find, show, mod) with logic to fix one upgrade bug. But I understand a need to communicate it somehow. Would it make sense to move such logic to a separate command, e.g. trust-check/trust-verify? The command can do additional check in a future. -- Petr Vobornik From abokovoy at redhat.com Fri Feb 19 14:02:16 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Feb 2016 16:02:16 +0200 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56C71F3E.4080102@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> Message-ID: <20160219140216.GZ4492@redhat.com> On Fri, 19 Feb 2016, Petr Vobornik wrote: >On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: >>On Fri, 19 Feb 2016, Martin Basti wrote: >>>WIP patch attached >>> >>>https://fedorahosted.org/freeipa/ticket/5665 >>> >>Comments inline. >> >>>+ # we need to run sidgen task >>>+ sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >>>+ "cn=config") >>>+ sidgen_tasks_attr = { >>>+ "objectclass": ["top", "extensibleObject"], >>>+ "cn": ["sidgen"], >>>+ "delay": [0], >>>+ "nsslapd-basedn": [self.api.env.basedn], >>>+ } >>May be you are better to name this task more uniquely? >>Something like 'cn=generate domain sid,cn=...'? >> >>>+ >>>+ task_entry = ldap.make_entry(sidgen_task_dn, >>>+ **sidgen_tasks_attr) >>>+ try: >>>+ ldap.add_entry(task_entry) >>>+ except errors.DuplicateEntry: >>>+ self.log.debug("sidgen task already created") >>>+ else: >>>+ self.log.debug("sidgen task has been created") >>There could be multiple tasks running in parallel, that's why it could >>be good to use a different and unique name. >> >>>+ # we have to check all trusts domains which have been added >>>after the >>>+ # upgrade that caused bug was done. >>>+ >>>+ base_dn = DN(self.api.env.container_adtrusts, >>>self.api.env.basedn) >>>+ trust_domain_entries, truncated = ldap.find_entries( >>>+ base_dn=base_dn, >>>+ scope=ldap.SCOPE_ONELEVEL, >>>+ attrs_list=[attr_name, "cn"], >>>+ ) >>>+ >>>+ if truncated: >>>+ self.log.warning("update_sids: Search results were >>>truncated") >>>+ >>>+ for entry in trust_domain_entries: >>>+ if entry.single_value[attr_name] is None: >>>+ domain = entry.single_value["cn"] >>>+ self.log.error( >>>+ "Your trust to %s is broken. Please re-create it >>>by " >>>+ "running 'ipa trust-add' again", domain) >>>+ >>>+ sysupgrade.set_upgrade_state('sidgen', 'update_sids', False) >>>+ return False, () >>This part looks fine. Basically, a similar check needs to be added to >>trust_find, trust_show, and may be trust_add. >> > >Why trust-add? > >I'm not a big fan of cluttering existing commands(find, show, mod) >with logic to fix one upgrade bug. But I understand a need to >communicate it somehow. > >Would it make sense to move such logic to a separate command, e.g. >trust-check/trust-verify? The command can do additional check in a >future. No. What is the value of trust-add if it says you 'Trust established and verified' while in reality it didn't? This specific issue is very easy to catch. -- / Alexander Bokovoy From mkosek at redhat.com Fri Feb 19 14:06:32 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Feb 2016 15:06:32 +0100 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins In-Reply-To: <20160219140216.GZ4492@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> Message-ID: <56C72168.5070406@redhat.com> On 02/19/2016 03:02 PM, Alexander Bokovoy wrote: > On Fri, 19 Feb 2016, Petr Vobornik wrote: >> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: >>> On Fri, 19 Feb 2016, Martin Basti wrote: >>>> WIP patch attached >>>> >>>> https://fedorahosted.org/freeipa/ticket/5665 >>>> >>> Comments inline. >>> >>>> + # we need to run sidgen task >>>> + sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >>>> + "cn=config") >>>> + sidgen_tasks_attr = { >>>> + "objectclass": ["top", "extensibleObject"], >>>> + "cn": ["sidgen"], >>>> + "delay": [0], >>>> + "nsslapd-basedn": [self.api.env.basedn], >>>> + } >>> May be you are better to name this task more uniquely? >>> Something like 'cn=generate domain sid,cn=...'? >>> >>>> + >>>> + task_entry = ldap.make_entry(sidgen_task_dn, >>>> + **sidgen_tasks_attr) >>>> + try: >>>> + ldap.add_entry(task_entry) >>>> + except errors.DuplicateEntry: >>>> + self.log.debug("sidgen task already created") >>>> + else: >>>> + self.log.debug("sidgen task has been created") >>> There could be multiple tasks running in parallel, that's why it could >>> be good to use a different and unique name. >>> >>>> + # we have to check all trusts domains which have been added >>>> after the >>>> + # upgrade that caused bug was done. >>>> + >>>> + base_dn = DN(self.api.env.container_adtrusts, >>>> self.api.env.basedn) >>>> + trust_domain_entries, truncated = ldap.find_entries( >>>> + base_dn=base_dn, >>>> + scope=ldap.SCOPE_ONELEVEL, >>>> + attrs_list=[attr_name, "cn"], >>>> + ) >>>> + >>>> + if truncated: >>>> + self.log.warning("update_sids: Search results were >>>> truncated") >>>> + >>>> + for entry in trust_domain_entries: >>>> + if entry.single_value[attr_name] is None: >>>> + domain = entry.single_value["cn"] >>>> + self.log.error( >>>> + "Your trust to %s is broken. Please re-create it >>>> by " >>>> + "running 'ipa trust-add' again", domain) >>>> + >>>> + sysupgrade.set_upgrade_state('sidgen', 'update_sids', False) >>>> + return False, () >>> This part looks fine. Basically, a similar check needs to be added to >>> trust_find, trust_show, and may be trust_add. >>> >> >> Why trust-add? >> >> I'm not a big fan of cluttering existing commands(find, show, mod) with logic >> to fix one upgrade bug. But I understand a need to communicate it somehow. >> >> Would it make sense to move such logic to a separate command, e.g. >> trust-check/trust-verify? The command can do additional check in a future. > No. What is the value of trust-add if it says you 'Trust established and > verified' while in reality it didn't? This specific issue is very easy > to catch. I think the point was that we are proposing and doing a non-trivial engineering effort to do warning for one-off bug that will be fixed in next bugfix release. I would agree if the check is more systematic, but doing a special LDAP search (for example) from now on because of this one-off bug does not seem to me as ideal path. From abokovoy at redhat.com Fri Feb 19 14:14:36 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Feb 2016 16:14:36 +0200 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56C72168.5070406@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56C72168.5070406@redhat.com> Message-ID: <20160219141436.GA4492@redhat.com> On Fri, 19 Feb 2016, Martin Kosek wrote: >>> Why trust-add? >>> >>> I'm not a big fan of cluttering existing commands(find, show, mod) with logic >>> to fix one upgrade bug. But I understand a need to communicate it somehow. >>> >>> Would it make sense to move such logic to a separate command, e.g. >>> trust-check/trust-verify? The command can do additional check in a future. >> No. What is the value of trust-add if it says you 'Trust established and >> verified' while in reality it didn't? This specific issue is very easy >> to catch. > >I think the point was that we are proposing and doing a non-trivial engineering >effort to do warning for one-off bug that will be fixed in next bugfix release. >I would agree if the check is more systematic, but doing a special LDAP search >(for example) from now on because of this one-off bug does not seem to me as >ideal path. I don't want to have a separate LDAP search. We do LDAP search *already* in trust_add because the object is actually created by Samba code as result of our interactions with local smbd, so we anyway are reading it. The problem here is in the fact that somebody may restore a backup done before the package upgrade which means whole data in LDAP will be back to the old state even though we ran the upgrade before. -- / Alexander Bokovoy From mkosek at redhat.com Fri Feb 19 14:18:00 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Feb 2016 15:18:00 +0100 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins In-Reply-To: <20160219141436.GA4492@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56C72168.5070406@redhat.com> <20160219141436.GA4492@redhat.com> Message-ID: <56C72418.1090004@redhat.com> On 02/19/2016 03:14 PM, Alexander Bokovoy wrote: > On Fri, 19 Feb 2016, Martin Kosek wrote: >>>> Why trust-add? >>>> >>>> I'm not a big fan of cluttering existing commands(find, show, mod) with logic >>>> to fix one upgrade bug. But I understand a need to communicate it somehow. >>>> >>>> Would it make sense to move such logic to a separate command, e.g. >>>> trust-check/trust-verify? The command can do additional check in a future. >>> No. What is the value of trust-add if it says you 'Trust established and >>> verified' while in reality it didn't? This specific issue is very easy >>> to catch. >> >> I think the point was that we are proposing and doing a non-trivial engineering >> effort to do warning for one-off bug that will be fixed in next bugfix release. >> I would agree if the check is more systematic, but doing a special LDAP search >> (for example) from now on because of this one-off bug does not seem to me as >> ideal path. > I don't want to have a separate LDAP search. We do LDAP search *already* > in trust_add because the object is actually created by Samba code as > result of our interactions with local smbd, so we anyway are reading it. Ok. > The problem here is in the fact that somebody may restore a backup done > before the package upgrade which means whole data in LDAP will be back > to the old state even though we ran the upgrade before. I think that is a highly unlikely situation to warrant any non-trivial development effort. After such restore, when the admin notice that trust is not working, they would start redoing trust-add anyway. From abokovoy at redhat.com Fri Feb 19 14:23:23 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 19 Feb 2016 16:23:23 +0200 Subject: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56C72418.1090004@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56C72168.5070406@redhat.com> <20160219141436.GA4492@redhat.com> <56C72418.1090004@redhat.com> Message-ID: <20160219142323.GB4492@redhat.com> On Fri, 19 Feb 2016, Martin Kosek wrote: >On 02/19/2016 03:14 PM, Alexander Bokovoy wrote: >> On Fri, 19 Feb 2016, Martin Kosek wrote: >>>>> Why trust-add? >>>>> >>>>> I'm not a big fan of cluttering existing commands(find, show, mod) with logic >>>>> to fix one upgrade bug. But I understand a need to communicate it somehow. >>>>> >>>>> Would it make sense to move such logic to a separate command, e.g. >>>>> trust-check/trust-verify? The command can do additional check in a future. >>>> No. What is the value of trust-add if it says you 'Trust established and >>>> verified' while in reality it didn't? This specific issue is very easy >>>> to catch. >>> >>> I think the point was that we are proposing and doing a non-trivial engineering >>> effort to do warning for one-off bug that will be fixed in next bugfix release. >>> I would agree if the check is more systematic, but doing a special LDAP search >>> (for example) from now on because of this one-off bug does not seem to me as >>> ideal path. >> I don't want to have a separate LDAP search. We do LDAP search *already* >> in trust_add because the object is actually created by Samba code as >> result of our interactions with local smbd, so we anyway are reading it. > >Ok. > >> The problem here is in the fact that somebody may restore a backup done >> before the package upgrade which means whole data in LDAP will be back >> to the old state even though we ran the upgrade before. > >I think that is a highly unlikely situation to warrant any non-trivial >development effort. After such restore, when the admin notice that trust is not >working, they would start redoing trust-add anyway. May be. I still think adding check for ipaNTSecurityIdentifier missing for normal operation of trust-add is beneficial because it actually allows us to detect problem immediately. -- / Alexander Bokovoy From simo at redhat.com Fri Feb 19 15:31:47 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Feb 2016 10:31:47 -0500 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56C6CB31.7080005@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> Message-ID: <1455895907.6599.104.camel@redhat.com> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: > On 4.2.2016 18:21, Petr Spacek wrote: > > On 3.2.2016 18:41, Petr Spacek wrote: > >> Hello, > >> > >> I've updated the design page > >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism > >> > >> Namely it now contains 'Version 2'. > > > > Okay, here is the idea how we can make it flexible: > > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation > > Hello, > > I'm thinking about LDAP schema for DNS locations. > > Purpose > ======= > * Allow admins to define any number of locations. > * 1 DNS server advertises at most 1 location. > * 1 location generally contains set of services with different priorities and > weights (in DNS SRV terms). > * Express server & service priority for each defined location in a way which > is granular and flexible and ad the same time easy to manage. > > > Proposal > ======== > a) Container for locations > -------------------------- > cn=locations,cn=ipa,cn=etc,dc=example,dc=com > > > b) 1 location > ------------- > Attributes: > 2.16.840.1.113730.3.8.5.32 idnsLocationMember > Server/service assigned to a DNS Location. Usually used to define 'main' > servers for that location. Should it point to service DNs to be sure we have > smooth upgrade to containers? > > 2.16.840.1.113730.3.8.5.33 idnsBackupLocation > Pointer to another location. Sucks in all servers from that location as one > group with the same priority. Easy to use with _default location where all > 'other' servers are used as backup. > > These two attributes use sub-type priority and relativeweight. > This is the only way I could express all the information without need for > separate objects. > > > Object classes: > 2.16.840.1.113730.3.8.6.7 idnsLocation > MAY ( idnsLocationMember $ idnsBackupLocation ) > > > 1st example: > Location CZ: > - servers czserver1, czserver2 > - priority=1 > - relative weight = 50 % each > - if both CZ servers fail, use servers in location UK as backup (priority 2) > - if all CZ and UK servers fail, use servers in location US as backup > (priority 3) - servers on the other continent are used only as option of last > resort > DN: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > objectClass: idnsLocation > idnsLocationMember;priority1;relativeweight50: > cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > idnsLocationMember;priority1;relativeweight50: > cn=czserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > > Location UK: > - servers ukserver1, ukserver2 > - priority=1 > - server ukserver1 is a new beefy machine so it can handle 3 times more load > than ukserver2, thus relative weights 75 % and 25 % > - if both UK servers fail, use servers in location CZ as backup (priority 2) > - if all CZ and UK servers fail, use servers in location US as backup > (priority 3) - servers on the other continent are used only as option of last > resort > DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > objectClass: idnsLocation > idnsLocationMember;priority1;relativeweight3: > cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > idnsLocationMember;priority1;relativeweight1: > cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > > Location US: > - servers usserver1, usserver2 > - priority=1 > - relative weight = 50 % each > - if both US servers fail, use servers in location CZ and UK as backup > (priority 2) - it is over ocean anyway, so US clients will not make any > difference between CZ and UK locations > DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > objectClass: idnsLocation > idnsLocationMember;priority1;relativeweight50: > cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > idnsLocationMember;priority1;relativeweight50: > cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > idnsBackupLocation;priority2: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > > > Resulting DNS SRV records (generated by FreeIPA framework). Please note that > only numbers in SRV records matter only relatively. Priorities work as group, > weights are relative only inside the group. Absolute values above are used > only in algorithm which generates SRV records: > Location CZ: > _kerberos._udp SRV 1 50 czserver1 > _kerberos._udp SRV 1 50 czserver2 > _kerberos._udp SRV 2 75 ukserver1 > _kerberos._udp SRV 2 25 ukserver1 > _kerberos._udp SRV 3 50 usserver1 > _kerberos._udp SRV 3 50 usserver2 > > Location UK: > _kerberos._udp SRV 1 75 ukserver1 > _kerberos._udp SRV 1 25 ukserver1 > _kerberos._udp SRV 2 50 czserver1 > _kerberos._udp SRV 2 50 czserver2 > _kerberos._udp SRV 3 50 usserver1 > _kerberos._udp SRV 3 50 usserver2 > > Location US: > _kerberos._udp SRV 1 50 usserver1 > _kerberos._udp SRV 1 50 usserver2 > _kerberos._udp SRV 2 250 czserver1 > _kerberos._udp SRV 2 250 czserver2 > _kerberos._udp SRV 2 375 ukserver1 > _kerberos._udp SRV 2 125 ukserver1 > > > 2nd example: > - 10 locations with 4 servers each > - we want to have use only 1 server from each location as backup so clients > will not spend a lot of time while attempting to contact cut-off branch (e.g. > when remote WAN link is down) > -> use only idnsLocationMember attribute instead of idnsBackupLocation attribute > > > Fancier combinations are possible with this schema. I assume that fancy things > will be necessary later on if/when IPA supports large topologies. > > > > c) Assigning DNS servers to locations: > Each DNS server can advertise at most 1 location as 'default' to its clients. > > Attributes: > 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation > Pointer to a idnsLocation object. On DNS service object / external server. > Single-valued. > > Example: > DN: cn=DNS,cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > idnsAdvertisedLocation: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com > > When we start integrating with external DNS we will need a special object to > represent external DNS servers. We can deal with that later on. > > > d) User interface > This is the hardest thing. > > First rough idea can be seen on > http://www.freeipa.org/page/V4/DNS_Location_Mechanism#UI > > I would think about CLI when we agree on WebUI, IMHO it will be easier. > > > What do you think? I'm waiting for your comments ;-) I am thinking about it, on the surface it all looks quite reasonable. I think the UI is alittle messy, I wonder if we want to expose lower level concepts as priority and groups, or if we just want to allow users to set an order in the UI and then let the framework come up with weight an priority numbers to assign. Maybe have a way in the CLI to override the decisions of the framework and set explicit weights ? Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Mon Feb 22 01:20:26 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Sun, 21 Feb 2016 20:20:26 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators Message-ID: <1456104026.2488.15.camel@redhat.com> https://github.com/npmccallum/freeipa/pull/1 The above (pseudo) pull request contains four patches against FreeIPA to enable the insertion of Authentication Indicators into Kerberos tickets. The basic flow looks like this. First, we patch ipa-pwd-extop to return a control indicating what authentication method succeeded resulting in a successful bind. Second, we patch ipa-otpd to check the returned control to ensure that the bind resulted from an otp validation. Third, we patch ipa-kdb to enable the KDC to return either the encrypted timestamp or encrypted challenge preauth mechanism when the user is configured for optional 2FA logins. Clients can then decide whether to do 1FA or 2FA login (for kinit, sane behavior already exists). Forth, we patch ipa-kdb again to insert hard-coded authentication indicators for either OTP or RADIUS. Some explanation is required for the first two patches. Currently, it is possible to do a 1FA through the otp preauthentication mechanism if the user is configured for doing optional 2FA. However, because we want to insert an authentication indicator in this code path, we need to guarantee that a request going through the otp preauth mechanism actually validates an OTP. This is the purpose of the control. Items still on the TODO list: ? * Authentication Indicator enforcement ? ? - Upstream libkrb5 needs to grow funcs for reading indicators ? ? - Schema change to add indicators multi-value attr to services ? ? - ipa-kdb needs to implement check_policy_tgs() ? * SSSD needs to learn to handle optional 2FA I will write up a project page for all of this tomorrow. But this small code basically amounts to my brainstorming. It is not ready for merge, just basic review. From simo at redhat.com Mon Feb 22 01:50:56 2016 From: simo at redhat.com (Simo Sorce) Date: Sun, 21 Feb 2016 20:50:56 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456104026.2488.15.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> Message-ID: <1456105856.6599.132.camel@redhat.com> On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: > https://github.com/npmccallum/freeipa/pull/1 > > The above (pseudo) pull request contains four patches against FreeIPA > to enable the insertion of Authentication Indicators into Kerberos > tickets. The basic flow looks like this. > > First, we patch ipa-pwd-extop to return a control indicating what > authentication method succeeded resulting in a successful bind. > > Second, we patch ipa-otpd to check the returned control to ensure that > the bind resulted from an otp validation. > > Third, we patch ipa-kdb to enable the KDC to return either the > encrypted timestamp or encrypted challenge preauth mechanism when the > user is configured for optional 2FA logins. Clients can then decide > whether to do 1FA or 2FA login (for kinit, sane behavior already > exists). > > Forth, we patch ipa-kdb again to insert hard-coded authentication > indicators for either OTP or RADIUS. > > Some explanation is required for the first two patches. Currently, it > is possible to do a 1FA through the otp preauthentication mechanism if > the user is configured for doing optional 2FA. However, because we want > to insert an authentication indicator in this code path, we need to > guarantee that a request going through the otp preauth mechanism > actually validates an OTP. This is the purpose of the control. > > Items still on the TODO list: > > * Authentication Indicator enforcement > - Upstream libkrb5 needs to grow funcs for reading indicators > - Schema change to add indicators multi-value attr to services > - ipa-kdb needs to implement check_policy_tgs() > > > * SSSD needs to learn to handle optional 2FA > > I will write up a project page for all of this tomorrow. But this small > code basically amounts to my brainstorming. It is not ready for merge, > just basic review. > It looks mostly ok, however the LDAP control part needs to be done as a request/response pair. A client that wishes to know what kind of authentication happened should send a request control, and only in that case , the server will send the associated reply control with the requested information. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Feb 22 06:18:13 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Feb 2016 07:18:13 +0100 Subject: [Freeipa-devel] [PATCH 0022-23] Coverity patches In-Reply-To: <56B0A2B1.8040507@redhat.com> References: <56AB6E03.2030601@redhat.com> <56AB7BF0.9030008@redhat.com> <56AB7BFD.1020308@redhat.com> <56AF113D.20804@redhat.com> <56AF3D46.5060901@redhat.com> <56AF5C75.9050409@redhat.com> <56B0A2B1.8040507@redhat.com> Message-ID: <56CAA825.60903@redhat.com> On 2.2.2016 13:36, Stanislav Laznicka wrote: > On 02/01/2016 02:24 PM, Jan Cholasta wrote: >> On 1.2.2016 12:11, Petr Spacek wrote: >>> On 1.2.2016 09:03, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 29.1.2016 15:49, Martin Basti wrote: >>>>> >>>>> >>>>> On 29.01.2016 15:49, Stanislav Laznicka wrote: >>>>>> Reworded the commits so that they better reflect what's going on >>>>>> in those. >>>>>> >>>>>> On 01/29/2016 02:49 PM, Stanislav Laznicka wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I made some patches based on the Coverity report from 18.1.2016. >>>>>>> >>>>>>> Cheers, >>>>>>> Standa >>>>>>> >>>>>> >>>>> NACK, see my previous email >>>> >>>> I don't think this deserves 9 patches, 1 would be sufficient enough. >>> >>> I would rather have it is separate patches as these fixes are largely >>> not >>> related. It will make bisecting easier. >> >> Most of the fixes are cosmetic, which makes them related, and the rest >> are small isolated changes, so in reality it would hardly make >> bisecting easier and only increase the overhead. In the past we >> usually had put such fixes into a single patch and AFAIK nobody >> complained so far. >> > Squeezed the changes into two new patches, then. One for the very > cosmetic changes, one for possible bugs. OK. >>> >>> >>>> Patch 0013: >>>> >>>> 1) I think this unreachable return is intentional, as indicated by >>>> the comment: >>>> >>>> - #we shouldn't get here >>>> - return [UNKNOWN_ERROR] >>> >>> I would use >>> assert False, "we shouldn't get here" >>> neither we nor Coverity are confused when we hit the code path one day. >>> >>> UNKNOWN_ERROR would pop up somewhere else and it will be harder to >>> find out >>> why the hell the code behaves as mad. Traceback will clearly indicate >>> that >>> there is a problem with the 'switch'. >> >> Sure, my point is that returning None is no better than returning >> UNKNOWN_ERROR. >> > Added assert as suggested. There should still be no way of getting to > it, though. >>> >>> Petr^2 Spacek >>> >>>> 2) How is this dead code? >>>> >>>> - if options.mode == 'validate_pot' or options.mode == >>>> 'validate_po': >>>> + if options.mode in ('validate_pot', 'validate_po'): >>>> >>>> - elif options.mode == 'create_test' or 'test_gettext': >>>> + elif options.mode in ('create_test', 'test_gettext'): >>>> >>>> >>>> >>>> Patch 0014-0015: LGTM >> >> Actually scratch that, patch 0015 breaks correct code. >> > The dead code appears in the 'else' branch as the latter of these two > conditions always evaluates to True. The first condition change is just > a cosmetic one so that both of the conditions look the same. OK. > > Also removed the changes made in patch 0015. >>>> >>>> >>>> Patch 0016: The original code is in fact correct. >>>> > Point taken, removed the change. >>>> >>>> Patch 0017: This will break Python 3. The two branches are >>>> performing the same >>>> action, but with different data types. >>>> > This might undergo further investigation in the future as there is no > way how "bytes" instance could become an argument of this function (as > suggested). Not even the newest Python 3 patches from pviktori mention > this code. OK. (This is not what Coverity was complaining about, though.) >>>> >>>> Patch 0018: LGTM >>>> >>>> >>>> Patch 0019: IMO the original code is better (None has a __class__ >>>> too, you know). >>>> > Made it more "Coverity friendly" yet nice enough modification. >>>> >>>> Patch 0020: LGTM >>>> > It seems that there actually is a check that checks whether the input is > correct. It is called ad-hoc but that might be the test feature. > Therefore just added an assert so that Coverity does not complain. OK. >>>> >>>> Patch 0021: Please use the original error messages (there are no >>>> requests >>>> being added to D-Bus, but to certmonger). >>>> >>>> >>>> Honza >>> >> > Added error messages that reflect the situation better, then. Could you please mention Coverity in the commit messages, so that it's clear why are we doing these changes? Otherwise LGTM. -- Jan Cholasta From jcholast at redhat.com Mon Feb 22 06:28:54 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Feb 2016 07:28:54 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56C58A8C.3050200@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> Message-ID: <56CAAAA6.5010302@redhat.com> On 18.2.2016 10:10, David Kupka wrote: > On 19/01/16 16:10, David Kupka wrote: >> On 19/01/16 14:38, Jan Cholasta wrote: >>> On 19.1.2016 14:26, Martin Kosek wrote: >>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>> >>>>> Thanks for the patch. I've fixed the path in specfile and removed >>>>> unused import >>>>> but otherwise it works, ACK. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>> >>>> Won't this break existing certmonger requests depending on the old >>>> path? >>> >>> It will, I don't see any upgrade code. >>> >>>> >>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>> "auditSigningCert >>>> cert-pki-ca" >>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>> "ocspSigningCert >>>> cert-pki-ca" >>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>> "subsystemCert >>>> cert-pki-ca" >>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>> "caSigningCert >>>> cert-pki-ca" >>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>> "Server-Cert >>>> cert-pki-ca" >>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv RHEL72 >>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>> >>> >>> >> >> You're right it will break the upgrade. I haven't noticed that >> Server-Cert for DS and HTTPD are not handled by >> certificate_renewal_update (ipaserver.install.server.upgrade) where all >> the other trackings are stopped and then configured again with the >> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >> >> Thanks for the catch. >> > > I've updated Timo's patch little more and added > start_tracking_certificates() for dsinstance and httpinstance. Now the > upgrade works as expected. The way the patches are split is kind of weird and apparently confusing (see the other thread). IMO there should be 2 patches: the first should add the ability to change DS and HTTP certmonger config during upgrade (i.e. the start_tracking_certificates() methods and certificate_renewal_update() changes), the second should move the helpers (i.e. the actual move and certificate_renewal_update() version bump). -- Jan Cholasta From jcholast at redhat.com Mon Feb 22 08:00:33 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Feb 2016 09:00:33 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements In-Reply-To: <56C47A58.6050207@redhat.com> References: <56C47A58.6050207@redhat.com> Message-ID: <56CAC021.8080906@redhat.com> Hi, On 17.2.2016 14:49, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5631 > > Patch attached (for master, 4.3, 4.2) 1) All the replication agreement permission ACIs should be located in the same entry. Currently "Read Replication Agreements" is in "cn=config" and everything else in "cn=mapping tree,cn=config", so I guess "cn=mapping tree,cn=config" makes more sense. 2) Instead of literal DN('cn=permissions,cn=pbac'), use api.env.container_permissions. 3) IMO the removal of managed permission attributes could be a little bit more robust. You should check that the original entry contains all the required values before touching it (objectclass=ipapermissionv2, ipapermissiontype=V2, ipapermissiontype=MANAGED) and remove only the values that need to be removed, instead of just overwriting everything. Honza -- Jan Cholasta From fskola at redhat.com Mon Feb 22 10:09:16 2016 From: fskola at redhat.com (Filip Skola) Date: Mon, 22 Feb 2016 05:09:16 -0500 (EST) Subject: [Freeipa-devel] [PATCH 0002] Refactor test_group_plugin In-Reply-To: <56BAF2FB.5050100@redhat.com> References: <20151120135636.71171d5c@vor2.netbox.priv> <569CD602.1030604@redhat.com> <1869235561.17372506.1453716664538.JavaMail.zimbra@redhat.com> <56A7B34E.2050906@redhat.com> <1320714330.19162635.1453974171503.JavaMail.zimbra@redhat.com> <56BA0388.7040307@redhat.com> <56BAF20B.3080305@redhat.com> <56BAF2FB.5050100@redhat.com> Message-ID: <713443456.32722025.1456135756669.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 02/10/2016 09:17 AM, Milan Kub?k wrote: > > On 02/09/2016 04:19 PM, Milan Kub?k wrote: > >> On 01/28/2016 10:42 AM, Filip Skola wrote: > >>> > >>> ----- Original Message ----- > >>>> On 01/25/2016 11:11 AM, Filip Skola wrote: > >>>>> ----- Original Message ----- > >>>>>> On 01/15/2016 03:38 PM, Filip Skola wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> sending rebased patch. > >>>>>>> > >>>>>>> F. > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> sorry for delays. The patch no longer applies to master. Rebase > >>>>>>>> it, > >>>>>>>> please. > >>>>>>>> > >>>>>>>> Milan > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>> From: "Filip ?kola" > >>>>>>>> To: "Milan Kub?k" > >>>>>>>> Cc: freeipa-devel at redhat.com > >>>>>>>> Sent: Wednesday, 9 December, 2015 7:01:02 PM > >>>>>>>> Subject: Re: [Freeipa-devel] [PATCH 0002] Refactor > >>>>>>>> test_group_plugin > >>>>>>>> > >>>>>>>> On Mon, 7 Dec 2015 17:49:18 +0100 > >>>>>>>> Milan Kub?k wrote: > >>>>>>>> > >>>>>>>>> On 12/03/2015 08:15 PM, Filip ?kola wrote: > >>>>>>>>>> On Mon, 30 Nov 2015 17:18:30 +0100 > >>>>>>>>>> Milan Kub?k wrote: > >>>>>>>>>> > >>>>>>>>>>> On 11/23/2015 04:42 PM, Filip ?kola wrote: > >>>>>>>>>>>> Sending updated patch. > >>>>>>>>>>>> > >>>>>>>>>>>> F. > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, 23 Nov 2015 14:59:34 +0100 > >>>>>>>>>>>> Filip ?kola wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Found couple of issues (broke some dependencies). > >>>>>>>>>>>>> > >>>>>>>>>>>>> NACK > >>>>>>>>>>>>> > >>>>>>>>>>>>> F. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Fri, 20 Nov 2015 13:56:36 +0100 > >>>>>>>>>>>>> Filip ?kola wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Another one. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> F. > >>>>>>>>>>> Hi, the tests look good. Few remarks, though. > >>>>>>>>>>> > >>>>>>>>>>> 1. Please, use the shortes copyright notice in new modules. > >>>>>>>>>>> > >>>>>>>>>>> # > >>>>>>>>>>> # Copyright (C) 2015 FreeIPA Contributors see > >>>>>>>>>>> COPYING for > >>>>>>>>>>> license # > >>>>>>>>>>> > >>>>>>>>>>> 2. The tests `test_group_remove_group_from_protected_group` and > >>>>>>>>>>> `test_group_full_set_of_objectclass_not_available_post_detach` > >>>>>>>>>>> were not ported. Please, include them in the patch. > >>>>>>>>>>> > >>>>>>>>>>> Also, for less hassle, please rebase your patches on top of > >>>>>>>>>>> freeipa-mkubik-0025-3-Separated-Tracker-implementations-into-standalone-pa.patch > >>>>>>>>>>> > >>>>>>>>>>> Which changes the location of tracker implementations and > >>>>>>>>>>> prevents > >>>>>>>>>>> circular imports. > >>>>>>>>>>> > >>>>>>>>>>> Thanks. > >>>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> these cases are there, in corresponding classes. They are marked > >>>>>>>>>> with the original comments. (However I can move them to separate > >>>>>>>>>> class if desirable.) > >>>>>>>>>> > >>>>>>>>>> The copyright notice is changed. Also included a few changes > >>>>>>>>>> in the > >>>>>>>>>> test with user without private group. > >>>>>>>>>> > >>>>>>>>>> Filip > >>>>>>>>> NACK > >>>>>>>>> > >>>>>>>>> linter: > >>>>>>>>> ************* Module tracker.group_plugin > >>>>>>>>> ipatests/test_xmlrpc/tracker/group_plugin.py:257: > >>>>>>>>> [E0102(function-redefined), GroupTracker.check_remove_member] > >>>>>>>>> method > >>>>>>>>> already defined line 253) > >>>>>>>>> > >>>>>>>>> Probably a leftover after the rebase made on top of my patch. > >>>>>>>>> Please > >>>>>>>>> fix it. You can check youch changes by make-lint script before > >>>>>>>>> sending them. > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I learned to use make-lint! > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> F. > >>>>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> NACK, pylint doesn't seem to like the way the fixtures are imported > >>>>>> (pytest does a lot of runtime magic) [1]. > >>>>>> One possible solution would be [2]. Though, I don't think this > >>>>>> would be > >>>>>> a good idea in our environment. I suggest to create the fixtures > >>>>>> on per > >>>>>> module basis. > >>>>>> > >>>>>> > >>>>>> [1]: http://fpaste.org/311949/53118942/ > >>>>>> [2]: > >>>>>> https://pytest.org/latest/fixture.html#using-fixtures-from-classes-modules-or-projects > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Milan Kubik > >>>>>> > >>>>>> > >>>>> Hi, > >>>>> > >>>>> the fixtures were copied into corresponding module. Please note > >>>>> that this > >>>>> patch has a dependence on my patch 0001 (user plugin). > >>>>> > >>>>> Filip > >>>> Linter: > >>>> ************* Module ipatests.test_xmlrpc.tracker.group_plugin > >>>> W:100,26: Calling a dict.iter*() method (dict-iter-method) > >>>> > >>>> please use dict.items > >>>> > >>>> -- > >>>> Milan Kubik > >>>> > >>>> > >>> Hi, sorry. This has been fixed in this patch. > >>> > >>> Filip > >> ACK, thanks for the patience. :) > >> > > Sorry, there are some other things I need clarified. NACK. > > Mail will follow later. > > > What is the purpose of `make_fixture_detach` in your patches? They are > not used anywhere and the finalizer does nothing. > > -- > Milan Kubik > > Hi, none, I guess, probably a leftover copied from the tracker in the early days. Deleting the function. Filip -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0002-8-Refactor-test_group_plugin.patch Type: text/x-patch Size: 75337 bytes Desc: not available URL: From abokovoy at redhat.com Mon Feb 22 10:48:11 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Feb 2016 12:48:11 +0200 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members Message-ID: <20160222104811.GN4492@redhat.com> Hi, attached patch should update compat tree configuration if it exist to follow slapi-nis 0.55 which has support for external members of IPA groups. However, the real work is done in SSSD. These patches are not upstreamed yet. We'll need to bump SSSD dependency in future once they come to distros. -- / Alexander Bokovoy -------------- next part -------------- From b08234f61ce7c6286ca9109df11a4c469862c428 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 22 Feb 2016 12:40:03 +0200 Subject: [PATCH] slapi-nis: update configuration to allow external members of IPA groups Currently in an environment with trust to AD the compat tree does not show AD users as members of IPA groups. The reason is that IPA groups are read directly from the IPA DS tree and external groups are not handled. slapi-nis project has added support for it in 0.55, make sure we update configuration for the group map if it exists and depend on 0.55 version. https://fedorahosted.org/freeipa/ticket/4403 --- freeipa.spec.in | 2 +- install/updates/50-externalmembers.update | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 install/updates/50-externalmembers.update diff --git a/freeipa.spec.in b/freeipa.spec.in index 54a11bf..0b14bdc 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -153,7 +153,7 @@ Requires(pre): systemd-units Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base >= %{selinux_policy_version} -Requires: slapi-nis >= 0.54.2-1 +Requires: slapi-nis >= 0.55-1 Requires: pki-ca >= 10.2.6-13 Requires: pki-kra >= 10.2.6-13 Requires(preun): python systemd-units diff --git a/install/updates/50-externalmembers.update b/install/updates/50-externalmembers.update new file mode 100644 index 0000000..0831cd2 --- /dev/null +++ b/install/updates/50-externalmembers.update @@ -0,0 +1,4 @@ +dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config +addifexist: schema-compat-entry-attribute: ipaexternalmember=%deref_r("member","ipaexternalmember") +addifexist: schema-compat-entry-attribute: objectclass=ipaexternalgroup + -- 2.5.0 From pviktori at redhat.com Mon Feb 22 11:35:43 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Feb 2016 12:35:43 +0100 Subject: [Freeipa-devel] [PATCH] 0771 Package python3-ipaclient Message-ID: <56CAF28F.6080308@redhat.com> Hello, This will make a python3-ipaclient RPM. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0771-Package-python3-ipaclient.patch Type: text/x-patch Size: 2738 bytes Desc: not available URL: From pviktori at redhat.com Mon Feb 22 11:37:51 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Feb 2016 12:37:51 +0100 Subject: [Freeipa-devel] [PATCHES] 0772-0774 Python3 fixes in for client installation Message-ID: <56CAF30F.7010306@redhat.com> Hello, These fixes are needed for the "happy path" of ipa-client-install --server on Python 3. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0772-ipadiscovery-Decode-to-unicode-in-ipacheckldap.patch Type: text/x-patch Size: 2672 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0773-ipapython.sysrestore-Use-str-methods-instead-of-func.patch Type: text/x-patch Size: 2705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0774-ipalib.x809-Accept-bytes-for-make_pem.patch Type: text/x-patch Size: 928 bytes Desc: not available URL: From lslebodn at redhat.com Mon Feb 22 12:50:57 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 22 Feb 2016 13:50:57 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <20160222104811.GN4492@redhat.com> References: <20160222104811.GN4492@redhat.com> Message-ID: <20160222125056.GF7273@mail.corp.redhat.com> On (22/02/16 12:48), Alexander Bokovoy wrote: >Hi, > >attached patch should update compat tree configuration if it exist to >follow slapi-nis 0.55 which has support for external members of IPA >groups. > >However, the real work is done in SSSD. These patches are not upstreamed >yet. We'll need to bump SSSD dependency in future once they come to >distros. > File a fedora BZ and I can backport patches after successful review in sssd/upstream. LS From fskola at redhat.com Mon Feb 22 12:59:43 2016 From: fskola at redhat.com (Filip Skola) Date: Mon, 22 Feb 2016 07:59:43 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin In-Reply-To: <1464040446.19836563.1455196912586.JavaMail.zimbra@redhat.com> References: <1415364427.17513799.1453733845873.JavaMail.zimbra@redhat.com> <1464040446.19836563.1455196912586.JavaMail.zimbra@redhat.com> Message-ID: <1618888650.32803170.1456145983381.JavaMail.zimbra@redhat.com> Hi, sudocmd tracker has been created. Filip ----- Original Message ----- > NACK. > > "create_sudocmd" and "delete_sudocmd" should be placed in Tracker. So this > patch should create the tracker as well. > > ----- Original Message ----- > > From: "Filip Skola" > > To: freeipa-devel at redhat.com > > Sent: Monday, January 25, 2016 3:57:25 PM > > Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin > > > > Hello, > > > > attaching refactored sudocmd_plugin. > > > > Filip > > -- > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0007-2-Refactor-test_sudocmd_plugin.patch Type: text/x-patch Size: 21572 bytes Desc: not available URL: From abokovoy at redhat.com Mon Feb 22 13:02:33 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Feb 2016 15:02:33 +0200 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <20160222125056.GF7273@mail.corp.redhat.com> References: <20160222104811.GN4492@redhat.com> <20160222125056.GF7273@mail.corp.redhat.com> Message-ID: <20160222130233.GP4492@redhat.com> On Mon, 22 Feb 2016, Lukas Slebodnik wrote: >On (22/02/16 12:48), Alexander Bokovoy wrote: >>Hi, >> >>attached patch should update compat tree configuration if it exist to >>follow slapi-nis 0.55 which has support for external members of IPA >>groups. >> >>However, the real work is done in SSSD. These patches are not upstreamed >>yet. We'll need to bump SSSD dependency in future once they come to >>distros. >> >File a fedora BZ and I can backport patches >after successful review in sssd/upstream. Thanks, https://bugzilla.redhat.com/show_bug.cgi?id=1310664 -- / Alexander Bokovoy From mbabinsk at redhat.com Mon Feb 22 13:03:49 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 22 Feb 2016 14:03:49 +0100 Subject: [Freeipa-devel] [PATCH 0135] upgrade: unconditional import of certificate profiles into LDAP Message-ID: <56CB0735.6080408@redhat.com> https://fedorahosted.org/freeipa/ticket/5682 -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0135-upgrade-unconditional-import-of-certificate-profiles.patch Type: text/x-patch Size: 2926 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0135-upgrade-unconditional-import-of-certificate-profiles.patch Type: text/x-patch Size: 2859 bytes Desc: not available URL: From fskola at redhat.com Mon Feb 22 14:41:36 2016 From: fskola at redhat.com (Filip Skola) Date: Mon, 22 Feb 2016 09:41:36 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, create SudoCmdGroupTracker In-Reply-To: <289487922.19837303.1455196994918.JavaMail.zimbra@redhat.com> References: <1667642851.19197845.1453981757248.JavaMail.zimbra@redhat.com> <289487922.19837303.1455196994918.JavaMail.zimbra@redhat.com> Message-ID: <892356320.32871945.1456152096564.JavaMail.zimbra@redhat.com> Hi, the test has been updated so it now uses the SudoCmdTracker (from the previous patch). Filip ----- Original Message ----- > NACK. > > "create_sudocmd" and "delete_sudocmd" should be imported from Tracker, not > from the previous test (sudocmd_plugin). > > - alich - > > ----- Original Message ----- > > From: "Filip Skola" > > To: freeipa-devel at redhat.com > > Sent: Thursday, January 28, 2016 12:49:17 PM > > Subject: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, > > create SudoCmdGroupTracker > > > > Hi, > > > > sending the next sudo patch. This one depends on the previous one > > (sudocmd_plugin). > > > > Filip > > > > -- > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0008-2-Refactor-test_sudocmdgroup_plugin.patch Type: text/x-patch Size: 41147 bytes Desc: not available URL: From dkupka at redhat.com Mon Feb 22 14:56:59 2016 From: dkupka at redhat.com (David Kupka) Date: Mon, 22 Feb 2016 15:56:59 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CAAAA6.5010302@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> Message-ID: <56CB21BB.8000201@redhat.com> On 22/02/16 07:28, Jan Cholasta wrote: > On 18.2.2016 10:10, David Kupka wrote: >> On 19/01/16 16:10, David Kupka wrote: >>> On 19/01/16 14:38, Jan Cholasta wrote: >>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>> >>>>>> Thanks for the patch. I've fixed the path in specfile and removed >>>>>> unused import >>>>>> but otherwise it works, ACK. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>> >>>>> Won't this break existing certmonger requests depending on the old >>>>> path? >>>> >>>> It will, I don't see any upgrade code. >>>> >>>>> >>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>> "auditSigningCert >>>>> cert-pki-ca" >>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>> "ocspSigningCert >>>>> cert-pki-ca" >>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>> "subsystemCert >>>>> cert-pki-ca" >>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>> "caSigningCert >>>>> cert-pki-ca" >>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>> "Server-Cert >>>>> cert-pki-ca" >>>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv RHEL72 >>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>> >>>> >>>> >>> >>> You're right it will break the upgrade. I haven't noticed that >>> Server-Cert for DS and HTTPD are not handled by >>> certificate_renewal_update (ipaserver.install.server.upgrade) where all >>> the other trackings are stopped and then configured again with the >>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>> >>> Thanks for the catch. >>> >> >> I've updated Timo's patch little more and added >> start_tracking_certificates() for dsinstance and httpinstance. Now the >> upgrade works as expected. > > The way the patches are split is kind of weird and apparently confusing > (see the other thread). IMO there should be 2 patches: the first should > add the ability to change DS and HTTP certmonger config during upgrade > (i.e. the start_tracking_certificates() methods and > certificate_renewal_update() changes), the second should move the > helpers (i.e. the actual move and certificate_renewal_update() version > bump). > Honza, do I understand it correctly that the code is OK but I did not split it to the patches correctly? -- David Kupka From jcholast at redhat.com Mon Feb 22 15:04:40 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Feb 2016 16:04:40 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CB21BB.8000201@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> Message-ID: <56CB2388.2040207@redhat.com> On 22.2.2016 15:56, David Kupka wrote: > On 22/02/16 07:28, Jan Cholasta wrote: >> On 18.2.2016 10:10, David Kupka wrote: >>> On 19/01/16 16:10, David Kupka wrote: >>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>> >>>>>>> Thanks for the patch. I've fixed the path in specfile and removed >>>>>>> unused import >>>>>>> but otherwise it works, ACK. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>> >>>>>> Won't this break existing certmonger requests depending on the old >>>>>> path? >>>>> >>>>> It will, I don't see any upgrade code. >>>>> >>>>>> >>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>> "auditSigningCert >>>>>> cert-pki-ca" >>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>> "ocspSigningCert >>>>>> cert-pki-ca" >>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>> "subsystemCert >>>>>> cert-pki-ca" >>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>> "caSigningCert >>>>>> cert-pki-ca" >>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>> "Server-Cert >>>>>> cert-pki-ca" >>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>> RHEL72 >>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>> >>>>> >>>>> >>>> >>>> You're right it will break the upgrade. I haven't noticed that >>>> Server-Cert for DS and HTTPD are not handled by >>>> certificate_renewal_update (ipaserver.install.server.upgrade) where all >>>> the other trackings are stopped and then configured again with the >>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>> >>>> Thanks for the catch. >>>> >>> >>> I've updated Timo's patch little more and added >>> start_tracking_certificates() for dsinstance and httpinstance. Now the >>> upgrade works as expected. >> >> The way the patches are split is kind of weird and apparently confusing >> (see the other thread). IMO there should be 2 patches: the first should >> add the ability to change DS and HTTP certmonger config during upgrade >> (i.e. the start_tracking_certificates() methods and >> certificate_renewal_update() changes), the second should move the >> helpers (i.e. the actual move and certificate_renewal_update() version >> bump). >> > Honza, do I understand it correctly that the code is OK but I did not > split it to the patches correctly? Yes. -- Jan Cholasta From jcholast at redhat.com Mon Feb 22 15:06:19 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Feb 2016 16:06:19 +0100 Subject: [Freeipa-devel] [PATCH 546] client: stop using /etc/pki/nssdb Message-ID: <56CB23EB.1010505@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-546-client-stop-using-etc-pki-nssdb.patch Type: text/x-patch Size: 11225 bytes Desc: not available URL: From mkosek at redhat.com Mon Feb 22 15:15:53 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Feb 2016 16:15:53 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CB2388.2040207@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> Message-ID: <56CB2629.3010102@redhat.com> On 02/22/2016 04:04 PM, Jan Cholasta wrote: > On 22.2.2016 15:56, David Kupka wrote: >> On 22/02/16 07:28, Jan Cholasta wrote: >>> On 18.2.2016 10:10, David Kupka wrote: >>>> On 19/01/16 16:10, David Kupka wrote: >>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>> >>>>>>>> Thanks for the patch. I've fixed the path in specfile and removed >>>>>>>> unused import >>>>>>>> but otherwise it works, ACK. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>> >>>>>>> Won't this break existing certmonger requests depending on the old >>>>>>> path? >>>>>> >>>>>> It will, I don't see any upgrade code. >>>>>> >>>>>>> >>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>> "auditSigningCert >>>>>>> cert-pki-ca" >>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>> "ocspSigningCert >>>>>>> cert-pki-ca" >>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>> "subsystemCert >>>>>>> cert-pki-ca" >>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>> "caSigningCert >>>>>>> cert-pki-ca" >>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>> "Server-Cert >>>>>>> cert-pki-ca" >>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>> RHEL72 >>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>>> >>>>>> >>>>>> >>>>> >>>>> You're right it will break the upgrade. I haven't noticed that >>>>> Server-Cert for DS and HTTPD are not handled by >>>>> certificate_renewal_update (ipaserver.install.server.upgrade) where all >>>>> the other trackings are stopped and then configured again with the >>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>> >>>>> Thanks for the catch. >>>>> >>>> >>>> I've updated Timo's patch little more and added >>>> start_tracking_certificates() for dsinstance and httpinstance. Now the >>>> upgrade works as expected. >>> >>> The way the patches are split is kind of weird and apparently confusing >>> (see the other thread). IMO there should be 2 patches: the first should >>> add the ability to change DS and HTTP certmonger config during upgrade >>> (i.e. the start_tracking_certificates() methods and >>> certificate_renewal_update() changes), the second should move the >>> helpers (i.e. the actual move and certificate_renewal_update() version >>> bump). >>> >> Honza, do I understand it correctly that the code is OK but I did not >> split it to the patches correctly? > > Yes. Before acking or pushing, can you please explain for me how the upgrade of certmonger tracking requests work? I want to make sure this is right, so please bear with me: 1) How does it edit existing tracking requests with the new helper paths? 2) Does it go and try to edit the requests on every upgrade? Or is there some check that requests were updated? Thanks, Martin From mbasti at redhat.com Mon Feb 22 16:05:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Feb 2016 17:05:55 +0100 Subject: [Freeipa-devel] [PATCH 0416] fix broken configuration of sidgen and extdom plugins In-Reply-To: <20160219140216.GZ4492@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> Message-ID: <56CB31E3.7030002@redhat.com> On 19.02.2016 15:02, Alexander Bokovoy wrote: > On Fri, 19 Feb 2016, Petr Vobornik wrote: >> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: >>> On Fri, 19 Feb 2016, Martin Basti wrote: >>>> WIP patch attached >>>> >>>> https://fedorahosted.org/freeipa/ticket/5665 >>>> >>> Comments inline. >>> >>>> + # we need to run sidgen task >>>> + sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >>>> + "cn=config") >>>> + sidgen_tasks_attr = { >>>> + "objectclass": ["top", "extensibleObject"], >>>> + "cn": ["sidgen"], >>>> + "delay": [0], >>>> + "nsslapd-basedn": [self.api.env.basedn], >>>> + } >>> May be you are better to name this task more uniquely? >>> Something like 'cn=generate domain sid,cn=...'? >>> >>>> + >>>> + task_entry = ldap.make_entry(sidgen_task_dn, >>>> + **sidgen_tasks_attr) >>>> + try: >>>> + ldap.add_entry(task_entry) >>>> + except errors.DuplicateEntry: >>>> + self.log.debug("sidgen task already created") >>>> + else: >>>> + self.log.debug("sidgen task has been created") >>> There could be multiple tasks running in parallel, that's why it could >>> be good to use a different and unique name. >>> >>>> + # we have to check all trusts domains which have been added >>>> after the >>>> + # upgrade that caused bug was done. >>>> + >>>> + base_dn = DN(self.api.env.container_adtrusts, >>>> self.api.env.basedn) >>>> + trust_domain_entries, truncated = ldap.find_entries( >>>> + base_dn=base_dn, >>>> + scope=ldap.SCOPE_ONELEVEL, >>>> + attrs_list=[attr_name, "cn"], >>>> + ) >>>> + >>>> + if truncated: >>>> + self.log.warning("update_sids: Search results were >>>> truncated") >>>> + >>>> + for entry in trust_domain_entries: >>>> + if entry.single_value[attr_name] is None: >>>> + domain = entry.single_value["cn"] >>>> + self.log.error( >>>> + "Your trust to %s is broken. Please re-create it >>>> by " >>>> + "running 'ipa trust-add' again", domain) >>>> + >>>> + sysupgrade.set_upgrade_state('sidgen', 'update_sids', False) >>>> + return False, () >>> This part looks fine. Basically, a similar check needs to be added to >>> trust_find, trust_show, and may be trust_add. >>> >> >> Why trust-add? >> >> I'm not a big fan of cluttering existing commands(find, show, mod) >> with logic to fix one upgrade bug. But I understand a need to >> communicate it somehow. >> >> Would it make sense to move such logic to a separate command, e.g. >> trust-check/trust-verify? The command can do additional check in a >> future. > No. What is the value of trust-add if it says you 'Trust established and > verified' while in reality it didn't? This specific issue is very easy > to catch. > Patch attached, patch with warning will land soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0416.2-upgrade-fix-config-of-sidgen-and-extdom-plugins.patch Type: text/x-patch Size: 10744 bytes Desc: not available URL: From pvomacka at redhat.com Mon Feb 22 16:34:14 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Mon, 22 Feb 2016 17:34:14 +0100 Subject: [Freeipa-devel] [PATCH] 0004 webui: topology graph: Add pan and zoom functionality In-Reply-To: <56C5FD80.70007@redhat.com> References: <56B2108E.2@redhat.com> <56C5FD80.70007@redhat.com> Message-ID: <56CB3886.1020805@redhat.com> On 02/18/2016 06:21 PM, Petr Vobornik wrote: > On 02/03/2016 03:37 PM, Pavel Vomacka wrote: >> Hello, >> >> I'm sending a patch for review. This patch adds pan and zoom >> functionality to the topology graph. The page remembers old position and >> size of the graph. So, it keeps these settings after refreshing the >> page. >> >> The patch is in atachement. >> >> Pavel Vomacka >> >> > > 1. if node.fixed should be number then, we can store number in local > storage as well(only as string, e.g. num + '') instead of 'true' so > that we make the logic more straightforward/consistent. > Fixed. > 2. following lines are too long: .attr("transform", "translate(" + > d3.event.translate + ")scale(" + d3.event.scale + ")"); > > .attr('transform', 'translate(' + trans.translate + ')scale(' + > trans.scale + ')'); > These two and one more line are now split into more lines which are short enough. > 3. 'svg_' prefix for translate and scale keys is too generic, would > use e.g. topo_graph > 'svg_' prefix is changed to the 'graph' prefix. There is also change in using 'this' and 'that' variables. Instead of declaring 'that' variable there is used the bind() method. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0004-3-Add-pan-and-zoom-functionality-to-the-topology-graph.patch Type: text/x-patch Size: 7241 bytes Desc: not available URL: From tbabej at redhat.com Mon Feb 22 17:04:02 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 22 Feb 2016 18:04:02 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <20160222104811.GN4492@redhat.com> References: <20160222104811.GN4492@redhat.com> Message-ID: <56CB3F82.1070408@redhat.com> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: > Hi, > > attached patch should update compat tree configuration if it exist to > follow slapi-nis 0.55 which has support for external members of IPA > groups. > > However, the real work is done in SSSD. These patches are not upstreamed > yet. We'll need to bump SSSD dependency in future once they come to > distros. > > > This looks good. However, the new update file needs to be added to Makefile.am. Additionally, patch adds a whitespace error. Tomas From abokovoy at redhat.com Mon Feb 22 17:14:55 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 22 Feb 2016 19:14:55 +0200 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <56CB3F82.1070408@redhat.com> References: <20160222104811.GN4492@redhat.com> <56CB3F82.1070408@redhat.com> Message-ID: <20160222171455.GT4492@redhat.com> On Mon, 22 Feb 2016, Tomas Babej wrote: > > >On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: >> Hi, >> >> attached patch should update compat tree configuration if it exist to >> follow slapi-nis 0.55 which has support for external members of IPA >> groups. >> >> However, the real work is done in SSSD. These patches are not upstreamed >> yet. We'll need to bump SSSD dependency in future once they come to >> distros. >> >> >> > >This looks good. > >However, the new update file needs to be added to Makefile.am. >Additionally, patch adds a whitespace error. Updated patch is attached. -- / Alexander Bokovoy -------------- next part -------------- From 6d50894c6ac2cf7f32b152bd09c16cde2fc327fb Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 22 Feb 2016 12:40:03 +0200 Subject: [PATCH] slapi-nis: update configuration to allow external members of IPA groups Currently in an environment with trust to AD the compat tree does not show AD users as members of IPA groups. The reason is that IPA groups are read directly from the IPA DS tree and external groups are not handled. slapi-nis project has added support for it in 0.55, make sure we update configuration for the group map if it exists and depend on 0.55 version. https://fedorahosted.org/freeipa/ticket/4403 --- freeipa.spec.in | 2 +- install/updates/50-externalmembers.update | 3 +++ install/updates/Makefile.am | 1 + 3 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 install/updates/50-externalmembers.update diff --git a/freeipa.spec.in b/freeipa.spec.in index 54a11bf..0b14bdc 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -153,7 +153,7 @@ Requires(pre): systemd-units Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base >= %{selinux_policy_version} -Requires: slapi-nis >= 0.54.2-1 +Requires: slapi-nis >= 0.55-1 Requires: pki-ca >= 10.2.6-13 Requires: pki-kra >= 10.2.6-13 Requires(preun): python systemd-units diff --git a/install/updates/50-externalmembers.update b/install/updates/50-externalmembers.update new file mode 100644 index 0000000..6b9c5dd --- /dev/null +++ b/install/updates/50-externalmembers.update @@ -0,0 +1,3 @@ +dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config +addifexist: schema-compat-entry-attribute: ipaexternalmember=%deref_r("member","ipaexternalmember") +addifexist: schema-compat-entry-attribute: objectclass=ipaexternalgroup diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index b04ab48..3edc214 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -45,6 +45,7 @@ app_DATA = \ 50-krbenctypes.update \ 50-nis.update \ 50-ipaconfig.update \ + 50-externalmembers.update \ 55-pbacmemberof.update \ 59-trusts-sysacount.update \ 60-trusts.update \ -- 2.5.0 From jcholast at redhat.com Mon Feb 22 17:30:33 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Feb 2016 18:30:33 +0100 Subject: [Freeipa-devel] [PATCH 547] cacert install: fix trust chain validation Message-ID: <56CB45B9.8040204@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-547-cacert-install-fix-trust-chain-validation.patch Type: text/x-patch Size: 1358 bytes Desc: not available URL: From mbasti at redhat.com Mon Feb 22 18:15:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Feb 2016 19:15:46 +0100 Subject: [Freeipa-devel] [PATCH 0416-0417] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56CB31E3.7030002@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> Message-ID: <56CB5052.5040803@redhat.com> On 22.02.2016 17:05, Martin Basti wrote: > > > On 19.02.2016 15:02, Alexander Bokovoy wrote: >> On Fri, 19 Feb 2016, Petr Vobornik wrote: >>> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: >>>> On Fri, 19 Feb 2016, Martin Basti wrote: >>>>> WIP patch attached >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5665 >>>>> >>>> Comments inline. >>>> >>>>> + # we need to run sidgen task >>>>> + sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >>>>> + "cn=config") >>>>> + sidgen_tasks_attr = { >>>>> + "objectclass": ["top", "extensibleObject"], >>>>> + "cn": ["sidgen"], >>>>> + "delay": [0], >>>>> + "nsslapd-basedn": [self.api.env.basedn], >>>>> + } >>>> May be you are better to name this task more uniquely? >>>> Something like 'cn=generate domain sid,cn=...'? >>>> >>>>> + >>>>> + task_entry = ldap.make_entry(sidgen_task_dn, >>>>> + **sidgen_tasks_attr) >>>>> + try: >>>>> + ldap.add_entry(task_entry) >>>>> + except errors.DuplicateEntry: >>>>> + self.log.debug("sidgen task already created") >>>>> + else: >>>>> + self.log.debug("sidgen task has been created") >>>> There could be multiple tasks running in parallel, that's why it could >>>> be good to use a different and unique name. >>>> >>>>> + # we have to check all trusts domains which have been added >>>>> after the >>>>> + # upgrade that caused bug was done. >>>>> + >>>>> + base_dn = DN(self.api.env.container_adtrusts, >>>>> self.api.env.basedn) >>>>> + trust_domain_entries, truncated = ldap.find_entries( >>>>> + base_dn=base_dn, >>>>> + scope=ldap.SCOPE_ONELEVEL, >>>>> + attrs_list=[attr_name, "cn"], >>>>> + ) >>>>> + >>>>> + if truncated: >>>>> + self.log.warning("update_sids: Search results were >>>>> truncated") >>>>> + >>>>> + for entry in trust_domain_entries: >>>>> + if entry.single_value[attr_name] is None: >>>>> + domain = entry.single_value["cn"] >>>>> + self.log.error( >>>>> + "Your trust to %s is broken. Please re-create it >>>>> by " >>>>> + "running 'ipa trust-add' again", domain) >>>>> + >>>>> + sysupgrade.set_upgrade_state('sidgen', 'update_sids', False) >>>>> + return False, () >>>> This part looks fine. Basically, a similar check needs to be added to >>>> trust_find, trust_show, and may be trust_add. >>>> >>> >>> Why trust-add? >>> >>> I'm not a big fan of cluttering existing commands(find, show, mod) >>> with logic to fix one upgrade bug. But I understand a need to >>> communicate it somehow. >>> >>> Would it make sense to move such logic to a separate command, e.g. >>> trust-check/trust-verify? The command can do additional check in a >>> future. >> No. What is the value of trust-add if it says you 'Trust established and >> verified' while in reality it didn't? This specific issue is very easy >> to catch. >> > Patch attached, patch with warning will land soon. > > Updated patches attached -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0416.2-upgrade-fix-config-of-sidgen-and-extdom-plugins.patch Type: text/x-patch Size: 10744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0417-trusts-use-ipaNTTrustPartner-attribute-to-detect-tru.patch Type: text/x-patch Size: 2650 bytes Desc: not available URL: From tbabej at redhat.com Mon Feb 22 18:56:35 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 22 Feb 2016 19:56:35 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <20160222171455.GT4492@redhat.com> References: <20160222104811.GN4492@redhat.com> <56CB3F82.1070408@redhat.com> <20160222171455.GT4492@redhat.com> Message-ID: <56CB59E3.3010709@redhat.com> On 02/22/2016 06:14 PM, Alexander Bokovoy wrote: > On Mon, 22 Feb 2016, Tomas Babej wrote: >> >> >> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: >>> Hi, >>> >>> attached patch should update compat tree configuration if it exist to >>> follow slapi-nis 0.55 which has support for external members of IPA >>> groups. >>> >>> However, the real work is done in SSSD. These patches are not upstreamed >>> yet. We'll need to bump SSSD dependency in future once they come to >>> distros. >>> >>> >>> >> >> This looks good. >> >> However, the new update file needs to be added to Makefile.am. >> Additionally, patch adds a whitespace error. > Updated patch is attached. > ACK. This should not be pushed until the dependency for SSSD can be bumped. From tbabej at redhat.com Mon Feb 22 19:02:13 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 22 Feb 2016 20:02:13 +0100 Subject: [Freeipa-devel] [PATCH 0416-0417] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56CB5052.5040803@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> <56CB5052.5040803@redhat.com> Message-ID: <56CB5B35.4020709@redhat.com> On 02/22/2016 07:15 PM, Martin Basti wrote: > > > On 22.02.2016 17:05, Martin Basti wrote: >> >> >> On 19.02.2016 15:02, Alexander Bokovoy wrote: >>> On Fri, 19 Feb 2016, Petr Vobornik wrote: >>>> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: >>>>> On Fri, 19 Feb 2016, Martin Basti wrote: >>>>>> WIP patch attached >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5665 >>>>>> >>>>> Comments inline. >>>>> >>>>>> + # we need to run sidgen task >>>>>> + sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >>>>>> + "cn=config") >>>>>> + sidgen_tasks_attr = { >>>>>> + "objectclass": ["top", "extensibleObject"], >>>>>> + "cn": ["sidgen"], >>>>>> + "delay": [0], >>>>>> + "nsslapd-basedn": [self.api.env.basedn], >>>>>> + } >>>>> May be you are better to name this task more uniquely? >>>>> Something like 'cn=generate domain sid,cn=...'? >>>>> >>>>>> + >>>>>> + task_entry = ldap.make_entry(sidgen_task_dn, >>>>>> + **sidgen_tasks_attr) >>>>>> + try: >>>>>> + ldap.add_entry(task_entry) >>>>>> + except errors.DuplicateEntry: >>>>>> + self.log.debug("sidgen task already created") >>>>>> + else: >>>>>> + self.log.debug("sidgen task has been created") >>>>> There could be multiple tasks running in parallel, that's why it could >>>>> be good to use a different and unique name. >>>>> >>>>>> + # we have to check all trusts domains which have been added >>>>>> after the >>>>>> + # upgrade that caused bug was done. >>>>>> + >>>>>> + base_dn = DN(self.api.env.container_adtrusts, >>>>>> self.api.env.basedn) >>>>>> + trust_domain_entries, truncated = ldap.find_entries( >>>>>> + base_dn=base_dn, >>>>>> + scope=ldap.SCOPE_ONELEVEL, >>>>>> + attrs_list=[attr_name, "cn"], >>>>>> + ) >>>>>> + >>>>>> + if truncated: >>>>>> + self.log.warning("update_sids: Search results were >>>>>> truncated") >>>>>> + >>>>>> + for entry in trust_domain_entries: >>>>>> + if entry.single_value[attr_name] is None: >>>>>> + domain = entry.single_value["cn"] >>>>>> + self.log.error( >>>>>> + "Your trust to %s is broken. Please re-create it >>>>>> by " >>>>>> + "running 'ipa trust-add' again", domain) >>>>>> + >>>>>> + sysupgrade.set_upgrade_state('sidgen', 'update_sids', False) >>>>>> + return False, () >>>>> This part looks fine. Basically, a similar check needs to be added to >>>>> trust_find, trust_show, and may be trust_add. >>>>> >>>> >>>> Why trust-add? >>>> >>>> I'm not a big fan of cluttering existing commands(find, show, mod) >>>> with logic to fix one upgrade bug. But I understand a need to >>>> communicate it somehow. >>>> >>>> Would it make sense to move such logic to a separate command, e.g. >>>> trust-check/trust-verify? The command can do additional check in a >>>> future. >>> No. What is the value of trust-add if it says you 'Trust established and >>> verified' while in reality it didn't? This specific issue is very easy >>> to catch. >>> >> Patch attached, patch with warning will land soon. >> >> > Updated patches attached During the RPM upgrade, the ipa-server-upgrade times out and leaves directory server stopped. Issues seem to be fixed after manual DS start&upgrade, but we should get the upgrade during RPM cleanup sorted out to have a seamless experience. Tomas From mbasti at redhat.com Mon Feb 22 19:11:19 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 22 Feb 2016 20:11:19 +0100 Subject: [Freeipa-devel] [PATCH 0416-0418] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56CB5052.5040803@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> <56CB5052.5040803@redhat.com> Message-ID: <56CB5D57.3070300@redhat.com> On 22.02.2016 19:15, Martin Basti wrote: > > > On 22.02.2016 17:05, Martin Basti wrote: >> >> >> On 19.02.2016 15:02, Alexander Bokovoy wrote: >>> On Fri, 19 Feb 2016, Petr Vobornik wrote: >>>> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: >>>>> On Fri, 19 Feb 2016, Martin Basti wrote: >>>>>> WIP patch attached >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5665 >>>>>> >>>>> Comments inline. >>>>> >>>>>> + # we need to run sidgen task >>>>>> + sidgen_task_dn = >>>>>> DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >>>>>> + "cn=config") >>>>>> + sidgen_tasks_attr = { >>>>>> + "objectclass": ["top", "extensibleObject"], >>>>>> + "cn": ["sidgen"], >>>>>> + "delay": [0], >>>>>> + "nsslapd-basedn": [self.api.env.basedn], >>>>>> + } >>>>> May be you are better to name this task more uniquely? >>>>> Something like 'cn=generate domain sid,cn=...'? >>>>> >>>>>> + >>>>>> + task_entry = ldap.make_entry(sidgen_task_dn, >>>>>> + **sidgen_tasks_attr) >>>>>> + try: >>>>>> + ldap.add_entry(task_entry) >>>>>> + except errors.DuplicateEntry: >>>>>> + self.log.debug("sidgen task already created") >>>>>> + else: >>>>>> + self.log.debug("sidgen task has been created") >>>>> There could be multiple tasks running in parallel, that's why it >>>>> could >>>>> be good to use a different and unique name. >>>>> >>>>>> + # we have to check all trusts domains which have been added >>>>>> after the >>>>>> + # upgrade that caused bug was done. >>>>>> + >>>>>> + base_dn = DN(self.api.env.container_adtrusts, >>>>>> self.api.env.basedn) >>>>>> + trust_domain_entries, truncated = ldap.find_entries( >>>>>> + base_dn=base_dn, >>>>>> + scope=ldap.SCOPE_ONELEVEL, >>>>>> + attrs_list=[attr_name, "cn"], >>>>>> + ) >>>>>> + >>>>>> + if truncated: >>>>>> + self.log.warning("update_sids: Search results were >>>>>> truncated") >>>>>> + >>>>>> + for entry in trust_domain_entries: >>>>>> + if entry.single_value[attr_name] is None: >>>>>> + domain = entry.single_value["cn"] >>>>>> + self.log.error( >>>>>> + "Your trust to %s is broken. Please >>>>>> re-create it >>>>>> by " >>>>>> + "running 'ipa trust-add' again", domain) >>>>>> + >>>>>> + sysupgrade.set_upgrade_state('sidgen', 'update_sids', >>>>>> False) >>>>>> + return False, () >>>>> This part looks fine. Basically, a similar check needs to be added to >>>>> trust_find, trust_show, and may be trust_add. >>>>> >>>> >>>> Why trust-add? >>>> >>>> I'm not a big fan of cluttering existing commands(find, show, mod) >>>> with logic to fix one upgrade bug. But I understand a need to >>>> communicate it somehow. >>>> >>>> Would it make sense to move such logic to a separate command, e.g. >>>> trust-check/trust-verify? The command can do additional check in a >>>> future. >>> No. What is the value of trust-add if it says you 'Trust established >>> and >>> verified' while in reality it didn't? This specific issue is very easy >>> to catch. >>> >> Patch attached, patch with warning will land soon. >> >> > Updated patches attached > > I fixed except clause in 416, added patch with user warnings, IMO to have separate search is the cleanest solution here, command is not used often, I would like to avoid any hacks in find and show command Patches attached. I will look on ldapsearch timeouts after restarting DS tomorrow. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0416.3-upgrade-fix-config-of-sidgen-and-extdom-plugins.patch Type: text/x-patch Size: 10741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0417-trusts-use-ipaNTTrustPartner-attribute-to-detect-tru.patch Type: text/x-patch Size: 2650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0418-Warn-user-if-trust-is-broken.patch Type: text/x-patch Size: 3855 bytes Desc: not available URL: From martin at stefany.eu Mon Feb 22 21:13:44 2016 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Mon, 22 Feb 2016 22:13:44 +0100 Subject: [Freeipa-devel] [PATCH 0001] Add new parameter --ssh-update to ipa-client-install Message-ID: <1456175624.5411.4.camel@stefany.eu> Hi, please, review the attached patch which adds --ssh-update to ipa-client- install. Ticket:?https://fedorahosted.org/freeipa/ticket/2655 --- Martin From 4974a57f48a0cd48b83724297ae2af572bc530eb Mon Sep 17 00:00:00 2001 From: Martin Stefany Date: Mon, 22 Feb 2016 20:58:13 +0000 Subject: [PATCH] Add new parameter --ssh-update to ipa-client-install Add a new parameter '--ssh-update' which can be used later after freeipa client is installed to update SSH hostkeys and SSHFP DNS records for host. https://fedorahosted.org/freeipa/ticket/2655 --- ?ipa-client/ipa-install/ipa-client-install | 102 +++++++++++++++++++++++++++++- ?1 file changed, 99 insertions(+), 3 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa- install/ipa-client-install index 789ff591591673744ee3b922e5c0181233ad553c..97adfb6b449fb441bddada89a3b151 33e398ca50 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -71,6 +71,7 @@ CLIENT_INSTALL_ERROR = 1 ?CLIENT_NOT_CONFIGURED = 2 ?CLIENT_ALREADY_CONFIGURED = 3 ?CLIENT_UNINSTALL_ERROR = 4 # error after restoring files/state +CLIENT_SSHUPDATE_ERROR = 5 # error during update of SSH public keys ? ?def parse_options(): ?????def validate_ca_cert_file_option(option, opt, value, parser): @@ -215,6 +216,12 @@ def parse_options(): ???????????????????????????????????????????"be run with --unattended option") ?????parser.add_option_group(uninstall_group) ? +????sshupdate_group = OptionGroup(parser, "SSH key update options") +????sshupdate_group.add_option("--ssh-update", dest="ssh_update", +??????????????????????action="store_true", default=False, +??????????????????????help="update local host's SSH public keys in host entry and DNS.") +????parser.add_option_group(sshupdate_group) + ?????options, args = parser.parse_args() ?????safe_opts = parser.get_safe_opts(options) ? @@ -840,6 +847,92 @@ def uninstall(options, env): ? ?????return rv ? +def sshupdate(options, env): +????if not is_ipa_client_installed(): +????????root_logger.error("IPA client is not configured on this system.") +????????return CLIENT_NOT_CONFIGURED + +????api.bootstrap(context='cli_installer', debug=options.debug) +????api.finalize() +????if 'config_loaded' not in api.env: +????????root_logger.error("Failed to initialize IPA API.") +????????return CLIENT_SSHUPDATE_ERROR + +????# Now, let's try to connect to the server's RPC interface +????connected = False +????try: +????????api.Backend.rpcclient.connect() +????????connected = True +????????root_logger.debug("Try RPC connection") +????????api.Backend.rpcclient.forward('ping') +????except errors.KerberosError as e: +????????if connected: +????????????api.Backend.rpcclient.disconnect() +????????root_logger.info( +????????????"Cannot connect to the server due to Kerberos error: %s. " +????????????"Trying with delegate=True", e) +????????try: +????????????api.Backend.rpcclient.connect(delegate=True) +????????????root_logger.debug("Try RPC connection") +????????????api.Backend.rpcclient.forward('ping') + +????????????root_logger.info("Connection with delegate=True successful") + +????????????# The remote server is not capable of Kerberos S4U2Proxy +????????????# delegation. This features is implemented in IPA server +????????????# version 2.2 and higher +????????????root_logger.warning( +????????????????"Target IPA server has a lower version than the enrolled " +????????????????"client") +????????????root_logger.warning( +????????????????"Some capabilities including the ipa command capability " +????????????????"may not be available") +????????except errors.PublicError as e2: +????????????root_logger.warning( +????????????????"Second connect with delegate=True also failed: %s", e2) +????????????root_logger.error( +????????????????"Cannot connect to the IPA server RPC interface: %s", e2) +????????????return CLIENT_SSHUPDATE_ERROR +????except errors.PublicError as e: +????????root_logger.error( +????????????"Cannot connect to the server due to generic error: %s", e) +????????return CLIENT_SSHUPDATE_ERROR + +????# We need to pull IPA server address from default.conf +????try: +????????parser = RawConfigParser() +????????parser.read(paths.IPA_DEFAULT_CONF) +????????cli_realm = parser.get('global', 'realm') +????????hostname = parser.get('global', 'host') +????# TODO: consult with review team +????# except ConfigParser.NoSectionError as e: +????#?????pass +????# except ConfigParser.ParsingError as e: +????#?????pass +????finally: +????????pass + +????host_principal = 'host/%s@%s' % (hostname, cli_realm) +????# Obtain the TGT. We do it with the temporary krb5.conf, so that +????# only the KDC we're installing under is contacted. +????# Other KDCs might not have replicated the principal yet. +????# Once we have the TGT, it's usable on any server. +????try: +????????ipautil.kinit_keytab(host_principal, paths.KRB5_KEYTAB, +?????????????????????????????CCACHE_FILE, +?????????????????????????????# config=krb_name, +?????????????????????????????attempts=options.kinit_attempts) +????????env['KRB5CCNAME'] = os.environ['KRB5CCNAME'] = CCACHE_FILE +????except Krb5Error as e: +????????print_port_conf_info() +????????root_logger.error("Failed to obtain host TGT: %s" % e) +????????# failure to get ticket makes it impossible to login and bind +????????# from sssd to LDAP, abort installation and rollback changes +????????return CLIENT_INSTALL_ERROR + +????# passing server parameter seems unneccessary, thus passing only "" +????update_ssh_keys("", hostname, services.knownservices.sshd.get_config_dir(), options.create_sshfp) + ?def configure_ipa_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server, hostname): ?????ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") ?????ipaconf.setOptionAssignment(" = ") @@ -2797,7 +2890,7 @@ def install(options, env, fstore, statestore): ?????????????connected = True ?????????????root_logger.debug("Try RPC connection") ?????????????api.Backend.rpcclient.forward('ping') -????????except errors.KerberosError, e: +????????except errors.KerberosError as e: ?????????????if connected: ?????????????????api.Backend.rpcclient.disconnect() ?????????????root_logger.info( @@ -2820,13 +2913,13 @@ def install(options, env, fstore, statestore): ?????????????????root_logger.warning( ?????????????????????"Some capabilities including the ipa command capability " ?????????????????????"may not be available") -????????????except errors.PublicError, e2: +????????????except errors.PublicError as e2: ?????????????????root_logger.warning( ?????????????????????"Second connect with delegate=True also failed: %s", e2) ?????????????????root_logger.error( ?????????????????????"Cannot connect to the IPA server RPC interface: %s", e2) ?????????????????return CLIENT_INSTALL_ERROR -????????except errors.PublicError, e: +????????except errors.PublicError as e: ?????????????root_logger.error( ?????????????????"Cannot connect to the server due to generic error: %s", e) ?????????????return CLIENT_INSTALL_ERROR @@ -3088,6 +3181,9 @@ def main(): ?????if options.uninstall: ?????????return uninstall(options, env) ? +????if options.ssh_update: +????????return sshupdate(options, env) + ?????if is_ipa_client_installed(on_master=options.on_master): ?????????root_logger.error("IPA client is already configured on this system.") ?????????root_logger.info( --? 1.8.3.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ftweedal at redhat.com Tue Feb 23 05:40:06 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 23 Feb 2016 15:40:06 +1000 Subject: [Freeipa-devel] [PATCH 0135] upgrade: unconditional import of certificate profiles into LDAP In-Reply-To: <56CB0735.6080408@redhat.com> References: <56CB0735.6080408@redhat.com> Message-ID: <20160223054006.GI21191@dhcp-40-8.bne.redhat.com> On Mon, Feb 22, 2016 at 02:03:49PM +0100, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5682 > > -- > Martin^3 Babinsky > Thanks for the patch. Conditional ACK. Patch is tested and works, but I am wary about checking for substring match against RemoteRetrieveError reason string (see hunk below). It would be better to carry the status code as an attribute of RemoteRetrieveError and check whether it is 409. > + except errors.RemoteRetrieveError as e: > + if "Profile already exists" in e.reason: > + root_logger.debug("Profile '{}' already present".format( > + profile_id)) > + else: > + root_logger.error("Error migrating profile '{}': {}".format( > + profile_id, e)) > + return If you agree, we can file a ticket and I am happy for these patches to be merged as-is. The scope of changing RemoteRetrieveError is larger than #5682 so it makes sense to do it separately, and just for master branch. Cheers, Fraser From jcholast at redhat.com Tue Feb 23 06:32:31 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Feb 2016 07:32:31 +0100 Subject: [Freeipa-devel] [PATCH 0135] upgrade: unconditional import of certificate profiles into LDAP In-Reply-To: <20160223054006.GI21191@dhcp-40-8.bne.redhat.com> References: <56CB0735.6080408@redhat.com> <20160223054006.GI21191@dhcp-40-8.bne.redhat.com> Message-ID: <56CBFCFF.7000506@redhat.com> On 23.2.2016 06:40, Fraser Tweedale wrote: > On Mon, Feb 22, 2016 at 02:03:49PM +0100, Martin Babinsky wrote: >> https://fedorahosted.org/freeipa/ticket/5682 >> >> -- >> Martin^3 Babinsky >> > Thanks for the patch. Conditional ACK. > > Patch is tested and works, but I am wary about checking for > substring match against RemoteRetrieveError reason string (see hunk > below). It would be better to carry the status code as an attribute > of RemoteRetrieveError and check whether it is 409. > >> + except errors.RemoteRetrieveError as e: >> + if "Profile already exists" in e.reason: >> + root_logger.debug("Profile '{}' already present".format( >> + profile_id)) >> + else: >> + root_logger.error("Error migrating profile '{}': {}".format( >> + profile_id, e)) >> + return > > If you agree, we can file a ticket and I am happy for these patches > to be merged as-is. The scope of changing RemoteRetrieveError is > larger than #5682 so it makes sense to do it separately, and just > for master branch. I don't think this is the right approach. create_profile() should raise DuplicateEntry rather than RemoteRetrieveError if the profile already exists, which can then be properly handled in _create_dogtag_profile(). -- Jan Cholasta From ftweedal at redhat.com Tue Feb 23 06:43:59 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 23 Feb 2016 16:43:59 +1000 Subject: [Freeipa-devel] [PATCH 0135] upgrade: unconditional import of certificate profiles into LDAP In-Reply-To: <56CBFCFF.7000506@redhat.com> References: <56CB0735.6080408@redhat.com> <20160223054006.GI21191@dhcp-40-8.bne.redhat.com> <56CBFCFF.7000506@redhat.com> Message-ID: <20160223064359.GN21191@dhcp-40-8.bne.redhat.com> On Tue, Feb 23, 2016 at 07:32:31AM +0100, Jan Cholasta wrote: > On 23.2.2016 06:40, Fraser Tweedale wrote: > >On Mon, Feb 22, 2016 at 02:03:49PM +0100, Martin Babinsky wrote: > >>https://fedorahosted.org/freeipa/ticket/5682 > >> > >>-- > >>Martin^3 Babinsky > >> > >Thanks for the patch. Conditional ACK. > > > >Patch is tested and works, but I am wary about checking for > >substring match against RemoteRetrieveError reason string (see hunk > >below). It would be better to carry the status code as an attribute > >of RemoteRetrieveError and check whether it is 409. > > > >>+ except errors.RemoteRetrieveError as e: > >>+ if "Profile already exists" in e.reason: > >>+ root_logger.debug("Profile '{}' already present".format( > >>+ profile_id)) > >>+ else: > >>+ root_logger.error("Error migrating profile '{}': {}".format( > >>+ profile_id, e)) > >>+ return > > > >If you agree, we can file a ticket and I am happy for these patches > >to be merged as-is. The scope of changing RemoteRetrieveError is > >larger than #5682 so it makes sense to do it separately, and just > >for master branch. > > I don't think this is the right approach. create_profile() should raise > DuplicateEntry rather than RemoteRetrieveError if the profile already > exists, which can then be properly handled in _create_dogtag_profile(). > I am happy with that. From dkupka at redhat.com Tue Feb 23 08:47:07 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 23 Feb 2016 09:47:07 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CB2629.3010102@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> Message-ID: <56CC1C8B.7050600@redhat.com> On 22/02/16 16:15, Martin Kosek wrote: > On 02/22/2016 04:04 PM, Jan Cholasta wrote: >> On 22.2.2016 15:56, David Kupka wrote: >>> On 22/02/16 07:28, Jan Cholasta wrote: >>>> On 18.2.2016 10:10, David Kupka wrote: >>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>> >>>>>>>>> Thanks for the patch. I've fixed the path in specfile and removed >>>>>>>>> unused import >>>>>>>>> but otherwise it works, ACK. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>> >>>>>>>> Won't this break existing certmonger requests depending on the old >>>>>>>> path? >>>>>>> >>>>>>> It will, I don't see any upgrade code. >>>>>>> >>>>>>>> >>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>> "auditSigningCert >>>>>>>> cert-pki-ca" >>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>> "ocspSigningCert >>>>>>>> cert-pki-ca" >>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>> "subsystemCert >>>>>>>> cert-pki-ca" >>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>> "caSigningCert >>>>>>>> cert-pki-ca" >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>> "Server-Cert >>>>>>>> cert-pki-ca" >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>> RHEL72 >>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) where all >>>>>> the other trackings are stopped and then configured again with the >>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>> >>>>>> Thanks for the catch. >>>>>> >>>>> >>>>> I've updated Timo's patch little more and added >>>>> start_tracking_certificates() for dsinstance and httpinstance. Now the >>>>> upgrade works as expected. >>>> >>>> The way the patches are split is kind of weird and apparently confusing >>>> (see the other thread). IMO there should be 2 patches: the first should >>>> add the ability to change DS and HTTP certmonger config during upgrade >>>> (i.e. the start_tracking_certificates() methods and >>>> certificate_renewal_update() changes), the second should move the >>>> helpers (i.e. the actual move and certificate_renewal_update() version >>>> bump). >>>> >>> Honza, do I understand it correctly that the code is OK but I did not >>> split it to the patches correctly? >> >> Yes. > > Before acking or pushing, can you please explain for me how the upgrade of > certmonger tracking requests work? I want to make sure this is right, so please > bear with me: > > 1) How does it edit existing tracking requests with the new helper paths? > > 2) Does it go and try to edit the requests on every upgrade? Or is there some > check that requests were updated? > > Thanks, > Martin > Whole upgrade of renewal requests is done in ipaserver/install/server/upgrade.py in certificate_renewal_upgrade(). First there is version of requests and if it's the same as in state file upgrade is skipped. Then every request is searched over certmonger's DBus interface and if at least one is not found it means that there was change in request configuration. All tracking requests are then stopped and started again with new configuration. So to answer you questions: 1) By stopping the old request with the old parameters (including path) and starting new with new parameters. 2) Only if version was bumped which happens only if some of the requests changes. -- David Kupka From mbabinsk at redhat.com Tue Feb 23 08:55:12 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 23 Feb 2016 09:55:12 +0100 Subject: [Freeipa-devel] [PATCH 0135] upgrade: unconditional import of certificate profiles into LDAP In-Reply-To: <20160223064359.GN21191@dhcp-40-8.bne.redhat.com> References: <56CB0735.6080408@redhat.com> <20160223054006.GI21191@dhcp-40-8.bne.redhat.com> <56CBFCFF.7000506@redhat.com> <20160223064359.GN21191@dhcp-40-8.bne.redhat.com> Message-ID: <56CC1E70.3030407@redhat.com> On 02/23/2016 07:43 AM, Fraser Tweedale wrote: > On Tue, Feb 23, 2016 at 07:32:31AM +0100, Jan Cholasta wrote: >> On 23.2.2016 06:40, Fraser Tweedale wrote: >>> On Mon, Feb 22, 2016 at 02:03:49PM +0100, Martin Babinsky wrote: >>>> https://fedorahosted.org/freeipa/ticket/5682 >>>> >>>> -- >>>> Martin^3 Babinsky >>>> >>> Thanks for the patch. Conditional ACK. >>> >>> Patch is tested and works, but I am wary about checking for >>> substring match against RemoteRetrieveError reason string (see hunk >>> below). It would be better to carry the status code as an attribute >>> of RemoteRetrieveError and check whether it is 409. >>> >>>> + except errors.RemoteRetrieveError as e: >>>> + if "Profile already exists" in e.reason: >>>> + root_logger.debug("Profile '{}' already present".format( >>>> + profile_id)) >>>> + else: >>>> + root_logger.error("Error migrating profile '{}': {}".format( >>>> + profile_id, e)) >>>> + return >>> >>> If you agree, we can file a ticket and I am happy for these patches >>> to be merged as-is. The scope of changing RemoteRetrieveError is >>> larger than #5682 so it makes sense to do it separately, and just >>> for master branch. >> >> I don't think this is the right approach. create_profile() should raise >> DuplicateEntry rather than RemoteRetrieveError if the profile already >> exists, which can then be properly handled in _create_dogtag_profile(). >> > I am happy with that. > Attaching updated patch. Unfortunately, REST API does report only a super-generic error code 400: Bad request when adding profile which already exists, which is not very useful for us (I will open a ticket for Dogtag for this). After consultation with Jan, we decided to log the error at debug level and be done with it (for the moment). -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0135.1-upgrade-unconditional-import-of-certificate-profiles.patch Type: text/x-patch Size: 2697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0135.1-upgrade-unconditional-import-of-certificate-profiles.patch Type: text/x-patch Size: 2630 bytes Desc: not available URL: From pvoborni at redhat.com Tue Feb 23 09:12:08 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Feb 2016 10:12:08 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0009] WebUI tests fix In-Reply-To: <56C71E61.6090107@redhat.com> References: <56BC5EC0.7000608@redhat.com> <56C2E773.8070304@redhat.com> <56C6E5B9.7020004@redhat.com> <56C71E61.6090107@redhat.com> Message-ID: <56CC2268.8070507@redhat.com> On 02/19/2016 02:53 PM, Lenka Doudova wrote: > > > On 02/19/2016 10:51 AM, Petr Vobornik wrote: >> On 02/16/2016 10:10 AM, Lenka Doudova wrote: >>> >>> >>> On 02/11/2016 11:13 AM, Lenka Doudova wrote: >>>> Hi all, >>>> >>>> most of webUI tests fail with >>>> >>>> AssertionError: Can't click on checkbox label: table.table >>>> Message: Element is not clickable at point (37, 340.3999938964844). >>>> Other element would receive the click: >>>> >>> type="checkbox"> >>>> >>>> >>>> The problem seems to be that the tests attempt to click on a checkbox >>>> label that is no longer there. Since the checkbox is clickable >>>> directly, I changed the code accordingly. Most of the tests should now >>>> proceed successfully. >>>> >>>> Lenka >>>> >>>> >>> >>> Attaching updated patch with minor fix. >>> >>> Lenka >>> >>> >> >> would ACK but the commit message is so generic that it doesn't say >> anything. >> >> Also the description in the mail should be in commit message to be >> usable in a future. > > Fix attached, hope this is better. > > Lenka ACK Pushed to master: a3f8e8e71f95c145cbf2e1917bd71c6bedee11d4 -- Petr Vobornik From mkosek at redhat.com Tue Feb 23 09:14:12 2016 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Feb 2016 10:14:12 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CC1C8B.7050600@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> <56CC1C8B.7050600@redhat.com> Message-ID: <56CC22E4.8040104@redhat.com> On 02/23/2016 09:47 AM, David Kupka wrote: > On 22/02/16 16:15, Martin Kosek wrote: >> On 02/22/2016 04:04 PM, Jan Cholasta wrote: >>> On 22.2.2016 15:56, David Kupka wrote: >>>> On 22/02/16 07:28, Jan Cholasta wrote: >>>>> On 18.2.2016 10:10, David Kupka wrote: >>>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>>> >>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and removed >>>>>>>>>> unused import >>>>>>>>>> but otherwise it works, ACK. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>>> >>>>>>>>> Won't this break existing certmonger requests depending on the old >>>>>>>>> path? >>>>>>>> >>>>>>>> It will, I don't see any upgrade code. >>>>>>>> >>>>>>>>> >>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>> "auditSigningCert >>>>>>>>> cert-pki-ca" >>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>> "ocspSigningCert >>>>>>>>> cert-pki-ca" >>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>> "subsystemCert >>>>>>>>> cert-pki-ca" >>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>> "caSigningCert >>>>>>>>> cert-pki-ca" >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>> "Server-Cert >>>>>>>>> cert-pki-ca" >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>>> RHEL72 >>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) where all >>>>>>> the other trackings are stopped and then configured again with the >>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>>> >>>>>>> Thanks for the catch. >>>>>>> >>>>>> >>>>>> I've updated Timo's patch little more and added >>>>>> start_tracking_certificates() for dsinstance and httpinstance. Now the >>>>>> upgrade works as expected. >>>>> >>>>> The way the patches are split is kind of weird and apparently confusing >>>>> (see the other thread). IMO there should be 2 patches: the first should >>>>> add the ability to change DS and HTTP certmonger config during upgrade >>>>> (i.e. the start_tracking_certificates() methods and >>>>> certificate_renewal_update() changes), the second should move the >>>>> helpers (i.e. the actual move and certificate_renewal_update() version >>>>> bump). >>>>> >>>> Honza, do I understand it correctly that the code is OK but I did not >>>> split it to the patches correctly? >>> >>> Yes. >> >> Before acking or pushing, can you please explain for me how the upgrade of >> certmonger tracking requests work? I want to make sure this is right, so please >> bear with me: >> >> 1) How does it edit existing tracking requests with the new helper paths? >> >> 2) Does it go and try to edit the requests on every upgrade? Or is there some >> check that requests were updated? >> >> Thanks, >> Martin >> > > Whole upgrade of renewal requests is done in > ipaserver/install/server/upgrade.py in certificate_renewal_upgrade(). > > First there is version of requests and if it's the same as in state file > upgrade is skipped. > Then every request is searched over certmonger's DBus interface and if at least > one is not found it means that there was change in request configuration. All > tracking requests are then stopped and started again with new configuration. > > So to answer you questions: > 1) By stopping the old request with the old parameters (including path) and > starting new with new parameters. > > 2) Only if version was bumped which happens only if some of the requests changes. Ah, so IIUC, if you bump the version, requests should be properly updated. The change looks fine then. From pvoborni at redhat.com Tue Feb 23 09:15:39 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Feb 2016 10:15:39 +0100 Subject: [Freeipa-devel] [PATCH] 947 webui: use API call ca_is_enabled instead of enable_ra env variable. In-Reply-To: <56C5DC5F.2010205@redhat.com> References: <569FCBC2.6020100@redhat.com> <56C5DB91.6070202@redhat.com> <56C5DC5F.2010205@redhat.com> Message-ID: <56CC233B.7060403@redhat.com> On 02/18/2016 03:59 PM, Pavel Vomacka wrote: > > > On 02/18/2016 03:56 PM, Petr Vobornik wrote: >> On 01/20/2016 07:02 PM, Petr Vobornik wrote: >>> To be consistent with backend code. >>> >>> https://fedorahosted.org/freeipa/ticket/5622 >>> >>> >> >> bump for review >> > Ack. Pushed to: master: 31f42bc2e1e931b4c7dec9bf89eb94c844397ea2 ipa-4-3: 814f20100dec5f465b23eb051873ede05480b676 > > -- > Pavel^3 Vomacka -- Petr Vobornik From pvoborni at redhat.com Tue Feb 23 09:19:30 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Feb 2016 10:19:30 +0100 Subject: [Freeipa-devel] [PATCH] 946 webui: fixed showing of success message after password change on login In-Reply-To: <56C5DC2C.4010208@redhat.com> References: <569FC71A.2020705@redhat.com> <56C5DB86.60809@redhat.com> <56C5DC2C.4010208@redhat.com> Message-ID: <56CC2422.2020707@redhat.com> On 02/18/2016 03:58 PM, Pavel Vomacka wrote: > > > On 02/18/2016 03:56 PM, Petr Vobornik wrote: >> On 01/20/2016 06:42 PM, Petr Vobornik wrote: >>> similar issue and cause as in >>> https://fedorahosted.org/freeipa/ticket/5567 >>> >>> root cause is that binding triggers validation which clears messages in >>> validation summary. Maybe it could be refactored in a future to not use >>> the same validation summary field for API calls and fields. >>> >>> If you think it is actually ticket #5567 (could be in some point of >>> view) then feel free to push also to 4.2 and 4.3 branch. >>> >>> >> >> bump for review > Ack. Works as expected. Pushed to master: b9c27b672218c30d669d085b5a57045711542fb9 -- Petr Vobornik From jcholast at redhat.com Tue Feb 23 10:00:39 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Feb 2016 11:00:39 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1455895907.6599.104.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> Message-ID: <56CC2DC7.7050006@redhat.com> Hi, On 19.2.2016 16:31, Simo Sorce wrote: > On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: >> On 4.2.2016 18:21, Petr Spacek wrote: >>> On 3.2.2016 18:41, Petr Spacek wrote: >>>> Hello, >>>> >>>> I've updated the design page >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>> >>>> Namely it now contains 'Version 2'. >>> >>> Okay, here is the idea how we can make it flexible: >>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation >> >> Hello, >> >> I'm thinking about LDAP schema for DNS locations. >> >> Purpose >> ======= >> * Allow admins to define any number of locations. >> * 1 DNS server advertises at most 1 location. >> * 1 location generally contains set of services with different priorities and >> weights (in DNS SRV terms). >> * Express server & service priority for each defined location in a way which >> is granular and flexible and ad the same time easy to manage. >> >> >> Proposal >> ======== >> a) Container for locations >> -------------------------- >> cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> >> b) 1 location >> ------------- >> Attributes: >> 2.16.840.1.113730.3.8.5.32 idnsLocationMember >> Server/service assigned to a DNS Location. Usually used to define 'main' >> servers for that location. Should it point to service DNs to be sure we have >> smooth upgrade to containers? Services always live on a host (call it server or not), so IMO it makes sense to point to servers. >> >> 2.16.840.1.113730.3.8.5.33 idnsBackupLocation >> Pointer to another location. Sucks in all servers from that location as one >> group with the same priority. Easy to use with _default location where all >> 'other' servers are used as backup. >> >> These two attributes use sub-type priority and relativeweight. >> This is the only way I could express all the information without need for >> separate objects. I don't see the benefit here. What is wrong with separate objects? Why is it necessary to reinvent the wheel and abuse attribute sub-types for this, losing schema integrity checks provided by DS and making the implementation more complex along the way? >> >> >> Object classes: >> 2.16.840.1.113730.3.8.6.7 idnsLocation >> MAY ( idnsLocationMember $ idnsBackupLocation ) >> >> >> 1st example: >> Location CZ: >> - servers czserver1, czserver2 >> - priority=1 >> - relative weight = 50 % each >> - if both CZ servers fail, use servers in location UK as backup (priority 2) >> - if all CZ and UK servers fail, use servers in location US as backup >> (priority 3) - servers on the other continent are used only as option of last >> resort >> DN: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> objectClass: idnsLocation >> idnsLocationMember;priority1;relativeweight50: >> cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsLocationMember;priority1;relativeweight50: >> cn=czserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> Location UK: >> - servers ukserver1, ukserver2 >> - priority=1 >> - server ukserver1 is a new beefy machine so it can handle 3 times more load >> than ukserver2, thus relative weights 75 % and 25 % >> - if both UK servers fail, use servers in location CZ as backup (priority 2) >> - if all CZ and UK servers fail, use servers in location US as backup >> (priority 3) - servers on the other continent are used only as option of last >> resort >> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> objectClass: idnsLocation >> idnsLocationMember;priority1;relativeweight3: >> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsLocationMember;priority1;relativeweight1: >> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> Location US: >> - servers usserver1, usserver2 >> - priority=1 >> - relative weight = 50 % each >> - if both US servers fail, use servers in location CZ and UK as backup >> (priority 2) - it is over ocean anyway, so US clients will not make any >> difference between CZ and UK locations >> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> objectClass: idnsLocation >> idnsLocationMember;priority1;relativeweight50: >> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsLocationMember;priority1;relativeweight50: >> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> >> Resulting DNS SRV records (generated by FreeIPA framework). Please note that >> only numbers in SRV records matter only relatively. Priorities work as group, >> weights are relative only inside the group. Absolute values above are used >> only in algorithm which generates SRV records: >> Location CZ: >> _kerberos._udp SRV 1 50 czserver1 >> _kerberos._udp SRV 1 50 czserver2 >> _kerberos._udp SRV 2 75 ukserver1 >> _kerberos._udp SRV 2 25 ukserver1 >> _kerberos._udp SRV 3 50 usserver1 >> _kerberos._udp SRV 3 50 usserver2 >> >> Location UK: >> _kerberos._udp SRV 1 75 ukserver1 >> _kerberos._udp SRV 1 25 ukserver1 >> _kerberos._udp SRV 2 50 czserver1 >> _kerberos._udp SRV 2 50 czserver2 >> _kerberos._udp SRV 3 50 usserver1 >> _kerberos._udp SRV 3 50 usserver2 >> >> Location US: >> _kerberos._udp SRV 1 50 usserver1 >> _kerberos._udp SRV 1 50 usserver2 >> _kerberos._udp SRV 2 250 czserver1 >> _kerberos._udp SRV 2 250 czserver2 >> _kerberos._udp SRV 2 375 ukserver1 >> _kerberos._udp SRV 2 125 ukserver1 >> >> >> 2nd example: >> - 10 locations with 4 servers each >> - we want to have use only 1 server from each location as backup so clients >> will not spend a lot of time while attempting to contact cut-off branch (e.g. >> when remote WAN link is down) >> -> use only idnsLocationMember attribute instead of idnsBackupLocation attribute >> >> >> Fancier combinations are possible with this schema. I assume that fancy things >> will be necessary later on if/when IPA supports large topologies. >> >> >> >> c) Assigning DNS servers to locations: >> Each DNS server can advertise at most 1 location as 'default' to its clients. >> >> Attributes: >> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation >> Pointer to a idnsLocation object. On DNS service object / external server. >> Single-valued. IMO this should be attribute of server rather than service, given that idnsLocationMember points to servers rather than services. Or, if there is an actual use case for different DNS services (internal or external) on the same server to reside in different locations, change idnsLocationMember to point to services rather than servers. >> >> Example: >> DN: cn=DNS,cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsAdvertisedLocation: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> When we start integrating with external DNS we will need a special object to >> represent external DNS servers. We can deal with that later on. >> >> >> d) User interface >> This is the hardest thing. >> >> First rough idea can be seen on >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#UI >> >> I would think about CLI when we agree on WebUI, IMHO it will be easier. >> >> >> What do you think? I'm waiting for your comments ;-) > > I am thinking about it, on the surface it all looks quite reasonable. > I think the UI is alittle messy, I wonder if we want to expose lower > level concepts as priority and groups, or if we just want to allow users > to set an order in the UI and then let the framework come up with weight > an priority numbers to assign. +1, it seems to me that locations are a rather standalone concept, so why tie them to DNS like this? > Maybe have a way in the CLI to override the decisions of the framework > and set explicit weights ? -- Jan Cholasta From mbasti at redhat.com Tue Feb 23 11:42:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 12:42:57 +0100 Subject: [Freeipa-devel] [PATCH 0416-0419] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56CB5D57.3070300@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> <56CB5052.5040803@redhat.com> <56CB5D57.3070300@redhat.com> Message-ID: <56CC45C1.1010805@redhat.com> On 22.02.2016 20:11, Martin Basti wrote: > > > On 22.02.2016 19:15, Martin Basti wrote: >> >> >> On 22.02.2016 17:05, Martin Basti wrote: >>> >>> >>> On 19.02.2016 15:02, Alexander Bokovoy wrote: >>>> On Fri, 19 Feb 2016, Petr Vobornik wrote: >>>>> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote: >>>>>> On Fri, 19 Feb 2016, Martin Basti wrote: >>>>>>> WIP patch attached >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/5665 >>>>>>> >>>>>> Comments inline. >>>>>> >>>>>>> + # we need to run sidgen task >>>>>>> + sidgen_task_dn = >>>>>>> DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks," >>>>>>> + "cn=config") >>>>>>> + sidgen_tasks_attr = { >>>>>>> + "objectclass": ["top", "extensibleObject"], >>>>>>> + "cn": ["sidgen"], >>>>>>> + "delay": [0], >>>>>>> + "nsslapd-basedn": [self.api.env.basedn], >>>>>>> + } >>>>>> May be you are better to name this task more uniquely? >>>>>> Something like 'cn=generate domain sid,cn=...'? >>>>>> >>>>>>> + >>>>>>> + task_entry = ldap.make_entry(sidgen_task_dn, >>>>>>> + **sidgen_tasks_attr) >>>>>>> + try: >>>>>>> + ldap.add_entry(task_entry) >>>>>>> + except errors.DuplicateEntry: >>>>>>> + self.log.debug("sidgen task already created") >>>>>>> + else: >>>>>>> + self.log.debug("sidgen task has been created") >>>>>> There could be multiple tasks running in parallel, that's why it >>>>>> could >>>>>> be good to use a different and unique name. >>>>>> >>>>>>> + # we have to check all trusts domains which have been >>>>>>> added >>>>>>> after the >>>>>>> + # upgrade that caused bug was done. >>>>>>> + >>>>>>> + base_dn = DN(self.api.env.container_adtrusts, >>>>>>> self.api.env.basedn) >>>>>>> + trust_domain_entries, truncated = ldap.find_entries( >>>>>>> + base_dn=base_dn, >>>>>>> + scope=ldap.SCOPE_ONELEVEL, >>>>>>> + attrs_list=[attr_name, "cn"], >>>>>>> + ) >>>>>>> + >>>>>>> + if truncated: >>>>>>> + self.log.warning("update_sids: Search results were >>>>>>> truncated") >>>>>>> + >>>>>>> + for entry in trust_domain_entries: >>>>>>> + if entry.single_value[attr_name] is None: >>>>>>> + domain = entry.single_value["cn"] >>>>>>> + self.log.error( >>>>>>> + "Your trust to %s is broken. Please >>>>>>> re-create it >>>>>>> by " >>>>>>> + "running 'ipa trust-add' again", domain) >>>>>>> + >>>>>>> + sysupgrade.set_upgrade_state('sidgen', 'update_sids', >>>>>>> False) >>>>>>> + return False, () >>>>>> This part looks fine. Basically, a similar check needs to be >>>>>> added to >>>>>> trust_find, trust_show, and may be trust_add. >>>>>> >>>>> >>>>> Why trust-add? >>>>> >>>>> I'm not a big fan of cluttering existing commands(find, show, mod) >>>>> with logic to fix one upgrade bug. But I understand a need to >>>>> communicate it somehow. >>>>> >>>>> Would it make sense to move such logic to a separate command, e.g. >>>>> trust-check/trust-verify? The command can do additional check in >>>>> a future. >>>> No. What is the value of trust-add if it says you 'Trust >>>> established and >>>> verified' while in reality it didn't? This specific issue is very easy >>>> to catch. >>>> >>> Patch attached, patch with warning will land soon. >>> >>> >> Updated patches attached >> >> > I fixed except clause in 416, added patch with user warnings, IMO to > have separate search is the cleanest solution here, command is not > used often, I would like to avoid any hacks in find and show command > > Patches attached. > > I will look on ldapsearch timeouts after restarting DS tomorrow. > > Updated patches attached + new patch fixing timeout error -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0416.4-upgrade-fix-config-of-sidgen-and-extdom-plugins.patch Type: text/x-patch Size: 10846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0417.4-trusts-use-ipaNTTrustPartner-attribute-to-detect-tru.patch Type: text/x-patch Size: 2611 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0418.4-Warn-user-if-trust-is-broken.patch Type: text/x-patch Size: 3832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0419.4-fix-upgrade-wait-for-proper-DS-socket-after-DS-resta.patch Type: text/x-patch Size: 1335 bytes Desc: not available URL: From pspacek at redhat.com Tue Feb 23 11:43:17 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Feb 2016 12:43:17 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56CC2DC7.7050006@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> Message-ID: <56CC45D5.6010705@redhat.com> On 23.2.2016 11:00, Jan Cholasta wrote: > Hi, > > On 19.2.2016 16:31, Simo Sorce wrote: >> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: >>> On 4.2.2016 18:21, Petr Spacek wrote: >>>> On 3.2.2016 18:41, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> I've updated the design page >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>> >>>>> Namely it now contains 'Version 2'. >>>> >>>> Okay, here is the idea how we can make it flexible: >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation >>> >>> Hello, >>> >>> I'm thinking about LDAP schema for DNS locations. >>> >>> Purpose >>> ======= >>> * Allow admins to define any number of locations. >>> * 1 DNS server advertises at most 1 location. >>> * 1 location generally contains set of services with different priorities and >>> weights (in DNS SRV terms). >>> * Express server & service priority for each defined location in a way which >>> is granular and flexible and ad the same time easy to manage. >>> >>> >>> Proposal >>> ======== >>> a) Container for locations >>> -------------------------- >>> cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> >>> >>> b) 1 location >>> ------------- >>> Attributes: >>> 2.16.840.1.113730.3.8.5.32 idnsLocationMember >>> Server/service assigned to a DNS Location. Usually used to define 'main' >>> servers for that location. Should it point to service DNs to be sure we have >>> smooth upgrade to containers? > > Services always live on a host (call it server or not), so IMO it makes sense > to point to servers. Fine with me. We just need something which will be able to accommodate containerization without upgrade headache. Do I undestand correctly that 1 container is going to have 1 host object with one service object inside it? Like: cn=container - cn=DNS, cn=container ? >>> 2.16.840.1.113730.3.8.5.33 idnsBackupLocation >>> Pointer to another location. Sucks in all servers from that location as one >>> group with the same priority. Easy to use with _default location where all >>> 'other' servers are used as backup. >>> >>> These two attributes use sub-type priority and relativeweight. >>> This is the only way I could express all the information without need for >>> separate objects. > > I don't see the benefit here. What is wrong with separate objects? Why is it > necessary to reinvent the wheel and abuse attribute sub-types for this, losing > schema integrity checks provided by DS and making the implementation more > complex along the way? AFAIK Simo did not like separate objects because we could not use referential integrity plugin to prune references to removed servers. This can surely be done in framework, I do not insist on subtypes. Talk is cheap, show me your schema :-) >>> Object classes: >>> 2.16.840.1.113730.3.8.6.7 idnsLocation >>> MAY ( idnsLocationMember $ idnsBackupLocation ) >>> >>> >>> 1st example: >>> Location CZ: >>> - servers czserver1, czserver2 >>> - priority=1 >>> - relative weight = 50 % each >>> - if both CZ servers fail, use servers in location UK as backup (priority 2) >>> - if all CZ and UK servers fail, use servers in location US as backup >>> (priority 3) - servers on the other continent are used only as option of last >>> resort >>> DN: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> objectClass: idnsLocation >>> idnsLocationMember;priority1;relativeweight50: >>> cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> idnsLocationMember;priority1;relativeweight50: >>> cn=czserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> idnsBackupLocation;priority2: >>> cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> idnsBackupLocation;priority3: >>> cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> >>> Location UK: >>> - servers ukserver1, ukserver2 >>> - priority=1 >>> - server ukserver1 is a new beefy machine so it can handle 3 times more load >>> than ukserver2, thus relative weights 75 % and 25 % >>> - if both UK servers fail, use servers in location CZ as backup (priority 2) >>> - if all CZ and UK servers fail, use servers in location US as backup >>> (priority 3) - servers on the other continent are used only as option of last >>> resort >>> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> objectClass: idnsLocation >>> idnsLocationMember;priority1;relativeweight3: >>> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> idnsLocationMember;priority1;relativeweight1: >>> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> idnsBackupLocation;priority2: >>> cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> idnsBackupLocation;priority3: >>> cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> >>> Location US: >>> - servers usserver1, usserver2 >>> - priority=1 >>> - relative weight = 50 % each >>> - if both US servers fail, use servers in location CZ and UK as backup >>> (priority 2) - it is over ocean anyway, so US clients will not make any >>> difference between CZ and UK locations >>> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> objectClass: idnsLocation >>> idnsLocationMember;priority1;relativeweight50: >>> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> idnsLocationMember;priority1;relativeweight50: >>> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> idnsBackupLocation;priority2: >>> cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> idnsBackupLocation;priority2: >>> cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> >>> >>> Resulting DNS SRV records (generated by FreeIPA framework). Please note that >>> only numbers in SRV records matter only relatively. Priorities work as group, >>> weights are relative only inside the group. Absolute values above are used >>> only in algorithm which generates SRV records: >>> Location CZ: >>> _kerberos._udp SRV 1 50 czserver1 >>> _kerberos._udp SRV 1 50 czserver2 >>> _kerberos._udp SRV 2 75 ukserver1 >>> _kerberos._udp SRV 2 25 ukserver1 >>> _kerberos._udp SRV 3 50 usserver1 >>> _kerberos._udp SRV 3 50 usserver2 >>> >>> Location UK: >>> _kerberos._udp SRV 1 75 ukserver1 >>> _kerberos._udp SRV 1 25 ukserver1 >>> _kerberos._udp SRV 2 50 czserver1 >>> _kerberos._udp SRV 2 50 czserver2 >>> _kerberos._udp SRV 3 50 usserver1 >>> _kerberos._udp SRV 3 50 usserver2 >>> >>> Location US: >>> _kerberos._udp SRV 1 50 usserver1 >>> _kerberos._udp SRV 1 50 usserver2 >>> _kerberos._udp SRV 2 250 czserver1 >>> _kerberos._udp SRV 2 250 czserver2 >>> _kerberos._udp SRV 2 375 ukserver1 >>> _kerberos._udp SRV 2 125 ukserver1 >>> >>> >>> 2nd example: >>> - 10 locations with 4 servers each >>> - we want to have use only 1 server from each location as backup so clients >>> will not spend a lot of time while attempting to contact cut-off branch (e.g. >>> when remote WAN link is down) >>> -> use only idnsLocationMember attribute instead of idnsBackupLocation >>> attribute >>> >>> >>> Fancier combinations are possible with this schema. I assume that fancy things >>> will be necessary later on if/when IPA supports large topologies. >>> >>> >>> >>> c) Assigning DNS servers to locations: >>> Each DNS server can advertise at most 1 location as 'default' to its clients. >>> >>> Attributes: >>> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation >>> Pointer to a idnsLocation object. On DNS service object / external server. >>> Single-valued. > > IMO this should be attribute of server rather than service, > given that > idnsLocationMember points to servers rather than services. The main reason is why idnsAdvertisedLocation is tied to DNS service is that a IPA server without a DNS server cannot advertise anything, so the attribute does not make sense on all server objects. Also, the attribute can be (in future) used on external DNS server. The external server is not going to be an IPA server, it will be just representation of a DNS endpoint. Likely this external DNS server is not going to reside in cn=masters at all. It might be in cn=dns so somewhere else. So it seemed to me that it would be good to tie this to 'DNS endpoint' object instead of IPA server object. Anyway, I do not insist on this. It can be on the IPA server if you want, but we will need additional checks to make sure that DNS service is always present on the IPA server in question. Negotiate with Simo :-) An alternative is to add idnsAdvertisedLocation to location object but then we need extra search to find out which location is advertised by particular server (or use yet another instance of memberOf plugin ...). > Or, if there is an actual use case for different DNS services (internal or > external) on the same server to reside in different locations, change > idnsLocationMember to point to services rather than servers. > >>> >>> Example: >>> DN: cn=DNS,cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> idnsAdvertisedLocation: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>> >>> When we start integrating with external DNS we will need a special object to >>> represent external DNS servers. We can deal with that later on. >>> >>> >>> d) User interface >>> This is the hardest thing. >>> >>> First rough idea can be seen on >>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#UI >>> >>> I would think about CLI when we agree on WebUI, IMHO it will be easier. >>> >>> >>> What do you think? I'm waiting for your comments ;-) >> >> I am thinking about it, on the surface it all looks quite reasonable. >> I think the UI is alittle messy, I wonder if we want to expose lower >> level concepts as priority and groups, or if we just want to allow users >> to set an order in the UI and then let the framework come up with weight >> an priority numbers to assign. > > +1, it seems to me that locations are a rather standalone concept, so why tie > them to DNS like this? I do not see the tie to DNS in the user interface except the terminology I used. Priority (grouping) and weights (load distribution inside one group) are not DNS things, these are fail-over and load balancing concepts. Look at manual for load balancers from F5 [1]: * term 'pool' = same thing as our 'priority groups', i.e. group of services with equal priority * term 'weight' (sometimes also 'ratio weight') = the exactly same sense I'm certainly open to terminological changes to make it more accessible, it would make sense to use the same terms as load balancer vendors. [1] https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html >> Maybe have a way in the CLI to override the decisions of the framework >> and set explicit weights ? I was thinking about this as well. Speaking of weights, we can easily default to the same weight for all servers by default so admins do not need to bother unless they want/need. Priority groups are harder because they express metric based on: * communication costs, * fail-over requirements, * other political requirements in given deployment. These are hard things to see from layer 7. Theoretically we can provide ipa-advise plugin to generate some initial set of groups but this is going to be complicated and error prone. E.g. we can use ICMP ping or LDAP base DN search timings and use some clustering algorithm to create priority groups using measured values. This could work if we use some smart-enough clustering algorithm (= AI library). And of course, we would have to do measurements from at least one server in each location to properly define groups for each location ... It is not that easy as it might seem and I do not see an easy solution. Maybe we should take evolutional approach: Implement this 'expert' UI which exposes groups & weights to the user first. (It will be necessary for special cases anyway.) When this is done, we can play with it, do some usability testing (we can ask RH IT to see if it makes sense to them, for example.) Later we can extend this with a 'simple' variant of UI based on feedback or add the generator). This does not even need to happen in the same release. IMHO it would be better to start with something and refine it later on because right now we are just hand-waving and have no idea what users actually do and want. -- Petr^2 Spacek From abokovoy at redhat.com Tue Feb 23 12:02:49 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 23 Feb 2016 14:02:49 +0200 Subject: [Freeipa-devel] [PATCH 0416-0419] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56CC45C1.1010805@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> <56CB5052.5040803@redhat.com> <56CB5D57.3070300@redhat.com> <56CC45C1.1010805@redhat.com> Message-ID: <20160223120249.GG4492@redhat.com> On Tue, 23 Feb 2016, Martin Basti wrote: >From f2ae1bd129a1741500d2f3dcb86a0da553604d15 Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Tue, 23 Feb 2016 10:37:47 +0100 >Subject: [PATCH 4/4] fix upgrade: wait for proper DS socket after DS restart > >Restarting DS executed by upgrade plugin causes that upgrade frameworg >was waiting for not proper socket to be ready. This commit fix issue. Please fix the commit message typos. -- / Alexander Bokovoy From mbasti at redhat.com Tue Feb 23 12:25:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 13:25:00 +0100 Subject: [Freeipa-devel] [PATCH 0416-0419] fix broken configuration of sidgen and extdom plugins In-Reply-To: <20160223120249.GG4492@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> <56CB5052.5040803@redhat.com> <56CB5D57.3070300@redhat.com> <56CC45C1.1010805@redhat.com> <20160223120249.GG4492@redhat.com> Message-ID: <56CC4F9C.5040705@redhat.com> On 23.02.2016 13:02, Alexander Bokovoy wrote: > On Tue, 23 Feb 2016, Martin Basti wrote: >> From f2ae1bd129a1741500d2f3dcb86a0da553604d15 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Tue, 23 Feb 2016 10:37:47 +0100 >> Subject: [PATCH 4/4] fix upgrade: wait for proper DS socket after DS >> restart >> >> Restarting DS executed by upgrade plugin causes that upgrade frameworg >> was waiting for not proper socket to be ready. This commit fix issue. > Please fix the commit message typos. > Fixed. Updated patches attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0416.5-upgrade-fix-config-of-sidgen-and-extdom-plugins.patch Type: text/x-patch Size: 10846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0417.5-trusts-use-ipaNTTrustPartner-attribute-to-detect-tru.patch Type: text/x-patch Size: 2611 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0418.5-Warn-user-if-trust-is-broken.patch Type: text/x-patch Size: 3832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0419.5-fix-upgrade-wait-for-proper-DS-socket-after-DS-resta.patch Type: text/x-patch Size: 1408 bytes Desc: not available URL: From dkupka at redhat.com Tue Feb 23 13:33:22 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 23 Feb 2016 14:33:22 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CC22E4.8040104@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> <56CC1C8B.7050600@redhat.com> <56CC22E4.8040104@redhat.com> Message-ID: <56CC5FA2.8030004@redhat.com> On 23/02/16 10:14, Martin Kosek wrote: > On 02/23/2016 09:47 AM, David Kupka wrote: >> On 22/02/16 16:15, Martin Kosek wrote: >>> On 02/22/2016 04:04 PM, Jan Cholasta wrote: >>>> On 22.2.2016 15:56, David Kupka wrote: >>>>> On 22/02/16 07:28, Jan Cholasta wrote: >>>>>> On 18.2.2016 10:10, David Kupka wrote: >>>>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>>>> >>>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and removed >>>>>>>>>>> unused import >>>>>>>>>>> but otherwise it works, ACK. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>>>> >>>>>>>>>> Won't this break existing certmonger requests depending on the old >>>>>>>>>> path? >>>>>>>>> >>>>>>>>> It will, I don't see any upgrade code. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>> "auditSigningCert >>>>>>>>>> cert-pki-ca" >>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>> "ocspSigningCert >>>>>>>>>> cert-pki-ca" >>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>> "subsystemCert >>>>>>>>>> cert-pki-ca" >>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>> "caSigningCert >>>>>>>>>> cert-pki-ca" >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>> "Server-Cert >>>>>>>>>> cert-pki-ca" >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>>>> RHEL72 >>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) where all >>>>>>>> the other trackings are stopped and then configured again with the >>>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>>>> >>>>>>>> Thanks for the catch. >>>>>>>> >>>>>>> >>>>>>> I've updated Timo's patch little more and added >>>>>>> start_tracking_certificates() for dsinstance and httpinstance. Now the >>>>>>> upgrade works as expected. >>>>>> >>>>>> The way the patches are split is kind of weird and apparently confusing >>>>>> (see the other thread). IMO there should be 2 patches: the first should >>>>>> add the ability to change DS and HTTP certmonger config during upgrade >>>>>> (i.e. the start_tracking_certificates() methods and >>>>>> certificate_renewal_update() changes), the second should move the >>>>>> helpers (i.e. the actual move and certificate_renewal_update() version >>>>>> bump). >>>>>> >>>>> Honza, do I understand it correctly that the code is OK but I did not >>>>> split it to the patches correctly? >>>> >>>> Yes. >>> >>> Before acking or pushing, can you please explain for me how the upgrade of >>> certmonger tracking requests work? I want to make sure this is right, so please >>> bear with me: >>> >>> 1) How does it edit existing tracking requests with the new helper paths? >>> >>> 2) Does it go and try to edit the requests on every upgrade? Or is there some >>> check that requests were updated? >>> >>> Thanks, >>> Martin >>> >> >> Whole upgrade of renewal requests is done in >> ipaserver/install/server/upgrade.py in certificate_renewal_upgrade(). >> >> First there is version of requests and if it's the same as in state file >> upgrade is skipped. >> Then every request is searched over certmonger's DBus interface and if at least >> one is not found it means that there was change in request configuration. All >> tracking requests are then stopped and started again with new configuration. >> >> So to answer you questions: >> 1) By stopping the old request with the old parameters (including path) and >> starting new with new parameters. >> >> 2) Only if version was bumped which happens only if some of the requests changes. > > Ah, so IIUC, if you bump the version, requests should be properly updated. The > change looks fine then. > After discussion with Honza, we decided to drop the part comparing only base names of pre- and post-save commands and use it as whole. I've also split the patches so it's obvious what is going on. Patches should be applied in this order: freeipa-dkupka-0091.0 freeipa-dkupka-0087.1 freeipa-dkupka-0088.1 freeipa-tjaalton-0011.2 freeipa-dkupka-0092.0 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0087.1-dsinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 4240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0088.1-httpinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 3767 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0091.0-upgrade-Match-whole-pre-post-command-not-just-basena.patch Type: text/x-patch Size: 4115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0092.0-upgrade-Bump-certificate-tracking-requests-version.patch Type: text/x-patch Size: 866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0011.2-Move-freeipa-certmonger-helpers-to-libexecdir.patch Type: text/x-patch Size: 5557 bytes Desc: not available URL: From amarecek at redhat.com Tue Feb 23 14:02:08 2016 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Tue, 23 Feb 2016 09:02:08 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin In-Reply-To: <1618888650.32803170.1456145983381.JavaMail.zimbra@redhat.com> References: <1415364427.17513799.1453733845873.JavaMail.zimbra@redhat.com> <1464040446.19836563.1455196912586.JavaMail.zimbra@redhat.com> <1618888650.32803170.1456145983381.JavaMail.zimbra@redhat.com> Message-ID: <1411609333.26185776.1456236128153.JavaMail.zimbra@redhat.com> NACK. Some little changes still required: * fixing the pep8 errors * fixing the wrong comment [root at master2 freeipa]# pep8 ipatests/test_xmlrpc/test_sudocmd_plugin.py ipatests/test_xmlrpc/test_sudocmd_plugin.py:94:80: E501 line too long (87 > 79 characters) ipatests/test_xmlrpc/test_sudocmd_plugin.py:97:80: E501 line too long (87 > 79 characters) ipatests/test_xmlrpc/test_sudocmd_plugin.py:134:80: E501 line too long (80 > 79 characters) [root at master2 freeipa]# pep8 ipatests/test_xmlrpc/tracker/sudocmd_plugin.py ipatests/test_xmlrpc/tracker/sudocmd_plugin.py:14:80: E501 line too long (81 > 79 characters) [root at master2 freeipa]# grep 'Class for' ipatests/test_xmlrpc/tracker/sudocmd_plugin.py """ Class for host plugin like tests """ ----- Original Message ----- > From: "Filip Skola" > To: "Ale? Mare?ek" > Cc: freeipa-devel at redhat.com, "Milan Kub?k" > Sent: Monday, February 22, 2016 1:59:43 PM > Subject: Re: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin > > Hi, > > sudocmd tracker has been created. > > Filip > > ----- Original Message ----- > > NACK. > > > > "create_sudocmd" and "delete_sudocmd" should be placed in Tracker. So this > > patch should create the tracker as well. > > > > ----- Original Message ----- > > > From: "Filip Skola" > > > To: freeipa-devel at redhat.com > > > Sent: Monday, January 25, 2016 3:57:25 PM > > > Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin > > > > > > Hello, > > > > > > attaching refactored sudocmd_plugin. > > > > > > Filip > > > -- > > > 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 simo at redhat.com Tue Feb 23 14:19:18 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 23 Feb 2016 09:19:18 -0500 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56CC45D5.6010705@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> Message-ID: <1456237158.6599.193.camel@redhat.com> On Tue, 2016-02-23 at 12:43 +0100, Petr Spacek wrote: > On 23.2.2016 11:00, Jan Cholasta wrote: > > Hi, > > > > On 19.2.2016 16:31, Simo Sorce wrote: > >> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: > >>> On 4.2.2016 18:21, Petr Spacek wrote: > >>>> On 3.2.2016 18:41, Petr Spacek wrote: > >>>>> Hello, > >>>>> > >>>>> I've updated the design page > >>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism > >>>>> > >>>>> Namely it now contains 'Version 2'. > >>>> > >>>> Okay, here is the idea how we can make it flexible: > >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation > >>> > >>> Hello, > >>> > >>> I'm thinking about LDAP schema for DNS locations. > >>> > >>> Purpose > >>> ======= > >>> * Allow admins to define any number of locations. > >>> * 1 DNS server advertises at most 1 location. > >>> * 1 location generally contains set of services with different priorities and > >>> weights (in DNS SRV terms). > >>> * Express server & service priority for each defined location in a way which > >>> is granular and flexible and ad the same time easy to manage. > >>> > >>> > >>> Proposal > >>> ======== > >>> a) Container for locations > >>> -------------------------- > >>> cn=locations,cn=ipa,cn=etc,dc=example,dc=com > >>> > >>> > >>> b) 1 location > >>> ------------- > >>> Attributes: > >>> 2.16.840.1.113730.3.8.5.32 idnsLocationMember > >>> Server/service assigned to a DNS Location. Usually used to define 'main' > >>> servers for that location. Should it point to service DNs to be sure we have > >>> smooth upgrade to containers? > > > > Services always live on a host (call it server or not), so IMO it makes sense > > to point to servers. > > Fine with me. We just need something which will be able to accommodate > containerization without upgrade headache. > > Do I undestand correctly that 1 container is going to have 1 host object with > one service object inside it? > > Like: > cn=container > - cn=DNS, cn=container > ? Do we think we will ever need to define different locations on a per service basis ? We based or hypothesis on the fact we only have one location and at most different weights per services ? Is there anything in here that will make it hard for us should we change our mind in future ? (I think the single _tcp DNAME may be an architectural issue anyway, but that could be resolved perhaps by moving the location DNAME on a per service basis in future should we need it ? > >>> 2.16.840.1.113730.3.8.5.33 idnsBackupLocation > >>> Pointer to another location. Sucks in all servers from that location as one > >>> group with the same priority. Easy to use with _default location where all > >>> 'other' servers are used as backup. > >>> > >>> These two attributes use sub-type priority and relativeweight. > >>> This is the only way I could express all the information without need for > >>> separate objects. > > > > I don't see the benefit here. What is wrong with separate objects? Why is it > > necessary to reinvent the wheel and abuse attribute sub-types for this, losing > > schema integrity checks provided by DS and making the implementation more > > complex along the way? > > AFAIK Simo did not like separate objects because we could not use referential > integrity plugin to prune references to removed servers. > > This can surely be done in framework, I do not insist on subtypes. > > > Talk is cheap, show me your schema :-) I had a preference, but I m ok also with multiplle objects one per server/service if we think this will make things easier to handle. Given we are going to need a Server object in DNS anyway (so that things are self contained for non IPA use cases) then I think the referential integrity thing goes out the window. [...] > >>> Attributes: > >>> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation > >>> Pointer to a idnsLocation object. On DNS service object / external server. > >>> Single-valued. > > > > IMO this should be attribute of server rather than service, > > given that > > idnsLocationMember points to servers rather than services. > > The main reason is why idnsAdvertisedLocation is tied to DNS service is that a > IPA server without a DNS server cannot advertise anything, so the attribute > does not make sense on all server objects. > > Also, the attribute can be (in future) used on external DNS server. The > external server is not going to be an IPA server, it will be just > representation of a DNS endpoint. Likely this external DNS server is not going > to reside in cn=masters at all. It might be in cn=dns so somewhere else. If possible I'd tie it to the DNS server's DNS object, or a new object in the DNS hierarchy. We may want to have locations for servers that are not IPA Server at all, like the preferred local XMPP server or other things like that. > So it seemed to me that it would be good to tie this to 'DNS endpoint' object > instead of IPA server object. > > Anyway, I do not insist on this. It can be on the IPA server if you want, but > we will need additional checks to make sure that DNS service is always present > on the IPA server in question. Negotiate with Simo :-) > > An alternative is to add idnsAdvertisedLocation to location object but then we > need extra search to find out which location is advertised by particular > server (or use yet another instance of memberOf plugin ...). We can put this on the location object, but what object would it point to ? The search is relatively easy if we can use the dereference control, no need for memberof tricks. > >> I am thinking about it, on the surface it all looks quite reasonable. > >> I think the UI is alittle messy, I wonder if we want to expose lower > >> level concepts as priority and groups, or if we just want to allow users > >> to set an order in the UI and then let the framework come up with weight > >> an priority numbers to assign. > > > > +1, it seems to me that locations are a rather standalone concept, so why tie > > them to DNS like this? > > I do not see the tie to DNS in the user interface except the terminology I used. > > Priority (grouping) and weights (load distribution inside one group) are not > DNS things, these are fail-over and load balancing concepts. > > Look at manual for load balancers from F5 [1]: > * term 'pool' = same thing as our 'priority groups', i.e. group of services > with equal priority > * term 'weight' (sometimes also 'ratio weight') = the exactly same sense > > I'm certainly open to terminological changes to make it more accessible, it > would make sense to use the same terms as load balancer vendors. Ack, my concern was not with terminology though, but with exposing users to the concept themselves, I was thinking we might want a simpler interface for the UI with limited ability to just define pools by default. However if we think that both pools and weights will be necessary for common administration I am ok exposing them. > [1] > https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html > > > >> Maybe have a way in the CLI to override the decisions of the framework > >> and set explicit weights ? > > I was thinking about this as well. > > Speaking of weights, we can easily default to the same weight for all servers > by default so admins do not need to bother unless they want/need. I was thinking that an UI that exposes ordering (by moving entries around up and down a list) would make things simpler, the framework would calculate a weight based on the order. However I am aware that a simple list cannot express concepts like 1 server being equal weight as 2 others, so perhaps we shouldn't go down this route ? > Priority groups are harder because they express metric based on: > * communication costs, > * fail-over requirements, > * other political requirements in given deployment. > These are hard things to see from layer 7. > > Theoretically we can provide ipa-advise plugin to generate some initial set of > groups but this is going to be complicated and error prone. > > E.g. we can use ICMP ping or LDAP base DN search timings and use some > clustering algorithm to create priority groups using measured values. > This could work if we use some smart-enough clustering algorithm (= AI > library). And of course, we would have to do measurements from at least one > server in each location to properly define groups for each location ... > > It is not that easy as it might seem and I do not see an easy solution. > > > Maybe we should take evolutional approach: > Implement this 'expert' UI which exposes groups & weights to the user first. > (It will be necessary for special cases anyway.) When this is done, we can > play with it, do some usability testing (we can ask RH IT to see if it makes > sense to them, for example.) > > Later we can extend this with a 'simple' variant of UI based on feedback or > add the generator). This does not even need to happen in the same release. > > IMHO it would be better to start with something and refine it later on because > right now we are just hand-waving and have no idea what users actually do and > want. As long as we establish a proper CLI I am ok with implementing a very bare bone UI first and improving it only later. Btw we probably want to have this information reported by the topology view, and used to automatically group servers there based on location, so I CCed Petr to see if there is anything that would make that job easier/harder. Simo. -- Simo Sorce * Red Hat, Inc * New York From ldoudova at redhat.com Tue Feb 23 14:20:13 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Tue, 23 Feb 2016 15:20:13 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0010] WebUI tests - ID views Message-ID: <56CC6A9D.5060309@redhat.com> Hi, attached is patch providing missing test coverage for ID views in webUI. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0010-WebUI-test-ID-views.patch Type: text/x-patch Size: 8816 bytes Desc: not available URL: From jcholast at redhat.com Tue Feb 23 14:46:35 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Feb 2016 15:46:35 +0100 Subject: [Freeipa-devel] [PATCH] 0048 Decode HTTP reason phrase as iso-8859-1 In-Reply-To: <5695F8FB.80801@redhat.com> References: <20160106042631.GJ31821@dhcp-40-8.bne.redhat.com> <568E0C0F.9060401@redhat.com> <20160107100051.GS31821@dhcp-40-8.bne.redhat.com> <20160108105616.GZ31821@dhcp-40-8.bne.redhat.com> <5695F8FB.80801@redhat.com> Message-ID: <56CC70CB.6070507@redhat.com> On 13.1.2016 08:12, Jan Cholasta wrote: > On 8.1.2016 11:56, Fraser Tweedale wrote: >> On Thu, Jan 07, 2016 at 08:00:51PM +1000, Fraser Tweedale wrote: >>> On Thu, Jan 07, 2016 at 07:56:15AM +0100, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 6.1.2016 05:26, Fraser Tweedale wrote: >>>>> Happy new year, all. >>>>> >>>>> The attached patch fixes a unicode decode error triggered in some >>>>> locales, which causes failure of installation (and probably other >>>>> oprations, if locale is changed under an existing server). >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5578 >>>> >>>> It seems like this fixes only part of the issue - the installer >>>> won't crash >>>> anymore. But what happens if the reason phrase uses characters which >>>> are not >>>> in iso-8859-1 (e.g. "?", a character commonly used in Czech)? >>>> Shouldn't we >>>> always specify the encoding in requests, so that Dogtag does not >>>> have to >>>> guess? >>>> >>> In this case it will not throw an exception, but it will decode >>> nonsense. However, in my investigation just now of how Tomcat >>> decides what to send in the reason phrase, it turns out that in >>> future releases they will not send a reason phrase[1] at all! >>> >>> [1] >>> https://github.com/apache/tomcat/commit/707ab1c77f3bc189e1c3f29b641506db4c8bce37 >>> >>> >>> (Nice to know about this in advance - I will not be surprised if >>> some clients break) >>> >>> I'll cut a new patch tomorrow that just ignores the reason phrase >>> rather than trying to decode and log it. All the info is in the >>> status code, after all. >>> >>> Thanks for reviewing, >>> Fraser >>> >> Promised new patch attached - removes the reason phrase and updates >> call sites accordingly. > > Thanks, ACK. > > Pushed to master: fe94222873c4df5118e93cebe7e9d69439266ba0 and to: ipa-4-2: 0aedaf10e1e3fe48df5f57ad0f25c80b91c2eb45 ipa-4-3: 45f7762a9229ff867700432413c434e61fdddc0d -- Jan Cholasta From mbasti at redhat.com Tue Feb 23 15:24:21 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 16:24:21 +0100 Subject: [Freeipa-devel] [PATCH 0006] Refactor test_hostgroup_plugin In-Reply-To: <991418926.1327028.1450781870579.JavaMail.zimbra@redhat.com> References: <991418926.1327028.1450781870579.JavaMail.zimbra@redhat.com> Message-ID: <56CC79A5.6010809@redhat.com> On 22.12.2015 11:57, Filip Skola wrote: > And also sending refactored hostgroup plugin test. > > F > > bump for review -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Feb 23 15:25:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 16:25:03 +0100 Subject: [Freeipa-devel] [PATCH] 811 performance: faster DN implementation In-Reply-To: <56797344.3000108@redhat.com> References: <551A72DB.3020105@redhat.com> <551D11C2.4070902@redhat.com> <552668E0.4050601@redhat.com> <5527AFEF.3060704@redhat.com> <552CC294.6030908@redhat.com> <552D4F3A.90705@redhat.com> <56797344.3000108@redhat.com> Message-ID: <56CC79CF.9090406@redhat.com> On 22.12.2015 16:59, Petr Spacek wrote: > On 14.4.2015 19:32, Petr Vobornik wrote: >> Pushed to master: 11bd9d96f191066f7ba760549f00179c128a9787 >> >>> Please be so kind and fix naming. AFAIK the patch refers to 'openldap' DN >>> format but in fact it is python-ldap-ishm. It will surely confuse next >>> generation of FreeIPA developers :-) >>> >> Will be in separate patch. > Petr, Santa found out that you did not send the patch! You are risking > Christmas without any presents ... :-) > Bump for patch. From mbasti at redhat.com Tue Feb 23 15:34:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 16:34:58 +0100 Subject: [Freeipa-devel] [PATCH 0012] Use HTTPD_USER in dogtaginstance.py In-Reply-To: <569E309B.5090007@redhat.com> References: <569E309B.5090007@redhat.com> Message-ID: <56CC7C22.9000006@redhat.com> On 19.01.2016 13:48, David Kupka wrote: > I've converted the diff attached to #5587 by Timo Aaltonen. > Works for me, ACK. > > https://fedorahosted.org/freeipa/ticket/5587 > > Patch has been pushed to master, original email is probably lost. 67c367d0db194d9afa56ecda34dafb46758d99b5 Use HTTPD_USER in dogtaginstance.py Also patch had not been pushed to ipa-4-3, fixed: Pushed to ipa-4-3: 073fdeb57465044bbce981672027253c2dd44c0f -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Feb 23 15:37:07 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Feb 2016 16:37:07 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1455895907.6599.104.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> Message-ID: <56CC7CA3.6040807@redhat.com> On 02/19/2016 04:31 PM, Simo Sorce wrote: > On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: >> On 4.2.2016 18:21, Petr Spacek wrote: >>> On 3.2.2016 18:41, Petr Spacek wrote: >>>> Hello, >>>> >>>> I've updated the design page >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>> >>>> Namely it now contains 'Version 2'. >>> >>> Okay, here is the idea how we can make it flexible: >>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation >> >> Hello, >> >> I'm thinking about LDAP schema for DNS locations. >> >> Purpose >> ======= >> * Allow admins to define any number of locations. >> * 1 DNS server advertises at most 1 location. >> * 1 location generally contains set of services with different priorities and >> weights (in DNS SRV terms). >> * Express server & service priority for each defined location in a way which >> is granular and flexible and ad the same time easy to manage. >> >> >> Proposal >> ======== >> a) Container for locations >> -------------------------- >> cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> >> b) 1 location >> ------------- >> Attributes: >> 2.16.840.1.113730.3.8.5.32 idnsLocationMember >> Server/service assigned to a DNS Location. Usually used to define 'main' >> servers for that location. Should it point to service DNs to be sure we have >> smooth upgrade to containers? >> >> 2.16.840.1.113730.3.8.5.33 idnsBackupLocation >> Pointer to another location. Sucks in all servers from that location as one >> group with the same priority. Easy to use with _default location where all >> 'other' servers are used as backup. >> >> These two attributes use sub-type priority and relativeweight. >> This is the only way I could express all the information without need for >> separate objects. >> >> >> Object classes: >> 2.16.840.1.113730.3.8.6.7 idnsLocation >> MAY ( idnsLocationMember $ idnsBackupLocation ) >> >> >> 1st example: >> Location CZ: >> - servers czserver1, czserver2 >> - priority=1 >> - relative weight = 50 % each >> - if both CZ servers fail, use servers in location UK as backup (priority 2) >> - if all CZ and UK servers fail, use servers in location US as backup >> (priority 3) - servers on the other continent are used only as option of last >> resort >> DN: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> objectClass: idnsLocation >> idnsLocationMember;priority1;relativeweight50: >> cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsLocationMember;priority1;relativeweight50: >> cn=czserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> Location UK: >> - servers ukserver1, ukserver2 >> - priority=1 >> - server ukserver1 is a new beefy machine so it can handle 3 times more load >> than ukserver2, thus relative weights 75 % and 25 % >> - if both UK servers fail, use servers in location CZ as backup (priority 2) >> - if all CZ and UK servers fail, use servers in location US as backup >> (priority 3) - servers on the other continent are used only as option of last >> resort >> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> objectClass: idnsLocation >> idnsLocationMember;priority1;relativeweight3: >> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsLocationMember;priority1;relativeweight1: >> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> Location US: >> - servers usserver1, usserver2 >> - priority=1 >> - relative weight = 50 % each >> - if both US servers fail, use servers in location CZ and UK as backup >> (priority 2) - it is over ocean anyway, so US clients will not make any >> difference between CZ and UK locations >> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> objectClass: idnsLocation >> idnsLocationMember;priority1;relativeweight50: >> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsLocationMember;priority1;relativeweight50: >> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> >> Resulting DNS SRV records (generated by FreeIPA framework). Please note that >> only numbers in SRV records matter only relatively. Priorities work as group, >> weights are relative only inside the group. Absolute values above are used >> only in algorithm which generates SRV records: >> Location CZ: >> _kerberos._udp SRV 1 50 czserver1 >> _kerberos._udp SRV 1 50 czserver2 >> _kerberos._udp SRV 2 75 ukserver1 >> _kerberos._udp SRV 2 25 ukserver1 >> _kerberos._udp SRV 3 50 usserver1 >> _kerberos._udp SRV 3 50 usserver2 >> >> Location UK: >> _kerberos._udp SRV 1 75 ukserver1 >> _kerberos._udp SRV 1 25 ukserver1 >> _kerberos._udp SRV 2 50 czserver1 >> _kerberos._udp SRV 2 50 czserver2 >> _kerberos._udp SRV 3 50 usserver1 >> _kerberos._udp SRV 3 50 usserver2 >> >> Location US: >> _kerberos._udp SRV 1 50 usserver1 >> _kerberos._udp SRV 1 50 usserver2 >> _kerberos._udp SRV 2 250 czserver1 >> _kerberos._udp SRV 2 250 czserver2 >> _kerberos._udp SRV 2 375 ukserver1 >> _kerberos._udp SRV 2 125 ukserver1 >> >> >> 2nd example: >> - 10 locations with 4 servers each >> - we want to have use only 1 server from each location as backup so clients >> will not spend a lot of time while attempting to contact cut-off branch (e.g. >> when remote WAN link is down) >> -> use only idnsLocationMember attribute instead of idnsBackupLocation attribute >> >> >> Fancier combinations are possible with this schema. I assume that fancy things >> will be necessary later on if/when IPA supports large topologies. >> >> >> >> c) Assigning DNS servers to locations: >> Each DNS server can advertise at most 1 location as 'default' to its clients. >> >> Attributes: >> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation >> Pointer to a idnsLocation object. On DNS service object / external server. >> Single-valued. >> >> Example: >> DN: cn=DNS,cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> idnsAdvertisedLocation: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com >> >> When we start integrating with external DNS we will need a special object to >> represent external DNS servers. We can deal with that later on. >> >> >> d) User interface >> This is the hardest thing. >> >> First rough idea can be seen on >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#UI >> >> I would think about CLI when we agree on WebUI, IMHO it will be easier. >> >> >> What do you think? I'm waiting for your comments ;-) > > I am thinking about it, on the surface it all looks quite reasonable. > I think the UI is alittle messy, I wonder if we want to expose lower > level concepts as priority and groups, or if we just want to allow users > to set an order in the UI and then let the framework come up with weight > an priority numbers to assign. > Maybe have a way in the CLI to override the decisions of the framework > and set explicit weights ? > > Simo. > The UI seems OK to me. Let's say that we would let user define only the order. How would the server come up with weights and priorities? Or how would it know that some servers are equal (same prio and weight). Then if server would compute the priorities it would be nice to see if some are the same(forms a group). I would continue with drafting CLI. It may help us with Web UI. Then focus on LDAP structure. Right now I'm not very fond of usage of multiple subtypes. It looks like a workaround of subentries to me. -- Petr Vobornik From rcritten at redhat.com Tue Feb 23 15:41:32 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Feb 2016 10:41:32 -0500 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CC5FA2.8030004@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> <56CC1C8B.7050600@redhat.com> <56CC22E4.8040104@redhat.com> <56CC5FA2.8030004@redhat.com> Message-ID: <56CC7DAC.9070904@redhat.com> David Kupka wrote: > On 23/02/16 10:14, Martin Kosek wrote: >> On 02/23/2016 09:47 AM, David Kupka wrote: >>> On 22/02/16 16:15, Martin Kosek wrote: >>>> On 02/22/2016 04:04 PM, Jan Cholasta wrote: >>>>> On 22.2.2016 15:56, David Kupka wrote: >>>>>> On 22/02/16 07:28, Jan Cholasta wrote: >>>>>>> On 18.2.2016 10:10, David Kupka wrote: >>>>>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and >>>>>>>>>>>> removed >>>>>>>>>>>> unused import >>>>>>>>>>>> but otherwise it works, ACK. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>>>>> >>>>>>>>>>> Won't this break existing certmonger requests depending on >>>>>>>>>>> the old >>>>>>>>>>> path? >>>>>>>>>> >>>>>>>>>> It will, I don't see any upgrade code. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>> "auditSigningCert >>>>>>>>>>> cert-pki-ca" >>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>> "ocspSigningCert >>>>>>>>>>> cert-pki-ca" >>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>> "subsystemCert >>>>>>>>>>> cert-pki-ca" >>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>> "caSigningCert >>>>>>>>>>> cert-pki-ca" >>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>> "Server-Cert >>>>>>>>>>> cert-pki-ca" >>>>>>>>>>> post-save command: >>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>>>>> RHEL72 >>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) >>>>>>>>> where all >>>>>>>>> the other trackings are stopped and then configured again with the >>>>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>>>>> >>>>>>>>> Thanks for the catch. >>>>>>>>> >>>>>>>> >>>>>>>> I've updated Timo's patch little more and added >>>>>>>> start_tracking_certificates() for dsinstance and httpinstance. >>>>>>>> Now the >>>>>>>> upgrade works as expected. >>>>>>> >>>>>>> The way the patches are split is kind of weird and apparently >>>>>>> confusing >>>>>>> (see the other thread). IMO there should be 2 patches: the first >>>>>>> should >>>>>>> add the ability to change DS and HTTP certmonger config during >>>>>>> upgrade >>>>>>> (i.e. the start_tracking_certificates() methods and >>>>>>> certificate_renewal_update() changes), the second should move the >>>>>>> helpers (i.e. the actual move and certificate_renewal_update() >>>>>>> version >>>>>>> bump). >>>>>>> >>>>>> Honza, do I understand it correctly that the code is OK but I did not >>>>>> split it to the patches correctly? >>>>> >>>>> Yes. >>>> >>>> Before acking or pushing, can you please explain for me how the >>>> upgrade of >>>> certmonger tracking requests work? I want to make sure this is >>>> right, so please >>>> bear with me: >>>> >>>> 1) How does it edit existing tracking requests with the new helper >>>> paths? >>>> >>>> 2) Does it go and try to edit the requests on every upgrade? Or is >>>> there some >>>> check that requests were updated? >>>> >>>> Thanks, >>>> Martin >>>> >>> >>> Whole upgrade of renewal requests is done in >>> ipaserver/install/server/upgrade.py in certificate_renewal_upgrade(). >>> >>> First there is version of requests and if it's the same as in state file >>> upgrade is skipped. >>> Then every request is searched over certmonger's DBus interface and >>> if at least >>> one is not found it means that there was change in request >>> configuration. All >>> tracking requests are then stopped and started again with new >>> configuration. >>> >>> So to answer you questions: >>> 1) By stopping the old request with the old parameters (including >>> path) and >>> starting new with new parameters. >>> >>> 2) Only if version was bumped which happens only if some of the >>> requests changes. >> >> Ah, so IIUC, if you bump the version, requests should be properly >> updated. The >> change looks fine then. >> > > After discussion with Honza, we decided to drop the part comparing only > base names of pre- and post-save commands and use it as whole. I've also > split the patches so it's obvious what is going on. > > Patches should be applied in this order: > > freeipa-dkupka-0091.0 A cert could silently fail to be tracked in start_tracking_certificates() if no serverid can be found. > freeipa-dkupka-0087.1 > freeipa-dkupka-0088.1 > freeipa-tjaalton-0011.2 > freeipa-dkupka-0092.0 > > > From jcholast at redhat.com Tue Feb 23 15:48:01 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Feb 2016 16:48:01 +0100 Subject: [Freeipa-devel] [PATCH 0135] upgrade: unconditional import of certificate profiles into LDAP In-Reply-To: <56CC1E70.3030407@redhat.com> References: <56CB0735.6080408@redhat.com> <20160223054006.GI21191@dhcp-40-8.bne.redhat.com> <56CBFCFF.7000506@redhat.com> <20160223064359.GN21191@dhcp-40-8.bne.redhat.com> <56CC1E70.3030407@redhat.com> Message-ID: <56CC7F31.3050505@redhat.com> On 23.2.2016 09:55, Martin Babinsky wrote: > On 02/23/2016 07:43 AM, Fraser Tweedale wrote: >> On Tue, Feb 23, 2016 at 07:32:31AM +0100, Jan Cholasta wrote: >>> On 23.2.2016 06:40, Fraser Tweedale wrote: >>>> On Mon, Feb 22, 2016 at 02:03:49PM +0100, Martin Babinsky wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5682 >>>>> >>>>> -- >>>>> Martin^3 Babinsky >>>>> >>>> Thanks for the patch. Conditional ACK. >>>> >>>> Patch is tested and works, but I am wary about checking for >>>> substring match against RemoteRetrieveError reason string (see hunk >>>> below). It would be better to carry the status code as an attribute >>>> of RemoteRetrieveError and check whether it is 409. >>>> >>>>> + except errors.RemoteRetrieveError as e: >>>>> + if "Profile already exists" in e.reason: >>>>> + root_logger.debug("Profile '{}' already >>>>> present".format( >>>>> + profile_id)) >>>>> + else: >>>>> + root_logger.error("Error migrating profile '{}': >>>>> {}".format( >>>>> + profile_id, e)) >>>>> + return >>>> >>>> If you agree, we can file a ticket and I am happy for these patches >>>> to be merged as-is. The scope of changing RemoteRetrieveError is >>>> larger than #5682 so it makes sense to do it separately, and just >>>> for master branch. >>> >>> I don't think this is the right approach. create_profile() should raise >>> DuplicateEntry rather than RemoteRetrieveError if the profile already >>> exists, which can then be properly handled in _create_dogtag_profile(). >>> >> I am happy with that. >> > > Attaching updated patch. Unfortunately, REST API does report only a > super-generic error code 400: Bad request when adding profile which > already exists, which is not very useful for us (I will open a ticket > for Dogtag for this). > > After consultation with Jan, we decided to log the error at debug level > and be done with it (for the moment). Thanks, ACK. Pushed to: master: 2c3b0b1bcd972e6beec4691c03830f37dd27e199 ipa-4-2: 704319c3eaf74e0531dd2aa1e5880db7b6ab830c ipa-4-3: e0ce7e37636969af56a4fa2b1068ae97f1058bdd -- Jan Cholasta From mbasti at redhat.com Tue Feb 23 15:55:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 16:55:25 +0100 Subject: [Freeipa-devel] [PATCH 0415] Pylint: disable new pylint checks In-Reply-To: <56C703C3.80209@redhat.com> References: <56C4A7B5.80809@redhat.com> <56C703C3.80209@redhat.com> Message-ID: <56CC80ED.4080203@redhat.com> On 19.02.2016 13:00, David Kupka wrote: > On 17/02/16 18:02, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5615 >> >> Disable unwanted or false positive checks. >> >> New checks cannot be disabled inline because pylint < 1.5 will report >> them as errors, thus must be disable globally until we decide to move >> completely to pytlint 1.5 (Fedora 25?) >> >> Patches attached. >> >> > Works for me, ACK. > > All tree branches tested on F23 with pylint 1.4.3-3 > Pushed to master: ddda062d58fd9c3c6b4edbea0afb236fc26024ba Pushed to ipa-4-3: 963ce7f117b0cd69590327350b893e755cc38856 Pushed to ipa-4-2: 9136d72ae1feff15a80f162d06a837e7f8cee7ea From mbasti at redhat.com Tue Feb 23 16:09:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 17:09:08 +0100 Subject: [Freeipa-devel] [PATCH 0420] Set BuildRequires to pylint 1.4 Message-ID: <56CC8424.3@redhat.com> We cannot guarantee that versions older than 1.4 will work with freeipa code. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0420-Set-BuildRequires-to-pylint-1.4.patch Type: text/x-patch Size: 886 bytes Desc: not available URL: From mbabinsk at redhat.com Tue Feb 23 16:13:45 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 23 Feb 2016 17:13:45 +0100 Subject: [Freeipa-devel] [PATCH 0414] py3: remove usage of iteritems In-Reply-To: <56C497A7.20309@redhat.com> References: <56C497A7.20309@redhat.com> Message-ID: <56CC8539.7000505@redhat.com> On 02/17/2016 04:54 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5623 > > Patch attached. > > > ACK -- Martin^3 Babinsky From mbasti at redhat.com Tue Feb 23 16:15:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 17:15:13 +0100 Subject: [Freeipa-devel] [PATCH 0414] py3: remove usage of iteritems In-Reply-To: <56CC8539.7000505@redhat.com> References: <56C497A7.20309@redhat.com> <56CC8539.7000505@redhat.com> Message-ID: <56CC8591.1030207@redhat.com> On 23.02.2016 17:13, Martin Babinsky wrote: > On 02/17/2016 04:54 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5623 >> >> Patch attached. >> >> >> > ACK > Pushed to: master: 697072cac9d94ebd006d6a0f595d7956d38d58b9 ipa-4-3: 93582ac57533b2c2bb3079da2ebc48b67b2c1655 From mbasti at redhat.com Tue Feb 23 16:20:56 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 17:20:56 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements In-Reply-To: <56CAC021.8080906@redhat.com> References: <56C47A58.6050207@redhat.com> <56CAC021.8080906@redhat.com> Message-ID: <56CC86E8.1040501@redhat.com> On 22.02.2016 09:00, Jan Cholasta wrote: > Hi, > > On 17.2.2016 14:49, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5631 >> >> Patch attached (for master, 4.3, 4.2) > > 1) All the replication agreement permission ACIs should be located in > the same entry. Currently "Read Replication Agreements" is in > "cn=config" and everything else in "cn=mapping tree,cn=config", so I > guess "cn=mapping tree,cn=config" makes more sense. > > > 2) Instead of literal DN('cn=permissions,cn=pbac'), use > api.env.container_permissions. > > > 3) IMO the removal of managed permission attributes could be a little > bit more robust. You should check that the original entry contains all > the required values before touching it (objectclass=ipapermissionv2, > ipapermissiontype=V2, ipapermissiontype=MANAGED) and remove only the > values that need to be removed, instead of just overwriting everything. > > > Honza > Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0413.2-fix-permission-Read-Replication-Agreements.patch Type: text/x-patch Size: 21364 bytes Desc: not available URL: From mbasti at redhat.com Tue Feb 23 16:30:48 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 17:30:48 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56C58B8A.8080801@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> <56BDFFB7.6040003@redhat.com> <56C58B8A.8080801@redhat.com> Message-ID: <56CC8938.7010801@redhat.com> On 18.02.2016 10:14, David Kupka wrote: > On 12/02/16 16:52, Martin Basti wrote: >> >> >> On 12.02.2016 13:03, Milan Kub?k wrote: >>> On 02/12/2016 10:59 AM, David Kupka wrote: >>>> Sending one more topology test. This one creates a M groups >>>> consisting N (N>=2) servers. >>>> First two servers in each group are used to connect with nearest four >>>> groups and also with the other servers inside the group (when N>2). >>>> Servers inside the group (not connecting to other groups) are >>>> connected with each other. >>>> >>>> The patch set needs freeipa-dkupka-8{1,2,3} applied. >>>> >>> ACK >>> >> I cannot apply patches, please rebase >> >> [mbasti at dhcp129-96 freeipa-devel]$ git checkout master >> Switched to branch 'master' >> Your branch is up-to-date with 'origin/master'. >> [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 >> Applying: CI: Add '2-connected' topology generator. >> Applying: CI: Add simple replication test in 2-connected topology. >> Applying: CI: Add test for 2-connected topology generator. >> Applying: CI: Add double circle topology. >> Applying: CI: Add replication test utilizing double-circle topology. >> Applying: CI: Add test for double-circle topology generator. >> error: invalid object 100644 e12d141391840cc7f9150a178875393a96dd469b >> for 'ipatests/test_integration/test_topologies.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. >> Patch failed at 0006 CI: Add test for double-circle topology generator. >> The copy of the patch that failed is found in: >> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch >> When you have resolved this problem, run "git am --continue". >> If you prefer to skip this patch, run "git am --skip" instead. >> To restore the original branch and stop patching, run "git am --abort". >> >> >> Martin^2 > > Git fails to apply patches because wrong version of > freeipa-dkupka-008{1,2,3} was pushed. Attached patches should fix it. > Sorry my bad. ACK Pushed to: ipa-4-3: ffe3731ae7813fcc3246a83e37d62fc2754bb4ca master: acdabba6ec0f68841f02c1e6ad65232de81bb505 From tbabej at redhat.com Tue Feb 23 16:31:30 2016 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Feb 2016 17:31:30 +0100 Subject: [Freeipa-devel] [PATCH 0416-0419] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56CC4F9C.5040705@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> <56CB5052.5040803@redhat.com> <56CB5D57.3070300@redhat.com> <56CC45C1.1010805@redhat.com> <20160223120249.GG4492@redhat.com> <56CC4F9C.5040705@redhat.com> Message-ID: <56CC8962.40201@redhat.com> On 02/23/2016 01:25 PM, Martin Basti wrote: > > > On 23.02.2016 13:02, Alexander Bokovoy wrote: >> On Tue, 23 Feb 2016, Martin Basti wrote: >>> From f2ae1bd129a1741500d2f3dcb86a0da553604d15 Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Tue, 23 Feb 2016 10:37:47 +0100 >>> Subject: [PATCH 4/4] fix upgrade: wait for proper DS socket after DS >>> restart >>> >>> Restarting DS executed by upgrade plugin causes that upgrade frameworg >>> was waiting for not proper socket to be ready. This commit fix issue. >> Please fix the commit message typos. >> > Fixed. Updated patches attached. ACK. Tomas From mbasti at redhat.com Tue Feb 23 16:33:22 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 17:33:22 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56CC8938.7010801@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> <56BDFFB7.6040003@redhat.com> <56C58B8A.8080801@redhat.com> <56CC8938.7010801@redhat.com> Message-ID: <56CC89D2.202@redhat.com> On 23.02.2016 17:30, Martin Basti wrote: > > > On 18.02.2016 10:14, David Kupka wrote: >> On 12/02/16 16:52, Martin Basti wrote: >>> >>> >>> On 12.02.2016 13:03, Milan Kub?k wrote: >>>> On 02/12/2016 10:59 AM, David Kupka wrote: >>>>> Sending one more topology test. This one creates a M groups >>>>> consisting N (N>=2) servers. >>>>> First two servers in each group are used to connect with nearest four >>>>> groups and also with the other servers inside the group (when N>2). >>>>> Servers inside the group (not connecting to other groups) are >>>>> connected with each other. >>>>> >>>>> The patch set needs freeipa-dkupka-8{1,2,3} applied. >>>>> >>>> ACK >>>> >>> I cannot apply patches, please rebase >>> >>> [mbasti at dhcp129-96 freeipa-devel]$ git checkout master >>> Switched to branch 'master' >>> Your branch is up-to-date with 'origin/master'. >>> [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 >>> Applying: CI: Add '2-connected' topology generator. >>> Applying: CI: Add simple replication test in 2-connected topology. >>> Applying: CI: Add test for 2-connected topology generator. >>> Applying: CI: Add double circle topology. >>> Applying: CI: Add replication test utilizing double-circle topology. >>> Applying: CI: Add test for double-circle topology generator. >>> error: invalid object 100644 e12d141391840cc7f9150a178875393a96dd469b >>> for 'ipatests/test_integration/test_topologies.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. >>> Patch failed at 0006 CI: Add test for double-circle topology generator. >>> The copy of the patch that failed is found in: >>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch >>> When you have resolved this problem, run "git am --continue". >>> If you prefer to skip this patch, run "git am --skip" instead. >>> To restore the original branch and stop patching, run "git am --abort". >>> >>> >>> Martin^2 >> >> Git fails to apply patches because wrong version of >> freeipa-dkupka-008{1,2,3} was pushed. Attached patches should fix it. >> > Sorry my bad. > > ACK > > Pushed to: > ipa-4-3: ffe3731ae7813fcc3246a83e37d62fc2754bb4ca > master: acdabba6ec0f68841f02c1e6ad65232de81bb505 > New test: Pushed to: master: a1e582b33c42bcc8a708777afb975e7dc571ee3d ipa-4-3: 2efa60637111e40a9ac9459d507d9f55a2ae301a From lslebodn at redhat.com Tue Feb 23 16:41:58 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 23 Feb 2016 17:41:58 +0100 Subject: [Freeipa-devel] [PATCH 0420] Set BuildRequires to pylint 1.4 In-Reply-To: <56CC8424.3@redhat.com> References: <56CC8424.3@redhat.com> Message-ID: <20160223164158.GF3452@mail.corp.redhat.com> On (23/02/16 17:09), Martin Basti wrote: >We cannot guarantee that versions older than 1.4 will work with freeipa code. > >Patch attached. >From a59e72a0b87231c0f2e0d737057550dd532feed7 Mon Sep 17 00:00:00 2001 >From: Martin Basti >Date: Tue, 23 Feb 2016 16:58:07 +0100 >Subject: [PATCH] Set BuildRequires to pylint >= 1.4 > >We can guarantee that only pylint 1.4 and newer will work > >https://fedorahosted.org/freeipa/ticket/5615 >--- > freeipa.spec.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/freeipa.spec.in b/freeipa.spec.in >index 54a11bfc8cced643c19c29c5ada70bacf7540395..219c5ca2f13eaac14746ec4689ba611bbc6fc377 100644 >--- a/freeipa.spec.in >+++ b/freeipa.spec.in >@@ -76,7 +76,7 @@ BuildRequires: python-netaddr > BuildRequires: python-gssapi >= 1.1.2 > BuildRequires: python-rhsm > BuildRequires: pyOpenSSL >-BuildRequires: pylint >= 1.0 >+BuildRequires: pylint >= 1.4 I can build rpms even withour pylint and pylint is not executed anywhere in spec file. (in other words, my patch was rejected) Why does it need to be in BuildRequires? LS From mbasti at redhat.com Tue Feb 23 16:54:14 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 17:54:14 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56CC89D2.202@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> <56BDFFB7.6040003@redhat.com> <56C58B8A.8080801@redhat.com> <56CC8938.7010801@redhat.com> <56CC89D2.202@redhat.com> Message-ID: <56CC8EB6.2090507@redhat.com> On 23.02.2016 17:33, Martin Basti wrote: > > > On 23.02.2016 17:30, Martin Basti wrote: >> >> >> On 18.02.2016 10:14, David Kupka wrote: >>> On 12/02/16 16:52, Martin Basti wrote: >>>> >>>> >>>> On 12.02.2016 13:03, Milan Kub?k wrote: >>>>> On 02/12/2016 10:59 AM, David Kupka wrote: >>>>>> Sending one more topology test. This one creates a M groups >>>>>> consisting N (N>=2) servers. >>>>>> First two servers in each group are used to connect with nearest >>>>>> four >>>>>> groups and also with the other servers inside the group (when N>2). >>>>>> Servers inside the group (not connecting to other groups) are >>>>>> connected with each other. >>>>>> >>>>>> The patch set needs freeipa-dkupka-8{1,2,3} applied. >>>>>> >>>>> ACK >>>>> >>>> I cannot apply patches, please rebase >>>> >>>> [mbasti at dhcp129-96 freeipa-devel]$ git checkout master >>>> Switched to branch 'master' >>>> Your branch is up-to-date with 'origin/master'. >>>> [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 >>>> Applying: CI: Add '2-connected' topology generator. >>>> Applying: CI: Add simple replication test in 2-connected topology. >>>> Applying: CI: Add test for 2-connected topology generator. >>>> Applying: CI: Add double circle topology. >>>> Applying: CI: Add replication test utilizing double-circle topology. >>>> Applying: CI: Add test for double-circle topology generator. >>>> error: invalid object 100644 e12d141391840cc7f9150a178875393a96dd469b >>>> for 'ipatests/test_integration/test_topologies.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. >>>> Patch failed at 0006 CI: Add test for double-circle topology >>>> generator. >>>> The copy of the patch that failed is found in: >>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch >>>> When you have resolved this problem, run "git am --continue". >>>> If you prefer to skip this patch, run "git am --skip" instead. >>>> To restore the original branch and stop patching, run "git am >>>> --abort". >>>> >>>> >>>> Martin^2 >>> >>> Git fails to apply patches because wrong version of >>> freeipa-dkupka-008{1,2,3} was pushed. Attached patches should fix it. >>> >> Sorry my bad. >> >> ACK >> >> Pushed to: >> ipa-4-3: ffe3731ae7813fcc3246a83e37d62fc2754bb4ca >> master: acdabba6ec0f68841f02c1e6ad65232de81bb505 >> > New test: > > Pushed to: > master: a1e582b33c42bcc8a708777afb975e7dc571ee3d > ipa-4-3: 2efa60637111e40a9ac9459d507d9f55a2ae301a > Revert? IMO this will not work on python3 ************* Module ipatests.test_integration.test_topologies ipatests/test_integration/test_topologies.py:124: [W1638(range-builtin-not-iterating), test_topology_double_circle_topo] range built-in referenced when not iterating) ************* Module ipatests.test_integration.tasks ipatests/test_integration/tasks.py:949: [W0110(deprecated-lambda), double_circle_topo] map/filter on lambda could be replaced by comprehension) ipatests/test_integration/tasks.py:949: [W1636(map-builtin-not-iterating), double_circle_topo] map built-in referenced when not iterating) ipatests/test_integration/tasks.py:949: [W1637(zip-builtin-not-iterating), double_circle_topo] zip built-in referenced when not iterating) From pspacek at redhat.com Tue Feb 23 17:04:56 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Feb 2016 18:04:56 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1456237158.6599.193.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> Message-ID: <56CC9138.8010409@redhat.com> On 23.2.2016 15:19, Simo Sorce wrote: > On Tue, 2016-02-23 at 12:43 +0100, Petr Spacek wrote: >> On 23.2.2016 11:00, Jan Cholasta wrote: >>> Hi, >>> >>> On 19.2.2016 16:31, Simo Sorce wrote: >>>> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: >>>>> On 4.2.2016 18:21, Petr Spacek wrote: >>>>>> On 3.2.2016 18:41, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I've updated the design page >>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism >>>>>>> >>>>>>> Namely it now contains 'Version 2'. >>>>>> >>>>>> Okay, here is the idea how we can make it flexible: >>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation >>>>> >>>>> Hello, >>>>> >>>>> I'm thinking about LDAP schema for DNS locations. >>>>> >>>>> Purpose >>>>> ======= >>>>> * Allow admins to define any number of locations. >>>>> * 1 DNS server advertises at most 1 location. >>>>> * 1 location generally contains set of services with different priorities and >>>>> weights (in DNS SRV terms). >>>>> * Express server & service priority for each defined location in a way which >>>>> is granular and flexible and ad the same time easy to manage. >>>>> >>>>> >>>>> Proposal >>>>> ======== >>>>> a) Container for locations >>>>> -------------------------- >>>>> cn=locations,cn=ipa,cn=etc,dc=example,dc=com >>>>> >>>>> >>>>> b) 1 location >>>>> ------------- >>>>> Attributes: >>>>> 2.16.840.1.113730.3.8.5.32 idnsLocationMember >>>>> Server/service assigned to a DNS Location. Usually used to define 'main' >>>>> servers for that location. Should it point to service DNs to be sure we have >>>>> smooth upgrade to containers? >>> >>> Services always live on a host (call it server or not), so IMO it makes sense >>> to point to servers. >> >> Fine with me. We just need something which will be able to accommodate >> containerization without upgrade headache. >> >> Do I undestand correctly that 1 container is going to have 1 host object with >> one service object inside it? >> >> Like: >> cn=container >> - cn=DNS, cn=container >> ? > > Do we think we will ever need to define different locations on a per > service basis ? No, I hope that we will avoid this. I suppose that when we containerize IPA things will get 'more interesting', but hopefully not in direction 'location per service'. If we have the possibility to have 1 DNS container and 2 CA containers attached to 1 LDAP container things will be complicated ... I would expect that we will need some additional logic to ensure that one location advertises all the services (so e.g. LDAP is not missing in that particular location). I would not go beyond that. > We based or hypothesis on the fact we only have one location and at most > different weights per services ? > Is there anything in here that will make it hard for us should we change > our mind in future ? (I think the single _tcp DNAME may be an > architectural issue anyway, but that could be resolved perhaps by moving > the location DNAME on a per service basis in future should we need it ? Yes, that is a possible approach but I hope it will not be necessary. Hopefully the logic for assigning containers/server to locations can be made smart enough to guarantee that we do not need more layers of CNAME/DNAME hacks or so. The DNAME trick should be seen as a cheap way to emulate views without actually using views. If you want more fancy things, go and use views on full-featured DNS server ... >>>>> 2.16.840.1.113730.3.8.5.33 idnsBackupLocation >>>>> Pointer to another location. Sucks in all servers from that location as one >>>>> group with the same priority. Easy to use with _default location where all >>>>> 'other' servers are used as backup. >>>>> >>>>> These two attributes use sub-type priority and relativeweight. >>>>> This is the only way I could express all the information without need for >>>>> separate objects. >>> >>> I don't see the benefit here. What is wrong with separate objects? Why is it >>> necessary to reinvent the wheel and abuse attribute sub-types for this, losing >>> schema integrity checks provided by DS and making the implementation more >>> complex along the way? >> >> AFAIK Simo did not like separate objects because we could not use referential >> integrity plugin to prune references to removed servers. >> >> This can surely be done in framework, I do not insist on subtypes. >> >> >> Talk is cheap, show me your schema :-) > > I had a preference, but I m ok also with multiplle objects one per > server/service if we think this will make things easier to handle. > > Given we are going to need a Server object in DNS anyway (so that things > are self contained for non IPA use cases) then I think the referential > integrity thing goes out the window. Back to the drawing board! :-) > [...] > >>>>> Attributes: >>>>> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation >>>>> Pointer to a idnsLocation object. On DNS service object / external server. >>>>> Single-valued. >>> >>> IMO this should be attribute of server rather than service, >>> given that >>> idnsLocationMember points to servers rather than services. >> >> The main reason is why idnsAdvertisedLocation is tied to DNS service is that a >> IPA server without a DNS server cannot advertise anything, so the attribute >> does not make sense on all server objects. >> >> Also, the attribute can be (in future) used on external DNS server. The >> external server is not going to be an IPA server, it will be just >> representation of a DNS endpoint. Likely this external DNS server is not going >> to reside in cn=masters at all. It might be in cn=dns so somewhere else. > > If possible I'd tie it to the DNS server's DNS object, or a new object > in the DNS hierarchy. > We may want to have locations for servers that are not IPA Server at > all, like the preferred local XMPP server or other things like that. Petr Vobornik mentioned an important question: Should we care about non-IPA services? IMHO it is a valid point. It complicates things a lot as soon as we start introducing 'locations per service'. It is certainly doable but I would like to avoid it. It seems easy enough to support custom services as long as there is only one set of locations (which match IPA locations). It would be a management nightmare to support N parallel locations for distinct sets of services. As far as I can tell, AD can live with only 1 set of locations and that sounds reasonable thing to support in the IPA management interface to me. >> So it seemed to me that it would be good to tie this to 'DNS endpoint' object >> instead of IPA server object. >> >> Anyway, I do not insist on this. It can be on the IPA server if you want, but >> we will need additional checks to make sure that DNS service is always present >> on the IPA server in question. Negotiate with Simo :-) >> >> An alternative is to add idnsAdvertisedLocation to location object but then we >> need extra search to find out which location is advertised by particular >> server (or use yet another instance of memberOf plugin ...). > > We can put this on the location object, but what object would it point > to ? To the DNS server object, so we know where to send generated records and configuration. > The search is relatively easy if we can use the dereference control, no > need for memberof tricks. > >>>> I am thinking about it, on the surface it all looks quite reasonable. >>>> I think the UI is alittle messy, I wonder if we want to expose lower >>>> level concepts as priority and groups, or if we just want to allow users >>>> to set an order in the UI and then let the framework come up with weight >>>> an priority numbers to assign. >>> >>> +1, it seems to me that locations are a rather standalone concept, so why tie >>> them to DNS like this? >> >> I do not see the tie to DNS in the user interface except the terminology I used. >> >> Priority (grouping) and weights (load distribution inside one group) are not >> DNS things, these are fail-over and load balancing concepts. >> >> Look at manual for load balancers from F5 [1]: >> * term 'pool' = same thing as our 'priority groups', i.e. group of services >> with equal priority >> * term 'weight' (sometimes also 'ratio weight') = the exactly same sense >> >> I'm certainly open to terminological changes to make it more accessible, it >> would make sense to use the same terms as load balancer vendors. > > Ack, my concern was not with terminology though, but with exposing users > to the concept themselves, I was thinking we might want a simpler > interface for the UI with limited ability to just define pools by > default. However if we think that both pools and weights will be > necessary for common administration I am ok exposing them. > > >> [1] >> https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html >> >> >>>> Maybe have a way in the CLI to override the decisions of the framework >>>> and set explicit weights ? >> >> I was thinking about this as well. >> >> Speaking of weights, we can easily default to the same weight for all servers >> by default so admins do not need to bother unless they want/need. > > I was thinking that an UI that exposes ordering (by moving entries > around up and down a list) would make things simpler, the framework > would calculate a weight based on the order. > > However I am aware that a simple list cannot express concepts like 1 > server being equal weight as 2 others, so perhaps we shouldn't go down > this route ? Ordering can be used to express priority. Weight can default to the same values for all servers and can be tweaked per-server because there is no way how to find out how beefy (or loaded) the server should be, that is purely administrative decision. Weight can be expressed as % (relative to one group) so it should be easy to understand. >> Priority groups are harder because they express metric based on: >> * communication costs, >> * fail-over requirements, >> * other political requirements in given deployment. >> These are hard things to see from layer 7. >> >> Theoretically we can provide ipa-advise plugin to generate some initial set of >> groups but this is going to be complicated and error prone. >> >> E.g. we can use ICMP ping or LDAP base DN search timings and use some >> clustering algorithm to create priority groups using measured values. >> This could work if we use some smart-enough clustering algorithm (= AI >> library). And of course, we would have to do measurements from at least one >> server in each location to properly define groups for each location ... >> >> It is not that easy as it might seem and I do not see an easy solution. >> >> >> Maybe we should take evolutional approach: >> Implement this 'expert' UI which exposes groups & weights to the user first. >> (It will be necessary for special cases anyway.) When this is done, we can >> play with it, do some usability testing (we can ask RH IT to see if it makes >> sense to them, for example.) >> >> Later we can extend this with a 'simple' variant of UI based on feedback or >> add the generator). This does not even need to happen in the same release. >> >> IMHO it would be better to start with something and refine it later on because >> right now we are just hand-waving and have no idea what users actually do and >> want. > > As long as we establish a proper CLI I am ok with implementing a very > bare bone UI first and improving it only later. > > Btw we probably want to have this information reported by the topology > view, and used to automatically group servers there based on location, > so I CCed Petr to see if there is anything that would make that job > easier/harder. We were kicking ideas around the drawing board in the Brno office. Finally, after many iterations we arrived to this: Wouldn't it be easier to implement concept of sites and links between sites at the same time? (In the AD spirit.) If we knew the locations/sites and links between them, we could compute priority groups etc. algorithmicaly. Then only remaining thing is weight, which can have default and admin do not have to touch it if not necessary. Even better, this can be later used to generate optimal replication topology (possibly as recommendation). As far as I can see in AD 2012 they do this: * define which servers belong to which sites * define site-to-site communication costs If we had this information we could take suitable graph algorithm generate priority groups without admin's intervention. It seems that it would make the user interface easier to use and potentially even simplify the schema. IMHO it is worth exploring because especially with large topologies manual priority (and later replication) management will become burden. What do you think? -- Petr^2 Spacek From simo at redhat.com Tue Feb 23 17:14:57 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 23 Feb 2016 12:14:57 -0500 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56CC9138.8010409@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> Message-ID: <1456247697.6599.244.camel@redhat.com> On Tue, 2016-02-23 at 18:04 +0100, Petr Spacek wrote: > On 23.2.2016 15:19, Simo Sorce wrote: > > On Tue, 2016-02-23 at 12:43 +0100, Petr Spacek wrote: > >> On 23.2.2016 11:00, Jan Cholasta wrote: > >>> Hi, > >>> > >>> On 19.2.2016 16:31, Simo Sorce wrote: > >>>> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote: > >>>>> On 4.2.2016 18:21, Petr Spacek wrote: > >>>>>> On 3.2.2016 18:41, Petr Spacek wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> I've updated the design page > >>>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism > >>>>>>> > >>>>>>> Namely it now contains 'Version 2'. > >>>>>> > >>>>>> Okay, here is the idea how we can make it flexible: > >>>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation > >>>>> > >>>>> Hello, > >>>>> > >>>>> I'm thinking about LDAP schema for DNS locations. > >>>>> > >>>>> Purpose > >>>>> ======= > >>>>> * Allow admins to define any number of locations. > >>>>> * 1 DNS server advertises at most 1 location. > >>>>> * 1 location generally contains set of services with different priorities and > >>>>> weights (in DNS SRV terms). > >>>>> * Express server & service priority for each defined location in a way which > >>>>> is granular and flexible and ad the same time easy to manage. > >>>>> > >>>>> > >>>>> Proposal > >>>>> ======== > >>>>> a) Container for locations > >>>>> -------------------------- > >>>>> cn=locations,cn=ipa,cn=etc,dc=example,dc=com > >>>>> > >>>>> > >>>>> b) 1 location > >>>>> ------------- > >>>>> Attributes: > >>>>> 2.16.840.1.113730.3.8.5.32 idnsLocationMember > >>>>> Server/service assigned to a DNS Location. Usually used to define 'main' > >>>>> servers for that location. Should it point to service DNs to be sure we have > >>>>> smooth upgrade to containers? > >>> > >>> Services always live on a host (call it server or not), so IMO it makes sense > >>> to point to servers. > >> > >> Fine with me. We just need something which will be able to accommodate > >> containerization without upgrade headache. > >> > >> Do I undestand correctly that 1 container is going to have 1 host object with > >> one service object inside it? > >> > >> Like: > >> cn=container > >> - cn=DNS, cn=container > >> ? > > > > Do we think we will ever need to define different locations on a per > > service basis ? > > No, I hope that we will avoid this. > > I suppose that when we containerize IPA things will get 'more interesting', > but hopefully not in direction 'location per service'. If we have the > possibility to have 1 DNS container and 2 CA containers attached to 1 LDAP > container things will be complicated ... > > I would expect that we will need some additional logic to ensure that one > location advertises all the services (so e.g. LDAP is not missing in that > particular location). I would not go beyond that. > > > We based or hypothesis on the fact we only have one location and at most > > different weights per services ? > > Is there anything in here that will make it hard for us should we change > > our mind in future ? (I think the single _tcp DNAME may be an > > architectural issue anyway, but that could be resolved perhaps by moving > > the location DNAME on a per service basis in future should we need it ? > > Yes, that is a possible approach but I hope it will not be necessary. > > Hopefully the logic for assigning containers/server to locations can be made > smart enough to guarantee that we do not need more layers of CNAME/DNAME hacks > or so. > > The DNAME trick should be seen as a cheap way to emulate views without > actually using views. If you want more fancy things, go and use views on > full-featured DNS server ... > > > >>>>> 2.16.840.1.113730.3.8.5.33 idnsBackupLocation > >>>>> Pointer to another location. Sucks in all servers from that location as one > >>>>> group with the same priority. Easy to use with _default location where all > >>>>> 'other' servers are used as backup. > >>>>> > >>>>> These two attributes use sub-type priority and relativeweight. > >>>>> This is the only way I could express all the information without need for > >>>>> separate objects. > >>> > >>> I don't see the benefit here. What is wrong with separate objects? Why is it > >>> necessary to reinvent the wheel and abuse attribute sub-types for this, losing > >>> schema integrity checks provided by DS and making the implementation more > >>> complex along the way? > >> > >> AFAIK Simo did not like separate objects because we could not use referential > >> integrity plugin to prune references to removed servers. > >> > >> This can surely be done in framework, I do not insist on subtypes. > >> > >> > >> Talk is cheap, show me your schema :-) > > > > I had a preference, but I m ok also with multiplle objects one per > > server/service if we think this will make things easier to handle. > > > > Given we are going to need a Server object in DNS anyway (so that things > > are self contained for non IPA use cases) then I think the referential > > integrity thing goes out the window. > > Back to the drawing board! :-) > > > > [...] > > > >>>>> Attributes: > >>>>> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation > >>>>> Pointer to a idnsLocation object. On DNS service object / external server. > >>>>> Single-valued. > >>> > >>> IMO this should be attribute of server rather than service, > >>> given that > >>> idnsLocationMember points to servers rather than services. > >> > >> The main reason is why idnsAdvertisedLocation is tied to DNS service is that a > >> IPA server without a DNS server cannot advertise anything, so the attribute > >> does not make sense on all server objects. > >> > >> Also, the attribute can be (in future) used on external DNS server. The > >> external server is not going to be an IPA server, it will be just > >> representation of a DNS endpoint. Likely this external DNS server is not going > >> to reside in cn=masters at all. It might be in cn=dns so somewhere else. > > > > If possible I'd tie it to the DNS server's DNS object, or a new object > > in the DNS hierarchy. > > We may want to have locations for servers that are not IPA Server at > > all, like the preferred local XMPP server or other things like that. > > Petr Vobornik mentioned an important question: > Should we care about non-IPA services? > > IMHO it is a valid point. It complicates things a lot as soon as we start > introducing 'locations per service'. It is certainly doable but I would like > to avoid it. > > It seems easy enough to support custom services as long as there is only one > set of locations (which match IPA locations). It would be a management > nightmare to support N parallel locations for distinct sets of services. > > As far as I can tell, AD can live with only 1 set of locations and that sounds > reasonable thing to support in the IPA management interface to me. I think one set of Locations is fine, but we need to be able to assign services to locations independently from "servers" in some cases, I think. Mostly because a server can have service 1 and 3 but not service 2 and another server can have service 2 and 3 but not 1. > >> So it seemed to me that it would be good to tie this to 'DNS endpoint' object > >> instead of IPA server object. > >> > >> Anyway, I do not insist on this. It can be on the IPA server if you want, but > >> we will need additional checks to make sure that DNS service is always present > >> on the IPA server in question. Negotiate with Simo :-) > >> > >> An alternative is to add idnsAdvertisedLocation to location object but then we > >> need extra search to find out which location is advertised by particular > >> server (or use yet another instance of memberOf plugin ...). > > > > We can put this on the location object, but what object would it point > > to ? > > To the DNS server object, so we know where to send generated records and > configuration. > > > The search is relatively easy if we can use the dereference control, no > > need for memberof tricks. > > > >>>> I am thinking about it, on the surface it all looks quite reasonable. > >>>> I think the UI is alittle messy, I wonder if we want to expose lower > >>>> level concepts as priority and groups, or if we just want to allow users > >>>> to set an order in the UI and then let the framework come up with weight > >>>> an priority numbers to assign. > >>> > >>> +1, it seems to me that locations are a rather standalone concept, so why tie > >>> them to DNS like this? > >> > >> I do not see the tie to DNS in the user interface except the terminology I used. > >> > >> Priority (grouping) and weights (load distribution inside one group) are not > >> DNS things, these are fail-over and load balancing concepts. > >> > >> Look at manual for load balancers from F5 [1]: > >> * term 'pool' = same thing as our 'priority groups', i.e. group of services > >> with equal priority > >> * term 'weight' (sometimes also 'ratio weight') = the exactly same sense > >> > >> I'm certainly open to terminological changes to make it more accessible, it > >> would make sense to use the same terms as load balancer vendors. > > > > Ack, my concern was not with terminology though, but with exposing users > > to the concept themselves, I was thinking we might want a simpler > > interface for the UI with limited ability to just define pools by > > default. However if we think that both pools and weights will be > > necessary for common administration I am ok exposing them. > > > > > >> [1] > >> https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html > >> > >> > >>>> Maybe have a way in the CLI to override the decisions of the framework > >>>> and set explicit weights ? > >> > >> I was thinking about this as well. > >> > >> Speaking of weights, we can easily default to the same weight for all servers > >> by default so admins do not need to bother unless they want/need. > > > > I was thinking that an UI that exposes ordering (by moving entries > > around up and down a list) would make things simpler, the framework > > would calculate a weight based on the order. > > > > However I am aware that a simple list cannot express concepts like 1 > > server being equal weight as 2 others, so perhaps we shouldn't go down > > this route ? > > Ordering can be used to express priority. Weight can default to the same > values for all servers and can be tweaked per-server because there is no way > how to find out how beefy (or loaded) the server should be, that is purely > administrative decision. Weight can be expressed as % (relative to one group) > so it should be easy to understand. OK. +1 > > >> Priority groups are harder because they express metric based on: > >> * communication costs, > >> * fail-over requirements, > >> * other political requirements in given deployment. > >> These are hard things to see from layer 7. > >> > >> Theoretically we can provide ipa-advise plugin to generate some initial set of > >> groups but this is going to be complicated and error prone. > >> > >> E.g. we can use ICMP ping or LDAP base DN search timings and use some > >> clustering algorithm to create priority groups using measured values. > >> This could work if we use some smart-enough clustering algorithm (= AI > >> library). And of course, we would have to do measurements from at least one > >> server in each location to properly define groups for each location ... > >> > >> It is not that easy as it might seem and I do not see an easy solution. > >> > >> > >> Maybe we should take evolutional approach: > >> Implement this 'expert' UI which exposes groups & weights to the user first. > >> (It will be necessary for special cases anyway.) When this is done, we can > >> play with it, do some usability testing (we can ask RH IT to see if it makes > >> sense to them, for example.) > >> > >> Later we can extend this with a 'simple' variant of UI based on feedback or > >> add the generator). This does not even need to happen in the same release. > >> > >> IMHO it would be better to start with something and refine it later on because > >> right now we are just hand-waving and have no idea what users actually do and > >> want. > > > > As long as we establish a proper CLI I am ok with implementing a very > > bare bone UI first and improving it only later. > > > > Btw we probably want to have this information reported by the topology > > view, and used to automatically group servers there based on location, > > so I CCed Petr to see if there is anything that would make that job > > easier/harder. > > > We were kicking ideas around the drawing board in the Brno office. Finally, > after many iterations we arrived to this: > > Wouldn't it be easier to implement concept of sites and links between sites at > the same time? (In the AD spirit.) > > If we knew the locations/sites and links between them, we could compute > priority groups etc. algorithmicaly. Then only remaining thing is weight, > which can have default and admin do not have to touch it if not necessary. You would need to add weights to links, because just the fact there is a link tells you nothing about how big the link is between 2 locations, it also tells you nothing abut the number of clients in a location which may influence how you want to distribute them around. I think we need to let the admin decide for now (as you proposed earlier) and get fancier slowly by thinking carefully about what kind of information we can use to do any automatic priority/weighting computation. > Even better, this can be later used to generate optimal replication topology > (possibly as recommendation). Maybe, but see above, the problem is we do not have metrics to determine what is the real weight of links in a topology, we need to develop these metrics first to be able to gt there. Let's start smaller. > As far as I can see in AD 2012 they do this: > * define which servers belong to which sites > * define site-to-site communication costs The first is easy, the second is not. > If we had this information we could take suitable graph algorithm generate > priority groups without admin's intervention. > > It seems that it would make the user interface easier to use and potentially > even simplify the schema. > > IMHO it is worth exploring because especially with large topologies manual > priority (and later replication) management will become burden. > > > What do you think? I think this has been my long term secret plan, now you spoiled it!! :-) More seriously I think it is a great idea, but too premature to get all the way there now. We need to build schema and CLI that will allow us to get there without having to completely change interfaces if at all possible or minimizing any disruption in the tools. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Tue Feb 23 17:15:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 23 Feb 2016 18:15:36 +0100 Subject: [Freeipa-devel] [PATCH 0416-0419] fix broken configuration of sidgen and extdom plugins In-Reply-To: <56CC8962.40201@redhat.com> References: <56C6E324.2090509@redhat.com> <20160219101226.GQ4492@redhat.com> <56C71F3E.4080102@redhat.com> <20160219140216.GZ4492@redhat.com> <56CB31E3.7030002@redhat.com> <56CB5052.5040803@redhat.com> <56CB5D57.3070300@redhat.com> <56CC45C1.1010805@redhat.com> <20160223120249.GG4492@redhat.com> <56CC4F9C.5040705@redhat.com> <56CC8962.40201@redhat.com> Message-ID: <56CC93B8.2050307@redhat.com> On 23.02.2016 17:31, Tomas Babej wrote: > > On 02/23/2016 01:25 PM, Martin Basti wrote: >> >> On 23.02.2016 13:02, Alexander Bokovoy wrote: >>> On Tue, 23 Feb 2016, Martin Basti wrote: >>>> From f2ae1bd129a1741500d2f3dcb86a0da553604d15 Mon Sep 17 00:00:00 2001 >>>> From: Martin Basti >>>> Date: Tue, 23 Feb 2016 10:37:47 +0100 >>>> Subject: [PATCH 4/4] fix upgrade: wait for proper DS socket after DS >>>> restart >>>> >>>> Restarting DS executed by upgrade plugin causes that upgrade frameworg >>>> was waiting for not proper socket to be ready. This commit fix issue. >>> Please fix the commit message typos. >>> >> Fixed. Updated patches attached. > ACK. > > Tomas Pushed to master: 0accf8ccb64963954dbe7c137d23f52e5901ac4f Pushed to ipa-4-3: 4734012c8063460f93f3b819a5bbcca797f6059e Pushed to ipa-4-2: 63d8caf0d105f02decc0b5d865fedf6ad063bc1a From amarecek at redhat.com Tue Feb 23 17:58:33 2016 From: amarecek at redhat.com (=?utf-8?Q?Ale=C5=A1_Mare=C4=8Dek?=) Date: Tue, 23 Feb 2016 12:58:33 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, create SudoCmdGroupTracker In-Reply-To: <892356320.32871945.1456152096564.JavaMail.zimbra@redhat.com> References: <1667642851.19197845.1453981757248.JavaMail.zimbra@redhat.com> <289487922.19837303.1455196994918.JavaMail.zimbra@redhat.com> <892356320.32871945.1456152096564.JavaMail.zimbra@redhat.com> Message-ID: <26549462.26332960.1456250313045.JavaMail.zimbra@redhat.com> NACK. [root at master2 test_xmlrpc]# pep8 test_sudocmdgroup_plugin.py test_sudocmdgroup_plugin.py:26:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:70:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:76:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:84:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:90:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:98:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:104:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:166:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:180:80: E501 line too long (80 > 79 characters) test_sudocmdgroup_plugin.py:186:80: E501 line too long (84 > 79 characters) [root at master2 test_xmlrpc]# pep8 tracker/sudocmdgroup_plugin.py tracker/sudocmdgroup_plugin.py:36:80: E501 line too long (82 > 79 characters) tracker/sudocmdgroup_plugin.py:42:80: E501 line too long (82 > 79 characters) tracker/sudocmdgroup_plugin.py:46:80: E501 line too long (85 > 79 characters) tracker/sudocmdgroup_plugin.py:55:80: E501 line too long (82 > 79 characters) tracker/sudocmdgroup_plugin.py:64:80: E501 line too long (82 > 79 characters) ----- Original Message ----- > From: "Filip Skola" > To: "Ale? Mare?ek" > Cc: freeipa-devel at redhat.com, "Milan Kub?k" > Sent: Monday, February 22, 2016 3:41:36 PM > Subject: Re: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, create SudoCmdGroupTracker > > Hi, > > the test has been updated so it now uses the SudoCmdTracker (from the > previous patch). > > Filip > > ----- Original Message ----- > > NACK. > > > > "create_sudocmd" and "delete_sudocmd" should be imported from Tracker, not > > from the previous test (sudocmd_plugin). > > > > - alich - > > > > ----- Original Message ----- > > > From: "Filip Skola" > > > To: freeipa-devel at redhat.com > > > Sent: Thursday, January 28, 2016 12:49:17 PM > > > Subject: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, > > > create SudoCmdGroupTracker > > > > > > Hi, > > > > > > sending the next sudo patch. This one depends on the previous one > > > (sudocmd_plugin). > > > > > > Filip > > > > > > -- > > > 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 pspacek at redhat.com Tue Feb 23 17:59:23 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Feb 2016 18:59:23 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1456247697.6599.244.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> Message-ID: <56CC9DFB.3050106@redhat.com> On 23.2.2016 18:14, Simo Sorce wrote: >> > Petr Vobornik mentioned an important question: >> > Should we care about non-IPA services? >> > >> > IMHO it is a valid point. It complicates things a lot as soon as we start >> > introducing 'locations per service'. It is certainly doable but I would like >> > to avoid it. >> > >> > It seems easy enough to support custom services as long as there is only one >> > set of locations (which match IPA locations). It would be a management >> > nightmare to support N parallel locations for distinct sets of services. >> > >> > As far as I can tell, AD can live with only 1 set of locations and that sounds >> > reasonable thing to support in the IPA management interface to me. > I think one set of Locations is fine, but we need to be able to assign > services to locations independently from "servers" in some cases, I > think. > > Mostly because a server can have service 1 and 3 but not service 2 and > another server can have service 2 and 3 but not 1. Hmm, I do not follow. Where is the problem? You can assign both servers to the location and get all three services available, the SRV records from all servers will just combine. We should have checks in IPA so it will not allow you to create a Frankenstein IPA server which is missing LDAP or so but this will be needed only when we decide to containerize - or when we allow to select individual services instead of servers :-) For custom services, you are on your own. Still, I would say that assigning services (instead of servers) to location is making it *more* error prone as there is bigger chance of omitting something (like selecting only service 1 from server A) and not the other way around. What did I miss? [...] >>>> > >> Priority groups are harder because they express metric based on: >>>> > >> * communication costs, >>>> > >> * fail-over requirements, >>>> > >> * other political requirements in given deployment. >>>> > >> These are hard things to see from layer 7. >>>> > >> >>>> > >> Theoretically we can provide ipa-advise plugin to generate some initial set of >>>> > >> groups but this is going to be complicated and error prone. >>>> > >> >>>> > >> E.g. we can use ICMP ping or LDAP base DN search timings and use some >>>> > >> clustering algorithm to create priority groups using measured values. >>>> > >> This could work if we use some smart-enough clustering algorithm (= AI >>>> > >> library). And of course, we would have to do measurements from at least one >>>> > >> server in each location to properly define groups for each location ... >>>> > >> >>>> > >> It is not that easy as it might seem and I do not see an easy solution. >>>> > >> >>>> > >> >>>> > >> Maybe we should take evolutional approach: >>>> > >> Implement this 'expert' UI which exposes groups & weights to the user first. >>>> > >> (It will be necessary for special cases anyway.) When this is done, we can >>>> > >> play with it, do some usability testing (we can ask RH IT to see if it makes >>>> > >> sense to them, for example.) >>>> > >> >>>> > >> Later we can extend this with a 'simple' variant of UI based on feedback or >>>> > >> add the generator). This does not even need to happen in the same release. >>>> > >> >>>> > >> IMHO it would be better to start with something and refine it later on because >>>> > >> right now we are just hand-waving and have no idea what users actually do and >>>> > >> want. >>> > > >>> > > As long as we establish a proper CLI I am ok with implementing a very >>> > > bare bone UI first and improving it only later. >>> > > >>> > > Btw we probably want to have this information reported by the topology >>> > > view, and used to automatically group servers there based on location, >>> > > so I CCed Petr to see if there is anything that would make that job >>> > > easier/harder. >> > >> > >> > We were kicking ideas around the drawing board in the Brno office. Finally, >> > after many iterations we arrived to this: >> > >> > Wouldn't it be easier to implement concept of sites and links between sites at >> > the same time? (In the AD spirit.) >> > >> > If we knew the locations/sites and links between them, we could compute >> > priority groups etc. algorithmicaly. Then only remaining thing is weight, >> > which can have default and admin do not have to touch it if not necessary. > You would need to add weights to links, because just the fact there is a > link tells you nothing about how big the link is between 2 locations, it Oh, sure, I was thinking about link metric implicitly :-) > also tells you nothing abut the number of clients in a location which > may influence how you want to distribute them around. Do you have an example in mind? It sounds weird to me that you want to distribute clients outside of local site. If I understand you correctly it means that the local site is not able to handle the load by itself. In this case you can either assign 'remote' servers to the location as a workaround (as IPA does not care where the server actually is), or define link cost = 0 which could threat two locations as equal. In any case such setup does not have sufficient power to handle clients locally so there is nothing to optimize. In other words splitting this setup into locations does not bring you anything because it is simply overloaded. (Just keep in mind that we are not building map of a real network but vastly simplified view usable for IPA servers and clients.) > I think we need to let the admin decide for now (as you proposed > earlier) and get fancier slowly by thinking carefully about what kind of > information we can use to do any automatic priority/weighting > computation. > >> > Even better, this can be later used to generate optimal replication topology >> > (possibly as recommendation). > Maybe, but see above, the problem is we do not have metrics to determine > what is the real weight of links in a topology, we need to develop these > metrics first to be able to gt there. Let's start smaller. Yes, we have to be careful. On the other hand, I do not believe that there is a way how to universally and automatically determine the metric. IMHO we will end up with 'administrative' metric as most of the IP routing protocols. As far as I remember from my network engineering studies routing is more about politics than anything else. There is ton of prior art about routing and this can (and should!) be re-used because we are talking about routing clients requests to servers. >> > As far as I can see in AD 2012 they do this: >> > * define which servers belong to which sites >> > * define site-to-site communication costs > The first is easy, the second is not. Unless it is an administrative metric, which is I believe the only feasible approach anyway. 1. The metric can have a default (pick your random number ;-) for links without explicit configuration. 2. We can use default all-to-all links with default metric when there is no explicit configuration. This should just work and does not add any administrative overhead for the simplest case: "Prefer local servers. If all of local servers fail, pick some other server randomly". >> > If we had this information we could take suitable graph algorithm generate >> > priority groups without admin's intervention. >> > >> > It seems that it would make the user interface easier to use and potentially >> > even simplify the schema. >> > >> > IMHO it is worth exploring because especially with large topologies manual >> > priority (and later replication) management will become burden. >> > >> > >> > What do you think? > I think this has been my long term secret plan, now you spoiled it!! :-) > > More seriously I think it is a great idea, but too premature to get all > the way there now. We need to build schema and CLI that will allow us to > get there without having to completely change interfaces if at all > possible or minimizing any disruption in the tools. Actually the backwards compatibility is the main worry which led to this idea with links. If we release first version of locations with custom priorities etc. we will have support the schema (which will be different) and API (which will be later unnecessary) forever. If we skip this intermediate phase with hand-made configuration we can save all the headache with upgrades to more automatic solution later on. Maybe we should invert the order: Start with locations + links with administrative metric and add hand-tweaking capabilities later (if necessary). IMHO locations + links with administrative metric will be easier to implement than the first version. Just thinking aloud ... -- Petr^2 Spacek From rcritten at redhat.com Tue Feb 23 19:23:15 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Feb 2016 14:23:15 -0500 Subject: [Freeipa-devel] [PATCH 0420] Set BuildRequires to pylint 1.4 In-Reply-To: <20160223164158.GF3452@mail.corp.redhat.com> References: <56CC8424.3@redhat.com> <20160223164158.GF3452@mail.corp.redhat.com> Message-ID: <56CCB1A3.1070000@redhat.com> Lukas Slebodnik wrote: > On (23/02/16 17:09), Martin Basti wrote: >> We cannot guarantee that versions older than 1.4 will work with freeipa code. >> >> Patch attached. > >>From a59e72a0b87231c0f2e0d737057550dd532feed7 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Tue, 23 Feb 2016 16:58:07 +0100 >> Subject: [PATCH] Set BuildRequires to pylint >= 1.4 >> >> We can guarantee that only pylint 1.4 and newer will work >> >> https://fedorahosted.org/freeipa/ticket/5615 >> --- >> freeipa.spec.in | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/freeipa.spec.in b/freeipa.spec.in >> index 54a11bfc8cced643c19c29c5ada70bacf7540395..219c5ca2f13eaac14746ec4689ba611bbc6fc377 100644 >> --- a/freeipa.spec.in >> +++ b/freeipa.spec.in >> @@ -76,7 +76,7 @@ BuildRequires: python-netaddr >> BuildRequires: python-gssapi >= 1.1.2 >> BuildRequires: python-rhsm >> BuildRequires: pyOpenSSL >> -BuildRequires: pylint >= 1.0 >> +BuildRequires: pylint >= 1.4 > > I can build rpms even withour pylint and pylint is not executed > anywhere in spec file. (in other words, my patch was rejected) > Why does it need to be in BuildRequires? pylint is part of the in-tree build process (make rpms). It is not executed when building upstream packages. rob From dkupka at redhat.com Wed Feb 24 05:49:38 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Feb 2016 06:49:38 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CC7DAC.9070904@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> <56CC1C8B.7050600@redhat.com> <56CC22E4.8040104@redhat.com> <56CC5FA2.8030004@redhat.com> <56CC7DAC.9070904@redhat.com> Message-ID: <56CD4472.3000307@redhat.com> On 23/02/16 16:41, Rob Crittenden wrote: > David Kupka wrote: >> On 23/02/16 10:14, Martin Kosek wrote: >>> On 02/23/2016 09:47 AM, David Kupka wrote: >>>> On 22/02/16 16:15, Martin Kosek wrote: >>>>> On 02/22/2016 04:04 PM, Jan Cholasta wrote: >>>>>> On 22.2.2016 15:56, David Kupka wrote: >>>>>>> On 22/02/16 07:28, Jan Cholasta wrote: >>>>>>>> On 18.2.2016 10:10, David Kupka wrote: >>>>>>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and >>>>>>>>>>>>> removed >>>>>>>>>>>>> unused import >>>>>>>>>>>>> but otherwise it works, ACK. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>>>>>> >>>>>>>>>>>> Won't this break existing certmonger requests depending on >>>>>>>>>>>> the old >>>>>>>>>>>> path? >>>>>>>>>>> >>>>>>>>>>> It will, I don't see any upgrade code. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>> "auditSigningCert >>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>> "subsystemCert >>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>> "caSigningCert >>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>> "Server-Cert >>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>> post-save command: >>>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>>>>>> RHEL72 >>>>>>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) >>>>>>>>>> where all >>>>>>>>>> the other trackings are stopped and then configured again with the >>>>>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>>>>>> >>>>>>>>>> Thanks for the catch. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I've updated Timo's patch little more and added >>>>>>>>> start_tracking_certificates() for dsinstance and httpinstance. >>>>>>>>> Now the >>>>>>>>> upgrade works as expected. >>>>>>>> >>>>>>>> The way the patches are split is kind of weird and apparently >>>>>>>> confusing >>>>>>>> (see the other thread). IMO there should be 2 patches: the first >>>>>>>> should >>>>>>>> add the ability to change DS and HTTP certmonger config during >>>>>>>> upgrade >>>>>>>> (i.e. the start_tracking_certificates() methods and >>>>>>>> certificate_renewal_update() changes), the second should move the >>>>>>>> helpers (i.e. the actual move and certificate_renewal_update() >>>>>>>> version >>>>>>>> bump). >>>>>>>> >>>>>>> Honza, do I understand it correctly that the code is OK but I did not >>>>>>> split it to the patches correctly? >>>>>> >>>>>> Yes. >>>>> >>>>> Before acking or pushing, can you please explain for me how the >>>>> upgrade of >>>>> certmonger tracking requests work? I want to make sure this is >>>>> right, so please >>>>> bear with me: >>>>> >>>>> 1) How does it edit existing tracking requests with the new helper >>>>> paths? >>>>> >>>>> 2) Does it go and try to edit the requests on every upgrade? Or is >>>>> there some >>>>> check that requests were updated? >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>> >>>> Whole upgrade of renewal requests is done in >>>> ipaserver/install/server/upgrade.py in certificate_renewal_upgrade(). >>>> >>>> First there is version of requests and if it's the same as in state file >>>> upgrade is skipped. >>>> Then every request is searched over certmonger's DBus interface and >>>> if at least >>>> one is not found it means that there was change in request >>>> configuration. All >>>> tracking requests are then stopped and started again with new >>>> configuration. >>>> >>>> So to answer you questions: >>>> 1) By stopping the old request with the old parameters (including >>>> path) and >>>> starting new with new parameters. >>>> >>>> 2) Only if version was bumped which happens only if some of the >>>> requests changes. >>> >>> Ah, so IIUC, if you bump the version, requests should be properly >>> updated. The >>> change looks fine then. >>> >> >> After discussion with Honza, we decided to drop the part comparing only >> base names of pre- and post-save commands and use it as whole. I've also >> split the patches so it's obvious what is going on. >> >> Patches should be applied in this order: >> >> freeipa-dkupka-0091.0 > > A cert could silently fail to be tracked in > start_tracking_certificates() if no serverid can be found. In that case it also wouldn't be stopped. The behavior is the same as in existing stop_tracking_certificates(). Should we rather raise and stop the upgrade? I guess not but warning would be probably useful. What solution would you prefer, Rob? > >> freeipa-dkupka-0087.1 >> freeipa-dkupka-0088.1 >> freeipa-tjaalton-0011.2 >> freeipa-dkupka-0092.0 >> >> >> -- David Kupka From dkupka at redhat.com Wed Feb 24 07:27:22 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Feb 2016 08:27:22 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56CC8EB6.2090507@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> <56BDFFB7.6040003@redhat.com> <56C58B8A.8080801@redhat.com> <56CC8938.7010801@redhat.com> <56CC89D2.202@redhat.com> <56CC8EB6.2090507@redhat.com> Message-ID: <56CD5B5A.60609@redhat.com> On 23/02/16 17:54, Martin Basti wrote: > > > On 23.02.2016 17:33, Martin Basti wrote: >> >> >> On 23.02.2016 17:30, Martin Basti wrote: >>> >>> >>> On 18.02.2016 10:14, David Kupka wrote: >>>> On 12/02/16 16:52, Martin Basti wrote: >>>>> >>>>> >>>>> On 12.02.2016 13:03, Milan Kub?k wrote: >>>>>> On 02/12/2016 10:59 AM, David Kupka wrote: >>>>>>> Sending one more topology test. This one creates a M groups >>>>>>> consisting N (N>=2) servers. >>>>>>> First two servers in each group are used to connect with nearest >>>>>>> four >>>>>>> groups and also with the other servers inside the group (when N>2). >>>>>>> Servers inside the group (not connecting to other groups) are >>>>>>> connected with each other. >>>>>>> >>>>>>> The patch set needs freeipa-dkupka-8{1,2,3} applied. >>>>>>> >>>>>> ACK >>>>>> >>>>> I cannot apply patches, please rebase >>>>> >>>>> [mbasti at dhcp129-96 freeipa-devel]$ git checkout master >>>>> Switched to branch 'master' >>>>> Your branch is up-to-date with 'origin/master'. >>>>> [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 >>>>> Applying: CI: Add '2-connected' topology generator. >>>>> Applying: CI: Add simple replication test in 2-connected topology. >>>>> Applying: CI: Add test for 2-connected topology generator. >>>>> Applying: CI: Add double circle topology. >>>>> Applying: CI: Add replication test utilizing double-circle topology. >>>>> Applying: CI: Add test for double-circle topology generator. >>>>> error: invalid object 100644 e12d141391840cc7f9150a178875393a96dd469b >>>>> for 'ipatests/test_integration/test_topologies.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. >>>>> Patch failed at 0006 CI: Add test for double-circle topology >>>>> generator. >>>>> The copy of the patch that failed is found in: >>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch >>>>> When you have resolved this problem, run "git am --continue". >>>>> If you prefer to skip this patch, run "git am --skip" instead. >>>>> To restore the original branch and stop patching, run "git am >>>>> --abort". >>>>> >>>>> >>>>> Martin^2 >>>> >>>> Git fails to apply patches because wrong version of >>>> freeipa-dkupka-008{1,2,3} was pushed. Attached patches should fix it. >>>> >>> Sorry my bad. >>> >>> ACK >>> >>> Pushed to: >>> ipa-4-3: ffe3731ae7813fcc3246a83e37d62fc2754bb4ca >>> master: acdabba6ec0f68841f02c1e6ad65232de81bb505 >>> >> New test: >> >> Pushed to: >> master: a1e582b33c42bcc8a708777afb975e7dc571ee3d >> ipa-4-3: 2efa60637111e40a9ac9459d507d9f55a2ae301a >> > Revert? > IMO this will not work on python3 > > ************* Module ipatests.test_integration.test_topologies > ipatests/test_integration/test_topologies.py:124: > [W1638(range-builtin-not-iterating), test_topology_double_circle_topo] > range built-in referenced when not iterating) > ************* Module ipatests.test_integration.tasks > ipatests/test_integration/tasks.py:949: [W0110(deprecated-lambda), > double_circle_topo] map/filter on lambda could be replaced by > comprehension) > ipatests/test_integration/tasks.py:949: > [W1636(map-builtin-not-iterating), double_circle_topo] map built-in > referenced when not iterating) > ipatests/test_integration/tasks.py:949: > [W1637(zip-builtin-not-iterating), double_circle_topo] zip built-in > referenced when not iterating) > You can revert it and I will send fixed patches or you can just apply attached patch. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0093.0-CI-Make-double-circle-topology-python3-compatible.patch Type: text/x-patch Size: 1620 bytes Desc: not available URL: From mkubik at redhat.com Wed Feb 24 07:34:58 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Wed, 24 Feb 2016 08:34:58 +0100 Subject: [Freeipa-devel] [patch 0034] ipatests: extend permission plugin test with new expected output In-Reply-To: <56C5DA92.4090805@redhat.com> References: <56C1F5C6.2090708@redhat.com> <56C5DA92.4090805@redhat.com> Message-ID: <56CD5D22.9000404@redhat.com> On 02/18/2016 03:52 PM, Milan Kub?k wrote: > On 02/15/2016 04:59 PM, Milan Kub?k wrote: >> Patch attached. Applies on ipa-4-3 as well. >> >> >> > Updated version of patch fixes test_old_permission_plugin as well. > > -- > Milan Kubik > > Review bump. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: From slaznick at redhat.com Wed Feb 24 07:46:51 2016 From: slaznick at redhat.com (Stanislav Laznicka) Date: Wed, 24 Feb 2016 08:46:51 +0100 Subject: [Freeipa-devel] [PATCH 0022-23] Coverity patches In-Reply-To: <56CAA825.60903@redhat.com> References: <56AB6E03.2030601@redhat.com> <56AB7BF0.9030008@redhat.com> <56AB7BFD.1020308@redhat.com> <56AF113D.20804@redhat.com> <56AF3D46.5060901@redhat.com> <56AF5C75.9050409@redhat.com> <56B0A2B1.8040507@redhat.com> <56CAA825.60903@redhat.com> Message-ID: <56CD5FEB.7050703@redhat.com> Reworded the commit messages so that they mention Coverity. On 02/22/2016 07:18 AM, Jan Cholasta wrote: > On 2.2.2016 13:36, Stanislav Laznicka wrote: >> On 02/01/2016 02:24 PM, Jan Cholasta wrote: >>> On 1.2.2016 12:11, Petr Spacek wrote: >>>> On 1.2.2016 09:03, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 29.1.2016 15:49, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 29.01.2016 15:49, Stanislav Laznicka wrote: >>>>>>> Reworded the commits so that they better reflect what's going on >>>>>>> in those. >>>>>>> >>>>>>> On 01/29/2016 02:49 PM, Stanislav Laznicka wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I made some patches based on the Coverity report from 18.1.2016. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Standa >>>>>>>> >>>>>>> >>>>>> NACK, see my previous email >>>>> >>>>> I don't think this deserves 9 patches, 1 would be sufficient enough. >>>> >>>> I would rather have it is separate patches as these fixes are largely >>>> not >>>> related. It will make bisecting easier. >>> >>> Most of the fixes are cosmetic, which makes them related, and the rest >>> are small isolated changes, so in reality it would hardly make >>> bisecting easier and only increase the overhead. In the past we >>> usually had put such fixes into a single patch and AFAIK nobody >>> complained so far. >>> >> Squeezed the changes into two new patches, then. One for the very >> cosmetic changes, one for possible bugs. > > OK. > >>>> >>>> >>>>> Patch 0013: >>>>> >>>>> 1) I think this unreachable return is intentional, as indicated by >>>>> the comment: >>>>> >>>>> - #we shouldn't get here >>>>> - return [UNKNOWN_ERROR] >>>> >>>> I would use >>>> assert False, "we shouldn't get here" >>>> neither we nor Coverity are confused when we hit the code path one >>>> day. >>>> >>>> UNKNOWN_ERROR would pop up somewhere else and it will be harder to >>>> find out >>>> why the hell the code behaves as mad. Traceback will clearly indicate >>>> that >>>> there is a problem with the 'switch'. >>> >>> Sure, my point is that returning None is no better than returning >>> UNKNOWN_ERROR. >>> >> Added assert as suggested. There should still be no way of getting to >> it, though. >>>> >>>> Petr^2 Spacek >>>> >>>>> 2) How is this dead code? >>>>> >>>>> - if options.mode == 'validate_pot' or options.mode == >>>>> 'validate_po': >>>>> + if options.mode in ('validate_pot', 'validate_po'): >>>>> >>>>> - elif options.mode == 'create_test' or 'test_gettext': >>>>> + elif options.mode in ('create_test', 'test_gettext'): >>>>> >>>>> >>>>> >>>>> Patch 0014-0015: LGTM >>> >>> Actually scratch that, patch 0015 breaks correct code. >>> >> The dead code appears in the 'else' branch as the latter of these two >> conditions always evaluates to True. The first condition change is just >> a cosmetic one so that both of the conditions look the same. > > OK. > >> >> Also removed the changes made in patch 0015. >>>>> >>>>> >>>>> Patch 0016: The original code is in fact correct. >>>>> >> Point taken, removed the change. >>>>> >>>>> Patch 0017: This will break Python 3. The two branches are >>>>> performing the same >>>>> action, but with different data types. >>>>> >> This might undergo further investigation in the future as there is no >> way how "bytes" instance could become an argument of this function (as >> suggested). Not even the newest Python 3 patches from pviktori mention >> this code. > > OK. (This is not what Coverity was complaining about, though.) > >>>>> >>>>> Patch 0018: LGTM >>>>> >>>>> >>>>> Patch 0019: IMO the original code is better (None has a __class__ >>>>> too, you know). >>>>> >> Made it more "Coverity friendly" yet nice enough modification. >>>>> >>>>> Patch 0020: LGTM >>>>> >> It seems that there actually is a check that checks whether the input is >> correct. It is called ad-hoc but that might be the test feature. >> Therefore just added an assert so that Coverity does not complain. > > OK. > >>>>> >>>>> Patch 0021: Please use the original error messages (there are no >>>>> requests >>>>> being added to D-Bus, but to certmonger). >>>>> >>>>> >>>>> Honza >>>> >>> >> Added error messages that reflect the situation better, then. > > Could you please mention Coverity in the commit messages, so that it's > clear why are we doing these changes? Otherwise LGTM. > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0022-2-Cosmetic-changes-to-the-code.patch Type: text/x-patch Size: 4165 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-stlaz-0023-2-Fixes-minor-issues.patch Type: text/x-patch Size: 3784 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Feb 24 08:13:37 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 24 Feb 2016 09:13:37 +0100 Subject: [Freeipa-devel] [PATCH 547] cacert install: fix trust chain validation In-Reply-To: <56CB45B9.8040204@redhat.com> References: <56CB45B9.8040204@redhat.com> Message-ID: <56CD6631.10603@redhat.com> On 02/22/2016 06:30 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > ACK. -- Martin^3 Babinsky From jcholast at redhat.com Wed Feb 24 08:21:50 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Feb 2016 09:21:50 +0100 Subject: [Freeipa-devel] [PATCH 0022-23] Coverity patches In-Reply-To: <56CD5FEB.7050703@redhat.com> References: <56AB6E03.2030601@redhat.com> <56AB7BF0.9030008@redhat.com> <56AB7BFD.1020308@redhat.com> <56AF113D.20804@redhat.com> <56AF3D46.5060901@redhat.com> <56AF5C75.9050409@redhat.com> <56B0A2B1.8040507@redhat.com> <56CAA825.60903@redhat.com> <56CD5FEB.7050703@redhat.com> Message-ID: <56CD681E.2080002@redhat.com> On 24.2.2016 08:46, Stanislav Laznicka wrote: > Reworded the commit messages so that they mention Coverity. > > On 02/22/2016 07:18 AM, Jan Cholasta wrote: >> On 2.2.2016 13:36, Stanislav Laznicka wrote: >>> On 02/01/2016 02:24 PM, Jan Cholasta wrote: >>>> On 1.2.2016 12:11, Petr Spacek wrote: >>>>> On 1.2.2016 09:03, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 29.1.2016 15:49, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 29.01.2016 15:49, Stanislav Laznicka wrote: >>>>>>>> Reworded the commits so that they better reflect what's going on >>>>>>>> in those. >>>>>>>> >>>>>>>> On 01/29/2016 02:49 PM, Stanislav Laznicka wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I made some patches based on the Coverity report from 18.1.2016. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Standa >>>>>>>>> >>>>>>>> >>>>>>> NACK, see my previous email >>>>>> >>>>>> I don't think this deserves 9 patches, 1 would be sufficient enough. >>>>> >>>>> I would rather have it is separate patches as these fixes are largely >>>>> not >>>>> related. It will make bisecting easier. >>>> >>>> Most of the fixes are cosmetic, which makes them related, and the rest >>>> are small isolated changes, so in reality it would hardly make >>>> bisecting easier and only increase the overhead. In the past we >>>> usually had put such fixes into a single patch and AFAIK nobody >>>> complained so far. >>>> >>> Squeezed the changes into two new patches, then. One for the very >>> cosmetic changes, one for possible bugs. >> >> OK. >> >>>>> >>>>> >>>>>> Patch 0013: >>>>>> >>>>>> 1) I think this unreachable return is intentional, as indicated by >>>>>> the comment: >>>>>> >>>>>> - #we shouldn't get here >>>>>> - return [UNKNOWN_ERROR] >>>>> >>>>> I would use >>>>> assert False, "we shouldn't get here" >>>>> neither we nor Coverity are confused when we hit the code path one >>>>> day. >>>>> >>>>> UNKNOWN_ERROR would pop up somewhere else and it will be harder to >>>>> find out >>>>> why the hell the code behaves as mad. Traceback will clearly indicate >>>>> that >>>>> there is a problem with the 'switch'. >>>> >>>> Sure, my point is that returning None is no better than returning >>>> UNKNOWN_ERROR. >>>> >>> Added assert as suggested. There should still be no way of getting to >>> it, though. >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>> 2) How is this dead code? >>>>>> >>>>>> - if options.mode == 'validate_pot' or options.mode == >>>>>> 'validate_po': >>>>>> + if options.mode in ('validate_pot', 'validate_po'): >>>>>> >>>>>> - elif options.mode == 'create_test' or 'test_gettext': >>>>>> + elif options.mode in ('create_test', 'test_gettext'): >>>>>> >>>>>> >>>>>> >>>>>> Patch 0014-0015: LGTM >>>> >>>> Actually scratch that, patch 0015 breaks correct code. >>>> >>> The dead code appears in the 'else' branch as the latter of these two >>> conditions always evaluates to True. The first condition change is just >>> a cosmetic one so that both of the conditions look the same. >> >> OK. >> >>> >>> Also removed the changes made in patch 0015. >>>>>> >>>>>> >>>>>> Patch 0016: The original code is in fact correct. >>>>>> >>> Point taken, removed the change. >>>>>> >>>>>> Patch 0017: This will break Python 3. The two branches are >>>>>> performing the same >>>>>> action, but with different data types. >>>>>> >>> This might undergo further investigation in the future as there is no >>> way how "bytes" instance could become an argument of this function (as >>> suggested). Not even the newest Python 3 patches from pviktori mention >>> this code. >> >> OK. (This is not what Coverity was complaining about, though.) >> >>>>>> >>>>>> Patch 0018: LGTM >>>>>> >>>>>> >>>>>> Patch 0019: IMO the original code is better (None has a __class__ >>>>>> too, you know). >>>>>> >>> Made it more "Coverity friendly" yet nice enough modification. >>>>>> >>>>>> Patch 0020: LGTM >>>>>> >>> It seems that there actually is a check that checks whether the input is >>> correct. It is called ad-hoc but that might be the test feature. >>> Therefore just added an assert so that Coverity does not complain. >> >> OK. >> >>>>>> >>>>>> Patch 0021: Please use the original error messages (there are no >>>>>> requests >>>>>> being added to D-Bus, but to certmonger). >>>>>> >>>>>> >>>>>> Honza >>>>> >>>> >>> Added error messages that reflect the situation better, then. >> >> Could you please mention Coverity in the commit messages, so that it's >> clear why are we doing these changes? Otherwise LGTM. >> Thanks, ACK. Pushed to: master: d7efd8a33ab14a561d3af445e62bceb6f2f13fd1 ipa-4-3: d78a759569020eba08b90e35707e86778523ec58 -- Jan Cholasta From jcholast at redhat.com Wed Feb 24 08:23:16 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Feb 2016 09:23:16 +0100 Subject: [Freeipa-devel] [PATCH 547] cacert install: fix trust chain validation In-Reply-To: <56CD6631.10603@redhat.com> References: <56CB45B9.8040204@redhat.com> <56CD6631.10603@redhat.com> Message-ID: <56CD6874.4010502@redhat.com> On 24.2.2016 09:13, Martin Babinsky wrote: > On 02/22/2016 06:30 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > ACK. Thanks. Pushed to: master: ef9134640795b736731bfbdb6fe0badb3e817552 ipa-4-3: 4fa8d3bca44b02b81783673dd14954b94ed49efa -- Jan Cholasta From lslebodn at redhat.com Wed Feb 24 08:50:29 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 24 Feb 2016 09:50:29 +0100 Subject: [Freeipa-devel] [PATCH 0420] Set BuildRequires to pylint 1.4 In-Reply-To: <56CCB1A3.1070000@redhat.com> References: <56CC8424.3@redhat.com> <20160223164158.GF3452@mail.corp.redhat.com> <56CCB1A3.1070000@redhat.com> Message-ID: <20160224085028.GB1234@mail.corp.redhat.com> On (23/02/16 14:23), Rob Crittenden wrote: >Lukas Slebodnik wrote: >> On (23/02/16 17:09), Martin Basti wrote: >>> We cannot guarantee that versions older than 1.4 will work with freeipa code. >>> >>> Patch attached. >> >>>From a59e72a0b87231c0f2e0d737057550dd532feed7 Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Tue, 23 Feb 2016 16:58:07 +0100 >>> Subject: [PATCH] Set BuildRequires to pylint >= 1.4 >>> >>> We can guarantee that only pylint 1.4 and newer will work >>> >>> https://fedorahosted.org/freeipa/ticket/5615 >>> --- >>> freeipa.spec.in | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>> index 54a11bfc8cced643c19c29c5ada70bacf7540395..219c5ca2f13eaac14746ec4689ba611bbc6fc377 100644 >>> --- a/freeipa.spec.in >>> +++ b/freeipa.spec.in >>> @@ -76,7 +76,7 @@ BuildRequires: python-netaddr >>> BuildRequires: python-gssapi >= 1.1.2 >>> BuildRequires: python-rhsm >>> BuildRequires: pyOpenSSL >>> -BuildRequires: pylint >= 1.0 >>> +BuildRequires: pylint >= 1.4 >> >> I can build rpms even withour pylint and pylint is not executed >> anywhere in spec file. (in other words, my patch was rejected) >> Why does it need to be in BuildRequires? > >pylint is part of the in-tree build process (make rpms). It is not >executed when building upstream packages. > It's not buildrequires becuase I can rebuild src.rpm without it. It should not be there or it should be optional to do not break developer workflow. e.g. "%bcond_with extra_dependencies_for_pylint" The upstream spec files is close to the fedora spec file and pylint is istalled there even though it's not used. Another use case is coverity scan. LS From mkosek at redhat.com Wed Feb 24 09:00:07 2016 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Feb 2016 10:00:07 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56CC9DFB.3050106@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> Message-ID: <56CD7117.8000202@redhat.com> On 02/23/2016 06:59 PM, Petr Spacek wrote: > On 23.2.2016 18:14, Simo Sorce wrote: ... >> More seriously I think it is a great idea, but too premature to get all >> the way there now. We need to build schema and CLI that will allow us to >> get there without having to completely change interfaces if at all >> possible or minimizing any disruption in the tools. > > Actually the backwards compatibility is the main worry which led to this idea > with links. > > If we release first version of locations with custom priorities etc. we will > have support the schema (which will be different) and API (which will be later > unnecessary) forever. > > If we skip this intermediate phase with hand-made configuration we can save > all the headache with upgrades to more automatic solution later on. > > > Maybe we should invert the order: > Start with locations + links with administrative metric and add hand-tweaking > capabilities later (if necessary). > > IMHO locations + links with administrative metric will be easier to implement > than the first version. > > Just thinking aloud ... Makes sense to me, I would have the same worry as Petr, that we would break something if we decide moving to links based solution later. From dkupka at redhat.com Wed Feb 24 09:07:51 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Feb 2016 10:07:51 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56CD5B5A.60609@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> <56BDFFB7.6040003@redhat.com> <56C58B8A.8080801@redhat.com> <56CC8938.7010801@redhat.com> <56CC89D2.202@redhat.com> <56CC8EB6.2090507@redhat.com> <56CD5B5A.60609@redhat.com> Message-ID: <56CD72E7.2050906@redhat.com> On 24/02/16 08:27, David Kupka wrote: > On 23/02/16 17:54, Martin Basti wrote: >> >> >> On 23.02.2016 17:33, Martin Basti wrote: >>> >>> >>> On 23.02.2016 17:30, Martin Basti wrote: >>>> >>>> >>>> On 18.02.2016 10:14, David Kupka wrote: >>>>> On 12/02/16 16:52, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 12.02.2016 13:03, Milan Kub?k wrote: >>>>>>> On 02/12/2016 10:59 AM, David Kupka wrote: >>>>>>>> Sending one more topology test. This one creates a M groups >>>>>>>> consisting N (N>=2) servers. >>>>>>>> First two servers in each group are used to connect with nearest >>>>>>>> four >>>>>>>> groups and also with the other servers inside the group (when N>2). >>>>>>>> Servers inside the group (not connecting to other groups) are >>>>>>>> connected with each other. >>>>>>>> >>>>>>>> The patch set needs freeipa-dkupka-8{1,2,3} applied. >>>>>>>> >>>>>>> ACK >>>>>>> >>>>>> I cannot apply patches, please rebase >>>>>> >>>>>> [mbasti at dhcp129-96 freeipa-devel]$ git checkout master >>>>>> Switched to branch 'master' >>>>>> Your branch is up-to-date with 'origin/master'. >>>>>> [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 >>>>>> Applying: CI: Add '2-connected' topology generator. >>>>>> Applying: CI: Add simple replication test in 2-connected topology. >>>>>> Applying: CI: Add test for 2-connected topology generator. >>>>>> Applying: CI: Add double circle topology. >>>>>> Applying: CI: Add replication test utilizing double-circle topology. >>>>>> Applying: CI: Add test for double-circle topology generator. >>>>>> error: invalid object 100644 e12d141391840cc7f9150a178875393a96dd469b >>>>>> for 'ipatests/test_integration/test_topologies.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. >>>>>> Patch failed at 0006 CI: Add test for double-circle topology >>>>>> generator. >>>>>> The copy of the patch that failed is found in: >>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch >>>>>> When you have resolved this problem, run "git am --continue". >>>>>> If you prefer to skip this patch, run "git am --skip" instead. >>>>>> To restore the original branch and stop patching, run "git am >>>>>> --abort". >>>>>> >>>>>> >>>>>> Martin^2 >>>>> >>>>> Git fails to apply patches because wrong version of >>>>> freeipa-dkupka-008{1,2,3} was pushed. Attached patches should fix it. >>>>> >>>> Sorry my bad. >>>> >>>> ACK >>>> >>>> Pushed to: >>>> ipa-4-3: ffe3731ae7813fcc3246a83e37d62fc2754bb4ca >>>> master: acdabba6ec0f68841f02c1e6ad65232de81bb505 >>>> >>> New test: >>> >>> Pushed to: >>> master: a1e582b33c42bcc8a708777afb975e7dc571ee3d >>> ipa-4-3: 2efa60637111e40a9ac9459d507d9f55a2ae301a >>> >> Revert? >> IMO this will not work on python3 >> >> ************* Module ipatests.test_integration.test_topologies >> ipatests/test_integration/test_topologies.py:124: >> [W1638(range-builtin-not-iterating), test_topology_double_circle_topo] >> range built-in referenced when not iterating) >> ************* Module ipatests.test_integration.tasks >> ipatests/test_integration/tasks.py:949: [W0110(deprecated-lambda), >> double_circle_topo] map/filter on lambda could be replaced by >> comprehension) >> ipatests/test_integration/tasks.py:949: >> [W1636(map-builtin-not-iterating), double_circle_topo] map built-in >> referenced when not iterating) >> ipatests/test_integration/tasks.py:949: >> [W1637(zip-builtin-not-iterating), double_circle_topo] zip built-in >> referenced when not iterating) >> > > You can revert it and I will send fixed patches or you can just apply > attached patch. > > Updated patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0093.1-CI-Make-double-circle-topology-python3-compatible.patch Type: text/x-patch Size: 1613 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 24 09:38:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 10:38:06 +0100 Subject: [Freeipa-devel] [PATCH 0084-0086] CI: Add double circle topology In-Reply-To: <56CD72E7.2050906@redhat.com> References: <56BDAD0F.6070706@redhat.com> <56BDCA19.1040405@redhat.com> <56BDFFB7.6040003@redhat.com> <56C58B8A.8080801@redhat.com> <56CC8938.7010801@redhat.com> <56CC89D2.202@redhat.com> <56CC8EB6.2090507@redhat.com> <56CD5B5A.60609@redhat.com> <56CD72E7.2050906@redhat.com> Message-ID: <56CD79FE.4030008@redhat.com> On 24.02.2016 10:07, David Kupka wrote: > On 24/02/16 08:27, David Kupka wrote: >> On 23/02/16 17:54, Martin Basti wrote: >>> >>> >>> On 23.02.2016 17:33, Martin Basti wrote: >>>> >>>> >>>> On 23.02.2016 17:30, Martin Basti wrote: >>>>> >>>>> >>>>> On 18.02.2016 10:14, David Kupka wrote: >>>>>> On 12/02/16 16:52, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 12.02.2016 13:03, Milan Kub?k wrote: >>>>>>>> On 02/12/2016 10:59 AM, David Kupka wrote: >>>>>>>>> Sending one more topology test. This one creates a M groups >>>>>>>>> consisting N (N>=2) servers. >>>>>>>>> First two servers in each group are used to connect with nearest >>>>>>>>> four >>>>>>>>> groups and also with the other servers inside the group (when >>>>>>>>> N>2). >>>>>>>>> Servers inside the group (not connecting to other groups) are >>>>>>>>> connected with each other. >>>>>>>>> >>>>>>>>> The patch set needs freeipa-dkupka-8{1,2,3} applied. >>>>>>>>> >>>>>>>> ACK >>>>>>>> >>>>>>> I cannot apply patches, please rebase >>>>>>> >>>>>>> [mbasti at dhcp129-96 freeipa-devel]$ git checkout master >>>>>>> Switched to branch 'master' >>>>>>> Your branch is up-to-date with 'origin/master'. >>>>>>> [mbasti at dhcp129-96 freeipa-devel]$ git am freeipa-dkupka-008* -3 >>>>>>> Applying: CI: Add '2-connected' topology generator. >>>>>>> Applying: CI: Add simple replication test in 2-connected topology. >>>>>>> Applying: CI: Add test for 2-connected topology generator. >>>>>>> Applying: CI: Add double circle topology. >>>>>>> Applying: CI: Add replication test utilizing double-circle >>>>>>> topology. >>>>>>> Applying: CI: Add test for double-circle topology generator. >>>>>>> error: invalid object 100644 >>>>>>> e12d141391840cc7f9150a178875393a96dd469b >>>>>>> for 'ipatests/test_integration/test_topologies.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. >>>>>>> Patch failed at 0006 CI: Add test for double-circle topology >>>>>>> generator. >>>>>>> The copy of the patch that failed is found in: >>>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch >>>>>>> When you have resolved this problem, run "git am --continue". >>>>>>> If you prefer to skip this patch, run "git am --skip" instead. >>>>>>> To restore the original branch and stop patching, run "git am >>>>>>> --abort". >>>>>>> >>>>>>> >>>>>>> Martin^2 >>>>>> >>>>>> Git fails to apply patches because wrong version of >>>>>> freeipa-dkupka-008{1,2,3} was pushed. Attached patches should fix >>>>>> it. >>>>>> >>>>> Sorry my bad. >>>>> >>>>> ACK >>>>> >>>>> Pushed to: >>>>> ipa-4-3: ffe3731ae7813fcc3246a83e37d62fc2754bb4ca >>>>> master: acdabba6ec0f68841f02c1e6ad65232de81bb505 >>>>> >>>> New test: >>>> >>>> Pushed to: >>>> master: a1e582b33c42bcc8a708777afb975e7dc571ee3d >>>> ipa-4-3: 2efa60637111e40a9ac9459d507d9f55a2ae301a >>>> >>> Revert? >>> IMO this will not work on python3 >>> >>> ************* Module ipatests.test_integration.test_topologies >>> ipatests/test_integration/test_topologies.py:124: >>> [W1638(range-builtin-not-iterating), test_topology_double_circle_topo] >>> range built-in referenced when not iterating) >>> ************* Module ipatests.test_integration.tasks >>> ipatests/test_integration/tasks.py:949: [W0110(deprecated-lambda), >>> double_circle_topo] map/filter on lambda could be replaced by >>> comprehension) >>> ipatests/test_integration/tasks.py:949: >>> [W1636(map-builtin-not-iterating), double_circle_topo] map built-in >>> referenced when not iterating) >>> ipatests/test_integration/tasks.py:949: >>> [W1637(zip-builtin-not-iterating), double_circle_topo] zip built-in >>> referenced when not iterating) >>> >> >> You can revert it and I will send fixed patches or you can just apply >> attached patch. >> >> > Updated patch attached. > ACK Pushed to: master: 775ee77bcc091ba31fdd3e59f8d45d0b646a44a0 ipa-4-3: 05539761cd6f7bd6ce40b687b913be81eabf69e1 From jcholast at redhat.com Wed Feb 24 09:45:15 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Feb 2016 10:45:15 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements In-Reply-To: <56CC86E8.1040501@redhat.com> References: <56C47A58.6050207@redhat.com> <56CAC021.8080906@redhat.com> <56CC86E8.1040501@redhat.com> Message-ID: <56CD7BAB.4040906@redhat.com> On 23.2.2016 17:20, Martin Basti wrote: > > > On 22.02.2016 09:00, Jan Cholasta wrote: >> Hi, >> >> On 17.2.2016 14:49, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5631 >>> >>> Patch attached (for master, 4.3, 4.2) >> >> 1) All the replication agreement permission ACIs should be located in >> the same entry. Currently "Read Replication Agreements" is in >> "cn=config" and everything else in "cn=mapping tree,cn=config", so I >> guess "cn=mapping tree,cn=config" makes more sense. >> >> >> 2) Instead of literal DN('cn=permissions,cn=pbac'), use >> api.env.container_permissions. >> >> >> 3) IMO the removal of managed permission attributes could be a little >> bit more robust. You should check that the original entry contains all >> the required values before touching it (objectclass=ipapermissionv2, >> ipapermissiontype=V2, ipapermissiontype=MANAGED) and remove only the >> values that need to be removed, instead of just overwriting everything. >> >> >> Honza >> > Updated patch attached. The patch does not apply on ipa-4-2. Also this bit in replica-acis.ldif is redundant: + +dn: cn=mapping tree,cn=config +changetype: modify +add: aci Honza -- Jan Cholasta From dkupka at redhat.com Wed Feb 24 09:50:08 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Feb 2016 10:50:08 +0100 Subject: [Freeipa-devel] [PATCH 546] client: stop using /etc/pki/nssdb In-Reply-To: <56CB23EB.1010505@redhat.com> References: <56CB23EB.1010505@redhat.com> Message-ID: <56CD7CD0.8030908@redhat.com> On 22/02/16 16:06, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > Works for me, ACK. -- David Kupka From jcholast at redhat.com Wed Feb 24 09:53:54 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Feb 2016 10:53:54 +0100 Subject: [Freeipa-devel] [PATCH 546] client: stop using /etc/pki/nssdb In-Reply-To: <56CD7CD0.8030908@redhat.com> References: <56CB23EB.1010505@redhat.com> <56CD7CD0.8030908@redhat.com> Message-ID: <56CD7DB2.1070806@redhat.com> On 24.2.2016 10:50, David Kupka wrote: > On 22/02/16 16:06, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> > Works for me, ACK. Thanks. Pushed to: master: 11592dde1b232a70f318e01f5271b38890090648 ipa-4-3: a3e8af3b4aae3dd59985b1065f530587015ae05c -- Jan Cholasta From pvoborni at redhat.com Wed Feb 24 10:06:05 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Feb 2016 11:06:05 +0100 Subject: [Freeipa-devel] [PATCH 0420] Set BuildRequires to pylint 1.4 In-Reply-To: <20160224085028.GB1234@mail.corp.redhat.com> References: <56CC8424.3@redhat.com> <20160223164158.GF3452@mail.corp.redhat.com> <56CCB1A3.1070000@redhat.com> <20160224085028.GB1234@mail.corp.redhat.com> Message-ID: <56CD808D.4060604@redhat.com> On 02/24/2016 09:50 AM, Lukas Slebodnik wrote: > On (23/02/16 14:23), Rob Crittenden wrote: >> Lukas Slebodnik wrote: >>> On (23/02/16 17:09), Martin Basti wrote: >>>> We cannot guarantee that versions older than 1.4 will work with freeipa code. >>>> >>>> Patch attached. >>> >>> >From a59e72a0b87231c0f2e0d737057550dd532feed7 Mon Sep 17 00:00:00 2001 >>>> From: Martin Basti >>>> Date: Tue, 23 Feb 2016 16:58:07 +0100 >>>> Subject: [PATCH] Set BuildRequires to pylint >= 1.4 >>>> >>>> We can guarantee that only pylint 1.4 and newer will work >>>> >>>> https://fedorahosted.org/freeipa/ticket/5615 >>>> --- >>>> freeipa.spec.in | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>> index 54a11bfc8cced643c19c29c5ada70bacf7540395..219c5ca2f13eaac14746ec4689ba611bbc6fc377 100644 >>>> --- a/freeipa.spec.in >>>> +++ b/freeipa.spec.in >>>> @@ -76,7 +76,7 @@ BuildRequires: python-netaddr >>>> BuildRequires: python-gssapi >= 1.1.2 >>>> BuildRequires: python-rhsm >>>> BuildRequires: pyOpenSSL >>>> -BuildRequires: pylint >= 1.0 >>>> +BuildRequires: pylint >= 1.4 >>> >>> I can build rpms even withour pylint and pylint is not executed >>> anywhere in spec file. (in other words, my patch was rejected) >>> Why does it need to be in BuildRequires? >> >> pylint is part of the in-tree build process (make rpms). It is not >> executed when building upstream packages. >> > It's not buildrequires becuase I can rebuild src.rpm > without it. It should not be there or it should be optional > to do not break developer workflow. > > e.g. "%bcond_with extra_dependencies_for_pylint" > > The upstream spec files is close to the fedora spec file > and pylint is istalled there even though it's not used. > > Another use case is coverity scan. > > LS > Basically I agree with Lukas but this patch is the way how we do build upstream right now. The proposed change would required more refactoring of build process and is out of scope of this ticket. Feel free to open a ticket for it. It should not block this patch. -- Petr Vobornik From mbasti at redhat.com Wed Feb 24 12:07:15 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 13:07:15 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements In-Reply-To: <56CD7BAB.4040906@redhat.com> References: <56C47A58.6050207@redhat.com> <56CAC021.8080906@redhat.com> <56CC86E8.1040501@redhat.com> <56CD7BAB.4040906@redhat.com> Message-ID: <56CD9CF3.2040905@redhat.com> On 24.02.2016 10:45, Jan Cholasta wrote: > On 23.2.2016 17:20, Martin Basti wrote: >> >> >> On 22.02.2016 09:00, Jan Cholasta wrote: >>> Hi, >>> >>> On 17.2.2016 14:49, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5631 >>>> >>>> Patch attached (for master, 4.3, 4.2) >>> >>> 1) All the replication agreement permission ACIs should be located in >>> the same entry. Currently "Read Replication Agreements" is in >>> "cn=config" and everything else in "cn=mapping tree,cn=config", so I >>> guess "cn=mapping tree,cn=config" makes more sense. >>> >>> >>> 2) Instead of literal DN('cn=permissions,cn=pbac'), use >>> api.env.container_permissions. >>> >>> >>> 3) IMO the removal of managed permission attributes could be a little >>> bit more robust. You should check that the original entry contains all >>> the required values before touching it (objectclass=ipapermissionv2, >>> ipapermissiontype=V2, ipapermissiontype=MANAGED) and remove only the >>> values that need to be removed, instead of just overwriting everything. >>> >>> >>> Honza >>> >> Updated patch attached. > > The patch does not apply on ipa-4-2. > I will send it later. > Also this bit in replica-acis.ldif is redundant: > > + > +dn: cn=mapping tree,cn=config > +changetype: modify > +add: aci All related ACIs to replication are in both replica-acis.ldif and 20-aci.update. I just do not want to mess it more than it is. > > Honza > Martin^2 From pvoborni at redhat.com Wed Feb 24 12:31:55 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Feb 2016 13:31:55 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <56C322DA.9040105@redhat.com> References: <56C322DA.9040105@redhat.com> Message-ID: <56CDA2BB.9060508@redhat.com> On 02/16/2016 02:23 PM, Martin Babinsky wrote: > Hi list, > > WARNING: huge brain dump ahead. > > During investigation of https://fedorahosted.org/freeipa/ticket/4305 me > and Petr Spaced (CC'ed) came to a conclusion that the IPA realm > autodiscovery code used by ipa-client-install is so convoluted, complex > and hard to understand that the cost of fixing a bug/adding a behavioral > change (there are some other tickets dealing with ipadiscovery, e.g. see > https://fedorahosted.org/freeipa/ticket/5270 > https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher > that a more large-scale rewrite of the module and related codebase. > > Since we plan to do some general refactoring work anyway, I would like > to discuss the possible course of action we may take to tackle this > issue. I would like to present the following options we have been > discussing so far: > > 1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") > > We may take the existing IPADiscovery class and try rewrite it in order > to get a more concise and deterministic code, which will: > > * rely more on python-dns and answers provided by resolver (e.g. we are > directly parsing resolv.conf for available domains when we can ask the > resolver to get domains for us) > * be more pythonic (replace error codes with thrown exceptions, clean up > numerous C-isms etc.) > * not try to outsmart user when server/realm/domain is specified > beforehand. Currently, even if you specify all three options, there is > still some DNS discovery performed, hence bug #4305. I think that one > you specify server(s), not magic should be performed and the discovery > process should be reduced to checking whether they are IPA servers and > pull all other info (like realm) from them. > > This may be a considerable effort requiring some time to implement and > get right, but IMHO still comparable to the time spent iteratively > placing 'if' statements into the existing code and hoping to not break > anything. I would even argue it is not worth the effort because we can > > 2.) Use realmd dbus interface to do DNS discovery > > I have attached aquick and dirty script I have slapped together to > leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm > discovery for us. This has a lot of appeal to me since we are leveraging > existing codebase for DNS discovery and will have to handle only cases > when the user manually specifies a list of IPA servers for the client. > > This however pulls in realmd as a (potentially circular) dependency for > ipa client, and when we find bug in the discovery code, we will have to > poke upstream (Stef or Sumit I think) to fix it. > > So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: > > 3.) Split out IPA discovery portion of realmd to a separate C library > shared between IPA and realmd > > may be best. Both projects will have shared codebase (maintained either > by us or realmd devs), which can be reused also by other people to > create their own discovery/enrollment solution. This would however > require sustained and concerted efforts of both teams to create the > library and possibly rewrite realmd to accommodate this change. > > There may be some other options viable for us, if so please mention them > in a reply. Also please correct any piece of information I got wrong. > > TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix > it. > #3 sounds good from long term perspective. In short term, i.e., #4305, we should skip discovery when --on-master is used. -- Petr Vobornik From jcholast at redhat.com Wed Feb 24 12:36:51 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Feb 2016 13:36:51 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements In-Reply-To: <56CD9CF3.2040905@redhat.com> References: <56C47A58.6050207@redhat.com> <56CAC021.8080906@redhat.com> <56CC86E8.1040501@redhat.com> <56CD7BAB.4040906@redhat.com> <56CD9CF3.2040905@redhat.com> Message-ID: <56CDA3E3.4070407@redhat.com> On 24.2.2016 13:07, Martin Basti wrote: > > > On 24.02.2016 10:45, Jan Cholasta wrote: >> On 23.2.2016 17:20, Martin Basti wrote: >>> >>> >>> On 22.02.2016 09:00, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 17.2.2016 14:49, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5631 >>>>> >>>>> Patch attached (for master, 4.3, 4.2) >>>> >>>> 1) All the replication agreement permission ACIs should be located in >>>> the same entry. Currently "Read Replication Agreements" is in >>>> "cn=config" and everything else in "cn=mapping tree,cn=config", so I >>>> guess "cn=mapping tree,cn=config" makes more sense. >>>> >>>> >>>> 2) Instead of literal DN('cn=permissions,cn=pbac'), use >>>> api.env.container_permissions. >>>> >>>> >>>> 3) IMO the removal of managed permission attributes could be a little >>>> bit more robust. You should check that the original entry contains all >>>> the required values before touching it (objectclass=ipapermissionv2, >>>> ipapermissiontype=V2, ipapermissiontype=MANAGED) and remove only the >>>> values that need to be removed, instead of just overwriting everything. >>>> >>>> >>>> Honza >>>> >>> Updated patch attached. >> >> The patch does not apply on ipa-4-2. >> > I will send it later. > >> Also this bit in replica-acis.ldif is redundant: >> >> + >> +dn: cn=mapping tree,cn=config >> +changetype: modify >> +add: aci > All related ACIs to replication are in both replica-acis.ldif and > 20-aci.update. > I just do not want to mess it more than it is. What I'm trying to say is that: dn: cn=mapping tree,cn=config changetype: modify add: aci aci: $ACI1 dn: cn=mapping tree,cn=config changetype: modify add: aci aci: $ACI2 is the same as: dn: cn=mapping tree,cn=config changetype: modify add: aci aci: $ACI1 aci: $ACI2 . You actually have it right in 20-aci.update, but not in replica-acis.ldif. -- Jan Cholasta From lslebodn at redhat.com Wed Feb 24 12:38:53 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 24 Feb 2016 13:38:53 +0100 Subject: [Freeipa-devel] [PATCH 0420] Set BuildRequires to pylint 1.4 In-Reply-To: <56CD808D.4060604@redhat.com> References: <56CC8424.3@redhat.com> <20160223164158.GF3452@mail.corp.redhat.com> <56CCB1A3.1070000@redhat.com> <20160224085028.GB1234@mail.corp.redhat.com> <56CD808D.4060604@redhat.com> Message-ID: <20160224123853.GC1234@mail.corp.redhat.com> On (24/02/16 11:06), Petr Vobornik wrote: >On 02/24/2016 09:50 AM, Lukas Slebodnik wrote: >>On (23/02/16 14:23), Rob Crittenden wrote: >>>Lukas Slebodnik wrote: >>>>On (23/02/16 17:09), Martin Basti wrote: >>>>>We cannot guarantee that versions older than 1.4 will work with freeipa code. >>>>> >>>>>Patch attached. >>>> >>>>>From a59e72a0b87231c0f2e0d737057550dd532feed7 Mon Sep 17 00:00:00 2001 >>>>>From: Martin Basti >>>>>Date: Tue, 23 Feb 2016 16:58:07 +0100 >>>>>Subject: [PATCH] Set BuildRequires to pylint >= 1.4 >>>>> >>>>>We can guarantee that only pylint 1.4 and newer will work >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/5615 >>>>>--- >>>>>freeipa.spec.in | 2 +- >>>>>1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>>diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>index 54a11bfc8cced643c19c29c5ada70bacf7540395..219c5ca2f13eaac14746ec4689ba611bbc6fc377 100644 >>>>>--- a/freeipa.spec.in >>>>>+++ b/freeipa.spec.in >>>>>@@ -76,7 +76,7 @@ BuildRequires: python-netaddr >>>>>BuildRequires: python-gssapi >= 1.1.2 >>>>>BuildRequires: python-rhsm >>>>>BuildRequires: pyOpenSSL >>>>>-BuildRequires: pylint >= 1.0 >>>>>+BuildRequires: pylint >= 1.4 >>>> >>>>I can build rpms even withour pylint and pylint is not executed >>>>anywhere in spec file. (in other words, my patch was rejected) >>>>Why does it need to be in BuildRequires? >>> >>>pylint is part of the in-tree build process (make rpms). It is not >>>executed when building upstream packages. >>> >>It's not buildrequires becuase I can rebuild src.rpm >>without it. It should not be there or it should be optional >>to do not break developer workflow. >> >>e.g. "%bcond_with extra_dependencies_for_pylint" >> >>The upstream spec files is close to the fedora spec file >>and pylint is istalled there even though it's not used. >> >>Another use case is coverity scan. >> >>LS >> > >Basically I agree with Lukas but this patch is the way how we do build >upstream right now. > >The proposed change would required more refactoring of build process and is >out of scope of this ticket. Feel free to open a ticket for it. It should not >block this patch. I have a different opinion here. The ticket #5615 says: "Prepare IPA for pylint 1.5.2" It does not say anything about minimal requirement on pylint 1.4 even though all current version of fedora has pylint 1.4. Older version of pylint (1.3.1) is available only in fedora 20. Which is out of support for more than a year. Patch is neither required for fedora nor for ticket #5615 However there is only pylint-1.3.1 in epel7 And it would cause issues there. Summary: This patch does not solve anything. LS From rcritten at redhat.com Wed Feb 24 14:07:53 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Feb 2016 09:07:53 -0500 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CD4472.3000307@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> <56CC1C8B.7050600@redhat.com> <56CC22E4.8040104@redhat.com> <56CC5FA2.8030004@redhat.com> <56CC7DAC.9070904@redhat.com> <56CD4472.3000307@redhat.com> Message-ID: <56CDB939.8000505@redhat.com> David Kupka wrote: > On 23/02/16 16:41, Rob Crittenden wrote: >> David Kupka wrote: >>> On 23/02/16 10:14, Martin Kosek wrote: >>>> On 02/23/2016 09:47 AM, David Kupka wrote: >>>>> On 22/02/16 16:15, Martin Kosek wrote: >>>>>> On 02/22/2016 04:04 PM, Jan Cholasta wrote: >>>>>>> On 22.2.2016 15:56, David Kupka wrote: >>>>>>>> On 22/02/16 07:28, Jan Cholasta wrote: >>>>>>>>> On 18.2.2016 10:10, David Kupka wrote: >>>>>>>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>>>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and >>>>>>>>>>>>>> removed >>>>>>>>>>>>>> unused import >>>>>>>>>>>>>> but otherwise it works, ACK. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>>>>>>> >>>>>>>>>>>>> Won't this break existing certmonger requests depending on >>>>>>>>>>>>> the old >>>>>>>>>>>>> path? >>>>>>>>>>>> >>>>>>>>>>>> It will, I don't see any upgrade code. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>> "auditSigningCert >>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>> "subsystemCert >>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>> "caSigningCert >>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>> "Server-Cert >>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>>>>>>> RHEL72 >>>>>>>>>>>>> post-save command: >>>>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>>>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) >>>>>>>>>>> where all >>>>>>>>>>> the other trackings are stopped and then configured again >>>>>>>>>>> with the >>>>>>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>>>>>>> >>>>>>>>>>> Thanks for the catch. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've updated Timo's patch little more and added >>>>>>>>>> start_tracking_certificates() for dsinstance and httpinstance. >>>>>>>>>> Now the >>>>>>>>>> upgrade works as expected. >>>>>>>>> >>>>>>>>> The way the patches are split is kind of weird and apparently >>>>>>>>> confusing >>>>>>>>> (see the other thread). IMO there should be 2 patches: the first >>>>>>>>> should >>>>>>>>> add the ability to change DS and HTTP certmonger config during >>>>>>>>> upgrade >>>>>>>>> (i.e. the start_tracking_certificates() methods and >>>>>>>>> certificate_renewal_update() changes), the second should move the >>>>>>>>> helpers (i.e. the actual move and certificate_renewal_update() >>>>>>>>> version >>>>>>>>> bump). >>>>>>>>> >>>>>>>> Honza, do I understand it correctly that the code is OK but I >>>>>>>> did not >>>>>>>> split it to the patches correctly? >>>>>>> >>>>>>> Yes. >>>>>> >>>>>> Before acking or pushing, can you please explain for me how the >>>>>> upgrade of >>>>>> certmonger tracking requests work? I want to make sure this is >>>>>> right, so please >>>>>> bear with me: >>>>>> >>>>>> 1) How does it edit existing tracking requests with the new helper >>>>>> paths? >>>>>> >>>>>> 2) Does it go and try to edit the requests on every upgrade? Or is >>>>>> there some >>>>>> check that requests were updated? >>>>>> >>>>>> Thanks, >>>>>> Martin >>>>>> >>>>> >>>>> Whole upgrade of renewal requests is done in >>>>> ipaserver/install/server/upgrade.py in certificate_renewal_upgrade(). >>>>> >>>>> First there is version of requests and if it's the same as in state >>>>> file >>>>> upgrade is skipped. >>>>> Then every request is searched over certmonger's DBus interface and >>>>> if at least >>>>> one is not found it means that there was change in request >>>>> configuration. All >>>>> tracking requests are then stopped and started again with new >>>>> configuration. >>>>> >>>>> So to answer you questions: >>>>> 1) By stopping the old request with the old parameters (including >>>>> path) and >>>>> starting new with new parameters. >>>>> >>>>> 2) Only if version was bumped which happens only if some of the >>>>> requests changes. >>>> >>>> Ah, so IIUC, if you bump the version, requests should be properly >>>> updated. The >>>> change looks fine then. >>>> >>> >>> After discussion with Honza, we decided to drop the part comparing only >>> base names of pre- and post-save commands and use it as whole. I've also >>> split the patches so it's obvious what is going on. >>> >>> Patches should be applied in this order: >>> >>> freeipa-dkupka-0091.0 >> >> A cert could silently fail to be tracked in >> start_tracking_certificates() if no serverid can be found. > > In that case it also wouldn't be stopped. The behavior is the same as in > existing stop_tracking_certificates(). Should we rather raise and stop > the upgrade? I guess not but warning would be probably useful. What > solution would you prefer, Rob? I don't know all the callers of this. It may be perfectly safe to assume that a serverid is always there, but the implication if it isn't is that some tracking cert won't be updated properly right? That potentially could mean no renewal. So the consequences could be severe, I just don't know the likelihood. In other words, a comment (# can never get here) might be perfectly adequate. rob > >> >>> freeipa-dkupka-0087.1 >>> freeipa-dkupka-0088.1 >>> freeipa-tjaalton-0011.2 >>> freeipa-dkupka-0092.0 >>> >>> >>> > > From mbasti at redhat.com Wed Feb 24 14:13:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 15:13:01 +0100 Subject: [Freeipa-devel] [PATCH 0421] Make PTR records check optional for IPA installation Message-ID: <56CDBA6D.5000803@redhat.com> https://fedorahosted.org/freeipa/ticket/5686 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0421-Make-PTR-records-check-optional-for-IPA-installation.patch Type: text/x-patch Size: 1957 bytes Desc: not available URL: From sbose at redhat.com Wed Feb 24 14:20:00 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 24 Feb 2016 15:20:00 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <56CDA2BB.9060508@redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> Message-ID: <20160224142000.GC7535@p.redhat.com> On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: > On 02/16/2016 02:23 PM, Martin Babinsky wrote: > >Hi list, > > > >WARNING: huge brain dump ahead. > > > >During investigation of https://fedorahosted.org/freeipa/ticket/4305 me > >and Petr Spaced (CC'ed) came to a conclusion that the IPA realm > >autodiscovery code used by ipa-client-install is so convoluted, complex > >and hard to understand that the cost of fixing a bug/adding a behavioral > >change (there are some other tickets dealing with ipadiscovery, e.g. see > >https://fedorahosted.org/freeipa/ticket/5270 > >https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher > >that a more large-scale rewrite of the module and related codebase. > > > >Since we plan to do some general refactoring work anyway, I would like > >to discuss the possible course of action we may take to tackle this > >issue. I would like to present the following options we have been > >discussing so far: > > > >1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") > > > >We may take the existing IPADiscovery class and try rewrite it in order > >to get a more concise and deterministic code, which will: > > > >* rely more on python-dns and answers provided by resolver (e.g. we are > >directly parsing resolv.conf for available domains when we can ask the > >resolver to get domains for us) > >* be more pythonic (replace error codes with thrown exceptions, clean up > >numerous C-isms etc.) > >* not try to outsmart user when server/realm/domain is specified > >beforehand. Currently, even if you specify all three options, there is > >still some DNS discovery performed, hence bug #4305. I think that one > >you specify server(s), not magic should be performed and the discovery > >process should be reduced to checking whether they are IPA servers and > >pull all other info (like realm) from them. > > > >This may be a considerable effort requiring some time to implement and > >get right, but IMHO still comparable to the time spent iteratively > >placing 'if' statements into the existing code and hoping to not break > >anything. I would even argue it is not worth the effort because we can > > > >2.) Use realmd dbus interface to do DNS discovery > > > >I have attached aquick and dirty script I have slapped together to > >leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm > >discovery for us. This has a lot of appeal to me since we are leveraging > >existing codebase for DNS discovery and will have to handle only cases > >when the user manually specifies a list of IPA servers for the client. > > > >This however pulls in realmd as a (potentially circular) dependency for > >ipa client, and when we find bug in the discovery code, we will have to > >poke upstream (Stef or Sumit I think) to fix it. > > > >So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: > > > >3.) Split out IPA discovery portion of realmd to a separate C library > >shared between IPA and realmd > > > >may be best. Both projects will have shared codebase (maintained either > >by us or realmd devs), which can be reused also by other people to > >create their own discovery/enrollment solution. This would however > >require sustained and concerted efforts of both teams to create the > >library and possibly rewrite realmd to accommodate this change. > > > >There may be some other options viable for us, if so please mention them > >in a reply. Also please correct any piece of information I got wrong. > > > >TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix > >it. > > > > #3 sounds good from long term perspective. > > In short term, i.e., #4305, we should skip discovery when --on-master is > used. I would prefer #2. Because as seen from the patch it is already working and can easily be used from python. I think this was also one of the reasons why Stef used a DBus service for this instead of a C library which then needs various bindings for python, Java, ruby, Go you name it. About the concerns. rpm-wise realmd has no dependencies on its underlying tools, it will tell which packages must be installed to do the join or will use packagekit to install them on its own. So it is safe to add a realmd dependency to the ipa-client package. And as long as you only use the Discover method realmd would not try to call ipa-client-install, so there is no logical circle either. To avoid an un-needed second discovery when ipa-client-install is not run from the command line but from realmd directly ipa-client-install can skip the realmd call if domain and realm are already given on the command line because realmd will set both options when calling ipa-client-install. And if there is a bug you have to poke the maintainer of the library or realmd either way. bye, Sumit > -- > Petr Vobornik > > -- > 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 simo at redhat.com Wed Feb 24 14:25:46 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 24 Feb 2016 09:25:46 -0500 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56CD7117.8000202@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> Message-ID: <1456323946.6599.254.camel@redhat.com> On Wed, 2016-02-24 at 10:00 +0100, Martin Kosek wrote: > On 02/23/2016 06:59 PM, Petr Spacek wrote: > > On 23.2.2016 18:14, Simo Sorce wrote: > ... > >> More seriously I think it is a great idea, but too premature to get all > >> the way there now. We need to build schema and CLI that will allow us to > >> get there without having to completely change interfaces if at all > >> possible or minimizing any disruption in the tools. > > > > Actually the backwards compatibility is the main worry which led to this idea > > with links. > > > > If we release first version of locations with custom priorities etc. we will > > have support the schema (which will be different) and API (which will be later > > unnecessary) forever. > > > > If we skip this intermediate phase with hand-made configuration we can save > > all the headache with upgrades to more automatic solution later on. > > > > > > Maybe we should invert the order: > > Start with locations + links with administrative metric and add hand-tweaking > > capabilities later (if necessary). > > > > IMHO locations + links with administrative metric will be easier to implement > > than the first version. > > > > Just thinking aloud ... > > Makes sense to me, I would have the same worry as Petr, that we would break > something if we decide moving to links based solution later. Maybe I am missing something, but in order to generate the proper SRV records we need priority and weights anyway, either by entering them manually or by autogenerating them from some other piece of information in the framework. So given this information is needed anyway why would it become a problem to retain it in the future if we enable a tool the simply autogenerates this information ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Wed Feb 24 14:30:40 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 24 Feb 2016 15:30:40 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <20160224142000.GC7535@p.redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> <20160224142000.GC7535@p.redhat.com> Message-ID: <56CDBE90.8040905@redhat.com> On 02/24/2016 03:20 PM, Sumit Bose wrote: > On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: >> On 02/16/2016 02:23 PM, Martin Babinsky wrote: >>> Hi list, >>> >>> WARNING: huge brain dump ahead. >>> >>> During investigation of https://fedorahosted.org/freeipa/ticket/4305 me >>> and Petr Spaced (CC'ed) came to a conclusion that the IPA realm >>> autodiscovery code used by ipa-client-install is so convoluted, complex >>> and hard to understand that the cost of fixing a bug/adding a behavioral >>> change (there are some other tickets dealing with ipadiscovery, e.g. see >>> https://fedorahosted.org/freeipa/ticket/5270 >>> https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher >>> that a more large-scale rewrite of the module and related codebase. >>> >>> Since we plan to do some general refactoring work anyway, I would like >>> to discuss the possible course of action we may take to tackle this >>> issue. I would like to present the following options we have been >>> discussing so far: >>> >>> 1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") >>> >>> We may take the existing IPADiscovery class and try rewrite it in order >>> to get a more concise and deterministic code, which will: >>> >>> * rely more on python-dns and answers provided by resolver (e.g. we are >>> directly parsing resolv.conf for available domains when we can ask the >>> resolver to get domains for us) >>> * be more pythonic (replace error codes with thrown exceptions, clean up >>> numerous C-isms etc.) >>> * not try to outsmart user when server/realm/domain is specified >>> beforehand. Currently, even if you specify all three options, there is >>> still some DNS discovery performed, hence bug #4305. I think that one >>> you specify server(s), not magic should be performed and the discovery >>> process should be reduced to checking whether they are IPA servers and >>> pull all other info (like realm) from them. >>> >>> This may be a considerable effort requiring some time to implement and >>> get right, but IMHO still comparable to the time spent iteratively >>> placing 'if' statements into the existing code and hoping to not break >>> anything. I would even argue it is not worth the effort because we can >>> >>> 2.) Use realmd dbus interface to do DNS discovery >>> >>> I have attached aquick and dirty script I have slapped together to >>> leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm >>> discovery for us. This has a lot of appeal to me since we are leveraging >>> existing codebase for DNS discovery and will have to handle only cases >>> when the user manually specifies a list of IPA servers for the client. >>> >>> This however pulls in realmd as a (potentially circular) dependency for >>> ipa client, and when we find bug in the discovery code, we will have to >>> poke upstream (Stef or Sumit I think) to fix it. >>> >>> So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: >>> >>> 3.) Split out IPA discovery portion of realmd to a separate C library >>> shared between IPA and realmd >>> >>> may be best. Both projects will have shared codebase (maintained either >>> by us or realmd devs), which can be reused also by other people to >>> create their own discovery/enrollment solution. This would however >>> require sustained and concerted efforts of both teams to create the >>> library and possibly rewrite realmd to accommodate this change. >>> >>> There may be some other options viable for us, if so please mention them >>> in a reply. Also please correct any piece of information I got wrong. >>> >>> TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix >>> it. >>> >> >> #3 sounds good from long term perspective. >> >> In short term, i.e., #4305, we should skip discovery when --on-master is >> used. > > I would prefer #2. Because as seen from the patch it is already working > and can easily be used from python. I think this was also one of the > reasons why Stef used a DBus service for this instead of a C library > which then needs various bindings for python, Java, ruby, Go you name > it. > This approach is also my favorite. However, my (and several of my colleagues) concern is that https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in kickstart environment. I don't know how much of an issue is this, I guess it completely precludes automatic enrollment during machine provisioning. > About the concerns. rpm-wise realmd has no dependencies on its > underlying tools, it will tell which packages must be installed to do > the join or will use packagekit to install them on its own. So it is > safe to add a realmd dependency to the ipa-client package. And as long > as you only use the Discover method realmd would not try to call > ipa-client-install, so there is no logical circle either. To avoid an > un-needed second discovery when ipa-client-install is not run from the > command line but from realmd directly ipa-client-install can skip the > realmd call if domain and realm are already given on the command line > because realmd will set both options when calling ipa-client-install. > And if there is a bug you have to poke the maintainer of the library or > realmd either way. > > > > bye, > Sumit > > >> -- >> Petr Vobornik >> >> -- >> 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 > -- Martin^3 Babinsky From mbasti at redhat.com Wed Feb 24 14:43:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 15:43:34 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements In-Reply-To: <56CDA3E3.4070407@redhat.com> References: <56C47A58.6050207@redhat.com> <56CAC021.8080906@redhat.com> <56CC86E8.1040501@redhat.com> <56CD7BAB.4040906@redhat.com> <56CD9CF3.2040905@redhat.com> <56CDA3E3.4070407@redhat.com> Message-ID: <56CDC196.8020108@redhat.com> On 24.02.2016 13:36, Jan Cholasta wrote: > On 24.2.2016 13:07, Martin Basti wrote: >> >> >> On 24.02.2016 10:45, Jan Cholasta wrote: >>> On 23.2.2016 17:20, Martin Basti wrote: >>>> >>>> >>>> On 22.02.2016 09:00, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 17.2.2016 14:49, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5631 >>>>>> >>>>>> Patch attached (for master, 4.3, 4.2) >>>>> >>>>> 1) All the replication agreement permission ACIs should be located in >>>>> the same entry. Currently "Read Replication Agreements" is in >>>>> "cn=config" and everything else in "cn=mapping tree,cn=config", so I >>>>> guess "cn=mapping tree,cn=config" makes more sense. >>>>> >>>>> >>>>> 2) Instead of literal DN('cn=permissions,cn=pbac'), use >>>>> api.env.container_permissions. >>>>> >>>>> >>>>> 3) IMO the removal of managed permission attributes could be a little >>>>> bit more robust. You should check that the original entry contains >>>>> all >>>>> the required values before touching it (objectclass=ipapermissionv2, >>>>> ipapermissiontype=V2, ipapermissiontype=MANAGED) and remove only the >>>>> values that need to be removed, instead of just overwriting >>>>> everything. >>>>> >>>>> >>>>> Honza >>>>> >>>> Updated patch attached. >>> >>> The patch does not apply on ipa-4-2. >>> >> I will send it later. >> >>> Also this bit in replica-acis.ldif is redundant: >>> >>> + >>> +dn: cn=mapping tree,cn=config >>> +changetype: modify >>> +add: aci >> All related ACIs to replication are in both replica-acis.ldif and >> 20-aci.update. >> I just do not want to mess it more than it is. > > What I'm trying to say is that: > > dn: cn=mapping tree,cn=config > changetype: modify > add: aci > aci: $ACI1 > > dn: cn=mapping tree,cn=config > changetype: modify > add: aci > aci: $ACI2 > > is the same as: > > dn: cn=mapping tree,cn=config > changetype: modify > add: aci > aci: $ACI1 > aci: $ACI2 > > . You actually have it right in 20-aci.update, but not in > replica-acis.ldif. > I made it in that way to keep consistency in the replica-acis.ldif file. Patch for 4-2 added -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbasti-0413.2-fix-permission-Read-Replication-Agreements.patch Type: text/x-patch Size: 20645 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0413.2-fix-permission-Read-Replication-Agreements.patch Type: text/x-patch Size: 21364 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 24 14:53:40 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 15:53:40 +0100 Subject: [Freeipa-devel] [PATCH 0420] Set BuildRequires to pylint 1.4 In-Reply-To: <20160224123853.GC1234@mail.corp.redhat.com> References: <56CC8424.3@redhat.com> <20160223164158.GF3452@mail.corp.redhat.com> <56CCB1A3.1070000@redhat.com> <20160224085028.GB1234@mail.corp.redhat.com> <56CD808D.4060604@redhat.com> <20160224123853.GC1234@mail.corp.redhat.com> Message-ID: <56CDC3F4.6070808@redhat.com> On 24.02.2016 13:38, Lukas Slebodnik wrote: > On (24/02/16 11:06), Petr Vobornik wrote: >> On 02/24/2016 09:50 AM, Lukas Slebodnik wrote: >>> On (23/02/16 14:23), Rob Crittenden wrote: >>>> Lukas Slebodnik wrote: >>>>> On (23/02/16 17:09), Martin Basti wrote: >>>>>> We cannot guarantee that versions older than 1.4 will work with freeipa code. >>>>>> >>>>>> Patch attached. >>>>> >From a59e72a0b87231c0f2e0d737057550dd532feed7 Mon Sep 17 00:00:00 2001 >>>>>> From: Martin Basti >>>>>> Date: Tue, 23 Feb 2016 16:58:07 +0100 >>>>>> Subject: [PATCH] Set BuildRequires to pylint >= 1.4 >>>>>> >>>>>> We can guarantee that only pylint 1.4 and newer will work >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/5615 >>>>>> --- >>>>>> freeipa.spec.in | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in >>>>>> index 54a11bfc8cced643c19c29c5ada70bacf7540395..219c5ca2f13eaac14746ec4689ba611bbc6fc377 100644 >>>>>> --- a/freeipa.spec.in >>>>>> +++ b/freeipa.spec.in >>>>>> @@ -76,7 +76,7 @@ BuildRequires: python-netaddr >>>>>> BuildRequires: python-gssapi >= 1.1.2 >>>>>> BuildRequires: python-rhsm >>>>>> BuildRequires: pyOpenSSL >>>>>> -BuildRequires: pylint >= 1.0 >>>>>> +BuildRequires: pylint >= 1.4 >>>>> I can build rpms even withour pylint and pylint is not executed >>>>> anywhere in spec file. (in other words, my patch was rejected) >>>>> Why does it need to be in BuildRequires? >>>> pylint is part of the in-tree build process (make rpms). It is not >>>> executed when building upstream packages. >>>> >>> It's not buildrequires becuase I can rebuild src.rpm >>> without it. It should not be there or it should be optional >>> to do not break developer workflow. >>> >>> e.g. "%bcond_with extra_dependencies_for_pylint" >>> >>> The upstream spec files is close to the fedora spec file >>> and pylint is istalled there even though it's not used. >>> >>> Another use case is coverity scan. >>> >>> LS >>> >> Basically I agree with Lukas but this patch is the way how we do build >> upstream right now. >> >> The proposed change would required more refactoring of build process and is >> out of scope of this ticket. Feel free to open a ticket for it. It should not >> block this patch. > I have a different opinion here. > > The ticket #5615 says: "Prepare IPA for pylint 1.5.2" > It does not say anything about minimal requirement on pylint 1.4 > even though all current version of fedora has pylint 1.4. > > Older version of pylint (1.3.1) is available only in fedora 20. > Which is out of support for more than a year. > Patch is neither required for fedora nor for ticket #5615 > > However there is only pylint-1.3.1 in epel7 > And it would cause issues there. > > Summary: This patch does not solve anything. > > LS > We can discard this patch, I do not insist on it, and I do not plan to spent time on it. In future we would add minimal dependency to pylint 1.5.x to have better checks accessible.` From npmccallum at redhat.com Wed Feb 24 14:55:10 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 24 Feb 2016 09:55:10 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456105856.6599.132.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> Message-ID: <1456325710.3148.10.camel@redhat.com> On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > The above (pseudo) pull request contains four patches against > > FreeIPA > > to enable the insertion of Authentication Indicators into Kerberos > > tickets. The basic flow looks like this. > > > > First, we patch ipa-pwd-extop to return a control indicating what > > authentication method succeeded resulting in a successful bind. > > > > Second, we patch ipa-otpd to check the returned control to ensure > > that > > the bind resulted from an otp validation. > > > > Third, we patch ipa-kdb to enable the KDC to return either the > > encrypted timestamp or encrypted challenge preauth mechanism when > > the > > user is configured for optional 2FA logins. Clients can then decide > > whether to do 1FA or 2FA login (for kinit, sane behavior already > > exists). > > > > Forth, we patch ipa-kdb again to insert hard-coded authentication > > indicators for either OTP or RADIUS. > > > > Some explanation is required for the first two patches. Currently, > > it > > is possible to do a 1FA through the otp preauthentication mechanism > > if > > the user is configured for doing optional 2FA. However, because we > > want > > to insert an authentication indicator in this code path, we need to > > guarantee that a request going through the otp preauth mechanism > > actually validates an OTP. This is the purpose of the control. > > > > Items still on the TODO list: > > > > ? * Authentication Indicator enforcement > > ????- Upstream libkrb5 needs to grow funcs for reading indicators > > ????- Schema change to add indicators multi-value attr to services > > ????- ipa-kdb needs to implement check_policy_tgs() > > > > > > ? * SSSD needs to learn to handle optional 2FA > > > > I will write up a project page for all of this tomorrow. But this > > small > > code basically amounts to my brainstorming. It is not ready for > > merge, > > just basic review. > > > It looks mostly ok, however the LDAP control part needs to be done as > a > request/response pair. > A client that wishes to know what kind of authentication happened > should > send a request control, and only in that case , the server will send > the > associated reply control with the requested information. I just pushed a new version of the control (now merged into a single patch):?https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de39 f28eb637f66199da7e9225 In this version the client sends a critical control with no content indicating that the server must validate an OTP. If the LDAP server doesn't support the control (for whatever reason), bind will fail. If the LDAP server doesn't validate an OTP (for whatever reason), bind will fail. This approach is simpler and doesn't require a request/response control pair. Nathaniel From sbose at redhat.com Wed Feb 24 14:55:16 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 24 Feb 2016 15:55:16 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <56CDBE90.8040905@redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> <20160224142000.GC7535@p.redhat.com> <56CDBE90.8040905@redhat.com> Message-ID: <20160224145516.GF7535@p.redhat.com> On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote: > On 02/24/2016 03:20 PM, Sumit Bose wrote: > >On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: > >>On 02/16/2016 02:23 PM, Martin Babinsky wrote: > >>>Hi list, > >>> > >>>WARNING: huge brain dump ahead. > >>> > >>>During investigation of https://fedorahosted.org/freeipa/ticket/4305 me > >>>and Petr Spaced (CC'ed) came to a conclusion that the IPA realm > >>>autodiscovery code used by ipa-client-install is so convoluted, complex > >>>and hard to understand that the cost of fixing a bug/adding a behavioral > >>>change (there are some other tickets dealing with ipadiscovery, e.g. see > >>>https://fedorahosted.org/freeipa/ticket/5270 > >>>https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher > >>>that a more large-scale rewrite of the module and related codebase. > >>> > >>>Since we plan to do some general refactoring work anyway, I would like > >>>to discuss the possible course of action we may take to tackle this > >>>issue. I would like to present the following options we have been > >>>discussing so far: > >>> > >>>1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") > >>> > >>>We may take the existing IPADiscovery class and try rewrite it in order > >>>to get a more concise and deterministic code, which will: > >>> > >>>* rely more on python-dns and answers provided by resolver (e.g. we are > >>>directly parsing resolv.conf for available domains when we can ask the > >>>resolver to get domains for us) > >>>* be more pythonic (replace error codes with thrown exceptions, clean up > >>>numerous C-isms etc.) > >>>* not try to outsmart user when server/realm/domain is specified > >>>beforehand. Currently, even if you specify all three options, there is > >>>still some DNS discovery performed, hence bug #4305. I think that one > >>>you specify server(s), not magic should be performed and the discovery > >>>process should be reduced to checking whether they are IPA servers and > >>>pull all other info (like realm) from them. > >>> > >>>This may be a considerable effort requiring some time to implement and > >>>get right, but IMHO still comparable to the time spent iteratively > >>>placing 'if' statements into the existing code and hoping to not break > >>>anything. I would even argue it is not worth the effort because we can > >>> > >>>2.) Use realmd dbus interface to do DNS discovery > >>> > >>>I have attached aquick and dirty script I have slapped together to > >>>leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm > >>>discovery for us. This has a lot of appeal to me since we are leveraging > >>>existing codebase for DNS discovery and will have to handle only cases > >>>when the user manually specifies a list of IPA servers for the client. > >>> > >>>This however pulls in realmd as a (potentially circular) dependency for > >>>ipa client, and when we find bug in the discovery code, we will have to > >>>poke upstream (Stef or Sumit I think) to fix it. > >>> > >>>So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: > >>> > >>>3.) Split out IPA discovery portion of realmd to a separate C library > >>>shared between IPA and realmd > >>> > >>>may be best. Both projects will have shared codebase (maintained either > >>>by us or realmd devs), which can be reused also by other people to > >>>create their own discovery/enrollment solution. This would however > >>>require sustained and concerted efforts of both teams to create the > >>>library and possibly rewrite realmd to accommodate this change. > >>> > >>>There may be some other options viable for us, if so please mention them > >>>in a reply. Also please correct any piece of information I got wrong. > >>> > >>>TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix > >>>it. > >>> > >> > >>#3 sounds good from long term perspective. > >> > >>In short term, i.e., #4305, we should skip discovery when --on-master is > >>used. > > > >I would prefer #2. Because as seen from the patch it is already working > >and can easily be used from python. I think this was also one of the > >reasons why Stef used a DBus service for this instead of a C library > >which then needs various bindings for python, Java, ruby, Go you name > >it. > > > > This approach is also my favorite. However, my (and several of my > colleagues) concern is that > https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in > kickstart environment. I don't know how much of an issue is this, I guess it > completely precludes automatic enrollment during machine provisioning. realmd has the --dbus-peer option. So I guess it might be possible that realmd can be started by ipa-client-install directly in this case and allow communication over a socket pair. I'm not sure how hard or easy this would be in python. Stef, do you have some pointers how to use dbus-peer from python? bye, Sumit > > >About the concerns. rpm-wise realmd has no dependencies on its > >underlying tools, it will tell which packages must be installed to do > >the join or will use packagekit to install them on its own. So it is > >safe to add a realmd dependency to the ipa-client package. And as long > >as you only use the Discover method realmd would not try to call > >ipa-client-install, so there is no logical circle either. To avoid an > >un-needed second discovery when ipa-client-install is not run from the > >command line but from realmd directly ipa-client-install can skip the > >realmd call if domain and realm are already given on the command line > >because realmd will set both options when calling ipa-client-install. > > >And if there is a bug you have to poke the maintainer of the library or > >realmd either way. > > > > > > > >bye, > >Sumit > > > > > >>-- > >>Petr Vobornik > >> > >>-- > >>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 > > > > > -- > Martin^3 Babinsky From mbabinsk at redhat.com Wed Feb 24 15:03:18 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 24 Feb 2016 16:03:18 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <56CDA2BB.9060508@redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> Message-ID: <56CDC636.5020504@redhat.com> On 02/24/2016 01:31 PM, Petr Vobornik wrote: > On 02/16/2016 02:23 PM, Martin Babinsky wrote: >> Hi list, >> >> WARNING: huge brain dump ahead. >> >> During investigation of https://fedorahosted.org/freeipa/ticket/4305 me >> and Petr Spaced (CC'ed) came to a conclusion that the IPA realm >> autodiscovery code used by ipa-client-install is so convoluted, complex >> and hard to understand that the cost of fixing a bug/adding a behavioral >> change (there are some other tickets dealing with ipadiscovery, e.g. see >> https://fedorahosted.org/freeipa/ticket/5270 >> https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher >> that a more large-scale rewrite of the module and related codebase. >> >> Since we plan to do some general refactoring work anyway, I would like >> to discuss the possible course of action we may take to tackle this >> issue. I would like to present the following options we have been >> discussing so far: >> >> 1.) Do a substantial rewrite of existing code >> ("ipaclient/ipadiscovery.py") >> >> We may take the existing IPADiscovery class and try rewrite it in order >> to get a more concise and deterministic code, which will: >> >> * rely more on python-dns and answers provided by resolver (e.g. we are >> directly parsing resolv.conf for available domains when we can ask the >> resolver to get domains for us) >> * be more pythonic (replace error codes with thrown exceptions, clean up >> numerous C-isms etc.) >> * not try to outsmart user when server/realm/domain is specified >> beforehand. Currently, even if you specify all three options, there is >> still some DNS discovery performed, hence bug #4305. I think that one >> you specify server(s), not magic should be performed and the discovery >> process should be reduced to checking whether they are IPA servers and >> pull all other info (like realm) from them. >> >> This may be a considerable effort requiring some time to implement and >> get right, but IMHO still comparable to the time spent iteratively >> placing 'if' statements into the existing code and hoping to not break >> anything. I would even argue it is not worth the effort because we can >> >> 2.) Use realmd dbus interface to do DNS discovery >> >> I have attached aquick and dirty script I have slapped together to >> leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm >> discovery for us. This has a lot of appeal to me since we are leveraging >> existing codebase for DNS discovery and will have to handle only cases >> when the user manually specifies a list of IPA servers for the client. >> >> This however pulls in realmd as a (potentially circular) dependency for >> ipa client, and when we find bug in the discovery code, we will have to >> poke upstream (Stef or Sumit I think) to fix it. >> >> So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion >> to: >> >> 3.) Split out IPA discovery portion of realmd to a separate C library >> shared between IPA and realmd >> >> may be best. Both projects will have shared codebase (maintained either >> by us or realmd devs), which can be reused also by other people to >> create their own discovery/enrollment solution. This would however >> require sustained and concerted efforts of both teams to create the >> library and possibly rewrite realmd to accommodate this change. >> >> There may be some other options viable for us, if so please mention them >> in a reply. Also please correct any piece of information I got wrong. >> >> TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix >> it. >> > > #3 sounds good from long term perspective. > > In short term, i.e., #4305, we should skip discovery when --on-master is > used. That was implemented already here https://www.redhat.com/archives/freeipa-devel/2015-October/msg00125.html along with some minor refactoring, but Petr Spacek perma-nacked the patchset. Alternative approach for #4305 would be to disable search for Kerberos KDC when list of servers, domain and realm is specified, since it always runs regardless of what was forced during discovery and is the only thing that causes #4305. -- Martin^3 Babinsky From dkupka at redhat.com Wed Feb 24 15:08:14 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 24 Feb 2016 16:08:14 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <20160224145516.GF7535@p.redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> <20160224142000.GC7535@p.redhat.com> <56CDBE90.8040905@redhat.com> <20160224145516.GF7535@p.redhat.com> Message-ID: <56CDC75E.1080004@redhat.com> On 24/02/16 15:55, Sumit Bose wrote: > On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote: >> On 02/24/2016 03:20 PM, Sumit Bose wrote: >>> On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: >>>> On 02/16/2016 02:23 PM, Martin Babinsky wrote: >>>>> Hi list, >>>>> >>>>> WARNING: huge brain dump ahead. >>>>> >>>>> During investigation of https://fedorahosted.org/freeipa/ticket/4305 me >>>>> and Petr Spaced (CC'ed) came to a conclusion that the IPA realm >>>>> autodiscovery code used by ipa-client-install is so convoluted, complex >>>>> and hard to understand that the cost of fixing a bug/adding a behavioral >>>>> change (there are some other tickets dealing with ipadiscovery, e.g. see >>>>> https://fedorahosted.org/freeipa/ticket/5270 >>>>> https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher >>>>> that a more large-scale rewrite of the module and related codebase. >>>>> >>>>> Since we plan to do some general refactoring work anyway, I would like >>>>> to discuss the possible course of action we may take to tackle this >>>>> issue. I would like to present the following options we have been >>>>> discussing so far: >>>>> >>>>> 1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") >>>>> >>>>> We may take the existing IPADiscovery class and try rewrite it in order >>>>> to get a more concise and deterministic code, which will: >>>>> >>>>> * rely more on python-dns and answers provided by resolver (e.g. we are >>>>> directly parsing resolv.conf for available domains when we can ask the >>>>> resolver to get domains for us) >>>>> * be more pythonic (replace error codes with thrown exceptions, clean up >>>>> numerous C-isms etc.) >>>>> * not try to outsmart user when server/realm/domain is specified >>>>> beforehand. Currently, even if you specify all three options, there is >>>>> still some DNS discovery performed, hence bug #4305. I think that one >>>>> you specify server(s), not magic should be performed and the discovery >>>>> process should be reduced to checking whether they are IPA servers and >>>>> pull all other info (like realm) from them. >>>>> >>>>> This may be a considerable effort requiring some time to implement and >>>>> get right, but IMHO still comparable to the time spent iteratively >>>>> placing 'if' statements into the existing code and hoping to not break >>>>> anything. I would even argue it is not worth the effort because we can >>>>> >>>>> 2.) Use realmd dbus interface to do DNS discovery >>>>> >>>>> I have attached aquick and dirty script I have slapped together to >>>>> leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm >>>>> discovery for us. This has a lot of appeal to me since we are leveraging >>>>> existing codebase for DNS discovery and will have to handle only cases >>>>> when the user manually specifies a list of IPA servers for the client. >>>>> >>>>> This however pulls in realmd as a (potentially circular) dependency for >>>>> ipa client, and when we find bug in the discovery code, we will have to >>>>> poke upstream (Stef or Sumit I think) to fix it. >>>>> >>>>> So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: >>>>> >>>>> 3.) Split out IPA discovery portion of realmd to a separate C library >>>>> shared between IPA and realmd >>>>> >>>>> may be best. Both projects will have shared codebase (maintained either >>>>> by us or realmd devs), which can be reused also by other people to >>>>> create their own discovery/enrollment solution. This would however >>>>> require sustained and concerted efforts of both teams to create the >>>>> library and possibly rewrite realmd to accommodate this change. >>>>> >>>>> There may be some other options viable for us, if so please mention them >>>>> in a reply. Also please correct any piece of information I got wrong. >>>>> >>>>> TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix >>>>> it. >>>>> >>>> >>>> #3 sounds good from long term perspective. >>>> >>>> In short term, i.e., #4305, we should skip discovery when --on-master is >>>> used. >>> >>> I would prefer #2. Because as seen from the patch it is already working >>> and can easily be used from python. I think this was also one of the >>> reasons why Stef used a DBus service for this instead of a C library >>> which then needs various bindings for python, Java, ruby, Go you name >>> it. >>> >> >> This approach is also my favorite. However, my (and several of my >> colleagues) concern is that >> https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in >> kickstart environment. I don't know how much of an issue is this, I guess it >> completely precludes automatic enrollment during machine provisioning. > > realmd has the --dbus-peer option. So I guess it might be possible that > realmd can be started by ipa-client-install directly in this case and > allow communication over a socket pair. I'm not sure how hard or easy > this would be in python. > > Stef, do you have some pointers how to use dbus-peer from python? > > bye, > Sumit > We have already done something similar with certmonger. You can look into ipapython/certmonger.py >> >>> About the concerns. rpm-wise realmd has no dependencies on its >>> underlying tools, it will tell which packages must be installed to do >>> the join or will use packagekit to install them on its own. So it is >>> safe to add a realmd dependency to the ipa-client package. And as long >>> as you only use the Discover method realmd would not try to call >>> ipa-client-install, so there is no logical circle either. To avoid an >>> un-needed second discovery when ipa-client-install is not run from the >>> command line but from realmd directly ipa-client-install can skip the >>> realmd call if domain and realm are already given on the command line >>> because realmd will set both options when calling ipa-client-install. >> >>> And if there is a bug you have to poke the maintainer of the library or >>> realmd either way. >>> >>> >>> >>> bye, >>> Sumit >>> >>> >>>> -- >>>> Petr Vobornik >>>> >>>> -- >>>> 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 >>> >> >> >> -- >> Martin^3 Babinsky > -- David Kupka From tbordaz at redhat.com Wed Feb 24 15:30:10 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 24 Feb 2016 16:30:10 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56A1018D.101@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> Message-ID: <56CDCC82.30108@redhat.com> On 01/21/2016 05:04 PM, Martin Babinsky wrote: > On 01/21/2016 01:37 PM, thierry bordaz wrote: >> >> >> > Hi Thierry, > > I have couple of comments to your patch: > > 1.) > there is a number of PEP8 errors in the patch > (http://paste.fedoraproject.org/313246/33893701), please fix them. > > See http://www.freeipa.org/page/Python_Coding_Style for our > conventions used in Python code. > > 2.) > + DNA_BIND_METHOD = "dnaRemoteBindMethod" > + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" > + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config' > + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN > > Uppercase names are usually reserved for module-level constants. OTOH, > local variables should be lowercase. Also you can instantiate > dna_config_base directly as DN, using 2-member tuples, i. e: > > """ > dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric > Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) > """ > > When passing DN object to the formatting functions/operators, it is > automatically converted to string so no need to hold string and DN > object separately. This is done in other places (see function/methods > in replication.py). > > 3.) > > + for i in range(len(entries)) : > + > + mod = [] > + if entries[i].single_value.get(DNA_BIND_METHOD) != method: > + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, method)) > + > + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != > protocol: > + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, > protocol)) > > > please use idiomatic Python when handling list of entries, e.g.: > > """ > for entry in entries: > mod = [] > if entry.single_value.get(DNA_BIND_METHOD) != method: > ... > """ > > 4.) I think that this method should in DSInstance class since it deals > with directory server configuration. Service is a parent object of all > other service installers/configurators and should contain only methods > common to more children. > > 5.) Since the method is called from every installer, it could be > beneficial to call it in DSInstance.__common_post_setup() as a part of > Directory server installation. Is there any reason why this is not the > case? > > 6.) > > + while attempt != MAX_WAIT: > + try: > + entries = conn.get_entries(sharedcfgdn, > scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) > + break > + except errors.NotFound: > + root_logger.debug("So far enable not find DNA shared > config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn, > sharedcfgdn)) > + attempt = attempt + 1 > + time.sleep(2) > + continue > + > + # safety checking > + # there is no return, if there are several entries, as a > workaround of #5510 > + if len(entries) != 1: > > I am quite afraid what would happen if the server does not return any > entries until 30 s timeout. The code will then continue to the > condition which can potentially test an uninitialized variable and > blow up with 'NameError'. This should be handled more robustly, e. g. > raise an exception when a timeout is reached and no entries were > returned. > > 7.) > > + if len(mod) > 0: > > A Pythonic way to test for non-empty container is > > """ > if mods: > # do stuff > """ > > since an empty list/dict/set evaluates to False and non-empty > containers are True. > > > 8.) > > + entry = conn.get_entry(entries[i].dn) > + if entry.single_value.get(DNA_BIND_METHOD) != method: > + root_logger.error("Fail to set SASL/GSSAPI bind > method to %s" % (entries[i].dn)) > + if entry.single_value.get(DNA_CONN_PROTOCOL) != > protocol: > + root_logger.error("Fail to set LDAP protocol to > %s" % (entries[i].dn)) > > rather than re-fetching the modified entry and testing what happened, > you can just catch an exception raised by unsuccessfull mod and log an > error like this: > > """ > try: > conn.modify_s(entry.dn, mod) > except Exception as e: > root_logger.error("Failed to modify entry {}: {}".format(entry, e)) > """ > > as a matter of fact, if the modify_s operation would fail for some > reason, an ldap exception would be raised and you checks would not > even be executed. > > 9.) > The debug message on line 219 should read "Unable to find DNA shared > config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors > at the end of the method should have "Failed" instead of "Fail". > Hi Martin, Finally tested... here is the updated patch. Thanks for you patience thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0017-2-configure-DNA-plugin-shared-config-entries-to-allow-.patch Type: text/x-patch Size: 8010 bytes Desc: not available URL: From sbose at redhat.com Wed Feb 24 15:30:54 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 24 Feb 2016 16:30:54 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <56CDC75E.1080004@redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> <20160224142000.GC7535@p.redhat.com> <56CDBE90.8040905@redhat.com> <20160224145516.GF7535@p.redhat.com> <56CDC75E.1080004@redhat.com> Message-ID: <20160224153054.GI7535@p.redhat.com> On Wed, Feb 24, 2016 at 04:08:14PM +0100, David Kupka wrote: > On 24/02/16 15:55, Sumit Bose wrote: > >On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote: > >>On 02/24/2016 03:20 PM, Sumit Bose wrote: > >>>On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: > >>>>On 02/16/2016 02:23 PM, Martin Babinsky wrote: > >>>>>Hi list, > >>>>> > >>>>>WARNING: huge brain dump ahead. > >>>>> > >>>>>During investigation of https://fedorahosted.org/freeipa/ticket/4305 me > >>>>>and Petr Spaced (CC'ed) came to a conclusion that the IPA realm > >>>>>autodiscovery code used by ipa-client-install is so convoluted, complex > >>>>>and hard to understand that the cost of fixing a bug/adding a behavioral > >>>>>change (there are some other tickets dealing with ipadiscovery, e.g. see > >>>>>https://fedorahosted.org/freeipa/ticket/5270 > >>>>>https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher > >>>>>that a more large-scale rewrite of the module and related codebase. > >>>>> > >>>>>Since we plan to do some general refactoring work anyway, I would like > >>>>>to discuss the possible course of action we may take to tackle this > >>>>>issue. I would like to present the following options we have been > >>>>>discussing so far: > >>>>> > >>>>>1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") > >>>>> > >>>>>We may take the existing IPADiscovery class and try rewrite it in order > >>>>>to get a more concise and deterministic code, which will: > >>>>> > >>>>>* rely more on python-dns and answers provided by resolver (e.g. we are > >>>>>directly parsing resolv.conf for available domains when we can ask the > >>>>>resolver to get domains for us) > >>>>>* be more pythonic (replace error codes with thrown exceptions, clean up > >>>>>numerous C-isms etc.) > >>>>>* not try to outsmart user when server/realm/domain is specified > >>>>>beforehand. Currently, even if you specify all three options, there is > >>>>>still some DNS discovery performed, hence bug #4305. I think that one > >>>>>you specify server(s), not magic should be performed and the discovery > >>>>>process should be reduced to checking whether they are IPA servers and > >>>>>pull all other info (like realm) from them. > >>>>> > >>>>>This may be a considerable effort requiring some time to implement and > >>>>>get right, but IMHO still comparable to the time spent iteratively > >>>>>placing 'if' statements into the existing code and hoping to not break > >>>>>anything. I would even argue it is not worth the effort because we can > >>>>> > >>>>>2.) Use realmd dbus interface to do DNS discovery > >>>>> > >>>>>I have attached aquick and dirty script I have slapped together to > >>>>>leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm > >>>>>discovery for us. This has a lot of appeal to me since we are leveraging > >>>>>existing codebase for DNS discovery and will have to handle only cases > >>>>>when the user manually specifies a list of IPA servers for the client. > >>>>> > >>>>>This however pulls in realmd as a (potentially circular) dependency for > >>>>>ipa client, and when we find bug in the discovery code, we will have to > >>>>>poke upstream (Stef or Sumit I think) to fix it. > >>>>> > >>>>>So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: > >>>>> > >>>>>3.) Split out IPA discovery portion of realmd to a separate C library > >>>>>shared between IPA and realmd > >>>>> > >>>>>may be best. Both projects will have shared codebase (maintained either > >>>>>by us or realmd devs), which can be reused also by other people to > >>>>>create their own discovery/enrollment solution. This would however > >>>>>require sustained and concerted efforts of both teams to create the > >>>>>library and possibly rewrite realmd to accommodate this change. > >>>>> > >>>>>There may be some other options viable for us, if so please mention them > >>>>>in a reply. Also please correct any piece of information I got wrong. > >>>>> > >>>>>TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix > >>>>>it. > >>>>> > >>>> > >>>>#3 sounds good from long term perspective. > >>>> > >>>>In short term, i.e., #4305, we should skip discovery when --on-master is > >>>>used. > >>> > >>>I would prefer #2. Because as seen from the patch it is already working > >>>and can easily be used from python. I think this was also one of the > >>>reasons why Stef used a DBus service for this instead of a C library > >>>which then needs various bindings for python, Java, ruby, Go you name > >>>it. > >>> > >> > >>This approach is also my favorite. However, my (and several of my > >>colleagues) concern is that > >>https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in > >>kickstart environment. I don't know how much of an issue is this, I guess it > >>completely precludes automatic enrollment during machine provisioning. > > > >realmd has the --dbus-peer option. So I guess it might be possible that > >realmd can be started by ipa-client-install directly in this case and > >allow communication over a socket pair. I'm not sure how hard or easy > >this would be in python. > > > >Stef, do you have some pointers how to use dbus-peer from python? > > > >bye, > >Sumit > > > > We have already done something similar with certmonger. You can look into > ipapython/certmonger.py Great, so it should be possible to use realmd in the same way in a kickstart environment. bye, Sumit > > > >> > >>>About the concerns. rpm-wise realmd has no dependencies on its > >>>underlying tools, it will tell which packages must be installed to do > >>>the join or will use packagekit to install them on its own. So it is > >>>safe to add a realmd dependency to the ipa-client package. And as long > >>>as you only use the Discover method realmd would not try to call > >>>ipa-client-install, so there is no logical circle either. To avoid an > >>>un-needed second discovery when ipa-client-install is not run from the > >>>command line but from realmd directly ipa-client-install can skip the > >>>realmd call if domain and realm are already given on the command line > >>>because realmd will set both options when calling ipa-client-install. > >> > >>>And if there is a bug you have to poke the maintainer of the library or > >>>realmd either way. > >>> > >>> > >>> > >>>bye, > >>>Sumit > >>> > >>> > >>>>-- > >>>>Petr Vobornik > >>>> > >>>>-- > >>>>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 > >>> > >> > >> > >>-- > >>Martin^3 Babinsky > > > > > -- > David Kupka From mbasti at redhat.com Wed Feb 24 16:32:50 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 17:32:50 +0100 Subject: [Freeipa-devel] [PATCH] revert temporal changes in the vault CI test Message-ID: <56CDDB32.509@redhat.com> Workaround for #5538 works, tests can be restored to original state https://fedorahosted.org/freeipa/ticket/5538 Pushed to: master: a14d68749397a52537594da890fb23e994dd04e2 ipa-4-3: 390f6342952b63d6d27648096d70bc3fdd81dc78 From mbasti at redhat.com Wed Feb 24 16:56:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 17:56:47 +0100 Subject: [Freeipa-devel] [PATCH 0423] fix duplicated except Message-ID: <56CDE0CF.2080405@redhat.com> During my playing with pylint, I fixed this issue which allows us to enable additional check in pylint (the nice one). Patch attached, it should go only to master. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0423-Remove-duplicated-except.patch Type: text/x-patch Size: 2219 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 24 17:54:24 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 18:54:24 +0100 Subject: [Freeipa-devel] [PATCH 0424] Pylint: add missing attributes of exceptions to definition in pylint plugin Message-ID: <56CDEE50.5030506@redhat.com> Pylint is not able to handle IPA errors objects, because attributes are added into objects dynamically, and pylint 1.5 reports them as no-member errors. https://fedorahosted.org/freeipa/ticket/5615 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0424-Pylint-add-missing-attributes-of-errors-to-definitio.patch Type: text/x-patch Size: 2021 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 24 18:01:43 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 19:01:43 +0100 Subject: [Freeipa-devel] [PATCH 0422] CI: allow customized DS install test to run under different domain levels Message-ID: <56CDF007.5030200@redhat.com> https://fedorahosted.org/freeipa/ticket/5606 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0422-CI-allow-customized-DS-install-test-to-work-with-dom.patch Type: text/x-patch Size: 4186 bytes Desc: not available URL: From mbasti at redhat.com Wed Feb 24 18:05:41 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 24 Feb 2016 19:05:41 +0100 Subject: [Freeipa-devel] [patch 0034] ipatests: extend permission plugin test with new expected output In-Reply-To: <56CD5D22.9000404@redhat.com> References: <56C1F5C6.2090708@redhat.com> <56C5DA92.4090805@redhat.com> <56CD5D22.9000404@redhat.com> Message-ID: <56CDF0F5.2010506@redhat.com> On 24.02.2016 08:34, Milan Kub?k wrote: > On 02/18/2016 03:52 PM, Milan Kub?k wrote: >> On 02/15/2016 04:59 PM, Milan Kub?k wrote: >>> Patch attached. Applies on ipa-4-3 as well. >>> >>> >>> >> Updated version of patch fixes test_old_permission_plugin as well. >> >> -- >> Milan Kubik >> >> > Review bump. > > -- > Milan Kubik > > NACK [mbasti at dhcp129-96 freeipa-devel]$ git show -U0 | pep8 --diff ./ipatests/test_xmlrpc/test_old_permission_plugin.py:528:80: E501 line too long (95 > 79 characters) ./ipatests/test_xmlrpc/test_old_permission_plugin.py:586:1: E101 indentation contains mixed spaces and tabs ./ipatests/test_xmlrpc/test_old_permission_plugin.py:586:1: W191 indentation contains tabs ./ipatests/test_xmlrpc/test_old_permission_plugin.py:587:1: E101 indentation contains mixed spaces and tabs ./ipatests/test_xmlrpc/test_old_permission_plugin.py:587:80: E501 line too long (95 > 79 characters) ./ipatests/test_xmlrpc/test_old_permission_plugin.py:591:1: E101 indentation contains mixed spaces and tabs ./ipatests/test_xmlrpc/test_old_permission_plugin.py:591:1: W191 indentation contains tabs ./ipatests/test_xmlrpc/test_permission_plugin.py:821:80: E501 line too long (99 > 79 characters) ./ipatests/test_xmlrpc/test_permission_plugin.py:884:80: E501 line too long (99 > 79 characters) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fskola at redhat.com Wed Feb 24 19:07:55 2016 From: fskola at redhat.com (Filip Skola) Date: Wed, 24 Feb 2016 14:07:55 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin In-Reply-To: <1411609333.26185776.1456236128153.JavaMail.zimbra@redhat.com> References: <1415364427.17513799.1453733845873.JavaMail.zimbra@redhat.com> <1464040446.19836563.1455196912586.JavaMail.zimbra@redhat.com> <1618888650.32803170.1456145983381.JavaMail.zimbra@redhat.com> <1411609333.26185776.1456236128153.JavaMail.zimbra@redhat.com> Message-ID: <1905014287.35162874.1456340875185.JavaMail.zimbra@redhat.com> Hi, these problems have been fixed. F. ----- Original Message ----- > NACK. > Some little changes still required: > * fixing the pep8 errors > * fixing the wrong comment > > [root at master2 freeipa]# pep8 ipatests/test_xmlrpc/test_sudocmd_plugin.py > ipatests/test_xmlrpc/test_sudocmd_plugin.py:94:80: E501 line too long (87 > > 79 characters) > ipatests/test_xmlrpc/test_sudocmd_plugin.py:97:80: E501 line too long (87 > > 79 characters) > ipatests/test_xmlrpc/test_sudocmd_plugin.py:134:80: E501 line too long (80 > > 79 characters) > > [root at master2 freeipa]# pep8 ipatests/test_xmlrpc/tracker/sudocmd_plugin.py > ipatests/test_xmlrpc/tracker/sudocmd_plugin.py:14:80: E501 line too long (81 > > 79 characters) > > [root at master2 freeipa]# grep 'Class for' > ipatests/test_xmlrpc/tracker/sudocmd_plugin.py > """ Class for host plugin like tests """ > > > ----- Original Message ----- > > From: "Filip Skola" > > To: "Ale? Mare?ek" > > Cc: freeipa-devel at redhat.com, "Milan Kub?k" > > Sent: Monday, February 22, 2016 1:59:43 PM > > Subject: Re: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin > > > > Hi, > > > > sudocmd tracker has been created. > > > > Filip > > > > ----- Original Message ----- > > > NACK. > > > > > > "create_sudocmd" and "delete_sudocmd" should be placed in Tracker. So > > > this > > > patch should create the tracker as well. > > > > > > ----- Original Message ----- > > > > From: "Filip Skola" > > > > To: freeipa-devel at redhat.com > > > > Sent: Monday, January 25, 2016 3:57:25 PM > > > > Subject: [Freeipa-devel] [PATCH] 0007 Refactor test_sudocmd_plugin > > > > > > > > Hello, > > > > > > > > attaching refactored sudocmd_plugin. > > > > > > > > Filip > > > > -- > > > > 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 > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0007-3-Refactor-test_sudocmd_plugin.patch Type: text/x-patch Size: 21648 bytes Desc: not available URL: From fskola at redhat.com Wed Feb 24 19:13:03 2016 From: fskola at redhat.com (Filip Skola) Date: Wed, 24 Feb 2016 14:13:03 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 0008 Refactor test_sudocmdgroup_plugin, create SudoCmdGroupTracker In-Reply-To: <26549462.26332960.1456250313045.JavaMail.zimbra@redhat.com> References: <1667642851.19197845.1453981757248.JavaMail.zimbra@redhat.com> <289487922.19837303.1455196994918.JavaMail.zimbra@redhat.com> <892356320.32871945.1456152096564.JavaMail.zimbra@redhat.com> <26549462.26332960.1456250313045.JavaMail.zimbra@redhat.com> Message-ID: <1204896696.35164319.1456341183055.JavaMail.zimbra@redhat.com> Hi, fixed. To be honest, I left that +1char longer lines there on purpose. IMHO it brings better readability and pep8 *.py | wc -l in test_xmlrpc dir returns an overwhelming number anyway. But yeah, some of these weren't really necessary...so I changed them all :) This patch is dependent on 0007-3 patch. Filip ----- Original Message ----- > NACK. > > > [root at master2 test_xmlrpc]# pep8 test_sudocmdgroup_plugin.py > test_sudocmdgroup_plugin.py:26:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:70:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:76:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:84:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:90:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:98:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:104:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:166:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:180:80: E501 line too long (80 > 79 characters) > test_sudocmdgroup_plugin.py:186:80: E501 line too long (84 > 79 characters) > [root at master2 test_xmlrpc]# pep8 tracker/sudocmdgroup_plugin.py > tracker/sudocmdgroup_plugin.py:36:80: E501 line too long (82 > 79 characters) > tracker/sudocmdgroup_plugin.py:42:80: E501 line too long (82 > 79 characters) > tracker/sudocmdgroup_plugin.py:46:80: E501 line too long (85 > 79 characters) > tracker/sudocmdgroup_plugin.py:55:80: E501 line too long (82 > 79 characters) > tracker/sudocmdgroup_plugin.py:64:80: E501 line too long (82 > 79 characters) > > > > ----- Original Message ----- > > From: "Filip Skola" > > To: "Ale? Mare?ek" > > Cc: freeipa-devel at redhat.com, "Milan Kub?k" > > Sent: Monday, February 22, 2016 3:41:36 PM > > Subject: Re: [Freeipa-devel] [PATCH] 0008 Refactor > > test_sudocmdgroup_plugin, create SudoCmdGroupTracker > > > > Hi, > > > > the test has been updated so it now uses the SudoCmdTracker (from the > > previous patch). > > > > Filip > > > > ----- Original Message ----- > > > NACK. > > > > > > "create_sudocmd" and "delete_sudocmd" should be imported from Tracker, > > > not > > > from the previous test (sudocmd_plugin). > > > > > > - alich - > > > > > > ----- Original Message ----- > > > > From: "Filip Skola" > > > > To: freeipa-devel at redhat.com > > > > Sent: Thursday, January 28, 2016 12:49:17 PM > > > > Subject: [Freeipa-devel] [PATCH] 0008 Refactor > > > > test_sudocmdgroup_plugin, > > > > create SudoCmdGroupTracker > > > > > > > > Hi, > > > > > > > > sending the next sudo patch. This one depends on the previous one > > > > (sudocmd_plugin). > > > > > > > > Filip > > > > > > > > -- > > > > 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 > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-fskola-0008-3-Refactor-test_sudocmdgroup_plugin.patch Type: text/x-patch Size: 40643 bytes Desc: not available URL: From mkubik at redhat.com Thu Feb 25 08:52:19 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 25 Feb 2016 09:52:19 +0100 Subject: [Freeipa-devel] [patch 0034] ipatests: extend permission plugin test with new expected output In-Reply-To: <56CDF0F5.2010506@redhat.com> References: <56C1F5C6.2090708@redhat.com> <56C5DA92.4090805@redhat.com> <56CD5D22.9000404@redhat.com> <56CDF0F5.2010506@redhat.com> Message-ID: <56CEC0C3.8040703@redhat.com> On 02/24/2016 07:05 PM, Martin Basti wrote: > > > On 24.02.2016 08:34, Milan Kub?k wrote: >> On 02/18/2016 03:52 PM, Milan Kub?k wrote: >>> On 02/15/2016 04:59 PM, Milan Kub?k wrote: >>>> Patch attached. Applies on ipa-4-3 as well. >>>> >>>> >>>> >>> Updated version of patch fixes test_old_permission_plugin as well. >>> >>> -- >>> Milan Kubik >>> >>> >> Review bump. >> >> -- >> Milan Kubik >> >> > NACK > > [mbasti at dhcp129-96 freeipa-devel]$ git show -U0 | pep8 --diff > ./ipatests/test_xmlrpc/test_old_permission_plugin.py:528:80: E501 line > too long (95 > 79 characters) > ./ipatests/test_xmlrpc/test_old_permission_plugin.py:586:1: E101 > indentation contains mixed spaces and tabs > ./ipatests/test_xmlrpc/test_old_permission_plugin.py:586:1: W191 > indentation contains tabs > ./ipatests/test_xmlrpc/test_old_permission_plugin.py:587:1: E101 > indentation contains mixed spaces and tabs > ./ipatests/test_xmlrpc/test_old_permission_plugin.py:587:80: E501 line > too long (95 > 79 characters) > ./ipatests/test_xmlrpc/test_old_permission_plugin.py:591:1: E101 > indentation contains mixed spaces and tabs > ./ipatests/test_xmlrpc/test_old_permission_plugin.py:591:1: W191 > indentation contains tabs > ./ipatests/test_xmlrpc/test_permission_plugin.py:821:80: E501 line too > long (99 > 79 characters) > ./ipatests/test_xmlrpc/test_permission_plugin.py:884:80: E501 line too > long (99 > 79 characters) > Sorry for that. Updated patch attached. -- Milan Kubik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0034-2-ipatests-extend-permission-plugin-test-with-new-expe.patch Type: text/x-patch Size: 3457 bytes Desc: not available URL: From mbabinsk at redhat.com Thu Feb 25 09:18:56 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 25 Feb 2016 10:18:56 +0100 Subject: [Freeipa-devel] [FREEIPA INSTALL ISSUE] Recent Tomcat build from F23 updates-testing breaks Dogtag installation Message-ID: <56CEC700.1090904@redhat.com> Hello everyone, please note that package tomcat-8.0.32-3.fc23.noarch [1] messes with symlinks to Catalina classes used by Dogtag. This makes CA deployment blow up spectacularly during FreeIPA server/replica/etc installation. A bugzilla exists[2] for this issue and also mentions a workaround which makes the symlinks point to correct files. An alternative is to downgrade tomcat to version 8.0.32-2.fc23 [2] or older. That should make Dogtag work again. If you already encountered this issue give negative karma to the package at Bodhi[2]. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2016-5e0bb2f21a [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=737537 -- Martin^3 Babinsky From pspacek at redhat.com Thu Feb 25 09:35:38 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 10:35:38 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <20160224153054.GI7535@p.redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> <20160224142000.GC7535@p.redhat.com> <56CDBE90.8040905@redhat.com> <20160224145516.GF7535@p.redhat.com> <56CDC75E.1080004@redhat.com> <20160224153054.GI7535@p.redhat.com> Message-ID: <56CECAEA.2050005@redhat.com> On 24.2.2016 16:30, Sumit Bose wrote: > On Wed, Feb 24, 2016 at 04:08:14PM +0100, David Kupka wrote: >> On 24/02/16 15:55, Sumit Bose wrote: >>> On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote: >>>> On 02/24/2016 03:20 PM, Sumit Bose wrote: >>>>> On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: >>>>>> On 02/16/2016 02:23 PM, Martin Babinsky wrote: >>>>>>> Hi list, >>>>>>> >>>>>>> WARNING: huge brain dump ahead. >>>>>>> >>>>>>> During investigation of https://fedorahosted.org/freeipa/ticket/4305 me >>>>>>> and Petr Spaced (CC'ed) came to a conclusion that the IPA realm >>>>>>> autodiscovery code used by ipa-client-install is so convoluted, complex >>>>>>> and hard to understand that the cost of fixing a bug/adding a behavioral >>>>>>> change (there are some other tickets dealing with ipadiscovery, e.g. see >>>>>>> https://fedorahosted.org/freeipa/ticket/5270 >>>>>>> https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher >>>>>>> that a more large-scale rewrite of the module and related codebase. >>>>>>> >>>>>>> Since we plan to do some general refactoring work anyway, I would like >>>>>>> to discuss the possible course of action we may take to tackle this >>>>>>> issue. I would like to present the following options we have been >>>>>>> discussing so far: >>>>>>> >>>>>>> 1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") >>>>>>> >>>>>>> We may take the existing IPADiscovery class and try rewrite it in order >>>>>>> to get a more concise and deterministic code, which will: >>>>>>> >>>>>>> * rely more on python-dns and answers provided by resolver (e.g. we are >>>>>>> directly parsing resolv.conf for available domains when we can ask the >>>>>>> resolver to get domains for us) >>>>>>> * be more pythonic (replace error codes with thrown exceptions, clean up >>>>>>> numerous C-isms etc.) >>>>>>> * not try to outsmart user when server/realm/domain is specified >>>>>>> beforehand. Currently, even if you specify all three options, there is >>>>>>> still some DNS discovery performed, hence bug #4305. I think that one >>>>>>> you specify server(s), not magic should be performed and the discovery >>>>>>> process should be reduced to checking whether they are IPA servers and >>>>>>> pull all other info (like realm) from them. >>>>>>> >>>>>>> This may be a considerable effort requiring some time to implement and >>>>>>> get right, but IMHO still comparable to the time spent iteratively >>>>>>> placing 'if' statements into the existing code and hoping to not break >>>>>>> anything. I would even argue it is not worth the effort because we can >>>>>>> >>>>>>> 2.) Use realmd dbus interface to do DNS discovery >>>>>>> >>>>>>> I have attached aquick and dirty script I have slapped together to >>>>>>> leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm >>>>>>> discovery for us. This has a lot of appeal to me since we are leveraging >>>>>>> existing codebase for DNS discovery and will have to handle only cases >>>>>>> when the user manually specifies a list of IPA servers for the client. >>>>>>> >>>>>>> This however pulls in realmd as a (potentially circular) dependency for >>>>>>> ipa client, and when we find bug in the discovery code, we will have to >>>>>>> poke upstream (Stef or Sumit I think) to fix it. >>>>>>> >>>>>>> So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: >>>>>>> >>>>>>> 3.) Split out IPA discovery portion of realmd to a separate C library >>>>>>> shared between IPA and realmd >>>>>>> >>>>>>> may be best. Both projects will have shared codebase (maintained either >>>>>>> by us or realmd devs), which can be reused also by other people to >>>>>>> create their own discovery/enrollment solution. This would however >>>>>>> require sustained and concerted efforts of both teams to create the >>>>>>> library and possibly rewrite realmd to accommodate this change. >>>>>>> >>>>>>> There may be some other options viable for us, if so please mention them >>>>>>> in a reply. Also please correct any piece of information I got wrong. >>>>>>> >>>>>>> TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix >>>>>>> it. >>>>>>> >>>>>> >>>>>> #3 sounds good from long term perspective. >>>>>> >>>>>> In short term, i.e., #4305, we should skip discovery when --on-master is >>>>>> used. >>>>> >>>>> I would prefer #2. Because as seen from the patch it is already working >>>>> and can easily be used from python. I think this was also one of the >>>>> reasons why Stef used a DBus service for this instead of a C library >>>>> which then needs various bindings for python, Java, ruby, Go you name >>>>> it. >>>>> >>>> >>>> This approach is also my favorite. However, my (and several of my >>>> colleagues) concern is that >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in >>>> kickstart environment. I don't know how much of an issue is this, I guess it >>>> completely precludes automatic enrollment during machine provisioning. >>> >>> realmd has the --dbus-peer option. So I guess it might be possible that >>> realmd can be started by ipa-client-install directly in this case and >>> allow communication over a socket pair. I'm not sure how hard or easy >>> this would be in python. >>> >>> Stef, do you have some pointers how to use dbus-peer from python? >>> >>> bye, >>> Sumit >>> >> >> We have already done something similar with certmonger. You can look into >> ipapython/certmonger.py > > Great, so it should be possible to use realmd in the same way in a > kickstart environment. Then I vote for #2 as it is easy enough. If necessary, realmd can be a weak dependency so if it is not present ipa-client-install will work as long as --option are explicitly specified. -- Petr^2 Spacek From mbabinsk at redhat.com Thu Feb 25 09:39:04 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 25 Feb 2016 10:39:04 +0100 Subject: [Freeipa-devel] [FREEIPA INSTALL ISSUE] Recent Tomcat build from F23 updates-testing breaks Dogtag installation In-Reply-To: <56CEC700.1090904@redhat.com> References: <56CEC700.1090904@redhat.com> Message-ID: <56CECBB8.9090104@redhat.com> On 02/25/2016 10:18 AM, Martin Babinsky wrote: > Hello everyone, > > please note that package tomcat-8.0.32-3.fc23.noarch [1] messes with > symlinks to Catalina classes used by Dogtag. This makes CA deployment > blow up spectacularly during FreeIPA server/replica/etc installation. A > bugzilla exists[2] for this issue and also mentions a workaround which > makes the symlinks point to correct files. > > An alternative is to downgrade tomcat to version 8.0.32-2.fc23 [2] or > older. That should make Dogtag work again. > > If you already encountered this issue give negative karma to the package > at Bodhi[2]. > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2016-5e0bb2f21a > [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=737537 > Actually you need to downgrade to tomcat-8.0.26-2.fc23 from 'updates' repo to make things work again. -- Martin^3 Babinsky From jcholast at redhat.com Thu Feb 25 10:02:42 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Feb 2016 11:02:42 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <56CECAEA.2050005@redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> <20160224142000.GC7535@p.redhat.com> <56CDBE90.8040905@redhat.com> <20160224145516.GF7535@p.redhat.com> <56CDC75E.1080004@redhat.com> <20160224153054.GI7535@p.redhat.com> <56CECAEA.2050005@redhat.com> Message-ID: <56CED142.1060006@redhat.com> On 25.2.2016 10:35, Petr Spacek wrote: > On 24.2.2016 16:30, Sumit Bose wrote: >> On Wed, Feb 24, 2016 at 04:08:14PM +0100, David Kupka wrote: >>> On 24/02/16 15:55, Sumit Bose wrote: >>>> On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote: >>>>> On 02/24/2016 03:20 PM, Sumit Bose wrote: >>>>>> On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: >>>>>>> On 02/16/2016 02:23 PM, Martin Babinsky wrote: >>>>>>>> Hi list, >>>>>>>> >>>>>>>> WARNING: huge brain dump ahead. >>>>>>>> >>>>>>>> During investigation of https://fedorahosted.org/freeipa/ticket/4305 me >>>>>>>> and Petr Spaced (CC'ed) came to a conclusion that the IPA realm >>>>>>>> autodiscovery code used by ipa-client-install is so convoluted, complex >>>>>>>> and hard to understand that the cost of fixing a bug/adding a behavioral >>>>>>>> change (there are some other tickets dealing with ipadiscovery, e.g. see >>>>>>>> https://fedorahosted.org/freeipa/ticket/5270 >>>>>>>> https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher >>>>>>>> that a more large-scale rewrite of the module and related codebase. >>>>>>>> >>>>>>>> Since we plan to do some general refactoring work anyway, I would like >>>>>>>> to discuss the possible course of action we may take to tackle this >>>>>>>> issue. I would like to present the following options we have been >>>>>>>> discussing so far: >>>>>>>> >>>>>>>> 1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py") >>>>>>>> >>>>>>>> We may take the existing IPADiscovery class and try rewrite it in order >>>>>>>> to get a more concise and deterministic code, which will: >>>>>>>> >>>>>>>> * rely more on python-dns and answers provided by resolver (e.g. we are >>>>>>>> directly parsing resolv.conf for available domains when we can ask the >>>>>>>> resolver to get domains for us) >>>>>>>> * be more pythonic (replace error codes with thrown exceptions, clean up >>>>>>>> numerous C-isms etc.) >>>>>>>> * not try to outsmart user when server/realm/domain is specified >>>>>>>> beforehand. Currently, even if you specify all three options, there is >>>>>>>> still some DNS discovery performed, hence bug #4305. I think that one >>>>>>>> you specify server(s), not magic should be performed and the discovery >>>>>>>> process should be reduced to checking whether they are IPA servers and >>>>>>>> pull all other info (like realm) from them. >>>>>>>> >>>>>>>> This may be a considerable effort requiring some time to implement and >>>>>>>> get right, but IMHO still comparable to the time spent iteratively >>>>>>>> placing 'if' statements into the existing code and hoping to not break >>>>>>>> anything. I would even argue it is not worth the effort because we can >>>>>>>> >>>>>>>> 2.) Use realmd dbus interface to do DNS discovery >>>>>>>> >>>>>>>> I have attached aquick and dirty script I have slapped together to >>>>>>>> leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm >>>>>>>> discovery for us. This has a lot of appeal to me since we are leveraging >>>>>>>> existing codebase for DNS discovery and will have to handle only cases >>>>>>>> when the user manually specifies a list of IPA servers for the client. >>>>>>>> >>>>>>>> This however pulls in realmd as a (potentially circular) dependency for >>>>>>>> ipa client, and when we find bug in the discovery code, we will have to >>>>>>>> poke upstream (Stef or Sumit I think) to fix it. >>>>>>>> >>>>>>>> So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to: >>>>>>>> >>>>>>>> 3.) Split out IPA discovery portion of realmd to a separate C library >>>>>>>> shared between IPA and realmd >>>>>>>> >>>>>>>> may be best. Both projects will have shared codebase (maintained either >>>>>>>> by us or realmd devs), which can be reused also by other people to >>>>>>>> create their own discovery/enrollment solution. This would however >>>>>>>> require sustained and concerted efforts of both teams to create the >>>>>>>> library and possibly rewrite realmd to accommodate this change. >>>>>>>> >>>>>>>> There may be some other options viable for us, if so please mention them >>>>>>>> in a reply. Also please correct any piece of information I got wrong. >>>>>>>> >>>>>>>> TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix >>>>>>>> it. >>>>>>>> >>>>>>> >>>>>>> #3 sounds good from long term perspective. >>>>>>> >>>>>>> In short term, i.e., #4305, we should skip discovery when --on-master is >>>>>>> used. >>>>>> >>>>>> I would prefer #2. Because as seen from the patch it is already working >>>>>> and can easily be used from python. I think this was also one of the >>>>>> reasons why Stef used a DBus service for this instead of a C library >>>>>> which then needs various bindings for python, Java, ruby, Go you name >>>>>> it. >>>>>> >>>>> >>>>> This approach is also my favorite. However, my (and several of my >>>>> colleagues) concern is that >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in >>>>> kickstart environment. I don't know how much of an issue is this, I guess it >>>>> completely precludes automatic enrollment during machine provisioning. >>>> >>>> realmd has the --dbus-peer option. So I guess it might be possible that >>>> realmd can be started by ipa-client-install directly in this case and >>>> allow communication over a socket pair. I'm not sure how hard or easy >>>> this would be in python. >>>> >>>> Stef, do you have some pointers how to use dbus-peer from python? >>>> >>>> bye, >>>> Sumit >>>> >>> >>> We have already done something similar with certmonger. You can look into >>> ipapython/certmonger.py >> >> Great, so it should be possible to use realmd in the same way in a >> kickstart environment. > > Then I vote for #2 as it is easy enough. > > If necessary, realmd can be a weak dependency so if it is not present > ipa-client-install will work as long as --option are explicitly specified. +1. My personal favorite would be to deprecate autodiscovery in ipa-client-install and tell people to use realmd instead. What you describe is all that is needed to retain backward compatibility. -- Jan Cholasta From mkubik at redhat.com Thu Feb 25 10:03:38 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 25 Feb 2016 11:03:38 +0100 Subject: [Freeipa-devel] [patch 0033] spec file: update the python-polib dependency name to python2-polib In-Reply-To: <20160215163920.GM25417@mail.corp.redhat.com> References: <56C1F0C4.7060707@redhat.com> <56C1F622.3000602@redhat.com> <20160215163920.GM25417@mail.corp.redhat.com> Message-ID: <56CED17A.3050808@redhat.com> On 02/15/2016 05:39 PM, Lukas Slebodnik wrote: > On (15/02/16 17:00), Petr Vobornik wrote: >> On 02/15/2016 04:37 PM, Milan Kub?k wrote: >>> Reflect the updated name of the package. >>> >> Seems to me as a packaging bug in python-polib. It should use python_provide >> macro to handle the transition. > There is not a bug in python-polib > > sh# rpm -q python2-polib > python2-polib-1.0.7-2.fc23.noarch > > sh# rpm -q --provides python2-polib > python-polib = 1.0.7-2.fc23 > python2-polib = 1.0.7-2.fc23 > > However it is a change in behaviour in dnf/yum. > You can see more details in BZ1291850 or better BZ1096506. > > This a readon why "dnf builddep" will try to remove package. > (it's not downgrade from dnf point of view) > > sh# dnf builddep freeipa.spec > Last metadata expiration check performed 0:17:37 ago on Mon Feb 15 16:19:14 > 2016. > Package python-setuptools-18.0.1-2.fc23.noarch is already installed, skipping. > Package systemd-222-10.fc23.x86_64 is already installed, skipping. > Package systemd-222-10.fc23.x86_64 is already installed, skipping. > Error: installed package python2-polib-1.0.7-2.fc23.noarch obsoletes > python-polib < 1.0.7-2.fc23 provided by python-polib-1.0.3-6.fc23.noarch > (try to add '--allowerasing' to command line to replace conflicting packages) > > > You might try to file a dnf BZ but mine 1291850 was two tiles closed as not a > but and then closed as a duplicate of another bug. > > IMHO the simplest solution would to push the patch with better explanation > in's a workaround. > > LSommit message becuase it's a workaround. > > LS Updated patch with reworded commit message. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0033-1-spec-file-update-the-python-polib-dependency-name-to.patch Type: text/x-patch Size: 1526 bytes Desc: not available URL: From jcholast at redhat.com Thu Feb 25 10:07:10 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Feb 2016 11:07:10 +0100 Subject: [Freeipa-devel] [patch 0033] spec file: update the python-polib dependency name to python2-polib In-Reply-To: <56CED17A.3050808@redhat.com> References: <56C1F0C4.7060707@redhat.com> <56C1F622.3000602@redhat.com> <20160215163920.GM25417@mail.corp.redhat.com> <56CED17A.3050808@redhat.com> Message-ID: <56CED24E.9060207@redhat.com> On 25.2.2016 11:03, Milan Kub?k wrote: > On 02/15/2016 05:39 PM, Lukas Slebodnik wrote: >> On (15/02/16 17:00), Petr Vobornik wrote: >>> On 02/15/2016 04:37 PM, Milan Kub?k wrote: >>>> Reflect the updated name of the package. >>>> >>> Seems to me as a packaging bug in python-polib. It should use >>> python_provide >>> macro to handle the transition. >> There is not a bug in python-polib >> >> sh# rpm -q python2-polib >> python2-polib-1.0.7-2.fc23.noarch >> >> sh# rpm -q --provides python2-polib >> python-polib = 1.0.7-2.fc23 >> python2-polib = 1.0.7-2.fc23 >> >> However it is a change in behaviour in dnf/yum. >> You can see more details in BZ1291850 or better BZ1096506. >> >> This a readon why "dnf builddep" will try to remove package. >> (it's not downgrade from dnf point of view) >> >> sh# dnf builddep freeipa.spec >> Last metadata expiration check performed 0:17:37 ago on Mon Feb 15 >> 16:19:14 >> 2016. >> Package python-setuptools-18.0.1-2.fc23.noarch is already installed, >> skipping. >> Package systemd-222-10.fc23.x86_64 is already installed, skipping. >> Package systemd-222-10.fc23.x86_64 is already installed, skipping. >> Error: installed package python2-polib-1.0.7-2.fc23.noarch obsoletes >> python-polib < 1.0.7-2.fc23 provided by python-polib-1.0.3-6.fc23.noarch >> (try to add '--allowerasing' to command line to replace conflicting >> packages) >> >> >> You might try to file a dnf BZ but mine 1291850 was two tiles closed >> as not a >> but and then closed as a duplicate of another bug. >> >> IMHO the simplest solution would to push the patch with better >> explanation >> in's a workaround. >> >> LSommit message becuase it's a workaround. >> >> LS > Updated patch with reworded commit message. Please also add "workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1096506" comment above the changed requires. -- Jan Cholasta From mkubik at redhat.com Thu Feb 25 10:07:28 2016 From: mkubik at redhat.com (=?UTF-8?Q?Milan_Kub=c3=adk?=) Date: Thu, 25 Feb 2016 11:07:28 +0100 Subject: [Freeipa-devel] [patch 0033] spec file: update the python-polib dependency name to python2-polib In-Reply-To: <56CED24E.9060207@redhat.com> References: <56C1F0C4.7060707@redhat.com> <56C1F622.3000602@redhat.com> <20160215163920.GM25417@mail.corp.redhat.com> <56CED17A.3050808@redhat.com> <56CED24E.9060207@redhat.com> Message-ID: <56CED260.4080703@redhat.com> On 02/25/2016 11:07 AM, Jan Cholasta wrote: > On 25.2.2016 11:03, Milan Kub?k wrote: >> On 02/15/2016 05:39 PM, Lukas Slebodnik wrote: >>> On (15/02/16 17:00), Petr Vobornik wrote: >>>> On 02/15/2016 04:37 PM, Milan Kub?k wrote: >>>>> Reflect the updated name of the package. >>>>> >>>> Seems to me as a packaging bug in python-polib. It should use >>>> python_provide >>>> macro to handle the transition. >>> There is not a bug in python-polib >>> >>> sh# rpm -q python2-polib >>> python2-polib-1.0.7-2.fc23.noarch >>> >>> sh# rpm -q --provides python2-polib >>> python-polib = 1.0.7-2.fc23 >>> python2-polib = 1.0.7-2.fc23 >>> >>> However it is a change in behaviour in dnf/yum. >>> You can see more details in BZ1291850 or better BZ1096506. >>> >>> This a readon why "dnf builddep" will try to remove package. >>> (it's not downgrade from dnf point of view) >>> >>> sh# dnf builddep freeipa.spec >>> Last metadata expiration check performed 0:17:37 ago on Mon Feb 15 >>> 16:19:14 >>> 2016. >>> Package python-setuptools-18.0.1-2.fc23.noarch is already installed, >>> skipping. >>> Package systemd-222-10.fc23.x86_64 is already installed, skipping. >>> Package systemd-222-10.fc23.x86_64 is already installed, skipping. >>> Error: installed package python2-polib-1.0.7-2.fc23.noarch obsoletes >>> python-polib < 1.0.7-2.fc23 provided by >>> python-polib-1.0.3-6.fc23.noarch >>> (try to add '--allowerasing' to command line to replace conflicting >>> packages) >>> >>> >>> You might try to file a dnf BZ but mine 1291850 was two tiles closed >>> as not a >>> but and then closed as a duplicate of another bug. >>> >>> IMHO the simplest solution would to push the patch with better >>> explanation >>> in's a workaround. >>> >>> LSommit message becuase it's a workaround. >>> >>> LS >> Updated patch with reworded commit message. > > Please also add "workaround for > https://bugzilla.redhat.com/show_bug.cgi?id=1096506" comment above the > changed requires. > Done. -- Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkubik-0033-2-spec-file-update-the-python-polib-dependency-name-to.patch Type: text/x-patch Size: 1668 bytes Desc: not available URL: From dkupka at redhat.com Thu Feb 25 10:25:13 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 25 Feb 2016 11:25:13 +0100 Subject: [Freeipa-devel] [PATCH 0423] fix duplicated except In-Reply-To: <56CDE0CF.2080405@redhat.com> References: <56CDE0CF.2080405@redhat.com> Message-ID: <56CED689.5070905@redhat.com> On 24/02/16 17:56, Martin Basti wrote: > During my playing with pylint, I fixed this issue which allows us to > enable additional check in pylint (the nice one). > > Patch attached, it should go only to master. > > Works for me, ACK. I always wonder how something like this can even get to the sources. Fortunately the added check will prevent that in the future. -- David Kupka From dkupka at redhat.com Thu Feb 25 10:29:13 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 25 Feb 2016 11:29:13 +0100 Subject: [Freeipa-devel] [PATCH 0424] Pylint: add missing attributes of exceptions to definition in pylint plugin In-Reply-To: <56CDEE50.5030506@redhat.com> References: <56CDEE50.5030506@redhat.com> Message-ID: <56CED779.50601@redhat.com> On 24/02/16 18:54, Martin Basti wrote: > Pylint is not able to handle IPA errors objects, because attributes are > added into objects dynamically, and pylint 1.5 reports them as no-member > errors. > > https://fedorahosted.org/freeipa/ticket/5615 > > Patch attached. > > It would be better to define all errors with all unrecoverable members but this is sufficient start. More can be add when it's needed. Works for me, ACK. -- David Kupka From pspacek at redhat.com Thu Feb 25 10:34:51 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 11:34:51 +0100 Subject: [Freeipa-devel] IPA client realm/domain autodiscovery improvements In-Reply-To: <56CED142.1060006@redhat.com> References: <56C322DA.9040105@redhat.com> <56CDA2BB.9060508@redhat.com> <20160224142000.GC7535@p.redhat.com> <56CDBE90.8040905@redhat.com> <20160224145516.GF7535@p.redhat.com> <56CDC75E.1080004@redhat.com> <20160224153054.GI7535@p.redhat.com> <56CECAEA.2050005@redhat.com> <56CED142.1060006@redhat.com> Message-ID: <56CED8CB.8060008@redhat.com> On 25.2.2016 11:02, Jan Cholasta wrote: > On 25.2.2016 10:35, Petr Spacek wrote: >> On 24.2.2016 16:30, Sumit Bose wrote: >>> On Wed, Feb 24, 2016 at 04:08:14PM +0100, David Kupka wrote: >>>> On 24/02/16 15:55, Sumit Bose wrote: >>>>> On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote: >>>>>> On 02/24/2016 03:20 PM, Sumit Bose wrote: >>>>>>> On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote: >>>>>>>> On 02/16/2016 02:23 PM, Martin Babinsky wrote: >>>>>>>>> Hi list, >>>>>>>>> >>>>>>>>> WARNING: huge brain dump ahead. >>>>>>>>> >>>>>>>>> During investigation of https://fedorahosted.org/freeipa/ticket/4305 me >>>>>>>>> and Petr Spaced (CC'ed) came to a conclusion that the IPA realm >>>>>>>>> autodiscovery code used by ipa-client-install is so convoluted, complex >>>>>>>>> and hard to understand that the cost of fixing a bug/adding a behavioral >>>>>>>>> change (there are some other tickets dealing with ipadiscovery, e.g. see >>>>>>>>> https://fedorahosted.org/freeipa/ticket/5270 >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher >>>>>>>>> that a more large-scale rewrite of the module and related codebase. >>>>>>>>> >>>>>>>>> Since we plan to do some general refactoring work anyway, I would like >>>>>>>>> to discuss the possible course of action we may take to tackle this >>>>>>>>> issue. I would like to present the following options we have been >>>>>>>>> discussing so far: >>>>>>>>> >>>>>>>>> 1.) Do a substantial rewrite of existing code >>>>>>>>> ("ipaclient/ipadiscovery.py") >>>>>>>>> >>>>>>>>> We may take the existing IPADiscovery class and try rewrite it in order >>>>>>>>> to get a more concise and deterministic code, which will: >>>>>>>>> >>>>>>>>> * rely more on python-dns and answers provided by resolver (e.g. we are >>>>>>>>> directly parsing resolv.conf for available domains when we can ask the >>>>>>>>> resolver to get domains for us) >>>>>>>>> * be more pythonic (replace error codes with thrown exceptions, clean up >>>>>>>>> numerous C-isms etc.) >>>>>>>>> * not try to outsmart user when server/realm/domain is specified >>>>>>>>> beforehand. Currently, even if you specify all three options, there is >>>>>>>>> still some DNS discovery performed, hence bug #4305. I think that one >>>>>>>>> you specify server(s), not magic should be performed and the discovery >>>>>>>>> process should be reduced to checking whether they are IPA servers and >>>>>>>>> pull all other info (like realm) from them. >>>>>>>>> >>>>>>>>> This may be a considerable effort requiring some time to implement and >>>>>>>>> get right, but IMHO still comparable to the time spent iteratively >>>>>>>>> placing 'if' statements into the existing code and hoping to not break >>>>>>>>> anything. I would even argue it is not worth the effort because we can >>>>>>>>> >>>>>>>>> 2.) Use realmd dbus interface to do DNS discovery >>>>>>>>> >>>>>>>>> I have attached aquick and dirty script I have slapped together to >>>>>>>>> leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm >>>>>>>>> discovery for us. This has a lot of appeal to me since we are leveraging >>>>>>>>> existing codebase for DNS discovery and will have to handle only cases >>>>>>>>> when the user manually specifies a list of IPA servers for the client. >>>>>>>>> >>>>>>>>> This however pulls in realmd as a (potentially circular) dependency for >>>>>>>>> ipa client, and when we find bug in the discovery code, we will have to >>>>>>>>> poke upstream (Stef or Sumit I think) to fix it. >>>>>>>>> >>>>>>>>> So from the long-term point of view, Jan Cholasta's (CC'ed) >>>>>>>>> suggestion to: >>>>>>>>> >>>>>>>>> 3.) Split out IPA discovery portion of realmd to a separate C library >>>>>>>>> shared between IPA and realmd >>>>>>>>> >>>>>>>>> may be best. Both projects will have shared codebase (maintained either >>>>>>>>> by us or realmd devs), which can be reused also by other people to >>>>>>>>> create their own discovery/enrollment solution. This would however >>>>>>>>> require sustained and concerted efforts of both teams to create the >>>>>>>>> library and possibly rewrite realmd to accommodate this change. >>>>>>>>> >>>>>>>>> There may be some other options viable for us, if so please mention them >>>>>>>>> in a reply. Also please correct any piece of information I got wrong. >>>>>>>>> >>>>>>>>> TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix >>>>>>>>> it. >>>>>>>>> >>>>>>>> >>>>>>>> #3 sounds good from long term perspective. >>>>>>>> >>>>>>>> In short term, i.e., #4305, we should skip discovery when --on-master is >>>>>>>> used. >>>>>>> >>>>>>> I would prefer #2. Because as seen from the patch it is already working >>>>>>> and can easily be used from python. I think this was also one of the >>>>>>> reasons why Stef used a DBus service for this instead of a C library >>>>>>> which then needs various bindings for python, Java, ruby, Go you name >>>>>>> it. >>>>>>> >>>>>> >>>>>> This approach is also my favorite. However, my (and several of my >>>>>> colleagues) concern is that >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1271551 will break it in >>>>>> kickstart environment. I don't know how much of an issue is this, I >>>>>> guess it >>>>>> completely precludes automatic enrollment during machine provisioning. >>>>> >>>>> realmd has the --dbus-peer option. So I guess it might be possible that >>>>> realmd can be started by ipa-client-install directly in this case and >>>>> allow communication over a socket pair. I'm not sure how hard or easy >>>>> this would be in python. >>>>> >>>>> Stef, do you have some pointers how to use dbus-peer from python? >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>> >>>> We have already done something similar with certmonger. You can look into >>>> ipapython/certmonger.py >>> >>> Great, so it should be possible to use realmd in the same way in a >>> kickstart environment. >> >> Then I vote for #2 as it is easy enough. >> >> If necessary, realmd can be a weak dependency so if it is not present >> ipa-client-install will work as long as --option are explicitly specified. > > +1. > > My personal favorite would be to deprecate autodiscovery in ipa-client-install > and tell people to use realmd instead. What you describe is all that is needed > to retain backward compatibility. Yeah, that sounds like a good long-term goal. -- Petr^2 Spacek From jcholast at redhat.com Thu Feb 25 10:40:32 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Feb 2016 11:40:32 +0100 Subject: [Freeipa-devel] [PATCH 0423] fix duplicated except In-Reply-To: <56CED689.5070905@redhat.com> References: <56CDE0CF.2080405@redhat.com> <56CED689.5070905@redhat.com> Message-ID: <56CEDA20.6040001@redhat.com> On 25.2.2016 11:25, David Kupka wrote: > On 24/02/16 17:56, Martin Basti wrote: >> During my playing with pylint, I fixed this issue which allows us to >> enable additional check in pylint (the nice one). >> >> Patch attached, it should go only to master. >> >> > Works for me, ACK. > > I always wonder how something like this can even get to the sources. > Fortunately the added check will prevent that in the future. Before this is pushed, could you please check git history to verify that these duplicate excepts are not symptomps of some actual problems? -- Jan Cholasta From tbabej at redhat.com Thu Feb 25 10:40:15 2016 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 25 Feb 2016 11:40:15 +0100 Subject: [Freeipa-devel] [PATCH 0400] l10n: Remove Transifex configuration Message-ID: <56CEDA0F.5010807@redhat.com> Hi, We're not using Transifex to manage our translations anymore. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0400-l10n-Remove-Transifex-configuration.patch Type: text/x-patch Size: 715 bytes Desc: not available URL: From dkupka at redhat.com Thu Feb 25 11:03:43 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 25 Feb 2016 12:03:43 +0100 Subject: [Freeipa-devel] [PATCH 0423] fix duplicated except In-Reply-To: <56CEDA20.6040001@redhat.com> References: <56CDE0CF.2080405@redhat.com> <56CED689.5070905@redhat.com> <56CEDA20.6040001@redhat.com> Message-ID: <56CEDF8F.9000504@redhat.com> On 25/02/16 11:40, Jan Cholasta wrote: > On 25.2.2016 11:25, David Kupka wrote: >> On 24/02/16 17:56, Martin Basti wrote: >>> During my playing with pylint, I fixed this issue which allows us to >>> enable additional check in pylint (the nice one). >>> >>> Patch attached, it should go only to master. >>> >>> >> Works for me, ACK. >> >> I always wonder how something like this can even get to the sources. >> Fortunately the added check will prevent that in the future. > > Before this is pushed, could you please check git history to verify that > these duplicate excepts are not symptomps of some actual problems? > Archaeology hat on. The duplicate except statement in ipalib/plugins/automount.py was introduced by commit 0197ebbb and was there since 2010. All the time the second except was logically dead code. The duplicate except statement in ipalib/backend.py was introduced by commit 01da4a8d converting StandardError to Exception. But the only difference is the message in raise error. I should be save to push this. -- David Kupka From mbabinsk at redhat.com Thu Feb 25 11:03:52 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 25 Feb 2016 12:03:52 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56CDCC82.30108@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> Message-ID: <56CEDF98.7060809@redhat.com> On 02/24/2016 04:30 PM, thierry bordaz wrote: > On 01/21/2016 05:04 PM, Martin Babinsky wrote: >> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>> >>> >>> >> Hi Thierry, >> >> I have couple of comments to your patch: >> >> 1.) >> there is a number of PEP8 errors in the patch >> (http://paste.fedoraproject.org/313246/33893701), please fix them. >> >> See http://www.freeipa.org/page/Python_Coding_Style for our >> conventions used in Python code. >> >> 2.) >> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >> Plugin,cn=plugins,cn=config' >> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >> >> Uppercase names are usually reserved for module-level constants. OTOH, >> local variables should be lowercase. Also you can instantiate >> dna_config_base directly as DN, using 2-member tuples, i. e: >> >> """ >> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric >> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >> """ >> >> When passing DN object to the formatting functions/operators, it is >> automatically converted to string so no need to hold string and DN >> object separately. This is done in other places (see function/methods >> in replication.py). >> >> 3.) >> >> + for i in range(len(entries)) : >> + >> + mod = [] >> + if entries[i].single_value.get(DNA_BIND_METHOD) != method: >> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, method)) >> + >> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >> protocol: >> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >> protocol)) >> >> >> please use idiomatic Python when handling list of entries, e.g.: >> >> """ >> for entry in entries: >> mod = [] >> if entry.single_value.get(DNA_BIND_METHOD) != method: >> ... >> """ >> >> 4.) I think that this method should in DSInstance class since it deals >> with directory server configuration. Service is a parent object of all >> other service installers/configurators and should contain only methods >> common to more children. >> >> 5.) Since the method is called from every installer, it could be >> beneficial to call it in DSInstance.__common_post_setup() as a part of >> Directory server installation. Is there any reason why this is not the >> case? >> >> 6.) >> >> + while attempt != MAX_WAIT: >> + try: >> + entries = conn.get_entries(sharedcfgdn, >> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >> + break >> + except errors.NotFound: >> + root_logger.debug("So far enable not find DNA shared >> config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn, >> sharedcfgdn)) >> + attempt = attempt + 1 >> + time.sleep(2) >> + continue >> + >> + # safety checking >> + # there is no return, if there are several entries, as a >> workaround of #5510 >> + if len(entries) != 1: >> >> I am quite afraid what would happen if the server does not return any >> entries until 30 s timeout. The code will then continue to the >> condition which can potentially test an uninitialized variable and >> blow up with 'NameError'. This should be handled more robustly, e. g. >> raise an exception when a timeout is reached and no entries were >> returned. >> >> 7.) >> >> + if len(mod) > 0: >> >> A Pythonic way to test for non-empty container is >> >> """ >> if mods: >> # do stuff >> """ >> >> since an empty list/dict/set evaluates to False and non-empty >> containers are True. >> >> >> 8.) >> >> + entry = conn.get_entry(entries[i].dn) >> + if entry.single_value.get(DNA_BIND_METHOD) != method: >> + root_logger.error("Fail to set SASL/GSSAPI bind >> method to %s" % (entries[i].dn)) >> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >> protocol: >> + root_logger.error("Fail to set LDAP protocol to >> %s" % (entries[i].dn)) >> >> rather than re-fetching the modified entry and testing what happened, >> you can just catch an exception raised by unsuccessfull mod and log an >> error like this: >> >> """ >> try: >> conn.modify_s(entry.dn, mod) >> except Exception as e: >> root_logger.error("Failed to modify entry {}: {}".format(entry, e)) >> """ >> >> as a matter of fact, if the modify_s operation would fail for some >> reason, an ldap exception would be raised and you checks would not >> even be executed. >> >> 9.) >> The debug message on line 219 should read "Unable to find DNA shared >> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >> at the end of the method should have "Failed" instead of "Fail". >> > Hi Martin, > > Finally tested... here is the updated patch. Thanks for you patience > > > thanks > thierry Hi Thierry, the patch works as expected. I have some more nitpicks though: 1.) Please fix the following pep8 errors: http://paste.fedoraproject.org/329086/56397841/ you can check whether you recent commit conforms to PEP8 by running "git show -U0 | pep8 --diff" 2.) + self.step("update DNA shared config entry", self.update_dna_shared_config) I would rather change the message to "Updating DNA shared config entry" since all other messages use continuous tense. 3.) + else: + raise RuntimeError("Could not get dnaHostname entries in {} seconds".format(max_wait * 2)) Please use root_logger.error() and then return as is used elsewhere in the method. We do not want a runaway exception crashing upgrade. -- Martin^3 Babinsky From pspacek at redhat.com Thu Feb 25 11:06:36 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 12:06:36 +0100 Subject: [Freeipa-devel] [PATCH 0421] Make PTR records check optional for IPA installation In-Reply-To: <56CDBA6D.5000803@redhat.com> References: <56CDBA6D.5000803@redhat.com> Message-ID: <56CEE03C.9030801@redhat.com> On 24.2.2016 15:13, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5686 > > Patch attached. LGTM, ACK if it passes QE testing. -- Petr^2 Spacek From tbordaz at redhat.com Thu Feb 25 11:17:25 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 25 Feb 2016 12:17:25 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56CEDF98.7060809@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> <56CEDF98.7060809@redhat.com> Message-ID: <56CEE2C5.10806@redhat.com> On 02/25/2016 12:03 PM, Martin Babinsky wrote: > On 02/24/2016 04:30 PM, thierry bordaz wrote: >> On 01/21/2016 05:04 PM, Martin Babinsky wrote: >>> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>>> >>>> >>>> >>> Hi Thierry, >>> >>> I have couple of comments to your patch: >>> >>> 1.) >>> there is a number of PEP8 errors in the patch >>> (http://paste.fedoraproject.org/313246/33893701), please fix them. >>> >>> See http://www.freeipa.org/page/Python_Coding_Style for our >>> conventions used in Python code. >>> >>> 2.) >>> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >>> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >>> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >>> Plugin,cn=plugins,cn=config' >>> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >>> >>> Uppercase names are usually reserved for module-level constants. OTOH, >>> local variables should be lowercase. Also you can instantiate >>> dna_config_base directly as DN, using 2-member tuples, i. e: >>> >>> """ >>> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric >>> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >>> """ >>> >>> When passing DN object to the formatting functions/operators, it is >>> automatically converted to string so no need to hold string and DN >>> object separately. This is done in other places (see function/methods >>> in replication.py). >>> >>> 3.) >>> >>> + for i in range(len(entries)) : >>> + >>> + mod = [] >>> + if entries[i].single_value.get(DNA_BIND_METHOD) != method: >>> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, >>> method)) >>> + >>> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >>> protocol: >>> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >>> protocol)) >>> >>> >>> please use idiomatic Python when handling list of entries, e.g.: >>> >>> """ >>> for entry in entries: >>> mod = [] >>> if entry.single_value.get(DNA_BIND_METHOD) != method: >>> ... >>> """ >>> >>> 4.) I think that this method should in DSInstance class since it deals >>> with directory server configuration. Service is a parent object of all >>> other service installers/configurators and should contain only methods >>> common to more children. >>> >>> 5.) Since the method is called from every installer, it could be >>> beneficial to call it in DSInstance.__common_post_setup() as a part of >>> Directory server installation. Is there any reason why this is not the >>> case? >>> >>> 6.) >>> >>> + while attempt != MAX_WAIT: >>> + try: >>> + entries = conn.get_entries(sharedcfgdn, >>> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >>> + break >>> + except errors.NotFound: >>> + root_logger.debug("So far enable not find DNA shared >>> config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn, >>> sharedcfgdn)) >>> + attempt = attempt + 1 >>> + time.sleep(2) >>> + continue >>> + >>> + # safety checking >>> + # there is no return, if there are several entries, as a >>> workaround of #5510 >>> + if len(entries) != 1: >>> >>> I am quite afraid what would happen if the server does not return any >>> entries until 30 s timeout. The code will then continue to the >>> condition which can potentially test an uninitialized variable and >>> blow up with 'NameError'. This should be handled more robustly, e. g. >>> raise an exception when a timeout is reached and no entries were >>> returned. >>> >>> 7.) >>> >>> + if len(mod) > 0: >>> >>> A Pythonic way to test for non-empty container is >>> >>> """ >>> if mods: >>> # do stuff >>> """ >>> >>> since an empty list/dict/set evaluates to False and non-empty >>> containers are True. >>> >>> >>> 8.) >>> >>> + entry = conn.get_entry(entries[i].dn) >>> + if entry.single_value.get(DNA_BIND_METHOD) != method: >>> + root_logger.error("Fail to set SASL/GSSAPI bind >>> method to %s" % (entries[i].dn)) >>> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >>> protocol: >>> + root_logger.error("Fail to set LDAP protocol to >>> %s" % (entries[i].dn)) >>> >>> rather than re-fetching the modified entry and testing what happened, >>> you can just catch an exception raised by unsuccessfull mod and log an >>> error like this: >>> >>> """ >>> try: >>> conn.modify_s(entry.dn, mod) >>> except Exception as e: >>> root_logger.error("Failed to modify entry {}: {}".format(entry, e)) >>> """ >>> >>> as a matter of fact, if the modify_s operation would fail for some >>> reason, an ldap exception would be raised and you checks would not >>> even be executed. >>> >>> 9.) >>> The debug message on line 219 should read "Unable to find DNA shared >>> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >>> at the end of the method should have "Failed" instead of "Fail". >>> >> Hi Martin, >> >> Finally tested... here is the updated patch. Thanks for you patience >> >> >> thanks >> thierry > > Hi Thierry, > > the patch works as expected. 8-) > I have some more nitpicks though: > > 1.) Please fix the following pep8 errors: > > http://paste.fedoraproject.org/329086/56397841/ > > you can check whether you recent commit conforms to PEP8 by running > > "git show -U0 | pep8 --diff" I did it and fixed most of them but what remains is long line. I fixed some of them but sometime I think it make the code more complex to read. Should I split those lines anyway ? > > 2.) > + self.step("update DNA shared config entry", > self.update_dna_shared_config) > > I would rather change the message to "Updating DNA shared config > entry" since all other messages use continuous tense. Right. I will do. > > 3.) > + else: > + raise RuntimeError("Could not get dnaHostname entries > in {} seconds".format(max_wait * 2)) > > Please use root_logger.error() and then return as is used elsewhere in > the method. We do not want a runaway exception crashing upgrade. ok I understand. I will fix that Thanks Martin From tbabej at redhat.com Thu Feb 25 12:38:48 2016 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 25 Feb 2016 13:38:48 +0100 Subject: [Freeipa-devel] [PATCH 0134] CI tests: use old schema when testing hostmask-based sudo rules In-Reply-To: <56C58FC9.9070901@redhat.com> References: <56C58FC9.9070901@redhat.com> Message-ID: <56CEF5D8.1070502@redhat.com> On 02/18/2016 10:32 AM, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5625 ACK, works fine for me. Thanks for the patch. Pushed to master: 94a836dd46e5e041443b7da03e4ce8a7a7aaa7e3 Pushed to ipa-4-2: 61475631f64206d771e3fd243220be242f4bdd38 Tomas From mbasti at redhat.com Thu Feb 25 12:50:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Feb 2016 13:50:08 +0100 Subject: [Freeipa-devel] [PATCH 0423] fix duplicated except In-Reply-To: <56CEDF8F.9000504@redhat.com> References: <56CDE0CF.2080405@redhat.com> <56CED689.5070905@redhat.com> <56CEDA20.6040001@redhat.com> <56CEDF8F.9000504@redhat.com> Message-ID: <56CEF880.8010005@redhat.com> On 25.02.2016 12:03, David Kupka wrote: > On 25/02/16 11:40, Jan Cholasta wrote: >> On 25.2.2016 11:25, David Kupka wrote: >>> On 24/02/16 17:56, Martin Basti wrote: >>>> During my playing with pylint, I fixed this issue which allows us to >>>> enable additional check in pylint (the nice one). >>>> >>>> Patch attached, it should go only to master. >>>> >>>> >>> Works for me, ACK. >>> >>> I always wonder how something like this can even get to the sources. >>> Fortunately the added check will prevent that in the future. >> >> Before this is pushed, could you please check git history to verify that >> these duplicate excepts are not symptomps of some actual problems? >> > > Archaeology hat on. > > The duplicate except statement in ipalib/plugins/automount.py was > introduced by commit 0197ebbb and was there since 2010. All the time > the second except was logically dead code. > > The duplicate except statement in ipalib/backend.py was introduced by > commit 01da4a8d converting StandardError to Exception. But the only > difference is the message in raise error. > > I should be save to push this. > > Pushed to master: 0d39abddc27b0c348131dc3d0f3c5c538cd5f0b5 From mbabinsk at redhat.com Thu Feb 25 12:56:31 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 25 Feb 2016 13:56:31 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56CEE2C5.10806@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> <56CEDF98.7060809@redhat.com> <56CEE2C5.10806@redhat.com> Message-ID: <56CEF9FF.8040809@redhat.com> On 02/25/2016 12:17 PM, thierry bordaz wrote: > On 02/25/2016 12:03 PM, Martin Babinsky wrote: >> On 02/24/2016 04:30 PM, thierry bordaz wrote: >>> On 01/21/2016 05:04 PM, Martin Babinsky wrote: >>>> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>>>> >>>>> >>>>> >>>> Hi Thierry, >>>> >>>> I have couple of comments to your patch: >>>> >>>> 1.) >>>> there is a number of PEP8 errors in the patch >>>> (http://paste.fedoraproject.org/313246/33893701), please fix them. >>>> >>>> See http://www.freeipa.org/page/Python_Coding_Style for our >>>> conventions used in Python code. >>>> >>>> 2.) >>>> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >>>> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >>>> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >>>> Plugin,cn=plugins,cn=config' >>>> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >>>> >>>> Uppercase names are usually reserved for module-level constants. OTOH, >>>> local variables should be lowercase. Also you can instantiate >>>> dna_config_base directly as DN, using 2-member tuples, i. e: >>>> >>>> """ >>>> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric >>>> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >>>> """ >>>> >>>> When passing DN object to the formatting functions/operators, it is >>>> automatically converted to string so no need to hold string and DN >>>> object separately. This is done in other places (see function/methods >>>> in replication.py). >>>> >>>> 3.) >>>> >>>> + for i in range(len(entries)) : >>>> + >>>> + mod = [] >>>> + if entries[i].single_value.get(DNA_BIND_METHOD) != method: >>>> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, >>>> method)) >>>> + >>>> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >>>> protocol: >>>> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >>>> protocol)) >>>> >>>> >>>> please use idiomatic Python when handling list of entries, e.g.: >>>> >>>> """ >>>> for entry in entries: >>>> mod = [] >>>> if entry.single_value.get(DNA_BIND_METHOD) != method: >>>> ... >>>> """ >>>> >>>> 4.) I think that this method should in DSInstance class since it deals >>>> with directory server configuration. Service is a parent object of all >>>> other service installers/configurators and should contain only methods >>>> common to more children. >>>> >>>> 5.) Since the method is called from every installer, it could be >>>> beneficial to call it in DSInstance.__common_post_setup() as a part of >>>> Directory server installation. Is there any reason why this is not the >>>> case? >>>> >>>> 6.) >>>> >>>> + while attempt != MAX_WAIT: >>>> + try: >>>> + entries = conn.get_entries(sharedcfgdn, >>>> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >>>> + break >>>> + except errors.NotFound: >>>> + root_logger.debug("So far enable not find DNA shared >>>> config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn, >>>> sharedcfgdn)) >>>> + attempt = attempt + 1 >>>> + time.sleep(2) >>>> + continue >>>> + >>>> + # safety checking >>>> + # there is no return, if there are several entries, as a >>>> workaround of #5510 >>>> + if len(entries) != 1: >>>> >>>> I am quite afraid what would happen if the server does not return any >>>> entries until 30 s timeout. The code will then continue to the >>>> condition which can potentially test an uninitialized variable and >>>> blow up with 'NameError'. This should be handled more robustly, e. g. >>>> raise an exception when a timeout is reached and no entries were >>>> returned. >>>> >>>> 7.) >>>> >>>> + if len(mod) > 0: >>>> >>>> A Pythonic way to test for non-empty container is >>>> >>>> """ >>>> if mods: >>>> # do stuff >>>> """ >>>> >>>> since an empty list/dict/set evaluates to False and non-empty >>>> containers are True. >>>> >>>> >>>> 8.) >>>> >>>> + entry = conn.get_entry(entries[i].dn) >>>> + if entry.single_value.get(DNA_BIND_METHOD) != method: >>>> + root_logger.error("Fail to set SASL/GSSAPI bind >>>> method to %s" % (entries[i].dn)) >>>> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >>>> protocol: >>>> + root_logger.error("Fail to set LDAP protocol to >>>> %s" % (entries[i].dn)) >>>> >>>> rather than re-fetching the modified entry and testing what happened, >>>> you can just catch an exception raised by unsuccessfull mod and log an >>>> error like this: >>>> >>>> """ >>>> try: >>>> conn.modify_s(entry.dn, mod) >>>> except Exception as e: >>>> root_logger.error("Failed to modify entry {}: {}".format(entry, e)) >>>> """ >>>> >>>> as a matter of fact, if the modify_s operation would fail for some >>>> reason, an ldap exception would be raised and you checks would not >>>> even be executed. >>>> >>>> 9.) >>>> The debug message on line 219 should read "Unable to find DNA shared >>>> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >>>> at the end of the method should have "Failed" instead of "Fail". >>>> >>> Hi Martin, >>> >>> Finally tested... here is the updated patch. Thanks for you patience >>> >>> >>> thanks >>> thierry >> >> Hi Thierry, >> >> the patch works as expected. > > 8-) >> I have some more nitpicks though: >> >> 1.) Please fix the following pep8 errors: >> >> http://paste.fedoraproject.org/329086/56397841/ >> >> you can check whether you recent commit conforms to PEP8 by running >> >> "git show -U0 | pep8 --diff" > > I did it and fixed most of them but what remains is long line. I fixed > some of them but sometime I think it make the code more complex to read. > Should I split those lines anyway ? > There are some lines that are over 120 characters long and that's really too much. See my quick patch which I attached to make the long lines pep8-conformant. I also fixes some redundant parentheses in the format string and replaces raised exception with logger error. >> >> 2.) >> + self.step("update DNA shared config entry", >> self.update_dna_shared_config) >> >> I would rather change the message to "Updating DNA shared config >> entry" since all other messages use continuous tense. > > Right. I will do. > >> >> 3.) >> + else: >> + raise RuntimeError("Could not get dnaHostname entries >> in {} seconds".format(max_wait * 2)) >> >> Please use root_logger.error() and then return as is used elsewhere in >> the method. We do not want a runaway exception crashing upgrade. > ok I understand. I will fix that > > Thanks Martin > > + # a server waits for 30s after its startup to update its shared config + max_wait = 30 + for i in range(0, max_wait + 1): I also realized that we have 30s timeout in the comment here, bu we actually wait for 60 seconds (30 * time.sleep(2)). We should fix the comment as to not confuse our future selves. -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: long_line_format.patch Type: text/x-patch Size: 4598 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 25 12:57:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Feb 2016 13:57:46 +0100 Subject: [Freeipa-devel] [PATCH 0424] Pylint: add missing attributes of exceptions to definition in pylint plugin In-Reply-To: <56CED779.50601@redhat.com> References: <56CDEE50.5030506@redhat.com> <56CED779.50601@redhat.com> Message-ID: <56CEFA4A.6060401@redhat.com> On 25.02.2016 11:29, David Kupka wrote: > On 24/02/16 18:54, Martin Basti wrote: >> Pylint is not able to handle IPA errors objects, because attributes are >> added into objects dynamically, and pylint 1.5 reports them as no-member >> errors. >> >> https://fedorahosted.org/freeipa/ticket/5615 >> >> Patch attached. >> >> > > It would be better to define all errors with all unrecoverable members > but this is sufficient start. More can be add when it's needed. > > Works for me, ACK. > Pushed to: master: 5c33edcd11c466df59dbd13aac5e1b42ffa6fbb7 ipa-4-3: a7fc12b3abc1d6e1bd8d817f6358455202e17fad ipa-4-2: a27f7dfa483fa1f088b46544f323fe3801a08b56 From tbordaz at redhat.com Thu Feb 25 13:12:29 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 25 Feb 2016 14:12:29 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56CEF9FF.8040809@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> <56CEDF98.7060809@redhat.com> <56CEE2C5.10806@redhat.com> <56CEF9FF.8040809@redhat.com> Message-ID: <56CEFDBD.90203@redhat.com> On 02/25/2016 01:56 PM, Martin Babinsky wrote: > On 02/25/2016 12:17 PM, thierry bordaz wrote: >> On 02/25/2016 12:03 PM, Martin Babinsky wrote: >>> On 02/24/2016 04:30 PM, thierry bordaz wrote: >>>> On 01/21/2016 05:04 PM, Martin Babinsky wrote: >>>>> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>>>>> >>>>>> >>>>>> >>>>> Hi Thierry, >>>>> >>>>> I have couple of comments to your patch: >>>>> >>>>> 1.) >>>>> there is a number of PEP8 errors in the patch >>>>> (http://paste.fedoraproject.org/313246/33893701), please fix them. >>>>> >>>>> See http://www.freeipa.org/page/Python_Coding_Style for our >>>>> conventions used in Python code. >>>>> >>>>> 2.) >>>>> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >>>>> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >>>>> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >>>>> Plugin,cn=plugins,cn=config' >>>>> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >>>>> >>>>> Uppercase names are usually reserved for module-level constants. >>>>> OTOH, >>>>> local variables should be lowercase. Also you can instantiate >>>>> dna_config_base directly as DN, using 2-member tuples, i. e: >>>>> >>>>> """ >>>>> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric >>>>> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >>>>> """ >>>>> >>>>> When passing DN object to the formatting functions/operators, it is >>>>> automatically converted to string so no need to hold string and DN >>>>> object separately. This is done in other places (see function/methods >>>>> in replication.py). >>>>> >>>>> 3.) >>>>> >>>>> + for i in range(len(entries)) : >>>>> + >>>>> + mod = [] >>>>> + if entries[i].single_value.get(DNA_BIND_METHOD) != >>>>> method: >>>>> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, >>>>> method)) >>>>> + >>>>> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >>>>> protocol: >>>>> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >>>>> protocol)) >>>>> >>>>> >>>>> please use idiomatic Python when handling list of entries, e.g.: >>>>> >>>>> """ >>>>> for entry in entries: >>>>> mod = [] >>>>> if entry.single_value.get(DNA_BIND_METHOD) != method: >>>>> ... >>>>> """ >>>>> >>>>> 4.) I think that this method should in DSInstance class since it >>>>> deals >>>>> with directory server configuration. Service is a parent object of >>>>> all >>>>> other service installers/configurators and should contain only >>>>> methods >>>>> common to more children. >>>>> >>>>> 5.) Since the method is called from every installer, it could be >>>>> beneficial to call it in DSInstance.__common_post_setup() as a >>>>> part of >>>>> Directory server installation. Is there any reason why this is not >>>>> the >>>>> case? >>>>> >>>>> 6.) >>>>> >>>>> + while attempt != MAX_WAIT: >>>>> + try: >>>>> + entries = conn.get_entries(sharedcfgdn, >>>>> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >>>>> + break >>>>> + except errors.NotFound: >>>>> + root_logger.debug("So far enable not find DNA shared >>>>> config entry for dnaHostname=%s under %s. Retry in 2sec" % >>>>> (self.fqdn, >>>>> sharedcfgdn)) >>>>> + attempt = attempt + 1 >>>>> + time.sleep(2) >>>>> + continue >>>>> + >>>>> + # safety checking >>>>> + # there is no return, if there are several entries, as a >>>>> workaround of #5510 >>>>> + if len(entries) != 1: >>>>> >>>>> I am quite afraid what would happen if the server does not return any >>>>> entries until 30 s timeout. The code will then continue to the >>>>> condition which can potentially test an uninitialized variable and >>>>> blow up with 'NameError'. This should be handled more robustly, e. g. >>>>> raise an exception when a timeout is reached and no entries were >>>>> returned. >>>>> >>>>> 7.) >>>>> >>>>> + if len(mod) > 0: >>>>> >>>>> A Pythonic way to test for non-empty container is >>>>> >>>>> """ >>>>> if mods: >>>>> # do stuff >>>>> """ >>>>> >>>>> since an empty list/dict/set evaluates to False and non-empty >>>>> containers are True. >>>>> >>>>> >>>>> 8.) >>>>> >>>>> + entry = conn.get_entry(entries[i].dn) >>>>> + if entry.single_value.get(DNA_BIND_METHOD) != >>>>> method: >>>>> + root_logger.error("Fail to set SASL/GSSAPI bind >>>>> method to %s" % (entries[i].dn)) >>>>> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >>>>> protocol: >>>>> + root_logger.error("Fail to set LDAP protocol to >>>>> %s" % (entries[i].dn)) >>>>> >>>>> rather than re-fetching the modified entry and testing what happened, >>>>> you can just catch an exception raised by unsuccessfull mod and >>>>> log an >>>>> error like this: >>>>> >>>>> """ >>>>> try: >>>>> conn.modify_s(entry.dn, mod) >>>>> except Exception as e: >>>>> root_logger.error("Failed to modify entry {}: {}".format(entry, >>>>> e)) >>>>> """ >>>>> >>>>> as a matter of fact, if the modify_s operation would fail for some >>>>> reason, an ldap exception would be raised and you checks would not >>>>> even be executed. >>>>> >>>>> 9.) >>>>> The debug message on line 219 should read "Unable to find DNA shared >>>>> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >>>>> at the end of the method should have "Failed" instead of "Fail". >>>>> >>>> Hi Martin, >>>> >>>> Finally tested... here is the updated patch. Thanks for you patience >>>> >>>> >>>> thanks >>>> thierry >>> >>> Hi Thierry, >>> >>> the patch works as expected. >> >> 8-) >>> I have some more nitpicks though: >>> >>> 1.) Please fix the following pep8 errors: >>> >>> http://paste.fedoraproject.org/329086/56397841/ >>> >>> you can check whether you recent commit conforms to PEP8 by running >>> >>> "git show -U0 | pep8 --diff" >> >> I did it and fixed most of them but what remains is long line. I fixed >> some of them but sometime I think it make the code more complex to read. >> Should I split those lines anyway ? >> > There are some lines that are over 120 characters long and that's > really too much. See my quick patch which I attached to make the long > lines pep8-conformant. I also fixes some redundant parentheses in the > format string and replaces raised exception with logger error. >>> >>> 2.) >>> + self.step("update DNA shared config entry", >>> self.update_dna_shared_config) >>> >>> I would rather change the message to "Updating DNA shared config >>> entry" since all other messages use continuous tense. >> >> Right. I will do. >> >>> >>> 3.) >>> + else: >>> + raise RuntimeError("Could not get dnaHostname entries >>> in {} seconds".format(max_wait * 2)) >>> >>> Please use root_logger.error() and then return as is used elsewhere in >>> the method. We do not want a runaway exception crashing upgrade. >> ok I understand. I will fix that >> >> Thanks Martin >> >> > + # a server waits for 30s after its startup to update its > shared config > + max_wait = 30 > + for i in range(0, max_wait + 1): > > I also realized that we have 30s timeout in the comment here, bu we > actually wait for 60 seconds (30 * time.sleep(2)). We should fix the > comment as to not confuse our future selves. > Hello Martin Thanks for correcting that patch, it looks very good. I will merge it with my patch and retesting it. The server is waiting 30sec after plugin startup to create/update the shared config entries. In fact I preferred to wait more because startup could be delayed a bit. The routine will complete immediately if the shared entry already exists, else it will usually wait <~30s (because the server is usually started few seconds before the routine is called). In case of failure to create shared config entry, the installation will wait up to 60sec. I will change the comment to clarify this thanks thierry From dkupka at redhat.com Thu Feb 25 13:13:09 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 25 Feb 2016 14:13:09 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CDB939.8000505@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> <56CC1C8B.7050600@redhat.com> <56CC22E4.8040104@redhat.com> <56CC5FA2.8030004@redhat.com> <56CC7DAC.9070904@redhat.com> <56CD4472.3000307@redhat.com> <56CDB939.8000505@redhat.com> Message-ID: <56CEFDE5.4090109@redhat.com> On 24/02/16 15:07, Rob Crittenden wrote: > David Kupka wrote: >> On 23/02/16 16:41, Rob Crittenden wrote: >>> David Kupka wrote: >>>> On 23/02/16 10:14, Martin Kosek wrote: >>>>> On 02/23/2016 09:47 AM, David Kupka wrote: >>>>>> On 22/02/16 16:15, Martin Kosek wrote: >>>>>>> On 02/22/2016 04:04 PM, Jan Cholasta wrote: >>>>>>>> On 22.2.2016 15:56, David Kupka wrote: >>>>>>>>> On 22/02/16 07:28, Jan Cholasta wrote: >>>>>>>>>> On 18.2.2016 10:10, David Kupka wrote: >>>>>>>>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>>>>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and >>>>>>>>>>>>>>> removed >>>>>>>>>>>>>>> unused import >>>>>>>>>>>>>>> but otherwise it works, ACK. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Won't this break existing certmonger requests depending on >>>>>>>>>>>>>> the old >>>>>>>>>>>>>> path? >>>>>>>>>>>>> >>>>>>>>>>>>> It will, I don't see any upgrade code. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>> "auditSigningCert >>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>> "subsystemCert >>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>> "caSigningCert >>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>> "Server-Cert >>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>>>>>>>> RHEL72 >>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>>>>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>>>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) >>>>>>>>>>>> where all >>>>>>>>>>>> the other trackings are stopped and then configured again >>>>>>>>>>>> with the >>>>>>>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the catch. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've updated Timo's patch little more and added >>>>>>>>>>> start_tracking_certificates() for dsinstance and httpinstance. >>>>>>>>>>> Now the >>>>>>>>>>> upgrade works as expected. >>>>>>>>>> >>>>>>>>>> The way the patches are split is kind of weird and apparently >>>>>>>>>> confusing >>>>>>>>>> (see the other thread). IMO there should be 2 patches: the first >>>>>>>>>> should >>>>>>>>>> add the ability to change DS and HTTP certmonger config during >>>>>>>>>> upgrade >>>>>>>>>> (i.e. the start_tracking_certificates() methods and >>>>>>>>>> certificate_renewal_update() changes), the second should move the >>>>>>>>>> helpers (i.e. the actual move and certificate_renewal_update() >>>>>>>>>> version >>>>>>>>>> bump). >>>>>>>>>> >>>>>>>>> Honza, do I understand it correctly that the code is OK but I >>>>>>>>> did not >>>>>>>>> split it to the patches correctly? >>>>>>>> >>>>>>>> Yes. >>>>>>> >>>>>>> Before acking or pushing, can you please explain for me how the >>>>>>> upgrade of >>>>>>> certmonger tracking requests work? I want to make sure this is >>>>>>> right, so please >>>>>>> bear with me: >>>>>>> >>>>>>> 1) How does it edit existing tracking requests with the new helper >>>>>>> paths? >>>>>>> >>>>>>> 2) Does it go and try to edit the requests on every upgrade? Or is >>>>>>> there some >>>>>>> check that requests were updated? >>>>>>> >>>>>>> Thanks, >>>>>>> Martin >>>>>>> >>>>>> >>>>>> Whole upgrade of renewal requests is done in >>>>>> ipaserver/install/server/upgrade.py in certificate_renewal_upgrade(). >>>>>> >>>>>> First there is version of requests and if it's the same as in state >>>>>> file >>>>>> upgrade is skipped. >>>>>> Then every request is searched over certmonger's DBus interface and >>>>>> if at least >>>>>> one is not found it means that there was change in request >>>>>> configuration. All >>>>>> tracking requests are then stopped and started again with new >>>>>> configuration. >>>>>> >>>>>> So to answer you questions: >>>>>> 1) By stopping the old request with the old parameters (including >>>>>> path) and >>>>>> starting new with new parameters. >>>>>> >>>>>> 2) Only if version was bumped which happens only if some of the >>>>>> requests changes. >>>>> >>>>> Ah, so IIUC, if you bump the version, requests should be properly >>>>> updated. The >>>>> change looks fine then. >>>>> >>>> >>>> After discussion with Honza, we decided to drop the part comparing only >>>> base names of pre- and post-save commands and use it as whole. I've also >>>> split the patches so it's obvious what is going on. >>>> >>>> Patches should be applied in this order: >>>> >>>> freeipa-dkupka-0091.0 >>> >>> A cert could silently fail to be tracked in >>> start_tracking_certificates() if no serverid can be found. >> >> In that case it also wouldn't be stopped. The behavior is the same as in >> existing stop_tracking_certificates(). Should we rather raise and stop >> the upgrade? I guess not but warning would be probably useful. What >> solution would you prefer, Rob? > > I don't know all the callers of this. It may be perfectly safe to assume > that a serverid is always there, but the implication if it isn't is that > some tracking cert won't be updated properly right? That potentially > could mean no renewal. > > So the consequences could be severe, I just don't know the likelihood. > > In other words, a comment (# can never get here) might be perfectly > adequate. > > rob > >> >>> >>>> freeipa-dkupka-0087.1 >>>> freeipa-dkupka-0088.1 >>>> freeipa-tjaalton-0011.2 >>>> freeipa-dkupka-0092.0 >>>> >>>> >>>> >> >> > Currently the function is called only from one place (also added in this patch) but to avoid problems in the future I made the serverid parameter mandatory. Also I squashed the version bump into Timo's patch. Updated patches attached. Apply in this order: freeipa-dkupka-0091.1 freeipa-dkupka-0087.2 freeipa-dkupka-0088.2 freeipa-tjaalton-0011.3 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0087.2-dsinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 4097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0088.2-httpinstance-add-start_tracking_certificates-method.patch Type: text/x-patch Size: 3767 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0091.1-upgrade-Match-whole-pre-post-command-not-just-basena.patch Type: text/x-patch Size: 4115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0011.3-Move-freeipa-certmonger-helpers-to-libexecdir.patch Type: text/x-patch Size: 5709 bytes Desc: not available URL: From tbabej at redhat.com Thu Feb 25 13:13:56 2016 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 25 Feb 2016 14:13:56 +0100 Subject: [Freeipa-devel] [PATCH 0401] ipa-adtrust-install: Allow dash in the NETBIOS name Message-ID: <56CEFE14.9000905@redhat.com> Hi, Dash should be one of the allowed characters in the netbios names, so relax the too strict validation. Note: the set of allowed characters might expand in the future https://fedorahosted.org/freeipa/ticket/5286 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-tbabej-0401-ipa-adtrust-install-Allow-dash.patch Type: text/x-patch Size: 3027 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0401-ipa-adtrust-install-Allow-dash-in-the-NETBIOS-name.patch Type: text/x-patch Size: 2719 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 25 13:23:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Feb 2016 14:23:44 +0100 Subject: [Freeipa-devel] [PATCH 0001] Add new parameter --ssh-update to ipa-client-install In-Reply-To: <1456175624.5411.4.camel@stefany.eu> References: <1456175624.5411.4.camel@stefany.eu> Message-ID: <56CF0060.3090202@redhat.com> On 22.02.2016 22:13, Martin ?tefany wrote: > Hi, > > please, review the attached patch which adds --ssh-update to ipa-client- > install. > > Ticket: https://fedorahosted.org/freeipa/ticket/2655 Hello, thank you for your patch. Please attach a patch as a file next time. I have doubts that this should be part of ipa-client-install, this needs a broader discussion. Code comments inline: > > --- > Martin > > From 4974a57f48a0cd48b83724297ae2af572bc530eb Mon Sep 17 00:00:00 2001 > From: Martin Stefany > Date: Mon, 22 Feb 2016 20:58:13 +0000 > Subject: [PATCH] Add new parameter --ssh-update to ipa-client-install > > Add a new parameter '--ssh-update' which can be used later after freeipa > client is installed to update SSH hostkeys and SSHFP DNS records for > host. > > https://fedorahosted.org/freeipa/ticket/2655 > --- > ipa-client/ipa-install/ipa-client-install | 102 > +++++++++++++++++++++++++++++- > 1 file changed, 99 insertions(+), 3 deletions(-) > > diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa- > install/ipa-client-install > index > 789ff591591673744ee3b922e5c0181233ad553c..97adfb6b449fb441bddada89a3b151 > 33e398ca50 100755 > --- a/ipa-client/ipa-install/ipa-client-install > +++ b/ipa-client/ipa-install/ipa-client-install > @@ -71,6 +71,7 @@ CLIENT_INSTALL_ERROR = 1 > CLIENT_NOT_CONFIGURED = 2 > CLIENT_ALREADY_CONFIGURED = 3 > CLIENT_UNINSTALL_ERROR = 4 # error after restoring files/state > +CLIENT_SSHUPDATE_ERROR = 5 # error during update of SSH public keys > > def parse_options(): > def validate_ca_cert_file_option(option, opt, value, parser): > @@ -215,6 +216,12 @@ def parse_options(): > "be run with --unattended > option") > parser.add_option_group(uninstall_group) > > + sshupdate_group = OptionGroup(parser, "SSH key update options") > + sshupdate_group.add_option("--ssh-update", dest="ssh_update", > + action="store_true", default=False, > + help="update local host's SSH public keys in host > entry and DNS.") > + parser.add_option_group(sshupdate_group) > + > options, args = parser.parse_args() > safe_opts = parser.get_safe_opts(options) > > @@ -840,6 +847,92 @@ def uninstall(options, env): > > return rv > > +def sshupdate(options, env): > + if not is_ipa_client_installed(): > + root_logger.error("IPA client is not configured on this > system.") > + return CLIENT_NOT_CONFIGURED > + > + api.bootstrap(context='cli_installer', debug=options.debug) > + api.finalize() > + if 'config_loaded' not in api.env: > + root_logger.error("Failed to initialize IPA API.") > + return CLIENT_SSHUPDATE_ERROR > + > + # Now, let's try to connect to the server's RPC interface > + connected = False > + try: > + api.Backend.rpcclient.connect() > + connected = True > + root_logger.debug("Try RPC connection") > + api.Backend.rpcclient.forward('ping') > + except errors.KerberosError as e: > + if connected: > + api.Backend.rpcclient.disconnect() > + root_logger.info( > + "Cannot connect to the server due to Kerberos error: %s. " > + "Trying with delegate=True", e) > + try: > + api.Backend.rpcclient.connect(delegate=True) > + root_logger.debug("Try RPC connection") > + api.Backend.rpcclient.forward('ping') > + > + root_logger.info("Connection with delegate=True > successful") > + > + # The remote server is not capable of Kerberos S4U2Proxy > + # delegation. This features is implemented in IPA server > + # version 2.2 and higher > + root_logger.warning( > + "Target IPA server has a lower version than the > enrolled " > + "client") > + root_logger.warning( > + "Some capabilities including the ipa command capability > " > + "may not be available") > + except errors.PublicError as e2: > + root_logger.warning( > + "Second connect with delegate=True also failed: %s", > e2) > + root_logger.error( > + "Cannot connect to the IPA server RPC interface: %s", > e2) > + return CLIENT_SSHUPDATE_ERROR > + except errors.PublicError as e: > + root_logger.error( > + "Cannot connect to the server due to generic error: %s", e) > + return CLIENT_SSHUPDATE_ERROR I think you should be kinited with client keytab, client is allowed to modify its SSHpublic keys in ldap. I'd only require to be root to execute it. kinit -kt /etc/krb5.keytab host/`hostname` ipa host-mod `hostname` --sshpubkey="something" Also this rpcconnection looks to me too much complicated, I think it should be just simple rpcconnect > + > + # We need to pull IPA server address from default.conf > + try: > + parser = RawConfigParser() > + parser.read(paths.IPA_DEFAULT_CONF) > + cli_realm = parser.get('global', 'realm') > + hostname = parser.get('global', 'host') > + # TODO: consult with review team > + # except ConfigParser.NoSectionError as e: > + # pass > + # except ConfigParser.ParsingError as e: > + # pass > + finally: > + pass You can raise error there. > + > + host_principal = 'host/%s@%s' % (hostname, cli_realm) > + # Obtain the TGT. We do it with the temporary krb5.conf, so that > + # only the KDC we're installing under is contacted. > + # Other KDCs might not have replicated the principal yet. > + # Once we have the TGT, it's usable on any server. I don't think that temporary krb5.conf should be used here > + try: > + ipautil.kinit_keytab(host_principal, paths.KRB5_KEYTAB, > + CCACHE_FILE, > + # config=krb_name, > + attempts=options.kinit_attempts) > + env['KRB5CCNAME'] = os.environ['KRB5CCNAME'] = CCACHE_FILE > + except Krb5Error as e: > + print_port_conf_info() > + root_logger.error("Failed to obtain host TGT: %s" % e) > + # failure to get ticket makes it impossible to login and bind > + # from sssd to LDAP, abort installation and rollback changes > + return CLIENT_INSTALL_ERROR This is not install error. > + > + # passing server parameter seems unneccessary, thus passing only "" > + update_ssh_keys("", hostname, > services.knownservices.sshd.get_config_dir(), options.create_sshfp) > + > def configure_ipa_conf(fstore, cli_basedn, cli_realm, cli_domain, > cli_server, hostname): > ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") > ipaconf.setOptionAssignment(" = ") > @@ -2797,7 +2890,7 @@ def install(options, env, fstore, statestore): > connected = True > root_logger.debug("Try RPC connection") > api.Backend.rpcclient.forward('ping') > - except errors.KerberosError, e: > + except errors.KerberosError as e: Please don't modify code that already exists and it is not related to this change > if connected: > api.Backend.rpcclient.disconnect() > root_logger.info( > @@ -2820,13 +2913,13 @@ def install(options, env, fstore, statestore): > root_logger.warning( > "Some capabilities including the ipa command > capability " > "may not be available") > - except errors.PublicError, e2: > + except errors.PublicError as e2: Remove this from patch too > root_logger.warning( > "Second connect with delegate=True also failed: > %s", e2) > root_logger.error( > "Cannot connect to the IPA server RPC interface: > %s", e2) > return CLIENT_INSTALL_ERROR > - except errors.PublicError, e: > + except errors.PublicError as e: and this too > root_logger.error( > "Cannot connect to the server due to generic error: > %s", e) > return CLIENT_INSTALL_ERROR > @@ -3088,6 +3181,9 @@ def main(): > if options.uninstall: > return uninstall(options, env) > > + if options.ssh_update: > + return sshupdate(options, env) > + > if is_ipa_client_installed(on_master=options.on_master): > root_logger.error("IPA client is already configured on this > system.") > root_logger.info( > -- > 1.8.3.1 > > Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Feb 25 13:30:26 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Feb 2016 14:30:26 +0100 Subject: [Freeipa-devel] [PATCH 0413] fix permission: Read Replication Agreements In-Reply-To: <56CDC196.8020108@redhat.com> References: <56C47A58.6050207@redhat.com> <56CAC021.8080906@redhat.com> <56CC86E8.1040501@redhat.com> <56CD7BAB.4040906@redhat.com> <56CD9CF3.2040905@redhat.com> <56CDA3E3.4070407@redhat.com> <56CDC196.8020108@redhat.com> Message-ID: <56CF01F2.1020704@redhat.com> On 24.2.2016 15:43, Martin Basti wrote: > > > On 24.02.2016 13:36, Jan Cholasta wrote: >> On 24.2.2016 13:07, Martin Basti wrote: >>> >>> >>> On 24.02.2016 10:45, Jan Cholasta wrote: >>>> On 23.2.2016 17:20, Martin Basti wrote: >>>>> >>>>> >>>>> On 22.02.2016 09:00, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 17.2.2016 14:49, Martin Basti wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/5631 >>>>>>> >>>>>>> Patch attached (for master, 4.3, 4.2) >>>>>> >>>>>> 1) All the replication agreement permission ACIs should be located in >>>>>> the same entry. Currently "Read Replication Agreements" is in >>>>>> "cn=config" and everything else in "cn=mapping tree,cn=config", so I >>>>>> guess "cn=mapping tree,cn=config" makes more sense. >>>>>> >>>>>> >>>>>> 2) Instead of literal DN('cn=permissions,cn=pbac'), use >>>>>> api.env.container_permissions. >>>>>> >>>>>> >>>>>> 3) IMO the removal of managed permission attributes could be a little >>>>>> bit more robust. You should check that the original entry contains >>>>>> all >>>>>> the required values before touching it (objectclass=ipapermissionv2, >>>>>> ipapermissiontype=V2, ipapermissiontype=MANAGED) and remove only the >>>>>> values that need to be removed, instead of just overwriting >>>>>> everything. >>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> Updated patch attached. >>>> >>>> The patch does not apply on ipa-4-2. >>>> >>> I will send it later. >>> >>>> Also this bit in replica-acis.ldif is redundant: >>>> >>>> + >>>> +dn: cn=mapping tree,cn=config >>>> +changetype: modify >>>> +add: aci >>> All related ACIs to replication are in both replica-acis.ldif and >>> 20-aci.update. >>> I just do not want to mess it more than it is. >> >> What I'm trying to say is that: >> >> dn: cn=mapping tree,cn=config >> changetype: modify >> add: aci >> aci: $ACI1 >> >> dn: cn=mapping tree,cn=config >> changetype: modify >> add: aci >> aci: $ACI2 >> >> is the same as: >> >> dn: cn=mapping tree,cn=config >> changetype: modify >> add: aci >> aci: $ACI1 >> aci: $ACI2 >> >> . You actually have it right in 20-aci.update, but not in >> replica-acis.ldif. >> > I made it in that way to keep consistency in the replica-acis.ldif file. I see. I missed that. > > Patch for 4-2 added Thanks, ACK. Pushed to: master: bba2355631c4cbadfb5089663c2a3af65a817fb7 ipa-4-2: de7ec77ea8811a6add2eab5d0853686484ae732c ipa-4-3: 2bac05a18720c4ab84bc1de5573d3d96e73ddc55 -- Jan Cholasta From jcholast at redhat.com Thu Feb 25 13:36:19 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Feb 2016 14:36:19 +0100 Subject: [Freeipa-devel] [PATCH 0001] Add new parameter --ssh-update to ipa-client-install In-Reply-To: <56CF0060.3090202@redhat.com> References: <1456175624.5411.4.camel@stefany.eu> <56CF0060.3090202@redhat.com> Message-ID: <56CF0353.5060705@redhat.com> Hi, On 25.2.2016 14:23, Martin Basti wrote: > > > On 22.02.2016 22:13, Martin ?tefany wrote: >> Hi, >> >> please, review the attached patch which adds --ssh-update to ipa-client- >> install. >> >> Ticket:https://fedorahosted.org/freeipa/ticket/2655 > Hello, > thank you for your patch. > Please attach a patch as a file next time. > > I have doubts that this should be part of ipa-client-install, this needs > a broader discussion. +1, I think it should be a separate command (ignore my earlier suggestion from Trac to incorporate this into ipa-client-install, I was young and stupid). See client/ipa-certupdate and ipaclient/ipa_certupdate.py for an example of how such a command should be implemented. > > Code comments inline: >> >> --- >> Martin >> >> >From 4974a57f48a0cd48b83724297ae2af572bc530eb Mon Sep 17 00:00:00 2001 >> From: Martin Stefany >> Date: Mon, 22 Feb 2016 20:58:13 +0000 >> Subject: [PATCH] Add new parameter --ssh-update to ipa-client-install >> >> Add a new parameter '--ssh-update' which can be used later after freeipa >> client is installed to update SSH hostkeys and SSHFP DNS records for >> host. >> >> https://fedorahosted.org/freeipa/ticket/2655 >> --- >> ipa-client/ipa-install/ipa-client-install | 102 >> +++++++++++++++++++++++++++++- >> 1 file changed, 99 insertions(+), 3 deletions(-) >> >> diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa- >> install/ipa-client-install >> index >> 789ff591591673744ee3b922e5c0181233ad553c..97adfb6b449fb441bddada89a3b151 >> 33e398ca50 100755 >> --- a/ipa-client/ipa-install/ipa-client-install >> +++ b/ipa-client/ipa-install/ipa-client-install >> @@ -71,6 +71,7 @@ CLIENT_INSTALL_ERROR = 1 >> CLIENT_NOT_CONFIGURED = 2 >> CLIENT_ALREADY_CONFIGURED = 3 >> CLIENT_UNINSTALL_ERROR = 4 # error after restoring files/state >> +CLIENT_SSHUPDATE_ERROR = 5 # error during update of SSH public keys >> >> def parse_options(): >> def validate_ca_cert_file_option(option, opt, value, parser): >> @@ -215,6 +216,12 @@ def parse_options(): >> "be run with --unattended >> option") >> parser.add_option_group(uninstall_group) >> >> + sshupdate_group = OptionGroup(parser, "SSH key update options") >> + sshupdate_group.add_option("--ssh-update", dest="ssh_update", >> + action="store_true", default=False, >> + help="update local host's SSH public keys in host >> entry and DNS.") >> + parser.add_option_group(sshupdate_group) >> + >> options, args = parser.parse_args() >> safe_opts = parser.get_safe_opts(options) >> >> @@ -840,6 +847,92 @@ def uninstall(options, env): >> >> return rv >> >> +def sshupdate(options, env): >> + if not is_ipa_client_installed(): >> + root_logger.error("IPA client is not configured on this >> system.") >> + return CLIENT_NOT_CONFIGURED >> + >> + api.bootstrap(context='cli_installer', debug=options.debug) >> + api.finalize() >> + if 'config_loaded' not in api.env: >> + root_logger.error("Failed to initialize IPA API.") >> + return CLIENT_SSHUPDATE_ERROR >> + >> + # Now, let's try to connect to the server's RPC interface >> + connected = False >> + try: >> + api.Backend.rpcclient.connect() >> + connected = True >> + root_logger.debug("Try RPC connection") >> + api.Backend.rpcclient.forward('ping') >> + except errors.KerberosError as e: >> + if connected: >> + api.Backend.rpcclient.disconnect() >> + root_logger.info( >> + "Cannot connect to the server due to Kerberos error: %s. " >> + "Trying with delegate=True", e) >> + try: >> + api.Backend.rpcclient.connect(delegate=True) >> + root_logger.debug("Try RPC connection") >> + api.Backend.rpcclient.forward('ping') >> + >> + root_logger.info("Connection with delegate=True >> successful") >> + >> + # The remote server is not capable of Kerberos S4U2Proxy >> + # delegation. This features is implemented in IPA server >> + # version 2.2 and higher >> + root_logger.warning( >> + "Target IPA server has a lower version than the >> enrolled " >> + "client") >> + root_logger.warning( >> + "Some capabilities including the ipa command capability >> " >> + "may not be available") >> + except errors.PublicError as e2: >> + root_logger.warning( >> + "Second connect with delegate=True also failed: %s", >> e2) >> + root_logger.error( >> + "Cannot connect to the IPA server RPC interface: %s", >> e2) >> + return CLIENT_SSHUPDATE_ERROR >> + except errors.PublicError as e: >> + root_logger.error( >> + "Cannot connect to the server due to generic error: %s", e) >> + return CLIENT_SSHUPDATE_ERROR > I think you should be kinited with client keytab, client is allowed to > modify its SSHpublic keys in ldap. I'd only require to be root to > execute it. > > kinit -kt /etc/krb5.keytab host/`hostname` > ipa host-mod `hostname` --sshpubkey="something" > > Also this rpcconnection looks to me too much complicated, I think it > should be just simple rpcconnect > >> + >> + # We need to pull IPA server address from default.conf >> + try: >> + parser = RawConfigParser() >> + parser.read(paths.IPA_DEFAULT_CONF) >> + cli_realm = parser.get('global', 'realm') >> + hostname = parser.get('global', 'host') >> + # TODO: consult with review team >> + # except ConfigParser.NoSectionError as e: >> + # pass >> + # except ConfigParser.ParsingError as e: >> + # pass >> + finally: >> + pass > You can raise error there. > >> + >> + host_principal = 'host/%s@%s' % (hostname, cli_realm) >> + # Obtain the TGT. We do it with the temporary krb5.conf, so that >> + # only the KDC we're installing under is contacted. >> + # Other KDCs might not have replicated the principal yet. >> + # Once we have the TGT, it's usable on any server. > I don't think that temporary krb5.conf should be used here >> + try: >> + ipautil.kinit_keytab(host_principal, paths.KRB5_KEYTAB, >> + CCACHE_FILE, >> + # config=krb_name, >> + attempts=options.kinit_attempts) >> + env['KRB5CCNAME'] = os.environ['KRB5CCNAME'] = CCACHE_FILE >> + except Krb5Error as e: >> + print_port_conf_info() >> + root_logger.error("Failed to obtain host TGT: %s" % e) >> + # failure to get ticket makes it impossible to login and bind >> + # from sssd to LDAP, abort installation and rollback changes >> + return CLIENT_INSTALL_ERROR > This is not install error. > >> + >> + # passing server parameter seems unneccessary, thus passing only "" >> + update_ssh_keys("", hostname, >> services.knownservices.sshd.get_config_dir(), options.create_sshfp) >> + >> def configure_ipa_conf(fstore, cli_basedn, cli_realm, cli_domain, >> cli_server, hostname): >> ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") >> ipaconf.setOptionAssignment(" =") @@ -2797,7 +2890,7 @@ def install(options, env, fstore, >> statestore): connected = True >> root_logger.debug("Try RPC connection") >> api.Backend.rpcclient.forward('ping') >> - except errors.KerberosError, e: >> + except errors.KerberosError as e: > Please don't modify code that already exists and it is not related to > this change >> if connected: >> api.Backend.rpcclient.disconnect() >> root_logger.info( >> @@ -2820,13 +2913,13 @@ def install(options, env, fstore, statestore): >> root_logger.warning( >> "Some capabilities including the ipa command >> capability " >> "may not be available") >> - except errors.PublicError, e2: >> + except errors.PublicError as e2: > Remove this from patch too >> root_logger.warning( >> "Second connect with delegate=True also failed: >> %s", e2) >> root_logger.error( >> "Cannot connect to the IPA server RPC interface: >> %s", e2) >> return CLIENT_INSTALL_ERROR >> - except errors.PublicError, e: >> + except errors.PublicError as e: > and this too >> root_logger.error( >> "Cannot connect to the server due to generic error: >> %s", e) >> return CLIENT_INSTALL_ERROR >> @@ -3088,6 +3181,9 @@ def main(): >> if options.uninstall: >> return uninstall(options, env) >> >> + if options.ssh_update: >> + return sshupdate(options, env) >> + >> if is_ipa_client_installed(on_master=options.on_master): >> root_logger.error("IPA client is already configured on this >> system.") >> root_logger.info( >> -- >> 1.8.3.1 >> >> > > Martin^2 > > Honza -- Jan Cholasta From pspacek at redhat.com Thu Feb 25 13:45:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 14:45:50 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1456323946.6599.254.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> Message-ID: <56CF058E.4020709@redhat.com> On 24.2.2016 15:25, Simo Sorce wrote: > On Wed, 2016-02-24 at 10:00 +0100, Martin Kosek wrote: >> On 02/23/2016 06:59 PM, Petr Spacek wrote: >>> On 23.2.2016 18:14, Simo Sorce wrote: >> ... >>>> More seriously I think it is a great idea, but too premature to get all >>>> the way there now. We need to build schema and CLI that will allow us to >>>> get there without having to completely change interfaces if at all >>>> possible or minimizing any disruption in the tools. >>> >>> Actually the backwards compatibility is the main worry which led to this idea >>> with links. >>> >>> If we release first version of locations with custom priorities etc. we will >>> have support the schema (which will be different) and API (which will be later >>> unnecessary) forever. >>> >>> If we skip this intermediate phase with hand-made configuration we can save >>> all the headache with upgrades to more automatic solution later on. >>> >>> >>> Maybe we should invert the order: >>> Start with locations + links with administrative metric and add hand-tweaking >>> capabilities later (if necessary). >>> >>> IMHO locations + links with administrative metric will be easier to implement >>> than the first version. >>> >>> Just thinking aloud ... >> >> Makes sense to me, I would have the same worry as Petr, that we would break >> something if we decide moving to links based solution later. > > Maybe I am missing something, but in order to generate the proper SRV > records we need priority and weights anyway, either by entering them > manually or by autogenerating them from some other piece of information > in the framework. So given this information is needed anyway why would > it become a problem to retain it in the future if we enable a tool the > simply autogenerates this information ? Let me clarify this: You are right, in the end we always somehow get to priorities and weights. TL;DR version ============= The difference is subtle details how we get priorities and if we store them in LDAP and represent them in API (or not). It will simplify things if we do not expose them. I'm not convinced that we *need* to expose them in the first round. TL version ========== In the high level the process is always as follows: 1. input tuples (location, server, weight) for all primary servers assigned to locations 2. input or derive (location, server, priority) for all backups 3. generate SRV records using priority groups combined from the previous two steps Now we are trying to decide if step (2) is "input" OR "derive" priorities for backup servers. Variants ~~~~~~~~ Variant A --------- If we let the user to do everything manually (no links etc.) we need to provide following schema + API + user interface: [first step - same in both variants] * create locations * assign 'main' (aka 'primary' aka 'home') servers to locations ++ specify weights for the 'main' servers in given location, i.e. manually input (server, weight) tuples [second step] * specify backup servers for each location ++ assign (server, priority, weight) information for each non-main server ++ for S servers and L locations we need to represent up to S * L tuples (server, priority, weight) and provide means to manage it ++ most importantly, maintenance complexity of backups grows any time you add one of (server OR location) ++ this would be a nightmare to manage. For simple cases this require some 'include' mechanism to declare one location as backup for another location. This include complicates things significantly as it has a lot of corner cases and requires different LDAP schema when compared to direct servers assignment. Variant B --------- If we let the user only specify locations + links with costs we need to provide following schema + API + user interface: [first step - no change from variant A] * create locations * assign 'main' (aka 'primary' aka 'home') servers to locations ++ specify weights for the 'main' servers in given location, i.e. manually input (server, weight) tuples [second step] * create links between locations ++ manually assign point-to-point information + administrative cost ++ for S servers and L locations we need to represent up to L^2 tuples (from, to, cost) and provide means to manage it ++ storage can be optimized to great extent if there is a lot of links with equal cost, typically a full-mesh interconnections can be represented by single object in LDAP * generate backups (i.e. priority assignment) using usual routing algorithms. Priority does not need to be neither exposed to user nor stored in LDAP at all. ++ most importantly, maintenance complexity of backups grows while you add locations *but* you do not need to manually go though backup configuration for (potentially) all locations every time as you add/change/remove servers in existing locations (which you have to do with variant A, unless you use some smart includes ...). Please note that variant B with (links, costs) do not use explicit priority specification at all as this is always calculated by a algorithm. If we ever decide to provide means to hand-tweak generated priorities, we can still invent LDAP schema and API for variant A and populate it with data generated by the variant B algorithm, but we do not need to do that today. Less schema and less API -> smaller maintenance costs. Does it clarify why (link, cost) model is easier to manage for end-user than (server, priority, weight)? Variant C --------- An alternative is to be lazy and dumb. Maybe it would be enough for the first round ... We would retain [first step - no change from variant A] * create locations * assign 'main' (aka 'primary' aka 'home') servers to locations ++ specify weights for the 'main' servers in given location, i.e. manually input (server, weight) tuples Then, backups would be auto-generated set of all remaining servers from all other locations. Additional storage complexity: 0 This covers the scenario "always prefer local servers and use remote only as fallback" easily. It does not cover any other scenario. This might be sufficient for the first run and would allow us to gather some feedback from the field. Now I'm inclined to this variant :-) Bonus ===== Variant B with links has some fancy properties, here are some for curious: * Speaking of storage, there is an interesting consequence: Assumption (S = number of servers) >= (L = number of locations) Variant A complexity: S * L Variant B complexity: L * L => S * L >= L * L => variant A complexity >= variant B complexity This holds for the usual cases where all servers within one location have the same priority. * Other cases can be represented in variant B using new location and appropriate link costs. Variant B requires splitting hot backups to separate location like "CZ-hot-backup", which is then easy to display in topology graph etc. * Coincidentally, variant B allows to do fancy things like empty locations which are used only for routing. This nicely describe situation where all branch offices have own local servers and are connected to a VPN concentrator somewhere in the middle of a continent. E.g. declare 'hub' location with no IPA servers in it. Then create links (branch, hub, cost) for each branch office. This trivial configuration would automatically allow to compute backups for branch1 in optimal way, where clients form branch1 prefer branch2 over branch3 because branch3 has crappy VPN link. If you reached this point while not skipping anything you deserve some reward points, let me know :-D -- Petr^2 Spacek From ldoudova at redhat.com Thu Feb 25 14:08:22 2016 From: ldoudova at redhat.com (Lenka Doudova) Date: Thu, 25 Feb 2016 15:08:22 +0100 Subject: [Freeipa-devel] [TESTS][PATCH 0011] WebUI: Creating user without private group Message-ID: <56CF0AD6.4060505@redhat.com> Hi, here's a patch for webUI tests that provides test for creating user without private group. Related to ticket https://fedorahosted.org/freeipa/ticket/4986 Since the option to specify GID when creating a user is not available https://fedorahosted.org/freeipa/ticket/5505 the test creates a new posix group, makes it a default user group instead of 'ipausers' and then attemps to create the user without private group. Returning default user group value to 'ipausers' is provided even for cases when the test fails so it would not block other tests from performing properly. Lenka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ldoudova-0011-WebUI-Test-creating-user-without-private-group.patch Type: text/x-patch Size: 2628 bytes Desc: not available URL: From simo at redhat.com Thu Feb 25 14:28:01 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 25 Feb 2016 09:28:01 -0500 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56CF058E.4020709@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> Message-ID: <1456410481.6599.279.camel@redhat.com> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: > Variant C > --------- > An alternative is to be lazy and dumb. Maybe it would be enough for > the first > round ... > > We would retain > [first step - no change from variant A] > * create locations > * assign 'main' (aka 'primary' aka 'home') servers to locations > ++ specify weights for the 'main' servers in given location, i.e. > manually > input (server, weight) tuples > > Then, backups would be auto-generated set of all remaining servers > from all > other locations. > > Additional storage complexity: 0 > > This covers the scenario "always prefer local servers and use remote > only as > fallback" easily. It does not cover any other scenario. > > This might be sufficient for the first run and would allow us to > gather some > feedback from the field. > > Now I'm inclined to this variant :-) To be honest, this is all I always had in mind, for the first step. To recap: - define a location with the list of servers (perhaps location is a property of server objects so you can have only one location per server, and if you remove the server it is automatically removed from the location w/o additional work or referential integrity necessary), if weight is not defined (default) then they all have the same weight. - Allow to specify backup locations in the location object, priorities are calculated automatically and all backup locations have same weight. - Define a *default* location, which is the backup for any other location but always with lower priority to any other explicitly defined backup locations. - Weights for backup location servers are the same as the weight defined within the backup location itself, so no additional weights are defined for backups. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Feb 25 14:48:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Feb 2016 15:48:53 +0100 Subject: [Freeipa-devel] [PATCH 0425] pylint: suppress false positive no-member errors Message-ID: <56CF1455.3020904@redhat.com> The last pylint 1.5 patch, \o/ https://fedorahosted.org/freeipa/ticket/5615 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0425-pylint-supress-false-positive-no-member-errors.patch Type: text/x-patch Size: 11767 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbasti-0425-pylint-supress-false-positive-no-member-errors.patch Type: text/x-patch Size: 8644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-3-mbasti-0425-pylint-supress-false-positive-no-member-errors.patch Type: text/x-patch Size: 11767 bytes Desc: not available URL: From pvomacka at redhat.com Thu Feb 25 14:50:00 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 25 Feb 2016 15:50:00 +0100 Subject: [Freeipa-devel] [PATCH] 0005 webui: topology graph: canvas resizes itself according to the window size In-Reply-To: <56C4ADF0.4080702@redhat.com> References: <56BC7105.3020609@redhat.com> <56BDD5A6.8010108@redhat.com> <56C1ECA4.2070900@redhat.com> <56C4ADF0.4080702@redhat.com> Message-ID: <56CF1498.8080302@redhat.com> On 02/17/2016 06:29 PM, Petr Vobornik wrote: > On 02/15/2016 04:20 PM, Pavel Vomacka wrote: >> >> >> On 02/12/2016 01:52 PM, Pavel Vomacka wrote: >>> >>> >>> On 02/11/2016 12:31 PM, Pavel Vomacka wrote: >>>> Hello, >>>> >>>> The canvas of the graph had static size. This patch fixes this issue >>>> and from now the graph canvas is resized according to the window size. >>>> >>>> Pavel Vomacka >>>> >>>> >>> Because of changes in previous patch I'm sending also this one again. >>> Plus I fixed some jslint warnings. >>> >>> And again a link to the ticket: >>> https://fedorahosted.org/freeipa/ticket/5647 . >>> >>> -- >>> Pavel^3 Vomacka >>> >>> >> And another change in the code. This patch adds checking whether a svg >> element even exists. And don't add 'col-sm-12' class to the svg element >> any more. This class just added useless paddings to the element. >> >> -- >> Pavel^3 Vomacka >> > > Hi, > > thanks for the patch. Hi, thank you for reviewing. > > 1. I don't like the fact that the resize handler registered in > initialize method is active forever, even when viewing other facets. I moved the handler to the topology graph facet. It is also removed after hide event is emited. > 2. The code will probably fail if there is other svg element present > on the page. > > $('svg') searches for all svg elements in DOM, such search is usually > slow and undeterministic. It is better to use a stored reference(if > possible) or limit the search to some parent element, e.g. TopoGraph > can store and then use its container. > > Would be funny if there were 2 graphs. Yep, you are right. I avoid using this type of searching in this patch. > > 3. Why is there the toFixed(1) call? Or more specifically on that > position? It hides the fact that toFixed transforms Number to String > and then '-' operator with Number on the right casts it back to Number. The toFixed(1) was used just because we don't need so accurate numbers, but in this patch this function is not used any more. > > 4. width could be just: this._svg.parent().width() The width is now solved by using this.content.width() in topology graph facet. I think that the calculating of width and height should be at the same place. That is why I didn't put calculating of width into the TopoGraph. > > 5. Your approach for bottom padding works well but I don't like that > the component assumes that there is some col-sm-12 element on a page > whose right padding is actually equal to space on the left of the svg. I agree, fixed. > > #1 and #5 makes me think that the resize logic should be moved > topology facet. Something like: > > * register resize handler on facet's 'show' event > * unregister resize handler on facet's 'hide' event (will solve #1) > * on window resize, compute the size in topology facet, call new > .resize(width, height) method of TopoGraph > > Then, we wouldn't have to search whole DOM for 'svg' elements to check > if page is visible. The bottom padding can be obtained by: > parseInt(this.content.css('paddingLeft')) where 'this' is facet. > I followed these tips and here is a new patch. -- Pavel^3 Vomacka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvomacka-0005-4-Resize-topology-graph-canvas-according-to-window-siz.patch Type: text/x-patch Size: 4776 bytes Desc: not available URL: From pspacek at redhat.com Thu Feb 25 14:54:52 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 15:54:52 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1456410481.6599.279.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> Message-ID: <56CF15BC.4030003@redhat.com> On 25.2.2016 15:28, Simo Sorce wrote: > On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >> Variant C >> --------- >> An alternative is to be lazy and dumb. Maybe it would be enough for >> the first >> round ... >> >> We would retain >> [first step - no change from variant A] >> * create locations >> * assign 'main' (aka 'primary' aka 'home') servers to locations >> ++ specify weights for the 'main' servers in given location, i.e. >> manually >> input (server, weight) tuples >> >> Then, backups would be auto-generated set of all remaining servers >> from all >> other locations. >> >> Additional storage complexity: 0 >> >> This covers the scenario "always prefer local servers and use remote >> only as >> fallback" easily. It does not cover any other scenario. >> >> This might be sufficient for the first run and would allow us to >> gather some >> feedback from the field. >> >> Now I'm inclined to this variant :-) > > To be honest, this is all I always had in mind, for the first step. > > To recap: > - define a location with the list of servers (perhaps location is a > property of server objects so you can have only one location per server, > and if you remove the server it is automatically removed from the > location w/o additional work or referential integrity necessary), if > weight is not defined (default) then they all have the same weight. Agreed. > - Allow to specify backup locations in the location object, priorities > are calculated automatically and all backup locations have same weight. Hmm, weights have to be inherited form the original location in all cases. Did you mean that all backup locations have the same *priority*? Anyway, explicit configuration of backup locations is introducing API and schema for variant A and that is what I'm questioning above. It is hard to make it extensible so we do not have headache in future when somebody decides that more flexibility is needed OR that link-based approach is better. In other words, for doing what you propose above we would have to design complete schema and API for variant A anyway to make sure we do not lock ourselves, so we are not getting any saving by doing so. > - Define a *default* location, which is the backup for any other > location but always with lower priority to any other explicitly defined > backup locations. I would rather *always* use the default location as backup for all other locations. It does not require any API or schema (as it equals to "all servers" except "servers in this location" which can be easily calculated on fly). This can be later on extended in whatever direction we want without any upgrade/migration problem. More importantly, all the schema and API will be common for all other variants anyway so we can start doing so and see how much time is left when it is done. > - Weights for backup location servers are the same as the weight defined > within the backup location itself, so no additional weights are defined > for backups. Yes, that was somehow implied in the variant A. Sorry for not mentioning it. Weight is always relative number for servers inside one location. -- Petr^2 Spacek From pspacek at redhat.com Thu Feb 25 14:57:51 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 15:57:51 +0100 Subject: [Freeipa-devel] [PATCH 0390] Fix build with GCC 4.9+ In-Reply-To: <56C710B0.3020005@redhat.com> References: <56C710B0.3020005@redhat.com> Message-ID: <56CF166F.1010003@redhat.com> On 19.2.2016 13:55, Petr Spacek wrote: > Hello, > > Fix build with GCC 4.9+. > > GCC 4.9+ is too aggressive when optimizing functions with nonnull > attributes. This removes most of asserts() in the plugin. > GCC 6 adds warnings for these cases. > > We are disabling the unwanted condition pruning by adding > -fno-delete-null-pointer-checks argument. > BIND 9 did the same in its commit 603a78708343f063b44affb882ef93bb19a5142a. > > Additionally we silence warnings to prevent build failures when -Werror > is used. > > https://bugzilla.redhat.com/show_bug.cgi?id=1307346 Updated version is attached. It contains less autotools magic because it enables attribute nonnull only under Clang static analyzer and Coverity - as a result we do not have to silence GCC warnings from -Wnonnull. Please review so I can fix build in Fedora 24. Thank you. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0390-2-Fix-build-with-GCC-4.9.patch Type: text/x-patch Size: 2490 bytes Desc: not available URL: From pspacek at redhat.com Thu Feb 25 14:59:07 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Feb 2016 15:59:07 +0100 Subject: [Freeipa-devel] [PATCH 0001] Add new parameter --ssh-update to ipa-client-install In-Reply-To: <56CF0353.5060705@redhat.com> References: <1456175624.5411.4.camel@stefany.eu> <56CF0060.3090202@redhat.com> <56CF0353.5060705@redhat.com> Message-ID: <56CF16BB.7000505@redhat.com> On 25.2.2016 14:36, Jan Cholasta wrote: > Hi, > > On 25.2.2016 14:23, Martin Basti wrote: >> >> >> On 22.02.2016 22:13, Martin ?tefany wrote: >>> Hi, >>> >>> please, review the attached patch which adds --ssh-update to ipa-client- >>> install. >>> >>> Ticket:https://fedorahosted.org/freeipa/ticket/2655 >> Hello, >> thank you for your patch. >> Please attach a patch as a file next time. >> >> I have doubts that this should be part of ipa-client-install, this needs >> a broader discussion. > > +1, I think it should be a separate command (ignore my earlier suggestion from > Trac to incorporate this into ipa-client-install, I was young and stupid). > > See client/ipa-certupdate and ipaclient/ipa_certupdate.py for an example of > how such a command should be implemented. Or we can have idempotent client installer as we have ipa-dns-install ... Petr^2 Spacek >> Code comments inline: >>> >>> --- >>> Martin >>> >>> >From 4974a57f48a0cd48b83724297ae2af572bc530eb Mon Sep 17 00:00:00 2001 >>> From: Martin Stefany >>> Date: Mon, 22 Feb 2016 20:58:13 +0000 >>> Subject: [PATCH] Add new parameter --ssh-update to ipa-client-install >>> >>> Add a new parameter '--ssh-update' which can be used later after freeipa >>> client is installed to update SSH hostkeys and SSHFP DNS records for >>> host. >>> >>> https://fedorahosted.org/freeipa/ticket/2655 >>> --- >>> ipa-client/ipa-install/ipa-client-install | 102 >>> +++++++++++++++++++++++++++++- >>> 1 file changed, 99 insertions(+), 3 deletions(-) >>> >>> diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa- >>> install/ipa-client-install >>> index >>> 789ff591591673744ee3b922e5c0181233ad553c..97adfb6b449fb441bddada89a3b151 >>> 33e398ca50 100755 >>> --- a/ipa-client/ipa-install/ipa-client-install >>> +++ b/ipa-client/ipa-install/ipa-client-install >>> @@ -71,6 +71,7 @@ CLIENT_INSTALL_ERROR = 1 >>> CLIENT_NOT_CONFIGURED = 2 >>> CLIENT_ALREADY_CONFIGURED = 3 >>> CLIENT_UNINSTALL_ERROR = 4 # error after restoring files/state >>> +CLIENT_SSHUPDATE_ERROR = 5 # error during update of SSH public keys >>> >>> def parse_options(): >>> def validate_ca_cert_file_option(option, opt, value, parser): >>> @@ -215,6 +216,12 @@ def parse_options(): >>> "be run with --unattended >>> option") >>> parser.add_option_group(uninstall_group) >>> >>> + sshupdate_group = OptionGroup(parser, "SSH key update options") >>> + sshupdate_group.add_option("--ssh-update", dest="ssh_update", >>> + action="store_true", default=False, >>> + help="update local host's SSH public keys in host >>> entry and DNS.") >>> + parser.add_option_group(sshupdate_group) >>> + >>> options, args = parser.parse_args() >>> safe_opts = parser.get_safe_opts(options) >>> >>> @@ -840,6 +847,92 @@ def uninstall(options, env): >>> >>> return rv >>> >>> +def sshupdate(options, env): >>> + if not is_ipa_client_installed(): >>> + root_logger.error("IPA client is not configured on this >>> system.") >>> + return CLIENT_NOT_CONFIGURED >>> + >>> + api.bootstrap(context='cli_installer', debug=options.debug) >>> + api.finalize() >>> + if 'config_loaded' not in api.env: >>> + root_logger.error("Failed to initialize IPA API.") >>> + return CLIENT_SSHUPDATE_ERROR >>> + >>> + # Now, let's try to connect to the server's RPC interface >>> + connected = False >>> + try: >>> + api.Backend.rpcclient.connect() >>> + connected = True >>> + root_logger.debug("Try RPC connection") >>> + api.Backend.rpcclient.forward('ping') >>> + except errors.KerberosError as e: >>> + if connected: >>> + api.Backend.rpcclient.disconnect() >>> + root_logger.info( >>> + "Cannot connect to the server due to Kerberos error: %s. " >>> + "Trying with delegate=True", e) >>> + try: >>> + api.Backend.rpcclient.connect(delegate=True) >>> + root_logger.debug("Try RPC connection") >>> + api.Backend.rpcclient.forward('ping') >>> + >>> + root_logger.info("Connection with delegate=True >>> successful") >>> + >>> + # The remote server is not capable of Kerberos S4U2Proxy >>> + # delegation. This features is implemented in IPA server >>> + # version 2.2 and higher >>> + root_logger.warning( >>> + "Target IPA server has a lower version than the >>> enrolled " >>> + "client") >>> + root_logger.warning( >>> + "Some capabilities including the ipa command capability >>> " >>> + "may not be available") >>> + except errors.PublicError as e2: >>> + root_logger.warning( >>> + "Second connect with delegate=True also failed: %s", >>> e2) >>> + root_logger.error( >>> + "Cannot connect to the IPA server RPC interface: %s", >>> e2) >>> + return CLIENT_SSHUPDATE_ERROR >>> + except errors.PublicError as e: >>> + root_logger.error( >>> + "Cannot connect to the server due to generic error: %s", e) >>> + return CLIENT_SSHUPDATE_ERROR >> I think you should be kinited with client keytab, client is allowed to >> modify its SSHpublic keys in ldap. I'd only require to be root to >> execute it. >> >> kinit -kt /etc/krb5.keytab host/`hostname` >> ipa host-mod `hostname` --sshpubkey="something" >> >> Also this rpcconnection looks to me too much complicated, I think it >> should be just simple rpcconnect >> >>> + >>> + # We need to pull IPA server address from default.conf >>> + try: >>> + parser = RawConfigParser() >>> + parser.read(paths.IPA_DEFAULT_CONF) >>> + cli_realm = parser.get('global', 'realm') >>> + hostname = parser.get('global', 'host') >>> + # TODO: consult with review team >>> + # except ConfigParser.NoSectionError as e: >>> + # pass >>> + # except ConfigParser.ParsingError as e: >>> + # pass >>> + finally: >>> + pass >> You can raise error there. >> >>> + >>> + host_principal = 'host/%s@%s' % (hostname, cli_realm) >>> + # Obtain the TGT. We do it with the temporary krb5.conf, so that >>> + # only the KDC we're installing under is contacted. >>> + # Other KDCs might not have replicated the principal yet. >>> + # Once we have the TGT, it's usable on any server. >> I don't think that temporary krb5.conf should be used here >>> + try: >>> + ipautil.kinit_keytab(host_principal, paths.KRB5_KEYTAB, >>> + CCACHE_FILE, >>> + # config=krb_name, >>> + attempts=options.kinit_attempts) >>> + env['KRB5CCNAME'] = os.environ['KRB5CCNAME'] = CCACHE_FILE >>> + except Krb5Error as e: >>> + print_port_conf_info() >>> + root_logger.error("Failed to obtain host TGT: %s" % e) >>> + # failure to get ticket makes it impossible to login and bind >>> + # from sssd to LDAP, abort installation and rollback changes >>> + return CLIENT_INSTALL_ERROR >> This is not install error. >> >>> + >>> + # passing server parameter seems unneccessary, thus passing only "" >>> + update_ssh_keys("", hostname, >>> services.knownservices.sshd.get_config_dir(), options.create_sshfp) >>> + >>> def configure_ipa_conf(fstore, cli_basedn, cli_realm, cli_domain, >>> cli_server, hostname): >>> ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") >>> ipaconf.setOptionAssignment(" =") @@ -2797,7 +2890,7 @@ def >>> install(options, env, fstore, >>> statestore): connected = True >>> root_logger.debug("Try RPC connection") >>> api.Backend.rpcclient.forward('ping') >>> - except errors.KerberosError, e: >>> + except errors.KerberosError as e: >> Please don't modify code that already exists and it is not related to >> this change >>> if connected: >>> api.Backend.rpcclient.disconnect() >>> root_logger.info( >>> @@ -2820,13 +2913,13 @@ def install(options, env, fstore, statestore): >>> root_logger.warning( >>> "Some capabilities including the ipa command >>> capability " >>> "may not be available") >>> - except errors.PublicError, e2: >>> + except errors.PublicError as e2: >> Remove this from patch too >>> root_logger.warning( >>> "Second connect with delegate=True also failed: >>> %s", e2) >>> root_logger.error( >>> "Cannot connect to the IPA server RPC interface: >>> %s", e2) >>> return CLIENT_INSTALL_ERROR >>> - except errors.PublicError, e: >>> + except errors.PublicError as e: >> and this too >>> root_logger.error( >>> "Cannot connect to the server due to generic error: >>> %s", e) >>> return CLIENT_INSTALL_ERROR >>> @@ -3088,6 +3181,9 @@ def main(): >>> if options.uninstall: >>> return uninstall(options, env) >>> >>> + if options.ssh_update: >>> + return sshupdate(options, env) >>> + >>> if is_ipa_client_installed(on_master=options.on_master): >>> root_logger.error("IPA client is already configured on this >>> system.") >>> root_logger.info( >>> -- >>> 1.8.3.1 >>> >>> >> >> Martin^2 >> >> > > Honza From jcholast at redhat.com Thu Feb 25 15:11:57 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Feb 2016 16:11:57 +0100 Subject: [Freeipa-devel] [PATCH 0001] Add new parameter --ssh-update to ipa-client-install In-Reply-To: <56CF16BB.7000505@redhat.com> References: <1456175624.5411.4.camel@stefany.eu> <56CF0060.3090202@redhat.com> <56CF0353.5060705@redhat.com> <56CF16BB.7000505@redhat.com> Message-ID: <56CF19BD.9080507@redhat.com> On 25.2.2016 15:59, Petr Spacek wrote: > On 25.2.2016 14:36, Jan Cholasta wrote: >> Hi, >> >> On 25.2.2016 14:23, Martin Basti wrote: >>> >>> >>> On 22.02.2016 22:13, Martin ?tefany wrote: >>>> Hi, >>>> >>>> please, review the attached patch which adds --ssh-update to ipa-client- >>>> install. >>>> >>>> Ticket:https://fedorahosted.org/freeipa/ticket/2655 >>> Hello, >>> thank you for your patch. >>> Please attach a patch as a file next time. >>> >>> I have doubts that this should be part of ipa-client-install, this needs >>> a broader discussion. >> >> +1, I think it should be a separate command (ignore my earlier suggestion from >> Trac to incorporate this into ipa-client-install, I was young and stupid). >> >> See client/ipa-certupdate and ipaclient/ipa_certupdate.py for an example of >> how such a command should be implemented. > > Or we can have idempotent client installer as we have ipa-dns-install ... We can, but don't. Patches are welcome of course. Nonetheless, you should be able to reinstall just the SSH keys, as opposed to the full client, which is exactly what the separate command should accomplish. > > Petr^2 Spacek > >>> Code comments inline: >>>> >>>> --- >>>> Martin >>>> >>>> >From 4974a57f48a0cd48b83724297ae2af572bc530eb Mon Sep 17 00:00:00 2001 >>>> From: Martin Stefany >>>> Date: Mon, 22 Feb 2016 20:58:13 +0000 >>>> Subject: [PATCH] Add new parameter --ssh-update to ipa-client-install >>>> >>>> Add a new parameter '--ssh-update' which can be used later after freeipa >>>> client is installed to update SSH hostkeys and SSHFP DNS records for >>>> host. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2655 >>>> --- >>>> ipa-client/ipa-install/ipa-client-install | 102 >>>> +++++++++++++++++++++++++++++- >>>> 1 file changed, 99 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa- >>>> install/ipa-client-install >>>> index >>>> 789ff591591673744ee3b922e5c0181233ad553c..97adfb6b449fb441bddada89a3b151 >>>> 33e398ca50 100755 >>>> --- a/ipa-client/ipa-install/ipa-client-install >>>> +++ b/ipa-client/ipa-install/ipa-client-install >>>> @@ -71,6 +71,7 @@ CLIENT_INSTALL_ERROR = 1 >>>> CLIENT_NOT_CONFIGURED = 2 >>>> CLIENT_ALREADY_CONFIGURED = 3 >>>> CLIENT_UNINSTALL_ERROR = 4 # error after restoring files/state >>>> +CLIENT_SSHUPDATE_ERROR = 5 # error during update of SSH public keys >>>> >>>> def parse_options(): >>>> def validate_ca_cert_file_option(option, opt, value, parser): >>>> @@ -215,6 +216,12 @@ def parse_options(): >>>> "be run with --unattended >>>> option") >>>> parser.add_option_group(uninstall_group) >>>> >>>> + sshupdate_group = OptionGroup(parser, "SSH key update options") >>>> + sshupdate_group.add_option("--ssh-update", dest="ssh_update", >>>> + action="store_true", default=False, >>>> + help="update local host's SSH public keys in host >>>> entry and DNS.") >>>> + parser.add_option_group(sshupdate_group) >>>> + >>>> options, args = parser.parse_args() >>>> safe_opts = parser.get_safe_opts(options) >>>> >>>> @@ -840,6 +847,92 @@ def uninstall(options, env): >>>> >>>> return rv >>>> >>>> +def sshupdate(options, env): >>>> + if not is_ipa_client_installed(): >>>> + root_logger.error("IPA client is not configured on this >>>> system.") >>>> + return CLIENT_NOT_CONFIGURED >>>> + >>>> + api.bootstrap(context='cli_installer', debug=options.debug) >>>> + api.finalize() >>>> + if 'config_loaded' not in api.env: >>>> + root_logger.error("Failed to initialize IPA API.") >>>> + return CLIENT_SSHUPDATE_ERROR >>>> + >>>> + # Now, let's try to connect to the server's RPC interface >>>> + connected = False >>>> + try: >>>> + api.Backend.rpcclient.connect() >>>> + connected = True >>>> + root_logger.debug("Try RPC connection") >>>> + api.Backend.rpcclient.forward('ping') >>>> + except errors.KerberosError as e: >>>> + if connected: >>>> + api.Backend.rpcclient.disconnect() >>>> + root_logger.info( >>>> + "Cannot connect to the server due to Kerberos error: %s. " >>>> + "Trying with delegate=True", e) >>>> + try: >>>> + api.Backend.rpcclient.connect(delegate=True) >>>> + root_logger.debug("Try RPC connection") >>>> + api.Backend.rpcclient.forward('ping') >>>> + >>>> + root_logger.info("Connection with delegate=True >>>> successful") >>>> + >>>> + # The remote server is not capable of Kerberos S4U2Proxy >>>> + # delegation. This features is implemented in IPA server >>>> + # version 2.2 and higher >>>> + root_logger.warning( >>>> + "Target IPA server has a lower version than the >>>> enrolled " >>>> + "client") >>>> + root_logger.warning( >>>> + "Some capabilities including the ipa command capability >>>> " >>>> + "may not be available") >>>> + except errors.PublicError as e2: >>>> + root_logger.warning( >>>> + "Second connect with delegate=True also failed: %s", >>>> e2) >>>> + root_logger.error( >>>> + "Cannot connect to the IPA server RPC interface: %s", >>>> e2) >>>> + return CLIENT_SSHUPDATE_ERROR >>>> + except errors.PublicError as e: >>>> + root_logger.error( >>>> + "Cannot connect to the server due to generic error: %s", e) >>>> + return CLIENT_SSHUPDATE_ERROR >>> I think you should be kinited with client keytab, client is allowed to >>> modify its SSHpublic keys in ldap. I'd only require to be root to >>> execute it. >>> >>> kinit -kt /etc/krb5.keytab host/`hostname` >>> ipa host-mod `hostname` --sshpubkey="something" >>> >>> Also this rpcconnection looks to me too much complicated, I think it >>> should be just simple rpcconnect >>> >>>> + >>>> + # We need to pull IPA server address from default.conf >>>> + try: >>>> + parser = RawConfigParser() >>>> + parser.read(paths.IPA_DEFAULT_CONF) >>>> + cli_realm = parser.get('global', 'realm') >>>> + hostname = parser.get('global', 'host') >>>> + # TODO: consult with review team >>>> + # except ConfigParser.NoSectionError as e: >>>> + # pass >>>> + # except ConfigParser.ParsingError as e: >>>> + # pass >>>> + finally: >>>> + pass >>> You can raise error there. >>> >>>> + >>>> + host_principal = 'host/%s@%s' % (hostname, cli_realm) >>>> + # Obtain the TGT. We do it with the temporary krb5.conf, so that >>>> + # only the KDC we're installing under is contacted. >>>> + # Other KDCs might not have replicated the principal yet. >>>> + # Once we have the TGT, it's usable on any server. >>> I don't think that temporary krb5.conf should be used here >>>> + try: >>>> + ipautil.kinit_keytab(host_principal, paths.KRB5_KEYTAB, >>>> + CCACHE_FILE, >>>> + # config=krb_name, >>>> + attempts=options.kinit_attempts) >>>> + env['KRB5CCNAME'] = os.environ['KRB5CCNAME'] = CCACHE_FILE >>>> + except Krb5Error as e: >>>> + print_port_conf_info() >>>> + root_logger.error("Failed to obtain host TGT: %s" % e) >>>> + # failure to get ticket makes it impossible to login and bind >>>> + # from sssd to LDAP, abort installation and rollback changes >>>> + return CLIENT_INSTALL_ERROR >>> This is not install error. >>> >>>> + >>>> + # passing server parameter seems unneccessary, thus passing only "" >>>> + update_ssh_keys("", hostname, >>>> services.knownservices.sshd.get_config_dir(), options.create_sshfp) >>>> + >>>> def configure_ipa_conf(fstore, cli_basedn, cli_realm, cli_domain, >>>> cli_server, hostname): >>>> ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") >>>> ipaconf.setOptionAssignment(" =") @@ -2797,7 +2890,7 @@ def >>>> install(options, env, fstore, >>>> statestore): connected = True >>>> root_logger.debug("Try RPC connection") >>>> api.Backend.rpcclient.forward('ping') >>>> - except errors.KerberosError, e: >>>> + except errors.KerberosError as e: >>> Please don't modify code that already exists and it is not related to >>> this change >>>> if connected: >>>> api.Backend.rpcclient.disconnect() >>>> root_logger.info( >>>> @@ -2820,13 +2913,13 @@ def install(options, env, fstore, statestore): >>>> root_logger.warning( >>>> "Some capabilities including the ipa command >>>> capability " >>>> "may not be available") >>>> - except errors.PublicError, e2: >>>> + except errors.PublicError as e2: >>> Remove this from patch too >>>> root_logger.warning( >>>> "Second connect with delegate=True also failed: >>>> %s", e2) >>>> root_logger.error( >>>> "Cannot connect to the IPA server RPC interface: >>>> %s", e2) >>>> return CLIENT_INSTALL_ERROR >>>> - except errors.PublicError, e: >>>> + except errors.PublicError as e: >>> and this too >>>> root_logger.error( >>>> "Cannot connect to the server due to generic error: >>>> %s", e) >>>> return CLIENT_INSTALL_ERROR >>>> @@ -3088,6 +3181,9 @@ def main(): >>>> if options.uninstall: >>>> return uninstall(options, env) >>>> >>>> + if options.ssh_update: >>>> + return sshupdate(options, env) >>>> + >>>> if is_ipa_client_installed(on_master=options.on_master): >>>> root_logger.error("IPA client is already configured on this >>>> system.") >>>> root_logger.info( >>>> -- >>>> 1.8.3.1 >>>> >>>> >>> >>> Martin^2 >>> >>> >> >> Honza > -- Jan Cholasta From mbasti at redhat.com Thu Feb 25 15:31:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Feb 2016 16:31:53 +0100 Subject: [Freeipa-devel] [patch 0034] ipatests: extend permission plugin test with new expected output In-Reply-To: <56CEC0C3.8040703@redhat.com> References: <56C1F5C6.2090708@redhat.com> <56C5DA92.4090805@redhat.com> <56CD5D22.9000404@redhat.com> <56CDF0F5.2010506@redhat.com> <56CEC0C3.8040703@redhat.com> Message-ID: <56CF1E69.9040205@redhat.com> On 25.02.2016 09:52, Milan Kub?k wrote: > On 02/24/2016 07:05 PM, Martin Basti wrote: >> >> >> On 24.02.2016 08:34, Milan Kub?k wrote: >>> On 02/18/2016 03:52 PM, Milan Kub?k wrote: >>>> On 02/15/2016 04:59 PM, Milan Kub?k wrote: >>>>> Patch attached. Applies on ipa-4-3 as well. >>>>> >>>>> >>>>> >>>> Updated version of patch fixes test_old_permission_plugin as well. >>>> >>>> -- >>>> Milan Kubik >>>> >>>> >>> Review bump. >>> >>> -- >>> Milan Kubik >>> >>> >> NACK >> >> [mbasti at dhcp129-96 freeipa-devel]$ git show -U0 | pep8 --diff >> ./ipatests/test_xmlrpc/test_old_permission_plugin.py:528:80: E501 >> line too long (95 > 79 characters) >> ./ipatests/test_xmlrpc/test_old_permission_plugin.py:586:1: E101 >> indentation contains mixed spaces and tabs >> ./ipatests/test_xmlrpc/test_old_permission_plugin.py:586:1: W191 >> indentation contains tabs >> ./ipatests/test_xmlrpc/test_old_permission_plugin.py:587:1: E101 >> indentation contains mixed spaces and tabs >> ./ipatests/test_xmlrpc/test_old_permission_plugin.py:587:80: E501 >> line too long (95 > 79 characters) >> ./ipatests/test_xmlrpc/test_old_permission_plugin.py:591:1: E101 >> indentation contains mixed spaces and tabs >> ./ipatests/test_xmlrpc/test_old_permission_plugin.py:591:1: W191 >> indentation contains tabs >> ./ipatests/test_xmlrpc/test_permission_plugin.py:821:80: E501 line >> too long (99 > 79 characters) >> ./ipatests/test_xmlrpc/test_permission_plugin.py:884:80: E501 line >> too long (99 > 79 characters) >> > Sorry for that. Updated patch attached. > > -- > Milan Kubik ACK Pushed to: master: b32c9d639ef8e3fa852fb07f9385ae7e7b48e00e ipa-4-3: 5ae12641426427552406af89feb15e9bcbad8db3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Thu Feb 25 15:32:55 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 25 Feb 2016 10:32:55 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456325710.3148.10.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> Message-ID: <1456414375.3074.10.camel@redhat.com> On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > The above (pseudo) pull request contains four patches against > > > FreeIPA > > > to enable the insertion of Authentication Indicators into > > > Kerberos > > > tickets. The basic flow looks like this. > > > > > > First, we patch ipa-pwd-extop to return a control indicating what > > > authentication method succeeded resulting in a successful bind. > > > > > > Second, we patch ipa-otpd to check the returned control to ensure > > > that > > > the bind resulted from an otp validation. > > > > > > Third, we patch ipa-kdb to enable the KDC to return either the > > > encrypted timestamp or encrypted challenge preauth mechanism when > > > the > > > user is configured for optional 2FA logins. Clients can then > > > decide > > > whether to do 1FA or 2FA login (for kinit, sane behavior already > > > exists). > > > > > > Forth, we patch ipa-kdb again to insert hard-coded authentication > > > indicators for either OTP or RADIUS. > > > > > > Some explanation is required for the first two patches. > > > Currently, > > > it > > > is possible to do a 1FA through the otp preauthentication > > > mechanism > > > if > > > the user is configured for doing optional 2FA. However, because > > > we > > > want > > > to insert an authentication indicator in this code path, we need > > > to > > > guarantee that a request going through the otp preauth mechanism > > > actually validates an OTP. This is the purpose of the control. > > > > > > Items still on the TODO list: > > > > > > ? * Authentication Indicator enforcement > > > ????- Upstream libkrb5 needs to grow funcs for reading indicators > > > ????- Schema change to add indicators multi-value attr to > > > services > > > ????- ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > ? * SSSD needs to learn to handle optional 2FA > > > > > > I will write up a project page for all of this tomorrow. But this > > > small > > > code basically amounts to my brainstorming. It is not ready for > > > merge, > > > just basic review. > > > > > It looks mostly ok, however the LDAP control part needs to be done > > as > > a > > request/response pair. > > A client that wishes to know what kind of authentication happened > > should > > send a request control, and only in that case , the server will > > send > > the > > associated reply control with the requested information. > I just pushed a new version of the control (now merged into a single > patch):?https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de > 39 > f28eb637f66199da7e9225 > > In this version the client sends a critical control with no content > indicating that the server must validate an OTP. If the LDAP server > doesn't support the control (for whatever reason), bind will fail. If > the LDAP server doesn't validate an OTP (for whatever reason), bind > will fail. > > This approach is simpler and doesn't require a request/response > control > pair. I need some design advice. My goal here is that we need a way to expose the authentication indicators to services in the FreeIPA UI/CLI. Here is the good news: users can already set these values in FreeIPA using kadmin. They do this by simply setting the?require_auth string on the target service principal. Our kdb plugin then encodes these with the rest of the tl_data into the krbExtraData attribute. I see two approaches here. First, we can try to manipulate the krbExtraData attribute directly. Second, we can create a separate attribute for the authentication indicator strings and then synthesize the tl_data internally in kdb. We would have to do this for both reads and writes so as not to break existing kdb functionality. The trade-off that I see is that the first method complicates the python framework side where the second method complicates the kdb plugin. A third option, which I doubt is even possible, is to use kadmin to manipulate this option rather than modifying LDAP directly. Thoughts? From simo at redhat.com Thu Feb 25 15:46:30 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 25 Feb 2016 10:46:30 -0500 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <56CF15BC.4030003@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> Message-ID: <1456415190.6599.302.camel@redhat.com> On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: > On 25.2.2016 15:28, Simo Sorce wrote: > > On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: > >> Variant C > >> --------- > >> An alternative is to be lazy and dumb. Maybe it would be enough for > >> the first > >> round ... > >> > >> We would retain > >> [first step - no change from variant A] > >> * create locations > >> * assign 'main' (aka 'primary' aka 'home') servers to locations > >> ++ specify weights for the 'main' servers in given location, i.e. > >> manually > >> input (server, weight) tuples > >> > >> Then, backups would be auto-generated set of all remaining servers > >> from all > >> other locations. > >> > >> Additional storage complexity: 0 > >> > >> This covers the scenario "always prefer local servers and use remote > >> only as > >> fallback" easily. It does not cover any other scenario. > >> > >> This might be sufficient for the first run and would allow us to > >> gather some > >> feedback from the field. > >> > >> Now I'm inclined to this variant :-) > > > > To be honest, this is all I always had in mind, for the first step. > > > > To recap: > > - define a location with the list of servers (perhaps location is a > > property of server objects so you can have only one location per server, > > and if you remove the server it is automatically removed from the > > location w/o additional work or referential integrity necessary), if > > weight is not defined (default) then they all have the same weight. > > Agreed. > > > > - Allow to specify backup locations in the location object, priorities > > are calculated automatically and all backup locations have same weight. > > Hmm, weights have to be inherited form the original location in all cases. Did > you mean that all backup locations have the same *priority*? Yes, sorry. > Anyway, explicit configuration of backup locations is introducing API and > schema for variant A and that is what I'm questioning above. It is hard to > make it extensible so we do not have headache in future when somebody decides > that more flexibility is needed OR that link-based approach is better. I think no matter we do we'll need to allow admins to override backup locations, in future if we can calculate them automatically admins will simply not set any backup location explicitly (or set some special value like "autogenerate" and the system will do it for them. Forcing admins to mentally calculate weights to force the system to autogenerate the configuration they want would be a bad experience, I personally would find it very annoying. > In other words, for doing what you propose above we would have to design > complete schema and API for variant A anyway to make sure we do not lock > ourselves, so we are not getting any saving by doing so. A seemed much more complicated to me, as you wanted to define a ful matrix for weights of servers when they are served as backups and all that. > > - Define a *default* location, which is the backup for any other > > location but always with lower priority to any other explicitly defined > > backup locations. > > I would rather *always* use the default location as backup for all other > locations. It does not require any API or schema (as it equals to "all > servers" except "servers in this location" which can be easily calculated on fly). We can start with this, but it works well only in a stellar topology where you have a central location all other location connect to. As soon as you have a super-stellar topology where you have hub location to which regional locations connect to, then this is wasteful. > This can be later on extended in whatever direction we want without any > upgrade/migration problem. > > More importantly, all the schema and API will be common for all other variants > anyway so we can start doing so and see how much time is left when it is done. I am ok with this for the first step. After all location is mostly about the "normal" case where clients want to reach the local servers, the backup part is only an additional feature we can keep simple for now. It's a degraded mode of operation anyway so it is probably ok to have just one default backup location as a starting point. > > - Weights for backup location servers are the same as the weight defined > > within the backup location itself, so no additional weights are defined > > for backups. > > Yes, that was somehow implied in the variant A. Sorry for not mentioning it. > Weight is always relative number for servers inside one location. Ok it looked a lot more complex from your description. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Feb 25 15:49:48 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 25 Feb 2016 10:49:48 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456414375.3074.10.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> Message-ID: <1456415388.6599.305.camel@redhat.com> On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > The above (pseudo) pull request contains four patches against > > > > FreeIPA > > > > to enable the insertion of Authentication Indicators into > > > > Kerberos > > > > tickets. The basic flow looks like this. > > > > > > > > First, we patch ipa-pwd-extop to return a control indicating what > > > > authentication method succeeded resulting in a successful bind. > > > > > > > > Second, we patch ipa-otpd to check the returned control to ensure > > > > that > > > > the bind resulted from an otp validation. > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return either the > > > > encrypted timestamp or encrypted challenge preauth mechanism when > > > > the > > > > user is configured for optional 2FA logins. Clients can then > > > > decide > > > > whether to do 1FA or 2FA login (for kinit, sane behavior already > > > > exists). > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded authentication > > > > indicators for either OTP or RADIUS. > > > > > > > > Some explanation is required for the first two patches. > > > > Currently, > > > > it > > > > is possible to do a 1FA through the otp preauthentication > > > > mechanism > > > > if > > > > the user is configured for doing optional 2FA. However, because > > > > we > > > > want > > > > to insert an authentication indicator in this code path, we need > > > > to > > > > guarantee that a request going through the otp preauth mechanism > > > > actually validates an OTP. This is the purpose of the control. > > > > > > > > Items still on the TODO list: > > > > > > > > * Authentication Indicator enforcement > > > > - Upstream libkrb5 needs to grow funcs for reading indicators > > > > - Schema change to add indicators multi-value attr to > > > > services > > > > - ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > * SSSD needs to learn to handle optional 2FA > > > > > > > > I will write up a project page for all of this tomorrow. But this > > > > small > > > > code basically amounts to my brainstorming. It is not ready for > > > > merge, > > > > just basic review. > > > > > > > It looks mostly ok, however the LDAP control part needs to be done > > > as > > > a > > > request/response pair. > > > A client that wishes to know what kind of authentication happened > > > should > > > send a request control, and only in that case , the server will > > > send > > > the > > > associated reply control with the requested information. > > I just pushed a new version of the control (now merged into a single > > patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d31e1de > > 39 > > f28eb637f66199da7e9225 > > > > In this version the client sends a critical control with no content > > indicating that the server must validate an OTP. If the LDAP server > > doesn't support the control (for whatever reason), bind will fail. If > > the LDAP server doesn't validate an OTP (for whatever reason), bind > > will fail. > > > > This approach is simpler and doesn't require a request/response > > control > > pair. > > I need some design advice. My goal here is that we need a way to expose > the authentication indicators to services in the FreeIPA UI/CLI. > > Here is the good news: users can already set these values in FreeIPA > using kadmin. They do this by simply setting the require_auth string on > the target service principal. Our kdb plugin then encodes these with > the rest of the tl_data into the krbExtraData attribute. > > I see two approaches here. First, we can try to manipulate the > krbExtraData attribute directly. Second, we can create a separate > attribute for the authentication indicator strings and then synthesize > the tl_data internally in kdb. We would have to do this for both reads > and writes so as not to break existing kdb functionality. > > The trade-off that I see is that the first method complicates the > python framework side where the second method complicates the kdb > plugin. > > A third option, which I doubt is even possible, is to use kadmin to > manipulate this option rather than modifying LDAP directly. > > Thoughts? We should translate it, we need that to allow to delegate access only to the specific attribute via our standard means. We already do this for other tl_data entries. The krbExtraData access cannot always be delegated because it would be open ended. also it is really obnoxious to have to manipulate ASN.1 stuff in the framework. kadmin could be used at some point, but we'd still want to have this attribute extracted in order to be able to grant access control individually, as our ACL system and delegation system is more fine grained than what kadmin can offer. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Feb 25 16:50:46 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Feb 2016 17:50:46 +0100 Subject: [Freeipa-devel] [PATCH 0425] pylint: suppress false positive no-member errors In-Reply-To: <56CF1455.3020904@redhat.com> References: <56CF1455.3020904@redhat.com> Message-ID: <56CF30E6.5080902@redhat.com> On 25.02.2016 15:48, Martin Basti wrote: > The last pylint 1.5 patch, \o/ > > https://fedorahosted.org/freeipa/ticket/5615 > > self-NACK too broad disables -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu Feb 25 17:01:06 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Feb 2016 18:01:06 +0100 Subject: [Freeipa-devel] [PATCH] 953 advise: configure TLS in redhat_nss_pam_ldapd and redhat_nss_ldap plugins Message-ID: <56CF3352.3060400@redhat.com> I did not add --enableldapstarttls to config_redhat_nss_ldap because I'm not sure if it is present on el5 (IMO it is not). authconfig in: * config_redhat_nss_ldap got * --enableldaptls * config_redhat_nss_pam_ldapd got * --enableldaptls * --enableldapstarttls options https://fedorahosted.org/freeipa/ticket/5654 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0953-advise-configure-TLS-in-redhat_nss_pam_ldapd-and-red.patch Type: text/x-patch Size: 3549 bytes Desc: not available URL: From mbasti at redhat.com Thu Feb 25 17:05:28 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 25 Feb 2016 18:05:28 +0100 Subject: [Freeipa-devel] [PATCH 0426] spec: add missing requires to python*-ipalib package Message-ID: <56CF3458.6030304@redhat.com> https://fedorahosted.org/freeipa/ticket/5680 Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0426-spec-Add-missing-dependencies-to-python-ipalib-packa.patch Type: text/x-patch Size: 2124 bytes Desc: not available URL: From npmccallum at redhat.com Thu Feb 25 17:19:07 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 25 Feb 2016 12:19:07 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456415388.6599.305.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> Message-ID: <1456420747.3074.24.camel@redhat.com> On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > > > The above (pseudo) pull request contains four patches against > > > > > FreeIPA > > > > > to enable the insertion of Authentication Indicators into > > > > > Kerberos > > > > > tickets. The basic flow looks like this. > > > > > > > > > > First, we patch ipa-pwd-extop to return a control indicating > > > > > what > > > > > authentication method succeeded resulting in a successful > > > > > bind. > > > > > > > > > > Second, we patch ipa-otpd to check the returned control to > > > > > ensure > > > > > that > > > > > the bind resulted from an otp validation. > > > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return either > > > > > the > > > > > encrypted timestamp or encrypted challenge preauth mechanism > > > > > when > > > > > the > > > > > user is configured for optional 2FA logins. Clients can then > > > > > decide > > > > > whether to do 1FA or 2FA login (for kinit, sane behavior > > > > > already > > > > > exists). > > > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded > > > > > authentication > > > > > indicators for either OTP or RADIUS. > > > > > > > > > > Some explanation is required for the first two patches. > > > > > Currently, > > > > > it > > > > > is possible to do a 1FA through the otp preauthentication > > > > > mechanism > > > > > if > > > > > the user is configured for doing optional 2FA. However, > > > > > because > > > > > we > > > > > want > > > > > to insert an authentication indicator in this code path, we > > > > > need > > > > > to > > > > > guarantee that a request going through the otp preauth > > > > > mechanism > > > > > actually validates an OTP. This is the purpose of the > > > > > control. > > > > > > > > > > Items still on the TODO list: > > > > > > > > > > ? * Authentication Indicator enforcement > > > > > ????- Upstream libkrb5 needs to grow funcs for reading > > > > > indicators > > > > > ????- Schema change to add indicators multi-value attr to > > > > > services > > > > > ????- ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > > > > ? * SSSD needs to learn to handle optional 2FA > > > > > > > > > > I will write up a project page for all of this tomorrow. But > > > > > this > > > > > small > > > > > code basically amounts to my brainstorming. It is not ready > > > > > for > > > > > merge, > > > > > just basic review. > > > > > > > > > It looks mostly ok, however the LDAP control part needs to be > > > > done > > > > as > > > > a > > > > request/response pair. > > > > A client that wishes to know what kind of authentication > > > > happened > > > > should > > > > send a request control, and only in that case , the server will > > > > send > > > > the > > > > associated reply control with the requested information. > > > I just pushed a new version of the control (now merged into a > > > single > > > patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d31 > > > e1de > > > 39 > > > f28eb637f66199da7e9225 > > > > > > In this version the client sends a critical control with no > > > content > > > indicating that the server must validate an OTP. If the LDAP > > > server > > > doesn't support the control (for whatever reason), bind will > > > fail. If > > > the LDAP server doesn't validate an OTP (for whatever reason), > > > bind > > > will fail. > > > > > > This approach is simpler and doesn't require a request/response > > > control > > > pair. > > I need some design advice. My goal here is that we need a way to > > expose > > the authentication indicators to services in the FreeIPA UI/CLI. > > > > Here is the good news: users can already set these values in > > FreeIPA > > using kadmin. They do this by simply setting the require_auth > > string on > > the target service principal. Our kdb plugin then encodes these > > with > > the rest of the tl_data into the krbExtraData attribute. > > > > I see two approaches here. First, we can try to manipulate the > > krbExtraData attribute directly. Second, we can create a separate > > attribute for the authentication indicator strings and then > > synthesize > > the tl_data internally in kdb. We would have to do this for both > > reads > > and writes so as not to break existing kdb functionality. > > > > The trade-off that I see is that the first method complicates the > > python framework side where the second method complicates the kdb > > plugin. > > > > A third option, which I doubt is even possible, is to use kadmin to > > manipulate this option rather than modifying LDAP directly. > > > > Thoughts? > We should translate it, we need that to allow to delegate access only > to > the specific attribute via our standard means. > > We already do this for other tl_data entries. > > The krbExtraData access cannot always be delegated because it would > be > open ended. also it is really obnoxious to have to manipulate ASN.1 > stuff in the framework. > > kadmin could be used at some point, but we'd still want to have this > attribute extracted in order to be able to grant access control > individually, as our ACL system and delegation system is more fine > grained than what kadmin can offer. After discussing this with MIT, Simo and Matt, it seems that the best option is to update the (MIT) upstream krbPrincipal objectClass to have a new attribute. The reason for this is twofold. First, it has upstream value. Second, we don't have good objectClass to attach the new attribute to inside FreeIPA. So the current plan is that Matt will create a patch for storing auth indicators (specifically, the "required_auth" strings) in a new multi- value string attribute on krbPrincipal objects. The get_principal() KDB hook will read "required_auth" from krbExtraData or (if present, preferred) the new attribute. In turn, the put_principal() KDB hook will store "required_auth" in the new attribute. This will allow the transparent migration of any data currently stored in krbExtraData. As part of this process, Matt will also refactor put_principal() into smaller functions (it is currently 800+ LOC). Once we have an attribute in upstream krbPrincipal, we will use this attribute exclusively in our KDB plugin. Nathaniel From tbordaz at redhat.com Thu Feb 25 18:17:18 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 25 Feb 2016 19:17:18 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56CEDF98.7060809@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> <56CEDF98.7060809@redhat.com> Message-ID: <56CF452E.30503@redhat.com> On 02/25/2016 12:03 PM, Martin Babinsky wrote: > On 02/24/2016 04:30 PM, thierry bordaz wrote: >> On 01/21/2016 05:04 PM, Martin Babinsky wrote: >>> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>>> >>>> >>>> >>> Hi Thierry, >>> >>> I have couple of comments to your patch: >>> >>> 1.) >>> there is a number of PEP8 errors in the patch >>> (http://paste.fedoraproject.org/313246/33893701), please fix them. >>> >>> See http://www.freeipa.org/page/Python_Coding_Style for our >>> conventions used in Python code. >>> >>> 2.) >>> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >>> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >>> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >>> Plugin,cn=plugins,cn=config' >>> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >>> >>> Uppercase names are usually reserved for module-level constants. OTOH, >>> local variables should be lowercase. Also you can instantiate >>> dna_config_base directly as DN, using 2-member tuples, i. e: >>> >>> """ >>> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric >>> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >>> """ >>> >>> When passing DN object to the formatting functions/operators, it is >>> automatically converted to string so no need to hold string and DN >>> object separately. This is done in other places (see function/methods >>> in replication.py). >>> >>> 3.) >>> >>> + for i in range(len(entries)) : >>> + >>> + mod = [] >>> + if entries[i].single_value.get(DNA_BIND_METHOD) != method: >>> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, >>> method)) >>> + >>> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >>> protocol: >>> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >>> protocol)) >>> >>> >>> please use idiomatic Python when handling list of entries, e.g.: >>> >>> """ >>> for entry in entries: >>> mod = [] >>> if entry.single_value.get(DNA_BIND_METHOD) != method: >>> ... >>> """ >>> >>> 4.) I think that this method should in DSInstance class since it deals >>> with directory server configuration. Service is a parent object of all >>> other service installers/configurators and should contain only methods >>> common to more children. >>> >>> 5.) Since the method is called from every installer, it could be >>> beneficial to call it in DSInstance.__common_post_setup() as a part of >>> Directory server installation. Is there any reason why this is not the >>> case? >>> >>> 6.) >>> >>> + while attempt != MAX_WAIT: >>> + try: >>> + entries = conn.get_entries(sharedcfgdn, >>> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >>> + break >>> + except errors.NotFound: >>> + root_logger.debug("So far enable not find DNA shared >>> config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn, >>> sharedcfgdn)) >>> + attempt = attempt + 1 >>> + time.sleep(2) >>> + continue >>> + >>> + # safety checking >>> + # there is no return, if there are several entries, as a >>> workaround of #5510 >>> + if len(entries) != 1: >>> >>> I am quite afraid what would happen if the server does not return any >>> entries until 30 s timeout. The code will then continue to the >>> condition which can potentially test an uninitialized variable and >>> blow up with 'NameError'. This should be handled more robustly, e. g. >>> raise an exception when a timeout is reached and no entries were >>> returned. >>> >>> 7.) >>> >>> + if len(mod) > 0: >>> >>> A Pythonic way to test for non-empty container is >>> >>> """ >>> if mods: >>> # do stuff >>> """ >>> >>> since an empty list/dict/set evaluates to False and non-empty >>> containers are True. >>> >>> >>> 8.) >>> >>> + entry = conn.get_entry(entries[i].dn) >>> + if entry.single_value.get(DNA_BIND_METHOD) != method: >>> + root_logger.error("Fail to set SASL/GSSAPI bind >>> method to %s" % (entries[i].dn)) >>> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >>> protocol: >>> + root_logger.error("Fail to set LDAP protocol to >>> %s" % (entries[i].dn)) >>> >>> rather than re-fetching the modified entry and testing what happened, >>> you can just catch an exception raised by unsuccessfull mod and log an >>> error like this: >>> >>> """ >>> try: >>> conn.modify_s(entry.dn, mod) >>> except Exception as e: >>> root_logger.error("Failed to modify entry {}: {}".format(entry, e)) >>> """ >>> >>> as a matter of fact, if the modify_s operation would fail for some >>> reason, an ldap exception would be raised and you checks would not >>> even be executed. >>> >>> 9.) >>> The debug message on line 219 should read "Unable to find DNA shared >>> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >>> at the end of the method should have "Failed" instead of "Fail". >>> >> Hi Martin, >> >> Finally tested... here is the updated patch. Thanks for you patience >> >> >> thanks >> thierry > > Hi Thierry, > > the patch works as expected. I have some more nitpicks though: > > 1.) Please fix the following pep8 errors: > > http://paste.fedoraproject.org/329086/56397841/ > > you can check whether you recent commit conforms to PEP8 by running > > "git show -U0 | pep8 --diff" > > 2.) > + self.step("update DNA shared config entry", > self.update_dna_shared_config) > > I would rather change the message to "Updating DNA shared config > entry" since all other messages use continuous tense. > > 3.) > + else: > + raise RuntimeError("Could not get dnaHostname entries > in {} seconds".format(max_wait * 2)) > > Please use root_logger.error() and then return as is used elsewhere in > the method. We do not want a runaway exception crashing upgrade. > Hi Martin, Updated/tested the patch with your help/recommendations. pep8 is clear now :-) thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0017-3-configure-DNA-plugin-shared-config-entries-to-allow-.patch Type: text/x-patch Size: 8986 bytes Desc: not available URL: From npmccallum at redhat.com Thu Feb 25 21:13:32 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 25 Feb 2016 16:13:32 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456420747.3074.24.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> Message-ID: <1456434812.3074.31.camel@redhat.com> On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote: > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > > > > > > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > > > > > The above (pseudo) pull request contains four patches > > > > > > against > > > > > > FreeIPA > > > > > > to enable the insertion of Authentication Indicators into > > > > > > Kerberos > > > > > > tickets. The basic flow looks like this. > > > > > > > > > > > > First, we patch ipa-pwd-extop to return a control > > > > > > indicating > > > > > > what > > > > > > authentication method succeeded resulting in a successful > > > > > > bind. > > > > > > > > > > > > Second, we patch ipa-otpd to check the returned control to > > > > > > ensure > > > > > > that > > > > > > the bind resulted from an otp validation. > > > > > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return either > > > > > > the > > > > > > encrypted timestamp or encrypted challenge preauth > > > > > > mechanism > > > > > > when > > > > > > the > > > > > > user is configured for optional 2FA logins. Clients can > > > > > > then > > > > > > decide > > > > > > whether to do 1FA or 2FA login (for kinit, sane behavior > > > > > > already > > > > > > exists). > > > > > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded > > > > > > authentication > > > > > > indicators for either OTP or RADIUS. > > > > > > > > > > > > Some explanation is required for the first two patches. > > > > > > Currently, > > > > > > it > > > > > > is possible to do a 1FA through the otp preauthentication > > > > > > mechanism > > > > > > if > > > > > > the user is configured for doing optional 2FA. However, > > > > > > because > > > > > > we > > > > > > want > > > > > > to insert an authentication indicator in this code path, we > > > > > > need > > > > > > to > > > > > > guarantee that a request going through the otp preauth > > > > > > mechanism > > > > > > actually validates an OTP. This is the purpose of the > > > > > > control. > > > > > > > > > > > > Items still on the TODO list: > > > > > > > > > > > > ? * Authentication Indicator enforcement > > > > > > ????- Upstream libkrb5 needs to grow funcs for reading > > > > > > indicators > > > > > > ????- Schema change to add indicators multi-value attr to > > > > > > services > > > > > > ????- ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > > > > > > > ? * SSSD needs to learn to handle optional 2FA > > > > > > > > > > > > I will write up a project page for all of this tomorrow. > > > > > > But > > > > > > this > > > > > > small > > > > > > code basically amounts to my brainstorming. It is not ready > > > > > > for > > > > > > merge, > > > > > > just basic review. > > > > > > > > > > > It looks mostly ok, however the LDAP control part needs to be > > > > > done > > > > > as > > > > > a > > > > > request/response pair. > > > > > A client that wishes to know what kind of authentication > > > > > happened > > > > > should > > > > > send a request control, and only in that case , the server > > > > > will > > > > > send > > > > > the > > > > > associated reply control with the requested information. > > > > I just pushed a new version of the control (now merged into a > > > > single > > > > patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d > > > > 31 > > > > e1de > > > > 39 > > > > f28eb637f66199da7e9225 > > > > > > > > In this version the client sends a critical control with no > > > > content > > > > indicating that the server must validate an OTP. If the LDAP > > > > server > > > > doesn't support the control (for whatever reason), bind will > > > > fail. If > > > > the LDAP server doesn't validate an OTP (for whatever reason), > > > > bind > > > > will fail. > > > > > > > > This approach is simpler and doesn't require a request/response > > > > control > > > > pair. > > > I need some design advice. My goal here is that we need a way to > > > expose > > > the authentication indicators to services in the FreeIPA UI/CLI. > > > > > > Here is the good news: users can already set these values in > > > FreeIPA > > > using kadmin. They do this by simply setting the require_auth > > > string on > > > the target service principal. Our kdb plugin then encodes these > > > with > > > the rest of the tl_data into the krbExtraData attribute. > > > > > > I see two approaches here. First, we can try to manipulate the > > > krbExtraData attribute directly. Second, we can create a separate > > > attribute for the authentication indicator strings and then > > > synthesize > > > the tl_data internally in kdb. We would have to do this for both > > > reads > > > and writes so as not to break existing kdb functionality. > > > > > > The trade-off that I see is that the first method complicates the > > > python framework side where the second method complicates the kdb > > > plugin. > > > > > > A third option, which I doubt is even possible, is to use kadmin > > > to > > > manipulate this option rather than modifying LDAP directly. > > > > > > Thoughts? > > We should translate it, we need that to allow to delegate access > > only > > to > > the specific attribute via our standard means. > > > > We already do this for other tl_data entries. > > > > The krbExtraData access cannot always be delegated because it would > > be > > open ended. also it is really obnoxious to have to manipulate ASN.1 > > stuff in the framework. > > > > kadmin could be used at some point, but we'd still want to have > > this > > attribute extracted in order to be able to grant access control > > individually, as our ACL system and delegation system is more fine > > grained than what kadmin can offer. > After discussing this with MIT, Simo and Matt, it seems that the best > option is to update the (MIT) upstream krbPrincipal objectClass to > have > a new attribute. The reason for this is twofold. First, it has > upstream > value. Second, we don't have good objectClass to attach the new > attribute to inside FreeIPA. > > So the current plan is that Matt will create a patch for storing auth > indicators (specifically, the "required_auth" strings) in a new > multi- > value string attribute on krbPrincipal objects. The get_principal() > KDB > hook will read "required_auth" from krbExtraData or (if present, > preferred) the new attribute. In turn, the put_principal() KDB hook > will store "required_auth" in the new attribute. This will allow the > transparent migration of any data currently stored in krbExtraData. > > As part of this process, Matt will also refactor put_principal() into > smaller functions (it is currently 800+ LOC). > > Once we have an attribute in upstream krbPrincipal, we will use this > attribute exclusively in our KDB plugin. I have started a project page: http://www.freeipa.org/page/V4/AuthenticationIndicators We are still waiting on some details. But the general shape of things is there. Please review. :) From simo at redhat.com Thu Feb 25 21:51:27 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 25 Feb 2016 16:51:27 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456434812.3074.31.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> Message-ID: <1456437087.6599.345.camel@redhat.com> On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote: > On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote: > > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: > > > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > > > > > > > The above (pseudo) pull request contains four patches > > > > > > > against > > > > > > > FreeIPA > > > > > > > to enable the insertion of Authentication Indicators into > > > > > > > Kerberos > > > > > > > tickets. The basic flow looks like this. > > > > > > > > > > > > > > First, we patch ipa-pwd-extop to return a control > > > > > > > indicating > > > > > > > what > > > > > > > authentication method succeeded resulting in a successful > > > > > > > bind. > > > > > > > > > > > > > > Second, we patch ipa-otpd to check the returned control to > > > > > > > ensure > > > > > > > that > > > > > > > the bind resulted from an otp validation. > > > > > > > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return either > > > > > > > the > > > > > > > encrypted timestamp or encrypted challenge preauth > > > > > > > mechanism > > > > > > > when > > > > > > > the > > > > > > > user is configured for optional 2FA logins. Clients can > > > > > > > then > > > > > > > decide > > > > > > > whether to do 1FA or 2FA login (for kinit, sane behavior > > > > > > > already > > > > > > > exists). > > > > > > > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded > > > > > > > authentication > > > > > > > indicators for either OTP or RADIUS. > > > > > > > > > > > > > > Some explanation is required for the first two patches. > > > > > > > Currently, > > > > > > > it > > > > > > > is possible to do a 1FA through the otp preauthentication > > > > > > > mechanism > > > > > > > if > > > > > > > the user is configured for doing optional 2FA. However, > > > > > > > because > > > > > > > we > > > > > > > want > > > > > > > to insert an authentication indicator in this code path, we > > > > > > > need > > > > > > > to > > > > > > > guarantee that a request going through the otp preauth > > > > > > > mechanism > > > > > > > actually validates an OTP. This is the purpose of the > > > > > > > control. > > > > > > > > > > > > > > Items still on the TODO list: > > > > > > > > > > > > > > * Authentication Indicator enforcement > > > > > > > - Upstream libkrb5 needs to grow funcs for reading > > > > > > > indicators > > > > > > > - Schema change to add indicators multi-value attr to > > > > > > > services > > > > > > > - ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > > > > > > > > > > * SSSD needs to learn to handle optional 2FA > > > > > > > > > > > > > > I will write up a project page for all of this tomorrow. > > > > > > > But > > > > > > > this > > > > > > > small > > > > > > > code basically amounts to my brainstorming. It is not ready > > > > > > > for > > > > > > > merge, > > > > > > > just basic review. > > > > > > > > > > > > > It looks mostly ok, however the LDAP control part needs to be > > > > > > done > > > > > > as > > > > > > a > > > > > > request/response pair. > > > > > > A client that wishes to know what kind of authentication > > > > > > happened > > > > > > should > > > > > > send a request control, and only in that case , the server > > > > > > will > > > > > > send > > > > > > the > > > > > > associated reply control with the requested information. > > > > > I just pushed a new version of the control (now merged into a > > > > > single > > > > > patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d > > > > > 31 > > > > > e1de > > > > > 39 > > > > > f28eb637f66199da7e9225 > > > > > > > > > > In this version the client sends a critical control with no > > > > > content > > > > > indicating that the server must validate an OTP. If the LDAP > > > > > server > > > > > doesn't support the control (for whatever reason), bind will > > > > > fail. If > > > > > the LDAP server doesn't validate an OTP (for whatever reason), > > > > > bind > > > > > will fail. > > > > > > > > > > This approach is simpler and doesn't require a request/response > > > > > control > > > > > pair. > > > > I need some design advice. My goal here is that we need a way to > > > > expose > > > > the authentication indicators to services in the FreeIPA UI/CLI. > > > > > > > > Here is the good news: users can already set these values in > > > > FreeIPA > > > > using kadmin. They do this by simply setting the require_auth > > > > string on > > > > the target service principal. Our kdb plugin then encodes these > > > > with > > > > the rest of the tl_data into the krbExtraData attribute. > > > > > > > > I see two approaches here. First, we can try to manipulate the > > > > krbExtraData attribute directly. Second, we can create a separate > > > > attribute for the authentication indicator strings and then > > > > synthesize > > > > the tl_data internally in kdb. We would have to do this for both > > > > reads > > > > and writes so as not to break existing kdb functionality. > > > > > > > > The trade-off that I see is that the first method complicates the > > > > python framework side where the second method complicates the kdb > > > > plugin. > > > > > > > > A third option, which I doubt is even possible, is to use kadmin > > > > to > > > > manipulate this option rather than modifying LDAP directly. > > > > > > > > Thoughts? > > > We should translate it, we need that to allow to delegate access > > > only > > > to > > > the specific attribute via our standard means. > > > > > > We already do this for other tl_data entries. > > > > > > The krbExtraData access cannot always be delegated because it would > > > be > > > open ended. also it is really obnoxious to have to manipulate ASN.1 > > > stuff in the framework. > > > > > > kadmin could be used at some point, but we'd still want to have > > > this > > > attribute extracted in order to be able to grant access control > > > individually, as our ACL system and delegation system is more fine > > > grained than what kadmin can offer. > > After discussing this with MIT, Simo and Matt, it seems that the best > > option is to update the (MIT) upstream krbPrincipal objectClass to > > have > > a new attribute. The reason for this is twofold. First, it has > > upstream > > value. Second, we don't have good objectClass to attach the new > > attribute to inside FreeIPA. > > > > So the current plan is that Matt will create a patch for storing auth > > indicators (specifically, the "required_auth" strings) in a new > > multi- > > value string attribute on krbPrincipal objects. The get_principal() > > KDB > > hook will read "required_auth" from krbExtraData or (if present, > > preferred) the new attribute. In turn, the put_principal() KDB hook > > will store "required_auth" in the new attribute. This will allow the > > transparent migration of any data currently stored in krbExtraData. > > > > As part of this process, Matt will also refactor put_principal() into > > smaller functions (it is currently 800+ LOC). > > > > Once we have an attribute in upstream krbPrincipal, we will use this > > attribute exclusively in our KDB plugin. > > I have started a project page: > http://www.freeipa.org/page/V4/AuthenticationIndicators > > We are still waiting on some details. But the general shape of things > is there. Please review. :) LGTM so far. Questions: - Should the control specify what kind of auth specifically should be required ? - Will it make sense in future to have different strength otp-like second factors and have ipa-otpd be able to specify which one it is expecting to be validated ? - Even if ipa-otpd will not grow such a feature, I see this control could be useful for pure LDAP auth clients, so perhaps a different kind of client may want to set this control ? Perhaps one day we can have a way to do GSSAPI auth and check that the AI on the ldap ticket was a 2FA and then DS will refuse login if the otp AI was missing on the ticket it received and the control requires it ? (could be used for the IPA UI connection to LDAP maybe ?) Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Fri Feb 26 06:25:05 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Feb 2016 07:25:05 +0100 Subject: [Freeipa-devel] [PATCH 0426] spec: add missing requires to python*-ipalib package In-Reply-To: <56CF3458.6030304@redhat.com> References: <56CF3458.6030304@redhat.com> Message-ID: <56CFEFC1.4060301@redhat.com> Hi, On 25.2.2016 18:05, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/5680 > > Patch attached. NACK. For python 3, the ldap module is provided by python3-pyldap. Any reason for the random ordering? The requires are not alphabetically ordered, so I would prefer if you just appended the new ones. There are missing as well as redundant requires in other packages, shouldn't we fix these too? Honza -- Jan Cholasta From jcholast at redhat.com Fri Feb 26 06:30:30 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Feb 2016 07:30:30 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <56CB59E3.3010709@redhat.com> References: <20160222104811.GN4492@redhat.com> <56CB3F82.1070408@redhat.com> <20160222171455.GT4492@redhat.com> <56CB59E3.3010709@redhat.com> Message-ID: <56CFF106.1080305@redhat.com> On 22.2.2016 19:56, Tomas Babej wrote: > > > On 02/22/2016 06:14 PM, Alexander Bokovoy wrote: >> On Mon, 22 Feb 2016, Tomas Babej wrote: >>> >>> >>> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> attached patch should update compat tree configuration if it exist to >>>> follow slapi-nis 0.55 which has support for external members of IPA >>>> groups. >>>> >>>> However, the real work is done in SSSD. These patches are not upstreamed >>>> yet. We'll need to bump SSSD dependency in future once they come to >>>> distros. >>>> >>>> >>>> >>> >>> This looks good. >>> >>> However, the new update file needs to be added to Makefile.am. >>> Additionally, patch adds a whitespace error. >> Updated patch is attached. >> > > ACK. > > This should not be pushed until the dependency for SSSD can be bumped. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d872920f74 -- Jan Cholasta From jcholast at redhat.com Fri Feb 26 07:30:06 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 26 Feb 2016 08:30:06 +0100 Subject: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir. In-Reply-To: <56CEFDE5.4090109@redhat.com> References: <569E307C.20602@redhat.com> <569E396F.4000104@redhat.com> <569E3C53.9030100@redhat.com> <569E51E6.6060005@redhat.com> <56C58A8C.3050200@redhat.com> <56CAAAA6.5010302@redhat.com> <56CB21BB.8000201@redhat.com> <56CB2388.2040207@redhat.com> <56CB2629.3010102@redhat.com> <56CC1C8B.7050600@redhat.com> <56CC22E4.8040104@redhat.com> <56CC5FA2.8030004@redhat.com> <56CC7DAC.9070904@redhat.com> <56CD4472.3000307@redhat.com> <56CDB939.8000505@redhat.com> <56CEFDE5.4090109@redhat.com> Message-ID: <56CFFEFE.2050907@redhat.com> On 25.2.2016 14:13, David Kupka wrote: > On 24/02/16 15:07, Rob Crittenden wrote: >> David Kupka wrote: >>> On 23/02/16 16:41, Rob Crittenden wrote: >>>> David Kupka wrote: >>>>> On 23/02/16 10:14, Martin Kosek wrote: >>>>>> On 02/23/2016 09:47 AM, David Kupka wrote: >>>>>>> On 22/02/16 16:15, Martin Kosek wrote: >>>>>>>> On 02/22/2016 04:04 PM, Jan Cholasta wrote: >>>>>>>>> On 22.2.2016 15:56, David Kupka wrote: >>>>>>>>>> On 22/02/16 07:28, Jan Cholasta wrote: >>>>>>>>>>> On 18.2.2016 10:10, David Kupka wrote: >>>>>>>>>>>> On 19/01/16 16:10, David Kupka wrote: >>>>>>>>>>>>> On 19/01/16 14:38, Jan Cholasta wrote: >>>>>>>>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote: >>>>>>>>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote: >>>>>>>>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and >>>>>>>>>>>>>>>> removed >>>>>>>>>>>>>>>> unused import >>>>>>>>>>>>>>>> but otherwise it works, ACK. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Won't this break existing certmonger requests depending on >>>>>>>>>>>>>>> the old >>>>>>>>>>>>>>> path? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It will, I don't see any upgrade code. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger' >>>>>>>>>>>>>>> pre-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>>> "auditSigningCert >>>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>>> pre-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>>> pre-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>>> "subsystemCert >>>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>>> pre-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>>> "caSigningCert >>>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ra_cert >>>>>>>>>>>>>>> pre-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/stop_pkicad >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/renew_ca_cert >>>>>>>>>>>>>>> "Server-Cert >>>>>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_dirsrv >>>>>>>>>>>>>>> RHEL72 >>>>>>>>>>>>>>> post-save command: >>>>>>>>>>>>>>> /usr/lib64/ipa/certmonger/restart_httpd >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> You're right it will break the upgrade. I haven't noticed that >>>>>>>>>>>>> Server-Cert for DS and HTTPD are not handled by >>>>>>>>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) >>>>>>>>>>>>> where all >>>>>>>>>>>>> the other trackings are stopped and then configured again >>>>>>>>>>>>> with the >>>>>>>>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the catch. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I've updated Timo's patch little more and added >>>>>>>>>>>> start_tracking_certificates() for dsinstance and httpinstance. >>>>>>>>>>>> Now the >>>>>>>>>>>> upgrade works as expected. >>>>>>>>>>> >>>>>>>>>>> The way the patches are split is kind of weird and apparently >>>>>>>>>>> confusing >>>>>>>>>>> (see the other thread). IMO there should be 2 patches: the first >>>>>>>>>>> should >>>>>>>>>>> add the ability to change DS and HTTP certmonger config during >>>>>>>>>>> upgrade >>>>>>>>>>> (i.e. the start_tracking_certificates() methods and >>>>>>>>>>> certificate_renewal_update() changes), the second should move >>>>>>>>>>> the >>>>>>>>>>> helpers (i.e. the actual move and certificate_renewal_update() >>>>>>>>>>> version >>>>>>>>>>> bump). >>>>>>>>>>> >>>>>>>>>> Honza, do I understand it correctly that the code is OK but I >>>>>>>>>> did not >>>>>>>>>> split it to the patches correctly? >>>>>>>>> >>>>>>>>> Yes. >>>>>>>> >>>>>>>> Before acking or pushing, can you please explain for me how the >>>>>>>> upgrade of >>>>>>>> certmonger tracking requests work? I want to make sure this is >>>>>>>> right, so please >>>>>>>> bear with me: >>>>>>>> >>>>>>>> 1) How does it edit existing tracking requests with the new helper >>>>>>>> paths? >>>>>>>> >>>>>>>> 2) Does it go and try to edit the requests on every upgrade? Or is >>>>>>>> there some >>>>>>>> check that requests were updated? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> Whole upgrade of renewal requests is done in >>>>>>> ipaserver/install/server/upgrade.py in >>>>>>> certificate_renewal_upgrade(). >>>>>>> >>>>>>> First there is version of requests and if it's the same as in state >>>>>>> file >>>>>>> upgrade is skipped. >>>>>>> Then every request is searched over certmonger's DBus interface and >>>>>>> if at least >>>>>>> one is not found it means that there was change in request >>>>>>> configuration. All >>>>>>> tracking requests are then stopped and started again with new >>>>>>> configuration. >>>>>>> >>>>>>> So to answer you questions: >>>>>>> 1) By stopping the old request with the old parameters (including >>>>>>> path) and >>>>>>> starting new with new parameters. >>>>>>> >>>>>>> 2) Only if version was bumped which happens only if some of the >>>>>>> requests changes. >>>>>> >>>>>> Ah, so IIUC, if you bump the version, requests should be properly >>>>>> updated. The >>>>>> change looks fine then. >>>>>> >>>>> >>>>> After discussion with Honza, we decided to drop the part comparing >>>>> only >>>>> base names of pre- and post-save commands and use it as whole. I've >>>>> also >>>>> split the patches so it's obvious what is going on. >>>>> >>>>> Patches should be applied in this order: >>>>> >>>>> freeipa-dkupka-0091.0 >>>> >>>> A cert could silently fail to be tracked in >>>> start_tracking_certificates() if no serverid can be found. >>> >>> In that case it also wouldn't be stopped. The behavior is the same as in >>> existing stop_tracking_certificates(). Should we rather raise and stop >>> the upgrade? I guess not but warning would be probably useful. What >>> solution would you prefer, Rob? >> >> I don't know all the callers of this. It may be perfectly safe to assume >> that a serverid is always there, but the implication if it isn't is that >> some tracking cert won't be updated properly right? That potentially >> could mean no renewal. >> >> So the consequences could be severe, I just don't know the likelihood. >> >> In other words, a comment (# can never get here) might be perfectly >> adequate. >> >> rob >> >>> >>>> >>>>> freeipa-dkupka-0087.1 >>>>> freeipa-dkupka-0088.1 >>>>> freeipa-tjaalton-0011.2 >>>>> freeipa-dkupka-0092.0 >>>>> >>>>> >>>>> >>> >>> >> > > > Currently the function is called only from one place (also added in this > patch) but to avoid problems in the future I made the serverid parameter > mandatory. > Also I squashed the version bump into Timo's patch. > > Updated patches attached. Apply in this order: > > freeipa-dkupka-0091.1 > freeipa-dkupka-0087.2 > freeipa-dkupka-0088.2 > freeipa-tjaalton-0011.3 Works for me, ACK. Pushed to: master: 872d5903d0d278914d740575b4ef92fa75c44a45 ipa-4-3: 8231f870e6adff2463a6911acd0191f1efbc0335 -- Jan Cholasta From mkosek at redhat.com Fri Feb 26 08:00:42 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Feb 2016 09:00:42 +0100 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456437087.6599.345.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> Message-ID: <56D0062A.6060706@redhat.com> On 02/25/2016 10:51 PM, Simo Sorce wrote: > On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote: >> On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote: >>> On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: >>>> >>>> On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: >>>>> >>>>> >>>>> On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: >>>>>> >>>>>> >>>>>> On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/npmccallum/freeipa/pull/1 >>>>>>>> >>>>>>>> The above (pseudo) pull request contains four patches >>>>>>>> against >>>>>>>> FreeIPA >>>>>>>> to enable the insertion of Authentication Indicators into >>>>>>>> Kerberos >>>>>>>> tickets. The basic flow looks like this. >>>>>>>> >>>>>>>> First, we patch ipa-pwd-extop to return a control >>>>>>>> indicating >>>>>>>> what >>>>>>>> authentication method succeeded resulting in a successful >>>>>>>> bind. >>>>>>>> >>>>>>>> Second, we patch ipa-otpd to check the returned control to >>>>>>>> ensure >>>>>>>> that >>>>>>>> the bind resulted from an otp validation. >>>>>>>> >>>>>>>> Third, we patch ipa-kdb to enable the KDC to return either >>>>>>>> the >>>>>>>> encrypted timestamp or encrypted challenge preauth >>>>>>>> mechanism >>>>>>>> when >>>>>>>> the >>>>>>>> user is configured for optional 2FA logins. Clients can >>>>>>>> then >>>>>>>> decide >>>>>>>> whether to do 1FA or 2FA login (for kinit, sane behavior >>>>>>>> already >>>>>>>> exists). >>>>>>>> >>>>>>>> Forth, we patch ipa-kdb again to insert hard-coded >>>>>>>> authentication >>>>>>>> indicators for either OTP or RADIUS. >>>>>>>> >>>>>>>> Some explanation is required for the first two patches. >>>>>>>> Currently, >>>>>>>> it >>>>>>>> is possible to do a 1FA through the otp preauthentication >>>>>>>> mechanism >>>>>>>> if >>>>>>>> the user is configured for doing optional 2FA. However, >>>>>>>> because >>>>>>>> we >>>>>>>> want >>>>>>>> to insert an authentication indicator in this code path, we >>>>>>>> need >>>>>>>> to >>>>>>>> guarantee that a request going through the otp preauth >>>>>>>> mechanism >>>>>>>> actually validates an OTP. This is the purpose of the >>>>>>>> control. >>>>>>>> >>>>>>>> Items still on the TODO list: >>>>>>>> >>>>>>>> * Authentication Indicator enforcement >>>>>>>> - Upstream libkrb5 needs to grow funcs for reading >>>>>>>> indicators >>>>>>>> - Schema change to add indicators multi-value attr to >>>>>>>> services >>>>>>>> - ipa-kdb needs to implement check_policy_tgs() >>>>>>>> >>>>>>>> >>>>>>>> * SSSD needs to learn to handle optional 2FA >>>>>>>> >>>>>>>> I will write up a project page for all of this tomorrow. >>>>>>>> But >>>>>>>> this >>>>>>>> small >>>>>>>> code basically amounts to my brainstorming. It is not ready >>>>>>>> for >>>>>>>> merge, >>>>>>>> just basic review. >>>>>>>> >>>>>>> It looks mostly ok, however the LDAP control part needs to be >>>>>>> done >>>>>>> as >>>>>>> a >>>>>>> request/response pair. >>>>>>> A client that wishes to know what kind of authentication >>>>>>> happened >>>>>>> should >>>>>>> send a request control, and only in that case , the server >>>>>>> will >>>>>>> send >>>>>>> the >>>>>>> associated reply control with the requested information. >>>>>> I just pushed a new version of the control (now merged into a >>>>>> single >>>>>> patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d >>>>>> 31 >>>>>> e1de >>>>>> 39 >>>>>> f28eb637f66199da7e9225 >>>>>> >>>>>> In this version the client sends a critical control with no >>>>>> content >>>>>> indicating that the server must validate an OTP. If the LDAP >>>>>> server >>>>>> doesn't support the control (for whatever reason), bind will >>>>>> fail. If >>>>>> the LDAP server doesn't validate an OTP (for whatever reason), >>>>>> bind >>>>>> will fail. >>>>>> >>>>>> This approach is simpler and doesn't require a request/response >>>>>> control >>>>>> pair. >>>>> I need some design advice. My goal here is that we need a way to >>>>> expose >>>>> the authentication indicators to services in the FreeIPA UI/CLI. >>>>> >>>>> Here is the good news: users can already set these values in >>>>> FreeIPA >>>>> using kadmin. They do this by simply setting the require_auth >>>>> string on >>>>> the target service principal. Our kdb plugin then encodes these >>>>> with >>>>> the rest of the tl_data into the krbExtraData attribute. >>>>> >>>>> I see two approaches here. First, we can try to manipulate the >>>>> krbExtraData attribute directly. Second, we can create a separate >>>>> attribute for the authentication indicator strings and then >>>>> synthesize >>>>> the tl_data internally in kdb. We would have to do this for both >>>>> reads >>>>> and writes so as not to break existing kdb functionality. >>>>> >>>>> The trade-off that I see is that the first method complicates the >>>>> python framework side where the second method complicates the kdb >>>>> plugin. >>>>> >>>>> A third option, which I doubt is even possible, is to use kadmin >>>>> to >>>>> manipulate this option rather than modifying LDAP directly. >>>>> >>>>> Thoughts? >>>> We should translate it, we need that to allow to delegate access >>>> only >>>> to >>>> the specific attribute via our standard means. >>>> >>>> We already do this for other tl_data entries. >>>> >>>> The krbExtraData access cannot always be delegated because it would >>>> be >>>> open ended. also it is really obnoxious to have to manipulate ASN.1 >>>> stuff in the framework. >>>> >>>> kadmin could be used at some point, but we'd still want to have >>>> this >>>> attribute extracted in order to be able to grant access control >>>> individually, as our ACL system and delegation system is more fine >>>> grained than what kadmin can offer. >>> After discussing this with MIT, Simo and Matt, it seems that the best >>> option is to update the (MIT) upstream krbPrincipal objectClass to >>> have >>> a new attribute. The reason for this is twofold. First, it has >>> upstream >>> value. Second, we don't have good objectClass to attach the new >>> attribute to inside FreeIPA. >>> >>> So the current plan is that Matt will create a patch for storing auth >>> indicators (specifically, the "required_auth" strings) in a new >>> multi- >>> value string attribute on krbPrincipal objects. The get_principal() >>> KDB >>> hook will read "required_auth" from krbExtraData or (if present, >>> preferred) the new attribute. In turn, the put_principal() KDB hook >>> will store "required_auth" in the new attribute. This will allow the >>> transparent migration of any data currently stored in krbExtraData. >>> >>> As part of this process, Matt will also refactor put_principal() into >>> smaller functions (it is currently 800+ LOC). >>> >>> Once we have an attribute in upstream krbPrincipal, we will use this >>> attribute exclusively in our KDB plugin. >> >> I have started a project page: >> http://www.freeipa.org/page/V4/AuthenticationIndicators Thanks Nathaniel! For starters, I moved the page to http://www.freeipa.org/page/V4/Authentication_Indicators to make sure the URL is consistent with other pages ;-) I also updated the Use Cases and added the User Story I am tracking with this feature: http://www.freeipa.org/page/V4/Authentication_Indicators#Strong_Authentication_on_Selected_System >> We are still waiting on some details. But the general shape of things >> is there. Please review. :) > > LGTM so far. > > Questions: > - Should the control specify what kind of auth specifically should be > required ? > > - Will it make sense in future to have different strength otp-like > second factors and have ipa-otpd be able to specify which one it is > expecting to be validated ? > > - Even if ipa-otpd will not grow such a feature, I see this control > could be useful for pure LDAP auth clients, so perhaps a different kind > of client may want to set this control ? Perhaps one day we can have a > way to do GSSAPI auth and check that the AI on the ldap ticket was a 2FA > and then DS will refuse login if the otp AI was missing on the ticket it > received and the control requires it ? (could be used for the IPA UI > connection to LDAP maybe ?) It would be also nice to add some graph how the workflows look like. It may be something based on Simo's picture he created some time back (attached). -------------- next part -------------- A non-text attachment was scrubbed... Name: Auth_Indicators_Diagaram.odg Type: application/vnd.oasis.opendocument.graphics Size: 33027 bytes Desc: not available URL: From ofayans at redhat.com Fri Feb 26 09:01:27 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 26 Feb 2016 10:01:27 +0100 Subject: [Freeipa-devel] [PATCH 0421] Make PTR records check optional for IPA installation In-Reply-To: <56CEE03C.9030801@redhat.com> References: <56CDBA6D.5000803@redhat.com> <56CEE03C.9030801@redhat.com> Message-ID: <56D01467.8080104@redhat.com> On 02/25/2016 12:06 PM, Petr Spacek wrote: > On 24.2.2016 15:13, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/5686 >> >> Patch attached. > > LGTM, ACK if it passes QE testing. > That did it. Works with both replica-prepare under domain level 0 and with replica-install on domlevel1. ACK -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mrniranjan at fedoraproject.org Fri Feb 26 10:14:34 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Fri, 26 Feb 2016 15:44:34 +0530 Subject: [Freeipa-devel] Request to add support to specify username/password for each host Message-ID: <20160226101434.GA18928@mniranja.pnq.redhat.com> Greetings, Request to review the patch for https://fedorahosted.org/python-pytest-multihost/ticket/5 Regards Niranjan -------------- next part -------------- From 28cd560f58b96817306a6eae6976e26166a9351a Mon Sep 17 00:00:00 2001 From: Niranjan MR Date: Fri, 26 Feb 2016 15:30:25 +0530 Subject: [PATCH] Add support to specify usernames/password per host https://fedorahosted.org/python-pytest-multihost/ticket/5 Signed-off-by: Niranjan MR --- pytest_multihost/host.py | 12 +++++++++--- pytest_multihost/transport.py | 12 ++++++++++-- 2 files changed, 19 insertions(+), 5 deletions(-) diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py index f3346f6..7885722 100644 --- a/pytest_multihost/host.py +++ b/pytest_multihost/host.py @@ -26,10 +26,13 @@ class BaseHost(object): """ transport_class = None - def __init__(self, domain, hostname, role, ip=None, - external_hostname=None): + def __init__(self, domain, hostname, role, + username=None, password=None, + ip=None, external_hostname=None): self.domain = domain self.role = str(role) + self.username = username + self.password = password shortname, dot, ext_domain = hostname.partition('.') self.shortname = shortname @@ -109,9 +112,12 @@ class BaseHost(object): ip = dct.pop('ip', None) external_hostname = dct.pop('external_hostname', None) + username = dct.pop('username', None) + password = dct.pop('password', None) + check_config_dict_empty(dct, 'host %s' % hostname) - return cls(domain, hostname, role, ip, external_hostname) + return cls(domain, hostname, role, username, password, ip, external_hostname) def to_dict(self): """Export info about this Host to a dict""" diff --git a/pytest_multihost/transport.py b/pytest_multihost/transport.py index eda71cd..e893e48 100644 --- a/pytest_multihost/transport.py +++ b/pytest_multihost/transport.py @@ -177,11 +177,19 @@ class ParamikoTransport(Transport): host.ssh_port)) self._transport = transport = paramiko.Transport(sock) transport.connect(hostkey=host.host_key) + if host.password: + self.log.debug('Authenticating with password set in host section') + transport.auth_password(username=host.username, + password=host.password) if host.ssh_key_filename: - self.log.debug('Authenticating with private RSA key') filename = os.path.expanduser(host.ssh_key_filename) key = paramiko.RSAKey.from_private_key_file(filename) - transport.auth_publickey(username=host.ssh_username, key=key) + if host.username: + self.log.debug('Authenticating with private RSA key using user %s' % ( host.username)) + transport.auth_publickey(username=host.username, key=key) + else: + self.log.debug('Authenticating with private RSA key') + transport.auth_publickey(username=host.ssh_username, key=key) elif host.ssh_password: self.log.debug('Authenticating with password') transport.auth_password(username='root', -- 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 lslebodn at redhat.com Fri Feb 26 10:43:52 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 26 Feb 2016 11:43:52 +0100 Subject: [Freeipa-devel] [PATCH] 953 advise: configure TLS in redhat_nss_pam_ldapd and redhat_nss_ldap plugins In-Reply-To: <56CF3352.3060400@redhat.com> References: <56CF3352.3060400@redhat.com> Message-ID: <20160226104352.GA28234@mail.corp.redhat.com> On (25/02/16 18:01), Petr Vobornik wrote: >I did not add --enableldapstarttls to config_redhat_nss_ldap because I'm not >sure if it is present on el5 (IMO it is not). > I can confirm it doesn't have such option [root at host /]# authconfig --help | grep -A1 "tls\|ssl" --enableldaptls, --enableldapssl enable use of TLS with LDAP --disableldaptls, --disableldapssl disable use of TLS with LDAP [root at host /]# cat /etc/issue CentOS release 5.11 (Final) Kernel \r on an \m LS From tbabej at redhat.com Fri Feb 26 11:37:24 2016 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 26 Feb 2016 12:37:24 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <56CFF106.1080305@redhat.com> References: <20160222104811.GN4492@redhat.com> <56CB3F82.1070408@redhat.com> <20160222171455.GT4492@redhat.com> <56CB59E3.3010709@redhat.com> <56CFF106.1080305@redhat.com> Message-ID: <56D038F4.5040909@redhat.com> On 02/26/2016 07:30 AM, Jan Cholasta wrote: > On 22.2.2016 19:56, Tomas Babej wrote: >> >> >> On 02/22/2016 06:14 PM, Alexander Bokovoy wrote: >>> On Mon, 22 Feb 2016, Tomas Babej wrote: >>>> >>>> >>>> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> attached patch should update compat tree configuration if it exist to >>>>> follow slapi-nis 0.55 which has support for external members of IPA >>>>> groups. >>>>> >>>>> However, the real work is done in SSSD. These patches are not >>>>> upstreamed >>>>> yet. We'll need to bump SSSD dependency in future once they come to >>>>> distros. >>>>> >>>>> >>>>> >>>> >>>> This looks good. >>>> >>>> However, the new update file needs to be added to Makefile.am. >>>> Additionally, patch adds a whitespace error. >>> Updated patch is attached. >>> >> >> ACK. >> >> This should not be pushed until the dependency for SSSD can be bumped. > > https://bodhi.fedoraproject.org/updates/FEDORA-2016-d872920f74 > Attaching the required spec change. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0402-spec-Bump-required-sssd-version-to-1.13.3-5.patch Type: text/x-patch Size: 800 bytes Desc: not available URL: From lhellebr at redhat.com Fri Feb 26 12:17:31 2016 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Fri, 26 Feb 2016 13:17:31 +0100 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback Message-ID: <56D0425B.4040503@redhat.com> Hi, FreeIPA and SSSD communities! I am working on adding URI to HBAC as my thesis [1]. The goal is to control access not only based on (user, host, service), but on (user, host, service, resource's URI). I created a patch for FreeIPA [2] so it is capable of storing URI as part of HBAC rule. I created a patch for SSSD [3] so it is able to get this URI from FreeIPA and use it in HBAC evaluation. I still need to develop a part of SSSD receiving URI-aware requests. It will either be an enhancement of Infopipe or I will use PAM responder (any suggestions?). I wanted to kindly ask you for review and your opinions on the patches and generally on my approach. This would be my first contribution to FreeIPA and SSSD so there might be bugs. What do you think? Btw, is there some better place to share patches than a pasting tool? Maybe some form of pull request? Thanks for your opinions! [1] https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa [2] http://pastebin.com/rsHzXeAR [3] http://pastebin.com/atcZMuP1 -- Lukas Hellebrandt From mkosek at redhat.com Fri Feb 26 12:30:06 2016 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 26 Feb 2016 13:30:06 +0100 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback In-Reply-To: <56D0425B.4040503@redhat.com> References: <56D0425B.4040503@redhat.com> Message-ID: <56D0454E.1050207@redhat.com> Greetings, welcome! On 02/26/2016 01:17 PM, Luk?? Hellebrandt wrote: ... > Btw, is there some better place to share patches than a pasting tool? > Maybe some form of pull request? There is :-) Please see advise here: http://www.freeipa.org/page/Contribute/Code#Submit_a_patch It has more information on top of submitting patches. For example, I think it would actually make sense to start with a design page where you would describe the use cases, design, APIs, etc: http://www.freeipa.org/page/Contribute/Code#Prepare Martin From ofayans at redhat.com Fri Feb 26 12:51:07 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 26 Feb 2016 13:51:07 +0100 Subject: [Freeipa-devel] [TEST][Patch 0022] small refactoring in integration tests due to BZ 1303095 In-Reply-To: <56C7147A.1090407@redhat.com> References: <56AB80BE.4090604@redhat.com> <56B1C6E2.60106@redhat.com> <56B1FE4C.4080600@redhat.com> <56B3029F.70001@redhat.com> <56BDF43D.70503@redhat.com> <56C7147A.1090407@redhat.com> Message-ID: <56D04A3B.9010909@redhat.com> Hey guys, could anyone review this please? On 02/19/2016 02:11 PM, Oleg Fayans wrote: > Hi Milan, > > On 02/12/2016 04:03 PM, Milan Kub?k wrote: >> On 02/04/2016 08:49 AM, Oleg Fayans wrote: >>> Hi Petr, >>> >>> On 02/03/2016 02:19 PM, Petr Spacek wrote: >>>> On 3.2.2016 10:22, Oleg Fayans wrote: >>>>> Guys, can anyone take a look at this? >>>> The commit message does not explain why you are setting search path. >>> Fixed. >>> >>>> I have to say that I do not like touching resolv.conf, as stated many times >>>> earlier. Why the test has to reconfigure the host and cannot use values >>>> provided by the provisioning system? >>> This patch exactly removes this messing around with nameservers in >>> resolv.conf >>> It introduces the possibility to put ipa domain in the search directive >>> of resolv.conf so that we could test service autodiscovery during client >>> installation. >>> >>> >>> >> I just verified that the tampering with resolv.conf is not needed >> (libvirt and ovirt/rhev). I think this is an artifact from the whole >> issue of "let's use improvised domain names, what can go wrong" approach >> that was uncovered by the enforced DNS checks. I think we can defer the >> networking configuration to provisioning system. > > Agreed. The latest patch gets rid of all resolv.conf related > manipulations. The tests work (where not affected by > https://fedorahosted.org/bind-dyndb-ldap/ticket/160) > > >> >> -- >> Milan Kubik >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From tbabej at redhat.com Fri Feb 26 13:32:53 2016 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 26 Feb 2016 14:32:53 +0100 Subject: [Freeipa-devel] [PATCH 0403] adtrustinstance: Make sure smb.conf exists Message-ID: <56D05405.2020609@redhat.com> Hi, The 'net' command fails unless smb.conf exists. Touch the file prior to any 'net' call to make sure we do not crash for this very reason. I couldn't find the aforementioned Samba bug either in the RH/Samba bugzilla, despite spending non-trivial amount of time searching for it. Can somebody point me to it? I referenced the IPA ticket for now. https://fedorahosted.org/freeipa/ticket/5687 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0403-adtrustinstance-Make-sure-smb.conf-exists.patch Type: text/x-patch Size: 1184 bytes Desc: not available URL: From pspacek at redhat.com Fri Feb 26 14:29:37 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 26 Feb 2016 15:29:37 +0100 Subject: [Freeipa-devel] [PATCH] 953 advise: configure TLS in redhat_nss_pam_ldapd and redhat_nss_ldap plugins In-Reply-To: <56CF3352.3060400@redhat.com> References: <56CF3352.3060400@redhat.com> Message-ID: <56D06151.7040007@redhat.com> On 25.2.2016 18:01, Petr Vobornik wrote: > I did not add --enableldapstarttls to config_redhat_nss_ldap because I'm not > sure if it is present on el5 (IMO it is not). > > authconfig in: > * config_redhat_nss_ldap got > * --enableldaptls > > * config_redhat_nss_pam_ldapd got > * --enableldaptls > * --enableldapstarttls > options Shouldn't it get only one of them? It seems weird to enable both at the same time. Petr^2 Spacek > https://fedorahosted.org/freeipa/ticket/5654 From npmccallum at redhat.com Fri Feb 26 14:30:46 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 26 Feb 2016 09:30:46 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456437087.6599.345.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> Message-ID: <1456497046.3136.8.camel@redhat.com> On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote: > On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote: > > > > On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote: > > > > > > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: > > > > > > > > > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > > > > > > > > > The above (pseudo) pull request contains four patches > > > > > > > > against > > > > > > > > FreeIPA > > > > > > > > to enable the insertion of Authentication Indicators > > > > > > > > into > > > > > > > > Kerberos > > > > > > > > tickets. The basic flow looks like this. > > > > > > > > > > > > > > > > First, we patch ipa-pwd-extop to return a control > > > > > > > > indicating > > > > > > > > what > > > > > > > > authentication method succeeded resulting in a > > > > > > > > successful > > > > > > > > bind. > > > > > > > > > > > > > > > > Second, we patch ipa-otpd to check the returned control > > > > > > > > to > > > > > > > > ensure > > > > > > > > that > > > > > > > > the bind resulted from an otp validation. > > > > > > > > > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return > > > > > > > > either > > > > > > > > the > > > > > > > > encrypted timestamp or encrypted challenge preauth > > > > > > > > mechanism > > > > > > > > when > > > > > > > > the > > > > > > > > user is configured for optional 2FA logins. Clients can > > > > > > > > then > > > > > > > > decide > > > > > > > > whether to do 1FA or 2FA login (for kinit, sane > > > > > > > > behavior > > > > > > > > already > > > > > > > > exists). > > > > > > > > > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded > > > > > > > > authentication > > > > > > > > indicators for either OTP or RADIUS. > > > > > > > > > > > > > > > > Some explanation is required for the first two patches. > > > > > > > > Currently, > > > > > > > > it > > > > > > > > is possible to do a 1FA through the otp > > > > > > > > preauthentication > > > > > > > > mechanism > > > > > > > > if > > > > > > > > the user is configured for doing optional 2FA. However, > > > > > > > > because > > > > > > > > we > > > > > > > > want > > > > > > > > to insert an authentication indicator in this code > > > > > > > > path, we > > > > > > > > need > > > > > > > > to > > > > > > > > guarantee that a request going through the otp preauth > > > > > > > > mechanism > > > > > > > > actually validates an OTP. This is the purpose of the > > > > > > > > control. > > > > > > > > > > > > > > > > Items still on the TODO list: > > > > > > > > > > > > > > > > ? * Authentication Indicator enforcement > > > > > > > > ????- Upstream libkrb5 needs to grow funcs for reading > > > > > > > > indicators > > > > > > > > ????- Schema change to add indicators multi-value attr > > > > > > > > to > > > > > > > > services > > > > > > > > ????- ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > > > > > > > > > > > > > ? * SSSD needs to learn to handle optional 2FA > > > > > > > > > > > > > > > > I will write up a project page for all of this > > > > > > > > tomorrow. > > > > > > > > But > > > > > > > > this > > > > > > > > small > > > > > > > > code basically amounts to my brainstorming. It is not > > > > > > > > ready > > > > > > > > for > > > > > > > > merge, > > > > > > > > just basic review. > > > > > > > > > > > > > > > It looks mostly ok, however the LDAP control part needs > > > > > > > to be > > > > > > > done > > > > > > > as > > > > > > > a > > > > > > > request/response pair. > > > > > > > A client that wishes to know what kind of authentication > > > > > > > happened > > > > > > > should > > > > > > > send a request control, and only in that case , the > > > > > > > server > > > > > > > will > > > > > > > send > > > > > > > the > > > > > > > associated reply control with the requested information. > > > > > > I just pushed a new version of the control (now merged into > > > > > > a > > > > > > single > > > > > > patch): https://github.com/npmccallum/freeipa/commit/a78191 > > > > > > ee5d > > > > > > 31 > > > > > > e1de > > > > > > 39 > > > > > > f28eb637f66199da7e9225 > > > > > > > > > > > > In this version the client sends a critical control with no > > > > > > content > > > > > > indicating that the server must validate an OTP. If the > > > > > > LDAP > > > > > > server > > > > > > doesn't support the control (for whatever reason), bind > > > > > > will > > > > > > fail. If > > > > > > the LDAP server doesn't validate an OTP (for whatever > > > > > > reason), > > > > > > bind > > > > > > will fail. > > > > > > > > > > > > This approach is simpler and doesn't require a > > > > > > request/response > > > > > > control > > > > > > pair. > > > > > I need some design advice. My goal here is that we need a way > > > > > to > > > > > expose > > > > > the authentication indicators to services in the FreeIPA > > > > > UI/CLI. > > > > > > > > > > Here is the good news: users can already set these values in > > > > > FreeIPA > > > > > using kadmin. They do this by simply setting the require_auth > > > > > string on > > > > > the target service principal. Our kdb plugin then encodes > > > > > these > > > > > with > > > > > the rest of the tl_data into the krbExtraData attribute. > > > > > > > > > > I see two approaches here. First, we can try to manipulate > > > > > the > > > > > krbExtraData attribute directly. Second, we can create a > > > > > separate > > > > > attribute for the authentication indicator strings and then > > > > > synthesize > > > > > the tl_data internally in kdb. We would have to do this for > > > > > both > > > > > reads > > > > > and writes so as not to break existing kdb functionality. > > > > > > > > > > The trade-off that I see is that the first method complicates > > > > > the > > > > > python framework side where the second method complicates the > > > > > kdb > > > > > plugin. > > > > > > > > > > A third option, which I doubt is even possible, is to use > > > > > kadmin > > > > > to > > > > > manipulate this option rather than modifying LDAP directly. > > > > > > > > > > Thoughts? > > > > We should translate it, we need that to allow to delegate > > > > access > > > > only > > > > to > > > > the specific attribute via our standard means. > > > > > > > > We already do this for other tl_data entries. > > > > > > > > The krbExtraData access cannot always be delegated because it > > > > would > > > > be > > > > open ended. also it is really obnoxious to have to manipulate > > > > ASN.1 > > > > stuff in the framework. > > > > > > > > kadmin could be used at some point, but we'd still want to have > > > > this > > > > attribute extracted in order to be able to grant access control > > > > individually, as our ACL system and delegation system is more > > > > fine > > > > grained than what kadmin can offer. > > > After discussing this with MIT, Simo and Matt, it seems that the > > > best > > > option is to update the (MIT) upstream krbPrincipal objectClass > > > to > > > have > > > a new attribute. The reason for this is twofold. First, it has > > > upstream > > > value. Second, we don't have good objectClass to attach the new > > > attribute to inside FreeIPA. > > > > > > So the current plan is that Matt will create a patch for storing > > > auth > > > indicators (specifically, the "required_auth" strings) in a new > > > multi- > > > value string attribute on krbPrincipal objects. The > > > get_principal() > > > KDB > > > hook will read "required_auth" from krbExtraData or (if present, > > > preferred) the new attribute. In turn, the put_principal() KDB > > > hook > > > will store "required_auth" in the new attribute. This will allow > > > the > > > transparent migration of any data currently stored in > > > krbExtraData. > > > > > > As part of this process, Matt will also refactor put_principal() > > > into > > > smaller functions (it is currently 800+ LOC). > > > > > > Once we have an attribute in upstream krbPrincipal, we will use > > > this > > > attribute exclusively in our KDB plugin. > > I have started a project page: > > http://www.freeipa.org/page/V4/AuthenticationIndicators > > > > We are still waiting on some details. But the general shape of > > things > > is there. Please review. :) > LGTM so far. > > Questions: > - Should the control specify what kind of auth specifically should be > required ? I had also wondered that. I'm certainly not against it. But I'd probably prefer a simple utf8 string value to avoid parsing complexity. > - Will it make sense in future to have different strength otp-like > second factors and have ipa-otpd be able to specify which one it is > expecting to be validated ? I'm personally hoping that we can deprecate ipa-otpd after SPAKE lands. Post-SPAKE validations will require a method for validating OTP-only (excluding password). This will probably be an extop. The same will be true for all new second factors. I'm thus not sure if we'll ever add more second factors to the existing simple bind mechanism. > - Even if ipa-otpd will not grow such a feature, I see this control > could be useful for pure LDAP auth clients, so perhaps a different > kind > of client may want to set this control ? Perhaps one day we can have > a > way to do GSSAPI auth and check that the AI on the ldap ticket was a > 2FA > and then DS will refuse login if the otp AI was missing on the ticket > it > received and the control requires it ? (could be used for the IPA UI > connection to LDAP maybe ?) That seems to me like a decision LDAP can make internally. No? From pspacek at redhat.com Fri Feb 26 14:37:21 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 26 Feb 2016 15:37:21 +0100 Subject: [Freeipa-devel] Locations design v2: LDAP schema & user interface In-Reply-To: <1456415190.6599.302.camel@redhat.com> References: <56B23BE0.4000207@redhat.com> <56B388A9.5090206@redhat.com> <56C6CB31.7080005@redhat.com> <1455895907.6599.104.camel@redhat.com> <56CC2DC7.7050006@redhat.com> <56CC45D5.6010705@redhat.com> <1456237158.6599.193.camel@redhat.com> <56CC9138.8010409@redhat.com> <1456247697.6599.244.camel@redhat.com> <56CC9DFB.3050106@redhat.com> <56CD7117.8000202@redhat.com> <1456323946.6599.254.camel@redhat.com> <56CF058E.4020709@redhat.com> <1456410481.6599.279.camel@redhat.com> <56CF15BC.4030003@redhat.com> <1456415190.6599.302.camel@redhat.com> Message-ID: <56D06321.3080109@redhat.com> On 25.2.2016 16:46, Simo Sorce wrote: > On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote: >> On 25.2.2016 15:28, Simo Sorce wrote: >>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote: >>>> Variant C >>>> --------- >>>> An alternative is to be lazy and dumb. Maybe it would be enough for >>>> the first >>>> round ... >>>> >>>> We would retain >>>> [first step - no change from variant A] >>>> * create locations >>>> * assign 'main' (aka 'primary' aka 'home') servers to locations >>>> ++ specify weights for the 'main' servers in given location, i.e. >>>> manually >>>> input (server, weight) tuples >>>> >>>> Then, backups would be auto-generated set of all remaining servers >>>> from all >>>> other locations. >>>> >>>> Additional storage complexity: 0 >>>> >>>> This covers the scenario "always prefer local servers and use remote >>>> only as >>>> fallback" easily. It does not cover any other scenario. >>>> >>>> This might be sufficient for the first run and would allow us to >>>> gather some >>>> feedback from the field. >>>> >>>> Now I'm inclined to this variant :-) >>> >>> To be honest, this is all I always had in mind, for the first step. >>> >>> To recap: >>> - define a location with the list of servers (perhaps location is a >>> property of server objects so you can have only one location per server, >>> and if you remove the server it is automatically removed from the >>> location w/o additional work or referential integrity necessary), if >>> weight is not defined (default) then they all have the same weight. >> >> Agreed. >> >> >>> - Allow to specify backup locations in the location object, priorities >>> are calculated automatically and all backup locations have same weight. >> >> Hmm, weights have to be inherited form the original location in all cases. Did >> you mean that all backup locations have the same *priority*? > > Yes, sorry. > >> Anyway, explicit configuration of backup locations is introducing API and >> schema for variant A and that is what I'm questioning above. It is hard to >> make it extensible so we do not have headache in future when somebody decides >> that more flexibility is needed OR that link-based approach is better. > > I think no matter we do we'll need to allow admins to override backup > locations, in future if we can calculate them automatically admins will > simply not set any backup location explicitly (or set some special value > like "autogenerate" and the system will do it for them. > > Forcing admins to mentally calculate weights to force the system to > autogenerate the configuration they want would be a bad experience, I > personally would find it very annoying. > >> In other words, for doing what you propose above we would have to design >> complete schema and API for variant A anyway to make sure we do not lock >> ourselves, so we are not getting any saving by doing so. > > A seemed much more complicated to me, as you wanted to define a ful > matrix for weights of servers when they are served as backups and all > that. > >>> - Define a *default* location, which is the backup for any other >>> location but always with lower priority to any other explicitly defined >>> backup locations. >> >> I would rather *always* use the default location as backup for all other >> locations. It does not require any API or schema (as it equals to "all >> servers" except "servers in this location" which can be easily calculated on fly). > > We can start with this, but it works well only in a stellar topology > where you have a central location all other location connect to. > As soon as you have a super-stellar topology where you have hub location > to which regional locations connect to, then this is wasteful. > >> This can be later on extended in whatever direction we want without any >> upgrade/migration problem. >> >> More importantly, all the schema and API will be common for all other variants >> anyway so we can start doing so and see how much time is left when it is done. > > I am ok with this for the first step. > After all location is mostly about the "normal" case where clients want > to reach the local servers, the backup part is only an additional > feature we can keep simple for now. It's a degraded mode of operation > anyway so it is probably ok to have just one default backup location as > a starting point. Okay, now we are in agreement. I will think about minimal schema and API over the weekend. Petr^2 Spacek >>> - Weights for backup location servers are the same as the weight defined >>> within the backup location itself, so no additional weights are defined >>> for backups. >> >> Yes, that was somehow implied in the variant A. Sorry for not mentioning it. >> Weight is always relative number for servers inside one location. > > Ok it looked a lot more complex from your description. > > Simo. From simo at redhat.com Fri Feb 26 15:12:32 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Feb 2016 10:12:32 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456497046.3136.8.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> Message-ID: <1456499552.6599.380.camel@redhat.com> On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote: > On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote: > > On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote: > > > > > > On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote: > > > > > > > > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > > > > > > > > > > > The above (pseudo) pull request contains four patches > > > > > > > > > against > > > > > > > > > FreeIPA > > > > > > > > > to enable the insertion of Authentication Indicators > > > > > > > > > into > > > > > > > > > Kerberos > > > > > > > > > tickets. The basic flow looks like this. > > > > > > > > > > > > > > > > > > First, we patch ipa-pwd-extop to return a control > > > > > > > > > indicating > > > > > > > > > what > > > > > > > > > authentication method succeeded resulting in a > > > > > > > > > successful > > > > > > > > > bind. > > > > > > > > > > > > > > > > > > Second, we patch ipa-otpd to check the returned control > > > > > > > > > to > > > > > > > > > ensure > > > > > > > > > that > > > > > > > > > the bind resulted from an otp validation. > > > > > > > > > > > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return > > > > > > > > > either > > > > > > > > > the > > > > > > > > > encrypted timestamp or encrypted challenge preauth > > > > > > > > > mechanism > > > > > > > > > when > > > > > > > > > the > > > > > > > > > user is configured for optional 2FA logins. Clients can > > > > > > > > > then > > > > > > > > > decide > > > > > > > > > whether to do 1FA or 2FA login (for kinit, sane > > > > > > > > > behavior > > > > > > > > > already > > > > > > > > > exists). > > > > > > > > > > > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded > > > > > > > > > authentication > > > > > > > > > indicators for either OTP or RADIUS. > > > > > > > > > > > > > > > > > > Some explanation is required for the first two patches. > > > > > > > > > Currently, > > > > > > > > > it > > > > > > > > > is possible to do a 1FA through the otp > > > > > > > > > preauthentication > > > > > > > > > mechanism > > > > > > > > > if > > > > > > > > > the user is configured for doing optional 2FA. However, > > > > > > > > > because > > > > > > > > > we > > > > > > > > > want > > > > > > > > > to insert an authentication indicator in this code > > > > > > > > > path, we > > > > > > > > > need > > > > > > > > > to > > > > > > > > > guarantee that a request going through the otp preauth > > > > > > > > > mechanism > > > > > > > > > actually validates an OTP. This is the purpose of the > > > > > > > > > control. > > > > > > > > > > > > > > > > > > Items still on the TODO list: > > > > > > > > > > > > > > > > > > * Authentication Indicator enforcement > > > > > > > > > - Upstream libkrb5 needs to grow funcs for reading > > > > > > > > > indicators > > > > > > > > > - Schema change to add indicators multi-value attr > > > > > > > > > to > > > > > > > > > services > > > > > > > > > - ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > > > > > > > > > > > > > > > > * SSSD needs to learn to handle optional 2FA > > > > > > > > > > > > > > > > > > I will write up a project page for all of this > > > > > > > > > tomorrow. > > > > > > > > > But > > > > > > > > > this > > > > > > > > > small > > > > > > > > > code basically amounts to my brainstorming. It is not > > > > > > > > > ready > > > > > > > > > for > > > > > > > > > merge, > > > > > > > > > just basic review. > > > > > > > > > > > > > > > > > It looks mostly ok, however the LDAP control part needs > > > > > > > > to be > > > > > > > > done > > > > > > > > as > > > > > > > > a > > > > > > > > request/response pair. > > > > > > > > A client that wishes to know what kind of authentication > > > > > > > > happened > > > > > > > > should > > > > > > > > send a request control, and only in that case , the > > > > > > > > server > > > > > > > > will > > > > > > > > send > > > > > > > > the > > > > > > > > associated reply control with the requested information. > > > > > > > I just pushed a new version of the control (now merged into > > > > > > > a > > > > > > > single > > > > > > > patch): https://github.com/npmccallum/freeipa/commit/a78191 > > > > > > > ee5d > > > > > > > 31 > > > > > > > e1de > > > > > > > 39 > > > > > > > f28eb637f66199da7e9225 > > > > > > > > > > > > > > In this version the client sends a critical control with no > > > > > > > content > > > > > > > indicating that the server must validate an OTP. If the > > > > > > > LDAP > > > > > > > server > > > > > > > doesn't support the control (for whatever reason), bind > > > > > > > will > > > > > > > fail. If > > > > > > > the LDAP server doesn't validate an OTP (for whatever > > > > > > > reason), > > > > > > > bind > > > > > > > will fail. > > > > > > > > > > > > > > This approach is simpler and doesn't require a > > > > > > > request/response > > > > > > > control > > > > > > > pair. > > > > > > I need some design advice. My goal here is that we need a way > > > > > > to > > > > > > expose > > > > > > the authentication indicators to services in the FreeIPA > > > > > > UI/CLI. > > > > > > > > > > > > Here is the good news: users can already set these values in > > > > > > FreeIPA > > > > > > using kadmin. They do this by simply setting the require_auth > > > > > > string on > > > > > > the target service principal. Our kdb plugin then encodes > > > > > > these > > > > > > with > > > > > > the rest of the tl_data into the krbExtraData attribute. > > > > > > > > > > > > I see two approaches here. First, we can try to manipulate > > > > > > the > > > > > > krbExtraData attribute directly. Second, we can create a > > > > > > separate > > > > > > attribute for the authentication indicator strings and then > > > > > > synthesize > > > > > > the tl_data internally in kdb. We would have to do this for > > > > > > both > > > > > > reads > > > > > > and writes so as not to break existing kdb functionality. > > > > > > > > > > > > The trade-off that I see is that the first method complicates > > > > > > the > > > > > > python framework side where the second method complicates the > > > > > > kdb > > > > > > plugin. > > > > > > > > > > > > A third option, which I doubt is even possible, is to use > > > > > > kadmin > > > > > > to > > > > > > manipulate this option rather than modifying LDAP directly. > > > > > > > > > > > > Thoughts? > > > > > We should translate it, we need that to allow to delegate > > > > > access > > > > > only > > > > > to > > > > > the specific attribute via our standard means. > > > > > > > > > > We already do this for other tl_data entries. > > > > > > > > > > The krbExtraData access cannot always be delegated because it > > > > > would > > > > > be > > > > > open ended. also it is really obnoxious to have to manipulate > > > > > ASN.1 > > > > > stuff in the framework. > > > > > > > > > > kadmin could be used at some point, but we'd still want to have > > > > > this > > > > > attribute extracted in order to be able to grant access control > > > > > individually, as our ACL system and delegation system is more > > > > > fine > > > > > grained than what kadmin can offer. > > > > After discussing this with MIT, Simo and Matt, it seems that the > > > > best > > > > option is to update the (MIT) upstream krbPrincipal objectClass > > > > to > > > > have > > > > a new attribute. The reason for this is twofold. First, it has > > > > upstream > > > > value. Second, we don't have good objectClass to attach the new > > > > attribute to inside FreeIPA. > > > > > > > > So the current plan is that Matt will create a patch for storing > > > > auth > > > > indicators (specifically, the "required_auth" strings) in a new > > > > multi- > > > > value string attribute on krbPrincipal objects. The > > > > get_principal() > > > > KDB > > > > hook will read "required_auth" from krbExtraData or (if present, > > > > preferred) the new attribute. In turn, the put_principal() KDB > > > > hook > > > > will store "required_auth" in the new attribute. This will allow > > > > the > > > > transparent migration of any data currently stored in > > > > krbExtraData. > > > > > > > > As part of this process, Matt will also refactor put_principal() > > > > into > > > > smaller functions (it is currently 800+ LOC). > > > > > > > > Once we have an attribute in upstream krbPrincipal, we will use > > > > this > > > > attribute exclusively in our KDB plugin. > > > I have started a project page: > > > http://www.freeipa.org/page/V4/AuthenticationIndicators > > > > > > We are still waiting on some details. But the general shape of > > > things > > > is there. Please review. :) > > LGTM so far. > > > > Questions: > > - Should the control specify what kind of auth specifically should be > > required ? > > I had also wondered that. I'm certainly not against it. But I'd > probably prefer a simple utf8 string value to avoid parsing complexity. > > > - Will it make sense in future to have different strength otp-like > > second factors and have ipa-otpd be able to specify which one it is > > expecting to be validated ? > > I'm personally hoping that we can deprecate ipa-otpd after SPAKE lands. > Post-SPAKE validations will require a method for validating OTP-only > (excluding password). This will probably be an extop. The same will be > true for all new second factors. Why an extop ? I was thinking you'd do a bind with this same control with a string that specifies you want to check only the second factor. (The result of the bind will be positive but you won't be logged in as the user the connection will still be marked anonymous.) > I'm thus not sure if we'll ever add more second factors to the existing > simple bind mechanism. LDAP binds still need to test both factors if they are required ... > > - Even if ipa-otpd will not grow such a feature, I see this control > > could be useful for pure LDAP auth clients, so perhaps a different > > kind > > of client may want to set this control ? Perhaps one day we can have > > a > > way to do GSSAPI auth and check that the AI on the ldap ticket was a > > 2FA > > and then DS will refuse login if the otp AI was missing on the ticket > > it > > received and the control requires it ? (could be used for the IPA UI > > connection to LDAP maybe ?) > > That seems to me like a decision LDAP can make internally. No? Not if the user has optional 2FA and you want to enforce the second factor only for certain operations from the framework (like say changing passwords or other more privileged operations). Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Fri Feb 26 15:24:09 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 26 Feb 2016 10:24:09 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456499552.6599.380.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> <1456499552.6599.380.camel@redhat.com> Message-ID: <1456500249.3136.15.camel@redhat.com> On Fri, 2016-02-26 at 10:12 -0500, Simo Sorce wrote: > On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote: > > > > On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote: > > > Questions: > > > - Should the control specify what kind of auth specifically > > > should be > > > required ? > > I had also wondered that. I'm certainly not against it. But I'd > > probably prefer a simple utf8 string value to avoid parsing > > complexity. > > > > > > > > - Will it make sense in future to have different strength otp- > > > like > > > second factors and have ipa-otpd be able to specify which one it > > > is > > > expecting to be validated ? > > I'm personally hoping that we can deprecate ipa-otpd after SPAKE > > lands. > > Post-SPAKE validations will require a method for validating OTP- > > only > > (excluding password). This will probably be an extop. The same will > > be > > true for all new second factors. > Why an extop ? I was thinking you'd do a bind with this same control > with a string that specifies you want to check only the second > factor. > (The result of the bind will be positive but you won't be logged in > as > the user the connection will still be marked anonymous.) How can you do this anonymously? You need to know which tokens to validate. This requires a user dn. Besides, I would think we also want to be bound *before* performing this operation. Otherwise, we could allow brute force tries on the 2nd factor. I was thinking: 1. Bind as the entity validating the 2nd factor. 2. Extop which takes the: ? ?* user dn ? ?* type of 2nd factor ? ?* validation data ? ?* dn of 2nd factor (optional) This provides an audit trail of who is validating 2nd factors. > > I'm thus not sure if we'll ever add more second factors to the > > existing > > simple bind mechanism. > LDAP binds still need to test both factors if they are required ... We would grandfather OTP. But all new 2FA would require GSSAPI (using AIs) to use LDAP. > > > - Even if ipa-otpd will not grow such a feature, I see this > > > control > > > could be useful for pure LDAP auth clients, so perhaps a > > > different > > > kind > > > of client may want to set this control ? Perhaps one day we can > > > have > > > a > > > way to do GSSAPI auth and check that the AI on the ldap ticket > > > was a > > > 2FA > > > and then DS will refuse login if the otp AI was missing on the > > > ticket > > > it > > > received and the control requires it ? (could be used for the IPA > > > UI > > > connection to LDAP maybe ?) > > That seems to me like a decision LDAP can make internally. No? > Not if the user has optional 2FA and you want to enforce the second > factor only for certain operations from the framework (like say > changing > passwords or other more privileged operations). Why can't we just use GSSAPI with AIs? From tbordaz at redhat.com Fri Feb 26 15:24:23 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 26 Feb 2016 16:24:23 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56CF452E.30503@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> <56CEDF98.7060809@redhat.com> <56CF452E.30503@redhat.com> Message-ID: <56D06E27.2050408@redhat.com> On 02/25/2016 07:17 PM, thierry bordaz wrote: > On 02/25/2016 12:03 PM, Martin Babinsky wrote: >> On 02/24/2016 04:30 PM, thierry bordaz wrote: >>> On 01/21/2016 05:04 PM, Martin Babinsky wrote: >>>> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>>>> >>>>> >>>>> >>>> Hi Thierry, >>>> >>>> I have couple of comments to your patch: >>>> >>>> 1.) >>>> there is a number of PEP8 errors in the patch >>>> (http://paste.fedoraproject.org/313246/33893701), please fix them. >>>> >>>> See http://www.freeipa.org/page/Python_Coding_Style for our >>>> conventions used in Python code. >>>> >>>> 2.) >>>> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >>>> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >>>> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >>>> Plugin,cn=plugins,cn=config' >>>> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >>>> >>>> Uppercase names are usually reserved for module-level constants. OTOH, >>>> local variables should be lowercase. Also you can instantiate >>>> dna_config_base directly as DN, using 2-member tuples, i. e: >>>> >>>> """ >>>> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric >>>> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >>>> """ >>>> >>>> When passing DN object to the formatting functions/operators, it is >>>> automatically converted to string so no need to hold string and DN >>>> object separately. This is done in other places (see function/methods >>>> in replication.py). >>>> >>>> 3.) >>>> >>>> + for i in range(len(entries)) : >>>> + >>>> + mod = [] >>>> + if entries[i].single_value.get(DNA_BIND_METHOD) != >>>> method: >>>> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, >>>> method)) >>>> + >>>> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >>>> protocol: >>>> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >>>> protocol)) >>>> >>>> >>>> please use idiomatic Python when handling list of entries, e.g.: >>>> >>>> """ >>>> for entry in entries: >>>> mod = [] >>>> if entry.single_value.get(DNA_BIND_METHOD) != method: >>>> ... >>>> """ >>>> >>>> 4.) I think that this method should in DSInstance class since it deals >>>> with directory server configuration. Service is a parent object of all >>>> other service installers/configurators and should contain only methods >>>> common to more children. >>>> >>>> 5.) Since the method is called from every installer, it could be >>>> beneficial to call it in DSInstance.__common_post_setup() as a part of >>>> Directory server installation. Is there any reason why this is not the >>>> case? >>>> >>>> 6.) >>>> >>>> + while attempt != MAX_WAIT: >>>> + try: >>>> + entries = conn.get_entries(sharedcfgdn, >>>> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >>>> + break >>>> + except errors.NotFound: >>>> + root_logger.debug("So far enable not find DNA shared >>>> config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn, >>>> sharedcfgdn)) >>>> + attempt = attempt + 1 >>>> + time.sleep(2) >>>> + continue >>>> + >>>> + # safety checking >>>> + # there is no return, if there are several entries, as a >>>> workaround of #5510 >>>> + if len(entries) != 1: >>>> >>>> I am quite afraid what would happen if the server does not return any >>>> entries until 30 s timeout. The code will then continue to the >>>> condition which can potentially test an uninitialized variable and >>>> blow up with 'NameError'. This should be handled more robustly, e. g. >>>> raise an exception when a timeout is reached and no entries were >>>> returned. >>>> >>>> 7.) >>>> >>>> + if len(mod) > 0: >>>> >>>> A Pythonic way to test for non-empty container is >>>> >>>> """ >>>> if mods: >>>> # do stuff >>>> """ >>>> >>>> since an empty list/dict/set evaluates to False and non-empty >>>> containers are True. >>>> >>>> >>>> 8.) >>>> >>>> + entry = conn.get_entry(entries[i].dn) >>>> + if entry.single_value.get(DNA_BIND_METHOD) != method: >>>> + root_logger.error("Fail to set SASL/GSSAPI bind >>>> method to %s" % (entries[i].dn)) >>>> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >>>> protocol: >>>> + root_logger.error("Fail to set LDAP protocol to >>>> %s" % (entries[i].dn)) >>>> >>>> rather than re-fetching the modified entry and testing what happened, >>>> you can just catch an exception raised by unsuccessfull mod and log an >>>> error like this: >>>> >>>> """ >>>> try: >>>> conn.modify_s(entry.dn, mod) >>>> except Exception as e: >>>> root_logger.error("Failed to modify entry {}: {}".format(entry, e)) >>>> """ >>>> >>>> as a matter of fact, if the modify_s operation would fail for some >>>> reason, an ldap exception would be raised and you checks would not >>>> even be executed. >>>> >>>> 9.) >>>> The debug message on line 219 should read "Unable to find DNA shared >>>> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >>>> at the end of the method should have "Failed" instead of "Fail". >>>> >>> Hi Martin, >>> >>> Finally tested... here is the updated patch. Thanks for you patience >>> >>> >>> thanks >>> thierry >> >> Hi Thierry, >> >> the patch works as expected. I have some more nitpicks though: >> >> 1.) Please fix the following pep8 errors: >> >> http://paste.fedoraproject.org/329086/56397841/ >> >> you can check whether you recent commit conforms to PEP8 by running >> >> "git show -U0 | pep8 --diff" >> >> 2.) >> + self.step("update DNA shared config entry", >> self.update_dna_shared_config) >> >> I would rather change the message to "Updating DNA shared config >> entry" since all other messages use continuous tense. >> >> 3.) >> + else: >> + raise RuntimeError("Could not get dnaHostname >> entries in {} seconds".format(max_wait * 2)) >> >> Please use root_logger.error() and then return as is used elsewhere >> in the method. We do not want a runaway exception crashing upgrade. >> > Hi Martin, > > Updated/tested the patch with your help/recommendations. pep8 is clear > now :-) > > thanks > thierry Hi Martin, Following your recommendation it is an updated patch to not check/update shared config entry in DSinstance.__post_common_setup(). In fact at this step, DNA plugin is disabled and such the check would be a no-op. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0017-4-configure-DNA-plugin-shared-config-entries-to-allow-.patch Type: text/x-patch Size: 8171 bytes Desc: not available URL: From lhellebr at redhat.com Fri Feb 26 15:38:44 2016 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Fri, 26 Feb 2016 16:38:44 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Adding URL to HBAC rule In-Reply-To: <56D0454E.1050207@redhat.com> References: <56D0425B.4040503@redhat.com> <56D0454E.1050207@redhat.com> Message-ID: <56D07184.5020405@redhat.com> On 02/26/2016 01:30 PM, Martin Kosek wrote: > Greetings, welcome! > > On 02/26/2016 01:17 PM, Luk?? Hellebrandt wrote: > ... >> Btw, is there some better place to share patches than a pasting tool? >> Maybe some form of pull request? > > There is :-) Please see advise here: > > http://www.freeipa.org/page/Contribute/Code#Submit_a_patch > > It has more information on top of submitting patches. For example, I think it > would actually make sense to start with a design page where you would describe > the use cases, design, APIs, etc: > > http://www.freeipa.org/page/Contribute/Code#Prepare > > Martin > Should I send it as an attachment? Ok, sending, but do not apply it yet (even if you don't find bugs), I just need some feedback - not everything is done yet. -- Lukas Hellebrandt Associate Quality Engineer lhellebr at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lhellebr-0001-Adding-URL-to-HBAC-rule.patch Type: text/x-patch Size: 14003 bytes Desc: not available URL: From simo at redhat.com Fri Feb 26 15:58:57 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Feb 2016 10:58:57 -0500 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback In-Reply-To: <56D0425B.4040503@redhat.com> References: <56D0425B.4040503@redhat.com> Message-ID: <1456502337.6599.393.camel@redhat.com> On Fri, 2016-02-26 at 13:17 +0100, Luk?? Hellebrandt wrote: > Hi, FreeIPA and SSSD communities! > > I am working on adding URI to HBAC as my thesis [1]. The goal is to > control access not only based on (user, host, service), but on (user, > host, service, resource's URI). > > I created a patch for FreeIPA [2] so it is capable of storing URI as > part of HBAC rule. I created a patch for SSSD [3] so it is able to get > this URI from FreeIPA and use it in HBAC evaluation. > > I still need to develop a part of SSSD receiving URI-aware requests. It > will either be an enhancement of Infopipe or I will use PAM responder > (any suggestions?). > > I wanted to kindly ask you for review and your opinions on the patches > and generally on my approach. This would be my first contribution to > FreeIPA and SSSD so there might be bugs. What do you think? > > Btw, is there some better place to share patches than a pasting tool? > Maybe some form of pull request? > > Thanks for your opinions! > > [1] > https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa > [2] > http://pastebin.com/rsHzXeAR > [3] > http://pastebin.com/atcZMuP1 > Hi Lukas, could please post your patches here using git-format-patch or even better provide a public git tree with them applied ? (Any place github, fedorapeople, your own server, etc. is fine) First a question, what service can actually use this scheme and how ? there is no URL field in PAM. On the patches: [2] you define a new attribute Url which is fine, but the actual attribute is not ok in several way. - You assigned an OID from a hole in the IPAv2 Attibutes space, it should be an assigned ID from the IPAv3 attribute space instead - You do not namespace the attribute, it should at least be ipaUrl - you are using case Exact matching, is this intentional? Are the URIs in there case sensitive strings ? - there is an available attribute called labeledURI (with alias labeledurl) in the standard schema (however I notice it also has caseExactMatch) that has basically the same definition of your Url attribute, why not use that one ? [3] If I read the patch correctly failing to find a Url is a fatal condition, this is not ok as it would fail to operate with older servers that do not have a url on the rules. It is not clear to me what happen on an older client if URL is used but not the service? Or is service always enforced ? (It is not clear to me that it is). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Feb 26 16:14:42 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Feb 2016 17:14:42 +0100 Subject: [Freeipa-devel] [PATCHES] 0772-0774 Python3 fixes in for client installation In-Reply-To: <56CAF30F.7010306@redhat.com> References: <56CAF30F.7010306@redhat.com> Message-ID: <56D079F2.2020501@redhat.com> On 02/22/2016 12:37 PM, Petr Viktorin wrote: > Hello, > These fixes are needed for the "happy path" of ipa-client-install > --server on Python 3. Hello, Could someone please look at these patches? -- Petr Viktorin From jhrozek at redhat.com Fri Feb 26 16:17:48 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 26 Feb 2016 17:17:48 +0100 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback In-Reply-To: <1456502337.6599.393.camel@redhat.com> References: <56D0425B.4040503@redhat.com> <1456502337.6599.393.camel@redhat.com> Message-ID: <20160226161748.GC20147@hendrix.redhat.com> On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote: > On Fri, 2016-02-26 at 13:17 +0100, Luk?? Hellebrandt wrote: > > Hi, FreeIPA and SSSD communities! > > > > I am working on adding URI to HBAC as my thesis [1]. The goal is to > > control access not only based on (user, host, service), but on (user, > > host, service, resource's URI). > > > > I created a patch for FreeIPA [2] so it is capable of storing URI as > > part of HBAC rule. I created a patch for SSSD [3] so it is able to get > > this URI from FreeIPA and use it in HBAC evaluation. > > > > I still need to develop a part of SSSD receiving URI-aware requests. It > > will either be an enhancement of Infopipe or I will use PAM responder > > (any suggestions?). > > > > I wanted to kindly ask you for review and your opinions on the patches > > and generally on my approach. This would be my first contribution to > > FreeIPA and SSSD so there might be bugs. What do you think? > > > > Btw, is there some better place to share patches than a pasting tool? > > Maybe some form of pull request? > > > > Thanks for your opinions! > > > > [1] > > https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa > > [2] > > http://pastebin.com/rsHzXeAR > > [3] > > http://pastebin.com/atcZMuP1 > > > > Hi Lukas, could please post your patches here using git-format-patch or > even better provide a public git tree with them applied ? > (Any place github, fedorapeople, your own server, etc. is fine) > > > First a question, what service can actually use this scheme and how ? > there is no URL field in PAM. When Lukas started the work, we IIRC concluded that PAM is not an appropriate interface and we should probably expose some DBUS methods for access control. We haven't really discussed any details since then. From simo at redhat.com Fri Feb 26 16:20:24 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Feb 2016 11:20:24 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456500249.3136.15.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> <1456499552.6599.380.camel@redhat.com> <1456500249.3136.15.camel@redhat.com> Message-ID: <1456503624.6599.401.camel@redhat.com> On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote: > On Fri, 2016-02-26 at 10:12 -0500, Simo Sorce wrote: > > On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote: > > > > > > On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote: > > > > Questions: > > > > - Should the control specify what kind of auth specifically > > > > should be > > > > required ? > > > I had also wondered that. I'm certainly not against it. But I'd > > > probably prefer a simple utf8 string value to avoid parsing > > > complexity. > > > > > > > > > > > - Will it make sense in future to have different strength otp- > > > > like > > > > second factors and have ipa-otpd be able to specify which one it > > > > is > > > > expecting to be validated ? > > > I'm personally hoping that we can deprecate ipa-otpd after SPAKE > > > lands. > > > Post-SPAKE validations will require a method for validating OTP- > > > only > > > (excluding password). This will probably be an extop. The same will > > > be > > > true for all new second factors. > > Why an extop ? I was thinking you'd do a bind with this same control > > with a string that specifies you want to check only the second > > factor. > > (The result of the bind will be positive but you won't be logged in > > as > > the user the connection will still be marked anonymous.) > > How can you do this anonymously? The bind is not done anonymously, but the outcome of the bind operation is that the user DS sees is the anonymous user (because you didn't use the first factor at all). > You need to know which tokens to > validate. This requires a user dn. Sure this is a different concern, I was concerned about the outcome of the bind operation not its setup. > Besides, I would think we also want > to be bound *before* performing this operation. Otherwise, we could > allow brute force tries on the 2nd factor. Yes, this is a concern, but only with HOTP, with TOTP, you cannot really brute force easily as you have to wait 30 sec. between each try (assuming we mark the current OTP has been used and immediately return an error on any further attempt ?) We can also still lock the user account if too many attempts are performed. However it is a concern indeed. > I was thinking: > 1. Bind as the entity validating the 2nd factor. > 2. Extop which takes the: > * user dn > * type of 2nd factor > * validation data > * dn of 2nd factor (optional) > > This provides an audit trail of who is validating 2nd factors. Ok, this makes sense. I wish we didn't have to create yet another extop, but if we want to gate the check via another bind it makes sense. > > > I'm thus not sure if we'll ever add more second factors to the > > > existing > > > simple bind mechanism. > > LDAP binds still need to test both factors if they are required ... > > We would grandfather OTP. But all new 2FA would require GSSAPI (using > AIs) to use LDAP. I do not think we can enforce this, we still have a lot of deployments that rely on LDAP binds to check credentials, and we should try to support this as much as possible. > > > > - Even if ipa-otpd will not grow such a feature, I see this > > > > control > > > > could be useful for pure LDAP auth clients, so perhaps a > > > > different > > > > kind > > > > of client may want to set this control ? Perhaps one day we can > > > > have > > > > a > > > > way to do GSSAPI auth and check that the AI on the ldap ticket > > > > was a > > > > 2FA > > > > and then DS will refuse login if the otp AI was missing on the > > > > ticket > > > > it > > > > received and the control requires it ? (could be used for the IPA > > > > UI > > > > connection to LDAP maybe ?) > > > That seems to me like a decision LDAP can make internally. No? > > Not if the user has optional 2FA and you want to enforce the second > > factor only for certain operations from the framework (like say > > changing > > passwords or other more privileged operations). > > Why can't we just use GSSAPI with AIs? We would! But the AI check would be done (optionally) for the LDAP server, not the HTTP service, remember that we do s4u2proxy and use GSSAPI auth from the framework. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Feb 26 16:33:26 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Feb 2016 11:33:26 -0500 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback In-Reply-To: <20160226161748.GC20147@hendrix.redhat.com> References: <56D0425B.4040503@redhat.com> <1456502337.6599.393.camel@redhat.com> <20160226161748.GC20147@hendrix.redhat.com> Message-ID: <1456504406.6599.403.camel@redhat.com> On Fri, 2016-02-26 at 17:17 +0100, Jakub Hrozek wrote: > On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote: > > On Fri, 2016-02-26 at 13:17 +0100, Luk?? Hellebrandt wrote: > > > Hi, FreeIPA and SSSD communities! > > > > > > I am working on adding URI to HBAC as my thesis [1]. The goal is to > > > control access not only based on (user, host, service), but on (user, > > > host, service, resource's URI). > > > > > > I created a patch for FreeIPA [2] so it is capable of storing URI as > > > part of HBAC rule. I created a patch for SSSD [3] so it is able to get > > > this URI from FreeIPA and use it in HBAC evaluation. > > > > > > I still need to develop a part of SSSD receiving URI-aware requests. It > > > will either be an enhancement of Infopipe or I will use PAM responder > > > (any suggestions?). > > > > > > I wanted to kindly ask you for review and your opinions on the patches > > > and generally on my approach. This would be my first contribution to > > > FreeIPA and SSSD so there might be bugs. What do you think? > > > > > > Btw, is there some better place to share patches than a pasting tool? > > > Maybe some form of pull request? > > > > > > Thanks for your opinions! > > > > > > [1] > > > https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa > > > [2] > > > http://pastebin.com/rsHzXeAR > > > [3] > > > http://pastebin.com/atcZMuP1 > > > > > > > Hi Lukas, could please post your patches here using git-format-patch or > > even better provide a public git tree with them applied ? > > (Any place github, fedorapeople, your own server, etc. is fine) > > > > > > First a question, what service can actually use this scheme and how ? > > there is no URL field in PAM. > > When Lukas started the work, we IIRC concluded that PAM is not an > appropriate interface and we should probably expose some DBUS methods > for access control. We haven't really discussed any details since then. This only shifts the question, what service would use this interface ? note I am not opposed to it, but would like to understand how we are going to test that it actually works and is useful. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Fri Feb 26 16:48:36 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 26 Feb 2016 17:48:36 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56D06E27.2050408@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> <56CEDF98.7060809@redhat.com> <56CF452E.30503@redhat.com> <56D06E27.2050408@redhat.com> Message-ID: <56D081E4.4070702@redhat.com> On 02/26/2016 04:24 PM, thierry bordaz wrote: > On 02/25/2016 07:17 PM, thierry bordaz wrote: >> On 02/25/2016 12:03 PM, Martin Babinsky wrote: >>> On 02/24/2016 04:30 PM, thierry bordaz wrote: >>>> On 01/21/2016 05:04 PM, Martin Babinsky wrote: >>>>> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>>>>> >>>>>> >>>>>> >>>>> Hi Thierry, >>>>> >>>>> I have couple of comments to your patch: >>>>> >>>>> 1.) >>>>> there is a number of PEP8 errors in the patch >>>>> (http://paste.fedoraproject.org/313246/33893701), please fix them. >>>>> >>>>> See http://www.freeipa.org/page/Python_Coding_Style for our >>>>> conventions used in Python code. >>>>> >>>>> 2.) >>>>> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >>>>> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >>>>> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >>>>> Plugin,cn=plugins,cn=config' >>>>> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >>>>> >>>>> Uppercase names are usually reserved for module-level constants. OTOH, >>>>> local variables should be lowercase. Also you can instantiate >>>>> dna_config_base directly as DN, using 2-member tuples, i. e: >>>>> >>>>> """ >>>>> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed Numeric >>>>> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >>>>> """ >>>>> >>>>> When passing DN object to the formatting functions/operators, it is >>>>> automatically converted to string so no need to hold string and DN >>>>> object separately. This is done in other places (see function/methods >>>>> in replication.py). >>>>> >>>>> 3.) >>>>> >>>>> + for i in range(len(entries)) : >>>>> + >>>>> + mod = [] >>>>> + if entries[i].single_value.get(DNA_BIND_METHOD) != >>>>> method: >>>>> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, >>>>> method)) >>>>> + >>>>> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >>>>> protocol: >>>>> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >>>>> protocol)) >>>>> >>>>> >>>>> please use idiomatic Python when handling list of entries, e.g.: >>>>> >>>>> """ >>>>> for entry in entries: >>>>> mod = [] >>>>> if entry.single_value.get(DNA_BIND_METHOD) != method: >>>>> ... >>>>> """ >>>>> >>>>> 4.) I think that this method should in DSInstance class since it deals >>>>> with directory server configuration. Service is a parent object of all >>>>> other service installers/configurators and should contain only methods >>>>> common to more children. >>>>> >>>>> 5.) Since the method is called from every installer, it could be >>>>> beneficial to call it in DSInstance.__common_post_setup() as a part of >>>>> Directory server installation. Is there any reason why this is not the >>>>> case? >>>>> >>>>> 6.) >>>>> >>>>> + while attempt != MAX_WAIT: >>>>> + try: >>>>> + entries = conn.get_entries(sharedcfgdn, >>>>> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >>>>> + break >>>>> + except errors.NotFound: >>>>> + root_logger.debug("So far enable not find DNA shared >>>>> config entry for dnaHostname=%s under %s. Retry in 2sec" % (self.fqdn, >>>>> sharedcfgdn)) >>>>> + attempt = attempt + 1 >>>>> + time.sleep(2) >>>>> + continue >>>>> + >>>>> + # safety checking >>>>> + # there is no return, if there are several entries, as a >>>>> workaround of #5510 >>>>> + if len(entries) != 1: >>>>> >>>>> I am quite afraid what would happen if the server does not return any >>>>> entries until 30 s timeout. The code will then continue to the >>>>> condition which can potentially test an uninitialized variable and >>>>> blow up with 'NameError'. This should be handled more robustly, e. g. >>>>> raise an exception when a timeout is reached and no entries were >>>>> returned. >>>>> >>>>> 7.) >>>>> >>>>> + if len(mod) > 0: >>>>> >>>>> A Pythonic way to test for non-empty container is >>>>> >>>>> """ >>>>> if mods: >>>>> # do stuff >>>>> """ >>>>> >>>>> since an empty list/dict/set evaluates to False and non-empty >>>>> containers are True. >>>>> >>>>> >>>>> 8.) >>>>> >>>>> + entry = conn.get_entry(entries[i].dn) >>>>> + if entry.single_value.get(DNA_BIND_METHOD) != method: >>>>> + root_logger.error("Fail to set SASL/GSSAPI bind >>>>> method to %s" % (entries[i].dn)) >>>>> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >>>>> protocol: >>>>> + root_logger.error("Fail to set LDAP protocol to >>>>> %s" % (entries[i].dn)) >>>>> >>>>> rather than re-fetching the modified entry and testing what happened, >>>>> you can just catch an exception raised by unsuccessfull mod and log an >>>>> error like this: >>>>> >>>>> """ >>>>> try: >>>>> conn.modify_s(entry.dn, mod) >>>>> except Exception as e: >>>>> root_logger.error("Failed to modify entry {}: {}".format(entry, e)) >>>>> """ >>>>> >>>>> as a matter of fact, if the modify_s operation would fail for some >>>>> reason, an ldap exception would be raised and you checks would not >>>>> even be executed. >>>>> >>>>> 9.) >>>>> The debug message on line 219 should read "Unable to find DNA shared >>>>> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >>>>> at the end of the method should have "Failed" instead of "Fail". >>>>> >>>> Hi Martin, >>>> >>>> Finally tested... here is the updated patch. Thanks for you patience >>>> >>>> >>>> thanks >>>> thierry >>> >>> Hi Thierry, >>> >>> the patch works as expected. I have some more nitpicks though: >>> >>> 1.) Please fix the following pep8 errors: >>> >>> http://paste.fedoraproject.org/329086/56397841/ >>> >>> you can check whether you recent commit conforms to PEP8 by running >>> >>> "git show -U0 | pep8 --diff" >>> >>> 2.) >>> + self.step("update DNA shared config entry", >>> self.update_dna_shared_config) >>> >>> I would rather change the message to "Updating DNA shared config >>> entry" since all other messages use continuous tense. >>> >>> 3.) >>> + else: >>> + raise RuntimeError("Could not get dnaHostname >>> entries in {} seconds".format(max_wait * 2)) >>> >>> Please use root_logger.error() and then return as is used elsewhere >>> in the method. We do not want a runaway exception crashing upgrade. >>> >> Hi Martin, >> >> Updated/tested the patch with your help/recommendations. pep8 is clear >> now :-) >> >> thanks >> thierry > > Hi Martin, > > Following your recommendation it is an updated patch to not check/update > shared config entry in DSinstance.__post_common_setup(). > In fact at this step, DNA plugin is disabled and such the check would be > a no-op. > > thanks > thierry Thanks Thierry, the patch will need a rebased version which applies cleanly on top of ipa-4-3 branch, but otherwise ACK. -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Feb 26 17:03:11 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 26 Feb 2016 18:03:11 +0100 Subject: [Freeipa-devel] [PATCH 00136] use LDAPS during standalone CA/KRA subsystem deployment Message-ID: <56D0854F.4030404@redhat.com> This patch fixes https://fedorahosted.org/freeipa/ticket/5570 and also enables CA installation on CA-less master with hardened dirsrv configuration. When testing I ran into the issue with Dogtag restart during KRA installation [1] which I will try to troubleshoot with Dogtag guys. You are welcome to troubleshoot it also during the review, maybe I did some misconfiguration on my part. [1] https://www.redhat.com/archives/pki-devel/2016-February/msg00100.html -- Martin^3 Babinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-mbabinsk-0136-use-LDAPS-during-standalone-CA-KRA-subsystem-deploym.patch Type: text/x-patch Size: 2760 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbabinsk-0136-use-LDAPS-during-standalone-CA-KRA-subsystem-deploym.patch Type: text/x-patch Size: 2785 bytes Desc: not available URL: From lslebodn at redhat.com Fri Feb 26 20:38:41 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 26 Feb 2016 21:38:41 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <56D038F4.5040909@redhat.com> References: <20160222104811.GN4492@redhat.com> <56CB3F82.1070408@redhat.com> <20160222171455.GT4492@redhat.com> <56CB59E3.3010709@redhat.com> <56CFF106.1080305@redhat.com> <56D038F4.5040909@redhat.com> Message-ID: <20160226203840.GB16465@mail.corp.redhat.com> On (26/02/16 12:37), Tomas Babej wrote: > > >On 02/26/2016 07:30 AM, Jan Cholasta wrote: >> On 22.2.2016 19:56, Tomas Babej wrote: >>> >>> >>> On 02/22/2016 06:14 PM, Alexander Bokovoy wrote: >>>> On Mon, 22 Feb 2016, Tomas Babej wrote: >>>>> >>>>> >>>>> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: >>>>>> Hi, >>>>>> >>>>>> attached patch should update compat tree configuration if it exist to >>>>>> follow slapi-nis 0.55 which has support for external members of IPA >>>>>> groups. >>>>>> >>>>>> However, the real work is done in SSSD. These patches are not >>>>>> upstreamed >>>>>> yet. We'll need to bump SSSD dependency in future once they come to >>>>>> distros. >>>>>> >>>>>> >>>>>> >>>>> >>>>> This looks good. >>>>> >>>>> However, the new update file needs to be added to Makefile.am. >>>>> Additionally, patch adds a whitespace error. >>>> Updated patch is attached. >>>> >>> >>> ACK. >>> >>> This should not be pushed until the dependency for SSSD can be bumped. >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2016-d872920f74 >> > >Attaching the required spec change. > >Tomas >From dae8b8fd0b23bf25ccf75b275deaa5c599faa27b Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Fri, 26 Feb 2016 12:35:09 +0100 >Subject: [PATCH] spec: Bump required sssd version to 1.13.3-5 > >Required as part of: https://fedorahosted.org/freeipa/ticket/4403 ^^^^^^^^^^^^^ There isn't mentioned sssd related ticket in slapi-nis bug It would be good to add also sssd related ticket to commit message https://fedorahosted.org/sssd/ticket/2522 LS From npmccallum at redhat.com Fri Feb 26 20:44:02 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 26 Feb 2016 15:44:02 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456503624.6599.401.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> <1456499552.6599.380.camel@redhat.com> <1456500249.3136.15.camel@redhat.com> <1456503624.6599.401.camel@redhat.com> Message-ID: <1456519442.3136.22.camel@redhat.com> On Fri, 2016-02-26 at 11:20 -0500, Simo Sorce wrote: > On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote: > > I was thinking: > > 1. Bind as the entity validating the 2nd factor. > > 2. Extop which takes the: > > ???* user dn > > ???* type of 2nd factor > > ???* validation data > > ???* dn of 2nd factor (optional) > > > > This provides an audit trail of who is validating 2nd factors. > Ok, this makes sense. > I wish we didn't have to create yet another extop, but if we want to > gate the check via another bind it makes sense. I wish we had done this the first time. However, this really only makes complete sense in a post-SPAKE world. I actually think we should have a different extop for each 2F type. Each 2F type can define its own interface (and possibly more than one round-trip; such as token sync). > > > > I'm thus not sure if we'll ever add more second factors to the > > > > existing > > > > simple bind mechanism. > > > LDAP binds still need to test both factors if they are required > > > ... > > We would grandfather OTP. But all new 2FA would require GSSAPI > > (using > > AIs) to use LDAP. > I do not think we can enforce this, we still have a lot of > deployments > that rely on LDAP binds to check credentials, and we should try to > support this as much as possible. Consider the case of U2F. I don't think we can ever support LDAP simple bind with U2F. And I think U2F will be supported long before anything else. > > > > > - Even if ipa-otpd will not grow such a feature, I see this > > > > > control > > > > > could be useful for pure LDAP auth clients, so perhaps a > > > > > different > > > > > kind > > > > > of client may want to set this control ? Perhaps one day we > > > > > can > > > > > have > > > > > a > > > > > way to do GSSAPI auth and check that the AI on the ldap > > > > > ticket > > > > > was a > > > > > 2FA > > > > > and then DS will refuse login if the otp AI was missing on > > > > > the > > > > > ticket > > > > > it > > > > > received and the control requires it ? (could be used for the > > > > > IPA > > > > > UI > > > > > connection to LDAP maybe ?) > > > > That seems to me like a decision LDAP can make internally. No? > > > Not if the user has optional 2FA and you want to enforce the > > > second > > > factor only for certain operations from the framework (like say > > > changing > > > passwords or other more privileged operations). > > Why can't we just use GSSAPI with AIs? > We would! But the AI check would be done (optionally) for the LDAP > server, not the HTTP service, remember that we do s4u2proxy and use > GSSAPI auth from the framework. I'm missing something here. From simo at redhat.com Sat Feb 27 01:54:39 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Feb 2016 20:54:39 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <1456519442.3136.22.camel@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <1456497046.3136.8.camel@redhat.com> <1456499552.6599.380.camel@redhat.com> <1456500249.3136.15.camel@redhat.com> <1456503624.6599.401.camel@redhat.com> <1456519442.3136.22.camel@redhat.com> Message-ID: <1456538079.6599.460.camel@redhat.com> On Fri, 2016-02-26 at 15:44 -0500, Nathaniel McCallum wrote: > On Fri, 2016-02-26 at 11:20 -0500, Simo Sorce wrote: > > On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote: > > > I was thinking: > > > 1. Bind as the entity validating the 2nd factor. > > > 2. Extop which takes the: > > > * user dn > > > * type of 2nd factor > > > * validation data > > > * dn of 2nd factor (optional) > > > > > > This provides an audit trail of who is validating 2nd factors. > > Ok, this makes sense. > > I wish we didn't have to create yet another extop, but if we want to > > gate the check via another bind it makes sense. > > I wish we had done this the first time. However, this really only makes > complete sense in a post-SPAKE world. > > I actually think we should have a different extop for each 2F type. > Each 2F type can define its own interface (and possibly more than one > round-trip; such as token sync). Not sure about this. > > > > > I'm thus not sure if we'll ever add more second factors to the > > > > > existing > > > > > simple bind mechanism. > > > > LDAP binds still need to test both factors if they are required > > > > ... > > > We would grandfather OTP. But all new 2FA would require GSSAPI > > > (using > > > AIs) to use LDAP. > > I do not think we can enforce this, we still have a lot of > > deployments > > that rely on LDAP binds to check credentials, and we should try to > > support this as much as possible. > > Consider the case of U2F. I don't think we can ever support LDAP simple > bind with U2F. And I think U2F will be supported long before anything > else. For things like U2F it may make more sense to develop a SASL mechanism, we use SASL for GSSAPI too. > > > > > > - Even if ipa-otpd will not grow such a feature, I see this > > > > > > control > > > > > > could be useful for pure LDAP auth clients, so perhaps a > > > > > > different > > > > > > kind > > > > > > of client may want to set this control ? Perhaps one day we > > > > > > can > > > > > > have > > > > > > a > > > > > > way to do GSSAPI auth and check that the AI on the ldap > > > > > > ticket > > > > > > was a > > > > > > 2FA > > > > > > and then DS will refuse login if the otp AI was missing on > > > > > > the > > > > > > ticket > > > > > > it > > > > > > received and the control requires it ? (could be used for the > > > > > > IPA > > > > > > UI > > > > > > connection to LDAP maybe ?) > > > > > That seems to me like a decision LDAP can make internally. No? > > > > Not if the user has optional 2FA and you want to enforce the > > > > second > > > > factor only for certain operations from the framework (like say > > > > changing > > > > passwords or other more privileged operations). > > > Why can't we just use GSSAPI with AIs? > > We would! But the AI check would be done (optionally) for the LDAP > > server, not the HTTP service, remember that we do s4u2proxy and use > > GSSAPI auth from the framework. > > I'm missing something here. The idea is that the framework may use the control that the server should fail the bind if 2FA AI is not present on the ticket and re-bind to LDAP before performing a high privilege operation. The bind would fail if the required AI is not present and the higher priv. operation would fail. for normally privileged operation (like listing users) the control 2 require OTP AI wouldn't be sent so a bind would succeed even if original credentials were 1FA. Hope this makes it more clear. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Sun Feb 28 10:39:35 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 28 Feb 2016 11:39:35 +0100 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback In-Reply-To: <1456504406.6599.403.camel@redhat.com> References: <56D0425B.4040503@redhat.com> <1456502337.6599.393.camel@redhat.com> <20160226161748.GC20147@hendrix.redhat.com> <1456504406.6599.403.camel@redhat.com> Message-ID: <20160228103935.GG20147@hendrix.redhat.com> On Fri, Feb 26, 2016 at 11:33:26AM -0500, Simo Sorce wrote: > On Fri, 2016-02-26 at 17:17 +0100, Jakub Hrozek wrote: > > On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote: > > > On Fri, 2016-02-26 at 13:17 +0100, Luk?? Hellebrandt wrote: > > > > Hi, FreeIPA and SSSD communities! > > > > > > > > I am working on adding URI to HBAC as my thesis [1]. The goal is to > > > > control access not only based on (user, host, service), but on (user, > > > > host, service, resource's URI). > > > > > > > > I created a patch for FreeIPA [2] so it is capable of storing URI as > > > > part of HBAC rule. I created a patch for SSSD [3] so it is able to get > > > > this URI from FreeIPA and use it in HBAC evaluation. > > > > > > > > I still need to develop a part of SSSD receiving URI-aware requests. It > > > > will either be an enhancement of Infopipe or I will use PAM responder > > > > (any suggestions?). > > > > > > > > I wanted to kindly ask you for review and your opinions on the patches > > > > and generally on my approach. This would be my first contribution to > > > > FreeIPA and SSSD so there might be bugs. What do you think? > > > > > > > > Btw, is there some better place to share patches than a pasting tool? > > > > Maybe some form of pull request? > > > > > > > > Thanks for your opinions! > > > > > > > > [1] > > > > https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa > > > > [2] > > > > http://pastebin.com/rsHzXeAR > > > > [3] > > > > http://pastebin.com/atcZMuP1 > > > > > > > > > > Hi Lukas, could please post your patches here using git-format-patch or > > > even better provide a public git tree with them applied ? > > > (Any place github, fedorapeople, your own server, etc. is fine) > > > > > > > > > First a question, what service can actually use this scheme and how ? > > > there is no URL field in PAM. > > > > When Lukas started the work, we IIRC concluded that PAM is not an > > appropriate interface and we should probably expose some DBUS methods > > for access control. We haven't really discussed any details since then. > > This only shifts the question, what service would use this interface ? > note I am not opposed to it, but would like to understand how we are > going to test that it actually works and is useful. I thought it was going to be an Apache module, much like Jan's mod_authnz_pam, so maybe something like mod_authnz_hbac. From martin at stefany.eu Sat Feb 27 20:19:26 2016 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Sat, 27 Feb 2016 21:19:26 +0100 Subject: [Freeipa-devel] [PATCH 0001] Add new parameter --ssh-update to ipa-client-install In-Reply-To: <56CF0353.5060705@redhat.com> References: <1456175624.5411.4.camel@stefany.eu> <56CF0060.3090202@redhat.com> <56CF0353.5060705@redhat.com> Message-ID: <1456604366.2844.13.camel@stefany.eu> Hi, I did as Jan suggested, everything is now a new command 'ipa-sshupdate', (so it's based on Jan's 'ipa-certupdate', yeah, a bit of copy-paste), rest is based on ipa-client-install's code. I'm not sure if this is correct, but you might want to change ipa-client-install to just 'import ipaclient.ipa_sshupdate' for ssh update, or not - I'm not sure how this is compatible with 'code deduplication', 're-usage', etc. Another open point from my side is PEP8 compliance, I've ran the new code through pep8 utility with defaults and it's 'OK'. But so is code in my employer's project and they look slightly 'different', mainly for brackets, strings, etc. Please, have a look to that, too, I'm happy for any guidance. Martin On ?t, 2016-02-25 at 14:36 +0100, Jan Cholasta wrote: > Hi, > > On 25.2.2016 14:23, Martin Basti wrote: > > > > > > > > On 22.02.2016 22:13, Martin ?tefany wrote: > > > > > > Hi, > > > > > > please, review the attached patch which adds --ssh-update to ipa- > > > client- > > > install. > > > > > > Ticket:https://fedorahosted.org/freeipa/ticket/2655 > > Hello, > > thank you for your patch. > > Please attach a patch as a file next time. > > > > I have doubts that this should be part of ipa-client-install, this > > needs > > a broader discussion. > +1, I think it should be a separate command (ignore my earlier? > suggestion from Trac to incorporate this into ipa-client-install, I > was? > young and stupid). > > See client/ipa-certupdate and ipaclient/ipa_certupdate.py for an > example? > of how such a command should be implemented. > > > > > > > Code comments inline: > > > > > > > > > --- > > > Martin > > > > > > > > > > > From 4974a57f48a0cd48b83724297ae2af572bc530eb Mon Sep 17 > > > > 00:00:00 2001 > > > From: Martin Stefany > > > Date: Mon, 22 Feb 2016 20:58:13 +0000 > > > Subject: [PATCH] Add new parameter --ssh-update to ipa-client- > > > install > > > > > > Add a new parameter '--ssh-update' which can be used later after > > > freeipa > > > client is installed to update SSH hostkeys and SSHFP DNS records > > > for > > > host. > > > > > > https://fedorahosted.org/freeipa/ticket/2655 > > > --- > > > ? ipa-client/ipa-install/ipa-client-install | 102 > > > +++++++++++++++++++++++++++++- > > > ? 1 file changed, 99 insertions(+), 3 deletions(-) > > > > > > diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa- > > > client/ipa- > > > install/ipa-client-install > > > index > > > 789ff591591673744ee3b922e5c0181233ad553c..97adfb6b449fb441bddada89 > > > a3b151 > > > 33e398ca50 100755 > > > --- a/ipa-client/ipa-install/ipa-client-install > > > +++ b/ipa-client/ipa-install/ipa-client-install > > > @@ -71,6 +71,7 @@ CLIENT_INSTALL_ERROR = 1 > > > ? CLIENT_NOT_CONFIGURED = 2 > > > ? CLIENT_ALREADY_CONFIGURED = 3 > > > ? CLIENT_UNINSTALL_ERROR = 4 # error after restoring files/state > > > +CLIENT_SSHUPDATE_ERROR = 5 # error during update of SSH public > > > keys > > > > > > ? def parse_options(): > > > ??????def validate_ca_cert_file_option(option, opt, value, > > > parser): > > > @@ -215,6 +216,12 @@ def parse_options(): > > > ????????????????????????????????????????????"be run with -- > > > unattended > > > option") > > > ??????parser.add_option_group(uninstall_group) > > > > > > +????sshupdate_group = OptionGroup(parser, "SSH key update > > > options") > > > +????sshupdate_group.add_option("--ssh-update", dest="ssh_update", > > > +??????????????????????action="store_true", default=False, > > > +??????????????????????help="update local host's SSH public keys > > > in host > > > entry and DNS.") > > > +????parser.add_option_group(sshupdate_group) > > > + > > > ??????options, args = parser.parse_args() > > > ??????safe_opts = parser.get_safe_opts(options) > > > > > > @@ -840,6 +847,92 @@ def uninstall(options, env): > > > > > > ??????return rv > > > > > > +def sshupdate(options, env): > > > +????if not is_ipa_client_installed(): > > > +????????root_logger.error("IPA client is not configured on this > > > system.") > > > +????????return CLIENT_NOT_CONFIGURED > > > + > > > +????api.bootstrap(context='cli_installer', debug=options.debug) > > > +????api.finalize() > > > +????if 'config_loaded' not in api.env: > > > +????????root_logger.error("Failed to initialize IPA API.") > > > +????????return CLIENT_SSHUPDATE_ERROR > > > + > > > +????# Now, let's try to connect to the server's RPC interface > > > +????connected = False > > > +????try: > > > +????????api.Backend.rpcclient.connect() > > > +????????connected = True > > > +????????root_logger.debug("Try RPC connection") > > > +????????api.Backend.rpcclient.forward('ping') > > > +????except errors.KerberosError as e: > > > +????????if connected: > > > +????????????api.Backend.rpcclient.disconnect() > > > +????????root_logger.info( > > > +????????????"Cannot connect to the server due to Kerberos error: > > > %s. " > > > +????????????"Trying with delegate=True", e) > > > +????????try: > > > +????????????api.Backend.rpcclient.connect(delegate=True) > > > +????????????root_logger.debug("Try RPC connection") > > > +????????????api.Backend.rpcclient.forward('ping') > > > + > > > +????????????root_logger.info("Connection with delegate=True > > > successful") > > > + > > > +????????????# The remote server is not capable of Kerberos > > > S4U2Proxy > > > +????????????# delegation. This features is implemented in IPA > > > server > > > +????????????# version 2.2 and higher > > > +????????????root_logger.warning( > > > +????????????????"Target IPA server has a lower version than the > > > enrolled " > > > +????????????????"client") > > > +????????????root_logger.warning( > > > +????????????????"Some capabilities including the ipa command > > > capability > > > " > > > +????????????????"may not be available") > > > +????????except errors.PublicError as e2: > > > +????????????root_logger.warning( > > > +????????????????"Second connect with delegate=True also failed: > > > %s", > > > e2) > > > +????????????root_logger.error( > > > +????????????????"Cannot connect to the IPA server RPC interface: > > > %s", > > > e2) > > > +????????????return CLIENT_SSHUPDATE_ERROR > > > +????except errors.PublicError as e: > > > +????????root_logger.error( > > > +????????????"Cannot connect to the server due to generic error: > > > %s", e) > > > +????????return CLIENT_SSHUPDATE_ERROR > > I think you should be kinited with client keytab, client is allowed > > to > > modify its SSHpublic keys in ldap. I'd only require to be root to > > execute it. > > > > kinit -kt /etc/krb5.keytab host/`hostname` > > ipa host-mod `hostname` --sshpubkey="something" > > > > Also this rpcconnection looks to me too much complicated, I think it > > should be just simple rpcconnect > > > > > > > > + > > > +????# We need to pull IPA server address from default.conf > > > +????try: > > > +????????parser = RawConfigParser() > > > +????????parser.read(paths.IPA_DEFAULT_CONF) > > > +????????cli_realm = parser.get('global', 'realm') > > > +????????hostname = parser.get('global', 'host') > > > +????# TODO: consult with review team > > > +????# except ConfigParser.NoSectionError as e: > > > +????#?????pass > > > +????# except ConfigParser.ParsingError as e: > > > +????#?????pass > > > +????finally: > > > +????????pass > > You can raise error there. > > > > > > > > + > > > +????host_principal = 'host/%s@%s' % (hostname, cli_realm) > > > +????# Obtain the TGT. We do it with the temporary krb5.conf, so > > > that > > > +????# only the KDC we're installing under is contacted. > > > +????# Other KDCs might not have replicated the principal yet. > > > +????# Once we have the TGT, it's usable on any server. > > I don't think that temporary krb5.conf should be used here > > > > > > +????try: > > > +????????ipautil.kinit_keytab(host_principal, paths.KRB5_KEYTAB, > > > +?????????????????????????????CCACHE_FILE, > > > +?????????????????????????????# config=krb_name, > > > +?????????????????????????????attempts=options.kinit_attempts) > > > +????????env['KRB5CCNAME'] = os.environ['KRB5CCNAME'] = > > > CCACHE_FILE > > > +????except Krb5Error as e: > > > +????????print_port_conf_info() > > > +????????root_logger.error("Failed to obtain host TGT: %s" % e) > > > +????????# failure to get ticket makes it impossible to login and > > > bind > > > +????????# from sssd to LDAP, abort installation and rollback > > > changes > > > +????????return CLIENT_INSTALL_ERROR > > This is not install error. > > > > > > > > + > > > +????# passing server parameter seems unneccessary, thus passing > > > only "" > > > +????update_ssh_keys("", hostname, > > > services.knownservices.sshd.get_config_dir(), > > > options.create_sshfp) > > > + > > > ? def configure_ipa_conf(fstore, cli_basedn, cli_realm, > > > cli_domain, > > > cli_server, hostname): > > > ??????ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA > > > Installer") > > > ??????ipaconf.setOptionAssignment(" =") @@ -2797,7 +2890,7 @@ def > > > install(options, env, fstore, > > > statestore):??????????????connected = True > > > ?????????????root_logger.debug("Try RPC connection") > > > ??????????????api.Backend.rpcclient.forward('ping') > > > -????????except errors.KerberosError, e: > > > +????????except errors.KerberosError as e: > > Please don't modify code that already exists and it is not related > > to > > this change > > > > > > ??????????????if connected: > > > ??????????????????api.Backend.rpcclient.disconnect() > > > ??????????????root_logger.info( > > > @@ -2820,13 +2913,13 @@ def install(options, env, fstore, > > > statestore): > > > ??????????????????root_logger.warning( > > > ??????????????????????"Some capabilities including the ipa command > > > capability " > > > ??????????????????????"may not be available") > > > -????????????except errors.PublicError, e2: > > > +????????????except errors.PublicError as e2: > > Remove this from patch too > > > > > > ??????????????????root_logger.warning( > > > ??????????????????????"Second connect with delegate=True also > > > failed: > > > %s", e2) > > > ??????????????????root_logger.error( > > > ??????????????????????"Cannot connect to the IPA server RPC > > > interface: > > > %s", e2) > > > ??????????????????return CLIENT_INSTALL_ERROR > > > -????????except errors.PublicError, e: > > > +????????except errors.PublicError as e: > > and this too > > > > > > ??????????????root_logger.error( > > > ??????????????????"Cannot connect to the server due to generic > > > error: > > > %s", e) > > > ??????????????return CLIENT_INSTALL_ERROR > > > @@ -3088,6 +3181,9 @@ def main(): > > > ??????if options.uninstall: > > > ??????????return uninstall(options, env) > > > > > > +????if options.ssh_update: > > > +????????return sshupdate(options, env) > > > + > > > ??????if is_ipa_client_installed(on_master=options.on_master): > > > ??????????root_logger.error("IPA client is already configured on > > > this > > > system.") > > > ??????????root_logger.info( > > > -- > > > 1.8.3.1 > > > > > > > > Martin^2 > > > > > Honza > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mstefany-0001-2-add-client-SSH-public-key-update-tool-ipa-sshupdate.patch Type: text/x-patch Size: 11369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jcholast at redhat.com Mon Feb 29 06:19:15 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Feb 2016 07:19:15 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <20160226203840.GB16465@mail.corp.redhat.com> References: <20160222104811.GN4492@redhat.com> <56CB3F82.1070408@redhat.com> <20160222171455.GT4492@redhat.com> <56CB59E3.3010709@redhat.com> <56CFF106.1080305@redhat.com> <56D038F4.5040909@redhat.com> <20160226203840.GB16465@mail.corp.redhat.com> Message-ID: <56D3E2E3.2080207@redhat.com> On 26.2.2016 21:38, Lukas Slebodnik wrote: > On (26/02/16 12:37), Tomas Babej wrote: >> >> >> On 02/26/2016 07:30 AM, Jan Cholasta wrote: >>> On 22.2.2016 19:56, Tomas Babej wrote: >>>> >>>> >>>> On 02/22/2016 06:14 PM, Alexander Bokovoy wrote: >>>>> On Mon, 22 Feb 2016, Tomas Babej wrote: >>>>>> >>>>>> >>>>>> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: >>>>>>> Hi, >>>>>>> >>>>>>> attached patch should update compat tree configuration if it exist to >>>>>>> follow slapi-nis 0.55 which has support for external members of IPA >>>>>>> groups. >>>>>>> >>>>>>> However, the real work is done in SSSD. These patches are not >>>>>>> upstreamed >>>>>>> yet. We'll need to bump SSSD dependency in future once they come to >>>>>>> distros. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> This looks good. >>>>>> >>>>>> However, the new update file needs to be added to Makefile.am. >>>>>> Additionally, patch adds a whitespace error. >>>>> Updated patch is attached. >>>>> >>>> >>>> ACK. >>>> >>>> This should not be pushed until the dependency for SSSD can be bumped. >>> >>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-d872920f74 >>> >> >> Attaching the required spec change. >> >> Tomas > >>From dae8b8fd0b23bf25ccf75b275deaa5c599faa27b Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Fri, 26 Feb 2016 12:35:09 +0100 >> Subject: [PATCH] spec: Bump required sssd version to 1.13.3-5 >> >> Required as part of: https://fedorahosted.org/freeipa/ticket/4403 > ^^^^^^^^^^^^^ > There isn't mentioned sssd related ticket in slapi-nis bug > It would be good to add also sssd related ticket to commit message > https://fedorahosted.org/sssd/ticket/2522 +1, that's in IPA. -- Jan Cholasta From ftweedal at redhat.com Mon Feb 29 06:59:15 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 29 Feb 2016 16:59:15 +1000 Subject: [Freeipa-devel] Design review request: RFC 2818 certificate compliance Message-ID: <20160229065915.GC21191@dhcp-40-8.bne.redhat.com> Hi all (especially those interested in certificates), Please provide early review of my design for RFC 2818 compliance which will address the following tickets: - #4970 Server certificate profile should always include a Subject Alternate name for the host - #5706 [RFE] Support SAN-only certificates http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance The design is a WIP and there is no code for it yet. Looking for feedback and (hopefully) validation of the approach before committing cycles to implementing new profile components in Dogtag. Thanks in advance, Fraser From mkosek at redhat.com Mon Feb 29 07:03:42 2016 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 29 Feb 2016 08:03:42 +0100 Subject: [Freeipa-devel] [PATCH] 0001 Adding URL to HBAC rule In-Reply-To: <56D07184.5020405@redhat.com> References: <56D0425B.4040503@redhat.com> <56D0454E.1050207@redhat.com> <56D07184.5020405@redhat.com> Message-ID: <56D3ED4E.70008@redhat.com> On 02/26/2016 04:38 PM, Luk?? Hellebrandt wrote: > On 02/26/2016 01:30 PM, Martin Kosek wrote: >> Greetings, welcome! >> >> On 02/26/2016 01:17 PM, Luk?? Hellebrandt wrote: >> ... >>> Btw, is there some better place to share patches than a pasting tool? >>> Maybe some form of pull request? >> >> There is :-) Please see advise here: >> >> http://www.freeipa.org/page/Contribute/Code#Submit_a_patch >> >> It has more information on top of submitting patches. For example, I think it >> would actually make sense to start with a design page where you would describe >> the use cases, design, APIs, etc: >> >> http://www.freeipa.org/page/Contribute/Code#Prepare >> >> Martin >> > > Should I send it as an attachment? Right. > Ok, sending, but do not apply it yet > (even if you don't find bugs), I just need some feedback - not > everything is done yet. The patch looks OK, but there is not much in the patch anyway, yet. But as I written above I would suggest starting with a design document you share with the other developers, so that you can be given an advise and feedback regarding the approach and overall design. From jcholast at redhat.com Mon Feb 29 07:12:28 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Feb 2016 08:12:28 +0100 Subject: [Freeipa-devel] [PATCHES] 0772-0774 Python3 fixes in for client installation In-Reply-To: <56D079F2.2020501@redhat.com> References: <56CAF30F.7010306@redhat.com> <56D079F2.2020501@redhat.com> Message-ID: <56D3EF5C.1090008@redhat.com> Hi, On 26.2.2016 17:14, Petr Viktorin wrote: > On 02/22/2016 12:37 PM, Petr Viktorin wrote: >> Hello, >> These fixes are needed for the "happy path" of ipa-client-install >> --server on Python 3. > > Hello, > Could someone please look at these patches? Patch 0772: 1) Instead of decoding when the type is bytes in get_ipa_basedn(), read attribute values from 'entry.raw' rather than 'entry' and decode always. 2) get_ipa_basedn() is used only in ipadiscovery, perhaps we should move it there? Patch 0773: ACK, but the patch does not apply on ipa-4-3. Patch 0774: ACK. Honza -- Jan Cholasta From jcholast at redhat.com Mon Feb 29 07:29:16 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 29 Feb 2016 08:29:16 +0100 Subject: [Freeipa-devel] [PATCH] 0771 Package python3-ipaclient In-Reply-To: <56CAF28F.6080308@redhat.com> References: <56CAF28F.6080308@redhat.com> Message-ID: <56D3F34C.2000708@redhat.com> Hi, On 22.2.2016 12:35, Petr Viktorin wrote: > Hello, > This will make a python3-ipaclient RPM. Thanks, ACK. Added a missing newline, rebased and pushed to: master: ec95ffaa529b3de61b12c85ce01e4b2f1d0c65b3 ipa-4-3: f714cb46923b23181daf20d72e34202ea0aacfd8 Honza -- Jan Cholasta From lhellebr at redhat.com Mon Feb 29 10:40:45 2016 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Mon, 29 Feb 2016 11:40:45 +0100 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback In-Reply-To: <20160228103935.GG20147@hendrix.redhat.com> References: <56D0425B.4040503@redhat.com> <1456502337.6599.393.camel@redhat.com> <20160226161748.GC20147@hendrix.redhat.com> <1456504406.6599.403.camel@redhat.com> <20160228103935.GG20147@hendrix.redhat.com> Message-ID: <56D4202D.8040709@redhat.com> On 02/28/2016 11:39 AM, Jakub Hrozek wrote: > On Fri, Feb 26, 2016 at 11:33:26AM -0500, Simo Sorce wrote: >> On Fri, 2016-02-26 at 17:17 +0100, Jakub Hrozek wrote: >>> On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote: >>>> On Fri, 2016-02-26 at 13:17 +0100, Luk?? Hellebrandt wrote: >>>>> Hi, FreeIPA and SSSD communities! >>>>> >>>>> I am working on adding URI to HBAC as my thesis [1]. The goal is to >>>>> control access not only based on (user, host, service), but on (user, >>>>> host, service, resource's URI). >>>>> >>>>> I created a patch for FreeIPA [2] so it is capable of storing URI as >>>>> part of HBAC rule. I created a patch for SSSD [3] so it is able to get >>>>> this URI from FreeIPA and use it in HBAC evaluation. >>>>> >>>>> I still need to develop a part of SSSD receiving URI-aware requests. It >>>>> will either be an enhancement of Infopipe or I will use PAM responder >>>>> (any suggestions?). >>>>> >>>>> I wanted to kindly ask you for review and your opinions on the patches >>>>> and generally on my approach. This would be my first contribution to >>>>> FreeIPA and SSSD so there might be bugs. What do you think? >>>>> >>>>> Btw, is there some better place to share patches than a pasting tool? >>>>> Maybe some form of pull request? >>>>> >>>>> Thanks for your opinions! >>>>> >>>>> [1] >>>>> https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa >>>>> [2] >>>>> http://pastebin.com/rsHzXeAR >>>>> [3] >>>>> http://pastebin.com/atcZMuP1 >>>>> >>>> >>>> Hi Lukas, could please post your patches here using git-format-patch or >>>> even better provide a public git tree with them applied ? >>>> (Any place github, fedorapeople, your own server, etc. is fine) >>>> >>>> >>>> First a question, what service can actually use this scheme and how ? >>>> there is no URL field in PAM. >>> >>> When Lukas started the work, we IIRC concluded that PAM is not an >>> appropriate interface and we should probably expose some DBUS methods >>> for access control. We haven't really discussed any details since then. >> >> This only shifts the question, what service would use this interface ? >> note I am not opposed to it, but would like to understand how we are >> going to test that it actually works and is useful. > > I thought it was going to be an Apache module, much like Jan's > mod_authnz_pam, so maybe something like mod_authnz_hbac. > Exactly. It could have other uses, but an example I will be using will be an Apache module. And really, the only functional difference between mod_authnz_pam and the new module would be that the new module will be URI-aware (so it will use either PAM or Infopipe to communicate with SSSD and among other things, send URI, too) and it will probably be authorization-only. I am still not sure about the Infopipe vs PAM thing. I am trying to do normal authorization as the PAM one, just add some URI parameter to the request. I am still not sure whether it is a good idea to use a PAM variable (URI is not a standard field but maybe PAM supports other than standard variables?) or whether to add more functionality to Infopipe and do not use PAM at all. That is probably my most important question for now. -- Lukas Hellebrandt Associate Quality Engineer lhellebr at redhat.com From lhellebr at redhat.com Mon Feb 29 11:05:10 2016 From: lhellebr at redhat.com (=?UTF-8?Q?Luk=c3=a1=c5=a1_Hellebrandt?=) Date: Mon, 29 Feb 2016 12:05:10 +0100 Subject: [Freeipa-devel] URI in HBAC rules - patch - request for feedback In-Reply-To: <1456502337.6599.393.camel@redhat.com> References: <56D0425B.4040503@redhat.com> <1456502337.6599.393.camel@redhat.com> Message-ID: <56D425E6.7080605@redhat.com> > On the patches: > > [2] you define a new attribute Url which is fine, but the actual > attribute is not ok in several way. > > - You assigned an OID from a hole in the IPAv2 Attibutes space, it > should be an assigned ID from the IPAv3 attribute space instead > > - You do not namespace the attribute, it should at least be ipaUrl > I'll look into that > - you are using case Exact matching, is this intentional? Are the URIs > in there case sensitive strings ? > > - there is an available attribute called labeledURI (with alias > labeledurl) in the standard schema (however I notice it also has > caseExactMatch) that has basically the same definition of your Url > attribute, why not use that one ? > Actually, URI is case sensitive: http://stackoverflow.com/a/26196170/1978950 I'll check labeledURI you mentioned. > [3] If I read the patch correctly failing to find a Url is a fatal > condition, this is not ok as it would fail to operate with older servers > that do not have a url on the rules. > I believe it is not a fatal condition. If you mean line 100, it is for the case of some failure of the call. If the call succeeds and there is no URI, then line 105 happens and the URI is considered empty. If you are talking about the evaluation in line 21, this will be changed, the exact string comparison is there just for testing. > It is not clear to me what happen on an older client if URL is used but > not the service? Or is service always enforced ? (It is not clear to me > that it is). > I'm not sure I understand. If there is no service, the rule must necessarily fail to allow the access before even evaluating URI, or at least I think so. URI will only reduce the set of HBAC rules matching certain request. -- Lukas Hellebrandt Associate Quality Engineer lhellebr at redhat.com From mrniranjan at fedoraproject.org Mon Feb 29 11:26:31 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Mon, 29 Feb 2016 16:56:31 +0530 Subject: [Freeipa-devel] [python-pytest-multihost] Request to add support to specify username/password for each host In-Reply-To: <20160226101434.GA18928@mniranja.pnq.redhat.com> References: <20160226101434.GA18928@mniranja.pnq.redhat.com> Message-ID: <20160229112631.GA13353@mniranja.pnq.redhat.com> Niranjan wrote: > Greetings, > > Request to review the patch for > https://fedorahosted.org/python-pytest-multihost/ticket/5 > > Regards > Niranjan > > From 28cd560f58b96817306a6eae6976e26166a9351a Mon Sep 17 00:00:00 2001 > From: Niranjan MR > Date: Fri, 26 Feb 2016 15:30:25 +0530 > Subject: [PATCH] Add support to specify usernames/password per host > > https://fedorahosted.org/python-pytest-multihost/ticket/5 > > Signed-off-by: Niranjan MR > --- > pytest_multihost/host.py | 12 +++++++++--- > pytest_multihost/transport.py | 12 ++++++++++-- > 2 files changed, 19 insertions(+), 5 deletions(-) > > diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py > index f3346f6..7885722 100644 > --- a/pytest_multihost/host.py > +++ b/pytest_multihost/host.py > @@ -26,10 +26,13 @@ class BaseHost(object): > """ > transport_class = None > > - def __init__(self, domain, hostname, role, ip=None, > - external_hostname=None): > + def __init__(self, domain, hostname, role, > + username=None, password=None, > + ip=None, external_hostname=None): > self.domain = domain > self.role = str(role) > + self.username = username > + self.password = password > > shortname, dot, ext_domain = hostname.partition('.') > self.shortname = shortname > @@ -109,9 +112,12 @@ class BaseHost(object): > ip = dct.pop('ip', None) > external_hostname = dct.pop('external_hostname', None) > > + username = dct.pop('username', None) > + password = dct.pop('password', None) > + > check_config_dict_empty(dct, 'host %s' % hostname) > > - return cls(domain, hostname, role, ip, external_hostname) > + return cls(domain, hostname, role, username, password, ip, external_hostname) > > def to_dict(self): > """Export info about this Host to a dict""" > diff --git a/pytest_multihost/transport.py b/pytest_multihost/transport.py > index eda71cd..e893e48 100644 > --- a/pytest_multihost/transport.py > +++ b/pytest_multihost/transport.py > @@ -177,11 +177,19 @@ class ParamikoTransport(Transport): > host.ssh_port)) > self._transport = transport = paramiko.Transport(sock) > transport.connect(hostkey=host.host_key) > + if host.password: > + self.log.debug('Authenticating with password set in host section') > + transport.auth_password(username=host.username, > + password=host.password) > if host.ssh_key_filename: > - self.log.debug('Authenticating with private RSA key') > filename = os.path.expanduser(host.ssh_key_filename) > key = paramiko.RSAKey.from_private_key_file(filename) > - transport.auth_publickey(username=host.ssh_username, key=key) > + if host.username: > + self.log.debug('Authenticating with private RSA key using user %s' % ( host.username)) > + transport.auth_publickey(username=host.username, key=key) > + else: > + self.log.debug('Authenticating with private RSA key') > + transport.auth_publickey(username=host.ssh_username, key=key) > elif host.ssh_password: > self.log.debug('Authenticating with password') > transport.auth_password(username='root', > -- > 1.9.3 > Greetings, I have modified the subject to include python-pytest-multihost. The attached patch adds support to include username/password or just username with ssh_key_filename under each host in a domain. This helps specifically in cases where we have AD (windows with openssh/cygwin installed) and we need to connect using username "Administrator". Also note that that this patch only works in cases where paramiko is used. This patch doesn't work in cases where openssh is used. > -- > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 311 bytes Desc: not available URL: From tbabej at redhat.com Mon Feb 29 12:07:14 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Feb 2016 13:07:14 +0100 Subject: [Freeipa-devel] [PATCH 200] slapi-nis: update configuration to allow external members In-Reply-To: <56D3E2E3.2080207@redhat.com> References: <20160222104811.GN4492@redhat.com> <56CB3F82.1070408@redhat.com> <20160222171455.GT4492@redhat.com> <56CB59E3.3010709@redhat.com> <56CFF106.1080305@redhat.com> <56D038F4.5040909@redhat.com> <20160226203840.GB16465@mail.corp.redhat.com> <56D3E2E3.2080207@redhat.com> Message-ID: <56D43472.9070502@redhat.com> On 02/29/2016 07:19 AM, Jan Cholasta wrote: > On 26.2.2016 21:38, Lukas Slebodnik wrote: >> On (26/02/16 12:37), Tomas Babej wrote: >>> >>> >>> On 02/26/2016 07:30 AM, Jan Cholasta wrote: >>>> On 22.2.2016 19:56, Tomas Babej wrote: >>>>> >>>>> >>>>> On 02/22/2016 06:14 PM, Alexander Bokovoy wrote: >>>>>> On Mon, 22 Feb 2016, Tomas Babej wrote: >>>>>>> >>>>>>> >>>>>>> On 02/22/2016 11:48 AM, Alexander Bokovoy wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> attached patch should update compat tree configuration if it >>>>>>>> exist to >>>>>>>> follow slapi-nis 0.55 which has support for external members of IPA >>>>>>>> groups. >>>>>>>> >>>>>>>> However, the real work is done in SSSD. These patches are not >>>>>>>> upstreamed >>>>>>>> yet. We'll need to bump SSSD dependency in future once they come to >>>>>>>> distros. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> This looks good. >>>>>>> >>>>>>> However, the new update file needs to be added to Makefile.am. >>>>>>> Additionally, patch adds a whitespace error. >>>>>> Updated patch is attached. >>>>>> >>>>> >>>>> ACK. >>>>> >>>>> This should not be pushed until the dependency for SSSD can be bumped. >>>> >>>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-d872920f74 >>>> >>> >>> Attaching the required spec change. >>> >>> Tomas >> >>> From dae8b8fd0b23bf25ccf75b275deaa5c599faa27b Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Fri, 26 Feb 2016 12:35:09 +0100 >>> Subject: [PATCH] spec: Bump required sssd version to 1.13.3-5 >>> >>> Required as part of: https://fedorahosted.org/freeipa/ticket/4403 >> ^^^^^^^^^^^^^ >> There isn't mentioned sssd related ticket in slapi-nis bug >> It would be good to add also sssd related ticket to commit message >> https://fedorahosted.org/sssd/ticket/2522 > > +1, that's in IPA. > Attaching patch with updated commit message. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0402-2-spec-Bump-required-sssd-version-to-1.13.3-5.patch Type: text/x-patch Size: 824 bytes Desc: not available URL: From ofayans at redhat.com Mon Feb 29 12:16:07 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Mon, 29 Feb 2016 13:16:07 +0100 Subject: [Freeipa-devel] [PATCH 016 - 017] First part of the replica promotion tests + testplan In-Reply-To: <5675E08C.7030109@redhat.com> References: <5640A90B.6030906@redhat.com> <564CA530.3060006@redhat.com> <5655D741.4010402@redhat.com> <56560124.4060904@redhat.com> <5656CB3B.8010000@redhat.com> <5656D5EE.7010208@redhat.com> <565862E6.4020100@redhat.com> <56586807.9080805@redhat.com> <565870D6.40908@redhat.com> <56587616.5030609@redhat.com> <565DB7D3.5040500@redhat.com> <565F0BDD.8080206@redhat.com> <565F17EE.3020701@redhat.com> <5666DC18.2040906@redhat.com> <56675E31.3050203@redhat.com> <5667F49B.5020709@redhat.com> <5667FEFB.6090904@redhat.com> <56680C2E.7060805@redhat.com> <56680DDD.2000106@redhat.com> <566FDD80.7030805@redhat.com> <56717785.4020304@redhat.com> <567195B9.9070104@redhat.com> <56727AA7.2030809@redhat.com> <5675E08C.7030109@redhat.com> Message-ID: <56D43687.10502@redhat.com> Hi all, Finally the tests pass. The patch 0024 applies on top of patch 0022 (please, consider reviewing it also). Besides, the whole functionality depends on Martin's patch N 0421 All patches pass pylint. On 12/19/2015 11:56 PM, Martin Basti wrote: > > > On 17.12.2015 10:04, Oleg Fayans wrote: >> Hi Martin, >> >> I am sorry, in my previous email I attached the old version of patch >> 0016. The correct on is attached. >> >> On 12/16/2015 05:47 PM, Martin Basti wrote: >>> >>> On 16.12.2015 15:39, Martin Basti wrote: >>>> >>>> On 15.12.2015 10:29, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> The updated patches are attached. Patch 0017 includes all changes from >>>>> patch 0018, so, if you approve this one, there would be no need to >>>>> continue with the review of 0018. This one contains all changes >>>>> related >>>>> to you remarks from 0018 review. Please see my explanation on the >>>>> stdout+stderr part in the thread from patch 0018. >>>>> With these two patches applied one of the tests fails due this bug: >>>>> https://fedorahosted.org/freeipa/ticket/5550 >>>>> >>>>> On 12/09/2015 12:17 PM, Martin Basti wrote: >>>>>> On 09.12.2015 12:10, Martin Basti wrote: >>>>>>> On 09.12.2015 11:14, Oleg Fayans wrote: >>>>>>>> Hi Martin >>>>>>>> >>>>>>>> On 12/09/2015 10:30 AM, Martin Basti wrote: >>>>>>>>> On 08.12.2015 23:48, Oleg Fayans wrote: >>>>>>>>>> Substituted a hardcoded suffix name with a constant >>>>>>>>>> DOMAIN_SUFFIX_NAME >>>>>>>>>> >>>>>>>>>> On 12/08/2015 02:33 PM, Oleg Fayans wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The patches are rebased against the current master. >>>>>>>>>>> >>>>>>>>>>> On 12/02/2015 05:10 PM, Martin Basti wrote: >>>>>>>>>>>> On 02.12.2015 16:18, Oleg Fayans wrote: >>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/01/2015 04:08 PM, Martin Basti wrote: >>>>>>>>>>>>>> On 27.11.2015 16:26, Oleg Fayans wrote: >>>>>>>>>>>>>>> And patch N 16 passes lint too: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/27/2015 04:03 PM, Oleg Fayans wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/27/2015 03:26 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>> On 27.11.2015 15:04, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> All your suggestions were taken into account. Both >>>>>>>>>>>>>>>>>> patches are >>>>>>>>>>>>>>>>>> updated. Thank you for your help! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/26/2015 10:50 AM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>> On 26.11.2015 10:04, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>> Hi Martin, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I agree to all your points but one. please, see my >>>>>>>>>>>>>>>>>>>> comment >>>>>>>>>>>>>>>>>>>> below >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 11/25/2015 07:42 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 0) Note >>>>>>>>>>>>>>>>>>>>> Please be aware of >>>>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5469 >>>>>>>>>>>>>>>>>>>>> during >>>>>>>>>>>>>>>>>>>>> KRA testing >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>>>>> Please do not use MIN and MAX_DOMAIN_LEVEL constants, >>>>>>>>>>>>>>>>>>>>> this may >>>>>>>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>>>>>>> over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for >>>>>>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>>>>>> level 0 >>>>>>>>>>>>>>>>>>>>> and 1 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>>>>> Why uninstall KRA then server, is not enough just >>>>>>>>>>>>>>>>>>>>> uninstall >>>>>>>>>>>>>>>>>>>>> server >>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>> covers KRA uninstall? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> + def teardown_method(self, method): >>>>>>>>>>>>>>>>>>>>> + for host in self.replicas: >>>>>>>>>>>>>>>>>>>>> + host.run_command(self.kra_uninstall, >>>>>>>>>>>>>>>>>>>>> raiseonerr=False) >>>>>>>>>>>>>>>>>>>>> + tasks.uninstall_master(host) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>>>>> Can be this function more generic? It should allow >>>>>>>>>>>>>>>>>>>>> specify >>>>>>>>>>>>>>>>>>>>> host >>>>>>>>>>>>>>>>>>>>> where >>>>>>>>>>>>>>>>>>>>> KRA should be installed not just master >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> + def test_kra_install_master(self): >>>>>>>>>>>>>>>>>>>>> + self.master.run_command(self.kra_install) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> TestLevel0(Dummy): >>>>>>>>>>>>>>>>>>>>> Can be the test name more specific, something like >>>>>>>>>>>>>>>>>>>>> TestReplicaPromotionLevel0 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 5) >>>>>>>>>>>>>>>>>>>>> please remove this, the patch is on review and it >>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>> pushed >>>>>>>>>>>>>>>>>>>>> sooner >>>>>>>>>>>>>>>>>>>>> than tests >>>>>>>>>>>>>>>>>>>>> + @pytest.mark.xfail # Ticket N 5455 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> and as I mentioned in ticket #5455, I cannot reproduce >>>>>>>>>>>>>>>>>>>>> it with >>>>>>>>>>>>>>>>>>>>> ipa-kra-install, so please provide steps to >>>>>>>>>>>>>>>>>>>>> reproduce if >>>>>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>> insist >>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>> this still does not work as expected with KRA. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 6) This is completely wrong, it removes everything >>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>> tried to >>>>>>>>>>>>>>>>>>>>> achieve with previous patches with domain level in CI >>>>>>>>>>>>>>>>>>>> Actually, being able to configure domain level per >>>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>>> is WAY >>>>>>>>>>>>>>>>>>>> more >>>>>>>>>>>>>>>>>>>> convenient, than to always have to think which domain >>>>>>>>>>>>>>>>>>>> level is >>>>>>>>>>>>>>>>>>>> appropriate for which particular test during jenkins >>>>>>>>>>>>>>>>>>>> job >>>>>>>>>>>>>>>>>>>> configuration. In fact, I should have thought about it >>>>>>>>>>>>>>>>>>>> from the >>>>>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>>>>> beginning. For example, in test_replica_promotion.py we >>>>>>>>>>>>>>>>>>>> have on >>>>>>>>>>>>>>>>>>>> class, >>>>>>>>>>>>>>>>>>>> which intiates with domain level = 1, while others - >>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>>>>> 0. With config-based approach, we would have to >>>>>>>>>>>>>>>>>>>> implement a >>>>>>>>>>>>>>>>>>>> separate >>>>>>>>>>>>>>>>>>>> step that raises domain level. Overall, I am against >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> approach, >>>>>>>>>>>>>>>>>>>> when you have to remember to set certain domain >>>>>>>>>>>>>>>>>>>> level in >>>>>>>>>>>>>>>>>>>> config >>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>> any particular test. The tests themselves should be >>>>>>>>>>>>>>>>>>>> aware of >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> domain level they need. >>>>>>>>>>>>>>>>>>> I do not say that we should not have something that >>>>>>>>>>>>>>>>>>> overrides >>>>>>>>>>>>>>>>>>> settings >>>>>>>>>>>>>>>>>>> in from config in a particular test case, I say your >>>>>>>>>>>>>>>>>>> patch is >>>>>>>>>>>>>>>>>>> doing it >>>>>>>>>>>>>>>>>>> wrong. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I agree it is useful to have param domain_level in >>>>>>>>>>>>>>>>>>> install_master, >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> intall_topo methods, but is cannot be >>>>>>>>>>>>>>>>>>> MAX_DOMAIN_LEVEL by >>>>>>>>>>>>>>>>>>> default, >>>>>>>>>>>>>>>>>>> because with your current patch the domain_level in >>>>>>>>>>>>>>>>>>> config is >>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>>>>> at all, it will be always MAX_DOMAIN_LEVEL >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For example I want to achieve this goal: >>>>>>>>>>>>>>>>>>> test_vault.py, this test suite can run on domain level1 >>>>>>>>>>>>>>>>>>> and on >>>>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>>>> level0, so with one test we can test 2 domain levels >>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> putting >>>>>>>>>>>>>>>>>>> domain level into config file. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I agree that with extraordinary test like replica >>>>>>>>>>>>>>>>>>> promotion test >>>>>>>>>>>>>>>>>>> is, we >>>>>>>>>>>>>>>>>>> need something that allows override the config file. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As I said bellow, domain_level default value should be >>>>>>>>>>>>>>>>>>> None in >>>>>>>>>>>>>>>>>>> install_master and install_topo plugin. If domain level >>>>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>>> specified >>>>>>>>>>>>>>>>>>> use the specified one, if not (value is None) use the >>>>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>> config file. >>>>>>>>>>>>>>>>>> Agreed :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Martin >>>>>>>>>>>>>>>>>>>>> [PATCH] Enabled setting domain_level per class >>>>>>>>>>>>>>>>>>>>> derived from >>>>>>>>>>>>>>>>>>>>> TestIntegration >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> When I configure domain level 0 in yaml config, how >>>>>>>>>>>>>>>>>>>>> is this >>>>>>>>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>>>>>>>> get into install methods when you removed that code? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - "--domain-level=%i" % >>>>>>>>>>>>>>>>>>>>> host.config.domain_level >>>>>>>>>>>>>>>>>>>>> + "--domain-level=%i" % domain_level >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> You always use MAX_DOMAIN_LEVEL in this case or >>>>>>>>>>>>>>>>>>>>> whatever is >>>>>>>>>>>>>>>>>>>>> specified in >>>>>>>>>>>>>>>>>>>>> domain_level option. >>>>>>>>>>>>>>>>>>>>> I suggest to use domain_level=None, and when it is >>>>>>>>>>>>>>>>>>>>> None use >>>>>>>>>>>>>>>>>>>>> 'host.config.domain_level', if it is not None, use >>>>>>>>>>>>>>>>>>>>> 'domain_level' >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> With this we can specify domain level in config >>>>>>>>>>>>>>>>>>>>> file for >>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>> be used for both domain levels and you can manually >>>>>>>>>>>>>>>>>>>>> specify >>>>>>>>>>>>>>>>>>>>> domain >>>>>>>>>>>>>>>>>>>>> level >>>>>>>>>>>>>>>>>>>>> for test that requires specific domain level. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also this should go away >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> @classmethod >>>>>>>>>>>>>>>>>>>>> def install(cls, mh): >>>>>>>>>>>>>>>>>>>>> + if hasattr(cls, "domain_level") and >>>>>>>>>>>>>>>>>>>>> cls.master: >>>>>>>>>>>>>>>>>>>>> + cls.master.config.domain_level = cls.domain_level >>>>>>>>>>>>>>>>>>>>> if cls.topology is None: >>>>>>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I do not see reason why test should override >>>>>>>>>>>>>>>>>>>>> configuration in >>>>>>>>>>>>>>>>>>>>> config in >>>>>>>>>>>>>>>>>>>>> this case. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Martin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 25.11.2015 16:44, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Here is the updated version of the patch (more >>>>>>>>>>>>>>>>>>>>>> tests + >>>>>>>>>>>>>>>>>>>>>> fixed the >>>>>>>>>>>>>>>>>>>>>> issues of the first one) + patch 0017, that >>>>>>>>>>>>>>>>>>>>>> implements the >>>>>>>>>>>>>>>>>>>>>> necessary >>>>>>>>>>>>>>>>>>>>>> changes in the background code, i. e. patch 16 >>>>>>>>>>>>>>>>>>>>>> does not >>>>>>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>>>>>>> patch 17 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 11/18/2015 05:20 PM, Martin Basti wrote: >>>>>>>>>>>>>>>>>>>>>>> On 09.11.2015 15:09, Oleg Fayans wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Here are first two automated testcases from this >>>>>>>>>>>>>>>>>>>>>>>> (so far >>>>>>>>>>>>>>>>>>>>>>>> incomplete) >>>>>>>>>>>>>>>>>>>>>>>> testplan: >>>>>>>>>>>>>>>>>>>>>>>> http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Testplan review is highly appreciated >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> PATCH 16: NACK >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 1) >>>>>>>>>>>>>>>>>>>>>>> What is the reason to add an unused parameter to >>>>>>>>>>>>>>>>>>>>>>> 'domain_level' to >>>>>>>>>>>>>>>>>>>>>>> install_topo()? >>>>>>>>>>>>>>>>>>>>>>> Also it is good practise to add new option as the >>>>>>>>>>>>>>>>>>>>>>> last >>>>>>>>>>>>>>>>>>>>>>> parameter. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2) >>>>>>>>>>>>>>>>>>>>>>> cab you in both tests specify a domain level with >>>>>>>>>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>>>>>>>>> instead of >>>>>>>>>>>>>>>>>>>>>>> number literal? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 3) >>>>>>>>>>>>>>>>>>>>>>> both test call install_topo with custom domain >>>>>>>>>>>>>>>>>>>>>>> level, >>>>>>>>>>>>>>>>>>>>>>> but it >>>>>>>>>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>>>>> because 1) (did you run the test?) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 4) >>>>>>>>>>>>>>>>>>>>>>> How the test "TestLevel1" is supposed to work? >>>>>>>>>>>>>>>>>>>>>>> Respectively why there is call of install_topo() >>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>> installs >>>>>>>>>>>>>>>>>>>>>>> replica. >>>>>>>>>>>>>>>>>>>>>>> As this test just tests that ipa-replica-prepare is >>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>> working >>>>>>>>>>>>>>>>>>>>>>> anymore, >>>>>>>>>>>>>>>>>>>>>>> is it worth to spend 20 minutes with installing >>>>>>>>>>>>>>>>>>>>>>> replica and >>>>>>>>>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>>>>>>>> just no >>>>>>>>>>>>>>>>>>>>>>> tot use it? IMO to install master in install step is >>>>>>>>>>>>>>>>>>>>>>> enough. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Martin^2 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ./make-lint >>>>>>>>>>>>>>>>> ************* Module ipatests.test_integration.base >>>>>>>>>>>>>>>>> ipatests/test_integration/base.py:66: [E1101(no-member), >>>>>>>>>>>>>>>>> IntegrationTest.install] Class 'IntegrationTest' has no >>>>>>>>>>>>>>>>> 'domain_level' >>>>>>>>>>>>>>>>> member) >>>>>>>>>>>>>>>>> ************* Module >>>>>>>>>>>>>>>>> ipatests.test_integration.test_replica_promotion >>>>>>>>>>>>>>>>> ipatests/test_integration/test_replica_promotion.py:16: >>>>>>>>>>>>>>>>> [E1101(no-member), Dummy.install] Class 'Dummy' has no >>>>>>>>>>>>>>>>> 'domain_level' >>>>>>>>>>>>>>>>> member) >>>>>>>>>>>>>>>>> ipatests/test_integration/test_replica_promotion.py:117: >>>>>>>>>>>>>>>>> [E1101(no-member), >>>>>>>>>>>>>>>>> TestCAInstall.test_ca_install_without_replica_file] >>>>>>>>>>>>>>>>> Module 'ipatests.test_integration.tasks' has no >>>>>>>>>>>>>>>>> 'setup_replica' >>>>>>>>>>>>>>>>> member) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is it so hard to run pylint before patch is posted for >>>>>>>>>>>>>>>>> review? >>>>>>>>>>>>>>>> Sorry, my bad. Fixed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> Why is this change in the patch? >>>>>>>>>>>>>> - # Clean up the test directory >>>>>>>>>>>>>> - host.run_command(['rm', '-rvf', host.config.test_dir]) >>>>>>>>>>>>> Otherwise 2 out of 8 tests fail with IOError at line 78 of >>>>>>>>>>>>> ipatests/test_integration/tasks.py >>>>>>>>>>>>> >>>>>>>>>>>>> I do not understand yet how does this happen, but if you >>>>>>>>>>>>> remove >>>>>>>>>>>>> ipatests folder once, it then fails to be created again. >>>>>>>>>>>>> >>>>>>>>>>>> So this should be in separated patch and investigated properly. >>>>>>>>>>> Agree. Removed >>>>>>>>>>>>>> - >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) >>>>>>>>>>>>>> is enough to have this check only in install_master, >>>>>>>>>>>>>> install_topo can >>>>>>>>>>>>>> pass None to install_master >>>>>>>>>>>>>> + if domain_level is None: >>>>>>>>>>>>>> + domain_level = master.config.domain_level >>>>>>>>>>>>> Done >>>>>>>>>>>>> >>>>>>>>>>>>>> 3) >>>>>>>>>>>>>> IMO replica-manage del should cleanup hosts entry, so >>>>>>>>>>>>>> following >>>>>>>>>>>>>> code >>>>>>>>>>>>>> should not be needed. >>>>>>>>>>>>>> + if cleanhost: >>>>>>>>>>>>>> + kinit_admin(master) >>>>>>>>>>>>>> + master.run_command(["ipa", "host-del", >>>>>>>>>>>>>> "--updatedns", >>>>>>>>>>>>>> replica.hostname], >>>>>>>>>>>>>> + raiseonerr=False) >>>>>>>>>>>>> Well, in fact it does not. At least the corresponding dns >>>>>>>>>>>>> record >>>>>>>>>>>>> stays >>>>>>>>>>>>> and causes the subsequent ipa-client-install to fail. Probably >>>>>>>>>>>>> it's a >>>>>>>>>>>>> bug. On the other hand, if I promote an existing client to >>>>>>>>>>>>> replica and >>>>>>>>>>>>> then delete this replica, then, I probably want the host >>>>>>>>>>>>> record >>>>>>>>>>>>> (that >>>>>>>>>>>>> was created during client-install) to stay in the system. So, >>>>>>>>>>>>> does not >>>>>>>>>>>>> look like a bug to me. >>>>>>>>>>>> No you don't, because replica uninstallation also removes the >>>>>>>>>>>> client. >>>>>>>>>>>> >>>>>>>>>>>> I tried it with ipa42, ipa-replica-manage del removes host >>>>>>>>>>>> entry, >>>>>>>>>>>> and >>>>>>>>>>>> DNS A records, only SSHFP records stay there (I'm not sure >>>>>>>>>>>> if it >>>>>>>>>>>> is bug >>>>>>>>>>>> or feature) >>>>>>>>>>>> >>>>>>>>>>>> Also I received this message >>>>>>>>>>>> """ >>>>>>>>>>>> Failed to cleanup replica1.ipa.test DNS entries: no matching >>>>>>>>>>>> entry >>>>>>>>>>>> found >>>>>>>>>>>> You may need to manually remove them from the tree >>>>>>>>>>>> """ >>>>>>>>>>>> But, A record has been removed, so this is probably false >>>>>>>>>>>> positive and >>>>>>>>>>>> it needs to have a ticket. >>>>>>>>>>> Agree, that was an issue with my setup. >>>>>>>>>>> Removed >>>>>>>>>>> >>>>>>>>>>>>>> 4) >>>>>>>>>>>>>> This variable is not used >>>>>>>>>>>>>> + kra_uninstall = ["ipa-kra-install", "--uninstall", "-U"] >>>>>>>>>>>>> Removed >>>>>>>>>>>>> >>>>>>>>>>>>>> 5) >>>>>>>>>>>>>> Why do you need this >>>>>>>>>>>>>> + kra_install = ["ipa-kra-install", "-U", "-p", >>>>>>>>>>>>>> config.dirman_password] >>>>>>>>>>>>>> when you implemented tasks.install_kra that returns the >>>>>>>>>>>>>> exactly >>>>>>>>>>>>>> the same >>>>>>>>>>>>>> result? >>>>>>>>>>>>> Right. Removed >>>>>>>>>>>>> >>>>>>>>>>>>>> 6) >>>>>>>>>>>>>> PEP8 >>>>>>>>>>>>>> ./ipatests/test_integration/tasks.py:928:1: E302 expected 2 >>>>>>>>>>>>>> blank >>>>>>>>>>>>>> lines, >>>>>>>>>>>>>> found 1 >>>>>>>>>>>>>> ./ipatests/test_integration/tasks.py:934:1: E302 expected 2 >>>>>>>>>>>>>> blank >>>>>>>>>>>>>> lines, >>>>>>>>>>>>>> found 1 >>>>>>>>>>>>>> ./ipatests/test_integration/tasks.py:939:1: E302 expected 2 >>>>>>>>>>>>>> blank >>>>>>>>>>>>>> lines, >>>>>>>>>>>>>> found 1 >>>>>>>>>>>>>> ./ipatests/test_integration/tasks.py:943:1: E302 expected 2 >>>>>>>>>>>>>> blank >>>>>>>>>>>>>> lines, >>>>>>>>>>>>>> found 1 >>>>>>>>>>>>>> ./ipatests/test_integration/tasks.py:950:80: E501 line too >>>>>>>>>>>>>> long >>>>>>>>>>>>>> (80 > 79 >>>>>>>>>>>>>> characters) >>>>>>>>>>>>>> >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:29:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (85 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:64:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (85 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:67:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (88 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:93:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (80 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:94:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (83 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:118:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (81 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:128:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (80 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:129:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (82 > 79 characters) >>>>>>>>>>>>>> ./ipatests/test_integration/test_replica_promotion.py:181:80: >>>>>>>>>>>>>> E501 >>>>>>>>>>>>>> >>>>>>>>>>>>>> line >>>>>>>>>>>>>> too long (80 > 79 characters) >>>>>>>>>>>>> Most of these complaints are unrelated to the current patches. >>>>>>>>>>>>> It's better to create a separate patch addressing PEP8 errors. >>>>>>>>>>>>> >>>>>>>>>>>> I beg for your pardon, those PEP8 errors have been >>>>>>>>>>>> introduced by >>>>>>>>>>>> your >>>>>>>>>>>> patches. >>>>>>>>>>> Fixed >>>>>>>>>>> >>>>>>>>>>>>>> 7) >>>>>>>>>>>>>> Why this must be stored in instance? IMO to have it stored as >>>>>>>>>>>>>> local >>>>>>>>>>>>>> variable is perfect >>>>>>>>>>>>>> TestKRAInstall, TestCAInstall >>>>>>>>>>>>>> self.replica1_filename = >>>>>>>>>>>>>> tasks.get_replica_filename(replica1) >>>>>>>>>>>>>> self.replica2_filename = >>>>>>>>>>>>>> tasks.get_replica_filename(replica2) >>>>>>>>>>>>> Agree. Fixed >>>>>>>>>>>>> >>>>>>>>> This patch is missing something. >>>>>>>> I am sorry, I forgot to revert my previous change. The correct >>>>>>>> patch is >>>>>>>> attached >>>>>>>> >>>>>>> ************* Module >>>>>>> ipatests.test_integration.test_replica_promotion >>>>>>> ipatests/test_integration/test_replica_promotion.py:15: >>>>>>> [E1123(unexpected-keyword-arg), Dummy.install] Unexpected keyword >>>>>>> argument 'domain_level' in function call) >>>>>>> ipatests/test_integration/test_replica_promotion.py:15: >>>>>>> [E1101(no-member), Dummy.install] Class 'Dummy' has no >>>>>>> 'domain_level' >>>>>>> member) >>>>>>> ipatests/test_integration/test_replica_promotion.py:19: >>>>>>> [E1101(no-member), Dummy.teardown_method] Module >>>>>>> 'ipatests.test_integration.tasks' has no 'uninstall_replica' member) >>>>>>> ipatests/test_integration/test_replica_promotion.py:67: >>>>>>> [E1101(no-member), TestReplicaPromotionLevel0.test_backup_restore] >>>>>>> Module 'ipatests.test_integration.tasks' has no 'ipa_backup' member) >>>>>>> ipatests/test_integration/test_replica_promotion.py:72: >>>>>>> [E1101(no-member), TestReplicaPromotionLevel0.test_backup_restore] >>>>>>> Module 'ipatests.test_integration.tasks' has no 'ipa_restore' >>>>>>> member) >>>>>>> ipatests/test_integration/test_replica_promotion.py:120: >>>>>>> [E1123(unexpected-keyword-arg), TestCAInstall.install] Unexpected >>>>>>> keyword argument 'domain_level' in function call) >>>>>>> >>>>>> Sorry I forgot to apply patch 17, my bad, I'm continuing with review >>>> LGTM, I haven't had time to test it, but if you are sure that test is >>>> working, we may push this. >>>> >>> Is this expected due the bug you mentioned? >>> _____ >>> __________________________________________________________________________ >>> >>> TestReplicaPromotionLevel0.test_kra_install_master >>> ________________________________________________________________________________ >>> >>> >>> >>> self = >>> >> >>> object at 0x7f5071a59e50> >>> >>> def test_kra_install_master(self): >>> result1 = tasks.install_kra(self.master, raiseonerr=False) >>>> assert result1.returncode == 0, result1.stderr_text >>> E AssertionError: Usage: ipa-kra-install [options] [replica_file] >>> E >>> E ipa-kra-install: error: Replica file >>> /root/ipatests/replica-info.gpg does not exist >>> E The ipa-kra-install command failed. See >>> /var/log/ipaserver-kra-install.log for more information >>> E >>> E assert 2 == 0 >>> E + where 2 = >> 0x7f5071adbd50>.returncode >>> > IMO the test needs fix, KRA on replica file needs KRA related > certificates in replica file > > [ipa.ipatests.test_integration.host.Host.replica2.ParamikoTransport] RUN > ['ipa-kra-install', '-U', '-p', 'Secret123', > '/root/ipatests/replica-info.gpg'] > [ipa.ipatests.test_integration.host.Host.replica2.cmd27] RUN > ['ipa-kra-install', '-U', '-p', 'Secret123', > '/root/ipatests/replica-info.gpg'] > [ipa.ipatests.test_integration.host.Host.replica2.cmd27] Missing KRA > certificates, please create a new replica file. > [ipa.ipatests.test_integration.host.Host.replica2.cmd27] The > ipa-kra-install command failed. See /var/log/ipaserver-kra-install.log > for more information > [ipa.ipatests.test_integration.host.Host.replica2.cmd27] Exit code: 1 > FAILED >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > traceback >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > self = object at 0x7f660bc1a590> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0016.8-Integration-tests-for-replica-promotion-feature.patch Type: text/x-patch Size: 10992 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0024-Enabled-setting-domain-level-explicitly-in-test-clas.patch Type: text/x-patch Size: 5579 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0025-Removed-a-constantly-failing-call-to-prepare_host.patch Type: text/x-patch Size: 1531 bytes Desc: not available URL: From tbabej at redhat.com Mon Feb 29 12:20:17 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Feb 2016 13:20:17 +0100 Subject: [Freeipa-devel] [PATCH 0421] Make PTR records check optional for IPA installation In-Reply-To: <56D01467.8080104@redhat.com> References: <56CDBA6D.5000803@redhat.com> <56CEE03C.9030801@redhat.com> <56D01467.8080104@redhat.com> Message-ID: <56D43781.9050103@redhat.com> On 02/26/2016 10:01 AM, Oleg Fayans wrote: > > > On 02/25/2016 12:06 PM, Petr Spacek wrote: >> On 24.2.2016 15:13, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/5686 >>> >>> Patch attached. >> >> LGTM, ACK if it passes QE testing. >> > That did it. Works with both replica-prepare under domain level 0 and > with replica-install on domlevel1. > > ACK > > Pushed to: master: 8f01b47ed96ee3118479d366a71a018e8f938156 ipa-4-3: bd725f4ba4449f285a8b1f646dc7a54978211ff9 ipa-4-2: e66ce1a63b5ea11fbecb9e268d1ac40f3994b339 From tbabej at redhat.com Mon Feb 29 12:20:43 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Feb 2016 13:20:43 +0100 Subject: [Freeipa-devel] [PATCH 0421] Make PTR records check optional for IPA installation In-Reply-To: <56D43781.9050103@redhat.com> References: <56CDBA6D.5000803@redhat.com> <56CEE03C.9030801@redhat.com> <56D01467.8080104@redhat.com> <56D43781.9050103@redhat.com> Message-ID: <56D4379B.9080208@redhat.com> On 02/29/2016 01:20 PM, Tomas Babej wrote: > > > On 02/26/2016 10:01 AM, Oleg Fayans wrote: >> >> >> On 02/25/2016 12:06 PM, Petr Spacek wrote: >>> On 24.2.2016 15:13, Martin Basti wrote: >>>> https://fedorahosted.org/freeipa/ticket/5686 >>>> >>>> Patch attached. >>> >>> LGTM, ACK if it passes QE testing. >>> >> That did it. Works with both replica-prepare under domain level 0 and >> with replica-install on domlevel1. >> >> ACK >> >> > > Pushed to: > master: 8f01b47ed96ee3118479d366a71a018e8f938156 > ipa-4-3: bd725f4ba4449f285a8b1f646dc7a54978211ff9 > ipa-4-2: e66ce1a63b5ea11fbecb9e268d1ac40f3994b339 > Note: 4.2 patch required a manual rebase. From mbabinsk at redhat.com Mon Feb 29 13:04:22 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 29 Feb 2016 14:04:22 +0100 Subject: [Freeipa-devel] [PATCH 0401] ipa-adtrust-install: Allow dash in the NETBIOS name In-Reply-To: <56CEFE14.9000905@redhat.com> References: <56CEFE14.9000905@redhat.com> Message-ID: <56D441D6.7010401@redhat.com> On 02/25/2016 02:13 PM, Tomas Babej wrote: > Hi, > > Dash should be one of the allowed characters in the netbios names, > so relax the too strict validation. > > Note: the set of allowed characters might expand in the future > > https://fedorahosted.org/freeipa/ticket/5286 > > Tomas > > > NACK, since this patch breaks the interactive installation of adtrust, see the following log: http://fpaste.org/331088/56750906/ Keep in mind that the argument of any is first instantiated and then each element is tested. Since during interactive installation there is a possibility in the current code that check_netbios_name receives None as argument. You will have to correct this somehow. -- Martin^3 Babinsky From tbabej at redhat.com Mon Feb 29 13:59:07 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Feb 2016 14:59:07 +0100 Subject: [Freeipa-devel] [PATCH 0401] ipa-adtrust-install: Allow dash in the NETBIOS name In-Reply-To: <56D441D6.7010401@redhat.com> References: <56CEFE14.9000905@redhat.com> <56D441D6.7010401@redhat.com> Message-ID: <56D44EAB.3010900@redhat.com> On 02/29/2016 02:04 PM, Martin Babinsky wrote: > On 02/25/2016 02:13 PM, Tomas Babej wrote: >> Hi, >> >> Dash should be one of the allowed characters in the netbios names, >> so relax the too strict validation. >> >> Note: the set of allowed characters might expand in the future >> >> https://fedorahosted.org/freeipa/ticket/5286 >> >> Tomas >> >> >> > > NACK, since this patch breaks the interactive installation of adtrust, > see the following log: http://fpaste.org/331088/56750906/ > > Keep in mind that the argument of any is first instantiated and then > each element is tested. Since during interactive installation there is a > possibility in the current code that check_netbios_name receives None as > argument. You will have to correct this somehow. > Good catch. My original patch indeed breaks the interactive installation on a clean machine where no netbios name has been specified explicitly. Fixed, attaching patches for both branches. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0401-ipa-adtrust-install-Allow-dash-in-the-NETBIOS-name.patch Type: text/x-patch Size: 2621 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-2-tbabej-0401-ipa-adtrust-install-Allow-dash-in-the-NETBIOS-name.patch Type: text/x-patch Size: 3142 bytes Desc: not available URL: From mbabinsk at redhat.com Mon Feb 29 14:20:19 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 29 Feb 2016 15:20:19 +0100 Subject: [Freeipa-devel] [PATCH 0401] ipa-adtrust-install: Allow dash in the NETBIOS name In-Reply-To: <56D44EAB.3010900@redhat.com> References: <56CEFE14.9000905@redhat.com> <56D441D6.7010401@redhat.com> <56D44EAB.3010900@redhat.com> Message-ID: <56D453A3.40005@redhat.com> On 02/29/2016 02:59 PM, Tomas Babej wrote: > > > On 02/29/2016 02:04 PM, Martin Babinsky wrote: >> On 02/25/2016 02:13 PM, Tomas Babej wrote: >>> Hi, >>> >>> Dash should be one of the allowed characters in the netbios names, >>> so relax the too strict validation. >>> >>> Note: the set of allowed characters might expand in the future >>> >>> https://fedorahosted.org/freeipa/ticket/5286 >>> >>> Tomas >>> >>> >>> >> >> NACK, since this patch breaks the interactive installation of adtrust, >> see the following log: http://fpaste.org/331088/56750906/ >> >> Keep in mind that the argument of any is first instantiated and then >> each element is tested. Since during interactive installation there is a >> possibility in the current code that check_netbios_name receives None as >> argument. You will have to correct this somehow. >> > > Good catch. My original patch indeed breaks the interactive installation > on a clean machine where no netbios name has been specified explicitly. > > Fixed, attaching patches for both branches. > > Tomas > ACK -- Martin^3 Babinsky From tbabej at redhat.com Mon Feb 29 15:01:38 2016 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Feb 2016 16:01:38 +0100 Subject: [Freeipa-devel] [PATCH 0401] ipa-adtrust-install: Allow dash in the NETBIOS name In-Reply-To: <56D453A3.40005@redhat.com> References: <56CEFE14.9000905@redhat.com> <56D441D6.7010401@redhat.com> <56D44EAB.3010900@redhat.com> <56D453A3.40005@redhat.com> Message-ID: <56D45D52.6010706@redhat.com> On 02/29/2016 03:20 PM, Martin Babinsky wrote: > On 02/29/2016 02:59 PM, Tomas Babej wrote: >> >> >> On 02/29/2016 02:04 PM, Martin Babinsky wrote: >>> On 02/25/2016 02:13 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Dash should be one of the allowed characters in the netbios names, >>>> so relax the too strict validation. >>>> >>>> Note: the set of allowed characters might expand in the future >>>> >>>> https://fedorahosted.org/freeipa/ticket/5286 >>>> >>>> Tomas >>>> >>>> >>>> >>> >>> NACK, since this patch breaks the interactive installation of adtrust, >>> see the following log: http://fpaste.org/331088/56750906/ >>> >>> Keep in mind that the argument of any is first instantiated and then >>> each element is tested. Since during interactive installation there is a >>> possibility in the current code that check_netbios_name receives None as >>> argument. You will have to correct this somehow. >>> >> >> Good catch. My original patch indeed breaks the interactive installation >> on a clean machine where no netbios name has been specified explicitly. >> >> Fixed, attaching patches for both branches. >> >> Tomas >> > ACK > Pushed to ipa-4-2: 657838462c4b0ce5be2cee584b3be112aca6c660 Pushed to ipa-4-3: 1496fb779d72fb590376df23e39206938fe8dad2 Pushed to master: b41fbceeafea126f8e014da5d3596138c6cf0feb From dkupka at redhat.com Mon Feb 29 15:02:57 2016 From: dkupka at redhat.com (David Kupka) Date: Mon, 29 Feb 2016 10:02:57 -0500 (EST) Subject: [Freeipa-devel] [PATCH 0029] Move user/group constants for PKI and DS into ipaplatform In-Reply-To: <569F6826.2060608@redhat.com> References: <569E381B.3040104@redhat.com> <20160120015428.GJ31821@dhcp-40-8.bne.redhat.com> <569F6826.2060608@redhat.com> Message-ID: <1542878923.39274119.1456758177069.JavaMail.zimbra@redhat.com> Hello Christian, sorry for letting this patch rot for so long. I've forget about it the minute Fraser replied. To compensate a little I've fixed pep8 error, rebased it and attaching two versions for master and for 4.3 branch. I haven't found any missing cases and it works for me. If you're OK with the modified patches it can be pushed. David ----- Original Message ----- From: "Christian Heimes" To: "Fraser Tweedale" Cc: "freeipa-devel" Sent: Wednesday, January 20, 2016 11:57:42 AM Subject: Re: [Freeipa-devel] [PATCH 0029] Move user/group constants for PKI and DS into ipaplatform On 2016-01-20 02:54, Fraser Tweedale wrote: > On Tue, Jan 19, 2016 at 02:20:27PM +0100, Christian Heimes wrote: >> ipaplatform.constants has platform specific names for a couple of system >> users like Apache HTTPD. The user names for PKI_USER, PKI_GROUP, DS_USER >> and DS_GROUP are defined in other modules. Similar to #5587 the patch my >> patch moves the constants into the platform module. >> >> https://fedorahosted.org/freeipa/ticket/5619 > > I see a few remaining cases: > > ipaserver/install/dsinstance.py > 712: pent = pwd.getpwnam("dirsrv") > > ipatests/test_integration/test_backup_and_restore.py > 167: self.master.run_command(['userdel', 'dirsrv']) > 168: self.master.run_command(['userdel', 'pkiuser']) > > ipaplatform/redhat/tasks.py > 441: if name == 'pkiuser': > > When these are included, ACK. Good catch! My new patch takes care of remaining cases. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-43-cheimes-0029-3-Move-user-group-constants-for-PKI-and-DS-into-ipapla.patch Type: text/x-patch Size: 17784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-cheimes-0029-3-Move-user-group-constants-for-PKI-and-DS-into-ipapla.patch Type: text/x-patch Size: 17716 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Mon Feb 29 16:07:44 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Mon, 29 Feb 2016 21:37:44 +0530 Subject: [Freeipa-devel] [python-pytest-multihost] Request to add support to specify username/password for each host In-Reply-To: <20160229112631.GA13353@mniranja.pnq.redhat.com> References: <20160226101434.GA18928@mniranja.pnq.redhat.com> <20160229112631.GA13353@mniranja.pnq.redhat.com> Message-ID: <20160229160744.GA18511@mniranja.pnq.redhat.com> Greetings, Sending the modified patch where there is an assertion when per host username/password is used in OpenSSH mode. Regards Niranjan -------------- next part -------------- From abfdda3cf8e4839b397ad82f61a8249317e10fba Mon Sep 17 00:00:00 2001 From: Niranjan MR Date: Fri, 26 Feb 2016 15:30:25 +0530 Subject: [PATCH] Add support to specify usernames/password per host Per Host username/password is supported when used with Paramiko and not supported in OpenSSH Mode. https://fedorahosted.org/python-pytest-multihost/ticket/5 Signed-off-by: Niranjan MR --- pytest_multihost/host.py | 12 +++++++++--- pytest_multihost/transport.py | 12 ++++++++++-- 2 files changed, 19 insertions(+), 5 deletions(-) diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py index f3346f60e3c48d79e85f88aa2387e4c89ee38f08..7885722535bc260a758acc1e8ad2f98a0483b48a 100644 --- a/pytest_multihost/host.py +++ b/pytest_multihost/host.py @@ -26,10 +26,13 @@ class BaseHost(object): """ transport_class = None - def __init__(self, domain, hostname, role, ip=None, - external_hostname=None): + def __init__(self, domain, hostname, role, + username=None, password=None, + ip=None, external_hostname=None): self.domain = domain self.role = str(role) + self.username = username + self.password = password shortname, dot, ext_domain = hostname.partition('.') self.shortname = shortname @@ -109,9 +112,12 @@ class BaseHost(object): ip = dct.pop('ip', None) external_hostname = dct.pop('external_hostname', None) + username = dct.pop('username', None) + password = dct.pop('password', None) + check_config_dict_empty(dct, 'host %s' % hostname) - return cls(domain, hostname, role, ip, external_hostname) + return cls(domain, hostname, role, username, password, ip, external_hostname) def to_dict(self): """Export info about this Host to a dict""" diff --git a/pytest_multihost/transport.py b/pytest_multihost/transport.py index eda71cd98ffe46d0d8927c10c391743345968751..e893e485425632729fa46fa81b3446d5d32d682b 100644 --- a/pytest_multihost/transport.py +++ b/pytest_multihost/transport.py @@ -177,11 +177,19 @@ class ParamikoTransport(Transport): host.ssh_port)) self._transport = transport = paramiko.Transport(sock) transport.connect(hostkey=host.host_key) + if host.password: + self.log.debug('Authenticating with password set in host section') + transport.auth_password(username=host.username, + password=host.password) if host.ssh_key_filename: - self.log.debug('Authenticating with private RSA key') filename = os.path.expanduser(host.ssh_key_filename) key = paramiko.RSAKey.from_private_key_file(filename) - transport.auth_publickey(username=host.ssh_username, key=key) + if host.username: + self.log.debug('Authenticating with private RSA key using user %s' % ( host.username)) + transport.auth_publickey(username=host.username, key=key) + else: + self.log.debug('Authenticating with private RSA key') + transport.auth_publickey(username=host.ssh_username, key=key) elif host.ssh_password: self.log.debug('Authenticating with password') transport.auth_password(username='root', -- 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 pviktori at redhat.com Mon Feb 29 16:14:34 2016 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Feb 2016 17:14:34 +0100 Subject: [Freeipa-devel] [PATCHES] 0772-0774 Python3 fixes in for client installation In-Reply-To: <56D3EF5C.1090008@redhat.com> References: <56CAF30F.7010306@redhat.com> <56D079F2.2020501@redhat.com> <56D3EF5C.1090008@redhat.com> Message-ID: <56D46E6A.2050600@redhat.com> On 02/29/2016 08:12 AM, Jan Cholasta wrote: > Hi, > > On 26.2.2016 17:14, Petr Viktorin wrote: >> On 02/22/2016 12:37 PM, Petr Viktorin wrote: >>> Hello, >>> These fixes are needed for the "happy path" of ipa-client-install >>> --server on Python 3. >> >> Hello, >> Could someone please look at these patches? > > Patch 0772: > > 1) Instead of decoding when the type is bytes in get_ipa_basedn(), read > attribute values from 'entry.raw' rather than 'entry' and decode always. Done. > 2) get_ipa_basedn() is used only in ipadiscovery, perhaps we should move > it there? I did that in an extra patch, mainly to make the diff more meaningful. > Patch 0773: ACK, but the patch does not apply on ipa-4-3. > > > Patch 0774: ACK. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0771-Move-get_ipa_basedn-from-ipautil-to-ipadiscovery.patch Type: text/x-patch Size: 5126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0772-ipadiscovery-Decode-to-unicode-in-ipacheckldap-get_i.patch Type: text/x-patch Size: 2418 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0773-ipapython.sysrestore-Use-str-methods-instead-of-func.patch Type: text/x-patch Size: 2705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0774-ipalib.x809-Accept-bytes-for-make_pem.patch Type: text/x-patch Size: 928 bytes Desc: not available URL: From tbordaz at redhat.com Mon Feb 29 16:37:43 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 29 Feb 2016 17:37:43 +0100 Subject: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI In-Reply-To: <56D081E4.4070702@redhat.com> References: <56A0D0EC.3010009@redhat.com> <56A1018D.101@redhat.com> <56CDCC82.30108@redhat.com> <56CEDF98.7060809@redhat.com> <56CF452E.30503@redhat.com> <56D06E27.2050408@redhat.com> <56D081E4.4070702@redhat.com> Message-ID: <56D473D7.2050103@redhat.com> On 02/26/2016 05:48 PM, Martin Babinsky wrote: > On 02/26/2016 04:24 PM, thierry bordaz wrote: >> On 02/25/2016 07:17 PM, thierry bordaz wrote: >>> On 02/25/2016 12:03 PM, Martin Babinsky wrote: >>>> On 02/24/2016 04:30 PM, thierry bordaz wrote: >>>>> On 01/21/2016 05:04 PM, Martin Babinsky wrote: >>>>>> On 01/21/2016 01:37 PM, thierry bordaz wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>> Hi Thierry, >>>>>> >>>>>> I have couple of comments to your patch: >>>>>> >>>>>> 1.) >>>>>> there is a number of PEP8 errors in the patch >>>>>> (http://paste.fedoraproject.org/313246/33893701), please fix them. >>>>>> >>>>>> See http://www.freeipa.org/page/Python_Coding_Style for our >>>>>> conventions used in Python code. >>>>>> >>>>>> 2.) >>>>>> + DNA_BIND_METHOD = "dnaRemoteBindMethod" >>>>>> + DNA_CONN_PROTOCOL = "dnaRemoteConnProtocol" >>>>>> + DNA_PLUGIN_DN = 'cn=Distributed Numeric Assignment >>>>>> Plugin,cn=plugins,cn=config' >>>>>> + dna_config_base = 'cn=Posix IDs,%s' % DNA_PLUGIN_DN >>>>>> >>>>>> Uppercase names are usually reserved for module-level constants. >>>>>> OTOH, >>>>>> local variables should be lowercase. Also you can instantiate >>>>>> dna_config_base directly as DN, using 2-member tuples, i. e: >>>>>> >>>>>> """ >>>>>> dna_config_base = DN(('cn', 'posix IDs'), ('cn', 'Distributed >>>>>> Numeric >>>>>> Assignment Plugin'), ('cn', 'plugins'), ('cn', 'config')) >>>>>> """ >>>>>> >>>>>> When passing DN object to the formatting functions/operators, it is >>>>>> automatically converted to string so no need to hold string and DN >>>>>> object separately. This is done in other places (see >>>>>> function/methods >>>>>> in replication.py). >>>>>> >>>>>> 3.) >>>>>> >>>>>> + for i in range(len(entries)) : >>>>>> + >>>>>> + mod = [] >>>>>> + if entries[i].single_value.get(DNA_BIND_METHOD) != >>>>>> method: >>>>>> + mod.append((ldap.MOD_REPLACE, DNA_BIND_METHOD, >>>>>> method)) >>>>>> + >>>>>> + if entries[i].single_value.get(DNA_CONN_PROTOCOL) != >>>>>> protocol: >>>>>> + mod.append((ldap.MOD_REPLACE, DNA_CONN_PROTOCOL, >>>>>> protocol)) >>>>>> >>>>>> >>>>>> please use idiomatic Python when handling list of entries, e.g.: >>>>>> >>>>>> """ >>>>>> for entry in entries: >>>>>> mod = [] >>>>>> if entry.single_value.get(DNA_BIND_METHOD) != method: >>>>>> ... >>>>>> """ >>>>>> >>>>>> 4.) I think that this method should in DSInstance class since it >>>>>> deals >>>>>> with directory server configuration. Service is a parent object >>>>>> of all >>>>>> other service installers/configurators and should contain only >>>>>> methods >>>>>> common to more children. >>>>>> >>>>>> 5.) Since the method is called from every installer, it could be >>>>>> beneficial to call it in DSInstance.__common_post_setup() as a >>>>>> part of >>>>>> Directory server installation. Is there any reason why this is >>>>>> not the >>>>>> case? >>>>>> >>>>>> 6.) >>>>>> >>>>>> + while attempt != MAX_WAIT: >>>>>> + try: >>>>>> + entries = conn.get_entries(sharedcfgdn, >>>>>> scope=ldap.SCOPE_ONELEVEL, filter='dnaHostname=%s' % self.fqdn) >>>>>> + break >>>>>> + except errors.NotFound: >>>>>> + root_logger.debug("So far enable not find DNA >>>>>> shared >>>>>> config entry for dnaHostname=%s under %s. Retry in 2sec" % >>>>>> (self.fqdn, >>>>>> sharedcfgdn)) >>>>>> + attempt = attempt + 1 >>>>>> + time.sleep(2) >>>>>> + continue >>>>>> + >>>>>> + # safety checking >>>>>> + # there is no return, if there are several entries, as a >>>>>> workaround of #5510 >>>>>> + if len(entries) != 1: >>>>>> >>>>>> I am quite afraid what would happen if the server does not return >>>>>> any >>>>>> entries until 30 s timeout. The code will then continue to the >>>>>> condition which can potentially test an uninitialized variable and >>>>>> blow up with 'NameError'. This should be handled more robustly, >>>>>> e. g. >>>>>> raise an exception when a timeout is reached and no entries were >>>>>> returned. >>>>>> >>>>>> 7.) >>>>>> >>>>>> + if len(mod) > 0: >>>>>> >>>>>> A Pythonic way to test for non-empty container is >>>>>> >>>>>> """ >>>>>> if mods: >>>>>> # do stuff >>>>>> """ >>>>>> >>>>>> since an empty list/dict/set evaluates to False and non-empty >>>>>> containers are True. >>>>>> >>>>>> >>>>>> 8.) >>>>>> >>>>>> + entry = conn.get_entry(entries[i].dn) >>>>>> + if entry.single_value.get(DNA_BIND_METHOD) != >>>>>> method: >>>>>> + root_logger.error("Fail to set SASL/GSSAPI bind >>>>>> method to %s" % (entries[i].dn)) >>>>>> + if entry.single_value.get(DNA_CONN_PROTOCOL) != >>>>>> protocol: >>>>>> + root_logger.error("Fail to set LDAP protocol to >>>>>> %s" % (entries[i].dn)) >>>>>> >>>>>> rather than re-fetching the modified entry and testing what >>>>>> happened, >>>>>> you can just catch an exception raised by unsuccessfull mod and >>>>>> log an >>>>>> error like this: >>>>>> >>>>>> """ >>>>>> try: >>>>>> conn.modify_s(entry.dn, mod) >>>>>> except Exception as e: >>>>>> root_logger.error("Failed to modify entry {}: >>>>>> {}".format(entry, e)) >>>>>> """ >>>>>> >>>>>> as a matter of fact, if the modify_s operation would fail for some >>>>>> reason, an ldap exception would be raised and you checks would not >>>>>> even be executed. >>>>>> >>>>>> 9.) >>>>>> The debug message on line 219 should read "Unable to find DNA shared >>>>>> config entry for dnaHostname=%s so far. Retry in 2 sec.". The errors >>>>>> at the end of the method should have "Failed" instead of "Fail". >>>>>> >>>>> Hi Martin, >>>>> >>>>> Finally tested... here is the updated patch. Thanks for you patience >>>>> >>>>> >>>>> thanks >>>>> thierry >>>> >>>> Hi Thierry, >>>> >>>> the patch works as expected. I have some more nitpicks though: >>>> >>>> 1.) Please fix the following pep8 errors: >>>> >>>> http://paste.fedoraproject.org/329086/56397841/ >>>> >>>> you can check whether you recent commit conforms to PEP8 by running >>>> >>>> "git show -U0 | pep8 --diff" >>>> >>>> 2.) >>>> + self.step("update DNA shared config entry", >>>> self.update_dna_shared_config) >>>> >>>> I would rather change the message to "Updating DNA shared config >>>> entry" since all other messages use continuous tense. >>>> >>>> 3.) >>>> + else: >>>> + raise RuntimeError("Could not get dnaHostname >>>> entries in {} seconds".format(max_wait * 2)) >>>> >>>> Please use root_logger.error() and then return as is used elsewhere >>>> in the method. We do not want a runaway exception crashing upgrade. >>>> >>> Hi Martin, >>> >>> Updated/tested the patch with your help/recommendations. pep8 is clear >>> now :-) >>> >>> thanks >>> thierry >> >> Hi Martin, >> >> Following your recommendation it is an updated patch to not check/update >> shared config entry in DSinstance.__post_common_setup(). >> In fact at this step, DNA plugin is disabled and such the check would be >> a no-op. >> >> thanks >> thierry > > Thanks Thierry, > > the patch will need a rebased version which applies cleanly on top of > ipa-4-3 branch, but otherwise ACK. > Thanks Martin for all the reviews. Here is the patch for ipa-4.3 thnaks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-43-tbordaz-0017-4-configure-DNA-plugin-shared-config-entries-to-allow-.patch Type: text/x-patch Size: 8263 bytes Desc: not available URL: From mrniranjan at fedoraproject.org Mon Feb 29 16:57:49 2016 From: mrniranjan at fedoraproject.org (Niranjan) Date: Mon, 29 Feb 2016 22:27:49 +0530 Subject: [Freeipa-devel] [python-pytest-multihost] Request to add support to specify username/password for each host In-Reply-To: <20160229160744.GA18511@mniranja.pnq.redhat.com> References: <20160226101434.GA18928@mniranja.pnq.redhat.com> <20160229112631.GA13353@mniranja.pnq.redhat.com> <20160229160744.GA18511@mniranja.pnq.redhat.com> Message-ID: <20160229165748.GA19752@mniranja.pnq.redhat.com> Greetings, Attached wrong patch in my last mail. Request to review the patch attached to this email Regards Niranjan -------------- next part -------------- From 0bed8ae52972b782158394179b868a9ff028b5e6 Mon Sep 17 00:00:00 2001 From: Niranjan MR Date: Fri, 26 Feb 2016 15:30:25 +0530 Subject: [PATCH] Add support to specify usernames/password per host Per Host username/password is supported when used with Paramiko and not supported in OpenSSH Mode https://fedorahosted.org/python-pytest-multihost/ticket/5 Signed-off-by: Niranjan MR --- pytest_multihost/host.py | 12 +++++++++--- pytest_multihost/transport.py | 16 +++++++++++++--- 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/pytest_multihost/host.py b/pytest_multihost/host.py index f3346f60e3c48d79e85f88aa2387e4c89ee38f08..7885722535bc260a758acc1e8ad2f98a0483b48a 100644 --- a/pytest_multihost/host.py +++ b/pytest_multihost/host.py @@ -26,10 +26,13 @@ class BaseHost(object): """ transport_class = None - def __init__(self, domain, hostname, role, ip=None, - external_hostname=None): + def __init__(self, domain, hostname, role, + username=None, password=None, + ip=None, external_hostname=None): self.domain = domain self.role = str(role) + self.username = username + self.password = password shortname, dot, ext_domain = hostname.partition('.') self.shortname = shortname @@ -109,9 +112,12 @@ class BaseHost(object): ip = dct.pop('ip', None) external_hostname = dct.pop('external_hostname', None) + username = dct.pop('username', None) + password = dct.pop('password', None) + check_config_dict_empty(dct, 'host %s' % hostname) - return cls(domain, hostname, role, ip, external_hostname) + return cls(domain, hostname, role, username, password, ip, external_hostname) def to_dict(self): """Export info about this Host to a dict""" diff --git a/pytest_multihost/transport.py b/pytest_multihost/transport.py index eda71cd98ffe46d0d8927c10c391743345968751..0906683d2e04f16944d508e8fe410534b850c0ea 100644 --- a/pytest_multihost/transport.py +++ b/pytest_multihost/transport.py @@ -177,11 +177,19 @@ class ParamikoTransport(Transport): host.ssh_port)) self._transport = transport = paramiko.Transport(sock) transport.connect(hostkey=host.host_key) + if host.password: + self.log.debug('Authenticating with password set in host section') + transport.auth_password(username=host.username, + password=host.password) if host.ssh_key_filename: - self.log.debug('Authenticating with private RSA key') filename = os.path.expanduser(host.ssh_key_filename) key = paramiko.RSAKey.from_private_key_file(filename) - transport.auth_publickey(username=host.ssh_username, key=key) + if host.username: + self.log.debug('Authenticating with private RSA key using user %s' % ( host.username)) + transport.auth_publickey(username=host.username, key=key) + else: + self.log.debug('Authenticating with private RSA key') + transport.auth_publickey(username=host.ssh_username, key=key) elif host.ssh_password: self.log.debug('Authenticating with password') transport.auth_password(username='root', @@ -303,7 +311,9 @@ class OpenSSHTransport(Transport): '-o', 'ControlPath=%s' % control_file, '-o', 'StrictHostKeyChecking=no', '-o', 'UserKnownHostsFile=%s' % known_hosts_file] - + if host.username: + self.log.critical('Per Host Username/Password is not supported') + raise RuntimeError('Per Host Username/Password is not supported with OpenSSH Mode') if self.host.ssh_key_filename: key_filename = os.path.expanduser(self.host.ssh_key_filename) argv.extend(['-i', key_filename]) -- 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 jfenal at gmail.com Mon Feb 29 17:45:05 2016 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 29 Feb 2016 18:45:05 +0100 Subject: [Freeipa-devel] French translation for FreeIPA Message-ID: Hi all, Just a quick note to let you that I completed the translation of what was available to translate on Zanata. Can you please check it passes the QA, that the strings available on Zanata are the latest ones, and that it can flow back into RHEL7? Regards, J. -- J?r?me Fenal From npmccallum at redhat.com Mon Feb 29 22:35:31 2016 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 29 Feb 2016 17:35:31 -0500 Subject: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators In-Reply-To: <56D0062A.6060706@redhat.com> References: <1456104026.2488.15.camel@redhat.com> <1456105856.6599.132.camel@redhat.com> <1456325710.3148.10.camel@redhat.com> <1456414375.3074.10.camel@redhat.com> <1456415388.6599.305.camel@redhat.com> <1456420747.3074.24.camel@redhat.com> <1456434812.3074.31.camel@redhat.com> <1456437087.6599.345.camel@redhat.com> <56D0062A.6060706@redhat.com> Message-ID: <1456785331.2643.1.camel@redhat.com> On Fri, 2016-02-26 at 09:00 +0100, Martin Kosek wrote: > On 02/25/2016 10:51 PM, Simo Sorce wrote: > > > > On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote: > > > > > > On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote: > > > > > > > > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/npmccallum/freeipa/pull/1 > > > > > > > > > > > > > > > > > > The above (pseudo) pull request contains four patches > > > > > > > > > against > > > > > > > > > FreeIPA > > > > > > > > > to enable the insertion of Authentication Indicators > > > > > > > > > into > > > > > > > > > Kerberos > > > > > > > > > tickets. The basic flow looks like this. > > > > > > > > > > > > > > > > > > First, we patch ipa-pwd-extop to return a control > > > > > > > > > indicating > > > > > > > > > what > > > > > > > > > authentication method succeeded resulting in a > > > > > > > > > successful > > > > > > > > > bind. > > > > > > > > > > > > > > > > > > Second, we patch ipa-otpd to check the returned > > > > > > > > > control to > > > > > > > > > ensure > > > > > > > > > that > > > > > > > > > the bind resulted from an otp validation. > > > > > > > > > > > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return > > > > > > > > > either > > > > > > > > > the > > > > > > > > > encrypted timestamp or encrypted challenge preauth > > > > > > > > > mechanism > > > > > > > > > when > > > > > > > > > the > > > > > > > > > user is configured for optional 2FA logins. Clients > > > > > > > > > can > > > > > > > > > then > > > > > > > > > decide > > > > > > > > > whether to do 1FA or 2FA login (for kinit, sane > > > > > > > > > behavior > > > > > > > > > already > > > > > > > > > exists). > > > > > > > > > > > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded > > > > > > > > > authentication > > > > > > > > > indicators for either OTP or RADIUS. > > > > > > > > > > > > > > > > > > Some explanation is required for the first two > > > > > > > > > patches. > > > > > > > > > Currently, > > > > > > > > > it > > > > > > > > > is possible to do a 1FA through the otp > > > > > > > > > preauthentication > > > > > > > > > mechanism > > > > > > > > > if > > > > > > > > > the user is configured for doing optional 2FA. > > > > > > > > > However, > > > > > > > > > because > > > > > > > > > we > > > > > > > > > want > > > > > > > > > to insert an authentication indicator in this code > > > > > > > > > path, we > > > > > > > > > need > > > > > > > > > to > > > > > > > > > guarantee that a request going through the otp > > > > > > > > > preauth > > > > > > > > > mechanism > > > > > > > > > actually validates an OTP. This is the purpose of the > > > > > > > > > control. > > > > > > > > > > > > > > > > > > Items still on the TODO list: > > > > > > > > > > > > > > > > > > ? * Authentication Indicator enforcement > > > > > > > > > ????- Upstream libkrb5 needs to grow funcs for > > > > > > > > > reading > > > > > > > > > indicators > > > > > > > > > ????- Schema change to add indicators multi-value > > > > > > > > > attr to > > > > > > > > > services > > > > > > > > > ????- ipa-kdb needs to implement check_policy_tgs() > > > > > > > > > > > > > > > > > > > > > > > > > > > ? * SSSD needs to learn to handle optional 2FA > > > > > > > > > > > > > > > > > > I will write up a project page for all of this > > > > > > > > > tomorrow. > > > > > > > > > But > > > > > > > > > this > > > > > > > > > small > > > > > > > > > code basically amounts to my brainstorming. It is not > > > > > > > > > ready > > > > > > > > > for > > > > > > > > > merge, > > > > > > > > > just basic review. > > > > > > > > > > > > > > > > > It looks mostly ok, however the LDAP control part needs > > > > > > > > to be > > > > > > > > done > > > > > > > > as > > > > > > > > a > > > > > > > > request/response pair. > > > > > > > > A client that wishes to know what kind of > > > > > > > > authentication > > > > > > > > happened > > > > > > > > should > > > > > > > > send a request control, and only in that case , the > > > > > > > > server > > > > > > > > will > > > > > > > > send > > > > > > > > the > > > > > > > > associated reply control with the requested > > > > > > > > information. > > > > > > > I just pushed a new version of the control (now merged > > > > > > > into a > > > > > > > single > > > > > > > patch): https://github.com/npmccallum/freeipa/commit/a781 > > > > > > > 91ee5d > > > > > > > 31 > > > > > > > e1de > > > > > > > 39 > > > > > > > f28eb637f66199da7e9225 > > > > > > > > > > > > > > In this version the client sends a critical control with > > > > > > > no > > > > > > > content > > > > > > > indicating that the server must validate an OTP. If the > > > > > > > LDAP > > > > > > > server > > > > > > > doesn't support the control (for whatever reason), bind > > > > > > > will > > > > > > > fail. If > > > > > > > the LDAP server doesn't validate an OTP (for whatever > > > > > > > reason), > > > > > > > bind > > > > > > > will fail. > > > > > > > > > > > > > > This approach is simpler and doesn't require a > > > > > > > request/response > > > > > > > control > > > > > > > pair. > > > > > > I need some design advice. My goal here is that we need a > > > > > > way to > > > > > > expose > > > > > > the authentication indicators to services in the FreeIPA > > > > > > UI/CLI. > > > > > > > > > > > > Here is the good news: users can already set these values > > > > > > in > > > > > > FreeIPA > > > > > > using kadmin. They do this by simply setting the > > > > > > require_auth > > > > > > string on > > > > > > the target service principal. Our kdb plugin then encodes > > > > > > these > > > > > > with > > > > > > the rest of the tl_data into the krbExtraData attribute. > > > > > > > > > > > > I see two approaches here. First, we can try to manipulate > > > > > > the > > > > > > krbExtraData attribute directly. Second, we can create a > > > > > > separate > > > > > > attribute for the authentication indicator strings and then > > > > > > synthesize > > > > > > the tl_data internally in kdb. We would have to do this for > > > > > > both > > > > > > reads > > > > > > and writes so as not to break existing kdb functionality. > > > > > > > > > > > > The trade-off that I see is that the first method > > > > > > complicates the > > > > > > python framework side where the second method complicates > > > > > > the kdb > > > > > > plugin. > > > > > > > > > > > > A third option, which I doubt is even possible, is to use > > > > > > kadmin > > > > > > to > > > > > > manipulate this option rather than modifying LDAP directly. > > > > > > > > > > > > Thoughts? > > > > > We should translate it, we need that to allow to delegate > > > > > access > > > > > only > > > > > to > > > > > the specific attribute via our standard means. > > > > > > > > > > We already do this for other tl_data entries. > > > > > > > > > > The krbExtraData access cannot always be delegated because it > > > > > would > > > > > be > > > > > open ended. also it is really obnoxious to have to manipulate > > > > > ASN.1 > > > > > stuff in the framework. > > > > > > > > > > kadmin could be used at some point, but we'd still want to > > > > > have > > > > > this > > > > > attribute extracted in order to be able to grant access > > > > > control > > > > > individually, as our ACL system and delegation system is more > > > > > fine > > > > > grained than what kadmin can offer. > > > > After discussing this with MIT, Simo and Matt, it seems that > > > > the best > > > > option is to update the (MIT) upstream krbPrincipal objectClass > > > > to > > > > have > > > > a new attribute. The reason for this is twofold. First, it has > > > > upstream > > > > value. Second, we don't have good objectClass to attach the new > > > > attribute to inside FreeIPA. > > > > > > > > So the current plan is that Matt will create a patch for > > > > storing auth > > > > indicators (specifically, the "required_auth" strings) in a new > > > > multi- > > > > value string attribute on krbPrincipal objects. The > > > > get_principal() > > > > KDB > > > > hook will read "required_auth" from krbExtraData or (if > > > > present, > > > > preferred) the new attribute. In turn, the put_principal() KDB > > > > hook > > > > will store "required_auth" in the new attribute. This will > > > > allow the > > > > transparent migration of any data currently stored in > > > > krbExtraData. > > > > > > > > As part of this process, Matt will also refactor > > > > put_principal() into > > > > smaller functions (it is currently 800+ LOC). > > > > > > > > Once we have an attribute in upstream krbPrincipal, we will use > > > > this > > > > attribute exclusively in our KDB plugin. > > > I have started a project page: > > > http://www.freeipa.org/page/V4/AuthenticationIndicators > Thanks Nathaniel! For starters, I moved the page to > http://www.freeipa.org/page/V4/Authentication_Indicators > to make sure the URL is consistent with other pages ;-) > > I also updated the Use Cases and added the User Story I am tracking > with this > feature: > http://www.freeipa.org/page/V4/Authentication_Indicators#Strong_Authe > ntication_on_Selected_System > > > > > > > > > We are still waiting on some details. But the general shape of > > > things > > > is there. Please review. :) > > LGTM so far. > > > > Questions: > > - Should the control specify what kind of auth specifically should > > be > > required ? > > > > - Will it make sense in future to have different strength otp-like > > second factors and have ipa-otpd be able to specify which one it is > > expecting to be validated ? > > > > - Even if ipa-otpd will not grow such a feature, I see this control > > could be useful for pure LDAP auth clients, so perhaps a different > > kind > > of client may want to set this control ? Perhaps one day we can > > have a > > way to do GSSAPI auth and check that the AI on the ldap ticket was > > a 2FA > > and then DS will refuse login if the otp AI was missing on the > > ticket it > > received and the control requires it ? (could be used for the IPA > > UI > > connection to LDAP maybe ?) > It would be also nice to add some graph how the workflows look like. > It may be > something based on Simo's picture he created some time back > (attached). How's this (attached)? -------------- next part -------------- A non-text attachment was scrubbed... Name: indicators.png Type: image/png Size: 79761 bytes Desc: not available URL: