From pviktori at redhat.com Thu Aug 1 12:54:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Aug 2013 14:54:25 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Handle --subject option in ipa-server-install In-Reply-To: <51F8DE33.50801@redhat.com> References: <51F778EA.7040305@redhat.com> <51F7E8C7.2000705@redhat.com> <51F8DE33.50801@redhat.com> Message-ID: <51FA5A81.8070904@redhat.com> On 07/31/2013 11:51 AM, Ana Krivokapic wrote: > On 07/30/2013 06:24 PM, Petr Viktorin wrote: >> On 07/30/2013 10:27 AM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3783. >>> >> >> Thanks for the patch, I have a concern below: >> >>> freeipa-akrivoka-0051-Handle-subject-option-in-ipa-server-install.patch >>> diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig >>> index >>> de17c5b23d79f31e8571a3400d44397630cadada..a2625e6198bcff0811c482e479c8af10716dcea1 >>> 100644 >>> --- a/install/tools/ipa-upgradeconfig >>> +++ b/install/tools/ipa-upgradeconfig >>> @@ -894,6 +895,7 @@ def main(): >>> configured_constants = dogtag.configured_constants() >>> sub_dict = dict( >>> REALM=api.env.realm, >>> + SUBJECT_BASE=str(DN(('O', api.env.realm))), >> >> When certmap.conf.template's version changes again, this will rewrite the >> subject to the default. Don't we want to use the subject base also here? >> >> >> > > You are right. The updated patch uses the current value of subject base from > LDAP to update certmap.conf during upgrades. When ipa-upgradeconfig is run while the DS is down, this results in a small warning, and very bad configuration: certmap ipaca CN=Certificate Authority,None I'm not sure how this should be handled. I'm adding Rob to the loop. Rob, can we start the DS in ipa-upgradeconfig? That sounds quite heavy-handed for a RPM upgrade script. Maybe if the DS is unavailable, we should use the old value from the config file itself. -- Petr? From mkosek at redhat.com Thu Aug 1 12:58:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 01 Aug 2013 14:58:33 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Handle --subject option in ipa-server-install In-Reply-To: <51FA5A81.8070904@redhat.com> References: <51F778EA.7040305@redhat.com> <51F7E8C7.2000705@redhat.com> <51F8DE33.50801@redhat.com> <51FA5A81.8070904@redhat.com> Message-ID: <51FA5B79.8090406@redhat.com> On 08/01/2013 02:54 PM, Petr Viktorin wrote: > On 07/31/2013 11:51 AM, Ana Krivokapic wrote: >> On 07/30/2013 06:24 PM, Petr Viktorin wrote: >>> On 07/30/2013 10:27 AM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3783. >>>> >>> >>> Thanks for the patch, I have a concern below: >>> >>>> freeipa-akrivoka-0051-Handle-subject-option-in-ipa-server-install.patch >>>> diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig >>>> index >>>> de17c5b23d79f31e8571a3400d44397630cadada..a2625e6198bcff0811c482e479c8af10716dcea1 >>>> >>>> 100644 >>>> --- a/install/tools/ipa-upgradeconfig >>>> +++ b/install/tools/ipa-upgradeconfig >>>> @@ -894,6 +895,7 @@ def main(): >>>> configured_constants = dogtag.configured_constants() >>>> sub_dict = dict( >>>> REALM=api.env.realm, >>>> + SUBJECT_BASE=str(DN(('O', api.env.realm))), >>> >>> When certmap.conf.template's version changes again, this will rewrite the >>> subject to the default. Don't we want to use the subject base also here? >>> >>> >>> >> >> You are right. The updated patch uses the current value of subject base from >> LDAP to update certmap.conf during upgrades. > > When ipa-upgradeconfig is run while the DS is down, this results in a small > warning, and very bad configuration: > certmap ipaca CN=Certificate Authority,None > > > I'm not sure how this should be handled. I'm adding Rob to the loop. > Rob, can we start the DS in ipa-upgradeconfig? That sounds quite heavy-handed > for a RPM upgrade script. > > Maybe if the DS is unavailable, we should use the old value from the config > file itself. Values can be stored/restored using a sysupgrade module. I would not be so afraid of starting the DS module, we already do that exercise in ipa-ldap-updater, so adding it in ipa-upgradeconfig too does not change much. Question is, what should we do what DS cannot be started or cannot be read (e.g. when upgrade is run in fedup's chrooted environment) - we must make sure we don't mess the configuration up. Martin From pviktori at redhat.com Thu Aug 1 13:15:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Aug 2013 15:15:41 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Handle --subject option in ipa-server-install In-Reply-To: <51FA5B79.8090406@redhat.com> References: <51F778EA.7040305@redhat.com> <51F7E8C7.2000705@redhat.com> <51F8DE33.50801@redhat.com> <51FA5A81.8070904@redhat.com> <51FA5B79.8090406@redhat.com> Message-ID: <51FA5F7D.30503@redhat.com> On 08/01/2013 02:58 PM, Martin Kosek wrote: > On 08/01/2013 02:54 PM, Petr Viktorin wrote: >> On 07/31/2013 11:51 AM, Ana Krivokapic wrote: >>> On 07/30/2013 06:24 PM, Petr Viktorin wrote: >>>> On 07/30/2013 10:27 AM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3783. >>>>> >>>> >>>> Thanks for the patch, I have a concern below: >>>> >>>>> freeipa-akrivoka-0051-Handle-subject-option-in-ipa-server-install.patch >>>>> diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig >>>>> index >>>>> de17c5b23d79f31e8571a3400d44397630cadada..a2625e6198bcff0811c482e479c8af10716dcea1 >>>>> >>>>> 100644 >>>>> --- a/install/tools/ipa-upgradeconfig >>>>> +++ b/install/tools/ipa-upgradeconfig >>>>> @@ -894,6 +895,7 @@ def main(): >>>>> configured_constants = dogtag.configured_constants() >>>>> sub_dict = dict( >>>>> REALM=api.env.realm, >>>>> + SUBJECT_BASE=str(DN(('O', api.env.realm))), >>>> >>>> When certmap.conf.template's version changes again, this will rewrite the >>>> subject to the default. Don't we want to use the subject base also here? >>>> >>>> >>>> >>> >>> You are right. The updated patch uses the current value of subject base from >>> LDAP to update certmap.conf during upgrades. >> >> When ipa-upgradeconfig is run while the DS is down, this results in a small >> warning, and very bad configuration: >> certmap ipaca CN=Certificate Authority,None >> >> >> I'm not sure how this should be handled. I'm adding Rob to the loop. >> Rob, can we start the DS in ipa-upgradeconfig? That sounds quite heavy-handed >> for a RPM upgrade script. >> >> Maybe if the DS is unavailable, we should use the old value from the config >> file itself. > > Values can be stored/restored using a sysupgrade module. The problem is that (AFAIK) old instances won't have this particular value stored. Upgrading from 3.1 to a future version where certmap.conf is modified again would fail. > I would not be so > afraid of starting the DS module, we already do that exercise in > ipa-ldap-updater, so adding it in ipa-upgradeconfig too does not change much. > > Question is, what should we do what DS cannot be started or cannot be read > (e.g. when upgrade is run in fedup's chrooted environment) - we must make sure > we don't mess the configuration up. Again AFAIK, if the server is down, certmap.conf is the only place where this value is available. I didn't check thoroughly, though. -- Petr? From pspacek at redhat.com Thu Aug 1 13:48:58 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 01 Aug 2013 15:48:58 +0200 Subject: [Freeipa-devel] [PATCH 0182] Fix false error messages when nonexistent object/attribute is deleted Message-ID: <51FA674A.5020708@redhat.com> Hello, Fix false error messages when nonexistent object/attribute is deleted. This patch should go to branches v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0182-Fix-false-error-messages-when-nonexistent-object-att.patch Type: text/x-patch Size: 1607 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 1 13:49:54 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 01 Aug 2013 15:49:54 +0200 Subject: [Freeipa-devel] [PATCH 0183] Move data structures for parser from ldap_qresult_t to ldap_entry_t Message-ID: <51FA6782.6060601@redhat.com> Hello, Move data structures for parser from ldap_qresult_t to ldap_entry_t. The target branch is master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0183-Move-data-structures-for-parser-from-ldap_qresult_t-.patch Type: text/x-patch Size: 12435 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 1 13:51:12 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 01 Aug 2013 15:51:12 +0200 Subject: [Freeipa-devel] [PATCH 0184] Use DNS_RDATA_MAXLENGTH from rdata.h instead of own definition Message-ID: <51FA67D0.4040103@redhat.com> Hello, Use DNS_RDATA_MAXLENGTH from rdata.h instead of own definition. This minor fix could go to v3 and master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0184-Use-DNS_RDATA_MAXLENGTH-from-rdata.h-instead-of-own-.patch Type: text/x-patch Size: 3062 bytes Desc: not available URL: From akrivoka at redhat.com Thu Aug 1 13:53:20 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 01 Aug 2013 15:53:20 +0200 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients Message-ID: <51FA6850.1050500@redhat.com> Hello, This patch adds ipa-advise plugins to help configure legacy clients for access to trusted domain resources. For more details, please read the commit message. Plugins are currently named "config-redhat-sssd-before-1-9" and "config-generic-sssd-before-1-9"; suggestions for better names are welcome. Plugin content heavily inspired by https://fedoraproject.org/wiki/QA:Testcase_freeipa_use_legacy_sssd_to_give_access_to_trusted_domain_users. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0052-Add-ipa-advise-plugins-for-legacy-clients.patch Type: text/x-patch Size: 8711 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 1 13:52:55 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 01 Aug 2013 15:52:55 +0200 Subject: [Freeipa-devel] [PATCH 0185] Do not execute new LDAP search for each updated object Message-ID: <51FA6837.60103@redhat.com> Hello, Do not execute new LDAP search for each updated object. Syncrepl delivers notification about change in particular object along with all data from the object. Resource Records are parsed out from this data instead of data obtained via separate LDAP search. Current code doesn't have any rate limitation. As a result, ldap_sync_init/poll() can enqueue update events faster than rest of BIND is able to dequeue and process them. Unprocessed events can consume significant amount of memory. This area definitely needs improvement. This is next in complete transition to RBTDB. It should go to master. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0185-Do-not-execute-new-LDAP-search-for-each-updated-obje.patch Type: text/x-patch Size: 9582 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 1 13:57:32 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 01 Aug 2013 15:57:32 +0200 Subject: [Freeipa-devel] [PATCH 0186-0189] Replace LDAP cache with RBTDB Message-ID: <51FA694C.1000302@redhat.com> Hello, attached monster patches replace our internal cache/database with RBTDB implementation. See commit messages and comments inside. This patch set provides very basic functionality (including DNS support for updates). Error handling definitely needs more love, but it should be enough for rapid DNSSEC prototyping. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0186-Use-RBTDB-instead-of-internal-LDAP-cache.patch Type: text/x-patch Size: 71350 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0187-Update-serial-after-each-change-in-zone.patch Type: text/x-patch Size: 4836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0188-Drop-old-LDAP-cache.patch Type: text/x-patch Size: 20492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0189-Add-support-for-write-back-to-LDAP-after-a-DNS-updat.patch Type: text/x-patch Size: 11300 bytes Desc: not available URL: From pviktori at redhat.com Thu Aug 1 13:57:35 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Aug 2013 15:57:35 +0200 Subject: [Freeipa-devel] Plugin registration API (Was: [PATCH] Return klass in api.register()) In-Reply-To: <1375289021.9252.51.camel@localhost> References: <1375197416.9252.0.camel@localhost> <51F7F0B2.6010402@redhat.com> <1375207538.9252.30.camel@localhost> <51F8D402.8060009@redhat.com> <1375289021.9252.51.camel@localhost> Message-ID: <51FA694F.8020108@redhat.com> On 07/31/2013 06:43 PM, Nathaniel McCallum wrote: > Mostly, we're agreed. This was mostly an inventory of approaches I've > seen in the Python world before. > > On Wed, 2013-07-31 at 11:08 +0200, Petr Viktorin wrote: >> On 07/30/2013 08:05 PM, Nathaniel McCallum wrote: >>> On Tue, 2013-07-30 at 18:58 +0200, Petr Viktorin wrote: >>>> On 07/30/2013 05:16 PM, Nathaniel McCallum wrote: >>>>> From 371e080fb6a86da6f0ec574c8cbc0d8d06c18c99 Mon Sep 17 00:00:00 2001 >>>>> From: Nathaniel McCallum >>>>> Date: Tue, 30 Jul 2013 11:13:55 -0400 >>>>> Subject: [PATCH] Return klass in api.register() >>>>> >>>>> This permits the use of api.register as a decorator. >>>> >>>> Thanks for the patch. >>>> Was there any discussion/reason for this? Can you file a ticket? >>>> I'm not opposed, I agree this would allow less typing for plugin authors. >>> >>> There was not really any discussion. I just simply noticed that a single >>> line change would make plugins a bit more pythonic. I mentioned it to >>> rcrit and he didn't see any problem with it. So I wrote the patch. >>> >>> Expressing registration as a decorator has numerous advantages, >>> including being less error prone and easier to read. But typing less is >>> probably a good enough reason. :) >>> >>> In my mind, this can be merged now since it doesn't break any backwards >>> compatibility and enables a syntax that is easier to modify in the >>> future. It is the migration from a function to a decorator that is where >>> all the work lies. Once you have decorators, you can fairly easily do a >>> sed replacement (or maintain backwards compatibility if you like). >> >> The patch is backwards compatible, but the new syntax is not forward >> compatible. You can't easily run sed on third-party plugins -- we want >> to switch just once. >> We should switch to supporting both the old and new syntax. An >> intermediate syntax that's better than the old one but not compatible >> with future plans isn't worth it. >> >> I can make a patch that adds my proposed syntax but keeps the old >> behavior. I'd like to get the design done first though. >> (And of course, the old syntax and functionality would still be supported) > > The *existing* syntax is not forward compatible. > > The current patch permits the use of decorators. It does NOT require the > migration to decorators. Any new code that is written with decorators > will be easier to migrate to the new API. Hence: > 1. Existing code stays the same and still works > 2. New code uses the decorator syntax > 3. New plugin api forces manual migration from #1 (hard) and #2 (easy) They're actually about the same level of easiness - deleting a line from below a class and adding one above the class is not hard. The main problem here is that someone has to look at the plugin and do the changes, and commit/deploy them. I'd like to skip this problem in the #2 case altogether. There are third-party plugins. We want to make these disruptions as infrequent as possible. > The cost/benefit analysis of my patch is: no cost, minor benefit. > > The only reason I can see not to merge this patch is if we would choose > a plugin registration system without decorators. This would make the > migration from #2 to #3 harder. Here is a patch that implements the API I proposed, but with old semantics. Plugins using this won't need to be rewritten when we switch the behavior as well. I've also converted one of the plugins to use this. If your approach is accepted please do this as well -- if we support an API we want it tested. >>>> I also think the plugin registration API needs a larger redesign, though >>>> I haven't shared my thoughts on it lately as there are more pressing >>>> things to do. I'll correct that now that there's (sort of) a thread on >>>> the topic :) >>>> >>>> Basically, my gripe is that plugin registration only works on the one >>>> global API object, ipalib.api. If you create a different API object, you >>>> can't register plugins on it. Different API object would be useful for >>>> testing, or for running IPA commands on another master (there's an ugly >>>> hack in ipa-replica-install that does that). >>>> >>>> A rough sketch of what I had in mind would be: >>>> >>>> plugin.py: >>>> # the "register" decorator will collect registered items; >>>> # it must be named "register" so the loading routine finds it >>>> register = plugable.Registry() >>>> >>>> @register >>>> class obj_mod(LDAPUpdate): >>>> .... >>>> >>>> plugable.py: >>>> class Registry: >>>> def __call__(self, item): >>>> self.items.append(item) >>>> >>>> class API: >>>> def load_plugin_package(self, package_name): >>>> plugin = __import__(package_name).register >>>> for item in register.items: >>>> self.register(item) >>>> >>>> Related ticket for this: https://fedorahosted.org/freeipa/ticket/3090 >>>> >>>> >>>> Maybe if we're giving an incentive for plugin authors to rewrite >>>> plugins, we should give them an API that's at least compatible with the >>>> above goals, so they won't have to rewrite again some time later. >>> >>> Having a registration collector as an independent object makes a lot of >>> sense. I also prefer type-safety to strings. >>> >>> Make sure you make the decorator a callable though. This permits you to >>> easily add options later without breaking backwards compatibility. >>> >>> You want: >>> @register() >>> class foo: >>> pass >>> >>> Not: >>> @register >>> class foo: >>> pass >> >> Fair point. >> >> So we're at: >> from ipalib.plugable import Registry >> >> register = Registry() >> >> @register() >> class object_mod(...) >> ... >> >>> Also, you can avoid the creation of a registry object for each plugin. >> >> But that is exactly what I want to do! I *want* a plugin module to just >> have a list of things it exports, and leave it to the consumer to load >> them if it wants to. > > Agreed. > >>> You can essentially do module cache poisoning to force an alternative >>> registry. This saves some typing and keeps the alternate code in the >>> same scope as the tests for that alternate path... >> >> Too much magic. I would really rather have things work as they normally >> do Python. Module cache poisoning is pretty tough on the reader. >> The extra line that you have to type keeps things clear and tells the >> reader where to look to see how things are done. >> >> I don't understand what exactly you mean by "alternate code" here? > > The difference here is keeping the registry instance where the plugins > are versus where the registry instance will actually be used. I don't > think it really matters. It is just what I've seen before. > >>> Lastly, you could use class hierarchy introspection to avoid >>> registration altogether. This has the advantage of some natural type >>> safety. >> >> Did you mean to look which classes in a module are Plugin subclasses? >> That would mean all plugins now have to be defined as top-level items in >> a module -- an unnecessary restriction. Doing anything else than a >> traditional plugin module would get unnecessarily complicated (e.g. >> creating plugins dynamically -- who knows what we'll need in the future?). >> Type safety is enforced by the API already. >> >> Or did you mean something like looking at Plugin.__subclasses__()? >> Assuming that all classes whose module happened to be loaded up to now >> need to be included in the API is extremely fragile. (This is another >> reason why the current registration sucks.) > > Plugin.__subclasses__() is what I was referring to. Plugins can get > loaded at any time with this approach (via import). They can't really be > unloaded easily though. You can compensate for this with > enabling/disabling. Plugins "silently" becoming available on import is something I really want to avoid - especially for the server plugins that don't tidily live in ipalib.plugins it's hard to (remember to) verify that each code path contains the right imports. (Speaking from my ipaldap refactoring experience.) Unloading plugins is against the current design, the API is immutable once initialized. > Again, I'm just describing what I've seen. The main > thing I like about this approach is the implied type safety. But I'm not > committed to this approach. The API already enforces types: all Command subclasses get assigned to the Command container etc. >> Let's just keep things explicit, please. > > Agreed. Explicit is almost always better, unless there is some other > obvious trade-off. > > Nathaniel > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0266-Allow-API-plugin-registration-via-a-decorator.patch Type: text/x-patch Size: 2839 bytes Desc: not available URL: From abokovoy at redhat.com Thu Aug 1 14:13:07 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Aug 2013 17:13:07 +0300 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <51FA6850.1050500@redhat.com> References: <51FA6850.1050500@redhat.com> Message-ID: <20130801141307.GO15859@redhat.com> Hi! On Thu, 01 Aug 2013, Ana Krivokapic wrote: >Hello, > >This patch adds ipa-advise plugins to help configure legacy clients for access >to trusted domain resources. For more details, please read the commit message. >Plugins are currently named "config-redhat-sssd-before-1-9" and >"config-generic-sssd-before-1-9"; suggestions for better names are welcome. > >Plugin content heavily inspired by >https://fedoraproject.org/wiki/QA:Testcase_freeipa_use_legacy_sssd_to_give_access_to_trusted_domain_users. I think it is a good start. Comments inline. >https://fedorahosted.org/freeipa/ticket/3671 >--- > install/share/Makefile.am | 2 + > install/share/pam.conf.template | 22 ++++++ > install/share/sssd.conf.template | 12 +++ I would imagine we would have multiple plugins that need their own templates for pam.conf/sssd.conf. What about introducing install/share/advise//*.template to avoid conflicts? In this case you use the same templates for both plugins so you might have as 'legacy', for example. Another way is to have plugin name in the template, e.g. legacy.sssd.conf.template. >+class config_redhat_sssd_before_1_9(Advice): >+ """ >+ Legacy client configuration for Red Hat based platforms. >+ """ >+ >+ description = ('Instructions for configuring a system with an old version ' >+ 'of SSSD (1.5-1.8) as a FreeIPA client. This set of ' >+ 'instructions is targeted for platforms that include ' >+ 'the authconfig utility, which are all Red Hat based ' >+ 'platforms.') You need to check that Schema Compatibility plugin is configured to serve trusted domain users and groups. We have two trees: dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config In both of the trees there should be schema-compat-lookup-sssd: attribute, with the value according to the tree (i.e. user for cn=users). If not, then suggest to run 'ipa-adtrust-install --enable-compat=true' on the IPA server. >+ >+ def get_info(self): >+ self.log.comment('Install the sssd and authconfig packages via yum') >+ self.log.command('yum install -y sssd authconfig\n') You are using 'wget' below, it might make sense to add it into the above line too. >+ >+ self.log.comment('Download the CA certificate of the IPA server') >+ self.log.command('mkdir -p -m 755 /etc/openldap/cacerts') >+ self.log.command('wget http://%s/ipa/config/ca.crt -O ' >+ '/etc/openldap/cacerts/ipa.crt\n' % api.env.host) >+ >+ self.log.comment('Generate hashes for the openldap library') >+ self.log.command('cacertdir_rehash /etc/openldap/cacerts/\n') >+ >+ self.log.comment('Use the authconfig to configure nsswitch.conf ' >+ 'and the PAM stack') >+ self.log.command('authconfig --updateall --enablesssd ' >+ '--enablesssdauth\n') >+ >+ self.log.comment('Configure SSSD') >+ self.log.command('cat > /etc/sssd/sssd.conf << EOF \n' >+ '%s\nEOF' % generate_sssd_conf()) >+ self.log.command('chmod 0600 /etc/sssd/sssd.conf\n') >+ >+ self.log.comment('Start SSSD') >+ self.log.command('service sssd start') Would it make sense to also add instructions to restore SELinux context (if needed)? I'm not sure, just throwing the idea for consideration. Same comments go for the second plugin. -- / Alexander Bokovoy From rcritten at redhat.com Thu Aug 1 14:52:28 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Aug 2013 10:52:28 -0400 Subject: [Freeipa-devel] [PATCH] 0051 Handle --subject option in ipa-server-install In-Reply-To: <51FA5F7D.30503@redhat.com> References: <51F778EA.7040305@redhat.com> <51F7E8C7.2000705@redhat.com> <51F8DE33.50801@redhat.com> <51FA5A81.8070904@redhat.com> <51FA5B79.8090406@redhat.com> <51FA5F7D.30503@redhat.com> Message-ID: <51FA762C.8090909@redhat.com> Petr Viktorin wrote: > On 08/01/2013 02:58 PM, Martin Kosek wrote: >> On 08/01/2013 02:54 PM, Petr Viktorin wrote: >>> On 07/31/2013 11:51 AM, Ana Krivokapic wrote: >>>> On 07/30/2013 06:24 PM, Petr Viktorin wrote: >>>>> On 07/30/2013 10:27 AM, Ana Krivokapic wrote: >>>>>> Hello, >>>>>> >>>>>> This patch addresses ticket >>>>>> https://fedorahosted.org/freeipa/ticket/3783. >>>>>> >>>>> >>>>> Thanks for the patch, I have a concern below: >>>>> >>>>>> freeipa-akrivoka-0051-Handle-subject-option-in-ipa-server-install.patch >>>>>> >>>>>> diff --git a/install/tools/ipa-upgradeconfig >>>>>> b/install/tools/ipa-upgradeconfig >>>>>> index >>>>>> de17c5b23d79f31e8571a3400d44397630cadada..a2625e6198bcff0811c482e479c8af10716dcea1 >>>>>> >>>>>> >>>>>> 100644 >>>>>> --- a/install/tools/ipa-upgradeconfig >>>>>> +++ b/install/tools/ipa-upgradeconfig >>>>>> @@ -894,6 +895,7 @@ def main(): >>>>>> configured_constants = dogtag.configured_constants() >>>>>> sub_dict = dict( >>>>>> REALM=api.env.realm, >>>>>> + SUBJECT_BASE=str(DN(('O', api.env.realm))), >>>>> >>>>> When certmap.conf.template's version changes again, this will >>>>> rewrite the >>>>> subject to the default. Don't we want to use the subject base also >>>>> here? >>>>> >>>>> >>>>> >>>> >>>> You are right. The updated patch uses the current value of subject >>>> base from >>>> LDAP to update certmap.conf during upgrades. >>> >>> When ipa-upgradeconfig is run while the DS is down, this results in a >>> small >>> warning, and very bad configuration: >>> certmap ipaca CN=Certificate Authority,None >>> >>> >>> I'm not sure how this should be handled. I'm adding Rob to the loop. >>> Rob, can we start the DS in ipa-upgradeconfig? That sounds quite >>> heavy-handed >>> for a RPM upgrade script. >>> >>> Maybe if the DS is unavailable, we should use the old value from the >>> config >>> file itself. >> >> Values can be stored/restored using a sysupgrade module. > > The problem is that (AFAIK) old instances won't have this particular > value stored. Upgrading from 3.1 to a future version where certmap.conf > is modified again would fail. > >> I would not be so >> afraid of starting the DS module, we already do that exercise in >> ipa-ldap-updater, so adding it in ipa-upgradeconfig too does not >> change much. >> >> Question is, what should we do what DS cannot be started or cannot be >> read >> (e.g. when upgrade is run in fedup's chrooted environment) - we must >> make sure >> we don't mess the configuration up. > > Again AFAIK, if the server is down, certmap.conf is the only place where > this value is available. I didn't check thoroughly, though. I think that's right. So the big problem here is we have no way of alerting users to possible problems found during the upgrade unless they happen to sift through ipaupgrade.log, which tends to be huge, and most users don't even know about. Part of this is due to not displaying anything during an rpm upgrade. I think we should print any exceptional errors found during the upgrade. Sure, something may eat the output, but it's a best effort sort of thing. I don't see us finding a perfect solution here. What I'd propose is this: - Store the value in sysupgrade from now on, even in new installs - Look there first on upgrade - Start dirsrv if necessary get the value - If we can't get the value, skip changing file and log loudly - Find out exactly this will present to a user by doing an upgrade from an old version to master and create an FAQ entry. I think that's about the best we can do. rob From pviktori at redhat.com Thu Aug 1 14:52:53 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Aug 2013 16:52:53 +0200 Subject: [Freeipa-devel] [PATCHES] 0258-0265 Add schema updater based on IPA schema files Message-ID: <51FA7645.6090702@redhat.com> Hello, With these patches, schema updates will be based on the ldif files we use for installation. https://fedorahosted.org/freeipa/ticket/3454 This is a RFE, here is the design doc: http://www.freeipa.org/page/V3/Improved_schema_updater -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0258-ldapupdate-Factor-out-connection-code.patch Type: text/x-patch Size: 4845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0259-dsinstance-Move-the-list-of-schema-filenames-to-a-co.patch Type: text/x-patch Size: 2098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0260-Add-schema-updater-based-on-IPA-schema-files.patch Type: text/x-patch Size: 13113 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0261-Update-the-man-page-for-ipa-ldap-updater.patch Type: text/x-patch Size: 2118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0262-Remove-schema-modifications-from-update-files.patch Type: text/x-patch Size: 57061 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0263-Remove-schema-special-casing-from-the-LDAP-updater.patch Type: text/x-patch Size: 10050 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0264-Make-schema-files-conform-to-new-updater.patch Type: text/x-patch Size: 27262 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0265-Add-formerly-update-only-schema.patch Type: text/x-patch Size: 10403 bytes Desc: not available URL: From nalin at redhat.com Thu Aug 1 20:00:47 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 1 Aug 2013 16:00:47 -0400 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130731125321.GN15859@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> Message-ID: <20130801200047.GB3268@redhat.com> On Wed, Jul 31, 2013 at 03:53:21PM +0300, Alexander Bokovoy wrote: > Authentication is handled for both IPA and trusted domain users. The > former case requires some specific handling of the SLAPI_BIND_TARGET_SDN > to rewrite it to the original entry's DN. As result successful bind > looks like this in the dirsrv logs: > [31/Jul/2013:15:49:03 +0300] conn=15 fd=79 slot=79 SSL connection from 192.168.111.216 to 192.168.111.216 > [31/Jul/2013:15:49:03 +0300] conn=15 SSL 256-bit AES > [31/Jul/2013:15:49:03 +0300] conn=15 op=0 BIND dn="uid=admin,cn=users,cn=compat,dc=example,dc=com" method=128 version=3 > [31/Jul/2013:15:49:03 +0300] conn=15 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=foobar)" attrs=ALL > [31/Jul/2013:15:49:03 +0300] conn=15 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" The RESULT dn being different from the BIND dn is easy to miss, but it should prevent possible problems where a given user can be bound to more than one DN, depending on where they started, so I guess it's fine. On to specific patches: HEAD~11 looks fine. HEAD~10: * Add internal whitespace when computing the value to pass to slapi_ch_malloc(). * Break the declaration and initialization of "str" into two lines. * Use '\0' to terminate str instead of 0. * In the new comment in format.h, NULL should be NUL. HEAD~9 looks fine. HEAD~8: * In configure.in, drop the hunk that changes the version number that we pass to AC_INIT. * In configure.in, one test compares x$use_sss_nss_idmap != xno, while one shortly after compares $use_sss_nss_idmap = yes. If $use_sss_nss_idmap can be empty, then the second test needs to be ready for that. * The help text still refers to SSSD specifically, when the code doesn't enforce or guarantee that SSSD's involved when performing nsswitch lookups or PAM authentication. HEAD~7: * Fix formatting of wrapped lines when calling backend_shr_get_vattr_str(). * Check for errors when converting the configured sssd_min_id to a number by switching from atol() to strtol() or strtoul(). HEAD~6: * Drop extra whitespace after the type of the "name" member when defining struct backend_search_filter_config. * backend_search_filter_has_cn_uid() allocates config->name using slapi_ch_malloc(), but it is later freed by free(). * backend_retrieve_user_entry_from_sssd(): fix line wrapping in function signature. * backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. * backend_retrieve_user_entry_from_sssd(): avoid using slapi_entry_attr_set_int(), which will treat an unsigned 32-bit with the high bit set as a negative value * backend_retrieve_user_entry_from_sssd(): check for zero-length pw_shell value, and avoid adding it as a loginShell value, since that'd be invalid * backend_retrieve_user_entry_from_sssd() adds "ipaNTUserAttrs" as an objectClass in the temporary entry, but the value isn't copied into the cache. What purpose does it serve? * backend_retrieve_user_entry_from_sssd(): extra whitespace when constructing the new entry's DN. * backend_retrieve_user_entry_from_sssd(): memory leak from not freeing the result of slapi_escape_filter_value(). * backend_retrieve_group_entry_from_sssd(): fix line wrapping in function signature. * backend_retrieve_group_entry_from_sssd() needs to handle ERANGE errors. * backend_retrieve_group_entry_from_sssd(): extra whitespace when constructing the new entry's DN. * backend_retrieve_group_entry_from_sssd(): memory leak from not freeing the result of slapi_escape_filter_value(). * backend_retrieve_group_entry_from_sssd() adds "ipaNTGroupAttrs" as an objectClass in the temporary entry, but the value isn't copied into the cache. What purpose does it serve? * backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors. * backend_retrieve_group_entry_from_sssd(): avoid using slapi_entry_attr_set_int(), which will treat an unsigned 32-bit with the high bit set as a negative value * backend_retrieve_group_list_from_sssd(): check for NULL result from realloc(). * backend_search_sssd(): fix line wrapping for call to slapi_filter_apply(). * backend_search_sssd(): use strtol() or strtoul() to convert a value to a number, and check for errors. * backend_search_sssd(): staged->container_sdn/map_group/map_set are allocated with slapi_ch_strdup() but freed with free() later. * backend_retrieve_from_sssd(): check for NULL result from malloc(). * backend_retrieve_from_sssd(): fix line wrapping for calls to backend_retrieve_user/group_entry_from_sssd. HEAD~5: * free_pam_response() uses slapi_ch_free() to free memory that was probably allocated with malloc(). * pam_conv_func(): remove extra whitespace in call to slapi_pblock_get() * pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate replies, because plugins tend to be use free() to free them. * pam_conv_func(): replace if/else-if/else-if/else-if stacks with a switch() statement. * do_pam_auth(): fix line wrapping in function signature. * do_pam_auth(): comments suggest that it's just entered or left a critical section, when the function's been called in one. * do_pam_auth(): replace if/else-if/else-if/else-if stacks with a switch() statement. * do_pam_auth(): fix line wrapping when calling PR_smprintf(). HEAD~4: * Also needs to add back-sch.h to nisserver_plugin_la_SOURCES. HEAD~3: * backend_search_find_set_data_in_group_cb(): fix line wrapping in function signature. * backend_search_cb() looks like it'll leak staged->entries[i] if another thread has added a similarly-named entry to the cache. * backend_search_cb() now appears to be freeing the closest-match as part of a conditional clause, right before it would unconditionally do so. * backend_search_cb() doesn't need to cast cbdata.sssd_buffer_len before comparing it to -1. HEAD~2: * backend_bind_cb() allocates strings with slapi_ch_strdup() and slapi_entry_attr_get_charptr() but frees them with free(). * backend_bind_cb() should avoid having to cast away a "const" by using non-const variables for the saved copies of the group and set names. HEAD~1: * Drop the version number change. HEAD: * Doesn't mention the PAM service used for authentication, which it probably should. Still, a good start. Thanks, Nalin From abokovoy at redhat.com Fri Aug 2 05:52:28 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Aug 2013 08:52:28 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130801200047.GB3268@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> <20130801200047.GB3268@redhat.com> Message-ID: <20130802055228.GP15859@redhat.com> Hi Nalin! Thanks for the review. On Thu, 01 Aug 2013, Nalin Dahyabhai wrote: >On Wed, Jul 31, 2013 at 03:53:21PM +0300, Alexander Bokovoy wrote: >> Authentication is handled for both IPA and trusted domain users. The >> former case requires some specific handling of the SLAPI_BIND_TARGET_SDN >> to rewrite it to the original entry's DN. As result successful bind >> looks like this in the dirsrv logs: >> [31/Jul/2013:15:49:03 +0300] conn=15 fd=79 slot=79 SSL connection from 192.168.111.216 to 192.168.111.216 >> [31/Jul/2013:15:49:03 +0300] conn=15 SSL 256-bit AES >> [31/Jul/2013:15:49:03 +0300] conn=15 op=0 BIND dn="uid=admin,cn=users,cn=compat,dc=example,dc=com" method=128 version=3 >> [31/Jul/2013:15:49:03 +0300] conn=15 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=foobar)" attrs=ALL >> [31/Jul/2013:15:49:03 +0300] conn=15 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" > >The RESULT dn being different from the BIND dn is easy to miss, but it >should prevent possible problems where a given user can be bound to more >than one DN, depending on where they started, so I guess it's fine. Yes. Frankly, I don't see any other way to handle this authentication correctly. >On to specific patches: >HEAD~11 looks fine. >HEAD~10: >* Add internal whitespace when computing the value to pass to > slapi_ch_malloc(). >* Break the declaration and initialization of "str" into two lines. >* Use '\0' to terminate str instead of 0. >* In the new comment in format.h, NULL should be NUL. done >HEAD~9 looks fine. >HEAD~8: >* In configure.in, drop the hunk that changes the version number that we > pass to AC_INIT. >* In configure.in, one test compares x$use_sss_nss_idmap != xno, while > one shortly after compares $use_sss_nss_idmap = yes. If > $use_sss_nss_idmap can be empty, then the second test needs to be > ready for that. >* The help text still refers to SSSD specifically, when the code doesn't > enforce or guarantee that SSSD's involved when performing nsswitch > lookups or PAM authentication. The whole setup really makes sense only when SSSD is in use. Aside from that, the whole setup is triggered only if we find libsss_nss_idmap library which is provided by SSSD. Yes, it is used for an optional adding of the SID but linking is explicit. Due to these reasons I has left the text there and added small mentioning of nsswitch interface. >HEAD~7: >* Fix formatting of wrapped lines when calling backend_shr_get_vattr_str(). >* Check for errors when converting the configured sssd_min_id to a number > by switching from atol() to strtol() or strtoul(). done. >HEAD~6: >* Drop extra whitespace after the type of the "name" member when > defining struct backend_search_filter_config. >* backend_search_filter_has_cn_uid() allocates config->name using > slapi_ch_malloc(), but it is later freed by free(). >* backend_retrieve_user_entry_from_sssd(): fix line wrapping in > function signature. >* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. >* backend_retrieve_user_entry_from_sssd(): avoid using > slapi_entry_attr_set_int(), which will treat an unsigned 32-bit > with the high bit set as a negative value >* backend_retrieve_user_entry_from_sssd(): check for zero-length > pw_shell value, and avoid adding it as a loginShell value, since > that'd be invalid all done. >* backend_retrieve_user_entry_from_sssd() adds "ipaNTUserAttrs" as an > objectClass in the temporary entry, but the value isn't copied into > the cache. What purpose does it serve? I removed this part since we are anyway using extensibleObject for the generated entry. >* backend_retrieve_user_entry_from_sssd(): extra whitespace when > constructing the new entry's DN. >* backend_retrieve_user_entry_from_sssd(): memory leak from not freeing > the result of slapi_escape_filter_value(). >* backend_retrieve_group_entry_from_sssd(): fix line wrapping in > function signature. >* backend_retrieve_group_entry_from_sssd() needs to handle ERANGE errors. >* backend_retrieve_group_entry_from_sssd(): extra whitespace when > constructing the new entry's DN. >* backend_retrieve_group_entry_from_sssd(): memory leak from not freeing > the result of slapi_escape_filter_value(). all done >* backend_retrieve_group_entry_from_sssd() adds "ipaNTGroupAttrs" as an > objectClass in the temporary entry, but the value isn't copied into > the cache. What purpose does it serve? I removed this part since we are anyway using extensibleObject for the generated entry >* backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors. >* backend_retrieve_group_entry_from_sssd(): avoid using > slapi_entry_attr_set_int(), which will treat an unsigned 32-bit > with the high bit set as a negative value >* backend_retrieve_group_list_from_sssd(): check for NULL result from > realloc(). >* backend_search_sssd(): fix line wrapping for call to > slapi_filter_apply(). >* backend_search_sssd(): use strtol() or strtoul() to convert a value to > a number, and check for errors. >* backend_search_sssd(): staged->container_sdn/map_group/map_set are > allocated with slapi_ch_strdup() but freed with free() later. >* backend_retrieve_from_sssd(): check for NULL result from malloc(). >* backend_retrieve_from_sssd(): fix line wrapping for calls to > backend_retrieve_user/group_entry_from_sssd. all done >HEAD~5: >* free_pam_response() uses slapi_ch_free() to free memory that was > probably allocated with malloc(). >* pam_conv_func(): remove extra whitespace in call to slapi_pblock_get() >* pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate > replies, because plugins tend to be use free() to free them. >* pam_conv_func(): replace if/else-if/else-if/else-if stacks with a > switch() statement. >* do_pam_auth(): fix line wrapping in function signature. >* do_pam_auth(): comments suggest that it's just entered or left a > critical section, when the function's been called in one. >* do_pam_auth(): replace if/else-if/else-if/else-if stacks with a > switch() statement. >* do_pam_auth(): fix line wrapping when calling PR_smprintf(). all done >HEAD~4: >* Also needs to add back-sch.h to nisserver_plugin_la_SOURCES. not done. I see no reason to add back-sch.h to nisserver_plugin_la_SOURCES -- it is not used or referenced in any code included into the nisserver plugin. >HEAD~3: >* backend_search_find_set_data_in_group_cb(): fix line wrapping in > function signature. >* backend_search_cb() looks like it'll leak staged->entries[i] if > another thread has added a similarly-named entry to the cache. all done >* backend_search_cb() now appears to be freeing the closest-match > as part of a conditional clause, right before it would unconditionally > do so. removed the duplicate. My original intent in moving that code was to avoid freeing closest-match right before we are printing it with slapi_log_error() and then sending the result with send_ldap_result(): https://git.fedorahosted.org/cgit/slapi-nis.git/tree/src/back-sch.c#n1219 I can revert this part back if you wish but I think there is an error in the original code. >* backend_search_cb() doesn't need to cast cbdata.sssd_buffer_len before > comparing it to -1. done >HEAD~2: >* backend_bind_cb() allocates strings with slapi_ch_strdup() and > slapi_entry_attr_get_charptr() but frees them with free(). >* backend_bind_cb() should avoid having to cast away a "const" by using > non-const variables for the saved copies of the group and set names. all done >HEAD~1: >* Drop the version number change. done. Instead, I have 'WIP' topmost patch handling version bump for development purposes that you can simply ignore. >HEAD: >* Doesn't mention the PAM service used for authentication, which it > probably should. Still, a good start. Added a paragraph about PAM service, on par with man page for ipa-adtrust-install utility. My fedorapeople tree has new version. -- / Alexander Bokovoy From pviktori at redhat.com Fri Aug 2 09:13:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Aug 2013 11:13:01 +0200 Subject: [Freeipa-devel] [PATCH] 0119 Switch client to JSON-RPC In-Reply-To: <518D0A2F.6040401@redhat.com> References: <50F53F2B.4020406@redhat.com> <511CF3D3.80107@redhat.com> <5159FE2B.306@redhat.com> <518D0A2F.6040401@redhat.com> Message-ID: <51FB781D.4060201@redhat.com> On 05/10/2013 04:54 PM, Petr Viktorin wrote: > On 04/01/2013 11:37 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 01/15/2013 12:36 PM, Petr Viktorin wrote: >>>> I meant to hold this patch a while longer to let it mature, but from >>>> what Brian Smith asked on the user list it seems it could help him. >>>> >>>> Design: http://freeipa.org/page/V3/JSON-RPC >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3299 >>>> >>>> See the design page for what the patch does. >>>> >>>> >>>> As much as I've tried to avoid them, the code includes some >>>> workarounds: >>>> It extends xmlrpclib to also support JSON. This is rather intrusive, >>>> but >>>> to not do that I'd need to write a parallel stack for JSON, without the >>>> help of a standard library. >>>> The registration of either jsonclient or xmlclient as "rpcclient" in >>>> the >>>> API also needs a bit of magic, since the framework requires the class >>>> name to match the attribute. >>>> >>>> >>>> To prevent backwards compatibility problems, we need to ensure that all >>>> official JSON clients send the API version, so this patch should be >>>> applied after my patches 0104-0106. >>>> >>> >>> Updating to current master. >> >> Please reverse this change in ipalib/rpc.py: >> >> @@ -665,8 +788,6 @@ class xmlclient(Connectible): >> except Exception, e: >> if not fallback: >> raise >> - else: >> - self.log.info('Connection to %s failed with %s', >> url, e) >> serverproxy = None >> >> This logs connection errors when the client fails over to another server. > > Thanks. Done, and rebased to master. > >> The changes look really good. The show stopper is that using jsonrpc >> doesn't create a session key. I noticed that xmlrpc_uri is hardcoded >> into ipalib/session.py but it appears the issue is deeper than that. > > That uses only the hostname from xmlrpc_uri. When using different > hostnames in xmlrpc_uri and jsonrpc_uri *on the server*, it'll put the > wrong domain in the cookie. In this case I think it's the configuration > that's wrong. > > The real problem is that KerberossSession code which creates the cookie, > was not called by the JSON server. > Patch 0223 adds it. > > Patch 0224 adds the server class name (e.g. [jsonserver_kerb]) to the > server logs. It should help debug problems specific to a backend/protocol. Rebased onto current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0222.4-Switch-client-to-JSON-RPC.patch Type: text/x-patch Size: 39790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0223.4-Make-jsonserver_kerb-start-a-cookie-based-session.patch Type: text/x-patch Size: 1580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0224.4-Add-server-protocol-type-to-rpcserver-logs.patch Type: text/x-patch Size: 2805 bytes Desc: not available URL: From tbabej at redhat.com Fri Aug 2 13:32:24 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 02 Aug 2013 15:32:24 +0200 Subject: [Freeipa-devel] [PATCH 0083] Make CS.cfg edits with CA instance stopped Message-ID: <1928170.mqmQzikh1F@thinkpad7.brq.redhat.com> Hi, This patch makes sure that all edits to CS.cfg configuration file are performed while pki-tomcatd service is stopped. Introduces a new contextmanager stopped_service for handling a general problem of performing a task that needs certain service being stopped. https://fedorahosted.org/freeipa/ticket/3804 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0083-Make-CS.cfg-edits-with-CA-instance-stopped.patch Type: text/x-patch Size: 18970 bytes Desc: not available URL: From abokovoy at redhat.com Fri Aug 2 13:44:33 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Aug 2013 16:44:33 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130802055228.GP15859@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> <20130801200047.GB3268@redhat.com> <20130802055228.GP15859@redhat.com> Message-ID: <20130802134433.GQ15859@redhat.com> On Fri, 02 Aug 2013, Alexander Bokovoy wrote: >Hi Nalin! > >Thanks for the review. > >On Thu, 01 Aug 2013, Nalin Dahyabhai wrote: >>On Wed, Jul 31, 2013 at 03:53:21PM +0300, Alexander Bokovoy wrote: >>>Authentication is handled for both IPA and trusted domain users. The >>>former case requires some specific handling of the SLAPI_BIND_TARGET_SDN >>>to rewrite it to the original entry's DN. As result successful bind >>>looks like this in the dirsrv logs: >>>[31/Jul/2013:15:49:03 +0300] conn=15 fd=79 slot=79 SSL connection from 192.168.111.216 to 192.168.111.216 >>>[31/Jul/2013:15:49:03 +0300] conn=15 SSL 256-bit AES >>>[31/Jul/2013:15:49:03 +0300] conn=15 op=0 BIND dn="uid=admin,cn=users,cn=compat,dc=example,dc=com" method=128 version=3 >>>[31/Jul/2013:15:49:03 +0300] conn=15 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=foobar)" attrs=ALL >>>[31/Jul/2013:15:49:03 +0300] conn=15 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" >> >>The RESULT dn being different from the BIND dn is easy to miss, but it >>should prevent possible problems where a given user can be bound to more >>than one DN, depending on where they started, so I guess it's fine. >Yes. Frankly, I don't see any other way to handle this authentication >correctly. > >>On to specific patches: >>HEAD~11 looks fine. >>HEAD~10: >>* Add internal whitespace when computing the value to pass to >> slapi_ch_malloc(). >>* Break the declaration and initialization of "str" into two lines. >>* Use '\0' to terminate str instead of 0. >>* In the new comment in format.h, NULL should be NUL. >done > >>HEAD~9 looks fine. >>HEAD~8: >>* In configure.in, drop the hunk that changes the version number that we >> pass to AC_INIT. >>* In configure.in, one test compares x$use_sss_nss_idmap != xno, while >> one shortly after compares $use_sss_nss_idmap = yes. If >> $use_sss_nss_idmap can be empty, then the second test needs to be >> ready for that. >>* The help text still refers to SSSD specifically, when the code doesn't >> enforce or guarantee that SSSD's involved when performing nsswitch >> lookups or PAM authentication. >The whole setup really makes sense only when SSSD is in use. Aside from >that, the whole setup is triggered only if we find libsss_nss_idmap >library which is provided by SSSD. Yes, it is used for an optional >adding of the SID but linking is explicit. > >Due to these reasons I has left the text there and added small >mentioning of nsswitch interface. > >>HEAD~7: >>* Fix formatting of wrapped lines when calling backend_shr_get_vattr_str(). >>* Check for errors when converting the configured sssd_min_id to a number >> by switching from atol() to strtol() or strtoul(). >done. > >>HEAD~6: >>* Drop extra whitespace after the type of the "name" member when >> defining struct backend_search_filter_config. >>* backend_search_filter_has_cn_uid() allocates config->name using >> slapi_ch_malloc(), but it is later freed by free(). >>* backend_retrieve_user_entry_from_sssd(): fix line wrapping in >> function signature. >>* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. >>* backend_retrieve_user_entry_from_sssd(): avoid using >> slapi_entry_attr_set_int(), which will treat an unsigned 32-bit >> with the high bit set as a negative value >>* backend_retrieve_user_entry_from_sssd(): check for zero-length >> pw_shell value, and avoid adding it as a loginShell value, since >> that'd be invalid >all done. > >>* backend_retrieve_user_entry_from_sssd() adds "ipaNTUserAttrs" as an >> objectClass in the temporary entry, but the value isn't copied into >> the cache. What purpose does it serve? >I removed this part since we are anyway using extensibleObject for the >generated entry. > >>* backend_retrieve_user_entry_from_sssd(): extra whitespace when >> constructing the new entry's DN. >>* backend_retrieve_user_entry_from_sssd(): memory leak from not freeing >> the result of slapi_escape_filter_value(). >>* backend_retrieve_group_entry_from_sssd(): fix line wrapping in >> function signature. >>* backend_retrieve_group_entry_from_sssd() needs to handle ERANGE errors. >>* backend_retrieve_group_entry_from_sssd(): extra whitespace when >> constructing the new entry's DN. >>* backend_retrieve_group_entry_from_sssd(): memory leak from not freeing >> the result of slapi_escape_filter_value(). >all done > >>* backend_retrieve_group_entry_from_sssd() adds "ipaNTGroupAttrs" as an >> objectClass in the temporary entry, but the value isn't copied into >> the cache. What purpose does it serve? >I removed this part since we are anyway using extensibleObject for the >generated entry > >>* backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors. >>* backend_retrieve_group_entry_from_sssd(): avoid using >> slapi_entry_attr_set_int(), which will treat an unsigned 32-bit >> with the high bit set as a negative value >>* backend_retrieve_group_list_from_sssd(): check for NULL result from >> realloc(). >>* backend_search_sssd(): fix line wrapping for call to >> slapi_filter_apply(). >>* backend_search_sssd(): use strtol() or strtoul() to convert a value to >> a number, and check for errors. >>* backend_search_sssd(): staged->container_sdn/map_group/map_set are >> allocated with slapi_ch_strdup() but freed with free() later. >>* backend_retrieve_from_sssd(): check for NULL result from malloc(). >>* backend_retrieve_from_sssd(): fix line wrapping for calls to >> backend_retrieve_user/group_entry_from_sssd. >all done > >>HEAD~5: >>* free_pam_response() uses slapi_ch_free() to free memory that was >> probably allocated with malloc(). >>* pam_conv_func(): remove extra whitespace in call to slapi_pblock_get() >>* pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate >> replies, because plugins tend to be use free() to free them. >>* pam_conv_func(): replace if/else-if/else-if/else-if stacks with a >> switch() statement. >>* do_pam_auth(): fix line wrapping in function signature. >>* do_pam_auth(): comments suggest that it's just entered or left a >> critical section, when the function's been called in one. >>* do_pam_auth(): replace if/else-if/else-if/else-if stacks with a >> switch() statement. >>* do_pam_auth(): fix line wrapping when calling PR_smprintf(). >all done > >>HEAD~4: >>* Also needs to add back-sch.h to nisserver_plugin_la_SOURCES. >not done. I see no reason to add back-sch.h to >nisserver_plugin_la_SOURCES -- it is not used or referenced in any code >included into the nisserver plugin. > >>HEAD~3: >>* backend_search_find_set_data_in_group_cb(): fix line wrapping in >> function signature. >>* backend_search_cb() looks like it'll leak staged->entries[i] if >> another thread has added a similarly-named entry to the cache. >all done > >>* backend_search_cb() now appears to be freeing the closest-match >> as part of a conditional clause, right before it would unconditionally >> do so. >removed the duplicate. My original intent in moving that code was to >avoid freeing closest-match right before we are printing it with >slapi_log_error() and then sending the result with send_ldap_result(): >https://git.fedorahosted.org/cgit/slapi-nis.git/tree/src/back-sch.c#n1219 > >I can revert this part back if you wish but I think there is an error in >the original code. > >>* backend_search_cb() doesn't need to cast cbdata.sssd_buffer_len before >> comparing it to -1. >done > >>HEAD~2: >>* backend_bind_cb() allocates strings with slapi_ch_strdup() and >> slapi_entry_attr_get_charptr() but frees them with free(). >>* backend_bind_cb() should avoid having to cast away a "const" by using >> non-const variables for the saved copies of the group and set names. >all done > >>HEAD~1: >>* Drop the version number change. >done. Instead, I have 'WIP' topmost patch handling version bump for >development purposes that you can simply ignore. > >>HEAD: >>* Doesn't mention the PAM service used for authentication, which it >> probably should. Still, a good start. >Added a paragraph about PAM service, on par with man page for >ipa-adtrust-install utility. > >My fedorapeople tree has new version. ... and I did fix couple more comments received from Sumit: 1. switched to use usigned long for sssd_min_id 2. added initializer for 'dn' in backend_retrieve_user_entry_from_sssd()/backend_retrieve_group_entry_from_sssd 3. switched to atoll() with cast of the result to (uid_t)/(gid_t) because we already know at staging phase that the id in as a string will convert without errors to an integer and it is > min id. 4. fixed copyright header in src/back-sch-sssd.c to mention 2013 only as this is new code. -- / Alexander Bokovoy From pviktori at redhat.com Fri Aug 2 14:25:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Aug 2013 16:25:22 +0200 Subject: [Freeipa-devel] [PATCH] 0267 Update translations Message-ID: <51FBC152.6090304@redhat.com> Hello, I've prepared a patch with fresh translations pulled from Transifex. As usual the patch is pretty large; please download it from: https://github.com/encukou/freeipa/compare/translations.patch Thank you to all translators! This time the patch also updates the Transifex URL in our config file; the old .net URL is still redirecting to the new .com, but its certificate has expired. In other news, I've set up a repo to archive the Transifex translations, and a cron job to update it periodically. The repo can be found at: https://github.com/encukou/freeipa-translations With this in place, there should be less fear of pushing source strings to Transifex. If you want to keep your own archive; my cron job goes like this: make git add po git commit -m"Update translations (automatic commit)" git push origin master In yet other news, the ticket to split long __doc__ strings is scheduled for the IPA 3.4. This time it's getting in :) https://fedorahosted.org/freeipa/ticket/3587 -- Petr? From jfenal at gmail.com Fri Aug 2 14:40:46 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 2 Aug 2013 16:40:46 +0200 Subject: [Freeipa-devel] [PATCH] 0267 Update translations In-Reply-To: <51FBC152.6090304@redhat.com> References: <51FBC152.6090304@redhat.com> Message-ID: 2013/8/2 Petr Viktorin > Hello, > I've prepared a patch with fresh translations pulled from Transifex. > As usual the patch is pretty large; please download it from: > https://github.com/encukou/**freeipa/compare/translations.**patch > > Thank you to all translators! > > This time the patch also updates the Transifex URL in our config file; the > old .net URL is still redirecting to the new .com, but its certificate has > expired. > > > In other news, I've set up a repo to archive the Transifex translations, > and a cron job to update it periodically. The repo can be found at: > https://github.com/encukou/**freeipa-translations > With this in place, there should be less fear of pushing source strings to > Transifex. > If you want to keep your own archive; my cron job goes like this: > make > git add po > git commit -m"Update translations (automatic commit)" > git push origin master > > > In yet other news, the ticket to split long __doc__ strings is scheduled > for the IPA 3.4. This time it's getting in :) > https://fedorahosted.org/freeipa/ticket/3587 > That's great news, Petr ! With that in place, French will soon jump to 100% ;) I'll watch the transifex resource being updated. Regards, J. -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Aug 2 15:00:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Aug 2013 17:00:54 +0200 Subject: [Freeipa-devel] [PATCH] 0267 Update translations In-Reply-To: <51FBC152.6090304@redhat.com> References: <51FBC152.6090304@redhat.com> Message-ID: <51FBC9A6.8040401@redhat.com> On 08/02/2013 04:25 PM, Petr Viktorin wrote: > Hello, > I've prepared a patch with fresh translations pulled from Transifex. > As usual the patch is pretty large; please download it from: > https://github.com/encukou/freeipa/compare/translations.patch > > Thank you to all translators! > > This time the patch also updates the Transifex URL in our config file; > the old .net URL is still redirecting to the new .com, but its > certificate has expired. > > > In other news, I've set up a repo to archive the Transifex translations, > and a cron job to update it periodically. The repo can be found at: > https://github.com/encukou/freeipa-translations > With this in place, there should be less fear of pushing source strings > to Transifex. > If you want to keep your own archive; my cron job goes like this: > make > git add po > git commit -m"Update translations (automatic commit)" > git push origin master > > > In yet other news, the ticket to split long __doc__ strings is scheduled > for the IPA 3.4. This time it's getting in :) > https://fedorahosted.org/freeipa/ticket/3587 > The IPA team doesn't have anyone who can check translations, so self-ACK, pushed to master: 5d141bd39cb99f2c2e16b61bcc4e06b734bbab04 -- Petr? From jfenal at gmail.com Fri Aug 2 15:10:11 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 2 Aug 2013 17:10:11 +0200 Subject: [Freeipa-devel] [PATCH] 0267 Update translations In-Reply-To: <51FBC9A6.8040401@redhat.com> References: <51FBC152.6090304@redhat.com> <51FBC9A6.8040401@redhat.com> Message-ID: 2013/8/2 Petr Viktorin > On 08/02/2013 04:25 PM, Petr Viktorin wrote: > >> Hello, >> I've prepared a patch with fresh translations pulled from Transifex. >> As usual the patch is pretty large; please download it from: >> https://github.com/encukou/**freeipa/compare/translations.**patch >> >> Thank you to all translators! >> >> This time the patch also updates the Transifex URL in our config file; >> the old .net URL is still redirecting to the new .com, but its >> certificate has expired. >> >> >> In other news, I've set up a repo to archive the Transifex translations, >> and a cron job to update it periodically. The repo can be found at: >> https://github.com/encukou/**freeipa-translations >> With this in place, there should be less fear of pushing source strings >> to Transifex. >> If you want to keep your own archive; my cron job goes like this: >> make >> git add po >> git commit -m"Update translations (automatic commit)" >> git push origin master >> >> >> In yet other news, the ticket to split long __doc__ strings is scheduled >> for the IPA 3.4. This time it's getting in :) >> https://fedorahosted.org/**freeipa/ticket/3587 >> >> > The IPA team doesn't have anyone who can check translations, so self-ACK, > pushed to master: 5d141bd39cb99f2c2e16b61bcc4e06b734bbab04 > Great! Were the __doc__ strings splitted as well? Or are they splitted on double \n at string extraction time? Regards, J. -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Fri Aug 2 15:16:19 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 02 Aug 2013 17:16:19 +0200 Subject: [Freeipa-devel] [PATCH 0084] Improve help entry for ipa host Message-ID: <1643125.dD1kTBdeuB@thinkpad7.brq.redhat.com> Hi, Updates old information produced by the ipa help host command. Also adds a section to ipa-client-install manpage about client re-enrollment. https://fedorahosted.org/freeipa/ticket/3820 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0084-Improve-help-entry-for-ipa-host.patch Type: text/x-patch Size: 3543 bytes Desc: not available URL: From akrivoka at redhat.com Fri Aug 2 15:50:21 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 02 Aug 2013 17:50:21 +0200 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <20130801141307.GO15859@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> Message-ID: <51FBD53D.3090905@redhat.com> On 08/01/2013 04:13 PM, Alexander Bokovoy wrote: > Hi! > > On Thu, 01 Aug 2013, Ana Krivokapic wrote: >> Hello, Thanks Alexander for the quick review! >> >> This patch adds ipa-advise plugins to help configure legacy clients for access >> to trusted domain resources. For more details, please read the commit message. >> Plugins are currently named "config-redhat-sssd-before-1-9" and >> "config-generic-sssd-before-1-9"; suggestions for better names are welcome. >> >> Plugin content heavily inspired by >> https://fedoraproject.org/wiki/QA:Testcase_freeipa_use_legacy_sssd_to_give_access_to_trusted_domain_users. >> > I think it is a good start. Comments inline. > >> https://fedorahosted.org/freeipa/ticket/3671 >> --- >> install/share/Makefile.am | 2 + >> install/share/pam.conf.template | 22 ++++++ >> install/share/sssd.conf.template | 12 +++ > I would imagine we would have multiple plugins that need their own > templates for pam.conf/sssd.conf. What about introducing > to avoid conflicts? > > In this case you use the same templates for both plugins so you might > have as 'legacy', for example. > > Another way is to have plugin name in the template, e.g. > legacy.sssd.conf.template. Done. I opted for the install/share/advise//*.template option. The changes are in the updated patch 52. > >> +class config_redhat_sssd_before_1_9(Advice): >> + """ >> + Legacy client configuration for Red Hat based platforms. >> + """ >> + >> + description = ('Instructions for configuring a system with an old version ' >> + 'of SSSD (1.5-1.8) as a FreeIPA client. This set of ' >> + 'instructions is targeted for platforms that include ' >> + 'the authconfig utility, which are all Red Hat based ' >> + 'platforms.') > You need to check that Schema Compatibility plugin is configured to > serve trusted domain users and groups. > > We have two trees: > dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config > dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config > > In both of the trees there should be > schema-compat-lookup-sssd: > > attribute, with the value according to the tree (i.e. user for > cn=users). > > If not, then suggest to run 'ipa-adtrust-install --enable-compat=true' on the > IPA server. Done. I added a new API command 'compat-is-enabled' (similar to 'adtrust-is-enabled') to facilitate checking whether the Schema Compatibility plugin is configured. 'compat-is-enabled' is called from the ipa-advise plugin and the suggestion to run 'ipa-adtrust-install --enable-compat' is printed as the first piece of advice, when appropriate. Patch 54 adds the new API command 'compat-is-enabled', while patch 53 is a small fix which enables IPA API commands to be run from the ipa-advise plugins. > >> + >> + def get_info(self): >> + self.log.comment('Install the sssd and authconfig packages via yum') >> + self.log.command('yum install -y sssd authconfig\n') > You are using 'wget' below, it might make sense to add it into the above > line too. Fixed in patch 52. > >> + >> + self.log.comment('Download the CA certificate of the IPA server') >> + self.log.command('mkdir -p -m 755 /etc/openldap/cacerts') >> + self.log.command('wget http://%s/ipa/config/ca.crt -O ' >> + '/etc/openldap/cacerts/ipa.crt\n' % api.env.host) >> + >> + self.log.comment('Generate hashes for the openldap library') >> + self.log.command('cacertdir_rehash /etc/openldap/cacerts/\n') >> + >> + self.log.comment('Use the authconfig to configure nsswitch.conf ' >> + 'and the PAM stack') >> + self.log.command('authconfig --updateall --enablesssd ' >> + '--enablesssdauth\n') >> + >> + self.log.comment('Configure SSSD') >> + self.log.command('cat > /etc/sssd/sssd.conf << EOF \n' >> + '%s\nEOF' % generate_sssd_conf()) >> + self.log.command('chmod 0600 /etc/sssd/sssd.conf\n') >> + >> + self.log.comment('Start SSSD') >> + self.log.command('service sssd start') > Would it make sense to also add instructions to restore SELinux context > (if needed)? I'm not sure, just throwing the idea for consideration. I am not sure about this either so I will wait for more opinions about this. > > Same comments go for the second plugin. > I also refactored the plugin a bit (added a new base class to avoid code duplication). Updated patches are attached. Patch 52 depends on patches 53 and 54. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0052-02-Add-ipa-advise-plugins-for-legacy-clients.patch Type: text/x-patch Size: 11549 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0053-Enable-running-API-commands-in-ipa-advise-plugins.patch Type: text/x-patch Size: 1993 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0054-Add-new-command-compat-is-enabled.patch Type: text/x-patch Size: 3209 bytes Desc: not available URL: From akrivoka at redhat.com Fri Aug 2 16:08:12 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 02 Aug 2013 18:08:12 +0200 Subject: [Freeipa-devel] [PATCH 0084] Improve help entry for ipa host In-Reply-To: <1643125.dD1kTBdeuB@thinkpad7.brq.redhat.com> References: <1643125.dD1kTBdeuB@thinkpad7.brq.redhat.com> Message-ID: <51FBD96C.7020605@redhat.com> On 08/02/2013 05:16 PM, Tomas Babej wrote: > Hi, > > Updates old information produced by the ipa help host command. > Also adds a section to ipa-client-install manpage about client > re-enrollment. > > https://fedorahosted.org/freeipa/ticket/3820 > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Sun Aug 4 20:04:57 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Sun, 4 Aug 2013 16:04:57 -0400 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130802134433.GQ15859@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> <20130801200047.GB3268@redhat.com> <20130802055228.GP15859@redhat.com> <20130802134433.GQ15859@redhat.com> Message-ID: <20130804200457.GA19227@redhat.com> Crikey, that was fast. On Fri, Aug 02, 2013 at 04:44:33PM +0300, Alexander Bokovoy wrote: > >On Thu, 01 Aug 2013, Nalin Dahyabhai wrote: > >>HEAD~10: > >>* Add internal whitespace when computing the value to pass to > >>slapi_ch_malloc(). > >>* Break the declaration and initialization of "str" into two lines. > >>* Use '\0' to terminate str instead of 0. > >>* In the new comment in format.h, NULL should be NUL. > >done Ok, good. > >>HEAD~8: > >>* In configure.in, drop the hunk that changes the version number that we > >>pass to AC_INIT. > >>* In configure.in, one test compares x$use_sss_nss_idmap != xno, while > >>one shortly after compares $use_sss_nss_idmap = yes. If > >>$use_sss_nss_idmap can be empty, then the second test needs to be > >>ready for that. Good. > >>* The help text still refers to SSSD specifically, when the code doesn't > >>enforce or guarantee that SSSD's involved when performing nsswitch > >>lookups or PAM authentication. > > > >The whole setup really makes sense only when SSSD is in use. Aside from > >that, the whole setup is triggered only if we find libsss_nss_idmap > >library which is provided by SSSD. Yes, it is used for an optional > >adding of the SID but linking is explicit. Yeah, but why is all of that required? If we want to be able to gateway whatever's going on at the server, the ipaNTSecurityIdentifier lookup is already optional at runtime. Making that part optional at compile-time would make the rest of the code (at least the nsswitch parts) easier to self-test. > >>HEAD~7: > >>* Fix formatting of wrapped lines when calling backend_shr_get_vattr_str(). > >>* Check for errors when converting the configured sssd_min_id to a number > >>by switching from atol() to strtol() or strtoul(). > >done. Looks good, except that the comment in the checking block implies that it's imposing a lower limit on ret.sssd_min_id, when it's reassigning the default in case of a parsing error. If the value parses as valid, it appears that a value lower than 1000 would be accepted. > >>HEAD~6: > >>* Drop extra whitespace after the type of the "name" member when > >>defining struct backend_search_filter_config. > >>* backend_search_filter_has_cn_uid() allocates config->name using > >>slapi_ch_malloc(), but it is later freed by free(). > >>* backend_retrieve_user_entry_from_sssd(): fix line wrapping in > >>function signature. > >>* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. > >>* backend_retrieve_user_entry_from_sssd(): avoid using > >>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit > >>with the high bit set as a negative value > >>* backend_retrieve_user_entry_from_sssd(): check for zero-length > >>pw_shell value, and avoid adding it as a loginShell value, since > >>that'd be invalid > >all done. That last one's just a NULL check now. Please add a check for a zero-length value, which would also be skipped. Otherwise, looks good. > >>* backend_retrieve_user_entry_from_sssd() adds "ipaNTUserAttrs" as an > >>objectClass in the temporary entry, but the value isn't copied into > >>the cache. What purpose does it serve? > >I removed this part since we are anyway using extensibleObject for the > >generated entry. Makes sense. > >>* backend_retrieve_user_entry_from_sssd(): extra whitespace when > >>constructing the new entry's DN. Both of these still have an extra space after the assignment operator. > >>* backend_retrieve_user_entry_from_sssd(): memory leak from not freeing > >>the result of slapi_escape_filter_value(). > >>* backend_retrieve_group_entry_from_sssd(): fix line wrapping in > >>function signature. > >>* backend_retrieve_group_entry_from_sssd() needs to handle ERANGE errors. > >>* backend_retrieve_group_entry_from_sssd(): extra whitespace when > >>constructing the new entry's DN. > >>* backend_retrieve_group_entry_from_sssd(): memory leak from not freeing > >>the result of slapi_escape_filter_value(). > >all done Otherwise, looks good. > >>* backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors. > >>* backend_retrieve_group_entry_from_sssd(): avoid using > >>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit > >>with the high bit set as a negative value > >>* backend_retrieve_group_list_from_sssd(): check for NULL result from > >>realloc(). Leaks are possible if realloc() fails for grouplist or entries. > >>* backend_search_sssd(): fix line wrapping for call to > >>slapi_filter_apply(). > >>* backend_search_sssd(): use strtol() or strtoul() to convert a value to > >>a number, and check for errors. > >>* backend_search_sssd(): staged->container_sdn/map_group/map_set are > >>allocated with slapi_ch_strdup() but freed with free() later. > >>* backend_retrieve_from_sssd(): check for NULL result from malloc(). > >>* backend_retrieve_from_sssd(): fix line wrapping for calls to > >>backend_retrieve_user/group_entry_from_sssd. > >all done Otherwise, looks good. > >>HEAD~5: > >>* free_pam_response() uses slapi_ch_free() to free memory that was > >>probably allocated with malloc(). > >>* pam_conv_func(): remove extra whitespace in call to slapi_pblock_get() > >>* pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate > >>replies, because plugins tend to be use free() to free them. > >>* pam_conv_func(): replace if/else-if/else-if/else-if stacks with a > >>switch() statement. > >>* do_pam_auth(): fix line wrapping in function signature. > >>* do_pam_auth(): comments suggest that it's just entered or left a > >>critical section, when the function's been called in one. > >>* do_pam_auth(): replace if/else-if/else-if/else-if stacks with a > >>switch() statement. > >>* do_pam_auth(): fix line wrapping when calling PR_smprintf(). Missed one, right after the done: label. > >>HEAD~4: > >>* Also needs to add back-sch.h to nisserver_plugin_la_SOURCES. > >not done. I see no reason to add back-sch.h to > >nisserver_plugin_la_SOURCES -- it is not used or referenced in any code > >included into the nisserver plugin. Whoops, yeah, you're right. Somehow I missed the part where it was being added to schemacompat_plugin_la_SOURCES, which is what I meant to point to. > >>HEAD~3: > >>* backend_search_find_set_data_in_group_cb(): fix line wrapping in > >>function signature. > >>* backend_search_cb() looks like it'll leak staged->entries[i] if > >>another thread has added a similarly-named entry to the cache. > >all done Looks good. > >>* backend_search_cb() now appears to be freeing the closest-match > >>as part of a conditional clause, right before it would unconditionally > >>do so. > >removed the duplicate. My original intent in moving that code was to > >avoid freeing closest-match right before we are printing it with > >slapi_log_error() and then sending the result with send_ldap_result(): > >https://git.fedorahosted.org/cgit/slapi-nis.git/tree/src/back-sch.c#n1219 > > > >I can revert this part back if you wish but I think there is an error in > >the original code. The current intent there is to avoid sending a closest-match DN when we're returning entries as part of the result, to only send such a value as part of the result if we're sending back an LDAP_NO_SUCH_OBJECT error. > >>HEAD~2: > >>* backend_bind_cb() should avoid having to cast away a "const" by using > >>non-const variables for the saved copies of the group and set names. > >all done I meant to suggest that attempting to use an array to store both a const and a non-const string still forces a cast somewhere. Use two variables. > ... and I did fix couple more comments received from Sumit: > > 1. switched to use usigned long for sssd_min_id > 2. added initializer for 'dn' in backend_retrieve_user_entry_from_sssd()/backend_retrieve_group_entry_from_sssd > 3. switched to atoll() with cast of the result to (uid_t)/(gid_t) because > we already know at staging phase that the id in as a string will convert without errors to an integer and it is > min id. Okay. Though, formatting the uid/gid as a string to pass it into a local function that converts it right back to an integer seems excessive. Anyhow, I guess we're down to minor stuff now. Cheers, Nalin From abokovoy at redhat.com Mon Aug 5 12:45:06 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Aug 2013 15:45:06 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130804200457.GA19227@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> <20130801200047.GB3268@redhat.com> <20130802055228.GP15859@redhat.com> <20130802134433.GQ15859@redhat.com> <20130804200457.GA19227@redhat.com> Message-ID: <20130805124506.GT15859@redhat.com> On Sun, 04 Aug 2013, Nalin Dahyabhai wrote: >> >>* The help text still refers to SSSD specifically, when the code doesn't >> >>enforce or guarantee that SSSD's involved when performing nsswitch >> >>lookups or PAM authentication. >> > >> >The whole setup really makes sense only when SSSD is in use. Aside from >> >that, the whole setup is triggered only if we find libsss_nss_idmap >> >library which is provided by SSSD. Yes, it is used for an optional >> >adding of the SID but linking is explicit. > >Yeah, but why is all of that required? If we want to be able to gateway >whatever's going on at the server, the ipaNTSecurityIdentifier lookup is >already optional at runtime. Making that part optional at compile-time >would make the rest of the code (at least the nsswitch parts) easier to >self-test. OK, fair enough. I did use of libsss_nss_idmap optional. For tests I think we need to involve nsswrapper here to make sure of a predictable testing. I've added: --with-nsswitch use nsswitch API to look up users and groupsnot found in the LDAP --with-sss-nss-idmap use libsss_nss_idmap to discover SIDs. Requires --with-nsswitch as well --with-pam use PAM API to authenticate users not found in the LDAP. Requires --with-nsswitch as well And also split PAM use -- if --with-nsswitch is provided, you may optionally disable use of PAM. I also moved src/back-sch-sssd.c to src/back-sch-nss.c to reflect that and renamed SSSD references to NSSWITCH. >> >>HEAD~7: >> >>* Fix formatting of wrapped lines when calling backend_shr_get_vattr_str(). >> >>* Check for errors when converting the configured sssd_min_id to a number >> >>by switching from atol() to strtol() or strtoul(). >> >done. > >Looks good, except that the comment in the checking block implies that >it's imposing a lower limit on ret.sssd_min_id, when it's reassigning >the default in case of a parsing error. If the value parses as valid, >it appears that a value lower than 1000 would be accepted. That's OK because it is a configuration option. If you want to have it set to something like 500, so be it -- not all distributions enforce 1000 as their defaults. >> >>HEAD~6: >> >>* Drop extra whitespace after the type of the "name" member when >> >>defining struct backend_search_filter_config. >> >>* backend_search_filter_has_cn_uid() allocates config->name using >> >>slapi_ch_malloc(), but it is later freed by free(). >> >>* backend_retrieve_user_entry_from_sssd(): fix line wrapping in >> >>function signature. >> >>* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. >> >>* backend_retrieve_user_entry_from_sssd(): avoid using >> >>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit >> >>with the high bit set as a negative value >> >>* backend_retrieve_user_entry_from_sssd(): check for zero-length >> >>pw_shell value, and avoid adding it as a loginShell value, since >> >>that'd be invalid >> >all done. > >That last one's just a NULL check now. Please add a check for a >zero-length value, which would also be skipped. Otherwise, looks good. Done. >> >>* backend_retrieve_user_entry_from_sssd(): extra whitespace when >> >>constructing the new entry's DN. > >Both of these still have an extra space after the assignment operator. Done >> >>* backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors. >> >>* backend_retrieve_group_entry_from_sssd(): avoid using >> >>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit >> >>with the high bit set as a negative value >> >>* backend_retrieve_group_list_from_sssd(): check for NULL result from >> >>realloc(). > >Leaks are possible if realloc() fails for grouplist or entries. I've used a temporary variable to realloc() into and then only change 'entries' if its value is not NULL. This should handle the case. >> >>HEAD~5: >> >>* free_pam_response() uses slapi_ch_free() to free memory that was >> >>probably allocated with malloc(). >> >>* pam_conv_func(): remove extra whitespace in call to slapi_pblock_get() >> >>* pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate >> >>replies, because plugins tend to be use free() to free them. >> >>* pam_conv_func(): replace if/else-if/else-if/else-if stacks with a >> >>switch() statement. >> >>* do_pam_auth(): fix line wrapping in function signature. >> >>* do_pam_auth(): comments suggest that it's just entered or left a >> >>critical section, when the function's been called in one. >> >>* do_pam_auth(): replace if/else-if/else-if/else-if stacks with a >> >>switch() statement. >> >>* do_pam_auth(): fix line wrapping when calling PR_smprintf(). > >Missed one, right after the done: label. Done. >> >>* backend_search_cb() now appears to be freeing the closest-match >> >>as part of a conditional clause, right before it would unconditionally >> >>do so. >> >removed the duplicate. My original intent in moving that code was to >> >avoid freeing closest-match right before we are printing it with >> >slapi_log_error() and then sending the result with send_ldap_result(): >> >https://git.fedorahosted.org/cgit/slapi-nis.git/tree/src/back-sch.c#n1219 >> > >> >I can revert this part back if you wish but I think there is an error in >> >the original code. > >The current intent there is to avoid sending a closest-match DN when >we're returning entries as part of the result, to only send such a value >as part of the result if we're sending back an LDAP_NO_SUCH_OBJECT >error. My main issue with this is that for the case when we found the entry we still show the debug message with 'closest match = (null)'. I think it is misleading at least. I moved freeing the closest_match after we print the debug message. > >> >>HEAD~2: >> >>* backend_bind_cb() should avoid having to cast away a "const" by using >> >>non-const variables for the saved copies of the group and set names. >> >all done > >I meant to suggest that attempting to use an array to store both a const >and a non-const string still forces a cast somewhere. Use two >variables. Done. > >> ... and I did fix couple more comments received from Sumit: >> >> 1. switched to use usigned long for sssd_min_id >> 2. added initializer for 'dn' in backend_retrieve_user_entry_from_sssd()/backend_retrieve_group_entry_from_sssd >> 3. switched to atoll() with cast of the result to (uid_t)/(gid_t) because >> we already know at staging phase that the id in as a string will convert without errors to an integer and it is > min id. > >Okay. Though, formatting the uid/gid as a string to pass it into a >local function that converts it right back to an integer seems >excessive. Anyhow, I guess we're down to minor stuff now. Following this suggestion, I made two entry points to a larger helper, one is a general one and another accepting the gid directly. The second one is used by the grouplist search. I don't think there is a need to abstract it more -- when we stage the request it is easier to store name (or uid) in a string form anyway. Otherwise I'd need to go with a union to store either string, an uid, or a gid... New code is in my repository at fedorapeople.org. Additionally, a patch to FreeIPA to change configuration variables names is attached. -- / Alexander Bokovoy -------------- next part -------------- >From 85ccd4f5290ad9ac05c5b534b9ce64b078f6e5c1 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 5 Aug 2013 15:42:29 +0300 Subject: [PATCH] Rename slapi-nis configuration variable --- ipaserver/install/adtrustinstance.py | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index f072a6a..5839b2f 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -667,16 +667,16 @@ class ADTRUSTInstance(service.Service): def __enable_compat_tree(self): try: compat_plugin_dn = DN("cn=Schema Compatibility,cn=plugins,cn=config") - lookup_sssd_name = "schema-compat-lookup-sssd" + lookup_nsswitch_name = "schema-compat-lookup-nsswitch" for config in (("cn=users", "user"), ("cn=groups", "group")): entry_dn = DN(config[0], compat_plugin_dn) current = self.admin_conn.get_entry(entry_dn) - lookup_sssd = current.get(lookup_sssd_name, []) - if not(config[1] in lookup_sssd): - current[lookup_sssd_name] = [config[1]] + lookup_nsswitch = current.get(lookup_nsswitch_name, []) + if not(config[1] in lookup_nsswitch): + current[lookup_nsswitch_name] = [config[1]] self.admin_conn.update_entry(entry_dn, current) except Exception, e: - root_logger.critical("Enabling SSSD support in slapi-nis failed with error '%s'" % e) + root_logger.critical("Enabling nsswitch support in slapi-nis failed with error '%s'" % e) def __start(self): try: -- 1.8.3.1 From tbabej at redhat.com Mon Aug 5 12:45:18 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 05 Aug 2013 14:45:18 +0200 Subject: [Freeipa-devel] [PATCH 0085] Limit pwpolicy maxlife to 20000 days Message-ID: <2353202.ZGBLvey0gJ@thinkpad7.brq.redhat.com> Hi, Since krbMaxPwdLife attribute is represented as number of seconds, setting maxlife to high values such as 999 999 days (~2739 years) would result to overflow when parsing this attribute in kdb plugin, and hence default maxlife of 90 days would be applied. Limit the maximum value of maxlife that can be set through the framework to 20 000 days (~ 54 years). https://fedorahosted.org/freeipa/ticket/3817 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0085-Limit-pwpolicy-maxlife-to-20000-days.patch Type: text/x-patch Size: 5038 bytes Desc: not available URL: From abokovoy at redhat.com Mon Aug 5 12:57:23 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Aug 2013 15:57:23 +0300 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <51FBD53D.3090905@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> Message-ID: <20130805125723.GU15859@redhat.com> On Fri, 02 Aug 2013, Ana Krivokapic wrote: >On 08/01/2013 04:13 PM, Alexander Bokovoy wrote: >> Hi! >> >> On Thu, 01 Aug 2013, Ana Krivokapic wrote: >>> Hello, > >Thanks Alexander for the quick review! > >>> >>> This patch adds ipa-advise plugins to help configure legacy clients for access >>> to trusted domain resources. For more details, please read the commit message. >>> Plugins are currently named "config-redhat-sssd-before-1-9" and >>> "config-generic-sssd-before-1-9"; suggestions for better names are welcome. >>> >>> Plugin content heavily inspired by >>> https://fedoraproject.org/wiki/QA:Testcase_freeipa_use_legacy_sssd_to_give_access_to_trusted_domain_users. >>> >> I think it is a good start. Comments inline. >> >>> https://fedorahosted.org/freeipa/ticket/3671 >>> --- >>> install/share/Makefile.am | 2 + >>> install/share/pam.conf.template | 22 ++++++ >>> install/share/sssd.conf.template | 12 +++ >> I would imagine we would have multiple plugins that need their own >> templates for pam.conf/sssd.conf. What about introducing >> to avoid conflicts? >> >> In this case you use the same templates for both plugins so you might >> have as 'legacy', for example. >> >> Another way is to have plugin name in the template, e.g. >> legacy.sssd.conf.template. > >Done. I opted for the install/share/advise//*.template option. The changes >are in the updated patch 52. > >> >>> +class config_redhat_sssd_before_1_9(Advice): >>> + """ >>> + Legacy client configuration for Red Hat based platforms. >>> + """ >>> + >>> + description = ('Instructions for configuring a system with an old version ' >>> + 'of SSSD (1.5-1.8) as a FreeIPA client. This set of ' >>> + 'instructions is targeted for platforms that include ' >>> + 'the authconfig utility, which are all Red Hat based ' >>> + 'platforms.') >> You need to check that Schema Compatibility plugin is configured to >> serve trusted domain users and groups. >> >> We have two trees: >> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >> >> In both of the trees there should be >> schema-compat-lookup-sssd: >> >> attribute, with the value according to the tree (i.e. user for >> cn=users). >> >> If not, then suggest to run 'ipa-adtrust-install --enable-compat=true' on the >> IPA server. > >Done. I added a new API command 'compat-is-enabled' (similar to >'adtrust-is-enabled') to facilitate checking whether the Schema Compatibility >plugin is configured. 'compat-is-enabled' is called from the ipa-advise plugin >and the suggestion to run 'ipa-adtrust-install --enable-compat' is printed as >the first piece of advice, when appropriate. > >Patch 54 adds the new API command 'compat-is-enabled', while patch 53 is a small >fix which enables IPA API commands to be run from the ipa-advise plugins. > >> >>> + >>> + def get_info(self): >>> + self.log.comment('Install the sssd and authconfig packages via yum') >>> + self.log.command('yum install -y sssd authconfig\n') >> You are using 'wget' below, it might make sense to add it into the above >> line too. > >Fixed in patch 52. > >> >>> + >>> + self.log.comment('Download the CA certificate of the IPA server') >>> + self.log.command('mkdir -p -m 755 /etc/openldap/cacerts') >>> + self.log.command('wget http://%s/ipa/config/ca.crt -O ' >>> + '/etc/openldap/cacerts/ipa.crt\n' % api.env.host) >>> + >>> + self.log.comment('Generate hashes for the openldap library') >>> + self.log.command('cacertdir_rehash /etc/openldap/cacerts/\n') >>> + >>> + self.log.comment('Use the authconfig to configure nsswitch.conf ' >>> + 'and the PAM stack') >>> + self.log.command('authconfig --updateall --enablesssd ' >>> + '--enablesssdauth\n') >>> + >>> + self.log.comment('Configure SSSD') >>> + self.log.command('cat > /etc/sssd/sssd.conf << EOF \n' >>> + '%s\nEOF' % generate_sssd_conf()) >>> + self.log.command('chmod 0600 /etc/sssd/sssd.conf\n') >>> + >>> + self.log.comment('Start SSSD') >>> + self.log.command('service sssd start') >> Would it make sense to also add instructions to restore SELinux context >> (if needed)? I'm not sure, just throwing the idea for consideration. > >I am not sure about this either so I will wait for more opinions about this. > >> >> Same comments go for the second plugin. >> > >I also refactored the plugin a bit (added a new base class to avoid code >duplication). > >Updated patches are attached. Patch 52 depends on patches 53 and 54. One small comment: I've refactored slapi-nis code to make it more generic and references to sssd in the configuration options went away, so please change this part too: >+ attr = users_entry.get('schema-compat-lookup-sssd') to + attr = users_entry.get('schema-compat-lookup-nsswitch') >+ if not attr or 'user' not in attr: >+ return dict(result=False) >+ >+ try: >+ groups_entry = ldap.get_entry(groups_dn) >+ except errors.NotFound: >+ return dict(result=False) >+ >+ attr = groups_entry.get('schema-compat-lookup-sssd') same here. It needs my patch 0112 too -- it changes ipa-adtrust-install to write proper configuration options to slapi-nis configs. -- / Alexander Bokovoy From npmccallum at redhat.com Mon Aug 5 13:41:55 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 05 Aug 2013 09:41:55 -0400 Subject: [Freeipa-devel] Plugin registration API (Was: [PATCH] Return klass in api.register()) In-Reply-To: <51FA694F.8020108@redhat.com> References: <1375197416.9252.0.camel@localhost> <51F7F0B2.6010402@redhat.com> <1375207538.9252.30.camel@localhost> <51F8D402.8060009@redhat.com> <1375289021.9252.51.camel@localhost> <51FA694F.8020108@redhat.com> Message-ID: <1375710115.13222.3.camel@localhost> On Thu, 2013-08-01 at 15:57 +0200, Petr Viktorin wrote: > Here is a patch that implements the API I proposed, but with old > semantics. Plugins using this won't need to be rewritten when we switch > the behavior as well. +1, reviewed. > I've also converted one of the plugins to use this. If your approach is > accepted please do this as well -- if we support an API we want it tested. I prefer your design. From akrivoka at redhat.com Mon Aug 5 14:55:35 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 05 Aug 2013 16:55:35 +0200 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <20130805125723.GU15859@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> <20130805125723.GU15859@redhat.com> Message-ID: <51FFBCE7.8090209@redhat.com> On 08/05/2013 02:57 PM, Alexander Bokovoy wrote: > On Fri, 02 Aug 2013, Ana Krivokapic wrote: >> On 08/01/2013 04:13 PM, Alexander Bokovoy wrote: >>> Hi! >>> >>> On Thu, 01 Aug 2013, Ana Krivokapic wrote: >>>> Hello, >> >> Thanks Alexander for the quick review! >> >>>> >>>> This patch adds ipa-advise plugins to help configure legacy clients for access >>>> to trusted domain resources. For more details, please read the commit message. >>>> Plugins are currently named "config-redhat-sssd-before-1-9" and >>>> "config-generic-sssd-before-1-9"; suggestions for better names are welcome. >>>> >>>> Plugin content heavily inspired by >>>> https://fedoraproject.org/wiki/QA:Testcase_freeipa_use_legacy_sssd_to_give_access_to_trusted_domain_users. >>>> >>>> >>> I think it is a good start. Comments inline. >>> >>>> https://fedorahosted.org/freeipa/ticket/3671 >>>> --- >>>> install/share/Makefile.am | 2 + >>>> install/share/pam.conf.template | 22 ++++++ >>>> install/share/sssd.conf.template | 12 +++ >>> I would imagine we would have multiple plugins that need their own >>> templates for pam.conf/sssd.conf. What about introducing >>> to avoid conflicts? >>> >>> In this case you use the same templates for both plugins so you might >>> have as 'legacy', for example. >>> >>> Another way is to have plugin name in the template, e.g. >>> legacy.sssd.conf.template. >> >> Done. I opted for the install/share/advise//*.template option. The changes >> are in the updated patch 52. >> >>> >>>> +class config_redhat_sssd_before_1_9(Advice): >>>> + """ >>>> + Legacy client configuration for Red Hat based platforms. >>>> + """ >>>> + >>>> + description = ('Instructions for configuring a system with an old >>>> version ' >>>> + 'of SSSD (1.5-1.8) as a FreeIPA client. This set of ' >>>> + 'instructions is targeted for platforms that include ' >>>> + 'the authconfig utility, which are all Red Hat based ' >>>> + 'platforms.') >>> You need to check that Schema Compatibility plugin is configured to >>> serve trusted domain users and groups. >>> >>> We have two trees: >>> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >>> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>> >>> In both of the trees there should be >>> schema-compat-lookup-sssd: >>> >>> attribute, with the value according to the tree (i.e. user for >>> cn=users). >>> >>> If not, then suggest to run 'ipa-adtrust-install --enable-compat=true' on the >>> IPA server. >> >> Done. I added a new API command 'compat-is-enabled' (similar to >> 'adtrust-is-enabled') to facilitate checking whether the Schema Compatibility >> plugin is configured. 'compat-is-enabled' is called from the ipa-advise plugin >> and the suggestion to run 'ipa-adtrust-install --enable-compat' is printed as >> the first piece of advice, when appropriate. >> >> Patch 54 adds the new API command 'compat-is-enabled', while patch 53 is a small >> fix which enables IPA API commands to be run from the ipa-advise plugins. >> >>> >>>> + >>>> + def get_info(self): >>>> + self.log.comment('Install the sssd and authconfig packages via yum') >>>> + self.log.command('yum install -y sssd authconfig\n') >>> You are using 'wget' below, it might make sense to add it into the above >>> line too. >> >> Fixed in patch 52. >> >>> >>>> + >>>> + self.log.comment('Download the CA certificate of the IPA server') >>>> + self.log.command('mkdir -p -m 755 /etc/openldap/cacerts') >>>> + self.log.command('wget http://%s/ipa/config/ca.crt -O ' >>>> + '/etc/openldap/cacerts/ipa.crt\n' % api.env.host) >>>> + >>>> + self.log.comment('Generate hashes for the openldap library') >>>> + self.log.command('cacertdir_rehash /etc/openldap/cacerts/\n') >>>> + >>>> + self.log.comment('Use the authconfig to configure nsswitch.conf ' >>>> + 'and the PAM stack') >>>> + self.log.command('authconfig --updateall --enablesssd ' >>>> + '--enablesssdauth\n') >>>> + >>>> + self.log.comment('Configure SSSD') >>>> + self.log.command('cat > /etc/sssd/sssd.conf << EOF \n' >>>> + '%s\nEOF' % generate_sssd_conf()) >>>> + self.log.command('chmod 0600 /etc/sssd/sssd.conf\n') >>>> + >>>> + self.log.comment('Start SSSD') >>>> + self.log.command('service sssd start') >>> Would it make sense to also add instructions to restore SELinux context >>> (if needed)? I'm not sure, just throwing the idea for consideration. >> >> I am not sure about this either so I will wait for more opinions about this. >> >>> >>> Same comments go for the second plugin. >>> >> >> I also refactored the plugin a bit (added a new base class to avoid code >> duplication). >> >> Updated patches are attached. Patch 52 depends on patches 53 and 54. > One small comment: > > I've refactored slapi-nis code to make it more generic and references to > sssd in the configuration options went away, so please change this part > too: > >> + attr = users_entry.get('schema-compat-lookup-sssd') > to + attr = users_entry.get('schema-compat-lookup-nsswitch') > >> + if not attr or 'user' not in attr: >> + return dict(result=False) >> + >> + try: >> + groups_entry = ldap.get_entry(groups_dn) >> + except errors.NotFound: >> + return dict(result=False) >> + >> + attr = groups_entry.get('schema-compat-lookup-sssd') > same here. > > It needs my patch 0112 too -- it changes ipa-adtrust-install to write > proper configuration options to slapi-nis configs. Done. Also, references to both relevant tickets https://fedorahosted.org/freeipa/ticket/3671 and https://fedorahosted.org/freeipa/ticket/3672 added to commit messages. Updated patches attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0052-03-Add-ipa-advise-plugins-for-legacy-clients.patch Type: text/x-patch Size: 11594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0054-02-Add-new-command-compat-is-enabled.patch Type: text/x-patch Size: 3262 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0053-02-Enable-running-API-commands-in-ipa-advise-plugins.patch Type: text/x-patch Size: 2038 bytes Desc: not available URL: From mkosek at redhat.com Mon Aug 5 15:43:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 05 Aug 2013 17:43:45 +0200 Subject: [Freeipa-devel] [PATCH 0083] Make CS.cfg edits with CA instance stopped In-Reply-To: <1928170.mqmQzikh1F@thinkpad7.brq.redhat.com> References: <1928170.mqmQzikh1F@thinkpad7.brq.redhat.com> Message-ID: <51FFC831.5060703@redhat.com> On 08/02/2013 03:32 PM, Tomas Babej wrote: > Hi, > > This patch makes sure that all edits to CS.cfg configuration file > are performed while pki-tomcatd service is stopped. > > Introduces a new contextmanager stopped_service for handling > a general problem of performing a task that needs certain service > being stopped. > > https://fedorahosted.org/freeipa/ticket/3804 > > Tomas > 1) I think it would make sense to ideally run the steps updating CS.cfg close together, stop PKI before this group and start it after it finishes. Otherwise, installer runs many service stops and starts which may be error prone, especially given the fragile (and sometimes slow) java server handling. 2) I am thinking that stopped_service context manager could be as well defined in ipaserver/install/service.py, as a context manager of the class. That way, every installer class could use that like: class CAInstance(): ... def __some_step(self): with self.stopped_service(start_when_finished=True): # do something That way, context manager could just use self.name to avoid numerous hardcoded service names like: ... with stopped_service('pki_tomcatd', instance_name=self.dogtag_constants.PKI_INSTANCE_NAME): ... 3) After I installed pki-ca, I saw no published CRL files: # ls -la /var/lib/ipa/pki-ca/publish/ I am not sure what is the root cause, maybe some of the numerous start/restarts broke the publisher process. Martin From mkosek at redhat.com Mon Aug 5 15:48:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 05 Aug 2013 17:48:20 +0200 Subject: [Freeipa-devel] [PATCH 0084] Improve help entry for ipa host In-Reply-To: <1643125.dD1kTBdeuB@thinkpad7.brq.redhat.com> References: <1643125.dD1kTBdeuB@thinkpad7.brq.redhat.com> Message-ID: <51FFC944.8010908@redhat.com> On 08/02/2013 05:16 PM, Tomas Babej wrote: > Hi, > > Updates old information produced by the ipa help host command. > Also adds a section to ipa-client-install manpage about client > re-enrollment. > > https://fedorahosted.org/freeipa/ticket/3820 > > Tomas > 1) "-" should be backslashed in the man pages (as others are) 2) s/perserved/preserved/ Martin From mkosek at redhat.com Mon Aug 5 15:53:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 05 Aug 2013 17:53:19 +0200 Subject: [Freeipa-devel] [PATCH 0085] Limit pwpolicy maxlife to 20000 days In-Reply-To: <2353202.ZGBLvey0gJ@thinkpad7.brq.redhat.com> References: <2353202.ZGBLvey0gJ@thinkpad7.brq.redhat.com> Message-ID: <51FFCA6F.2050109@redhat.com> On 08/05/2013 02:45 PM, Tomas Babej wrote: > Hi, > > Since krbMaxPwdLife attribute is represented as number of seconds, > setting maxlife to high values such as 999 999 days (~2739 years) > would result to overflow when parsing this attribute in kdb plugin, > and hence default maxlife of 90 days would be applied. > > Limit the maximum value of maxlife that can be set through the > framework to 20 000 days (~ 54 years). > > https://fedorahosted.org/freeipa/ticket/3817 > > Tomas ACK. Pushed to master. Martin From mkosek at redhat.com Mon Aug 5 15:59:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 05 Aug 2013 17:59:32 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> Message-ID: <51FFCBE4.8050807@redhat.com> On 07/17/2013 01:47 PM, Tomas Babej wrote: >> I will release version 3.5 before end of this week. I have some small fixes >> ready so it is worth to release it now. >> >> To summarize the discussion - please remove following options from >> configuration file and LDAP schema: >> cache_ttl >> psearch (attribute idnsPersistentSearch in idnsConfigObject) >> zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) >> >> -- >> Petr^2 Spacek > > I have a patch ready, but it can't be tested until 3.5 is out. > > Tomas > I did not test the patch yet, I just want to comment on one thing I just noticed. I is it a good idea to remove idnsZoneRefresh and idnsPersistentSearch attribute types and modify idnsConfigObject objectclass? This will affect not only new instances, but also the old ones (i.e. RHEL-6.4) which may still use these attributes. DNS config object would suddenly become unusable because DS would refuse to operate the entry as it does not follow the schema. The same applies for ACIs. I would personally not do these changes yet, I think just hiding and marking as DeprecatedParam is enough for now. Alexander, what do you think? Martin From tbabej at redhat.com Mon Aug 5 16:40:24 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 05 Aug 2013 18:40:24 +0200 Subject: [Freeipa-devel] [PATCH 0084] Improve help entry for ipa host In-Reply-To: <51FFC944.8010908@redhat.com> References: <1643125.dD1kTBdeuB@thinkpad7.brq.redhat.com> <51FFC944.8010908@redhat.com> Message-ID: <51FFD578.40207@redhat.com> On 08/05/2013 05:48 PM, Martin Kosek wrote: > On 08/02/2013 05:16 PM, Tomas Babej wrote: >> Hi, >> >> Updates old information produced by the ipa help host command. >> Also adds a section to ipa-client-install manpage about client >> re-enrollment. >> >> https://fedorahosted.org/freeipa/ticket/3820 >> >> Tomas >> > 1) "-" should be backslashed in the man pages (as others are) > > 2) s/perserved/preserved/ > > Martin Thanks! I also fixed the new-line formatting so that content is more fluid when resizing terminal. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0084-2-Improve-help-entry-for-ipa-host.patch Type: text/x-patch Size: 3536 bytes Desc: not available URL: From akrivoka at redhat.com Mon Aug 5 17:05:25 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 05 Aug 2013 19:05:25 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Handle --subject option in ipa-server-install In-Reply-To: <51FA762C.8090909@redhat.com> References: <51F778EA.7040305@redhat.com> <51F7E8C7.2000705@redhat.com> <51F8DE33.50801@redhat.com> <51FA5A81.8070904@redhat.com> <51FA5B79.8090406@redhat.com> <51FA5F7D.30503@redhat.com> <51FA762C.8090909@redhat.com> Message-ID: <51FFDB55.3080701@redhat.com> On 08/01/2013 04:52 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 08/01/2013 02:58 PM, Martin Kosek wrote: >>> On 08/01/2013 02:54 PM, Petr Viktorin wrote: >>>> On 07/31/2013 11:51 AM, Ana Krivokapic wrote: >>>>> On 07/30/2013 06:24 PM, Petr Viktorin wrote: >>>>>> On 07/30/2013 10:27 AM, Ana Krivokapic wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This patch addresses ticket >>>>>>> https://fedorahosted.org/freeipa/ticket/3783. >>>>>>> >>>>>> >>>>>> Thanks for the patch, I have a concern below: >>>>>> >>>>>>> freeipa-akrivoka-0051-Handle-subject-option-in-ipa-server-install.patch >>>>>>> >>>>>>> diff --git a/install/tools/ipa-upgradeconfig >>>>>>> b/install/tools/ipa-upgradeconfig >>>>>>> index >>>>>>> de17c5b23d79f31e8571a3400d44397630cadada..a2625e6198bcff0811c482e479c8af10716dcea1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> 100644 >>>>>>> --- a/install/tools/ipa-upgradeconfig >>>>>>> +++ b/install/tools/ipa-upgradeconfig >>>>>>> @@ -894,6 +895,7 @@ def main(): >>>>>>> configured_constants = dogtag.configured_constants() >>>>>>> sub_dict = dict( >>>>>>> REALM=api.env.realm, >>>>>>> + SUBJECT_BASE=str(DN(('O', api.env.realm))), >>>>>> >>>>>> When certmap.conf.template's version changes again, this will >>>>>> rewrite the >>>>>> subject to the default. Don't we want to use the subject base also >>>>>> here? >>>>>> >>>>>> >>>>>> >>>>> >>>>> You are right. The updated patch uses the current value of subject >>>>> base from >>>>> LDAP to update certmap.conf during upgrades. >>>> >>>> When ipa-upgradeconfig is run while the DS is down, this results in a >>>> small >>>> warning, and very bad configuration: >>>> certmap ipaca CN=Certificate Authority,None >>>> >>>> >>>> I'm not sure how this should be handled. I'm adding Rob to the loop. >>>> Rob, can we start the DS in ipa-upgradeconfig? That sounds quite >>>> heavy-handed >>>> for a RPM upgrade script. >>>> >>>> Maybe if the DS is unavailable, we should use the old value from the >>>> config >>>> file itself. >>> >>> Values can be stored/restored using a sysupgrade module. >> >> The problem is that (AFAIK) old instances won't have this particular >> value stored. Upgrading from 3.1 to a future version where certmap.conf >> is modified again would fail. >> >>> I would not be so >>> afraid of starting the DS module, we already do that exercise in >>> ipa-ldap-updater, so adding it in ipa-upgradeconfig too does not >>> change much. >>> >>> Question is, what should we do what DS cannot be started or cannot be >>> read >>> (e.g. when upgrade is run in fedup's chrooted environment) - we must >>> make sure >>> we don't mess the configuration up. >> >> Again AFAIK, if the server is down, certmap.conf is the only place where >> this value is available. I didn't check thoroughly, though. > > I think that's right. > > So the big problem here is we have no way of alerting users to possible > problems found during the upgrade unless they happen to sift through > ipaupgrade.log, which tends to be huge, and most users don't even know about. > > Part of this is due to not displaying anything during an rpm upgrade. I think > we should print any exceptional errors found during the upgrade. Sure, > something may eat the output, but it's a best effort sort of thing. > > I don't see us finding a perfect solution here. What I'd propose is this: > > - Store the value in sysupgrade from now on, even in new installs > - Look there first on upgrade > - Start dirsrv if necessary get the value > - If we can't get the value, skip changing file and log loudly > - Find out exactly this will present to a user by doing an upgrade from an old > version to master and create an FAQ entry. > > I think that's about the best we can do. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Updated patch tries to find the subject base value by searching in this order: 1) sysupgrade 2) dirsrv 3) certmap.conf If it cannot be found, an error is displayed and the file is not modified. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0051-03-Handle-subject-option-in-ipa-server-install.patch Type: text/x-patch Size: 7391 bytes Desc: not available URL: From abokovoy at redhat.com Mon Aug 5 18:55:26 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Aug 2013 21:55:26 +0300 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <51FFBCE7.8090209@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> <20130805125723.GU15859@redhat.com> <51FFBCE7.8090209@redhat.com> Message-ID: <20130805185526.GW15859@redhat.com> On Mon, 05 Aug 2013, Ana Krivokapic wrote: >>> + except errors.NotFound: >>> + return dict(result=False) >>> + >>> + attr = groups_entry.get('schema-compat-lookup-sssd') >> same here. >> >> It needs my patch 0112 too -- it changes ipa-adtrust-install to write >> proper configuration options to slapi-nis configs. > >Done. > >Also, references to both relevant tickets >https://fedorahosted.org/freeipa/ticket/3671 and >https://fedorahosted.org/freeipa/ticket/3672 added to commit messages. > >Updated patches attached. Thanks. Few more comments now that I've ran the ipa-advise with the plugins: 1. We need to put downloading the certificate to both plugins. 2. The certificate needs to be specified in sssd.conf as well as ldap.conf Also it would be nice to actually reformat comments to be shorter. I think it should be done on a framework level -- we have the code for that already in the CLI handlers. Additionally, plugin writers may want to have 'verbatim' comments, i.e. which would resist reformatting. The same reformatting should be applied to the list of advises shown by 'ipa-advise' by default. It is now a bit unreadable. -- / Alexander Bokovoy From nalin at redhat.com Mon Aug 5 20:17:22 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 5 Aug 2013 16:17:22 -0400 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130805124506.GT15859@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> <20130801200047.GB3268@redhat.com> <20130802055228.GP15859@redhat.com> <20130802134433.GQ15859@redhat.com> <20130804200457.GA19227@redhat.com> <20130805124506.GT15859@redhat.com> Message-ID: <20130805201722.GB22172@redhat.com> On Mon, Aug 05, 2013 at 03:45:06PM +0300, Alexander Bokovoy wrote: > OK, fair enough. I did use of libsss_nss_idmap optional. For tests I > think we need to involve nsswrapper here to make sure of a predictable > testing. > > I've added: > > --with-nsswitch use nsswitch API to look up users and groupsnot > found in the LDAP > --with-sss-nss-idmap use libsss_nss_idmap to discover SIDs. Requires > --with-nsswitch as well > --with-pam use PAM API to authenticate users not found in the > LDAP. Requires --with-nsswitch as well > > And also split PAM use -- if --with-nsswitch is provided, you may > optionally disable use of PAM. I like where this is going, but the configure logic looks a bit off. In HEAD~9, if configure is passed --without-nsswitch, $use_nsswitch will be set to "no", so the conditional USE_NSSWITCH will be enabled. The USE_PAM conditional's based on $use_nsswitch instead of $use_pam, which looks like a copy/paste error. The subsequent call to check the contents of $USE_NSSWITCH should probably be changed to check $use_nsswitch, as automake conditionals don't set variables in configure that are named after the conditionals. Likewise for $USE_PAM and $use_pam. > I also moved src/back-sch-sssd.c to src/back-sch-nss.c to reflect that > and renamed SSSD references to NSSWITCH. Ok. Some line wrapping adjustments appear to still be needed. > >>>>HEAD~7: > >>>>* Fix formatting of wrapped lines when calling backend_shr_get_vattr_str(). > >>>>* Check for errors when converting the configured sssd_min_id to a number > >>>>by switching from atol() to strtol() or strtoul(). > >>>done. > > > >Looks good, except that the comment in the checking block implies that > >it's imposing a lower limit on ret.sssd_min_id, when it's reassigning > >the default in case of a parsing error. If the value parses as valid, > >it appears that a value lower than 1000 would be accepted. > That's OK because it is a configuration option. If you want to have it set > to something like 500, so be it -- not all distributions enforce 1000 > as their defaults. That's fine by me. Please correct the comment to reflect the intent. > >>>>HEAD~6: > >>>>* Drop extra whitespace after the type of the "name" member when > >>>>defining struct backend_search_filter_config. > >>>>* backend_search_filter_has_cn_uid() allocates config->name using > >>>>slapi_ch_malloc(), but it is later freed by free(). > >>>>* backend_retrieve_user_entry_from_sssd(): fix line wrapping in > >>>>function signature. > >>>>* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. > >>>>* backend_retrieve_user_entry_from_sssd(): avoid using > >>>>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit > >>>>with the high bit set as a negative value > >>>>* backend_retrieve_user_entry_from_sssd(): check for zero-length > >>>>pw_shell value, and avoid adding it as a loginShell value, since > >>>>that'd be invalid > >>>all done. > > > >That last one's just a NULL check now. Please add a check for a > >zero-length value, which would also be skipped. Otherwise, looks good. > Done. Good. One thing I just noticed: in backend_search_filter_has_cn_uid(), is there a guarantee that bval->bv_val is NUL-terminated when it's being passed to strcasecmp()? If not, it could cause problems later. > >>>>* backend_retrieve_group_list_from_sssd(): check for NULL result from > >>>>realloc(). > > > >Leaks are possible if realloc() fails for grouplist or entries. > I've used a temporary variable to realloc() into and then only change > 'entries' if its value is not NULL. This should handle the case. I see it being handled for 'entries' now, but not where it's being done for 'grouplist'. > >>>>* backend_search_cb() now appears to be freeing the closest-match > >>>>as part of a conditional clause, right before it would unconditionally > >>>>do so. > >>>removed the duplicate. My original intent in moving that code was to > >>>avoid freeing closest-match right before we are printing it with > >>>slapi_log_error() and then sending the result with send_ldap_result(): > >>>https://git.fedorahosted.org/cgit/slapi-nis.git/tree/src/back-sch.c#n1219 > >>> > >>>I can revert this part back if you wish but I think there is an error in > >>>the original code. > > > >The current intent there is to avoid sending a closest-match DN when > >we're returning entries as part of the result, to only send such a value > >as part of the result if we're sending back an LDAP_NO_SUCH_OBJECT > >error. > My main issue with this is that for the case when we found the entry we > still show the debug message with 'closest match = (null)'. I think it > is misleading at least. Oh, that's the error you were referring to. Yeah, we should fix that. > >>... and I did fix couple more comments received from Sumit: > >> > >>1. switched to use usigned long for sssd_min_id > >>2. added initializer for 'dn' in backend_retrieve_user_entry_from_sssd()/backend_retrieve_group_entry_from_sssd > >>3. switched to atoll() with cast of the result to (uid_t)/(gid_t) because > >> we already know at staging phase that the id in as a string will convert without errors to an integer and it is > min id. > > > >Okay. Though, formatting the uid/gid as a string to pass it into a > >local function that converts it right back to an integer seems > >excessive. Anyhow, I guess we're down to minor stuff now. > Following this suggestion, I made two entry points to a larger helper, > one is a general one and another accepting the gid directly. The second one is > used by the grouplist search. Looks reasonable. HTH, Nalin From jhrozek at redhat.com Mon Aug 5 22:15:26 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 6 Aug 2013 00:15:26 +0200 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <20130805185526.GW15859@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> <20130805125723.GU15859@redhat.com> <51FFBCE7.8090209@redhat.com> <20130805185526.GW15859@redhat.com> Message-ID: <20130805221526.GP4537@hendrix.brq.redhat.com> On Mon, Aug 05, 2013 at 09:55:26PM +0300, Alexander Bokovoy wrote: > On Mon, 05 Aug 2013, Ana Krivokapic wrote: > >>>+ except errors.NotFound: > >>>+ return dict(result=False) > >>>+ > >>>+ attr = groups_entry.get('schema-compat-lookup-sssd') > >>same here. > >> > >>It needs my patch 0112 too -- it changes ipa-adtrust-install to write > >>proper configuration options to slapi-nis configs. > > > >Done. > > > >Also, references to both relevant tickets > >https://fedorahosted.org/freeipa/ticket/3671 and > >https://fedorahosted.org/freeipa/ticket/3672 added to commit messages. > > > >Updated patches attached. > Thanks. Few more comments now that I've ran the ipa-advise with the > plugins: > > 1. We need to put downloading the certificate to both plugins. Right, this is something that was documented on the wiki during the test day and I agree with Alexander it makes sense to be present in the advise tool as well. > 2. The certificate needs to be specified in sssd.conf as well as ldap.conf Wouldn't it be better to just say that you need to make sure that the certicicates are present on openldap's configured directories? That would cover not only the SSSD but also all the tool like ldapsearch the admin might want to run for troubleshooting. Maybe a hint to run cacertdir_rehash would be nice. From mkosek at redhat.com Tue Aug 6 08:35:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 10:35:08 +0200 Subject: [Freeipa-devel] [PATCH] 0256 Fix installutils.get_password without a TTY In-Reply-To: <1375200353.9252.8.camel@localhost> References: <51F7A051.2020403@redhat.com> <1375197653.9252.2.camel@localhost> <51F7DD94.6060804@redhat.com> <1375198990.9252.7.camel@localhost> <51F7E34F.7000602@redhat.com> <1375200353.9252.8.camel@localhost> Message-ID: <5200B53C.1050107@redhat.com> On 07/30/2013 06:05 PM, Nathaniel McCallum wrote: > On Tue, 2013-07-30 at 18:01 +0200, Petr Viktorin wrote: >> On 07/30/2013 05:23 PM, Ana Krivokapic wrote:> On 07/30/2013 01:15 PM, > >> There's a typo in the commit message: "ises" instead of "uses". >> >> Fixed. >> >> >> On 07/30/2013 05:43 PM, Nathaniel McCallum wrote: >>> On Tue, 2013-07-30 at 17:36 +0200, Petr Viktorin wrote: >>>> On 07/30/2013 05:20 PM, Nathaniel McCallum wrote: >>>>> On Tue, 2013-07-30 at 13:15 +0200, Petr Viktorin wrote: >>>>>> See the commit message or ticket. >>>>>> >>>>>> This is a nuisance when writing tests for interactive prompting. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3824 >>>>> >>>>> There appears to be a stray comma. >>>> >>>> The comma at the end of a print statement suppresses the trailing newline. >>> >>> Wouldn't sys.stdout.write() be clearer? >> >> I don't have a preference. Changed. >> >>> The comma approach also doesn't work in py3k. >> >> Well, the print statement itself doesn't work in py3k :) >> >> The 2to3 tool handles the trailing comma without problems (and we'll >> probably use the print fixer when porting). >> >> $ 2to3 --fix print /tmp/printtest.py >> RefactoringTool: Refactored /tmp/printtest.py >> --- /tmp/printtest.py (original) >> +++ /tmp/printtest.py (refactored) >> @@ -1 +1 @@ >> -print 'foo', >> +print('foo', end=' ') >> RefactoringTool: Files that need to be modified: >> RefactoringTool: /tmp/printtest.py >> > > +1 ACK for Petr's patch. Pushed to master. Martin From tbabej at redhat.com Tue Aug 6 08:46:19 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 Aug 2013 10:46:19 +0200 Subject: [Freeipa-devel] [PATCH 0086] Remove overlapping use-cases of the same result variable Message-ID: <5200B7DB.4000203@redhat.com> Hi, a simple fix for an issue I found while reading the code. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0086-Remove-overlapping-use-cases-of-the-same-result-vari.patch Type: text/x-patch Size: 1328 bytes Desc: not available URL: From tbabej at redhat.com Tue Aug 6 08:55:18 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 Aug 2013 10:55:18 +0200 Subject: [Freeipa-devel] [PATCH 0086] Remove overlapping use-cases of the same result variable In-Reply-To: <5200B7DB.4000203@redhat.com> References: <5200B7DB.4000203@redhat.com> Message-ID: <5200B9F6.20802@redhat.com> On 08/06/2013 10:46 AM, Tomas Babej wrote: > Hi, > > a simple fix for an issue I found while reading the code. > > -- > Tomas Babej > Associate Software Engeneer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel One occurrence missing, thanks Alexander. Tomas -- -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | Mobile: +421 949 134 729 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0086-2-Remove-overlapping-use-cases-of-the-same-result-vari.patch Type: text/x-patch Size: 1534 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 6 08:56:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 10:56:30 +0200 Subject: [Freeipa-devel] New FreeIPA.org wiki templates Message-ID: <5200BA3E.6060202@redhat.com> Hello, I added 2 new templates for informational or warning messages in wiki: http://www.freeipa.org/page/Template:Admon/note http://www.freeipa.org/page/Template:Admon/important They are great to point some information out of normal text, much more visible than for example just making text bold. Both templates are ported from Fedora project wiki (https://fedoraproject.org). To use: {{admon/note | Title | Message body }} Example: http://www.freeipa.org/page/Downloads HTH, Martin From mkosek at redhat.com Tue Aug 6 10:26:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 12:26:28 +0200 Subject: [Freeipa-devel] [PATCH 0082] Use case-insensitive dict for trusted domain info In-Reply-To: <2136025.0jqZbo4hvD@thinkpad7.brq.redhat.com> References: <7974382.AtMgSypeFm@thinkpad7.brq.redhat.com> <2136025.0jqZbo4hvD@thinkpad7.brq.redhat.com> Message-ID: <5200CF54.2070007@redhat.com> On 07/26/2013 11:15 AM, Tomas Babej wrote: > On Friday 26 of July 2013 11:07:05 Tomas Babej wrote: >> Hi, >> >> In DomainValidator, we store a dictionary containing information >> for trusted domains. This is a case-sensitive dictionary keyed by >> the domain name. >> >> We need to use case-insensitive dictionary since domain names >> are generally case-insensitive. >> >> https://fedorahosted.org/freeipa/ticket/3816 >> >> Tomas >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Yes, I know. > > Tomas Worked fine (tested with AD2012). ACK, pushed to master. Martin From mkosek at redhat.com Tue Aug 6 10:32:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 12:32:34 +0200 Subject: [Freeipa-devel] [PATCH 0084] Improve help entry for ipa host In-Reply-To: <51FFD578.40207@redhat.com> References: <1643125.dD1kTBdeuB@thinkpad7.brq.redhat.com> <51FFC944.8010908@redhat.com> <51FFD578.40207@redhat.com> Message-ID: <5200D0C2.6060400@redhat.com> On 08/05/2013 06:40 PM, Tomas Babej wrote: > On 08/05/2013 05:48 PM, Martin Kosek wrote: >> On 08/02/2013 05:16 PM, Tomas Babej wrote: >>> Hi, >>> >>> Updates old information produced by the ipa help host command. >>> Also adds a section to ipa-client-install manpage about client >>> re-enrollment. >>> >>> https://fedorahosted.org/freeipa/ticket/3820 >>> >>> Tomas >>> >> 1) "-" should be backslashed in the man pages (as others are) >> >> 2) s/perserved/preserved/ >> >> Martin > Thanks! > > I also fixed the new-line formatting so that content is more fluid when > resizing terminal. > > Updated patch attached. > > Tomas > ACK. Pushed to master. Martin From mkosek at redhat.com Tue Aug 6 10:37:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 12:37:17 +0200 Subject: [Freeipa-devel] [PATCH] 0109-0110 Support querying AD DC when establishing trust as HTTP/ipa.server principal In-Reply-To: <1374589918.15431.7.camel@willson.li.ssimo.org> References: <20130718153733.GX18587@redhat.com> <1374581750.15431.4.camel@willson.li.ssimo.org> <20130723131158.GI15859@redhat.com> <1374589918.15431.7.camel@willson.li.ssimo.org> Message-ID: <5200D1DD.9060204@redhat.com> On 07/23/2013 04:31 PM, Simo Sorce wrote: > On Tue, 2013-07-23 at 16:11 +0300, Alexander Bokovoy wrote: >> On Tue, 23 Jul 2013, Simo Sorce wrote: >>> On Thu, 2013-07-18 at 18:37 +0300, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Attached patches make possible to use HTTP/ipa.server at REALM to query AD >>>> DC over LDAP immediately after trust is established. We need this to get >>>> range discovery working prior to creating range for trusted domain. >>>> >>>> The patch 0109 makes KDC hostname cached on ipadb context to avoid >>>> resolving own hostname multiple times. >>>> >>>> The patch 0110 depends on ulc_casemap patches by Nathaniel and makes >>>> exception for HTTP/ipa.server at REALM when TGT is requested and MS-PAC is >>>> asked for -- we force refreshing list of trusted domains here. >>>> >>>> More details are available in the commit logs. >>> >>> I do not think that changing reinit interval is the right thing to do. >>> >>> I would rather pass a boolean that tells reinit to check if we have any >>> trust info, and if not unconditionally try to reinit immediately. >>> >>> I see that you treat the interval sort of like a boolean but then you >>> just race hoping the previous reload w/o trust info happened more than 1 >>> second earlier. >>> >>> I think and explicit "bool force_reload" flag would be much clearer. >>> >>> Otherwise ack. >> Attached is modified patch that uses 'bool force_reinit' (as function is >> called ipadb_reinit_mspac). >> >> I tested it together with updated Tomas patch 0076 which relies on these >> patches so I'm going to commit whole set together. > > LGTM, please proceed. > > Simo. Just to close this thread - patch was pushed to master. Martin From abokovoy at redhat.com Tue Aug 6 11:26:20 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 6 Aug 2013 14:26:20 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130805201722.GB22172@redhat.com> References: <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> <20130801200047.GB3268@redhat.com> <20130802055228.GP15859@redhat.com> <20130802134433.GQ15859@redhat.com> <20130804200457.GA19227@redhat.com> <20130805124506.GT15859@redhat.com> <20130805201722.GB22172@redhat.com> Message-ID: <20130806112620.GY15859@redhat.com> On Mon, 05 Aug 2013, Nalin Dahyabhai wrote: >On Mon, Aug 05, 2013 at 03:45:06PM +0300, Alexander Bokovoy wrote: >> OK, fair enough. I did use of libsss_nss_idmap optional. For tests I >> think we need to involve nsswrapper here to make sure of a predictable >> testing. >> >> I've added: >> >> --with-nsswitch use nsswitch API to look up users and groupsnot >> found in the LDAP >> --with-sss-nss-idmap use libsss_nss_idmap to discover SIDs. Requires >> --with-nsswitch as well >> --with-pam use PAM API to authenticate users not found in the >> LDAP. Requires --with-nsswitch as well >> >> And also split PAM use -- if --with-nsswitch is provided, you may >> optionally disable use of PAM. > >I like where this is going, but the configure logic looks a bit off. > >In HEAD~9, if configure is passed --without-nsswitch, $use_nsswitch will >be set to "no", so the conditional USE_NSSWITCH will be enabled. The >USE_PAM conditional's based on $use_nsswitch instead of $use_pam, which >looks like a copy/paste error. > >The subsequent call to check the contents of $USE_NSSWITCH should >probably be changed to check $use_nsswitch, as automake conditionals >don't set variables in configure that are named after the conditionals. >Likewise for $USE_PAM and $use_pam. Thanks, fixed. >> I also moved src/back-sch-sssd.c to src/back-sch-nss.c to reflect that >> and renamed SSSD references to NSSWITCH. > >Ok. Some line wrapping adjustments appear to still be needed. Yes, fixed. >> >Looks good, except that the comment in the checking block implies that >> >it's imposing a lower limit on ret.sssd_min_id, when it's reassigning >> >the default in case of a parsing error. If the value parses as valid, >> >it appears that a value lower than 1000 would be accepted. >> That's OK because it is a configuration option. If you want to have it set >> to something like 500, so be it -- not all distributions enforce 1000 >> as their defaults. > >That's fine by me. Please correct the comment to reflect the intent. I've added one more sentence. Below is the full comment, reformatted by my mail client: /* Make sure we don't return system users/groups by limiting lower bound on searches. * If config value cannot be parsed or not specified, default to 1000. * It is OK to specify something lower in the config as some * Linux distributions force lower limit to 500 */ >> >>>>HEAD~6: >> >>>>* Drop extra whitespace after the type of the "name" member when >> >>>>defining struct backend_search_filter_config. >> >>>>* backend_search_filter_has_cn_uid() allocates config->name using >> >>>>slapi_ch_malloc(), but it is later freed by free(). >> >>>>* backend_retrieve_user_entry_from_sssd(): fix line wrapping in >> >>>>function signature. >> >>>>* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. >> >>>>* backend_retrieve_user_entry_from_sssd(): avoid using >> >>>>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit >> >>>>with the high bit set as a negative value >> >>>>* backend_retrieve_user_entry_from_sssd(): check for zero-length >> >>>>pw_shell value, and avoid adding it as a loginShell value, since >> >>>>that'd be invalid >> >>>all done. >> > >> >That last one's just a NULL check now. Please add a check for a >> >zero-length value, which would also be skipped. Otherwise, looks good. >> Done. > >Good. One thing I just noticed: in backend_search_filter_has_cn_uid(), >is there a guarantee that bval->bv_val is NUL-terminated when it's being >passed to strcasecmp()? If not, it could cause problems later. I've switched to use strncasecmp() with bval->bv_len but in reality slapd manages it as a NUL-terminated string: $ git grep f_avvalue filter.c: ptr = slapi_filter_sprintf(fmt, f->f_avtype, ESC_NEXT_VAL, f->f_avvalue.bv_val ); filter.c: if (strchr (f->f_avvalue.bv_val, '.')) { filter.c: char *ocname = oc_find_name( f->f_avvalue.bv_val ); filter.c: slapi_ch_free((void**)&f->f_avvalue.bv_val ); filter.c: f->f_avvalue.bv_val = ocname; filter.c: f->f_avvalue.bv_len = strlen ( f->f_avvalue.bv_val ); filter.c: *bval = &f->f_avvalue; filter.c: if ( 0 == strcasecmp ( f->f_avvalue.bv_val, SLAPI_ATTR_VALUE_TOMBSTONE)) { filter.c: if ( 0 == strcasecmp ( f->f_avvalue.bv_val, "ffffffff-ffffffff-ffffffff-ffffffff")) { slap.h:#define f_avvalue f_un.f_un_ava.ava_value str2filter.c: f->f_avvalue.bv_val = unqstr; str2filter.c: f->f_avvalue.bv_len = len2; str2filter.c: f->f_avvalue.bv_val = slapi_ch_strdup ( value ); str2filter.c: f->f_avvalue.bv_len = strlen ( f->f_avvalue.bv_val ); subentry.c: if ( 0 == strcasecmp ( f->f_avvalue.bv_val, "ldapsubentry")) { Using strncasecmp() doesn't really hurt. >> I've used a temporary variable to realloc() into and then only change >> 'entries' if its value is not NULL. This should handle the case. > >I see it being handled for 'entries' now, but not where it's being done >for 'grouplist'. Added handling to all realloc()s. Updated my tree with the new set of patches. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Aug 6 11:27:25 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 6 Aug 2013 14:27:25 +0300 Subject: [Freeipa-devel] [PATCH 0086] Remove overlapping use-cases of the same result variable In-Reply-To: <5200B9F6.20802@redhat.com> References: <5200B7DB.4000203@redhat.com> <5200B9F6.20802@redhat.com> Message-ID: <20130806112725.GZ15859@redhat.com> On Tue, 06 Aug 2013, Tomas Babej wrote: >On 08/06/2013 10:46 AM, Tomas Babej wrote: >>Hi, >> >>a simple fix for an issue I found while reading the code. > >One occurrence missing, thanks Alexander. ACK -- / Alexander Bokovoy From tbabej at redhat.com Tue Aug 6 11:38:43 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 Aug 2013 13:38:43 +0200 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <20130805185526.GW15859@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> <20130805125723.GU15859@redhat.com> <51FFBCE7.8090209@redhat.com> <20130805185526.GW15859@redhat.com> Message-ID: <5200E043.3020303@redhat.com> On 08/05/2013 08:55 PM, Alexander Bokovoy wrote: > On Mon, 05 Aug 2013, Ana Krivokapic wrote: >>>> + except errors.NotFound: >>>> + return dict(result=False) >>>> + >>>> + attr = groups_entry.get('schema-compat-lookup-sssd') >>> same here. >>> >>> It needs my patch 0112 too -- it changes ipa-adtrust-install to write >>> proper configuration options to slapi-nis configs. >> >> Done. >> >> Also, references to both relevant tickets >> https://fedorahosted.org/freeipa/ticket/3671 and >> https://fedorahosted.org/freeipa/ticket/3672 added to commit messages. >> >> Updated patches attached. > Thanks. Few more comments now that I've ran the ipa-advise with the > plugins: > > 1. We need to put downloading the certificate to both plugins. > 2. The certificate needs to be specified in sssd.conf as well as > ldap.conf > > Also it would be nice to actually reformat comments to be shorter. > I think it should be done on a framework level -- we have the code for > that already in the CLI handlers. Additionally, plugin writers may want > to have 'verbatim' comments, i.e. which would resist reformatting. The patch 0088 should fix that. Adds a wrapped flag to the log.comment command. > > The same reformatting should be applied to the list of advises shown by > 'ipa-advise' by default. It is now a bit unreadable. > The patch 0089 should fix that. Tomas -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tbabej at redhat.com Tue Aug 6 11:40:30 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 Aug 2013 13:40:30 +0200 Subject: [Freeipa-devel] [PATCHES 0088-0089] Add wrapping to ipa-advise Message-ID: <5200E0AE.9080306@redhat.com> Hi, these patches add wrapping to ipa-advise's output so that generated advices are more readable. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0088-Add-a-word-wrapping-for-comment-log-messages-to-Advi.patch Type: text/x-patch Size: 2636 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0089-Wrap-lines-in-the-list-of-available-advices.patch Type: text/x-patch Size: 2573 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 6 11:45:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 13:45:22 +0200 Subject: [Freeipa-devel] [PATCH 0086] Remove overlapping use-cases of the same result variable In-Reply-To: <20130806112725.GZ15859@redhat.com> References: <5200B7DB.4000203@redhat.com> <5200B9F6.20802@redhat.com> <20130806112725.GZ15859@redhat.com> Message-ID: <5200E1D2.3080605@redhat.com> On 08/06/2013 01:27 PM, Alexander Bokovoy wrote: > On Tue, 06 Aug 2013, Tomas Babej wrote: >> On 08/06/2013 10:46 AM, Tomas Babej wrote: >>> Hi, >>> >>> a simple fix for an issue I found while reading the code. >> >> One occurrence missing, thanks Alexander. > ACK > Pushed to master, ipa-3-2. Martin From akrivoka at redhat.com Tue Aug 6 12:02:51 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 06 Aug 2013 14:02:51 +0200 Subject: [Freeipa-devel] [PATCHES 0088-0089] Add wrapping to ipa-advise In-Reply-To: <5200E0AE.9080306@redhat.com> References: <5200E0AE.9080306@redhat.com> Message-ID: <5200E5EB.9050709@redhat.com> On 08/06/2013 01:40 PM, Tomas Babej wrote: > Hi, > > these patches add wrapping to ipa-advise's output so that generated advices > are more readable. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel There is a typo in the commit message for patch 89 (formmatted -> formatted). -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Aug 6 13:27:21 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 Aug 2013 15:27:21 +0200 Subject: [Freeipa-devel] [PATCH 0087] Log proper error message when defaultNamingContext not found Message-ID: <5200F9B9.5050709@redhat.com> Hi, When adding a trust using trust-add with misconfigured DNS, an improper LDAP entry might be returned. Log a proper error message. https://fedorahosted.org/freeipa/ticket/3690 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0087-Log-proper-error-message-when-defaultNamingContext-n.patch Type: text/x-patch Size: 1416 bytes Desc: not available URL: From abokovoy at redhat.com Tue Aug 6 13:46:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 6 Aug 2013 16:46:27 +0300 Subject: [Freeipa-devel] [PATCHES 0088-0089] Add wrapping to ipa-advise In-Reply-To: <5200E0AE.9080306@redhat.com> References: <5200E0AE.9080306@redhat.com> Message-ID: <20130806134627.GA27194@redhat.com> On Tue, 06 Aug 2013, Tomas Babej wrote: >Hi, > >these patches add wrapping to ipa-advise's output so that generated >advices are more readable. ACK, thanks! -- / Alexander Bokovoy From mkosek at redhat.com Tue Aug 6 13:55:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 15:55:45 +0200 Subject: [Freeipa-devel] [PATCHES 0088-0089] Add wrapping to ipa-advise In-Reply-To: <20130806134627.GA27194@redhat.com> References: <5200E0AE.9080306@redhat.com> <20130806134627.GA27194@redhat.com> Message-ID: <52010061.5020100@redhat.com> On 08/06/2013 03:46 PM, Alexander Bokovoy wrote: > On Tue, 06 Aug 2013, Tomas Babej wrote: >> Hi, >> >> these patches add wrapping to ipa-advise's output so that generated advices >> are more readable. > ACK, thanks! Fixed typo that Ana found and pushed both patches to master. Martin From mkosek at redhat.com Tue Aug 6 14:32:06 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Aug 2013 16:32:06 +0200 Subject: [Freeipa-devel] [PATCH] slapi-nis support for trusted domains In-Reply-To: <20130805124506.GT15859@redhat.com> References: <20130715173003.GF18587@redhat.com> <20130723064634.GA20085@redhat.com> <20130723071547.GF15859@redhat.com> <20130723145943.GA26555@redhat.com> <20130731125321.GN15859@redhat.com> <20130801200047.GB3268@redhat.com> <20130802055228.GP15859@redhat.com> <20130802134433.GQ15859@redhat.com> <20130804200457.GA19227@redhat.com> <20130805124506.GT15859@redhat.com> Message-ID: <520108E6.8000604@redhat.com> On 08/05/2013 02:45 PM, Alexander Bokovoy wrote: > On Sun, 04 Aug 2013, Nalin Dahyabhai wrote: >>> >>* The help text still refers to SSSD specifically, when the code doesn't >>> >>enforce or guarantee that SSSD's involved when performing nsswitch >>> >>lookups or PAM authentication. >>> > >>> >The whole setup really makes sense only when SSSD is in use. Aside from >>> >that, the whole setup is triggered only if we find libsss_nss_idmap >>> >library which is provided by SSSD. Yes, it is used for an optional >>> >adding of the SID but linking is explicit. >> >> Yeah, but why is all of that required? If we want to be able to gateway >> whatever's going on at the server, the ipaNTSecurityIdentifier lookup is >> already optional at runtime. Making that part optional at compile-time >> would make the rest of the code (at least the nsswitch parts) easier to >> self-test. > OK, fair enough. I did use of libsss_nss_idmap optional. For tests I > think we need to involve nsswrapper here to make sure of a predictable > testing. > > I've added: > > --with-nsswitch use nsswitch API to look up users and groupsnot > found in the LDAP > --with-sss-nss-idmap use libsss_nss_idmap to discover SIDs. Requires > --with-nsswitch as well > --with-pam use PAM API to authenticate users not found in the > LDAP. Requires --with-nsswitch as well > > And also split PAM use -- if --with-nsswitch is provided, you may > optionally disable use of PAM. > > I also moved src/back-sch-sssd.c to src/back-sch-nss.c to reflect that > and renamed SSSD references to NSSWITCH. > >>> >>HEAD~7: >>> >>* Fix formatting of wrapped lines when calling backend_shr_get_vattr_str(). >>> >>* Check for errors when converting the configured sssd_min_id to a number >>> >>by switching from atol() to strtol() or strtoul(). >>> >done. >> >> Looks good, except that the comment in the checking block implies that >> it's imposing a lower limit on ret.sssd_min_id, when it's reassigning >> the default in case of a parsing error. If the value parses as valid, >> it appears that a value lower than 1000 would be accepted. > That's OK because it is a configuration option. If you want to have it set > to something like 500, so be it -- not all distributions enforce 1000 > as their defaults. > >>> >>HEAD~6: >>> >>* Drop extra whitespace after the type of the "name" member when >>> >>defining struct backend_search_filter_config. >>> >>* backend_search_filter_has_cn_uid() allocates config->name using >>> >>slapi_ch_malloc(), but it is later freed by free(). >>> >>* backend_retrieve_user_entry_from_sssd(): fix line wrapping in >>> >>function signature. >>> >>* backend_retrieve_user_entry_from_sssd() needs to handle ERANGE errors. >>> >>* backend_retrieve_user_entry_from_sssd(): avoid using >>> >>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit >>> >>with the high bit set as a negative value >>> >>* backend_retrieve_user_entry_from_sssd(): check for zero-length >>> >>pw_shell value, and avoid adding it as a loginShell value, since >>> >>that'd be invalid >>> >all done. >> >> That last one's just a NULL check now. Please add a check for a >> zero-length value, which would also be skipped. Otherwise, looks good. > Done. > >>> >>* backend_retrieve_user_entry_from_sssd(): extra whitespace when >>> >>constructing the new entry's DN. >> >> Both of these still have an extra space after the assignment operator. > Done > > >>> >>* backend_retrieve_group_list_from_sssd() needs to handle ERANGE errors. >>> >>* backend_retrieve_group_entry_from_sssd(): avoid using >>> >>slapi_entry_attr_set_int(), which will treat an unsigned 32-bit >>> >>with the high bit set as a negative value >>> >>* backend_retrieve_group_list_from_sssd(): check for NULL result from >>> >>realloc(). >> >> Leaks are possible if realloc() fails for grouplist or entries. > I've used a temporary variable to realloc() into and then only change > 'entries' if its value is not NULL. This should handle the case. > >>> >>HEAD~5: >>> >>* free_pam_response() uses slapi_ch_free() to free memory that was >>> >>probably allocated with malloc(). >>> >>* pam_conv_func(): remove extra whitespace in call to slapi_pblock_get() >>> >>* pam_conv_func(): use malloc() instead of slapi_ch_calloc() to allocate >>> >>replies, because plugins tend to be use free() to free them. >>> >>* pam_conv_func(): replace if/else-if/else-if/else-if stacks with a >>> >>switch() statement. >>> >>* do_pam_auth(): fix line wrapping in function signature. >>> >>* do_pam_auth(): comments suggest that it's just entered or left a >>> >>critical section, when the function's been called in one. >>> >>* do_pam_auth(): replace if/else-if/else-if/else-if stacks with a >>> >>switch() statement. >>> >>* do_pam_auth(): fix line wrapping when calling PR_smprintf(). >> >> Missed one, right after the done: label. > Done. > >>> >>* backend_search_cb() now appears to be freeing the closest-match >>> >>as part of a conditional clause, right before it would unconditionally >>> >>do so. >>> >removed the duplicate. My original intent in moving that code was to >>> >avoid freeing closest-match right before we are printing it with >>> >slapi_log_error() and then sending the result with send_ldap_result(): >>> >https://git.fedorahosted.org/cgit/slapi-nis.git/tree/src/back-sch.c#n1219 >>> > >>> >I can revert this part back if you wish but I think there is an error in >>> >the original code. >> >> The current intent there is to avoid sending a closest-match DN when >> we're returning entries as part of the result, to only send such a value >> as part of the result if we're sending back an LDAP_NO_SUCH_OBJECT >> error. > My main issue with this is that for the case when we found the entry we > still show the debug message with 'closest match = (null)'. I think it > is misleading at least. > > I moved freeing the closest_match after we print the debug message. > >> >>> >>HEAD~2: >>> >>* backend_bind_cb() should avoid having to cast away a "const" by using >>> >>non-const variables for the saved copies of the group and set names. >>> >all done >> >> I meant to suggest that attempting to use an array to store both a const >> and a non-const string still forces a cast somewhere. Use two >> variables. > Done. > >> >>> ... and I did fix couple more comments received from Sumit: >>> >>> 1. switched to use usigned long for sssd_min_id >>> 2. added initializer for 'dn' in >>> backend_retrieve_user_entry_from_sssd()/backend_retrieve_group_entry_from_sssd >>> 3. switched to atoll() with cast of the result to (uid_t)/(gid_t) because >>> we already know at staging phase that the id in as a string will convert >>> without errors to an integer and it is > min id. >> >> Okay. Though, formatting the uid/gid as a string to pass it into a >> local function that converts it right back to an integer seems >> excessive. Anyhow, I guess we're down to minor stuff now. > Following this suggestion, I made two entry points to a larger helper, > one is a general one and another accepting the gid directly. The second one is > used by the grouplist search. > > I don't think there is a need to abstract it more -- when we stage the request > it is easier to store name (or uid) in a string form anyway. Otherwise > I'd need to go with a union to store either string, an uid, or a gid... > > New code is in my repository at fedorapeople.org. Additionally, a patch > to FreeIPA to change configuration variables names is attached. ACK. Pushed to master. Martin From akrivoka at redhat.com Tue Aug 6 14:33:58 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 06 Aug 2013 16:33:58 +0200 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <20130805221526.GP4537@hendrix.brq.redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> <20130805125723.GU15859@redhat.com> <51FFBCE7.8090209@redhat.com> <20130805185526.GW15859@redhat.com> <20130805221526.GP4537@hendrix.brq.redhat.com> Message-ID: <52010956.20807@redhat.com> On 08/06/2013 12:15 AM, Jakub Hrozek wrote: > On Mon, Aug 05, 2013 at 09:55:26PM +0300, Alexander Bokovoy wrote: >> On Mon, 05 Aug 2013, Ana Krivokapic wrote: >>>>> + except errors.NotFound: >>>>> + return dict(result=False) >>>>> + >>>>> + attr = groups_entry.get('schema-compat-lookup-sssd') >>>> same here. >>>> >>>> It needs my patch 0112 too -- it changes ipa-adtrust-install to write >>>> proper configuration options to slapi-nis configs. >>> Done. >>> >>> Also, references to both relevant tickets >>> https://fedorahosted.org/freeipa/ticket/3671 and >>> https://fedorahosted.org/freeipa/ticket/3672 added to commit messages. >>> >>> Updated patches attached. >> Thanks. Few more comments now that I've ran the ipa-advise with the >> plugins: >> >> 1. We need to put downloading the certificate to both plugins. > Right, this is something that was documented on the wiki during the test > day and I agree with Alexander it makes sense to be present in the > advise tool as well. Fixed. cacertdir_rehash script is also downloaded if necessary. > >> 2. The certificate needs to be specified in sssd.conf as well as ldap.conf > Wouldn't it be better to just say that you need to make sure that the > certicicates are present on openldap's configured directories? That > would cover not only the SSSD but also all the tool like ldapsearch the > admin might want to run for troubleshooting. Maybe a hint to run > cacertdir_rehash would be nice. Fixed. We agreed it is best to specify the defaults explicitly in config files, while including a comment about a possible need for manual modification of the script. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Patch 52 is updated, patch 53 needed a rebase. The whole updated patch set is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0052-04-Add-ipa-advise-plugins-for-legacy-clients.patch Type: text/x-patch Size: 13121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0054-03-Add-new-command-compat-is-enabled.patch Type: text/x-patch Size: 3262 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0053-02-Enable-running-API-commands-in-ipa-advise-plugins.patch Type: text/x-patch Size: 2038 bytes Desc: not available URL: From tbabej at redhat.com Tue Aug 6 15:05:36 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 Aug 2013 17:05:36 +0200 Subject: [Freeipa-devel] [PATCH 0090] Allow deletion of an empty trusted range with the --force flag Message-ID: <520110C0.60000@redhat.com> Hi, Adds a --force flag to idrange-del command that allows the deletion of the empty trusted range. This can be used in case the range has been mistakenly created with wrong parameters, and needs to be recreated. Note at Minor Enhacements page added: http://www.freeipa.org/page/V3_Minor_Enhancements https://fedorahosted.org/freeipa/ticket/3787 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0090-Allow-deletion-of-an-empty-trusted-range-with-the-fo.patch Type: text/x-patch Size: 4176 bytes Desc: not available URL: From akrivoka at redhat.com Tue Aug 6 15:40:52 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 06 Aug 2013 17:40:52 +0200 Subject: [Freeipa-devel] [PATCH 0090] Allow deletion of an empty trusted range with the --force flag In-Reply-To: <520110C0.60000@redhat.com> References: <520110C0.60000@redhat.com> Message-ID: <52011904.9050705@redhat.com> 1) I can now delete the default range that gets created together with the trust. Should this be allowed? 2) There is a failing test now, because you changed the DependentEntry error to ValidationError. Btw, isn't a DependentEntry more appropriate here? ====================================================================== FAIL: test_range[23]: idrange_del: Try to delete active AD trusted range u'testrange10' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/akrivoka/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/home/akrivoka/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/home/akrivoka/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 304, in check_exception UNEXPECTED % (cmd, name, args, options, e.__class__.__name__, e) AssertionError: Expected 'idrange_del' to raise DependentEntry, but caught different. args = [u'testrange10'] options = {'version': u'2.64'} ValidationError: invalid 'ID range': ID range 'testrange10' cannot be deleted because it belongs to the active trust 'testtrust'. Remove it prior to removing this range or use --force option. 3) > + doc=_('Forces deletion of an empty range even if it belongs to ' > + 'a active trust.'), "a active trust" -> "an active trust" -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From tbabej at redhat.com Tue Aug 6 16:01:02 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 06 Aug 2013 18:01:02 +0200 Subject: [Freeipa-devel] [PATCH 0090] Allow deletion of an empty trusted range with the --force flag In-Reply-To: <52011904.9050705@redhat.com> References: <520110C0.60000@redhat.com> <52011904.9050705@redhat.com> Message-ID: <52011DBE.4000002@redhat.com> On 08/06/2013 05:40 PM, Ana Krivokapic wrote: > 1) I can now delete the default range that gets created together with the trust. > Should this be allowed? > > 2) There is a failing test now, because you changed the DependentEntry error to > ValidationError. Btw, isn't a DependentEntry more appropriate here? > > ====================================================================== > FAIL: test_range[23]: idrange_del: Try to delete active AD trusted range > u'testrange10' > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/home/akrivoka/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 271, > in > func = lambda: self.check(nice, **test) > File "/home/akrivoka/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 285, > in check > self.check_exception(nice, cmd, args, options, expected) > File "/home/akrivoka/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 304, > in check_exception > UNEXPECTED % (cmd, name, args, options, e.__class__.__name__, e) > AssertionError: Expected 'idrange_del' to raise DependentEntry, but caught > different. > args = [u'testrange10'] > options = {'version': u'2.64'} > ValidationError: invalid 'ID range': ID range 'testrange10' cannot be deleted > because it belongs to the active trust 'testtrust'. Remove it prior to removing > this range or use --force option. > > > 3) >> + doc=_('Forces deletion of an empty range even if it belongs to ' >> + 'a active trust.'), > "a active trust" -> "an active trust" We had a discussion with Sumit and Alexander after which we came to the conclusion that bug described in the ticket should be expected behaviour. Please discard the patches. I closed the ticket as invalid. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From abokovoy at redhat.com Wed Aug 7 06:48:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 7 Aug 2013 09:48:16 +0300 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <52010956.20807@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> <20130805125723.GU15859@redhat.com> <51FFBCE7.8090209@redhat.com> <20130805185526.GW15859@redhat.com> <20130805221526.GP4537@hendrix.brq.redhat.com> <52010956.20807@redhat.com> Message-ID: <20130807064816.GC27194@redhat.com> On Tue, 06 Aug 2013, Ana Krivokapic wrote: >On 08/06/2013 12:15 AM, Jakub Hrozek wrote: >> On Mon, Aug 05, 2013 at 09:55:26PM +0300, Alexander Bokovoy wrote: >>> On Mon, 05 Aug 2013, Ana Krivokapic wrote: >>>>>> + except errors.NotFound: >>>>>> + return dict(result=False) >>>>>> + >>>>>> + attr = groups_entry.get('schema-compat-lookup-sssd') >>>>> same here. >>>>> >>>>> It needs my patch 0112 too -- it changes ipa-adtrust-install to write >>>>> proper configuration options to slapi-nis configs. >>>> Done. >>>> >>>> Also, references to both relevant tickets >>>> https://fedorahosted.org/freeipa/ticket/3671 and >>>> https://fedorahosted.org/freeipa/ticket/3672 added to commit messages. >>>> >>>> Updated patches attached. >>> Thanks. Few more comments now that I've ran the ipa-advise with the >>> plugins: >>> >>> 1. We need to put downloading the certificate to both plugins. >> Right, this is something that was documented on the wiki during the test >> day and I agree with Alexander it makes sense to be present in the >> advise tool as well. > >Fixed. cacertdir_rehash script is also downloaded if necessary. > >> >>> 2. The certificate needs to be specified in sssd.conf as well as ldap.conf >> Wouldn't it be better to just say that you need to make sure that the >> certicicates are present on openldap's configured directories? That >> would cover not only the SSSD but also all the tool like ldapsearch the >> admin might want to run for troubleshooting. Maybe a hint to run >> cacertdir_rehash would be nice. > >Fixed. We agreed it is best to specify the defaults explicitly in config files, >while including a comment about a possible need for manual modification of the >script. > >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > >Patch 52 is updated, patch 53 needed a rebase. The whole updated patch set is >attached. Thanks, looks more complete now. ACK -- / Alexander Bokovoy From mkosek at redhat.com Wed Aug 7 07:22:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Aug 2013 09:22:50 +0200 Subject: [Freeipa-devel] [PATCH] 0052 Add ipa-advise plugins for legacy clients In-Reply-To: <20130807064816.GC27194@redhat.com> References: <51FA6850.1050500@redhat.com> <20130801141307.GO15859@redhat.com> <51FBD53D.3090905@redhat.com> <20130805125723.GU15859@redhat.com> <51FFBCE7.8090209@redhat.com> <20130805185526.GW15859@redhat.com> <20130805221526.GP4537@hendrix.brq.redhat.com> <52010956.20807@redhat.com> <20130807064816.GC27194@redhat.com> Message-ID: <5201F5CA.9020507@redhat.com> On 08/07/2013 08:48 AM, Alexander Bokovoy wrote: > On Tue, 06 Aug 2013, Ana Krivokapic wrote: >> On 08/06/2013 12:15 AM, Jakub Hrozek wrote: >>> On Mon, Aug 05, 2013 at 09:55:26PM +0300, Alexander Bokovoy wrote: >>>> On Mon, 05 Aug 2013, Ana Krivokapic wrote: >>>>>>> + except errors.NotFound: >>>>>>> + return dict(result=False) >>>>>>> + >>>>>>> + attr = groups_entry.get('schema-compat-lookup-sssd') >>>>>> same here. >>>>>> >>>>>> It needs my patch 0112 too -- it changes ipa-adtrust-install to write >>>>>> proper configuration options to slapi-nis configs. >>>>> Done. >>>>> >>>>> Also, references to both relevant tickets >>>>> https://fedorahosted.org/freeipa/ticket/3671 and >>>>> https://fedorahosted.org/freeipa/ticket/3672 added to commit messages. >>>>> >>>>> Updated patches attached. >>>> Thanks. Few more comments now that I've ran the ipa-advise with the >>>> plugins: >>>> >>>> 1. We need to put downloading the certificate to both plugins. >>> Right, this is something that was documented on the wiki during the test >>> day and I agree with Alexander it makes sense to be present in the >>> advise tool as well. >> >> Fixed. cacertdir_rehash script is also downloaded if necessary. >> >>> >>>> 2. The certificate needs to be specified in sssd.conf as well as ldap.conf >>> Wouldn't it be better to just say that you need to make sure that the >>> certicicates are present on openldap's configured directories? That >>> would cover not only the SSSD but also all the tool like ldapsearch the >>> admin might want to run for troubleshooting. Maybe a hint to run >>> cacertdir_rehash would be nice. >> >> Fixed. We agreed it is best to specify the defaults explicitly in config files, >> while including a comment about a possible need for manual modification of the >> script. >> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Patch 52 is updated, patch 53 needed a rebase. The whole updated patch set is >> attached. > Thanks, looks more complete now. > > ACK > Looks good! Pushed to master. Martin From mkosek at redhat.com Wed Aug 7 11:37:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Aug 2013 13:37:04 +0200 Subject: [Freeipa-devel] [PATCH] 417 Increase default SASL buffer size Message-ID: <52023160.8090601@redhat.com> Default SASL buffer size was too small and could lead for example to migration errors. https://fedorahosted.org/freeipa/ticket/3826 --- Done based on Rich's recommendation. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-417-increase-default-sasl-buffer-size.patch Type: text/x-patch Size: 1023 bytes Desc: not available URL: From tbabej at redhat.com Wed Aug 7 12:08:21 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 07 Aug 2013 14:08:21 +0200 Subject: [Freeipa-devel] [PATCH] 417 Increase default SASL buffer size In-Reply-To: <52023160.8090601@redhat.com> References: <52023160.8090601@redhat.com> Message-ID: <520238B5.2010003@redhat.com> On 08/07/2013 01:37 PM, Martin Kosek wrote: > Default SASL buffer size was too small and could lead for example to > migration errors. > > https://fedorahosted.org/freeipa/ticket/3826 The ldif file needs to be changed - use only instead of default. There is already default value provided by 389 DS set to 64 kB. With that change applied, ACK. Tomas > > --- > > Done based on Rich's recommendation. > > Martin > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Aug 7 12:17:47 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Aug 2013 14:17:47 +0200 Subject: [Freeipa-devel] [PATCH] 417 Increase default SASL buffer size In-Reply-To: <520238B5.2010003@redhat.com> References: <52023160.8090601@redhat.com> <520238B5.2010003@redhat.com> Message-ID: <52023AEB.4000306@redhat.com> On 08/07/2013 02:08 PM, Tomas Babej wrote: > On 08/07/2013 01:37 PM, Martin Kosek wrote: >> Default SASL buffer size was too small and could lead for example to >> migration errors. >> >> https://fedorahosted.org/freeipa/ticket/3826 > > The ldif file needs to be changed - use only instead of default. > There is already default value provided by 389 DS set to 64 kB. > > With that change applied, ACK. Good catch! Fixed and pushed to master. Martin From tbabej at redhat.com Wed Aug 7 14:52:29 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 07 Aug 2013 16:52:29 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <51FFCBE4.8050807@redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> <51FFCBE4.8050807@redhat.com> Message-ID: <52025F2D.6060206@redhat.com> On 08/05/2013 05:59 PM, Martin Kosek wrote: > On 07/17/2013 01:47 PM, Tomas Babej wrote: >>> I will release version 3.5 before end of this week. I have some small fixes >>> ready so it is worth to release it now. >>> >>> To summarize the discussion - please remove following options from >>> configuration file and LDAP schema: >>> cache_ttl >>> psearch (attribute idnsPersistentSearch in idnsConfigObject) >>> zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) >>> >>> -- >>> Petr^2 Spacek >> I have a patch ready, but it can't be tested until 3.5 is out. >> >> Tomas >> > I did not test the patch yet, I just want to comment on one thing I just noticed. > > I is it a good idea to remove idnsZoneRefresh and idnsPersistentSearch > attribute types and modify idnsConfigObject objectclass? > > This will affect not only new instances, but also the old ones (i.e. RHEL-6.4) > which may still use these attributes. DNS config object would suddenly become > unusable because DS would refuse to operate the entry as it does not follow the > schema. The same applies for ACIs. > > I would personally not do these changes yet, I think just hiding and marking as > DeprecatedParam is enough for now. Alexander, what do you think? > > Martin We discussed this with Martin. I agreed it would be less cumbersome to keep the attributes in schema for now. I retested the patches, updated versions attached. Petr, can bind-dyndb-ldap handle idnsConfigObject containing idnsPersistentSearch and idnsZoneRefresh attributes? -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0073-6-Remove-support-for-IPA-deployments-with-no-persisten.patch Type: text/x-patch Size: 33442 bytes Desc: not available URL: From npmccallum at redhat.com Wed Aug 7 19:57:10 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 07 Aug 2013 15:57:10 -0400 Subject: [Freeipa-devel] [PATCH] Bypass ipa-replica-conncheck ssh tests when ssh is not installed Message-ID: <1375905430.13222.11.camel@localhost> In the interest of getting ticket 3777 moving, I have created the attached patch. It is *NOT* tested as I don't have a replica setup at the moment and won't have time until after Flock. If someone else has a replica setup and has a few minutes to burn, you are welcome to test the patch. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0014-Bypass-ipa-replica-conncheck-ssh-tests.patch Type: text/x-patch Size: 3963 bytes Desc: not available URL: From mkosek at redhat.com Thu Aug 8 07:19:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 09:19:21 +0200 Subject: [Freeipa-devel] Planning FreeIPA Upstream Doc changes Message-ID: <52034679.2030306@redhat.com> Hello all, This is a follow up for upstream doc maintenance questions I had on freeipa-users in June: http://www.redhat.com/archives/freeipa-users/2013-June/msg00202.html As Content Writer taking care of the User Guide (on docs.fedoraproject.org) no longer has resources to maintain it and the guide become partially outdated. FreeIPA development team and community will need to take over as it was agreed this is of a great benefit to the project. I would like to propose a plan to revive the guide: 1) Move FreeIPA Guide out of current Deon's git tree (hosted on https://fedorahosted.org/freeipa-guide/) to git owned by FreeIPA. There are 2 options: A) Host and package it in current FreeIPA git along with a code. Handling the doc patches would be much simpler, however it would mean, that the docs for next version would need to be prepared at the time when code is ready for release which could either postpone the release and release with incomplete doc (this introduces question how should the git be tagged/branched). B) Add a new git tree to FreeIPA fedorahosted account (freeipa/docs.git) and release the docs asynchronously to the code (there could be of course a preliminary version on FreeIPA.org site). I was already thinking about options to seamlessly integrate an RPM with docs to FreeIPA Web UI which could then provide relevant help links from the UI dialogs to the right spots of documentation. - so far, it seems that option B) will get us more flexibility and would avoid people contributing to the code only downloading also the doc. WHEN: this step would be right after the plan is acknowledged 2) Update the guide to match FreeIPA 3.3 - currently, the guide is approximately on FreeIPA 3.1 level - I filed Trac tickets for gaps I identified in the guide: https://fedorahosted.org/freeipa/milestone/Revive%20FreeIPA%20guide - I would keep the guide in Docbook format unless there are strong reasons to use other format and avoid loosing information. It is very easy to generate all sorts of formats (html, pdf, epub) out of Docbook with publican utility which is packaged in Fedora -> easy build in koji - ideally, editorial would be done by a potential contractor we identified WHEN: most should be done in August, some can be done in September 3) Host the result on FreeIPA.org - we used to release to Fedora documentation portal, but I am thinking it would be more natural to host a project site on project portal instead of Fedora Documentation which rather holds general Fedora infrastructure books. It may be also more intuitive for users to find it on FreeIPA.org than on Fedora docs. - we can take advantage of publican and build a doc site like "docs.freeipa.org" which would held publican-managed doc site with our guides. I tried to play with publican and this is a first PoC result: http://mkosek.fedorapeople.org/publican_site/ - I would prefer if our generated user guides (including current Extending guide hosted on abbra.fedorapeople.org site) use Docbook + be integrated in the site + wiki to have them all under the same roof with consistent look WHEN: Before FreeIPA 3.4 is released 4) Start maintaining and releasing User guide with FreeIPA releases - revive "Affects doc" Trac ticket flag and make sure that Doc is updated along with RFEs and bugfixes - the process of tracking and doing the doc updates and changes is essential in order to keep the doc updated and useful for our users - ideally, editorial would be done by a contractor WHEN: Before 3.4 is release Any ideas or comments very welcome. Thanks, Martin -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pspacek at redhat.com Thu Aug 8 11:29:19 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Aug 2013 13:29:19 +0200 Subject: [Freeipa-devel] Planning FreeIPA Upstream Doc changes: URL/docs.freeipa.org In-Reply-To: <52034679.2030306@redhat.com> References: <52034679.2030306@redhat.com> Message-ID: <5203810F.3060401@redhat.com> On 8.8.2013 09:19, Martin Kosek wrote: > - we can take advantage of publican and build a doc site like > "docs.freeipa.org" which would held publican-managed doc site with our guides. I think that "docs" subdomain is very general and should point to some place with links to guide *and* how tos *and* presentations etc. Is it possible to do do something like that with Publican? Alternatively, should the docs.freeipa.org site point to Documentation portal on wiki with some *huge* link to the guide? What about guide.freeipa.org for the guide itself? -- Petr^2 Spacek From mkosek at redhat.com Thu Aug 8 11:34:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 13:34:16 +0200 Subject: [Freeipa-devel] Planning FreeIPA Upstream Doc changes: URL/docs.freeipa.org In-Reply-To: <5203810F.3060401@redhat.com> References: <52034679.2030306@redhat.com> <5203810F.3060401@redhat.com> Message-ID: <52038238.9070405@redhat.com> On 08/08/2013 01:29 PM, Petr Spacek wrote: > On 8.8.2013 09:19, Martin Kosek wrote: >> - we can take advantage of publican and build a doc site like >> "docs.freeipa.org" which would held publican-managed doc site with our guides. > > I think that "docs" subdomain is very general and should point to some place > with links to guide *and* how tos *and* presentations etc. Is it possible to do > do something like that with Publican? Should be. Look at docs.fedoraproject.org - also managed by Publican. I did a first try here: http://mkosek.fedorapeople.org/publican_site/ (just a PoC). Alternatively, should the > docs.freeipa.org site point to Documentation portal on wiki with some *huge* > link to the guide? > > What about guide.freeipa.org for the guide itself? > IMO docs.freeipa.org is enough - it would contain all our guides (User Guide, Extending FreeIPA guide, maybe also Web UI plugin developer guide...). Martin From tbabej at redhat.com Thu Aug 8 12:32:17 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 08 Aug 2013 14:32:17 +0200 Subject: [Freeipa-devel] [PATCH] Bypass ipa-replica-conncheck ssh tests when ssh is not installed In-Reply-To: <1375905430.13222.11.camel@localhost> References: <1375905430.13222.11.camel@localhost> Message-ID: <52038FD1.60806@redhat.com> On 08/07/2013 09:57 PM, Nathaniel McCallum wrote: > In the interest of getting ticket 3777 moving, I have created the > attached patch. It is *NOT* tested as I don't have a replica setup at > the moment and won't have time until after Flock. If someone else has a > replica setup and has a few minutes to burn, you are welcome to test the > patch. > > Nathaniel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The replica installation fails with: Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master Check SSH connection to remote master Traceback (most recent call last): File "/usr/sbin/ipa-replica-conncheck", line 418, in sys.exit(main()) File "/usr/sbin/ipa-replica-conncheck", line 392, in main stdout, stderr, returncode = ssh('echo OK', verbose=True) File "/usr/sbin/ipa-replica-conncheck", line 70, in __call__ return ipautil.run(cmd, env=env, raiseonerr=False) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 303, in run close_fds=True, env=env, cwd=cwd) File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__ errread, errwrite) File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child raise child_exception TypeError: execve() arg 3 must be a mapping object Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. The culprit here is the comma after the definition of env: + env = {'KRB5_CONFIG': KRB5_CONFIG, 'KRB5CCNAME': CCACHE_FILE}, + return ipautil.run(cmd, env=env, raiseonerr=False) With that fixed the patch works as expected. I have addtitional minor comments: +class SshExec(object): + def __init__(self, user, addr): + self.user = user + self.addr = addr + self.cmd = + [...] The refactored way of calling commands using SSH is nice, so why keep it hidden in ipa-replica-connecheck? I'd rather see this as part of ipapython.ipautil. Also, + def __call__(self, command, verbose=False): + # Bail if ssh is not installed + if self.cmd is None: + print "WARNING: ssh not installed, skipping ssh test" The following message needs to be changed for allowing more generic use-case. + print "WARNING: ssh not installed, skipping" Should be sufficient. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Aug 8 12:40:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 14:40:45 +0200 Subject: [Freeipa-devel] [PATCH] 418 Add requires for slapi-nis and SSSD Message-ID: <520391CD.3050703@redhat.com> Require slapi-nis 0.47.7 and sssd 1.11.0-0.1.beta2 required for core features of 3.3.0 release. -- When this patch is acked, I will start 3.3 final release process and release it to Fedora 19 as we now have all the required bits there. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-418-add-requires-for-slapi-nis-and-sssd.patch Type: text/x-patch Size: 1497 bytes Desc: not available URL: From abokovoy at redhat.com Thu Aug 8 12:59:58 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Aug 2013 15:59:58 +0300 Subject: [Freeipa-devel] [PATCH] 418 Add requires for slapi-nis and SSSD In-Reply-To: <520391CD.3050703@redhat.com> References: <520391CD.3050703@redhat.com> Message-ID: <20130808125958.GD27194@redhat.com> On Thu, 08 Aug 2013, Martin Kosek wrote: >Require slapi-nis 0.47.7 and sssd 1.11.0-0.1.beta2 required for core >features of 3.3.0 release. > >-- >When this patch is acked, I will start 3.3 final release process and release it >to Fedora 19 as we now have all the required bits there. ACK. -- / Alexander Bokovoy From mkosek at redhat.com Thu Aug 8 13:01:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 15:01:09 +0200 Subject: [Freeipa-devel] [PATCH] 418 Add requires for slapi-nis and SSSD In-Reply-To: <20130808125958.GD27194@redhat.com> References: <520391CD.3050703@redhat.com> <20130808125958.GD27194@redhat.com> Message-ID: <52039695.2050007@redhat.com> On 08/08/2013 02:59 PM, Alexander Bokovoy wrote: > On Thu, 08 Aug 2013, Martin Kosek wrote: >> Require slapi-nis 0.47.7 and sssd 1.11.0-0.1.beta2 required for core >> features of 3.3.0 release. >> >> -- >> When this patch is acked, I will start 3.3 final release process and release it >> to Fedora 19 as we now have all the required bits there. > ACK. Pushed to master. Martin From pspacek at redhat.com Thu Aug 8 13:41:04 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Aug 2013 15:41:04 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <52025F2D.6060206@redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> <51FFCBE4.8050807@redhat.com> <52025F2D.6060206@redhat.com> Message-ID: <52039FF0.7050202@redhat.com> On 7.8.2013 16:52, Tomas Babej wrote: > Petr, can bind-dyndb-ldap handle idnsConfigObject containing idnsPersistentSearch > and idnsZoneRefresh attributes? Yes, it should work. Old attributes will be ignored by bind-dyndb-ldap v4.0 and higher. -- Petr^2 Spacek From mkosek at redhat.com Thu Aug 8 14:03:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 16:03:16 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.3.0 Message-ID: <5203A524.7060808@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.0! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 builds are already on their way to updates-testing repo. == Highlights in 3.3.0 == === New features for 3.3 === * Active Directory integration: ** Support of externally defined POSIX attributes for Active Directory trusted domains ** Automatic discovery of Active Directory identity mapping configuration ** Support of trusted domain users for legacy clients ** Identity mapping for AD users can now be delegated * Performance improvements in processing large number of users and groups * Automated integration testing infrastructure * ipa-advise utility is added to generate client setup advice based on an IPA master configuration * FreeIPA-specific SELinux policies has been merged to the main SELinux policy in Fedora 19 * SSSD 1.11 is required === Active Directory integration === Starting with FreeIPA 3.3, it is possible to define identity ranges for a trusted Active Directory domain that rely on POSIX attributes provided by AD DC instead of generating them out of corresponding security identifiers. This functionality requires Services for Unix (SFU) or Identity Management for UNIX enabled on Active Directory side and is provided mostly to aid with migration to SID-based mapping. In order to support externally defined POSIX attributes, identity ranges have been extended to support new range types: * AD trust with SID-based mapping: 'ipa-ad-trust' (default) * SFU support: 'ipa-ad-trust-posix' 'ipa-ad-trust-posix' range type is activated when range discovery finds out SFU is in use by Active Directory domain. To override automatic detection, --range-type=ipa-ad-trust can be specified to 'ipa trust-add' command. FreeIPA 3.3 requires SSSD 1.11 on the IPA master in order to support externally defined POSIX attributes in AD. More details: http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD FreeIPA 3.3 provides a new way to enable legacy clients to support trusted domain users. A compatibility tree, provided by slapi-nis, can now be configured to look up trusted domain users and handle authentication for them. This functionality relies on SSSD 1.11 and release 0.47.7 of slapi-nis. One can enable legacy clients support by running ipa-adtrust-install and answering positively to the corresponding question. More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts Finally, SSSD 1.11 is used to query identity information about trusted domains' users from within IPA framework, including SID to name and name to SID resolution. In addition to speed improvements, FreeIPA 3.3 allows to manage mappings for trusted domains' users without requiring elevated privileges of 'trust admins'. === Performance improvements === When acting on large datasets, FreeIPA now reduces number of potential read roundtrips required to update user and group information. When scaled to thousands of users and groups, this shortens the time required by certain operations tenfold. === Automated testing infrastructure === The FreeIPA team has been providing self-testing code for a long time. The FreeIPA 3.3 test suite includes a framework for integration tests that verify functionality such as replication across several machines. Tests can be run manually, or by test automation servers such as Jenkins or Beaker. Development builds now create a freeipa-tests RPM containing the test suite and related tools. However, as the focus is on testing development code, this package will not be released to Fedora yet. More details: http://www.freeipa.org/page/V3/Integration_testing Additionally, it is now possible to run Web UI tests through the test suite. More details: http://www.freeipa.org/page/Web_UI_Integration_Tests === IPA advise tool === FreeIPA 3.3 introduces new framework to generate recipes of configuration based on how IPA master is configured. These recipes can be taken to the target client systems and used there to configure them for a specific task. We expect to expand use of 'ipa-advise' tool to cover at least configuration of legacy systems in subsequent releases. Three advices are provided with FreeIPA 3.3.0 release: * configuring a generic Fedora release with authconfig tool * configuring RHEL-based systems with SSSD 1.5-1.8 * configuring Debian-based systems with SSSD 1.5-1.8 Contributions are always welcome to grow capabilities of 'ipa-advise' tool to other areas. More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts#Major_configuration_options_and_enablement === SELinux policy === SELinux policies specific to FreeIPA have been merged back to the main SELinux policy package in Fedora 19. Starting with FreeIPA 3.2.2 (available in Fedora 19 updates) SELinux policy is no londer provided by freeipa-selinux package and the package is removed in favor of selinux-policy package. === SSSD 1.11 is required === FreeIPA 3.3 depends on SSSD 1.11 for cross-realm trusts with Active Directory. In particular, FreeIPA 3.3 depends on a new operational mode of SSSD called 'ipa_server_mode'. Thus, SSSD 1.11 is required for FreeIPA 3.3. More details: https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode == Upgrading == === FreeIPA servers with CA installed prior to version 3.1 === Manual upgrade procedure is required for FreeIPA servers installed with version prior to 3.1. === Other FreeIPA servers and clients === An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Please note, that the performance improvements requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.2.0 == === Alexander Bokovoy (9): === * Fix cldap parser to work with a single equality filter (NtVer=...) * Make sure domain_name is also set when processing INP_NAME requests * Fix extdom plugin to provide unqualified name in response as sssd expects * Generate syntethic MS-PAC for all services running on IPA master * ipa-adtrust-install: configure compatibility tree to serve trusted domain users * ipa-kdb: cache KDC hostname on startup * ipa-kdb: reinit mspac on HTTP TGT acquisition to aid trust-add case * ipaserver/dcerpc: attempt to resolve SIDs through SSSD first * Rename slapi-nis configuration variable === Ana Krivokapic (26): === * Prompt for nameserver IP address in dnszone-add * Do not display success message on failure in web UI * Ignore files generated by build * Deprecate options --dom-sid and --dom-name in idrange-mod * Prevent error when running IPA commands with su/sudo * Fix displaying of success message * Fix location of service.crt in .gitignore * Improve handling of options in ipa-client-install * Fail when adding a trust with a different range * Do not display traceback to user * Require rid-base and secondary-rid-base in idrange-add after ipa-adtrust-install * Fix bug in adtrustinstance * Use correct DS instance in ipactl status * Avoid systemd service deadlock during shutdown * Make sure replication works after DM password is changed * Use --ignore-dependencies only when necessary * Properly handle non-existent cert files * Add 'ipa_server_mode' option to SSSD configuration * Bump version of sssd in spec file * Use admin at REALM when testing if SSSD is ready * Fix internal error in idrange-add * Honor 'enabled' option for widgets. * Expose ipaRangeType in Web UI * Add ipa-advise plugins for legacy clients * Enable running API commands in ipa-advise plugins * Add new command compat-is-enabled === Diane Trout (1): === * Fix log format not a string literal. === Jakub Hrozek (3): === * Remove unused variable * IPA KDB MS-PAC: return ENOMEM if allocation fails * IPA KDB MS-PAC: remove unused variable === Jan Cholasta (21): === * Use the correct PKCS#12 file for HTTP server. * Remove stray error condition in ipa-server-install. * Handle exceptions gracefully when verifying PKCS#12 files. * Skip empty lines when parsing pk12util output. * Do not allow installing CA replicas in CA-less setup. * Do not track DS certificate in CA-less setup. * Fix CA-less check in ipa-replica-install and ipa-ca-install. * Do not skip SSSD known hosts in ipa-client-install --ssh-trust-dns. * Enable SASL mapping fallback. * Skip cert issuer validation in service and host commands in CA-less install. * Check trust chain length in CA-less install. * Use LDAP search instead of *group_show to check if a group exists. * Use LDAP search instead of *group_show to check for a group objectclass. * Use LDAP modify operation directly to add/remove group members. * Add missing substring indices for attributes managed by the referint plugin. * Add missing equality index for ipaUniqueId. * Run gpg-agent explicitly when encrypting/decrypting files. * Add new hidden command option to suppress processing of membership attributes. * Ask for PKCS#12 password interactively in ipa-server-install. * Ask for PKCS#12 password interactively in ipa-replica-prepare. * Print newline after receiving EOF in installutils.read_password. === Lukas Slebodnik (4): === * Use pkg-config to detect cmocka * Use right function prototype for thread function * Remove unused variable * Remove unused variable === Martin Kosek (17): === * Set KRB5CCNAME so that dirsrv can work with newer krb5-server * Handle DIR type CCACHEs in test_cmdline properly * Avoid exporting KRB5_KTNAME in dirsrv env * Remove redundant u'' character * Drop SELinux subpackage * Drop redundant directory /var/cache/ipa/sessions * Remove entitlement support * Run server upgrade and restart in posttrans * Require new selinux-policy replacing old server-selinux subpackage * Bump minimum SSSD version * Become 3.3.0 Beta 1 * Free NSS objects in --external-ca scenario * Use valid LDAP search base in migration plugin * Increase default SASL buffer size * Become 3.3.0 Beta 2 * Add requires for slapi-nis and SSSD * Become 3.3.0 === Nathaniel McCallum (10): === * Add ipaUserAuthType and ipaUserAuthTypeClass * Add IPA OTP schema and ACLs * ipa-kdb: Add OTP support * Add the krb5/FreeIPA RADIUS companion daemon * Remove unnecessary prefixes from ipa-pwd-extop files * Add OTP support to ipa-pwd-extop * Fix client install exception if /etc/ssh is missing * Permit reads to ipatokenRadiusProxyUser objects * Fix for small syntax error in OTP schema * Use libunistring ulc_casecmp() on unicode strings === Petr Spacek (1): === * ipa-client-install: Add 'debug' and 'show' statements to nsupdate commands === Petr Viktorin (33): === * Remove leading zero from IPA_NUM_VERSION * Relax getkeytab test to allow additional messages on stderr * Remove code to install Dogtag 9 * Flush stream after writing service messages * Make an ipa-tests package * Add ipa-run-tests command * Add Nose plugin for BeakerLib integration * Add a plugin for test ordering * Add a framework for integration test configuration * Add a framework for integration testing * Introduce a class for remote commands * Collect logs from tests * Show logs in failed tests * tests: Allow public keys for authentication to the remote machines * tests: Configure/unconfigure remote hosts * Host class improvements * Use dosctrings in BeakerLib phase descriptions * Make BeakerLib logging less verbose * BeakerLib plugin: Log http links in test docstrings * Integration test config: Make it possible to specify host IP * ipa-client: Use "ipa" as the package name for i18n * Move BeakerLibProcess out of BeakerLibPlugin * test_integration: Add log collection to Host * test_integration: Set up CA on replicas by default * Add more test tasks * Add install_topo to test tasks * Add the ipa-test-task tool * Add tar and xz dependencies to the freeipa-tests package * Correct default value of LDAPClient.get_entries scope argument * test_simple_replication: Wait for replication to finish before checking * Add the new no_member option to CLI tests * Update translations * Fix installutils.get_password without a TTY === Petr Vobornik (24): === * Fix: HBAC Test tab is missing * Move spec modifications from facet factories to pre_ops * Unite and move facet pre_ops to related modules * Web UI: move ./_base/metadata_provider.js to ./metadata.js * Regression fix: missing control buttons in nested search facets * Make ssbrowser.html work in IE 10 * Fix regression: missing facet tab group labels * Regression fix: rule table with ext. member support doesn't offer any items * Fix default value selection in radio widget * Do not redirect to https in /ipa/ui on non-HTML files * Create Firefox configuration extension on CA-less install * Disable checkboxes and radios for readonly attributes * Better automated test support * Fix container element in adder dialogs * Upstream Web UI tests * Web UI search optimization * Break long words in notification area * Remove word 'field' from GECOS param label * Web UI integration tests: Add trust tests * Web UI integration tests: Add ui_driver method descriptions * Web UI integration tests: Verify data after add and mod * Web UI integration tests: Compute range sizes to avoid overlaps * Web UI integration tests: PEP8 fixes * Web UI integration tests: Code quality fixes === Rob Crittenden (4): === * Bump version for development branch to 3.2.99 * Return the correct Content-type on negotiated XML-RPC requests. * Add Camellia ciphers to allowed list. * Hide sensitive attributes in LDAP updater logging and output === Simo Sorce (2): === * CLDAP: Fix domain handling in netlogon requests * CLDAP: Return empty reply on non-fatal errors === Sumit Bose (5): === * Fix format string typo * Fix type of printf argument * Add PAC to master host TGTs * extdom: replace winbind calls with POSIX/SSSD calls * Remove winbind client configure check === Tomas Babej (32): === * Remove redundancy from hbactest help text * Do not translate trust type and direction with --raw in trust_show and trust-find * Support multiple local domain ranges with RID base set * Do not allow removal of ID range of an active trust * Use private ccache in ipa install tools * Remove redundant check for env.interactive * Add prompt_param method to avoid code duplication * Incorporate interactive prompts in idrange-add * Do not check userPassword with 7-bit plugin * Manage ipa-otpd.socket by IPA * Add ipaRangeType attribute to LDAP Schema * Add update plugin to fill in ipaRangeType attribute * Extend idrange commands to support new range origin types * PEP8 fixes in idrange.py * Remove hardcoded values from idrange plugin tests * Return ipaRangeType as a list in idrange commands * Do not redirect ipa/crl to HTTPS * Add --range-type option that forces range type of the trusted domain * Add libsss_nss_idmap-devel to BuildRequires * Change group ownership of CRL publish directory * Provide ipa-advise tool * Use AD LDAP probing to create trusted domain ID range * Move requirement for keyutils to freeipa-python package * Change shebang to absolute path in ipa-client-automount * Skip referrals when converting LDAP result to LDAPEntry * Refactor the interactive prompt logic in idrange_add * Limit pwpolicy maxlife to 20000 days * Use case-insensitive dict for trusted domain info * Improve help entry for ipa host * Remove overlapping use-cases of the same result variable * Add a word wrapping for comment log messages to AdviceLogger * Wrap lines in the list of available advices From akrivoka at redhat.com Thu Aug 8 14:09:07 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 08 Aug 2013 16:09:07 +0200 Subject: [Freeipa-devel] [PATCH] 0055 Fix tests which fail after ipa-adtrust-install Message-ID: <5203A683.4040907@redhat.com> Hello, This patch should fix the failing unit tests. https://fedorahosted.org/freeipa/ticket/3852 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0055-Fix-tests-which-fail-after-ipa-adtrust-install.patch Type: text/x-patch Size: 45880 bytes Desc: not available URL: From pspacek at redhat.com Thu Aug 8 14:14:09 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Aug 2013 16:14:09 +0200 Subject: [Freeipa-devel] [RFC] Interoperable DNS server control protocol - design review In-Reply-To: <20130807102038.3ca0fd6861f7ae5c736d70ff@nic.cz> References: <20130807102038.3ca0fd6861f7ae5c736d70ff@nic.cz> Message-ID: <5203A7B1.905@redhat.com> Hello list, some time ago, there were rumours about a new protocol for controlling DNS servers from various vendors. I think that FreeIPA could benefit from such protocol - in long term perspective. Please, join the 'nsrpc' mailing list dedicated to the new protocol and contribute to protocol design. Note that 'security' is open of big open questions! The proposal/first protocol design: https://gitlab.labs.nic.cz/knot/wikis/nsrpc Mailing list: https://lists.nic.cz/cgi-bin/mailman/listinfo/nsrpc Thank you for your time! Petr^2 Spacek -------- Original Message -------- Subject: Interoperable NS control protocol R2 Date: Wed, 7 Aug 2013 10:20:38 +0200 From: Marek Vavrusa Organization: CZ.NIC CC: nsrpc at lists.nic.cz Hi, about a year ago, a couple of us (DNS vendors) sat at a table and talked about how to make NS control interoperable. This resulted in a paper where we described what do (and more importantly, what do we don't) want. Since then, the idea is still sound, but also a lot of changes happened. Like the demand for the ability of a NS to talk to each other, zone provisioning and a possible (web?) front-end for this protocol. We also had some feedback from other people in the industry, so I came up with several changes to accomodate for recent changes and added a bit of futureproofing. With all this, I'd like to raise the topic again and see if there's still any agreement and will to do this. Here's a draft, but a very very open to discussion and clarification. The main changes are shift to notation like JSON(-RPC), so we don't have to reinvent the wheel, rambling about what is and isn't core and a couple thoughts about confidentiality and security. https://gitlab.labs.nic.cz/knot/wikis/nsrpc We also set up a mailinglist to joint the discussion https://lists.nic.cz/cgi-bin/mailman/listinfo/nsrpc nsrpc at lists.nic.cz I'd really like to make this happen and deliver an actual code, as soon as we reach some sort of agreement on this. Cheers, Marek -- Marek Vavru?a Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americk? 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz From tbabej at redhat.com Thu Aug 8 14:22:28 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 08 Aug 2013 16:22:28 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Handle --subject option in ipa-server-install In-Reply-To: <51FFDB55.3080701@redhat.com> References: <51F778EA.7040305@redhat.com> <51F7E8C7.2000705@redhat.com> <51F8DE33.50801@redhat.com> <51FA5A81.8070904@redhat.com> <51FA5B79.8090406@redhat.com> <51FA5F7D.30503@redhat.com> <51FA762C.8090909@redhat.com> <51FFDB55.3080701@redhat.com> Message-ID: <5203A9A4.70703@redhat.com> On 08/05/2013 07:05 PM, Ana Krivokapic wrote: > On 08/01/2013 04:52 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 08/01/2013 02:58 PM, Martin Kosek wrote: >>>> On 08/01/2013 02:54 PM, Petr Viktorin wrote: >>>>> On 07/31/2013 11:51 AM, Ana Krivokapic wrote: >>>>>> On 07/30/2013 06:24 PM, Petr Viktorin wrote: >>>>>>> On 07/30/2013 10:27 AM, Ana Krivokapic wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> This patch addresses ticket >>>>>>>> https://fedorahosted.org/freeipa/ticket/3783. >>>>>>>> >>>>>>> Thanks for the patch, I have a concern below: >>>>>>> >>>>>>>> freeipa-akrivoka-0051-Handle-subject-option-in-ipa-server-install.patch >>>>>>>> >>>>>>>> diff --git a/install/tools/ipa-upgradeconfig >>>>>>>> b/install/tools/ipa-upgradeconfig >>>>>>>> index >>>>>>>> de17c5b23d79f31e8571a3400d44397630cadada..a2625e6198bcff0811c482e479c8af10716dcea1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 100644 >>>>>>>> --- a/install/tools/ipa-upgradeconfig >>>>>>>> +++ b/install/tools/ipa-upgradeconfig >>>>>>>> @@ -894,6 +895,7 @@ def main(): >>>>>>>> configured_constants = dogtag.configured_constants() >>>>>>>> sub_dict = dict( >>>>>>>> REALM=api.env.realm, >>>>>>>> + SUBJECT_BASE=str(DN(('O', api.env.realm))), >>>>>>> When certmap.conf.template's version changes again, this will >>>>>>> rewrite the >>>>>>> subject to the default. Don't we want to use the subject base also >>>>>>> here? >>>>>>> >>>>>>> >>>>>>> >>>>>> You are right. The updated patch uses the current value of subject >>>>>> base from >>>>>> LDAP to update certmap.conf during upgrades. >>>>> When ipa-upgradeconfig is run while the DS is down, this results in a >>>>> small >>>>> warning, and very bad configuration: >>>>> certmap ipaca CN=Certificate Authority,None >>>>> >>>>> >>>>> I'm not sure how this should be handled. I'm adding Rob to the loop. >>>>> Rob, can we start the DS in ipa-upgradeconfig? That sounds quite >>>>> heavy-handed >>>>> for a RPM upgrade script. >>>>> >>>>> Maybe if the DS is unavailable, we should use the old value from the >>>>> config >>>>> file itself. >>>> Values can be stored/restored using a sysupgrade module. >>> The problem is that (AFAIK) old instances won't have this particular >>> value stored. Upgrading from 3.1 to a future version where certmap.conf >>> is modified again would fail. >>> >>>> I would not be so >>>> afraid of starting the DS module, we already do that exercise in >>>> ipa-ldap-updater, so adding it in ipa-upgradeconfig too does not >>>> change much. >>>> >>>> Question is, what should we do what DS cannot be started or cannot be >>>> read >>>> (e.g. when upgrade is run in fedup's chrooted environment) - we must >>>> make sure >>>> we don't mess the configuration up. >>> Again AFAIK, if the server is down, certmap.conf is the only place where >>> this value is available. I didn't check thoroughly, though. >> I think that's right. >> >> So the big problem here is we have no way of alerting users to possible >> problems found during the upgrade unless they happen to sift through >> ipaupgrade.log, which tends to be huge, and most users don't even know about. >> >> Part of this is due to not displaying anything during an rpm upgrade. I think >> we should print any exceptional errors found during the upgrade. Sure, >> something may eat the output, but it's a best effort sort of thing. >> >> I don't see us finding a perfect solution here. What I'd propose is this: >> >> - Store the value in sysupgrade from now on, even in new installs >> - Look there first on upgrade >> - Start dirsrv if necessary get the value >> - If we can't get the value, skip changing file and log loudly >> - Find out exactly this will present to a user by doing an upgrade from an old >> version to master and create an FAQ entry. >> >> I think that's about the best we can do. >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Updated patch tries to find the subject base value by searching in this order: > 1) sysupgrade > 2) dirsrv > 3) certmap.conf > If it cannot be found, an error is displayed and the file is not modified. > > I tested exhaustively and patch held up against my efforts. No objections to the code itself, so, ACK. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mkosek at redhat.com Thu Aug 8 14:31:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 16:31:57 +0200 Subject: [Freeipa-devel] New ipa-3-3 branch Message-ID: <5203ABDD.7030003@redhat.com> Hi all fellow developers! Please note that as 3.3.0 went final, we will change the default branches we commit to. 3.3.x bugfixes -> master + new ipa-3-3 branch 3.4 features -> master branch only Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From JR.Aquino at citrix.com Thu Aug 8 14:53:35 2013 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 8 Aug 2013 14:53:35 +0000 Subject: [Freeipa-devel] Planning FreeIPA Upstream Doc changes In-Reply-To: <52034679.2030306@redhat.com> References: <52034679.2030306@redhat.com> Message-ID: <651FE276-A420-4C42-9B1D-7A6486BE3D4C@citrix.com> On Aug 8, 2013, at 12:19 AM, "Martin Kosek" wrote: > Hello all, > > This is a follow up for upstream doc maintenance questions I had on > freeipa-users in June: > http://www.redhat.com/archives/freeipa-users/2013-June/msg00202.html > > As Content Writer taking care of the User Guide (on docs.fedoraproject.org) no > longer has resources to maintain it and the guide become partially outdated. > FreeIPA development team and community will need to take over as it was agreed > this is of a great benefit to the project. > > I would like to propose a plan to revive the guide: > > 1) Move FreeIPA Guide out of current Deon's git tree (hosted on > https://fedorahosted.org/freeipa-guide/) to git owned by FreeIPA. There are 2 > options: > A) Host and package it in current FreeIPA git along with a code. Handling the > doc patches would be much simpler, however it would mean, that the docs for > next version would need to be prepared at the time when code is ready for > release which could either postpone the release and release with incomplete doc > (this introduces question how should the git be tagged/branched). > B) Add a new git tree to FreeIPA fedorahosted account (freeipa/docs.git) and > release the docs asynchronously to the code (there could be of course a > preliminary version on FreeIPA.org site). I was already thinking about options > to seamlessly integrate an RPM with docs to FreeIPA Web UI which could then > provide relevant help links from the UI dialogs to the right spots of > documentation. > - so far, it seems that option B) will get us more flexibility and would avoid > people contributing to the code only downloading also the doc. > WHEN: this step would be right after the plan is acknowledged ^ +1 And I agree that a preliminary should be hosted on the FreeIPA.org project portal rather than the fedora documentation site. It feels more natural that way. Ideally, it should be trivial to check out or grab the relevant rpm for a given version as we move forward into new releases, that way an admin can view the doc that refers specifically to their running release rather than be confused about up-to-date features that may not exist on theirs. > 2) Update the guide to match FreeIPA 3.3 > - currently, the guide is approximately on FreeIPA 3.1 level > - I filed Trac tickets for gaps I identified in the guide: > https://fedorahosted.org/freeipa/milestone/Revive%20FreeIPA%20guide > - I would keep the guide in Docbook format unless there are strong reasons to > use other format and avoid loosing information. It is very easy to generate all > sorts of formats (html, pdf, epub) out of Docbook with publican utility which > is packaged in Fedora -> easy build in koji > - ideally, editorial would be done by a potential contractor we identified > WHEN: most should be done in August, some can be done in September > > 3) Host the result on FreeIPA.org > - we used to release to Fedora documentation portal, but I am thinking it would > be more natural to host a project site on project portal instead of Fedora > Documentation which rather holds general Fedora infrastructure books. It may be > also more intuitive for users to find it on FreeIPA.org than on Fedora docs. > - we can take advantage of publican and build a doc site like > "docs.freeipa.org" which would held publican-managed doc site with our guides. > I tried to play with publican and this is a first PoC result: > http://mkosek.fedorapeople.org/publican_site/ > - I would prefer if our generated user guides (including current Extending > guide hosted on abbra.fedorapeople.org site) use Docbook + be integrated in the > site + wiki to have them all under the same roof with consistent look > WHEN: Before FreeIPA 3.4 is released ^+1 I've always found it a little awkward to hunt docs down at the fedora documentation portal. > > 4) Start maintaining and releasing User guide with FreeIPA releases > - revive "Affects doc" Trac ticket flag and make sure that Doc is updated along > with RFEs and bugfixes > - the process of tracking and doing the doc updates and changes is essential in > order to keep the doc updated and useful for our users > - ideally, editorial would be done by a contractor > WHEN: Before 3.4 is release > > Any ideas or comments very welcome. > > Thanks, > Martin > Thanks carrying the torch! > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Thu Aug 8 14:59:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 16:59:20 +0200 Subject: [Freeipa-devel] Planning FreeIPA Upstream Doc changes In-Reply-To: <651FE276-A420-4C42-9B1D-7A6486BE3D4C@citrix.com> References: <52034679.2030306@redhat.com> <651FE276-A420-4C42-9B1D-7A6486BE3D4C@citrix.com> Message-ID: <5203B248.4040200@redhat.com> On 08/08/2013 04:53 PM, JR Aquino wrote: > > On Aug 8, 2013, at 12:19 AM, "Martin Kosek" wrote: ... >> B) Add a new git tree to FreeIPA fedorahosted account (freeipa/docs.git) and >> release the docs asynchronously to the code (there could be of course a >> preliminary version on FreeIPA.org site). I was already thinking about options >> to seamlessly integrate an RPM with docs to FreeIPA Web UI which could then >> provide relevant help links from the UI dialogs to the right spots of >> documentation. >> - so far, it seems that option B) will get us more flexibility and would avoid >> people contributing to the code only downloading also the doc. >> WHEN: this step would be right after the plan is acknowledged > > ^ +1 > > And I agree that a preliminary should be hosted on the FreeIPA.org project portal rather than the fedora documentation site. It feels more natural that way. > > Ideally, it should be trivial to check out or grab the relevant rpm for a given version as we move forward into new releases, that way an admin can view the doc that refers specifically to their running release rather than be confused about up-to-date features that may not exist on theirs. In the beginning, there will be just a _version_ documentation on FreeIPA.org. Admins could then easily read the version that's relevant to them or download it in a format they like. Later we can bells and whistles and start releasing RPM you could install along with your FreeIPA (we are already discussing means if integrating doc with Web UI). ... >> 3) Host the result on FreeIPA.org >> - we used to release to Fedora documentation portal, but I am thinking it would >> be more natural to host a project site on project portal instead of Fedora >> Documentation which rather holds general Fedora infrastructure books. It may be >> also more intuitive for users to find it on FreeIPA.org than on Fedora docs. >> - we can take advantage of publican and build a doc site like >> "docs.freeipa.org" which would held publican-managed doc site with our guides. >> I tried to play with publican and this is a first PoC result: >> http://mkosek.fedorapeople.org/publican_site/ >> - I would prefer if our generated user guides (including current Extending >> guide hosted on abbra.fedorapeople.org site) use Docbook + be integrated in the >> site + wiki to have them all under the same roof with consistent look >> WHEN: Before FreeIPA 3.4 is released > > ^+1 > > I've always found it a little awkward to hunt docs down at the fedora documentation portal. Good! Then it seems as a good decision. Thanks for response, Martin From mkosek at redhat.com Thu Aug 8 15:00:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 17:00:22 +0200 Subject: [Freeipa-devel] [PATCH] 0051 Handle --subject option in ipa-server-install In-Reply-To: <5203A9A4.70703@redhat.com> References: <51F778EA.7040305@redhat.com> <51F7E8C7.2000705@redhat.com> <51F8DE33.50801@redhat.com> <51FA5A81.8070904@redhat.com> <51FA5B79.8090406@redhat.com> <51FA5F7D.30503@redhat.com> <51FA762C.8090909@redhat.com> <51FFDB55.3080701@redhat.com> <5203A9A4.70703@redhat.com> Message-ID: <5203B286.4080603@redhat.com> On 08/08/2013 04:22 PM, Tomas Babej wrote: > On 08/05/2013 07:05 PM, Ana Krivokapic wrote: >> On 08/01/2013 04:52 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 08/01/2013 02:58 PM, Martin Kosek wrote: >>>>> On 08/01/2013 02:54 PM, Petr Viktorin wrote: >>>>>> On 07/31/2013 11:51 AM, Ana Krivokapic wrote: >>>>>>> On 07/30/2013 06:24 PM, Petr Viktorin wrote: >>>>>>>> On 07/30/2013 10:27 AM, Ana Krivokapic wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> This patch addresses ticket >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3783. >>>>>>>>> >>>>>>>> Thanks for the patch, I have a concern below: >>>>>>>> >>>>>>>>> freeipa-akrivoka-0051-Handle-subject-option-in-ipa-server-install.patch >>>>>>>>> >>>>>>>>> diff --git a/install/tools/ipa-upgradeconfig >>>>>>>>> b/install/tools/ipa-upgradeconfig >>>>>>>>> index >>>>>>>>> de17c5b23d79f31e8571a3400d44397630cadada..a2625e6198bcff0811c482e479c8af10716dcea1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 100644 >>>>>>>>> --- a/install/tools/ipa-upgradeconfig >>>>>>>>> +++ b/install/tools/ipa-upgradeconfig >>>>>>>>> @@ -894,6 +895,7 @@ def main(): >>>>>>>>> configured_constants = dogtag.configured_constants() >>>>>>>>> sub_dict = dict( >>>>>>>>> REALM=api.env.realm, >>>>>>>>> + SUBJECT_BASE=str(DN(('O', api.env.realm))), >>>>>>>> When certmap.conf.template's version changes again, this will >>>>>>>> rewrite the >>>>>>>> subject to the default. Don't we want to use the subject base also >>>>>>>> here? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> You are right. The updated patch uses the current value of subject >>>>>>> base from >>>>>>> LDAP to update certmap.conf during upgrades. >>>>>> When ipa-upgradeconfig is run while the DS is down, this results in a >>>>>> small >>>>>> warning, and very bad configuration: >>>>>> certmap ipaca CN=Certificate Authority,None >>>>>> >>>>>> >>>>>> I'm not sure how this should be handled. I'm adding Rob to the loop. >>>>>> Rob, can we start the DS in ipa-upgradeconfig? That sounds quite >>>>>> heavy-handed >>>>>> for a RPM upgrade script. >>>>>> >>>>>> Maybe if the DS is unavailable, we should use the old value from the >>>>>> config >>>>>> file itself. >>>>> Values can be stored/restored using a sysupgrade module. >>>> The problem is that (AFAIK) old instances won't have this particular >>>> value stored. Upgrading from 3.1 to a future version where certmap.conf >>>> is modified again would fail. >>>> >>>>> I would not be so >>>>> afraid of starting the DS module, we already do that exercise in >>>>> ipa-ldap-updater, so adding it in ipa-upgradeconfig too does not >>>>> change much. >>>>> >>>>> Question is, what should we do what DS cannot be started or cannot be >>>>> read >>>>> (e.g. when upgrade is run in fedup's chrooted environment) - we must >>>>> make sure >>>>> we don't mess the configuration up. >>>> Again AFAIK, if the server is down, certmap.conf is the only place where >>>> this value is available. I didn't check thoroughly, though. >>> I think that's right. >>> >>> So the big problem here is we have no way of alerting users to possible >>> problems found during the upgrade unless they happen to sift through >>> ipaupgrade.log, which tends to be huge, and most users don't even know about. >>> >>> Part of this is due to not displaying anything during an rpm upgrade. I think >>> we should print any exceptional errors found during the upgrade. Sure, >>> something may eat the output, but it's a best effort sort of thing. >>> >>> I don't see us finding a perfect solution here. What I'd propose is this: >>> >>> - Store the value in sysupgrade from now on, even in new installs >>> - Look there first on upgrade >>> - Start dirsrv if necessary get the value >>> - If we can't get the value, skip changing file and log loudly >>> - Find out exactly this will present to a user by doing an upgrade from an old >>> version to master and create an FAQ entry. >>> >>> I think that's about the best we can do. >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Updated patch tries to find the subject base value by searching in this order: >> 1) sysupgrade >> 2) dirsrv >> 3) certmap.conf >> If it cannot be found, an error is displayed and the file is not modified. >> >> > > I tested exhaustively and patch held up against my efforts. > > No objections to the code itself, so, ACK. > Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Thu Aug 8 16:20:56 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Aug 2013 18:20:56 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <52025F2D.6060206@redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> <51FFCBE4.8050807@redhat.com> <52025F2D.6060206@redhat.com> Message-ID: <5203C568.4060004@redhat.com> On 08/07/2013 04:52 PM, Tomas Babej wrote: > On 08/05/2013 05:59 PM, Martin Kosek wrote: >> On 07/17/2013 01:47 PM, Tomas Babej wrote: >>>> I will release version 3.5 before end of this week. I have some small fixes >>>> ready so it is worth to release it now. >>>> >>>> To summarize the discussion - please remove following options from >>>> configuration file and LDAP schema: >>>> cache_ttl >>>> psearch (attribute idnsPersistentSearch in idnsConfigObject) >>>> zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) >>>> >>>> -- >>>> Petr^2 Spacek >>> I have a patch ready, but it can't be tested until 3.5 is out. >>> >>> Tomas >>> >> I did not test the patch yet, I just want to comment on one thing I just >> noticed. >> >> I is it a good idea to remove idnsZoneRefresh and idnsPersistentSearch >> attribute types and modify idnsConfigObject objectclass? >> >> This will affect not only new instances, but also the old ones (i.e. RHEL-6.4) >> which may still use these attributes. DNS config object would suddenly become >> unusable because DS would refuse to operate the entry as it does not follow the >> schema. The same applies for ACIs. >> >> I would personally not do these changes yet, I think just hiding and marking as >> DeprecatedParam is enough for now. Alexander, what do you think? >> >> Martin > We discussed this with Martin. I agreed it would be less cumbersome to > keep the attributes in schema for now. > > I retested the patches, updated versions attached. > > Petr, can bind-dyndb-ldap handle idnsConfigObject containing idnsPersistentSearch > and idnsZoneRefresh attributes? > I still see some schema and aci changes: --- a/install/updates/10-bind-schema.update +++ b/install/updates/10-bind-schema.update @@ -44,7 +44,7 @@ add:attributeTypes: SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v2' ) -add:attributeTypes: +remove:attributeTypes: ( 2.16.840.1.113730.3.8.5.16 NAME 'idnsZoneRefresh' DESC 'zone refresh interval' @@ -52,7 +52,7 @@ add:attributeTypes: SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v2' ) -add:attributeTypes: +remove:attributeTypes: ( 2.16.840.1.113730.3.8.5.17 NAME 'idnsPersistentSearch' DESC 'allow persistent searches' @@ -65,8 +65,7 @@ add:objectClasses: NAME 'idnsConfigObject' DESC 'DNS global config options' STRUCTURAL - MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR $$ - idnsZoneRefresh $$ idnsPersistentSearch + MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR ) ) add:objectClasses: ( 2.16.840.1.113730.3.8.12.18 AND - _write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy || idnsforwarders || idnsallowsyncptr || idnszonerefresh || idnspersistentsearch")(target = "ldap:///cn=dns,%(realm)s")(version 3.0;acl "permission:Write DNS Configuration";allow (write) groupdn = "ldap:///cn=Write DNS Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' % dict(realm=api.env.basedn)] + _write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy || idnsforwarders || idnsallowsyncptr")(target = "ldap:///cn=dns,%(realm)s")(version 3.0;acl "permission:Write DNS Configuration";allow (write) groupdn = "ldap:///cn=Write DNS Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' % dict(realm=api.env.basedn)] Besides these, patch worked fine on both upgrade and new installation. So when you remove these chunks, it will be ack. Martin From tbabej at redhat.com Fri Aug 9 07:39:11 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 09 Aug 2013 09:39:11 +0200 Subject: [Freeipa-devel] [PATCH] 0055 Fix tests which fail after ipa-adtrust-install In-Reply-To: <5203A683.4040907@redhat.com> References: <5203A683.4040907@redhat.com> Message-ID: <52049C9F.6080706@redhat.com> On 08/08/2013 04:09 PM, Ana Krivokapic wrote: > Hello, > > This patch should fix the failing unit tests. > > https://fedorahosted.org/freeipa/ticket/3852 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel There are two tests failing on my machine when running the tests after ipa-adtrust-install with your patch applied: ====================================================================== FAIL: test_group[24]: group_find: Search for POSIX groups ---------------------------------------------------------------------- Traceback (most recent call last): [...] AssertionError: assert_deepequal: dict keys mismatch. test_group[24]: group_find: Search for POSIX groups missing keys = [] extra keys = ['ipantsecurityidentifier'] expected = {'dn': ipapython.dn.DN('cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'), 'cn': [u'editors'], 'objectclass': Fuzzy(None, None, at 0x3768c08>), 'gidnumber': [Fuzzy('^\\d+$', , None)], 'ipauniqueid': [Fuzzy('^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$', , None)], 'description': [u'Limited admins who can edit other users']} got = {'dn': u'cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com', 'cn': (u'editors',), 'objectclass': (u'top', u'groupofnames', u'posixgroup', u'ipausergroup', u'ipaobject', u'nestedGroup', u'ipantgroupattrs'), 'ipantsecurityidentifier': (u'S-1-5-21-1457515837-642396627-3509099663-1002',), 'gidnumber': (u'1804600002',), 'ipauniqueid': (u'7c6e1672-0039-11e3-9567-001a4a2221fb',), 'description': (u'Limited admins who can edit other users',)} path = ('result', 1) I think you need the wrap the dictionary discribing the editor's group entry with the add_sid wrapper, and its objectclasses using the add_oc wrapper. [tbabej at vm-139 freeipa]$ git diff diff --git a/ipatests/test_xmlrpc/test_group_plugin.py b/ipatests/test_xmlrpc/test_group_plugin.py index d380fe5..14c70cd 100644 --- a/ipatests/test_xmlrpc/test_group_plugin.py +++ b/ipatests/test_xmlrpc/test_group_plugin.py @@ -447,14 +447,15 @@ class test_group(Declarative): objectclasses.posixgroup, u'ipantgroupattrs')), 'ipauniqueid': [fuzzy_uuid], }), - { + add_sid({ 'dn': get_group_dn('editors'), 'gidnumber': [fuzzy_digits], 'cn': [u'editors'], 'description': [u'Limited admins who can edit other users'], - 'objectclass': fuzzy_set_ci(objectclasses.posixgroup), + 'objectclass': fuzzy_set_ci(add_oc( + objectclasses.posixgroup, u'ipantgroupattrs')), 'ipauniqueid': [fuzzy_uuid], - }, + }), dict( dn=get_group_dn(group1), cn=[group1], These changes were sufficient for me to have the unit test suite run without errors. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Aug 9 08:42:25 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 09 Aug 2013 10:42:25 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <51EE44E9.6010807@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> <51EE44E9.6010807@redhat.com> Message-ID: <5204AB71.3080904@redhat.com> On 23.7.2013 10:55, Petr Spacek wrote: > On 19.7.2013 19:55, Simo Sorce wrote: >> I will reply to the rest of the message later if necessary, still >> digesting some of your answers, but I wanted to address the following >> first. >> >> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: >>> >>> The most important question at the moment is "What can we postpone? >>> How >>> fragile it can be for shipping it as part of Fedora 20?" Could we >>> declare >>> DNSSEC support as "technology preview"/"don't use it for anything >>> serious"? >> >> Until we figur out proper management in LDAP we will be a bit stuck, esp >> if we want to consider usin the 'somthing' that stores keys instead of >> toring them stright in LDAP. >> >> So maybe we can start with allowing just one server to do DNSSEC and >> source keys from files for now ? > > The problem is that DNSSEC deployment *on single domain* is 'all or nothing': > All DNS servers have to support DNSSEC otherwise the validation on client side > can fail randomly. > > Note that *parent* zone indicates that the particular child zone is secured > with DNSSEC by sending DS (delegation signer) record to the client. Validation > will fail if client receives DS record from the parent but no signatures are > present in data from 'child' zone itself. > > This prevents downgrade (DNSSEC => plain DNS) attacks. > > As a result, we have only two options: One DNS server with DNSSEC enabled or > arbitrary number DNS servers without DNSSEC, which is very unfortunate. > >> as soon as we have that workign we should also have clearer plans about >> how we manage keys in LDAP (or elsewhere). Dmitri, Martin and me discussed this proposal in person and the new plan is: - Elect one super-master which will handle key generation (as we do with special CA certificates) - Store generated DNSSEC keys in LDAP - Encrypt stored keys with 'DNSSEC master key' shared by all servers - Derive 'DNSSEC master key' from 'Kerberos master key' during server install/upgrade and store it somewhere on the filesystem (as the Kerberos master key, on each IPA server) - Consider certmonger or oddjob as key generation triggers I think that we should add one new thing - a 'salt' - used for Kerberos master key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC master key as necessary without a change in the Kerberos master key. Does it make sense? Does anybody have any ideas/recommendations which libraries we should use for key derivation and key material en/decryption? Thank you for your time! -- Petr^2 Spacek From tbabej at redhat.com Fri Aug 9 10:02:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 09 Aug 2013 12:02:46 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <5203C568.4060004@redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> <51FFCBE4.8050807@redhat.com> <52025F2D.6060206@redhat.com> <5203C568.4060004@redhat.com> Message-ID: <5204BE46.7060201@redhat.com> On 08/08/2013 06:20 PM, Martin Kosek wrote: > On 08/07/2013 04:52 PM, Tomas Babej wrote: >> On 08/05/2013 05:59 PM, Martin Kosek wrote: >>> On 07/17/2013 01:47 PM, Tomas Babej wrote: >>>>> I will release version 3.5 before end of this week. I have some small fixes >>>>> ready so it is worth to release it now. >>>>> >>>>> To summarize the discussion - please remove following options from >>>>> configuration file and LDAP schema: >>>>> cache_ttl >>>>> psearch (attribute idnsPersistentSearch in idnsConfigObject) >>>>> zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) >>>>> >>>>> -- >>>>> Petr^2 Spacek >>>> I have a patch ready, but it can't be tested until 3.5 is out. >>>> >>>> Tomas >>>> >>> I did not test the patch yet, I just want to comment on one thing I just >>> noticed. >>> >>> I is it a good idea to remove idnsZoneRefresh and idnsPersistentSearch >>> attribute types and modify idnsConfigObject objectclass? >>> >>> This will affect not only new instances, but also the old ones (i.e. RHEL-6.4) >>> which may still use these attributes. DNS config object would suddenly become >>> unusable because DS would refuse to operate the entry as it does not follow the >>> schema. The same applies for ACIs. >>> >>> I would personally not do these changes yet, I think just hiding and marking as >>> DeprecatedParam is enough for now. Alexander, what do you think? >>> >>> Martin >> We discussed this with Martin. I agreed it would be less cumbersome to >> keep the attributes in schema for now. >> >> I retested the patches, updated versions attached. >> >> Petr, can bind-dyndb-ldap handle idnsConfigObject containing idnsPersistentSearch >> and idnsZoneRefresh attributes? >> > I still see some schema and aci changes: > > --- a/install/updates/10-bind-schema.update > +++ b/install/updates/10-bind-schema.update > @@ -44,7 +44,7 @@ add:attributeTypes: > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 > X-ORIGIN 'IPA v2' ) > -add:attributeTypes: > +remove:attributeTypes: > ( 2.16.840.1.113730.3.8.5.16 > NAME 'idnsZoneRefresh' > DESC 'zone refresh interval' > @@ -52,7 +52,7 @@ add:attributeTypes: > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > SINGLE-VALUE > X-ORIGIN 'IPA v2' ) > -add:attributeTypes: > +remove:attributeTypes: > ( 2.16.840.1.113730.3.8.5.17 > NAME 'idnsPersistentSearch' > DESC 'allow persistent searches' > @@ -65,8 +65,7 @@ add:objectClasses: > NAME 'idnsConfigObject' > DESC 'DNS global config options' > STRUCTURAL > - MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR $$ > - idnsZoneRefresh $$ idnsPersistentSearch > + MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR > ) ) > add:objectClasses: > ( 2.16.840.1.113730.3.8.12.18 > > AND > > - _write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy || > idnsforwarders || idnsallowsyncptr || idnszonerefresh || > idnspersistentsearch")(target = "ldap:///cn=dns,%(realm)s")(version 3.0;acl > "permission:Write DNS Configuration";allow (write) groupdn = "ldap:///cn=Write > DNS Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' % > dict(realm=api.env.basedn)] > + _write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy || > idnsforwarders || idnsallowsyncptr")(target = > "ldap:///cn=dns,%(realm)s")(version 3.0;acl "permission:Write DNS > Configuration";allow (write) groupdn = "ldap:///cn=Write DNS > Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' % dict(realm=api.env.basedn)] > > Besides these, patch worked fine on both upgrade and new installation. So when > you remove these chunks, it will be ack. > > Martin Updated patch attached. Tomas -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0073-7-Remove-support-for-IPA-deployments-with-no-persisten.patch Type: text/x-patch Size: 30615 bytes Desc: not available URL: From mkosek at redhat.com Fri Aug 9 10:16:35 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Aug 2013 12:16:35 +0200 Subject: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search In-Reply-To: <5204BE46.7060201@redhat.com> References: <51B86955.6040905@redhat.com> <51E4250E.9030201@redhat.com> <51E4F433.6030901@redhat.com> <9416239.8Nbpp4Oebj@thinkpad7.brq.redhat.com> <51FFCBE4.8050807@redhat.com> <52025F2D.6060206@redhat.com> <5203C568.4060004@redhat.com> <5204BE46.7060201@redhat.com> Message-ID: <5204C183.3020009@redhat.com> On 08/09/2013 12:02 PM, Tomas Babej wrote: > On 08/08/2013 06:20 PM, Martin Kosek wrote: >> On 08/07/2013 04:52 PM, Tomas Babej wrote: >>> On 08/05/2013 05:59 PM, Martin Kosek wrote: >>>> On 07/17/2013 01:47 PM, Tomas Babej wrote: >>>>>> I will release version 3.5 before end of this week. I have some small fixes >>>>>> ready so it is worth to release it now. >>>>>> >>>>>> To summarize the discussion - please remove following options from >>>>>> configuration file and LDAP schema: >>>>>> cache_ttl >>>>>> psearch (attribute idnsPersistentSearch in idnsConfigObject) >>>>>> zone_refresh (attribute idnsZoneRefresh in idnsConfigObject) >>>>>> >>>>>> -- >>>>>> Petr^2 Spacek >>>>> I have a patch ready, but it can't be tested until 3.5 is out. >>>>> >>>>> Tomas >>>>> >>>> I did not test the patch yet, I just want to comment on one thing I just >>>> noticed. >>>> >>>> I is it a good idea to remove idnsZoneRefresh and idnsPersistentSearch >>>> attribute types and modify idnsConfigObject objectclass? >>>> >>>> This will affect not only new instances, but also the old ones (i.e. RHEL-6.4) >>>> which may still use these attributes. DNS config object would suddenly become >>>> unusable because DS would refuse to operate the entry as it does not follow >>>> the >>>> schema. The same applies for ACIs. >>>> >>>> I would personally not do these changes yet, I think just hiding and >>>> marking as >>>> DeprecatedParam is enough for now. Alexander, what do you think? >>>> >>>> Martin >>> We discussed this with Martin. I agreed it would be less cumbersome to >>> keep the attributes in schema for now. >>> >>> I retested the patches, updated versions attached. >>> >>> Petr, can bind-dyndb-ldap handle idnsConfigObject containing >>> idnsPersistentSearch >>> and idnsZoneRefresh attributes? >>> >> I still see some schema and aci changes: >> >> --- a/install/updates/10-bind-schema.update >> +++ b/install/updates/10-bind-schema.update >> @@ -44,7 +44,7 @@ add:attributeTypes: >> SUBSTR caseIgnoreIA5SubstringsMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >> X-ORIGIN 'IPA v2' ) >> -add:attributeTypes: >> +remove:attributeTypes: >> ( 2.16.840.1.113730.3.8.5.16 >> NAME 'idnsZoneRefresh' >> DESC 'zone refresh interval' >> @@ -52,7 +52,7 @@ add:attributeTypes: >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >> SINGLE-VALUE >> X-ORIGIN 'IPA v2' ) >> -add:attributeTypes: >> +remove:attributeTypes: >> ( 2.16.840.1.113730.3.8.5.17 >> NAME 'idnsPersistentSearch' >> DESC 'allow persistent searches' >> @@ -65,8 +65,7 @@ add:objectClasses: >> NAME 'idnsConfigObject' >> DESC 'DNS global config options' >> STRUCTURAL >> - MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR $$ >> - idnsZoneRefresh $$ idnsPersistentSearch >> + MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR >> ) ) >> add:objectClasses: >> ( 2.16.840.1.113730.3.8.12.18 >> >> AND >> >> - _write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy || >> idnsforwarders || idnsallowsyncptr || idnszonerefresh || >> idnspersistentsearch")(target = "ldap:///cn=dns,%(realm)s")(version 3.0;acl >> "permission:Write DNS Configuration";allow (write) groupdn = "ldap:///cn=Write >> DNS Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' % >> dict(realm=api.env.basedn)] >> + _write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy || >> idnsforwarders || idnsallowsyncptr")(target = >> "ldap:///cn=dns,%(realm)s")(version 3.0;acl "permission:Write DNS >> Configuration";allow (write) groupdn = "ldap:///cn=Write DNS >> Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' % >> dict(realm=api.env.basedn)] >> >> Besides these, patch worked fine on both upgrade and new installation. So when >> you remove these chunks, it will be ack. >> >> Martin > Updated patch attached. > > Tomas > ACK! Pushed to master. Martin From pspacek at redhat.com Fri Aug 9 12:30:59 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 09 Aug 2013 14:30:59 +0200 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance Message-ID: <5204E103.1090109@redhat.com> Hello, I would like to get opinions about key maintenance for DNSSEC. Problem summary: - FreeIPA will support DNSSEC - DNSSEC deployment requires <2,n> cryptographic keys for each DNS zone (i.e. objects in LDAP) - The same keys are shared by all FreeIPA servers - Keys have limited lifetime and have to be re-generated on monthly basics (in very first approximation, it will be configurable and the interval will differ for different key types) - The plan is to store keys in LDAP and let 'something' (i.e. certmonger or oddjob?) to generate and store the new keys back into LDAP - There are command line tools for key-generation (dnssec-keygen from the package bind-utils) - We plan to select one super-master which will handle regular key-regeneration (i.e. do the same as we do for special CA certificates) - Keys stored in LDAP will be encrypted somehow, most probably by some symmetric key shared among all IPA DNS servers Could certmonger or oddjob do key maintenance for us? I can imagine something like this: - watch some attributes in LDAP and wait until some key expires - run dnssec-keygen utility - read resulting keys and encrypt them with given 'master key' - store resulting blobs in LDAP - wait until another key reaches expiration timestamp It is simplified, because there will be multiple keys with different lifetimes, but the idea is the same. All the gory details are in the thread '[Freeipa-devel] DNSSEC support design considerations: key material handling': https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html Nalin and others, what do you think? Is certmonger or oddjob the right place to do something like this? Thank you for your time! -- Petr^2 Spacek From simo at redhat.com Fri Aug 9 12:49:29 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 09 Aug 2013 08:49:29 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <5204AB71.3080904@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> <51EE44E9.6010807@redhat.com> <5204AB71.3080904@redhat.com> Message-ID: <1376052569.21810.114.camel@willson.li.ssimo.org> On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: > On 23.7.2013 10:55, Petr Spacek wrote: > > On 19.7.2013 19:55, Simo Sorce wrote: > >> I will reply to the rest of the message later if necessary, still > >> digesting some of your answers, but I wanted to address the following > >> first. > >> > >> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: > >>> > >>> The most important question at the moment is "What can we postpone? > >>> How > >>> fragile it can be for shipping it as part of Fedora 20?" Could we > >>> declare > >>> DNSSEC support as "technology preview"/"don't use it for anything > >>> serious"? > >> > >> Until we figur out proper management in LDAP we will be a bit stuck, esp > >> if we want to consider usin the 'somthing' that stores keys instead of > >> toring them stright in LDAP. > >> > >> So maybe we can start with allowing just one server to do DNSSEC and > >> source keys from files for now ? > > > > The problem is that DNSSEC deployment *on single domain* is 'all or nothing': > > All DNS servers have to support DNSSEC otherwise the validation on client side > > can fail randomly. > > > > Note that *parent* zone indicates that the particular child zone is secured > > with DNSSEC by sending DS (delegation signer) record to the client. Validation > > will fail if client receives DS record from the parent but no signatures are > > present in data from 'child' zone itself. > > > > This prevents downgrade (DNSSEC => plain DNS) attacks. > > > > As a result, we have only two options: One DNS server with DNSSEC enabled or > > arbitrary number DNS servers without DNSSEC, which is very unfortunate. > > > >> as soon as we have that workign we should also have clearer plans about > >> how we manage keys in LDAP (or elsewhere). > > Dmitri, Martin and me discussed this proposal in person and the new plan is: > - Elect one super-master which will handle key generation (as we do with > special CA certificates) I guess we can start this way, but how do you determine which one is master ? I do not really like to have all this 'super roles', it's brittle and admins will be confused which means one day their whole infrastructure will be down because the keys are expired and all the clients will refuse to communicate with anything. I think it is ok as a first implementation, but I think this *must not* be the final state. We can and must do better than this. > - Store generated DNSSEC keys in LDAP > - Encrypt stored keys with 'DNSSEC master key' shared by all servers ok. > - Derive 'DNSSEC master key' from 'Kerberos master key' during server > install/upgrade and store it somewhere on the filesystem (as the Kerberos > master key, on each IPA server) The Kerberos master key is not stored on disk, furthermore it could change, so if you derive it at install time and install a replica after it was changed everything will break. I think we need to store the key in LDAP, encrypted, and dump it to disk when a new one is generated. Aside, DNSSEC uses pub/private key crypto so this would be a special 'master key' used exclusively to encrypt keys in LDAP ? > - Consider certmonger or oddjob as key generation triggers I do not understand this comment. > I think that we should add one new thing - a 'salt' - used for Kerberos master > key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC > master key as necessary without a change in the Kerberos master key. Salts are not necessary, HKDF from a cryptographically random key does not require it. > Does it make sense? Does anybody have any ideas/recommendations which > libraries we should use for key derivation and key material en/decryption? openssl/nss I already have all the basic code we need for that. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Aug 9 13:12:36 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Aug 2013 09:12:36 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <1376052569.21810.114.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> <51EE44E9.6010807@redhat.com> <5204AB71.3080904@redhat.com> <1376052569.21810.114.camel@willson.li.ssimo.org> Message-ID: <5204EAC4.40100@redhat.com> Simo Sorce wrote: > On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: >> On 23.7.2013 10:55, Petr Spacek wrote: >>> On 19.7.2013 19:55, Simo Sorce wrote: >>>> I will reply to the rest of the message later if necessary, still >>>> digesting some of your answers, but I wanted to address the following >>>> first. >>>> >>>> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: >>>>> >>>>> The most important question at the moment is "What can we postpone? >>>>> How >>>>> fragile it can be for shipping it as part of Fedora 20?" Could we >>>>> declare >>>>> DNSSEC support as "technology preview"/"don't use it for anything >>>>> serious"? >>>> >>>> Until we figur out proper management in LDAP we will be a bit stuck, esp >>>> if we want to consider usin the 'somthing' that stores keys instead of >>>> toring them stright in LDAP. >>>> >>>> So maybe we can start with allowing just one server to do DNSSEC and >>>> source keys from files for now ? >>> >>> The problem is that DNSSEC deployment *on single domain* is 'all or nothing': >>> All DNS servers have to support DNSSEC otherwise the validation on client side >>> can fail randomly. >>> >>> Note that *parent* zone indicates that the particular child zone is secured >>> with DNSSEC by sending DS (delegation signer) record to the client. Validation >>> will fail if client receives DS record from the parent but no signatures are >>> present in data from 'child' zone itself. >>> >>> This prevents downgrade (DNSSEC => plain DNS) attacks. >>> >>> As a result, we have only two options: One DNS server with DNSSEC enabled or >>> arbitrary number DNS servers without DNSSEC, which is very unfortunate. >>> >>>> as soon as we have that workign we should also have clearer plans about >>>> how we manage keys in LDAP (or elsewhere). >> >> Dmitri, Martin and me discussed this proposal in person and the new plan is: >> - Elect one super-master which will handle key generation (as we do with >> special CA certificates) > > I guess we can start this way, but how do you determine which one is > master ? > I do not really like to have all this 'super roles', it's brittle and > admins will be confused which means one day their whole infrastructure > will be down because the keys are expired and all the clients will > refuse to communicate with anything. AFAIU keys don't expire, rather there is a rollover process. The problem would be if the server that controlled the rollover went away the keys would never roll, leaving you potentially exposed. > I think it is ok as a first implementation, but I think this *must not* > be the final state. We can and must do better than this. > >> - Store generated DNSSEC keys in LDAP >> - Encrypt stored keys with 'DNSSEC master key' shared by all servers > > ok. > >> - Derive 'DNSSEC master key' from 'Kerberos master key' during server >> install/upgrade and store it somewhere on the filesystem (as the Kerberos >> master key, on each IPA server) > > The Kerberos master key is not stored on disk, furthermore it could > change, so if you derive it at install time and install a replica after > it was changed everything will break. I think we need to store the key > in LDAP, encrypted, and dump it to disk when a new one is generated. > > Aside, DNSSEC uses pub/private key crypto so this would be a special > 'master key' used exclusively to encrypt keys in LDAP ? > >> - Consider certmonger or oddjob as key generation triggers > > I do not understand this comment. He is trying to automate the key rollover. I don't think certmonger will work as it is designed for X.509 certs. Are you proposing an additional attribute to schedule the rollover? I thought that it was a good idea to have some flexibility here to prevent timed DoS attacks for rollover time. >> I think that we should add one new thing - a 'salt' - used for Kerberos master >> key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC >> master key as necessary without a change in the Kerberos master key. > > Salts are not necessary, HKDF from a cryptographically random key does > not require it. > >> Does it make sense? Does anybody have any ideas/recommendations which >> libraries we should use for key derivation and key material en/decryption? > > openssl/nss I already have all the basic code we need for that. I prefer the procedure just outlined in https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html which just calls dnssec-keygen rather than trying to roll your own. I don't know what derivation really buys you. rob From akrivoka at redhat.com Fri Aug 9 14:03:56 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 09 Aug 2013 16:03:56 +0200 Subject: [Freeipa-devel] [PATCH] 0055 Fix tests which fail after ipa-adtrust-install In-Reply-To: <52049C9F.6080706@redhat.com> References: <5203A683.4040907@redhat.com> <52049C9F.6080706@redhat.com> Message-ID: <5204F6CC.2090503@redhat.com> On 08/09/2013 09:39 AM, Tomas Babej wrote: > On 08/08/2013 04:09 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch should fix the failing unit tests. >> >> https://fedorahosted.org/freeipa/ticket/3852 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > There are two tests failing on my machine when running the tests after > ipa-adtrust-install with your patch applied: You say there are two tests failing but I only see one below. > > ====================================================================== > FAIL: test_group[24]: group_find: Search for POSIX groups > ---------------------------------------------------------------------- > Traceback (most recent call last): > [...] > AssertionError: assert_deepequal: dict keys mismatch. > test_group[24]: group_find: Search for POSIX groups > missing keys = [] > extra keys = ['ipantsecurityidentifier'] > expected = {'dn': > ipapython.dn.DN('cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'), > 'cn': [u'editors'], 'objectclass': Fuzzy(None, None, at > 0x3768c08>), 'gidnumber': [Fuzzy('^\\d+$', , None)], > 'ipauniqueid': > [Fuzzy('^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$', 'unicode'>, None)], 'description': [u'Limited admins who can edit other users']} > got = {'dn': > u'cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com', > 'cn': (u'editors',), 'objectclass': (u'top', u'groupofnames', u'posixgroup', > u'ipausergroup', u'ipaobject', u'nestedGroup', u'ipantgroupattrs'), > 'ipantsecurityidentifier': > (u'S-1-5-21-1457515837-642396627-3509099663-1002',), 'gidnumber': > (u'1804600002',), 'ipauniqueid': (u'7c6e1672-0039-11e3-9567-001a4a2221fb',), > 'description': (u'Limited admins who can edit other users',)} > path = ('result', 1) > > I think you need the wrap the dictionary discribing the editor's group entry > with the add_sid wrapper, and its objectclasses using the add_oc wrapper. > > [tbabej at vm-139 freeipa]$ git diff > diff --git a/ipatests/test_xmlrpc/test_group_plugin.py > b/ipatests/test_xmlrpc/test_group_plugin.py > index d380fe5..14c70cd 100644 > --- a/ipatests/test_xmlrpc/test_group_plugin.py > +++ b/ipatests/test_xmlrpc/test_group_plugin.py > @@ -447,14 +447,15 @@ class test_group(Declarative): > objectclasses.posixgroup, u'ipantgroupattrs')), > 'ipauniqueid': [fuzzy_uuid], > }), > - { > + add_sid({ > 'dn': get_group_dn('editors'), > 'gidnumber': [fuzzy_digits], > 'cn': [u'editors'], > 'description': [u'Limited admins who can edit other > users'], > - 'objectclass': fuzzy_set_ci(objectclasses.posixgroup), > + 'objectclass': fuzzy_set_ci(add_oc( > + objectclasses.posixgroup, u'ipantgroupattrs')), > 'ipauniqueid': [fuzzy_uuid], > - }, > + }), > dict( > dn=get_group_dn(group1), > cn=[group1], > > > These changes were sufficient for me to have the unit test suite run without > errors. > -- > Tomas Babej > Associate Software Engeneer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org I retested the patch and the tests are passing in my setup. The editors group definitely does not have the ipantsecurityidentifier attribute nor the ipantgroupattrs objectclass: [akrivoka at vm-181 freeipa]$ ipa group-show editors --all dn: cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com Group name: editors Description: Limited admins who can edit other users GID: 1977000002 ipauniqueid: 91b3597e-00f3-11e3-92ae-001a4a22217b objectclass: top, groupofnames, posixgroup, ipausergroup, ipaobject, nestedGroup What I noticed though, is that if I delete and re-create the editors group (after ipa-adtrust-install has been run), it then gets the above mentioned attribute and objectclass. Maybe you did some similar manipulation in your setup, resulting in the test failing? -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amessina at messinet.com Fri Aug 9 14:13:12 2013 From: amessina at messinet.com (Anthony Messina) Date: Fri, 09 Aug 2013 09:13:12 -0500 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <1376052569.21810.114.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <5204AB71.3080904@redhat.com> <1376052569.21810.114.camel@willson.li.ssimo.org> Message-ID: <5750106.441KhhDJRC@linux-ws1.messinet.com> On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote: > > Dmitri, Martin and me discussed this proposal in person and the new plan > > is: - Elect one super-master which will handle key generation (as we do > > with special CA certificates) > > I guess we can start this way, but how do you determine which one is > master ? > I do not really like to have all this 'super roles', it's brittle and > admins will be confused which means one day their whole infrastructure > will be down because the keys are expired and all the clients will > refuse to communicate with anything. > > I think it is ok as a first implementation, but I think this *must not* > be the final state. We can and must do better than this. I've been "listening in" on the DNSSEC discussion and do not mean to derail the course of this thread, however... >From a sysadmin's perspective, I agree with Simo's comments insofar as they relate to "not all masters being created equal". Administratively, unequal masters have the potential to create single points of failure which may be difficult to resolve, especially on upgrade between minor versions and between replicas. Small-time sysadmins like myself who may only run one (maybe two) FreeIPA instances incur a significant about of trouble when that already limited resource isn't working properly after some issue with file ownership or SELinux during a yum upgrade. In addition, I realize FreeIPA wasn't probably designed with small-ish installs as the target use case. But I would argue that since FreeIPA *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it is a viable choice for small-timers (with the only exception being no real way to "back up" an instance without an "always-on" multi-master replica). As a user who has just completed a "manual" migration/upgrade to F19 (after realizing that there really was no way to migrate/upgrade when the original install began on F17 2.1 on bare metal with the split slapd processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA move forward but continue to deliver the above-mentioned services to the small-timers, who, without FreeIPA's unification, would never be able to manage or offer all of those services independently, like the big-timers might be able to. Thanks. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From pspacek at redhat.com Fri Aug 9 14:22:03 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 09 Aug 2013 16:22:03 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <5204EAC4.40100@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> <51EE44E9.6010807@redhat.com> <5204AB71.3080904@redhat.com> <1376052569.21810.114.camel@willson.li.ssimo.org> <5204EAC4.40100@redhat.com> Message-ID: <5204FB0B.70705@redhat.com> On 9.8.2013 15:12, Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: >>> On 23.7.2013 10:55, Petr Spacek wrote: >>>> On 19.7.2013 19:55, Simo Sorce wrote: >>>>> I will reply to the rest of the message later if necessary, still >>>>> digesting some of your answers, but I wanted to address the following >>>>> first. >>>>> >>>>> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: >>>>>> >>>>>> The most important question at the moment is "What can we postpone? >>>>>> How >>>>>> fragile it can be for shipping it as part of Fedora 20?" Could we >>>>>> declare >>>>>> DNSSEC support as "technology preview"/"don't use it for anything >>>>>> serious"? >>>>> >>>>> Until we figur out proper management in LDAP we will be a bit stuck, esp >>>>> if we want to consider usin the 'somthing' that stores keys instead of >>>>> toring them stright in LDAP. >>>>> >>>>> So maybe we can start with allowing just one server to do DNSSEC and >>>>> source keys from files for now ? >>>> >>>> The problem is that DNSSEC deployment *on single domain* is 'all or nothing': >>>> All DNS servers have to support DNSSEC otherwise the validation on client >>>> side >>>> can fail randomly. >>>> >>>> Note that *parent* zone indicates that the particular child zone is secured >>>> with DNSSEC by sending DS (delegation signer) record to the client. >>>> Validation >>>> will fail if client receives DS record from the parent but no signatures are >>>> present in data from 'child' zone itself. >>>> >>>> This prevents downgrade (DNSSEC => plain DNS) attacks. >>>> >>>> As a result, we have only two options: One DNS server with DNSSEC enabled or >>>> arbitrary number DNS servers without DNSSEC, which is very unfortunate. >>>> >>>>> as soon as we have that workign we should also have clearer plans about >>>>> how we manage keys in LDAP (or elsewhere). >>> >>> Dmitri, Martin and me discussed this proposal in person and the new plan is: >>> - Elect one super-master which will handle key generation (as we do with >>> special CA certificates) >> >> I guess we can start this way, but how do you determine which one is >> master ? How do we select the 'super-master' for CA certificates? I would re-use the same logic (for now). >> I do not really like to have all this 'super roles', it's brittle and >> admins will be confused which means one day their whole infrastructure >> will be down because the keys are expired and all the clients will >> refuse to communicate with anything. > > AFAIU keys don't expire, rather there is a rollover process. The problem would > be if the server that controlled the rollover went away the keys would never > roll, leaving you potentially exposed. In DNSSEC it could be a problem. Each signature contains validity interval and validation will fail when it expires. It practically means that DNS will stop working if the keys are not rotated in time. (More keys can co-exists, so the roll-over process can be started e.g. a month before the current key really expires.) >> I think it is ok as a first implementation, but I think this *must not* >> be the final state. We can and must do better than this. I definitely agree. IMHO the basic problem is the same or very similar for DNSSEC key generation & CA certificates, so we should solve both problems at once - one day. I mean - we need to coordinate key & cert maintenance between multiple masters somehow - and this will be the common problem for CA & DNSSEC. >>> - Store generated DNSSEC keys in LDAP >>> - Encrypt stored keys with 'DNSSEC master key' shared by all servers >> >> ok. >> >>> - Derive 'DNSSEC master key' from 'Kerberos master key' during server >>> install/upgrade and store it somewhere on the filesystem (as the Kerberos >>> master key, on each IPA server) >> >> The Kerberos master key is not stored on disk, furthermore it could >> change, so if you derive it at install time and install a replica after Interesting. The master key is stored in the krbMKey attribute in cn=REALM,cn=kerberos,dc=your,dc=domain , I didn't know that. >> it was changed everything will break. I think we need to store the key >> in LDAP, encrypted, and dump it to disk when a new one is generated. I agree. >> Aside, DNSSEC uses pub/private key crypto so this would be a special >> 'master key' used exclusively to encrypt keys in LDAP ? That was the original intention - generate a new 'DNSSEC master key'/'DNSSEC wrapping key' and let named+certmonger/oddjob to play with it. >>> - Consider certmonger or oddjob as key generation triggers >> >> I do not understand this comment. I mean: How hard would it be to extend certmonger/oddjob to take care of DNSSEC key maintenance? > He is trying to automate the key rollover. I don't think certmonger will work > as it is designed for X.509 certs. Are you proposing an additional attribute > to schedule the rollover? I thought that it was a good idea to have some > flexibility here to prevent timed DoS attacks for rollover time. It definitely requires some changes in certmonger, I'm just exploring various possibilities. >>> I think that we should add one new thing - a 'salt' - used for Kerberos master >>> key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC >>> master key as necessary without a change in the Kerberos master key. >> >> Salts are not necessary, HKDF from a cryptographically random key does >> not require it. It is correct as long as you don't need to change the 'derived' key without a change in the 'source' key. Did I miss something? We don't need to dive into details because (as Simo pointed out) the K/M can change. >>> Does it make sense? Does anybody have any ideas/recommendations which >>> libraries we should use for key derivation and key material en/decryption? >> >> openssl/nss I already have all the basic code we need for that. > > I prefer the procedure just outlined in > https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html which > just calls dnssec-keygen rather than trying to roll your own. I don't know > what derivation really buys you. I think that there is slight misunderstanding. We need to decide how the keys generated by dnssec-keygen will be wrapped with 'the DNSSEC master key'. I totally agree with using dnssec-keygen for the 'key generation' part! :-) Simo proposed to use separate keys for each IPA DNS server. It could work in theory, but I can see some problems: How the keys are split: - The (trusted) parent zone 'com.' contains hashes of public parts of KSKs (key signing keys) used by child zone 'example.com.' - The child zone 'example.com.' contains the whole public parts of KSKs and ZSKs - KSKs signs ZSKs (zone signing key, the keys used for signing of real data) Layers are: top ] hash of the KSKs in parent zone 'com.' middle] KSKs in the zone 'example.com.' bottom] ZSKs - 'zone subkeys' used for real data signing How the client validates DNSSEC signatures (client operates with public keys): 1) Read hashes of KSKs from (trusted) parent domain 'com.' 2) Get KSKs from the child domain 'example.com.' 3) Compare hashes received from parent domain with hashes computed from KSKs. 4) Trust ZSKs published in the zone 'example.com.' if they are signed by valid KSK (valid = hash from parent and the zone itself match). 5) Get data requested by user along with signatures. 6) Validate that the data are signed by one of valid ZSKs. The point is that *parent* zone has to contain all KSKs used by all IPA servers. As a result, different keys on each IPA server will create very interesting game with KSKs (on each KSK re-generation, i.e. approximately once a year). The another problem is that each key & signature contains key-id, which has to be unique for each key. The client use this key-id to chose the right public key for signature validation. Key-id is 16 bits long unsigned integer, so there is not much space for distributed number assignment. Fortunately, you can re-use key-id if the key was removed from the zone and records with this key-id disappeared from all caches. A secure interval for key-id reuse can be determined from key TTL. And the third problem: Many keys in parent zone will result in much bigger responses to clients from the parent. It could cause some problems if we exceed some 'local limit'. Some crazy firewalls could drop large UDP DNS packets and TCP is not very nice solution alternative. -- Petr^2 Spacek From tbabej at redhat.com Fri Aug 9 15:35:26 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 09 Aug 2013 17:35:26 +0200 Subject: [Freeipa-devel] [PATCH] 0055 Fix tests which fail after ipa-adtrust-install In-Reply-To: <5204F6CC.2090503@redhat.com> References: <5203A683.4040907@redhat.com> <52049C9F.6080706@redhat.com> <5204F6CC.2090503@redhat.com> Message-ID: <52050C3E.4020101@redhat.com> On 08/09/2013 04:03 PM, Ana Krivokapic wrote: > On 08/09/2013 09:39 AM, Tomas Babej wrote: >> On 08/08/2013 04:09 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch should fix the failing unit tests. >>> >>> https://fedorahosted.org/freeipa/ticket/3852 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> There are two tests failing on my machine when running the tests >> after ipa-adtrust-install with your patch applied: > > You say there are two tests failing but I only see one below. > That was just debris from trying to break your patch too much, one of my comments rendered invalid in the end :) >> >> ====================================================================== >> FAIL: test_group[24]: group_find: Search for POSIX groups >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> [...] >> AssertionError: assert_deepequal: dict keys mismatch. >> test_group[24]: group_find: Search for POSIX groups >> missing keys = [] >> extra keys = ['ipantsecurityidentifier'] >> expected = {'dn': >> ipapython.dn.DN('cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'), >> 'cn': [u'editors'], 'objectclass': Fuzzy(None, None, > at 0x3768c08>), 'gidnumber': [Fuzzy('^\\d+$', > 'basestring'>, None)], 'ipauniqueid': >> [Fuzzy('^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$', >> , None)], 'description': [u'Limited admins who can >> edit other users']} >> got = {'dn': >> u'cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com', >> 'cn': (u'editors',), 'objectclass': (u'top', u'groupofnames', >> u'posixgroup', u'ipausergroup', u'ipaobject', u'nestedGroup', >> u'ipantgroupattrs'), 'ipantsecurityidentifier': >> (u'S-1-5-21-1457515837-642396627-3509099663-1002',), 'gidnumber': >> (u'1804600002',), 'ipauniqueid': >> (u'7c6e1672-0039-11e3-9567-001a4a2221fb',), 'description': (u'Limited >> admins who can edit other users',)} >> path = ('result', 1) >> >> I think you need the wrap the dictionary discribing the editor's >> group entry with the add_sid wrapper, and its objectclasses using the >> add_oc wrapper. >> >> [tbabej at vm-139 freeipa]$ git diff >> diff --git a/ipatests/test_xmlrpc/test_group_plugin.py >> b/ipatests/test_xmlrpc/test_group_plugin.py >> index d380fe5..14c70cd 100644 >> --- a/ipatests/test_xmlrpc/test_group_plugin.py >> +++ b/ipatests/test_xmlrpc/test_group_plugin.py >> @@ -447,14 +447,15 @@ class test_group(Declarative): >> objectclasses.posixgroup, >> u'ipantgroupattrs')), >> 'ipauniqueid': [fuzzy_uuid], >> }), >> - { >> + add_sid({ >> 'dn': get_group_dn('editors'), >> 'gidnumber': [fuzzy_digits], >> 'cn': [u'editors'], >> 'description': [u'Limited admins who can >> edit other users'], >> - 'objectclass': >> fuzzy_set_ci(objectclasses.posixgroup), >> + 'objectclass': fuzzy_set_ci(add_oc( >> + objectclasses.posixgroup, >> u'ipantgroupattrs')), >> 'ipauniqueid': [fuzzy_uuid], >> - }, >> + }), >> dict( >> dn=get_group_dn(group1), >> cn=[group1], >> >> >> These changes were sufficient for me to have the unit test suite run >> without errors. >> -- >> Tomas Babej >> Associate Software Engeneer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org > > I retested the patch and the tests are passing in my setup. The > editors group definitely does not have the ipantsecurityidentifier > attribute nor the ipantgroupattrs objectclass: > > [akrivoka at vm-181 freeipa]$ ipa group-show editors --all > dn: > cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > Group name: editors > Description: Limited admins who can edit other users > GID: 1977000002 > ipauniqueid: 91b3597e-00f3-11e3-92ae-001a4a22217b > objectclass: top, groupofnames, posixgroup, ipausergroup, ipaobject, > nestedGroup > > What I noticed though, is that if I delete and re-create the editors > group (after ipa-adtrust-install has been run), it then gets the above > mentioned attribute and objectclass. Maybe you did some similar > manipulation in your setup, resulting in the test failing? > I think it does depend on whether you have ran the ipa-sidgen task when running the ipa-adtrust-install. Do you think we can cover both cases here? > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From enewland at redhat.com Fri Aug 9 17:46:20 2013 From: enewland at redhat.com (Ellen Newlands) Date: Fri, 9 Aug 2013 13:46:20 -0400 Subject: [Freeipa-devel] [Freeipa-interest] Announcing FreeIPA 3.3.0 In-Reply-To: <5203A524.7060808@redhat.com> References: <5203A524.7060808@redhat.com> Message-ID: Congrats team, this is a very nice list of new features. On Aug 8, 2013, at 10:03 AM, Martin Kosek wrote: > The FreeIPA team is proud to announce FreeIPA v3.3.0! > > It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 > builds are already on their way to updates-testing repo. > > == Highlights in 3.3.0 == > === New features for 3.3 === > * Active Directory integration: > ** Support of externally defined POSIX attributes for Active Directory trusted > domains > ** Automatic discovery of Active Directory identity mapping configuration > ** Support of trusted domain users for legacy clients > ** Identity mapping for AD users can now be delegated > * Performance improvements in processing large number of users and groups > * Automated integration testing infrastructure > * ipa-advise utility is added to generate client setup advice based on an IPA > master configuration > * FreeIPA-specific SELinux policies has been merged to the main SELinux policy > in Fedora 19 > * SSSD 1.11 is required > > === Active Directory integration === > Starting with FreeIPA 3.3, it is possible to define identity ranges for a > trusted Active Directory domain that rely on POSIX attributes provided by AD DC > instead of generating them out of corresponding security identifiers. This > functionality requires Services for Unix (SFU) or Identity Management for UNIX > enabled on Active Directory side and is provided mostly to aid with migration > to SID-based mapping. > > In order to support externally defined POSIX attributes, identity ranges have > been extended to support new range types: > * AD trust with SID-based mapping: 'ipa-ad-trust' (default) > * SFU support: 'ipa-ad-trust-posix' > > 'ipa-ad-trust-posix' range type is activated when range discovery finds out SFU > is in use by Active Directory domain. To override automatic detection, > --range-type=ipa-ad-trust can be specified to 'ipa trust-add' command. > > FreeIPA 3.3 requires SSSD 1.11 on the IPA master in order to support externally > defined POSIX attributes in AD. > > More details: http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD > > FreeIPA 3.3 provides a new way to enable legacy clients to support trusted > domain users. A compatibility tree, provided by slapi-nis, can now be > configured to look up trusted domain users and handle authentication for them. > This functionality relies on SSSD 1.11 and release 0.47.7 of slapi-nis. One can > enable legacy clients support by running ipa-adtrust-install and answering > positively to the corresponding question. > > More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > Finally, SSSD 1.11 is used to query identity information about trusted domains' > users from within IPA framework, including SID to name and name to SID > resolution. In addition to speed improvements, FreeIPA 3.3 allows to manage > mappings for trusted domains' users without requiring elevated privileges of > 'trust admins'. > > === Performance improvements === > When acting on large datasets, FreeIPA now reduces number of potential read > roundtrips required to update user and group information. When scaled to > thousands of users and groups, this shortens the time required by certain > operations tenfold. > > === Automated testing infrastructure === > The FreeIPA team has been providing self-testing code for a long time. > > The FreeIPA 3.3 test suite includes a framework for integration tests that > verify functionality such as replication across several machines. Tests can be > run manually, or by test automation servers such as Jenkins or Beaker. > > Development builds now create a freeipa-tests RPM containing the test suite and > related tools. However, as the focus is on testing development code, this > package will not be released to Fedora yet. > > More details: http://www.freeipa.org/page/V3/Integration_testing > > Additionally, it is now possible to run Web UI tests through the test suite. > > More details: http://www.freeipa.org/page/Web_UI_Integration_Tests > > === IPA advise tool === > FreeIPA 3.3 introduces new framework to generate recipes of configuration based > on how IPA master is configured. These recipes can be taken to the target > client systems and used there to configure them for a specific task. > > We expect to expand use of 'ipa-advise' tool to cover at least configuration of > legacy systems in subsequent releases. Three advices are provided with FreeIPA > 3.3.0 release: > * configuring a generic Fedora release with authconfig tool > * configuring RHEL-based systems with SSSD 1.5-1.8 > * configuring Debian-based systems with SSSD 1.5-1.8 > > Contributions are always welcome to grow capabilities of 'ipa-advise' tool to > other areas. > > More details: > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts#Major_configuration_options_and_enablement > > === SELinux policy === > SELinux policies specific to FreeIPA have been merged back to the main SELinux > policy package in Fedora 19. Starting with FreeIPA 3.2.2 (available in Fedora > 19 updates) SELinux policy is no londer provided by freeipa-selinux package and > the package is removed in favor of selinux-policy package. > > === SSSD 1.11 is required === > FreeIPA 3.3 depends on SSSD 1.11 for cross-realm trusts with Active Directory. > In particular, FreeIPA 3.3 depends on a new operational mode of SSSD called > 'ipa_server_mode'. Thus, SSSD 1.11 is required for FreeIPA 3.3. > > More details: https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > > == Upgrading == > === FreeIPA servers with CA installed prior to version 3.1 === > Manual upgrade procedure is required for FreeIPA servers installed with version > prior to 3.1. > > === Other FreeIPA servers and clients === > An IPA server can be upgraded simply by installing updated rpms. The server > does not need to be shut down in advance. > > Please note that if you are doing the upgrade in special environment (e.g. > FedUp) which does not allow running LDAP server during upgrade process, upgrade > scripts need to be run manually after the first boot: > # ipa-upgradeconfig > # ipa-ldap-updater --upgrade > > Please note, that the performance improvements requires an extended set of > indexes to be configured. RPM update for an IPA server with a excessive number > of users may require several minutes to finish. > > If you have multiple servers you may upgrade them one at a time. It is expected > that all servers will be upgraded in a relatively short period (days or weeks > not months). They should be able to co-exist peacefully but new features will > not be available on old servers and enrolling a new client against an old > server will result in the SSH keys not being uploaded. > > Downgrading a server once upgraded is not supported. > > Upgrading from 2.2.0 and later versions is supported. Upgrading from previous > versions is not supported and has not been tested. > > An enrolled client does not need the new packages installed unless you want to > re-enroll it. SSH keys for already installed clients are not uploaded, you will > have to re-enroll the client or manually upload the keys. > > == Feedback == > Please provide comments, bugs and other feedback via the freeipa-users mailing > list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel > on Freenode. > > == Detailed Changelog since 3.2.0 == > === Alexander Bokovoy (9): === > * Fix cldap parser to work with a single equality filter (NtVer=...) > * Make sure domain_name is also set when processing INP_NAME requests > * Fix extdom plugin to provide unqualified name in response as sssd expects > * Generate syntethic MS-PAC for all services running on IPA master > * ipa-adtrust-install: configure compatibility tree to serve trusted domain users > * ipa-kdb: cache KDC hostname on startup > * ipa-kdb: reinit mspac on HTTP TGT acquisition to aid trust-add case > * ipaserver/dcerpc: attempt to resolve SIDs through SSSD first > * Rename slapi-nis configuration variable > > === Ana Krivokapic (26): === > * Prompt for nameserver IP address in dnszone-add > * Do not display success message on failure in web UI > * Ignore files generated by build > * Deprecate options --dom-sid and --dom-name in idrange-mod > * Prevent error when running IPA commands with su/sudo > * Fix displaying of success message > * Fix location of service.crt in .gitignore > * Improve handling of options in ipa-client-install > * Fail when adding a trust with a different range > * Do not display traceback to user > * Require rid-base and secondary-rid-base in idrange-add after ipa-adtrust-install > * Fix bug in adtrustinstance > * Use correct DS instance in ipactl status > * Avoid systemd service deadlock during shutdown > * Make sure replication works after DM password is changed > * Use --ignore-dependencies only when necessary > * Properly handle non-existent cert files > * Add 'ipa_server_mode' option to SSSD configuration > * Bump version of sssd in spec file > * Use admin at REALM when testing if SSSD is ready > * Fix internal error in idrange-add > * Honor 'enabled' option for widgets. > * Expose ipaRangeType in Web UI > * Add ipa-advise plugins for legacy clients > * Enable running API commands in ipa-advise plugins > * Add new command compat-is-enabled > > === Diane Trout (1): === > * Fix log format not a string literal. > > === Jakub Hrozek (3): === > * Remove unused variable > * IPA KDB MS-PAC: return ENOMEM if allocation fails > * IPA KDB MS-PAC: remove unused variable > > === Jan Cholasta (21): === > * Use the correct PKCS#12 file for HTTP server. > * Remove stray error condition in ipa-server-install. > * Handle exceptions gracefully when verifying PKCS#12 files. > * Skip empty lines when parsing pk12util output. > * Do not allow installing CA replicas in CA-less setup. > * Do not track DS certificate in CA-less setup. > * Fix CA-less check in ipa-replica-install and ipa-ca-install. > * Do not skip SSSD known hosts in ipa-client-install --ssh-trust-dns. > * Enable SASL mapping fallback. > * Skip cert issuer validation in service and host commands in CA-less install. > * Check trust chain length in CA-less install. > * Use LDAP search instead of *group_show to check if a group exists. > * Use LDAP search instead of *group_show to check for a group objectclass. > * Use LDAP modify operation directly to add/remove group members. > * Add missing substring indices for attributes managed by the referint plugin. > * Add missing equality index for ipaUniqueId. > * Run gpg-agent explicitly when encrypting/decrypting files. > * Add new hidden command option to suppress processing of membership attributes. > * Ask for PKCS#12 password interactively in ipa-server-install. > * Ask for PKCS#12 password interactively in ipa-replica-prepare. > * Print newline after receiving EOF in installutils.read_password. > > === Lukas Slebodnik (4): === > * Use pkg-config to detect cmocka > * Use right function prototype for thread function > * Remove unused variable > * Remove unused variable > > === Martin Kosek (17): === > * Set KRB5CCNAME so that dirsrv can work with newer krb5-server > * Handle DIR type CCACHEs in test_cmdline properly > * Avoid exporting KRB5_KTNAME in dirsrv env > * Remove redundant u'' character > * Drop SELinux subpackage > * Drop redundant directory /var/cache/ipa/sessions > * Remove entitlement support > * Run server upgrade and restart in posttrans > * Require new selinux-policy replacing old server-selinux subpackage > * Bump minimum SSSD version > * Become 3.3.0 Beta 1 > * Free NSS objects in --external-ca scenario > * Use valid LDAP search base in migration plugin > * Increase default SASL buffer size > * Become 3.3.0 Beta 2 > * Add requires for slapi-nis and SSSD > * Become 3.3.0 > > === Nathaniel McCallum (10): === > * Add ipaUserAuthType and ipaUserAuthTypeClass > * Add IPA OTP schema and ACLs > * ipa-kdb: Add OTP support > * Add the krb5/FreeIPA RADIUS companion daemon > * Remove unnecessary prefixes from ipa-pwd-extop files > * Add OTP support to ipa-pwd-extop > * Fix client install exception if /etc/ssh is missing > * Permit reads to ipatokenRadiusProxyUser objects > * Fix for small syntax error in OTP schema > * Use libunistring ulc_casecmp() on unicode strings > > === Petr Spacek (1): === > * ipa-client-install: Add 'debug' and 'show' statements to nsupdate commands > > === Petr Viktorin (33): === > * Remove leading zero from IPA_NUM_VERSION > * Relax getkeytab test to allow additional messages on stderr > * Remove code to install Dogtag 9 > * Flush stream after writing service messages > * Make an ipa-tests package > * Add ipa-run-tests command > * Add Nose plugin for BeakerLib integration > * Add a plugin for test ordering > * Add a framework for integration test configuration > * Add a framework for integration testing > * Introduce a class for remote commands > * Collect logs from tests > * Show logs in failed tests > * tests: Allow public keys for authentication to the remote machines > * tests: Configure/unconfigure remote hosts > * Host class improvements > * Use dosctrings in BeakerLib phase descriptions > * Make BeakerLib logging less verbose > * BeakerLib plugin: Log http links in test docstrings > * Integration test config: Make it possible to specify host IP > * ipa-client: Use "ipa" as the package name for i18n > * Move BeakerLibProcess out of BeakerLibPlugin > * test_integration: Add log collection to Host > * test_integration: Set up CA on replicas by default > * Add more test tasks > * Add install_topo to test tasks > * Add the ipa-test-task tool > * Add tar and xz dependencies to the freeipa-tests package > * Correct default value of LDAPClient.get_entries scope argument > * test_simple_replication: Wait for replication to finish before checking > * Add the new no_member option to CLI tests > * Update translations > * Fix installutils.get_password without a TTY > > === Petr Vobornik (24): === > * Fix: HBAC Test tab is missing > * Move spec modifications from facet factories to pre_ops > * Unite and move facet pre_ops to related modules > * Web UI: move ./_base/metadata_provider.js to ./metadata.js > * Regression fix: missing control buttons in nested search facets > * Make ssbrowser.html work in IE 10 > * Fix regression: missing facet tab group labels > * Regression fix: rule table with ext. member support doesn't offer any items > * Fix default value selection in radio widget > * Do not redirect to https in /ipa/ui on non-HTML files > * Create Firefox configuration extension on CA-less install > * Disable checkboxes and radios for readonly attributes > * Better automated test support > * Fix container element in adder dialogs > * Upstream Web UI tests > * Web UI search optimization > * Break long words in notification area > * Remove word 'field' from GECOS param label > * Web UI integration tests: Add trust tests > * Web UI integration tests: Add ui_driver method descriptions > * Web UI integration tests: Verify data after add and mod > * Web UI integration tests: Compute range sizes to avoid overlaps > * Web UI integration tests: PEP8 fixes > * Web UI integration tests: Code quality fixes > > === Rob Crittenden (4): === > * Bump version for development branch to 3.2.99 > * Return the correct Content-type on negotiated XML-RPC requests. > * Add Camellia ciphers to allowed list. > * Hide sensitive attributes in LDAP updater logging and output > > === Simo Sorce (2): === > * CLDAP: Fix domain handling in netlogon requests > * CLDAP: Return empty reply on non-fatal errors > > === Sumit Bose (5): === > * Fix format string typo > * Fix type of printf argument > * Add PAC to master host TGTs > * extdom: replace winbind calls with POSIX/SSSD calls > * Remove winbind client configure check > > === Tomas Babej (32): === > * Remove redundancy from hbactest help text > * Do not translate trust type and direction with --raw in trust_show and trust-find > * Support multiple local domain ranges with RID base set > * Do not allow removal of ID range of an active trust > * Use private ccache in ipa install tools > * Remove redundant check for env.interactive > * Add prompt_param method to avoid code duplication > * Incorporate interactive prompts in idrange-add > * Do not check userPassword with 7-bit plugin > * Manage ipa-otpd.socket by IPA > * Add ipaRangeType attribute to LDAP Schema > * Add update plugin to fill in ipaRangeType attribute > * Extend idrange commands to support new range origin types > * PEP8 fixes in idrange.py > * Remove hardcoded values from idrange plugin tests > * Return ipaRangeType as a list in idrange commands > * Do not redirect ipa/crl to HTTPS > * Add --range-type option that forces range type of the trusted domain > * Add libsss_nss_idmap-devel to BuildRequires > * Change group ownership of CRL publish directory > * Provide ipa-advise tool > * Use AD LDAP probing to create trusted domain ID range > * Move requirement for keyutils to freeipa-python package > * Change shebang to absolute path in ipa-client-automount > * Skip referrals when converting LDAP result to LDAPEntry > * Refactor the interactive prompt logic in idrange_add > * Limit pwpolicy maxlife to 20000 days > * Use case-insensitive dict for trusted domain info > * Improve help entry for ipa host > * Remove overlapping use-cases of the same result variable > * Add a word wrapping for comment log messages to AdviceLogger > * Wrap lines in the list of available advices > > _______________________________________________ > Freeipa-interest mailing list > Freeipa-interest at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-interest From mkosek at redhat.com Mon Aug 12 07:34:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Aug 2013 09:34:19 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <5750106.441KhhDJRC@linux-ws1.messinet.com> References: <51924269.8020000@redhat.com> <5204AB71.3080904@redhat.com> <1376052569.21810.114.camel@willson.li.ssimo.org> <5750106.441KhhDJRC@linux-ws1.messinet.com> Message-ID: <52088FFB.3040407@redhat.com> On 08/09/2013 04:13 PM, Anthony Messina wrote: > On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote: >>> Dmitri, Martin and me discussed this proposal in person and the new >>> plan is: - Elect one super-master which will handle key generation (as >>> we do with special CA certificates) >> >> I guess we can start this way, but how do you determine which one is >> master ? I do not really like to have all this 'super roles', it's >> brittle and admins will be confused which means one day their whole >> infrastructure will be down because the keys are expired and all the >> clients will refuse to communicate with anything. >> >> I think it is ok as a first implementation, but I think this *must not* >> be the final state. We can and must do better than this. > > I've been "listening in" on the DNSSEC discussion and do not mean to > derail the course of this thread, however... > >> From a sysadmin's perspective, I agree with Simo's comments insofar as >> they > relate to "not all masters being created equal". Administratively, > unequal masters have the potential to create single points of failure > which may be difficult to resolve, especially on upgrade between minor > versions and between replicas. > > Small-time sysadmins like myself who may only run one (maybe two) FreeIPA > instances incur a significant about of trouble when that already limited > resource isn't working properly after some issue with file ownership or > SELinux during a yum upgrade. > > In addition, I realize FreeIPA wasn't probably designed with small-ish > installs as the target use case. But I would argue that since FreeIPA > *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it > is a viable choice for small-timers (with the only exception being no real > way to "back up" an instance without an "always-on" multi-master > replica). > > As a user who has just completed a "manual" migration/upgrade to F19 > (after realizing that there really was no way to migrate/upgrade when the > original install began on F17 2.1 on bare metal with the split slapd > processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA > move forward but continue to deliver the above-mentioned services to the > small-timers, who, without FreeIPA's unification, would never be able to > manage or offer all of those services independently, like the big-timers > might be able to. > > Thanks. -A Hello Anthony, >From your post above, I did not understand what is the actual problem with FreeIPA vs. small-time admins. I personally think that FreeIPA is usable for both small-timers and bigger deployments (sorry for having to undergo the manual migration procedure). If you see that this is not true in some part of FreeIPA, please comment or file tickets/RFEs/Bugzillas which we can process and act on to amend the situation. Thanks in advance, Martin From pviktori at redhat.com Mon Aug 12 08:17:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Aug 2013 10:17:01 +0200 Subject: [Freeipa-devel] [PATCH] 0119 Switch client to JSON-RPC In-Reply-To: <51FB781D.4060201@redhat.com> References: <50F53F2B.4020406@redhat.com> <511CF3D3.80107@redhat.com> <5159FE2B.306@redhat.com> <518D0A2F.6040401@redhat.com> <51FB781D.4060201@redhat.com> Message-ID: <520899FD.9060202@redhat.com> On 08/02/2013 11:13 AM, Petr Viktorin wrote: > On 05/10/2013 04:54 PM, Petr Viktorin wrote: >> On 04/01/2013 11:37 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 01/15/2013 12:36 PM, Petr Viktorin wrote: >>>>> I meant to hold this patch a while longer to let it mature, but from >>>>> what Brian Smith asked on the user list it seems it could help him. >>>>> >>>>> Design: http://freeipa.org/page/V3/JSON-RPC >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3299 >>>>> >>>>> See the design page for what the patch does. >>>>> >>>>> >>>>> As much as I've tried to avoid them, the code includes some >>>>> workarounds: >>>>> It extends xmlrpclib to also support JSON. This is rather intrusive, >>>>> but >>>>> to not do that I'd need to write a parallel stack for JSON, without >>>>> the >>>>> help of a standard library. >>>>> The registration of either jsonclient or xmlclient as "rpcclient" in >>>>> the >>>>> API also needs a bit of magic, since the framework requires the class >>>>> name to match the attribute. >>>>> >>>>> >>>>> To prevent backwards compatibility problems, we need to ensure that >>>>> all >>>>> official JSON clients send the API version, so this patch should be >>>>> applied after my patches 0104-0106. >>>>> >>>> >>>> Updating to current master. >>> >>> Please reverse this change in ipalib/rpc.py: >>> >>> @@ -665,8 +788,6 @@ class xmlclient(Connectible): >>> except Exception, e: >>> if not fallback: >>> raise >>> - else: >>> - self.log.info('Connection to %s failed with %s', >>> url, e) >>> serverproxy = None >>> >>> This logs connection errors when the client fails over to another >>> server. >> >> Thanks. Done, and rebased to master. >> >>> The changes look really good. The show stopper is that using jsonrpc >>> doesn't create a session key. I noticed that xmlrpc_uri is hardcoded >>> into ipalib/session.py but it appears the issue is deeper than that. >> >> That uses only the hostname from xmlrpc_uri. When using different >> hostnames in xmlrpc_uri and jsonrpc_uri *on the server*, it'll put the >> wrong domain in the cookie. In this case I think it's the configuration >> that's wrong. >> >> The real problem is that KerberossSession code which creates the cookie, >> was not called by the JSON server. >> Patch 0223 adds it. >> >> Patch 0224 adds the server class name (e.g. [jsonserver_kerb]) to the >> server logs. It should help debug problems specific to a >> backend/protocol. > > Rebased onto current master. > Another minor rebase -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0119.5-Switch-client-to-JSON-RPC.patch Type: text/x-patch Size: 39793 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0223.5-Make-jsonserver_kerb-start-a-cookie-based-session.patch Type: text/x-patch Size: 1580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0224.5-Add-server-protocol-type-to-rpcserver-logs.patch Type: text/x-patch Size: 2805 bytes Desc: not available URL: From pviktori at redhat.com Mon Aug 12 10:10:33 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Aug 2013 12:10:33 +0200 Subject: [Freeipa-devel] [PATCH] 0267 Update translations In-Reply-To: References: <51FBC152.6090304@redhat.com> <51FBC9A6.8040401@redhat.com> Message-ID: <5208B499.5000107@redhat.com> On 08/02/2013 05:10 PM, J?r?me Fenal wrote: > 2013/8/2 Petr Viktorin > > > On 08/02/2013 04:25 PM, Petr Viktorin wrote: > > Hello, > I've prepared a patch with fresh translations pulled from Transifex. > As usual the patch is pretty large; please download it from: > https://github.com/encukou/__freeipa/compare/translations.__patch > > Thank you to all translators! > > This time the patch also updates the Transifex URL in our config > file; > the old .net URL is still redirecting to the new .com, but its > certificate has expired. > > > In other news, I've set up a repo to archive the Transifex > translations, > and a cron job to update it periodically. The repo can be found at: > https://github.com/encukou/__freeipa-translations > > With this in place, there should be less fear of pushing source > strings > to Transifex. > If you want to keep your own archive; my cron job goes like this: > make > git add po > git commit -m"Update translations (automatic commit)" > git push origin master > > > In yet other news, the ticket to split long __doc__ strings is > scheduled > for the IPA 3.4. This time it's getting in :) > https://fedorahosted.org/__freeipa/ticket/3587 > > > > The IPA team doesn't have anyone who can check translations, so > self-ACK, pushed to master: 5d141bd39cb99f2c2e16b61bcc4e06b734bbab04 > > > Great! > > Were the __doc__ strings splitted as well? Not yet, it's planned for the next release (3.4). I'm sorry if that wasn't clear. > Or are they splitted on double \n at string extraction time? The plan is to split them directly in the source; the extraction process isn't too flexible. I think it would be best to only split them when they're first changed, so the existing translations aren't disturbed. -- Petr? From loris at lgs.com.ve Mon Aug 12 12:30:04 2013 From: loris at lgs.com.ve (Loris Santamaria) Date: Mon, 12 Aug 2013 08:00:04 -0430 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <5204FB0B.70705@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> <51EE44E9.6010807@redhat.com> <5204AB71.3080904@redhat.com> <1376052569.21810.114.camel@willson.li.ssimo.org> <5204EAC4.40100@redhat.com> <5204FB0B.70705@redhat.com> Message-ID: <1376310604.31361.14.camel@toron.pzo.lgs.com.ve> El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribi?: > On 9.8.2013 15:12, Rob Crittenden wrote: > > Simo Sorce wrote: > >> On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: > >>> On 23.7.2013 10:55, Petr Spacek wrote: > >>>> On 19.7.2013 19:55, Simo Sorce wrote: > >>>>> I will reply to the rest of the message later if necessary, still > >>>>> digesting some of your answers, but I wanted to address the following > >>>>> first. > >>>>> > >>>>> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: > >>>>>> > >>>>>> The most important question at the moment is "What can we postpone? > >>>>>> How > >>>>>> fragile it can be for shipping it as part of Fedora 20?" Could we > >>>>>> declare > >>>>>> DNSSEC support as "technology preview"/"don't use it for anything > >>>>>> serious"? > >>>>> > >>>>> Until we figur out proper management in LDAP we will be a bit stuck, esp > >>>>> if we want to consider usin the 'somthing' that stores keys instead of > >>>>> toring them stright in LDAP. > >>>>> > >>>>> So maybe we can start with allowing just one server to do DNSSEC and > >>>>> source keys from files for now ? > >>>> > >>>> The problem is that DNSSEC deployment *on single domain* is 'all or nothing': > >>>> All DNS servers have to support DNSSEC otherwise the validation on client > >>>> side > >>>> can fail randomly. > >>>> > >>>> Note that *parent* zone indicates that the particular child zone is secured > >>>> with DNSSEC by sending DS (delegation signer) record to the client. > >>>> Validation > >>>> will fail if client receives DS record from the parent but no signatures are > >>>> present in data from 'child' zone itself. > >>>> > >>>> This prevents downgrade (DNSSEC => plain DNS) attacks. > >>>> > >>>> As a result, we have only two options: One DNS server with DNSSEC enabled or > >>>> arbitrary number DNS servers without DNSSEC, which is very unfortunate. > >>>> > >>>>> as soon as we have that workign we should also have clearer plans about > >>>>> how we manage keys in LDAP (or elsewhere). > >>> > >>> Dmitri, Martin and me discussed this proposal in person and the new plan is: > >>> - Elect one super-master which will handle key generation (as we do with > >>> special CA certificates) > >> > >> I guess we can start this way, but how do you determine which one is > >> master ? > How do we select the 'super-master' for CA certificates? I would re-use the > same logic (for now). > > >> I do not really like to have all this 'super roles', it's brittle and > >> admins will be confused which means one day their whole infrastructure > >> will be down because the keys are expired and all the clients will > >> refuse to communicate with anything. > > > > AFAIU keys don't expire, rather there is a rollover process. The problem would > > be if the server that controlled the rollover went away the keys would never > > roll, leaving you potentially exposed. > In DNSSEC it could be a problem. Each signature contains validity interval and > validation will fail when it expires. It practically means that DNS will stop > working if the keys are not rotated in time. (More keys can co-exists, so the > roll-over process can be started e.g. a month before the current key really > expires.) > > >> I think it is ok as a first implementation, but I think this *must not* > >> be the final state. We can and must do better than this. > I definitely agree. IMHO the basic problem is the same or very similar for > DNSSEC key generation & CA certificates, so we should solve both problems at > once - one day. > > I mean - we need to coordinate key & cert maintenance between multiple masters > somehow - and this will be the common problem for CA & DNSSEC. You could implement a "protocol" where each master has a day or the week or the month where it checks if there are any pending keys or CA certificates to renew and tries to do the job. Next day it is another master's turn to do the same job and so on. Every master is identified by an unique nsDS5ReplicaId, which could be used as a vector to generate an ordered list of masters. If you have masters with nsDS5ReplicaId 5,34,35,45 you can say that the one with nsDS5ReplicaId 5 is master number one, the next is master number two and so on. On first day of the month it is master number one's turn to check of any pending key and CA certificate renewal issues and to do the renewal. On second day of the month it is master number two's turn to do the same. So if a master was down the job will be done next day by the next master. The cicle will repeat every "number of master" days, in the example every four days. -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6173 bytes Desc: not available URL: From amessina at messinet.com Mon Aug 12 13:20:54 2013 From: amessina at messinet.com (Anthony Messina) Date: Mon, 12 Aug 2013 08:20:54 -0500 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <52088FFB.3040407@redhat.com> References: <51924269.8020000@redhat.com> <5750106.441KhhDJRC@linux-ws1.messinet.com> <52088FFB.3040407@redhat.com> Message-ID: <98310711.KWPpMUYqM0@linux-ws1.messinet.com> On Monday, August 12, 2013 09:34:19 AM Martin Kosek wrote: > On 08/09/2013 04:13 PM, Anthony Messina wrote: > > On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote: > >>> Dmitri, Martin and me discussed this proposal in person and the new > >>> plan is: - Elect one super-master which will handle key generation (as > >>> we do with special CA certificates) > >> > >> > >> > >> I guess we can start this way, but how do you determine which one is > >> master ? I do not really like to have all this 'super roles', it's > >> brittle and admins will be confused which means one day their whole > >> infrastructure will be down because the keys are expired and all the > >> clients will refuse to communicate with anything. > >> > >> > >> > >> I think it is ok as a first implementation, but I think this *must not* > >> be the final state. We can and must do better than this. > > > > > > > > I've been "listening in" on the DNSSEC discussion and do not mean to > > derail the course of this thread, however... > > > > > > > >> From a sysadmin's perspective, I agree with Simo's comments insofar as > >> they > > > > relate to "not all masters being created equal". Administratively, > > unequal masters have the potential to create single points of failure > > which may be difficult to resolve, especially on upgrade between minor > > versions and between replicas. > > > > > > > > Small-time sysadmins like myself who may only run one (maybe two) FreeIPA > > > > instances incur a significant about of trouble when that already limited > > resource isn't working properly after some issue with file ownership or > > > > SELinux during a yum upgrade. > > > > > > > > In addition, I realize FreeIPA wasn't probably designed with small-ish > > installs as the target use case. But I would argue that since FreeIPA > > *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it > > is a viable choice for small-timers (with the only exception being no real > > way to "back up" an instance without an "always-on" multi-master > > replica). > > > > > > > > As a user who has just completed a "manual" migration/upgrade to F19 > > (after realizing that there really was no way to migrate/upgrade when the > > original install began on F17 2.1 on bare metal with the split slapd > > processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA > > move forward but continue to deliver the above-mentioned services to the > > small-timers, who, without FreeIPA's unification, would never be able to > > manage or offer all of those services independently, like the big-timers > > might be able to. > > > > > > > > Thanks. -A > > Hello Anthony, > > From your post above, I did not understand what is the actual problem with > FreeIPA vs. small-time admins. I personally think that FreeIPA is usable for > both small-timers and bigger deployments (sorry for having to undergo the > manual migration procedure). > > If you see that this is not true in some part of FreeIPA, please comment or > file tickets/RFEs/Bugzillas which we can process and act on to amend the > situation. > > Thanks in advance, > Martin Martin, I *do* think FreeIPA is an excellent choice for small-time admins, especially with the increased effort on improving documentation, the upcoming ipa-client-advise tool, and the ipa-backup/restore tools. I merely wanted to state that 1) I agreed with Simo's comments, and point out that 2) unequal masters with regard to DNSSEC has the potential to be a single point of failure and an area of concern for small-time admins who may for example, already be coping with the, albeit solid, recommendations to run multiple concurrent masters in virtualized environments with duplicates of those environments available simply for testing upgrades (a fair amount of administrative overhead for a small-timer). In short, I was voicing a sysadmin's opinion that FreeIPA should continue to evolve in a way that supports small-time admins as well. I do not think there is a problem with "FreeIPA vs. small-time admins" and am hoping it stays that way. As far as the manual migration... This was likely an issue with documentation and/or release notes: 2.2 said it was ok to upgrade from 2.1, 3.0 said it was ok to upgrade from 2.2, etc. This is likely all true, unless your original 2.2 was based on a 2.1 with Dogtag9. At that point in time, I had one FreeIPA master on bare metal. I have since upgraded my infrastructure and "started over" to have two FreeIPA masters in VMs hosted on separate machines. Hopefully, this amount of redundancy will afford me some upgrade protection for the future. Thanks again. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From pviktori at redhat.com Mon Aug 12 13:45:36 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Aug 2013 15:45:36 +0200 Subject: [Freeipa-devel] [PATCH] 0268 Allow freeipa-tests to work with older paramiko versions Message-ID: <5208E700.6070101@redhat.com> Hello, Not all systems have the latest python-paramiko available. This patch allows the testing framework to run with Paramiko 1.7, as opposed to requiring 1.10. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0268-Allow-freeipa-tests-to-work-with-older-paramiko-vers.patch Type: text/x-patch Size: 3161 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 13 08:50:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Aug 2013 10:50:23 +0200 Subject: [Freeipa-devel] [PATCH] 419 Prevent *.pyo and *.pyc multilib problems Message-ID: <5209F34F.4000004@redhat.com> Differences in the python byte code fails in a build validation (rpmdiff) done on difference architecture of the same package. This patch: 1) Ensures that timestamps of generated *.pyo and *.pyc files match 2) Python integer literals greater or equal 2^32 and lower than 2^64 are converted to long right away to prevent different type of the integer on architectures with different size of int https://fedorahosted.org/freeipa/ticket/3858 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-419-prevent-.pyo-and-.pyc-multilib-problems.patch Type: text/x-patch Size: 7473 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 13 09:10:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Aug 2013 11:10:04 +0200 Subject: [Freeipa-devel] [PATCH] 420-421 Fix selected minor issues in the spec file and license Message-ID: <5209F7EC.4030300@redhat.com> This fixes 1), 2), 3) and 4) in https://fedorahosted.org/freeipa/ticket/3855. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-420-remove-rpmlint-warnings-in-spec-file.patch Type: text/x-patch Size: 7287 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-421-fix-selected-minor-issues-in-the-spec-file-and-licen.patch Type: text/x-patch Size: 4071 bytes Desc: not available URL: From pviktori at redhat.com Tue Aug 13 10:43:10 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 Aug 2013 12:43:10 +0200 Subject: [Freeipa-devel] [PATCH] 420-421 Fix selected minor issues in the spec file and license In-Reply-To: <5209F7EC.4030300@redhat.com> References: <5209F7EC.4030300@redhat.com> Message-ID: <520A0DBE.20707@redhat.com> On 08/13/2013 11:10 AM, Martin Kosek wrote: > This fixes 1), 2), 3) and 4) in https://fedorahosted.org/freeipa/ticket/3855. > > Martin > Tested together with your patch 419. IPA still builds, tests pass. ACK. -- Petr? From pviktori at redhat.com Tue Aug 13 10:43:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 Aug 2013 12:43:12 +0200 Subject: [Freeipa-devel] [PATCH] 419 Prevent *.pyo and *.pyc multilib problems In-Reply-To: <5209F34F.4000004@redhat.com> References: <5209F34F.4000004@redhat.com> Message-ID: <520A0DC0.5050300@redhat.com> On 08/13/2013 10:50 AM, Martin Kosek wrote: > Differences in the python byte code fails in a build validation > (rpmdiff) done on difference architecture of the same package. > > This patch: > 1) Ensures that timestamps of generated *.pyo and *.pyc files match > 2) Python integer literals greater or equal 2^32 and lower than 2^64 > are converted to long right away to prevent different type of > the integer on architectures with different size of int > > https://fedorahosted.org/freeipa/ticket/3858 I tested this together with your patches 420-421. IPA still builds, tests pass. ACK. -- Petr? From pvoborni at redhat.com Tue Aug 13 10:48:33 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Aug 2013 12:48:33 +0200 Subject: [Freeipa-devel] [PATCH] 429 Make ssh_widget not-editable if attr is readonly In-Reply-To: <51F672A1.1070902@redhat.com> References: <51E7BFAB.2000809@redhat.com> <51F632A0.4020002@redhat.com> <51F639AD.3060007@redhat.com> <51F65E50.10906@redhat.com> <51F669AD.7030904@redhat.com> <51F672A1.1070902@redhat.com> Message-ID: <520A0F01.2000801@redhat.com> On 07/29/2013 03:48 PM, Ana Krivokapic wrote: > On 07/29/2013 03:10 PM, Petr Vobornik wrote: >> On 07/29/2013 02:21 PM, Ana Krivokapic wrote: >>> On 07/29/2013 11:45 AM, Petr Vobornik wrote: >>>> dialog.textarea = $('