From jcholast at redhat.com Mon Dec 1 07:46:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Dec 2014 08:46:48 +0100 Subject: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade In-Reply-To: <54772621.5050003@redhat.com> References: <54772621.5050003@redhat.com> Message-ID: <547C1CE8.5000707@redhat.com> Hi, Dne 27.11.2014 v 14:24 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4676 > Replaces current workaround. Should go to 4.1.3. > Patch attached. When constructing URLs with host:port, please use ipautil.format_netloc(). wget should be added as a dependency of freeipa-python in the spec file. Honza -- Jan Cholasta From jcholast at redhat.com Mon Dec 1 08:10:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Dec 2014 09:10:37 +0100 Subject: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds In-Reply-To: <54772535.40202@redhat.com> References: <54772535.40202@redhat.com> Message-ID: <547C227D.4040503@redhat.com> Hi, Dne 27.11.2014 v 14:20 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4771 > Patch attached. I would prefer if you did something like this instead: 1) Add validate_idn_normalized function with the normalized IDN check to ipapython.dnsutil, have it raise ValueError if the check fails. (Also please get rid of the map() call for better readability.) 2) Use validate_idn_normalized in DNSNameParam. 3) Do the following in validate_zonemgr_str: validate_idn_normalized(zonemgr) try: zonemgr = DNSName(zonemgr) except dns.exception.DNSException as e: raise ValueError(e) Honza -- Jan Cholasta From dkupka at redhat.com Mon Dec 1 11:20:53 2014 From: dkupka at redhat.com (David Kupka) Date: Mon, 01 Dec 2014 12:20:53 +0100 Subject: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration In-Reply-To: References: Message-ID: <547C4F15.8000601@redhat.com> On 11/30/2014 02:03 AM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4583 > > Thanks, > > Gabe > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hello! Thanks for patch. I guess that you wanted to add the "iburst" option only once. Right now it will generate lines like: server iburst iburst Attaching the fixed patch. Are you satisfied with it? -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0038-2-Update-default-NTP-configuration.patch Type: text/x-patch Size: 1445 bytes Desc: not available URL: From mkosek at redhat.com Mon Dec 1 12:05:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Dec 2014 13:05:48 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> Message-ID: <547C599C.6040202@redhat.com> On 11/30/2014 03:28 AM, Gabe Alford wrote: > Ignore the last patch. Updated patch attached. > > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford wrote: > >> This patch removes the app_PYTHON usage. >> >> Thanks, >> >> Gabe >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek wrote: >> >>> Exactly, this was the message from Martin :-) I did not test it myself, >>> but >>> removing all app_PYTHON should be benign given we use Python setup.py >>> packaging. >>> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: >>>> Thanks guys. Sounds like it would be better to submit a patch that >>> removes >>>> app_PYTHON if it is considered dead code. >>>> >>>> Gabe >>>> >>>> On Thursday, November 27, 2014, Petr Spacek wrote: >>>> >>>>> On 27.11.2014 11:00, Martin Basti wrote: >>>>>> On 27/11/14 00:50, Gabe Alford wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Wondering if I could get a review. Updated patch attached. >>>>>>> >>>>>>> Thanks, >>>>>>> Gabe >>>>>>> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >>>> >>>>>>> >> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gabe >>>>>>> >>>>>>> >>>>>>> >>>>>> Hello, >>>>>> >>>>>> sorry for late response. >>>>>> >>>>>> We push this ticket to backlog, as it would be part of build system >>>>> refactoring. >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the better >>>>> solution is >>>>>> remove it, instead of keeping dead code up-to-date. >>>>> >>>>> Just to clarify: >>>>> It can be pushed if it works, there is no need to postpone accepting >>> patch >>>>> if >>>>> the patch seems okay and doesn't break anything. >>>>> >>>>> Martin, please keep in mind that contributions are welcome at any time. >>>>> >>>>> Milestones in Trac reflect our view of priorities but it doesn't >>> prevent us >>>>> from accepting correct patches from contributions at any time, no >>> matter >>>>> which >>>>> priority is stated in Trac (or even if there is no ticket for it ...). >>>>> >>>>> -- >>>>> Petr^2 Spacek Worked in my tests, I did not see any breakage. I guess we can also remove the ipa-client/ipaclient/Makefile.am while we are at it. Martin From jcholast at redhat.com Mon Dec 1 12:16:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Dec 2014 13:16:54 +0100 Subject: [Freeipa-devel] [PATCH] 380 Improve validation of --instance and --backend options in ipa-restore Message-ID: <547C5C36.5040407@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-380-Improve-validation-of-instance-and-backend-options-i.patch Type: text/x-patch Size: 7965 bytes Desc: not available URL: From jcholast at redhat.com Mon Dec 1 12:32:10 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Dec 2014 13:32:10 +0100 Subject: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds In-Reply-To: <547C227D.4040503@redhat.com> References: <54772535.40202@redhat.com> <547C227D.4040503@redhat.com> Message-ID: <547C5FCA.5010909@redhat.com> Dne 1.12.2014 v 09:10 Jan Cholasta napsal(a): > Hi, > > Dne 27.11.2014 v 14:20 Martin Basti napsal(a): >> Ticket: https://fedorahosted.org/freeipa/ticket/4771 >> Patch attached. > > I would prefer if you did something like this instead: > > 1) Add validate_idn_normalized function with the normalized IDN check > to ipapython.dnsutil, have it raise ValueError if the check fails. (Also > please get rid of the map() call for better readability.) > > 2) Use validate_idn_normalized in DNSNameParam. > > 3) Do the following in validate_zonemgr_str: > > validate_idn_normalized(zonemgr) > try: > zonemgr = DNSName(zonemgr) > except dns.exception.DNSException as e: > raise ValueError(e) > > Honza > Actually, sratch that, exceptions thrown by python-dns do not have messages. ACK. Pushed to: master: ca25c92ea89661755d7204ac703e8c419c8929fa ipa-4-1: 07e29d250550f238e5706b348d69632fdbb67bda Honza -- Jan Cholasta From pvoborni at redhat.com Mon Dec 1 13:17:02 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 01 Dec 2014 14:17:02 +0100 Subject: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods Message-ID: <547C6A4E.3090307@redhat.com> `--hosts` option added to: * service-allow-create-keytab * service-allow-retrieve-keytab * service-disallow-create-keytab * service-disallow-retrieve-keytab * host-allow-create-keytab * host-allow-retrieve-keytab * host-disallow-create-keytab * host-disallow-retrieve-keytab in order to allow hosts to retrieve keytab of their services or related hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval design page https://fedorahosted.org/freeipa/ticket/4777 I'm pondering how to handle Web UI. I'm not font of adding a third pair of tables to host and service details pages because the amount of space on the page required for the keytab management is much bigger than its importance compared to other fields. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0792-add-hosts-option-to-allow-retrieve-keytab-methods.patch Type: text/x-patch Size: 35192 bytes Desc: not available URL: From pspacek at redhat.com Mon Dec 1 13:22:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 01 Dec 2014 14:22:52 +0100 Subject: [Freeipa-devel] Threat model & abuse cases in design documents Message-ID: <547C6BAC.70807@redhat.com> Hello, while wondering about design for 'external DNS integration' feature I have realized that I did not see any explicit threat model for FreeIPA. Do we have any? IMHO it would be handy to have it somewhere on wiki so it could be used as 'checklist' while developing design documents for security reviews. Threat model ============ IMHO our assumed attacker should have these powers: 1) Do active man-in-the-middle attack on network: - All network communication can be monitored and altered by attacked. - This includes client<->FreeIPA server communication, - and also server<->server communication. 2) Compromise normal user account: I think that in in large networks the probability of successful attack against at least one user account is almost 1. So, we should assume that at least one user account was compromised. I.e. our attacker knows user's password or has equivalent of keytab. 3) Compromise a client machine: Again, I think that in in large networks the probability of successful attack against at least one machine is almost 1. So, we should assume that at least one machine account was compromised. I.e. our attacker has equivalent of machine keytab and keytabs for services running on it. What did I miss? Maybe we should explicitly say how replica files and other 'secrets' (DM password ...) should be handled. It would help with discussion about automated FreeIPA deployment too. Also, we should explicitly say that FreeIPA server itself and its LDAP database is the key to everything. If the FreeIPA server and its LDAP database is compromised then the game is over - attacker has access to everything. Abuse cases =========== IMHO security sensitive design documents (e.g. automated FreeIPA deployment, sub-CAs, Vault, external DNS integration) should explicitly walk through the thread model and state what is going to happen if FreeIPA infrastructure is under attack we assume. E.g. for external DNS integration with symmetric TSIG keys: Proposal in design document: - TSIG keys are distributed all to FreeIPA clients using LDAP & GSSAPI and thus are accessible using any host/client.example.com credentials. Design assessment with thread model in mind: -> MitM attack will not reveal anything because we trust GSSAPI. -> User account compromise will not reveal anything because uses doesn't have access to TSIG keys. -> Single compromised client will reveal TSIG keys to attacker so authentication to external DNS will be completely compromised. This will allow attacker to modify any records in external DNS. This could be have very serious consequences if DNSSEC is in place so clients can fully trust the records and use them for e.g. TLS validation. --> This could be a reason to re-think the design and remove this weak point. What do you think? -- Petr^2 Spacek From jcholast at redhat.com Mon Dec 1 13:33:07 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 01 Dec 2014 14:33:07 +0100 Subject: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods In-Reply-To: <547C6A4E.3090307@redhat.com> References: <547C6A4E.3090307@redhat.com> Message-ID: <547C6E13.8010501@redhat.com> Hi, Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a): > `--hosts` option added to: > * service-allow-create-keytab > * service-allow-retrieve-keytab > * service-disallow-create-keytab > * service-disallow-retrieve-keytab > * host-allow-create-keytab > * host-allow-retrieve-keytab > * host-disallow-create-keytab > * host-disallow-retrieve-keytab > > in order to allow hosts to retrieve keytab of their services or related > hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval > design page > > https://fedorahosted.org/freeipa/ticket/4777 Since groups of users are supported with "group" members, we should probably also support groups of hosts with "hostgroup" members, for consistency. > > > I'm pondering how to handle Web UI. I'm not font of adding a third pair > of tables to host and service details pages because the amount of space > on the page required for the keytab management is much bigger than its > importance compared to other fields. Honza -- Jan Cholasta From mbasti at redhat.com Mon Dec 1 13:39:34 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 01 Dec 2014 14:39:34 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <54735BA0.3030209@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> Message-ID: <547C6F96.1060106@redhat.com> On 24/11/14 17:24, Petr Spacek wrote: > Hello! > > Thank you for the patch. It is not ready yet but the overall direction seems > good. Please see my comments in-line. > > On 24.11.2014 14:35, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >> Patch attached >> >> -- >> Martin Basti >> >> >> freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch >> >> >> From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Fri, 21 Nov 2014 16:54:09 +0100 >> Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration >> >> Shows warning if forward and parent authoritative zone do not have >> proper NS record delegation, which can cause the forward zone will be >> ineffective and forwarding will not work. >> >> The chande in the test was required due python changes order of elemnts >> in dict (python doesnt guarantee an order in dict) >> >> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >> --- >> ipalib/messages.py | 12 +++ >> ipalib/plugins/dns.py | 147 +++++++++++++++++++++++++++++--- >> ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- >> 3 files changed, 149 insertions(+), 12 deletions(-) >> >> diff --git a/ipalib/messages.py b/ipalib/messages.py >> index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f 100644 >> --- a/ipalib/messages.py >> +++ b/ipalib/messages.py >> @@ -200,6 +200,18 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): >> u"If DNSSEC validation is enabled on IPA server(s), " >> u"please disable it.") >> >> +class ForwardzoneIsNotEffectiveWarning(PublicMessage): >> + """ >> + **13008** Forwardzone is not effective, forwarding will not work because >> + there is authoritative parent zone, without proper NS delegation >> + """ >> + >> + errno = 13008 >> + type = "warning" >> + format = _(u"forward zone \"%(fwzone)s\" is not effective (missing proper " >> + u"NS delegation in authoritative zone \"%(authzone)s\"). " >> + u"Forwarding may not work.") > I think that the error message could be made mode useful: > > "Forwarding will not work. Please add NS record > to parent zone %(authzone)s" (or something like that). > >> + >> >> def iter_messages(variables, base): >> """Return a tuple with all subclasses >> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >> index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 100644 >> --- a/ipalib/plugins/dns.py >> +++ b/ipalib/plugins/dns.py >> @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): >> return zone >> >> >> +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): > Generally, this method finds an authoritative zone for given "fwzonename". > What about method name _find_auth_zone_ldap(name) ? > >> + """ >> + Check if forward zone is effective. >> + >> + If parent zone exists as authoritative zone, forward zone will not >> + forward queries. It is necessary to delegate authority of forward zone > I would clarify it: "forward queries by default." > > >> + to another server (non IPA DNS server). > I would personally omit "(non IPA DNS server)" because this mechanism is not > related to IPA domain at all. > >> + Example: >> + >> + Forward zone: sub.example.com >> + Zone: example.com >> + >> + Forwarding will not work, because server thinks it is authoritative >> + and returns NXDOMAIN >> + >> + Adding record: sub.example.com NS nameserver.out.of.ipa.domain. > Again, this is not related to IPA domain at all. I propose this text: > "Adding record: sub.example.com NS ns.sub.example.com." > >> + will delegate authority to another server, and IPA DNS server will >> + forward DNS queries. >> + >> + :param fwzonename: forwardzone >> + :return: None if effective, name of authoritative zone otherwise >> + """ >> + assert isinstance(fwzonename, DNSName) >> + >> + # get all zones >> + zones = api.Command.dnszone_find(pkey_only=True, >> + sizelimit=0)['result'] > Ooooh, are you serious? :-) I don't like this approach, I would rather chop > left-most labels from "name" and so dnszone_find() one by one. What if you > have many DNS zones? > > > This could be thrown away if you iterate only over relevant zones. >> + zonenames = [zone['idnsname'][0].make_absolute() for zone in zones] >> + zonenames.sort(reverse=True, key=len) # sort, we need longest match >> + >> + # check if is there a zone which can cause the forward zone will >> + # be ineffective >> + sub_of_auth_zone = None >> + for name in zonenames: >> + if fwzonename.is_subdomain(name): >> + sub_of_auth_zone = name >> + break >> + >> + if sub_of_auth_zone is None: >> + return None >> + >> + # check if forwardzone is delegated in authoritative zone >> + # test if exists and get NS record >> + try: >> + ns_records = api.Command.dnsrecord_show( >> + sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord'] >> + except (errors.NotFound, KeyError): >> + return sub_of_auth_zone > Note: This function should process only deepest (existing) sub-domain in LDAP > which is active (idnsZoneActive = TRUE). > > Example: > fwzonename = sub.fwd.example.com. > Existing LDAP master zone = fwd.example.com. - DISABLED > Existing LDAP master zone = example.com. > Existing LDAP master zone = com. > > 1) Check existence & activity of fwd.example.com. -> does not exist, continue. > 2) Check existence & activity of example.com. -> exists, search for NS records. > 3) [inner loop - searching for NS records] > 3a) sub.fwd.example.com. NS -> does not exist, continue inner loop. > 3b) fwd.example.com. NS -> does not exist, continue inner loop. > 3c) Inner loop ends: no more (relative) candidate names to try. > 4) Exit returning "example.com." - deepest authoritative super-domain of > sub.fwd.example.com. in LDAP. > > AFAIK content of the NS record does not matter so this check can be thrown > away. (Check this before doing so, please :-)) > >> + # make sure the target is not IPA DNS server >> + # FIXME: what if aliases are used? >> + normalized_ns_records = set() >> + for record in ns_records: >> + if record.endswith('.'): >> + normalized_ns_records.add(record) >> + else: >> + normalized_record = "%s.%s" % (record, sub_of_auth_zone) >> + normalized_ns_records.add(normalized_record) >> + >> + nameservers = [normalize_zone(x) for x in >> + api.Object.dnsrecord.get_dns_masters()] >> + >> + if any(nameserver in normalized_ns_records >> + for nameserver in nameservers): >> + # NS record is pointing to IPA DNS server >> + return sub_of_auth_zone >> + >> + # authoritative zone contains NS records which delegates forwardzone to >> + # different server, forwardzone is effective >> + return None >> + >> + >> class DNSZoneBase(LDAPObject): >> """ >> Base class for DNS Zone >> @@ -3164,6 +3237,29 @@ class dnsrecord(LDAPObject): >> dns_name = entry_name[1].derelativize(dns_domain) >> self.wait_for_modified_attrs(entry, dns_name, dns_domain) >> >> + def warning_if_ns_change_cause_fwzone_ineffective(self, keys, result, >> + options): >> + """after execute""" >> + record_name_absolute = keys[-1] >> + if not keys[-1].is_absolute(): >> + record_name_absolute = keys[-1].derelativize(keys[-2]) >> + >> + try: >> + api.Command.dnsforwardzone_show(record_name_absolute) >> + except errors.NotFound: >> + # no forward zone >> + return >> + >> + authoritative_zone = \ >> + _find_zone_which_makes_fw_zone_ineffective(record_name_absolute) >> + if authoritative_zone: >> + # forward zone is not effective and forwarding will not work >> + messages.add_message( >> + options['version'], result, >> + messages.ForwardzoneIsNotEffectiveWarning( >> + fwzone=record_name_absolute, authzone=authoritative_zone >> + ) >> + ) >> >> >> @register() >> @@ -3358,6 +3454,14 @@ class dnsrecord_add(LDAPCreate): >> return >> raise exc >> >> + def execute(self, *keys, **options): >> + result = super(dnsrecord_add, self).execute(*keys, **options) >> + if 'nsrecord' in options: >> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >> + result, >> + options) >> + return result >> + >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> assert isinstance(dn, DN) >> for attr in getattr(context, 'dnsrecord_precallback_attrs', []): >> @@ -3487,7 +3591,10 @@ class dnsrecord_mod(LDAPUpdate): >> >> if self.api.env['wait_for_dns']: >> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >> - >> + if 'nsrecord' in options: >> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >> + result, >> + options) >> return result >> >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> @@ -3654,19 +3761,23 @@ class dnsrecord_del(LDAPUpdate): >> if self.api.env['wait_for_dns']: >> entries = {(keys[0], keys[1]): None} >> self.obj.wait_for_modified_entries(entries) >> - return result >> + else: >> + result = super(dnsrecord_del, self).execute(*keys, **options) >> + result['value'] = pkey_to_value([keys[-1]], options) >> >> - result = super(dnsrecord_del, self).execute(*keys, **options) >> - result['value'] = pkey_to_value([keys[-1]], options) >> + if getattr(context, 'del_all', False) and not \ >> + self.obj.is_pkey_zone_record(*keys): >> + result = self.obj.methods.delentry(*keys, >> + version=options['version']) >> + context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >> >> - if getattr(context, 'del_all', False) and not \ >> - self.obj.is_pkey_zone_record(*keys): >> - result = self.obj.methods.delentry(*keys, >> - version=options['version']) >> - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >> + if self.api.env['wait_for_dns']: >> + self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >> >> - if self.api.env['wait_for_dns']: >> - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >> + if 'nsrecord' in options or options.get('del_all', False): >> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >> + result, >> + options) >> return result >> >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> @@ -4019,6 +4130,20 @@ class dnsforwardzone_add(DNSZoneBase_add): >> >> return dn >> >> + def execute(self, *keys, **options): >> + result = super(dnsforwardzone_add, self).execute(*keys, **options) >> + authoritative_zone = _find_zone_which_makes_fw_zone_ineffective(keys[-1]) >> + if authoritative_zone: >> + # forward zone is not effective and forwarding will not work >> + messages.add_message( >> + options['version'], result, >> + messages.ForwardzoneIsNotEffectiveWarning( >> + fwzone=keys[-1], authzone=authoritative_zone >> + ) >> + ) >> + >> + return result >> + >> >> @register() >> class dnsforwardzone_del(DNSZoneBase_del): >> diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py >> index fb53853147ecf663cf7015867131445f32364cfb..224a80d98273480f40fd78dea0f27e34ea36492f 100644 >> --- a/ipatests/test_xmlrpc/test_dns_plugin.py >> +++ b/ipatests/test_xmlrpc/test_dns_plugin.py >> @@ -1060,7 +1060,7 @@ class test_dns(Declarative): >> 'srv_part_target' : u'foo.bar.', >> 'srvrecord': [u"1 100 1234 %s" \ >> % zone1_ns]}), >> - expected=errors.ValidationError(name='srv_target', >> + expected=errors.ValidationError(name='srv_weight', >> error=u'Raw value of a DNS record was already set by ' + >> u'"srv_rec" option'), >> ), >> -- 1.8.3.1 > The same check should be done also on zone de/activation. > Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0170.2-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch Type: text/x-patch Size: 17202 bytes Desc: not available URL: From redhatrises at gmail.com Mon Dec 1 15:16:25 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 1 Dec 2014 09:16:25 -0600 Subject: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration In-Reply-To: <547C4F15.8000601@redhat.com> References: <547C4F15.8000601@redhat.com> Message-ID: Thanks, David. You're totally right. I am good with it. thanks, Gabe On Mon, Dec 1, 2014 at 5:20 AM, David Kupka wrote: > On 11/30/2014 02:03 AM, Gabe Alford wrote: > >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/4583 >> >> Thanks, >> >> Gabe >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Hello! > > Thanks for patch. I guess that you wanted to add the "iburst" option only > once. Right now it will generate lines like: > > server iburst iburst > > Attaching the fixed patch. Are you satisfied with it? > > -- > David Kupka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Dec 1 15:17:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 01 Dec 2014 16:17:54 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <54662E77.9020608@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> Message-ID: <547C86A2.5010508@redhat.com> On 14.11.2014 17:31, Petr Spacek wrote: > On 14.11.2014 02:22, Simo Sorce wrote: >> On Tue, 11 Nov 2014 16:29:51 +0100 >> Petr Spacek wrote: >> >>> Hello, >>> >>> this thread is about RFE >>> "IPA servers when installed should register themselves in the >>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >>> >>> It is not a complete design, just a raw idea. >>> >>> >>> Use case >>> ======== >>> FreeIPA installation to a network with existing DNS infrastructure + >>> network administrator who is not willing to add/maintain new DNS >>> servers "just for FreeIPA". >>> >>> >>> High-level idea >>> =============== >>> - Transform dns* commands from FreeIPA framework to equivalent >>> "nsupdate" commands and send DNS updates to existing DNS servers. >>> - Provide necessary encryption/signing keys to nsupdate. >>> >>> >>> 1) Integration to FreeIPA framework >>> =================================== >>> First of all, we need to decide if "external DNS integration" can be >>> used at the same time with FreeIPA-integrated DNS or not. >>> Side-question is what to do if a first server is installed with >>> external-DNS but another replica is being installed with >>> integrated-DNS and so on. >> >> I think being able to integrate with an external DNS is important, and >> not just at the server level, being able to distribute TSIG keys to >> client would be nice too, though a lot less important, than getting >> server integration.. > > Using TSIG on many clients is very problematic. Keep in mind that TSIG is > basically HMAC computed using symmetric key so: > a) Every client would have to use the same key - this is a security nightmare. > b) We would have to distribute and maintain many keys for many^2 clients, > which is an administrative nightmare. > > For *clients* I would rather stay with GSS-TSIG which is much more manageable > because we can use Kerberos trust and Keytab distribution is already solved > by ipa-client-install. > > Alternative for clients would be to use FreeIPA server as proxy which > encapsulates TSIG keys and issues update requests on behalf of clients. This > would be FreeIPA-specific but any TSIG-distribution mechanism will be > FreeIPA-specific anyway. > > TSIG standard explicitly says that there is no standardized distribution > mechanism. > >>> In other words, the question is if current "dns.py" plugin shipped >>> with FreeIPA framework should be: >>> >>> a) Extended dns.py with dnsexternal-* commands >>> ---------------------------------------------- >>> Disadvantages: >>> - It complicate FreeIPA DNS interface which is a complex beast even >>> now. >>> - We would have add condition to every DNS API call in installers >>> which would increase horribleness of the installer code even more (or >>> add another layer of abstraction...). >> >> I agree having a special command is undesirable. >>> >>> - I don't see a point in using integrated-DNS with external-DNS at >>> the same time. To use integrated-DNS you have to get a proper DNS >>> delegation from parent domain - and if you can get the delegation >>> then there is no point in using external DNS ... >> >> I disagree on this point, it makes a lot of sense to have some zones >> maintained by IPA and ... some not. >> >>> Advantages: >>> - You can use external & integrated DNS at the same time. >> >> We can achieve the same w/o a new ipa level command. > > This needs to be decided by FreeIPA framework experts ... > > Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would > provide all ipa dns* commands and dispatch user-issued commands to appropriate > FreeIPA-plugin (internal-dns or external-dns). This decision could depend on > some values in LDAP. > >>> b) Replace dns.py with another implementation of current dnszone-* & >>> dnsrecord-* API. >>> --------------------------------------------------------------------- >>> This seems like a cleaner approach to me. It could be shipped as >>> ipa-server-dns-external package (opposed to "standard" ipa-server-dns >>> package). >>> >>> Advantages: >>> - It could seamlessly work with FreeIPA client installer because the >>> dns*->nsupdate command transformation would be done on FreeIPA server >>> and client doesn't need to know about it. >>> - Does not require re-training/not much new documentation because >>> commands are the same. >>> >>> Disadvantages: >>> - You can't use integrated & external DNS at the same time (but I >>> don't think it justifies the added complexity). >> >> I disagree. >> >> One of the reason to use a mix is to allow smooth migrations where >> zones are moved into (or out of) IPA one by one. > > Good point, I agree. I will focus on supporting both (internal and external) > DNS at the same time. > >>> Petr^3 or anyone else, what do you propose? >> >> I think what I'd like to see is to be able to configure a DNS zone in >> LDAP and mark it external. >> The zone would held the TSIG keys necessary to perform DNS updates. >> >> When the regular ipa dnsrecord-add etc... commands are called, the >> framework detects that the zone is "external", fewttches the TSIG key >> (if the user has access to it) and spawn an nsupdate command that will >> perform the update against whatever DNS server is authoritative for the >> zone. >> >> Some commands may be disabled if the zone is external and appropriate >> errors would be returned. > > Correct, this will be inevitable. > >>> 2) Authentication to external DNS server/keys >>> ============================================= >>> This is separate problem from FreeIPA framework integration. >>> We will have to somehow store raw symmetric keys (for DNS TSIG) or >>> keytabs (for DNS GSS-TSIG) and distribute them somehow to replicas so >>> every replica can update DNS records as necessary. >> >> For TSIG keys I think we should just store them in a LDAP record, see >> above. > > Without any encryption? Am I missing something? > >> For keytabs we can simply store them just like any other kerberos key >> if we really need it (in a trust case for example, we may not need a >> new keytab, we may be allowed to use our own credentials through the >> trust. So we'll need to explore a bit how to properly express that in >> configuration. REtrieval ok keytabs is then just a matter of running >> ipa-getkeytab -r on the replica that needs it. >> >>> This will be the funny part because in case of AD trusts we have >>> chicken-egg problem. You need to establish trust to get ticket for >>> DNS/dc1.ad.example at AD principal but you can't (I guess) establish >>> trust until proper DNS records are in place ... >> >> No, in this case we should create the records at trust establishment >> time using the admin credentials we have been provided. NO chicken-egg >> issue. > > Sorry, we surely *have* a chicken-egg issue because ipa-server-install is > completely separate step from from ipa-adtrust-install which is completely > separate from ipa trust-add. (And there is nothing which forces user to > establish AD trust right after ipa-server-install finished.) > > Also, in some cases it is not possible to use the same credentials for > trust establishment and for DNS updates on AD. Think about one-way trust or > possibly two-way trust but established using pre-shared trust secret (which is > AFAIK not usable for kinit). > > Alexander, could you clarify if it is possible to create an AD trust *without* > DNS records for FreeIPA side of the trust? > > Another problem is that reliance on AD trusts would effectively prevent > interoperability with non-AD DNS servers (think Infoblox or standard BIND). > > I tend to think that we will need to obtain credentials (AD > login/pass/keytab/TSIG key) as one of ipa-server-install parameters so all DNS > updates can be done right away. This would allow us have ipa-server-install > script which in fact produces *working* FreeIPA domain. In other cases > ipa-server-install would end but the FreeIPA domain would not be functional > because of missing records in DNS. > >>> For 'experimental' phase I would go with pre-populated CCcache, i.e. >>> admin will manually do kinit Administrator at AD and then run FreeIPA >>> installer. >> >> We already to this, so there is no need to invent anything here IMO. > > Except for cases mentioned above ... > >>> Maybe we can re-use trust secret somehow? I don't know, I will reach >>> out to AD experts with questions. >>> >>> This area needs more research but for now it seems feasible to re-use >>> DNSSEC key distribution system for TSIG keys and keytabs so "only" >>> the chicken-egg problem is left. >>> >>> This will need new LDAP schema but I will propose something when I'm >>> done with investigation. >> >> Please let me know if you agree with a new zone type as a way to >> "forward" updates. > > Generally I agree, it was my plan too. My main concern is not about LDAP > structure but about FreeIPA framework and about workflow in general. It will > be fun to extend the spaghetti code we have ... Ping :-) I would like to move the discussion forward. Alexander, could you please comment on authentication to AD mentioned above? Simo and everybody else, what do you think about client use-case, i.e. forwarding DNS updates from FreeIPA clients to external DNS infrastructure? What about security implications (keeping in mind that TSIG keys are symmetric)? Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy instead of nsupdate command (to hide TSIG key behind FreeIPA)? Ideas? -- Petr^2 Spacek From redhatrises at gmail.com Mon Dec 1 15:23:05 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 1 Dec 2014 09:23:05 -0600 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <547C599C.6040202@redhat.com> References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> Message-ID: On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek wrote: > On 11/30/2014 03:28 AM, Gabe Alford wrote: > > Ignore the last patch. Updated patch attached. > > > > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford > wrote: > > > >> This patch removes the app_PYTHON usage. > >> > >> Thanks, > >> > >> Gabe > >> > >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek > wrote: > >> > >>> Exactly, this was the message from Martin :-) I did not test it myself, > >>> but > >>> removing all app_PYTHON should be benign given we use Python setup.py > >>> packaging. > >>> > >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: > >>>> Thanks guys. Sounds like it would be better to submit a patch that > >>> removes > >>>> app_PYTHON if it is considered dead code. > >>>> > >>>> Gabe > >>>> > >>>> On Thursday, November 27, 2014, Petr Spacek > wrote: > >>>> > >>>>> On 27.11.2014 11:00, Martin Basti wrote: > >>>>>> On 27/11/14 00:50, Gabe Alford wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> Wondering if I could get a review. Updated patch attached. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Gabe > >>>>>>> > >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford < > redhatrises at gmail.com > >>>>> > >>>>>>> >> wrote: > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Gabe > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> sorry for late response. > >>>>>> > >>>>>> We push this ticket to backlog, as it would be part of build system > >>>>> refactoring. > >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the better > >>>>> solution is > >>>>>> remove it, instead of keeping dead code up-to-date. > >>>>> > >>>>> Just to clarify: > >>>>> It can be pushed if it works, there is no need to postpone accepting > >>> patch > >>>>> if > >>>>> the patch seems okay and doesn't break anything. > >>>>> > >>>>> Martin, please keep in mind that contributions are welcome at any > time. > >>>>> > >>>>> Milestones in Trac reflect our view of priorities but it doesn't > >>> prevent us > >>>>> from accepting correct patches from contributions at any time, no > >>> matter > >>>>> which > >>>>> priority is stated in Trac (or even if there is no ticket for it > ...). > >>>>> > >>>>> -- > >>>>> Petr^2 Spacek > > Worked in my tests, I did not see any breakage. I guess we can also remove > the > ipa-client/ipaclient/Makefile.am while we are at it. > > Martin > It looks like the ipaclient/Makefile.am is still being used. I tried removing it and there were errors in the build, but maybe I am wrong? Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Dec 1 15:25:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Dec 2014 10:25:30 -0500 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> Message-ID: <547C886A.4080205@redhat.com> Gabe Alford wrote: > > On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek > wrote: > > On 11/30/2014 03:28 AM, Gabe Alford wrote: > > Ignore the last patch. Updated patch attached. > > > > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford > > wrote: > > > >> This patch removes the app_PYTHON usage. > >> > >> Thanks, > >> > >> Gabe > >> > >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek > wrote: > >> > >>> Exactly, this was the message from Martin :-) I did not test it > myself, > >>> but > >>> removing all app_PYTHON should be benign given we use Python > setup.py > >>> packaging. > >>> > >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: > >>>> Thanks guys. Sounds like it would be better to submit a patch that > >>> removes > >>>> app_PYTHON if it is considered dead code. > >>>> > >>>> Gabe > >>>> > >>>> On Thursday, November 27, 2014, Petr Spacek > wrote: > >>>> > >>>>> On 27.11.2014 11:00, Martin Basti wrote: > >>>>>> On 27/11/14 00:50, Gabe Alford wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> Wondering if I could get a review. Updated patch > attached. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Gabe > >>>>>>> > >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > > >>>>> > >>>>>>> > >> wrote: > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Gabe > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> sorry for late response. > >>>>>> > >>>>>> We push this ticket to backlog, as it would be part of build > system > >>>>> refactoring. > >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the better > >>>>> solution is > >>>>>> remove it, instead of keeping dead code up-to-date. > >>>>> > >>>>> Just to clarify: > >>>>> It can be pushed if it works, there is no need to postpone > accepting > >>> patch > >>>>> if > >>>>> the patch seems okay and doesn't break anything. > >>>>> > >>>>> Martin, please keep in mind that contributions are welcome at > any time. > >>>>> > >>>>> Milestones in Trac reflect our view of priorities but it doesn't > >>> prevent us > >>>>> from accepting correct patches from contributions at any time, no > >>> matter > >>>>> which > >>>>> priority is stated in Trac (or even if there is no ticket for > it ...). > >>>>> > >>>>> -- > >>>>> Petr^2 Spacek > > Worked in my tests, I did not see any breakage. I guess we can also > remove the > ipa-client/ipaclient/Makefile.am while we are at it. > > Martin > > > It looks like the ipaclient/Makefile.am is still being used. I tried > removing it and there were errors in the build, but maybe I am wrong? It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. Feel free to rip out the outdated hg ChangeLog stuff though. rob From mkosek at redhat.com Mon Dec 1 15:28:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 01 Dec 2014 16:28:59 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <547C886A.4080205@redhat.com> References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> Message-ID: <547C893B.1000008@redhat.com> On 12/01/2014 04:25 PM, Rob Crittenden wrote: > Gabe Alford wrote: >> >> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek > > wrote: >> >> On 11/30/2014 03:28 AM, Gabe Alford wrote: >> > Ignore the last patch. Updated patch attached. >> > >> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford >> > wrote: >> > >> >> This patch removes the app_PYTHON usage. >> >> >> >> Thanks, >> >> >> >> Gabe >> >> >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek > > wrote: >> >> >> >>> Exactly, this was the message from Martin :-) I did not test it >> myself, >> >>> but >> >>> removing all app_PYTHON should be benign given we use Python >> setup.py >> >>> packaging. >> >>> >> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: >> >>>> Thanks guys. Sounds like it would be better to submit a patch that >> >>> removes >> >>>> app_PYTHON if it is considered dead code. >> >>>> >> >>>> Gabe >> >>>> >> >>>> On Thursday, November 27, 2014, Petr Spacek > > wrote: >> >>>> >> >>>>> On 27.11.2014 11:00, Martin Basti wrote: >> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: >> >>>>>>> Hello, >> >>>>>>> >> >>>>>>> Wondering if I could get a review. Updated patch >> attached. >> >>>>>>> >> >>>>>>> Thanks, >> >>>>>>> Gabe >> >>>>>>> >> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >> >> >>>>> >> >>>>>>> >> >> wrote: >> >>>>>>> >> >>>>>>> Hello, >> >>>>>>> >> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >> >>>>>>> >> >>>>>>> Thanks, >> >>>>>>> >> >>>>>>> Gabe >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> Hello, >> >>>>>> >> >>>>>> sorry for late response. >> >>>>>> >> >>>>>> We push this ticket to backlog, as it would be part of build >> system >> >>>>> refactoring. >> >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the better >> >>>>> solution is >> >>>>>> remove it, instead of keeping dead code up-to-date. >> >>>>> >> >>>>> Just to clarify: >> >>>>> It can be pushed if it works, there is no need to postpone >> accepting >> >>> patch >> >>>>> if >> >>>>> the patch seems okay and doesn't break anything. >> >>>>> >> >>>>> Martin, please keep in mind that contributions are welcome at >> any time. >> >>>>> >> >>>>> Milestones in Trac reflect our view of priorities but it doesn't >> >>> prevent us >> >>>>> from accepting correct patches from contributions at any time, no >> >>> matter >> >>>>> which >> >>>>> priority is stated in Trac (or even if there is no ticket for >> it ...). >> >>>>> >> >>>>> -- >> >>>>> Petr^2 Spacek >> >> Worked in my tests, I did not see any breakage. I guess we can also >> remove the >> ipa-client/ipaclient/Makefile.am while we are at it. >> >> Martin >> >> >> It looks like the ipaclient/Makefile.am is still being used. I tried >> removing it and there were errors in the build, but maybe I am wrong? > > It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. > > Feel free to rip out the outdated hg ChangeLog stuff though. > > rob I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not about ipa-client/Makefile.am - we still need this one as Rob correctly said. The failure that Gabe hit in build probably comes from the the SUBDIR reference in ipa-client/Makefile.am file. I assume that if the reference is removed, the removal should work. And yes, you can remove the Changelog too if you are OK with it :) Martin From mbasti at redhat.com Mon Dec 1 15:48:13 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 01 Dec 2014 16:48:13 +0100 Subject: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade In-Reply-To: <547C1CE8.5000707@redhat.com> References: <54772621.5050003@redhat.com> <547C1CE8.5000707@redhat.com> Message-ID: <547C8DBD.2020204@redhat.com> On 01/12/14 08:46, Jan Cholasta wrote: > Hi, > > Dne 27.11.2014 v 14:24 Martin Basti napsal(a): >> Ticket: https://fedorahosted.org/freeipa/ticket/4676 >> Replaces current workaround. Should go to 4.1.3. >> Patch attached. > > When constructing URLs with host:port, please use > ipautil.format_netloc(). > > wget should be added as a dependency of freeipa-python in the spec file. > > Honza > Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0168.2-Using-wget-to-get-status-of-CA.patch Type: text/x-patch Size: 4792 bytes Desc: not available URL: From simo at redhat.com Mon Dec 1 16:12:33 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 1 Dec 2014 11:12:33 -0500 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <547C86A2.5010508@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> Message-ID: <20141201111233.5a44b40e@willson.usersys.redhat.com> On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek wrote: > On 14.11.2014 17:31, Petr Spacek wrote: > > On 14.11.2014 02:22, Simo Sorce wrote: > >> On Tue, 11 Nov 2014 16:29:51 +0100 > >> Petr Spacek wrote: > >> > >>> Hello, > >>> > >>> this thread is about RFE > >>> "IPA servers when installed should register themselves in the > >>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 > >>> > >>> It is not a complete design, just a raw idea. > >>> > >>> > >>> Use case > >>> ======== > >>> FreeIPA installation to a network with existing DNS > >>> infrastructure + network administrator who is not willing to > >>> add/maintain new DNS servers "just for FreeIPA". > >>> > >>> > >>> High-level idea > >>> =============== > >>> - Transform dns* commands from FreeIPA framework to equivalent > >>> "nsupdate" commands and send DNS updates to existing DNS servers. > >>> - Provide necessary encryption/signing keys to nsupdate. > >>> > >>> > >>> 1) Integration to FreeIPA framework > >>> =================================== > >>> First of all, we need to decide if "external DNS integration" can > >>> be used at the same time with FreeIPA-integrated DNS or not. > >>> Side-question is what to do if a first server is installed with > >>> external-DNS but another replica is being installed with > >>> integrated-DNS and so on. > >> > >> I think being able to integrate with an external DNS is important, > >> and not just at the server level, being able to distribute TSIG > >> keys to client would be nice too, though a lot less important, > >> than getting server integration.. > > > > Using TSIG on many clients is very problematic. Keep in mind that > > TSIG is basically HMAC computed using symmetric key so: > > a) Every client would have to use the same key - this is a security > > nightmare. b) We would have to distribute and maintain many keys > > for many^2 clients, which is an administrative nightmare. > > > > For *clients* I would rather stay with GSS-TSIG which is much more > > manageable because we can use Kerberos trust and Keytab > > distribution is already solved by ipa-client-install. > > > > Alternative for clients would be to use FreeIPA server as proxy > > which encapsulates TSIG keys and issues update requests on behalf > > of clients. This would be FreeIPA-specific but any > > TSIG-distribution mechanism will be FreeIPA-specific anyway. > > > > TSIG standard explicitly says that there is no standardized > > distribution mechanism. > > > >>> In other words, the question is if current "dns.py" plugin shipped > >>> with FreeIPA framework should be: > >>> > >>> a) Extended dns.py with dnsexternal-* commands > >>> ---------------------------------------------- > >>> Disadvantages: > >>> - It complicate FreeIPA DNS interface which is a complex beast > >>> even now. > >>> - We would have add condition to every DNS API call in installers > >>> which would increase horribleness of the installer code even more > >>> (or add another layer of abstraction...). > >> > >> I agree having a special command is undesirable. > >>> > >>> - I don't see a point in using integrated-DNS with external-DNS at > >>> the same time. To use integrated-DNS you have to get a proper DNS > >>> delegation from parent domain - and if you can get the delegation > >>> then there is no point in using external DNS ... > >> > >> I disagree on this point, it makes a lot of sense to have some > >> zones maintained by IPA and ... some not. > >> > >>> Advantages: > >>> - You can use external & integrated DNS at the same time. > >> > >> We can achieve the same w/o a new ipa level command. > > > > This needs to be decided by FreeIPA framework experts ... > > > > Petr^3 came up with clever 'proxy' idea for IPA-commands. This > > proxy would provide all ipa dns* commands and dispatch user-issued > > commands to appropriate FreeIPA-plugin (internal-dns or > > external-dns). This decision could depend on some values in LDAP. > > > >>> b) Replace dns.py with another implementation of current > >>> dnszone-* & dnsrecord-* API. > >>> --------------------------------------------------------------------- > >>> This seems like a cleaner approach to me. It could be shipped as > >>> ipa-server-dns-external package (opposed to "standard" > >>> ipa-server-dns package). > >>> > >>> Advantages: > >>> - It could seamlessly work with FreeIPA client installer because > >>> the dns*->nsupdate command transformation would be done on > >>> FreeIPA server and client doesn't need to know about it. > >>> - Does not require re-training/not much new documentation because > >>> commands are the same. > >>> > >>> Disadvantages: > >>> - You can't use integrated & external DNS at the same time (but I > >>> don't think it justifies the added complexity). > >> > >> I disagree. > >> > >> One of the reason to use a mix is to allow smooth migrations where > >> zones are moved into (or out of) IPA one by one. > > > > Good point, I agree. I will focus on supporting both (internal and > > external) DNS at the same time. > > > >>> Petr^3 or anyone else, what do you propose? > >> > >> I think what I'd like to see is to be able to configure a DNS zone > >> in LDAP and mark it external. > >> The zone would held the TSIG keys necessary to perform DNS updates. > >> > >> When the regular ipa dnsrecord-add etc... commands are called, the > >> framework detects that the zone is "external", fewttches the TSIG > >> key (if the user has access to it) and spawn an nsupdate command > >> that will perform the update against whatever DNS server is > >> authoritative for the zone. > >> > >> Some commands may be disabled if the zone is external and > >> appropriate errors would be returned. > > > > Correct, this will be inevitable. > > > >>> 2) Authentication to external DNS server/keys > >>> ============================================= > >>> This is separate problem from FreeIPA framework integration. > >>> We will have to somehow store raw symmetric keys (for DNS TSIG) or > >>> keytabs (for DNS GSS-TSIG) and distribute them somehow to > >>> replicas so every replica can update DNS records as necessary. > >> > >> For TSIG keys I think we should just store them in a LDAP record, > >> see above. > > > > Without any encryption? Am I missing something? > > > >> For keytabs we can simply store them just like any other kerberos > >> key if we really need it (in a trust case for example, we may not > >> need a new keytab, we may be allowed to use our own credentials > >> through the trust. So we'll need to explore a bit how to properly > >> express that in configuration. REtrieval ok keytabs is then just a > >> matter of running ipa-getkeytab -r on the replica that needs it. > >> > >>> This will be the funny part because in case of AD trusts we have > >>> chicken-egg problem. You need to establish trust to get ticket for > >>> DNS/dc1.ad.example at AD principal but you can't (I guess) establish > >>> trust until proper DNS records are in place ... > >> > >> No, in this case we should create the records at trust > >> establishment time using the admin credentials we have been > >> provided. NO chicken-egg issue. > > > > Sorry, we surely *have* a chicken-egg issue because > > ipa-server-install is completely separate step from from > > ipa-adtrust-install which is completely separate from ipa > > trust-add. (And there is nothing which forces user to establish AD > > trust right after ipa-server-install finished.) > > > > Also, in some cases it is not possible to use the same credentials > > for trust establishment and for DNS updates on AD. Think about > > one-way trust or possibly two-way trust but established using > > pre-shared trust secret (which is AFAIK not usable for kinit). > > > > Alexander, could you clarify if it is possible to create an AD > > trust *without* DNS records for FreeIPA side of the trust? > > > > Another problem is that reliance on AD trusts would effectively > > prevent interoperability with non-AD DNS servers (think Infoblox or > > standard BIND). > > > > I tend to think that we will need to obtain credentials (AD > > login/pass/keytab/TSIG key) as one of ipa-server-install parameters > > so all DNS updates can be done right away. This would allow us have > > ipa-server-install script which in fact produces *working* FreeIPA > > domain. In other cases ipa-server-install would end but the FreeIPA > > domain would not be functional because of missing records in DNS. > > > >>> For 'experimental' phase I would go with pre-populated CCcache, > >>> i.e. admin will manually do kinit Administrator at AD and then run > >>> FreeIPA installer. > >> > >> We already to this, so there is no need to invent anything here > >> IMO. > > > > Except for cases mentioned above ... > > > >>> Maybe we can re-use trust secret somehow? I don't know, I will > >>> reach out to AD experts with questions. > >>> > >>> This area needs more research but for now it seems feasible to > >>> re-use DNSSEC key distribution system for TSIG keys and keytabs > >>> so "only" the chicken-egg problem is left. > >>> > >>> This will need new LDAP schema but I will propose something when > >>> I'm done with investigation. > >> > >> Please let me know if you agree with a new zone type as a way to > >> "forward" updates. > > > > Generally I agree, it was my plan too. My main concern is not about > > LDAP structure but about FreeIPA framework and about workflow in > > general. It will be fun to extend the spaghetti code we have ... > > Ping :-) I would like to move the discussion forward. > > Alexander, could you please comment on authentication to AD mentioned > above? > > Simo and everybody else, what do you think about client use-case, i.e. > forwarding DNS updates from FreeIPA clients to external DNS > infrastructure? What about security implications (keeping in mind > that TSIG keys are symmetric)? > > Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy > instead of nsupdate command (to hide TSIG key behind FreeIPA)? Remind me this, when a client tries to update the DNS, does it always contact its own DNS server first, or does it try to go straight to the authoritative DNS server? I do not like the XML-RPC->DNS approach as it requires a special client, leaving out the majority of clients. Also, I am thinking that we only _need_ to set infrastructure relevant names (like IPA servers SRV records), but if someone decides not to use IPA for the DNS we may decide that it is not our responsibility to provide a full end-to-end client dns update solution. So I would concentrate on making it possible for IPA *Servers* to use a private TSIG key to update infrastructure relevant names, and possibly defer the clients side of the problem. We could use an internal bus on the server to allow the ipa framework to use nsupdate w/o gaining direct access to the TSIG key, this way admins can use ipa dnsrecod-add and friends w/o exposing the key. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Dec 1 16:29:56 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 1 Dec 2014 18:29:56 +0200 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <20141201111233.5a44b40e@willson.usersys.redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> Message-ID: <20141201162956.GA16288@redhat.com> On Mon, 01 Dec 2014, Simo Sorce wrote: >On Mon, 01 Dec 2014 16:17:54 +0100 >Petr Spacek wrote: > >> On 14.11.2014 17:31, Petr Spacek wrote: >> > On 14.11.2014 02:22, Simo Sorce wrote: >> >> On Tue, 11 Nov 2014 16:29:51 +0100 >> >> Petr Spacek wrote: >> >> >> >>> Hello, >> >>> >> >>> this thread is about RFE >> >>> "IPA servers when installed should register themselves in the >> >>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >> >>> >> >>> It is not a complete design, just a raw idea. >> >>> >> >>> >> >>> Use case >> >>> ======== >> >>> FreeIPA installation to a network with existing DNS >> >>> infrastructure + network administrator who is not willing to >> >>> add/maintain new DNS servers "just for FreeIPA". >> >>> >> >>> >> >>> High-level idea >> >>> =============== >> >>> - Transform dns* commands from FreeIPA framework to equivalent >> >>> "nsupdate" commands and send DNS updates to existing DNS servers. >> >>> - Provide necessary encryption/signing keys to nsupdate. >> >>> >> >>> >> >>> 1) Integration to FreeIPA framework >> >>> =================================== >> >>> First of all, we need to decide if "external DNS integration" can >> >>> be used at the same time with FreeIPA-integrated DNS or not. >> >>> Side-question is what to do if a first server is installed with >> >>> external-DNS but another replica is being installed with >> >>> integrated-DNS and so on. >> >> >> >> I think being able to integrate with an external DNS is important, >> >> and not just at the server level, being able to distribute TSIG >> >> keys to client would be nice too, though a lot less important, >> >> than getting server integration.. >> > >> > Using TSIG on many clients is very problematic. Keep in mind that >> > TSIG is basically HMAC computed using symmetric key so: >> > a) Every client would have to use the same key - this is a security >> > nightmare. b) We would have to distribute and maintain many keys >> > for many^2 clients, which is an administrative nightmare. >> > >> > For *clients* I would rather stay with GSS-TSIG which is much more >> > manageable because we can use Kerberos trust and Keytab >> > distribution is already solved by ipa-client-install. >> > >> > Alternative for clients would be to use FreeIPA server as proxy >> > which encapsulates TSIG keys and issues update requests on behalf >> > of clients. This would be FreeIPA-specific but any >> > TSIG-distribution mechanism will be FreeIPA-specific anyway. >> > >> > TSIG standard explicitly says that there is no standardized >> > distribution mechanism. >> > >> >>> In other words, the question is if current "dns.py" plugin shipped >> >>> with FreeIPA framework should be: >> >>> >> >>> a) Extended dns.py with dnsexternal-* commands >> >>> ---------------------------------------------- >> >>> Disadvantages: >> >>> - It complicate FreeIPA DNS interface which is a complex beast >> >>> even now. >> >>> - We would have add condition to every DNS API call in installers >> >>> which would increase horribleness of the installer code even more >> >>> (or add another layer of abstraction...). >> >> >> >> I agree having a special command is undesirable. >> >>> >> >>> - I don't see a point in using integrated-DNS with external-DNS at >> >>> the same time. To use integrated-DNS you have to get a proper DNS >> >>> delegation from parent domain - and if you can get the delegation >> >>> then there is no point in using external DNS ... >> >> >> >> I disagree on this point, it makes a lot of sense to have some >> >> zones maintained by IPA and ... some not. >> >> >> >>> Advantages: >> >>> - You can use external & integrated DNS at the same time. >> >> >> >> We can achieve the same w/o a new ipa level command. >> > >> > This needs to be decided by FreeIPA framework experts ... >> > >> > Petr^3 came up with clever 'proxy' idea for IPA-commands. This >> > proxy would provide all ipa dns* commands and dispatch user-issued >> > commands to appropriate FreeIPA-plugin (internal-dns or >> > external-dns). This decision could depend on some values in LDAP. >> > >> >>> b) Replace dns.py with another implementation of current >> >>> dnszone-* & dnsrecord-* API. >> >>> --------------------------------------------------------------------- >> >>> This seems like a cleaner approach to me. It could be shipped as >> >>> ipa-server-dns-external package (opposed to "standard" >> >>> ipa-server-dns package). >> >>> >> >>> Advantages: >> >>> - It could seamlessly work with FreeIPA client installer because >> >>> the dns*->nsupdate command transformation would be done on >> >>> FreeIPA server and client doesn't need to know about it. >> >>> - Does not require re-training/not much new documentation because >> >>> commands are the same. >> >>> >> >>> Disadvantages: >> >>> - You can't use integrated & external DNS at the same time (but I >> >>> don't think it justifies the added complexity). >> >> >> >> I disagree. >> >> >> >> One of the reason to use a mix is to allow smooth migrations where >> >> zones are moved into (or out of) IPA one by one. >> > >> > Good point, I agree. I will focus on supporting both (internal and >> > external) DNS at the same time. >> > >> >>> Petr^3 or anyone else, what do you propose? >> >> >> >> I think what I'd like to see is to be able to configure a DNS zone >> >> in LDAP and mark it external. >> >> The zone would held the TSIG keys necessary to perform DNS updates. >> >> >> >> When the regular ipa dnsrecord-add etc... commands are called, the >> >> framework detects that the zone is "external", fewttches the TSIG >> >> key (if the user has access to it) and spawn an nsupdate command >> >> that will perform the update against whatever DNS server is >> >> authoritative for the zone. >> >> >> >> Some commands may be disabled if the zone is external and >> >> appropriate errors would be returned. >> > >> > Correct, this will be inevitable. >> > >> >>> 2) Authentication to external DNS server/keys >> >>> ============================================= >> >>> This is separate problem from FreeIPA framework integration. >> >>> We will have to somehow store raw symmetric keys (for DNS TSIG) or >> >>> keytabs (for DNS GSS-TSIG) and distribute them somehow to >> >>> replicas so every replica can update DNS records as necessary. >> >> >> >> For TSIG keys I think we should just store them in a LDAP record, >> >> see above. >> > >> > Without any encryption? Am I missing something? >> > >> >> For keytabs we can simply store them just like any other kerberos >> >> key if we really need it (in a trust case for example, we may not >> >> need a new keytab, we may be allowed to use our own credentials >> >> through the trust. So we'll need to explore a bit how to properly >> >> express that in configuration. REtrieval ok keytabs is then just a >> >> matter of running ipa-getkeytab -r on the replica that needs it. >> >> >> >>> This will be the funny part because in case of AD trusts we have >> >>> chicken-egg problem. You need to establish trust to get ticket for >> >>> DNS/dc1.ad.example at AD principal but you can't (I guess) establish >> >>> trust until proper DNS records are in place ... >> >> >> >> No, in this case we should create the records at trust >> >> establishment time using the admin credentials we have been >> >> provided. NO chicken-egg issue. >> > >> > Sorry, we surely *have* a chicken-egg issue because >> > ipa-server-install is completely separate step from from >> > ipa-adtrust-install which is completely separate from ipa >> > trust-add. (And there is nothing which forces user to establish AD >> > trust right after ipa-server-install finished.) >> > >> > Also, in some cases it is not possible to use the same credentials >> > for trust establishment and for DNS updates on AD. Think about >> > one-way trust or possibly two-way trust but established using >> > pre-shared trust secret (which is AFAIK not usable for kinit). >> > >> > Alexander, could you clarify if it is possible to create an AD >> > trust *without* DNS records for FreeIPA side of the trust? Trust is not possible to establish without proper DNS records in place. At least, verification step will fail because for it to be successful, AD DC must contact IPA domain controllers which it searches via SRV records -- we can't influence that. Additionally, there are no AD admin credentials available when we create DNS records in ipa-adtrust-install because it is an operation done by IPA admin. At this stage we don't really need these DNS records for IPA side yet. When IPA - AD trust is established with 'ipa trust-add' in one use case we have both IPA admin and AD forest root domain's admin credentials, thus we theoretically can create DNS records in AD as part of the process, essentially making it two-step: 1. Discover IPA DCs via SRV records and if that fails, propose AD admin to create the records -- either via confirmation or by providing a separate command (e.g. 'ipa trust-init-dnsconfig'). 2. Establish trust to AD and verify it. It will not be working for the case we are creating a trust with a shared secret because we'd have no AD admin credentials at all. -- / Alexander Bokovoy From pspacek at redhat.com Mon Dec 1 16:44:53 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 01 Dec 2014 17:44:53 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <547C6F96.1060106@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> Message-ID: <547C9B05.5010904@redhat.com> On 1.12.2014 14:39, Martin Basti wrote: > On 24/11/14 17:24, Petr Spacek wrote: >> Hello! >> >> Thank you for the patch. It is not ready yet but the overall direction seems >> good. Please see my comments in-line. >> >> On 24.11.2014 14:35, Martin Basti wrote: >>> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >>> Patch attached >>> >>> -- >>> Martin Basti >>> >>> >>> freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch >>> >>> >>> From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Fri, 21 Nov 2014 16:54:09 +0100 >>> Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration >>> >>> Shows warning if forward and parent authoritative zone do not have >>> proper NS record delegation, which can cause the forward zone will be >>> ineffective and forwarding will not work. >>> >>> The chande in the test was required due python changes order of elemnts >>> in dict (python doesnt guarantee an order in dict) >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >>> --- >>> ipalib/messages.py | 12 +++ >>> ipalib/plugins/dns.py | 147 >>> +++++++++++++++++++++++++++++--- >>> ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- >>> 3 files changed, 149 insertions(+), 12 deletions(-) >>> >>> diff --git a/ipalib/messages.py b/ipalib/messages.py >>> index >>> 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f >>> 100644 >>> --- a/ipalib/messages.py >>> +++ b/ipalib/messages.py >>> @@ -200,6 +200,18 @@ class >>> DNSServerDoesNotSupportDNSSECWarning(PublicMessage): >>> u"If DNSSEC validation is enabled on IPA server(s), " >>> u"please disable it.") >>> +class ForwardzoneIsNotEffectiveWarning(PublicMessage): >>> + """ >>> + **13008** Forwardzone is not effective, forwarding will not work because >>> + there is authoritative parent zone, without proper NS delegation >>> + """ >>> + >>> + errno = 13008 >>> + type = "warning" >>> + format = _(u"forward zone \"%(fwzone)s\" is not effective (missing >>> proper " >>> + u"NS delegation in authoritative zone \"%(authzone)s\"). " >>> + u"Forwarding may not work.") >> I think that the error message could be made mode useful: >> >> "Forwarding will not work. Please add NS record >> to parent zone %(authzone)s" (or something like that). >> >>> + >>> def iter_messages(variables, base): >>> """Return a tuple with all subclasses >>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>> index >>> c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 >>> 100644 >>> --- a/ipalib/plugins/dns.py >>> +++ b/ipalib/plugins/dns.py >>> @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): >>> return zone >>> +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): >> Generally, this method finds an authoritative zone for given "fwzonename". >> What about method name _find_auth_zone_ldap(name) ? >> >>> + """ >>> + Check if forward zone is effective. >>> + >>> + If parent zone exists as authoritative zone, forward zone will not >>> + forward queries. It is necessary to delegate authority of forward zone >> I would clarify it: "forward queries by default." >> >> >>> + to another server (non IPA DNS server). >> I would personally omit "(non IPA DNS server)" because this mechanism is not >> related to IPA domain at all. >> >>> + Example: >>> + >>> + Forward zone: sub.example.com >>> + Zone: example.com >>> + >>> + Forwarding will not work, because server thinks it is authoritative >>> + and returns NXDOMAIN >>> + >>> + Adding record: sub.example.com NS nameserver.out.of.ipa.domain. >> Again, this is not related to IPA domain at all. I propose this text: >> "Adding record: sub.example.com NS ns.sub.example.com." >> >>> + will delegate authority to another server, and IPA DNS server will >>> + forward DNS queries. >>> + >>> + :param fwzonename: forwardzone >>> + :return: None if effective, name of authoritative zone otherwise >>> + """ >>> + assert isinstance(fwzonename, DNSName) >>> + >>> + # get all zones >>> + zones = api.Command.dnszone_find(pkey_only=True, >>> + sizelimit=0)['result'] >> Ooooh, are you serious? :-) I don't like this approach, I would rather chop >> left-most labels from "name" and so dnszone_find() one by one. What if you >> have many DNS zones? >> >> >> This could be thrown away if you iterate only over relevant zones. >>> + zonenames = [zone['idnsname'][0].make_absolute() for zone in zones] >>> + zonenames.sort(reverse=True, key=len) # sort, we need longest match >>> + >>> + # check if is there a zone which can cause the forward zone will >>> + # be ineffective >>> + sub_of_auth_zone = None >>> + for name in zonenames: >>> + if fwzonename.is_subdomain(name): >>> + sub_of_auth_zone = name >>> + break >>> + >>> + if sub_of_auth_zone is None: >>> + return None >>> + >>> + # check if forwardzone is delegated in authoritative zone >>> + # test if exists and get NS record >>> + try: >>> + ns_records = api.Command.dnsrecord_show( >>> + sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord'] >>> + except (errors.NotFound, KeyError): >>> + return sub_of_auth_zone >> Note: This function should process only deepest (existing) sub-domain in LDAP >> which is active (idnsZoneActive = TRUE). >> >> Example: >> fwzonename = sub.fwd.example.com. >> Existing LDAP master zone = fwd.example.com. - DISABLED >> Existing LDAP master zone = example.com. >> Existing LDAP master zone = com. >> >> 1) Check existence & activity of fwd.example.com. -> does not exist, continue. >> 2) Check existence & activity of example.com. -> exists, search for NS records. >> 3) [inner loop - searching for NS records] >> 3a) sub.fwd.example.com. NS -> does not exist, continue inner loop. >> 3b) fwd.example.com. NS -> does not exist, continue inner loop. >> 3c) Inner loop ends: no more (relative) candidate names to try. >> 4) Exit returning "example.com." - deepest authoritative super-domain of >> sub.fwd.example.com. in LDAP. >> >> AFAIK content of the NS record does not matter so this check can be thrown >> away. (Check this before doing so, please :-)) >> >>> + # make sure the target is not IPA DNS server >>> + # FIXME: what if aliases are used? >>> + normalized_ns_records = set() >>> + for record in ns_records: >>> + if record.endswith('.'): >>> + normalized_ns_records.add(record) >>> + else: >>> + normalized_record = "%s.%s" % (record, sub_of_auth_zone) >>> + normalized_ns_records.add(normalized_record) >>> + >>> + nameservers = [normalize_zone(x) for x in >>> + api.Object.dnsrecord.get_dns_masters()] >>> + >>> + if any(nameserver in normalized_ns_records >>> + for nameserver in nameservers): >>> + # NS record is pointing to IPA DNS server >>> + return sub_of_auth_zone >>> + >>> + # authoritative zone contains NS records which delegates forwardzone to >>> + # different server, forwardzone is effective >>> + return None >>> + >>> + >>> class DNSZoneBase(LDAPObject): >>> """ >>> Base class for DNS Zone >>> @@ -3164,6 +3237,29 @@ class dnsrecord(LDAPObject): >>> dns_name = entry_name[1].derelativize(dns_domain) >>> self.wait_for_modified_attrs(entry, dns_name, dns_domain) >>> + def warning_if_ns_change_cause_fwzone_ineffective(self, keys, result, >>> + options): >>> + """after execute""" >>> + record_name_absolute = keys[-1] >>> + if not keys[-1].is_absolute(): >>> + record_name_absolute = keys[-1].derelativize(keys[-2]) >>> + >>> + try: >>> + api.Command.dnsforwardzone_show(record_name_absolute) >>> + except errors.NotFound: >>> + # no forward zone >>> + return >>> + >>> + authoritative_zone = \ >>> + _find_zone_which_makes_fw_zone_ineffective(record_name_absolute) >>> + if authoritative_zone: >>> + # forward zone is not effective and forwarding will not work >>> + messages.add_message( >>> + options['version'], result, >>> + messages.ForwardzoneIsNotEffectiveWarning( >>> + fwzone=record_name_absolute, authzone=authoritative_zone >>> + ) >>> + ) >>> @register() >>> @@ -3358,6 +3454,14 @@ class dnsrecord_add(LDAPCreate): >>> return >>> raise exc >>> + def execute(self, *keys, **options): >>> + result = super(dnsrecord_add, self).execute(*keys, **options) >>> + if 'nsrecord' in options: >>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>> + result, >>> + options) >>> + return result >>> + >>> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >>> assert isinstance(dn, DN) >>> for attr in getattr(context, 'dnsrecord_precallback_attrs', []): >>> @@ -3487,7 +3591,10 @@ class dnsrecord_mod(LDAPUpdate): >>> if self.api.env['wait_for_dns']: >>> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>> - >>> + if 'nsrecord' in options: >>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>> + result, >>> + options) >>> return result >>> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >>> @@ -3654,19 +3761,23 @@ class dnsrecord_del(LDAPUpdate): >>> if self.api.env['wait_for_dns']: >>> entries = {(keys[0], keys[1]): None} >>> self.obj.wait_for_modified_entries(entries) >>> - return result >>> + else: >>> + result = super(dnsrecord_del, self).execute(*keys, **options) >>> + result['value'] = pkey_to_value([keys[-1]], options) >>> - result = super(dnsrecord_del, self).execute(*keys, **options) >>> - result['value'] = pkey_to_value([keys[-1]], options) >>> + if getattr(context, 'del_all', False) and not \ >>> + self.obj.is_pkey_zone_record(*keys): >>> + result = self.obj.methods.delentry(*keys, >>> + >>> version=options['version']) >>> + context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >>> - if getattr(context, 'del_all', False) and not \ >>> - self.obj.is_pkey_zone_record(*keys): >>> - result = self.obj.methods.delentry(*keys, >>> - version=options['version']) >>> - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >>> + if self.api.env['wait_for_dns']: >>> + >>> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>> - if self.api.env['wait_for_dns']: >>> - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>> + if 'nsrecord' in options or options.get('del_all', False): >>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>> + result, >>> + options) >>> return result >>> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >>> @@ -4019,6 +4130,20 @@ class dnsforwardzone_add(DNSZoneBase_add): >>> return dn >>> + def execute(self, *keys, **options): >>> + result = super(dnsforwardzone_add, self).execute(*keys, **options) >>> + authoritative_zone = >>> _find_zone_which_makes_fw_zone_ineffective(keys[-1]) >>> + if authoritative_zone: >>> + # forward zone is not effective and forwarding will not work >>> + messages.add_message( >>> + options['version'], result, >>> + messages.ForwardzoneIsNotEffectiveWarning( >>> + fwzone=keys[-1], authzone=authoritative_zone >>> + ) >>> + ) >>> + >>> + return result >>> + >>> @register() >>> class dnsforwardzone_del(DNSZoneBase_del): >>> diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py >>> b/ipatests/test_xmlrpc/test_dns_plugin.py >>> index >>> fb53853147ecf663cf7015867131445f32364cfb..224a80d98273480f40fd78dea0f27e34ea36492f >>> 100644 >>> --- a/ipatests/test_xmlrpc/test_dns_plugin.py >>> +++ b/ipatests/test_xmlrpc/test_dns_plugin.py >>> @@ -1060,7 +1060,7 @@ class test_dns(Declarative): >>> >>> 'srv_part_target' : u'foo.bar.', >>> >>> 'srvrecord': [u"1 100 1234 %s" \ >>> % >>> zone1_ns]}), >>> - expected=errors.ValidationError(name='srv_target', >>> + expected=errors.ValidationError(name='srv_weight', >>> error=u'Raw value of a DNS record was already set by ' + >>> u'"srv_rec" option'), >>> ), >>> -- 1.8.3.1 >> The same check should be done also on zone de/activation. >> > Updated patch attached. > > -- > Martin Basti > > > freeipa-mbasti-0170.2-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch Hello, first of all - the code looks reasonable, I have only couple nitpicks. See below. > From 2a5cf557840e8f578444039326ad90c76bdfb75a Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Fri, 21 Nov 2014 16:54:09 +0100 > Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration > > Shows warning if forward and parent authoritative zone do not have > proper NS record delegation, which can cause the forward zone will be > ineffective and forwarding will not work. > > Ticket: https://fedorahosted.org/freeipa/ticket/4721 > --- > ipalib/messages.py | 13 ++ > ipalib/plugins/dns.py | 334 ++++++++++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 336 insertions(+), 11 deletions(-) > > diff --git a/ipalib/messages.py b/ipalib/messages.py > index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..b44beca729f5483a7241e4c98a9f724ed663e70f 100644 > --- a/ipalib/messages.py > +++ b/ipalib/messages.py > @@ -200,6 +200,19 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): > u"If DNSSEC validation is enabled on IPA server(s), " > u"please disable it.") > > +class ForwardzoneIsNotEffectiveWarning(PublicMessage): > + """ > + **13008** Forwardzone is not effective, forwarding will not work because > + there is authoritative parent zone, without proper NS delegation > + """ > + > + errno = 13008 > + type = "warning" > + format = _(u"forward zone \"%(fwzone)s\" is not effective because of " > + u"missing proper NS delegation in authoritative zone " > + u"\"%(authzone)s\". Please add NS record " > + u"\"%(ns_rec)s\" to parent zone \"%(authzone)s\".") > + > > def iter_messages(variables, base): > """Return a tuple with all subclasses > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..b381dcc5e42761bb6d8d7ec35ef403c6e9b4d629 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -1725,6 +1725,222 @@ def _normalize_zone(zone): > return zone > > > +def _get_auth_zone_ldap(name): > + """ > + Find authoritative zone in LDAP for name > + :param name: > + :return: > + """ > + assert isinstance(name, DNSName) > + ldap = api.Backend.ldap2 > + > + # Create all possible parent zone names > + labels = name.make_absolute().ToASCII().split('.') Please use python-dns interface and do not work with domain names as with strings. > + zone_names = ['.', ] # always add root zone > + # decrease len by 1, we already have root zone > + for i in xrange(len(labels) - 1): > + zone_name_abs = '.'.join(labels[i:]) > + zone_names.append(zone_name_abs) > + # compatibility with IPA < 4.0, zone name can be relative > + zone_names.append(zone_name_abs[:-1]) > + > + # Create filters > + objectclass_filter = ldap.make_filter({'objectclass':'idnszone'}) > + zonenames_filter = ldap.make_filter({'idnsname': zone_names}) > + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) > + complete_filter = ldap.combine_filters( > + [objectclass_filter, zonenames_filter, zoneactive_filter], > + rules=ldap.MATCH_ALL > + ) > + > + try: > + entries, truncated = ldap.find_entries( > + filter=complete_filter, > + attrs_list=['idnsname'], > + base_dn=DN(api.env.container_dns, api.env.basedn), > + scope=ldap.SCOPE_ONELEVEL > + ) What about truncated return value? It would be better to throw a exception and optionally catch it in _warning* functions if you don't want throw fatal errors from warning-generator. > + except errors.NotFound: > + return None > + > + # always use absolute zones > + matched_auth_zones = [entry.single_value['idnsname'].make_absolute() > + for entry in entries] > + > + # return longest match > + return max(matched_auth_zones, key=len) > + > + > +def _get_longest_match_ns_delegation_ldap(zone, name): > + """ > + Finds record in LDAP which has the longest match with name. > + > + NOTE: does not search in zone apex, returns None if there is no NS > + delegation outside of zone apex > + > + Example: > + zone: example.com. > + name: ns.sub.example.com. > + > + records: > + extra.ns.sub.example.com. > + sub.example.com. > + example.com > + > + result: sub.example.com. > + > + :param zone: zone name > + :param name: > + :return: record name if success, or None if no such record exists, or > + record is zone apex record > + """ > + assert isinstance(zone, DNSName) > + assert isinstance(name, DNSName) > + > + ldap = api.Backend.ldap2 > + > + # get zone DN > + zone_dn = api.Object.dnszone.get_dn(zone) > + > + if name.is_absolute(): > + relative_record_name = name.relativize(zone.make_absolute()) > + else: > + relative_record_name = name > + > + # Name is zone apex > + if relative_record_name.is_empty(): > + return None > + > + relative_record_name = relative_record_name.ToASCII() Again, please do not work with DNS names as with strings. > + labels = relative_record_name.split('.') > + > + # create list of possible record names > + possible_record_names = ['.'.join(labels[i:]) for i in xrange(len(labels))] > + > + # search filters > + name_filter = ldap.make_filter({'idnsname': [possible_record_names]}) > + objectclass_filter = ldap.make_filter({'objectclass': 'idnsrecord'}) > + complete_filter = ldap.combine_filters( > + [name_filter, objectclass_filter], > + rules=ldap.MATCH_ALL > + ) > + > + try: > + entries, truncated = ldap.find_entries( > + filter=complete_filter, > + attrs_list=['idnsname', 'nsrecord'], > + base_dn=zone_dn, > + scope=ldap.SCOPE_ONELEVEL > + ) What about truncated? > + except errors.NotFound: > + return None > + > + matched_records = [] > + > + # test if entry contains NS records > + for entry in entries: > + print entry > + if entry.get('nsrecord'): > + matched_records.append(entry.single_value['idnsname']) > + > + if not matched_records: > + return None > + > + # return longest match > + return max(matched_records, key=len) > + > + > +def _find_subtree_forward_zones_ldap(name, child_zones_only=False): > + """ > + Search for forwardzone and all child forwardzones > + Filter: (|(*..)(.)) > + :param name: > + :param child_zones_only: search only for child zones > + :return: list of zonenames, or empty list if no zone was found > + """ > + assert isinstance(name, DNSName) > + ldap = api.Backend.ldap2 > + > + # prepare for filter "*.." > + search_name = u".%s" % name.make_absolute().ToASCII() > + # we need to search zone with and without last dot, due compatibility > + # with IPA < 4.0 > + search_names = [search_name, search_name[:-1]] > + > + # Create filters > + objectclass_filter = ldap.make_filter({'objectclass':'idnsforwardzone'}) > + zonenames_filter = ldap.make_filter({'idnsname': search_names}, exact=False, > + trailing_wildcard=False) > + if not child_zones_only: > + # find also zone with exact name > + exact_name = name.make_absolute().ToASCII() Again, please do not work with DNS names as with strings. > + # we need to search zone with and without last dot, due compatibility > + # with IPA < 4.0 > + exact_names = [exact_name, exact_name[-1]] > + exact_name_filter = ldap.make_filter({'idnsname': exact_names}) > + zonenames_filter = ldap.combine_filters([zonenames_filter, > + exact_name_filter]) > + > + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) > + complete_filter = ldap.combine_filters( > + [objectclass_filter, zonenames_filter, zoneactive_filter], > + rules=ldap.MATCH_ALL > + ) > + > + try: > + entries, truncated = ldap.find_entries( > + filter=complete_filter, > + attrs_list=['idnsname'], > + base_dn=DN(api.env.container_dns, api.env.basedn), > + scope=ldap.SCOPE_ONELEVEL > + ) What about truncated? > + except errors.NotFound: > + return [] > + > + result = [entry.single_value['idnsname'].make_absolute() > + for entry in entries] > + > + return result > + > + > +def _get_zone_which_makes_fw_zone_ineffective(fwzonename): > + """ > + Check if forward zone is effective. > + > + If parent zone exists as authoritative zone, the forward zone will not > + forward queries by default. It is necessary to delegate authority > + to forward zone with a NS record. > + > + Example: > + > + Forward zone: sub.example.com > + Zone: example.com > + > + Forwarding will not work, because the server thinks it is authoritative > + for zone and will return NXDOMAIN > + > + Adding record: sub.example.com NS ns.sub.example.com. > + will delegate authority, and IPA DNS server will forward DNS queries. > + > + :param fwzonename: forwardzone > + :return: None if effective, name of authoritative zone otherwise > + """ > + assert isinstance(fwzonename, DNSName) > + > + auth_zone = _get_auth_zone_ldap(fwzonename) > + if not auth_zone: > + return None > + > + delegation_record_name = _get_longest_match_ns_delegation_ldap( > + auth_zone, fwzonename) > + > + if delegation_record_name: > + return None > + > + return auth_zone > + > + > class DNSZoneBase(LDAPObject): > """ > Base class for DNS Zone > @@ -2376,6 +2592,30 @@ class dnszone(DNSZoneBase): > ) > ) > > + def _warning_fw_zone_is_not_effective(self, result, *keys, **options): > + """ > + Warning if any operation with zone causes, a child forward zone is > + not effective > + """ > + zone = keys[-1] > + affected_fw_zones = _find_subtree_forward_zones_ldap( > + zone, child_zones_only=True) > + if not affected_fw_zones: > + return > + > + for fwzone in affected_fw_zones: > + authoritative_zone = \ > + _get_zone_which_makes_fw_zone_ineffective(fwzone) > + if authoritative_zone: > + # forward zone is not effective and forwarding will not work > + messages.add_message( > + options['version'], result, > + messages.ForwardzoneIsNotEffectiveWarning( > + fwzone=fwzone, authzone=authoritative_zone, > + ns_rec=fwzone.relativize(authoritative_zone) > + ) > + ) > + > @register() > class dnszone_add(DNSZoneBase_add): > __doc__ = _('Create new DNS zone (SOA record).') > @@ -2445,6 +2685,7 @@ class dnszone_add(DNSZoneBase_add): > self.obj._warning_forwarding(result, **options) > self.obj._warning_dnssec_experimental(result, *keys, **options) > self.obj._warning_name_server_option(result, context, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -2475,6 +2716,13 @@ class dnszone_del(DNSZoneBase_del): > > msg_summary = _('Deleted DNS zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnszone_del, self).execute(*keys, **options) > + nkeys = keys[-1] # we can delete more zones > + for key in nkeys: > + self.obj._warning_fw_zone_is_not_effective(result, key, **options) > + return result > + > def post_callback(self, ldap, dn, *keys, **options): > super(dnszone_del, self).post_callback(ldap, dn, *keys, **options) > > @@ -2595,12 +2843,22 @@ class dnszone_disable(DNSZoneBase_disable): > __doc__ = _('Disable DNS Zone.') > msg_summary = _('Disabled DNS zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnszone_disable, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnszone_enable(DNSZoneBase_enable): > __doc__ = _('Enable DNS Zone.') > msg_summary = _('Enabled DNS zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnszone_enable, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnszone_add_permission(DNSZoneBase_add_permission): > @@ -3164,6 +3422,30 @@ class dnsrecord(LDAPObject): > dns_name = entry_name[1].derelativize(dns_domain) > self.wait_for_modified_attrs(entry, dns_name, dns_domain) > > + def warning_if_ns_change_cause_fwzone_ineffective(self, result, *keys, > + **options): > + """after execute""" Please add more descriptive comment to doc string. > + record_name_absolute = keys[-1] a variable with zone name instead of keys[-2] would make it more readable > + if not keys[-1].is_absolute(): record_name_absolute.is_absolute() would be better > + record_name_absolute = keys[-1].derelativize(keys[-2]) again, please replace keys[x] with sensible names > + > + affected_fw_zones = _find_subtree_forward_zones_ldap( > + record_name_absolute) > + if not affected_fw_zones: > + return > + > + for fwzone in affected_fw_zones: Would it be possible to generalize & use _warning_fw_zone_is_not_effective() here? > + authoritative_zone = \ > + _get_zone_which_makes_fw_zone_ineffective(fwzone) > + if authoritative_zone: > + # forward zone is not effective and forwarding will not work > + messages.add_message( > + options['version'], result, > + messages.ForwardzoneIsNotEffectiveWarning( > + fwzone=fwzone, authzone=authoritative_zone, > + ns_rec=fwzone.relativize(authoritative_zone) > + ) > + ) > > > @register() > @@ -3487,7 +3769,10 @@ class dnsrecord_mod(LDAPUpdate): > > if self.api.env['wait_for_dns']: > self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > - > + if 'nsrecord' in options: > + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, > + *keys, > + **options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -3654,19 +3939,23 @@ class dnsrecord_del(LDAPUpdate): > if self.api.env['wait_for_dns']: > entries = {(keys[0], keys[1]): None} > self.obj.wait_for_modified_entries(entries) > - return result > + else: > + result = super(dnsrecord_del, self).execute(*keys, **options) > + result['value'] = pkey_to_value([keys[-1]], options) > > - result = super(dnsrecord_del, self).execute(*keys, **options) > - result['value'] = pkey_to_value([keys[-1]], options) > + if getattr(context, 'del_all', False) and not \ > + self.obj.is_pkey_zone_record(*keys): > + result = self.obj.methods.delentry(*keys, > + version=options['version']) > + context.dnsrecord_entry_mods[(keys[0], keys[1])] = None > > - if getattr(context, 'del_all', False) and not \ > - self.obj.is_pkey_zone_record(*keys): > - result = self.obj.methods.delentry(*keys, > - version=options['version']) > - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None > + if self.api.env['wait_for_dns']: > + self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > > - if self.api.env['wait_for_dns']: > - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > + if 'nsrecord' in options or options.get('del_all', False): > + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, > + *keys, > + **options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -3998,6 +4287,19 @@ class dnsforwardzone(DNSZoneBase): > # managed_permissions: permissions was apllied in dnszone class, do NOT > # add them here, they should not be applied twice. > > + def _warning_fw_zone_is_not_effective(self, result, *keys, **options): > + fwzone = keys[-1] > + authoritative_zone = _get_zone_which_makes_fw_zone_ineffective( > + fwzone) > + if authoritative_zone: > + # forward zone is not effective and forwarding will not work > + messages.add_message( > + options['version'], result, > + messages.ForwardzoneIsNotEffectiveWarning( > + fwzone=fwzone, authzone=authoritative_zone, > + ns_rec=fwzone.relativize(authoritative_zone) > + ) > + ) > > @register() > class dnsforwardzone_add(DNSZoneBase_add): > @@ -4019,6 +4321,11 @@ class dnsforwardzone_add(DNSZoneBase_add): > > return dn > > + def execute(self, *keys, **options): > + result = super(dnsforwardzone_add, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnsforwardzone_del(DNSZoneBase_del): > @@ -4083,6 +4390,11 @@ class dnsforwardzone_enable(DNSZoneBase_enable): > __doc__ = _('Enable DNS Forward Zone.') > msg_summary = _('Enabled DNS forward zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnsforwardzone_enable, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnsforwardzone_add_permission(DNSZoneBase_add_permission): > -- 1.8.3.1 NACK Thank you for your patience with me ;-) -- Petr^2 Spacek From tbordaz at redhat.com Mon Dec 1 16:46:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 01 Dec 2014 17:46:58 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415831860.3363.4.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> Message-ID: <547C9B82.9040304@redhat.com> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>> On 7.11.2014 08:58, Martin Kosek wrote: >>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>> >>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>> how to >>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>> However, >>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>> on the >>>>>>>>>> server. What am I doing wrong? >>>>>>>>>> >>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>> works >>>>>>>>>> just fine. >>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>> attribute >>>>>>>>> names. >>>>>>>> Thanks Nathaniel! >>>>>>>> >>>>>>>>> The above known issue still remains. >>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>> extension >>>>>>>> should work just fine, AFAIK. >>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>> they aren't considered in the update. >>>>>>> Without the blank line it works fine. >>>>>> Thanks for the catch! >>>>>> >>>>>> Here is a version without the blank line. >>>>> I forgot to remove the old steps defines. This patch performs this >>>>> cleanup. >>>> I am now wondering, is the global config object really the nest place to >>>> add these OTP specific settings? >>>> >>>> I would prefer not to overload the object and instead: >>>> - create new ipaOTPConfig objectclass >>>> - add it to cn=otp,$SUFFIX >>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>> of dnsconfig-* and trustconfig-* commands >>>> >>>> IMO, this would allow more flexibility for the OTP settings and would >>>> also scale better for the future updates. >>> +1 >>> >>> I will comment the patch as if ^^ would not exist because it will still be >>> needed in the new plugin. >>> >>> Because of ^^ I did not test, just read. >>> >>> 1. Got: >>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>> recommended in array initializers >>> >>> Please run: >>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>> in install/ui directory >>> >>> The goal is no have no warnings and errors. >>> >>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>> permission >> +1. Though if we go with OTP config, it should be called >> >> System: Read OTP Configuration >> >> Martin > Attached is a new set of patches that replaces this single patch. This > now fixes multiple issues. > > I now create two new entries: > * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > > There are two corresponding CLI commands: > * totpconfig-(show|mod) > * hotpconfig-(show|mod) > > There is no UI support for this yet (pointers welcome). > > This is designed so that eventually tokens can grow a per-token > override, but I have not yet implemented this feature (it should be easy > in the future). > > Additionally, I had to do some shared refactoring to address issues in > ipa-otp-lasttoken, which is why all of these are now merged into a > single patch set. > > Nathaniel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Sorry for this long delay. The patch 0001 is fine for me. Ack I have a question regarding 0002. The function 'otp_config_update' is called in postop in order to 'update' the configuration in case of successful op. In 'update' it can updates 'config_record->value. In case the SLAPI_ENTRY_POST_OP sdn is not the the config_rec->sdn but the SLAPI_TARGET_SDN sdn is the config_rec->sdn , it resets 'config_record'->value to 'config_record->dflt'. Is that the expected effect ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Dec 1 18:25:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 01 Dec 2014 19:25:43 +0100 Subject: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods In-Reply-To: <547C6E13.8010501@redhat.com> References: <547C6A4E.3090307@redhat.com> <547C6E13.8010501@redhat.com> Message-ID: <547CB2A7.60400@redhat.com> On 12/01/2014 02:33 PM, Jan Cholasta wrote: > Hi, > > Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a): >> `--hosts` option added to: >> * service-allow-create-keytab >> * service-allow-retrieve-keytab >> * service-disallow-create-keytab >> * service-disallow-retrieve-keytab >> * host-allow-create-keytab >> * host-allow-retrieve-keytab >> * host-disallow-create-keytab >> * host-disallow-retrieve-keytab >> >> in order to allow hosts to retrieve keytab of their services or related >> hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval >> design page >> >> https://fedorahosted.org/freeipa/ticket/4777 > > Since groups of users are supported with "group" members, we should > probably also support groups of hosts with "hostgroup" members, for > consistency. --hostgroup options added. > >> >> >> I'm pondering how to handle Web UI. I'm not font of adding a third pair >> of tables to host and service details pages because the amount of space >> on the page required for the keytab management is much bigger than its >> importance compared to other fields. > > Honza > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0792-1-add-hosts-option-to-allow-retrieve-keytab-methods.patch Type: text/x-patch Size: 42764 bytes Desc: not available URL: From mbasti at redhat.com Tue Dec 2 08:57:08 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 02 Dec 2014 09:57:08 +0100 Subject: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration In-Reply-To: References: <547C4F15.8000601@redhat.com> Message-ID: <547D7EE4.9040205@redhat.com> On 01/12/14 16:16, Gabe Alford wrote: > Thanks, David. You're totally right. I am good with it. > > thanks, > > Gabe ACK > > On Mon, Dec 1, 2014 at 5:20 AM, David Kupka > wrote: > > On 11/30/2014 02:03 AM, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4583 > > Thanks, > > Gabe > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Hello! > > Thanks for patch. I guess that you wanted to add the "iburst" > option only once. Right now it will generate lines like: > > server iburst iburst > > Attaching the fixed patch. Are you satisfied with it? > > -- > David Kupka > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Dec 2 09:45:03 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Dec 2014 10:45:03 +0100 Subject: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds In-Reply-To: <547C5FCA.5010909@redhat.com> References: <54772535.40202@redhat.com> <547C227D.4040503@redhat.com> <547C5FCA.5010909@redhat.com> Message-ID: <547D8A1F.8060700@redhat.com> On 1.12.2014 13:32, Jan Cholasta wrote: > Actually, sratch that, exceptions thrown by python-dns do not have messages. Oh yes, it is very annoying. I have asked upstream if potential patches about this issues can be accepted: https://github.com/rthalley/dnspython/issues/84 -- Petr^2 Spacek From mkosek at redhat.com Tue Dec 2 11:37:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Dec 2014 12:37:00 +0100 Subject: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration In-Reply-To: References: <547C4F15.8000601@redhat.com> Message-ID: <547DA45C.9020700@redhat.com> I understand this as a patch from Gabe and ACK from David :-) Pushed to master: 5f223a89adb400cfbe25231c8e6629dbf867642f Martin On 12/01/2014 04:16 PM, Gabe Alford wrote: > Thanks, David. You're totally right. I am good with it. > > thanks, > > Gabe > > On Mon, Dec 1, 2014 at 5:20 AM, David Kupka wrote: > >> On 11/30/2014 02:03 AM, Gabe Alford wrote: >> >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/4583 >>> >>> Thanks, >>> >>> Gabe >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Hello! >> >> Thanks for patch. I guess that you wanted to add the "iburst" option only >> once. Right now it will generate lines like: >> >> server iburst iburst >> >> Attaching the fixed patch. Are you satisfied with it? >> >> -- >> David Kupka >> > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From pviktori at redhat.com Tue Dec 2 11:40:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Dec 2014 12:40:43 +0100 Subject: [Freeipa-devel] [PATCH] 791 fix indentation in ipa-restore page In-Reply-To: <54774D35.3050907@redhat.com> References: <54774D35.3050907@redhat.com> Message-ID: <547DA53B.1070803@redhat.com> ACK, pushed to: master: 79d9c4943617bf57fde4a38325cbc9a14d0ff495 ipa-4-1: 250bb5cf3cf6d05fca7e99867a29ce1cfbb1da97 -- Petr? From mkosek at redhat.com Tue Dec 2 11:47:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Dec 2014 12:47:59 +0100 Subject: [Freeipa-devel] [PATCH] Stop ntpd before running ntpdate In-Reply-To: References: <535F4DED.8090004@redhat.com> Message-ID: <547DA6EF.5010701@redhat.com> On 05/09/2014 04:09 AM, Gabe Alford wrote: > Re-factored my second patch. :) > > Gabe > > > On Tue, Apr 29, 2014 at 8:04 PM, Gabe Alford wrote: > >> Updated patch to not run ntpdate if ntpd is running. >> >> Gabe >> >> >> >> On Tue, Apr 29, 2014 at 8:16 AM, Gabe Alford wrote: >> >>> Thanks Petr! >>> >>> Will rework patch to just skip ntpdate if ntpd is already running. >>> >>> >>> On Tue, Apr 29, 2014 at 12:59 AM, Petr Spacek wrote: >>> >>>> Hello Gabe! >>>> >>>> >>>> On 25.4.2014 16:28, Gabe Alford wrote: >>>> >>>>> Here is a patch for https://fedorahosted.org/ >>>>> freeipa/ticket/3735. >>>>> It seemed better to try to stop ntpd before running ntpdate rather than >>>>> not >>>>> running ntpdate if ntpd was already running. I believe this patch only >>>>> applies to the ipa-3-3 branch as ntpdate is not used anymore in the >>>>> master. >>>>> >>>> >>>> IMHO we should never stop ntpd if it is running. Plain ntpdate opens >>>> potential security hole because attacker can fake NTP answers and force the >>>> machine to rewind it's clock to the past. >>>> >>>> This opens potential for replay attacks/re-suing old compromised keys >>>> etc. I just noticed that https://fedorahosted.org/freeipa/ticket/3735 has a pending patch from Gabe. David or Tomas, do we still want to go with this approach? IIRC, David is now working in related area in ipa-client-install, so the patch could be reviewed/reworked as part of his job. Martin From jpazdziora at redhat.com Tue Dec 2 12:00:13 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 2 Dec 2014 13:00:13 +0100 Subject: [Freeipa-devel] [PATCH 3] ipa-client-install shouldn't be eager in specifying zone when doing nsupdate Message-ID: <20141202120013.GA24924@redhat.com> Hello, presumably explicitly specifying zone is not needed and can be harmful. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -------------- next part -------------- >From 934c5672cb0f73fc7d237cbf916707693dff9c39 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora Date: Tue, 2 Dec 2014 11:48:04 +0100 Subject: [PATCH] No explicit zone specification. https://fedorahosted.org/freeipa/ticket/4780 --- ipa-client/ipa-install/ipa-client-install | 2 -- 1 file changed, 2 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 612ff62a12a24672e6bc390bcd5165cd20bf834a..eb9a4c2cd884d5412388b2a5c01149c40e8e2e3e 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -1553,7 +1553,6 @@ def do_nsupdate(update_txt): UPDATE_TEMPLATE_A = """ debug -zone $ZONE. update delete $HOSTNAME. IN A show send @@ -1564,7 +1563,6 @@ send UPDATE_TEMPLATE_AAAA = """ debug -zone $ZONE. update delete $HOSTNAME. IN AAAA show send -- 1.9.3 From tbabej at redhat.com Tue Dec 2 12:16:55 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Dec 2014 13:16:55 +0100 Subject: [Freeipa-devel] [PATCH 0288] certs: Fix incorrect flag handling in load_cacert Message-ID: <547DADB7.6080908@redhat.com> Hi, For CA certificates that are not certificates of IPA CA, we incorrectly set the trust flags to ",,", regardless what the actual trust_flags parameter was passed. Make the load_cacert method respect trust_flags and make "C,," default set of trust flags. https://fedorahosted.org/freeipa/ticket/4779 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0288-certs-Fix-incorrect-flag-handling-in-load_cacert.patch Type: text/x-patch Size: 1782 bytes Desc: not available URL: From jcholast at redhat.com Tue Dec 2 12:45:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Dec 2014 13:45:45 +0100 Subject: [Freeipa-devel] [PATCH 0288] certs: Fix incorrect flag handling in load_cacert In-Reply-To: <547DADB7.6080908@redhat.com> References: <547DADB7.6080908@redhat.com> Message-ID: <547DB479.3020005@redhat.com> Hi, Dne 2.12.2014 v 13:16 Tomas Babej napsal(a): > Hi, > > For CA certificates that are not certificates of IPA CA, we incorrectly > set the trust flags to ",,", regardless what the actual trust_flags > parameter was passed. > > Make the load_cacert method respect trust_flags and make "C,," default > set of trust flags. For unknown CA certificates, you must keep the default ",," and explicitly override it where necessary. We don't want to trust *any* CA certificate to issue server certs. > > https://fedorahosted.org/freeipa/ticket/4779 Honza -- Jan Cholasta From tbabej at redhat.com Tue Dec 2 12:55:38 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Dec 2014 13:55:38 +0100 Subject: [Freeipa-devel] [PATCH 0288] certs: Fix incorrect flag handling in load_cacert In-Reply-To: <547DB479.3020005@redhat.com> References: <547DADB7.6080908@redhat.com> <547DB479.3020005@redhat.com> Message-ID: <547DB6CA.4000701@redhat.com> On 12/02/2014 01:45 PM, Jan Cholasta wrote: > Hi, > > Dne 2.12.2014 v 13:16 Tomas Babej napsal(a): >> Hi, >> >> For CA certificates that are not certificates of IPA CA, we incorrectly >> set the trust flags to ",,", regardless what the actual trust_flags >> parameter was passed. >> >> Make the load_cacert method respect trust_flags and make "C,," default >> set of trust flags. > > For unknown CA certificates, you must keep the default ",," and > explicitly override it where necessary. We don't want to trust *any* > CA certificate to issue server certs. > >> >> https://fedorahosted.org/freeipa/ticket/4779 > > Honza Updated patch attached. However, this boils down to the same, so there is really no functional difference between the two versions of the patches in the current code base. All places where load_cacert is called, the trust flags are explicitly overriden. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0288-2-certs-Fix-incorrect-flag-handling-in-load_cacert.patch Type: text/x-patch Size: 2530 bytes Desc: not available URL: From jcholast at redhat.com Tue Dec 2 13:02:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Dec 2014 14:02:06 +0100 Subject: [Freeipa-devel] [PATCH 0288] certs: Fix incorrect flag handling in load_cacert In-Reply-To: <547DB6CA.4000701@redhat.com> References: <547DADB7.6080908@redhat.com> <547DB479.3020005@redhat.com> <547DB6CA.4000701@redhat.com> Message-ID: <547DB84E.80501@redhat.com> Dne 2.12.2014 v 13:55 Tomas Babej napsal(a): > > On 12/02/2014 01:45 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 2.12.2014 v 13:16 Tomas Babej napsal(a): >>> Hi, >>> >>> For CA certificates that are not certificates of IPA CA, we incorrectly >>> set the trust flags to ",,", regardless what the actual trust_flags >>> parameter was passed. >>> >>> Make the load_cacert method respect trust_flags and make "C,," default >>> set of trust flags. >> >> For unknown CA certificates, you must keep the default ",," and >> explicitly override it where necessary. We don't want to trust *any* >> CA certificate to issue server certs. >> >>> >>> https://fedorahosted.org/freeipa/ticket/4779 >> >> Honza > > Updated patch attached. > > However, this boils down to the same, so there is really no functional > difference between the two versions of the patches in the current code > base. All places where load_cacert is called, the trust flags are > explicitly overriden. > OK, then we don't need a default value at all. -- Jan Cholasta From tbordaz at redhat.com Tue Dec 2 13:05:24 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 02 Dec 2014 14:05:24 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1415831860.3363.4.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> Message-ID: <547DB914.7050605@redhat.com> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>> On 7.11.2014 08:58, Martin Kosek wrote: >>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>> >>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>> how to >>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>> However, >>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>> on the >>>>>>>>>> server. What am I doing wrong? >>>>>>>>>> >>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>> works >>>>>>>>>> just fine. >>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>> attribute >>>>>>>>> names. >>>>>>>> Thanks Nathaniel! >>>>>>>> >>>>>>>>> The above known issue still remains. >>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>> extension >>>>>>>> should work just fine, AFAIK. >>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>> they aren't considered in the update. >>>>>>> Without the blank line it works fine. >>>>>> Thanks for the catch! >>>>>> >>>>>> Here is a version without the blank line. >>>>> I forgot to remove the old steps defines. This patch performs this >>>>> cleanup. >>>> I am now wondering, is the global config object really the nest place to >>>> add these OTP specific settings? >>>> >>>> I would prefer not to overload the object and instead: >>>> - create new ipaOTPConfig objectclass >>>> - add it to cn=otp,$SUFFIX >>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>> of dnsconfig-* and trustconfig-* commands >>>> >>>> IMO, this would allow more flexibility for the OTP settings and would >>>> also scale better for the future updates. >>> +1 >>> >>> I will comment the patch as if ^^ would not exist because it will still be >>> needed in the new plugin. >>> >>> Because of ^^ I did not test, just read. >>> >>> 1. Got: >>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>> recommended in array initializers >>> >>> Please run: >>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>> in install/ui directory >>> >>> The goal is no have no warnings and errors. >>> >>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>> permission >> +1. Though if we go with OTP config, it should be called >> >> System: Read OTP Configuration >> >> Martin > Attached is a new set of patches that replaces this single patch. This > now fixes multiple issues. > > I now create two new entries: > * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > > There are two corresponding CLI commands: > * totpconfig-(show|mod) > * hotpconfig-(show|mod) > > There is no UI support for this yet (pointers welcome). > > This is designed so that eventually tokens can grow a per-token > override, but I have not yet implemented this feature (it should be easy > in the future). > > Additionally, I had to do some shared refactoring to address issues in > ipa-otp-lasttoken, which is why all of these are now merged into a > single patch set. > > Nathaniel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Nathaniel, Very few comments. On patch 0002: Is it possible that we later define a spec with 'dflt' contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs to be 32bits. When otp_config_fini is it called ? On patch 0003: In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h). In ipa-otp-lasttoken:preop_mod , the test is_allowed is done on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that the entry you want to check ? On patch 0004: In otp_config.c:otp_config_window you may use SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) in otp_token: bvtod if 'code' contains non digit character ,'out' is not reset before return. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Dec 2 13:09:15 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Dec 2014 14:09:15 +0100 Subject: [Freeipa-devel] [PATCH 0288] certs: Fix incorrect flag handling in load_cacert In-Reply-To: <547DB84E.80501@redhat.com> References: <547DADB7.6080908@redhat.com> <547DB479.3020005@redhat.com> <547DB6CA.4000701@redhat.com> <547DB84E.80501@redhat.com> Message-ID: <547DB9FB.3050903@redhat.com> On 12/02/2014 02:02 PM, Jan Cholasta wrote: > Dne 2.12.2014 v 13:55 Tomas Babej napsal(a): >> >> On 12/02/2014 01:45 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 2.12.2014 v 13:16 Tomas Babej napsal(a): >>>> Hi, >>>> >>>> For CA certificates that are not certificates of IPA CA, we >>>> incorrectly >>>> set the trust flags to ",,", regardless what the actual trust_flags >>>> parameter was passed. >>>> >>>> Make the load_cacert method respect trust_flags and make "C,," default >>>> set of trust flags. >>> >>> For unknown CA certificates, you must keep the default ",," and >>> explicitly override it where necessary. We don't want to trust *any* >>> CA certificate to issue server certs. >>> >>>> >>>> https://fedorahosted.org/freeipa/ticket/4779 >>> >>> Honza >> >> Updated patch attached. >> >> However, this boils down to the same, so there is really no functional >> difference between the two versions of the patches in the current code >> base. All places where load_cacert is called, the trust flags are >> explicitly overriden. >> > > OK, then we don't need a default value at all. > Updated patch makes trust_flags a required argument of load_cacert. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0288-3-certs-Fix-incorrect-flag-handling-in-load_cacert.patch Type: text/x-patch Size: 2483 bytes Desc: not available URL: From tbabej at redhat.com Tue Dec 2 14:43:22 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Dec 2014 15:43:22 +0100 Subject: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show Message-ID: <547DD00A.7030705@redhat.com> Hi, Makes ipaassignedidview a default attribute and takes care about the conversion from the DN to the proper ID view name. https://fedorahosted.org/freeipa/ticket/4774 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0289-hosts-Display-assigned-ID-view-by-default-in-host-fi.patch Type: text/x-patch Size: 2564 bytes Desc: not available URL: From jcholast at redhat.com Tue Dec 2 14:45:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Dec 2014 15:45:31 +0100 Subject: [Freeipa-devel] [PATCH 0288] certs: Fix incorrect flag handling in load_cacert In-Reply-To: <547DB9FB.3050903@redhat.com> References: <547DADB7.6080908@redhat.com> <547DB479.3020005@redhat.com> <547DB6CA.4000701@redhat.com> <547DB84E.80501@redhat.com> <547DB9FB.3050903@redhat.com> Message-ID: <547DD08B.6050705@redhat.com> Dne 2.12.2014 v 14:09 Tomas Babej napsal(a): > > On 12/02/2014 02:02 PM, Jan Cholasta wrote: >> Dne 2.12.2014 v 13:55 Tomas Babej napsal(a): >>> >>> On 12/02/2014 01:45 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 2.12.2014 v 13:16 Tomas Babej napsal(a): >>>>> Hi, >>>>> >>>>> For CA certificates that are not certificates of IPA CA, we >>>>> incorrectly >>>>> set the trust flags to ",,", regardless what the actual trust_flags >>>>> parameter was passed. >>>>> >>>>> Make the load_cacert method respect trust_flags and make "C,," default >>>>> set of trust flags. >>>> >>>> For unknown CA certificates, you must keep the default ",," and >>>> explicitly override it where necessary. We don't want to trust *any* >>>> CA certificate to issue server certs. >>>> >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4779 >>>> >>>> Honza >>> >>> Updated patch attached. >>> >>> However, this boils down to the same, so there is really no functional >>> difference between the two versions of the patches in the current code >>> base. All places where load_cacert is called, the trust flags are >>> explicitly overriden. >>> >> >> OK, then we don't need a default value at all. >> > > Updated patch makes trust_flags a required argument of load_cacert. > Thanks, ACK! Pushed to: master: faec4ef9de431a1b72423be8ce6cea28a7221531 ipa-4-1: db4ac4774523c1d41a606b1c0297e9eeae13ebd6 Honza -- Jan Cholasta From pspacek at redhat.com Tue Dec 2 14:56:28 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Dec 2014 15:56:28 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <20141201111233.5a44b40e@willson.usersys.redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> Message-ID: <547DD31C.1020106@redhat.com> On 1.12.2014 17:12, Simo Sorce wrote: > On Mon, 01 Dec 2014 16:17:54 +0100 > Petr Spacek wrote: > >> On 14.11.2014 17:31, Petr Spacek wrote: >>> On 14.11.2014 02:22, Simo Sorce wrote: >>>> On Tue, 11 Nov 2014 16:29:51 +0100 >>>> Petr Spacek wrote: >>>> >>>>> Hello, >>>>> >>>>> this thread is about RFE >>>>> "IPA servers when installed should register themselves in the >>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >>>>> >>>>> It is not a complete design, just a raw idea. >>>>> >>>>> >>>>> Use case >>>>> ======== >>>>> FreeIPA installation to a network with existing DNS >>>>> infrastructure + network administrator who is not willing to >>>>> add/maintain new DNS servers "just for FreeIPA". >>>>> >>>>> >>>>> High-level idea >>>>> =============== >>>>> - Transform dns* commands from FreeIPA framework to equivalent >>>>> "nsupdate" commands and send DNS updates to existing DNS servers. >>>>> - Provide necessary encryption/signing keys to nsupdate. >>>>> >>>>> >>>>> 1) Integration to FreeIPA framework >>>>> =================================== >>>>> First of all, we need to decide if "external DNS integration" can >>>>> be used at the same time with FreeIPA-integrated DNS or not. >>>>> Side-question is what to do if a first server is installed with >>>>> external-DNS but another replica is being installed with >>>>> integrated-DNS and so on. >>>> >>>> I think being able to integrate with an external DNS is important, >>>> and not just at the server level, being able to distribute TSIG >>>> keys to client would be nice too, though a lot less important, >>>> than getting server integration.. >>> >>> Using TSIG on many clients is very problematic. Keep in mind that >>> TSIG is basically HMAC computed using symmetric key so: >>> a) Every client would have to use the same key - this is a security >>> nightmare. b) We would have to distribute and maintain many keys >>> for many^2 clients, which is an administrative nightmare. >>> >>> For *clients* I would rather stay with GSS-TSIG which is much more >>> manageable because we can use Kerberos trust and Keytab >>> distribution is already solved by ipa-client-install. >>> >>> Alternative for clients would be to use FreeIPA server as proxy >>> which encapsulates TSIG keys and issues update requests on behalf >>> of clients. This would be FreeIPA-specific but any >>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>> >>> TSIG standard explicitly says that there is no standardized >>> distribution mechanism. >>> >>>>> In other words, the question is if current "dns.py" plugin shipped >>>>> with FreeIPA framework should be: >>>>> >>>>> a) Extended dns.py with dnsexternal-* commands >>>>> ---------------------------------------------- >>>>> Disadvantages: >>>>> - It complicate FreeIPA DNS interface which is a complex beast >>>>> even now. >>>>> - We would have add condition to every DNS API call in installers >>>>> which would increase horribleness of the installer code even more >>>>> (or add another layer of abstraction...). >>>> >>>> I agree having a special command is undesirable. >>>>> >>>>> - I don't see a point in using integrated-DNS with external-DNS at >>>>> the same time. To use integrated-DNS you have to get a proper DNS >>>>> delegation from parent domain - and if you can get the delegation >>>>> then there is no point in using external DNS ... >>>> >>>> I disagree on this point, it makes a lot of sense to have some >>>> zones maintained by IPA and ... some not. >>>> >>>>> Advantages: >>>>> - You can use external & integrated DNS at the same time. >>>> >>>> We can achieve the same w/o a new ipa level command. >>> >>> This needs to be decided by FreeIPA framework experts ... >>> >>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>> proxy would provide all ipa dns* commands and dispatch user-issued >>> commands to appropriate FreeIPA-plugin (internal-dns or >>> external-dns). This decision could depend on some values in LDAP. >>> >>>>> b) Replace dns.py with another implementation of current >>>>> dnszone-* & dnsrecord-* API. >>>>> --------------------------------------------------------------------- >>>>> This seems like a cleaner approach to me. It could be shipped as >>>>> ipa-server-dns-external package (opposed to "standard" >>>>> ipa-server-dns package). >>>>> >>>>> Advantages: >>>>> - It could seamlessly work with FreeIPA client installer because >>>>> the dns*->nsupdate command transformation would be done on >>>>> FreeIPA server and client doesn't need to know about it. >>>>> - Does not require re-training/not much new documentation because >>>>> commands are the same. >>>>> >>>>> Disadvantages: >>>>> - You can't use integrated & external DNS at the same time (but I >>>>> don't think it justifies the added complexity). >>>> >>>> I disagree. >>>> >>>> One of the reason to use a mix is to allow smooth migrations where >>>> zones are moved into (or out of) IPA one by one. >>> >>> Good point, I agree. I will focus on supporting both (internal and >>> external) DNS at the same time. >>> >>>>> Petr^3 or anyone else, what do you propose? >>>> >>>> I think what I'd like to see is to be able to configure a DNS zone >>>> in LDAP and mark it external. >>>> The zone would held the TSIG keys necessary to perform DNS updates. >>>> >>>> When the regular ipa dnsrecord-add etc... commands are called, the >>>> framework detects that the zone is "external", fewttches the TSIG >>>> key (if the user has access to it) and spawn an nsupdate command >>>> that will perform the update against whatever DNS server is >>>> authoritative for the zone. >>>> >>>> Some commands may be disabled if the zone is external and >>>> appropriate errors would be returned. >>> >>> Correct, this will be inevitable. >>> >>>>> 2) Authentication to external DNS server/keys >>>>> ============================================= >>>>> This is separate problem from FreeIPA framework integration. >>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) or >>>>> keytabs (for DNS GSS-TSIG) and distribute them somehow to >>>>> replicas so every replica can update DNS records as necessary. >>>> >>>> For TSIG keys I think we should just store them in a LDAP record, >>>> see above. >>> >>> Without any encryption? Am I missing something? >>> >>>> For keytabs we can simply store them just like any other kerberos >>>> key if we really need it (in a trust case for example, we may not >>>> need a new keytab, we may be allowed to use our own credentials >>>> through the trust. So we'll need to explore a bit how to properly >>>> express that in configuration. REtrieval ok keytabs is then just a >>>> matter of running ipa-getkeytab -r on the replica that needs it. >>>> >>>>> This will be the funny part because in case of AD trusts we have >>>>> chicken-egg problem. You need to establish trust to get ticket for >>>>> DNS/dc1.ad.example at AD principal but you can't (I guess) establish >>>>> trust until proper DNS records are in place ... >>>> >>>> No, in this case we should create the records at trust >>>> establishment time using the admin credentials we have been >>>> provided. NO chicken-egg issue. >>> >>> Sorry, we surely *have* a chicken-egg issue because >>> ipa-server-install is completely separate step from from >>> ipa-adtrust-install which is completely separate from ipa >>> trust-add. (And there is nothing which forces user to establish AD >>> trust right after ipa-server-install finished.) >>> >>> Also, in some cases it is not possible to use the same credentials >>> for trust establishment and for DNS updates on AD. Think about >>> one-way trust or possibly two-way trust but established using >>> pre-shared trust secret (which is AFAIK not usable for kinit). >>> >>> Alexander, could you clarify if it is possible to create an AD >>> trust *without* DNS records for FreeIPA side of the trust? >>> >>> Another problem is that reliance on AD trusts would effectively >>> prevent interoperability with non-AD DNS servers (think Infoblox or >>> standard BIND). >>> >>> I tend to think that we will need to obtain credentials (AD >>> login/pass/keytab/TSIG key) as one of ipa-server-install parameters >>> so all DNS updates can be done right away. This would allow us have >>> ipa-server-install script which in fact produces *working* FreeIPA >>> domain. In other cases ipa-server-install would end but the FreeIPA >>> domain would not be functional because of missing records in DNS. >>> >>>>> For 'experimental' phase I would go with pre-populated CCcache, >>>>> i.e. admin will manually do kinit Administrator at AD and then run >>>>> FreeIPA installer. >>>> >>>> We already to this, so there is no need to invent anything here >>>> IMO. >>> >>> Except for cases mentioned above ... >>> >>>>> Maybe we can re-use trust secret somehow? I don't know, I will >>>>> reach out to AD experts with questions. >>>>> >>>>> This area needs more research but for now it seems feasible to >>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs >>>>> so "only" the chicken-egg problem is left. >>>>> >>>>> This will need new LDAP schema but I will propose something when >>>>> I'm done with investigation. >>>> >>>> Please let me know if you agree with a new zone type as a way to >>>> "forward" updates. >>> >>> Generally I agree, it was my plan too. My main concern is not about >>> LDAP structure but about FreeIPA framework and about workflow in >>> general. It will be fun to extend the spaghetti code we have ... >> >> Ping :-) I would like to move the discussion forward. >> >> Alexander, could you please comment on authentication to AD mentioned >> above? >> >> Simo and everybody else, what do you think about client use-case, i.e. >> forwarding DNS updates from FreeIPA clients to external DNS >> infrastructure? What about security implications (keeping in mind >> that TSIG keys are symmetric)? >> >> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy >> instead of nsupdate command (to hide TSIG key behind FreeIPA)? > > Remind me this, when a client tries to update the DNS, does it always > contact its own DNS server first, or does it try to go straight to the > authoritative DNS server? It should go straight to authoritative servers listed in NS records. > I do not like the XML-RPC->DNS approach as it requires a special > client, leaving out the majority of clients. Yes, it is an option of last resort (because I don't see a way how to be compatible with standard clients, see the point above). > Also, I am thinking that we only _need_ to set infrastructure relevant > names (like IPA servers SRV records), but if someone decides not to use > IPA for the DNS we may decide that it is not our responsibility to > provide a full end-to-end client dns update solution. If we can agree on that then I'm fine with it. > So I would concentrate on making it possible for IPA *Servers* to use a > private TSIG key to update infrastructure relevant names, and possibly > defer the clients side of the problem. Speaking about native clients, two-way AD trust should nicely work with clients because clients could go straight to the AD and authenticate using host keytab from FreeIPA realm. It will not work in other cases but it is still better than nothing. > We could use an internal bus on the server to allow the ipa framework > to use nsupdate w/o gaining direct access to the TSIG key, this way > admins can use ipa dnsrecod-add and friends w/o exposing the key. I agree with the idea but it depends on an authorization daemon you have proposed earlier (in different discussion). Do you see it as reasonable goal for FreeIPA 4.2 time-span? If the authorization daemon is too far away, would it be okay to support external DNS domains only for ipa* installers but do not support it for FreeIPA users? (I.e. basically store the key in HSM which is not accessible to users - that is what we do with DNSSEC keys now.) -- Petr^2 Spacek From jcholast at redhat.com Tue Dec 2 15:14:27 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Dec 2014 16:14:27 +0100 Subject: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show In-Reply-To: <547DD00A.7030705@redhat.com> References: <547DD00A.7030705@redhat.com> Message-ID: <547DD753.1040405@redhat.com> Hi, Dne 2.12.2014 v 15:43 Tomas Babej napsal(a): > Hi, > > Makes ipaassignedidview a default attribute and takes care about the > conversion from the DN to the proper ID view name. > > https://fedorahosted.org/freeipa/ticket/4774 Since you are converting the value from DN to primary key string, the type of the ipassignedview param should be changed to Str, for consistency with existing code. Honza -- Jan Cholasta From npmccallum at redhat.com Tue Dec 2 15:39:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 10:39:16 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <547C9B82.9040304@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547C9B82.9040304@redhat.com> Message-ID: <1417534756.5864.37.camel@redhat.com> On Mon, 2014-12-01 at 17:46 +0100, thierry bordaz wrote: > On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > > > On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > > > On 11/07/2014 04:44 PM, Petr Vobornik wrote: > > > > On 7.11.2014 08:58, Martin Kosek wrote: > > > > > On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > > > > > > On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > > > > > > > On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > > > > > > > > On 10/29/2014 10:37 AM, Martin Kosek wrote: > > > > > > > > > On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > > > > > > > > > > On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > > > > > > > > > > > This patch gives the administrator variables to control the size of > > > > > > > > > > > the authentication and synchronization windows for OTP tokens. > > > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/4511 > > > > > > > > > > > > > > > > > > > > > > NOTE: There is one known issue with this patch which I don't know > > > > > > > > > > > how to > > > > > > > > > > > solve. This patch changes the schema in > > > > > > > > > > > install/share/60ipaconfig.ldif. > > > > > > > > > > > On an upgrade, all of the new attributeTypes appear correctly. > > > > > > > > > > > However, > > > > > > > > > > > the modifications to the pre-existing objectClass do not show up > > > > > > > > > > > on the > > > > > > > > > > > server. What am I doing wrong? > > > > > > > > > > > > > > > > > > > > > > After modifying ipaGuiConfig manually, everything in this patch > > > > > > > > > > > works > > > > > > > > > > > just fine. > > > > > > > > > > This new version takes into account the new (proper) OIDs and > > > > > > > > > > attribute > > > > > > > > > > names. > > > > > > > > > Thanks Nathaniel! > > > > > > > > > > > > > > > > > > > The above known issue still remains. > > > > > > > > > Petr3, any idea what could have gone wrong? ObjectClass MAY list > > > > > > > > > extension > > > > > > > > > should work just fine, AFAIK. > > > > > > > > You added a blank line to the LDIF file. This is an entry separator, so > > > > > > > > the objectClasses after the blank line don't belong to cn=schema, so > > > > > > > > they aren't considered in the update. > > > > > > > > Without the blank line it works fine. > > > > > > > Thanks for the catch! > > > > > > > > > > > > > > Here is a version without the blank line. > > > > > > I forgot to remove the old steps defines. This patch performs this > > > > > > cleanup. > > > > > I am now wondering, is the global config object really the nest place to > > > > > add these OTP specific settings? > > > > > > > > > > I would prefer not to overload the object and instead: > > > > > - create new ipaOTPConfig objectclass > > > > > - add it to cn=otp,$SUFFIX > > > > > - create otpconfig-mod and otpconfig-show commands to follow an example > > > > > of dnsconfig-* and trustconfig-* commands > > > > > > > > > > IMO, this would allow more flexibility for the OTP settings and would > > > > > also scale better for the future updates. > > > > +1 > > > > > > > > I will comment the patch as if ^^ would not exist because it will still be > > > > needed in the new plugin. > > > > > > > > Because of ^^ I did not test, just read. > > > > > > > > 1. Got: > > > > install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > > > > recommended in array initializers > > > > > > > > Please run: > > > > jsl -nofilelisting -nosummary -nologo -conf jsl.conf > > > > in install/ui directory > > > > > > > > The goal is no have no warnings and errors. > > > > > > > > 2. new attrs should be added to 'System: Read Global Configuration' managed > > > > permission > > > +1. Though if we go with OTP config, it should be called > > > > > > System: Read OTP Configuration > > > > > > Martin > > Attached is a new set of patches that replaces this single patch. This > > now fixes multiple issues. > > > > I now create two new entries: > > * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > > * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > > > > There are two corresponding CLI commands: > > * totpconfig-(show|mod) > > * hotpconfig-(show|mod) > > > > There is no UI support for this yet (pointers welcome). > > > > This is designed so that eventually tokens can grow a per-token > > override, but I have not yet implemented this feature (it should be easy > > in the future). > > > > Additionally, I had to do some shared refactoring to address issues in > > ipa-otp-lasttoken, which is why all of these are now merged into a > > single patch set. > > > > Nathaniel > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Hello Nathaniel, > > Sorry for this long delay. > The patch 0001 is fine for me. Ack > > I have a question regarding 0002. > The function 'otp_config_update' is called in postop in order to > 'update' the configuration in case of successful op. > In 'update' it can updates 'config_record->value. > In case the SLAPI_ENTRY_POST_OP sdn is not the the config_rec->sdn > but the SLAPI_TARGET_SDN sdn is the config_rec->sdn , it resets > 'config_record'->value to 'config_record->dflt'. Is that the expected > effect ? Yes. There are two cases here. 1. If dst is NULL, it means that the config object was deleted. 2. If dst is not NULL but the sdns don't match, it was moved. In both of these cases, we no longer have a valid configuration object and set the configuration record back to the default value. Nathaniel From pvoborni at redhat.com Tue Dec 2 15:43:06 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 02 Dec 2014 16:43:06 +0100 Subject: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show In-Reply-To: <547DD753.1040405@redhat.com> References: <547DD00A.7030705@redhat.com> <547DD753.1040405@redhat.com> Message-ID: <547DDE0A.7000409@redhat.com> On 12/02/2014 04:14 PM, Jan Cholasta wrote: > Hi, > > Dne 2.12.2014 v 15:43 Tomas Babej napsal(a): >> Hi, >> >> Makes ipaassignedidview a default attribute and takes care about the >> conversion from the DN to the proper ID view name. >> >> https://fedorahosted.org/freeipa/ticket/4774 > > Since you are converting the value from DN to primary key string, the > type of the ipassignedview param should be changed to Str, for > consistency with existing code. > > Honza > 1. the output is no longer a list: it was changed from: "ipaassignedidview": [ "cn=foo,cn=views,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" ], to: "ipaassignedidview": "foo", 2. the value is not normalized in host-mod command -- Petr Vobornik From npmccallum at redhat.com Tue Dec 2 15:56:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 10:56:08 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <547DB914.7050605@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547DB914.7050605@redhat.com> Message-ID: <1417535768.5864.46.camel@redhat.com> On Tue, 2014-12-02 at 14:05 +0100, thierry bordaz wrote: > On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > > > On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > > > On 11/07/2014 04:44 PM, Petr Vobornik wrote: > > > > On 7.11.2014 08:58, Martin Kosek wrote: > > > > > On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > > > > > > On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > > > > > > > On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > > > > > > > > On 10/29/2014 10:37 AM, Martin Kosek wrote: > > > > > > > > > On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > > > > > > > > > > On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > > > > > > > > > > > This patch gives the administrator variables to control the size of > > > > > > > > > > > the authentication and synchronization windows for OTP tokens. > > > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/4511 > > > > > > > > > > > > > > > > > > > > > > NOTE: There is one known issue with this patch which I don't know > > > > > > > > > > > how to > > > > > > > > > > > solve. This patch changes the schema in > > > > > > > > > > > install/share/60ipaconfig.ldif. > > > > > > > > > > > On an upgrade, all of the new attributeTypes appear correctly. > > > > > > > > > > > However, > > > > > > > > > > > the modifications to the pre-existing objectClass do not show up > > > > > > > > > > > on the > > > > > > > > > > > server. What am I doing wrong? > > > > > > > > > > > > > > > > > > > > > > After modifying ipaGuiConfig manually, everything in this patch > > > > > > > > > > > works > > > > > > > > > > > just fine. > > > > > > > > > > This new version takes into account the new (proper) OIDs and > > > > > > > > > > attribute > > > > > > > > > > names. > > > > > > > > > Thanks Nathaniel! > > > > > > > > > > > > > > > > > > > The above known issue still remains. > > > > > > > > > Petr3, any idea what could have gone wrong? ObjectClass MAY list > > > > > > > > > extension > > > > > > > > > should work just fine, AFAIK. > > > > > > > > You added a blank line to the LDIF file. This is an entry separator, so > > > > > > > > the objectClasses after the blank line don't belong to cn=schema, so > > > > > > > > they aren't considered in the update. > > > > > > > > Without the blank line it works fine. > > > > > > > Thanks for the catch! > > > > > > > > > > > > > > Here is a version without the blank line. > > > > > > I forgot to remove the old steps defines. This patch performs this > > > > > > cleanup. > > > > > I am now wondering, is the global config object really the nest place to > > > > > add these OTP specific settings? > > > > > > > > > > I would prefer not to overload the object and instead: > > > > > - create new ipaOTPConfig objectclass > > > > > - add it to cn=otp,$SUFFIX > > > > > - create otpconfig-mod and otpconfig-show commands to follow an example > > > > > of dnsconfig-* and trustconfig-* commands > > > > > > > > > > IMO, this would allow more flexibility for the OTP settings and would > > > > > also scale better for the future updates. > > > > +1 > > > > > > > > I will comment the patch as if ^^ would not exist because it will still be > > > > needed in the new plugin. > > > > > > > > Because of ^^ I did not test, just read. > > > > > > > > 1. Got: > > > > install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > > > > recommended in array initializers > > > > > > > > Please run: > > > > jsl -nofilelisting -nosummary -nologo -conf jsl.conf > > > > in install/ui directory > > > > > > > > The goal is no have no warnings and errors. > > > > > > > > 2. new attrs should be added to 'System: Read Global Configuration' managed > > > > permission > > > +1. Though if we go with OTP config, it should be called > > > > > > System: Read OTP Configuration > > > > > > Martin > > Attached is a new set of patches that replaces this single patch. This > > now fixes multiple issues. > > > > I now create two new entries: > > * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > > * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > > > > There are two corresponding CLI commands: > > * totpconfig-(show|mod) > > * hotpconfig-(show|mod) > > > > There is no UI support for this yet (pointers welcome). > > > > This is designed so that eventually tokens can grow a per-token > > override, but I have not yet implemented this feature (it should be easy > > in the future). > > > > Additionally, I had to do some shared refactoring to address issues in > > ipa-otp-lasttoken, which is why all of these are now merged into a > > single patch set. > > > > Nathaniel > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Hello Nathaniel, > > Very few comments. Just as a reminder, patch 0001 is already ACKed. > On patch 0002: > > Is it possible that we later define a spec with 'dflt' > contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs to be > 32bits. Fixed. It was just a typo. > When otp_config_fini is it called ? Sadly, never. I admit that I am cargo-culting the lack of calling otp_config_fini(). Surely there must be a way to sanely tear this down when 389 shuts down? > On patch 0003: > > In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS > (slapi-plugin.h). Fixed. > In ipa-otp-lasttoken:preop_mod , the test is_allowed is done > on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry > untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that the > entry you want to check ? Yes, the code is correct as written. We check to see if a change to the existing state would cause bad behavior. Then, if any such change is attempted (ipa_otp_lasttoken.c:205) we reject it. In the future we might improve this to be more granular regarding the values of the change. But for now it is good enough. > On patch 0004: > In otp_config.c:otp_config_window you may use > SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) Fixed. > in otp_token: bvtod if 'code' contains non digit > character ,'out' is not reset before return. Yes. If the input value is invalid, the function returns an error status and the state of the output is undefined. This is pretty normal behavior. I think the first three patches are ready for merge. The last patch still needs some polish on my part. However, the first three also fix an important, independent bug. So let's merge them as soon as you feel they are ready. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Preliminary-refactoring-of-libotp-files.patch Type: text/x-patch Size: 24175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Make-token-auth-and-sync-windows-configurable.patch Type: text/x-patch Size: 39872 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Move-authentication-configuration-cache-into-libotp.patch Type: text/x-patch Size: 38470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Enable-last-token-deletion-when-password-auth-type-i.patch Type: text/x-patch Size: 10633 bytes Desc: not available URL: From tbabej at redhat.com Tue Dec 2 16:01:59 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Dec 2014 17:01:59 +0100 Subject: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show In-Reply-To: <547DD753.1040405@redhat.com> References: <547DD00A.7030705@redhat.com> <547DD753.1040405@redhat.com> Message-ID: <547DE277.4080406@redhat.com> On 12/02/2014 04:14 PM, Jan Cholasta wrote: > Hi, > > Dne 2.12.2014 v 15:43 Tomas Babej napsal(a): >> Hi, >> >> Makes ipaassignedidview a default attribute and takes care about the >> conversion from the DN to the proper ID view name. >> >> https://fedorahosted.org/freeipa/ticket/4774 > > Since you are converting the value from DN to primary key string, the > type of the ipassignedview param should be changed to Str, for > consistency with existing code. > > Honza > I see. Actually during the development, I craved for simple output_normalizer option in the Param itself, which would apply the output normalization funtion after the post_callback, instead of having to mangle the entry_attrs in the post callback of each command (and could potentionally apply on the client). Would there a be not-so-hard way to do this in the framework? My understanding is that Output classes are quite decoupled from the Params they resulted from, and at the point we're printing the information via the textui, we're no longer aware what Param instance it originated from. Updated patch attached. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0289-2-hosts-Display-assigned-ID-view-by-default-in-host-fi.patch Type: text/x-patch Size: 6846 bytes Desc: not available URL: From npmccallum at redhat.com Tue Dec 2 16:06:15 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 11:06:15 -0500 Subject: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type In-Reply-To: <1415898295.9116.12.camel@redhat.com> References: <1415898295.9116.12.camel@redhat.com> Message-ID: <1417536375.5864.50.camel@redhat.com> On Thu, 2014-11-13 at 12:04 -0500, Nathaniel McCallum wrote: > Additionally, fix a small bug in ipa-kdb so that the disabled User > Auth Type is properly handled. > > https://fedorahosted.org/freeipa/ticket/4720 I still need a review of this. Any takers? From npmccallum at redhat.com Tue Dec 2 16:12:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 11:12:11 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1415314821.5013.3.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> Message-ID: <1417536731.5864.51.camel@redhat.com> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: > On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > > > ----- Original Message ----- > > > On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > > Patch attached. > > > > > > I'm curious - what is the purpose of this patch? To prevent 1 second timeouts > > > and re-transmits when OTP is in place? > > > > > > What is the expected performance impact? Could it be configured for OTP > > > separately - somehow? (I guess that it is not possible now ...) > > > > It benefits also communication of large packets (when large MS-PAC or CAMMAC AD Data > > are attached), so it is a better choice for IPA in general. Especially given we have > > multiple KDC processes configured we do not want clients wasting KDC resources by > > making multiple processes do the same operation. > > So apparently this patch never got reviewed over a year ago. > > It was related to a bug which was opened in SSSD. However, when it > became clear we wanted to solve this in FreeIPA, the SSSD bug was closed > but no corresponding FreeIPA bug was opened. The patch then fell through > the cracks. > > Without this patch, if OTP validation runs long we get retransmits and > failures. > > One question I have is how to handle this for upgrades since (I think) > this patch only handles new installs. > > Anyway, this patch is somewhat urgent now. So help is appreciated. > > I have attached a rebased version which has no other changes. I still need a review on this. Any takers? From mkosek at redhat.com Tue Dec 2 16:12:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Dec 2014 17:12:12 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1417535768.5864.46.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547DB914.7050605@redhat.com> <1417535768.5864.46.camel@redhat.com> Message-ID: <547DE4DC.9030708@redhat.com> On 12/02/2014 04:56 PM, Nathaniel McCallum wrote: > On Tue, 2014-12-02 at 14:05 +0100, thierry bordaz wrote: >> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: >> >>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>>>> On 7.11.2014 08:58, Martin Kosek wrote: >>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>>>> >>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>>>> how to >>>>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>>>> However, >>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>>>> on the >>>>>>>>>>>> server. What am I doing wrong? >>>>>>>>>>>> >>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>>>> works >>>>>>>>>>>> just fine. >>>>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>>>> attribute >>>>>>>>>>> names. >>>>>>>>>> Thanks Nathaniel! >>>>>>>>>> >>>>>>>>>>> The above known issue still remains. >>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>>>> extension >>>>>>>>>> should work just fine, AFAIK. >>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>>>> they aren't considered in the update. >>>>>>>>> Without the blank line it works fine. >>>>>>>> Thanks for the catch! >>>>>>>> >>>>>>>> Here is a version without the blank line. >>>>>>> I forgot to remove the old steps defines. This patch performs this >>>>>>> cleanup. >>>>>> I am now wondering, is the global config object really the nest place to >>>>>> add these OTP specific settings? >>>>>> >>>>>> I would prefer not to overload the object and instead: >>>>>> - create new ipaOTPConfig objectclass >>>>>> - add it to cn=otp,$SUFFIX >>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>>>> of dnsconfig-* and trustconfig-* commands >>>>>> >>>>>> IMO, this would allow more flexibility for the OTP settings and would >>>>>> also scale better for the future updates. >>>>> +1 >>>>> >>>>> I will comment the patch as if ^^ would not exist because it will still be >>>>> needed in the new plugin. >>>>> >>>>> Because of ^^ I did not test, just read. >>>>> >>>>> 1. Got: >>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>>>> recommended in array initializers >>>>> >>>>> Please run: >>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>>>> in install/ui directory >>>>> >>>>> The goal is no have no warnings and errors. >>>>> >>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>>>> permission >>>> +1. Though if we go with OTP config, it should be called >>>> >>>> System: Read OTP Configuration >>>> >>>> Martin >>> Attached is a new set of patches that replaces this single patch. This >>> now fixes multiple issues. >>> >>> I now create two new entries: >>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX >>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX >>> >>> There are two corresponding CLI commands: >>> * totpconfig-(show|mod) >>> * hotpconfig-(show|mod) >>> >>> There is no UI support for this yet (pointers welcome). >>> >>> This is designed so that eventually tokens can grow a per-token >>> override, but I have not yet implemented this feature (it should be easy >>> in the future). >>> >>> Additionally, I had to do some shared refactoring to address issues in >>> ipa-otp-lasttoken, which is why all of these are now merged into a >>> single patch set. >>> >>> Nathaniel >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Hello Nathaniel, >> >> Very few comments. > > Just as a reminder, patch 0001 is already ACKed. > >> On patch 0002: >> >> Is it possible that we later define a spec with 'dflt' >> contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs to be >> 32bits. > > Fixed. It was just a typo. > >> When otp_config_fini is it called ? > > Sadly, never. I admit that I am cargo-culting the lack of calling > otp_config_fini(). Surely there must be a way to sanely tear this down > when 389 shuts down? > >> On patch 0003: >> >> In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS >> (slapi-plugin.h). > > Fixed. > >> In ipa-otp-lasttoken:preop_mod , the test is_allowed is done >> on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry >> untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that the >> entry you want to check ? > > Yes, the code is correct as written. We check to see if a change to the > existing state would cause bad behavior. Then, if any such change is > attempted (ipa_otp_lasttoken.c:205) we reject it. In the future we might > improve this to be more granular regarding the values of the change. But > for now it is good enough. > >> On patch 0004: >> In otp_config.c:otp_config_window you may use >> SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) > > Fixed. > >> in otp_token: bvtod if 'code' contains non digit >> character ,'out' is not reset before return. > > Yes. If the input value is invalid, the function returns an error status > and the state of the output is undefined. This is pretty normal > behavior. > > I think the first three patches are ready for merge. The last patch > still needs some polish on my part. However, the first three also fix an > important, independent bug. So let's merge them as soon as you feel they > are ready. > > Nathaniel If the Python parts are also OK and acked by Petr Vobornik or anyone else then sure, we can merge them. By the fourth part you mean patch 0004, right? It somehow ended as second in my MUA. Martin From simo at redhat.com Tue Dec 2 16:21:07 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 2 Dec 2014 11:21:07 -0500 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <547DD31C.1020106@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> Message-ID: <20141202112107.1d0032d7@willson.usersys.redhat.com> On Tue, 02 Dec 2014 15:56:28 +0100 Petr Spacek wrote: > On 1.12.2014 17:12, Simo Sorce wrote: > > On Mon, 01 Dec 2014 16:17:54 +0100 > > Petr Spacek wrote: > > > >> On 14.11.2014 17:31, Petr Spacek wrote: > >>> On 14.11.2014 02:22, Simo Sorce wrote: > >>>> On Tue, 11 Nov 2014 16:29:51 +0100 > >>>> Petr Spacek wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> this thread is about RFE > >>>>> "IPA servers when installed should register themselves in the > >>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 > >>>>> > >>>>> It is not a complete design, just a raw idea. > >>>>> > >>>>> > >>>>> Use case > >>>>> ======== > >>>>> FreeIPA installation to a network with existing DNS > >>>>> infrastructure + network administrator who is not willing to > >>>>> add/maintain new DNS servers "just for FreeIPA". > >>>>> > >>>>> > >>>>> High-level idea > >>>>> =============== > >>>>> - Transform dns* commands from FreeIPA framework to equivalent > >>>>> "nsupdate" commands and send DNS updates to existing DNS > >>>>> servers. > >>>>> - Provide necessary encryption/signing keys to nsupdate. > >>>>> > >>>>> > >>>>> 1) Integration to FreeIPA framework > >>>>> =================================== > >>>>> First of all, we need to decide if "external DNS integration" > >>>>> can be used at the same time with FreeIPA-integrated DNS or not. > >>>>> Side-question is what to do if a first server is installed with > >>>>> external-DNS but another replica is being installed with > >>>>> integrated-DNS and so on. > >>>> > >>>> I think being able to integrate with an external DNS is > >>>> important, and not just at the server level, being able to > >>>> distribute TSIG keys to client would be nice too, though a lot > >>>> less important, than getting server integration.. > >>> > >>> Using TSIG on many clients is very problematic. Keep in mind that > >>> TSIG is basically HMAC computed using symmetric key so: > >>> a) Every client would have to use the same key - this is a > >>> security nightmare. b) We would have to distribute and maintain > >>> many keys for many^2 clients, which is an administrative > >>> nightmare. > >>> > >>> For *clients* I would rather stay with GSS-TSIG which is much more > >>> manageable because we can use Kerberos trust and Keytab > >>> distribution is already solved by ipa-client-install. > >>> > >>> Alternative for clients would be to use FreeIPA server as proxy > >>> which encapsulates TSIG keys and issues update requests on behalf > >>> of clients. This would be FreeIPA-specific but any > >>> TSIG-distribution mechanism will be FreeIPA-specific anyway. > >>> > >>> TSIG standard explicitly says that there is no standardized > >>> distribution mechanism. > >>> > >>>>> In other words, the question is if current "dns.py" plugin > >>>>> shipped with FreeIPA framework should be: > >>>>> > >>>>> a) Extended dns.py with dnsexternal-* commands > >>>>> ---------------------------------------------- > >>>>> Disadvantages: > >>>>> - It complicate FreeIPA DNS interface which is a complex beast > >>>>> even now. > >>>>> - We would have add condition to every DNS API call in > >>>>> installers which would increase horribleness of the installer > >>>>> code even more (or add another layer of abstraction...). > >>>> > >>>> I agree having a special command is undesirable. > >>>>> > >>>>> - I don't see a point in using integrated-DNS with external-DNS > >>>>> at the same time. To use integrated-DNS you have to get a > >>>>> proper DNS delegation from parent domain - and if you can get > >>>>> the delegation then there is no point in using external DNS ... > >>>> > >>>> I disagree on this point, it makes a lot of sense to have some > >>>> zones maintained by IPA and ... some not. > >>>> > >>>>> Advantages: > >>>>> - You can use external & integrated DNS at the same time. > >>>> > >>>> We can achieve the same w/o a new ipa level command. > >>> > >>> This needs to be decided by FreeIPA framework experts ... > >>> > >>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This > >>> proxy would provide all ipa dns* commands and dispatch user-issued > >>> commands to appropriate FreeIPA-plugin (internal-dns or > >>> external-dns). This decision could depend on some values in LDAP. > >>> > >>>>> b) Replace dns.py with another implementation of current > >>>>> dnszone-* & dnsrecord-* API. > >>>>> --------------------------------------------------------------------- > >>>>> This seems like a cleaner approach to me. It could be shipped as > >>>>> ipa-server-dns-external package (opposed to "standard" > >>>>> ipa-server-dns package). > >>>>> > >>>>> Advantages: > >>>>> - It could seamlessly work with FreeIPA client installer because > >>>>> the dns*->nsupdate command transformation would be done on > >>>>> FreeIPA server and client doesn't need to know about it. > >>>>> - Does not require re-training/not much new documentation > >>>>> because commands are the same. > >>>>> > >>>>> Disadvantages: > >>>>> - You can't use integrated & external DNS at the same time (but > >>>>> I don't think it justifies the added complexity). > >>>> > >>>> I disagree. > >>>> > >>>> One of the reason to use a mix is to allow smooth migrations > >>>> where zones are moved into (or out of) IPA one by one. > >>> > >>> Good point, I agree. I will focus on supporting both (internal and > >>> external) DNS at the same time. > >>> > >>>>> Petr^3 or anyone else, what do you propose? > >>>> > >>>> I think what I'd like to see is to be able to configure a DNS > >>>> zone in LDAP and mark it external. > >>>> The zone would held the TSIG keys necessary to perform DNS > >>>> updates. > >>>> > >>>> When the regular ipa dnsrecord-add etc... commands are called, > >>>> the framework detects that the zone is "external", fewttches the > >>>> TSIG key (if the user has access to it) and spawn an nsupdate > >>>> command that will perform the update against whatever DNS server > >>>> is authoritative for the zone. > >>>> > >>>> Some commands may be disabled if the zone is external and > >>>> appropriate errors would be returned. > >>> > >>> Correct, this will be inevitable. > >>> > >>>>> 2) Authentication to external DNS server/keys > >>>>> ============================================= > >>>>> This is separate problem from FreeIPA framework integration. > >>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) > >>>>> or keytabs (for DNS GSS-TSIG) and distribute them somehow to > >>>>> replicas so every replica can update DNS records as necessary. > >>>> > >>>> For TSIG keys I think we should just store them in a LDAP record, > >>>> see above. > >>> > >>> Without any encryption? Am I missing something? > >>> > >>>> For keytabs we can simply store them just like any other > >>>> kerberos key if we really need it (in a trust case for example, > >>>> we may not need a new keytab, we may be allowed to use our own > >>>> credentials through the trust. So we'll need to explore a bit > >>>> how to properly express that in configuration. REtrieval ok > >>>> keytabs is then just a matter of running ipa-getkeytab -r on the > >>>> replica that needs it. > >>>> > >>>>> This will be the funny part because in case of AD trusts we have > >>>>> chicken-egg problem. You need to establish trust to get ticket > >>>>> for DNS/dc1.ad.example at AD principal but you can't (I guess) > >>>>> establish trust until proper DNS records are in place ... > >>>> > >>>> No, in this case we should create the records at trust > >>>> establishment time using the admin credentials we have been > >>>> provided. NO chicken-egg issue. > >>> > >>> Sorry, we surely *have* a chicken-egg issue because > >>> ipa-server-install is completely separate step from from > >>> ipa-adtrust-install which is completely separate from ipa > >>> trust-add. (And there is nothing which forces user to establish AD > >>> trust right after ipa-server-install finished.) > >>> > >>> Also, in some cases it is not possible to use the same credentials > >>> for trust establishment and for DNS updates on AD. Think about > >>> one-way trust or possibly two-way trust but established using > >>> pre-shared trust secret (which is AFAIK not usable for kinit). > >>> > >>> Alexander, could you clarify if it is possible to create an AD > >>> trust *without* DNS records for FreeIPA side of the trust? > >>> > >>> Another problem is that reliance on AD trusts would effectively > >>> prevent interoperability with non-AD DNS servers (think Infoblox > >>> or standard BIND). > >>> > >>> I tend to think that we will need to obtain credentials (AD > >>> login/pass/keytab/TSIG key) as one of ipa-server-install > >>> parameters so all DNS updates can be done right away. This would > >>> allow us have ipa-server-install script which in fact produces > >>> *working* FreeIPA domain. In other cases ipa-server-install would > >>> end but the FreeIPA domain would not be functional because of > >>> missing records in DNS. > >>> > >>>>> For 'experimental' phase I would go with pre-populated CCcache, > >>>>> i.e. admin will manually do kinit Administrator at AD and then run > >>>>> FreeIPA installer. > >>>> > >>>> We already to this, so there is no need to invent anything here > >>>> IMO. > >>> > >>> Except for cases mentioned above ... > >>> > >>>>> Maybe we can re-use trust secret somehow? I don't know, I will > >>>>> reach out to AD experts with questions. > >>>>> > >>>>> This area needs more research but for now it seems feasible to > >>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs > >>>>> so "only" the chicken-egg problem is left. > >>>>> > >>>>> This will need new LDAP schema but I will propose something when > >>>>> I'm done with investigation. > >>>> > >>>> Please let me know if you agree with a new zone type as a way to > >>>> "forward" updates. > >>> > >>> Generally I agree, it was my plan too. My main concern is not > >>> about LDAP structure but about FreeIPA framework and about > >>> workflow in general. It will be fun to extend the spaghetti code > >>> we have ... > >> > >> Ping :-) I would like to move the discussion forward. > >> > >> Alexander, could you please comment on authentication to AD > >> mentioned above? > >> > >> Simo and everybody else, what do you think about client use-case, > >> i.e. forwarding DNS updates from FreeIPA clients to external DNS > >> infrastructure? What about security implications (keeping in mind > >> that TSIG keys are symmetric)? > >> > >> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy > >> instead of nsupdate command (to hide TSIG key behind FreeIPA)? > > > > Remind me this, when a client tries to update the DNS, does it > > always contact its own DNS server first, or does it try to go > > straight to the authoritative DNS server? > > It should go straight to authoritative servers listed in NS records. > > > I do not like the XML-RPC->DNS approach as it requires a special > > client, leaving out the majority of clients. > > Yes, it is an option of last resort (because I don't see a way how to > be compatible with standard clients, see the point above). > > > Also, I am thinking that we only _need_ to set infrastructure > > relevant names (like IPA servers SRV records), but if someone > > decides not to use IPA for the DNS we may decide that it is not our > > responsibility to provide a full end-to-end client dns update > > solution. > > If we can agree on that then I'm fine with it. Yes the more I think of it, the more I prefer to wait in trying to solve the clients problem. > > So I would concentrate on making it possible for IPA *Servers* to > > use a private TSIG key to update infrastructure relevant names, and > > possibly defer the clients side of the problem. > > Speaking about native clients, two-way AD trust should nicely work > with clients because clients could go straight to the AD and > authenticate using host keytab from FreeIPA realm. It will not work > in other cases but it is still better than nothing. Yes, this has been accounted for. > > We could use an internal bus on the server to allow the ipa > > framework to use nsupdate w/o gaining direct access to the TSIG > > key, this way admins can use ipa dnsrecod-add and friends w/o > > exposing the key. > > I agree with the idea but it depends on an authorization daemon you > have proposed earlier (in different discussion). Do you see it as > reasonable goal for FreeIPA 4.2 time-span? I wouldn't say a definite no, but I am not confident we can. > If the authorization daemon is too far away, would it be okay to > support external DNS domains only for ipa* installers but do not > support it for FreeIPA users? (I.e. basically store the key in HSM > which is not accessible to users - that is what we do with DNSSEC > keys now.) Yes I think it would be fine as a first step. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Dec 2 16:23:43 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Dec 2014 17:23:43 +0100 Subject: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show In-Reply-To: <547DE277.4080406@redhat.com> References: <547DD00A.7030705@redhat.com> <547DD753.1040405@redhat.com> <547DE277.4080406@redhat.com> Message-ID: <547DE78F.8090104@redhat.com> Dne 2.12.2014 v 17:01 Tomas Babej napsal(a): > > On 12/02/2014 04:14 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 2.12.2014 v 15:43 Tomas Babej napsal(a): >>> Hi, >>> >>> Makes ipaassignedidview a default attribute and takes care about the >>> conversion from the DN to the proper ID view name. >>> >>> https://fedorahosted.org/freeipa/ticket/4774 >> >> Since you are converting the value from DN to primary key string, the >> type of the ipassignedview param should be changed to Str, for >> consistency with existing code. >> >> Honza >> > > I see. Actually during the development, I craved for simple > output_normalizer option in the Param itself, which would apply the > output normalization funtion after the post_callback, > instead of having to mangle the entry_attrs in the post callback of each > command (and could potentionally apply on the client). Would there a be > not-so-hard way to do this in the framework? My understanding is that > Output classes are quite decoupled from the Params they resulted from, > and at the point we're printing the information via the textui, we're no > longer aware what Param instance it originated from. This wouldn't solve the real problem in this case, which is that we do not support one-to-many relationships between objects in the framework (and our support for many-to-many relationships is clunky). I plan to fix this with . > > Updated patch attached. > -- Jan Cholasta From npmccallum at redhat.com Tue Dec 2 16:24:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 11:24:35 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <547DE4DC.9030708@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547DB914.7050605@redhat.com> <1417535768.5864.46.camel@redhat.com> <547DE4DC.9030708@redhat.com> Message-ID: <1417537475.5864.60.camel@redhat.com> On Tue, 2014-12-02 at 17:12 +0100, Martin Kosek wrote: > On 12/02/2014 04:56 PM, Nathaniel McCallum wrote: > > On Tue, 2014-12-02 at 14:05 +0100, thierry bordaz wrote: > >> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > >> > >>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > >>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: > >>>>> On 7.11.2014 08:58, Martin Kosek wrote: > >>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > >>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > >>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > >>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: > >>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > >>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>>> This patch gives the administrator variables to control the size of > >>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. > >>>>>>>>>>>> > >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 > >>>>>>>>>>>> > >>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know > >>>>>>>>>>>> how to > >>>>>>>>>>>> solve. This patch changes the schema in > >>>>>>>>>>>> install/share/60ipaconfig.ldif. > >>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. > >>>>>>>>>>>> However, > >>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up > >>>>>>>>>>>> on the > >>>>>>>>>>>> server. What am I doing wrong? > >>>>>>>>>>>> > >>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch > >>>>>>>>>>>> works > >>>>>>>>>>>> just fine. > >>>>>>>>>>> This new version takes into account the new (proper) OIDs and > >>>>>>>>>>> attribute > >>>>>>>>>>> names. > >>>>>>>>>> Thanks Nathaniel! > >>>>>>>>>> > >>>>>>>>>>> The above known issue still remains. > >>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list > >>>>>>>>>> extension > >>>>>>>>>> should work just fine, AFAIK. > >>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so > >>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so > >>>>>>>>> they aren't considered in the update. > >>>>>>>>> Without the blank line it works fine. > >>>>>>>> Thanks for the catch! > >>>>>>>> > >>>>>>>> Here is a version without the blank line. > >>>>>>> I forgot to remove the old steps defines. This patch performs this > >>>>>>> cleanup. > >>>>>> I am now wondering, is the global config object really the nest place to > >>>>>> add these OTP specific settings? > >>>>>> > >>>>>> I would prefer not to overload the object and instead: > >>>>>> - create new ipaOTPConfig objectclass > >>>>>> - add it to cn=otp,$SUFFIX > >>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example > >>>>>> of dnsconfig-* and trustconfig-* commands > >>>>>> > >>>>>> IMO, this would allow more flexibility for the OTP settings and would > >>>>>> also scale better for the future updates. > >>>>> +1 > >>>>> > >>>>> I will comment the patch as if ^^ would not exist because it will still be > >>>>> needed in the new plugin. > >>>>> > >>>>> Because of ^^ I did not test, just read. > >>>>> > >>>>> 1. Got: > >>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > >>>>> recommended in array initializers > >>>>> > >>>>> Please run: > >>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf > >>>>> in install/ui directory > >>>>> > >>>>> The goal is no have no warnings and errors. > >>>>> > >>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed > >>>>> permission > >>>> +1. Though if we go with OTP config, it should be called > >>>> > >>>> System: Read OTP Configuration > >>>> > >>>> Martin > >>> Attached is a new set of patches that replaces this single patch. This > >>> now fixes multiple issues. > >>> > >>> I now create two new entries: > >>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > >>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > >>> > >>> There are two corresponding CLI commands: > >>> * totpconfig-(show|mod) > >>> * hotpconfig-(show|mod) > >>> > >>> There is no UI support for this yet (pointers welcome). > >>> > >>> This is designed so that eventually tokens can grow a per-token > >>> override, but I have not yet implemented this feature (it should be easy > >>> in the future). > >>> > >>> Additionally, I had to do some shared refactoring to address issues in > >>> ipa-otp-lasttoken, which is why all of these are now merged into a > >>> single patch set. > >>> > >>> Nathaniel > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> > >> Hello Nathaniel, > >> > >> Very few comments. > > > > Just as a reminder, patch 0001 is already ACKed. > > > >> On patch 0002: > >> > >> Is it possible that we later define a spec with 'dflt' > >> contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs to be > >> 32bits. > > > > Fixed. It was just a typo. > > > >> When otp_config_fini is it called ? > > > > Sadly, never. I admit that I am cargo-culting the lack of calling > > otp_config_fini(). Surely there must be a way to sanely tear this down > > when 389 shuts down? > > > >> On patch 0003: > >> > >> In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS > >> (slapi-plugin.h). > > > > Fixed. > > > >> In ipa-otp-lasttoken:preop_mod , the test is_allowed is done > >> on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry > >> untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that the > >> entry you want to check ? > > > > Yes, the code is correct as written. We check to see if a change to the > > existing state would cause bad behavior. Then, if any such change is > > attempted (ipa_otp_lasttoken.c:205) we reject it. In the future we might > > improve this to be more granular regarding the values of the change. But > > for now it is good enough. > > > >> On patch 0004: > >> In otp_config.c:otp_config_window you may use > >> SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) > > > > Fixed. > > > >> in otp_token: bvtod if 'code' contains non digit > >> character ,'out' is not reset before return. > > > > Yes. If the input value is invalid, the function returns an error status > > and the state of the output is undefined. This is pretty normal > > behavior. > > > > I think the first three patches are ready for merge. The last patch > > still needs some polish on my part. However, the first three also fix an > > important, independent bug. So let's merge them as soon as you feel they > > are ready. > > > > Nathaniel > > If the Python parts are also OK and acked by Petr Vobornik or anyone else then > sure, we can merge them. Python code is confined to patch 0004, so I think we just need Thierry's ACK on 0001-0003. > By the fourth part you mean patch 0004, right? It somehow ended as second in my > MUA. Yes. This patch 0004 is basically the rework of patch 0074 which is the main topic of this thread. But doing it properly meant sharing code (0001 and 0002) with another bugfix (0003). Thus, if we merge 0001-0003 we're back to just evaluating 0004/0074. Nathaniel From ssorce at redhat.com Tue Dec 2 16:36:48 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 2 Dec 2014 11:36:48 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1417536731.5864.51.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> Message-ID: <20141202113648.4c249112@willson.usersys.redhat.com> On Tue, 02 Dec 2014 11:12:11 -0500 Nathaniel McCallum wrote: > On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: > > On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > > > > > ----- Original Message ----- > > > > On 3.10.2013 23:43, Nathaniel McCallum wrote: > > > > > Patch attached. > > > > > > > > I'm curious - what is the purpose of this patch? To prevent 1 > > > > second timeouts and re-transmits when OTP is in place? > > > > > > > > What is the expected performance impact? Could it be configured > > > > for OTP separately - somehow? (I guess that it is not possible > > > > now ...) > > > > > > It benefits also communication of large packets (when large > > > MS-PAC or CAMMAC AD Data are attached), so it is a better choice > > > for IPA in general. Especially given we have multiple KDC > > > processes configured we do not want clients wasting KDC resources > > > by making multiple processes do the same operation. > > > > So apparently this patch never got reviewed over a year ago. > > > > It was related to a bug which was opened in SSSD. However, when it > > became clear we wanted to solve this in FreeIPA, the SSSD bug was > > closed but no corresponding FreeIPA bug was opened. The patch then > > fell through the cracks. > > > > Without this patch, if OTP validation runs long we get retransmits > > and failures. > > > > One question I have is how to handle this for upgrades since (I > > think) this patch only handles new installs. > > > > Anyway, this patch is somewhat urgent now. So help is appreciated. > > > > I have attached a rebased version which has no other changes. > > I still need a review on this. Any takers? The patch looks good to me Simo. -- Simo Sorce * Red Hat, Inc * New York From jpazdziora at redhat.com Tue Dec 2 16:36:54 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 2 Dec 2014 17:36:54 +0100 Subject: [Freeipa-devel] [PATCH 4] Removing the dependency on subscription-manager Message-ID: <20141202163654.GA25741@redhat.com> Hello, Martin suggests dependency on subscription-manager is no longer needed. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -------------- next part -------------- >From 4243c4016d5e9844e555f134ce091cf85c01fcb2 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora Date: Tue, 2 Dec 2014 17:33:43 +0100 Subject: [PATCH] Removing the dependency on subscription-manager. https://fedorahosted.org/freeipa/ticket/4783 --- freeipa.spec.in | 3 --- 1 file changed, 3 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 9b12c20899e729cedacdee470f8f2b13250af4e0..11af2d6626cfcba60ef3e4a63edc262e6d1ca10b 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -133,9 +133,6 @@ Requires(post): selinux-policy-base Requires: slapi-nis >= 0.54.1-1 Requires: pki-ca >= 10.2.1-0.1 Requires: pki-kra >= 10.2.1-0.1 -%if 0%{?rhel} -Requires: subscription-manager -%endif Requires(preun): python systemd-units Requires(postun): python systemd-units Requires: python-dns >= 1.11.1 -- 1.9.3 From tbordaz at redhat.com Tue Dec 2 16:39:33 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 02 Dec 2014 17:39:33 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1417537475.5864.60.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547DB914.7050605@redhat.com> <1417535768.5864.46.camel@redhat.com> <547DE4DC.9030708@redhat.com> <1417537475.5864.60.camel@redhat.com> Message-ID: <547DEB45.4000404@redhat.com> On 12/02/2014 05:24 PM, Nathaniel McCallum wrote: > On Tue, 2014-12-02 at 17:12 +0100, Martin Kosek wrote: >> On 12/02/2014 04:56 PM, Nathaniel McCallum wrote: >>> On Tue, 2014-12-02 at 14:05 +0100, thierry bordaz wrote: >>>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: >>>> >>>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >>>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>>>>>> On 7.11.2014 08:58, Martin Kosek wrote: >>>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>>>>>> >>>>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>>>>>> how to >>>>>>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>>>>>> However, >>>>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>>>>>> on the >>>>>>>>>>>>>> server. What am I doing wrong? >>>>>>>>>>>>>> >>>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>>>>>> works >>>>>>>>>>>>>> just fine. >>>>>>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>>>>>> attribute >>>>>>>>>>>>> names. >>>>>>>>>>>> Thanks Nathaniel! >>>>>>>>>>>> >>>>>>>>>>>>> The above known issue still remains. >>>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>>>>>> extension >>>>>>>>>>>> should work just fine, AFAIK. >>>>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>>>>>> they aren't considered in the update. >>>>>>>>>>> Without the blank line it works fine. >>>>>>>>>> Thanks for the catch! >>>>>>>>>> >>>>>>>>>> Here is a version without the blank line. >>>>>>>>> I forgot to remove the old steps defines. This patch performs this >>>>>>>>> cleanup. >>>>>>>> I am now wondering, is the global config object really the nest place to >>>>>>>> add these OTP specific settings? >>>>>>>> >>>>>>>> I would prefer not to overload the object and instead: >>>>>>>> - create new ipaOTPConfig objectclass >>>>>>>> - add it to cn=otp,$SUFFIX >>>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>>>>>> of dnsconfig-* and trustconfig-* commands >>>>>>>> >>>>>>>> IMO, this would allow more flexibility for the OTP settings and would >>>>>>>> also scale better for the future updates. >>>>>>> +1 >>>>>>> >>>>>>> I will comment the patch as if ^^ would not exist because it will still be >>>>>>> needed in the new plugin. >>>>>>> >>>>>>> Because of ^^ I did not test, just read. >>>>>>> >>>>>>> 1. Got: >>>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>>>>>> recommended in array initializers >>>>>>> >>>>>>> Please run: >>>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>>>>>> in install/ui directory >>>>>>> >>>>>>> The goal is no have no warnings and errors. >>>>>>> >>>>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>>>>>> permission >>>>>> +1. Though if we go with OTP config, it should be called >>>>>> >>>>>> System: Read OTP Configuration >>>>>> >>>>>> Martin >>>>> Attached is a new set of patches that replaces this single patch. This >>>>> now fixes multiple issues. >>>>> >>>>> I now create two new entries: >>>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX >>>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX >>>>> >>>>> There are two corresponding CLI commands: >>>>> * totpconfig-(show|mod) >>>>> * hotpconfig-(show|mod) >>>>> >>>>> There is no UI support for this yet (pointers welcome). >>>>> >>>>> This is designed so that eventually tokens can grow a per-token >>>>> override, but I have not yet implemented this feature (it should be easy >>>>> in the future). >>>>> >>>>> Additionally, I had to do some shared refactoring to address issues in >>>>> ipa-otp-lasttoken, which is why all of these are now merged into a >>>>> single patch set. >>>>> >>>>> Nathaniel >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Hello Nathaniel, >>>> >>>> Very few comments. >>> Just as a reminder, patch 0001 is already ACKed. >>> >>>> On patch 0002: >>>> >>>> Is it possible that we later define a spec with 'dflt' >>>> contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs to be >>>> 32bits. >>> Fixed. It was just a typo. >>> >>>> When otp_config_fini is it called ? >>> Sadly, never. I admit that I am cargo-culting the lack of calling >>> otp_config_fini(). Surely there must be a way to sanely tear this down >>> when 389 shuts down? >>> >>>> On patch 0003: >>>> >>>> In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS >>>> (slapi-plugin.h). >>> Fixed. >>> >>>> In ipa-otp-lasttoken:preop_mod , the test is_allowed is done >>>> on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry >>>> untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that the >>>> entry you want to check ? >>> Yes, the code is correct as written. We check to see if a change to the >>> existing state would cause bad behavior. Then, if any such change is >>> attempted (ipa_otp_lasttoken.c:205) we reject it. In the future we might >>> improve this to be more granular regarding the values of the change. But >>> for now it is good enough. >>> >>>> On patch 0004: >>>> In otp_config.c:otp_config_window you may use >>>> SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) >>> Fixed. >>> >>>> in otp_token: bvtod if 'code' contains non digit >>>> character ,'out' is not reset before return. >>> Yes. If the input value is invalid, the function returns an error status >>> and the state of the output is undefined. This is pretty normal >>> behavior. >>> >>> I think the first three patches are ready for merge. The last patch >>> still needs some polish on my part. However, the first three also fix an >>> important, independent bug. So let's merge them as soon as you feel they >>> are ready. >>> >>> Nathaniel >> If the Python parts are also OK and acked by Petr Vobornik or anyone else then >> sure, we can merge them. > Python code is confined to patch 0004, so I think we just need Thierry's > ACK on 0001-0003. Nathaniel, Thanks for all your explanations. ACK for the pacthes 0001-0002-0003. regarding the DS plugin part of 0004, the patch is good to me. For the ipa plugins part I am too novice. thanks thierry >> By the fourth part you mean patch 0004, right? It somehow ended as second in my >> MUA. > Yes. This patch 0004 is basically the rework of patch 0074 which is the > main topic of this thread. But doing it properly meant sharing code > (0001 and 0002) with another bugfix (0003). Thus, if we merge 0001-0003 > we're back to just evaluating 0004/0074. > > Nathaniel > > From mkosek at redhat.com Tue Dec 2 16:48:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Dec 2014 17:48:43 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <20141202113648.4c249112@willson.usersys.redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> Message-ID: <547DED6B.4010206@redhat.com> On 12/02/2014 05:36 PM, Simo Sorce wrote: > On Tue, 02 Dec 2014 11:12:11 -0500 > Nathaniel McCallum wrote: > >> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: >>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>> >>>> ----- Original Message ----- >>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>> Patch attached. >>>>> >>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>> second timeouts and re-transmits when OTP is in place? >>>>> >>>>> What is the expected performance impact? Could it be configured >>>>> for OTP separately - somehow? (I guess that it is not possible >>>>> now ...) >>>> >>>> It benefits also communication of large packets (when large >>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice >>>> for IPA in general. Especially given we have multiple KDC >>>> processes configured we do not want clients wasting KDC resources >>>> by making multiple processes do the same operation. >>> >>> So apparently this patch never got reviewed over a year ago. >>> >>> It was related to a bug which was opened in SSSD. However, when it >>> became clear we wanted to solve this in FreeIPA, the SSSD bug was >>> closed but no corresponding FreeIPA bug was opened. The patch then >>> fell through the cracks. >>> >>> Without this patch, if OTP validation runs long we get retransmits >>> and failures. >>> >>> One question I have is how to handle this for upgrades since (I >>> think) this patch only handles new installs. >>> >>> Anyway, this patch is somewhat urgent now. So help is appreciated. >>> >>> I have attached a rebased version which has no other changes. >> >> I still need a review on this. Any takers? > > The patch looks good to me > > Simo. This fixes the new installations. Can you please refresh the memory what is the decision regarding the upgrades? From npmccallum at redhat.com Tue Dec 2 16:49:54 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 11:49:54 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <547DED6B.4010206@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> <547DED6B.4010206@redhat.com> Message-ID: <1417538994.5864.62.camel@redhat.com> On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: > On 12/02/2014 05:36 PM, Simo Sorce wrote: > > On Tue, 02 Dec 2014 11:12:11 -0500 > > Nathaniel McCallum wrote: > > > >> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: > >>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > >>>> > >>>> ----- Original Message ----- > >>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > >>>>>> Patch attached. > >>>>> > >>>>> I'm curious - what is the purpose of this patch? To prevent 1 > >>>>> second timeouts and re-transmits when OTP is in place? > >>>>> > >>>>> What is the expected performance impact? Could it be configured > >>>>> for OTP separately - somehow? (I guess that it is not possible > >>>>> now ...) > >>>> > >>>> It benefits also communication of large packets (when large > >>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice > >>>> for IPA in general. Especially given we have multiple KDC > >>>> processes configured we do not want clients wasting KDC resources > >>>> by making multiple processes do the same operation. > >>> > >>> So apparently this patch never got reviewed over a year ago. > >>> > >>> It was related to a bug which was opened in SSSD. However, when it > >>> became clear we wanted to solve this in FreeIPA, the SSSD bug was > >>> closed but no corresponding FreeIPA bug was opened. The patch then > >>> fell through the cracks. > >>> > >>> Without this patch, if OTP validation runs long we get retransmits > >>> and failures. > >>> > >>> One question I have is how to handle this for upgrades since (I > >>> think) this patch only handles new installs. > >>> > >>> Anyway, this patch is somewhat urgent now. So help is appreciated. > >>> > >>> I have attached a rebased version which has no other changes. > >> > >> I still need a review on this. Any takers? > > > > The patch looks good to me > > > > Simo. > > This fixes the new installations. Can you please refresh the memory what is the > decision regarding the upgrades? The need to fix upgrades will be documented. In the future, we will get /etc/krb.conf.d and we will ship a file there. Nathaniel From mkosek at redhat.com Tue Dec 2 16:51:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Dec 2014 17:51:53 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1417538994.5864.62.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> <547DED6B.4010206@redhat.com> <1417538994.5864.62.camel@redhat.com> Message-ID: <547DEE29.1010407@redhat.com> On 12/02/2014 05:49 PM, Nathaniel McCallum wrote: > On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: >> On 12/02/2014 05:36 PM, Simo Sorce wrote: >>> On Tue, 02 Dec 2014 11:12:11 -0500 >>> Nathaniel McCallum wrote: >>> >>>> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: >>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>>> >>>>>> ----- Original Message ----- >>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>>> Patch attached. >>>>>>> >>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>>> second timeouts and re-transmits when OTP is in place? >>>>>>> >>>>>>> What is the expected performance impact? Could it be configured >>>>>>> for OTP separately - somehow? (I guess that it is not possible >>>>>>> now ...) >>>>>> >>>>>> It benefits also communication of large packets (when large >>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice >>>>>> for IPA in general. Especially given we have multiple KDC >>>>>> processes configured we do not want clients wasting KDC resources >>>>>> by making multiple processes do the same operation. >>>>> >>>>> So apparently this patch never got reviewed over a year ago. >>>>> >>>>> It was related to a bug which was opened in SSSD. However, when it >>>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was >>>>> closed but no corresponding FreeIPA bug was opened. The patch then >>>>> fell through the cracks. >>>>> >>>>> Without this patch, if OTP validation runs long we get retransmits >>>>> and failures. >>>>> >>>>> One question I have is how to handle this for upgrades since (I >>>>> think) this patch only handles new installs. >>>>> >>>>> Anyway, this patch is somewhat urgent now. So help is appreciated. >>>>> >>>>> I have attached a rebased version which has no other changes. >>>> >>>> I still need a review on this. Any takers? >>> >>> The patch looks good to me >>> >>> Simo. >> >> This fixes the new installations. Can you please refresh the memory what is the >> decision regarding the upgrades? > > The need to fix upgrades will be documented. In the future, we will > get /etc/krb.conf.d and we will ship a file there. > > Nathaniel > Nobody reads the documentation :-) What is the implication for users doing client update (majority of them) and using OTP feature? From npmccallum at redhat.com Tue Dec 2 16:55:12 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 11:55:12 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <547DEE29.1010407@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> <547DED6B.4010206@redhat.com> <1417538994.5864.62.camel@redhat.com> <547DEE29.1010407@redhat.com> Message-ID: <1417539312.5864.64.camel@redhat.com> On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote: > On 12/02/2014 05:49 PM, Nathaniel McCallum wrote: > > On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: > >> On 12/02/2014 05:36 PM, Simo Sorce wrote: > >>> On Tue, 02 Dec 2014 11:12:11 -0500 > >>> Nathaniel McCallum wrote: > >>> > >>>> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: > >>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > >>>>>>>> Patch attached. > >>>>>>> > >>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 > >>>>>>> second timeouts and re-transmits when OTP is in place? > >>>>>>> > >>>>>>> What is the expected performance impact? Could it be configured > >>>>>>> for OTP separately - somehow? (I guess that it is not possible > >>>>>>> now ...) > >>>>>> > >>>>>> It benefits also communication of large packets (when large > >>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice > >>>>>> for IPA in general. Especially given we have multiple KDC > >>>>>> processes configured we do not want clients wasting KDC resources > >>>>>> by making multiple processes do the same operation. > >>>>> > >>>>> So apparently this patch never got reviewed over a year ago. > >>>>> > >>>>> It was related to a bug which was opened in SSSD. However, when it > >>>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was > >>>>> closed but no corresponding FreeIPA bug was opened. The patch then > >>>>> fell through the cracks. > >>>>> > >>>>> Without this patch, if OTP validation runs long we get retransmits > >>>>> and failures. > >>>>> > >>>>> One question I have is how to handle this for upgrades since (I > >>>>> think) this patch only handles new installs. > >>>>> > >>>>> Anyway, this patch is somewhat urgent now. So help is appreciated. > >>>>> > >>>>> I have attached a rebased version which has no other changes. > >>>> > >>>> I still need a review on this. Any takers? > >>> > >>> The patch looks good to me > >>> > >>> Simo. > >> > >> This fixes the new installations. Can you please refresh the memory what is the > >> decision regarding the upgrades? > > > > The need to fix upgrades will be documented. In the future, we will > > get /etc/krb.conf.d and we will ship a file there. > > > > Nathaniel > > > > Nobody reads the documentation :-) What is the implication for users doing > client update (majority of them) and using OTP feature? They will get spurious failures. Most will think it is a bug or a network issue. If the failures happen consistently enough, users might get locked out. Nathaniel From pvoborni at redhat.com Tue Dec 2 16:56:48 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 02 Dec 2014 17:56:48 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <547DEB45.4000404@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547DB914.7050605@redhat.com> <1417535768.5864.46.camel@redhat.com> <547DE4DC.9030708@redhat.com> <1417537475.5864.60.camel@redhat.com> <547DEB45.4000404@redhat.com> Message-ID: <547DEF50.4060401@redhat.com> On 12/02/2014 05:39 PM, thierry bordaz wrote: > On 12/02/2014 05:24 PM, Nathaniel McCallum wrote: >> On Tue, 2014-12-02 at 17:12 +0100, Martin Kosek wrote: >>> On 12/02/2014 04:56 PM, Nathaniel McCallum wrote: >>>> On Tue, 2014-12-02 at 14:05 +0100, thierry bordaz wrote: >>>>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: >>>>> >>>>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >>>>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>>>>>>> On 7.11.2014 08:58, Martin Kosek wrote: >>>>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>>> This patch gives the administrator variables to control >>>>>>>>>>>>>>> the size of >>>>>>>>>>>>>>> the authentication and synchronization windows for OTP >>>>>>>>>>>>>>> tokens. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NOTE: There is one known issue with this patch which I >>>>>>>>>>>>>>> don't know >>>>>>>>>>>>>>> how to >>>>>>>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear >>>>>>>>>>>>>>> correctly. >>>>>>>>>>>>>>> However, >>>>>>>>>>>>>>> the modifications to the pre-existing objectClass do not >>>>>>>>>>>>>>> show up >>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>> server. What am I doing wrong? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this >>>>>>>>>>>>>>> patch >>>>>>>>>>>>>>> works >>>>>>>>>>>>>>> just fine. >>>>>>>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>>>>>>> attribute >>>>>>>>>>>>>> names. >>>>>>>>>>>>> Thanks Nathaniel! >>>>>>>>>>>>> >>>>>>>>>>>>>> The above known issue still remains. >>>>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY >>>>>>>>>>>>> list >>>>>>>>>>>>> extension >>>>>>>>>>>>> should work just fine, AFAIK. >>>>>>>>>>>> You added a blank line to the LDIF file. This is an entry >>>>>>>>>>>> separator, so >>>>>>>>>>>> the objectClasses after the blank line don't belong to >>>>>>>>>>>> cn=schema, so >>>>>>>>>>>> they aren't considered in the update. >>>>>>>>>>>> Without the blank line it works fine. >>>>>>>>>>> Thanks for the catch! >>>>>>>>>>> >>>>>>>>>>> Here is a version without the blank line. >>>>>>>>>> I forgot to remove the old steps defines. This patch performs >>>>>>>>>> this >>>>>>>>>> cleanup. >>>>>>>>> I am now wondering, is the global config object really the nest >>>>>>>>> place to >>>>>>>>> add these OTP specific settings? >>>>>>>>> >>>>>>>>> I would prefer not to overload the object and instead: >>>>>>>>> - create new ipaOTPConfig objectclass >>>>>>>>> - add it to cn=otp,$SUFFIX >>>>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an >>>>>>>>> example >>>>>>>>> of dnsconfig-* and trustconfig-* commands >>>>>>>>> >>>>>>>>> IMO, this would allow more flexibility for the OTP settings and >>>>>>>>> would >>>>>>>>> also scale better for the future updates. >>>>>>>> +1 >>>>>>>> >>>>>>>> I will comment the patch as if ^^ would not exist because it >>>>>>>> will still be >>>>>>>> needed in the new plugin. >>>>>>>> >>>>>>>> Because of ^^ I did not test, just read. >>>>>>>> >>>>>>>> 1. Got: >>>>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra >>>>>>>> comma is not >>>>>>>> recommended in array initializers >>>>>>>> >>>>>>>> Please run: >>>>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>>>>>>> in install/ui directory >>>>>>>> >>>>>>>> The goal is no have no warnings and errors. >>>>>>>> >>>>>>>> 2. new attrs should be added to 'System: Read Global >>>>>>>> Configuration' managed >>>>>>>> permission >>>>>>> +1. Though if we go with OTP config, it should be called >>>>>>> >>>>>>> System: Read OTP Configuration >>>>>>> >>>>>>> Martin >>>>>> Attached is a new set of patches that replaces this single patch. >>>>>> This >>>>>> now fixes multiple issues. >>>>>> >>>>>> I now create two new entries: >>>>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX >>>>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX >>>>>> >>>>>> There are two corresponding CLI commands: >>>>>> * totpconfig-(show|mod) >>>>>> * hotpconfig-(show|mod) >>>>>> >>>>>> There is no UI support for this yet (pointers welcome). >>>>>> >>>>>> This is designed so that eventually tokens can grow a per-token >>>>>> override, but I have not yet implemented this feature (it should >>>>>> be easy >>>>>> in the future). >>>>>> >>>>>> Additionally, I had to do some shared refactoring to address >>>>>> issues in >>>>>> ipa-otp-lasttoken, which is why all of these are now merged into a >>>>>> single patch set. >>>>>> >>>>>> Nathaniel >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> Hello Nathaniel, >>>>> >>>>> Very few comments. >>>> Just as a reminder, patch 0001 is already ACKed. >>>> >>>>> On patch 0002: >>>>> Is it possible that we later define a spec with 'dflt' >>>>> contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs >>>>> to be >>>>> 32bits. >>>> Fixed. It was just a typo. >>>> >>>>> When otp_config_fini is it called ? >>>> Sadly, never. I admit that I am cargo-culting the lack of calling >>>> otp_config_fini(). Surely there must be a way to sanely tear this down >>>> when 389 shuts down? >>>> >>>>> On patch 0003: >>>>> In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS >>>>> (slapi-plugin.h). >>>> Fixed. >>>> >>>>> In ipa-otp-lasttoken:preop_mod , the test is_allowed is done >>>>> on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry >>>>> untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that >>>>> the >>>>> entry you want to check ? >>>> Yes, the code is correct as written. We check to see if a change to the >>>> existing state would cause bad behavior. Then, if any such change is >>>> attempted (ipa_otp_lasttoken.c:205) we reject it. In the future we >>>> might >>>> improve this to be more granular regarding the values of the change. >>>> But >>>> for now it is good enough. >>>> >>>>> On patch 0004: >>>>> In otp_config.c:otp_config_window you may use >>>>> SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) >>>> Fixed. >>>> >>>>> in otp_token: bvtod if 'code' contains non digit >>>>> character ,'out' is not reset before return. >>>> Yes. If the input value is invalid, the function returns an error >>>> status >>>> and the state of the output is undefined. This is pretty normal >>>> behavior. >>>> >>>> I think the first three patches are ready for merge. The last patch >>>> still needs some polish on my part. However, the first three also >>>> fix an >>>> important, independent bug. So let's merge them as soon as you feel >>>> they >>>> are ready. >>>> >>>> Nathaniel >>> If the Python parts are also OK and acked by Petr Vobornik or anyone >>> else then >>> sure, we can merge them. >> Python code is confined to patch 0004, so I think we just need Thierry's >> ACK on 0001-0003. > > Nathaniel, > > Thanks for all your explanations. ACK for the pacthes 0001-0002-0003. > > regarding the DS plugin part of 0004, the patch is good to me. For the > ipa plugins part I am too novice. Just a remainder: the python part of patch 0004 is still being discussed: http://www.redhat.com/archives/freeipa-devel/2014-November/msg00295.html > > thanks > thierry >>> By the fourth part you mean patch 0004, right? It somehow ended as >>> second in my >>> MUA. >> Yes. This patch 0004 is basically the rework of patch 0074 which is the >> main topic of this thread. But doing it properly meant sharing code >> (0001 and 0002) with another bugfix (0003). Thus, if we merge 0001-0003 >> we're back to just evaluating 0004/0074. >> >> Nathaniel >> -- Petr Vobornik From npmccallum at redhat.com Tue Dec 2 17:20:24 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 12:20:24 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <547DEF50.4060401@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547DB914.7050605@redhat.com> <1417535768.5864.46.camel@redhat.com> <547DE4DC.9030708@redhat.com> <1417537475.5864.60.camel@redhat.com> <547DEB45.4000404@redhat.com> <547DEF50.4060401@redhat.com> Message-ID: <1417540824.5864.65.camel@redhat.com> On Tue, 2014-12-02 at 17:56 +0100, Petr Vobornik wrote: > On 12/02/2014 05:39 PM, thierry bordaz wrote: > > On 12/02/2014 05:24 PM, Nathaniel McCallum wrote: > >> On Tue, 2014-12-02 at 17:12 +0100, Martin Kosek wrote: > >>> On 12/02/2014 04:56 PM, Nathaniel McCallum wrote: > >>>> On Tue, 2014-12-02 at 14:05 +0100, thierry bordaz wrote: > >>>>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > >>>>> > >>>>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > >>>>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: > >>>>>>>> On 7.11.2014 08:58, Martin Kosek wrote: > >>>>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > >>>>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > >>>>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: > >>>>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > >>>>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>>>>>> This patch gives the administrator variables to control > >>>>>>>>>>>>>>> the size of > >>>>>>>>>>>>>>> the authentication and synchronization windows for OTP > >>>>>>>>>>>>>>> tokens. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> NOTE: There is one known issue with this patch which I > >>>>>>>>>>>>>>> don't know > >>>>>>>>>>>>>>> how to > >>>>>>>>>>>>>>> solve. This patch changes the schema in > >>>>>>>>>>>>>>> install/share/60ipaconfig.ldif. > >>>>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear > >>>>>>>>>>>>>>> correctly. > >>>>>>>>>>>>>>> However, > >>>>>>>>>>>>>>> the modifications to the pre-existing objectClass do not > >>>>>>>>>>>>>>> show up > >>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>> server. What am I doing wrong? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this > >>>>>>>>>>>>>>> patch > >>>>>>>>>>>>>>> works > >>>>>>>>>>>>>>> just fine. > >>>>>>>>>>>>>> This new version takes into account the new (proper) OIDs and > >>>>>>>>>>>>>> attribute > >>>>>>>>>>>>>> names. > >>>>>>>>>>>>> Thanks Nathaniel! > >>>>>>>>>>>>> > >>>>>>>>>>>>>> The above known issue still remains. > >>>>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY > >>>>>>>>>>>>> list > >>>>>>>>>>>>> extension > >>>>>>>>>>>>> should work just fine, AFAIK. > >>>>>>>>>>>> You added a blank line to the LDIF file. This is an entry > >>>>>>>>>>>> separator, so > >>>>>>>>>>>> the objectClasses after the blank line don't belong to > >>>>>>>>>>>> cn=schema, so > >>>>>>>>>>>> they aren't considered in the update. > >>>>>>>>>>>> Without the blank line it works fine. > >>>>>>>>>>> Thanks for the catch! > >>>>>>>>>>> > >>>>>>>>>>> Here is a version without the blank line. > >>>>>>>>>> I forgot to remove the old steps defines. This patch performs > >>>>>>>>>> this > >>>>>>>>>> cleanup. > >>>>>>>>> I am now wondering, is the global config object really the nest > >>>>>>>>> place to > >>>>>>>>> add these OTP specific settings? > >>>>>>>>> > >>>>>>>>> I would prefer not to overload the object and instead: > >>>>>>>>> - create new ipaOTPConfig objectclass > >>>>>>>>> - add it to cn=otp,$SUFFIX > >>>>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an > >>>>>>>>> example > >>>>>>>>> of dnsconfig-* and trustconfig-* commands > >>>>>>>>> > >>>>>>>>> IMO, this would allow more flexibility for the OTP settings and > >>>>>>>>> would > >>>>>>>>> also scale better for the future updates. > >>>>>>>> +1 > >>>>>>>> > >>>>>>>> I will comment the patch as if ^^ would not exist because it > >>>>>>>> will still be > >>>>>>>> needed in the new plugin. > >>>>>>>> > >>>>>>>> Because of ^^ I did not test, just read. > >>>>>>>> > >>>>>>>> 1. Got: > >>>>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra > >>>>>>>> comma is not > >>>>>>>> recommended in array initializers > >>>>>>>> > >>>>>>>> Please run: > >>>>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf > >>>>>>>> in install/ui directory > >>>>>>>> > >>>>>>>> The goal is no have no warnings and errors. > >>>>>>>> > >>>>>>>> 2. new attrs should be added to 'System: Read Global > >>>>>>>> Configuration' managed > >>>>>>>> permission > >>>>>>> +1. Though if we go with OTP config, it should be called > >>>>>>> > >>>>>>> System: Read OTP Configuration > >>>>>>> > >>>>>>> Martin > >>>>>> Attached is a new set of patches that replaces this single patch. > >>>>>> This > >>>>>> now fixes multiple issues. > >>>>>> > >>>>>> I now create two new entries: > >>>>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > >>>>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > >>>>>> > >>>>>> There are two corresponding CLI commands: > >>>>>> * totpconfig-(show|mod) > >>>>>> * hotpconfig-(show|mod) > >>>>>> > >>>>>> There is no UI support for this yet (pointers welcome). > >>>>>> > >>>>>> This is designed so that eventually tokens can grow a per-token > >>>>>> override, but I have not yet implemented this feature (it should > >>>>>> be easy > >>>>>> in the future). > >>>>>> > >>>>>> Additionally, I had to do some shared refactoring to address > >>>>>> issues in > >>>>>> ipa-otp-lasttoken, which is why all of these are now merged into a > >>>>>> single patch set. > >>>>>> > >>>>>> Nathaniel > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Freeipa-devel mailing list > >>>>>> Freeipa-devel at redhat.com > >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >>>>> Hello Nathaniel, > >>>>> > >>>>> Very few comments. > >>>> Just as a reminder, patch 0001 is already ACKed. > >>>> > >>>>> On patch 0002: > >>>>> Is it possible that we later define a spec with 'dflt' > >>>>> contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs > >>>>> to be > >>>>> 32bits. > >>>> Fixed. It was just a typo. > >>>> > >>>>> When otp_config_fini is it called ? > >>>> Sadly, never. I admit that I am cargo-culting the lack of calling > >>>> otp_config_fini(). Surely there must be a way to sanely tear this down > >>>> when 389 shuts down? > >>>> > >>>>> On patch 0003: > >>>>> In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS > >>>>> (slapi-plugin.h). > >>>> Fixed. > >>>> > >>>>> In ipa-otp-lasttoken:preop_mod , the test is_allowed is done > >>>>> on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry > >>>>> untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that > >>>>> the > >>>>> entry you want to check ? > >>>> Yes, the code is correct as written. We check to see if a change to the > >>>> existing state would cause bad behavior. Then, if any such change is > >>>> attempted (ipa_otp_lasttoken.c:205) we reject it. In the future we > >>>> might > >>>> improve this to be more granular regarding the values of the change. > >>>> But > >>>> for now it is good enough. > >>>> > >>>>> On patch 0004: > >>>>> In otp_config.c:otp_config_window you may use > >>>>> SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) > >>>> Fixed. > >>>> > >>>>> in otp_token: bvtod if 'code' contains non digit > >>>>> character ,'out' is not reset before return. > >>>> Yes. If the input value is invalid, the function returns an error > >>>> status > >>>> and the state of the output is undefined. This is pretty normal > >>>> behavior. > >>>> > >>>> I think the first three patches are ready for merge. The last patch > >>>> still needs some polish on my part. However, the first three also > >>>> fix an > >>>> important, independent bug. So let's merge them as soon as you feel > >>>> they > >>>> are ready. > >>>> > >>>> Nathaniel > >>> If the Python parts are also OK and acked by Petr Vobornik or anyone > >>> else then > >>> sure, we can merge them. > >> Python code is confined to patch 0004, so I think we just need Thierry's > >> ACK on 0001-0003. > > > > Nathaniel, > > > > Thanks for all your explanations. ACK for the pacthes 0001-0002-0003. > > > > regarding the DS plugin part of 0004, the patch is good to me. For the > > ipa plugins part I am too novice. > > Just a remainder: the python part of patch 0004 is still being > discussed: > http://www.redhat.com/archives/freeipa-devel/2014-November/msg00295.html Correct. Please merge 0001-0003 as they are ACKed, but NOT 0004. I will have an alternative proposal for 0004 shortly. Nathaniel From pspacek at redhat.com Tue Dec 2 17:42:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Dec 2014 18:42:54 +0100 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 6.1 Message-ID: <547DFA1E.9060301@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 6.1. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 21+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-6.1-1.fc21 This version is also available from FreeIPA COPR repo: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ 6.1 ==== [1] Crash caused by interaction between forward and master zones was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/145 [2] DNS NOTIFY messages are sent after any modification to the zone. https://fedorahosted.org/bind-dyndb-ldap/ticket/144 [3] Misleading error message about forward zones during reconnect was fixed. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. Downgrading back to any 5.x version is supported if idnsZoneActive is always set to TRUE. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek From npmccallum at redhat.com Tue Dec 2 19:47:22 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 14:47:22 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1417540824.5864.65.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <547DB914.7050605@redhat.com> <1417535768.5864.46.camel@redhat.com> <547DE4DC.9030708@redhat.com> <1417537475.5864.60.camel@redhat.com> <547DEB45.4000404@redhat.com> <547DEF50.4060401@redhat.com> <1417540824.5864.65.camel@redhat.com> Message-ID: <1417549642.5864.72.camel@redhat.com> On Tue, 2014-12-02 at 12:20 -0500, Nathaniel McCallum wrote: > On Tue, 2014-12-02 at 17:56 +0100, Petr Vobornik wrote: > > On 12/02/2014 05:39 PM, thierry bordaz wrote: > > > On 12/02/2014 05:24 PM, Nathaniel McCallum wrote: > > >> On Tue, 2014-12-02 at 17:12 +0100, Martin Kosek wrote: > > >>> On 12/02/2014 04:56 PM, Nathaniel McCallum wrote: > > >>>> On Tue, 2014-12-02 at 14:05 +0100, thierry bordaz wrote: > > >>>>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > > >>>>> > > >>>>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > > >>>>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: > > >>>>>>>> On 7.11.2014 08:58, Martin Kosek wrote: > > >>>>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > > >>>>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > > >>>>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > > >>>>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: > > >>>>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > > >>>>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > > >>>>>>>>>>>>>>> This patch gives the administrator variables to control > > >>>>>>>>>>>>>>> the size of > > >>>>>>>>>>>>>>> the authentication and synchronization windows for OTP > > >>>>>>>>>>>>>>> tokens. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> NOTE: There is one known issue with this patch which I > > >>>>>>>>>>>>>>> don't know > > >>>>>>>>>>>>>>> how to > > >>>>>>>>>>>>>>> solve. This patch changes the schema in > > >>>>>>>>>>>>>>> install/share/60ipaconfig.ldif. > > >>>>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear > > >>>>>>>>>>>>>>> correctly. > > >>>>>>>>>>>>>>> However, > > >>>>>>>>>>>>>>> the modifications to the pre-existing objectClass do not > > >>>>>>>>>>>>>>> show up > > >>>>>>>>>>>>>>> on the > > >>>>>>>>>>>>>>> server. What am I doing wrong? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this > > >>>>>>>>>>>>>>> patch > > >>>>>>>>>>>>>>> works > > >>>>>>>>>>>>>>> just fine. > > >>>>>>>>>>>>>> This new version takes into account the new (proper) OIDs and > > >>>>>>>>>>>>>> attribute > > >>>>>>>>>>>>>> names. > > >>>>>>>>>>>>> Thanks Nathaniel! > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> The above known issue still remains. > > >>>>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY > > >>>>>>>>>>>>> list > > >>>>>>>>>>>>> extension > > >>>>>>>>>>>>> should work just fine, AFAIK. > > >>>>>>>>>>>> You added a blank line to the LDIF file. This is an entry > > >>>>>>>>>>>> separator, so > > >>>>>>>>>>>> the objectClasses after the blank line don't belong to > > >>>>>>>>>>>> cn=schema, so > > >>>>>>>>>>>> they aren't considered in the update. > > >>>>>>>>>>>> Without the blank line it works fine. > > >>>>>>>>>>> Thanks for the catch! > > >>>>>>>>>>> > > >>>>>>>>>>> Here is a version without the blank line. > > >>>>>>>>>> I forgot to remove the old steps defines. This patch performs > > >>>>>>>>>> this > > >>>>>>>>>> cleanup. > > >>>>>>>>> I am now wondering, is the global config object really the nest > > >>>>>>>>> place to > > >>>>>>>>> add these OTP specific settings? > > >>>>>>>>> > > >>>>>>>>> I would prefer not to overload the object and instead: > > >>>>>>>>> - create new ipaOTPConfig objectclass > > >>>>>>>>> - add it to cn=otp,$SUFFIX > > >>>>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an > > >>>>>>>>> example > > >>>>>>>>> of dnsconfig-* and trustconfig-* commands > > >>>>>>>>> > > >>>>>>>>> IMO, this would allow more flexibility for the OTP settings and > > >>>>>>>>> would > > >>>>>>>>> also scale better for the future updates. > > >>>>>>>> +1 > > >>>>>>>> > > >>>>>>>> I will comment the patch as if ^^ would not exist because it > > >>>>>>>> will still be > > >>>>>>>> needed in the new plugin. > > >>>>>>>> > > >>>>>>>> Because of ^^ I did not test, just read. > > >>>>>>>> > > >>>>>>>> 1. Got: > > >>>>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra > > >>>>>>>> comma is not > > >>>>>>>> recommended in array initializers > > >>>>>>>> > > >>>>>>>> Please run: > > >>>>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf > > >>>>>>>> in install/ui directory > > >>>>>>>> > > >>>>>>>> The goal is no have no warnings and errors. > > >>>>>>>> > > >>>>>>>> 2. new attrs should be added to 'System: Read Global > > >>>>>>>> Configuration' managed > > >>>>>>>> permission > > >>>>>>> +1. Though if we go with OTP config, it should be called > > >>>>>>> > > >>>>>>> System: Read OTP Configuration > > >>>>>>> > > >>>>>>> Martin > > >>>>>> Attached is a new set of patches that replaces this single patch. > > >>>>>> This > > >>>>>> now fixes multiple issues. > > >>>>>> > > >>>>>> I now create two new entries: > > >>>>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > > >>>>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > > >>>>>> > > >>>>>> There are two corresponding CLI commands: > > >>>>>> * totpconfig-(show|mod) > > >>>>>> * hotpconfig-(show|mod) > > >>>>>> > > >>>>>> There is no UI support for this yet (pointers welcome). > > >>>>>> > > >>>>>> This is designed so that eventually tokens can grow a per-token > > >>>>>> override, but I have not yet implemented this feature (it should > > >>>>>> be easy > > >>>>>> in the future). > > >>>>>> > > >>>>>> Additionally, I had to do some shared refactoring to address > > >>>>>> issues in > > >>>>>> ipa-otp-lasttoken, which is why all of these are now merged into a > > >>>>>> single patch set. > > >>>>>> > > >>>>>> Nathaniel > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Freeipa-devel mailing list > > >>>>>> Freeipa-devel at redhat.com > > >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel > > >>>>> Hello Nathaniel, > > >>>>> > > >>>>> Very few comments. > > >>>> Just as a reminder, patch 0001 is already ACKed. > > >>>> > > >>>>> On patch 0002: > > >>>>> Is it possible that we later define a spec with 'dflt' > > >>>>> contains OTP_CONFIG_AUTH_TYPE_DISABLED ? If yes it needs > > >>>>> to be > > >>>>> 32bits. > > >>>> Fixed. It was just a typo. > > >>>> > > >>>>> When otp_config_fini is it called ? > > >>>> Sadly, never. I admit that I am cargo-culting the lack of calling > > >>>> otp_config_fini(). Surely there must be a way to sanely tear this down > > >>>> when 389 shuts down? > > >>>> > > >>>>> On patch 0003: > > >>>>> In ipa-otp-lasttoken:58 you may use SLAPI_ATTR_OBJECTCLASS > > >>>>> (slapi-plugin.h). > > >>>> Fixed. > > >>>> > > >>>>> In ipa-otp-lasttoken:preop_mod , the test is_allowed is done > > >>>>> on the original entry (SLAPI_ENTRY_PRE_OP). That is the entry > > >>>>> untouched by others BE_PREOP/TXN_BE_PREOP plugins. Is that > > >>>>> the > > >>>>> entry you want to check ? > > >>>> Yes, the code is correct as written. We check to see if a change to the > > >>>> existing state would cause bad behavior. Then, if any such change is > > >>>> attempted (ipa_otp_lasttoken.c:205) we reject it. In the future we > > >>>> might > > >>>> improve this to be more granular regarding the values of the change. > > >>>> But > > >>>> for now it is good enough. > > >>>> > > >>>>> On patch 0004: > > >>>>> In otp_config.c:otp_config_window you may use > > >>>>> SLAPI_ATTR_OBJECTCLASS (slapi-plugin.h) > > >>>> Fixed. > > >>>> > > >>>>> in otp_token: bvtod if 'code' contains non digit > > >>>>> character ,'out' is not reset before return. > > >>>> Yes. If the input value is invalid, the function returns an error > > >>>> status > > >>>> and the state of the output is undefined. This is pretty normal > > >>>> behavior. > > >>>> > > >>>> I think the first three patches are ready for merge. The last patch > > >>>> still needs some polish on my part. However, the first three also > > >>>> fix an > > >>>> important, independent bug. So let's merge them as soon as you feel > > >>>> they > > >>>> are ready. > > >>>> > > >>>> Nathaniel > > >>> If the Python parts are also OK and acked by Petr Vobornik or anyone > > >>> else then > > >>> sure, we can merge them. > > >> Python code is confined to patch 0004, so I think we just need Thierry's > > >> ACK on 0001-0003. > > > > > > Nathaniel, > > > > > > Thanks for all your explanations. ACK for the pacthes 0001-0002-0003. > > > > > > regarding the DS plugin part of 0004, the patch is good to me. For the > > > ipa plugins part I am too novice. > > > > Just a remainder: the python part of patch 0004 is still being > > discussed: > > http://www.redhat.com/archives/freeipa-devel/2014-November/msg00295.html > > Correct. Please merge 0001-0003 as they are ACKed, but NOT 0004. I will > have an alternative proposal for 0004 shortly. I found a small typo in patch 0002. I will attach it in reply to Petr's review email. Nathaniel From npmccallum at redhat.com Tue Dec 2 19:57:57 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 02 Dec 2014 14:57:57 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <546B9D66.5010704@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> Message-ID: <1417550277.5864.82.camel@redhat.com> On Tue, 2014-11-18 at 20:26 +0100, Petr Vobornik wrote: > On 13.11.2014 08:53, Martin Kosek wrote: > > On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: > >> On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: > >>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > >>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > >>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: > >>>>>> On 7.11.2014 08:58, Martin Kosek wrote: > >>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > >>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > >>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > >>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: > >>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > >>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>>>> This patch gives the administrator variables to control the size of > >>>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 > >>>>>>>>>>>>> > >>>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know > >>>>>>>>>>>>> how to > >>>>>>>>>>>>> solve. This patch changes the schema in > >>>>>>>>>>>>> install/share/60ipaconfig.ldif. > >>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. > >>>>>>>>>>>>> However, > >>>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up > >>>>>>>>>>>>> on the > >>>>>>>>>>>>> server. What am I doing wrong? > >>>>>>>>>>>>> > >>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch > >>>>>>>>>>>>> works > >>>>>>>>>>>>> just fine. > >>>>>>>>>>>> > >>>>>>>>>>>> This new version takes into account the new (proper) OIDs and > >>>>>>>>>>>> attribute > >>>>>>>>>>>> names. > >>>>>>>>>>> > >>>>>>>>>>> Thanks Nathaniel! > >>>>>>>>>>> > >>>>>>>>>>>> The above known issue still remains. > >>>>>>>>>>> > >>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list > >>>>>>>>>>> extension > >>>>>>>>>>> should work just fine, AFAIK. > >>>>>>>>>> > >>>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so > >>>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so > >>>>>>>>>> they aren't considered in the update. > >>>>>>>>>> Without the blank line it works fine. > >>>>>>>>> > >>>>>>>>> Thanks for the catch! > >>>>>>>>> > >>>>>>>>> Here is a version without the blank line. > >>>>>>>> > >>>>>>>> I forgot to remove the old steps defines. This patch performs this > >>>>>>>> cleanup. > >>>>>>> > >>>>>>> I am now wondering, is the global config object really the nest place to > >>>>>>> add these OTP specific settings? > >>>>>>> > >>>>>>> I would prefer not to overload the object and instead: > >>>>>>> - create new ipaOTPConfig objectclass > >>>>>>> - add it to cn=otp,$SUFFIX > >>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example > >>>>>>> of dnsconfig-* and trustconfig-* commands > >>>>>>> > >>>>>>> IMO, this would allow more flexibility for the OTP settings and would > >>>>>>> also scale better for the future updates. > >>>>>> > >>>>>> +1 > >>>>>> > >>>>>> I will comment the patch as if ^^ would not exist because it will still be > >>>>>> needed in the new plugin. > >>>>>> > >>>>>> Because of ^^ I did not test, just read. > >>>>>> > >>>>>> 1. Got: > >>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > >>>>>> recommended in array initializers > >>>>>> > >>>>>> Please run: > >>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf > >>>>>> in install/ui directory > >>>>>> > >>>>>> The goal is no have no warnings and errors. > >>>>>> > >>>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed > >>>>>> permission > >>>>> > >>>>> +1. Though if we go with OTP config, it should be called > >>>>> > >>>>> System: Read OTP Configuration > >>>>> > >>>>> Martin > >>>> > >>>> Attached is a new set of patches that replaces this single patch. This > >>>> now fixes multiple issues. > >>>> > >>>> I now create two new entries: > >>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > >>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > >>>> > >>>> There are two corresponding CLI commands: > >>>> * totpconfig-(show|mod) > >>>> * hotpconfig-(show|mod) > >>>> > >>>> There is no UI support for this yet (pointers welcome). > >>>> > >>>> This is designed so that eventually tokens can grow a per-token > >>>> override, but I have not yet implemented this feature (it should be easy > >>>> in the future). > >>>> > >>>> Additionally, I had to do some shared refactoring to address issues in > >>>> ipa-otp-lasttoken, which is why all of these are now merged into a > >>>> single patch set. > >>>> > >>>> Nathaniel > > I'm little confused with a state of reviews. Thierry were some of the > patches ACKed in different threads or are they under review (I'm not > reviewing DS plugin parts)? Patches 0001, 0002, 0003 are ACKed by Thierry, but not merged. They can and should be merged as they fix an independent bug. > >>> Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want > >>> to make TOTP/HOTP token config as separate entries (to enable future per-token > >>> overrides), your approach should make sense. Rather adding Rob to CC for sanity. > >> > >> That would work too. I'm open to that. > >> > >>> I am just not sure we should create them as separate plugins, I think the new > >>> commands should be rather added to otp plugin directly so that they show in > >>> "ipa help otptoken" instead of adding 2 new topics just for OTP config. > >> > >> I can play with that. > > Do you plan to change it? I like the idea of a single point of help for > OTP but I'm also unsure about the length of the commands. Current > solution is also more consistent with a rest of the framework. Would it > be something like: > > otptoken-totpconfig-(show|mod) > otptoken-hotpconfig-(show|mod) In the latest patch, I merged totpconfig-* and hotpconfig-* into a single otpconfig-* plugin. > Maybe it would be better to introduce more help topics for otp. This > concept is used for HBAC already: > > $ ipa help hbac > hbacsvcgroup HBAC Service Groups > hbacsvc HBAC Services > hbacrule Host-based access control > > $ ipa help hbacrule > Host-based access control > ... a lot of text > > So we could introduce otp umbrella topic: > > $ ipa help otp > opttoken OTP tokens' > totpconfig TOTP configuration options > hotpconfig HOTP configuration options I added a fifth patch (0005) which creates an otp umbrella topic. We can merge it or not. > >> Nathaniel > > > > No worries ATM, you can wait for proper review. I was just looking at the new > > API to make sure we are on the same page - we seem to mostly are. > > > > Martin > > > > Commenting just patch 0004: > > 1. Requires rebase because of API change. Fixed. > 2. git diff HEAD~4 -U0 | pep8 --diff > I would ignore E124 and fix E302 (5x) Fixed. > I did not test actual functionality yet. The attached patches I think have a much better overall aesthetic. Now patch 0004 introduces only two new commands: * otpconfig-mod * otpconfig-show Under the covers, a single configuration entity is used: * cn=otp,cn=etc,$SUFFIX Other than these small changes, there are no changes to patch 0004. I have not tested the latest changes, however, due to an unrelated build issue I'm working on. Patch 0005 introduces an umbrella help topic for all OTP related commands (currently: otpconfig, otptoken, otptoken-yubikey). Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Preliminary-refactoring-of-libotp-files.patch Type: text/x-patch Size: 24175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Move-authentication-configuration-cache-into-libotp.patch Type: text/x-patch Size: 38471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Enable-last-token-deletion-when-password-auth-type-i.patch Type: text/x-patch Size: 10633 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Make-token-auth-and-sync-windows-configurable.patch Type: text/x-patch Size: 33048 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Create-an-OTP-help-topic.patch Type: text/x-patch Size: 1801 bytes Desc: not available URL: From redhatrises at gmail.com Wed Dec 3 04:13:54 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 2 Dec 2014 21:13:54 -0700 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <547C893B.1000008@redhat.com> References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> Message-ID: This patch removes the changelog and Makefile.am for ipaclient as well. Thanks, Gabe On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek wrote: > On 12/01/2014 04:25 PM, Rob Crittenden wrote: > > Gabe Alford wrote: > >> > >> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek >> > wrote: > >> > >> On 11/30/2014 03:28 AM, Gabe Alford wrote: > >> > Ignore the last patch. Updated patch attached. > >> > > >> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford > >> > wrote: > >> > > >> >> This patch removes the app_PYTHON usage. > >> >> > >> >> Thanks, > >> >> > >> >> Gabe > >> >> > >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek >> > wrote: > >> >> > >> >>> Exactly, this was the message from Martin :-) I did not test it > >> myself, > >> >>> but > >> >>> removing all app_PYTHON should be benign given we use Python > >> setup.py > >> >>> packaging. > >> >>> > >> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: > >> >>>> Thanks guys. Sounds like it would be better to submit a patch > that > >> >>> removes > >> >>>> app_PYTHON if it is considered dead code. > >> >>>> > >> >>>> Gabe > >> >>>> > >> >>>> On Thursday, November 27, 2014, Petr Spacek < > pspacek at redhat.com > >> > wrote: > >> >>>> > >> >>>>> On 27.11.2014 11:00, Martin Basti wrote: > >> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: > >> >>>>>>> Hello, > >> >>>>>>> > >> >>>>>>> Wondering if I could get a review. Updated patch > >> attached. > >> >>>>>>> > >> >>>>>>> Thanks, > >> >>>>>>> Gabe > >> >>>>>>> > >> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > >> > >> >>>>> > >> >>>>>>> > > >> >> wrote: > >> >>>>>>> > >> >>>>>>> Hello, > >> >>>>>>> > >> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 > >> >>>>>>> > >> >>>>>>> Thanks, > >> >>>>>>> > >> >>>>>>> Gabe > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>> Hello, > >> >>>>>> > >> >>>>>> sorry for late response. > >> >>>>>> > >> >>>>>> We push this ticket to backlog, as it would be part of build > >> system > >> >>>>> refactoring. > >> >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the > better > >> >>>>> solution is > >> >>>>>> remove it, instead of keeping dead code up-to-date. > >> >>>>> > >> >>>>> Just to clarify: > >> >>>>> It can be pushed if it works, there is no need to postpone > >> accepting > >> >>> patch > >> >>>>> if > >> >>>>> the patch seems okay and doesn't break anything. > >> >>>>> > >> >>>>> Martin, please keep in mind that contributions are welcome at > >> any time. > >> >>>>> > >> >>>>> Milestones in Trac reflect our view of priorities but it > doesn't > >> >>> prevent us > >> >>>>> from accepting correct patches from contributions at any > time, no > >> >>> matter > >> >>>>> which > >> >>>>> priority is stated in Trac (or even if there is no ticket for > >> it ...). > >> >>>>> > >> >>>>> -- > >> >>>>> Petr^2 Spacek > >> > >> Worked in my tests, I did not see any breakage. I guess we can also > >> remove the > >> ipa-client/ipaclient/Makefile.am while we are at it. > >> > >> Martin > >> > >> > >> It looks like the ipaclient/Makefile.am is still being used. I tried > >> removing it and there were errors in the build, but maybe I am wrong? > > > > It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. > > > > Feel free to rip out the outdated hg ChangeLog stuff though. > > > > rob > > I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not > about > ipa-client/Makefile.am - we still need this one as Rob correctly said. > > The failure that Gabe hit in build probably comes from the the SUBDIR > reference > in ipa-client/Makefile.am file. I assume that if the reference is removed, > the > removal should work. > > And yes, you can remove the Changelog too if you are OK with it :) > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0036-4-Remove-missing-python-files-to-Makefiles.patch Type: text/x-patch Size: 3902 bytes Desc: not available URL: From redhatrises at gmail.com Wed Dec 3 04:21:16 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 2 Dec 2014 21:21:16 -0700 Subject: [Freeipa-devel] [PATCH 0039] Add test case for unsupported arg for ipa-advise Message-ID: Hello, I was going to try my hand at attempting a patch for ipa-tests. However in wanting to test my patch, I am not sure how to run ipa-tests to check if it works or not. Documentation is not really clear on what needs to be done to start a test and run a test. This is for https://fedorahosted.org/freeipa/ticket/4029 I have attached the patch that I have yet to really test with ipa-test. Any help on how to test the patch running ipa-tests would be great. Of course, if one of the reviewers looks at the patch and looks good, then I would be happy with that as well. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0039-Add-test-case-for-unsupported-argument-for-ipa-advis.patch Type: text/x-patch Size: 1264 bytes Desc: not available URL: From jcholast at redhat.com Wed Dec 3 09:23:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Dec 2014 10:23:36 +0100 Subject: [Freeipa-devel] [PATCH] 381 Fix stop_tracking_certificates call in ipa-restore Message-ID: <547ED698.8080201@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-381-Fix-stop_tracking_certificates-call-in-ipa-restore.patch Type: text/x-patch Size: 1436 bytes Desc: not available URL: From jcholast at redhat.com Wed Dec 3 11:35:08 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 03 Dec 2014 12:35:08 +0100 Subject: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods In-Reply-To: <547CB2A7.60400@redhat.com> References: <547C6A4E.3090307@redhat.com> <547C6E13.8010501@redhat.com> <547CB2A7.60400@redhat.com> Message-ID: <547EF56C.5080709@redhat.com> Dne 1.12.2014 v 19:25 Petr Vobornik napsal(a): > On 12/01/2014 02:33 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a): >>> `--hosts` option added to: >>> * service-allow-create-keytab >>> * service-allow-retrieve-keytab >>> * service-disallow-create-keytab >>> * service-disallow-retrieve-keytab >>> * host-allow-create-keytab >>> * host-allow-retrieve-keytab >>> * host-disallow-create-keytab >>> * host-disallow-retrieve-keytab >>> >>> in order to allow hosts to retrieve keytab of their services or related >>> hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval >>> design page >>> >>> https://fedorahosted.org/freeipa/ticket/4777 >> >> Since groups of users are supported with "group" members, we should >> probably also support groups of hosts with "hostgroup" members, for >> consistency. > > --hostgroup options added. Thanks, ACK. Fixed a typo in host.py: + label=_('Hosts Groups allowed to create keytab'), ^ and pushed to: master: 026c9eca0920e92e56148b808c851e9bde00ece8 ipa-4-1: 1108e7145538f84da2e0dfdf4fb0e76583575dd2 > >> >>> >>> >>> I'm pondering how to handle Web UI. I'm not font of adding a third pair >>> of tables to host and service details pages because the amount of space >>> on the page required for the keytab management is much bigger than its >>> importance compared to other fields. >> >> Honza >> -- Jan Cholasta From mkosek at redhat.com Wed Dec 3 13:05:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Dec 2014 14:05:32 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> Message-ID: <547F0A9C.7070908@redhat.com> On 12/03/2014 05:13 AM, Gabe Alford wrote: > This patch removes the changelog and Makefile.am for ipaclient as well. > > Thanks, > > Gabe > > On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek wrote: > >> On 12/01/2014 04:25 PM, Rob Crittenden wrote: >>> Gabe Alford wrote: >>>> >>>> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek >>> > wrote: >>>> >>>> On 11/30/2014 03:28 AM, Gabe Alford wrote: >>>> > Ignore the last patch. Updated patch attached. >>>> > >>>> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford >>>> > wrote: >>>> > >>>> >> This patch removes the app_PYTHON usage. >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Gabe >>>> >> >>>> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek >>> > wrote: >>>> >> >>>> >>> Exactly, this was the message from Martin :-) I did not test it >>>> myself, >>>> >>> but >>>> >>> removing all app_PYTHON should be benign given we use Python >>>> setup.py >>>> >>> packaging. >>>> >>> >>>> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: >>>> >>>> Thanks guys. Sounds like it would be better to submit a patch >> that >>>> >>> removes >>>> >>>> app_PYTHON if it is considered dead code. >>>> >>>> >>>> >>>> Gabe >>>> >>>> >>>> >>>> On Thursday, November 27, 2014, Petr Spacek < >> pspacek at redhat.com >>>> > wrote: >>>> >>>> >>>> >>>>> On 27.11.2014 11:00, Martin Basti wrote: >>>> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: >>>> >>>>>>> Hello, >>>> >>>>>>> >>>> >>>>>>> Wondering if I could get a review. Updated patch >>>> attached. >>>> >>>>>>> >>>> >>>>>>> Thanks, >>>> >>>>>>> Gabe >>>> >>>>>>> >>>> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >>>> >>>> >>>>> >>>> >>>>>>> >> >>>> >> wrote: >>>> >>>>>>> >>>> >>>>>>> Hello, >>>> >>>>>>> >>>> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >>>> >>>>>>> >>>> >>>>>>> Thanks, >>>> >>>>>>> >>>> >>>>>>> Gabe >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>> Hello, >>>> >>>>>> >>>> >>>>>> sorry for late response. >>>> >>>>>> >>>> >>>>>> We push this ticket to backlog, as it would be part of build >>>> system >>>> >>>>> refactoring. >>>> >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the >> better >>>> >>>>> solution is >>>> >>>>>> remove it, instead of keeping dead code up-to-date. >>>> >>>>> >>>> >>>>> Just to clarify: >>>> >>>>> It can be pushed if it works, there is no need to postpone >>>> accepting >>>> >>> patch >>>> >>>>> if >>>> >>>>> the patch seems okay and doesn't break anything. >>>> >>>>> >>>> >>>>> Martin, please keep in mind that contributions are welcome at >>>> any time. >>>> >>>>> >>>> >>>>> Milestones in Trac reflect our view of priorities but it >> doesn't >>>> >>> prevent us >>>> >>>>> from accepting correct patches from contributions at any >> time, no >>>> >>> matter >>>> >>>>> which >>>> >>>>> priority is stated in Trac (or even if there is no ticket for >>>> it ...). >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Petr^2 Spacek >>>> >>>> Worked in my tests, I did not see any breakage. I guess we can also >>>> remove the >>>> ipa-client/ipaclient/Makefile.am while we are at it. >>>> >>>> Martin >>>> >>>> >>>> It looks like the ipaclient/Makefile.am is still being used. I tried >>>> removing it and there were errors in the build, but maybe I am wrong? >>> >>> It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. >>> >>> Feel free to rip out the outdated hg ChangeLog stuff though. >>> >>> rob >> >> I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not >> about >> ipa-client/Makefile.am - we still need this one as Rob correctly said. >> >> The failure that Gabe hit in build probably comes from the the SUBDIR >> reference >> in ipa-client/Makefile.am file. I assume that if the reference is removed, >> the >> removal should work. >> >> And yes, you can remove the Changelog too if you are OK with it :) >> >> Martin >> > I think you did some error during the process. This is what I got: $ git clean -fxd $ git apply ... $ make rpms ... checking that generated files are newer than configure... done configure: creating ./config.status config.status: error: cannot find input file: `Makefile.in' Makefile:84: recipe for target 'client-autogen' failed make: *** [client-autogen] Error 1 Martin From mkosek at redhat.com Wed Dec 3 13:43:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Dec 2014 14:43:54 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1417550277.5864.82.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> <1417550277.5864.82.camel@redhat.com> Message-ID: <547F139A.4050306@redhat.com> On 12/02/2014 08:57 PM, Nathaniel McCallum wrote: > On Tue, 2014-11-18 at 20:26 +0100, Petr Vobornik wrote: >> On 13.11.2014 08:53, Martin Kosek wrote: >>> On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: >>>> On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: >>>>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: >>>>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: >>>>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: >>>>>>>> On 7.11.2014 08:58, Martin Kosek wrote: >>>>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: >>>>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: >>>>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: >>>>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: >>>>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >>>>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>>> This patch gives the administrator variables to control the size of >>>>>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know >>>>>>>>>>>>>>> how to >>>>>>>>>>>>>>> solve. This patch changes the schema in >>>>>>>>>>>>>>> install/share/60ipaconfig.ldif. >>>>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. >>>>>>>>>>>>>>> However, >>>>>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up >>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>> server. What am I doing wrong? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch >>>>>>>>>>>>>>> works >>>>>>>>>>>>>>> just fine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This new version takes into account the new (proper) OIDs and >>>>>>>>>>>>>> attribute >>>>>>>>>>>>>> names. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks Nathaniel! >>>>>>>>>>>>> >>>>>>>>>>>>>> The above known issue still remains. >>>>>>>>>>>>> >>>>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list >>>>>>>>>>>>> extension >>>>>>>>>>>>> should work just fine, AFAIK. >>>>>>>>>>>> >>>>>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so >>>>>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so >>>>>>>>>>>> they aren't considered in the update. >>>>>>>>>>>> Without the blank line it works fine. >>>>>>>>>>> >>>>>>>>>>> Thanks for the catch! >>>>>>>>>>> >>>>>>>>>>> Here is a version without the blank line. >>>>>>>>>> >>>>>>>>>> I forgot to remove the old steps defines. This patch performs this >>>>>>>>>> cleanup. >>>>>>>>> >>>>>>>>> I am now wondering, is the global config object really the nest place to >>>>>>>>> add these OTP specific settings? >>>>>>>>> >>>>>>>>> I would prefer not to overload the object and instead: >>>>>>>>> - create new ipaOTPConfig objectclass >>>>>>>>> - add it to cn=otp,$SUFFIX >>>>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example >>>>>>>>> of dnsconfig-* and trustconfig-* commands >>>>>>>>> >>>>>>>>> IMO, this would allow more flexibility for the OTP settings and would >>>>>>>>> also scale better for the future updates. >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> I will comment the patch as if ^^ would not exist because it will still be >>>>>>>> needed in the new plugin. >>>>>>>> >>>>>>>> Because of ^^ I did not test, just read. >>>>>>>> >>>>>>>> 1. Got: >>>>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not >>>>>>>> recommended in array initializers >>>>>>>> >>>>>>>> Please run: >>>>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf >>>>>>>> in install/ui directory >>>>>>>> >>>>>>>> The goal is no have no warnings and errors. >>>>>>>> >>>>>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed >>>>>>>> permission >>>>>>> >>>>>>> +1. Though if we go with OTP config, it should be called >>>>>>> >>>>>>> System: Read OTP Configuration >>>>>>> >>>>>>> Martin >>>>>> >>>>>> Attached is a new set of patches that replaces this single patch. This >>>>>> now fixes multiple issues. >>>>>> >>>>>> I now create two new entries: >>>>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX >>>>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX >>>>>> >>>>>> There are two corresponding CLI commands: >>>>>> * totpconfig-(show|mod) >>>>>> * hotpconfig-(show|mod) >>>>>> >>>>>> There is no UI support for this yet (pointers welcome). >>>>>> >>>>>> This is designed so that eventually tokens can grow a per-token >>>>>> override, but I have not yet implemented this feature (it should be easy >>>>>> in the future). >>>>>> >>>>>> Additionally, I had to do some shared refactoring to address issues in >>>>>> ipa-otp-lasttoken, which is why all of these are now merged into a >>>>>> single patch set. >>>>>> >>>>>> Nathaniel >> >> I'm little confused with a state of reviews. Thierry were some of the >> patches ACKed in different threads or are they under review (I'm not >> reviewing DS plugin parts)? > > Patches 0001, 0002, 0003 are ACKed by Thierry, but not merged. They can > and should be merged as they fix an independent bug. > >>>>> Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want >>>>> to make TOTP/HOTP token config as separate entries (to enable future per-token >>>>> overrides), your approach should make sense. Rather adding Rob to CC for sanity. >>>> >>>> That would work too. I'm open to that. >>>> >>>>> I am just not sure we should create them as separate plugins, I think the new >>>>> commands should be rather added to otp plugin directly so that they show in >>>>> "ipa help otptoken" instead of adding 2 new topics just for OTP config. >>>> >>>> I can play with that. >> >> Do you plan to change it? I like the idea of a single point of help for >> OTP but I'm also unsure about the length of the commands. Current >> solution is also more consistent with a rest of the framework. Would it >> be something like: >> >> otptoken-totpconfig-(show|mod) >> otptoken-hotpconfig-(show|mod) > > In the latest patch, I merged totpconfig-* and hotpconfig-* into a > single otpconfig-* plugin. > >> Maybe it would be better to introduce more help topics for otp. This >> concept is used for HBAC already: >> >> $ ipa help hbac >> hbacsvcgroup HBAC Service Groups >> hbacsvc HBAC Services >> hbacrule Host-based access control >> >> $ ipa help hbacrule >> Host-based access control >> ... a lot of text >> >> So we could introduce otp umbrella topic: >> >> $ ipa help otp >> opttoken OTP tokens' >> totpconfig TOTP configuration options >> hotpconfig HOTP configuration options > > I added a fifth patch (0005) which creates an otp umbrella topic. We can > merge it or not. > >>>> Nathaniel >>> >>> No worries ATM, you can wait for proper review. I was just looking at the new >>> API to make sure we are on the same page - we seem to mostly are. >>> >>> Martin >>> >> >> Commenting just patch 0004: >> >> 1. Requires rebase because of API change. > > Fixed. > >> 2. git diff HEAD~4 -U0 | pep8 --diff >> I would ignore E124 and fix E302 (5x) > > Fixed. > >> I did not test actual functionality yet. > > The attached patches I think have a much better overall aesthetic. Now > patch 0004 introduces only two new commands: > * otpconfig-mod > * otpconfig-show > > Under the covers, a single configuration entity is used: > * cn=otp,cn=etc,$SUFFIX > > Other than these small changes, there are no changes to patch 0004. I > have not tested the latest changes, however, due to an unrelated build > issue I'm working on. > > Patch 0005 introduces an umbrella help topic for all OTP related > commands (currently: otpconfig, otptoken, otptoken-yubikey). > > Nathaniel > Patches 0001-0003 pushed to master, ipa-4-1. Was the typo you found yesterday ("I found a small typo in patch 0002. I will attach it in reply to Petr's review email") fixed in this version? Martin From redhatrises at gmail.com Wed Dec 3 13:38:27 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 3 Dec 2014 06:38:27 -0700 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <547F0A9C.7070908@redhat.com> References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> <547F0A9C.7070908@redhat.com> Message-ID: Yeah. This is what I was talking about ipaclient builds still relying on Makefile.am. Plus if you remove the ipaclient/Makefile.am and then run `make rpm`, it fails to find the *.py files to package into the rpm. Gabe On Wed, Dec 3, 2014 at 6:05 AM, Martin Kosek wrote: > On 12/03/2014 05:13 AM, Gabe Alford wrote: > > This patch removes the changelog and Makefile.am for ipaclient as well. > > > > Thanks, > > > > Gabe > > > > On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek wrote: > > > >> On 12/01/2014 04:25 PM, Rob Crittenden wrote: > >>> Gabe Alford wrote: > >>>> > >>>> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek >>>> > wrote: > >>>> > >>>> On 11/30/2014 03:28 AM, Gabe Alford wrote: > >>>> > Ignore the last patch. Updated patch attached. > >>>> > > >>>> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford > >>>> > wrote: > >>>> > > >>>> >> This patch removes the app_PYTHON usage. > >>>> >> > >>>> >> Thanks, > >>>> >> > >>>> >> Gabe > >>>> >> > >>>> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek < > mkosek at redhat.com > >>>> > wrote: > >>>> >> > >>>> >>> Exactly, this was the message from Martin :-) I did not test > it > >>>> myself, > >>>> >>> but > >>>> >>> removing all app_PYTHON should be benign given we use Python > >>>> setup.py > >>>> >>> packaging. > >>>> >>> > >>>> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: > >>>> >>>> Thanks guys. Sounds like it would be better to submit a patch > >> that > >>>> >>> removes > >>>> >>>> app_PYTHON if it is considered dead code. > >>>> >>>> > >>>> >>>> Gabe > >>>> >>>> > >>>> >>>> On Thursday, November 27, 2014, Petr Spacek < > >> pspacek at redhat.com > >>>> > wrote: > >>>> >>>> > >>>> >>>>> On 27.11.2014 11:00, Martin Basti wrote: > >>>> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: > >>>> >>>>>>> Hello, > >>>> >>>>>>> > >>>> >>>>>>> Wondering if I could get a review. Updated patch > >>>> attached. > >>>> >>>>>>> > >>>> >>>>>>> Thanks, > >>>> >>>>>>> Gabe > >>>> >>>>>>> > >>>> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > >>>> > >>>> >>>>> > >>>> >>>>>>> redhatrises at gmail.com > >>> > >>>> >> wrote: > >>>> >>>>>>> > >>>> >>>>>>> Hello, > >>>> >>>>>>> > >>>> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 > >>>> >>>>>>> > >>>> >>>>>>> Thanks, > >>>> >>>>>>> > >>>> >>>>>>> Gabe > >>>> >>>>>>> > >>>> >>>>>>> > >>>> >>>>>>> > >>>> >>>>>> Hello, > >>>> >>>>>> > >>>> >>>>>> sorry for late response. > >>>> >>>>>> > >>>> >>>>>> We push this ticket to backlog, as it would be part of > build > >>>> system > >>>> >>>>> refactoring. > >>>> >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the > >> better > >>>> >>>>> solution is > >>>> >>>>>> remove it, instead of keeping dead code up-to-date. > >>>> >>>>> > >>>> >>>>> Just to clarify: > >>>> >>>>> It can be pushed if it works, there is no need to postpone > >>>> accepting > >>>> >>> patch > >>>> >>>>> if > >>>> >>>>> the patch seems okay and doesn't break anything. > >>>> >>>>> > >>>> >>>>> Martin, please keep in mind that contributions are welcome > at > >>>> any time. > >>>> >>>>> > >>>> >>>>> Milestones in Trac reflect our view of priorities but it > >> doesn't > >>>> >>> prevent us > >>>> >>>>> from accepting correct patches from contributions at any > >> time, no > >>>> >>> matter > >>>> >>>>> which > >>>> >>>>> priority is stated in Trac (or even if there is no ticket > for > >>>> it ...). > >>>> >>>>> > >>>> >>>>> -- > >>>> >>>>> Petr^2 Spacek > >>>> > >>>> Worked in my tests, I did not see any breakage. I guess we can > also > >>>> remove the > >>>> ipa-client/ipaclient/Makefile.am while we are at it. > >>>> > >>>> Martin > >>>> > >>>> > >>>> It looks like the ipaclient/Makefile.am is still being used. I tried > >>>> removing it and there were errors in the build, but maybe I am wrong? > >>> > >>> It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. > >>> > >>> Feel free to rip out the outdated hg ChangeLog stuff though. > >>> > >>> rob > >> > >> I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not > >> about > >> ipa-client/Makefile.am - we still need this one as Rob correctly said. > >> > >> The failure that Gabe hit in build probably comes from the the SUBDIR > >> reference > >> in ipa-client/Makefile.am file. I assume that if the reference is > removed, > >> the > >> removal should work. > >> > >> And yes, you can remove the Changelog too if you are OK with it :) > >> > >> Martin > >> > > > > I think you did some error during the process. This is what I got: > > $ git clean -fxd > $ git apply ... > $ make rpms > ... > checking that generated files are newer than configure... done > configure: creating ./config.status > config.status: error: cannot find input file: `Makefile.in' > Makefile:84: recipe for target 'client-autogen' failed > make: *** [client-autogen] Error 1 > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Wed Dec 3 14:32:56 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 03 Dec 2014 09:32:56 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <547F139A.4050306@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> <1417550277.5864.82.camel@redhat.com> <547F139A.4050306@redhat.com> Message-ID: <1417617176.5864.88.camel@redhat.com> On Wed, 2014-12-03 at 14:43 +0100, Martin Kosek wrote: > On 12/02/2014 08:57 PM, Nathaniel McCallum wrote: > > On Tue, 2014-11-18 at 20:26 +0100, Petr Vobornik wrote: > >> On 13.11.2014 08:53, Martin Kosek wrote: > >>> On 11/13/2014 08:51 AM, Nathaniel McCallum wrote: > >>>> On Thu, 2014-11-13 at 08:48 +0100, Martin Kosek wrote: > >>>>> On 11/12/2014 11:37 PM, Nathaniel McCallum wrote: > >>>>>> On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote: > >>>>>>> On 11/07/2014 04:44 PM, Petr Vobornik wrote: > >>>>>>>> On 7.11.2014 08:58, Martin Kosek wrote: > >>>>>>>>> On 11/04/2014 05:17 PM, Nathaniel McCallum wrote: > >>>>>>>>>> On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > >>>>>>>>>>>> On 10/29/2014 10:37 AM, Martin Kosek wrote: > >>>>>>>>>>>>> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > >>>>>>>>>>>>>> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>>>>>> This patch gives the administrator variables to control the size of > >>>>>>>>>>>>>>> the authentication and synchronization windows for OTP tokens. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4511 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> NOTE: There is one known issue with this patch which I don't know > >>>>>>>>>>>>>>> how to > >>>>>>>>>>>>>>> solve. This patch changes the schema in > >>>>>>>>>>>>>>> install/share/60ipaconfig.ldif. > >>>>>>>>>>>>>>> On an upgrade, all of the new attributeTypes appear correctly. > >>>>>>>>>>>>>>> However, > >>>>>>>>>>>>>>> the modifications to the pre-existing objectClass do not show up > >>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>> server. What am I doing wrong? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> After modifying ipaGuiConfig manually, everything in this patch > >>>>>>>>>>>>>>> works > >>>>>>>>>>>>>>> just fine. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This new version takes into account the new (proper) OIDs and > >>>>>>>>>>>>>> attribute > >>>>>>>>>>>>>> names. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks Nathaniel! > >>>>>>>>>>>>> > >>>>>>>>>>>>>> The above known issue still remains. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Petr3, any idea what could have gone wrong? ObjectClass MAY list > >>>>>>>>>>>>> extension > >>>>>>>>>>>>> should work just fine, AFAIK. > >>>>>>>>>>>> > >>>>>>>>>>>> You added a blank line to the LDIF file. This is an entry separator, so > >>>>>>>>>>>> the objectClasses after the blank line don't belong to cn=schema, so > >>>>>>>>>>>> they aren't considered in the update. > >>>>>>>>>>>> Without the blank line it works fine. > >>>>>>>>>>> > >>>>>>>>>>> Thanks for the catch! > >>>>>>>>>>> > >>>>>>>>>>> Here is a version without the blank line. > >>>>>>>>>> > >>>>>>>>>> I forgot to remove the old steps defines. This patch performs this > >>>>>>>>>> cleanup. > >>>>>>>>> > >>>>>>>>> I am now wondering, is the global config object really the nest place to > >>>>>>>>> add these OTP specific settings? > >>>>>>>>> > >>>>>>>>> I would prefer not to overload the object and instead: > >>>>>>>>> - create new ipaOTPConfig objectclass > >>>>>>>>> - add it to cn=otp,$SUFFIX > >>>>>>>>> - create otpconfig-mod and otpconfig-show commands to follow an example > >>>>>>>>> of dnsconfig-* and trustconfig-* commands > >>>>>>>>> > >>>>>>>>> IMO, this would allow more flexibility for the OTP settings and would > >>>>>>>>> also scale better for the future updates. > >>>>>>>> > >>>>>>>> +1 > >>>>>>>> > >>>>>>>> I will comment the patch as if ^^ would not exist because it will still be > >>>>>>>> needed in the new plugin. > >>>>>>>> > >>>>>>>> Because of ^^ I did not test, just read. > >>>>>>>> > >>>>>>>> 1. Got: > >>>>>>>> install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not > >>>>>>>> recommended in array initializers > >>>>>>>> > >>>>>>>> Please run: > >>>>>>>> jsl -nofilelisting -nosummary -nologo -conf jsl.conf > >>>>>>>> in install/ui directory > >>>>>>>> > >>>>>>>> The goal is no have no warnings and errors. > >>>>>>>> > >>>>>>>> 2. new attrs should be added to 'System: Read Global Configuration' managed > >>>>>>>> permission > >>>>>>> > >>>>>>> +1. Though if we go with OTP config, it should be called > >>>>>>> > >>>>>>> System: Read OTP Configuration > >>>>>>> > >>>>>>> Martin > >>>>>> > >>>>>> Attached is a new set of patches that replaces this single patch. This > >>>>>> now fixes multiple issues. > >>>>>> > >>>>>> I now create two new entries: > >>>>>> * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX > >>>>>> * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX > >>>>>> > >>>>>> There are two corresponding CLI commands: > >>>>>> * totpconfig-(show|mod) > >>>>>> * hotpconfig-(show|mod) > >>>>>> > >>>>>> There is no UI support for this yet (pointers welcome). > >>>>>> > >>>>>> This is designed so that eventually tokens can grow a per-token > >>>>>> override, but I have not yet implemented this feature (it should be easy > >>>>>> in the future). > >>>>>> > >>>>>> Additionally, I had to do some shared refactoring to address issues in > >>>>>> ipa-otp-lasttoken, which is why all of these are now merged into a > >>>>>> single patch set. > >>>>>> > >>>>>> Nathaniel > >> > >> I'm little confused with a state of reviews. Thierry were some of the > >> patches ACKed in different threads or are they under review (I'm not > >> reviewing DS plugin parts)? > > > > Patches 0001, 0002, 0003 are ACKed by Thierry, but not merged. They can > > and should be merged as they fix an independent bug. > > > >>>>> Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want > >>>>> to make TOTP/HOTP token config as separate entries (to enable future per-token > >>>>> overrides), your approach should make sense. Rather adding Rob to CC for sanity. > >>>> > >>>> That would work too. I'm open to that. > >>>> > >>>>> I am just not sure we should create them as separate plugins, I think the new > >>>>> commands should be rather added to otp plugin directly so that they show in > >>>>> "ipa help otptoken" instead of adding 2 new topics just for OTP config. > >>>> > >>>> I can play with that. > >> > >> Do you plan to change it? I like the idea of a single point of help for > >> OTP but I'm also unsure about the length of the commands. Current > >> solution is also more consistent with a rest of the framework. Would it > >> be something like: > >> > >> otptoken-totpconfig-(show|mod) > >> otptoken-hotpconfig-(show|mod) > > > > In the latest patch, I merged totpconfig-* and hotpconfig-* into a > > single otpconfig-* plugin. > > > >> Maybe it would be better to introduce more help topics for otp. This > >> concept is used for HBAC already: > >> > >> $ ipa help hbac > >> hbacsvcgroup HBAC Service Groups > >> hbacsvc HBAC Services > >> hbacrule Host-based access control > >> > >> $ ipa help hbacrule > >> Host-based access control > >> ... a lot of text > >> > >> So we could introduce otp umbrella topic: > >> > >> $ ipa help otp > >> opttoken OTP tokens' > >> totpconfig TOTP configuration options > >> hotpconfig HOTP configuration options > > > > I added a fifth patch (0005) which creates an otp umbrella topic. We can > > merge it or not. > > > >>>> Nathaniel > >>> > >>> No worries ATM, you can wait for proper review. I was just looking at the new > >>> API to make sure we are on the same page - we seem to mostly are. > >>> > >>> Martin > >>> > >> > >> Commenting just patch 0004: > >> > >> 1. Requires rebase because of API change. > > > > Fixed. > > > >> 2. git diff HEAD~4 -U0 | pep8 --diff > >> I would ignore E124 and fix E302 (5x) > > > > Fixed. > > > >> I did not test actual functionality yet. > > > > The attached patches I think have a much better overall aesthetic. Now > > patch 0004 introduces only two new commands: > > * otpconfig-mod > > * otpconfig-show > > > > Under the covers, a single configuration entity is used: > > * cn=otp,cn=etc,$SUFFIX > > > > Other than these small changes, there are no changes to patch 0004. I > > have not tested the latest changes, however, due to an unrelated build > > issue I'm working on. > > > > Patch 0005 introduces an umbrella help topic for all OTP related > > commands (currently: otpconfig, otptoken, otptoken-yubikey). > > > > Nathaniel > > > > Patches 0001-0003 pushed to master, ipa-4-1. > > Was the typo you found yesterday ("I found a small typo in patch 0002. I will > attach it in reply to Petr's review email") fixed in this version? Yes. From pspacek at redhat.com Wed Dec 3 15:41:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 03 Dec 2014 16:41:12 +0100 Subject: [Freeipa-devel] disaster recovery if replica was compromised Message-ID: <547F2F18.60309@redhat.com> Hello, I wonder what we can recommend as disaster recovery procedure for cases where a replica (its LDAP database) was compromised. Saying "you are screwed" doesn't sound like the right answer :-D It is clear that all passwords and keys have to be changed and complete replica re-installation is inevitable. I would expect something like: - install fresh FreeIPA server and do not connect it to the compromised topology - run migrate-ds to get users, groups etc. (review is necessary) - use this to force all users to change passwords> - use this to re-generate all certificates ... This sounds like yet another case for FreeIPA-FreeIPA migration tool which could import SUDO rules and all other FreeIPA-specific stuff. Any ideas? -- Petr^2 Spacek From pspacek at redhat.com Wed Dec 3 16:04:30 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 03 Dec 2014 17:04:30 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <20141202112107.1d0032d7@willson.usersys.redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> Message-ID: <547F348E.3090401@redhat.com> On 2.12.2014 17:21, Simo Sorce wrote: > On Tue, 02 Dec 2014 15:56:28 +0100 > Petr Spacek wrote: > >> On 1.12.2014 17:12, Simo Sorce wrote: >>> On Mon, 01 Dec 2014 16:17:54 +0100 >>> Petr Spacek wrote: >>> >>>> On 14.11.2014 17:31, Petr Spacek wrote: >>>>> On 14.11.2014 02:22, Simo Sorce wrote: >>>>>> On Tue, 11 Nov 2014 16:29:51 +0100 >>>>>> Petr Spacek wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> this thread is about RFE >>>>>>> "IPA servers when installed should register themselves in the >>>>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >>>>>>> >>>>>>> It is not a complete design, just a raw idea. >>>>>>> >>>>>>> >>>>>>> Use case >>>>>>> ======== >>>>>>> FreeIPA installation to a network with existing DNS >>>>>>> infrastructure + network administrator who is not willing to >>>>>>> add/maintain new DNS servers "just for FreeIPA". >>>>>>> >>>>>>> >>>>>>> High-level idea >>>>>>> =============== >>>>>>> - Transform dns* commands from FreeIPA framework to equivalent >>>>>>> "nsupdate" commands and send DNS updates to existing DNS >>>>>>> servers. >>>>>>> - Provide necessary encryption/signing keys to nsupdate. >>>>>>> >>>>>>> >>>>>>> 1) Integration to FreeIPA framework >>>>>>> =================================== >>>>>>> First of all, we need to decide if "external DNS integration" >>>>>>> can be used at the same time with FreeIPA-integrated DNS or not. >>>>>>> Side-question is what to do if a first server is installed with >>>>>>> external-DNS but another replica is being installed with >>>>>>> integrated-DNS and so on. >>>>>> >>>>>> I think being able to integrate with an external DNS is >>>>>> important, and not just at the server level, being able to >>>>>> distribute TSIG keys to client would be nice too, though a lot >>>>>> less important, than getting server integration.. >>>>> >>>>> Using TSIG on many clients is very problematic. Keep in mind that >>>>> TSIG is basically HMAC computed using symmetric key so: >>>>> a) Every client would have to use the same key - this is a >>>>> security nightmare. b) We would have to distribute and maintain >>>>> many keys for many^2 clients, which is an administrative >>>>> nightmare. >>>>> >>>>> For *clients* I would rather stay with GSS-TSIG which is much more >>>>> manageable because we can use Kerberos trust and Keytab >>>>> distribution is already solved by ipa-client-install. >>>>> >>>>> Alternative for clients would be to use FreeIPA server as proxy >>>>> which encapsulates TSIG keys and issues update requests on behalf >>>>> of clients. This would be FreeIPA-specific but any >>>>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>>>> >>>>> TSIG standard explicitly says that there is no standardized >>>>> distribution mechanism. >>>>> >>>>>>> In other words, the question is if current "dns.py" plugin >>>>>>> shipped with FreeIPA framework should be: >>>>>>> >>>>>>> a) Extended dns.py with dnsexternal-* commands >>>>>>> ---------------------------------------------- >>>>>>> Disadvantages: >>>>>>> - It complicate FreeIPA DNS interface which is a complex beast >>>>>>> even now. >>>>>>> - We would have add condition to every DNS API call in >>>>>>> installers which would increase horribleness of the installer >>>>>>> code even more (or add another layer of abstraction...). >>>>>> >>>>>> I agree having a special command is undesirable. >>>>>>> >>>>>>> - I don't see a point in using integrated-DNS with external-DNS >>>>>>> at the same time. To use integrated-DNS you have to get a >>>>>>> proper DNS delegation from parent domain - and if you can get >>>>>>> the delegation then there is no point in using external DNS ... >>>>>> >>>>>> I disagree on this point, it makes a lot of sense to have some >>>>>> zones maintained by IPA and ... some not. >>>>>> >>>>>>> Advantages: >>>>>>> - You can use external & integrated DNS at the same time. >>>>>> >>>>>> We can achieve the same w/o a new ipa level command. >>>>> >>>>> This needs to be decided by FreeIPA framework experts ... >>>>> >>>>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>>>> proxy would provide all ipa dns* commands and dispatch user-issued >>>>> commands to appropriate FreeIPA-plugin (internal-dns or >>>>> external-dns). This decision could depend on some values in LDAP. >>>>> >>>>>>> b) Replace dns.py with another implementation of current >>>>>>> dnszone-* & dnsrecord-* API. >>>>>>> --------------------------------------------------------------------- >>>>>>> This seems like a cleaner approach to me. It could be shipped as >>>>>>> ipa-server-dns-external package (opposed to "standard" >>>>>>> ipa-server-dns package). >>>>>>> >>>>>>> Advantages: >>>>>>> - It could seamlessly work with FreeIPA client installer because >>>>>>> the dns*->nsupdate command transformation would be done on >>>>>>> FreeIPA server and client doesn't need to know about it. >>>>>>> - Does not require re-training/not much new documentation >>>>>>> because commands are the same. >>>>>>> >>>>>>> Disadvantages: >>>>>>> - You can't use integrated & external DNS at the same time (but >>>>>>> I don't think it justifies the added complexity). >>>>>> >>>>>> I disagree. >>>>>> >>>>>> One of the reason to use a mix is to allow smooth migrations >>>>>> where zones are moved into (or out of) IPA one by one. >>>>> >>>>> Good point, I agree. I will focus on supporting both (internal and >>>>> external) DNS at the same time. >>>>> >>>>>>> Petr^3 or anyone else, what do you propose? >>>>>> >>>>>> I think what I'd like to see is to be able to configure a DNS >>>>>> zone in LDAP and mark it external. >>>>>> The zone would held the TSIG keys necessary to perform DNS >>>>>> updates. >>>>>> >>>>>> When the regular ipa dnsrecord-add etc... commands are called, >>>>>> the framework detects that the zone is "external", fewttches the >>>>>> TSIG key (if the user has access to it) and spawn an nsupdate >>>>>> command that will perform the update against whatever DNS server >>>>>> is authoritative for the zone. >>>>>> >>>>>> Some commands may be disabled if the zone is external and >>>>>> appropriate errors would be returned. >>>>> >>>>> Correct, this will be inevitable. >>>>> >>>>>>> 2) Authentication to external DNS server/keys >>>>>>> ============================================= >>>>>>> This is separate problem from FreeIPA framework integration. >>>>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) >>>>>>> or keytabs (for DNS GSS-TSIG) and distribute them somehow to >>>>>>> replicas so every replica can update DNS records as necessary. >>>>>> >>>>>> For TSIG keys I think we should just store them in a LDAP record, >>>>>> see above. >>>>> >>>>> Without any encryption? Am I missing something? >>>>> >>>>>> For keytabs we can simply store them just like any other >>>>>> kerberos key if we really need it (in a trust case for example, >>>>>> we may not need a new keytab, we may be allowed to use our own >>>>>> credentials through the trust. So we'll need to explore a bit >>>>>> how to properly express that in configuration. REtrieval ok >>>>>> keytabs is then just a matter of running ipa-getkeytab -r on the >>>>>> replica that needs it. >>>>>> >>>>>>> This will be the funny part because in case of AD trusts we have >>>>>>> chicken-egg problem. You need to establish trust to get ticket >>>>>>> for DNS/dc1.ad.example at AD principal but you can't (I guess) >>>>>>> establish trust until proper DNS records are in place ... >>>>>> >>>>>> No, in this case we should create the records at trust >>>>>> establishment time using the admin credentials we have been >>>>>> provided. NO chicken-egg issue. >>>>> >>>>> Sorry, we surely *have* a chicken-egg issue because >>>>> ipa-server-install is completely separate step from from >>>>> ipa-adtrust-install which is completely separate from ipa >>>>> trust-add. (And there is nothing which forces user to establish AD >>>>> trust right after ipa-server-install finished.) >>>>> >>>>> Also, in some cases it is not possible to use the same credentials >>>>> for trust establishment and for DNS updates on AD. Think about >>>>> one-way trust or possibly two-way trust but established using >>>>> pre-shared trust secret (which is AFAIK not usable for kinit). >>>>> >>>>> Alexander, could you clarify if it is possible to create an AD >>>>> trust *without* DNS records for FreeIPA side of the trust? >>>>> >>>>> Another problem is that reliance on AD trusts would effectively >>>>> prevent interoperability with non-AD DNS servers (think Infoblox >>>>> or standard BIND). >>>>> >>>>> I tend to think that we will need to obtain credentials (AD >>>>> login/pass/keytab/TSIG key) as one of ipa-server-install >>>>> parameters so all DNS updates can be done right away. This would >>>>> allow us have ipa-server-install script which in fact produces >>>>> *working* FreeIPA domain. In other cases ipa-server-install would >>>>> end but the FreeIPA domain would not be functional because of >>>>> missing records in DNS. >>>>> >>>>>>> For 'experimental' phase I would go with pre-populated CCcache, >>>>>>> i.e. admin will manually do kinit Administrator at AD and then run >>>>>>> FreeIPA installer. >>>>>> >>>>>> We already to this, so there is no need to invent anything here >>>>>> IMO. >>>>> >>>>> Except for cases mentioned above ... >>>>> >>>>>>> Maybe we can re-use trust secret somehow? I don't know, I will >>>>>>> reach out to AD experts with questions. >>>>>>> >>>>>>> This area needs more research but for now it seems feasible to >>>>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs >>>>>>> so "only" the chicken-egg problem is left. >>>>>>> >>>>>>> This will need new LDAP schema but I will propose something when >>>>>>> I'm done with investigation. >>>>>> >>>>>> Please let me know if you agree with a new zone type as a way to >>>>>> "forward" updates. >>>>> >>>>> Generally I agree, it was my plan too. My main concern is not >>>>> about LDAP structure but about FreeIPA framework and about >>>>> workflow in general. It will be fun to extend the spaghetti code >>>>> we have ... >>>> >>>> Ping :-) I would like to move the discussion forward. >>>> >>>> Alexander, could you please comment on authentication to AD >>>> mentioned above? >>>> >>>> Simo and everybody else, what do you think about client use-case, >>>> i.e. forwarding DNS updates from FreeIPA clients to external DNS >>>> infrastructure? What about security implications (keeping in mind >>>> that TSIG keys are symmetric)? >>>> >>>> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy >>>> instead of nsupdate command (to hide TSIG key behind FreeIPA)? >>> >>> Remind me this, when a client tries to update the DNS, does it >>> always contact its own DNS server first, or does it try to go >>> straight to the authoritative DNS server? >> >> It should go straight to authoritative servers listed in NS records. >> >>> I do not like the XML-RPC->DNS approach as it requires a special >>> client, leaving out the majority of clients. >> >> Yes, it is an option of last resort (because I don't see a way how to >> be compatible with standard clients, see the point above). >> >>> Also, I am thinking that we only _need_ to set infrastructure >>> relevant names (like IPA servers SRV records), but if someone >>> decides not to use IPA for the DNS we may decide that it is not our >>> responsibility to provide a full end-to-end client dns update >>> solution. >> >> If we can agree on that then I'm fine with it. > > Yes the more I think of it, the more I prefer to wait in trying to > solve the clients problem. > >>> So I would concentrate on making it possible for IPA *Servers* to >>> use a private TSIG key to update infrastructure relevant names, and >>> possibly defer the clients side of the problem. >> >> Speaking about native clients, two-way AD trust should nicely work >> with clients because clients could go straight to the AD and >> authenticate using host keytab from FreeIPA realm. It will not work >> in other cases but it is still better than nothing. > > Yes, this has been accounted for. > >>> We could use an internal bus on the server to allow the ipa >>> framework to use nsupdate w/o gaining direct access to the TSIG >>> key, this way admins can use ipa dnsrecod-add and friends w/o >>> exposing the key. >> >> I agree with the idea but it depends on an authorization daemon you >> have proposed earlier (in different discussion). Do you see it as >> reasonable goal for FreeIPA 4.2 time-span? > > I wouldn't say a definite no, but I am not confident we can. > >> If the authorization daemon is too far away, would it be okay to >> support external DNS domains only for ipa* installers but do not >> support it for FreeIPA users? (I.e. basically store the key in HSM >> which is not accessible to users - that is what we do with DNSSEC >> keys now.) > > Yes I think it would be fine as a first step. Okay, I tried to summarize current goals on: http://www.freeipa.org/page/V4/External_DNS_integration_with_installer At the moment I see a first obstacle: $ ipa-replica-manage can authenticate to LDAP servers using: - LDAPI (when running as root) - GSSAPI - DM password The problem is that we would need to have access to TSIG keys even when using GSSAPI and DM password authentication ... so we again need the authorization daemon. Alternatively we can use Vault for TSIG key storage and use Vault's capability to share keys among many users. In that case we don't have problem with key distribution nor authorization. Another possibility is to say that replica-deletion can be done only by root user or that updates to external DNS are supported only when running ipa-replica-manage as root. Other tools (ipa-*install*) should not have this problem because they are running under the root anyway. Ideas are more than welcome! -- Petr^2 Spacek From mbasti at redhat.com Wed Dec 3 16:16:23 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 03 Dec 2014 17:16:23 +0100 Subject: [Freeipa-devel] [PATCH 3] ipa-client-install shouldn't be eager in specifying zone when doing nsupdate In-Reply-To: <20141202120013.GA24924@redhat.com> References: <20141202120013.GA24924@redhat.com> Message-ID: <547F3757.8090806@redhat.com> On 02/12/14 13:00, Jan Pazdziora wrote: > Hello, > > presumably explicitly specifying zone is not needed and can be > harmful. > This should be fixed in template for uploading SSHFP keys as well. I have zone bububu.test. 2014-12-03T04:00:36Z DEBUG debug zone client.bububu.test. update delete test.client.bububu.test. IN SSHFP show send update add test.client.bububu.test. 1200 IN SSHFP 1 1 8FD003E98D818E4E2813672234410835AB5844AC update add test.client.bububu.test. 1200 IN SSHFP 1 2 37BF6366A44B67F6CA8FF8A8313B7C964CEA971CCB3E092D775FDF082170AAA4 update add test.client.bububu.test. 1200 IN SSHFP 3 1 3651173F6737DF24EB6494434AC5968B3C90B749 update add test.client.bububu.test. 1200 IN SSHFP 3 2 97EF4030A9DD471A3D4730A819B3A662E11994BB20AFC56FC3875AB1662260BF show send -- Martin Basti From pspacek at redhat.com Wed Dec 3 16:16:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 03 Dec 2014 17:16:34 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <5476F633.30808@redhat.com> <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> <547F0A9C.7070908@redhat.com> Message-ID: <547F3762.1040702@redhat.com> On 3.12.2014 14:38, Gabe Alford wrote: > Yeah. This is what I was talking about ipaclient builds still relying on > Makefile.am. Plus if you remove the ipaclient/Makefile.am and then run > `make rpm`, it fails to find the *.py files to package into the rpm. > > Gabe > > On Wed, Dec 3, 2014 at 6:05 AM, Martin Kosek wrote: > >> On 12/03/2014 05:13 AM, Gabe Alford wrote: >>> This patch removes the changelog and Makefile.am for ipaclient as well. >>> >>> Thanks, >>> >>> Gabe >>> >>> On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek wrote: >>> >>>> On 12/01/2014 04:25 PM, Rob Crittenden wrote: >>>>> Gabe Alford wrote: >>>>>> >>>>>> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek >>>>> > wrote: >>>>>> >>>>>> On 11/30/2014 03:28 AM, Gabe Alford wrote: >>>>>> > Ignore the last patch. Updated patch attached. >>>>>> > >>>>>> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford >>>>>> > wrote: >>>>>> > >>>>>> >> This patch removes the app_PYTHON usage. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> >>>>>> >> Gabe >>>>>> >> >>>>>> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek < >> mkosek at redhat.com >>>>>> > wrote: >>>>>> >> >>>>>> >>> Exactly, this was the message from Martin :-) I did not test >> it >>>>>> myself, >>>>>> >>> but >>>>>> >>> removing all app_PYTHON should be benign given we use Python >>>>>> setup.py >>>>>> >>> packaging. >>>>>> >>> >>>>>> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: >>>>>> >>>> Thanks guys. Sounds like it would be better to submit a patch >>>> that >>>>>> >>> removes >>>>>> >>>> app_PYTHON if it is considered dead code. >>>>>> >>>> >>>>>> >>>> Gabe >>>>>> >>>> >>>>>> >>>> On Thursday, November 27, 2014, Petr Spacek < >>>> pspacek at redhat.com >>>>>> > wrote: >>>>>> >>>> >>>>>> >>>>> On 27.11.2014 11:00, Martin Basti wrote: >>>>>> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: >>>>>> >>>>>>> Hello, >>>>>> >>>>>>> >>>>>> >>>>>>> Wondering if I could get a review. Updated patch >>>>>> attached. >>>>>> >>>>>>> >>>>>> >>>>>>> Thanks, >>>>>> >>>>>>> Gabe >>>>>> >>>>>>> >>>>>> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >>>>>> >>>>>> >>>>> >>>>>> >>>>>>> > redhatrises at gmail.com >>>>> >>>>>> >> wrote: >>>>>> >>>>>>> >>>>>> >>>>>>> Hello, >>>>>> >>>>>>> >>>>>> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >>>>>> >>>>>>> >>>>>> >>>>>>> Thanks, >>>>>> >>>>>>> >>>>>> >>>>>>> Gabe >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> sorry for late response. >>>>>> >>>>>> >>>>>> >>>>>> We push this ticket to backlog, as it would be part of >> build >>>>>> system >>>>>> >>>>> refactoring. >>>>>> >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the >>>> better >>>>>> >>>>> solution is >>>>>> >>>>>> remove it, instead of keeping dead code up-to-date. >>>>>> >>>>> >>>>>> >>>>> Just to clarify: >>>>>> >>>>> It can be pushed if it works, there is no need to postpone >>>>>> accepting >>>>>> >>> patch >>>>>> >>>>> if >>>>>> >>>>> the patch seems okay and doesn't break anything. >>>>>> >>>>> >>>>>> >>>>> Martin, please keep in mind that contributions are welcome >> at >>>>>> any time. >>>>>> >>>>> >>>>>> >>>>> Milestones in Trac reflect our view of priorities but it >>>> doesn't >>>>>> >>> prevent us >>>>>> >>>>> from accepting correct patches from contributions at any >>>> time, no >>>>>> >>> matter >>>>>> >>>>> which >>>>>> >>>>> priority is stated in Trac (or even if there is no ticket >> for >>>>>> it ...). >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Petr^2 Spacek >>>>>> >>>>>> Worked in my tests, I did not see any breakage. I guess we can >> also >>>>>> remove the >>>>>> ipa-client/ipaclient/Makefile.am while we are at it. >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>>> It looks like the ipaclient/Makefile.am is still being used. I tried >>>>>> removing it and there were errors in the build, but maybe I am wrong? >>>>> >>>>> It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. >>>>> >>>>> Feel free to rip out the outdated hg ChangeLog stuff though. >>>>> >>>>> rob >>>> >>>> I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not >>>> about >>>> ipa-client/Makefile.am - we still need this one as Rob correctly said. >>>> >>>> The failure that Gabe hit in build probably comes from the the SUBDIR >>>> reference >>>> in ipa-client/Makefile.am file. I assume that if the reference is >> removed, >>>> the >>>> removal should work. >>>> >>>> And yes, you can remove the Changelog too if you are OK with it :) >>>> >>>> Martin >>>> >>> >> >> I think you did some error during the process. This is what I got: >> >> $ git clean -fxd >> $ git apply ... >> $ make rpms >> ... >> checking that generated files are newer than configure... done >> configure: creating ./config.status >> config.status: error: cannot find input file: `Makefile.in' >> Makefile:84: recipe for target 'client-autogen' failed >> make: *** [client-autogen] Error 1 Lukas, could you please help us to find a way from the Autotools maze? :-) Thank you! -- Petr^2 Spacek From pvoborni at redhat.com Wed Dec 3 16:18:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 03 Dec 2014 17:18:27 +0100 Subject: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type In-Reply-To: <1415898295.9116.12.camel@redhat.com> References: <1415898295.9116.12.camel@redhat.com> Message-ID: <547F37D3.6040701@redhat.com> On 13.11.2014 18:04, Nathaniel McCallum wrote: > Additionally, fix a small bug in ipa-kdb so that the disabled User > Auth Type is properly handled. > > https://fedorahosted.org/freeipa/ticket/4720 > The patch itself looks good to me, VERSION needs to be updated though. But I don't think it works. Don't know why. In my setup, user's config was not ignored. When I tested login in Web UI with: - global config: disabled, otp - user fbar's config: password - fbar had an hotp token assigned I could still login with password and not with otp. If I added 'otp' to fbar's config, I could also login with otp. -- Petr Vobornik From lslebodn at redhat.com Wed Dec 3 16:30:23 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 3 Dec 2014 17:30:23 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> Message-ID: <20141203163023.GB24459@mail.corp.redhat.com> On (02/12/14 21:13), Gabe Alford wrote: >This patch removes the changelog and Makefile.am for ipaclient as well. > >Thanks, > >Gabe > >On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek wrote: > >> On 12/01/2014 04:25 PM, Rob Crittenden wrote: >> > Gabe Alford wrote: >> >> >> >> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek > >> > wrote: >> >> >> >> On 11/30/2014 03:28 AM, Gabe Alford wrote: >> >> > Ignore the last patch. Updated patch attached. >> >> > >> >> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford >> >> > wrote: >> >> > >> >> >> This patch removes the app_PYTHON usage. >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Gabe >> >> >> >> >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek > >> > wrote: >> >> >> >> >> >>> Exactly, this was the message from Martin :-) I did not test it >> >> myself, >> >> >>> but >> >> >>> removing all app_PYTHON should be benign given we use Python >> >> setup.py >> >> >>> packaging. >> >> >>> >> >> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: >> >> >>>> Thanks guys. Sounds like it would be better to submit a patch >> that >> >> >>> removes >> >> >>>> app_PYTHON if it is considered dead code. >> >> >>>> >> >> >>>> Gabe >> >> >>>> >> >> >>>> On Thursday, November 27, 2014, Petr Spacek < >> pspacek at redhat.com >> >> > wrote: >> >> >>>> >> >> >>>>> On 27.11.2014 11:00, Martin Basti wrote: >> >> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: >> >> >>>>>>> Hello, >> >> >>>>>>> >> >> >>>>>>> Wondering if I could get a review. Updated patch >> >> attached. >> >> >>>>>>> >> >> >>>>>>> Thanks, >> >> >>>>>>> Gabe >> >> >>>>>>> >> >> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >> >> >> >> >>>>> >> >> >>>>>>> > > >> >> >> wrote: >> >> >>>>>>> >> >> >>>>>>> Hello, >> >> >>>>>>> >> >> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 >> >> >>>>>>> >> >> >>>>>>> Thanks, >> >> >>>>>>> >> >> >>>>>>> Gabe >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>> Hello, >> >> >>>>>> >> >> >>>>>> sorry for late response. >> >> >>>>>> >> >> >>>>>> We push this ticket to backlog, as it would be part of build >> >> system >> >> >>>>> refactoring. >> >> >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the >> better >> >> >>>>> solution is >> >> >>>>>> remove it, instead of keeping dead code up-to-date. >> >> >>>>> >> >> >>>>> Just to clarify: >> >> >>>>> It can be pushed if it works, there is no need to postpone >> >> accepting >> >> >>> patch >> >> >>>>> if >> >> >>>>> the patch seems okay and doesn't break anything. >> >> >>>>> >> >> >>>>> Martin, please keep in mind that contributions are welcome at >> >> any time. >> >> >>>>> >> >> >>>>> Milestones in Trac reflect our view of priorities but it >> doesn't >> >> >>> prevent us >> >> >>>>> from accepting correct patches from contributions at any >> time, no >> >> >>> matter >> >> >>>>> which >> >> >>>>> priority is stated in Trac (or even if there is no ticket for >> >> it ...). >> >> >>>>> >> >> >>>>> -- >> >> >>>>> Petr^2 Spacek >> >> >> >> Worked in my tests, I did not see any breakage. I guess we can also >> >> remove the >> >> ipa-client/ipaclient/Makefile.am while we are at it. >> >> >> >> Martin >> >> >> >> >> >> It looks like the ipaclient/Makefile.am is still being used. I tried >> >> removing it and there were errors in the build, but maybe I am wrong? >> > >> > It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. >> > >> > Feel free to rip out the outdated hg ChangeLog stuff though. >> > >> > rob >> >> I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not >> about >> ipa-client/Makefile.am - we still need this one as Rob correctly said. >> >> The failure that Gabe hit in build probably comes from the the SUBDIR >> reference >> in ipa-client/Makefile.am file. I assume that if the reference is removed, >> the >> removal should work. >> >> And yes, you can remove the Changelog too if you are OK with it :) >> >> Martin >> >From d2e3176b6f6f2abb2ffbdfc198814bd1a845b876 Mon Sep 17 00:00:00 2001 >From: Gabe >Date: Tue, 2 Dec 2014 14:43:57 -0700 >Subject: [PATCH] Remove usage of app_PYTHON in ipaserver Makefiles > >https://fedorahosted.org/freeipa/ticket/4700 >--- > ipa-client/Makefile.am | 21 --------------------- > ipa-client/ipaclient/Makefile.am | 17 ----------------- > ipaserver/install/Makefile.am | 27 --------------------------- > ipaserver/install/plugins/Makefile.am | 24 ------------------------ > 4 files changed, 89 deletions(-) > delete mode 100644 ipa-client/ipaclient/Makefile.am > delete mode 100644 ipaserver/install/Makefile.am > delete mode 100644 ipaserver/install/plugins/Makefile.am > >diff --git a/ipa-client/Makefile.am b/ipa-client/Makefile.am >index b9c7020f3b687b3c0030ed5166625e6ef07e2fa4..f6f3168774c3024e10f626b88a8952c51c0eab90 100644 >--- a/ipa-client/Makefile.am >+++ b/ipa-client/Makefile.am >@@ -84,7 +84,6 @@ ipa_join_LDADD = \ > > SUBDIRS = \ > ../asn1 \ >- ipaclient \ > ipa-install \ > man \ > $(NULL) >@@ -97,7 +96,6 @@ EXTRA_DIST = \ > README \ > HACKING \ > NEWS \ >- ChangeLog \ > $(NULL) > > DISTCLEANFILES = \ >@@ -125,22 +123,3 @@ MAINTAINERCLEANFILES = \ > py-compile \ > $(NULL) > >-# Creating ChangeLog from hg log (taken from cairo/Makefile.am): >- >-ChangeLog: $(srcdir)/ChangeLog >- >-$(srcdir)/ChangeLog: >- @if test -d "$(srcdir)/../.hg"; then \ >- (cd "$(srcdir)" && \ >- ./missing --run hg log --verbose) | fmt --split-only > $@.tmp \ >- && mv -f $@.tmp $@ \ >- || ($(RM) $@.tmp; \ >- echo Failed to generate ChangeLog, your ChangeLog may be outdated >&2; \ >- (test -f $@ || echo hg log is required to generate this file >> $@)); \ >- else \ >- test -f $@ || \ >- (echo A hg checkout and hg -log is required to generate ChangeLog >&2 && \ >- echo A hg checkout and hg log is required to generate this file >> $@); \ >- fi >- >-.PHONY: ChangeLog $(srcdir)/ChangeLog >diff --git a/ipa-client/ipaclient/Makefile.am b/ipa-client/ipaclient/Makefile.am >deleted file mode 100644 >index 01824b86584992fd84d4542da88395aa0e89de12..0000000000000000000000000000000000000000 >--- a/ipa-client/ipaclient/Makefile.am >+++ /dev/null >@@ -1,17 +0,0 @@ >-NULL = >- >-appdir = $(pythondir)/ipaclient >-app_PYTHON = \ >- __init__.py \ >- ipachangeconf.py \ >- ipadiscovery.py \ >- ntpconf.py \ >- ipa_certupdate.py \ >- $(NULL) >- >-EXTRA_DIST = \ >- $(NULL) >- >-MAINTAINERCLEANFILES = \ >- *~ \ >- Makefile.in You need to remove ipa-client/ipaclient/Makefile.am also from AC_CONFIG_FILES in file ipa-client/configure.ac It should fix problem with autoreconf. LS From pspacek at redhat.com Wed Dec 3 17:35:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 03 Dec 2014 18:35:09 +0100 Subject: [Freeipa-devel] Gaps in upstream tests In-Reply-To: <54744F2F.9070904@redhat.com> References: <545CCC22.9040501@redhat.com> <54744F2F.9070904@redhat.com> Message-ID: <547F49CD.6040904@redhat.com> On 25.11.2014 10:43, Petr Spacek wrote: > On 7.11.2014 14:41, Martin Kosek wrote: >> FreeIPA team will soon grow with a new member focusing on upstream QE tests. I >> would like to collect ideas what are the biggest gaps in the current upstream >> test suite from your POV. >> >> Existing requests are tracked here: >> https://fedorahosted.org/freeipa/query?status=assigned&status=new&status=reopened&component=Tests&col=id&col=summary&col=component&col=status&col=owner&col=type&col=priority&col=milestone&group=milestone&order=priority >> >> >> First idea that I head proposed are Upgrade tests. These are often done >> manually. I think that upgrade test from currently supported FreeIPA/Fedora >> version would go a long way (like 3.3.5 on F20 upgraded built RPMs and running >> unit tests). >> >> Second, it would be nice to try testing FreeIPA server in a container. Not >> only it would verify our container efforts, but it may also allow easy >> multi-master tests on one Jenkins VM or local host instead of expensive VM >> orchestration. >> >> Any other areas worth focusing on (besides of course testing newly developed >> features)? > > At least simple automated MitM attack against TLS. > > First thing which comes to mind is CLI<->server interaction and also > certmonger<->server interaction. > > TLS is hard to get right and if I recall it correctly we already had a problem > with certificate validation... Related link: http://thehackernews.com/2014/11/nogotofail-Network-Security-Testing-Tool.html "The Nogotofail tool requires Python 2.7 and pyOpenSSL>=0.13. It features an on-path network Man-in-the-Middle (MiTM), designed to work on Linux machines, as well and optional clients for the devices being tested." -- Petr^2 Spacek From jcholast at redhat.com Thu Dec 4 07:24:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Dec 2014 08:24:32 +0100 Subject: [Freeipa-devel] [PATCH] 382 Fix automatic CA cert renewal endless loop in dogtag-ipa-ca-renew-agent Message-ID: <54800C30.7010306@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-382-Fix-automatic-CA-cert-renewal-endless-loop-in-dogtag.patch Type: text/x-patch Size: 1319 bytes Desc: not available URL: From jcholast at redhat.com Thu Dec 4 08:36:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 04 Dec 2014 09:36:06 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew Message-ID: <54801CF6.7080809@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-383-Check-subject-name-encoding-in-ipa-cacert-manage-ren.patch Type: text/x-patch Size: 2179 bytes Desc: not available URL: From jpazdziora at redhat.com Thu Dec 4 09:03:38 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 4 Dec 2014 10:03:38 +0100 Subject: [Freeipa-devel] [PATCH 3] ipa-client-install shouldn't be eager in specifying zone when doing nsupdate In-Reply-To: <547F3757.8090806@redhat.com> References: <20141202120013.GA24924@redhat.com> <547F3757.8090806@redhat.com> Message-ID: <20141204090338.GD11035@redhat.com> On Wed, Dec 03, 2014 at 05:16:23PM +0100, Martin Basti wrote: > On 02/12/14 13:00, Jan Pazdziora wrote: > >Hello, > > > >presumably explicitly specifying zone is not needed and can be > >harmful. > > > This should be fixed in template for uploading SSHFP keys as well. > > I have zone bububu.test. > > 2014-12-03T04:00:36Z DEBUG debug > zone client.bububu.test. > update delete test.client.bububu.test. IN SSHFP > show > send > update add test.client.bububu.test. 1200 IN SSHFP 1 1 > 8FD003E98D818E4E2813672234410835AB5844AC > update add test.client.bububu.test. 1200 IN SSHFP 1 2 > 37BF6366A44B67F6CA8FF8A8313B7C964CEA971CCB3E092D775FDF082170AAA4 > update add test.client.bububu.test. 1200 IN SSHFP 3 1 > 3651173F6737DF24EB6494434AC5968B3C90B749 > update add test.client.bububu.test. 1200 IN SSHFP 3 2 > 97EF4030A9DD471A3D4730A819B3A662E11994BB20AFC56FC3875AB1662260BF > show > send Updated patch attached. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat -------------- next part -------------- >From 0de294e74fc8de9dddd71eb8ca7d56080bce3374 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora Date: Tue, 2 Dec 2014 11:48:04 +0100 Subject: [PATCH] No explicit zone specification. https://fedorahosted.org/freeipa/ticket/4780 --- ipa-client/ipa-install/ipa-client-install | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 612ff62a12a24672e6bc390bcd5165cd20bf834a..1f45a544ca3ab5ef7b81c20cab552e8cbfc4a6c3 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -1553,7 +1553,6 @@ def do_nsupdate(update_txt): UPDATE_TEMPLATE_A = """ debug -zone $ZONE. update delete $HOSTNAME. IN A show send @@ -1564,7 +1563,6 @@ send UPDATE_TEMPLATE_AAAA = """ debug -zone $ZONE. update delete $HOSTNAME. IN AAAA show send @@ -1664,10 +1662,9 @@ def update_ssh_keys(server, hostname, ssh_dir, create_sshfp): return if create_sshfp: - zone = '.'.join(hostname.split('.')[1:]) ttl = 1200 - update_txt = 'debug\nzone %s.\n' % zone + update_txt = 'debug\n' update_txt += 'update delete %s. IN SSHFP\nshow\nsend\n' % hostname for pubkey in pubkeys: sshfp = pubkey.fingerprint_dns_sha1() -- 1.9.3 From mbasti at redhat.com Thu Dec 4 11:47:58 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Dec 2014 12:47:58 +0100 Subject: [Freeipa-devel] [PATCH 3] ipa-client-install shouldn't be eager in specifying zone when doing nsupdate In-Reply-To: <20141204090338.GD11035@redhat.com> References: <20141202120013.GA24924@redhat.com> <547F3757.8090806@redhat.com> <20141204090338.GD11035@redhat.com> Message-ID: <548049EE.8030500@redhat.com> On 04/12/14 10:03, Jan Pazdziora wrote: > On Wed, Dec 03, 2014 at 05:16:23PM +0100, Martin Basti wrote: >> On 02/12/14 13:00, Jan Pazdziora wrote: >>> Hello, >>> >>> presumably explicitly specifying zone is not needed and can be >>> harmful. >>> >> This should be fixed in template for uploading SSHFP keys as well. >> >> I have zone bububu.test. >> >> 2014-12-03T04:00:36Z DEBUG debug >> zone client.bububu.test. >> update delete test.client.bububu.test. IN SSHFP >> show >> send >> update add test.client.bububu.test. 1200 IN SSHFP 1 1 >> 8FD003E98D818E4E2813672234410835AB5844AC >> update add test.client.bububu.test. 1200 IN SSHFP 1 2 >> 37BF6366A44B67F6CA8FF8A8313B7C964CEA971CCB3E092D775FDF082170AAA4 >> update add test.client.bububu.test. 1200 IN SSHFP 3 1 >> 3651173F6737DF24EB6494434AC5968B3C90B749 >> update add test.client.bububu.test. 1200 IN SSHFP 3 2 >> 97EF4030A9DD471A3D4730A819B3A662E11994BB20AFC56FC3875AB1662260BF >> show >> send > Updated patch attached. > ACK I just removed unused dict value. @@ -1590,8 +1590,7 @@ def update_dns(server, hostname): sub_dict = dict(HOSTNAME=hostname, IPADDRESS=ip, - TTL=1200, - ZONE='.'.join(hostname.split('.')[1:]) + TTL=1200 ) if af == socket.AF_INET: Patch with this update attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-adelton+mbasti-0003.2-No-explicit-zone-specification.patch Type: text/x-patch Size: 1668 bytes Desc: not available URL: From mkosek at redhat.com Thu Dec 4 11:59:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Dec 2014 12:59:58 +0100 Subject: [Freeipa-devel] ds-migrate feature enhancements In-Reply-To: <5475B0D5.10308@redhat.com> References: <5475B0D5.10308@redhat.com> Message-ID: <54804CBE.4000501@redhat.com> On 11/26/2014 11:52 AM, Martin Kosek wrote: > On 11/24/2014 11:24 PM, Alan Evans wrote: >> I am in the midst of preparing for a migration from OpenLDAP to FreeIPA. >> ds-migrate wasn't going to fill all of my needs so I thought I would use it >> for most and then make up some LDIF's and massage them to do the last bit >> of migration. >> >> I have instead decided to extend ds-migrate and I think that my features >> might be of use to others so I would like to contribute them. > > Great idea! :-) IMO, enhancing FreeIPA migration capability and making it more > even more pleasant experience for user users is a good goal. > >> Before I get >> too for I wanted to get some input from the community. >> >> Here are MY original goals: >> * Migrate ssh public keys >> The openssh-lpk schema is used in my tree so objectClass: ldapPublicKey >> attribute: sshPublicKey >> * Migrate disabled accounts as disabled >> We 'disable' usere by setting their shadowExpire to a date in the past >> and setting their shell to /bin/false >> >> I realized that the ssh-public key problem is more generally an attribute >> mapping problem and dealing with disabled users could be more generalized >> too. >> >> Here are instead the new features I would provide. >> >> * Attribute mapping >> Feature should check the new syntax exists and is the same as the old >> syntax (perhaps further check for compatible syntax) >> --user-attribute-map=oldAttribute=newAttribute >> --group-attribute-map=foo=bar >> Should I drop user/group and just make it --attribute-map and apply it to >> both? >> Should certain attributes be mapped by default, i.e. >> sshPublicKey=ipaSSHPubKey (this means we also need to ignore the >> objectClass ldapPublicKey by default) Maybe make a separate switch >> --with-ssh-keys that automatically adds a map and an ignore? > > If the mapping sshPublicKey -> ipaSSHPubKey is clear, I would do it by default > and maybe add a switch to skip these advanced migrations. Just make sure the > expected format matches (ipa requires all 3 pieces of the public key, not just > the blob) > > I think it would be very useful to combine user attribute mapping with the > ideas from > > https://fedorahosted.org/freeipa/ticket/3709 > > i.e. filling attribute with values from original entry or a default. This may > lead to following syntax: > > --user-attribute-default "sn=notdefined" --user-attribute-default > "description=User with cn $cn" > > which would only use the pattern if attribute is not defined in original entry > > and > > --user-attribute-map "sn=$cn" > > which would fill overwrite the attribute even if it was defined in the original > entry. > >> >> * Handling disabled users >> 1. How to identify disabled users? >> a. shadowExpire < now() >> --use-disable-shadow-expire > > How would you like to disable users then? With nsAccountLock attribute? > Wouldn't it be better to instead map shadowExpire to krbPrincipalExpiration > attribute which should have sematically the same meaning? > >> b. loginShell is one of configurable shells >> --use-disable-login-shell >> --disabled-shell=/bin/false --disabled-shell=/sbin/nologin (these > > Is this really a general mechanism? I think Kerberos principal expiration is > the way to go: > > # ipa user-mod fbar --principal-expiration 20140101000000Z > > # ssh fbar@`hostname` > fbar at vm-067.idm.lab.bos.redhat.com's password: > Permission denied, please try again. > > # tail /var/log/krb5kdc.log > ... > Nov 26 04:56:51 vm-067.idm.lab.bos.redhat.com krb5kdc[19615](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 10.16.78.67: CLIENT EXPIRED: > fbar at IDM.LAB.BOS.REDHAT.COM for > krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM, Client's entry in > database has expired > > It is respected by Kerberos authentication and SSSD logins, at minimum. > > >> two would be the defaults) >> c. nsAccountLocked (though that would be straight copied by the >> migrator anyway > > +1 for copying. > >> d. From Open DJ the attribute ds-pwp-account-disabled can be used to >> identify disabled users >> (are there others?) >> 2. What do do with disabled users (in my case migrate and disable) >> a. Migrate them and don't touch nsAccountLocked >> b. Migrate them and set nsAccountLocked = true >> --disable-users >> c. Do not migrate them >> --skip-disabled-users >> d. Which is the default? Migrate and disable? If so which are the >> default methods for identifying them? All methods? > > I may be missing something, but to me following would make sense: > > - properly migrate and fill krbPrincipalExpiration and nsACcountLock attributes > - optionally implement --skip-disabled-users. Though it may be challenging to > implement the "is_user_disabled" function right so that it works on all sort of > DS schemes. > >> So is there anything I'm missing? Any suggestions on the switches? I'm not >> entirely sure I like them the way they are. >> >> I have code to cover about 60% of the above already. The user-attr-map >> feature is working and the --disabled-users and disabled-shells options are >> working. >> >> Regards, >> -Alan Hello Alan, Are there any updates in this noble effort? Are you stuck? Can I or the team help you in any way? Thanks, Martin From redhatrises at gmail.com Thu Dec 4 13:18:26 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 4 Dec 2014 06:18:26 -0700 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: <20141203163023.GB24459@mail.corp.redhat.com> References: <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> <20141203163023.GB24459@mail.corp.redhat.com> Message-ID: Thanks for the assistance Lukas! I have an updated patch attached. Thanks, Gabe On Wed, Dec 3, 2014 at 9:30 AM, Lukas Slebodnik wrote: > On (02/12/14 21:13), Gabe Alford wrote: > >This patch removes the changelog and Makefile.am for ipaclient as well. > > > >Thanks, > > > >Gabe > > > >On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek wrote: > > > >> On 12/01/2014 04:25 PM, Rob Crittenden wrote: > >> > Gabe Alford wrote: > >> >> > >> >> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek >> >> > wrote: > >> >> > >> >> On 11/30/2014 03:28 AM, Gabe Alford wrote: > >> >> > Ignore the last patch. Updated patch attached. > >> >> > > >> >> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford > >> >> > wrote: > >> >> > > >> >> >> This patch removes the app_PYTHON usage. > >> >> >> > >> >> >> Thanks, > >> >> >> > >> >> >> Gabe > >> >> >> > >> >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek < > mkosek at redhat.com > >> >> > wrote: > >> >> >> > >> >> >>> Exactly, this was the message from Martin :-) I did not test > it > >> >> myself, > >> >> >>> but > >> >> >>> removing all app_PYTHON should be benign given we use Python > >> >> setup.py > >> >> >>> packaging. > >> >> >>> > >> >> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: > >> >> >>>> Thanks guys. Sounds like it would be better to submit a > patch > >> that > >> >> >>> removes > >> >> >>>> app_PYTHON if it is considered dead code. > >> >> >>>> > >> >> >>>> Gabe > >> >> >>>> > >> >> >>>> On Thursday, November 27, 2014, Petr Spacek < > >> pspacek at redhat.com > >> >> > wrote: > >> >> >>>> > >> >> >>>>> On 27.11.2014 11:00, Martin Basti wrote: > >> >> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: > >> >> >>>>>>> Hello, > >> >> >>>>>>> > >> >> >>>>>>> Wondering if I could get a review. Updated patch > >> >> attached. > >> >> >>>>>>> > >> >> >>>>>>> Thanks, > >> >> >>>>>>> Gabe > >> >> >>>>>>> > >> >> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > >> >> > >> >> >>>>> > >> >> >>>>>>> redhatrises at gmail.com > >> > > >> >> >> wrote: > >> >> >>>>>>> > >> >> >>>>>>> Hello, > >> >> >>>>>>> > >> >> >>>>>>> Fix for https://fedorahosted.org/freeipa/ticket/4700 > >> >> >>>>>>> > >> >> >>>>>>> Thanks, > >> >> >>>>>>> > >> >> >>>>>>> Gabe > >> >> >>>>>>> > >> >> >>>>>>> > >> >> >>>>>>> > >> >> >>>>>> Hello, > >> >> >>>>>> > >> >> >>>>>> sorry for late response. > >> >> >>>>>> > >> >> >>>>>> We push this ticket to backlog, as it would be part of > build > >> >> system > >> >> >>>>> refactoring. > >> >> >>>>>> The "app_PYTHON" statement is not used anymore in IPA, the > >> better > >> >> >>>>> solution is > >> >> >>>>>> remove it, instead of keeping dead code up-to-date. > >> >> >>>>> > >> >> >>>>> Just to clarify: > >> >> >>>>> It can be pushed if it works, there is no need to postpone > >> >> accepting > >> >> >>> patch > >> >> >>>>> if > >> >> >>>>> the patch seems okay and doesn't break anything. > >> >> >>>>> > >> >> >>>>> Martin, please keep in mind that contributions are welcome > at > >> >> any time. > >> >> >>>>> > >> >> >>>>> Milestones in Trac reflect our view of priorities but it > >> doesn't > >> >> >>> prevent us > >> >> >>>>> from accepting correct patches from contributions at any > >> time, no > >> >> >>> matter > >> >> >>>>> which > >> >> >>>>> priority is stated in Trac (or even if there is no ticket > for > >> >> it ...). > >> >> >>>>> > >> >> >>>>> -- > >> >> >>>>> Petr^2 Spacek > >> >> > >> >> Worked in my tests, I did not see any breakage. I guess we can > also > >> >> remove the > >> >> ipa-client/ipaclient/Makefile.am while we are at it. > >> >> > >> >> Martin > >> >> > >> >> > >> >> It looks like the ipaclient/Makefile.am is still being used. I tried > >> >> removing it and there were errors in the build, but maybe I am wrong? > >> > > >> > It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. > >> > > >> > Feel free to rip out the outdated hg ChangeLog stuff though. > >> > > >> > rob > >> > >> I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not > >> about > >> ipa-client/Makefile.am - we still need this one as Rob correctly said. > >> > >> The failure that Gabe hit in build probably comes from the the SUBDIR > >> reference > >> in ipa-client/Makefile.am file. I assume that if the reference is > removed, > >> the > >> removal should work. > >> > >> And yes, you can remove the Changelog too if you are OK with it :) > >> > >> Martin > >> > > >From d2e3176b6f6f2abb2ffbdfc198814bd1a845b876 Mon Sep 17 00:00:00 2001 > >From: Gabe > >Date: Tue, 2 Dec 2014 14:43:57 -0700 > >Subject: [PATCH] Remove usage of app_PYTHON in ipaserver Makefiles > > > >https://fedorahosted.org/freeipa/ticket/4700 > >--- > > ipa-client/Makefile.am | 21 --------------------- > > ipa-client/ipaclient/Makefile.am | 17 ----------------- > > ipaserver/install/Makefile.am | 27 --------------------------- > > ipaserver/install/plugins/Makefile.am | 24 ------------------------ > > 4 files changed, 89 deletions(-) > > delete mode 100644 ipa-client/ipaclient/Makefile.am > > delete mode 100644 ipaserver/install/Makefile.am > > delete mode 100644 ipaserver/install/plugins/Makefile.am > > > >diff --git a/ipa-client/Makefile.am b/ipa-client/Makefile.am > >index > b9c7020f3b687b3c0030ed5166625e6ef07e2fa4..f6f3168774c3024e10f626b88a8952c51c0eab90 > 100644 > >--- a/ipa-client/Makefile.am > >+++ b/ipa-client/Makefile.am > >@@ -84,7 +84,6 @@ ipa_join_LDADD = \ > > > > SUBDIRS = \ > > ../asn1 \ > >- ipaclient \ > > ipa-install \ > > man \ > > $(NULL) > >@@ -97,7 +96,6 @@ EXTRA_DIST = \ > > README \ > > HACKING \ > > NEWS \ > >- ChangeLog \ > > $(NULL) > > > > DISTCLEANFILES = \ > >@@ -125,22 +123,3 @@ MAINTAINERCLEANFILES = \ > > py-compile \ > > $(NULL) > > > >-# Creating ChangeLog from hg log (taken from cairo/Makefile.am): > >- > >-ChangeLog: $(srcdir)/ChangeLog > >- > >-$(srcdir)/ChangeLog: > >- @if test -d "$(srcdir)/../.hg"; then \ > >- (cd "$(srcdir)" && \ > >- ./missing --run hg log --verbose) | fmt --split-only > $@.tmp \ > >- && mv -f $@.tmp $@ \ > >- || ($(RM) $@.tmp; \ > >- echo Failed to generate ChangeLog, your ChangeLog may be > outdated >&2; \ > >- (test -f $@ || echo hg log is required to generate this file > >> $@)); \ > >- else \ > >- test -f $@ || \ > >- (echo A hg checkout and hg -log is required to generate > ChangeLog >&2 && \ > >- echo A hg checkout and hg log is required to generate this file > >> $@); \ > >- fi > >- > >-.PHONY: ChangeLog $(srcdir)/ChangeLog > >diff --git a/ipa-client/ipaclient/Makefile.am > b/ipa-client/ipaclient/Makefile.am > >deleted file mode 100644 > >index > 01824b86584992fd84d4542da88395aa0e89de12..0000000000000000000000000000000000000000 > >--- a/ipa-client/ipaclient/Makefile.am > >+++ /dev/null > >@@ -1,17 +0,0 @@ > >-NULL = > >- > >-appdir = $(pythondir)/ipaclient > >-app_PYTHON = \ > >- __init__.py \ > >- ipachangeconf.py \ > >- ipadiscovery.py \ > >- ntpconf.py \ > >- ipa_certupdate.py \ > >- $(NULL) > >- > >-EXTRA_DIST = \ > >- $(NULL) > >- > >-MAINTAINERCLEANFILES = \ > >- *~ \ > >- Makefile.in > > You need to remove ipa-client/ipaclient/Makefile.am also from > AC_CONFIG_FILES > in file ipa-client/configure.ac > > > It should fix problem with autoreconf. > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0036-5-Remove-missing-python-files-to-Makefiles.patch Type: text/x-patch Size: 4394 bytes Desc: not available URL: From lkrispen at redhat.com Thu Dec 4 13:33:09 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 04 Dec 2014 14:33:09 +0100 Subject: [Freeipa-devel] topology management question Message-ID: <54806295.4040404@redhat.com> hi, I just have another (hopefully this will end soon) issue I want to get your input. (please read to teh end first) To recapture the conditions: - the topology plugin manages the connections between servers as segments in the shared tree - it is authoritative for managed servers, eg it controls all connections between servers listed under cn=masters, it is permissive for connection to other servers - it rejects any removal of a segment, which would disconnect the topology. - a change in topology can be applied to any server in the topology, it will reach the respective servers and the plugin will act upon it Now there is a special case, causing a bit of trouble. If a replica is to be removed from the topology, this means that the replication agreements from and to this replica should be removed, the server should be removed from the manages servers. The problem is that: - if you remove the server first, the server becomes unmanaged and removal of the segment will not trigger a removal of the replication agreement - if you remove the segments first, one segment will be the last one connecting this replica to the topology and removal will be rejected Now, with some effort this can be resolved, eg if the server is removed, keep it internally as removed server and for segments connecting this server trigger removal of replication agreements or mark a the last segment, when tried to remove, as pending and once the server is removed also remove the corresponding repl agreements But there is a problem, which I think is much harder and I am not sure how much effort I should put in resolving it. If we want to have the replication agreements cleaned up after removal of a replica without direct modification of cn=config, we need to follow the path above, but this also means that the last change needs to reach both the removed replica (R) and the last server(S) it is connected to. The bad thing is that if this change triggers a removal of the replication agreement on S it could be that the change is not replicated to R before the agreement is removed and is lost. There is no way (or no easy) way to know for teh plugin if a change was received by an other server, I was also thinking about some kind of acknowledge mechanism by doing a ping pong of changes, but the problem always is the same that one server does not know if the other has received it. And even if this would theoretically work, we cannot be sure that R is not shutdown and only the remaining topology is tried to be cleaned up, so S would wait forever. My suggestion to resolve this (in most cases) is to define a wait interval, after the final combination of removal of a server and its connecting segment is received, wait for some time and then remove the corresponding replication agreements. So I'm asking you if this would be acceptable or if you have a better solution. Thanks, Ludwig From pvoborni at redhat.com Thu Dec 4 13:56:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 04 Dec 2014 14:56:41 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1417550277.5864.82.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> <1417550277.5864.82.camel@redhat.com> Message-ID: <54806819.7010101@redhat.com> On 2.12.2014 20:57, Nathaniel McCallum wrote: >> >> I'm little confused with a state of reviews. Thierry were some of the >> patches ACKed in different threads or are they under review (I'm not >> reviewing DS plugin parts)? > > Patches 0001, 0002, 0003 are ACKed by Thierry, but not merged. They can > and should be merged as they fix an independent bug. > >>>>> Ah, I meant adding the token config to cn=otp,SUFFIX directly, but if we want >>>>> to make TOTP/HOTP token config as separate entries (to enable future per-token >>>>> overrides), your approach should make sense. Rather adding Rob to CC for sanity. >>>> >>>> That would work too. I'm open to that. >>>> >>>>> I am just not sure we should create them as separate plugins, I think the new >>>>> commands should be rather added to otp plugin directly so that they show in >>>>> "ipa help otptoken" instead of adding 2 new topics just for OTP config. >>>> >>>> I can play with that. >> >> Do you plan to change it? I like the idea of a single point of help for >> OTP but I'm also unsure about the length of the commands. Current >> solution is also more consistent with a rest of the framework. Would it >> be something like: >> >> otptoken-totpconfig-(show|mod) >> otptoken-hotpconfig-(show|mod) > > In the latest patch, I merged totpconfig-* and hotpconfig-* into a > single otpconfig-* plugin. > >> Maybe it would be better to introduce more help topics for otp. This >> concept is used for HBAC already: >> >> $ ipa help hbac >> hbacsvcgroup HBAC Service Groups >> hbacsvc HBAC Services >> hbacrule Host-based access control >> >> $ ipa help hbacrule >> Host-based access control >> ... a lot of text >> >> So we could introduce otp umbrella topic: >> >> $ ipa help otp >> opttoken OTP tokens' >> totpconfig TOTP configuration options >> hotpconfig HOTP configuration options > > I added a fifth patch (0005) which creates an otp umbrella topic. We can > merge it or not. > >>>> Nathaniel >>> >>> No worries ATM, you can wait for proper review. I was just looking at the new >>> API to make sure we are on the same page - we seem to mostly are. >>> >>> Martin >>> >> >> Commenting just patch 0004: >> >> 1. Requires rebase because of API change. > > Fixed. > >> 2. git diff HEAD~4 -U0 | pep8 --diff >> I would ignore E124 and fix E302 (5x) > > Fixed. > >> I did not test actual functionality yet. > > The attached patches I think have a much better overall aesthetic. Now > patch 0004 introduces only two new commands: > * otpconfig-mod > * otpconfig-show > > Under the covers, a single configuration entity is used: > * cn=otp,cn=etc,$SUFFIX > > Other than these small changes, there are no changes to patch 0004. I > have not tested the latest changes, however, due to an unrelated build > issue I'm working on. > > Patch 0005 introduces an umbrella help topic for all OTP related > commands (currently: otpconfig, otptoken, otptoken-yubikey). > > Nathaniel > Works fine. python part of 0004: ACK, but VERSION needs to be updated before push 0005: ACK One question before push: For per-token configuration, do you intent to extend each token, regardless of type, by 'ipatokenOTPConfig' object class? I.e. to have config attributes for both types? Or do you plan to have special object classes for each token type as we now have for tokens? -- Petr Vobornik From mbasti at redhat.com Thu Dec 4 14:22:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 04 Dec 2014 15:22:10 +0100 Subject: [Freeipa-devel] [PATCH 0174] Show SSHFP record in CLI if contains space in fingerprint part Message-ID: <54806E12.4080300@redhat.com> SSHFP records added by nsupdate contains space in fingerprint part, this space prevent framework to show record. Fixes https://fedorahosted.org/freeipa/ticket/4789 https://fedorahosted.org/freeipa/ticket/4790 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0174-Show-SSHFP-record-containing-space-in-fingerprint.patch Type: text/x-patch Size: 1115 bytes Desc: not available URL: From tbabej at redhat.com Thu Dec 4 15:22:34 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 04 Dec 2014 16:22:34 +0100 Subject: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show In-Reply-To: <547DE78F.8090104@redhat.com> References: <547DD00A.7030705@redhat.com> <547DD753.1040405@redhat.com> <547DE277.4080406@redhat.com> <547DE78F.8090104@redhat.com> Message-ID: <54807C3A.9090400@redhat.com> On 12/02/2014 05:23 PM, Jan Cholasta wrote: > Dne 2.12.2014 v 17:01 Tomas Babej napsal(a): >> >> On 12/02/2014 04:14 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 2.12.2014 v 15:43 Tomas Babej napsal(a): >>>> Hi, >>>> >>>> Makes ipaassignedidview a default attribute and takes care about the >>>> conversion from the DN to the proper ID view name. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4774 >>> >>> Since you are converting the value from DN to primary key string, the >>> type of the ipassignedview param should be changed to Str, for >>> consistency with existing code. >>> >>> Honza >>> >> >> I see. Actually during the development, I craved for simple >> output_normalizer option in the Param itself, which would apply the >> output normalization funtion after the post_callback, >> instead of having to mangle the entry_attrs in the post callback of each >> command (and could potentionally apply on the client). Would there a be >> not-so-hard way to do this in the framework? My understanding is that >> Output classes are quite decoupled from the Params they resulted from, >> and at the point we're printing the information via the textui, we're no >> longer aware what Param instance it originated from. > > This wouldn't solve the real problem in this case, which is that we do > not support one-to-many relationships between objects in the framework > (and our support for many-to-many relationships is clunky). I plan to > fix this with . > >> >> Updated patch attached. >> > > Updated patch with fixed WebUI bits. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0289-3-hosts-Display-assigned-ID-view-by-default-in-host-fi.patch Type: text/x-patch Size: 7514 bytes Desc: not available URL: From pspacek at redhat.com Thu Dec 4 16:04:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 04 Dec 2014 17:04:34 +0100 Subject: [Freeipa-devel] [PATCH 0315] Support BIND 9.10 Message-ID: <54808612.6040309@redhat.com> Hello, Support BIND 9.10. https://fedorahosted.org/bind-dyndb-ldap/ticket/139 This patch definitely needs more testing but ...: - It compiles with BIND 9.9 and BIND 9.10. - It seems that it is able to load master and forward zones. - Basic dynamic updates work. I did not test other features yet. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0315-Support-BIND-9.10.patch Type: text/x-patch Size: 16585 bytes Desc: not available URL: From npmccallum at redhat.com Thu Dec 4 18:15:42 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 04 Dec 2014 13:15:42 -0500 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <54806819.7010101@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> <1417550277.5864.82.camel@redhat.com> <54806819.7010101@redhat.com> Message-ID: <1417716942.3111.4.camel@redhat.com> On Thu, 2014-12-04 at 14:56 +0100, Petr Vobornik wrote: > On 2.12.2014 20:57, Nathaniel McCallum wrote: > > The attached patches I think have a much better overall aesthetic. Now > > patch 0004 introduces only two new commands: > > * otpconfig-mod > > * otpconfig-show > > > > Under the covers, a single configuration entity is used: > > * cn=otp,cn=etc,$SUFFIX > > > > Other than these small changes, there are no changes to patch 0004. I > > have not tested the latest changes, however, due to an unrelated build > > issue I'm working on. > > > > Patch 0005 introduces an umbrella help topic for all OTP related > > commands (currently: otpconfig, otptoken, otptoken-yubikey). > > > > Nathaniel > > > > Works fine. > > python part of 0004: ACK, but VERSION needs to be updated before push > 0005: ACK Fixed and rebased. Patch numbers have changed: 0004 => 0001 0005 => 0002 > One question before push: For per-token configuration, do you intent to > extend each token, regardless of type, by 'ipatokenOTPConfig' object > class? I.e. to have config attributes for both types? Or do you plan to > have special object classes for each token type as we now have for tokens? I would probably just add the TOTP options to the ipatokenTOTP object class as MAY. Same for HOTP. The attributes were designed to look like the other token-type-specific attributes. I think we are just waiting on Thierry's review of the C code. :) Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-token-auth-and-sync-windows-configurable.patch Type: text/x-patch Size: 33054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Create-an-OTP-help-topic.patch Type: text/x-patch Size: 1801 bytes Desc: not available URL: From npmccallum at redhat.com Thu Dec 4 18:17:06 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 04 Dec 2014 13:17:06 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1417539312.5864.64.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> <547DED6B.4010206@redhat.com> <1417538994.5864.62.camel@redhat.com> <547DEE29.1010407@redhat.com> <1417539312.5864.64.camel@redhat.com> Message-ID: <1417717026.3111.5.camel@redhat.com> On Tue, 2014-12-02 at 11:55 -0500, Nathaniel McCallum wrote: > On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote: > > On 12/02/2014 05:49 PM, Nathaniel McCallum wrote: > > > On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: > > >> On 12/02/2014 05:36 PM, Simo Sorce wrote: > > >>> On Tue, 02 Dec 2014 11:12:11 -0500 > > >>> Nathaniel McCallum wrote: > > >>> > > >>>> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: > > >>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > > >>>>>>>> Patch attached. > > >>>>>>> > > >>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 > > >>>>>>> second timeouts and re-transmits when OTP is in place? > > >>>>>>> > > >>>>>>> What is the expected performance impact? Could it be configured > > >>>>>>> for OTP separately - somehow? (I guess that it is not possible > > >>>>>>> now ...) > > >>>>>> > > >>>>>> It benefits also communication of large packets (when large > > >>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice > > >>>>>> for IPA in general. Especially given we have multiple KDC > > >>>>>> processes configured we do not want clients wasting KDC resources > > >>>>>> by making multiple processes do the same operation. > > >>>>> > > >>>>> So apparently this patch never got reviewed over a year ago. > > >>>>> > > >>>>> It was related to a bug which was opened in SSSD. However, when it > > >>>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was > > >>>>> closed but no corresponding FreeIPA bug was opened. The patch then > > >>>>> fell through the cracks. > > >>>>> > > >>>>> Without this patch, if OTP validation runs long we get retransmits > > >>>>> and failures. > > >>>>> > > >>>>> One question I have is how to handle this for upgrades since (I > > >>>>> think) this patch only handles new installs. > > >>>>> > > >>>>> Anyway, this patch is somewhat urgent now. So help is appreciated. > > >>>>> > > >>>>> I have attached a rebased version which has no other changes. > > >>>> > > >>>> I still need a review on this. Any takers? > > >>> > > >>> The patch looks good to me > > >>> > > >>> Simo. > > >> > > >> This fixes the new installations. Can you please refresh the memory what is the > > >> decision regarding the upgrades? > > > > > > The need to fix upgrades will be documented. In the future, we will > > > get /etc/krb.conf.d and we will ship a file there. > > > > > > Nathaniel > > > > > > > Nobody reads the documentation :-) What is the implication for users doing > > client update (majority of them) and using OTP feature? > > They will get spurious failures. Most will think it is a bug or a > network issue. If the failures happen consistently enough, users might > get locked out. So what is the plan with this patch? We need to get it sorted. :) From npmccallum at redhat.com Thu Dec 4 18:25:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 04 Dec 2014 13:25:39 -0500 Subject: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type In-Reply-To: <547F37D3.6040701@redhat.com> References: <1415898295.9116.12.camel@redhat.com> <547F37D3.6040701@redhat.com> Message-ID: <1417717539.3111.6.camel@redhat.com> On Wed, 2014-12-03 at 17:18 +0100, Petr Vobornik wrote: > On 13.11.2014 18:04, Nathaniel McCallum wrote: > > Additionally, fix a small bug in ipa-kdb so that the disabled User > > Auth Type is properly handled. > > > > https://fedorahosted.org/freeipa/ticket/4720 > > > > The patch itself looks good to me, VERSION needs to be updated though. > > But I don't think it works. Don't know why. In my setup, user's config > was not ignored. > > When I tested login in Web UI with: > > - global config: disabled, otp > - user fbar's config: password > - fbar had an hotp token assigned > > I could still login with password and not with otp. If I added 'otp' to > fbar's config, I could also login with otp. How are you logging in? krb5 or LDAP bind? From pvoborni at redhat.com Thu Dec 4 18:56:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 04 Dec 2014 19:56:13 +0100 Subject: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type In-Reply-To: <1417717539.3111.6.camel@redhat.com> References: <1415898295.9116.12.camel@redhat.com> <547F37D3.6040701@redhat.com> <1417717539.3111.6.camel@redhat.com> Message-ID: <5480AE4D.2000800@redhat.com> On 12/04/2014 07:25 PM, Nathaniel McCallum wrote: > On Wed, 2014-12-03 at 17:18 +0100, Petr Vobornik wrote: >> On 13.11.2014 18:04, Nathaniel McCallum wrote: >>> Additionally, fix a small bug in ipa-kdb so that the disabled User >>> Auth Type is properly handled. >>> >>> https://fedorahosted.org/freeipa/ticket/4720 >>> >> >> The patch itself looks good to me, VERSION needs to be updated though. >> >> But I don't think it works. Don't know why. In my setup, user's config >> was not ignored. >> >> When I tested login in Web UI with: >> >> - global config: disabled, otp >> - user fbar's config: password >> - fbar had an hotp token assigned >> >> I could still login with password and not with otp. If I added 'otp' to >> fbar's config, I could also login with otp. > > How are you logging in? krb5 or LDAP bind? > Forms-based in Web UI. It uses kinit internally. -- Petr Vobornik From alanwevans at gmail.com Thu Dec 4 23:32:24 2014 From: alanwevans at gmail.com (Alan Evans) Date: Thu, 4 Dec 2014 16:32:24 -0700 Subject: [Freeipa-devel] ds-migrate feature enhancements In-Reply-To: <54804CBE.4000501@redhat.com> References: <5475B0D5.10308@redhat.com> <54804CBE.4000501@redhat.com> Message-ID: Hello Martin, I have spent some time looking into how to address https://fedorahosted.org/freeipa/ticket/3709. I thought I would look at --setattr --addattr from user-add and others to see if I could reuse code for --user-attr-default. At least for parsing the commandline arguments anyway. It does not look like it would be easy to re-purpose the code in _convert_2_dict() from ipalib/plugins/baseldap.py (without blatantly copying it). What are your thoughts about creating a Dict paramater type in ipalib/parameters.py to to user for --setaddr --addattr --delattr and to use for --user-attr-default? Also I was looking at string.Template() vs string.Formatter(). I think string.Template is probably sufficient. But I don't follow PEPs so I don't know if that's Python3 future proof or not. Thoughts? # Pseudocode (attr, default) = args['userdefaultattr'][0].split('=',2) entry_attrs[attr] = default.safe_substitute(entry_attrs.toDict()) In looking at ipalib/plugins/baseldap.py, I was wondering if It might make sense to make migrate more in line with the --*attr paramaters. Consider: ipa migrate-ds --user-delattr ou Instead of: ipa-migrate-ds --user-ignore-attribute ou Then we could also add user-{setattr,addattr,delattr,attrdefault} like: ipa migrate-ds --user-attrdefault "mail=$uid at example.com" --user-setattr "cn=$givenname $sn" --user-addattr description="Migrated $(date)" --user-delattr ou Which would add a mail address if one wasn't present, replace the CN with the first and last name, add a description attribute and get rid of the ou attribute. Another thought I had was about the behaivor of the search on the source directory. Currently one provides --{user,group}-continer and --{user,group}-objectclass and the scope is statically defined in the script. --{user,group}-filter -------------------------- What about adding --{user,group}-scope ONE|SUB? My directory for example is like: dn: uid=me,ou=ops,ou=people,dc=example,dc=com dn: uid=joe,ou=eng,ou=people,dc=example,dc=com So currently I have to use the --continue switch and change my --user-container to get all of my users. If the scope weren't limited to ONELEVEL then I could get everyone in one pass. ipa migrate-ds --user-container ou=People,dc=example,dc=com --user-scope SUB Lastly I was thinking that --user-objectclass and --exclude-users could be made more powerful with --user-filter ipa migrate-ds --user-container ou=People,dc=example,dc=com --user-objectclass posixAccount --user-filter '(!(loginShell=/bin/false))' or we could fire all of sales --user-filter '(!(ou=Sales))' Which gets concatenated internally in the search to "(&(objectClass=posixAccount)(!(loginShell=/bin/false)))" On Thu, Dec 4, 2014 at 4:59 AM, Martin Kosek wrote: > On 11/26/2014 11:52 AM, Martin Kosek wrote: > > On 11/24/2014 11:24 PM, Alan Evans wrote: > >> I am in the midst of preparing for a migration from OpenLDAP to FreeIPA. > >> ds-migrate wasn't going to fill all of my needs so I thought I would > use it > >> for most and then make up some LDIF's and massage them to do the last > bit > >> of migration. > >> > >> I have instead decided to extend ds-migrate and I think that my features > >> might be of use to others so I would like to contribute them. > > > > Great idea! :-) IMO, enhancing FreeIPA migration capability and making > it more > > even more pleasant experience for user users is a good goal. > > > >> Before I get > >> too for I wanted to get some input from the community. > >> > >> Here are MY original goals: > >> * Migrate ssh public keys > >> The openssh-lpk schema is used in my tree so objectClass: > ldapPublicKey > >> attribute: sshPublicKey > >> * Migrate disabled accounts as disabled > >> We 'disable' usere by setting their shadowExpire to a date in the past > >> and setting their shell to /bin/false > >> > >> I realized that the ssh-public key problem is more generally an > attribute > >> mapping problem and dealing with disabled users could be more > generalized > >> too. > >> > >> Here are instead the new features I would provide. > >> > >> * Attribute mapping > >> Feature should check the new syntax exists and is the same as the old > >> syntax (perhaps further check for compatible syntax) > >> --user-attribute-map=oldAttribute=newAttribute > >> --group-attribute-map=foo=bar > >> Should I drop user/group and just make it --attribute-map and apply > it to > >> both? > >> Should certain attributes be mapped by default, i.e. > >> sshPublicKey=ipaSSHPubKey (this means we also need to ignore the > >> objectClass ldapPublicKey by default) Maybe make a separate switch > >> --with-ssh-keys that automatically adds a map and an ignore? > > > > If the mapping sshPublicKey -> ipaSSHPubKey is clear, I would do it by > default > > and maybe add a switch to skip these advanced migrations. Just make sure > the > > expected format matches (ipa requires all 3 pieces of the public key, > not just > > the blob) > > > > I think it would be very useful to combine user attribute mapping with > the > > ideas from > > > > https://fedorahosted.org/freeipa/ticket/3709 > > > > i.e. filling attribute with values from original entry or a default. > This may > > lead to following syntax: > > > > --user-attribute-default "sn=notdefined" --user-attribute-default > > "description=User with cn $cn" > > > > which would only use the pattern if attribute is not defined in original > entry > > > > and > > > > --user-attribute-map "sn=$cn" > > > > which would fill overwrite the attribute even if it was defined in the > original > > entry. > > > >> > >> * Handling disabled users > >> 1. How to identify disabled users? > >> a. shadowExpire < now() > >> --use-disable-shadow-expire > > > > How would you like to disable users then? With nsAccountLock attribute? > > Wouldn't it be better to instead map shadowExpire to > krbPrincipalExpiration > > attribute which should have sematically the same meaning? > > > >> b. loginShell is one of configurable shells > >> --use-disable-login-shell > >> --disabled-shell=/bin/false --disabled-shell=/sbin/nologin > (these > > > > Is this really a general mechanism? I think Kerberos principal > expiration is > > the way to go: > > > > # ipa user-mod fbar --principal-expiration 20140101000000Z > > > > # ssh fbar@`hostname` > > fbar at vm-067.idm.lab.bos.redhat.com's password: > > Permission denied, please try again. > > > > # tail /var/log/krb5kdc.log > > ... > > Nov 26 04:56:51 vm-067.idm.lab.bos.redhat.com krb5kdc[19615](info): > AS_REQ (6 > > etypes {18 17 16 23 25 26}) 10.16.78.67: CLIENT EXPIRED: > > fbar at IDM.LAB.BOS.REDHAT.COM for > > krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM, Client's entry in > > database has expired > > > > It is respected by Kerberos authentication and SSSD logins, at minimum. > > > > > >> two would be the defaults) > >> c. nsAccountLocked (though that would be straight copied by the > >> migrator anyway > > > > +1 for copying. > > > >> d. From Open DJ the attribute ds-pwp-account-disabled can be used to > >> identify disabled users > >> (are there others?) > >> 2. What do do with disabled users (in my case migrate and disable) > >> a. Migrate them and don't touch nsAccountLocked > >> b. Migrate them and set nsAccountLocked = true > >> --disable-users > >> c. Do not migrate them > >> --skip-disabled-users > >> d. Which is the default? Migrate and disable? If so which are the > >> default methods for identifying them? All methods? > > > > I may be missing something, but to me following would make sense: > > > > - properly migrate and fill krbPrincipalExpiration and nsACcountLock > attributes > > - optionally implement --skip-disabled-users. Though it may be > challenging to > > implement the "is_user_disabled" function right so that it works on all > sort of > > DS schemes. > > > >> So is there anything I'm missing? Any suggestions on the switches? I'm > not > >> entirely sure I like them the way they are. > >> > >> I have code to cover about 60% of the above already. The user-attr-map > >> feature is working and the --disabled-users and disabled-shells options > are > >> working. > >> > >> Regards, > >> -Alan > > Hello Alan, > > Are there any updates in this noble effort? Are you stuck? Can I or the > team > help you in any way? > > Thanks, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Dec 5 08:03:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Dec 2014 09:03:05 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54801CF6.7080809@redhat.com> References: <54801CF6.7080809@redhat.com> Message-ID: <548166B9.9090807@redhat.com> On 12/04/2014 09:36 AM, Jan Cholasta wrote: > + if x509.get_der_subject(cert, x509.DER) != der_subject: > + raise admintool.ScriptError("Subject name encoding mismatch") I think we can expect this to be a pretty common error, given this is the default behavior of Microsoft Certificate Services. I would thus like to make the error message more juicy. We need to make sure we offer some pointers for these users or they will just blame IPA for screwing up. So, the information I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 need to somehow get to the error message as a potential/likely root cause of the problem. Whether you write it in the error message itself or update the design page and just insert a link is up to you. Martin From mkosek at redhat.com Fri Dec 5 08:19:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Dec 2014 09:19:50 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1417717026.3111.5.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> <547DED6B.4010206@redhat.com> <1417538994.5864.62.camel@redhat.com> <547DEE29.1010407@redhat.com> <1417539312.5864.64.camel@redhat.com> <1417717026.3111.5.camel@redhat.com> Message-ID: <54816AA6.4000107@redhat.com> On 12/04/2014 07:17 PM, Nathaniel McCallum wrote: > On Tue, 2014-12-02 at 11:55 -0500, Nathaniel McCallum wrote: >> On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote: >>> On 12/02/2014 05:49 PM, Nathaniel McCallum wrote: >>>> On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: >>>>> On 12/02/2014 05:36 PM, Simo Sorce wrote: >>>>>> On Tue, 02 Dec 2014 11:12:11 -0500 >>>>>> Nathaniel McCallum wrote: >>>>>> >>>>>>> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: >>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>>>>>> Patch attached. >>>>>>>>>> >>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>>>>>> second timeouts and re-transmits when OTP is in place? >>>>>>>>>> >>>>>>>>>> What is the expected performance impact? Could it be configured >>>>>>>>>> for OTP separately - somehow? (I guess that it is not possible >>>>>>>>>> now ...) >>>>>>>>> >>>>>>>>> It benefits also communication of large packets (when large >>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice >>>>>>>>> for IPA in general. Especially given we have multiple KDC >>>>>>>>> processes configured we do not want clients wasting KDC resources >>>>>>>>> by making multiple processes do the same operation. >>>>>>>> >>>>>>>> So apparently this patch never got reviewed over a year ago. >>>>>>>> >>>>>>>> It was related to a bug which was opened in SSSD. However, when it >>>>>>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was >>>>>>>> closed but no corresponding FreeIPA bug was opened. The patch then >>>>>>>> fell through the cracks. >>>>>>>> >>>>>>>> Without this patch, if OTP validation runs long we get retransmits >>>>>>>> and failures. >>>>>>>> >>>>>>>> One question I have is how to handle this for upgrades since (I >>>>>>>> think) this patch only handles new installs. >>>>>>>> >>>>>>>> Anyway, this patch is somewhat urgent now. So help is appreciated. >>>>>>>> >>>>>>>> I have attached a rebased version which has no other changes. >>>>>>> >>>>>>> I still need a review on this. Any takers? >>>>>> >>>>>> The patch looks good to me >>>>>> >>>>>> Simo. >>>>> >>>>> This fixes the new installations. Can you please refresh the memory what is the >>>>> decision regarding the upgrades? >>>> >>>> The need to fix upgrades will be documented. In the future, we will >>>> get /etc/krb.conf.d and we will ship a file there. >>>> >>>> Nathaniel >>>> >>> >>> Nobody reads the documentation :-) What is the implication for users doing >>> client update (majority of them) and using OTP feature? >> >> They will get spurious failures. Most will think it is a bug or a >> network issue. If the failures happen consistently enough, users might >> get locked out. > > So what is the plan with this patch? We need to get it sorted. :) Ok, I am fine with your original approach then and only fix the new installations. You just need to rebase your patch, it does not apply to ipa-4-1 or master. Also, I am not convinced we should touch contrib/RHEL4/ipa-client-setup, did you try the script and are you confident this option is available on RHEL4? :-) If not, I would only update current installers. Martin From mkosek at redhat.com Fri Dec 5 08:48:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Dec 2014 09:48:45 +0100 Subject: [Freeipa-devel] [PATCH 3] ipa-client-install shouldn't be eager in specifying zone when doing nsupdate In-Reply-To: <548049EE.8030500@redhat.com> References: <20141202120013.GA24924@redhat.com> <547F3757.8090806@redhat.com> <20141204090338.GD11035@redhat.com> <548049EE.8030500@redhat.com> Message-ID: <5481716D.8030007@redhat.com> On 12/04/2014 12:47 PM, Martin Basti wrote: > On 04/12/14 10:03, Jan Pazdziora wrote: >> On Wed, Dec 03, 2014 at 05:16:23PM +0100, Martin Basti wrote: >>> On 02/12/14 13:00, Jan Pazdziora wrote: >>>> Hello, >>>> >>>> presumably explicitly specifying zone is not needed and can be >>>> harmful. >>>> >>> This should be fixed in template for uploading SSHFP keys as well. >>> >>> I have zone bububu.test. >>> >>> 2014-12-03T04:00:36Z DEBUG debug >>> zone client.bububu.test. >>> update delete test.client.bububu.test. IN SSHFP >>> show >>> send >>> update add test.client.bububu.test. 1200 IN SSHFP 1 1 >>> 8FD003E98D818E4E2813672234410835AB5844AC >>> update add test.client.bububu.test. 1200 IN SSHFP 1 2 >>> 37BF6366A44B67F6CA8FF8A8313B7C964CEA971CCB3E092D775FDF082170AAA4 >>> update add test.client.bububu.test. 1200 IN SSHFP 3 1 >>> 3651173F6737DF24EB6494434AC5968B3C90B749 >>> update add test.client.bububu.test. 1200 IN SSHFP 3 2 >>> 97EF4030A9DD471A3D4730A819B3A662E11994BB20AFC56FC3875AB1662260BF >>> show >>> send >> Updated patch attached. >> > ACK > I just removed unused dict value. > > @@ -1590,8 +1590,7 @@ def update_dns(server, hostname): > > sub_dict = dict(HOSTNAME=hostname, > IPADDRESS=ip, > - TTL=1200, > - ZONE='.'.join(hostname.split('.')[1:]) > + TTL=1200 > ) > > if af == socket.AF_INET: > > > Patch with this update attached. Pushed to: master: bea417828d61777015785c716c4225bb48dcf037 ipa-4-1: 8b4301473233afdf0ae3c72ad33bcd04182e63c6 From dkupka at redhat.com Fri Dec 5 09:23:04 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 05 Dec 2014 10:23:04 +0100 Subject: [Freeipa-devel] [PATCH 0162] Upgrade fix: masking named service should be executed only once In-Reply-To: <54635609.3010601@redhat.com> References: <54635609.3010601@redhat.com> Message-ID: <54817978.5020506@redhat.com> On 11/12/2014 01:43 PM, Martin Basti wrote: > Hello, > > masking named service is executed more than once, following patch fixes it. > > Patch attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works as expected but: 0) mask_named_regular() returns True, False and None. None evaluates as False so why not use False directly? 1) missing link to ticket in commit message. -- David Kupka From jcholast at redhat.com Fri Dec 5 10:30:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 05 Dec 2014 11:30:31 +0100 Subject: [Freeipa-devel] [PATCH] 384 Do not renew the IPA CA cert by serial number in dogtag-ipa-ca-renew-agent Message-ID: <54818947.4070801@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-384-Do-not-renew-the-IPA-CA-cert-by-serial-number-in-dog.patch Type: text/x-patch Size: 1376 bytes Desc: not available URL: From jcholast at redhat.com Fri Dec 5 10:34:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 05 Dec 2014 11:34:32 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <548166B9.9090807@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> Message-ID: <54818A38.5010008@redhat.com> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): > On 12/04/2014 09:36 AM, Jan Cholasta wrote: >> + if x509.get_der_subject(cert, x509.DER) != der_subject: >> + raise admintool.ScriptError("Subject name encoding >> mismatch") > > I think we can expect this to be a pretty common error, given this is > the default behavior of Microsoft Certificate Services. I would thus > like to make the error message more juicy. > > We need to make sure we offer some pointers for these users or they will > just blame IPA for screwing up. So, the information I wrote > > https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 > > need to somehow get to the error message as a potential/likely root > cause of the problem. Whether you write it in the error message itself > or update the design page and just insert a link is up to you. > > Martin I would rather document this and have users read the documentation, which they should do anyway when something goes wrong. There are many errors in IPA which are common and users may blame IPA for them and I don't see what makes this one so special that it should require a special treatment. Anyway, I have created . Honza -- Jan Cholasta From mkosek at redhat.com Fri Dec 5 10:43:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Dec 2014 11:43:34 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54818A38.5010008@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> Message-ID: <54818C56.6050201@redhat.com> On 12/05/2014 11:34 AM, Jan Cholasta wrote: > Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>> + if x509.get_der_subject(cert, x509.DER) != der_subject: >>> + raise admintool.ScriptError("Subject name encoding >>> mismatch") >> >> I think we can expect this to be a pretty common error, given this is >> the default behavior of Microsoft Certificate Services. I would thus >> like to make the error message more juicy. >> >> We need to make sure we offer some pointers for these users or they will >> just blame IPA for screwing up. So, the information I wrote >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >> >> need to somehow get to the error message as a potential/likely root >> cause of the problem. Whether you write it in the error message itself >> or update the design page and just insert a link is up to you. >> >> Martin > > I would rather document this and have users read the documentation, which they > should do anyway when something goes wrong. There are many errors in IPA which > are common and users may blame IPA for them and I don't see what makes this one > so special that it should require a special treatment. I saw several reasons: - Certificate&installation error are more common than the others and users are usually quite lost in what to do with them. - In this case, we know by 90% probability what is the root cause - It will block one of the main use cases for the new CA renewal tool and people will likely hit it as MS CAs is one of the most common CAs and this is it's default behavior. Giving more details in this case will not hurt us, but benefit users. So I still do not see the harm. > Anyway, I have created > . Good. Do you plan to reference the section or enhance the error message? Martin From jcholast at redhat.com Fri Dec 5 11:01:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 05 Dec 2014 12:01:33 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54818C56.6050201@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> <54818C56.6050201@redhat.com> Message-ID: <5481908D.2010706@redhat.com> Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): > On 12/05/2014 11:34 AM, Jan Cholasta wrote: >> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >>> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>>> + if x509.get_der_subject(cert, x509.DER) != der_subject: >>>> + raise admintool.ScriptError("Subject name encoding >>>> mismatch") >>> >>> I think we can expect this to be a pretty common error, given this is >>> the default behavior of Microsoft Certificate Services. I would thus >>> like to make the error message more juicy. >>> >>> We need to make sure we offer some pointers for these users or they will >>> just blame IPA for screwing up. So, the information I wrote >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >>> >>> need to somehow get to the error message as a potential/likely root >>> cause of the problem. Whether you write it in the error message itself >>> or update the design page and just insert a link is up to you. >>> >>> Martin >> >> I would rather document this and have users read the documentation, >> which they >> should do anyway when something goes wrong. There are many errors in >> IPA which >> are common and users may blame IPA for them and I don't see what makes >> this one >> so special that it should require a special treatment. > > I saw several reasons: > - Certificate&installation error are more common than the others and > users are usually quite lost in what to do with them. > - In this case, we know by 90% probability what is the root cause > - It will block one of the main use cases for the new CA renewal tool > and people will likely hit it as MS CAs is one of the most common CAs > and this is it's default behavior. > > Giving more details in this case will not hurt us, but benefit users. So > I still do not see the harm. I do not see a harm either, my point is that we should probably point the user to documentation when *anything* in *any* script goes wrong, not just when some arbitrarily cherry-picked error occurs. > >> Anyway, I have created >> . >> > > Good. Do you plan to reference the section or enhance the error message? I plan to reference . > > Martin -- Jan Cholasta From mbasti at redhat.com Fri Dec 5 11:58:40 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 05 Dec 2014 12:58:40 +0100 Subject: [Freeipa-devel] [PATCH 0162] Upgrade fix: masking named service should be executed only once In-Reply-To: <54817978.5020506@redhat.com> References: <54635609.3010601@redhat.com> <54817978.5020506@redhat.com> Message-ID: <54819DF0.90601@redhat.com> On 05/12/14 10:23, David Kupka wrote: > On 11/12/2014 01:43 PM, Martin Basti wrote: >> Hello, >> >> masking named service is executed more than once, following patch >> fixes it. >> >> Patch attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Works as expected but: > > 0) mask_named_regular() returns True, False and None. None evaluates > as False so why not use False directly? > 1) missing link to ticket in commit message. > > Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0162.2-Upgrade-fix-masking-named-should-be-executed-only-on.patch Type: text/x-patch Size: 2235 bytes Desc: not available URL: From pvoborni at redhat.com Fri Dec 5 12:46:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Dec 2014 13:46:20 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1417716942.3111.4.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> <1417550277.5864.82.camel@redhat.com> <54806819.7010101@redhat.com> <1417716942.3111.4.camel@redhat.com> Message-ID: <5481A91C.2000803@redhat.com> On 12/04/2014 07:15 PM, Nathaniel McCallum wrote: > On Thu, 2014-12-04 at 14:56 +0100, Petr Vobornik wrote: >> On 2.12.2014 20:57, Nathaniel McCallum wrote: >>> >> >> Works fine. >> >> python part of 0004: ACK, but VERSION needs to be updated before push >> 0005: ACK > > Fixed and rebased. Patch numbers have changed: > 0004 => 0001 > 0005 => 0002 > >> One question before push: For per-token configuration, do you intent to >> extend each token, regardless of type, by 'ipatokenOTPConfig' object >> class? I.e. to have config attributes for both types? Or do you plan to >> have special object classes for each token type as we now have for tokens? > > I would probably just add the TOTP options to the ipatokenTOTP object > class as MAY. Same for HOTP. The attributes were designed to look like > the other token-type-specific attributes. > > I think we are just waiting on Thierry's review of the C code. :) Thierry already wrote: > regarding the DS plugin part of 0004, the patch is good to me. For the ipa plugins part I am too novice. Therefore: 0001 Pushed to: master: 9baa93da1cbf56c2a6f7e82e099bc3ff3f19e2e4 ipa-4-1: 3013385ca4a28a4f203fae6dbef34321720d8879 0002 Pushed to: ipa-4-1: f5ae902eb5c391bd6150c99d5b3316be937aa459 master: b01767c69d69806b3c701242d617b6fa08e7d882 > > Nathaniel > -- Petr Vobornik From mkosek at redhat.com Fri Dec 5 12:53:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 05 Dec 2014 13:53:13 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <5481A91C.2000803@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> <1414589697.16650.4.camel@redhat.com> <1415117855.3318.3.camel@redhat.com> <545C7BC0.80205@redhat.com> <545CE8E9.2030009@redhat.com> <54606932.1030809@redhat.com> <1415831860.3363.4.camel@redhat.com> <54646256.5090908@redhat.com> <1415865083.9222.5.camel@redhat.com> <54646370.1090304@redhat.com> <546B9D66.5010704@redhat.com> <1417550277.5864.82.camel@redhat.com> <54806819.7010101@redhat.com> <1417716942.3111.4.camel@redhat.com> <5481A91C.2000803@redhat.com> Message-ID: <5481AAB9.6030103@redhat.com> On 12/05/2014 01:46 PM, Petr Vobornik wrote: > On 12/04/2014 07:15 PM, Nathaniel McCallum wrote: >> On Thu, 2014-12-04 at 14:56 +0100, Petr Vobornik wrote: >>> On 2.12.2014 20:57, Nathaniel McCallum wrote: >>>> >>> >>> Works fine. >>> >>> python part of 0004: ACK, but VERSION needs to be updated before push >>> 0005: ACK >> >> Fixed and rebased. Patch numbers have changed: >> 0004 => 0001 >> 0005 => 0002 >> >>> One question before push: For per-token configuration, do you intent to >>> extend each token, regardless of type, by 'ipatokenOTPConfig' object >>> class? I.e. to have config attributes for both types? Or do you plan to >>> have special object classes for each token type as we now have for tokens? >> >> I would probably just add the TOTP options to the ipatokenTOTP object >> class as MAY. Same for HOTP. The attributes were designed to look like >> the other token-type-specific attributes. >> >> I think we are just waiting on Thierry's review of the C code. :) > > Thierry already wrote: > >> regarding the DS plugin part of 0004, the patch is good to me. For the ipa >> plugins part I am too novice. > > Therefore: > > 0001 Pushed to: > master: 9baa93da1cbf56c2a6f7e82e099bc3ff3f19e2e4 > ipa-4-1: 3013385ca4a28a4f203fae6dbef34321720d8879 > > 0002 Pushed to: > ipa-4-1: f5ae902eb5c391bd6150c99d5b3316be937aa459 > master: b01767c69d69806b3c701242d617b6fa08e7d882 Thanks to all for resolving this RFE and this thread. It started to be little bit tangled :-) From pvoborni at redhat.com Fri Dec 5 13:33:53 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Dec 2014 14:33:53 +0100 Subject: [Freeipa-devel] [PATCH] 793-794 Fix schema related replication issues between IPA-3-0 and IPA-4-1 In-Reply-To: <5481B38B.2080300@redhat.com> References: <5481B38B.2080300@redhat.com> Message-ID: <5481B441.4030401@redhat.com> Hello, I've transformed Thierry's and Ludwig's findings of bz 1167964 [1] and ticket 4794 [2] into patches. I wonder if the mgrpRFC822MailMember and nsViewFilter issue(patch 794) should be solved on 389's side rather than on FreeIPA's? Also is the increase of nsslapd-sasl-max-buffer-size necessary? With these two patches, replication appears to work fine for me. Tested with F21 FreeIPA 4.1.x-GIT-something and ipa-server-3.0.0-42.el6.x86_64 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1167964 [2] https://fedorahosted.org/freeipa/ticket/4794 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0794-add-schema-control-exceptions-for-mgrpRFC822MailMemb.patch Type: text/x-patch Size: 1140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0793-revert-removal-of-cn-attribute-from-idnsRecord.patch Type: text/x-patch Size: 3278 bytes Desc: not available URL: From pvoborni at redhat.com Fri Dec 5 14:57:02 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Dec 2014 15:57:02 +0100 Subject: [Freeipa-devel] [PATCH 0289] hosts: Display assigned ID view by default in host-find and show In-Reply-To: <54807C3A.9090400@redhat.com> References: <547DD00A.7030705@redhat.com> <547DD753.1040405@redhat.com> <547DE277.4080406@redhat.com> <547DE78F.8090104@redhat.com> <54807C3A.9090400@redhat.com> Message-ID: <5481C7BE.1010809@redhat.com> On 12/04/2014 04:22 PM, Tomas Babej wrote: > > Updated patch with fixed WebUI bits. > ACK Pushed to: master: d0a781b9c6911f1875df4b0c7da5e6ae030d36de ipa-4-1: b986eb281d038e871cd613bf5a7a21a1456370cc -- Petr Vobornik From rcritten at redhat.com Fri Dec 5 15:01:08 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Dec 2014 10:01:08 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54806295.4040404@redhat.com> References: <54806295.4040404@redhat.com> Message-ID: <5481C8B4.3090106@redhat.com> Ludwig Krispenz wrote: > hi, > > I just have another (hopefully this will end soon) issue I want to get > your input. (please read to teh end first) > > To recapture the conditions: > - the topology plugin manages the connections between servers as > segments in the shared tree > - it is authoritative for managed servers, eg it controls all > connections between servers listed under cn=masters, > it is permissive for connection to other servers > - it rejects any removal of a segment, which would disconnect the topology. > - a change in topology can be applied to any server in the topology, it > will reach the respective servers and the plugin will act upon it > > Now there is a special case, causing a bit of trouble. If a replica is > to be removed from the topology, this means that > the replication agreements from and to this replica should be removed, > the server should be removed from the manages servers. > The problem is that: > - if you remove the server first, the server becomes unmanaged and > removal of the segment will not trigger a removal of the replication > agreement > - if you remove the segments first, one segment will be the last one > connecting this replica to the topology and removal will be rejected > Now, with some effort this can be resolved, eg > if the server is removed, keep it internally as removed server and for > segments connecting this server trigger removal of replication agreements > or mark a the last segment, when tried to remove, as pending and once > the server is removed also remove the corresponding repl agreements > > But there is a problem, which I think is much harder and I am not sure > how much effort I should put in resolving it. > If we want to have the replication agreements cleaned up after removal > of a replica without direct modification of cn=config, we need to follow > the path above, > but this also means that the last change needs to reach both the removed > replica (R) and the last server(S) it is connected to. The bad thing is > that if this change triggers a > removal of the replication agreement on S it could be that the change is > not replicated to R before the agreement is removed and is lost. > There is no way (or no easy) way to know for teh plugin if a change was > received by an other server, I was also thinking about some kind of > acknowledge mechanism by doing a ping pong of changes, but the problem > always is the same that one server does not know if the other has > received it. > And even if this would theoretically work, we cannot be sure that R is > not shutdown and only the remaining topology is tried to be cleaned up, > so S would wait forever. > > My suggestion to resolve this (in most cases) is to define a wait > interval, after the final combination of removal of a server and its > connecting segment is received, wait for some time and then remove the > corresponding replication agreements. > > So I'm asking you if this would be acceptable or if you have a better > solution. As I understood the proposal, you receive change requests which are validated and applied on the server that received them. This is going to cause changes to be replicated. On servers that get these replicated changes they simply apply the changes w/o applying the associated logic. Blindly, in other words. Doesn't that make this problem go away? rob From pvoborni at redhat.com Fri Dec 5 15:23:52 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Dec 2014 16:23:52 +0100 Subject: [Freeipa-devel] [PATCH] 795 webui: increase duration of notification messages Message-ID: <5481CE08.6000602@redhat.com> increase duration of notification messages by 66% https://fedorahosted.org/freeipa/ticket/4792 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0795-webui-increase-duration-of-notification-messages.patch Type: text/x-patch Size: 844 bytes Desc: not available URL: From simo at redhat.com Fri Dec 5 15:50:28 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 5 Dec 2014 10:50:28 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54806295.4040404@redhat.com> References: <54806295.4040404@redhat.com> Message-ID: <20141205105028.73a9d284@willson.usersys.redhat.com> On Thu, 04 Dec 2014 14:33:09 +0100 Ludwig Krispenz wrote: > hi, > > I just have another (hopefully this will end soon) issue I want to > get your input. (please read to teh end first) > > To recapture the conditions: > - the topology plugin manages the connections between servers as > segments in the shared tree > - it is authoritative for managed servers, eg it controls all > connections between servers listed under cn=masters, > it is permissive for connection to other servers > - it rejects any removal of a segment, which would disconnect the > topology. > - a change in topology can be applied to any server in the topology, > it will reach the respective servers and the plugin will act upon it > > Now there is a special case, causing a bit of trouble. If a replica > is to be removed from the topology, this means that > the replication agreements from and to this replica should be > removed, the server should be removed from the manages servers. > The problem is that: > - if you remove the server first, the server becomes unmanaged and > removal of the segment will not trigger a removal of the replication > agreement Can you explain what you mean "if you remove the server first" exactly ? What LDAP operation will be performed, by the management tools ? > - if you remove the segments first, one segment will be the last one > connecting this replica to the topology and removal will be rejected We should never remove the segments first indeed. > Now, with some effort this can be resolved, eg > if the server is removed, keep it internally as removed server and > for segments connecting this server trigger removal of replication > agreements or mark a the last segment, when tried to remove, as > pending and once the server is removed also remove the corresponding > repl agreements Why should we "keep it internally" ? If you mark the agreements as managed by setting an attribute on them, then you will never have any issue recognizing a "managed" agreement in cn=config, and you will also immediately find out it is "old" as it is not backed by a segment so you will safely remove it. Segments (and their agreements) should be removed as trigger on the master entry getting removed. This should be done even if it causes a split brain, because if the server is removed, no matter how much we wish to keep tropology integrity we effectively are in a split brain situation, keeping toplogy agreements alive w/o the server entry doesn't help. > But there is a problem, which I think is much harder and I am not > sure how much effort I should put in resolving it. > If we want to have the replication agreements cleaned up after > removal of a replica without direct modification of cn=config, we > need to follow the path above, > but this also means that the last change needs to reach both the > removed replica (R) and the last server(S) it is connected to. It would be nice if the changed reached the replica, indeed, but not a big deal if it doesn't, if you are removing the replica it means you are decommissioning it, so it is not really that important that it receives updates, it will be destroyed shortly. And if it is not destroyed for whatever reason, it will be removed from the masters group anyway so it will have no permission to replicate back, and no harm is done to the overall domain. > The bad thing is that if this change triggers a > removal of the replication agreement on S it could be that the change > is not replicated to R before the agreement is removed and is lost. > There is no way (or no easy) way to know for teh plugin if a change > was received by an other server, There is an easy way, contact the other server and see if the change happened in its LDAP tree :) BNut this is not really necessary, as explained above. > I was also thinking about some kind > of acknowledge mechanism by doing a ping pong of changes, but the > problem always is the same that one server does not know if the other > has received it. > And even if this would theoretically work, we cannot be sure that R > is not shutdown and only the remaining topology is tried to be > cleaned up, so S would wait forever. We should not care, if you are deleting a replica it doesn't matter what's on the replica side IMO. > My suggestion to resolve this (in most cases) is to define a wait > interval, after the final combination of removal of a server and its > connecting segment is received, wait for some time and then remove > the corresponding replication agreements. Why ? > So I'm asking you if this would be acceptable or if you have a better > solution. I am trying to understand why we have a problem, actually, I do not really see one, why do you think it is important to update a replica that is being killed ? Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Fri Dec 5 16:23:54 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 05 Dec 2014 11:23:54 -0500 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <54816AA6.4000107@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> <547DED6B.4010206@redhat.com> <1417538994.5864.62.camel@redhat.com> <547DEE29.1010407@redhat.com> <1417539312.5864.64.camel@redhat.com> <1417717026.3111.5.camel@redhat.com> <54816AA6.4000107@redhat.com> Message-ID: <1417796634.3111.9.camel@redhat.com> On Fri, 2014-12-05 at 09:19 +0100, Martin Kosek wrote: > On 12/04/2014 07:17 PM, Nathaniel McCallum wrote: > > On Tue, 2014-12-02 at 11:55 -0500, Nathaniel McCallum wrote: > >> On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote: > >>> On 12/02/2014 05:49 PM, Nathaniel McCallum wrote: > >>>> On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: > >>>>> On 12/02/2014 05:36 PM, Simo Sorce wrote: > >>>>>> On Tue, 02 Dec 2014 11:12:11 -0500 > >>>>>> Nathaniel McCallum wrote: > >>>>>> > >>>>>>> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: > >>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: > >>>>>>>>>>> Patch attached. > >>>>>>>>>> > >>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 > >>>>>>>>>> second timeouts and re-transmits when OTP is in place? > >>>>>>>>>> > >>>>>>>>>> What is the expected performance impact? Could it be configured > >>>>>>>>>> for OTP separately - somehow? (I guess that it is not possible > >>>>>>>>>> now ...) > >>>>>>>>> > >>>>>>>>> It benefits also communication of large packets (when large > >>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice > >>>>>>>>> for IPA in general. Especially given we have multiple KDC > >>>>>>>>> processes configured we do not want clients wasting KDC resources > >>>>>>>>> by making multiple processes do the same operation. > >>>>>>>> > >>>>>>>> So apparently this patch never got reviewed over a year ago. > >>>>>>>> > >>>>>>>> It was related to a bug which was opened in SSSD. However, when it > >>>>>>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was > >>>>>>>> closed but no corresponding FreeIPA bug was opened. The patch then > >>>>>>>> fell through the cracks. > >>>>>>>> > >>>>>>>> Without this patch, if OTP validation runs long we get retransmits > >>>>>>>> and failures. > >>>>>>>> > >>>>>>>> One question I have is how to handle this for upgrades since (I > >>>>>>>> think) this patch only handles new installs. > >>>>>>>> > >>>>>>>> Anyway, this patch is somewhat urgent now. So help is appreciated. > >>>>>>>> > >>>>>>>> I have attached a rebased version which has no other changes. > >>>>>>> > >>>>>>> I still need a review on this. Any takers? > >>>>>> > >>>>>> The patch looks good to me > >>>>>> > >>>>>> Simo. > >>>>> > >>>>> This fixes the new installations. Can you please refresh the memory what is the > >>>>> decision regarding the upgrades? > >>>> > >>>> The need to fix upgrades will be documented. In the future, we will > >>>> get /etc/krb.conf.d and we will ship a file there. > >>>> > >>>> Nathaniel > >>>> > >>> > >>> Nobody reads the documentation :-) What is the implication for users doing > >>> client update (majority of them) and using OTP feature? > >> > >> They will get spurious failures. Most will think it is a bug or a > >> network issue. If the failures happen consistently enough, users might > >> get locked out. > > > > So what is the plan with this patch? We need to get it sorted. :) > > Ok, I am fine with your original approach then and only fix the new > installations. You just need to rebase your patch, it does not apply to ipa-4-1 > or master. Fixed. > Also, I am not convinced we should touch contrib/RHEL4/ipa-client-setup, did > you try the script and are you confident this option is available on RHEL4? :-) > If not, I would only update current installers. Agreed. Fixed. Also, I updated the commit message to be more thorough. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0019.1-Prefer-TCP-connections-to-UDP-in-krb5-clients.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: From dpal at redhat.com Fri Dec 5 18:54:39 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 5 Dec 2014 13:54:39 -0500 (EST) Subject: [Freeipa-devel] [Freeipa-interest] Announcing FreeIPA 4.1.2 - NEED HELP WITH 2FA/OTP!!! In-Reply-To: <54775877.6060102@redhat.com> References: <54775877.6060102@redhat.com> Message-ID: <176433463.23902008.1417805679430.JavaMail.zimbra@redhat.com> Hello, WE NEED HELP! The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here. http://www.freeipa.org/page/V4/OTP If you want to see this feature in downstream distros sooner rather than later we need your help! Please give it a try and provide feedback. We really, really need it! Thank you, FreeIPA development team ----- Original Message ----- From: "Petr Vobornik" To: "freeipa-devel" , "freeipa-users" , freeipa-interest at redhat.com Sent: Thursday, November 27, 2014 11:59:35 AM Subject: [Freeipa-interest] Announcing FreeIPA 4.1.2 The FreeIPA team would like to announce FreeIPA v4.1.2 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.2 == === Bug fixes === * CVE-2014-7850: ensure that user input is properly escaped to prevent XSS attacks [https://fedorahosted.org/freeipa/ticket/4742] [http://www.freeipa.org/page/CVE-2014-7850] * harden mod_nss config on update to use TLSv1.0, TLSv1.1, TLSv1.2 * fixed getkeytab operation [https://fedorahosted.org/freeipa/ticket/4718] [https://fedorahosted.org/freeipa/ticket/4728] * backup and restore fixes related to certificates restore and SELinux context * static code analysis fixes * various small fixes == Upgrading == 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 the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require 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 3.3.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 4.1.1 == === Alexander Bokovoy (2) === * Update slapi-nis dependency to pull 0.54.1 * AD trust: improve trust validation === David Kupka (6) === * Remove unneeded internal methods. Move code to public methods. * Remove service file even if it isn't link. * Produce better error in group-add command. * Fix --{user,group}-ignore-attribute in migration plugin. * ipa-restore: Check if directory is provided + better errors. * Fix error message for nonexistent members and add tests. === Gabe Alford (1) === * ipa-server-install Directory Manager help incorrect === Jan Cholasta (15) === * Fix CA certificate backup and restore * Update Requires on pki-ca to 10.2.1-0.1 * Fix wrong expiration date on renewed IPA CA certificates * Restore file extended attributes and SELinux context in ipa-restore * Use correct service name in cainstance.backup_config * Stop tracking certificates before restoring them in ipa-restore * Remove redefinition of LOG from ipa-otp-lasttoken * Unload P11_Helper object's library when it is finalized in ipap11helper * Fix Kerberos error handling in ipa-sam * Fix unchecked return value in ipa-kdb * Fix unchecked return values in ipa-winsync * Fix unchecked return value in ipa-join * Fix unchecked return value in krb5 common utils * Fix memory leak in GetKeytabControl asn1 code * Add TLS 1.2 to the protocol list in mod_nss config === Martin Ba?ti (12) === * Fix: DNS installer adds invalid zonemgr email * Fix: DNS policy upgrade raises asertion error * Fix upgrade referint plugin * Upgrade: fix trusts objectclass violationi * Fix named working directory permissions * Fix: zonemgr must be unicode value * Fix warning message should not contain CLI commands * Show warning instead of error if CA did not start * Raise right exception if domain name is not valid * Fix pk11helper module compiler warnings * Fix: read_ip_addresses should return ipaddr object * Fix detection of encoding in zonemgr option === Martin Ko?ek (1) === * Lower pki-ca requires to 10.1.2 === Nathaniel McCallum (3) === * Improve otptoken help messages * Ensure users exist when assigning tokens to them * Enable QR code display by default in otptoken-add === Petr Viktorin (5) === * ipa-restore: Don't crash if AD trust is not installed * ipaplatform: Use the dirsrv service, not target * Do not restore SELinux settings that were not backed up * Add additional backup & restore checks * copy_schema_to_ca: Fallback to old import location for ipaplatform.services === Petr Voborn?k (9) === * ranges: prohibit setting --rid-base with ipa-trust-ad-posix type * unittests: baserid for ipa-ad-trust-posix idranges * ldapupdater: set baserid to 0 for ipa-ad-trust-posix ranges * idrange: include raw range type in output * webui: prohibit setting rid base with ipa-trust-ad-posix type * webui: fix potential XSS vulnerabilities * restore: clear httpd ccache after restore * webui: use domain name instead of domain SID in idrange adder dialog * webui: normalize idview tab labels === Petr ?pa?ek (1) === * Fix minimal version of BIND for Fedora 20 and 21 === Rob Crittenden (2) === * Search using proper scope when connecting CA instances * Use NSS protocol range API to set available TLS protocols === Simo Sorce (4) === * Add UTC date to GIT snapshot version generation * Fix filtering of enctypes in server code. * Add asn1c generated code for keytab controls * Use asn1c helpers to encode/decode the getkeytab control === Thorsten Scherf (1) === * Add help string on how to configure multiple DNS forwards for various cli tools -- Petr Vobornik _______________________________________________ Freeipa-interest mailing list Freeipa-interest at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-interest From npmccallum at redhat.com Fri Dec 5 22:51:31 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 05 Dec 2014 17:51:31 -0500 Subject: [Freeipa-devel] [RANT] pytest fixture scope is braindead Message-ID: <1417819891.3111.64.camel@redhat.com> So I've been working this week on porting the OTP tests that were manually coded to the new pytest framework. Now, I'm the first to want better tooling to make our job easier. But, pytest? Meh. I'm having to write just as much code (or more) to get my tests on par with pytest, and they are riddled with subtle bugs. Most painful, is pytest.fixture(). It is a cool idea, but the scoping and lifecycle is horribly broken. Here is an example: Here is an example. I want to create a user, enable otp in two different ways, test with two different types of tokens under two different authentication scenarios. This is a total of 8 tests. @pytest.fixture(scope="function") # This scope is default. def user(request): user = create_user('tuser1') request.addfinalizer(lambda: delete_user('tuser1')) return user @pytest.fixture(params=["per-user", "global"]) def enablement(request, user): output = enable(user, request.param) request.addfinalizer(lambda: disable(user)) return output @pytest.fixture(params=[{'type': 'HOTP'}, {'disabled': True}]) def token(request, user, enablement): output = create_token(request.param) request.addfinalizer(lambda: delete_token(output.id)) return output @pytest.mark.parametrize("opts", [foo, bar]) def test_authentication(user, token, opts): return auth(user.uid, token.code(), opts) Because the default scope is "function", a new user is created for every single run of token. This is *way* more work than necessary, and leads to slow runtimes. Fortunately, we can fix this by changing the scope of the user fixture to "module". In this case, only one user will be created per module. So far so good. The enablement scope is still "function", so it will still be called eight times (#tokens * #enablements * #opts). Now, this is a problem because (let's say) enablement takes a long time to switch tests. Here is problem #1 with pytest: it presumes that all variants of fixtures should be grouped by test parameters. This is a bad assumption. It may make sense in some cases, but there is no way to change it. Now, we can work around this problem just like with the user fixture: change the scope to "module". Unfortunately, we've just caused a second bug. Now, enablement() will only be run twice; but the finalizer will not be called until all tests are run. This means that "per-user" enablement will still be active when "global" enablement runs; both will be torn down simultaneously. This same problem arises for the token fixture: eight tokens will be created and destroyed when only four are necessary. You guessed it, we can fix this by changing the scope. But by doing this all four tokens will be deleted simultaneously. This means we cannot test the state where only a disabled token exists. Any attempt to use a fixture to create long-lived states (precisely what fixtures are designed for) with mutually exclusive parameters is extremely error prone as it is not clear which items are alive in the LDAP db at any point. This leads to both long runtimes *and* extremely subtle bugs in the tests that are multiplied by every layer of fixtures. Call me nonplussed. Now, let's look at how this same test can be implemented without pytest: user = create_user('tuser1') try: for enablement in ('per-user', 'global'): enable(user, enablement) try: for token in [{'type': 'HOTP'}, {'disabled': True}]: object = create_token(token) try: for opt in [foo, bar]: auth(user.uid, object.code(), opt) finally: delete_token(object.id) finally: disable(user) finally: delete_user('tuser1') Comparing the non-pytest implementation to the pytest one we can see a few things. First, the pytest code has some nice separation of roles. This is the big benefit of pytest. Second, the non-pytest implementation is less code. Third, the non-pytest implementation has no subtle scoping bugs: we know exactly when each database record is created and destroyed. I *want* to like pytest. Honestly I do. But this scoping idiocy has already cost me roughly two days tracking down subtle bugs in the tests (while not finding any bugs in the OTP code itself). And I can't think that OTP tests written using pytest will be maintainable in any regard; not when such small changes can cause such hard to find bugs. Now, it may be possible that I have just missed something obvious. If I have, forgive me this rant. But I've spent a lot of time reading docs and I haven't seen any obvious solutions to these problems. Nathaniel From rcritten at redhat.com Sun Dec 7 15:25:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 07 Dec 2014 10:25:06 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <20141205105028.73a9d284@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> Message-ID: <54847152.3030209@redhat.com> Simo Sorce wrote: > On Thu, 04 Dec 2014 14:33:09 +0100 > Ludwig Krispenz wrote: > >> hi, >> >> I just have another (hopefully this will end soon) issue I want to >> get your input. (please read to teh end first) >> >> To recapture the conditions: >> - the topology plugin manages the connections between servers as >> segments in the shared tree >> - it is authoritative for managed servers, eg it controls all >> connections between servers listed under cn=masters, >> it is permissive for connection to other servers >> - it rejects any removal of a segment, which would disconnect the >> topology. >> - a change in topology can be applied to any server in the topology, >> it will reach the respective servers and the plugin will act upon it >> >> Now there is a special case, causing a bit of trouble. If a replica >> is to be removed from the topology, this means that >> the replication agreements from and to this replica should be >> removed, the server should be removed from the manages servers. >> The problem is that: >> - if you remove the server first, the server becomes unmanaged and >> removal of the segment will not trigger a removal of the replication >> agreement I had another, sort of unrelated thought about this, thinking about deleting servers. What happens if a replication conflict entry gets added? While both exist I imagine that the actual agreement would reflect whichever entry is processed last. Probably not the end of the world. But how do you remove the conflict entry without also potentially deleting that master? rob From mkosek at redhat.com Mon Dec 8 10:03:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Dec 2014 11:03:18 +0100 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1417796634.3111.9.camel@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> <1415314821.5013.3.camel@redhat.com> <1417536731.5864.51.camel@redhat.com> <20141202113648.4c249112@willson.usersys.redhat.com> <547DED6B.4010206@redhat.com> <1417538994.5864.62.camel@redhat.com> <547DEE29.1010407@redhat.com> <1417539312.5864.64.camel@redhat.com> <1417717026.3111.5.camel@redhat.com> <54816AA6.4000107@redhat.com> <1417796634.3111.9.camel@redhat.com> Message-ID: <54857766.2040204@redhat.com> On 12/05/2014 05:23 PM, Nathaniel McCallum wrote: > On Fri, 2014-12-05 at 09:19 +0100, Martin Kosek wrote: >> On 12/04/2014 07:17 PM, Nathaniel McCallum wrote: >>> On Tue, 2014-12-02 at 11:55 -0500, Nathaniel McCallum wrote: >>>> On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote: >>>>> On 12/02/2014 05:49 PM, Nathaniel McCallum wrote: >>>>>> On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote: >>>>>>> On 12/02/2014 05:36 PM, Simo Sorce wrote: >>>>>>>> On Tue, 02 Dec 2014 11:12:11 -0500 >>>>>>>> Nathaniel McCallum wrote: >>>>>>>> >>>>>>>>> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote: >>>>>>>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote: >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote: >>>>>>>>>>>>> Patch attached. >>>>>>>>>>>> >>>>>>>>>>>> I'm curious - what is the purpose of this patch? To prevent 1 >>>>>>>>>>>> second timeouts and re-transmits when OTP is in place? >>>>>>>>>>>> >>>>>>>>>>>> What is the expected performance impact? Could it be configured >>>>>>>>>>>> for OTP separately - somehow? (I guess that it is not possible >>>>>>>>>>>> now ...) >>>>>>>>>>> >>>>>>>>>>> It benefits also communication of large packets (when large >>>>>>>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice >>>>>>>>>>> for IPA in general. Especially given we have multiple KDC >>>>>>>>>>> processes configured we do not want clients wasting KDC resources >>>>>>>>>>> by making multiple processes do the same operation. >>>>>>>>>> >>>>>>>>>> So apparently this patch never got reviewed over a year ago. >>>>>>>>>> >>>>>>>>>> It was related to a bug which was opened in SSSD. However, when it >>>>>>>>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was >>>>>>>>>> closed but no corresponding FreeIPA bug was opened. The patch then >>>>>>>>>> fell through the cracks. >>>>>>>>>> >>>>>>>>>> Without this patch, if OTP validation runs long we get retransmits >>>>>>>>>> and failures. >>>>>>>>>> >>>>>>>>>> One question I have is how to handle this for upgrades since (I >>>>>>>>>> think) this patch only handles new installs. >>>>>>>>>> >>>>>>>>>> Anyway, this patch is somewhat urgent now. So help is appreciated. >>>>>>>>>> >>>>>>>>>> I have attached a rebased version which has no other changes. >>>>>>>>> >>>>>>>>> I still need a review on this. Any takers? >>>>>>>> >>>>>>>> The patch looks good to me >>>>>>>> >>>>>>>> Simo. >>>>>>> >>>>>>> This fixes the new installations. Can you please refresh the memory what is the >>>>>>> decision regarding the upgrades? >>>>>> >>>>>> The need to fix upgrades will be documented. In the future, we will >>>>>> get /etc/krb.conf.d and we will ship a file there. >>>>>> >>>>>> Nathaniel >>>>>> >>>>> >>>>> Nobody reads the documentation :-) What is the implication for users doing >>>>> client update (majority of them) and using OTP feature? >>>> >>>> They will get spurious failures. Most will think it is a bug or a >>>> network issue. If the failures happen consistently enough, users might >>>> get locked out. >>> >>> So what is the plan with this patch? We need to get it sorted. :) >> >> Ok, I am fine with your original approach then and only fix the new >> installations. You just need to rebase your patch, it does not apply to ipa-4-1 >> or master. > > Fixed. > >> Also, I am not convinced we should touch contrib/RHEL4/ipa-client-setup, did >> you try the script and are you confident this option is available on RHEL4? :-) >> If not, I would only update current installers. > > Agreed. Fixed. This one worked fine in my tests. > Also, I updated the commit message to be more thorough. Thanks. I just changed the SSSD ticket to the FreeIPA one, to fix commit automated processing. ACK, pushed to: master: 7ad9f5d3d5ff2eec43bc355c4e7e9514aff01a31 ipa-4-1: d73ed48cf7fa820b6ff8c46b394ff6da19bc7087 Martin From pviktori at redhat.com Mon Dec 8 11:27:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Dec 2014 12:27:27 +0100 Subject: [Freeipa-devel] [RANT] pytest fixture scope is braindead In-Reply-To: <1417819891.3111.64.camel@redhat.com> References: <1417819891.3111.64.camel@redhat.com> Message-ID: <54858B1F.2020402@redhat.com> On 12/05/2014 11:51 PM, Nathaniel McCallum wrote: > So I've been working this week on porting the OTP tests that were > manually coded to the new pytest framework. Now, I'm the first to want > better tooling to make our job easier. But, pytest? Meh. I'm having to > write just as much code (or more) to get my tests on par with pytest, > and they are riddled with subtle bugs. Hi, Yeah, IPA runs into specific situations that are very different from how tests usually work in other projects. And you took one of the harder cases. IPA's existing tests also don't really follow best practices ? they pretty much assume you run the whole test suite, or at least the whole module, so selecting individual tests is currently not reliable. On the other hand, this assumption made some things easy to code ? like complicated ordering and setup/teardown. One thing we want to do during the move to pytest is to have the tests be more independent of the current state of the database, and also of each other. If certain assertions only make sense in a specific order, either put them in the same test*, or write additional code that explicitly handles dependencies and ordering. (Sorry, that's the price to pay for isolated tests ? I don't see a way around it.) If on the other hand the order doesn't matter ? any order of any subset of individual tests should pass, which is our goal ? but pytest's default ordering makes the suite slow, there is a hook that allows you to override the order: pytest_collection_modifyitems [0]. Stick it in the affected module (or conftest.py file for multiple modules, or a plugin for the whole suite), and sort the items explicitly. If your test depends on something not existing or being disabled, you should try removing/disabling it before the test, or write a fixture to do that. * might make sense, for starters? [0] http://pytest.org/latest/plugins.html#_pytest.hookspec.pytest_collection_modifyitems > Most painful, is pytest.fixture(). It is a cool idea, but the scoping > and lifecycle is horribly broken. Here is an example: > > Here is an example. I want to create a user, enable otp in two different > ways, test with two different types of tokens under two different > authentication scenarios. This is a total of 8 tests. > > @pytest.fixture(scope="function") # This scope is default. > def user(request): > user = create_user('tuser1') > request.addfinalizer(lambda: delete_user('tuser1')) > return user > > @pytest.fixture(params=["per-user", "global"]) > def enablement(request, user): > output = enable(user, request.param) > request.addfinalizer(lambda: disable(user)) > return output > > @pytest.fixture(params=[{'type': 'HOTP'}, {'disabled': True}]) > def token(request, user, enablement): > output = create_token(request.param) > request.addfinalizer(lambda: delete_token(output.id)) > return output > > @pytest.mark.parametrize("opts", [foo, bar]) > def test_authentication(user, token, opts): > return auth(user.uid, token.code(), opts) > > Because the default scope is "function", a new user is created for every > single run of token. This is *way* more work than necessary, and leads > to slow runtimes. Fortunately, we can fix this by changing the scope of > the user fixture to "module". In this case, only one user will be > created per module. So far so good. > > The enablement scope is still "function", so it will still be called > eight times (#tokens * #enablements * #opts). Now, this is a problem > because (let's say) enablement takes a long time to switch tests. Here > is problem #1 with pytest: it presumes that all variants of fixtures > should be grouped by test parameters. This is a bad assumption. It may > make sense in some cases, but there is no way to change it. > > Now, we can work around this problem just like with the user fixture: > change the scope to "module". Unfortunately, we've just caused a second > bug. Now, enablement() will only be run twice; but the finalizer will > not be called until all tests are run. This means that "per-user" > enablement will still be active when "global" enablement runs; both will > be torn down simultaneously. > > This same problem arises for the token fixture: eight tokens will be > created and destroyed when only four are necessary. You guessed it, we > can fix this by changing the scope. But by doing this all four tokens > will be deleted simultaneously. This means we cannot test the state > where only a disabled token exists. > > Any attempt to use a fixture to create long-lived states (precisely what > fixtures are designed for) with mutually exclusive parameters is > extremely error prone as it is not clear which items are alive in the > LDAP db at any point. This leads to both long runtimes *and* extremely > subtle bugs in the tests that are multiplied by every layer of fixtures. > Call me nonplussed. > > Now, let's look at how this same test can be implemented without pytest: > > user = create_user('tuser1') > try: > for enablement in ('per-user', 'global'): > enable(user, enablement) > try: > for token in [{'type': 'HOTP'}, {'disabled': True}]: > object = create_token(token) > try: > for opt in [foo, bar]: > auth(user.uid, object.code(), opt) > finally: > delete_token(object.id) > finally: > disable(user) > finally: > delete_user('tuser1') > > Comparing the non-pytest implementation to the pytest one we can see a > few things. First, the pytest code has some nice separation of roles. > This is the big benefit of pytest. Second, the non-pytest implementation > is less code. Third, the non-pytest implementation has no subtle scoping > bugs: we know exactly when each database record is created and > destroyed. This "non-pytest" implementation is a *single test*, since it hard-codes dependencies and ordering. If you write it as as a single test function in pytest, it should look much the same, and get the ordering/dependencies right (except the case of the test user already existing). > I *want* to like pytest. Honestly I do. But this scoping idiocy has > already cost me roughly two days tracking down subtle bugs in the tests > (while not finding any bugs in the OTP code itself). And I can't think > that OTP tests written using pytest will be maintainable in any regard; > not when such small changes can cause such hard to find bugs. > > Now, it may be possible that I have just missed something obvious. If I > have, forgive me this rant. But I've spent a lot of time reading docs > and I haven't seen any obvious solutions to these problems. > > Nathaniel -- Petr? From pviktori at redhat.com Mon Dec 8 11:52:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Dec 2014 12:52:54 +0100 Subject: [Freeipa-devel] Heads up: Samba considering port to Python 3 Message-ID: <54859116.3030405@redhat.com> Hello, I'm slowly starting the work to port Samba's bindings to Python 3, and since FreeIPA depends on them, this is relevant here. Currently the consensus on the Samba list seems to be that support for Python 2 will be dropped shortly after the port. If that happens in Samba 4.3, this would give us about a year to port FreeIPA and all its dependencies. Keep in mind that this is a very early heads-up. Samba build infrastructure improvements seem inevitable, and if the needed changes end up trivial enough, perhaps Samba can reconsider supporting both Python versions for some longer time. -- Petr? From npmccallum at redhat.com Mon Dec 8 14:15:10 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 08 Dec 2014 09:15:10 -0500 Subject: [Freeipa-devel] [RANT] pytest fixture scope is braindead In-Reply-To: <54858B1F.2020402@redhat.com> References: <1417819891.3111.64.camel@redhat.com> <54858B1F.2020402@redhat.com> Message-ID: <1418048110.2578.19.camel@redhat.com> On Mon, 2014-12-08 at 12:27 +0100, Petr Viktorin wrote: > On 12/05/2014 11:51 PM, Nathaniel McCallum wrote: > > So I've been working this week on porting the OTP tests that were > > manually coded to the new pytest framework. Now, I'm the first to want > > better tooling to make our job easier. But, pytest? Meh. I'm having to > > write just as much code (or more) to get my tests on par with pytest, > > and they are riddled with subtle bugs. > > Hi, > Yeah, IPA runs into specific situations that are very different from how > tests usually work in other projects. Yeah, this I get. > And you took one of the harder cases. > IPA's existing tests also don't really follow best practices ? they > pretty much assume you run the whole test suite, or at least the whole > module, so selecting individual tests is currently not reliable. On the > other hand, this assumption made some things easy to code ? like > complicated ordering and setup/teardown. I think this is pretty much a red herring. It isn't so much about setup and teardown but about mutually exclusive parameterization. It is a poor assumption on the part of pytest that the lifecycles of parameters overlap. At the least, an option should be provided to control this. > One thing we want to do during the move to pytest is to have the tests > be more independent of the current state of the database, and also of > each other. Sure, this is a fine goal. Unless of course you want to test the functionality of the code against all possible database states. I think pretty much every xmlrpc test will have some component of this. > If certain assertions only make sense in a specific order, either put > them in the same test*, or write additional code that explicitly handles > dependencies and ordering. (Sorry, that's the price to pay for isolated > tests ? I don't see a way around it.) In an ideal world, we define a test and all possible parameters to that test and allow the running of that test independently by choosing from the proscribed inputs. This all works fine so long as you specify a way to indicate when inputs are mutually exclusive. Since inputs are single valued anyway, this should be the default behavior. Unfortunately, pytest fails on both of these counts. > If on the other hand the order doesn't matter ? any order of any subset > of individual tests should pass, which is our goal ? but pytest's > default ordering makes the suite slow, there is a hook that allows you > to override the order: pytest_collection_modifyitems [0]. Stick it in > the affected module (or conftest.py file for multiple modules, or a > plugin for the whole suite), and sort the items explicitly. The problem isn't (I think) ordering but lifecycle. I think that if I scope the fixture to the function but reorder the items, they will still be constructed and torn down for every single function iteration. On the other hand, if I scope the fixture for a longer lifecycle, the parameters may not be mutually exclusive. > If your test depends on something not existing or being disabled, you > should try removing/disabling it before the test, or write a fixture to > do that. That's not the problem. The problem is that I can't define parameters for a single object which sets the same variable to different values. Such an act means the parameters are mutually exclusive. > * might make sense, for starters? > [0] > http://pytest.org/latest/plugins.html#_pytest.hookspec.pytest_collection_modifyitems > > > > Most painful, is pytest.fixture(). It is a cool idea, but the scoping > > and lifecycle is horribly broken. Here is an example: > > > > Here is an example. I want to create a user, enable otp in two different > > ways, test with two different types of tokens under two different > > authentication scenarios. This is a total of 8 tests. > > > > @pytest.fixture(scope="function") # This scope is default. > > def user(request): > > user = create_user('tuser1') > > request.addfinalizer(lambda: delete_user('tuser1')) > > return user > > > > @pytest.fixture(params=["per-user", "global"]) > > def enablement(request, user): > > output = enable(user, request.param) > > request.addfinalizer(lambda: disable(user)) > > return output > > > > @pytest.fixture(params=[{'type': 'HOTP'}, {'disabled': True}]) > > def token(request, user, enablement): > > output = create_token(request.param) > > request.addfinalizer(lambda: delete_token(output.id)) > > return output > > > > @pytest.mark.parametrize("opts", [foo, bar]) > > def test_authentication(user, token, opts): > > return auth(user.uid, token.code(), opts) > > > > Because the default scope is "function", a new user is created for every > > single run of token. This is *way* more work than necessary, and leads > > to slow runtimes. Fortunately, we can fix this by changing the scope of > > the user fixture to "module". In this case, only one user will be > > created per module. So far so good. > > > > The enablement scope is still "function", so it will still be called > > eight times (#tokens * #enablements * #opts). Now, this is a problem > > because (let's say) enablement takes a long time to switch tests. Here > > is problem #1 with pytest: it presumes that all variants of fixtures > > should be grouped by test parameters. This is a bad assumption. It may > > make sense in some cases, but there is no way to change it. > > > > Now, we can work around this problem just like with the user fixture: > > change the scope to "module". Unfortunately, we've just caused a second > > bug. Now, enablement() will only be run twice; but the finalizer will > > not be called until all tests are run. This means that "per-user" > > enablement will still be active when "global" enablement runs; both will > > be torn down simultaneously. > > > > This same problem arises for the token fixture: eight tokens will be > > created and destroyed when only four are necessary. You guessed it, we > > can fix this by changing the scope. But by doing this all four tokens > > will be deleted simultaneously. This means we cannot test the state > > where only a disabled token exists. > > > > Any attempt to use a fixture to create long-lived states (precisely what > > fixtures are designed for) with mutually exclusive parameters is > > extremely error prone as it is not clear which items are alive in the > > LDAP db at any point. This leads to both long runtimes *and* extremely > > subtle bugs in the tests that are multiplied by every layer of fixtures. > > Call me nonplussed. > > > > Now, let's look at how this same test can be implemented without pytest: > > > > user = create_user('tuser1') > > try: > > for enablement in ('per-user', 'global'): > > enable(user, enablement) > > try: > > for token in [{'type': 'HOTP'}, {'disabled': True}]: > > object = create_token(token) > > try: > > for opt in [foo, bar]: > > auth(user.uid, object.code(), opt) > > finally: > > delete_token(object.id) > > finally: > > disable(user) > > finally: > > delete_user('tuser1') > > > > Comparing the non-pytest implementation to the pytest one we can see a > > few things. First, the pytest code has some nice separation of roles. > > This is the big benefit of pytest. Second, the non-pytest implementation > > is less code. Third, the non-pytest implementation has no subtle scoping > > bugs: we know exactly when each database record is created and > > destroyed. > > This "non-pytest" implementation is a *single test*, since it hard-codes > dependencies and ordering. If you write it as as a single test function > in pytest, it should look much the same, and get the > ordering/dependencies right (except the case of the test user already > existing). Which conflicts with the desired granularity; which is the whole reason we are moving away from this model. I should be able to define, as fixtures, a set of states required to run any one of a set of test. Then I can choose just to run a single iteration of a set of tests and the set of states should be assembled correctly. The problem is that, with pytest, this all works unless the parameterized fixtures contain mutually exclusive state values. So, I'm obviously not proposing that we do something like the non-pytest implementation. What I'm pointing out is that being forced to implement it this way in pytest negates all the benefits of pytest. > > I *want* to like pytest. Honestly I do. But this scoping idiocy has > > already cost me roughly two days tracking down subtle bugs in the tests > > (while not finding any bugs in the OTP code itself). And I can't think > > that OTP tests written using pytest will be maintainable in any regard; > > not when such small changes can cause such hard to find bugs. > > > > Now, it may be possible that I have just missed something obvious. If I > > have, forgive me this rant. But I've spent a lot of time reading docs > > and I haven't seen any obvious solutions to these problems. > > > > Nathaniel > From simo at redhat.com Mon Dec 8 14:17:08 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 8 Dec 2014 09:17:08 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54847152.3030209@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <54847152.3030209@redhat.com> Message-ID: <20141208091708.414ef1ed@willson.usersys.redhat.com> On Sun, 07 Dec 2014 10:25:06 -0500 Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 04 Dec 2014 14:33:09 +0100 > > Ludwig Krispenz wrote: > > > >> hi, > >> > >> I just have another (hopefully this will end soon) issue I want to > >> get your input. (please read to teh end first) > >> > >> To recapture the conditions: > >> - the topology plugin manages the connections between servers as > >> segments in the shared tree > >> - it is authoritative for managed servers, eg it controls all > >> connections between servers listed under cn=masters, > >> it is permissive for connection to other servers > >> - it rejects any removal of a segment, which would disconnect the > >> topology. > >> - a change in topology can be applied to any server in the > >> topology, it will reach the respective servers and the plugin will > >> act upon it > >> > >> Now there is a special case, causing a bit of trouble. If a replica > >> is to be removed from the topology, this means that > >> the replication agreements from and to this replica should be > >> removed, the server should be removed from the manages servers. > >> The problem is that: > >> - if you remove the server first, the server becomes unmanaged and > >> removal of the segment will not trigger a removal of the > >> replication agreement > > I had another, sort of unrelated thought about this, thinking about > deleting servers. > > What happens if a replication conflict entry gets added? This would happen in case a provisioning system tries to instantiate 2 servers with the same name at the same time talking to different existing masters. > While both exist I imagine that the actual agreement would reflect > whichever entry is processed last. Probably not the end of the world. > > But how do you remove the conflict entry without also potentially > deleting that master? It should probably delete both, the domain would be pretty messed up anyone and we have no easy way to know which of the 2 is part of the domain and which one has all replication severed due to their keys being overwritten by the other server ones. I guess the only thing we can reasonably do is to make recommendations on how to deal with replicas deployments to avoid this case and instructions on how to remove remnants entries if any. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Dec 9 07:48:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Dec 2014 08:48:29 +0100 Subject: [Freeipa-devel] Heads up: Samba considering port to Python 3 In-Reply-To: <54859116.3030405@redhat.com> References: <54859116.3030405@redhat.com> Message-ID: <5486A94D.6000008@redhat.com> On 12/08/2014 12:52 PM, Petr Viktorin wrote: > Hello, > I'm slowly starting the work to port Samba's bindings to Python 3, and since > FreeIPA depends on them, this is relevant here. > > Currently the consensus on the Samba list seems to be that support for Python 2 > will be dropped shortly after the port. If that happens in Samba 4.3, this > would give us about a year to port FreeIPA and all its dependencies. > > Keep in mind that this is a very early heads-up. Samba build infrastructure > improvements seem inevitable, and if the needed changes end up trivial enough, > perhaps Samba can reconsider supporting both Python versions for some longer time. > FYI, related discussion: https://lists.samba.org/archive/samba-technical/2014-December/104223.html Martin From dkupka at redhat.com Tue Dec 9 08:51:19 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 09 Dec 2014 09:51:19 +0100 Subject: [Freeipa-devel] [PATCH 0162] Upgrade fix: masking named service should be executed only once In-Reply-To: <54819DF0.90601@redhat.com> References: <54635609.3010601@redhat.com> <54817978.5020506@redhat.com> <54819DF0.90601@redhat.com> Message-ID: <5486B807.8070402@redhat.com> On 12/05/2014 12:58 PM, Martin Basti wrote: > On 05/12/14 10:23, David Kupka wrote: >> On 11/12/2014 01:43 PM, Martin Basti wrote: >>> Hello, >>> >>> masking named service is executed more than once, following patch >>> fixes it. >>> >>> Patch attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Works as expected but: >> >> 0) mask_named_regular() returns True, False and None. None evaluates >> as False so why not use False directly? >> 1) missing link to ticket in commit message. >> >> > Updated patch attached > Works for me, ACK. -- David Kupka From pviktori at redhat.com Tue Dec 9 09:39:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Dec 2014 10:39:39 +0100 Subject: [Freeipa-devel] [RANT] pytest fixture scope is braindead In-Reply-To: <1418048110.2578.19.camel@redhat.com> References: <1417819891.3111.64.camel@redhat.com> <54858B1F.2020402@redhat.com> <1418048110.2578.19.camel@redhat.com> Message-ID: <5486C35B.5070102@redhat.com> On 12/08/2014 03:15 PM, Nathaniel McCallum wrote: > On Mon, 2014-12-08 at 12:27 +0100, Petr Viktorin wrote: >> On 12/05/2014 11:51 PM, Nathaniel McCallum wrote: >>> So I've been working this week on porting the OTP tests that were >>> manually coded to the new pytest framework. Now, I'm the first to want >>> better tooling to make our job easier. But, pytest? Meh. I'm having to >>> write just as much code (or more) to get my tests on par with pytest, >>> and they are riddled with subtle bugs. >> >> Hi, >> Yeah, IPA runs into specific situations that are very different from how >> tests usually work in other projects. > > Yeah, this I get. > >> And you took one of the harder cases. >> IPA's existing tests also don't really follow best practices ? they >> pretty much assume you run the whole test suite, or at least the whole >> module, so selecting individual tests is currently not reliable. On the >> other hand, this assumption made some things easy to code ? like >> complicated ordering and setup/teardown. > > I think this is pretty much a red herring. It isn't so much about setup > and teardown but about mutually exclusive parameterization. It is a poor > assumption on the part of pytest that the lifecycles of parameters > overlap. At the least, an option should be provided to control this. > >> One thing we want to do during the move to pytest is to have the tests >> be more independent of the current state of the database, and also of >> each other. > > Sure, this is a fine goal. Unless of course you want to test the > functionality of the code against all possible database states. I think > pretty much every xmlrpc test will have some component of this. > >> If certain assertions only make sense in a specific order, either put >> them in the same test*, or write additional code that explicitly handles >> dependencies and ordering. (Sorry, that's the price to pay for isolated >> tests ? I don't see a way around it.) > > In an ideal world, we define a test and all possible parameters to that > test and allow the running of that test independently by choosing from > the proscribed inputs. This all works fine so long as you specify a way > to indicate when inputs are mutually exclusive. Since inputs are single > valued anyway, this should be the default behavior. Unfortunately, > pytest fails on both of these counts. > >> If on the other hand the order doesn't matter ? any order of any subset >> of individual tests should pass, which is our goal ? but pytest's >> default ordering makes the suite slow, there is a hook that allows you >> to override the order: pytest_collection_modifyitems [0]. Stick it in >> the affected module (or conftest.py file for multiple modules, or a >> plugin for the whole suite), and sort the items explicitly. > > The problem isn't (I think) ordering but lifecycle. I think that if I > scope the fixture to the function but reorder the items, they will still > be constructed and torn down for every single function iteration. On the > other hand, if I scope the fixture for a longer lifecycle, the > parameters may not be mutually exclusive. > >> If your test depends on something not existing or being disabled, you >> should try removing/disabling it before the test, or write a fixture to >> do that. > > That's not the problem. The problem is that I can't define parameters > for a single object which sets the same variable to different values. > Such an act means the parameters are mutually exclusive. OK, I see the problem now. Pytest fixtures are meant for resources, not states of a shared object. You ran into a fairly exotic use case (which is what I feared, so I wanted to look into porting this.) I think in this case we should use using separate users for the enablement states, since user creation is not expensive. Or am I missing something else? >> * might make sense, for starters? >> [0] >> http://pytest.org/latest/plugins.html#_pytest.hookspec.pytest_collection_modifyitems >> >> >>> Most painful, is pytest.fixture(). It is a cool idea, but the scoping >>> and lifecycle is horribly broken. Here is an example: >>> >>> Here is an example. I want to create a user, enable otp in two different >>> ways, test with two different types of tokens under two different >>> authentication scenarios. This is a total of 8 tests. >>> >>> @pytest.fixture(scope="function") # This scope is default. >>> def user(request): >>> user = create_user('tuser1') >>> request.addfinalizer(lambda: delete_user('tuser1')) >>> return user >>> >>> @pytest.fixture(params=["per-user", "global"]) >>> def enablement(request, user): >>> output = enable(user, request.param) >>> request.addfinalizer(lambda: disable(user)) >>> return output >>> >>> @pytest.fixture(params=[{'type': 'HOTP'}, {'disabled': True}]) >>> def token(request, user, enablement): >>> output = create_token(request.param) >>> request.addfinalizer(lambda: delete_token(output.id)) >>> return output >>> >>> @pytest.mark.parametrize("opts", [foo, bar]) >>> def test_authentication(user, token, opts): >>> return auth(user.uid, token.code(), opts) >>> >>> Because the default scope is "function", a new user is created for every >>> single run of token. This is *way* more work than necessary, and leads >>> to slow runtimes. Fortunately, we can fix this by changing the scope of >>> the user fixture to "module". In this case, only one user will be >>> created per module. So far so good. >>> >>> The enablement scope is still "function", so it will still be called >>> eight times (#tokens * #enablements * #opts). Now, this is a problem >>> because (let's say) enablement takes a long time to switch tests. Here >>> is problem #1 with pytest: it presumes that all variants of fixtures >>> should be grouped by test parameters. This is a bad assumption. It may >>> make sense in some cases, but there is no way to change it. >>> >>> Now, we can work around this problem just like with the user fixture: >>> change the scope to "module". Unfortunately, we've just caused a second >>> bug. Now, enablement() will only be run twice; but the finalizer will >>> not be called until all tests are run. This means that "per-user" >>> enablement will still be active when "global" enablement runs; both will >>> be torn down simultaneously. >>> >>> This same problem arises for the token fixture: eight tokens will be >>> created and destroyed when only four are necessary. You guessed it, we >>> can fix this by changing the scope. But by doing this all four tokens >>> will be deleted simultaneously. This means we cannot test the state >>> where only a disabled token exists. >>> >>> Any attempt to use a fixture to create long-lived states (precisely what >>> fixtures are designed for) with mutually exclusive parameters is >>> extremely error prone as it is not clear which items are alive in the >>> LDAP db at any point. This leads to both long runtimes *and* extremely >>> subtle bugs in the tests that are multiplied by every layer of fixtures. >>> Call me nonplussed. >>> >>> Now, let's look at how this same test can be implemented without pytest: >>> >>> user = create_user('tuser1') >>> try: >>> for enablement in ('per-user', 'global'): >>> enable(user, enablement) >>> try: >>> for token in [{'type': 'HOTP'}, {'disabled': True}]: >>> object = create_token(token) >>> try: >>> for opt in [foo, bar]: >>> auth(user.uid, object.code(), opt) >>> finally: >>> delete_token(object.id) >>> finally: >>> disable(user) >>> finally: >>> delete_user('tuser1') >>> >>> Comparing the non-pytest implementation to the pytest one we can see a >>> few things. First, the pytest code has some nice separation of roles. >>> This is the big benefit of pytest. Second, the non-pytest implementation >>> is less code. Third, the non-pytest implementation has no subtle scoping >>> bugs: we know exactly when each database record is created and >>> destroyed. >> >> This "non-pytest" implementation is a *single test*, since it hard-codes >> dependencies and ordering. If you write it as as a single test function >> in pytest, it should look much the same, and get the >> ordering/dependencies right (except the case of the test user already >> existing). > > Which conflicts with the desired granularity; which is the whole reason > we are moving away from this model. I should be able to define, as > fixtures, a set of states required to run any one of a set of test. Then > I can choose just to run a single iteration of a set of tests and the > set of states should be assembled correctly. The problem is that, with > pytest, this all works unless the parameterized fixtures contain > mutually exclusive state values. > > So, I'm obviously not proposing that we do something like the non-pytest > implementation. What I'm pointing out is that being forced to implement > it this way in pytest negates all the benefits of pytest. > >>> I *want* to like pytest. Honestly I do. But this scoping idiocy has >>> already cost me roughly two days tracking down subtle bugs in the tests >>> (while not finding any bugs in the OTP code itself). And I can't think >>> that OTP tests written using pytest will be maintainable in any regard; >>> not when such small changes can cause such hard to find bugs. >>> >>> Now, it may be possible that I have just missed something obvious. If I >>> have, forgive me this rant. But I've spent a lot of time reading docs >>> and I haven't seen any obvious solutions to these problems. >>> >>> Nathaniel -- Petr? From mbasti at redhat.com Tue Dec 9 11:48:03 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Dec 2014 12:48:03 +0100 Subject: [Freeipa-devel] [PATCH] 795 webui: increase duration of notification messages In-Reply-To: <5481CE08.6000602@redhat.com> References: <5481CE08.6000602@redhat.com> Message-ID: <5486E173.7060002@redhat.com> On 05/12/14 16:23, Petr Vobornik wrote: > increase duration of notification messages by 66% > > https://fedorahosted.org/freeipa/ticket/4792 ACK -- Martin Basti From mbasti at redhat.com Tue Dec 9 11:48:32 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Dec 2014 12:48:32 +0100 Subject: [Freeipa-devel] [PATCH] 790 webui: fix service unprovisioning In-Reply-To: <54773A50.1000405@redhat.com> References: <54773A50.1000405@redhat.com> Message-ID: <5486E190.6040207@redhat.com> On 27/11/14 15:50, Petr Vobornik wrote: > Missed part of field refactoring caused that service could not be > unprovisioned. > > https://fedorahosted.org/freeipa/ticket/4770 > > For regression tests I've opened ticket: > https://fedorahosted.org/freeipa/ticket/4772 ACK, works for me now -- Martin Basti From pvoborni at redhat.com Tue Dec 9 11:56:49 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Dec 2014 12:56:49 +0100 Subject: [Freeipa-devel] [PATCH] 790 webui: fix service unprovisioning In-Reply-To: <5486E190.6040207@redhat.com> References: <54773A50.1000405@redhat.com> <5486E190.6040207@redhat.com> Message-ID: <5486E381.4010509@redhat.com> On 12/09/2014 12:48 PM, Martin Basti wrote: > On 27/11/14 15:50, Petr Vobornik wrote: >> Missed part of field refactoring caused that service could not be >> unprovisioned. >> >> https://fedorahosted.org/freeipa/ticket/4770 >> >> For regression tests I've opened ticket: >> https://fedorahosted.org/freeipa/ticket/4772 > > ACK, works for me now > Pushed to: master: edddb4fb2ebad5963275b4b1910d88878e0ad774 ipa-4-1: d1cc285adf594edd4afda033f4a0e1ed35b82f95 -- Petr Vobornik From pvoborni at redhat.com Tue Dec 9 12:00:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Dec 2014 13:00:05 +0100 Subject: [Freeipa-devel] [PATCH] 795 webui: increase duration of notification messages In-Reply-To: <5486E173.7060002@redhat.com> References: <5481CE08.6000602@redhat.com> <5486E173.7060002@redhat.com> Message-ID: <5486E445.2080305@redhat.com> On 12/09/2014 12:48 PM, Martin Basti wrote: > On 05/12/14 16:23, Petr Vobornik wrote: >> increase duration of notification messages by 66% >> >> https://fedorahosted.org/freeipa/ticket/4792 > ACK > Pushed to: master: e4f014dfa01e8b37c6b196310f7cca18ca4b5400 ipa-4-1: 88ab70b053f12bee81c53c534f546890d38015e9 -- Petr Vobornik From dkupka at redhat.com Tue Dec 9 12:03:55 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 09 Dec 2014 13:03:55 +0100 Subject: [Freeipa-devel] [PATCH] 382 Fix automatic CA cert renewal endless loop in dogtag-ipa-ca-renew-agent In-Reply-To: <54800C30.7010306@redhat.com> References: <54800C30.7010306@redhat.com> Message-ID: <5486E52B.6010701@redhat.com> On 12/04/2014 08:24 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From dkupka at redhat.com Tue Dec 9 12:03:58 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 09 Dec 2014 13:03:58 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54801CF6.7080809@redhat.com> References: <54801CF6.7080809@redhat.com> Message-ID: <5486E52E.4020008@redhat.com> On 12/04/2014 09:36 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From dkupka at redhat.com Tue Dec 9 12:04:02 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 09 Dec 2014 13:04:02 +0100 Subject: [Freeipa-devel] [PATCH] 384 Do not renew the IPA CA cert by serial number in dogtag-ipa-ca-renew-agent In-Reply-To: <54818947.4070801@redhat.com> References: <54818947.4070801@redhat.com> Message-ID: <5486E532.1030309@redhat.com> On 12/05/2014 11:30 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From pvoborni at redhat.com Tue Dec 9 12:05:07 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Dec 2014 13:05:07 +0100 Subject: [Freeipa-devel] [PATCH 0162] Upgrade fix: masking named service should be executed only once In-Reply-To: <5486B807.8070402@redhat.com> References: <54635609.3010601@redhat.com> <54817978.5020506@redhat.com> <54819DF0.90601@redhat.com> <5486B807.8070402@redhat.com> Message-ID: <5486E573.1040707@redhat.com> On 12/09/2014 09:51 AM, David Kupka wrote: > On 12/05/2014 12:58 PM, Martin Basti wrote: >> On 05/12/14 10:23, David Kupka wrote: >>> On 11/12/2014 01:43 PM, Martin Basti wrote: >>>> Hello, >>>> >>>> masking named service is executed more than once, following patch >>>> fixes it. >>>> >>>> Patch attached. >>>> >>>> >>> Works as expected but: >>> >>> 0) mask_named_regular() returns True, False and None. None evaluates >>> as False so why not use False directly? >>> 1) missing link to ticket in commit message. >>> >>> >> Updated patch attached >> > Works for me, ACK. > Pushed to: master: 29ff2868cde9f80eda62d50c0d5fc2c22541faf1 ipa-4-1: b13f764b3c355576692e558299d17e8ea8819834 -- Petr Vobornik From pvoborni at redhat.com Tue Dec 9 12:07:40 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Dec 2014 13:07:40 +0100 Subject: [Freeipa-devel] [PATCH] 382 Fix automatic CA cert renewal endless loop in dogtag-ipa-ca-renew-agent In-Reply-To: <5486E52B.6010701@redhat.com> References: <54800C30.7010306@redhat.com> <5486E52B.6010701@redhat.com> Message-ID: <5486E60C.8010105@redhat.com> On 12/09/2014 01:03 PM, David Kupka wrote: > On 12/04/2014 08:24 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> > Works for me, ACK. > Pushed to: master: 423c3e8f34d6ae6655c3b82c4e5a18caf1e63a49 ipa-4-1: 9bfb16c22043d714b8227567600f94345c40cad6 -- Petr Vobornik From pvoborni at redhat.com Tue Dec 9 12:17:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Dec 2014 13:17:21 +0100 Subject: [Freeipa-devel] [PATCH] 384 Do not renew the IPA CA cert by serial number in dogtag-ipa-ca-renew-agent In-Reply-To: <5486E532.1030309@redhat.com> References: <54818947.4070801@redhat.com> <5486E532.1030309@redhat.com> Message-ID: <5486E851.5010302@redhat.com> On 12/09/2014 01:04 PM, David Kupka wrote: > On 12/05/2014 11:30 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> > Works for me, ACK. > Pushed to: master: 1f6fff2b5aea7f92e3321870ea59661b127ab50a ipa-4-1: 7f1db9303e14fc7b3f505cf63d21544197ea6047 -- Petr Vobornik From mkosek at redhat.com Tue Dec 9 12:33:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Dec 2014 13:33:03 +0100 Subject: [Freeipa-devel] ds-migrate feature enhancements In-Reply-To: References: <5475B0D5.10308@redhat.com> <54804CBE.4000501@redhat.com> Message-ID: <5486EBFF.3060800@redhat.com> On 12/05/2014 12:32 AM, Alan Evans wrote: > Hello Martin, > > I have spent some time looking into how to address > https://fedorahosted.org/freeipa/ticket/3709. I thought I would look at > --setattr --addattr from user-add and others to see if I could reuse code > for --user-attr-default. At least for parsing the commandline arguments > anyway. It does not look like it would be easy to re-purpose the code in > _convert_2_dict() from ipalib/plugins/baseldap.py (without blatantly > copying it). What are your thoughts about creating a Dict paramater type > in ipalib/parameters.py to to user for --setaddr --addattr --delattr and to > use for --user-attr-default? Ah, I did not expect any integration with the standard baseldap.py --*attr functions at all. Though reusing _convert_2_dict sounds as a good idea! > Also I was looking at string.Template() vs string.Formatter(). I think > string.Template is probably sufficient. But I don't follow PEPs so I don't > know if that's Python3 future proof or not. Thoughts? You do not need to worry with Python3 at this moment too much, string.Template is already used by FreeIPA anyway. > # Pseudocode > (attr, default) = args['userdefaultattr'][0].split('=',2) > entry_attrs[attr] = default.safe_substitute(entry_attrs.toDict()) > > In looking at ipalib/plugins/baseldap.py, I was wondering if It might make > sense to make migrate more in line with the --*attr paramaters. > > Consider: > ipa migrate-ds --user-delattr ou > > Instead of: > ipa-migrate-ds --user-ignore-attribute ou Hm, I would be afraid that you would get into a too much complexity if you try to integrate the new functionality which was supposed to be rather simple with *attr parameters processed process_attr_options that even do LDAP search do process the merge the *attr options with existing LDAP entry. You do not need to worry about that, you always work only on top of the migrated user entry that you have available. That simplifies the processing a lot. > Then we could also add user-{setattr,addattr,delattr,attrdefault} like: > ipa migrate-ds --user-attrdefault "mail=$uid at example.com" --user-setattr > "cn=$givenname $sn" --user-addattr description="Migrated $(date)" > --user-delattr ou > Which would add a mail address if one wasn't present, replace the CN with > the first and last name, add a description attribute and get rid of the ou > attribute. This functionality may make sense as an extension, eventually. Currently, we have nothing so even having --user-attr-default and --user-attr-set would go a long way. > Another thought I had was about the behaivor of the search on the source > directory. Currently one provides --{user,group}-continer and > --{user,group}-objectclass and the scope is statically defined in the > script. > > > --{user,group}-filter > -------------------------- > > What about adding --{user,group}-scope ONE|SUB? This is actually a very good idea and a valid option to add! We even have a ticket in the FreeIPA Trac that no one brave enough took so far. https://fedorahosted.org/freeipa/ticket/2547 If you decide to contribute this one, I would recommend doing in a separate patch from your template work as it is parallel effort and would make the review easier. > > My directory for example is like: > > dn: uid=me,ou=ops,ou=people,dc=example,dc=com > dn: uid=joe,ou=eng,ou=people,dc=example,dc=com > > So currently I have to use the --continue switch and change my > --user-container to get all of my users. If the scope weren't limited to > ONELEVEL then I could get everyone in one pass. > > ipa migrate-ds --user-container ou=People,dc=example,dc=com --user-scope SUB This makes a lot of sense, +1 for adding the switches (should be very easy to implement) > Lastly I was thinking that --user-objectclass and --exclude-users could be > made more powerful with --user-filter > > ipa migrate-ds --user-container ou=People,dc=example,dc=com > --user-objectclass posixAccount --user-filter '(!(loginShell=/bin/false))' > or we could fire all of sales --user-filter '(!(ou=Sales))' > > Which gets concatenated internally in the search to > "(&(objectClass=posixAccount)(!(loginShell=/bin/false)))" Another great idea. Currently we only create automated filter in def construct_filter(template, oc_list): oc_subfilter = ''.join([ '(objectclass=%s)' % oc for oc in oc_list]) return template % oc_subfilter based on objectclass. Your proposal would make it much more flexible. This one is also completely parallel so it should be in a separate patch compared to the template work. I am really looking forward to your patches! :-) > On Thu, Dec 4, 2014 at 4:59 AM, Martin Kosek wrote: > >> On 11/26/2014 11:52 AM, Martin Kosek wrote: >>> On 11/24/2014 11:24 PM, Alan Evans wrote: >>>> I am in the midst of preparing for a migration from OpenLDAP to FreeIPA. >>>> ds-migrate wasn't going to fill all of my needs so I thought I would >> use it >>>> for most and then make up some LDIF's and massage them to do the last >> bit >>>> of migration. >>>> >>>> I have instead decided to extend ds-migrate and I think that my features >>>> might be of use to others so I would like to contribute them. >>> >>> Great idea! :-) IMO, enhancing FreeIPA migration capability and making >> it more >>> even more pleasant experience for user users is a good goal. >>> >>>> Before I get >>>> too for I wanted to get some input from the community. >>>> >>>> Here are MY original goals: >>>> * Migrate ssh public keys >>>> The openssh-lpk schema is used in my tree so objectClass: >> ldapPublicKey >>>> attribute: sshPublicKey >>>> * Migrate disabled accounts as disabled >>>> We 'disable' usere by setting their shadowExpire to a date in the past >>>> and setting their shell to /bin/false >>>> >>>> I realized that the ssh-public key problem is more generally an >> attribute >>>> mapping problem and dealing with disabled users could be more >> generalized >>>> too. >>>> >>>> Here are instead the new features I would provide. >>>> >>>> * Attribute mapping >>>> Feature should check the new syntax exists and is the same as the old >>>> syntax (perhaps further check for compatible syntax) >>>> --user-attribute-map=oldAttribute=newAttribute >>>> --group-attribute-map=foo=bar >>>> Should I drop user/group and just make it --attribute-map and apply >> it to >>>> both? >>>> Should certain attributes be mapped by default, i.e. >>>> sshPublicKey=ipaSSHPubKey (this means we also need to ignore the >>>> objectClass ldapPublicKey by default) Maybe make a separate switch >>>> --with-ssh-keys that automatically adds a map and an ignore? >>> >>> If the mapping sshPublicKey -> ipaSSHPubKey is clear, I would do it by >> default >>> and maybe add a switch to skip these advanced migrations. Just make sure >> the >>> expected format matches (ipa requires all 3 pieces of the public key, >> not just >>> the blob) >>> >>> I think it would be very useful to combine user attribute mapping with >> the >>> ideas from >>> >>> https://fedorahosted.org/freeipa/ticket/3709 >>> >>> i.e. filling attribute with values from original entry or a default. >> This may >>> lead to following syntax: >>> >>> --user-attribute-default "sn=notdefined" --user-attribute-default >>> "description=User with cn $cn" >>> >>> which would only use the pattern if attribute is not defined in original >> entry >>> >>> and >>> >>> --user-attribute-map "sn=$cn" >>> >>> which would fill overwrite the attribute even if it was defined in the >> original >>> entry. >>> >>>> >>>> * Handling disabled users >>>> 1. How to identify disabled users? >>>> a. shadowExpire < now() >>>> --use-disable-shadow-expire >>> >>> How would you like to disable users then? With nsAccountLock attribute? >>> Wouldn't it be better to instead map shadowExpire to >> krbPrincipalExpiration >>> attribute which should have sematically the same meaning? >>> >>>> b. loginShell is one of configurable shells >>>> --use-disable-login-shell >>>> --disabled-shell=/bin/false --disabled-shell=/sbin/nologin >> (these >>> >>> Is this really a general mechanism? I think Kerberos principal >> expiration is >>> the way to go: >>> >>> # ipa user-mod fbar --principal-expiration 20140101000000Z >>> >>> # ssh fbar@`hostname` >>> fbar at vm-067.idm.lab.bos.redhat.com's password: >>> Permission denied, please try again. >>> >>> # tail /var/log/krb5kdc.log >>> ... >>> Nov 26 04:56:51 vm-067.idm.lab.bos.redhat.com krb5kdc[19615](info): >> AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 10.16.78.67: CLIENT EXPIRED: >>> fbar at IDM.LAB.BOS.REDHAT.COM for >>> krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM, Client's entry in >>> database has expired >>> >>> It is respected by Kerberos authentication and SSSD logins, at minimum. >>> >>> >>>> two would be the defaults) >>>> c. nsAccountLocked (though that would be straight copied by the >>>> migrator anyway >>> >>> +1 for copying. >>> >>>> d. From Open DJ the attribute ds-pwp-account-disabled can be used to >>>> identify disabled users >>>> (are there others?) >>>> 2. What do do with disabled users (in my case migrate and disable) >>>> a. Migrate them and don't touch nsAccountLocked >>>> b. Migrate them and set nsAccountLocked = true >>>> --disable-users >>>> c. Do not migrate them >>>> --skip-disabled-users >>>> d. Which is the default? Migrate and disable? If so which are the >>>> default methods for identifying them? All methods? >>> >>> I may be missing something, but to me following would make sense: >>> >>> - properly migrate and fill krbPrincipalExpiration and nsACcountLock >> attributes >>> - optionally implement --skip-disabled-users. Though it may be >> challenging to >>> implement the "is_user_disabled" function right so that it works on all >> sort of >>> DS schemes. >>> >>>> So is there anything I'm missing? Any suggestions on the switches? I'm >> not >>>> entirely sure I like them the way they are. >>>> >>>> I have code to cover about 60% of the above already. The user-attr-map >>>> feature is working and the --disabled-users and disabled-shells options >> are >>>> working. >>>> >>>> Regards, >>>> -Alan >> >> Hello Alan, >> >> Are there any updates in this noble effort? Are you stuck? Can I or the >> team >> help you in any way? >> >> Thanks, >> Martin >> > From mkosek at redhat.com Tue Dec 9 12:40:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Dec 2014 13:40:17 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <547F348E.3090401@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> Message-ID: <5486EDB1.50500@redhat.com> On 12/03/2014 05:04 PM, Petr Spacek wrote: > On 2.12.2014 17:21, Simo Sorce wrote: >> On Tue, 02 Dec 2014 15:56:28 +0100 >> Petr Spacek wrote: >> >>> On 1.12.2014 17:12, Simo Sorce wrote: >>>> On Mon, 01 Dec 2014 16:17:54 +0100 >>>> Petr Spacek wrote: >>>> >>>>> On 14.11.2014 17:31, Petr Spacek wrote: >>>>>> On 14.11.2014 02:22, Simo Sorce wrote: >>>>>>> On Tue, 11 Nov 2014 16:29:51 +0100 >>>>>>> Petr Spacek wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> this thread is about RFE >>>>>>>> "IPA servers when installed should register themselves in the >>>>>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >>>>>>>> >>>>>>>> It is not a complete design, just a raw idea. >>>>>>>> >>>>>>>> >>>>>>>> Use case >>>>>>>> ======== >>>>>>>> FreeIPA installation to a network with existing DNS >>>>>>>> infrastructure + network administrator who is not willing to >>>>>>>> add/maintain new DNS servers "just for FreeIPA". >>>>>>>> >>>>>>>> >>>>>>>> High-level idea >>>>>>>> =============== >>>>>>>> - Transform dns* commands from FreeIPA framework to equivalent >>>>>>>> "nsupdate" commands and send DNS updates to existing DNS >>>>>>>> servers. >>>>>>>> - Provide necessary encryption/signing keys to nsupdate. >>>>>>>> >>>>>>>> >>>>>>>> 1) Integration to FreeIPA framework >>>>>>>> =================================== >>>>>>>> First of all, we need to decide if "external DNS integration" >>>>>>>> can be used at the same time with FreeIPA-integrated DNS or not. >>>>>>>> Side-question is what to do if a first server is installed with >>>>>>>> external-DNS but another replica is being installed with >>>>>>>> integrated-DNS and so on. >>>>>>> >>>>>>> I think being able to integrate with an external DNS is >>>>>>> important, and not just at the server level, being able to >>>>>>> distribute TSIG keys to client would be nice too, though a lot >>>>>>> less important, than getting server integration.. >>>>>> >>>>>> Using TSIG on many clients is very problematic. Keep in mind that >>>>>> TSIG is basically HMAC computed using symmetric key so: >>>>>> a) Every client would have to use the same key - this is a >>>>>> security nightmare. b) We would have to distribute and maintain >>>>>> many keys for many^2 clients, which is an administrative >>>>>> nightmare. >>>>>> >>>>>> For *clients* I would rather stay with GSS-TSIG which is much more >>>>>> manageable because we can use Kerberos trust and Keytab >>>>>> distribution is already solved by ipa-client-install. >>>>>> >>>>>> Alternative for clients would be to use FreeIPA server as proxy >>>>>> which encapsulates TSIG keys and issues update requests on behalf >>>>>> of clients. This would be FreeIPA-specific but any >>>>>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>>>>> >>>>>> TSIG standard explicitly says that there is no standardized >>>>>> distribution mechanism. >>>>>> >>>>>>>> In other words, the question is if current "dns.py" plugin >>>>>>>> shipped with FreeIPA framework should be: >>>>>>>> >>>>>>>> a) Extended dns.py with dnsexternal-* commands >>>>>>>> ---------------------------------------------- >>>>>>>> Disadvantages: >>>>>>>> - It complicate FreeIPA DNS interface which is a complex beast >>>>>>>> even now. >>>>>>>> - We would have add condition to every DNS API call in >>>>>>>> installers which would increase horribleness of the installer >>>>>>>> code even more (or add another layer of abstraction...). >>>>>>> >>>>>>> I agree having a special command is undesirable. >>>>>>>> >>>>>>>> - I don't see a point in using integrated-DNS with external-DNS >>>>>>>> at the same time. To use integrated-DNS you have to get a >>>>>>>> proper DNS delegation from parent domain - and if you can get >>>>>>>> the delegation then there is no point in using external DNS ... >>>>>>> >>>>>>> I disagree on this point, it makes a lot of sense to have some >>>>>>> zones maintained by IPA and ... some not. >>>>>>> >>>>>>>> Advantages: >>>>>>>> - You can use external & integrated DNS at the same time. >>>>>>> >>>>>>> We can achieve the same w/o a new ipa level command. >>>>>> >>>>>> This needs to be decided by FreeIPA framework experts ... >>>>>> >>>>>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>>>>> proxy would provide all ipa dns* commands and dispatch user-issued >>>>>> commands to appropriate FreeIPA-plugin (internal-dns or >>>>>> external-dns). This decision could depend on some values in LDAP. >>>>>> >>>>>>>> b) Replace dns.py with another implementation of current >>>>>>>> dnszone-* & dnsrecord-* API. >>>>>>>> --------------------------------------------------------------------- >>>>>>>> This seems like a cleaner approach to me. It could be shipped as >>>>>>>> ipa-server-dns-external package (opposed to "standard" >>>>>>>> ipa-server-dns package). >>>>>>>> >>>>>>>> Advantages: >>>>>>>> - It could seamlessly work with FreeIPA client installer because >>>>>>>> the dns*->nsupdate command transformation would be done on >>>>>>>> FreeIPA server and client doesn't need to know about it. >>>>>>>> - Does not require re-training/not much new documentation >>>>>>>> because commands are the same. >>>>>>>> >>>>>>>> Disadvantages: >>>>>>>> - You can't use integrated & external DNS at the same time (but >>>>>>>> I don't think it justifies the added complexity). >>>>>>> >>>>>>> I disagree. >>>>>>> >>>>>>> One of the reason to use a mix is to allow smooth migrations >>>>>>> where zones are moved into (or out of) IPA one by one. >>>>>> >>>>>> Good point, I agree. I will focus on supporting both (internal and >>>>>> external) DNS at the same time. >>>>>> >>>>>>>> Petr^3 or anyone else, what do you propose? >>>>>>> >>>>>>> I think what I'd like to see is to be able to configure a DNS >>>>>>> zone in LDAP and mark it external. >>>>>>> The zone would held the TSIG keys necessary to perform DNS >>>>>>> updates. >>>>>>> >>>>>>> When the regular ipa dnsrecord-add etc... commands are called, >>>>>>> the framework detects that the zone is "external", fewttches the >>>>>>> TSIG key (if the user has access to it) and spawn an nsupdate >>>>>>> command that will perform the update against whatever DNS server >>>>>>> is authoritative for the zone. >>>>>>> >>>>>>> Some commands may be disabled if the zone is external and >>>>>>> appropriate errors would be returned. >>>>>> >>>>>> Correct, this will be inevitable. >>>>>> >>>>>>>> 2) Authentication to external DNS server/keys >>>>>>>> ============================================= >>>>>>>> This is separate problem from FreeIPA framework integration. >>>>>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) >>>>>>>> or keytabs (for DNS GSS-TSIG) and distribute them somehow to >>>>>>>> replicas so every replica can update DNS records as necessary. >>>>>>> >>>>>>> For TSIG keys I think we should just store them in a LDAP record, >>>>>>> see above. >>>>>> >>>>>> Without any encryption? Am I missing something? >>>>>> >>>>>>> For keytabs we can simply store them just like any other >>>>>>> kerberos key if we really need it (in a trust case for example, >>>>>>> we may not need a new keytab, we may be allowed to use our own >>>>>>> credentials through the trust. So we'll need to explore a bit >>>>>>> how to properly express that in configuration. REtrieval ok >>>>>>> keytabs is then just a matter of running ipa-getkeytab -r on the >>>>>>> replica that needs it. >>>>>>> >>>>>>>> This will be the funny part because in case of AD trusts we have >>>>>>>> chicken-egg problem. You need to establish trust to get ticket >>>>>>>> for DNS/dc1.ad.example at AD principal but you can't (I guess) >>>>>>>> establish trust until proper DNS records are in place ... >>>>>>> >>>>>>> No, in this case we should create the records at trust >>>>>>> establishment time using the admin credentials we have been >>>>>>> provided. NO chicken-egg issue. >>>>>> >>>>>> Sorry, we surely *have* a chicken-egg issue because >>>>>> ipa-server-install is completely separate step from from >>>>>> ipa-adtrust-install which is completely separate from ipa >>>>>> trust-add. (And there is nothing which forces user to establish AD >>>>>> trust right after ipa-server-install finished.) >>>>>> >>>>>> Also, in some cases it is not possible to use the same credentials >>>>>> for trust establishment and for DNS updates on AD. Think about >>>>>> one-way trust or possibly two-way trust but established using >>>>>> pre-shared trust secret (which is AFAIK not usable for kinit). >>>>>> >>>>>> Alexander, could you clarify if it is possible to create an AD >>>>>> trust *without* DNS records for FreeIPA side of the trust? >>>>>> >>>>>> Another problem is that reliance on AD trusts would effectively >>>>>> prevent interoperability with non-AD DNS servers (think Infoblox >>>>>> or standard BIND). >>>>>> >>>>>> I tend to think that we will need to obtain credentials (AD >>>>>> login/pass/keytab/TSIG key) as one of ipa-server-install >>>>>> parameters so all DNS updates can be done right away. This would >>>>>> allow us have ipa-server-install script which in fact produces >>>>>> *working* FreeIPA domain. In other cases ipa-server-install would >>>>>> end but the FreeIPA domain would not be functional because of >>>>>> missing records in DNS. >>>>>> >>>>>>>> For 'experimental' phase I would go with pre-populated CCcache, >>>>>>>> i.e. admin will manually do kinit Administrator at AD and then run >>>>>>>> FreeIPA installer. >>>>>>> >>>>>>> We already to this, so there is no need to invent anything here >>>>>>> IMO. >>>>>> >>>>>> Except for cases mentioned above ... >>>>>> >>>>>>>> Maybe we can re-use trust secret somehow? I don't know, I will >>>>>>>> reach out to AD experts with questions. >>>>>>>> >>>>>>>> This area needs more research but for now it seems feasible to >>>>>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs >>>>>>>> so "only" the chicken-egg problem is left. >>>>>>>> >>>>>>>> This will need new LDAP schema but I will propose something when >>>>>>>> I'm done with investigation. >>>>>>> >>>>>>> Please let me know if you agree with a new zone type as a way to >>>>>>> "forward" updates. >>>>>> >>>>>> Generally I agree, it was my plan too. My main concern is not >>>>>> about LDAP structure but about FreeIPA framework and about >>>>>> workflow in general. It will be fun to extend the spaghetti code >>>>>> we have ... >>>>> >>>>> Ping :-) I would like to move the discussion forward. >>>>> >>>>> Alexander, could you please comment on authentication to AD >>>>> mentioned above? >>>>> >>>>> Simo and everybody else, what do you think about client use-case, >>>>> i.e. forwarding DNS updates from FreeIPA clients to external DNS >>>>> infrastructure? What about security implications (keeping in mind >>>>> that TSIG keys are symmetric)? >>>>> >>>>> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy >>>>> instead of nsupdate command (to hide TSIG key behind FreeIPA)? >>>> >>>> Remind me this, when a client tries to update the DNS, does it >>>> always contact its own DNS server first, or does it try to go >>>> straight to the authoritative DNS server? >>> >>> It should go straight to authoritative servers listed in NS records. >>> >>>> I do not like the XML-RPC->DNS approach as it requires a special >>>> client, leaving out the majority of clients. >>> >>> Yes, it is an option of last resort (because I don't see a way how to >>> be compatible with standard clients, see the point above). >>> >>>> Also, I am thinking that we only _need_ to set infrastructure >>>> relevant names (like IPA servers SRV records), but if someone >>>> decides not to use IPA for the DNS we may decide that it is not our >>>> responsibility to provide a full end-to-end client dns update >>>> solution. >>> >>> If we can agree on that then I'm fine with it. >> >> Yes the more I think of it, the more I prefer to wait in trying to >> solve the clients problem. >> >>>> So I would concentrate on making it possible for IPA *Servers* to >>>> use a private TSIG key to update infrastructure relevant names, and >>>> possibly defer the clients side of the problem. >>> >>> Speaking about native clients, two-way AD trust should nicely work >>> with clients because clients could go straight to the AD and >>> authenticate using host keytab from FreeIPA realm. It will not work >>> in other cases but it is still better than nothing. >> >> Yes, this has been accounted for. >> >>>> We could use an internal bus on the server to allow the ipa >>>> framework to use nsupdate w/o gaining direct access to the TSIG >>>> key, this way admins can use ipa dnsrecod-add and friends w/o >>>> exposing the key. >>> >>> I agree with the idea but it depends on an authorization daemon you >>> have proposed earlier (in different discussion). Do you see it as >>> reasonable goal for FreeIPA 4.2 time-span? >> >> I wouldn't say a definite no, but I am not confident we can. >> >>> If the authorization daemon is too far away, would it be okay to >>> support external DNS domains only for ipa* installers but do not >>> support it for FreeIPA users? (I.e. basically store the key in HSM >>> which is not accessible to users - that is what we do with DNSSEC >>> keys now.) >> >> Yes I think it would be fine as a first step. > > Okay, I tried to summarize current goals on: > http://www.freeipa.org/page/V4/External_DNS_integration_with_installer > > At the moment I see a first obstacle: > $ ipa-replica-manage can authenticate to LDAP servers using: > - LDAPI (when running as root) > - GSSAPI > - DM password > > The problem is that we would need to have access to TSIG keys even when using > GSSAPI and DM password authentication ... so we again need the authorization > daemon. > > > Alternatively we can use Vault for TSIG key storage and use Vault's capability > to share keys among many users. In that case we don't have problem with key > distribution nor authorization. I am not convinced we should grow Vault dependency for this functionality, it requires the whole PKI machinery to be available. Many deployments do not use it though. > Another possibility is to say that replica-deletion can be done only by root > user or that updates to external DNS are supported only when running > ipa-replica-manage as root. Why does root help? So that TSIG keys will be available on all IPA servers, regardless whether they have DNS service running or not? It would be better to have the TSIG keys available using standard FreeIPA RBAC roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I missing anything? I am also wondering that the design should be friendly to the Topology work that Ludwig is working on. I would it up to Simo to evaluate this part though. > > Other tools (ipa-*install*) should not have this problem because they are > running under the root anyway. > > Ideas are more than welcome! > From jcholast at redhat.com Tue Dec 9 12:56:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 09 Dec 2014 13:56:37 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <5481908D.2010706@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> <54818C56.6050201@redhat.com> <5481908D.2010706@redhat.com> Message-ID: <5486F185.1010300@redhat.com> Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): > Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): >> On 12/05/2014 11:34 AM, Jan Cholasta wrote: >>> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >>>> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>>>> + if x509.get_der_subject(cert, x509.DER) != der_subject: >>>>> + raise admintool.ScriptError("Subject name encoding >>>>> mismatch") >>>> >>>> I think we can expect this to be a pretty common error, given this is >>>> the default behavior of Microsoft Certificate Services. I would thus >>>> like to make the error message more juicy. >>>> >>>> We need to make sure we offer some pointers for these users or they >>>> will >>>> just blame IPA for screwing up. So, the information I wrote >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >>>> >>>> need to somehow get to the error message as a potential/likely root >>>> cause of the problem. Whether you write it in the error message itself >>>> or update the design page and just insert a link is up to you. >>>> >>>> Martin >>> >>> I would rather document this and have users read the documentation, >>> which they >>> should do anyway when something goes wrong. There are many errors in >>> IPA which >>> are common and users may blame IPA for them and I don't see what makes >>> this one >>> so special that it should require a special treatment. >> >> I saw several reasons: >> - Certificate&installation error are more common than the others and >> users are usually quite lost in what to do with them. >> - In this case, we know by 90% probability what is the root cause >> - It will block one of the main use cases for the new CA renewal tool >> and people will likely hit it as MS CAs is one of the most common CAs >> and this is it's default behavior. >> >> Giving more details in this case will not hurt us, but benefit users. So >> I still do not see the harm. > > I do not see a harm either, my point is that we should probably point > the user to documentation when *anything* in *any* script goes wrong, > not just when some arbitrarily cherry-picked error occurs. > >> >>> Anyway, I have created >>> . >>> >>> >> >> Good. Do you plan to reference the section or enhance the error message? > > I plan to reference . See the attached patch (385). > >> >> Martin > > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-385-Refer-the-user-to-freeipa.org-when-something-goes-wr.patch Type: text/x-patch Size: 1121 bytes Desc: not available URL: From dkupka at redhat.com Tue Dec 9 13:27:03 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 09 Dec 2014 14:27:03 +0100 Subject: [Freeipa-devel] [PATCH] 380 Improve validation of --instance and --backend options in ipa-restore In-Reply-To: <547C5C36.5040407@redhat.com> References: <547C5C36.5040407@redhat.com> Message-ID: <5486F8A7.5070204@redhat.com> On 12/01/2014 01:16 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From jcholast at redhat.com Tue Dec 9 13:47:02 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 09 Dec 2014 14:47:02 +0100 Subject: [Freeipa-devel] [PATCH] 380 Improve validation of --instance and --backend options in ipa-restore In-Reply-To: <5486F8A7.5070204@redhat.com> References: <547C5C36.5040407@redhat.com> <5486F8A7.5070204@redhat.com> Message-ID: <5486FD56.9030407@redhat.com> Dne 9.12.2014 v 14:27 David Kupka napsal(a): > On 12/01/2014 01:16 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Works for me, ACK. > Thanks for the review. Pushed to: master: 7b0149f32b95b42598dd30acde4d2c589ffcfce1 ipa-4-1: f92d0efca693ddcf4de0bc3413ab26c76bad6963 -- Jan Cholasta From rcritten at redhat.com Tue Dec 9 14:21:43 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Dec 2014 09:21:43 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <20141208091708.414ef1ed@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <54847152.3030209@redhat.com> <20141208091708.414ef1ed@willson.usersys.redhat.com> Message-ID: <54870577.9070304@redhat.com> Simo Sorce wrote: > On Sun, 07 Dec 2014 10:25:06 -0500 > Rob Crittenden wrote: > >> Simo Sorce wrote: >>> On Thu, 04 Dec 2014 14:33:09 +0100 >>> Ludwig Krispenz wrote: >>> >>>> hi, >>>> >>>> I just have another (hopefully this will end soon) issue I want to >>>> get your input. (please read to teh end first) >>>> >>>> To recapture the conditions: >>>> - the topology plugin manages the connections between servers as >>>> segments in the shared tree >>>> - it is authoritative for managed servers, eg it controls all >>>> connections between servers listed under cn=masters, >>>> it is permissive for connection to other servers >>>> - it rejects any removal of a segment, which would disconnect the >>>> topology. >>>> - a change in topology can be applied to any server in the >>>> topology, it will reach the respective servers and the plugin will >>>> act upon it >>>> >>>> Now there is a special case, causing a bit of trouble. If a replica >>>> is to be removed from the topology, this means that >>>> the replication agreements from and to this replica should be >>>> removed, the server should be removed from the manages servers. >>>> The problem is that: >>>> - if you remove the server first, the server becomes unmanaged and >>>> removal of the segment will not trigger a removal of the >>>> replication agreement >> >> I had another, sort of unrelated thought about this, thinking about >> deleting servers. >> >> What happens if a replication conflict entry gets added? > > This would happen in case a provisioning system tries to instantiate 2 > servers with the same name at the same time talking to different > existing masters. Sure and quite possible if there is some link down and two admins doing the same thing. > >> While both exist I imagine that the actual agreement would reflect >> whichever entry is processed last. Probably not the end of the world. >> >> But how do you remove the conflict entry without also potentially >> deleting that master? > > It should probably delete both, the domain would be pretty messed up > anyone and we have no easy way to know which of the 2 is part of the > domain and which one has all replication severed due to their keys > being overwritten by the other server ones. Yes, this is what I was leaning towards as well, but the plugin may need to specifically do this. It all depends on the search filters Ludwig uses to find the master(s) to operate on. And should this be automatically detected? So in reality the fact that there is a duplicate agreement in topology probably won't hurt anything at all since we don't really define much there. The actual agreement(s) will still be created just fine, but this extra topology record could be confusing depending on whether it gets returned by anything. > I guess the only thing we can reasonably do is to make recommendations > on how to deal with replicas deployments to avoid this case and > instructions on how to remove remnants entries if any. I brought this up in case deleting the conflict entry would create an orphan, for example. It occurs to me that perhaps the conflict entry may not actually contain anything different than the real entry. It isn't like we store a ton of data. So I wonder if one deletes a conflict entry it shouldn't trigger topology changes. But that is likely going to require extra logic. rob From npmccallum at redhat.com Tue Dec 9 14:30:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 09 Dec 2014 09:30:03 -0500 Subject: [Freeipa-devel] [RANT] pytest fixture scope is braindead In-Reply-To: <5486C35B.5070102@redhat.com> References: <1417819891.3111.64.camel@redhat.com> <54858B1F.2020402@redhat.com> <1418048110.2578.19.camel@redhat.com> <5486C35B.5070102@redhat.com> Message-ID: <1418135403.2578.45.camel@redhat.com> On Tue, 2014-12-09 at 10:39 +0100, Petr Viktorin wrote: > On 12/08/2014 03:15 PM, Nathaniel McCallum wrote: > > On Mon, 2014-12-08 at 12:27 +0100, Petr Viktorin wrote: > >> On 12/05/2014 11:51 PM, Nathaniel McCallum wrote: > >>> So I've been working this week on porting the OTP tests that were > >>> manually coded to the new pytest framework. Now, I'm the first to want > >>> better tooling to make our job easier. But, pytest? Meh. I'm having to > >>> write just as much code (or more) to get my tests on par with pytest, > >>> and they are riddled with subtle bugs. > >> > >> Hi, > >> Yeah, IPA runs into specific situations that are very different from how > >> tests usually work in other projects. > > > > Yeah, this I get. > > > >> And you took one of the harder cases. > >> IPA's existing tests also don't really follow best practices ? they > >> pretty much assume you run the whole test suite, or at least the whole > >> module, so selecting individual tests is currently not reliable. On the > >> other hand, this assumption made some things easy to code ? like > >> complicated ordering and setup/teardown. > > > > I think this is pretty much a red herring. It isn't so much about setup > > and teardown but about mutually exclusive parameterization. It is a poor > > assumption on the part of pytest that the lifecycles of parameters > > overlap. At the least, an option should be provided to control this. > > > >> One thing we want to do during the move to pytest is to have the tests > >> be more independent of the current state of the database, and also of > >> each other. > > > > Sure, this is a fine goal. Unless of course you want to test the > > functionality of the code against all possible database states. I think > > pretty much every xmlrpc test will have some component of this. > > > >> If certain assertions only make sense in a specific order, either put > >> them in the same test*, or write additional code that explicitly handles > >> dependencies and ordering. (Sorry, that's the price to pay for isolated > >> tests ? I don't see a way around it.) > > > > In an ideal world, we define a test and all possible parameters to that > > test and allow the running of that test independently by choosing from > > the proscribed inputs. This all works fine so long as you specify a way > > to indicate when inputs are mutually exclusive. Since inputs are single > > valued anyway, this should be the default behavior. Unfortunately, > > pytest fails on both of these counts. > > > >> If on the other hand the order doesn't matter ? any order of any subset > >> of individual tests should pass, which is our goal ? but pytest's > >> default ordering makes the suite slow, there is a hook that allows you > >> to override the order: pytest_collection_modifyitems [0]. Stick it in > >> the affected module (or conftest.py file for multiple modules, or a > >> plugin for the whole suite), and sort the items explicitly. > > > > The problem isn't (I think) ordering but lifecycle. I think that if I > > scope the fixture to the function but reorder the items, they will still > > be constructed and torn down for every single function iteration. On the > > other hand, if I scope the fixture for a longer lifecycle, the > > parameters may not be mutually exclusive. > > > >> If your test depends on something not existing or being disabled, you > >> should try removing/disabling it before the test, or write a fixture to > >> do that. > > > > That's not the problem. The problem is that I can't define parameters > > for a single object which sets the same variable to different values. > > Such an act means the parameters are mutually exclusive. > > OK, I see the problem now. Pytest fixtures are meant for resources, not > states of a shared object. > You ran into a fairly exotic use case (which is what I feared, so I > wanted to look into porting this.) > I think in this case we should use using separate users for the > enablement states, since user creation is not expensive. Or am I missing > something else? Yes, two things. First, while a single user creation isn't expensive (~5 seconds w/ IPA running on tmpfs), 360 user creations *are* (~30 minutes). This figure does not include user deletions which have a similar run-time. So I estimate creating a user for every test adds about 45 minutes to a full test run. This is entirely unnecessary. Second, there is a much worse case: global otp enablement. We can't guarantee the changes take effect without sleeping for 60 seconds on every modification (see 8b2f4443dcf61e1edf59ef0812ed05e1fa93f8fc). This means 2 minutes for every enablement/disablement cycle. This isn't a big deal if we do it once. If we do it 360 times, however... You can do the math. It isn't pretty. However, if we put this in a fixture which has module/class scope and allow the parameters to be mutually exclusive (i.e. the finalizer for the previous parameter is called immediately before construction of the next parameter) this problem goes away. > >> * might make sense, for starters? > >> [0] > >> http://pytest.org/latest/plugins.html#_pytest.hookspec.pytest_collection_modifyitems > >> > >> > >>> Most painful, is pytest.fixture(). It is a cool idea, but the scoping > >>> and lifecycle is horribly broken. Here is an example: > >>> > >>> Here is an example. I want to create a user, enable otp in two different > >>> ways, test with two different types of tokens under two different > >>> authentication scenarios. This is a total of 8 tests. > >>> > >>> @pytest.fixture(scope="function") # This scope is default. > >>> def user(request): > >>> user = create_user('tuser1') > >>> request.addfinalizer(lambda: delete_user('tuser1')) > >>> return user > >>> > >>> @pytest.fixture(params=["per-user", "global"]) > >>> def enablement(request, user): > >>> output = enable(user, request.param) > >>> request.addfinalizer(lambda: disable(user)) > >>> return output > >>> > >>> @pytest.fixture(params=[{'type': 'HOTP'}, {'disabled': True}]) > >>> def token(request, user, enablement): > >>> output = create_token(request.param) > >>> request.addfinalizer(lambda: delete_token(output.id)) > >>> return output > >>> > >>> @pytest.mark.parametrize("opts", [foo, bar]) > >>> def test_authentication(user, token, opts): > >>> return auth(user.uid, token.code(), opts) > >>> > >>> Because the default scope is "function", a new user is created for every > >>> single run of token. This is *way* more work than necessary, and leads > >>> to slow runtimes. Fortunately, we can fix this by changing the scope of > >>> the user fixture to "module". In this case, only one user will be > >>> created per module. So far so good. > >>> > >>> The enablement scope is still "function", so it will still be called > >>> eight times (#tokens * #enablements * #opts). Now, this is a problem > >>> because (let's say) enablement takes a long time to switch tests. Here > >>> is problem #1 with pytest: it presumes that all variants of fixtures > >>> should be grouped by test parameters. This is a bad assumption. It may > >>> make sense in some cases, but there is no way to change it. > >>> > >>> Now, we can work around this problem just like with the user fixture: > >>> change the scope to "module". Unfortunately, we've just caused a second > >>> bug. Now, enablement() will only be run twice; but the finalizer will > >>> not be called until all tests are run. This means that "per-user" > >>> enablement will still be active when "global" enablement runs; both will > >>> be torn down simultaneously. > >>> > >>> This same problem arises for the token fixture: eight tokens will be > >>> created and destroyed when only four are necessary. You guessed it, we > >>> can fix this by changing the scope. But by doing this all four tokens > >>> will be deleted simultaneously. This means we cannot test the state > >>> where only a disabled token exists. > >>> > >>> Any attempt to use a fixture to create long-lived states (precisely what > >>> fixtures are designed for) with mutually exclusive parameters is > >>> extremely error prone as it is not clear which items are alive in the > >>> LDAP db at any point. This leads to both long runtimes *and* extremely > >>> subtle bugs in the tests that are multiplied by every layer of fixtures. > >>> Call me nonplussed. > >>> > >>> Now, let's look at how this same test can be implemented without pytest: > >>> > >>> user = create_user('tuser1') > >>> try: > >>> for enablement in ('per-user', 'global'): > >>> enable(user, enablement) > >>> try: > >>> for token in [{'type': 'HOTP'}, {'disabled': True}]: > >>> object = create_token(token) > >>> try: > >>> for opt in [foo, bar]: > >>> auth(user.uid, object.code(), opt) > >>> finally: > >>> delete_token(object.id) > >>> finally: > >>> disable(user) > >>> finally: > >>> delete_user('tuser1') > >>> > >>> Comparing the non-pytest implementation to the pytest one we can see a > >>> few things. First, the pytest code has some nice separation of roles. > >>> This is the big benefit of pytest. Second, the non-pytest implementation > >>> is less code. Third, the non-pytest implementation has no subtle scoping > >>> bugs: we know exactly when each database record is created and > >>> destroyed. > >> > >> This "non-pytest" implementation is a *single test*, since it hard-codes > >> dependencies and ordering. If you write it as as a single test function > >> in pytest, it should look much the same, and get the > >> ordering/dependencies right (except the case of the test user already > >> existing). > > > > Which conflicts with the desired granularity; which is the whole reason > > we are moving away from this model. I should be able to define, as > > fixtures, a set of states required to run any one of a set of test. Then > > I can choose just to run a single iteration of a set of tests and the > > set of states should be assembled correctly. The problem is that, with > > pytest, this all works unless the parameterized fixtures contain > > mutually exclusive state values. > > > > So, I'm obviously not proposing that we do something like the non-pytest > > implementation. What I'm pointing out is that being forced to implement > > it this way in pytest negates all the benefits of pytest. > > > >>> I *want* to like pytest. Honestly I do. But this scoping idiocy has > >>> already cost me roughly two days tracking down subtle bugs in the tests > >>> (while not finding any bugs in the OTP code itself). And I can't think > >>> that OTP tests written using pytest will be maintainable in any regard; > >>> not when such small changes can cause such hard to find bugs. > >>> > >>> Now, it may be possible that I have just missed something obvious. If I > >>> have, forgive me this rant. But I've spent a lot of time reading docs > >>> and I haven't seen any obvious solutions to these problems. > >>> > >>> Nathaniel > From simo at redhat.com Tue Dec 9 14:30:27 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 9 Dec 2014 09:30:27 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <54870577.9070304@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <54847152.3030209@redhat.com> <20141208091708.414ef1ed@willson.usersys.redhat.com> <54870577.9070304@redhat.com> Message-ID: <20141209093027.5bd6a31e@willson.usersys.redhat.com> On Tue, 09 Dec 2014 09:21:43 -0500 Rob Crittenden wrote: > Simo Sorce wrote: > > On Sun, 07 Dec 2014 10:25:06 -0500 > > Rob Crittenden wrote: > > > >> Simo Sorce wrote: > >>> On Thu, 04 Dec 2014 14:33:09 +0100 > >>> Ludwig Krispenz wrote: > >>> > >>>> hi, > >>>> > >>>> I just have another (hopefully this will end soon) issue I want > >>>> to get your input. (please read to teh end first) > >>>> > >>>> To recapture the conditions: > >>>> - the topology plugin manages the connections between servers > >>>> as segments in the shared tree > >>>> - it is authoritative for managed servers, eg it controls all > >>>> connections between servers listed under cn=masters, > >>>> it is permissive for connection to other servers > >>>> - it rejects any removal of a segment, which would disconnect the > >>>> topology. > >>>> - a change in topology can be applied to any server in the > >>>> topology, it will reach the respective servers and the plugin > >>>> will act upon it > >>>> > >>>> Now there is a special case, causing a bit of trouble. If a > >>>> replica is to be removed from the topology, this means that > >>>> the replication agreements from and to this replica should be > >>>> removed, the server should be removed from the manages servers. > >>>> The problem is that: > >>>> - if you remove the server first, the server becomes unmanaged > >>>> and removal of the segment will not trigger a removal of the > >>>> replication agreement > >> > >> I had another, sort of unrelated thought about this, thinking about > >> deleting servers. > >> > >> What happens if a replication conflict entry gets added? > > > > This would happen in case a provisioning system tries to > > instantiate 2 servers with the same name at the same time talking > > to different existing masters. > > Sure and quite possible if there is some link down and two admins > doing the same thing. > > > > >> While both exist I imagine that the actual agreement would reflect > >> whichever entry is processed last. Probably not the end of the > >> world. > >> > >> But how do you remove the conflict entry without also potentially > >> deleting that master? > > > > It should probably delete both, the domain would be pretty messed up > > anyone and we have no easy way to know which of the 2 is part of the > > domain and which one has all replication severed due to their keys > > being overwritten by the other server ones. > > Yes, this is what I was leaning towards as well, but the plugin may > need to specifically do this. It all depends on the search filters > Ludwig uses to find the master(s) to operate on. And should this be > automatically detected? > > So in reality the fact that there is a duplicate agreement in topology > probably won't hurt anything at all since we don't really define much > there. The actual agreement(s) will still be created just fine, but > this extra topology record could be confusing depending on whether it > gets returned by anything. > > > I guess the only thing we can reasonably do is to make > > recommendations on how to deal with replicas deployments to avoid > > this case and instructions on how to remove remnants entries if any. > > I brought this up in case deleting the conflict entry would create an > orphan, for example. > > It occurs to me that perhaps the conflict entry may not actually > contain anything different than the real entry. It isn't like we > store a ton of data. So I wonder if one deletes a conflict entry it > shouldn't trigger topology changes. But that is likely going to > require extra logic. I think we can avoid this situation completely going forward by introducing the concept of "ephemeral replication master" (what a mouthful eh? :). The idea is that when creating a new replica the installer always determines deterministically a server among all to contact and creates the master entry there with an add operation. So if two masters try to be installed they will conflict early and one will fail. If we are in split-brain the one on the wrong side will fail to contact the master and fail. If the agreed master is down, no replicas can be installed until it is restored or removed (or maybe a force flag is used to work around it for whatever reason). I think this could work, but I am not sure how well it will mesh with the new install procedure work that promotes a normal client because then the basic host keytab will be already broken possibly. So perhaps we keep this possible plan in mind (open a ticket) ? But wait a bit to understand what we will end up with on the promotion changes side. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Tue Dec 9 14:52:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Dec 2014 15:52:10 +0100 Subject: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile In-Reply-To: References: <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> <20141203163023.GB24459@mail.corp.redhat.com> Message-ID: <54870C9A.1090803@redhat.com> On 04/12/14 14:18, Gabe Alford wrote: > Thanks for the assistance Lukas! I have an updated patch attached. > > Thanks, > > Gabe > > On Wed, Dec 3, 2014 at 9:30 AM, Lukas Slebodnik > wrote: > > On (02/12/14 21:13), Gabe Alford wrote: > >This patch removes the changelog and Makefile.am for ipaclient as > well. > > > >Thanks, > > > >Gabe > > > >On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek > wrote: > > > >> On 12/01/2014 04:25 PM, Rob Crittenden wrote: > >> > Gabe Alford wrote: > >> >> > >> >> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek > > >> >> >> wrote: > >> >> > >> >> On 11/30/2014 03:28 AM, Gabe Alford wrote: > >> >> > Ignore the last patch. Updated patch attached. > >> >> > > >> >> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford > >> >> > >> wrote: > >> >> > > >> >> >> This patch removes the app_PYTHON usage. > >> >> >> > >> >> >> Thanks, > >> >> >> > >> >> >> Gabe > >> >> >> > >> >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek > > >> >> >> > wrote: > >> >> >> > >> >> >>> Exactly, this was the message from Martin :-) I did > not test it > >> >> myself, > >> >> >>> but > >> >> >>> removing all app_PYTHON should be benign given we > use Python > >> >> setup.py > >> >> >>> packaging. > >> >> >>> > >> >> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: > >> >> >>>> Thanks guys. Sounds like it would be better to > submit a patch > >> that > >> >> >>> removes > >> >> >>>> app_PYTHON if it is considered dead code. > >> >> >>>> > >> >> >>>> Gabe > >> >> >>>> > >> >> >>>> On Thursday, November 27, 2014, Petr Spacek < > >> pspacek at redhat.com > >> >> >> > wrote: > >> >> >>>> > >> >> >>>>> On 27.11.2014 11:00, Martin Basti wrote: > >> >> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: > >> >> >>>>>>> Hello, > >> >> >>>>>>> > >> >> >>>>>>> Wondering if I could get a review. Updated patch > >> >> attached. > >> >> >>>>>>> > >> >> >>>>>>> Thanks, > >> >> >>>>>>> Gabe > >> >> >>>>>>> > >> >> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford > >> >> > > > >> >> >>>>> > >> >> >>>>>>> > >> > > >> >> >> wrote: > >> >> >>>>>>> > >> >> >>>>>>> Hello, > >> >> >>>>>>> > >> >> >>>>>>> Fix for > https://fedorahosted.org/freeipa/ticket/4700 > >> >> >>>>>>> > >> >> >>>>>>> Thanks, > >> >> >>>>>>> > >> >> >>>>>>> Gabe > >> >> >>>>>>> > >> >> >>>>>>> > >> >> >>>>>>> > >> >> >>>>>> Hello, > >> >> >>>>>> > >> >> >>>>>> sorry for late response. > >> >> >>>>>> > >> >> >>>>>> We push this ticket to backlog, as it would be > part of build > >> >> system > >> >> >>>>> refactoring. > >> >> >>>>>> The "app_PYTHON" statement is not used anymore in > IPA, the > >> better > >> >> >>>>> solution is > >> >> >>>>>> remove it, instead of keeping dead code up-to-date. > >> >> >>>>> > >> >> >>>>> Just to clarify: > >> >> >>>>> It can be pushed if it works, there is no need to > postpone > >> >> accepting > >> >> >>> patch > >> >> >>>>> if > >> >> >>>>> the patch seems okay and doesn't break anything. > >> >> >>>>> > >> >> >>>>> Martin, please keep in mind that contributions are > welcome at > >> >> any time. > >> >> >>>>> > >> >> >>>>> Milestones in Trac reflect our view of priorities > but it > >> doesn't > >> >> >>> prevent us > >> >> >>>>> from accepting correct patches from contributions > at any > >> time, no > >> >> >>> matter > >> >> >>>>> which > >> >> >>>>> priority is stated in Trac (or even if there is no > ticket for > >> >> it ...). > >> >> >>>>> > >> >> >>>>> -- > >> >> >>>>> Petr^2 Spacek > >> >> > >> >> Worked in my tests, I did not see any breakage. I guess > we can also > >> >> remove the > >> >> ipa-client/ipaclient/Makefile.am while we are at it. > >> >> > >> >> Martin > >> >> > >> >> > >> >> It looks like the ipaclient/Makefile.am is still being used. > I tried > >> >> removing it and there were errors in the build, but maybe I > am wrong? > >> > > >> > It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. > >> > > >> > Feel free to rip out the outdated hg ChangeLog stuff though. > >> > > >> > rob > >> > >> I think Gabe was asking about ipa-client/ipaclient/Makefile.am > and not > >> about > >> ipa-client/Makefile.am - we still need this one as Rob > correctly said. > >> > >> The failure that Gabe hit in build probably comes from the the > SUBDIR > >> reference > >> in ipa-client/Makefile.am file. I assume that if the reference > is removed, > >> the > >> removal should work. > >> > >> And yes, you can remove the Changelog too if you are OK with it :) > >> > >> Martin > >> > > >From d2e3176b6f6f2abb2ffbdfc198814bd1a845b876 Mon Sep 17 00:00:00 > 2001 > >From: Gabe > > >Date: Tue, 2 Dec 2014 14:43:57 -0700 > >Subject: [PATCH] Remove usage of app_PYTHON in ipaserver Makefiles > > > >https://fedorahosted.org/freeipa/ticket/4700 > >--- > > ipa-client/Makefile.am | 21 --------------------- > > ipa-client/ipaclient/Makefile.am | 17 ----------------- > > ipaserver/install/Makefile.am | 27 > --------------------------- > > ipaserver/install/plugins/Makefile.am | 24 ------------------------ > > 4 files changed, 89 deletions(-) > > delete mode 100644 ipa-client/ipaclient/Makefile.am > > delete mode 100644 ipaserver/install/Makefile.am > > delete mode 100644 ipaserver/install/plugins/Makefile.am > > > >diff --git a/ipa-client/Makefile.am b/ipa-client/Makefile.am > >index > b9c7020f3b687b3c0030ed5166625e6ef07e2fa4..f6f3168774c3024e10f626b88a8952c51c0eab90 > 100644 > >--- a/ipa-client/Makefile.am > >+++ b/ipa-client/Makefile.am > >@@ -84,7 +84,6 @@ ipa_join_LDADD = \ > > > > SUBDIRS = \ > > ../asn1 \ > >- ipaclient \ > > ipa-install \ > > man \ > > $(NULL) > >@@ -97,7 +96,6 @@ EXTRA_DIST = \ > > README \ > > HACKING \ > > NEWS \ > >- ChangeLog \ > > $(NULL) > > > > DISTCLEANFILES = \ > >@@ -125,22 +123,3 @@ MAINTAINERCLEANFILES = \ > > py-compile \ > > $(NULL) > > > >-# Creating ChangeLog from hg log (taken from cairo/Makefile.am): > >- > >-ChangeLog: $(srcdir)/ChangeLog > >- > >-$(srcdir)/ChangeLog: > >- @if test -d "$(srcdir)/../.hg"; then \ > >- (cd "$(srcdir)" && \ > >- ./missing --run hg log --verbose) | fmt --split-only > > $@.tmp \ > >- && mv -f $@.tmp $@ \ > >- || ($(RM) $@.tmp; \ > >- echo Failed to generate ChangeLog, your ChangeLog > may be outdated >&2; \ > >- (test -f $@ || echo hg log is required to generate > this file >> $@)); \ > >- else \ > >- test -f $@ || \ > >- (echo A hg checkout and hg -log is required to generate > ChangeLog >&2 && \ > >- echo A hg checkout and hg log is required to generate > this file >> $@); \ > >- fi > >- > >-.PHONY: ChangeLog $(srcdir)/ChangeLog > >diff --git a/ipa-client/ipaclient/Makefile.am > b/ipa-client/ipaclient/Makefile.am > >deleted file mode 100644 > >index > 01824b86584992fd84d4542da88395aa0e89de12..0000000000000000000000000000000000000000 > >--- a/ipa-client/ipaclient/Makefile.am > >+++ /dev/null > >@@ -1,17 +0,0 @@ > >-NULL = > >- > >-appdir = $(pythondir)/ipaclient > >-app_PYTHON = \ > >- __init__.py \ > >- ipachangeconf.py \ > >- ipadiscovery.py \ > >- ntpconf.py \ > >- ipa_certupdate.py \ > >- $(NULL) > >- > >-EXTRA_DIST = \ > >- $(NULL) > >- > >-MAINTAINERCLEANFILES = \ > >- *~ \ > >- Makefile.in > > You need to remove ipa-client/ipaclient/Makefile.am also from > AC_CONFIG_FILES > in file ipa-client/configure.ac > > > It should fix problem with autoreconf. > > LS > Sorry I can't build RPMS RPM build errors: Directory not found: /root/freeipa/rpmbuild/BUILDROOT/freeipa-4.1.2-0.fc21.x86_64/usr/lib/python2.7/site-packages/ipaclient File not found by glob: /root/freeipa/rpmbuild/BUILDROOT/freeipa-4.1.2-0.fc21.x86_64/usr/lib/python2.7/site-packages/ipaclient/*.py* Makefile:229: recipe for target 'rpms' failed The problem is, we don't have setup.py script for ipa client (just for ipaserver). I suggest to remove only Changelog from ipa-client, and let other parts of ipa-client related Makefiles untouched. Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 9 15:07:27 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Dec 2014 16:07:27 +0100 Subject: [Freeipa-devel] [PATCH 0177] Fix adding (warning) messages on client side Message-ID: <5487102F.10806@redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4793 I'm able to reproduce it only in one nose test. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0177-Fix-adding-messages-on-client-side.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: From mbasti at redhat.com Tue Dec 9 16:40:34 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 09 Dec 2014 17:40:34 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <547C9B05.5010904@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> Message-ID: <54872602.4050101@redhat.com> On 01/12/14 17:44, Petr Spacek wrote: > On 1.12.2014 14:39, Martin Basti wrote: >> On 24/11/14 17:24, Petr Spacek wrote: >>> Hello! >>> >>> Thank you for the patch. It is not ready yet but the overall direction seems >>> good. Please see my comments in-line. >>> >>> On 24.11.2014 14:35, Martin Basti wrote: >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >>>> Patch attached >>>> >>>> -- >>>> Martin Basti >>>> >>>> >>>> freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch >>>> >>>> >>>> From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001 >>>> From: Martin Basti >>>> Date: Fri, 21 Nov 2014 16:54:09 +0100 >>>> Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration >>>> >>>> Shows warning if forward and parent authoritative zone do not have >>>> proper NS record delegation, which can cause the forward zone will be >>>> ineffective and forwarding will not work. >>>> >>>> The chande in the test was required due python changes order of elemnts >>>> in dict (python doesnt guarantee an order in dict) >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >>>> --- >>>> ipalib/messages.py | 12 +++ >>>> ipalib/plugins/dns.py | 147 >>>> +++++++++++++++++++++++++++++--- >>>> ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- >>>> 3 files changed, 149 insertions(+), 12 deletions(-) >>>> >>>> diff --git a/ipalib/messages.py b/ipalib/messages.py >>>> index >>>> 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f >>>> 100644 >>>> --- a/ipalib/messages.py >>>> +++ b/ipalib/messages.py >>>> @@ -200,6 +200,18 @@ class >>>> DNSServerDoesNotSupportDNSSECWarning(PublicMessage): >>>> u"If DNSSEC validation is enabled on IPA server(s), " >>>> u"please disable it.") >>>> +class ForwardzoneIsNotEffectiveWarning(PublicMessage): >>>> + """ >>>> + **13008** Forwardzone is not effective, forwarding will not work because >>>> + there is authoritative parent zone, without proper NS delegation >>>> + """ >>>> + >>>> + errno = 13008 >>>> + type = "warning" >>>> + format = _(u"forward zone \"%(fwzone)s\" is not effective (missing >>>> proper " >>>> + u"NS delegation in authoritative zone \"%(authzone)s\"). " >>>> + u"Forwarding may not work.") >>> I think that the error message could be made mode useful: >>> >>> "Forwarding will not work. Please add NS record >>> to parent zone %(authzone)s" (or something like that). >>> >>>> + >>>> def iter_messages(variables, base): >>>> """Return a tuple with all subclasses >>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>> index >>>> c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 >>>> 100644 >>>> --- a/ipalib/plugins/dns.py >>>> +++ b/ipalib/plugins/dns.py >>>> @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): >>>> return zone >>>> +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): >>> Generally, this method finds an authoritative zone for given "fwzonename". >>> What about method name _find_auth_zone_ldap(name) ? >>> >>>> + """ >>>> + Check if forward zone is effective. >>>> + >>>> + If parent zone exists as authoritative zone, forward zone will not >>>> + forward queries. It is necessary to delegate authority of forward zone >>> I would clarify it: "forward queries by default." >>> >>> >>>> + to another server (non IPA DNS server). >>> I would personally omit "(non IPA DNS server)" because this mechanism is not >>> related to IPA domain at all. >>> >>>> + Example: >>>> + >>>> + Forward zone: sub.example.com >>>> + Zone: example.com >>>> + >>>> + Forwarding will not work, because server thinks it is authoritative >>>> + and returns NXDOMAIN >>>> + >>>> + Adding record: sub.example.com NS nameserver.out.of.ipa.domain. >>> Again, this is not related to IPA domain at all. I propose this text: >>> "Adding record: sub.example.com NS ns.sub.example.com." >>> >>>> + will delegate authority to another server, and IPA DNS server will >>>> + forward DNS queries. >>>> + >>>> + :param fwzonename: forwardzone >>>> + :return: None if effective, name of authoritative zone otherwise >>>> + """ >>>> + assert isinstance(fwzonename, DNSName) >>>> + >>>> + # get all zones >>>> + zones = api.Command.dnszone_find(pkey_only=True, >>>> + sizelimit=0)['result'] >>> Ooooh, are you serious? :-) I don't like this approach, I would rather chop >>> left-most labels from "name" and so dnszone_find() one by one. What if you >>> have many DNS zones? >>> >>> >>> This could be thrown away if you iterate only over relevant zones. >>>> + zonenames = [zone['idnsname'][0].make_absolute() for zone in zones] >>>> + zonenames.sort(reverse=True, key=len) # sort, we need longest match >>>> + >>>> + # check if is there a zone which can cause the forward zone will >>>> + # be ineffective >>>> + sub_of_auth_zone = None >>>> + for name in zonenames: >>>> + if fwzonename.is_subdomain(name): >>>> + sub_of_auth_zone = name >>>> + break >>>> + >>>> + if sub_of_auth_zone is None: >>>> + return None >>>> + >>>> + # check if forwardzone is delegated in authoritative zone >>>> + # test if exists and get NS record >>>> + try: >>>> + ns_records = api.Command.dnsrecord_show( >>>> + sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord'] >>>> + except (errors.NotFound, KeyError): >>>> + return sub_of_auth_zone >>> Note: This function should process only deepest (existing) sub-domain in LDAP >>> which is active (idnsZoneActive = TRUE). >>> >>> Example: >>> fwzonename = sub.fwd.example.com. >>> Existing LDAP master zone = fwd.example.com. - DISABLED >>> Existing LDAP master zone = example.com. >>> Existing LDAP master zone = com. >>> >>> 1) Check existence & activity of fwd.example.com. -> does not exist, continue. >>> 2) Check existence & activity of example.com. -> exists, search for NS records. >>> 3) [inner loop - searching for NS records] >>> 3a) sub.fwd.example.com. NS -> does not exist, continue inner loop. >>> 3b) fwd.example.com. NS -> does not exist, continue inner loop. >>> 3c) Inner loop ends: no more (relative) candidate names to try. >>> 4) Exit returning "example.com." - deepest authoritative super-domain of >>> sub.fwd.example.com. in LDAP. >>> >>> AFAIK content of the NS record does not matter so this check can be thrown >>> away. (Check this before doing so, please :-)) >>> >>>> + # make sure the target is not IPA DNS server >>>> + # FIXME: what if aliases are used? >>>> + normalized_ns_records = set() >>>> + for record in ns_records: >>>> + if record.endswith('.'): >>>> + normalized_ns_records.add(record) >>>> + else: >>>> + normalized_record = "%s.%s" % (record, sub_of_auth_zone) >>>> + normalized_ns_records.add(normalized_record) >>>> + >>>> + nameservers = [normalize_zone(x) for x in >>>> + api.Object.dnsrecord.get_dns_masters()] >>>> + >>>> + if any(nameserver in normalized_ns_records >>>> + for nameserver in nameservers): >>>> + # NS record is pointing to IPA DNS server >>>> + return sub_of_auth_zone >>>> + >>>> + # authoritative zone contains NS records which delegates forwardzone to >>>> + # different server, forwardzone is effective >>>> + return None >>>> + >>>> + >>>> class DNSZoneBase(LDAPObject): >>>> """ >>>> Base class for DNS Zone >>>> @@ -3164,6 +3237,29 @@ class dnsrecord(LDAPObject): >>>> dns_name = entry_name[1].derelativize(dns_domain) >>>> self.wait_for_modified_attrs(entry, dns_name, dns_domain) >>>> + def warning_if_ns_change_cause_fwzone_ineffective(self, keys, result, >>>> + options): >>>> + """after execute""" >>>> + record_name_absolute = keys[-1] >>>> + if not keys[-1].is_absolute(): >>>> + record_name_absolute = keys[-1].derelativize(keys[-2]) >>>> + >>>> + try: >>>> + api.Command.dnsforwardzone_show(record_name_absolute) >>>> + except errors.NotFound: >>>> + # no forward zone >>>> + return >>>> + >>>> + authoritative_zone = \ >>>> + _find_zone_which_makes_fw_zone_ineffective(record_name_absolute) >>>> + if authoritative_zone: >>>> + # forward zone is not effective and forwarding will not work >>>> + messages.add_message( >>>> + options['version'], result, >>>> + messages.ForwardzoneIsNotEffectiveWarning( >>>> + fwzone=record_name_absolute, authzone=authoritative_zone >>>> + ) >>>> + ) >>>> @register() >>>> @@ -3358,6 +3454,14 @@ class dnsrecord_add(LDAPCreate): >>>> return >>>> raise exc >>>> + def execute(self, *keys, **options): >>>> + result = super(dnsrecord_add, self).execute(*keys, **options) >>>> + if 'nsrecord' in options: >>>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>>> + result, >>>> + options) >>>> + return result >>>> + >>>> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >>>> assert isinstance(dn, DN) >>>> for attr in getattr(context, 'dnsrecord_precallback_attrs', []): >>>> @@ -3487,7 +3591,10 @@ class dnsrecord_mod(LDAPUpdate): >>>> if self.api.env['wait_for_dns']: >>>> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>>> - >>>> + if 'nsrecord' in options: >>>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>>> + result, >>>> + options) >>>> return result >>>> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >>>> @@ -3654,19 +3761,23 @@ class dnsrecord_del(LDAPUpdate): >>>> if self.api.env['wait_for_dns']: >>>> entries = {(keys[0], keys[1]): None} >>>> self.obj.wait_for_modified_entries(entries) >>>> - return result >>>> + else: >>>> + result = super(dnsrecord_del, self).execute(*keys, **options) >>>> + result['value'] = pkey_to_value([keys[-1]], options) >>>> - result = super(dnsrecord_del, self).execute(*keys, **options) >>>> - result['value'] = pkey_to_value([keys[-1]], options) >>>> + if getattr(context, 'del_all', False) and not \ >>>> + self.obj.is_pkey_zone_record(*keys): >>>> + result = self.obj.methods.delentry(*keys, >>>> + >>>> version=options['version']) >>>> + context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >>>> - if getattr(context, 'del_all', False) and not \ >>>> - self.obj.is_pkey_zone_record(*keys): >>>> - result = self.obj.methods.delentry(*keys, >>>> - version=options['version']) >>>> - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >>>> + if self.api.env['wait_for_dns']: >>>> + >>>> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>>> - if self.api.env['wait_for_dns']: >>>> - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>>> + if 'nsrecord' in options or options.get('del_all', False): >>>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>>> + result, >>>> + options) >>>> return result >>>> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >>>> @@ -4019,6 +4130,20 @@ class dnsforwardzone_add(DNSZoneBase_add): >>>> return dn >>>> + def execute(self, *keys, **options): >>>> + result = super(dnsforwardzone_add, self).execute(*keys, **options) >>>> + authoritative_zone = >>>> _find_zone_which_makes_fw_zone_ineffective(keys[-1]) >>>> + if authoritative_zone: >>>> + # forward zone is not effective and forwarding will not work >>>> + messages.add_message( >>>> + options['version'], result, >>>> + messages.ForwardzoneIsNotEffectiveWarning( >>>> + fwzone=keys[-1], authzone=authoritative_zone >>>> + ) >>>> + ) >>>> + >>>> + return result >>>> + >>>> @register() >>>> class dnsforwardzone_del(DNSZoneBase_del): >>>> diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py >>>> b/ipatests/test_xmlrpc/test_dns_plugin.py >>>> index >>>> fb53853147ecf663cf7015867131445f32364cfb..224a80d98273480f40fd78dea0f27e34ea36492f >>>> 100644 >>>> --- a/ipatests/test_xmlrpc/test_dns_plugin.py >>>> +++ b/ipatests/test_xmlrpc/test_dns_plugin.py >>>> @@ -1060,7 +1060,7 @@ class test_dns(Declarative): >>>> >>>> 'srv_part_target' : u'foo.bar.', >>>> >>>> 'srvrecord': [u"1 100 1234 %s" \ >>>> % >>>> zone1_ns]}), >>>> - expected=errors.ValidationError(name='srv_target', >>>> + expected=errors.ValidationError(name='srv_weight', >>>> error=u'Raw value of a DNS record was already set by ' + >>>> u'"srv_rec" option'), >>>> ), >>>> -- 1.8.3.1 >>> The same check should be done also on zone de/activation. >>> >> Updated patch attached. >> >> -- >> Martin Basti >> >> >> freeipa-mbasti-0170.2-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch > Hello, > > first of all - the code looks reasonable, I have only couple nitpicks. See below. > >> From 2a5cf557840e8f578444039326ad90c76bdfb75a Mon Sep 17 00:00:00 2001 >> From: Martin Basti >> Date: Fri, 21 Nov 2014 16:54:09 +0100 >> Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration >> >> Shows warning if forward and parent authoritative zone do not have >> proper NS record delegation, which can cause the forward zone will be >> ineffective and forwarding will not work. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >> --- >> ipalib/messages.py | 13 ++ >> ipalib/plugins/dns.py | 334 ++++++++++++++++++++++++++++++++++++++++++++++++-- >> 2 files changed, 336 insertions(+), 11 deletions(-) >> >> diff --git a/ipalib/messages.py b/ipalib/messages.py >> index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..b44beca729f5483a7241e4c98a9f724ed663e70f 100644 >> --- a/ipalib/messages.py >> +++ b/ipalib/messages.py >> @@ -200,6 +200,19 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): >> u"If DNSSEC validation is enabled on IPA server(s), " >> u"please disable it.") >> >> +class ForwardzoneIsNotEffectiveWarning(PublicMessage): >> + """ >> + **13008** Forwardzone is not effective, forwarding will not work because >> + there is authoritative parent zone, without proper NS delegation >> + """ >> + >> + errno = 13008 >> + type = "warning" >> + format = _(u"forward zone \"%(fwzone)s\" is not effective because of " >> + u"missing proper NS delegation in authoritative zone " >> + u"\"%(authzone)s\". Please add NS record " >> + u"\"%(ns_rec)s\" to parent zone \"%(authzone)s\".") >> + >> >> def iter_messages(variables, base): >> """Return a tuple with all subclasses >> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >> index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..b381dcc5e42761bb6d8d7ec35ef403c6e9b4d629 100644 >> --- a/ipalib/plugins/dns.py >> +++ b/ipalib/plugins/dns.py >> @@ -1725,6 +1725,222 @@ def _normalize_zone(zone): >> return zone >> >> >> +def _get_auth_zone_ldap(name): >> + """ >> + Find authoritative zone in LDAP for name >> + :param name: >> + :return: >> + """ >> + assert isinstance(name, DNSName) >> + ldap = api.Backend.ldap2 >> + >> + # Create all possible parent zone names >> + labels = name.make_absolute().ToASCII().split('.') > Please use python-dns interface and do not work with domain names as with strings. > >> + zone_names = ['.', ] # always add root zone >> + # decrease len by 1, we already have root zone >> + for i in xrange(len(labels) - 1): >> + zone_name_abs = '.'.join(labels[i:]) >> + zone_names.append(zone_name_abs) >> + # compatibility with IPA < 4.0, zone name can be relative >> + zone_names.append(zone_name_abs[:-1]) >> + >> + # Create filters >> + objectclass_filter = ldap.make_filter({'objectclass':'idnszone'}) >> + zonenames_filter = ldap.make_filter({'idnsname': zone_names}) >> + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) >> + complete_filter = ldap.combine_filters( >> + [objectclass_filter, zonenames_filter, zoneactive_filter], >> + rules=ldap.MATCH_ALL >> + ) >> + >> + try: >> + entries, truncated = ldap.find_entries( >> + filter=complete_filter, >> + attrs_list=['idnsname'], >> + base_dn=DN(api.env.container_dns, api.env.basedn), >> + scope=ldap.SCOPE_ONELEVEL >> + ) > What about truncated return value? It would be better to throw a exception and > optionally catch it in _warning* functions if you don't want throw fatal > errors from warning-generator. > >> + except errors.NotFound: >> + return None >> + >> + # always use absolute zones >> + matched_auth_zones = [entry.single_value['idnsname'].make_absolute() >> + for entry in entries] >> + >> + # return longest match >> + return max(matched_auth_zones, key=len) >> + >> + >> +def _get_longest_match_ns_delegation_ldap(zone, name): >> + """ >> + Finds record in LDAP which has the longest match with name. >> + >> + NOTE: does not search in zone apex, returns None if there is no NS >> + delegation outside of zone apex >> + >> + Example: >> + zone: example.com. >> + name: ns.sub.example.com. >> + >> + records: >> + extra.ns.sub.example.com. >> + sub.example.com. >> + example.com >> + >> + result: sub.example.com. >> + >> + :param zone: zone name >> + :param name: >> + :return: record name if success, or None if no such record exists, or >> + record is zone apex record >> + """ >> + assert isinstance(zone, DNSName) >> + assert isinstance(name, DNSName) >> + >> + ldap = api.Backend.ldap2 >> + >> + # get zone DN >> + zone_dn = api.Object.dnszone.get_dn(zone) >> + >> + if name.is_absolute(): >> + relative_record_name = name.relativize(zone.make_absolute()) >> + else: >> + relative_record_name = name >> + >> + # Name is zone apex >> + if relative_record_name.is_empty(): >> + return None >> + >> + relative_record_name = relative_record_name.ToASCII() > Again, please do not work with DNS names as with strings. > >> + labels = relative_record_name.split('.') >> + >> + # create list of possible record names >> + possible_record_names = ['.'.join(labels[i:]) for i in xrange(len(labels))] >> + >> + # search filters >> + name_filter = ldap.make_filter({'idnsname': [possible_record_names]}) >> + objectclass_filter = ldap.make_filter({'objectclass': 'idnsrecord'}) >> + complete_filter = ldap.combine_filters( >> + [name_filter, objectclass_filter], >> + rules=ldap.MATCH_ALL >> + ) >> + >> + try: >> + entries, truncated = ldap.find_entries( >> + filter=complete_filter, >> + attrs_list=['idnsname', 'nsrecord'], >> + base_dn=zone_dn, >> + scope=ldap.SCOPE_ONELEVEL >> + ) > What about truncated? > >> + except errors.NotFound: >> + return None >> + >> + matched_records = [] >> + >> + # test if entry contains NS records >> + for entry in entries: >> + print entry >> + if entry.get('nsrecord'): >> + matched_records.append(entry.single_value['idnsname']) >> + >> + if not matched_records: >> + return None >> + >> + # return longest match >> + return max(matched_records, key=len) >> + >> + >> +def _find_subtree_forward_zones_ldap(name, child_zones_only=False): >> + """ >> + Search for forwardzone and all child forwardzones >> + Filter: (|(*..)(.)) >> + :param name: >> + :param child_zones_only: search only for child zones >> + :return: list of zonenames, or empty list if no zone was found >> + """ >> + assert isinstance(name, DNSName) >> + ldap = api.Backend.ldap2 >> + >> + # prepare for filter "*.." >> + search_name = u".%s" % name.make_absolute().ToASCII() >> + # we need to search zone with and without last dot, due compatibility >> + # with IPA < 4.0 >> + search_names = [search_name, search_name[:-1]] >> + >> + # Create filters >> + objectclass_filter = ldap.make_filter({'objectclass':'idnsforwardzone'}) >> + zonenames_filter = ldap.make_filter({'idnsname': search_names}, exact=False, >> + trailing_wildcard=False) >> + if not child_zones_only: >> + # find also zone with exact name >> + exact_name = name.make_absolute().ToASCII() > Again, please do not work with DNS names as with strings. > >> + # we need to search zone with and without last dot, due compatibility >> + # with IPA < 4.0 >> + exact_names = [exact_name, exact_name[-1]] >> + exact_name_filter = ldap.make_filter({'idnsname': exact_names}) >> + zonenames_filter = ldap.combine_filters([zonenames_filter, >> + exact_name_filter]) >> + >> + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) >> + complete_filter = ldap.combine_filters( >> + [objectclass_filter, zonenames_filter, zoneactive_filter], >> + rules=ldap.MATCH_ALL >> + ) >> + >> + try: >> + entries, truncated = ldap.find_entries( >> + filter=complete_filter, >> + attrs_list=['idnsname'], >> + base_dn=DN(api.env.container_dns, api.env.basedn), >> + scope=ldap.SCOPE_ONELEVEL >> + ) > What about truncated? > >> + except errors.NotFound: >> + return [] >> + >> + result = [entry.single_value['idnsname'].make_absolute() >> + for entry in entries] >> + >> + return result >> + >> + >> +def _get_zone_which_makes_fw_zone_ineffective(fwzonename): >> + """ >> + Check if forward zone is effective. >> + >> + If parent zone exists as authoritative zone, the forward zone will not >> + forward queries by default. It is necessary to delegate authority >> + to forward zone with a NS record. >> + >> + Example: >> + >> + Forward zone: sub.example.com >> + Zone: example.com >> + >> + Forwarding will not work, because the server thinks it is authoritative >> + for zone and will return NXDOMAIN >> + >> + Adding record: sub.example.com NS ns.sub.example.com. >> + will delegate authority, and IPA DNS server will forward DNS queries. >> + >> + :param fwzonename: forwardzone >> + :return: None if effective, name of authoritative zone otherwise >> + """ >> + assert isinstance(fwzonename, DNSName) >> + >> + auth_zone = _get_auth_zone_ldap(fwzonename) >> + if not auth_zone: >> + return None >> + >> + delegation_record_name = _get_longest_match_ns_delegation_ldap( >> + auth_zone, fwzonename) >> + >> + if delegation_record_name: >> + return None >> + >> + return auth_zone >> + >> + >> class DNSZoneBase(LDAPObject): >> """ >> Base class for DNS Zone >> @@ -2376,6 +2592,30 @@ class dnszone(DNSZoneBase): >> ) >> ) >> >> + def _warning_fw_zone_is_not_effective(self, result, *keys, **options): >> + """ >> + Warning if any operation with zone causes, a child forward zone is >> + not effective >> + """ >> + zone = keys[-1] >> + affected_fw_zones = _find_subtree_forward_zones_ldap( >> + zone, child_zones_only=True) >> + if not affected_fw_zones: >> + return >> + >> + for fwzone in affected_fw_zones: >> + authoritative_zone = \ >> + _get_zone_which_makes_fw_zone_ineffective(fwzone) >> + if authoritative_zone: >> + # forward zone is not effective and forwarding will not work >> + messages.add_message( >> + options['version'], result, >> + messages.ForwardzoneIsNotEffectiveWarning( >> + fwzone=fwzone, authzone=authoritative_zone, >> + ns_rec=fwzone.relativize(authoritative_zone) >> + ) >> + ) >> + >> @register() >> class dnszone_add(DNSZoneBase_add): >> __doc__ = _('Create new DNS zone (SOA record).') >> @@ -2445,6 +2685,7 @@ class dnszone_add(DNSZoneBase_add): >> self.obj._warning_forwarding(result, **options) >> self.obj._warning_dnssec_experimental(result, *keys, **options) >> self.obj._warning_name_server_option(result, context, **options) >> + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) >> return result >> >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> @@ -2475,6 +2716,13 @@ class dnszone_del(DNSZoneBase_del): >> >> msg_summary = _('Deleted DNS zone "%(value)s"') >> >> + def execute(self, *keys, **options): >> + result = super(dnszone_del, self).execute(*keys, **options) >> + nkeys = keys[-1] # we can delete more zones >> + for key in nkeys: >> + self.obj._warning_fw_zone_is_not_effective(result, key, **options) >> + return result >> + >> def post_callback(self, ldap, dn, *keys, **options): >> super(dnszone_del, self).post_callback(ldap, dn, *keys, **options) >> >> @@ -2595,12 +2843,22 @@ class dnszone_disable(DNSZoneBase_disable): >> __doc__ = _('Disable DNS Zone.') >> msg_summary = _('Disabled DNS zone "%(value)s"') >> >> + def execute(self, *keys, **options): >> + result = super(dnszone_disable, self).execute(*keys, **options) >> + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) >> + return result >> + >> >> @register() >> class dnszone_enable(DNSZoneBase_enable): >> __doc__ = _('Enable DNS Zone.') >> msg_summary = _('Enabled DNS zone "%(value)s"') >> >> + def execute(self, *keys, **options): >> + result = super(dnszone_enable, self).execute(*keys, **options) >> + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) >> + return result >> + >> >> @register() >> class dnszone_add_permission(DNSZoneBase_add_permission): >> @@ -3164,6 +3422,30 @@ class dnsrecord(LDAPObject): >> dns_name = entry_name[1].derelativize(dns_domain) >> self.wait_for_modified_attrs(entry, dns_name, dns_domain) >> >> + def warning_if_ns_change_cause_fwzone_ineffective(self, result, *keys, >> + **options): >> + """after execute""" > Please add more descriptive comment to doc string. > >> + record_name_absolute = keys[-1] > a variable with zone name instead of keys[-2] would make it more readable > >> + if not keys[-1].is_absolute(): > record_name_absolute.is_absolute() would be better > >> + record_name_absolute = keys[-1].derelativize(keys[-2]) > again, please replace keys[x] with sensible names > >> + >> + affected_fw_zones = _find_subtree_forward_zones_ldap( >> + record_name_absolute) >> + if not affected_fw_zones: >> + return >> + >> + for fwzone in affected_fw_zones: > Would it be possible to generalize & use _warning_fw_zone_is_not_effective() here? > >> + authoritative_zone = \ >> + _get_zone_which_makes_fw_zone_ineffective(fwzone) >> + if authoritative_zone: >> + # forward zone is not effective and forwarding will not work >> + messages.add_message( >> + options['version'], result, >> + messages.ForwardzoneIsNotEffectiveWarning( >> + fwzone=fwzone, authzone=authoritative_zone, >> + ns_rec=fwzone.relativize(authoritative_zone) >> + ) >> + ) >> >> >> @register() >> @@ -3487,7 +3769,10 @@ class dnsrecord_mod(LDAPUpdate): >> >> if self.api.env['wait_for_dns']: >> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >> - >> + if 'nsrecord' in options: >> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, >> + *keys, >> + **options) >> return result >> >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> @@ -3654,19 +3939,23 @@ class dnsrecord_del(LDAPUpdate): >> if self.api.env['wait_for_dns']: >> entries = {(keys[0], keys[1]): None} >> self.obj.wait_for_modified_entries(entries) >> - return result >> + else: >> + result = super(dnsrecord_del, self).execute(*keys, **options) >> + result['value'] = pkey_to_value([keys[-1]], options) >> >> - result = super(dnsrecord_del, self).execute(*keys, **options) >> - result['value'] = pkey_to_value([keys[-1]], options) >> + if getattr(context, 'del_all', False) and not \ >> + self.obj.is_pkey_zone_record(*keys): >> + result = self.obj.methods.delentry(*keys, >> + version=options['version']) >> + context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >> >> - if getattr(context, 'del_all', False) and not \ >> - self.obj.is_pkey_zone_record(*keys): >> - result = self.obj.methods.delentry(*keys, >> - version=options['version']) >> - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >> + if self.api.env['wait_for_dns']: >> + self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >> >> - if self.api.env['wait_for_dns']: >> - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >> + if 'nsrecord' in options or options.get('del_all', False): >> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, >> + *keys, >> + **options) >> return result >> >> def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >> @@ -3998,6 +4287,19 @@ class dnsforwardzone(DNSZoneBase): >> # managed_permissions: permissions was apllied in dnszone class, do NOT >> # add them here, they should not be applied twice. >> >> + def _warning_fw_zone_is_not_effective(self, result, *keys, **options): >> + fwzone = keys[-1] >> + authoritative_zone = _get_zone_which_makes_fw_zone_ineffective( >> + fwzone) >> + if authoritative_zone: >> + # forward zone is not effective and forwarding will not work >> + messages.add_message( >> + options['version'], result, >> + messages.ForwardzoneIsNotEffectiveWarning( >> + fwzone=fwzone, authzone=authoritative_zone, >> + ns_rec=fwzone.relativize(authoritative_zone) >> + ) >> + ) >> >> @register() >> class dnsforwardzone_add(DNSZoneBase_add): >> @@ -4019,6 +4321,11 @@ class dnsforwardzone_add(DNSZoneBase_add): >> >> return dn >> >> + def execute(self, *keys, **options): >> + result = super(dnsforwardzone_add, self).execute(*keys, **options) >> + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) >> + return result >> + >> >> @register() >> class dnsforwardzone_del(DNSZoneBase_del): >> @@ -4083,6 +4390,11 @@ class dnsforwardzone_enable(DNSZoneBase_enable): >> __doc__ = _('Enable DNS Forward Zone.') >> msg_summary = _('Enabled DNS forward zone "%(value)s"') >> >> + def execute(self, *keys, **options): >> + result = super(dnsforwardzone_enable, self).execute(*keys, **options) >> + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) >> + return result >> + >> >> @register() >> class dnsforwardzone_add_permission(DNSZoneBase_add_permission): >> -- 1.8.3.1 > NACK > > Thank you for your patience with me ;-) > Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0170.3-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch Type: text/x-patch Size: 17775 bytes Desc: not available URL: From pviktori at redhat.com Tue Dec 9 16:42:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Dec 2014 17:42:14 +0100 Subject: [Freeipa-devel] [PATCH] 0677 test_integration: Use python-pytest-multihost In-Reply-To: <5475EF31.3060606@redhat.com> References: <5475EF31.3060606@redhat.com> Message-ID: <54872666.2080201@redhat.com> On 11/26/2014 04:18 PM, Petr Viktorin wrote: > Hello, > > I have split FreeIPA's multi-host testing infrastructure into a separate > project. It is temoprarily available at: > https://github.com/encukou/pytest-multihost > and I will move it to fedorahosted as soon as it's approved: > https://fedorahosted.org/fedora-infrastructure/ticket/4605 > RPMs for Fedora 20..rawhide and EPEL 7 are available in COPR: > https://copr.fedoraproject.org/coprs/pviktori/pytest-plugins/ > > This patch contains the necessary changes to FreeIPA. The tests > themselves are almost unchanged. FreeIPA specific parts (most > importantly, logging and environ-based configuration) are also left in. Hi Tom??! Thanks for testing the patch and finding a problem in the pytest-multihost library. It is now solved. I'm also attaching two smaller patches that fix bugs in the pytest port. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0677.2-test_integration-Use-python-pytest-multihost.patch Type: text/x-patch Size: 75445 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0678.2-test_integration-Use-collect_log-from-the-host-not-t.patch Type: text/x-patch Size: 2390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0679.2-test_integration-Parametrize-test-instead-of-using-a.patch Type: text/x-patch Size: 2006 bytes Desc: not available URL: From jcholast at redhat.com Tue Dec 9 20:40:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 09 Dec 2014 21:40:46 +0100 Subject: [Freeipa-devel] [PATCH] 793-794 Fix schema related replication issues between IPA-3-0 and IPA-4-1 In-Reply-To: <5481B441.4030401@redhat.com> References: <5481B38B.2080300@redhat.com> <5481B441.4030401@redhat.com> Message-ID: <54875E4E.8060409@redhat.com> Hi, Dne 5.12.2014 v 14:33 Petr Vobornik napsal(a): > Hello, > I've transformed Thierry's and Ludwig's findings of bz 1167964 [1] and > ticket 4794 [2] into patches. > > I wonder if the mgrpRFC822MailMember and nsViewFilter issue(patch 794) > should be solved on 389's side rather than on FreeIPA's? > > Also is the increase of nsslapd-sasl-max-buffer-size necessary? With > these two patches, replication appears to work fine for me. Tested with > F21 FreeIPA 4.1.x-GIT-something and ipa-server-3.0.0-42.el6.x86_64 > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1167964 > [2] https://fedorahosted.org/freeipa/ticket/4794 Patch 793: Works for me, ACK. Pushed to: master: 489dfe64689f86f7ddc4ad0784de0636f8e6c1f8 ipa-4-1: 2fa07b1d24f61f9bcff5adb804a18c9eae72932d Patch 794: As Thierry pointed out, this patch is not necessary, as the bug is fixed by patch 793 alone. Not pushed. Honza -- Jan Cholasta From mkosek at redhat.com Wed Dec 10 10:53:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Dec 2014 11:53:44 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <5486F185.1010300@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> <54818C56.6050201@redhat.com> <5481908D.2010706@redhat.com> <5486F185.1010300@redhat.com> Message-ID: <54882638.7050503@redhat.com> On 12/09/2014 01:56 PM, Jan Cholasta wrote: > Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): >> Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): >>> On 12/05/2014 11:34 AM, Jan Cholasta wrote: >>>> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >>>>> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>>>>> + if x509.get_der_subject(cert, x509.DER) != der_subject: >>>>>> + raise admintool.ScriptError("Subject name encoding >>>>>> mismatch") >>>>> >>>>> I think we can expect this to be a pretty common error, given this is >>>>> the default behavior of Microsoft Certificate Services. I would thus >>>>> like to make the error message more juicy. >>>>> >>>>> We need to make sure we offer some pointers for these users or they >>>>> will >>>>> just blame IPA for screwing up. So, the information I wrote >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >>>>> >>>>> need to somehow get to the error message as a potential/likely root >>>>> cause of the problem. Whether you write it in the error message itself >>>>> or update the design page and just insert a link is up to you. >>>>> >>>>> Martin >>>> >>>> I would rather document this and have users read the documentation, >>>> which they >>>> should do anyway when something goes wrong. There are many errors in >>>> IPA which >>>> are common and users may blame IPA for them and I don't see what makes >>>> this one >>>> so special that it should require a special treatment. >>> >>> I saw several reasons: >>> - Certificate&installation error are more common than the others and >>> users are usually quite lost in what to do with them. >>> - In this case, we know by 90% probability what is the root cause >>> - It will block one of the main use cases for the new CA renewal tool >>> and people will likely hit it as MS CAs is one of the most common CAs >>> and this is it's default behavior. >>> >>> Giving more details in this case will not hurt us, but benefit users. So >>> I still do not see the harm. >> >> I do not see a harm either, my point is that we should probably point >> the user to documentation when *anything* in *any* script goes wrong, >> not just when some arbitrarily cherry-picked error occurs. >> >>> >>>> Anyway, I have created >>>> . >>>> >>>> >>>> >>> >>> Good. Do you plan to reference the section or enhance the error message? >> >> I plan to reference . > > See the attached patch (385). I think the reference for the Troubleshooting page should be more narrow so that people only see the URL only for the cases we give specific advise for. Otherwise I assume they will just ignore the page if they do not find the advise for other errors. Other idea would be to give reference to the article when the actual CSR is generated - as a heads up. Martin From jcholast at redhat.com Wed Dec 10 13:35:56 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Dec 2014 14:35:56 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54882638.7050503@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> <54818C56.6050201@redhat.com> <5481908D.2010706@redhat.com> <5486F185.1010300@redhat.com> <54882638.7050503@redhat.com> Message-ID: <54884C3C.4020600@redhat.com> Dne 10.12.2014 v 11:53 Martin Kosek napsal(a): > On 12/09/2014 01:56 PM, Jan Cholasta wrote: >> Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): >>> Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): >>>> On 12/05/2014 11:34 AM, Jan Cholasta wrote: >>>>> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >>>>>> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>>>>>> + if x509.get_der_subject(cert, x509.DER) != der_subject: >>>>>>> + raise admintool.ScriptError("Subject name encoding >>>>>>> mismatch") >>>>>> >>>>>> I think we can expect this to be a pretty common error, given this is >>>>>> the default behavior of Microsoft Certificate Services. I would thus >>>>>> like to make the error message more juicy. >>>>>> >>>>>> We need to make sure we offer some pointers for these users or they >>>>>> will >>>>>> just blame IPA for screwing up. So, the information I wrote >>>>>> >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >>>>>> >>>>>> need to somehow get to the error message as a potential/likely root >>>>>> cause of the problem. Whether you write it in the error message itself >>>>>> or update the design page and just insert a link is up to you. >>>>>> >>>>>> Martin >>>>> >>>>> I would rather document this and have users read the documentation, >>>>> which they >>>>> should do anyway when something goes wrong. There are many errors in >>>>> IPA which >>>>> are common and users may blame IPA for them and I don't see what makes >>>>> this one >>>>> so special that it should require a special treatment. >>>> >>>> I saw several reasons: >>>> - Certificate&installation error are more common than the others and >>>> users are usually quite lost in what to do with them. >>>> - In this case, we know by 90% probability what is the root cause >>>> - It will block one of the main use cases for the new CA renewal tool >>>> and people will likely hit it as MS CAs is one of the most common CAs >>>> and this is it's default behavior. >>>> >>>> Giving more details in this case will not hurt us, but benefit users. So >>>> I still do not see the harm. >>> >>> I do not see a harm either, my point is that we should probably point >>> the user to documentation when *anything* in *any* script goes wrong, >>> not just when some arbitrarily cherry-picked error occurs. >>> >>>> >>>>> Anyway, I have created >>>>> . >>>>> >>>>> >>>>> >>>> >>>> Good. Do you plan to reference the section or enhance the error message? >>> >>> I plan to reference . >> >> See the attached patch (385). > > I think the reference for the Troubleshooting page should be more narrow so > that people only see the URL only for the cases we give specific advise for. > Otherwise I assume they will just ignore the page if they do not find the > advise for other errors. Right, makes sense. > > Other idea would be to give reference to the article when the actual CSR is > generated - as a heads up. I think referring to troubleshooting before there actually is some trouble is not very good for publicity. Anyway, updated patch attached, it implements what you suggested originally - link to the troubleshooting guide is added to relevant error messages. Let's think about this in more broad terms when the time comes for the installer refactoring. > > Martin > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-385.1-Refer-the-user-to-freeipa.org-when-something-goes-wr.patch Type: text/x-patch Size: 3107 bytes Desc: not available URL: From mbasti at redhat.com Wed Dec 10 14:10:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Dec 2014 15:10:56 +0100 Subject: [Freeipa-devel] [PATCH 0036] Remove ipaserver makefiles (was: Add missing python files to Makefile) In-Reply-To: <54870C9A.1090803@redhat.com> References: <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> <20141203163023.GB24459@mail.corp.redhat.com> <54870C9A.1090803@redhat.com> Message-ID: <54885470.2010609@redhat.com> On 09/12/14 15:52, Martin Basti wrote: > On 04/12/14 14:18, Gabe Alford wrote: >> Thanks for the assistance Lukas! I have an updated patch attached. >> >> Thanks, >> >> Gabe >> >> On Wed, Dec 3, 2014 at 9:30 AM, Lukas Slebodnik > > wrote: >> >> On (02/12/14 21:13), Gabe Alford wrote: >> >This patch removes the changelog and Makefile.am for ipaclient >> as well. >> > >> >Thanks, >> > >> >Gabe >> > >> >On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek > > wrote: >> > >> >> On 12/01/2014 04:25 PM, Rob Crittenden wrote: >> >> > Gabe Alford wrote: >> >> >> >> >> >> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek >> >> >> >> >> wrote: >> >> >> >> >> >> On 11/30/2014 03:28 AM, Gabe Alford wrote: >> >> >> > Ignore the last patch. Updated patch attached. >> >> >> > >> >> >> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford >> >> >> >> >> wrote: >> >> >> > >> >> >> >> This patch removes the app_PYTHON usage. >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> >> >> Gabe >> >> >> >> >> >> >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek >> >> >> >> >> >> wrote: >> >> >> >> >> >> >> >>> Exactly, this was the message from Martin :-) I did >> not test it >> >> >> myself, >> >> >> >>> but >> >> >> >>> removing all app_PYTHON should be benign given we >> use Python >> >> >> setup.py >> >> >> >>> packaging. >> >> >> >>> >> >> >> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: >> >> >> >>>> Thanks guys. Sounds like it would be better to >> submit a patch >> >> that >> >> >> >>> removes >> >> >> >>>> app_PYTHON if it is considered dead code. >> >> >> >>>> >> >> >> >>>> Gabe >> >> >> >>>> >> >> >> >>>> On Thursday, November 27, 2014, Petr Spacek < >> >> pspacek at redhat.com >> >> >> > >> wrote: >> >> >> >>>> >> >> >> >>>>> On 27.11.2014 11:00, Martin Basti wrote: >> >> >> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: >> >> >> >>>>>>> Hello, >> >> >> >>>>>>> >> >> >> >>>>>>> Wondering if I could get a review. Updated >> patch >> >> >> attached. >> >> >> >>>>>>> >> >> >> >>>>>>> Thanks, >> >> >> >>>>>>> Gabe >> >> >> >>>>>>> >> >> >> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >> >> >> >> > >> >> >> >>>>> >> >> >> >>>>>>> > > >> >> > >> >> >> >> wrote: >> >> >> >>>>>>> >> >> >> >>>>>>> Hello, >> >> >> >>>>>>> >> >> >> >>>>>>> Fix for >> https://fedorahosted.org/freeipa/ticket/4700 >> >> >> >>>>>>> >> >> >> >>>>>>> Thanks, >> >> >> >>>>>>> >> >> >> >>>>>>> Gabe >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>>> >> >> >> >>>>>> Hello, >> >> >> >>>>>> >> >> >> >>>>>> sorry for late response. >> >> >> >>>>>> >> >> >> >>>>>> We push this ticket to backlog, as it would be >> part of build >> >> >> system >> >> >> >>>>> refactoring. >> >> >> >>>>>> The "app_PYTHON" statement is not used anymore >> in IPA, the >> >> better >> >> >> >>>>> solution is >> >> >> >>>>>> remove it, instead of keeping dead code up-to-date. >> >> >> >>>>> >> >> >> >>>>> Just to clarify: >> >> >> >>>>> It can be pushed if it works, there is no need to >> postpone >> >> >> accepting >> >> >> >>> patch >> >> >> >>>>> if >> >> >> >>>>> the patch seems okay and doesn't break anything. >> >> >> >>>>> >> >> >> >>>>> Martin, please keep in mind that contributions >> are welcome at >> >> >> any time. >> >> >> >>>>> >> >> >> >>>>> Milestones in Trac reflect our view of priorities >> but it >> >> doesn't >> >> >> >>> prevent us >> >> >> >>>>> from accepting correct patches from contributions >> at any >> >> time, no >> >> >> >>> matter >> >> >> >>>>> which >> >> >> >>>>> priority is stated in Trac (or even if there is >> no ticket for >> >> >> it ...). >> >> >> >>>>> >> >> >> >>>>> -- >> >> >> >>>>> Petr^2 Spacek >> >> >> >> >> >> Worked in my tests, I did not see any breakage. I guess >> we can also >> >> >> remove the >> >> >> ipa-client/ipaclient/Makefile.am while we are at it. >> >> >> >> >> >> Martin >> >> >> >> >> >> >> >> >> It looks like the ipaclient/Makefile.am is still being >> used. I tried >> >> >> removing it and there were errors in the build, but maybe I >> am wrong? >> >> > >> >> > It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. >> >> > >> >> > Feel free to rip out the outdated hg ChangeLog stuff though. >> >> > >> >> > rob >> >> >> >> I think Gabe was asking about ipa-client/ipaclient/Makefile.am >> and not >> >> about >> >> ipa-client/Makefile.am - we still need this one as Rob >> correctly said. >> >> >> >> The failure that Gabe hit in build probably comes from the the >> SUBDIR >> >> reference >> >> in ipa-client/Makefile.am file. I assume that if the reference >> is removed, >> >> the >> >> removal should work. >> >> >> >> And yes, you can remove the Changelog too if you are OK with it :) >> >> >> >> Martin >> >> >> >> >From d2e3176b6f6f2abb2ffbdfc198814bd1a845b876 Mon Sep 17 >> 00:00:00 2001 >> >From: Gabe > >> >Date: Tue, 2 Dec 2014 14:43:57 -0700 >> >Subject: [PATCH] Remove usage of app_PYTHON in ipaserver Makefiles >> > >> >https://fedorahosted.org/freeipa/ticket/4700 >> >--- >> > ipa-client/Makefile.am | 21 --------------------- >> > ipa-client/ipaclient/Makefile.am | 17 ----------------- >> > ipaserver/install/Makefile.am | 27 >> --------------------------- >> > ipaserver/install/plugins/Makefile.am | 24 ------------------------ >> > 4 files changed, 89 deletions(-) >> > delete mode 100644 ipa-client/ipaclient/Makefile.am >> > delete mode 100644 ipaserver/install/Makefile.am >> > delete mode 100644 ipaserver/install/plugins/Makefile.am >> > >> >diff --git a/ipa-client/Makefile.am b/ipa-client/Makefile.am >> >index >> b9c7020f3b687b3c0030ed5166625e6ef07e2fa4..f6f3168774c3024e10f626b88a8952c51c0eab90 >> 100644 >> >--- a/ipa-client/Makefile.am >> >+++ b/ipa-client/Makefile.am >> >@@ -84,7 +84,6 @@ ipa_join_LDADD = \ >> > >> > SUBDIRS = \ >> > ../asn1 \ >> >- ipaclient \ >> > ipa-install \ >> > man \ >> > $(NULL) >> >@@ -97,7 +96,6 @@ EXTRA_DIST = \ >> > README \ >> > HACKING \ >> > NEWS \ >> >- ChangeLog \ >> > $(NULL) >> > >> > DISTCLEANFILES = \ >> >@@ -125,22 +123,3 @@ MAINTAINERCLEANFILES = \ >> > py-compile \ >> > $(NULL) >> > >> >-# Creating ChangeLog from hg log (taken from cairo/Makefile.am): >> >- >> >-ChangeLog: $(srcdir)/ChangeLog >> >- >> >-$(srcdir)/ChangeLog: >> >- @if test -d "$(srcdir)/../.hg"; then \ >> >- (cd "$(srcdir)" && \ >> >- ./missing --run hg log --verbose) | fmt --split-only > >> $@.tmp \ >> >- && mv -f $@.tmp $@ \ >> >- || ($(RM) $@.tmp; \ >> >- echo Failed to generate ChangeLog, your ChangeLog >> may be outdated >&2; \ >> >- (test -f $@ || echo hg log is required to generate >> this file >> $@)); \ >> >- else \ >> >- test -f $@ || \ >> >- (echo A hg checkout and hg -log is required to generate >> ChangeLog >&2 && \ >> >- echo A hg checkout and hg log is required to generate >> this file >> $@); \ >> >- fi >> >- >> >-.PHONY: ChangeLog $(srcdir)/ChangeLog >> >diff --git a/ipa-client/ipaclient/Makefile.am >> b/ipa-client/ipaclient/Makefile.am >> >deleted file mode 100644 >> >index >> 01824b86584992fd84d4542da88395aa0e89de12..0000000000000000000000000000000000000000 >> >--- a/ipa-client/ipaclient/Makefile.am >> >+++ /dev/null >> >@@ -1,17 +0,0 @@ >> >-NULL = >> >- >> >-appdir = $(pythondir)/ipaclient >> >-app_PYTHON = \ >> >- __init__.py \ >> >- ipachangeconf.py \ >> >- ipadiscovery.py \ >> >- ntpconf.py \ >> >- ipa_certupdate.py \ >> >- $(NULL) >> >- >> >-EXTRA_DIST = \ >> >- $(NULL) >> >- >> >-MAINTAINERCLEANFILES = \ >> >- *~ \ >> >- Makefile.in >> >> You need to remove ipa-client/ipaclient/Makefile.am also from >> AC_CONFIG_FILES >> in file ipa-client/configure.ac >> >> >> It should fix problem with autoreconf. >> >> LS >> > > Sorry I can't build RPMS > > RPM build errors: > Directory not found: > /root/freeipa/rpmbuild/BUILDROOT/freeipa-4.1.2-0.fc21.x86_64/usr/lib/python2.7/site-packages/ipaclient > File not found by glob: > /root/freeipa/rpmbuild/BUILDROOT/freeipa-4.1.2-0.fc21.x86_64/usr/lib/python2.7/site-packages/ipaclient/*.py* > Makefile:229: recipe for target 'rpms' failed > > > The problem is, we don't have setup.py script for ipa client (just for > ipaserver). > I suggest to remove only Changelog from ipa-client, and let other > parts of ipa-client related Makefiles untouched. > > Martin^2 Gabe sent me the updated patch without copy for devel-list. I attach the patch. ACK, works as expected. Thanks Gabe! -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0036-6-Remove-usage-of-app_PYTHON-in-ipaserver-Makefiles.patch Type: text/x-patch Size: 3196 bytes Desc: not available URL: From pspacek at redhat.com Wed Dec 10 14:13:30 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 10 Dec 2014 15:13:30 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <5486EDB1.50500@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> Message-ID: <5488550A.3000400@redhat.com> On 9.12.2014 13:40, Martin Kosek wrote: > On 12/03/2014 05:04 PM, Petr Spacek wrote: >> On 2.12.2014 17:21, Simo Sorce wrote: >>> On Tue, 02 Dec 2014 15:56:28 +0100 >>> Petr Spacek wrote: >>> >>>> On 1.12.2014 17:12, Simo Sorce wrote: >>>>> On Mon, 01 Dec 2014 16:17:54 +0100 >>>>> Petr Spacek wrote: >>>>> >>>>>> On 14.11.2014 17:31, Petr Spacek wrote: >>>>>>> On 14.11.2014 02:22, Simo Sorce wrote: >>>>>>>> On Tue, 11 Nov 2014 16:29:51 +0100 >>>>>>>> Petr Spacek wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> this thread is about RFE >>>>>>>>> "IPA servers when installed should register themselves in the >>>>>>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >>>>>>>>> >>>>>>>>> It is not a complete design, just a raw idea. >>>>>>>>> >>>>>>>>> >>>>>>>>> Use case >>>>>>>>> ======== >>>>>>>>> FreeIPA installation to a network with existing DNS >>>>>>>>> infrastructure + network administrator who is not willing to >>>>>>>>> add/maintain new DNS servers "just for FreeIPA". >>>>>>>>> >>>>>>>>> >>>>>>>>> High-level idea >>>>>>>>> =============== >>>>>>>>> - Transform dns* commands from FreeIPA framework to equivalent >>>>>>>>> "nsupdate" commands and send DNS updates to existing DNS >>>>>>>>> servers. >>>>>>>>> - Provide necessary encryption/signing keys to nsupdate. >>>>>>>>> >>>>>>>>> >>>>>>>>> 1) Integration to FreeIPA framework >>>>>>>>> =================================== >>>>>>>>> First of all, we need to decide if "external DNS integration" >>>>>>>>> can be used at the same time with FreeIPA-integrated DNS or not. >>>>>>>>> Side-question is what to do if a first server is installed with >>>>>>>>> external-DNS but another replica is being installed with >>>>>>>>> integrated-DNS and so on. >>>>>>>> >>>>>>>> I think being able to integrate with an external DNS is >>>>>>>> important, and not just at the server level, being able to >>>>>>>> distribute TSIG keys to client would be nice too, though a lot >>>>>>>> less important, than getting server integration.. >>>>>>> >>>>>>> Using TSIG on many clients is very problematic. Keep in mind that >>>>>>> TSIG is basically HMAC computed using symmetric key so: >>>>>>> a) Every client would have to use the same key - this is a >>>>>>> security nightmare. b) We would have to distribute and maintain >>>>>>> many keys for many^2 clients, which is an administrative >>>>>>> nightmare. >>>>>>> >>>>>>> For *clients* I would rather stay with GSS-TSIG which is much more >>>>>>> manageable because we can use Kerberos trust and Keytab >>>>>>> distribution is already solved by ipa-client-install. >>>>>>> >>>>>>> Alternative for clients would be to use FreeIPA server as proxy >>>>>>> which encapsulates TSIG keys and issues update requests on behalf >>>>>>> of clients. This would be FreeIPA-specific but any >>>>>>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>>>>>> >>>>>>> TSIG standard explicitly says that there is no standardized >>>>>>> distribution mechanism. >>>>>>> >>>>>>>>> In other words, the question is if current "dns.py" plugin >>>>>>>>> shipped with FreeIPA framework should be: >>>>>>>>> >>>>>>>>> a) Extended dns.py with dnsexternal-* commands >>>>>>>>> ---------------------------------------------- >>>>>>>>> Disadvantages: >>>>>>>>> - It complicate FreeIPA DNS interface which is a complex beast >>>>>>>>> even now. >>>>>>>>> - We would have add condition to every DNS API call in >>>>>>>>> installers which would increase horribleness of the installer >>>>>>>>> code even more (or add another layer of abstraction...). >>>>>>>> >>>>>>>> I agree having a special command is undesirable. >>>>>>>>> >>>>>>>>> - I don't see a point in using integrated-DNS with external-DNS >>>>>>>>> at the same time. To use integrated-DNS you have to get a >>>>>>>>> proper DNS delegation from parent domain - and if you can get >>>>>>>>> the delegation then there is no point in using external DNS ... >>>>>>>> >>>>>>>> I disagree on this point, it makes a lot of sense to have some >>>>>>>> zones maintained by IPA and ... some not. >>>>>>>> >>>>>>>>> Advantages: >>>>>>>>> - You can use external & integrated DNS at the same time. >>>>>>>> >>>>>>>> We can achieve the same w/o a new ipa level command. >>>>>>> >>>>>>> This needs to be decided by FreeIPA framework experts ... >>>>>>> >>>>>>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>>>>>> proxy would provide all ipa dns* commands and dispatch user-issued >>>>>>> commands to appropriate FreeIPA-plugin (internal-dns or >>>>>>> external-dns). This decision could depend on some values in LDAP. >>>>>>> >>>>>>>>> b) Replace dns.py with another implementation of current >>>>>>>>> dnszone-* & dnsrecord-* API. >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> This seems like a cleaner approach to me. It could be shipped as >>>>>>>>> ipa-server-dns-external package (opposed to "standard" >>>>>>>>> ipa-server-dns package). >>>>>>>>> >>>>>>>>> Advantages: >>>>>>>>> - It could seamlessly work with FreeIPA client installer because >>>>>>>>> the dns*->nsupdate command transformation would be done on >>>>>>>>> FreeIPA server and client doesn't need to know about it. >>>>>>>>> - Does not require re-training/not much new documentation >>>>>>>>> because commands are the same. >>>>>>>>> >>>>>>>>> Disadvantages: >>>>>>>>> - You can't use integrated & external DNS at the same time (but >>>>>>>>> I don't think it justifies the added complexity). >>>>>>>> >>>>>>>> I disagree. >>>>>>>> >>>>>>>> One of the reason to use a mix is to allow smooth migrations >>>>>>>> where zones are moved into (or out of) IPA one by one. >>>>>>> >>>>>>> Good point, I agree. I will focus on supporting both (internal and >>>>>>> external) DNS at the same time. >>>>>>> >>>>>>>>> Petr^3 or anyone else, what do you propose? >>>>>>>> >>>>>>>> I think what I'd like to see is to be able to configure a DNS >>>>>>>> zone in LDAP and mark it external. >>>>>>>> The zone would held the TSIG keys necessary to perform DNS >>>>>>>> updates. >>>>>>>> >>>>>>>> When the regular ipa dnsrecord-add etc... commands are called, >>>>>>>> the framework detects that the zone is "external", fewttches the >>>>>>>> TSIG key (if the user has access to it) and spawn an nsupdate >>>>>>>> command that will perform the update against whatever DNS server >>>>>>>> is authoritative for the zone. >>>>>>>> >>>>>>>> Some commands may be disabled if the zone is external and >>>>>>>> appropriate errors would be returned. >>>>>>> >>>>>>> Correct, this will be inevitable. >>>>>>> >>>>>>>>> 2) Authentication to external DNS server/keys >>>>>>>>> ============================================= >>>>>>>>> This is separate problem from FreeIPA framework integration. >>>>>>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) >>>>>>>>> or keytabs (for DNS GSS-TSIG) and distribute them somehow to >>>>>>>>> replicas so every replica can update DNS records as necessary. >>>>>>>> >>>>>>>> For TSIG keys I think we should just store them in a LDAP record, >>>>>>>> see above. >>>>>>> >>>>>>> Without any encryption? Am I missing something? >>>>>>> >>>>>>>> For keytabs we can simply store them just like any other >>>>>>>> kerberos key if we really need it (in a trust case for example, >>>>>>>> we may not need a new keytab, we may be allowed to use our own >>>>>>>> credentials through the trust. So we'll need to explore a bit >>>>>>>> how to properly express that in configuration. REtrieval ok >>>>>>>> keytabs is then just a matter of running ipa-getkeytab -r on the >>>>>>>> replica that needs it. >>>>>>>> >>>>>>>>> This will be the funny part because in case of AD trusts we have >>>>>>>>> chicken-egg problem. You need to establish trust to get ticket >>>>>>>>> for DNS/dc1.ad.example at AD principal but you can't (I guess) >>>>>>>>> establish trust until proper DNS records are in place ... >>>>>>>> >>>>>>>> No, in this case we should create the records at trust >>>>>>>> establishment time using the admin credentials we have been >>>>>>>> provided. NO chicken-egg issue. >>>>>>> >>>>>>> Sorry, we surely *have* a chicken-egg issue because >>>>>>> ipa-server-install is completely separate step from from >>>>>>> ipa-adtrust-install which is completely separate from ipa >>>>>>> trust-add. (And there is nothing which forces user to establish AD >>>>>>> trust right after ipa-server-install finished.) >>>>>>> >>>>>>> Also, in some cases it is not possible to use the same credentials >>>>>>> for trust establishment and for DNS updates on AD. Think about >>>>>>> one-way trust or possibly two-way trust but established using >>>>>>> pre-shared trust secret (which is AFAIK not usable for kinit). >>>>>>> >>>>>>> Alexander, could you clarify if it is possible to create an AD >>>>>>> trust *without* DNS records for FreeIPA side of the trust? >>>>>>> >>>>>>> Another problem is that reliance on AD trusts would effectively >>>>>>> prevent interoperability with non-AD DNS servers (think Infoblox >>>>>>> or standard BIND). >>>>>>> >>>>>>> I tend to think that we will need to obtain credentials (AD >>>>>>> login/pass/keytab/TSIG key) as one of ipa-server-install >>>>>>> parameters so all DNS updates can be done right away. This would >>>>>>> allow us have ipa-server-install script which in fact produces >>>>>>> *working* FreeIPA domain. In other cases ipa-server-install would >>>>>>> end but the FreeIPA domain would not be functional because of >>>>>>> missing records in DNS. >>>>>>> >>>>>>>>> For 'experimental' phase I would go with pre-populated CCcache, >>>>>>>>> i.e. admin will manually do kinit Administrator at AD and then run >>>>>>>>> FreeIPA installer. >>>>>>>> >>>>>>>> We already to this, so there is no need to invent anything here >>>>>>>> IMO. >>>>>>> >>>>>>> Except for cases mentioned above ... >>>>>>> >>>>>>>>> Maybe we can re-use trust secret somehow? I don't know, I will >>>>>>>>> reach out to AD experts with questions. >>>>>>>>> >>>>>>>>> This area needs more research but for now it seems feasible to >>>>>>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs >>>>>>>>> so "only" the chicken-egg problem is left. >>>>>>>>> >>>>>>>>> This will need new LDAP schema but I will propose something when >>>>>>>>> I'm done with investigation. >>>>>>>> >>>>>>>> Please let me know if you agree with a new zone type as a way to >>>>>>>> "forward" updates. >>>>>>> >>>>>>> Generally I agree, it was my plan too. My main concern is not >>>>>>> about LDAP structure but about FreeIPA framework and about >>>>>>> workflow in general. It will be fun to extend the spaghetti code >>>>>>> we have ... >>>>>> >>>>>> Ping :-) I would like to move the discussion forward. >>>>>> >>>>>> Alexander, could you please comment on authentication to AD >>>>>> mentioned above? >>>>>> >>>>>> Simo and everybody else, what do you think about client use-case, >>>>>> i.e. forwarding DNS updates from FreeIPA clients to external DNS >>>>>> infrastructure? What about security implications (keeping in mind >>>>>> that TSIG keys are symmetric)? >>>>>> >>>>>> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy >>>>>> instead of nsupdate command (to hide TSIG key behind FreeIPA)? >>>>> >>>>> Remind me this, when a client tries to update the DNS, does it >>>>> always contact its own DNS server first, or does it try to go >>>>> straight to the authoritative DNS server? >>>> >>>> It should go straight to authoritative servers listed in NS records. >>>> >>>>> I do not like the XML-RPC->DNS approach as it requires a special >>>>> client, leaving out the majority of clients. >>>> >>>> Yes, it is an option of last resort (because I don't see a way how to >>>> be compatible with standard clients, see the point above). >>>> >>>>> Also, I am thinking that we only _need_ to set infrastructure >>>>> relevant names (like IPA servers SRV records), but if someone >>>>> decides not to use IPA for the DNS we may decide that it is not our >>>>> responsibility to provide a full end-to-end client dns update >>>>> solution. >>>> >>>> If we can agree on that then I'm fine with it. >>> >>> Yes the more I think of it, the more I prefer to wait in trying to >>> solve the clients problem. >>> >>>>> So I would concentrate on making it possible for IPA *Servers* to >>>>> use a private TSIG key to update infrastructure relevant names, and >>>>> possibly defer the clients side of the problem. >>>> >>>> Speaking about native clients, two-way AD trust should nicely work >>>> with clients because clients could go straight to the AD and >>>> authenticate using host keytab from FreeIPA realm. It will not work >>>> in other cases but it is still better than nothing. >>> >>> Yes, this has been accounted for. >>> >>>>> We could use an internal bus on the server to allow the ipa >>>>> framework to use nsupdate w/o gaining direct access to the TSIG >>>>> key, this way admins can use ipa dnsrecod-add and friends w/o >>>>> exposing the key. >>>> >>>> I agree with the idea but it depends on an authorization daemon you >>>> have proposed earlier (in different discussion). Do you see it as >>>> reasonable goal for FreeIPA 4.2 time-span? >>> >>> I wouldn't say a definite no, but I am not confident we can. >>> >>>> If the authorization daemon is too far away, would it be okay to >>>> support external DNS domains only for ipa* installers but do not >>>> support it for FreeIPA users? (I.e. basically store the key in HSM >>>> which is not accessible to users - that is what we do with DNSSEC >>>> keys now.) >>> >>> Yes I think it would be fine as a first step. >> >> Okay, I tried to summarize current goals on: >> http://www.freeipa.org/page/V4/External_DNS_integration_with_installer >> >> At the moment I see a first obstacle: >> $ ipa-replica-manage can authenticate to LDAP servers using: >> - LDAPI (when running as root) >> - GSSAPI >> - DM password >> >> The problem is that we would need to have access to TSIG keys even when using >> GSSAPI and DM password authentication ... so we again need the authorization >> daemon. >> >> >> Alternatively we can use Vault for TSIG key storage and use Vault's capability >> to share keys among many users. In that case we don't have problem with key >> distribution nor authorization. > > I am not convinced we should grow Vault dependency for this functionality, it > requires the whole PKI machinery to be available. Many deployments do not use > it though. > >> Another possibility is to say that replica-deletion can be done only by root >> user or that updates to external DNS are supported only when running >> ipa-replica-manage as root. > > Why does root help? So that TSIG keys will be available on all IPA servers, > regardless whether they have DNS service running or not? The point is that we need to store TSIG keys "somewhere" to make them available to ipa* scripts on all replica but at the same not to human-users. BTW there don't need to be any 'DNS service' if only external DNS integration is in use. > It would be better to have the TSIG keys available using standard FreeIPA RBAC > roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I > missing anything? Ideologically - no, it sounds fine. Technically - the problem is in implementation. We need a mechanism for secure key distribution *among users*, i.e. Vault-like functionality. I would rather not re-implement Vault just for external DNS. I think that external DNS could depend on Vault (assuming that external DNS support will be purely optional). DNSSEC key distribution is very different because it distributes keys to *servers* and there is no ACI mechanism on top of that - all DNS servers need to know all the keys anyway. Petr^2 Spacek > I am also wondering that the design should be friendly to the Topology work > that Ludwig is working on. I would it up to Simo to evaluate this part though. > >> >> Other tools (ipa-*install*) should not have this problem because they are >> running under the root anyway. >> >> Ideas are more than welcome! From mkosek at redhat.com Wed Dec 10 14:43:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Dec 2014 15:43:54 +0100 Subject: [Freeipa-devel] [PATCH 0036] Remove ipaserver makefiles In-Reply-To: <54885470.2010609@redhat.com> References: <54773F42.7030405@redhat.com> <54774605.2090603@redhat.com> <547C599C.6040202@redhat.com> <547C886A.4080205@redhat.com> <547C893B.1000008@redhat.com> <20141203163023.GB24459@mail.corp.redhat.com> <54870C9A.1090803@redhat.com> <54885470.2010609@redhat.com> Message-ID: <54885C2A.1070202@redhat.com> On 12/10/2014 03:10 PM, Martin Basti wrote: > On 09/12/14 15:52, Martin Basti wrote: >> On 04/12/14 14:18, Gabe Alford wrote: >>> Thanks for the assistance Lukas! I have an updated patch attached. >>> >>> Thanks, >>> >>> Gabe >>> >>> On Wed, Dec 3, 2014 at 9:30 AM, Lukas Slebodnik >> > wrote: >>> >>> On (02/12/14 21:13), Gabe Alford wrote: >>> >This patch removes the changelog and Makefile.am for ipaclient >>> as well. >>> > >>> >Thanks, >>> > >>> >Gabe >>> > >>> >On Mon, Dec 1, 2014 at 8:28 AM, Martin Kosek >> > wrote: >>> > >>> >> On 12/01/2014 04:25 PM, Rob Crittenden wrote: >>> >> > Gabe Alford wrote: >>> >> >> >>> >> >> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek >>> >>> >> >> >> wrote: >>> >> >> >>> >> >> On 11/30/2014 03:28 AM, Gabe Alford wrote: >>> >> >> > Ignore the last patch. Updated patch attached. >>> >> >> > >>> >> >> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford >>> >> >> >>> >> wrote: >>> >> >> > >>> >> >> >> This patch removes the app_PYTHON usage. >>> >> >> >> >>> >> >> >> Thanks, >>> >> >> >> >>> >> >> >> Gabe >>> >> >> >> >>> >> >> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek >>> >>> >> >> >> >>> wrote: >>> >> >> >> >>> >> >> >>> Exactly, this was the message from Martin :-) I did >>> not test it >>> >> >> myself, >>> >> >> >>> but >>> >> >> >>> removing all app_PYTHON should be benign given we >>> use Python >>> >> >> setup.py >>> >> >> >>> packaging. >>> >> >> >>> >>> >> >> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote: >>> >> >> >>>> Thanks guys. Sounds like it would be better to >>> submit a patch >>> >> that >>> >> >> >>> removes >>> >> >> >>>> app_PYTHON if it is considered dead code. >>> >> >> >>>> >>> >> >> >>>> Gabe >>> >> >> >>>> >>> >> >> >>>> On Thursday, November 27, 2014, Petr Spacek < >>> >> pspacek at redhat.com >>> >> >> >> >> wrote: >>> >> >> >>>> >>> >> >> >>>>> On 27.11.2014 11:00, Martin Basti wrote: >>> >> >> >>>>>> On 27/11/14 00:50, Gabe Alford wrote: >>> >> >> >>>>>>> Hello, >>> >> >> >>>>>>> >>> >> >> >>>>>>> Wondering if I could get a review. Updated >>> patch >>> >> >> attached. >>> >> >> >>>>>>> >>> >> >> >>>>>>> Thanks, >>> >> >> >>>>>>> Gabe >>> >> >> >>>>>>> >>> >> >> >>>>>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford >>> >> >> >>> > >>> >> >> >>>>> >>> >> >> >>>>>>> >> >> >>> >> > >>> >> >> >> wrote: >>> >> >> >>>>>>> >>> >> >> >>>>>>> Hello, >>> >> >> >>>>>>> >>> >> >> >>>>>>> Fix for >>> https://fedorahosted.org/freeipa/ticket/4700 >>> >> >> >>>>>>> >>> >> >> >>>>>>> Thanks, >>> >> >> >>>>>>> >>> >> >> >>>>>>> Gabe >>> >> >> >>>>>>> >>> >> >> >>>>>>> >>> >> >> >>>>>>> >>> >> >> >>>>>> Hello, >>> >> >> >>>>>> >>> >> >> >>>>>> sorry for late response. >>> >> >> >>>>>> >>> >> >> >>>>>> We push this ticket to backlog, as it would be >>> part of build >>> >> >> system >>> >> >> >>>>> refactoring. >>> >> >> >>>>>> The "app_PYTHON" statement is not used anymore >>> in IPA, the >>> >> better >>> >> >> >>>>> solution is >>> >> >> >>>>>> remove it, instead of keeping dead code up-to-date. >>> >> >> >>>>> >>> >> >> >>>>> Just to clarify: >>> >> >> >>>>> It can be pushed if it works, there is no need to >>> postpone >>> >> >> accepting >>> >> >> >>> patch >>> >> >> >>>>> if >>> >> >> >>>>> the patch seems okay and doesn't break anything. >>> >> >> >>>>> >>> >> >> >>>>> Martin, please keep in mind that contributions >>> are welcome at >>> >> >> any time. >>> >> >> >>>>> >>> >> >> >>>>> Milestones in Trac reflect our view of priorities >>> but it >>> >> doesn't >>> >> >> >>> prevent us >>> >> >> >>>>> from accepting correct patches from contributions >>> at any >>> >> time, no >>> >> >> >>> matter >>> >> >> >>>>> which >>> >> >> >>>>> priority is stated in Trac (or even if there is >>> no ticket for >>> >> >> it ...). >>> >> >> >>>>> >>> >> >> >>>>> -- >>> >> >> >>>>> Petr^2 Spacek >>> >> >> >>> >> >> Worked in my tests, I did not see any breakage. I guess >>> we can also >>> >> >> remove the >>> >> >> ipa-client/ipaclient/Makefile.am while we are at it. >>> >> >> >>> >> >> Martin >>> >> >> >>> >> >> >>> >> >> It looks like the ipaclient/Makefile.am is still being >>> used. I tried >>> >> >> removing it and there were errors in the build, but maybe I >>> am wrong? >>> >> > >>> >> > It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab. >>> >> > >>> >> > Feel free to rip out the outdated hg ChangeLog stuff though. >>> >> > >>> >> > rob >>> >> >>> >> I think Gabe was asking about ipa-client/ipaclient/Makefile.am >>> and not >>> >> about >>> >> ipa-client/Makefile.am - we still need this one as Rob >>> correctly said. >>> >> >>> >> The failure that Gabe hit in build probably comes from the the >>> SUBDIR >>> >> reference >>> >> in ipa-client/Makefile.am file. I assume that if the reference >>> is removed, >>> >> the >>> >> removal should work. >>> >> >>> >> And yes, you can remove the Changelog too if you are OK with it :) >>> >> >>> >> Martin >>> >> >>> >>> >From d2e3176b6f6f2abb2ffbdfc198814bd1a845b876 Mon Sep 17 >>> 00:00:00 2001 >>> >From: Gabe > >>> >Date: Tue, 2 Dec 2014 14:43:57 -0700 >>> >Subject: [PATCH] Remove usage of app_PYTHON in ipaserver Makefiles >>> > >>> >https://fedorahosted.org/freeipa/ticket/4700 >>> >--- >>> > ipa-client/Makefile.am | 21 --------------------- >>> > ipa-client/ipaclient/Makefile.am | 17 ----------------- >>> > ipaserver/install/Makefile.am | 27 >>> --------------------------- >>> > ipaserver/install/plugins/Makefile.am | 24 ------------------------ >>> > 4 files changed, 89 deletions(-) >>> > delete mode 100644 ipa-client/ipaclient/Makefile.am >>> > delete mode 100644 ipaserver/install/Makefile.am >>> > delete mode 100644 ipaserver/install/plugins/Makefile.am >>> > >>> >diff --git a/ipa-client/Makefile.am b/ipa-client/Makefile.am >>> >index >>> >>> b9c7020f3b687b3c0030ed5166625e6ef07e2fa4..f6f3168774c3024e10f626b88a8952c51c0eab90 >>> >>> 100644 >>> >--- a/ipa-client/Makefile.am >>> >+++ b/ipa-client/Makefile.am >>> >@@ -84,7 +84,6 @@ ipa_join_LDADD = \ >>> > >>> > SUBDIRS = \ >>> > ../asn1 \ >>> >- ipaclient \ >>> > ipa-install \ >>> > man \ >>> > $(NULL) >>> >@@ -97,7 +96,6 @@ EXTRA_DIST = \ >>> > README \ >>> > HACKING \ >>> > NEWS \ >>> >- ChangeLog \ >>> > $(NULL) >>> > >>> > DISTCLEANFILES = \ >>> >@@ -125,22 +123,3 @@ MAINTAINERCLEANFILES = \ >>> > py-compile \ >>> > $(NULL) >>> > >>> >-# Creating ChangeLog from hg log (taken from cairo/Makefile.am): >>> >- >>> >-ChangeLog: $(srcdir)/ChangeLog >>> >- >>> >-$(srcdir)/ChangeLog: >>> >- @if test -d "$(srcdir)/../.hg"; then \ >>> >- (cd "$(srcdir)" && \ >>> >- ./missing --run hg log --verbose) | fmt --split-only > >>> $@.tmp \ >>> >- && mv -f $@.tmp $@ \ >>> >- || ($(RM) $@.tmp; \ >>> >- echo Failed to generate ChangeLog, your ChangeLog >>> may be outdated >&2; \ >>> >- (test -f $@ || echo hg log is required to generate >>> this file >> $@)); \ >>> >- else \ >>> >- test -f $@ || \ >>> >- (echo A hg checkout and hg -log is required to generate >>> ChangeLog >&2 && \ >>> >- echo A hg checkout and hg log is required to generate >>> this file >> $@); \ >>> >- fi >>> >- >>> >-.PHONY: ChangeLog $(srcdir)/ChangeLog >>> >diff --git a/ipa-client/ipaclient/Makefile.am >>> b/ipa-client/ipaclient/Makefile.am >>> >deleted file mode 100644 >>> >index >>> >>> 01824b86584992fd84d4542da88395aa0e89de12..0000000000000000000000000000000000000000 >>> >>> >--- a/ipa-client/ipaclient/Makefile.am >>> >+++ /dev/null >>> >@@ -1,17 +0,0 @@ >>> >-NULL = >>> >- >>> >-appdir = $(pythondir)/ipaclient >>> >-app_PYTHON = \ >>> >- __init__.py \ >>> >- ipachangeconf.py \ >>> >- ipadiscovery.py \ >>> >- ntpconf.py \ >>> >- ipa_certupdate.py \ >>> >- $(NULL) >>> >- >>> >-EXTRA_DIST = \ >>> >- $(NULL) >>> >- >>> >-MAINTAINERCLEANFILES = \ >>> >- *~ \ >>> >- Makefile.in >>> >>> You need to remove ipa-client/ipaclient/Makefile.am also from >>> AC_CONFIG_FILES >>> in file ipa-client/configure.ac >>> >>> >>> It should fix problem with autoreconf. >>> >>> LS >>> >> >> Sorry I can't build RPMS >> >> RPM build errors: >> Directory not found: >> /root/freeipa/rpmbuild/BUILDROOT/freeipa-4.1.2-0.fc21.x86_64/usr/lib/python2.7/site-packages/ipaclient >> >> File not found by glob: >> /root/freeipa/rpmbuild/BUILDROOT/freeipa-4.1.2-0.fc21.x86_64/usr/lib/python2.7/site-packages/ipaclient/*.py* >> >> Makefile:229: recipe for target 'rpms' failed >> >> >> The problem is, we don't have setup.py script for ipa client (just for >> ipaserver). >> I suggest to remove only Changelog from ipa-client, and let other parts of >> ipa-client related Makefiles untouched. >> >> Martin^2 > > Gabe sent me the updated patch without copy for devel-list. > > I attach the patch. > > ACK, works as expected. > > Thanks Gabe! Pushed to master: 6d3403edacbf547c31085acb0d542ec7f56c6e90 Martin From redhatrises at gmail.com Wed Dec 10 14:45:16 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 10 Dec 2014 07:45:16 -0700 Subject: [Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4783 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0040-Remove-dependency-on-subscription-manager.patch Type: text/x-patch Size: 850 bytes Desc: not available URL: From mkosek at redhat.com Wed Dec 10 14:50:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Dec 2014 15:50:23 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <5488550A.3000400@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> <5488550A.3000400@redhat.com> Message-ID: <54885DAF.2090408@redhat.com> On 12/10/2014 03:13 PM, Petr Spacek wrote: > On 9.12.2014 13:40, Martin Kosek wrote: >> On 12/03/2014 05:04 PM, Petr Spacek wrote: >>> On 2.12.2014 17:21, Simo Sorce wrote: >>>> On Tue, 02 Dec 2014 15:56:28 +0100 >>>> Petr Spacek wrote: >>>> >>>>> On 1.12.2014 17:12, Simo Sorce wrote: >>>>>> On Mon, 01 Dec 2014 16:17:54 +0100 >>>>>> Petr Spacek wrote: >>>>>> >>>>>>> On 14.11.2014 17:31, Petr Spacek wrote: >>>>>>>> On 14.11.2014 02:22, Simo Sorce wrote: >>>>>>>>> On Tue, 11 Nov 2014 16:29:51 +0100 >>>>>>>>> Petr Spacek wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> this thread is about RFE >>>>>>>>>> "IPA servers when installed should register themselves in the >>>>>>>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >>>>>>>>>> >>>>>>>>>> It is not a complete design, just a raw idea. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Use case >>>>>>>>>> ======== >>>>>>>>>> FreeIPA installation to a network with existing DNS >>>>>>>>>> infrastructure + network administrator who is not willing to >>>>>>>>>> add/maintain new DNS servers "just for FreeIPA". >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> High-level idea >>>>>>>>>> =============== >>>>>>>>>> - Transform dns* commands from FreeIPA framework to equivalent >>>>>>>>>> "nsupdate" commands and send DNS updates to existing DNS >>>>>>>>>> servers. >>>>>>>>>> - Provide necessary encryption/signing keys to nsupdate. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1) Integration to FreeIPA framework >>>>>>>>>> =================================== >>>>>>>>>> First of all, we need to decide if "external DNS integration" >>>>>>>>>> can be used at the same time with FreeIPA-integrated DNS or not. >>>>>>>>>> Side-question is what to do if a first server is installed with >>>>>>>>>> external-DNS but another replica is being installed with >>>>>>>>>> integrated-DNS and so on. >>>>>>>>> >>>>>>>>> I think being able to integrate with an external DNS is >>>>>>>>> important, and not just at the server level, being able to >>>>>>>>> distribute TSIG keys to client would be nice too, though a lot >>>>>>>>> less important, than getting server integration.. >>>>>>>> >>>>>>>> Using TSIG on many clients is very problematic. Keep in mind that >>>>>>>> TSIG is basically HMAC computed using symmetric key so: >>>>>>>> a) Every client would have to use the same key - this is a >>>>>>>> security nightmare. b) We would have to distribute and maintain >>>>>>>> many keys for many^2 clients, which is an administrative >>>>>>>> nightmare. >>>>>>>> >>>>>>>> For *clients* I would rather stay with GSS-TSIG which is much more >>>>>>>> manageable because we can use Kerberos trust and Keytab >>>>>>>> distribution is already solved by ipa-client-install. >>>>>>>> >>>>>>>> Alternative for clients would be to use FreeIPA server as proxy >>>>>>>> which encapsulates TSIG keys and issues update requests on behalf >>>>>>>> of clients. This would be FreeIPA-specific but any >>>>>>>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>>>>>>> >>>>>>>> TSIG standard explicitly says that there is no standardized >>>>>>>> distribution mechanism. >>>>>>>> >>>>>>>>>> In other words, the question is if current "dns.py" plugin >>>>>>>>>> shipped with FreeIPA framework should be: >>>>>>>>>> >>>>>>>>>> a) Extended dns.py with dnsexternal-* commands >>>>>>>>>> ---------------------------------------------- >>>>>>>>>> Disadvantages: >>>>>>>>>> - It complicate FreeIPA DNS interface which is a complex beast >>>>>>>>>> even now. >>>>>>>>>> - We would have add condition to every DNS API call in >>>>>>>>>> installers which would increase horribleness of the installer >>>>>>>>>> code even more (or add another layer of abstraction...). >>>>>>>>> >>>>>>>>> I agree having a special command is undesirable. >>>>>>>>>> >>>>>>>>>> - I don't see a point in using integrated-DNS with external-DNS >>>>>>>>>> at the same time. To use integrated-DNS you have to get a >>>>>>>>>> proper DNS delegation from parent domain - and if you can get >>>>>>>>>> the delegation then there is no point in using external DNS ... >>>>>>>>> >>>>>>>>> I disagree on this point, it makes a lot of sense to have some >>>>>>>>> zones maintained by IPA and ... some not. >>>>>>>>> >>>>>>>>>> Advantages: >>>>>>>>>> - You can use external & integrated DNS at the same time. >>>>>>>>> >>>>>>>>> We can achieve the same w/o a new ipa level command. >>>>>>>> >>>>>>>> This needs to be decided by FreeIPA framework experts ... >>>>>>>> >>>>>>>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>>>>>>> proxy would provide all ipa dns* commands and dispatch user-issued >>>>>>>> commands to appropriate FreeIPA-plugin (internal-dns or >>>>>>>> external-dns). This decision could depend on some values in LDAP. >>>>>>>> >>>>>>>>>> b) Replace dns.py with another implementation of current >>>>>>>>>> dnszone-* & dnsrecord-* API. >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> This seems like a cleaner approach to me. It could be shipped as >>>>>>>>>> ipa-server-dns-external package (opposed to "standard" >>>>>>>>>> ipa-server-dns package). >>>>>>>>>> >>>>>>>>>> Advantages: >>>>>>>>>> - It could seamlessly work with FreeIPA client installer because >>>>>>>>>> the dns*->nsupdate command transformation would be done on >>>>>>>>>> FreeIPA server and client doesn't need to know about it. >>>>>>>>>> - Does not require re-training/not much new documentation >>>>>>>>>> because commands are the same. >>>>>>>>>> >>>>>>>>>> Disadvantages: >>>>>>>>>> - You can't use integrated & external DNS at the same time (but >>>>>>>>>> I don't think it justifies the added complexity). >>>>>>>>> >>>>>>>>> I disagree. >>>>>>>>> >>>>>>>>> One of the reason to use a mix is to allow smooth migrations >>>>>>>>> where zones are moved into (or out of) IPA one by one. >>>>>>>> >>>>>>>> Good point, I agree. I will focus on supporting both (internal and >>>>>>>> external) DNS at the same time. >>>>>>>> >>>>>>>>>> Petr^3 or anyone else, what do you propose? >>>>>>>>> >>>>>>>>> I think what I'd like to see is to be able to configure a DNS >>>>>>>>> zone in LDAP and mark it external. >>>>>>>>> The zone would held the TSIG keys necessary to perform DNS >>>>>>>>> updates. >>>>>>>>> >>>>>>>>> When the regular ipa dnsrecord-add etc... commands are called, >>>>>>>>> the framework detects that the zone is "external", fewttches the >>>>>>>>> TSIG key (if the user has access to it) and spawn an nsupdate >>>>>>>>> command that will perform the update against whatever DNS server >>>>>>>>> is authoritative for the zone. >>>>>>>>> >>>>>>>>> Some commands may be disabled if the zone is external and >>>>>>>>> appropriate errors would be returned. >>>>>>>> >>>>>>>> Correct, this will be inevitable. >>>>>>>> >>>>>>>>>> 2) Authentication to external DNS server/keys >>>>>>>>>> ============================================= >>>>>>>>>> This is separate problem from FreeIPA framework integration. >>>>>>>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) >>>>>>>>>> or keytabs (for DNS GSS-TSIG) and distribute them somehow to >>>>>>>>>> replicas so every replica can update DNS records as necessary. >>>>>>>>> >>>>>>>>> For TSIG keys I think we should just store them in a LDAP record, >>>>>>>>> see above. >>>>>>>> >>>>>>>> Without any encryption? Am I missing something? >>>>>>>> >>>>>>>>> For keytabs we can simply store them just like any other >>>>>>>>> kerberos key if we really need it (in a trust case for example, >>>>>>>>> we may not need a new keytab, we may be allowed to use our own >>>>>>>>> credentials through the trust. So we'll need to explore a bit >>>>>>>>> how to properly express that in configuration. REtrieval ok >>>>>>>>> keytabs is then just a matter of running ipa-getkeytab -r on the >>>>>>>>> replica that needs it. >>>>>>>>> >>>>>>>>>> This will be the funny part because in case of AD trusts we have >>>>>>>>>> chicken-egg problem. You need to establish trust to get ticket >>>>>>>>>> for DNS/dc1.ad.example at AD principal but you can't (I guess) >>>>>>>>>> establish trust until proper DNS records are in place ... >>>>>>>>> >>>>>>>>> No, in this case we should create the records at trust >>>>>>>>> establishment time using the admin credentials we have been >>>>>>>>> provided. NO chicken-egg issue. >>>>>>>> >>>>>>>> Sorry, we surely *have* a chicken-egg issue because >>>>>>>> ipa-server-install is completely separate step from from >>>>>>>> ipa-adtrust-install which is completely separate from ipa >>>>>>>> trust-add. (And there is nothing which forces user to establish AD >>>>>>>> trust right after ipa-server-install finished.) >>>>>>>> >>>>>>>> Also, in some cases it is not possible to use the same credentials >>>>>>>> for trust establishment and for DNS updates on AD. Think about >>>>>>>> one-way trust or possibly two-way trust but established using >>>>>>>> pre-shared trust secret (which is AFAIK not usable for kinit). >>>>>>>> >>>>>>>> Alexander, could you clarify if it is possible to create an AD >>>>>>>> trust *without* DNS records for FreeIPA side of the trust? >>>>>>>> >>>>>>>> Another problem is that reliance on AD trusts would effectively >>>>>>>> prevent interoperability with non-AD DNS servers (think Infoblox >>>>>>>> or standard BIND). >>>>>>>> >>>>>>>> I tend to think that we will need to obtain credentials (AD >>>>>>>> login/pass/keytab/TSIG key) as one of ipa-server-install >>>>>>>> parameters so all DNS updates can be done right away. This would >>>>>>>> allow us have ipa-server-install script which in fact produces >>>>>>>> *working* FreeIPA domain. In other cases ipa-server-install would >>>>>>>> end but the FreeIPA domain would not be functional because of >>>>>>>> missing records in DNS. >>>>>>>> >>>>>>>>>> For 'experimental' phase I would go with pre-populated CCcache, >>>>>>>>>> i.e. admin will manually do kinit Administrator at AD and then run >>>>>>>>>> FreeIPA installer. >>>>>>>>> >>>>>>>>> We already to this, so there is no need to invent anything here >>>>>>>>> IMO. >>>>>>>> >>>>>>>> Except for cases mentioned above ... >>>>>>>> >>>>>>>>>> Maybe we can re-use trust secret somehow? I don't know, I will >>>>>>>>>> reach out to AD experts with questions. >>>>>>>>>> >>>>>>>>>> This area needs more research but for now it seems feasible to >>>>>>>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs >>>>>>>>>> so "only" the chicken-egg problem is left. >>>>>>>>>> >>>>>>>>>> This will need new LDAP schema but I will propose something when >>>>>>>>>> I'm done with investigation. >>>>>>>>> >>>>>>>>> Please let me know if you agree with a new zone type as a way to >>>>>>>>> "forward" updates. >>>>>>>> >>>>>>>> Generally I agree, it was my plan too. My main concern is not >>>>>>>> about LDAP structure but about FreeIPA framework and about >>>>>>>> workflow in general. It will be fun to extend the spaghetti code >>>>>>>> we have ... >>>>>>> >>>>>>> Ping :-) I would like to move the discussion forward. >>>>>>> >>>>>>> Alexander, could you please comment on authentication to AD >>>>>>> mentioned above? >>>>>>> >>>>>>> Simo and everybody else, what do you think about client use-case, >>>>>>> i.e. forwarding DNS updates from FreeIPA clients to external DNS >>>>>>> infrastructure? What about security implications (keeping in mind >>>>>>> that TSIG keys are symmetric)? >>>>>>> >>>>>>> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy >>>>>>> instead of nsupdate command (to hide TSIG key behind FreeIPA)? >>>>>> >>>>>> Remind me this, when a client tries to update the DNS, does it >>>>>> always contact its own DNS server first, or does it try to go >>>>>> straight to the authoritative DNS server? >>>>> >>>>> It should go straight to authoritative servers listed in NS records. >>>>> >>>>>> I do not like the XML-RPC->DNS approach as it requires a special >>>>>> client, leaving out the majority of clients. >>>>> >>>>> Yes, it is an option of last resort (because I don't see a way how to >>>>> be compatible with standard clients, see the point above). >>>>> >>>>>> Also, I am thinking that we only _need_ to set infrastructure >>>>>> relevant names (like IPA servers SRV records), but if someone >>>>>> decides not to use IPA for the DNS we may decide that it is not our >>>>>> responsibility to provide a full end-to-end client dns update >>>>>> solution. >>>>> >>>>> If we can agree on that then I'm fine with it. >>>> >>>> Yes the more I think of it, the more I prefer to wait in trying to >>>> solve the clients problem. >>>> >>>>>> So I would concentrate on making it possible for IPA *Servers* to >>>>>> use a private TSIG key to update infrastructure relevant names, and >>>>>> possibly defer the clients side of the problem. >>>>> >>>>> Speaking about native clients, two-way AD trust should nicely work >>>>> with clients because clients could go straight to the AD and >>>>> authenticate using host keytab from FreeIPA realm. It will not work >>>>> in other cases but it is still better than nothing. >>>> >>>> Yes, this has been accounted for. >>>> >>>>>> We could use an internal bus on the server to allow the ipa >>>>>> framework to use nsupdate w/o gaining direct access to the TSIG >>>>>> key, this way admins can use ipa dnsrecod-add and friends w/o >>>>>> exposing the key. >>>>> >>>>> I agree with the idea but it depends on an authorization daemon you >>>>> have proposed earlier (in different discussion). Do you see it as >>>>> reasonable goal for FreeIPA 4.2 time-span? >>>> >>>> I wouldn't say a definite no, but I am not confident we can. >>>> >>>>> If the authorization daemon is too far away, would it be okay to >>>>> support external DNS domains only for ipa* installers but do not >>>>> support it for FreeIPA users? (I.e. basically store the key in HSM >>>>> which is not accessible to users - that is what we do with DNSSEC >>>>> keys now.) >>>> >>>> Yes I think it would be fine as a first step. >>> >>> Okay, I tried to summarize current goals on: >>> http://www.freeipa.org/page/V4/External_DNS_integration_with_installer >>> >>> At the moment I see a first obstacle: >>> $ ipa-replica-manage can authenticate to LDAP servers using: >>> - LDAPI (when running as root) >>> - GSSAPI >>> - DM password >>> >>> The problem is that we would need to have access to TSIG keys even when using >>> GSSAPI and DM password authentication ... so we again need the authorization >>> daemon. >>> >>> >>> Alternatively we can use Vault for TSIG key storage and use Vault's capability >>> to share keys among many users. In that case we don't have problem with key >>> distribution nor authorization. >> >> I am not convinced we should grow Vault dependency for this functionality, it >> requires the whole PKI machinery to be available. Many deployments do not use >> it though. >> >>> Another possibility is to say that replica-deletion can be done only by root >>> user or that updates to external DNS are supported only when running >>> ipa-replica-manage as root. >> >> Why does root help? So that TSIG keys will be available on all IPA servers, >> regardless whether they have DNS service running or not? > The point is that we need to store TSIG keys "somewhere" to make them > available to ipa* scripts on all replica but at the same not to human-users. > > BTW there don't need to be any 'DNS service' if only external DNS integration > is in use. > >> It would be better to have the TSIG keys available using standard FreeIPA RBAC >> roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I >> missing anything? > > Ideologically - no, it sounds fine. > Technically - the problem is in implementation. We need a mechanism for secure > key distribution *among users*, i.e. Vault-like functionality. I would rather > not re-implement Vault just for external DNS. > > I think that external DNS could depend on Vault (assuming that external DNS > support will be purely optional). > > DNSSEC key distribution is very different because it distributes keys to > *servers* and there is no ACI mechanism on top of that - all DNS servers need > to know all the keys anyway. So IIUC, the goal would be to put TSIG keys in the Vault and then make them available for all IPA servers? I am now not sure if the Vault as proposed can easily select a group of principals to allow reading the Vault or if it is only confined for the owner/user principal. We would need to ask Endi (CCed). From pspacek at redhat.com Wed Dec 10 14:59:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 10 Dec 2014 15:59:52 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <54885DAF.2090408@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> <5488550A.3000400@redhat.com> <54885DAF.2090408@redhat.com> Message-ID: <54885FE8.8060309@redhat.com> On 10.12.2014 15:50, Martin Kosek wrote: > On 12/10/2014 03:13 PM, Petr Spacek wrote: >> On 9.12.2014 13:40, Martin Kosek wrote: >>> On 12/03/2014 05:04 PM, Petr Spacek wrote: >>>> On 2.12.2014 17:21, Simo Sorce wrote: >>>>> On Tue, 02 Dec 2014 15:56:28 +0100 >>>>> Petr Spacek wrote: >>>>> >>>>>> On 1.12.2014 17:12, Simo Sorce wrote: >>>>>>> On Mon, 01 Dec 2014 16:17:54 +0100 >>>>>>> Petr Spacek wrote: >>>>>>> >>>>>>>> On 14.11.2014 17:31, Petr Spacek wrote: >>>>>>>>> On 14.11.2014 02:22, Simo Sorce wrote: >>>>>>>>>> On Tue, 11 Nov 2014 16:29:51 +0100 >>>>>>>>>> Petr Spacek wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> this thread is about RFE >>>>>>>>>>> "IPA servers when installed should register themselves in the >>>>>>>>>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424 >>>>>>>>>>> >>>>>>>>>>> It is not a complete design, just a raw idea. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Use case >>>>>>>>>>> ======== >>>>>>>>>>> FreeIPA installation to a network with existing DNS >>>>>>>>>>> infrastructure + network administrator who is not willing to >>>>>>>>>>> add/maintain new DNS servers "just for FreeIPA". >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> High-level idea >>>>>>>>>>> =============== >>>>>>>>>>> - Transform dns* commands from FreeIPA framework to equivalent >>>>>>>>>>> "nsupdate" commands and send DNS updates to existing DNS >>>>>>>>>>> servers. >>>>>>>>>>> - Provide necessary encryption/signing keys to nsupdate. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1) Integration to FreeIPA framework >>>>>>>>>>> =================================== >>>>>>>>>>> First of all, we need to decide if "external DNS integration" >>>>>>>>>>> can be used at the same time with FreeIPA-integrated DNS or not. >>>>>>>>>>> Side-question is what to do if a first server is installed with >>>>>>>>>>> external-DNS but another replica is being installed with >>>>>>>>>>> integrated-DNS and so on. >>>>>>>>>> >>>>>>>>>> I think being able to integrate with an external DNS is >>>>>>>>>> important, and not just at the server level, being able to >>>>>>>>>> distribute TSIG keys to client would be nice too, though a lot >>>>>>>>>> less important, than getting server integration.. >>>>>>>>> >>>>>>>>> Using TSIG on many clients is very problematic. Keep in mind that >>>>>>>>> TSIG is basically HMAC computed using symmetric key so: >>>>>>>>> a) Every client would have to use the same key - this is a >>>>>>>>> security nightmare. b) We would have to distribute and maintain >>>>>>>>> many keys for many^2 clients, which is an administrative >>>>>>>>> nightmare. >>>>>>>>> >>>>>>>>> For *clients* I would rather stay with GSS-TSIG which is much more >>>>>>>>> manageable because we can use Kerberos trust and Keytab >>>>>>>>> distribution is already solved by ipa-client-install. >>>>>>>>> >>>>>>>>> Alternative for clients would be to use FreeIPA server as proxy >>>>>>>>> which encapsulates TSIG keys and issues update requests on behalf >>>>>>>>> of clients. This would be FreeIPA-specific but any >>>>>>>>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>>>>>>>> >>>>>>>>> TSIG standard explicitly says that there is no standardized >>>>>>>>> distribution mechanism. >>>>>>>>> >>>>>>>>>>> In other words, the question is if current "dns.py" plugin >>>>>>>>>>> shipped with FreeIPA framework should be: >>>>>>>>>>> >>>>>>>>>>> a) Extended dns.py with dnsexternal-* commands >>>>>>>>>>> ---------------------------------------------- >>>>>>>>>>> Disadvantages: >>>>>>>>>>> - It complicate FreeIPA DNS interface which is a complex beast >>>>>>>>>>> even now. >>>>>>>>>>> - We would have add condition to every DNS API call in >>>>>>>>>>> installers which would increase horribleness of the installer >>>>>>>>>>> code even more (or add another layer of abstraction...). >>>>>>>>>> >>>>>>>>>> I agree having a special command is undesirable. >>>>>>>>>>> >>>>>>>>>>> - I don't see a point in using integrated-DNS with external-DNS >>>>>>>>>>> at the same time. To use integrated-DNS you have to get a >>>>>>>>>>> proper DNS delegation from parent domain - and if you can get >>>>>>>>>>> the delegation then there is no point in using external DNS ... >>>>>>>>>> >>>>>>>>>> I disagree on this point, it makes a lot of sense to have some >>>>>>>>>> zones maintained by IPA and ... some not. >>>>>>>>>> >>>>>>>>>>> Advantages: >>>>>>>>>>> - You can use external & integrated DNS at the same time. >>>>>>>>>> >>>>>>>>>> We can achieve the same w/o a new ipa level command. >>>>>>>>> >>>>>>>>> This needs to be decided by FreeIPA framework experts ... >>>>>>>>> >>>>>>>>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>>>>>>>> proxy would provide all ipa dns* commands and dispatch user-issued >>>>>>>>> commands to appropriate FreeIPA-plugin (internal-dns or >>>>>>>>> external-dns). This decision could depend on some values in LDAP. >>>>>>>>> >>>>>>>>>>> b) Replace dns.py with another implementation of current >>>>>>>>>>> dnszone-* & dnsrecord-* API. >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> This seems like a cleaner approach to me. It could be shipped as >>>>>>>>>>> ipa-server-dns-external package (opposed to "standard" >>>>>>>>>>> ipa-server-dns package). >>>>>>>>>>> >>>>>>>>>>> Advantages: >>>>>>>>>>> - It could seamlessly work with FreeIPA client installer because >>>>>>>>>>> the dns*->nsupdate command transformation would be done on >>>>>>>>>>> FreeIPA server and client doesn't need to know about it. >>>>>>>>>>> - Does not require re-training/not much new documentation >>>>>>>>>>> because commands are the same. >>>>>>>>>>> >>>>>>>>>>> Disadvantages: >>>>>>>>>>> - You can't use integrated & external DNS at the same time (but >>>>>>>>>>> I don't think it justifies the added complexity). >>>>>>>>>> >>>>>>>>>> I disagree. >>>>>>>>>> >>>>>>>>>> One of the reason to use a mix is to allow smooth migrations >>>>>>>>>> where zones are moved into (or out of) IPA one by one. >>>>>>>>> >>>>>>>>> Good point, I agree. I will focus on supporting both (internal and >>>>>>>>> external) DNS at the same time. >>>>>>>>> >>>>>>>>>>> Petr^3 or anyone else, what do you propose? >>>>>>>>>> >>>>>>>>>> I think what I'd like to see is to be able to configure a DNS >>>>>>>>>> zone in LDAP and mark it external. >>>>>>>>>> The zone would held the TSIG keys necessary to perform DNS >>>>>>>>>> updates. >>>>>>>>>> >>>>>>>>>> When the regular ipa dnsrecord-add etc... commands are called, >>>>>>>>>> the framework detects that the zone is "external", fewttches the >>>>>>>>>> TSIG key (if the user has access to it) and spawn an nsupdate >>>>>>>>>> command that will perform the update against whatever DNS server >>>>>>>>>> is authoritative for the zone. >>>>>>>>>> >>>>>>>>>> Some commands may be disabled if the zone is external and >>>>>>>>>> appropriate errors would be returned. >>>>>>>>> >>>>>>>>> Correct, this will be inevitable. >>>>>>>>> >>>>>>>>>>> 2) Authentication to external DNS server/keys >>>>>>>>>>> ============================================= >>>>>>>>>>> This is separate problem from FreeIPA framework integration. >>>>>>>>>>> We will have to somehow store raw symmetric keys (for DNS TSIG) >>>>>>>>>>> or keytabs (for DNS GSS-TSIG) and distribute them somehow to >>>>>>>>>>> replicas so every replica can update DNS records as necessary. >>>>>>>>>> >>>>>>>>>> For TSIG keys I think we should just store them in a LDAP record, >>>>>>>>>> see above. >>>>>>>>> >>>>>>>>> Without any encryption? Am I missing something? >>>>>>>>> >>>>>>>>>> For keytabs we can simply store them just like any other >>>>>>>>>> kerberos key if we really need it (in a trust case for example, >>>>>>>>>> we may not need a new keytab, we may be allowed to use our own >>>>>>>>>> credentials through the trust. So we'll need to explore a bit >>>>>>>>>> how to properly express that in configuration. REtrieval ok >>>>>>>>>> keytabs is then just a matter of running ipa-getkeytab -r on the >>>>>>>>>> replica that needs it. >>>>>>>>>> >>>>>>>>>>> This will be the funny part because in case of AD trusts we have >>>>>>>>>>> chicken-egg problem. You need to establish trust to get ticket >>>>>>>>>>> for DNS/dc1.ad.example at AD principal but you can't (I guess) >>>>>>>>>>> establish trust until proper DNS records are in place ... >>>>>>>>>> >>>>>>>>>> No, in this case we should create the records at trust >>>>>>>>>> establishment time using the admin credentials we have been >>>>>>>>>> provided. NO chicken-egg issue. >>>>>>>>> >>>>>>>>> Sorry, we surely *have* a chicken-egg issue because >>>>>>>>> ipa-server-install is completely separate step from from >>>>>>>>> ipa-adtrust-install which is completely separate from ipa >>>>>>>>> trust-add. (And there is nothing which forces user to establish AD >>>>>>>>> trust right after ipa-server-install finished.) >>>>>>>>> >>>>>>>>> Also, in some cases it is not possible to use the same credentials >>>>>>>>> for trust establishment and for DNS updates on AD. Think about >>>>>>>>> one-way trust or possibly two-way trust but established using >>>>>>>>> pre-shared trust secret (which is AFAIK not usable for kinit). >>>>>>>>> >>>>>>>>> Alexander, could you clarify if it is possible to create an AD >>>>>>>>> trust *without* DNS records for FreeIPA side of the trust? >>>>>>>>> >>>>>>>>> Another problem is that reliance on AD trusts would effectively >>>>>>>>> prevent interoperability with non-AD DNS servers (think Infoblox >>>>>>>>> or standard BIND). >>>>>>>>> >>>>>>>>> I tend to think that we will need to obtain credentials (AD >>>>>>>>> login/pass/keytab/TSIG key) as one of ipa-server-install >>>>>>>>> parameters so all DNS updates can be done right away. This would >>>>>>>>> allow us have ipa-server-install script which in fact produces >>>>>>>>> *working* FreeIPA domain. In other cases ipa-server-install would >>>>>>>>> end but the FreeIPA domain would not be functional because of >>>>>>>>> missing records in DNS. >>>>>>>>> >>>>>>>>>>> For 'experimental' phase I would go with pre-populated CCcache, >>>>>>>>>>> i.e. admin will manually do kinit Administrator at AD and then run >>>>>>>>>>> FreeIPA installer. >>>>>>>>>> >>>>>>>>>> We already to this, so there is no need to invent anything here >>>>>>>>>> IMO. >>>>>>>>> >>>>>>>>> Except for cases mentioned above ... >>>>>>>>> >>>>>>>>>>> Maybe we can re-use trust secret somehow? I don't know, I will >>>>>>>>>>> reach out to AD experts with questions. >>>>>>>>>>> >>>>>>>>>>> This area needs more research but for now it seems feasible to >>>>>>>>>>> re-use DNSSEC key distribution system for TSIG keys and keytabs >>>>>>>>>>> so "only" the chicken-egg problem is left. >>>>>>>>>>> >>>>>>>>>>> This will need new LDAP schema but I will propose something when >>>>>>>>>>> I'm done with investigation. >>>>>>>>>> >>>>>>>>>> Please let me know if you agree with a new zone type as a way to >>>>>>>>>> "forward" updates. >>>>>>>>> >>>>>>>>> Generally I agree, it was my plan too. My main concern is not >>>>>>>>> about LDAP structure but about FreeIPA framework and about >>>>>>>>> workflow in general. It will be fun to extend the spaghetti code >>>>>>>>> we have ... >>>>>>>> >>>>>>>> Ping :-) I would like to move the discussion forward. >>>>>>>> >>>>>>>> Alexander, could you please comment on authentication to AD >>>>>>>> mentioned above? >>>>>>>> >>>>>>>> Simo and everybody else, what do you think about client use-case, >>>>>>>> i.e. forwarding DNS updates from FreeIPA clients to external DNS >>>>>>>> infrastructure? What about security implications (keeping in mind >>>>>>>> that TSIG keys are symmetric)? >>>>>>>> >>>>>>>> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy >>>>>>>> instead of nsupdate command (to hide TSIG key behind FreeIPA)? >>>>>>> >>>>>>> Remind me this, when a client tries to update the DNS, does it >>>>>>> always contact its own DNS server first, or does it try to go >>>>>>> straight to the authoritative DNS server? >>>>>> >>>>>> It should go straight to authoritative servers listed in NS records. >>>>>> >>>>>>> I do not like the XML-RPC->DNS approach as it requires a special >>>>>>> client, leaving out the majority of clients. >>>>>> >>>>>> Yes, it is an option of last resort (because I don't see a way how to >>>>>> be compatible with standard clients, see the point above). >>>>>> >>>>>>> Also, I am thinking that we only _need_ to set infrastructure >>>>>>> relevant names (like IPA servers SRV records), but if someone >>>>>>> decides not to use IPA for the DNS we may decide that it is not our >>>>>>> responsibility to provide a full end-to-end client dns update >>>>>>> solution. >>>>>> >>>>>> If we can agree on that then I'm fine with it. >>>>> >>>>> Yes the more I think of it, the more I prefer to wait in trying to >>>>> solve the clients problem. >>>>> >>>>>>> So I would concentrate on making it possible for IPA *Servers* to >>>>>>> use a private TSIG key to update infrastructure relevant names, and >>>>>>> possibly defer the clients side of the problem. >>>>>> >>>>>> Speaking about native clients, two-way AD trust should nicely work >>>>>> with clients because clients could go straight to the AD and >>>>>> authenticate using host keytab from FreeIPA realm. It will not work >>>>>> in other cases but it is still better than nothing. >>>>> >>>>> Yes, this has been accounted for. >>>>> >>>>>>> We could use an internal bus on the server to allow the ipa >>>>>>> framework to use nsupdate w/o gaining direct access to the TSIG >>>>>>> key, this way admins can use ipa dnsrecod-add and friends w/o >>>>>>> exposing the key. >>>>>> >>>>>> I agree with the idea but it depends on an authorization daemon you >>>>>> have proposed earlier (in different discussion). Do you see it as >>>>>> reasonable goal for FreeIPA 4.2 time-span? >>>>> >>>>> I wouldn't say a definite no, but I am not confident we can. >>>>> >>>>>> If the authorization daemon is too far away, would it be okay to >>>>>> support external DNS domains only for ipa* installers but do not >>>>>> support it for FreeIPA users? (I.e. basically store the key in HSM >>>>>> which is not accessible to users - that is what we do with DNSSEC >>>>>> keys now.) >>>>> >>>>> Yes I think it would be fine as a first step. >>>> >>>> Okay, I tried to summarize current goals on: >>>> http://www.freeipa.org/page/V4/External_DNS_integration_with_installer >>>> >>>> At the moment I see a first obstacle: >>>> $ ipa-replica-manage can authenticate to LDAP servers using: >>>> - LDAPI (when running as root) >>>> - GSSAPI >>>> - DM password >>>> >>>> The problem is that we would need to have access to TSIG keys even when using >>>> GSSAPI and DM password authentication ... so we again need the authorization >>>> daemon. >>>> >>>> >>>> Alternatively we can use Vault for TSIG key storage and use Vault's capability >>>> to share keys among many users. In that case we don't have problem with key >>>> distribution nor authorization. >>> >>> I am not convinced we should grow Vault dependency for this functionality, it >>> requires the whole PKI machinery to be available. Many deployments do not use >>> it though. >>> >>>> Another possibility is to say that replica-deletion can be done only by root >>>> user or that updates to external DNS are supported only when running >>>> ipa-replica-manage as root. >>> >>> Why does root help? So that TSIG keys will be available on all IPA servers, >>> regardless whether they have DNS service running or not? >> The point is that we need to store TSIG keys "somewhere" to make them >> available to ipa* scripts on all replica but at the same not to human-users. >> >> BTW there don't need to be any 'DNS service' if only external DNS integration >> is in use. >> >>> It would be better to have the TSIG keys available using standard FreeIPA RBAC >>> roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I >>> missing anything? >> >> Ideologically - no, it sounds fine. >> Technically - the problem is in implementation. We need a mechanism for secure >> key distribution *among users*, i.e. Vault-like functionality. I would rather >> not re-implement Vault just for external DNS. >> >> I think that external DNS could depend on Vault (assuming that external DNS >> support will be purely optional). >> >> DNSSEC key distribution is very different because it distributes keys to >> *servers* and there is no ACI mechanism on top of that - all DNS servers need >> to know all the keys anyway. > > So IIUC, the goal would be to put TSIG keys in the Vault and then make them > available for all IPA servers? > > I am now not sure if the Vault as proposed can easily select a group of > principals to allow reading the Vault or if it is only confined for the > owner/user principal. We would need to ask Endi (CCed). I assumed that very first sentence of http://www.freeipa.org/page/V4/Password_Vault_Implementation#Vault "Vault is a secure place to store data or a collection of secrets. A vault may be privately owned by a user, or shared among users, groups, or services." is correct :-) Endi, we would like to have one secret which is shared among services & users at the same time. Is it possible to do that with Vault? -- Petr^2 Spacek From mkosek at redhat.com Wed Dec 10 15:02:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Dec 2014 16:02:08 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54884C3C.4020600@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> <54818C56.6050201@redhat.com> <5481908D.2010706@redhat.com> <5486F185.1010300@redhat.com> <54882638.7050503@redhat.com> <54884C3C.4020600@redhat.com> Message-ID: <54886070.2090907@redhat.com> On 12/10/2014 02:35 PM, Jan Cholasta wrote: > Dne 10.12.2014 v 11:53 Martin Kosek napsal(a): >> On 12/09/2014 01:56 PM, Jan Cholasta wrote: >>> Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): >>>> Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): >>>>> On 12/05/2014 11:34 AM, Jan Cholasta wrote: >>>>>> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >>>>>>> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>>>>>>> + if x509.get_der_subject(cert, x509.DER) != der_subject: >>>>>>>> + raise admintool.ScriptError("Subject name encoding >>>>>>>> mismatch") >>>>>>> >>>>>>> I think we can expect this to be a pretty common error, given this is >>>>>>> the default behavior of Microsoft Certificate Services. I would thus >>>>>>> like to make the error message more juicy. >>>>>>> >>>>>>> We need to make sure we offer some pointers for these users or they >>>>>>> will >>>>>>> just blame IPA for screwing up. So, the information I wrote >>>>>>> >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >>>>>>> >>>>>>> need to somehow get to the error message as a potential/likely root >>>>>>> cause of the problem. Whether you write it in the error message itself >>>>>>> or update the design page and just insert a link is up to you. >>>>>>> >>>>>>> Martin >>>>>> >>>>>> I would rather document this and have users read the documentation, >>>>>> which they >>>>>> should do anyway when something goes wrong. There are many errors in >>>>>> IPA which >>>>>> are common and users may blame IPA for them and I don't see what makes >>>>>> this one >>>>>> so special that it should require a special treatment. >>>>> >>>>> I saw several reasons: >>>>> - Certificate&installation error are more common than the others and >>>>> users are usually quite lost in what to do with them. >>>>> - In this case, we know by 90% probability what is the root cause >>>>> - It will block one of the main use cases for the new CA renewal tool >>>>> and people will likely hit it as MS CAs is one of the most common CAs >>>>> and this is it's default behavior. >>>>> >>>>> Giving more details in this case will not hurt us, but benefit users. So >>>>> I still do not see the harm. >>>> >>>> I do not see a harm either, my point is that we should probably point >>>> the user to documentation when *anything* in *any* script goes wrong, >>>> not just when some arbitrarily cherry-picked error occurs. >>>> >>>>> >>>>>> Anyway, I have created >>>>>> . >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Good. Do you plan to reference the section or enhance the error message? >>>> >>>> I plan to reference . >>> >>> See the attached patch (385). >> >> I think the reference for the Troubleshooting page should be more narrow so >> that people only see the URL only for the cases we give specific advise for. >> Otherwise I assume they will just ignore the page if they do not find the >> advise for other errors. > > Right, makes sense. > >> >> Other idea would be to give reference to the article when the actual CSR is >> generated - as a heads up. > > I think referring to troubleshooting before there actually is some trouble is > not very good for publicity. Ah, that's a good point - in this purpose it would be better to have it somewhere else or only refer to the MS article. > Anyway, updated patch attached, it implements what you suggested originally - > link to the troubleshooting guide is added to relevant error messages. Let's > think about this in more broad terms when the time comes for the installer > refactoring. Ok. I am fine with the patch conceptually. So now just someone (David?) needs to make sure it did not break anything :-) Martin From mbasti at redhat.com Wed Dec 10 15:02:44 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Dec 2014 16:02:44 +0100 Subject: [Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager In-Reply-To: References: Message-ID: <54886094.3040605@redhat.com> On 10/12/14 15:45, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4783 > > Thanks, > > Gabe Hello, thanks for patch. The patch needs rebase for IPA-4-1 branch Martin^2 -- Martin Basti From mbasti at redhat.com Wed Dec 10 16:53:25 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Dec 2014 17:53:25 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54886070.2090907@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> <54818C56.6050201@redhat.com> <5481908D.2010706@redhat.com> <5486F185.1010300@redhat.com> <54882638.7050503@redhat.com> <54884C3C.4020600@redhat.com> <54886070.2090907@redhat.com> Message-ID: <54887A85.60302@redhat.com> On 10/12/14 16:02, Martin Kosek wrote: > On 12/10/2014 02:35 PM, Jan Cholasta wrote: >> Dne 10.12.2014 v 11:53 Martin Kosek napsal(a): >>> On 12/09/2014 01:56 PM, Jan Cholasta wrote: >>>> Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): >>>>> Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): >>>>>> On 12/05/2014 11:34 AM, Jan Cholasta wrote: >>>>>>> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >>>>>>>> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>>>>>>>> + if x509.get_der_subject(cert, x509.DER) != der_subject: >>>>>>>>> + raise admintool.ScriptError("Subject name encoding >>>>>>>>> mismatch") >>>>>>>> I think we can expect this to be a pretty common error, given this is >>>>>>>> the default behavior of Microsoft Certificate Services. I would thus >>>>>>>> like to make the error message more juicy. >>>>>>>> >>>>>>>> We need to make sure we offer some pointers for these users or they >>>>>>>> will >>>>>>>> just blame IPA for screwing up. So, the information I wrote >>>>>>>> >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >>>>>>>> >>>>>>>> need to somehow get to the error message as a potential/likely root >>>>>>>> cause of the problem. Whether you write it in the error message itself >>>>>>>> or update the design page and just insert a link is up to you. >>>>>>>> >>>>>>>> Martin >>>>>>> I would rather document this and have users read the documentation, >>>>>>> which they >>>>>>> should do anyway when something goes wrong. There are many errors in >>>>>>> IPA which >>>>>>> are common and users may blame IPA for them and I don't see what makes >>>>>>> this one >>>>>>> so special that it should require a special treatment. >>>>>> I saw several reasons: >>>>>> - Certificate&installation error are more common than the others and >>>>>> users are usually quite lost in what to do with them. >>>>>> - In this case, we know by 90% probability what is the root cause >>>>>> - It will block one of the main use cases for the new CA renewal tool >>>>>> and people will likely hit it as MS CAs is one of the most common CAs >>>>>> and this is it's default behavior. >>>>>> >>>>>> Giving more details in this case will not hurt us, but benefit users. So >>>>>> I still do not see the harm. >>>>> I do not see a harm either, my point is that we should probably point >>>>> the user to documentation when *anything* in *any* script goes wrong, >>>>> not just when some arbitrarily cherry-picked error occurs. >>>>> >>>>>>> Anyway, I have created >>>>>>> . >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Good. Do you plan to reference the section or enhance the error message? >>>>> I plan to reference . >>>> See the attached patch (385). >>> I think the reference for the Troubleshooting page should be more narrow so >>> that people only see the URL only for the cases we give specific advise for. >>> Otherwise I assume they will just ignore the page if they do not find the >>> advise for other errors. >> Right, makes sense. >> >>> Other idea would be to give reference to the article when the actual CSR is >>> generated - as a heads up. >> I think referring to troubleshooting before there actually is some trouble is >> not very good for publicity. > Ah, that's a good point - in this purpose it would be better to have it > somewhere else or only refer to the MS article. > >> Anyway, updated patch attached, it implements what you suggested originally - >> link to the troubleshooting guide is added to relevant error messages. Let's >> think about this in more broad terms when the time comes for the installer >> refactoring. > Ok. I am fine with the patch conceptually. So now just someone (David?) needs > to make sure it did not break anything :-) > > Martin > ACK, seems it doesnt break anything. -- Martin Basti From jcholast at redhat.com Wed Dec 10 17:01:04 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Dec 2014 18:01:04 +0100 Subject: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade In-Reply-To: <547C8DBD.2020204@redhat.com> References: <54772621.5050003@redhat.com> <547C1CE8.5000707@redhat.com> <547C8DBD.2020204@redhat.com> Message-ID: <54887C50.7070701@redhat.com> Dne 1.12.2014 v 16:48 Martin Basti napsal(a): > On 01/12/14 08:46, Jan Cholasta wrote: >> Hi, >> >> Dne 27.11.2014 v 14:24 Martin Basti napsal(a): >>> Ticket: https://fedorahosted.org/freeipa/ticket/4676 >>> Replaces current workaround. Should go to 4.1.3. >>> Patch attached. >> >> When constructing URLs with host:port, please use >> ipautil.format_netloc(). >> >> wget should be added as a dependency of freeipa-python in the spec file. >> >> Honza >> > Updated patch attached. > Thanks, ACK. Pushed to: master: 337faf506462a01c6dbcd00f2039ed5627691864 ipa-4-1: 5052af773f652bc19e91fe49e15351e5c5c7d976 -- Jan Cholasta From jcholast at redhat.com Wed Dec 10 17:07:50 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Dec 2014 18:07:50 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <5486E52E.4020008@redhat.com> References: <54801CF6.7080809@redhat.com> <5486E52E.4020008@redhat.com> Message-ID: <54887DE6.90506@redhat.com> Dne 9.12.2014 v 13:03 David Kupka napsal(a): > On 12/04/2014 09:36 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Works for me, ACK. > Thanks for the review. Pushed to: master: f7f3c83748b3b5d5d968cc3c72145f3c5f23cd8b ipa-4-1: 731035e526441b93b69fb20c6a6c990cdcdc4899 -- Jan Cholasta From jcholast at redhat.com Wed Dec 10 17:09:22 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Dec 2014 18:09:22 +0100 Subject: [Freeipa-devel] [PATCH] 383 Check subject name encoding in ipa-cacert-manage renew In-Reply-To: <54887A85.60302@redhat.com> References: <54801CF6.7080809@redhat.com> <548166B9.9090807@redhat.com> <54818A38.5010008@redhat.com> <54818C56.6050201@redhat.com> <5481908D.2010706@redhat.com> <5486F185.1010300@redhat.com> <54882638.7050503@redhat.com> <54884C3C.4020600@redhat.com> <54886070.2090907@redhat.com> <54887A85.60302@redhat.com> Message-ID: <54887E42.6070800@redhat.com> Dne 10.12.2014 v 17:53 Martin Basti napsal(a): > On 10/12/14 16:02, Martin Kosek wrote: >> On 12/10/2014 02:35 PM, Jan Cholasta wrote: >>> Dne 10.12.2014 v 11:53 Martin Kosek napsal(a): >>>> On 12/09/2014 01:56 PM, Jan Cholasta wrote: >>>>> Dne 5.12.2014 v 12:01 Jan Cholasta napsal(a): >>>>>> Dne 5.12.2014 v 11:43 Martin Kosek napsal(a): >>>>>>> On 12/05/2014 11:34 AM, Jan Cholasta wrote: >>>>>>>> Dne 5.12.2014 v 09:03 Martin Kosek napsal(a): >>>>>>>>> On 12/04/2014 09:36 AM, Jan Cholasta wrote: >>>>>>>>>> + if x509.get_der_subject(cert, x509.DER) != >>>>>>>>>> der_subject: >>>>>>>>>> + raise admintool.ScriptError("Subject name >>>>>>>>>> encoding >>>>>>>>>> mismatch") >>>>>>>>> I think we can expect this to be a pretty common error, given >>>>>>>>> this is >>>>>>>>> the default behavior of Microsoft Certificate Services. I would >>>>>>>>> thus >>>>>>>>> like to make the error message more juicy. >>>>>>>>> >>>>>>>>> We need to make sure we offer some pointers for these users or >>>>>>>>> they >>>>>>>>> will >>>>>>>>> just blame IPA for screwing up. So, the information I wrote >>>>>>>>> >>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 >>>>>>>>> >>>>>>>>> need to somehow get to the error message as a potential/likely >>>>>>>>> root >>>>>>>>> cause of the problem. Whether you write it in the error message >>>>>>>>> itself >>>>>>>>> or update the design page and just insert a link is up to you. >>>>>>>>> >>>>>>>>> Martin >>>>>>>> I would rather document this and have users read the documentation, >>>>>>>> which they >>>>>>>> should do anyway when something goes wrong. There are many >>>>>>>> errors in >>>>>>>> IPA which >>>>>>>> are common and users may blame IPA for them and I don't see what >>>>>>>> makes >>>>>>>> this one >>>>>>>> so special that it should require a special treatment. >>>>>>> I saw several reasons: >>>>>>> - Certificate&installation error are more common than the others and >>>>>>> users are usually quite lost in what to do with them. >>>>>>> - In this case, we know by 90% probability what is the root cause >>>>>>> - It will block one of the main use cases for the new CA renewal >>>>>>> tool >>>>>>> and people will likely hit it as MS CAs is one of the most common >>>>>>> CAs >>>>>>> and this is it's default behavior. >>>>>>> >>>>>>> Giving more details in this case will not hurt us, but benefit >>>>>>> users. So >>>>>>> I still do not see the harm. >>>>>> I do not see a harm either, my point is that we should probably point >>>>>> the user to documentation when *anything* in *any* script goes wrong, >>>>>> not just when some arbitrarily cherry-picked error occurs. >>>>>> >>>>>>>> Anyway, I have created >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Good. Do you plan to reference the section or enhance the error >>>>>>> message? >>>>>> I plan to reference . >>>>> See the attached patch (385). >>>> I think the reference for the Troubleshooting page should be more >>>> narrow so >>>> that people only see the URL only for the cases we give specific >>>> advise for. >>>> Otherwise I assume they will just ignore the page if they do not >>>> find the >>>> advise for other errors. >>> Right, makes sense. >>> >>>> Other idea would be to give reference to the article when the actual >>>> CSR is >>>> generated - as a heads up. >>> I think referring to troubleshooting before there actually is some >>> trouble is >>> not very good for publicity. >> Ah, that's a good point - in this purpose it would be better to have it >> somewhere else or only refer to the MS article. >> >>> Anyway, updated patch attached, it implements what you suggested >>> originally - >>> link to the troubleshooting guide is added to relevant error >>> messages. Let's >>> think about this in more broad terms when the time comes for the >>> installer >>> refactoring. >> Ok. I am fine with the patch conceptually. So now just someone >> (David?) needs >> to make sure it did not break anything :-) >> >> Martin >> > ACK, seems it doesnt break anything. > Thanks for the review. Pushed to: master: 8f9c5988e2f370cef66a4cd7cf3d363f061a439c ipa-4-1: 3cb2f5e841f5bac6a8cc02bc9467846b35f7aab8 -- Jan Cholasta From mbasti at redhat.com Wed Dec 10 17:20:38 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 10 Dec 2014 18:20:38 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <54872602.4050101@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> Message-ID: <548880E6.4010105@redhat.com> On 09/12/14 17:40, Martin Basti wrote: > On 01/12/14 17:44, Petr Spacek wrote: >> On 1.12.2014 14:39, Martin Basti wrote: >>> On 24/11/14 17:24, Petr Spacek wrote: >>>> Hello! >>>> >>>> Thank you for the patch. It is not ready yet but the overall >>>> direction seems >>>> good. Please see my comments in-line. >>>> >>>> On 24.11.2014 14:35, Martin Basti wrote: >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >>>>> Patch attached >>>>> >>>>> -- >>>>> Martin Basti >>>>> >>>>> >>>>> freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch >>>>> >>>>> >>>>> >>>>> From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 >>>>> 00:00:00 2001 >>>>> From: Martin Basti >>>>> Date: Fri, 21 Nov 2014 16:54:09 +0100 >>>>> Subject: [PATCH] Detect and warn about invalid DNS forward zone >>>>> configuration >>>>> >>>>> Shows warning if forward and parent authoritative zone do not have >>>>> proper NS record delegation, which can cause the forward zone will be >>>>> ineffective and forwarding will not work. >>>>> >>>>> The chande in the test was required due python changes order of >>>>> elemnts >>>>> in dict (python doesnt guarantee an order in dict) >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >>>>> --- >>>>> ipalib/messages.py | 12 +++ >>>>> ipalib/plugins/dns.py | 147 >>>>> +++++++++++++++++++++++++++++--- >>>>> ipatests/test_xmlrpc/test_dns_plugin.py | 2 +- >>>>> 3 files changed, 149 insertions(+), 12 deletions(-) >>>>> >>>>> diff --git a/ipalib/messages.py b/ipalib/messages.py >>>>> index >>>>> 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f >>>>> >>>>> 100644 >>>>> --- a/ipalib/messages.py >>>>> +++ b/ipalib/messages.py >>>>> @@ -200,6 +200,18 @@ class >>>>> DNSServerDoesNotSupportDNSSECWarning(PublicMessage): >>>>> u"If DNSSEC validation is enabled on IPA >>>>> server(s), " >>>>> u"please disable it.") >>>>> +class ForwardzoneIsNotEffectiveWarning(PublicMessage): >>>>> + """ >>>>> + **13008** Forwardzone is not effective, forwarding will not >>>>> work because >>>>> + there is authoritative parent zone, without proper NS delegation >>>>> + """ >>>>> + >>>>> + errno = 13008 >>>>> + type = "warning" >>>>> + format = _(u"forward zone \"%(fwzone)s\" is not effective >>>>> (missing >>>>> proper " >>>>> + u"NS delegation in authoritative zone >>>>> \"%(authzone)s\"). " >>>>> + u"Forwarding may not work.") >>>> I think that the error message could be made mode useful: >>>> >>>> "Forwarding will not work. Please add NS record >>>> >>>> to parent zone %(authzone)s" (or something like that). >>>> >>>>> + >>>>> def iter_messages(variables, base): >>>>> """Return a tuple with all subclasses >>>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>> index >>>>> c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 >>>>> >>>>> 100644 >>>>> --- a/ipalib/plugins/dns.py >>>>> +++ b/ipalib/plugins/dns.py >>>>> @@ -1725,6 +1725,79 @@ def _normalize_zone(zone): >>>>> return zone >>>>> +def _find_zone_which_makes_fw_zone_ineffective(fwzonename): >>>> Generally, this method finds an authoritative zone for given >>>> "fwzonename". >>>> What about method name _find_auth_zone_ldap(name) ? >>>> >>>>> + """ >>>>> + Check if forward zone is effective. >>>>> + >>>>> + If parent zone exists as authoritative zone, forward zone >>>>> will not >>>>> + forward queries. It is necessary to delegate authority of >>>>> forward zone >>>> I would clarify it: "forward queries by default." >>>> >>>> >>>>> + to another server (non IPA DNS server). >>>> I would personally omit "(non IPA DNS server)" because this >>>> mechanism is not >>>> related to IPA domain at all. >>>> >>>>> + Example: >>>>> + >>>>> + Forward zone: sub.example.com >>>>> + Zone: example.com >>>>> + >>>>> + Forwarding will not work, because server thinks it is >>>>> authoritative >>>>> + and returns NXDOMAIN >>>>> + >>>>> + Adding record: sub.example.com NS nameserver.out.of.ipa.domain. >>>> Again, this is not related to IPA domain at all. I propose this text: >>>> "Adding record: sub.example.com NS ns.sub.example.com." >>>> >>>>> + will delegate authority to another server, and IPA DNS server >>>>> will >>>>> + forward DNS queries. >>>>> + >>>>> + :param fwzonename: forwardzone >>>>> + :return: None if effective, name of authoritative zone otherwise >>>>> + """ >>>>> + assert isinstance(fwzonename, DNSName) >>>>> + >>>>> + # get all zones >>>>> + zones = api.Command.dnszone_find(pkey_only=True, >>>>> + sizelimit=0)['result'] >>>> Ooooh, are you serious? :-) I don't like this approach, I would >>>> rather chop >>>> left-most labels from "name" and so dnszone_find() one by one. What >>>> if you >>>> have many DNS zones? >>>> >>>> >>>> This could be thrown away if you iterate only over relevant zones. >>>>> + zonenames = [zone['idnsname'][0].make_absolute() for zone in >>>>> zones] >>>>> + zonenames.sort(reverse=True, key=len) # sort, we need >>>>> longest match >>>>> + >>>>> + # check if is there a zone which can cause the forward zone will >>>>> + # be ineffective >>>>> + sub_of_auth_zone = None >>>>> + for name in zonenames: >>>>> + if fwzonename.is_subdomain(name): >>>>> + sub_of_auth_zone = name >>>>> + break >>>>> + >>>>> + if sub_of_auth_zone is None: >>>>> + return None >>>>> + >>>>> + # check if forwardzone is delegated in authoritative zone >>>>> + # test if exists and get NS record >>>>> + try: >>>>> + ns_records = api.Command.dnsrecord_show( >>>>> + sub_of_auth_zone, fwzonename, >>>>> raw=True)['result']['nsrecord'] >>>>> + except (errors.NotFound, KeyError): >>>>> + return sub_of_auth_zone >>>> Note: This function should process only deepest (existing) >>>> sub-domain in LDAP >>>> which is active (idnsZoneActive = TRUE). >>>> >>>> Example: >>>> fwzonename = sub.fwd.example.com. >>>> Existing LDAP master zone = fwd.example.com. - DISABLED >>>> Existing LDAP master zone = example.com. >>>> Existing LDAP master zone = com. >>>> >>>> 1) Check existence & activity of fwd.example.com. -> does not >>>> exist, continue. >>>> 2) Check existence & activity of example.com. -> exists, search for >>>> NS records. >>>> 3) [inner loop - searching for NS records] >>>> 3a) sub.fwd.example.com. NS -> does not exist, continue inner loop. >>>> 3b) fwd.example.com. NS -> does not exist, continue inner loop. >>>> 3c) Inner loop ends: no more (relative) candidate names to try. >>>> 4) Exit returning "example.com." - deepest authoritative >>>> super-domain of >>>> sub.fwd.example.com. in LDAP. >>>> >>>> AFAIK content of the NS record does not matter so this check can be >>>> thrown >>>> away. (Check this before doing so, please :-)) >>>> >>>>> + # make sure the target is not IPA DNS server >>>>> + # FIXME: what if aliases are used? >>>>> + normalized_ns_records = set() >>>>> + for record in ns_records: >>>>> + if record.endswith('.'): >>>>> + normalized_ns_records.add(record) >>>>> + else: >>>>> + normalized_record = "%s.%s" % (record, sub_of_auth_zone) >>>>> + normalized_ns_records.add(normalized_record) >>>>> + >>>>> + nameservers = [normalize_zone(x) for x in >>>>> + api.Object.dnsrecord.get_dns_masters()] >>>>> + >>>>> + if any(nameserver in normalized_ns_records >>>>> + for nameserver in nameservers): >>>>> + # NS record is pointing to IPA DNS server >>>>> + return sub_of_auth_zone >>>>> + >>>>> + # authoritative zone contains NS records which delegates >>>>> forwardzone to >>>>> + # different server, forwardzone is effective >>>>> + return None >>>>> + >>>>> + >>>>> class DNSZoneBase(LDAPObject): >>>>> """ >>>>> Base class for DNS Zone >>>>> @@ -3164,6 +3237,29 @@ class dnsrecord(LDAPObject): >>>>> dns_name = entry_name[1].derelativize(dns_domain) >>>>> self.wait_for_modified_attrs(entry, dns_name, >>>>> dns_domain) >>>>> + def warning_if_ns_change_cause_fwzone_ineffective(self, >>>>> keys, result, >>>>> + options): >>>>> + """after execute""" >>>>> + record_name_absolute = keys[-1] >>>>> + if not keys[-1].is_absolute(): >>>>> + record_name_absolute = keys[-1].derelativize(keys[-2]) >>>>> + >>>>> + try: >>>>> + api.Command.dnsforwardzone_show(record_name_absolute) >>>>> + except errors.NotFound: >>>>> + # no forward zone >>>>> + return >>>>> + >>>>> + authoritative_zone = \ >>>>> + _find_zone_which_makes_fw_zone_ineffective(record_name_absolute) >>>>> + if authoritative_zone: >>>>> + # forward zone is not effective and forwarding will >>>>> not work >>>>> + messages.add_message( >>>>> + options['version'], result, >>>>> + messages.ForwardzoneIsNotEffectiveWarning( >>>>> + fwzone=record_name_absolute, >>>>> authzone=authoritative_zone >>>>> + ) >>>>> + ) >>>>> @register() >>>>> @@ -3358,6 +3454,14 @@ class dnsrecord_add(LDAPCreate): >>>>> return >>>>> raise exc >>>>> + def execute(self, *keys, **options): >>>>> + result = super(dnsrecord_add, self).execute(*keys, >>>>> **options) >>>>> + if 'nsrecord' in options: >>>>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>>>> + result, >>>>> + options) >>>>> + return result >>>>> + >>>>> def post_callback(self, ldap, dn, entry_attrs, *keys, >>>>> **options): >>>>> assert isinstance(dn, DN) >>>>> for attr in getattr(context, >>>>> 'dnsrecord_precallback_attrs', []): >>>>> @@ -3487,7 +3591,10 @@ class dnsrecord_mod(LDAPUpdate): >>>>> if self.api.env['wait_for_dns']: >>>>> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>>>> - >>>>> + if 'nsrecord' in options: >>>>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>>>> + result, >>>>> + options) >>>>> return result >>>>> def post_callback(self, ldap, dn, entry_attrs, *keys, >>>>> **options): >>>>> @@ -3654,19 +3761,23 @@ class dnsrecord_del(LDAPUpdate): >>>>> if self.api.env['wait_for_dns']: >>>>> entries = {(keys[0], keys[1]): None} >>>>> self.obj.wait_for_modified_entries(entries) >>>>> - return result >>>>> + else: >>>>> + result = super(dnsrecord_del, self).execute(*keys, >>>>> **options) >>>>> + result['value'] = pkey_to_value([keys[-1]], options) >>>>> - result = super(dnsrecord_del, self).execute(*keys, >>>>> **options) >>>>> - result['value'] = pkey_to_value([keys[-1]], options) >>>>> + if getattr(context, 'del_all', False) and not \ >>>>> + self.obj.is_pkey_zone_record(*keys): >>>>> + result = self.obj.methods.delentry(*keys, >>>>> + >>>>> version=options['version']) >>>>> + context.dnsrecord_entry_mods[(keys[0], keys[1])] >>>>> = None >>>>> - if getattr(context, 'del_all', False) and not \ >>>>> - self.obj.is_pkey_zone_record(*keys): >>>>> - result = self.obj.methods.delentry(*keys, >>>>> - version=options['version']) >>>>> - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >>>>> + if self.api.env['wait_for_dns']: >>>>> + >>>>> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>>>> - if self.api.env['wait_for_dns']: >>>>> - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>>>> + if 'nsrecord' in options or options.get('del_all', False): >>>>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(keys, >>>>> + result, >>>>> + options) >>>>> return result >>>>> def post_callback(self, ldap, dn, entry_attrs, *keys, >>>>> **options): >>>>> @@ -4019,6 +4130,20 @@ class dnsforwardzone_add(DNSZoneBase_add): >>>>> return dn >>>>> + def execute(self, *keys, **options): >>>>> + result = super(dnsforwardzone_add, self).execute(*keys, >>>>> **options) >>>>> + authoritative_zone = >>>>> _find_zone_which_makes_fw_zone_ineffective(keys[-1]) >>>>> + if authoritative_zone: >>>>> + # forward zone is not effective and forwarding will >>>>> not work >>>>> + messages.add_message( >>>>> + options['version'], result, >>>>> + messages.ForwardzoneIsNotEffectiveWarning( >>>>> + fwzone=keys[-1], authzone=authoritative_zone >>>>> + ) >>>>> + ) >>>>> + >>>>> + return result >>>>> + >>>>> @register() >>>>> class dnsforwardzone_del(DNSZoneBase_del): >>>>> diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py >>>>> b/ipatests/test_xmlrpc/test_dns_plugin.py >>>>> index >>>>> fb53853147ecf663cf7015867131445f32364cfb..224a80d98273480f40fd78dea0f27e34ea36492f >>>>> >>>>> 100644 >>>>> --- a/ipatests/test_xmlrpc/test_dns_plugin.py >>>>> +++ b/ipatests/test_xmlrpc/test_dns_plugin.py >>>>> @@ -1060,7 +1060,7 @@ class test_dns(Declarative): >>>>> 'srv_part_target' : u'foo.bar.', >>>>> 'srvrecord': [u"1 100 1234 %s" \ >>>>> % >>>>> zone1_ns]}), >>>>> - expected=errors.ValidationError(name='srv_target', >>>>> + expected=errors.ValidationError(name='srv_weight', >>>>> error=u'Raw value of a DNS record was already >>>>> set by ' + >>>>> u'"srv_rec" option'), >>>>> ), >>>>> -- 1.8.3.1 >>>> The same check should be done also on zone de/activation. >>>> >>> Updated patch attached. >>> >>> -- >>> Martin Basti >>> >>> >>> freeipa-mbasti-0170.2-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch >>> >> Hello, >> >> first of all - the code looks reasonable, I have only couple >> nitpicks. See below. >> >>> From 2a5cf557840e8f578444039326ad90c76bdfb75a Mon Sep 17 00:00:00 2001 >>> From: Martin Basti >>> Date: Fri, 21 Nov 2014 16:54:09 +0100 >>> Subject: [PATCH] Detect and warn about invalid DNS forward zone >>> configuration >>> >>> Shows warning if forward and parent authoritative zone do not have >>> proper NS record delegation, which can cause the forward zone will be >>> ineffective and forwarding will not work. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/4721 >>> --- >>> ipalib/messages.py | 13 ++ >>> ipalib/plugins/dns.py | 334 >>> ++++++++++++++++++++++++++++++++++++++++++++++++-- >>> 2 files changed, 336 insertions(+), 11 deletions(-) >>> >>> diff --git a/ipalib/messages.py b/ipalib/messages.py >>> index >>> 102e35275dbe37328c84ecb3cd5b2a8d8578056f..b44beca729f5483a7241e4c98a9f724ed663e70f >>> 100644 >>> --- a/ipalib/messages.py >>> +++ b/ipalib/messages.py >>> @@ -200,6 +200,19 @@ class >>> DNSServerDoesNotSupportDNSSECWarning(PublicMessage): >>> u"If DNSSEC validation is enabled on IPA server(s), " >>> u"please disable it.") >>> +class ForwardzoneIsNotEffectiveWarning(PublicMessage): >>> + """ >>> + **13008** Forwardzone is not effective, forwarding will not >>> work because >>> + there is authoritative parent zone, without proper NS delegation >>> + """ >>> + >>> + errno = 13008 >>> + type = "warning" >>> + format = _(u"forward zone \"%(fwzone)s\" is not effective >>> because of " >>> + u"missing proper NS delegation in authoritative zone " >>> + u"\"%(authzone)s\". Please add NS record " >>> + u"\"%(ns_rec)s\" to parent zone \"%(authzone)s\".") >>> + >>> def iter_messages(variables, base): >>> """Return a tuple with all subclasses >>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>> index >>> c5d96a8c4fcdf101254ecefb60cb83d63bee6310..b381dcc5e42761bb6d8d7ec35ef403c6e9b4d629 >>> 100644 >>> --- a/ipalib/plugins/dns.py >>> +++ b/ipalib/plugins/dns.py >>> @@ -1725,6 +1725,222 @@ def _normalize_zone(zone): >>> return zone >>> +def _get_auth_zone_ldap(name): >>> + """ >>> + Find authoritative zone in LDAP for name >>> + :param name: >>> + :return: >>> + """ >>> + assert isinstance(name, DNSName) >>> + ldap = api.Backend.ldap2 >>> + >>> + # Create all possible parent zone names >>> + labels = name.make_absolute().ToASCII().split('.') >> Please use python-dns interface and do not work with domain names as >> with strings. >> >>> + zone_names = ['.', ] # always add root zone >>> + # decrease len by 1, we already have root zone >>> + for i in xrange(len(labels) - 1): >>> + zone_name_abs = '.'.join(labels[i:]) >>> + zone_names.append(zone_name_abs) >>> + # compatibility with IPA < 4.0, zone name can be relative >>> + zone_names.append(zone_name_abs[:-1]) >>> + >>> + # Create filters >>> + objectclass_filter = ldap.make_filter({'objectclass':'idnszone'}) >>> + zonenames_filter = ldap.make_filter({'idnsname': zone_names}) >>> + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) >>> + complete_filter = ldap.combine_filters( >>> + [objectclass_filter, zonenames_filter, zoneactive_filter], >>> + rules=ldap.MATCH_ALL >>> + ) >>> + >>> + try: >>> + entries, truncated = ldap.find_entries( >>> + filter=complete_filter, >>> + attrs_list=['idnsname'], >>> + base_dn=DN(api.env.container_dns, api.env.basedn), >>> + scope=ldap.SCOPE_ONELEVEL >>> + ) >> What about truncated return value? It would be better to throw a >> exception and >> optionally catch it in _warning* functions if you don't want throw fatal >> errors from warning-generator. >> >>> + except errors.NotFound: >>> + return None >>> + >>> + # always use absolute zones >>> + matched_auth_zones = >>> [entry.single_value['idnsname'].make_absolute() >>> + for entry in entries] >>> + >>> + # return longest match >>> + return max(matched_auth_zones, key=len) >>> + >>> + >>> +def _get_longest_match_ns_delegation_ldap(zone, name): >>> + """ >>> + Finds record in LDAP which has the longest match with name. >>> + >>> + NOTE: does not search in zone apex, returns None if there is no NS >>> + delegation outside of zone apex >>> + >>> + Example: >>> + zone: example.com. >>> + name: ns.sub.example.com. >>> + >>> + records: >>> + extra.ns.sub.example.com. >>> + sub.example.com. >>> + example.com >>> + >>> + result: sub.example.com. >>> + >>> + :param zone: zone name >>> + :param name: >>> + :return: record name if success, or None if no such record >>> exists, or >>> + record is zone apex record >>> + """ >>> + assert isinstance(zone, DNSName) >>> + assert isinstance(name, DNSName) >>> + >>> + ldap = api.Backend.ldap2 >>> + >>> + # get zone DN >>> + zone_dn = api.Object.dnszone.get_dn(zone) >>> + >>> + if name.is_absolute(): >>> + relative_record_name = name.relativize(zone.make_absolute()) >>> + else: >>> + relative_record_name = name >>> + >>> + # Name is zone apex >>> + if relative_record_name.is_empty(): >>> + return None >>> + >>> + relative_record_name = relative_record_name.ToASCII() >> Again, please do not work with DNS names as with strings. >> >>> + labels = relative_record_name.split('.') >>> + >>> + # create list of possible record names >>> + possible_record_names = ['.'.join(labels[i:]) for i in >>> xrange(len(labels))] >>> + >>> + # search filters >>> + name_filter = ldap.make_filter({'idnsname': >>> [possible_record_names]}) >>> + objectclass_filter = ldap.make_filter({'objectclass': >>> 'idnsrecord'}) >>> + complete_filter = ldap.combine_filters( >>> + [name_filter, objectclass_filter], >>> + rules=ldap.MATCH_ALL >>> + ) >>> + >>> + try: >>> + entries, truncated = ldap.find_entries( >>> + filter=complete_filter, >>> + attrs_list=['idnsname', 'nsrecord'], >>> + base_dn=zone_dn, >>> + scope=ldap.SCOPE_ONELEVEL >>> + ) >> What about truncated? >> >>> + except errors.NotFound: >>> + return None >>> + >>> + matched_records = [] >>> + >>> + # test if entry contains NS records >>> + for entry in entries: >>> + print entry >>> + if entry.get('nsrecord'): >>> + matched_records.append(entry.single_value['idnsname']) >>> + >>> + if not matched_records: >>> + return None >>> + >>> + # return longest match >>> + return max(matched_records, key=len) >>> + >>> + >>> +def _find_subtree_forward_zones_ldap(name, child_zones_only=False): >>> + """ >>> + Search for forwardzone and all child forwardzones >>> + Filter: (|(*..)(.)) >>> + :param name: >>> + :param child_zones_only: search only for child zones >>> + :return: list of zonenames, or empty list if no zone was found >>> + """ >>> + assert isinstance(name, DNSName) >>> + ldap = api.Backend.ldap2 >>> + >>> + # prepare for filter "*.." >>> + search_name = u".%s" % name.make_absolute().ToASCII() >>> + # we need to search zone with and without last dot, due >>> compatibility >>> + # with IPA < 4.0 >>> + search_names = [search_name, search_name[:-1]] >>> + >>> + # Create filters >>> + objectclass_filter = >>> ldap.make_filter({'objectclass':'idnsforwardzone'}) >>> + zonenames_filter = ldap.make_filter({'idnsname': search_names}, >>> exact=False, >>> + trailing_wildcard=False) >>> + if not child_zones_only: >>> + # find also zone with exact name >>> + exact_name = name.make_absolute().ToASCII() >> Again, please do not work with DNS names as with strings. >> >>> + # we need to search zone with and without last dot, due >>> compatibility >>> + # with IPA < 4.0 >>> + exact_names = [exact_name, exact_name[-1]] >>> + exact_name_filter = ldap.make_filter({'idnsname': >>> exact_names}) >>> + zonenames_filter = ldap.combine_filters([zonenames_filter, >>> + exact_name_filter]) >>> + >>> + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) >>> + complete_filter = ldap.combine_filters( >>> + [objectclass_filter, zonenames_filter, zoneactive_filter], >>> + rules=ldap.MATCH_ALL >>> + ) >>> + >>> + try: >>> + entries, truncated = ldap.find_entries( >>> + filter=complete_filter, >>> + attrs_list=['idnsname'], >>> + base_dn=DN(api.env.container_dns, api.env.basedn), >>> + scope=ldap.SCOPE_ONELEVEL >>> + ) >> What about truncated? >> >>> + except errors.NotFound: >>> + return [] >>> + >>> + result = [entry.single_value['idnsname'].make_absolute() >>> + for entry in entries] >>> + >>> + return result >>> + >>> + >>> +def _get_zone_which_makes_fw_zone_ineffective(fwzonename): >>> + """ >>> + Check if forward zone is effective. >>> + >>> + If parent zone exists as authoritative zone, the forward zone >>> will not >>> + forward queries by default. It is necessary to delegate authority >>> + to forward zone with a NS record. >>> + >>> + Example: >>> + >>> + Forward zone: sub.example.com >>> + Zone: example.com >>> + >>> + Forwarding will not work, because the server thinks it is >>> authoritative >>> + for zone and will return NXDOMAIN >>> + >>> + Adding record: sub.example.com NS ns.sub.example.com. >>> + will delegate authority, and IPA DNS server will forward DNS >>> queries. >>> + >>> + :param fwzonename: forwardzone >>> + :return: None if effective, name of authoritative zone otherwise >>> + """ >>> + assert isinstance(fwzonename, DNSName) >>> + >>> + auth_zone = _get_auth_zone_ldap(fwzonename) >>> + if not auth_zone: >>> + return None >>> + >>> + delegation_record_name = _get_longest_match_ns_delegation_ldap( >>> + auth_zone, fwzonename) >>> + >>> + if delegation_record_name: >>> + return None >>> + >>> + return auth_zone >>> + >>> + >>> class DNSZoneBase(LDAPObject): >>> """ >>> Base class for DNS Zone >>> @@ -2376,6 +2592,30 @@ class dnszone(DNSZoneBase): >>> ) >>> ) >>> + def _warning_fw_zone_is_not_effective(self, result, *keys, >>> **options): >>> + """ >>> + Warning if any operation with zone causes, a child forward >>> zone is >>> + not effective >>> + """ >>> + zone = keys[-1] >>> + affected_fw_zones = _find_subtree_forward_zones_ldap( >>> + zone, child_zones_only=True) >>> + if not affected_fw_zones: >>> + return >>> + >>> + for fwzone in affected_fw_zones: >>> + authoritative_zone = \ >>> + _get_zone_which_makes_fw_zone_ineffective(fwzone) >>> + if authoritative_zone: >>> + # forward zone is not effective and forwarding will >>> not work >>> + messages.add_message( >>> + options['version'], result, >>> + messages.ForwardzoneIsNotEffectiveWarning( >>> + fwzone=fwzone, authzone=authoritative_zone, >>> + ns_rec=fwzone.relativize(authoritative_zone) >>> + ) >>> + ) >>> + >>> @register() >>> class dnszone_add(DNSZoneBase_add): >>> __doc__ = _('Create new DNS zone (SOA record).') >>> @@ -2445,6 +2685,7 @@ class dnszone_add(DNSZoneBase_add): >>> self.obj._warning_forwarding(result, **options) >>> self.obj._warning_dnssec_experimental(result, *keys, >>> **options) >>> self.obj._warning_name_server_option(result, context, >>> **options) >>> + self.obj._warning_fw_zone_is_not_effective(result, *keys, >>> **options) >>> return result >>> def post_callback(self, ldap, dn, entry_attrs, *keys, >>> **options): >>> @@ -2475,6 +2716,13 @@ class dnszone_del(DNSZoneBase_del): >>> msg_summary = _('Deleted DNS zone "%(value)s"') >>> + def execute(self, *keys, **options): >>> + result = super(dnszone_del, self).execute(*keys, **options) >>> + nkeys = keys[-1] # we can delete more zones >>> + for key in nkeys: >>> + self.obj._warning_fw_zone_is_not_effective(result, key, **options) >>> + return result >>> + >>> def post_callback(self, ldap, dn, *keys, **options): >>> super(dnszone_del, self).post_callback(ldap, dn, *keys, >>> **options) >>> @@ -2595,12 +2843,22 @@ class dnszone_disable(DNSZoneBase_disable): >>> __doc__ = _('Disable DNS Zone.') >>> msg_summary = _('Disabled DNS zone "%(value)s"') >>> + def execute(self, *keys, **options): >>> + result = super(dnszone_disable, self).execute(*keys, >>> **options) >>> + self.obj._warning_fw_zone_is_not_effective(result, *keys, >>> **options) >>> + return result >>> + >>> @register() >>> class dnszone_enable(DNSZoneBase_enable): >>> __doc__ = _('Enable DNS Zone.') >>> msg_summary = _('Enabled DNS zone "%(value)s"') >>> + def execute(self, *keys, **options): >>> + result = super(dnszone_enable, self).execute(*keys, **options) >>> + self.obj._warning_fw_zone_is_not_effective(result, *keys, >>> **options) >>> + return result >>> + >>> @register() >>> class dnszone_add_permission(DNSZoneBase_add_permission): >>> @@ -3164,6 +3422,30 @@ class dnsrecord(LDAPObject): >>> dns_name = entry_name[1].derelativize(dns_domain) >>> self.wait_for_modified_attrs(entry, dns_name, dns_domain) >>> + def warning_if_ns_change_cause_fwzone_ineffective(self, >>> result, *keys, >>> + **options): >>> + """after execute""" >> Please add more descriptive comment to doc string. >> >>> + record_name_absolute = keys[-1] >> a variable with zone name instead of keys[-2] would make it more >> readable >> >>> + if not keys[-1].is_absolute(): >> record_name_absolute.is_absolute() would be better >> >>> + record_name_absolute = keys[-1].derelativize(keys[-2]) >> again, please replace keys[x] with sensible names >> >>> + >>> + affected_fw_zones = _find_subtree_forward_zones_ldap( >>> + record_name_absolute) >>> + if not affected_fw_zones: >>> + return >>> + >>> + for fwzone in affected_fw_zones: >> Would it be possible to generalize & use >> _warning_fw_zone_is_not_effective() here? >> >>> + authoritative_zone = \ >>> + _get_zone_which_makes_fw_zone_ineffective(fwzone) >>> + if authoritative_zone: >>> + # forward zone is not effective and forwarding will >>> not work >>> + messages.add_message( >>> + options['version'], result, >>> + messages.ForwardzoneIsNotEffectiveWarning( >>> + fwzone=fwzone, authzone=authoritative_zone, >>> + ns_rec=fwzone.relativize(authoritative_zone) >>> + ) >>> + ) >>> @register() >>> @@ -3487,7 +3769,10 @@ class dnsrecord_mod(LDAPUpdate): >>> if self.api.env['wait_for_dns']: >>> self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>> - >>> + if 'nsrecord' in options: >>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, >>> + *keys, >>> + **options) >>> return result >>> def post_callback(self, ldap, dn, entry_attrs, *keys, >>> **options): >>> @@ -3654,19 +3939,23 @@ class dnsrecord_del(LDAPUpdate): >>> if self.api.env['wait_for_dns']: >>> entries = {(keys[0], keys[1]): None} >>> self.obj.wait_for_modified_entries(entries) >>> - return result >>> + else: >>> + result = super(dnsrecord_del, self).execute(*keys, >>> **options) >>> + result['value'] = pkey_to_value([keys[-1]], options) >>> - result = super(dnsrecord_del, self).execute(*keys, >>> **options) >>> - result['value'] = pkey_to_value([keys[-1]], options) >>> + if getattr(context, 'del_all', False) and not \ >>> + self.obj.is_pkey_zone_record(*keys): >>> + result = self.obj.methods.delentry(*keys, >>> + version=options['version']) >>> + context.dnsrecord_entry_mods[(keys[0], keys[1])] = >>> None >>> - if getattr(context, 'del_all', False) and not \ >>> - self.obj.is_pkey_zone_record(*keys): >>> - result = self.obj.methods.delentry(*keys, >>> - version=options['version']) >>> - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None >>> + if self.api.env['wait_for_dns']: >>> + self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>> - if self.api.env['wait_for_dns']: >>> - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) >>> + if 'nsrecord' in options or options.get('del_all', False): >>> + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, >>> + *keys, >>> + **options) >>> return result >>> def post_callback(self, ldap, dn, entry_attrs, *keys, >>> **options): >>> @@ -3998,6 +4287,19 @@ class dnsforwardzone(DNSZoneBase): >>> # managed_permissions: permissions was apllied in dnszone >>> class, do NOT >>> # add them here, they should not be applied twice. >>> + def _warning_fw_zone_is_not_effective(self, result, *keys, >>> **options): >>> + fwzone = keys[-1] >>> + authoritative_zone = >>> _get_zone_which_makes_fw_zone_ineffective( >>> + fwzone) >>> + if authoritative_zone: >>> + # forward zone is not effective and forwarding will not >>> work >>> + messages.add_message( >>> + options['version'], result, >>> + messages.ForwardzoneIsNotEffectiveWarning( >>> + fwzone=fwzone, authzone=authoritative_zone, >>> + ns_rec=fwzone.relativize(authoritative_zone) >>> + ) >>> + ) >>> @register() >>> class dnsforwardzone_add(DNSZoneBase_add): >>> @@ -4019,6 +4321,11 @@ class dnsforwardzone_add(DNSZoneBase_add): >>> return dn >>> + def execute(self, *keys, **options): >>> + result = super(dnsforwardzone_add, self).execute(*keys, >>> **options) >>> + self.obj._warning_fw_zone_is_not_effective(result, *keys, >>> **options) >>> + return result >>> + >>> @register() >>> class dnsforwardzone_del(DNSZoneBase_del): >>> @@ -4083,6 +4390,11 @@ class dnsforwardzone_enable(DNSZoneBase_enable): >>> __doc__ = _('Enable DNS Forward Zone.') >>> msg_summary = _('Enabled DNS forward zone "%(value)s"') >>> + def execute(self, *keys, **options): >>> + result = super(dnsforwardzone_enable, self).execute(*keys, >>> **options) >>> + self.obj._warning_fw_zone_is_not_effective(result, *keys, >>> **options) >>> + return result >>> + >>> @register() >>> class dnsforwardzone_add_permission(DNSZoneBase_add_permission): >>> -- 1.8.3.1 >> NACK >> >> Thank you for your patience with me ;-) >> > Updated patch attached. > Updated patch attached. Removes change in tests, which causes false positive error. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0170.4-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch Type: text/x-patch Size: 17034 bytes Desc: not available URL: From simo at redhat.com Wed Dec 10 17:50:12 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Dec 2014 12:50:12 -0500 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <5488550A.3000400@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> <5488550A.3000400@redhat.com> Message-ID: <20141210125012.27c8943d@willson.usersys.redhat.com> On Wed, 10 Dec 2014 15:13:30 +0100 Petr Spacek wrote: > I think that external DNS could depend on Vault (assuming that > external DNS support will be purely optional). TBH, I do not think this is a sensible option, the Vault will drag huge dependencies for now, and I would like to avoid that if all we need is to add a couple of A/SRV records to an external DNS. If we can't come up with a service, I think I am ok telling admins they need to manually copy the TKEY (or use puppet or other similar configuration manager to push the key file around) on each replica, and we defer automatic distribution of TKEYs. We will have a service that can give out keys, it is identified as necessary in the replica promotion proposal, so we'll eventually get there. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed Dec 10 18:21:39 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Dec 2014 19:21:39 +0100 Subject: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade In-Reply-To: <54887C50.7070701@redhat.com> References: <54772621.5050003@redhat.com> <547C1CE8.5000707@redhat.com> <547C8DBD.2020204@redhat.com> <54887C50.7070701@redhat.com> Message-ID: <54888F33.3030200@redhat.com> Dne 10.12.2014 v 18:01 Jan Cholasta napsal(a): > Dne 1.12.2014 v 16:48 Martin Basti napsal(a): >> On 01/12/14 08:46, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 27.11.2014 v 14:24 Martin Basti napsal(a): >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4676 >>>> Replaces current workaround. Should go to 4.1.3. >>>> Patch attached. >>> >>> When constructing URLs with host:port, please use >>> ipautil.format_netloc(). >>> >>> wget should be added as a dependency of freeipa-python in the spec file. >>> >>> Honza >>> >> Updated patch attached. >> > > Thanks, ACK. > > Pushed to: > master: 337faf506462a01c6dbcd00f2039ed5627691864 > ipa-4-1: 5052af773f652bc19e91fe49e15351e5c5c7d976 > It turns out I messed up the review (sorry). This fixes the upgrade, but it also breaks ipa-server-install: 2014-12-10T06:06:44Z DEBUG [8/27]: starting certificate server instance 2014-12-10T06:06:44Z DEBUG Starting external process 2014-12-10T06:06:44Z DEBUG args='/bin/systemctl' 'start' 'pki-tomcatd.target' 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 2014-12-10T06:06:45Z DEBUG stdout= 2014-12-10T06:06:45Z DEBUG stderr= 2014-12-10T06:06:45Z DEBUG Starting external process 2014-12-10T06:06:45Z DEBUG args='/bin/systemctl' 'is-active' 'pki-tomcatd.target' 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 2014-12-10T06:06:45Z DEBUG stdout=active 2014-12-10T06:06:45Z DEBUG stderr= 2014-12-10T06:06:45Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 2014-12-10T06:06:49Z DEBUG The httpd proxy is not installed, wait on local port 2014-12-10T06:06:49Z DEBUG Waiting until the CA is running 2014-12-10T06:06:49Z DEBUG Starting external process 2014-12-10T06:06:49Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' 'https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus' 2014-12-10T06:07:09Z DEBUG Process finished, return code=5 2014-12-10T06:07:09Z DEBUG stdout= 2014-12-10T06:07:09Z DEBUG stderr=--2014-12-10 01:06:49-- https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus Resolving vm-088.idm.lab.bos.redhat.com (vm-088.idm.lab.bos.redhat.com)... 10.16.78.88 Connecting to vm-088.idm.lab.bos.redhat.com (vm-088.idm.lab.bos.redhat.com)|10.16.78.88|:8443... connected. ERROR: cannot verify vm-088.idm.lab.bos.redhat.com's certificate, issued by ?/O=IDM.LAB.BOS.REDHAT.COM/CN=Certificate Authority?: Self-signed certificate encountered. To connect to vm-088.idm.lab.bos.redhat.com insecurely, use `--no-check-certificate'. 2014-12-10T06:07:09Z DEBUG The CA status is: check interrupted I have reopened the ticket. -- Jan Cholasta From jcholast at redhat.com Wed Dec 10 18:36:22 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 10 Dec 2014 19:36:22 +0100 Subject: [Freeipa-devel] [PATCH 0174] Show SSHFP record in CLI if contains space in fingerprint part In-Reply-To: <54806E12.4080300@redhat.com> References: <54806E12.4080300@redhat.com> Message-ID: <548892A6.901@redhat.com> Hi, Dne 4.12.2014 v 15:22 Martin Basti napsal(a): > SSHFP records added by nsupdate contains space in fingerprint part, this > space prevent framework to show record. > > Fixes > https://fedorahosted.org/freeipa/ticket/4789 > https://fedorahosted.org/freeipa/ticket/4790 > > Patch attached. Thanks, ACK. Pushed to: master: b5ff0b941efad5170ff5fdda4ab05b9f1c7a2113 ipa-4-1: d229c4a1cc397cfe6adf661b6bcc8360a758248c Honza -- Jan Cholasta From edewata at redhat.com Wed Dec 10 21:50:48 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 11 Dec 2014 04:50:48 +0700 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <54885FE8.8060309@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> <5488550A.3000400@redhat.com> <54885DAF.2090408@redhat.com> <54885FE8.8060309@redhat.com> Message-ID: <5488C038.3060309@redhat.com> On 12/10/2014 9:59 PM, Petr Spacek wrote: >>>>> Alternatively we can use Vault for TSIG key storage and use Vault's capability >>>>> to share keys among many users. In that case we don't have problem with key >>>>> distribution nor authorization. >>>> >>>> I am not convinced we should grow Vault dependency for this functionality, it >>>> requires the whole PKI machinery to be available. Many deployments do not use >>>> it though. >>>> >>>>> Another possibility is to say that replica-deletion can be done only by root >>>>> user or that updates to external DNS are supported only when running >>>>> ipa-replica-manage as root. >>>> >>>> Why does root help? So that TSIG keys will be available on all IPA servers, >>>> regardless whether they have DNS service running or not? >>> The point is that we need to store TSIG keys "somewhere" to make them >>> available to ipa* scripts on all replica but at the same not to human-users. >>> >>> BTW there don't need to be any 'DNS service' if only external DNS integration >>> is in use. >>> >>>> It would be better to have the TSIG keys available using standard FreeIPA RBAC >>>> roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I >>>> missing anything? >>> >>> Ideologically - no, it sounds fine. >>> Technically - the problem is in implementation. We need a mechanism for secure >>> key distribution *among users*, i.e. Vault-like functionality. I would rather >>> not re-implement Vault just for external DNS. >>> >>> I think that external DNS could depend on Vault (assuming that external DNS >>> support will be purely optional). >>> >>> DNSSEC key distribution is very different because it distributes keys to >>> *servers* and there is no ACI mechanism on top of that - all DNS servers need >>> to know all the keys anyway. >> >> So IIUC, the goal would be to put TSIG keys in the Vault and then make them >> available for all IPA servers? >> >> I am now not sure if the Vault as proposed can easily select a group of >> principals to allow reading the Vault or if it is only confined for the >> owner/user principal. We would need to ask Endi (CCed). > > I assumed that very first sentence of > http://www.freeipa.org/page/V4/Password_Vault_Implementation#Vault > "Vault is a secure place to store data or a collection of secrets. A vault may > be privately owned by a user, or shared among users, groups, or services." > is correct :-) > > Endi, we would like to have one secret which is shared among services & users > at the same time. Is it possible to do that with Vault? Yes, the access to a particular vault is limited to the vault members & owners which can be a set of users, groups, and/or services. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control A vault member can list, archive, and retrieve the secrets in a standard vault. With symmetric vault the member will need a vault password in order to archive and retrieve secrets. With asymmetric vault the member can only archive the secrets but not retrieve them since it only has the public key and not the private key. A vault owner can list, archive, and retrieve the secrets like vault members, but it has the private key so it can retrieve secrets from asymmetric vault. The owner can also manage the list of members and owners of the vault, and change the vault password/keys. There are commands to manage the members/owners. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Adding_vault_member $ ipa vault-add-member MyVault --groups group1,group2 $ ipa vault-add-owner MyVault --users user1,user2 (we may need a separate option for services) Below are the vault LDAP ACIs. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control_Attributes aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Indirect vault members can access the vault"; allow(read, search, compare) userattr="member#GROUPDN";) aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#USERDN";) aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Indirect vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#GROUPDN";) Note that the secrets are stored separately in KRA, not in the IPA LDAP tree, so they are not directly controlled by the above ACIs. The vault service will first verify that you have access to the vault based on the above ACIs then it will let you archive/retrieve secrets in KRA. -- Endi S. Dewata From redhatrises at gmail.com Thu Dec 11 04:01:10 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 10 Dec 2014 21:01:10 -0700 Subject: [Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager In-Reply-To: <54886094.3040605@redhat.com> References: <54886094.3040605@redhat.com> Message-ID: Updated patch attached. Thanks, Gabe On Wed, Dec 10, 2014 at 8:02 AM, Martin Basti wrote: > On 10/12/14 15:45, Gabe Alford wrote: > >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/4783 >> >> Thanks, >> >> Gabe >> > > Hello, thanks for patch. > > The patch needs rebase for IPA-4-1 branch > > Martin^2 > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0040-2-Remove-dependency-on-subscription-manager.patch Type: text/x-patch Size: 771 bytes Desc: not available URL: From tbabej at redhat.com Thu Dec 11 06:05:57 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Dec 2014 07:05:57 +0100 Subject: [Freeipa-devel] [PATCH] drop archeological feature :) In-Reply-To: <20141124131040.2f2a8ea7@willson.usersys.redhat.com> References: <20141124131040.2f2a8ea7@willson.usersys.redhat.com> Message-ID: <54893445.1010408@redhat.com> ACK, works fine (in other words, removal does not break anything I could detect). Pushed to master: 8822be36d342c2bc499937c3f144e11ae98d8e58 On 11/24/2014 07:10 PM, Simo Sorce wrote: > Getting through krbinstancepy I discovered we are still doing this > thing with the master key that has been unnecessary for a few years now. > > Stop doing that. > > I haven't really tested this yet ... but ... what could possibly go > wrong ? :-D > > Simo. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Dec 11 07:09:07 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Dec 2014 08:09:07 +0100 Subject: [Freeipa-devel] [PATCH] 0677 test_integration: Use python-pytest-multihost In-Reply-To: <54872666.2080201@redhat.com> References: <5475EF31.3060606@redhat.com> <54872666.2080201@redhat.com> Message-ID: <54894313.7010909@redhat.com> On 12/09/2014 05:42 PM, Petr Viktorin wrote: > On 11/26/2014 04:18 PM, Petr Viktorin wrote: >> Hello, >> >> I have split FreeIPA's multi-host testing infrastructure into a separate >> project. It is temoprarily available at: >> https://github.com/encukou/pytest-multihost >> and I will move it to fedorahosted as soon as it's approved: >> https://fedorahosted.org/fedora-infrastructure/ticket/4605 >> RPMs for Fedora 20..rawhide and EPEL 7 are available in COPR: >> https://copr.fedoraproject.org/coprs/pviktori/pytest-plugins/ >> >> This patch contains the necessary changes to FreeIPA. The tests >> themselves are almost unchanged. FreeIPA specific parts (most >> importantly, logging and environ-based configuration) are also left in. > > Hi Tom??! Thanks for testing the patch and finding a problem in the > pytest-multihost library. It is now solved. > > I'm also attaching two smaller patches that fix bugs in the pytest port. > > Thank you for fixing the reported issues. This version works fine, ACK from me. Pushed to master: a97d61df040111b9ce4585db262ddfaba24df4da Also pushed attached one-liner to bump the Requires for python-multihost: Pushed to master: 3e406f9924428e638dd37d2b43f6c349f1ce36e8 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0290-ipatests-Increase-required-version-for-pytest-multih.patch Type: text/x-patch Size: 783 bytes Desc: not available URL: From tbabej at redhat.com Thu Dec 11 08:23:54 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Dec 2014 09:23:54 +0100 Subject: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply Message-ID: <5489549A.5080802@redhat.com> Hi, When running a idview-apply command, the hosts that were already assigned the desired view were silently ignored. Make sure such hosts show up in the list of failed hosts. https://fedorahosted.org/freeipa/ticket/4743 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0291-idviews-Complain-if-host-is-already-assigned-the-ID-.patch Type: text/x-patch Size: 1342 bytes Desc: not available URL: From mbasti at redhat.com Thu Dec 11 09:01:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Dec 2014 10:01:35 +0100 Subject: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade In-Reply-To: <54888F33.3030200@redhat.com> References: <54772621.5050003@redhat.com> <547C1CE8.5000707@redhat.com> <547C8DBD.2020204@redhat.com> <54887C50.7070701@redhat.com> <54888F33.3030200@redhat.com> Message-ID: <54895D6F.3050208@redhat.com> On 10/12/14 19:21, Jan Cholasta wrote: > Dne 10.12.2014 v 18:01 Jan Cholasta napsal(a): >> Dne 1.12.2014 v 16:48 Martin Basti napsal(a): >>> On 01/12/14 08:46, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 27.11.2014 v 14:24 Martin Basti napsal(a): >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4676 >>>>> Replaces current workaround. Should go to 4.1.3. >>>>> Patch attached. >>>> >>>> When constructing URLs with host:port, please use >>>> ipautil.format_netloc(). >>>> >>>> wget should be added as a dependency of freeipa-python in the spec >>>> file. >>>> >>>> Honza >>>> >>> Updated patch attached. >>> >> >> Thanks, ACK. >> >> Pushed to: >> master: 337faf506462a01c6dbcd00f2039ed5627691864 >> ipa-4-1: 5052af773f652bc19e91fe49e15351e5c5c7d976 >> > > It turns out I messed up the review (sorry). This fixes the upgrade, > but it also breaks ipa-server-install: > > 2014-12-10T06:06:44Z DEBUG [8/27]: starting certificate server instance > 2014-12-10T06:06:44Z DEBUG Starting external process > 2014-12-10T06:06:44Z DEBUG args='/bin/systemctl' 'start' > 'pki-tomcatd.target' > 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 > 2014-12-10T06:06:45Z DEBUG stdout= > 2014-12-10T06:06:45Z DEBUG stderr= > 2014-12-10T06:06:45Z DEBUG Starting external process > 2014-12-10T06:06:45Z DEBUG args='/bin/systemctl' 'is-active' > 'pki-tomcatd.target' > 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 > 2014-12-10T06:06:45Z DEBUG stdout=active > > 2014-12-10T06:06:45Z DEBUG stderr= > 2014-12-10T06:06:45Z DEBUG wait_for_open_ports: localhost [8080, 8443] > timeout 300 > 2014-12-10T06:06:49Z DEBUG The httpd proxy is not installed, wait on > local port > 2014-12-10T06:06:49Z DEBUG Waiting until the CA is running > 2014-12-10T06:06:49Z DEBUG Starting external process > 2014-12-10T06:06:49Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' > '--timeout=30' > 'https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus' > 2014-12-10T06:07:09Z DEBUG Process finished, return code=5 > 2014-12-10T06:07:09Z DEBUG stdout= > 2014-12-10T06:07:09Z DEBUG stderr=--2014-12-10 01:06:49-- > https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus > Resolving vm-088.idm.lab.bos.redhat.com > (vm-088.idm.lab.bos.redhat.com)... 10.16.78.88 > Connecting to vm-088.idm.lab.bos.redhat.com > (vm-088.idm.lab.bos.redhat.com)|10.16.78.88|:8443... connected. > ERROR: cannot verify vm-088.idm.lab.bos.redhat.com's certificate, > issued by ?/O=IDM.LAB.BOS.REDHAT.COM/CN=Certificate Authority?: > Self-signed certificate encountered. > To connect to vm-088.idm.lab.bos.redhat.com insecurely, use > `--no-check-certificate'. > > 2014-12-10T06:07:09Z DEBUG The CA status is: check interrupted > > > I have reopened the ticket. > Patch with '--no-check-certificate' option attached. Before workaround there was no certificate check, so it should not be problem if we ignore the certificate. Martin^2 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0178-Fix-don-t-check-certificate-during-getting-CA-status.patch Type: text/x-patch Size: 973 bytes Desc: not available URL: From pspacek at redhat.com Thu Dec 11 09:43:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Dec 2014 10:43:02 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <20141210125012.27c8943d@willson.usersys.redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> <5488550A.3000400@redhat.com> <20141210125012.27c8943d@willson.usersys.redhat.com> Message-ID: <54896726.6020001@redhat.com> On 10.12.2014 18:50, Simo Sorce wrote: > On Wed, 10 Dec 2014 15:13:30 +0100 > Petr Spacek wrote: > >> I think that external DNS could depend on Vault (assuming that >> external DNS support will be purely optional). > > TBH, I do not think this is a sensible option, the Vault will drag huge > dependencies for now, and I would like to avoid that if all we need is > to add a couple of A/SRV records to an external DNS. > > If we can't come up with a service, I think I am ok telling admins they > need to manually copy the TKEY (or use puppet or other similar > configuration manager to push the key file around) on each replica, and > we defer automatic distribution of TKEYs. > > We will have a service that can give out keys, it is identified as > necessary in the replica promotion proposal, so we'll eventually get > there. Thank you for discussion. Now I would like to know in which direction are we heading with external DNS support :-) I have to admit that I don't understand why we are spending time on Vault and at the same time we refuse to use it ... Anyway, someone competent has to decide if we want to implement external DNS support and: - defer key distribution for now - use Vault - re-invent Vault and use that new cool thing -- Petr^2 Spacek From jcholast at redhat.com Thu Dec 11 10:07:41 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Dec 2014 11:07:41 +0100 Subject: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply In-Reply-To: <5489549A.5080802@redhat.com> References: <5489549A.5080802@redhat.com> Message-ID: <54896CED.6030908@redhat.com> Hi, Dne 11.12.2014 v 09:23 Tomas Babej napsal(a): > Hi, > > When running a idview-apply command, the hosts that were already assigned > the desired view were silently ignored. Make sure such hosts show up in > the list of failed hosts. > > https://fedorahosted.org/freeipa/ticket/4743 Shouldn't the error message strings be translatable? Honza -- Jan Cholasta From jcholast at redhat.com Thu Dec 11 10:19:43 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Dec 2014 11:19:43 +0100 Subject: [Freeipa-devel] [PATCH 0177] Fix adding (warning) messages on client side In-Reply-To: <5487102F.10806@redhat.com> References: <5487102F.10806@redhat.com> Message-ID: <54896FBF.7010204@redhat.com> Hi, Dne 9.12.2014 v 16:07 Martin Basti napsal(a): > Ticket: https://fedorahosted.org/freeipa/ticket/4793 > > I'm able to reproduce it only in one nose test. Which test? > > Patch attached. What about: result['messages'] = result.get('messages', ()) + (message.to_dict(),) (My point is, don't support both lists and tuples, pick just one.) Honza -- Jan Cholasta From jcholast at redhat.com Thu Dec 11 10:23:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Dec 2014 11:23:03 +0100 Subject: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade In-Reply-To: <54895D6F.3050208@redhat.com> References: <54772621.5050003@redhat.com> <547C1CE8.5000707@redhat.com> <547C8DBD.2020204@redhat.com> <54887C50.7070701@redhat.com> <54888F33.3030200@redhat.com> <54895D6F.3050208@redhat.com> Message-ID: <54897087.4020408@redhat.com> Dne 11.12.2014 v 10:01 Martin Basti napsal(a): > On 10/12/14 19:21, Jan Cholasta wrote: >> Dne 10.12.2014 v 18:01 Jan Cholasta napsal(a): >>> Dne 1.12.2014 v 16:48 Martin Basti napsal(a): >>>> On 01/12/14 08:46, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 27.11.2014 v 14:24 Martin Basti napsal(a): >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4676 >>>>>> Replaces current workaround. Should go to 4.1.3. >>>>>> Patch attached. >>>>> >>>>> When constructing URLs with host:port, please use >>>>> ipautil.format_netloc(). >>>>> >>>>> wget should be added as a dependency of freeipa-python in the spec >>>>> file. >>>>> >>>>> Honza >>>>> >>>> Updated patch attached. >>>> >>> >>> Thanks, ACK. >>> >>> Pushed to: >>> master: 337faf506462a01c6dbcd00f2039ed5627691864 >>> ipa-4-1: 5052af773f652bc19e91fe49e15351e5c5c7d976 >>> >> >> It turns out I messed up the review (sorry). This fixes the upgrade, >> but it also breaks ipa-server-install: >> >> 2014-12-10T06:06:44Z DEBUG [8/27]: starting certificate server instance >> 2014-12-10T06:06:44Z DEBUG Starting external process >> 2014-12-10T06:06:44Z DEBUG args='/bin/systemctl' 'start' >> 'pki-tomcatd.target' >> 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 >> 2014-12-10T06:06:45Z DEBUG stdout= >> 2014-12-10T06:06:45Z DEBUG stderr= >> 2014-12-10T06:06:45Z DEBUG Starting external process >> 2014-12-10T06:06:45Z DEBUG args='/bin/systemctl' 'is-active' >> 'pki-tomcatd.target' >> 2014-12-10T06:06:45Z DEBUG Process finished, return code=0 >> 2014-12-10T06:06:45Z DEBUG stdout=active >> >> 2014-12-10T06:06:45Z DEBUG stderr= >> 2014-12-10T06:06:45Z DEBUG wait_for_open_ports: localhost [8080, 8443] >> timeout 300 >> 2014-12-10T06:06:49Z DEBUG The httpd proxy is not installed, wait on >> local port >> 2014-12-10T06:06:49Z DEBUG Waiting until the CA is running >> 2014-12-10T06:06:49Z DEBUG Starting external process >> 2014-12-10T06:06:49Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' >> '--timeout=30' >> 'https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus' >> 2014-12-10T06:07:09Z DEBUG Process finished, return code=5 >> 2014-12-10T06:07:09Z DEBUG stdout= >> 2014-12-10T06:07:09Z DEBUG stderr=--2014-12-10 01:06:49-- >> https://vm-088.idm.lab.bos.redhat.com:8443/ca/admin/ca/getStatus >> Resolving vm-088.idm.lab.bos.redhat.com >> (vm-088.idm.lab.bos.redhat.com)... 10.16.78.88 >> Connecting to vm-088.idm.lab.bos.redhat.com >> (vm-088.idm.lab.bos.redhat.com)|10.16.78.88|:8443... connected. >> ERROR: cannot verify vm-088.idm.lab.bos.redhat.com's certificate, >> issued by ?/O=IDM.LAB.BOS.REDHAT.COM/CN=Certificate Authority?: >> Self-signed certificate encountered. >> To connect to vm-088.idm.lab.bos.redhat.com insecurely, use >> `--no-check-certificate'. >> >> 2014-12-10T06:07:09Z DEBUG The CA status is: check interrupted >> >> >> I have reopened the ticket. >> > Patch with '--no-check-certificate' option attached. Before workaround > there was no certificate check, so it should not be problem if we ignore > the certificate. > Martin^2 > Thanks, ACK. Pushed to: master: 95becc1d542c78721088398eddbfd0d0ffe9b27f ipa-4-1: 8440c2ee97e1c7e29e20629a2579af28a6d654be -- Jan Cholasta From mbasti at redhat.com Thu Dec 11 11:05:00 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Dec 2014 12:05:00 +0100 Subject: [Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager In-Reply-To: References: <54886094.3040605@redhat.com> Message-ID: <54897A5C.7060602@redhat.com> On 11/12/14 05:01, Gabe Alford wrote: > Updated patch attached. > > Thanks, > > Gabe > > On Wed, Dec 10, 2014 at 8:02 AM, Martin Basti > wrote: > > On 10/12/14 15:45, Gabe Alford wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4783 > > Thanks, > > Gabe > > > Hello, thanks for patch. > > The patch needs rebase for IPA-4-1 branch > > Martin^2 > > -- > Martin Basti > > Thank you. ACK freeipa-rga-0040: master ACK freeipa-rga-0040-2: IPA-4-1 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Dec 11 11:13:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Dec 2014 12:13:54 +0100 Subject: [Freeipa-devel] [PATCH 0177] Fix adding (warning) messages on client side In-Reply-To: <54896FBF.7010204@redhat.com> References: <5487102F.10806@redhat.com> <54896FBF.7010204@redhat.com> Message-ID: <54897C72.90401@redhat.com> On 11/12/14 11:19, Jan Cholasta wrote: > Hi, > > Dne 9.12.2014 v 16:07 Martin Basti napsal(a): >> Ticket: https://fedorahosted.org/freeipa/ticket/4793 >> >> I'm able to reproduce it only in one nose test. > > Which test? If you apply my patch 170 and add a random forwardzone, then DNS root zone tests failed. > >> >> Patch attached. > > What about: > > result['messages'] = result.get('messages', ()) + > (message.to_dict(),) > > (My point is, don't support both lists and tuples, pick just one.) > > Honza > This is question for framework guru (you?), I tried to preserve format unchanged. Shouldn't be all values in lists in server part? Martin^2 -- Martin Basti From mkosek at redhat.com Thu Dec 11 13:17:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Dec 2014 14:17:00 +0100 Subject: [Freeipa-devel] [PATCH 0040] Remove dependency on subscription-manager In-Reply-To: <54897A5C.7060602@redhat.com> References: <54886094.3040605@redhat.com> <54897A5C.7060602@redhat.com> Message-ID: <5489994C.3020300@redhat.com> On 12/11/2014 12:05 PM, Martin Basti wrote: > On 11/12/14 05:01, Gabe Alford wrote: >> Updated patch attached. >> >> Thanks, >> >> Gabe >> >> On Wed, Dec 10, 2014 at 8:02 AM, Martin Basti > > wrote: >> >> On 10/12/14 15:45, Gabe Alford wrote: >> >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/4783 >> >> Thanks, >> >> Gabe >> >> >> Hello, thanks for patch. >> >> The patch needs rebase for IPA-4-1 branch >> >> Martin^2 >> >> -- Martin Basti >> >> > Thank you. > > ACK freeipa-rga-0040: master > ACK freeipa-rga-0040-2: IPA-4-1 Thanks Gabe and Martin! Pushed to master, ipa-4-1. Martin From lkrispen at redhat.com Thu Dec 11 13:18:36 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 11 Dec 2014 14:18:36 +0100 Subject: [Freeipa-devel] topology management question In-Reply-To: <20141205105028.73a9d284@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> Message-ID: <548999AC.6030801@redhat.com> On 12/05/2014 04:50 PM, Simo Sorce wrote: > On Thu, 04 Dec 2014 14:33:09 +0100 > Ludwig Krispenz wrote: > >> hi, >> >> I just have another (hopefully this will end soon) issue I want to >> get your input. (please read to teh end first) >> >> To recapture the conditions: >> - the topology plugin manages the connections between servers as >> segments in the shared tree >> - it is authoritative for managed servers, eg it controls all >> connections between servers listed under cn=masters, >> it is permissive for connection to other servers >> - it rejects any removal of a segment, which would disconnect the >> topology. >> - a change in topology can be applied to any server in the topology, >> it will reach the respective servers and the plugin will act upon it >> >> Now there is a special case, causing a bit of trouble. If a replica >> is to be removed from the topology, this means that >> the replication agreements from and to this replica should be >> removed, the server should be removed from the manages servers. >> The problem is that: >> - if you remove the server first, the server becomes unmanaged and >> removal of the segment will not trigger a removal of the replication >> agreement > Can you explain what you mean "if you remove the server first" exactly ? > What LDAP operation will be performed, by the management tools ? as far as the plugin is concerned a removal of a replica triggers two operations: - removal of the host from the sservers in cn=masters, so the server is no longer considered as managed - removal of the segment(s) connecting the to be removed replica to other still amnaged servers, which should remove the corresponding replication agreements. It was the order of these two operations I was talking > >> - if you remove the segments first, one segment will be the last one >> connecting this replica to the topology and removal will be rejected > We should never remove the segments first indeed. if we can fully control that only specific management tools can be used, we can define the order, but an admin could apply individual operations and still it would be good if nothing breaks > >> Now, with some effort this can be resolved, eg >> if the server is removed, keep it internally as removed server and >> for segments connecting this server trigger removal of replication >> agreements or mark a the last segment, when tried to remove, as >> pending and once the server is removed also remove the corresponding >> repl agreements > Why should we "keep it internally" ? > If you mark the agreements as managed by setting an attribute on them, > then you will never have any issue recognizing a "managed" agreement in > cn=config, and you will also immediately find out it is "old" as it is > not backed by a segment so you will safely remove it. I didn't want to add new flags/fields to the replication agreements as long as anything can be handled by the data in the shared tree. "internally" was probably misleading, but I will think about it again > > Segments (and their agreements) should be removed as trigger on the > master entry getting removed. This should be done even if it causes a > split brain, because if the server is removed, no matter how much we > wish to keep tropology integrity we effectively are in a split brain > situation, keeping toplogy agreements alive w/o the server entry > doesn't help. If we can agree on that, that presence/removal of masters is the primary trigger that's fine. I was thinking of situations where a server was removed, but not uninstalled. Just taking it out of the topology, but it could still be reached > >> But there is a problem, which I think is much harder and I am not >> sure how much effort I should put in resolving it. >> If we want to have the replication agreements cleaned up after >> removal of a replica without direct modification of cn=config, we >> need to follow the path above, >> but this also means that the last change needs to reach both the >> removed replica (R) and the last server(S) it is connected to. > It would be nice if the changed reached the replica, indeed, but not a > big deal if it doesn't, if you are removing the replica it means you > are decommissioning it, so it is not really that important that it > receives updates, it will be destroyed shortly. That's what I was not sure about, couldn't there be cases where it is not destroyed, just isolated. > And if it is not destroyed for whatever reason, it will be removed from > the masters group anyway so it will have no permission to replicate > back, and no harm is done to the overall domain. > >> The bad thing is that if this change triggers a >> removal of the replication agreement on S it could be that the change >> is not replicated to R before the agreement is removed and is lost. >> There is no way (or no easy) way to know for teh plugin if a change >> was received by an other server, > There is an easy way, contact the other server and see if the change > happened in its LDAP tree :) > BNut this is not really necessary, as explained above. > >> I was also thinking about some kind >> of acknowledge mechanism by doing a ping pong of changes, but the >> problem always is the same that one server does not know if the other >> has received it. >> And even if this would theoretically work, we cannot be sure that R >> is not shutdown and only the remaining topology is tried to be >> cleaned up, so S would wait forever. > We should not care, if you are deleting a replica it doesn't matter > what's on the replica side IMO. > >> My suggestion to resolve this (in most cases) is to define a wait >> interval, after the final combination of removal of a server and its >> connecting segment is received, wait for some time and then remove >> the corresponding replication agreements. > Why ? > >> So I'm asking you if this would be acceptable or if you have a better >> solution. > I am trying to understand why we have a problem, actually, I do not > really see one, why do you think it is important to update a replica > that is being killed ? because I had scenarios in mind where it would not be killed, just removed from the topology > > Simo. > From simo at redhat.com Thu Dec 11 14:05:04 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Dec 2014 09:05:04 -0500 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <54896726.6020001@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> <5488550A.3000400@redhat.com> <20141210125012.27c8943d@willson.usersys.redhat.com> <54896726.6020001@redhat.com> Message-ID: <20141211090505.79bd519d@willson.usersys.redhat.com> On Thu, 11 Dec 2014 10:43:02 +0100 Petr Spacek wrote: > On 10.12.2014 18:50, Simo Sorce wrote: > > On Wed, 10 Dec 2014 15:13:30 +0100 > > Petr Spacek wrote: > > > >> I think that external DNS could depend on Vault (assuming that > >> external DNS support will be purely optional). > > > > TBH, I do not think this is a sensible option, the Vault will drag > > huge dependencies for now, and I would like to avoid that if all we > > need is to add a couple of A/SRV records to an external DNS. > > > > If we can't come up with a service, I think I am ok telling admins > > they need to manually copy the TKEY (or use puppet or other similar > > configuration manager to push the key file around) on each replica, > > and we defer automatic distribution of TKEYs. > > > > We will have a service that can give out keys, it is identified as > > necessary in the replica promotion proposal, so we'll eventually get > > there. > > Thank you for discussion. Now I would like to know in which direction > are we heading with external DNS support :-) > > I have to admit that I don't understand why we are spending time on > Vault and at the same time we refuse to use it ... > > Anyway, someone competent has to decide if we want to implement > external DNS support and: > - defer key distribution for now I vote for deferring for now. Simo. > - use Vault > - re-invent Vault and use that new cool thing > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Dec 11 14:20:24 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Dec 2014 09:20:24 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <548999AC.6030801@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> Message-ID: <20141211092024.5449a932@willson.usersys.redhat.com> On Thu, 11 Dec 2014 14:18:36 +0100 Ludwig Krispenz wrote: > > On 12/05/2014 04:50 PM, Simo Sorce wrote: > > On Thu, 04 Dec 2014 14:33:09 +0100 > > Ludwig Krispenz wrote: > > > >> hi, > >> > >> I just have another (hopefully this will end soon) issue I want to > >> get your input. (please read to teh end first) > >> > >> To recapture the conditions: > >> - the topology plugin manages the connections between servers as > >> segments in the shared tree > >> - it is authoritative for managed servers, eg it controls all > >> connections between servers listed under cn=masters, > >> it is permissive for connection to other servers > >> - it rejects any removal of a segment, which would disconnect the > >> topology. > >> - a change in topology can be applied to any server in the > >> topology, it will reach the respective servers and the plugin will > >> act upon it > >> > >> Now there is a special case, causing a bit of trouble. If a replica > >> is to be removed from the topology, this means that > >> the replication agreements from and to this replica should be > >> removed, the server should be removed from the manages servers. > >> The problem is that: > >> - if you remove the server first, the server becomes unmanaged and > >> removal of the segment will not trigger a removal of the > >> replication agreement > > Can you explain what you mean "if you remove the server first" > > exactly ? What LDAP operation will be performed, by the management > > tools ? > as far as the plugin is concerned a removal of a replica triggers two > operations: > - removal of the host from the sservers in cn=masters, so the server > is no longer considered as managed > - removal of the segment(s) connecting the to be removed replica to > other still amnaged servers, which should remove the corresponding > replication agreements. > It was the order of these two operations I was talking We can define a correct order, the plugin can refuse to do any other order for direct operations (we need to be careful not to refuse replication operations I think). > > > >> - if you remove the segments first, one segment will be the last > >> one connecting this replica to the topology and removal will be > >> rejected > > We should never remove the segments first indeed. > if we can fully control that only specific management tools can be > used, we can define the order, but an admin could apply individual > operations and still it would be good if nothing breaks I think we had a plan to return UNWILLING_TO_PERFORM if the admin tries to remove the last segment first. So we would have no problem really, the admin can try and fail. If he wants to remove a master he'll have to remove it from the masters group, and this will trigger the removal of all segments. > >> Now, with some effort this can be resolved, eg > >> if the server is removed, keep it internally as removed server and > >> for segments connecting this server trigger removal of replication > >> agreements or mark a the last segment, when tried to remove, as > >> pending and once the server is removed also remove the > >> corresponding repl agreements > > Why should we "keep it internally" ? > > If you mark the agreements as managed by setting an attribute on > > them, then you will never have any issue recognizing a "managed" > > agreement in cn=config, and you will also immediately find out it > > is "old" as it is not backed by a segment so you will safely remove > > it. > I didn't want to add new flags/fields to the replication agreements > as long as anything can be handled by the data in the shared tree. We have too. I think it is a must or we will find numerous corner cases. Is there a specific reason why you do not want to add flags to replication agreements in cn=config ? > "internally" was probably misleading, but I will think about it again Ok, it is important we both understand what issues we see with any of the possible approaches so we can agree on the best one. > > Segments (and their agreements) should be removed as trigger on the > > master entry getting removed. This should be done even if it causes > > a split brain, because if the server is removed, no matter how much > > we wish to keep tropology integrity we effectively are in a split > > brain situation, keeping toplogy agreements alive w/o the server > > entry doesn't help. > If we can agree on that, that presence/removal of masters is the > primary trigger that's fine. Yes I think we can definitely agree that this is the primary trigger for server removal/addition. > I was thinking of situations where a server was removed, > but not uninstalled. Understood, but even then it makes no real difference, once the server is removed from the group of masters it will not be able to replicate outbound anymore as the other master's ACIs will not recognize this server credentials as valid replicator creds. > Just taking it out of the topology, but it could still be reached It can be reached, and that may be a problem for clients. But in the long term this should be true only for clients manually configured to reach that server. Clients that use SRV records would see it drop off, and switch to another one. We may consider whether we want some automatism that causes the server to shut itself down if it can't replicate (or receives replication data to the effect it realizes it is out of the topology). But this may be a little too drastic. > >> But there is a problem, which I think is much harder and I am not > >> sure how much effort I should put in resolving it. > >> If we want to have the replication agreements cleaned up after > >> removal of a replica without direct modification of cn=config, we > >> need to follow the path above, > >> but this also means that the last change needs to reach both the > >> removed replica (R) and the last server(S) it is connected to. > > It would be nice if the changed reached the replica, indeed, but > > not a big deal if it doesn't, if you are removing the replica it > > means you are decommissioning it, so it is not really that > > important that it receives updates, it will be destroyed shortly. > That's what I was not sure about, couldn't there be cases where it is > not destroyed, just isolated. Why would you isolate a server ? Is there a legitimate case an admin would want to do that ? > > And if it is not destroyed for whatever reason, it will be removed > > from the masters group anyway so it will have no permission to > > replicate back, and no harm is done to the overall domain. > > > >> The bad thing is that if this change triggers a > >> removal of the replication agreement on S it could be that the > >> change is not replicated to R before the agreement is removed and > >> is lost. There is no way (or no easy) way to know for teh plugin > >> if a change was received by an other server, > > There is an easy way, contact the other server and see if the change > > happened in its LDAP tree :) > > BNut this is not really necessary, as explained above. > > > >> I was also thinking about some kind > >> of acknowledge mechanism by doing a ping pong of changes, but the > >> problem always is the same that one server does not know if the > >> other has received it. > >> And even if this would theoretically work, we cannot be sure that R > >> is not shutdown and only the remaining topology is tried to be > >> cleaned up, so S would wait forever. > > We should not care, if you are deleting a replica it doesn't matter > > what's on the replica side IMO. > > > >> My suggestion to resolve this (in most cases) is to define a wait > >> interval, after the final combination of removal of a server and > >> its connecting segment is received, wait for some time and then > >> remove the corresponding replication agreements. > > Why ? > > > >> So I'm asking you if this would be acceptable or if you have a > >> better solution. > > I am trying to understand why we have a problem, actually, I do not > > really see one, why do you think it is important to update a replica > > that is being killed ? > because I had scenarios in mind where it would not be killed, just > removed from the topology Ok, but I do not see what it would be a legitimate action to cause a server to get out. But even if that happens the server won't be able to replicate back to the domain until the admin takes the step of putting the server back into the masters group (causing replication to be restored both ways), so I see no harm. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Dec 11 14:36:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Dec 2014 15:36:55 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <20141211090505.79bd519d@willson.usersys.redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <547DD31C.1020106@redhat.com> <20141202112107.1d0032d7@willson.usersys.redhat.com> <547F348E.3090401@redhat.com> <5486EDB1.50500@redhat.com> <5488550A.3000400@redhat.com> <20141210125012.27c8943d@willson.usersys.redhat.com> <54896726.6020001@redhat.com> <20141211090505.79bd519d@willson.usersys.redhat.com> Message-ID: <5489AC07.6040800@redhat.com> On 12/11/2014 03:05 PM, Simo Sorce wrote: > On Thu, 11 Dec 2014 10:43:02 +0100 > Petr Spacek wrote: > >> On 10.12.2014 18:50, Simo Sorce wrote: >>> On Wed, 10 Dec 2014 15:13:30 +0100 >>> Petr Spacek wrote: >>> >>>> I think that external DNS could depend on Vault (assuming that >>>> external DNS support will be purely optional). >>> >>> TBH, I do not think this is a sensible option, the Vault will drag >>> huge dependencies for now, and I would like to avoid that if all we >>> need is to add a couple of A/SRV records to an external DNS. >>> >>> If we can't come up with a service, I think I am ok telling admins >>> they need to manually copy the TKEY (or use puppet or other similar >>> configuration manager to push the key file around) on each replica, >>> and we defer automatic distribution of TKEYs. >>> >>> We will have a service that can give out keys, it is identified as >>> necessary in the replica promotion proposal, so we'll eventually get >>> there. >> >> Thank you for discussion. Now I would like to know in which direction >> are we heading with external DNS support :-) >> >> I have to admit that I don't understand why we are spending time on >> Vault and at the same time we refuse to use it ... >> >> Anyway, someone competent has to decide if we want to implement >> external DNS support and: >> - defer key distribution for now > > I vote for deferring for now. > > Simo. +1, we can defer until we have the Simo's KISS service from replica promotion work: http://www.freeipa.org/page/V4/Replica_Promotion#Key_Interchange_Security_Service_.28KISS.29 Same as Simo, I would also rather avoid the dependency on PKI&Vault for this base infrastructure feature orthogonal to FreeIPA PKI. Martin From tbabej at redhat.com Thu Dec 11 14:43:09 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Dec 2014 15:43:09 +0100 Subject: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply In-Reply-To: <54896CED.6030908@redhat.com> References: <5489549A.5080802@redhat.com> <54896CED.6030908@redhat.com> Message-ID: <5489AD7D.5080801@redhat.com> On 12/11/2014 11:07 AM, Jan Cholasta wrote: > Hi, > > Dne 11.12.2014 v 09:23 Tomas Babej napsal(a): >> Hi, >> >> When running a idview-apply command, the hosts that were already >> assigned >> the desired view were silently ignored. Make sure such hosts show up in >> the list of failed hosts. >> >> https://fedorahosted.org/freeipa/ticket/4743 > > Shouldn't the error message strings be translatable? > Sure, why not. Good point, I transformed the other error message string as well. Updated patch attach. > Honza > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0291-2-idviews-Complain-if-host-is-already-assigned-the-ID-.patch Type: text/x-patch Size: 1469 bytes Desc: not available URL: From pspacek at redhat.com Thu Dec 11 15:28:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Dec 2014 16:28:16 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <548880E6.4010105@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> Message-ID: <5489B810.60801@redhat.com> Hello, I have only few nitpicks and one minor non-nitpick. Rest is in-line. On 10.12.2014 18:20, Martin Basti wrote: > freeipa-mbasti-0170.4-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch > > > From a1b70e7a12ffdb08941d43587a05d7e36b57ab2b Mon Sep 17 00:00:00 2001 > From: Martin Basti > Date: Fri, 21 Nov 2014 16:54:09 +0100 > Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration > > Shows warning if forward and parent authoritative zone do not have > proper NS record delegation, which can cause the forward zone will be > ineffective and forwarding will not work. > > Ticket: https://fedorahosted.org/freeipa/ticket/4721 > --- > ipalib/messages.py | 13 ++ > ipalib/plugins/dns.py | 332 ++++++++++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 334 insertions(+), 11 deletions(-) > > diff --git a/ipalib/messages.py b/ipalib/messages.py > index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..b44beca729f5483a7241e4c98a9f724ed663e70f 100644 > --- a/ipalib/messages.py > +++ b/ipalib/messages.py > @@ -200,6 +200,19 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage): > u"If DNSSEC validation is enabled on IPA server(s), " > u"please disable it.") > > +class ForwardzoneIsNotEffectiveWarning(PublicMessage): > + """ > + **13008** Forwardzone is not effective, forwarding will not work because > + there is authoritative parent zone, without proper NS delegation > + """ > + > + errno = 13008 > + type = "warning" > + format = _(u"forward zone \"%(fwzone)s\" is not effective because of " > + u"missing proper NS delegation in authoritative zone " > + u"\"%(authzone)s\". Please add NS record " > + u"\"%(ns_rec)s\" to parent zone \"%(authzone)s\".") > + > > def iter_messages(variables, base): > """Return a tuple with all subclasses > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..5c3a017989b23a1c6076d9dc4d93be65dd66cc67 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -1725,6 +1725,241 @@ def _normalize_zone(zone): > return zone > > > +def _get_auth_zone_ldap(name): > + """ > + Find authoritative zone in LDAP for name Nitpick: Please add this note: . Only active zones are considered. > + :param name: > + :return: (zone, truncated) > + zone: authoritative zone, or None if authoritative zone is not in LDAP > + """ > + assert isinstance(name, DNSName) > + ldap = api.Backend.ldap2 > + > + # Create all possible parent zone names > + search_name = name.make_absolute() > + zone_names = [] > + for i in xrange(len(search_name)): > + zone_name_abs = DNSName(search_name[i:]).ToASCII() > + zone_names.append(zone_name_abs) > + # compatibility with IPA < 4.0, zone name can be relative > + zone_names.append(zone_name_abs[:-1]) > + > + # Create filters > + objectclass_filter = ldap.make_filter({'objectclass':'idnszone'}) > + zonenames_filter = ldap.make_filter({'idnsname': zone_names}) > + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) > + complete_filter = ldap.combine_filters( > + [objectclass_filter, zonenames_filter, zoneactive_filter], > + rules=ldap.MATCH_ALL > + ) > + > + try: > + entries, truncated = ldap.find_entries( > + filter=complete_filter, > + attrs_list=['idnsname'], > + base_dn=DN(api.env.container_dns, api.env.basedn), > + scope=ldap.SCOPE_ONELEVEL > + ) > + except errors.NotFound: > + return None, False > + > + # always use absolute zones > + matched_auth_zones = [entry.single_value['idnsname'].make_absolute() > + for entry in entries] > + > + # return longest match > + return max(matched_auth_zones, key=len), truncated > + > + > +def _get_longest_match_ns_delegation_ldap(zone, name): > + """ > + Finds record in LDAP which has the longest match with name. > + > + NOTE: does not search in zone apex, returns None if there is no NS > + delegation outside of zone apex Nitpick: Searches for deepest delegation for name in LDAP zone. NOTE: NS record in zone apex is not considered as delegation. It returns None if there is no delegation outside of zone apex. > + > + Example: > + zone: example.com. > + name: ns.sub.example.com. > + > + records: > + extra.ns.sub.example.com. > + sub.example.com. > + example.com > + > + result: sub.example.com. > + > + :param zone: zone name > + :param name: > + :return: (record, truncated); > + record: record name if success, or None if no such record exists, or > + record is zone apex record Nitpick: :return: (match, truncated); match: delegation name if success, or None if no delegation record exists > + """ > + assert isinstance(zone, DNSName) > + assert isinstance(name, DNSName) > + > + ldap = api.Backend.ldap2 > + > + # get zone DN > + zone_dn = api.Object.dnszone.get_dn(zone) > + > + if name.is_absolute(): > + relative_record_name = name.relativize(zone.make_absolute()) > + else: > + relative_record_name = name > + > + # Name is zone apex > + if relative_record_name.is_empty(): > + return None, False > + > + # create list of possible record names > + possible_record_names = [DNSName(relative_record_name[i:]).ToASCII() > + for i in xrange(len(relative_record_name))] > + > + # search filters > + name_filter = ldap.make_filter({'idnsname': [possible_record_names]}) > + objectclass_filter = ldap.make_filter({'objectclass': 'idnsrecord'}) > + complete_filter = ldap.combine_filters( > + [name_filter, objectclass_filter], > + rules=ldap.MATCH_ALL > + ) > + > + try: > + entries, truncated = ldap.find_entries( > + filter=complete_filter, > + attrs_list=['idnsname', 'nsrecord'], > + base_dn=zone_dn, > + scope=ldap.SCOPE_ONELEVEL > + ) > + except errors.NotFound: > + return None, False > + > + matched_records = [] > + > + # test if entry contains NS records > + for entry in entries: > + print entry Not-a-nitpick :-) ^^^ > + if entry.get('nsrecord'): > + matched_records.append(entry.single_value['idnsname']) > + > + if not matched_records: > + return None, truncated > + > + # return longest match > + return max(matched_records, key=len), truncated > + > + > +def _find_subtree_forward_zones_ldap(name, child_zones_only=False): > + """ > + Search for forwardzone and all child forwardzones > + Filter: (|(*..)(.)) > + :param name: > + :param child_zones_only: search only for child zones > + :return: (list of zonenames, truncated), list is empty if no zone found > + """ > + assert isinstance(name, DNSName) > + ldap = api.Backend.ldap2 > + > + # prepare for filter "*.." > + search_name = u".%s" % name.make_absolute().ToASCII() > + > + # we need to search zone with and without last dot, due compatibility > + # with IPA < 4.0 > + search_names = [search_name, search_name[:-1]] > + > + # Create filters > + objectclass_filter = ldap.make_filter({'objectclass':'idnsforwardzone'}) > + zonenames_filter = ldap.make_filter({'idnsname': search_names}, exact=False, > + trailing_wildcard=False) > + if not child_zones_only: > + # find also zone with exact name > + exact_name = name.make_absolute().ToASCII() > + # we need to search zone with and without last dot, due compatibility > + # with IPA < 4.0 > + exact_names = [exact_name, exact_name[-1]] > + exact_name_filter = ldap.make_filter({'idnsname': exact_names}) > + zonenames_filter = ldap.combine_filters([zonenames_filter, > + exact_name_filter]) > + > + zoneactive_filter = ldap.make_filter({'idnsZoneActive': 'true'}) > + complete_filter = ldap.combine_filters( > + [objectclass_filter, zonenames_filter, zoneactive_filter], > + rules=ldap.MATCH_ALL > + ) > + > + try: > + entries, truncated = ldap.find_entries( > + filter=complete_filter, > + attrs_list=['idnsname'], > + base_dn=DN(api.env.container_dns, api.env.basedn), > + scope=ldap.SCOPE_ONELEVEL > + ) > + except errors.NotFound: > + return [], False > + > + result = [entry.single_value['idnsname'].make_absolute() > + for entry in entries] > + > + return result, truncated > + > + > +def _get_zone_which_makes_fw_zone_ineffective(fwzonename): > + """ > + Check if forward zone is effective. > + > + If parent zone exists as authoritative zone, the forward zone will not > + forward queries by default. It is necessary to delegate authority > + to forward zone with a NS record. > + > + Example: > + > + Forward zone: sub.example.com > + Zone: example.com > + > + Forwarding will not work, because the server thinks it is authoritative > + for zone and will return NXDOMAIN > + > + Adding record: sub.example.com NS ns.sub.example.com. > + will delegate authority, and IPA DNS server will forward DNS queries. > + > + :param fwzonename: forwardzone > + :return: (zone, truncated) > + zone: None if effective, name of authoritative zone otherwise > + """ > + assert isinstance(fwzonename, DNSName) > + > + auth_zone, truncated_zone = _get_auth_zone_ldap(fwzonename) > + if not auth_zone: > + return None, truncated_zone > + > + delegation_record_name, truncated_ns =\ > + _get_longest_match_ns_delegation_ldap(auth_zone, fwzonename) > + > + truncated = truncated_ns or truncated_zone > + > + if delegation_record_name: > + return None, truncated > + > + return auth_zone, truncated > + > + > +def _add_warning_fw_zone_is_not_effective(result, fwzone, version): > + """ > + Adds warning message to result, if required > + """ > + authoritative_zone, truncated = \ > + _get_zone_which_makes_fw_zone_ineffective(fwzone) > + if authoritative_zone: > + # forward zone is not effective and forwarding will not work > + messages.add_message( > + version, result, > + messages.ForwardzoneIsNotEffectiveWarning( > + fwzone=fwzone, authzone=authoritative_zone, > + ns_rec=fwzone.relativize(authoritative_zone) > + ) > + ) > + > + > class DNSZoneBase(LDAPObject): > """ > Base class for DNS Zone > @@ -2376,6 +2611,22 @@ class dnszone(DNSZoneBase): > ) > ) > > + def _warning_fw_zone_is_not_effective(self, result, *keys, **options): > + """ > + Warning if any operation with zone causes, a child forward zone is > + not effective > + """ > + zone = keys[-1] > + affected_fw_zones, truncated = _find_subtree_forward_zones_ldap( > + zone, child_zones_only=True) > + if not affected_fw_zones: > + return > + > + for fwzone in affected_fw_zones: > + _add_warning_fw_zone_is_not_effective(result, fwzone, > + options['version']) > + > + > @register() > class dnszone_add(DNSZoneBase_add): > __doc__ = _('Create new DNS zone (SOA record).') > @@ -2445,6 +2696,7 @@ class dnszone_add(DNSZoneBase_add): > self.obj._warning_forwarding(result, **options) > self.obj._warning_dnssec_experimental(result, *keys, **options) > self.obj._warning_name_server_option(result, context, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -2475,6 +2727,13 @@ class dnszone_del(DNSZoneBase_del): > > msg_summary = _('Deleted DNS zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnszone_del, self).execute(*keys, **options) > + nkeys = keys[-1] # we can delete more zones > + for key in nkeys: > + self.obj._warning_fw_zone_is_not_effective(result, key, **options) > + return result > + > def post_callback(self, ldap, dn, *keys, **options): > super(dnszone_del, self).post_callback(ldap, dn, *keys, **options) > > @@ -2595,12 +2854,22 @@ class dnszone_disable(DNSZoneBase_disable): > __doc__ = _('Disable DNS Zone.') > msg_summary = _('Disabled DNS zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnszone_disable, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnszone_enable(DNSZoneBase_enable): > __doc__ = _('Enable DNS Zone.') > msg_summary = _('Enabled DNS zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnszone_enable, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnszone_add_permission(DNSZoneBase_add_permission): > @@ -3164,6 +3433,25 @@ class dnsrecord(LDAPObject): > dns_name = entry_name[1].derelativize(dns_domain) > self.wait_for_modified_attrs(entry, dns_name, dns_domain) > > + def warning_if_ns_change_cause_fwzone_ineffective(self, result, *keys, > + **options): > + """Detect if NS record change can make forward zones ineffective due > + missing delegation. Run after parent's execute method method. Nitpick: method. > + """ > + record_name_absolute = keys[-1] > + zone = keys[-2] > + > + if not record_name_absolute.is_absolute(): > + record_name_absolute = record_name_absolute.derelativize(zone) > + > + affected_fw_zones, truncated = _find_subtree_forward_zones_ldap( > + record_name_absolute) > + if not affected_fw_zones: > + return > + > + for fwzone in affected_fw_zones: > + _add_warning_fw_zone_is_not_effective(result, fwzone, > + options['version']) > > > @register() > @@ -3487,7 +3775,10 @@ class dnsrecord_mod(LDAPUpdate): > > if self.api.env['wait_for_dns']: > self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > - > + if 'nsrecord' in options: > + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, > + *keys, > + **options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -3654,19 +3945,23 @@ class dnsrecord_del(LDAPUpdate): > if self.api.env['wait_for_dns']: > entries = {(keys[0], keys[1]): None} > self.obj.wait_for_modified_entries(entries) > - return result > + else: > + result = super(dnsrecord_del, self).execute(*keys, **options) > + result['value'] = pkey_to_value([keys[-1]], options) > > - result = super(dnsrecord_del, self).execute(*keys, **options) > - result['value'] = pkey_to_value([keys[-1]], options) > + if getattr(context, 'del_all', False) and not \ > + self.obj.is_pkey_zone_record(*keys): > + result = self.obj.methods.delentry(*keys, > + version=options['version']) > + context.dnsrecord_entry_mods[(keys[0], keys[1])] = None > > - if getattr(context, 'del_all', False) and not \ > - self.obj.is_pkey_zone_record(*keys): > - result = self.obj.methods.delentry(*keys, > - version=options['version']) > - context.dnsrecord_entry_mods[(keys[0], keys[1])] = None > + if self.api.env['wait_for_dns']: > + self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > > - if self.api.env['wait_for_dns']: > - self.obj.wait_for_modified_entries(context.dnsrecord_entry_mods) > + if 'nsrecord' in options or options.get('del_all', False): > + self.obj.warning_if_ns_change_cause_fwzone_ineffective(result, > + *keys, > + **options) > return result > > def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > @@ -3998,6 +4293,11 @@ class dnsforwardzone(DNSZoneBase): > # managed_permissions: permissions was apllied in dnszone class, do NOT > # add them here, they should not be applied twice. > > + def _warning_fw_zone_is_not_effective(self, result, *keys, **options): > + fwzone = keys[-1] > + _add_warning_fw_zone_is_not_effective(result, fwzone, > + options['version']) > + > > @register() > class dnsforwardzone_add(DNSZoneBase_add): > @@ -4019,6 +4319,11 @@ class dnsforwardzone_add(DNSZoneBase_add): > > return dn > > + def execute(self, *keys, **options): > + result = super(dnsforwardzone_add, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnsforwardzone_del(DNSZoneBase_del): > @@ -4083,6 +4388,11 @@ class dnsforwardzone_enable(DNSZoneBase_enable): > __doc__ = _('Enable DNS Forward Zone.') > msg_summary = _('Enabled DNS forward zone "%(value)s"') > > + def execute(self, *keys, **options): > + result = super(dnsforwardzone_enable, self).execute(*keys, **options) > + self.obj._warning_fw_zone_is_not_effective(result, *keys, **options) > + return result > + > > @register() > class dnsforwardzone_add_permission(DNSZoneBase_add_permission): > -- 1.8.3.1 Thank you for patience! -- Petr^2 Spacek From mbasti at redhat.com Thu Dec 11 15:50:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 11 Dec 2014 16:50:56 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <5489B810.60801@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> <5489B810.60801@redhat.com> Message-ID: <5489BD60.8000100@redhat.com> Updated aptch attached: diff with previous: diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py index f9d8321..7a80036 100644 --- a/ipalib/plugins/dns.py +++ b/ipalib/plugins/dns.py @@ -1735,7 +1735,7 @@ def _normalize_zone(zone): def _get_auth_zone_ldap(name): """ - Find authoritative zone in LDAP for name + Find authoritative zone in LDAP for name. Only active zones are considered. :param name: :return: (zone, truncated) zone: authoritative zone, or None if authoritative zone is not in LDAP @@ -1781,10 +1781,10 @@ def _get_auth_zone_ldap(name): def _get_longest_match_ns_delegation_ldap(zone, name): """ - Finds record in LDAP which has the longest match with name. + Searches for deepest delegation for name in LDAP zone. - NOTE: does not search in zone apex, returns None if there is no NS - delegation outside of zone apex + NOTE: NS record in zone apex is not considered as delegation. + It returns None if there is no delegation outside of zone apex. Example: zone: example.com. @@ -1799,9 +1799,8 @@ def _get_longest_match_ns_delegation_ldap(zone, name): :param zone: zone name :param name: - :return: (record, truncated); - record: record name if success, or None if no such record exists, or - record is zone apex record + :return: (match, truncated); + match: delegation name if success, or None if no delegation record exists """ assert isinstance(zone, DNSName) assert isinstance(name, DNSName) @@ -1846,7 +1845,6 @@ def _get_longest_match_ns_delegation_ldap(zone, name): # test if entry contains NS records for entry in entries: - print entry if entry.get('nsrecord'): matched_records.append(entry.single_value['idnsname']) @@ -3444,7 +3442,7 @@ class dnsrecord(LDAPObject): def warning_if_ns_change_cause_fwzone_ineffective(self, result, *keys, **options): """Detect if NS record change can make forward zones ineffective due - missing delegation. Run after parent's execute method method. + missing delegation. Run after parent's execute method. """ record_name_absolute = keys[-1] zone = keys[-2] -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0170.5-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch Type: text/x-patch Size: 17035 bytes Desc: not available URL: From pspacek at redhat.com Thu Dec 11 16:03:55 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Dec 2014 17:03:55 +0100 Subject: [Freeipa-devel] topology management question In-Reply-To: <20141211092024.5449a932@willson.usersys.redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> Message-ID: <5489C06B.7030100@redhat.com> On 11.12.2014 15:20, Simo Sorce wrote: > On Thu, 11 Dec 2014 14:18:36 +0100 > Ludwig Krispenz wrote: > >> >> On 12/05/2014 04:50 PM, Simo Sorce wrote: >>> On Thu, 04 Dec 2014 14:33:09 +0100 >>> Ludwig Krispenz wrote: >>> >>>> hi, >>>> >>>> I just have another (hopefully this will end soon) issue I want to >>>> get your input. (please read to teh end first) >>>> >>>> To recapture the conditions: >>>> - the topology plugin manages the connections between servers as >>>> segments in the shared tree >>>> - it is authoritative for managed servers, eg it controls all >>>> connections between servers listed under cn=masters, >>>> it is permissive for connection to other servers >>>> - it rejects any removal of a segment, which would disconnect the >>>> topology. >>>> - a change in topology can be applied to any server in the >>>> topology, it will reach the respective servers and the plugin will >>>> act upon it >>>> >>>> Now there is a special case, causing a bit of trouble. If a replica >>>> is to be removed from the topology, this means that >>>> the replication agreements from and to this replica should be >>>> removed, the server should be removed from the manages servers. >>>> The problem is that: >>>> - if you remove the server first, the server becomes unmanaged and >>>> removal of the segment will not trigger a removal of the >>>> replication agreement >>> Can you explain what you mean "if you remove the server first" >>> exactly ? What LDAP operation will be performed, by the management >>> tools ? >> as far as the plugin is concerned a removal of a replica triggers two >> operations: >> - removal of the host from the sservers in cn=masters, so the server >> is no longer considered as managed >> - removal of the segment(s) connecting the to be removed replica to >> other still amnaged servers, which should remove the corresponding >> replication agreements. >> It was the order of these two operations I was talking > > We can define a correct order, the plugin can refuse to do any other > order for direct operations (we need to be careful not to refuse > replication operations I think). > >>> >>>> - if you remove the segments first, one segment will be the last >>>> one connecting this replica to the topology and removal will be >>>> rejected >>> We should never remove the segments first indeed. >> if we can fully control that only specific management tools can be >> used, we can define the order, but an admin could apply individual >> operations and still it would be good if nothing breaks > > I think we had a plan to return UNWILLING_TO_PERFORM if the admin tries > to remove the last segment first. So we would have no problem really, > the admin can try and fail. If he wants to remove a master he'll have > to remove it from the masters group, and this will trigger the removal > of all segments. > >>>> Now, with some effort this can be resolved, eg >>>> if the server is removed, keep it internally as removed server and >>>> for segments connecting this server trigger removal of replication >>>> agreements or mark a the last segment, when tried to remove, as >>>> pending and once the server is removed also remove the >>>> corresponding repl agreements >>> Why should we "keep it internally" ? >>> If you mark the agreements as managed by setting an attribute on >>> them, then you will never have any issue recognizing a "managed" >>> agreement in cn=config, and you will also immediately find out it >>> is "old" as it is not backed by a segment so you will safely remove >>> it. >> I didn't want to add new flags/fields to the replication agreements >> as long as anything can be handled by the data in the shared tree. > > We have too. I think it is a must or we will find numerous corner cases. > Is there a specific reason why you do not want to add flags to > replication agreements in cn=config ? > >> "internally" was probably misleading, but I will think about it again > > Ok, it is important we both understand what issues we see with any of > the possible approaches so we can agree on the best one. > >>> Segments (and their agreements) should be removed as trigger on the >>> master entry getting removed. This should be done even if it causes >>> a split brain, because if the server is removed, no matter how much >>> we wish to keep tropology integrity we effectively are in a split >>> brain situation, keeping toplogy agreements alive w/o the server >>> entry doesn't help. >> If we can agree on that, that presence/removal of masters is the >> primary trigger that's fine. > > Yes I think we can definitely agree that this is the primary trigger > for server removal/addition. > >> I was thinking of situations where a server was removed, >> but not uninstalled. > > Understood, but even then it makes no real difference, once the server > is removed from the group of masters it will not be able to replicate > outbound anymore as the other master's ACIs will not recognize this > server credentials as valid replicator creds. > >> Just taking it out of the topology, but it could still be reached > > It can be reached, and that may be a problem for clients. But in the > long term this should be true only for clients manually configured to > reach that server. Clients that use SRV records would see it drop off, > and switch to another one. > > We may consider whether we want some automatism that causes the server > to shut itself down if it can't replicate (or receives replication data > to the effect it realizes it is out of the topology). But this may be a > little too drastic. > >>>> But there is a problem, which I think is much harder and I am not >>>> sure how much effort I should put in resolving it. >>>> If we want to have the replication agreements cleaned up after >>>> removal of a replica without direct modification of cn=config, we >>>> need to follow the path above, >>>> but this also means that the last change needs to reach both the >>>> removed replica (R) and the last server(S) it is connected to. >>> It would be nice if the changed reached the replica, indeed, but >>> not a big deal if it doesn't, if you are removing the replica it >>> means you are decommissioning it, so it is not really that >>> important that it receives updates, it will be destroyed shortly. >> That's what I was not sure about, couldn't there be cases where it is >> not destroyed, just isolated. > > Why would you isolate a server ? Is there a legitimate case an admin > would want to do that ? I know about one use case: Upgrade testing. Recipe: - Install new replica. - Connect it to existing topology and suck in all the data. - Disconnect the new replica from rest of topology. - Do upgrade experiments. - Destroy the new/'experimental' replica. Petr^2 Spacek >>> And if it is not destroyed for whatever reason, it will be removed >>> from the masters group anyway so it will have no permission to >>> replicate back, and no harm is done to the overall domain. >>> >>>> The bad thing is that if this change triggers a >>>> removal of the replication agreement on S it could be that the >>>> change is not replicated to R before the agreement is removed and >>>> is lost. There is no way (or no easy) way to know for teh plugin >>>> if a change was received by an other server, >>> There is an easy way, contact the other server and see if the change >>> happened in its LDAP tree :) >>> BNut this is not really necessary, as explained above. >>> >>>> I was also thinking about some kind >>>> of acknowledge mechanism by doing a ping pong of changes, but the >>>> problem always is the same that one server does not know if the >>>> other has received it. >>>> And even if this would theoretically work, we cannot be sure that R >>>> is not shutdown and only the remaining topology is tried to be >>>> cleaned up, so S would wait forever. >>> We should not care, if you are deleting a replica it doesn't matter >>> what's on the replica side IMO. >>> >>>> My suggestion to resolve this (in most cases) is to define a wait >>>> interval, after the final combination of removal of a server and >>>> its connecting segment is received, wait for some time and then >>>> remove the corresponding replication agreements. >>> Why ? >>> >>>> So I'm asking you if this would be acceptable or if you have a >>>> better solution. >>> I am trying to understand why we have a problem, actually, I do not >>> really see one, why do you think it is important to update a replica >>> that is being killed ? >> because I had scenarios in mind where it would not be killed, just >> removed from the topology > > Ok, but I do not see what it would be a legitimate action to cause a > server to get out. But even if that happens the server won't be able to > replicate back to the domain until the admin takes the step of putting > the server back into the masters group (causing replication to be > restored both ways), so I see no harm. > > Simo. From simo at redhat.com Thu Dec 11 16:38:01 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Dec 2014 11:38:01 -0500 Subject: [Freeipa-devel] topology management question In-Reply-To: <5489C06B.7030100@redhat.com> References: <54806295.4040404@redhat.com> <20141205105028.73a9d284@willson.usersys.redhat.com> <548999AC.6030801@redhat.com> <20141211092024.5449a932@willson.usersys.redhat.com> <5489C06B.7030100@redhat.com> Message-ID: <20141211113801.116fe0e1@willson.usersys.redhat.com> On Thu, 11 Dec 2014 17:03:55 +0100 Petr Spacek wrote: > On 11.12.2014 15:20, Simo Sorce wrote: > > On Thu, 11 Dec 2014 14:18:36 +0100 > > Ludwig Krispenz wrote: > > > >> > >> On 12/05/2014 04:50 PM, Simo Sorce wrote: > >>> On Thu, 04 Dec 2014 14:33:09 +0100 > >>> Ludwig Krispenz wrote: > >>> > >>>> hi, > >>>> > >>>> I just have another (hopefully this will end soon) issue I want > >>>> to get your input. (please read to teh end first) > >>>> > >>>> To recapture the conditions: > >>>> - the topology plugin manages the connections between servers as > >>>> segments in the shared tree > >>>> - it is authoritative for managed servers, eg it controls all > >>>> connections between servers listed under cn=masters, > >>>> it is permissive for connection to other servers > >>>> - it rejects any removal of a segment, which would disconnect the > >>>> topology. > >>>> - a change in topology can be applied to any server in the > >>>> topology, it will reach the respective servers and the plugin > >>>> will act upon it > >>>> > >>>> Now there is a special case, causing a bit of trouble. If a > >>>> replica is to be removed from the topology, this means that > >>>> the replication agreements from and to this replica should be > >>>> removed, the server should be removed from the manages servers. > >>>> The problem is that: > >>>> - if you remove the server first, the server becomes unmanaged > >>>> and removal of the segment will not trigger a removal of the > >>>> replication agreement > >>> Can you explain what you mean "if you remove the server first" > >>> exactly ? What LDAP operation will be performed, by the management > >>> tools ? > >> as far as the plugin is concerned a removal of a replica triggers > >> two operations: > >> - removal of the host from the sservers in cn=masters, so the > >> server is no longer considered as managed > >> - removal of the segment(s) connecting the to be removed replica > >> to other still amnaged servers, which should remove the > >> corresponding replication agreements. > >> It was the order of these two operations I was talking > > > > We can define a correct order, the plugin can refuse to do any other > > order for direct operations (we need to be careful not to refuse > > replication operations I think). > > > >>> > >>>> - if you remove the segments first, one segment will be the last > >>>> one connecting this replica to the topology and removal will be > >>>> rejected > >>> We should never remove the segments first indeed. > >> if we can fully control that only specific management tools can be > >> used, we can define the order, but an admin could apply individual > >> operations and still it would be good if nothing breaks > > > > I think we had a plan to return UNWILLING_TO_PERFORM if the admin > > tries to remove the last segment first. So we would have no problem > > really, the admin can try and fail. If he wants to remove a master > > he'll have to remove it from the masters group, and this will > > trigger the removal of all segments. > > > >>>> Now, with some effort this can be resolved, eg > >>>> if the server is removed, keep it internally as removed server > >>>> and for segments connecting this server trigger removal of > >>>> replication agreements or mark a the last segment, when tried to > >>>> remove, as pending and once the server is removed also remove the > >>>> corresponding repl agreements > >>> Why should we "keep it internally" ? > >>> If you mark the agreements as managed by setting an attribute on > >>> them, then you will never have any issue recognizing a "managed" > >>> agreement in cn=config, and you will also immediately find out it > >>> is "old" as it is not backed by a segment so you will safely > >>> remove it. > >> I didn't want to add new flags/fields to the replication agreements > >> as long as anything can be handled by the data in the shared tree. > > > > We have too. I think it is a must or we will find numerous corner > > cases. Is there a specific reason why you do not want to add flags > > to replication agreements in cn=config ? > > > >> "internally" was probably misleading, but I will think about it > >> again > > > > Ok, it is important we both understand what issues we see with any > > of the possible approaches so we can agree on the best one. > > > >>> Segments (and their agreements) should be removed as trigger on > >>> the master entry getting removed. This should be done even if it > >>> causes a split brain, because if the server is removed, no matter > >>> how much we wish to keep tropology integrity we effectively are > >>> in a split brain situation, keeping toplogy agreements alive w/o > >>> the server entry doesn't help. > >> If we can agree on that, that presence/removal of masters is the > >> primary trigger that's fine. > > > > Yes I think we can definitely agree that this is the primary trigger > > for server removal/addition. > > > >> I was thinking of situations where a server was removed, > >> but not uninstalled. > > > > Understood, but even then it makes no real difference, once the > > server is removed from the group of masters it will not be able to > > replicate outbound anymore as the other master's ACIs will not > > recognize this server credentials as valid replicator creds. > > > >> Just taking it out of the topology, but it could still be reached > > > > It can be reached, and that may be a problem for clients. But in the > > long term this should be true only for clients manually configured > > to reach that server. Clients that use SRV records would see it > > drop off, and switch to another one. > > > > We may consider whether we want some automatism that causes the > > server to shut itself down if it can't replicate (or receives > > replication data to the effect it realizes it is out of the > > topology). But this may be a little too drastic. > > > >>>> But there is a problem, which I think is much harder and I am not > >>>> sure how much effort I should put in resolving it. > >>>> If we want to have the replication agreements cleaned up after > >>>> removal of a replica without direct modification of cn=config, we > >>>> need to follow the path above, > >>>> but this also means that the last change needs to reach both the > >>>> removed replica (R) and the last server(S) it is connected to. > >>> It would be nice if the changed reached the replica, indeed, but > >>> not a big deal if it doesn't, if you are removing the replica it > >>> means you are decommissioning it, so it is not really that > >>> important that it receives updates, it will be destroyed shortly. > >> That's what I was not sure about, couldn't there be cases where it > >> is not destroyed, just isolated. > > > > Why would you isolate a server ? Is there a legitimate case an admin > > would want to do that ? > > I know about one use case: Upgrade testing. > > Recipe: > - Install new replica. > - Connect it to existing topology and suck in all the data. > - Disconnect the new replica from rest of topology. > - Do upgrade experiments. > - Destroy the new/'experimental' replica. You end up destroying it, so I do not see the problem :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu Dec 11 16:44:09 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Dec 2014 17:44:09 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <5489BD60.8000100@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> <5489B810.60801@redhat.com> <5489BD60.8000100@redhat.com> Message-ID: <5489C9D9.3070302@redhat.com> On 11.12.2014 16:50, Martin Basti wrote: > Updated aptch attached: Nice work, ACK! -- Petr^2 Spacek From jcholast at redhat.com Fri Dec 12 09:20:28 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 12 Dec 2014 10:20:28 +0100 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <20141201111233.5a44b40e@willson.usersys.redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> Message-ID: <548AB35C.6010904@redhat.com> Hi, Dne 1.12.2014 v 17:12 Simo Sorce napsal(a): > On Mon, 01 Dec 2014 16:17:54 +0100 > Petr Spacek wrote: > >> On 14.11.2014 17:31, Petr Spacek wrote: >>> On 14.11.2014 02:22, Simo Sorce wrote: >>>> I think what I'd like to see is to be able to configure a DNS zone >>>> in LDAP and mark it external. >>>> The zone would held the TSIG keys necessary to perform DNS updates. >>>> >>>> When the regular ipa dnsrecord-add etc... commands are called, the >>>> framework detects that the zone is "external", fewttches the TSIG >>>> key (if the user has access to it) and spawn an nsupdate command >>>> that will perform the update against whatever DNS server is >>>> authoritative for the zone. >> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy >> instead of nsupdate command (to hide TSIG key behind FreeIPA)? > I do not like the XML-RPC->DNS approach as it requires a special > client, leaving out the majority of clients. I'm confused. Above you have suggested hiding the nsupdate machinery behind the framework and now you are saying that you do not like the XML-RPC->DNS approach. But the framework talks XML-RPC (and JSON-RPC) and using *anything else* would require a special client. Or did you mean some other XML-RPC->DNS? > > Also, I am thinking that we only _need_ to set infrastructure relevant > names (like IPA servers SRV records), but if someone decides not to use > IPA for the DNS we may decide that it is not our responsibility to > provide a full end-to-end client dns update solution. > > So I would concentrate on making it possible for IPA *Servers* to use a > private TSIG key to update infrastructure relevant names, and possibly > defer the clients side of the problem. > > We could use an internal bus on the server to allow the ipa framework > to use nsupdate w/o gaining direct access to the TSIG key, this way > admins can use ipa dnsrecod-add and friends w/o exposing the key. +1, we had a short discussion about external DNS with Petr yesterday and reached the same conclusion. Honza -- Jan Cholasta From mbasti at redhat.com Fri Dec 12 09:38:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Dec 2014 10:38:56 +0100 Subject: [Freeipa-devel] IPA ldap-updater improvements Message-ID: <548AB7B0.2010602@redhat.com> Hello, I would like to discuss following list of *ldap-updater characteristics*: 1. Updates sorting are based on length of DN, update with shorter DN is executed earlier 2. DNs of update entries are stored in dictionary 3. update files are parsed in batches 10-19, 20-29, ..., 80-89 * **Issues**:* 1. This approach solves parent-children dependency issues, but currently we have dependencies between different branches of tree, required by plugins, it happens several times for me that shorter DN depends on longer DN, and DS rejects update. 2. This disallow to specify order of upgrades per file, for example, update entries A and B have the same length of DN, but B depends on A. However python internally (may) change order in dict which causes The B update is executed first and update failed. Solution now is move B to the file in next update batch. The ticket https://fedorahosted.org/freeipa/ticket/4680 hits this problem. 3. This granularity seems to be not enough to me, it causes the more updates are mixed by applying 1. and 2. for more update entries. *Solutions:* 1. Don't sort DN, developer should be responsible for order of updates. 2. Use ordered dictionary, developer should be responsible for order of updates per file. 3. Parse files in batches per number, 10, 11, 12, ..., 89 *Summary:* IMO the ipa ldap-updater does to much magic with updates, would be better if the updater delegates those responsibilities to developers. With current state we would hit the issues above more frequently as the we increase the amount of updates in each release. As first I suggest to fix 3., which is quite easy and it will decrease effects of 1. and 2., and allows to use better granularity with upgrades. Martin^2 -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Dec 12 12:46:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Dec 2014 13:46:59 +0100 Subject: [Freeipa-devel] IPA ldap-updater improvements In-Reply-To: <548AB7B0.2010602@redhat.com> References: <548AB7B0.2010602@redhat.com> Message-ID: <548AE3C3.7080700@redhat.com> On 12/12/2014 10:38 AM, Martin Basti wrote: > Hello, > > I would like to discuss following list of *ldap-updater characteristics*: > 1. Updates sorting are based on length of DN, update with shorter DN is > executed earlier > 2. DNs of update entries are stored in dictionary > 3. update files are parsed in batches 10-19, 20-29, ..., 80-89 > * > **Issues**:* > 1. This approach solves parent-children dependency issues, but currently we > have dependencies between different branches of tree, required by plugins, it > happens several times for me that shorter DN depends on longer DN, and DS > rejects update. > > 2. This disallow to specify order of upgrades per file, for example, update > entries A and B have the same length of DN, but B depends on A. However python > internally (may) change order in dict which causes The B update is executed > first and update failed. Solution now is move B to the file in next update > batch. The ticket https://fedorahosted.org/freeipa/ticket/4680 hits this problem. > > > 3. This granularity seems to be not enough to me, it causes the more updates > are mixed by applying 1. and 2. for more update entries. > > *Solutions:* > 1. Don't sort DN, developer should be responsible for order of updates. > 2. Use ordered dictionary, developer should be responsible for order of updates > per file. > 3. Parse files in batches per number, 10, 11, 12, ..., 89 > > *Summary:* > IMO the ipa ldap-updater does to much magic with updates, would be better if > the updater delegates those responsibilities to developers. With current state > we would hit the issues above more frequently as the we increase the amount of > updates in each release. > > As first I suggest to fix 3., which is quite easy and it will decrease effects > of 1. and 2., and allows to use better granularity with upgrades. Makes sense to me, better determinism should help us avoid the problems we had with 4.1 upgrades. CCing Rob for reference. From mkosek at redhat.com Fri Dec 12 12:50:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Dec 2014 13:50:24 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <5489C9D9.3070302@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> <5489B810.60801@redhat.com> <5489BD60.8000100@redhat.com> <5489C9D9.3070302@redhat.com> Message-ID: <548AE490.7060003@redhat.com> On 12/11/2014 05:44 PM, Petr Spacek wrote: > On 11.12.2014 16:50, Martin Basti wrote: >> Updated aptch attached: > > Nice work, ACK! > Can we also add some tests? This is a lot of new code that could break stuff. From mbasti at redhat.com Fri Dec 12 12:52:38 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Dec 2014 13:52:38 +0100 Subject: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration In-Reply-To: <548AE490.7060003@redhat.com> References: <54733436.8030703@redhat.com> <54735BA0.3030209@redhat.com> <547C6F96.1060106@redhat.com> <547C9B05.5010904@redhat.com> <54872602.4050101@redhat.com> <548880E6.4010105@redhat.com> <5489B810.60801@redhat.com> <5489BD60.8000100@redhat.com> <5489C9D9.3070302@redhat.com> <548AE490.7060003@redhat.com> Message-ID: <548AE516.9020906@redhat.com> On 12/12/14 13:50, Martin Kosek wrote: > On 12/11/2014 05:44 PM, Petr Spacek wrote: >> On 11.12.2014 16:50, Martin Basti wrote: >>> Updated aptch attached: >> >> Nice work, ACK! >> > > Can we also add some tests? This is a lot of new code that could break > stuff. We can, in week maybe or after christmas, currently I do some work with tests and adding new tests required by QE, I will add forwardzone warnings tests when finish this. -- Martin Basti From pvoborni at redhat.com Fri Dec 12 13:19:11 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 12 Dec 2014 14:19:11 +0100 Subject: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply In-Reply-To: <5489AD7D.5080801@redhat.com> References: <5489549A.5080802@redhat.com> <54896CED.6030908@redhat.com> <5489AD7D.5080801@redhat.com> Message-ID: <548AEB4F.4030508@redhat.com> On 12/11/2014 03:43 PM, Tomas Babej wrote: > > On 12/11/2014 11:07 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 11.12.2014 v 09:23 Tomas Babej napsal(a): >>> Hi, >>> >>> When running a idview-apply command, the hosts that were already >>> assigned >>> the desired view were silently ignored. Make sure such hosts show up in >>> the list of failed hosts. >>> >>> https://fedorahosted.org/freeipa/ticket/4743 >> >> Shouldn't the error message strings be translatable? >> > > Sure, why not. Good point, I transformed the other error message string > as well. > > Updated patch attach. > >> Honza >> Got JSON serialization issues for both "ID View already applied" and "not found" errors. Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 402, in __call__ response = self.wsgi_execute(environ) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 387, in wsgi_execute return self.marshal(result, error, _id, version) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 467, in marshal return json.dumps(response, sort_keys=True, indent=4) File "/usr/lib64/python2.7/json/__init__.py", line 250, in dumps sort_keys=sort_keys, **kw).encode(obj) File "/usr/lib64/python2.7/json/encoder.py", line 209, in encode chunks = list(chunks) File "/usr/lib64/python2.7/json/encoder.py", line 434, in _iterencode for chunk in _iterencode_dict(o, _current_indent_level): File "/usr/lib64/python2.7/json/encoder.py", line 408, in _iterencode_dict for chunk in chunks: File "/usr/lib64/python2.7/json/encoder.py", line 408, in _iterencode_dict for chunk in chunks: File "/usr/lib64/python2.7/json/encoder.py", line 408, in _iterencode_dict for chunk in chunks: File "/usr/lib64/python2.7/json/encoder.py", line 408, in _iterencode_dict for chunk in chunks: File "/usr/lib64/python2.7/json/encoder.py", line 332, in _iterencode_list for chunk in chunks: File "/usr/lib64/python2.7/json/encoder.py", line 332, in _iterencode_list for chunk in chunks: File "/usr/lib64/python2.7/json/encoder.py", line 442, in _iterencode o = _default(o) File "/usr/lib64/python2.7/json/encoder.py", line 184, in default raise TypeError(repr(o) + " is not JSON serializable") TypeError: Gettext('ID View already applied', domain='ipa', localedir=None) is not JSON serializable -- Petr Vobornik From mbasti at redhat.com Fri Dec 12 13:26:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 12 Dec 2014 14:26:54 +0100 Subject: [Freeipa-devel] [PATCH 0179] Fix traceback if zonemgr error message contains unicode characters Message-ID: <548AED1E.2020308@redhat.com> https://fedorahosted.org/freeipa/ticket/4805 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0179-Fix-traceback-if-zonemgr-error-contains-unicode.patch Type: text/x-patch Size: 1353 bytes Desc: not available URL: From tbabej at redhat.com Fri Dec 12 15:15:14 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 12 Dec 2014 16:15:14 +0100 Subject: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply In-Reply-To: <548AEB4F.4030508@redhat.com> References: <5489549A.5080802@redhat.com> <54896CED.6030908@redhat.com> <5489AD7D.5080801@redhat.com> <548AEB4F.4030508@redhat.com> Message-ID: <548B0682.2040705@redhat.com> On 12/12/2014 02:19 PM, Petr Vobornik wrote: > On 12/11/2014 03:43 PM, Tomas Babej wrote: >> >> On 12/11/2014 11:07 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 11.12.2014 v 09:23 Tomas Babej napsal(a): >>>> Hi, >>>> >>>> When running a idview-apply command, the hosts that were already >>>> assigned >>>> the desired view were silently ignored. Make sure such hosts show >>>> up in >>>> the list of failed hosts. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4743 >>> >>> Shouldn't the error message strings be translatable? >>> >> >> Sure, why not. Good point, I transformed the other error message string >> as well. >> >> Updated patch attach. >> >>> Honza >>> > > Got JSON serialization issues for both "ID View already applied" and > "not found" errors. > > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > 402, in __call__ > response = self.wsgi_execute(environ) > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > 387, in wsgi_execute > return self.marshal(result, error, _id, version) > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > 467, in marshal > return json.dumps(response, sort_keys=True, indent=4) > File "/usr/lib64/python2.7/json/__init__.py", line 250, in dumps > sort_keys=sort_keys, **kw).encode(obj) > File "/usr/lib64/python2.7/json/encoder.py", line 209, in encode > chunks = list(chunks) > File "/usr/lib64/python2.7/json/encoder.py", line 434, in _iterencode > for chunk in _iterencode_dict(o, _current_indent_level): > File "/usr/lib64/python2.7/json/encoder.py", line 408, in > _iterencode_dict > for chunk in chunks: > File "/usr/lib64/python2.7/json/encoder.py", line 408, in > _iterencode_dict > for chunk in chunks: > File "/usr/lib64/python2.7/json/encoder.py", line 408, in > _iterencode_dict > for chunk in chunks: > File "/usr/lib64/python2.7/json/encoder.py", line 408, in > _iterencode_dict > for chunk in chunks: > File "/usr/lib64/python2.7/json/encoder.py", line 332, in > _iterencode_list > for chunk in chunks: > File "/usr/lib64/python2.7/json/encoder.py", line 332, in > _iterencode_list > for chunk in chunks: > File "/usr/lib64/python2.7/json/encoder.py", line 442, in _iterencode > o = _default(o) > File "/usr/lib64/python2.7/json/encoder.py", line 184, in default > raise TypeError(repr(o) + " is not JSON serializable") > TypeError: Gettext('ID View already applied', domain='ipa', > localedir=None) is not JSON serializable Thanks, fixed. Updated patch attached. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0291-3-idviews-Complain-if-host-is-already-assigned-the-ID-.patch Type: text/x-patch Size: 2065 bytes Desc: not available URL: From pvoborni at redhat.com Fri Dec 12 15:44:34 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 12 Dec 2014 16:44:34 +0100 Subject: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply In-Reply-To: <548B0682.2040705@redhat.com> References: <5489549A.5080802@redhat.com> <54896CED.6030908@redhat.com> <5489AD7D.5080801@redhat.com> <548AEB4F.4030508@redhat.com> <548B0682.2040705@redhat.com> Message-ID: <548B0D62.8030205@redhat.com> On 12/12/2014 04:15 PM, Tomas Babej wrote: > > Thanks, fixed. Updated patch attached. > ACK Pushed to: master: fdd7b79eeafae3891a9aa5bf414f9c65f947e88d ipa-4-1: 12f6969ec9daafe7926a49a6775501d1034694f4 -- Petr Vobornik From tbabej at redhat.com Fri Dec 12 15:49:17 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 12 Dec 2014 16:49:17 +0100 Subject: [Freeipa-devel] [PATCH 0292] idviews: Ignore host or hostgroup options set to None Message-ID: <548B0E7D.8090201@redhat.com> Hi, Since passing --hosts= or --hostsgroups= to idview-apply or unapply commands does not make sense, ignore it. https://fedorahosted.org/freeipa/ticket/4806 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0292-idviews-Ignore-host-or-hostgroup-options-set-to-None.patch Type: text/x-patch Size: 1153 bytes Desc: not available URL: From simo at redhat.com Fri Dec 12 15:49:46 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 12 Dec 2014 10:49:46 -0500 Subject: [Freeipa-devel] FreeIPA integration with external DNS services In-Reply-To: <548AB35C.6010904@redhat.com> References: <54622B6F.3080101@redhat.com> <20141113202255.373aa1ca@willson.usersys.redhat.com> <54662E77.9020608@redhat.com> <547C86A2.5010508@redhat.com> <20141201111233.5a44b40e@willson.usersys.redhat.com> <548AB35C.6010904@redhat.com> Message-ID: <20141212104946.3073297a@willson.usersys.redhat.com> On Fri, 12 Dec 2014 10:20:28 +0100 Jan Cholasta wrote: > Hi, > > Dne 1.12.2014 v 17:12 Simo Sorce napsal(a): > > On Mon, 01 Dec 2014 16:17:54 +0100 > > Petr Spacek wrote: > > > >> On 14.11.2014 17:31, Petr Spacek wrote: > >>> On 14.11.2014 02:22, Simo Sorce wrote: > >>>> I think what I'd like to see is to be able to configure a DNS > >>>> zone in LDAP and mark it external. > >>>> The zone would held the TSIG keys necessary to perform DNS > >>>> updates. > >>>> > >>>> When the regular ipa dnsrecord-add etc... commands are called, > >>>> the framework detects that the zone is "external", fewttches the > >>>> TSIG key (if the user has access to it) and spawn an nsupdate > >>>> command that will perform the update against whatever DNS server > >>>> is authoritative for the zone. > > >> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy > >> instead of nsupdate command (to hide TSIG key behind FreeIPA)? > > > I do not like the XML-RPC->DNS approach as it requires a special > > client, leaving out the majority of clients. > > I'm confused. Above you have suggested hiding the nsupdate machinery > behind the framework and now you are saying that you do not like the > XML-RPC->DNS approach. But the framework talks XML-RPC (and JSON-RPC) > and using *anything else* would require a special client. Or did you > mean some other XML-RPC->DNS? I do not like XML-RPC -> DNS for when clients need to update the DNS. For the FreeIPA server itself or the manager working through the framework it is just fine of course, but then it is an internal detail. > > Also, I am thinking that we only _need_ to set infrastructure > > relevant names (like IPA servers SRV records), but if someone > > decides not to use IPA for the DNS we may decide that it is not our > > responsibility to provide a full end-to-end client dns update > > solution. > > > > So I would concentrate on making it possible for IPA *Servers* to > > use a private TSIG key to update infrastructure relevant names, and > > possibly defer the clients side of the problem. > > > > We could use an internal bus on the server to allow the ipa > > framework to use nsupdate w/o gaining direct access to the TSIG > > key, this way admins can use ipa dnsrecod-add and friends w/o > > exposing the key. > > +1, we had a short discussion about external DNS with Petr yesterday > and reached the same conclusion. Nice :) Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Dec 12 16:02:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 12 Dec 2014 17:02:30 +0100 Subject: [Freeipa-devel] [PATCH 0292] idviews: Ignore host or hostgroup options set to None In-Reply-To: <548B0E7D.8090201@redhat.com> References: <548B0E7D.8090201@redhat.com> Message-ID: <548B1196.6060101@redhat.com> On 12/12/2014 04:49 PM, Tomas Babej wrote: > Hi, > > Since passing --hosts= or --hostsgroups= to idview-apply or unapply > commands does not make sense, ignore it. > > https://fedorahosted.org/freeipa/ticket/4806 > ACK -- Petr Vobornik From tbabej at redhat.com Fri Dec 12 16:04:58 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 12 Dec 2014 17:04:58 +0100 Subject: [Freeipa-devel] [PATCH 0292] idviews: Ignore host or hostgroup options set to None In-Reply-To: <548B1196.6060101@redhat.com> References: <548B0E7D.8090201@redhat.com> <548B1196.6060101@redhat.com> Message-ID: <548B122A.80800@redhat.com> On 12/12/2014 05:02 PM, Petr Vobornik wrote: > On 12/12/2014 04:49 PM, Tomas Babej wrote: >> Hi, >> >> Since passing --hosts= or --hostsgroups= to idview-apply or unapply >> commands does not make sense, ignore it. >> >> https://fedorahosted.org/freeipa/ticket/4806 >> > > ACK Pushed to: master: c5c9d49706d27455c7f7bdb811108d45deb82bf4 ipa-4-1: 86a7dfccd522b16dc3deadb9837a409b65aa1aeb -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From ayoung at redhat.com Fri Dec 12 20:01:14 2014 From: ayoung at redhat.com (Adam Young) Date: Fri, 12 Dec 2014 15:01:14 -0500 Subject: [Freeipa-devel] Features for F22 In-Reply-To: <548AE089.8080005@redhat.com> References: <548AE089.8080005@redhat.com> Message-ID: <548B498A.2080803@redhat.com> On 12/12/2014 07:33 AM, Joe Brockmeier wrote: > On 12/12/2014 03:15 AM, Kushal Das wrote: >> It is time again to start discussion on the new features we want to >> work for Fedora 22 release. The release schedule can be found at [1]. >> >> Please reply to this thread with the ideas you think will fit to >> Fedora 22 timeline. > Some things to think about in the F22 timeline: > > - Rocket packages (already in progress, I believe) > - Flannel > - Additional Docker packages launched at Dockercon? > - Overlay packages for rpm-ostree > - Package testCloud: https://github.com/Rorosha/testCloud > - Reduce Atomic, cloud base, and Docker image sizes > - Bare metal installer for Atomic Crossposting: Cloud Init support for auto registering a VM with FreeIPA. > > > Those are the ideas off the top of my head we've talked about and should > have for F22. I'm sure there's more. > > Best, > > jzb > > > _______________________________________________ > cloud mailing list > cloud at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon Dec 15 10:32:06 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 15 Dec 2014 11:32:06 +0100 Subject: [Freeipa-devel] [PATCH 0293] ipatests: Invoke class install methods properly with respect Message-ID: <548EB8A6.5010102@redhat.com> Hi, Multihost object was is not passed to the install method in the super construction. This fixes setup errors in AD Trust, Forced client reenrollment, CALess and Sudo tests. https://fedorahosted.org/freeipa/ticket/4809 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0293-ipatests-Invoke-class-install-methods-properly-with-.patch Type: text/x-patch Size: 3371 bytes Desc: not available URL: From mbasti at redhat.com Mon Dec 15 18:18:52 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 15 Dec 2014 19:18:52 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases Message-ID: <548F260C.1080403@redhat.com> https://fedorahosted.org/freeipa/ticket/4750 Patches need rebase and minor pytest modification to apply on master, I will do that after review. Patches for ipa-4-1 attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0175-DNS-tests-separate-current-forward-zone-tests.patch Type: text/x-patch Size: 29881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0176-New-test-cases-for-Forward_zones.patch Type: text/x-patch Size: 36960 bytes Desc: not available URL: From mbasti at redhat.com Mon Dec 15 19:15:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 15 Dec 2014 20:15:21 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <548F260C.1080403@redhat.com> References: <548F260C.1080403@redhat.com> Message-ID: <548F3349.4000307@redhat.com> On 15/12/14 19:18, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4750 > > Patches need rebase and minor pytest modification to apply on master, > I will do that after review. > > Patches for ipa-4-1 attached. > > I forgot to fix copy paste error. Updated patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0175.2-DNS-tests-separate-current-forward-zone-tests.patch Type: text/x-patch Size: 29881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0176.2-New-test-cases-for-Forward_zones.patch Type: text/x-patch Size: 37118 bytes Desc: not available URL: From simo at redhat.com Mon Dec 15 22:01:50 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 15 Dec 2014 17:01:50 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages Message-ID: <20141215170150.00437756@willson.usersys.redhat.com> Hello fellow developers, I added this new design: http://www.freeipa.org/page/V4/Domain_Levels It is a prerequisite for both the Replica Promotion design: http://www.freeipa.org/page/V4/Replica_Promotion and the Topology plugins design: http://www.freeipa.org/page/V4/Manage_replication_topology (Ludwig will change this to include the changes we have discussed in a previous phone call, and which involve mostly Domain Level/Domain Upgrades/migrations issues) As usual feel free to add as needed or comments and ask questions. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Tue Dec 16 09:55:52 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 16 Dec 2014 10:55:52 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141215170150.00437756@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> Message-ID: <549001A8.8010205@redhat.com> On 12/15/2014 11:01 PM, Simo Sorce wrote: > Hello fellow developers, I added this new design: > http://www.freeipa.org/page/V4/Domain_Levels > > It is a prerequisite for both the Replica Promotion design: > http://www.freeipa.org/page/V4/Replica_Promotion > and the Topology plugins design: > http://www.freeipa.org/page/V4/Manage_replication_topology > (Ludwig will change this to include the changes we have discussed in a > previous phone call, and which involve mostly Domain Level/Domain > Upgrades/migrations issues) > > As usual feel free to add as needed or comments and ask questions. > > Simo. > Hello, A new/old replica can join a topology with a given Domain level. This replica may miss the requirements to be running at the current Domain level. Does the new comer replica need to follow a procedure before joining ? Is there a 'gate keeper' replica that would grant the authorization to join ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Tue Dec 16 10:33:41 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 16 Dec 2014 11:33:41 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141215170150.00437756@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> Message-ID: <54900A85.9090806@redhat.com> Hi Simo, one thing is not quite clear to me: do you want a domain level per feature or a global domain level or both ? For a single feature (eg topology management) it could be required that it is available on all servers, so it will be active only if it's domain level is set. But there could be another feature, independent of this one, it also could require to be installed on all servers, and wait until it's domain level is set. If we would only one domainlevel this would mean that all features need to be at a specific level until any of tehm could be enabled Ludwig On 12/15/2014 11:01 PM, Simo Sorce wrote: > Hello fellow developers, I added this new design: > http://www.freeipa.org/page/V4/Domain_Levels > > It is a prerequisite for both the Replica Promotion design: > http://www.freeipa.org/page/V4/Replica_Promotion > and the Topology plugins design: > http://www.freeipa.org/page/V4/Manage_replication_topology > (Ludwig will change this to include the changes we have discussed in a > previous phone call, and which involve mostly Domain Level/Domain > Upgrades/migrations issues) > > As usual feel free to add as needed or comments and ask questions. > > Simo. > From tbabej at redhat.com Tue Dec 16 10:49:41 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Dec 2014 11:49:41 +0100 Subject: [Freeipa-devel] [PATCH 0293] ipatests: Invoke class install methods properly with respect In-Reply-To: <548EB8A6.5010102@redhat.com> References: <548EB8A6.5010102@redhat.com> Message-ID: <54900E45.70601@redhat.com> On 12/15/2014 11:32 AM, Tomas Babej wrote: > Hi, > > Multihost object was is not passed to the install method in the super > construction. > This fixes setup errors in AD Trust, Forced client reenrollment, CALess > and Sudo > tests. > > https://fedorahosted.org/freeipa/ticket/4809 > Attaching updated patch, along with few related fixes. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0295-ipatests-Refactor-and-fix-docstrings-in-integration-.patch Type: text/x-patch Size: 2621 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0294-ipatests-Set-the-correct-number-of-required-clients-.patch Type: text/x-patch Size: 1039 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0293-2-ipatests-Invoke-class-install-methods-properly-with-.patch Type: text/x-patch Size: 4999 bytes Desc: not available URL: From tbabej at redhat.com Tue Dec 16 10:57:25 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Dec 2014 11:57:25 +0100 Subject: [Freeipa-devel] [PATCH 0293] ipatests: Invoke class install methods properly with respect In-Reply-To: <54900E45.70601@redhat.com> References: <548EB8A6.5010102@redhat.com> <54900E45.70601@redhat.com> Message-ID: <54901015.5030707@redhat.com> On 12/16/2014 11:49 AM, Tomas Babej wrote: > On 12/15/2014 11:32 AM, Tomas Babej wrote: >> Hi, >> >> Multihost object was is not passed to the install method in the super >> construction. >> This fixes setup errors in AD Trust, Forced client reenrollment, CALess >> and Sudo >> tests. >> >> https://fedorahosted.org/freeipa/ticket/4809 >> > Attaching updated patch, along with few related fixes. > Upon further inspection, it seems I managed to miss two cases in the first patch. Fixed. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0293-3-ipatests-Invoke-class-install-methods-properly-with-.patch Type: text/x-patch Size: 5675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0295-ipatests-Refactor-and-fix-docstrings-in-integration-.patch Type: text/x-patch Size: 2621 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0294-ipatests-Set-the-correct-number-of-required-clients-.patch Type: text/x-patch Size: 1039 bytes Desc: not available URL: From pviktori at redhat.com Tue Dec 16 11:21:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 16 Dec 2014 12:21:50 +0100 Subject: [Freeipa-devel] [PATCH 0293] ipatests: Invoke class install methods properly with respect In-Reply-To: <54901015.5030707@redhat.com> References: <548EB8A6.5010102@redhat.com> <54900E45.70601@redhat.com> <54901015.5030707@redhat.com> Message-ID: <549015CE.90001@redhat.com> On 12/16/2014 11:57 AM, Tomas Babej wrote: > > On 12/16/2014 11:49 AM, Tomas Babej wrote: >> On 12/15/2014 11:32 AM, Tomas Babej wrote: >>> Hi, >>> >>> Multihost object was is not passed to the install method in the super >>> construction. >>> This fixes setup errors in AD Trust, Forced client reenrollment, CALess >>> and Sudo >>> tests. >>> >>> https://fedorahosted.org/freeipa/ticket/4809 >>> >> Attaching updated patch, along with few related fixes. >> > > Upon further inspection, it seems I managed to miss two cases in the > first patch. Fixed. Thank you! ACK, pushed to master: b7e58ce74623c5bb52ce7c74c4242dfda3786a3a -- Petr? From mbasti at redhat.com Tue Dec 16 11:30:29 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Dec 2014 12:30:29 +0100 Subject: [Freeipa-devel] [PATCH 0177] Fix adding (warning) messages on client side In-Reply-To: <54897C72.90401@redhat.com> References: <5487102F.10806@redhat.com> <54896FBF.7010204@redhat.com> <54897C72.90401@redhat.com> Message-ID: <549017D5.30909@redhat.com> On 11/12/14 12:13, Martin Basti wrote: > On 11/12/14 11:19, Jan Cholasta wrote: >> Hi, >> >> Dne 9.12.2014 v 16:07 Martin Basti napsal(a): >>> Ticket: https://fedorahosted.org/freeipa/ticket/4793 >>> >>> I'm able to reproduce it only in one nose test. >> >> Which test? > If you apply my patch 170 and add a random forwardzone, then DNS root > zone tests failed. >> >>> >>> Patch attached. >> >> What about: >> >> result['messages'] = result.get('messages', ()) + >> (message.to_dict(),) >> >> (My point is, don't support both lists and tuples, pick just one.) >> >> Honza >> > This is question for framework guru (you?), I tried to preserve format > unchanged. > Shouldn't be all values in lists in server part? > > Martin^2 > As was requested, I convert tuple to list instead handling both types. Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0177.2-Fix-add-message-on-client-side.patch Type: text/x-patch Size: 2907 bytes Desc: not available URL: From mkosek at redhat.com Tue Dec 16 12:00:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Dec 2014 13:00:26 +0100 Subject: [Freeipa-devel] [PATCH 0177] Fix adding (warning) messages on client side In-Reply-To: <549017D5.30909@redhat.com> References: <5487102F.10806@redhat.com> <54896FBF.7010204@redhat.com> <54897C72.90401@redhat.com> <549017D5.30909@redhat.com> Message-ID: <54901EDA.3060601@redhat.com> On 12/16/2014 12:30 PM, Martin Basti wrote: > On 11/12/14 12:13, Martin Basti wrote: >> On 11/12/14 11:19, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 9.12.2014 v 16:07 Martin Basti napsal(a): >>>> Ticket: https://fedorahosted.org/freeipa/ticket/4793 >>>> >>>> I'm able to reproduce it only in one nose test. >>> >>> Which test? >> If you apply my patch 170 and add a random forwardzone, then DNS root zone >> tests failed. >>> >>>> >>>> Patch attached. >>> >>> What about: >>> >>> result['messages'] = result.get('messages', ()) + (message.to_dict(),) >>> >>> (My point is, don't support both lists and tuples, pick just one.) >>> >>> Honza >>> >> This is question for framework guru (you?), I tried to preserve format >> unchanged. >> Shouldn't be all values in lists in server part? >> >> Martin^2 >> > As was requested, I convert tuple to list instead handling both types. > > Updated patch attached. I assume you do not want to track the .idea/ files in FreeIPA git :-) From mbasti at redhat.com Tue Dec 16 12:04:07 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Dec 2014 13:04:07 +0100 Subject: [Freeipa-devel] [PATCH 0177] Fix adding (warning) messages on client side In-Reply-To: <54901EDA.3060601@redhat.com> References: <5487102F.10806@redhat.com> <54896FBF.7010204@redhat.com> <54897C72.90401@redhat.com> <549017D5.30909@redhat.com> <54901EDA.3060601@redhat.com> Message-ID: <54901FB7.40900@redhat.com> On 16/12/14 13:00, Martin Kosek wrote: > On 12/16/2014 12:30 PM, Martin Basti wrote: >> On 11/12/14 12:13, Martin Basti wrote: >>> On 11/12/14 11:19, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 9.12.2014 v 16:07 Martin Basti napsal(a): >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4793 >>>>> >>>>> I'm able to reproduce it only in one nose test. >>>> Which test? >>> If you apply my patch 170 and add a random forwardzone, then DNS root zone >>> tests failed. >>>>> Patch attached. >>>> What about: >>>> >>>> result['messages'] = result.get('messages', ()) + (message.to_dict(),) >>>> >>>> (My point is, don't support both lists and tuples, pick just one.) >>>> >>>> Honza >>>> >>> This is question for framework guru (you?), I tried to preserve format >>> unchanged. >>> Shouldn't be all values in lists in server part? >>> >>> Martin^2 >>> >> As was requested, I convert tuple to list instead handling both types. >> >> Updated patch attached. > I assume you do not want to track the .idea/ files in FreeIPA git :-) > Oh, thanks. My IDE was too smart again and add those files there itself. updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0177.3-Fix-warning-message-on-client-side.patch Type: text/x-patch Size: 1142 bytes Desc: not available URL: From simo at redhat.com Tue Dec 16 14:14:32 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Dec 2014 09:14:32 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <549001A8.8010205@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <549001A8.8010205@redhat.com> Message-ID: <20141216091432.31222a32@willson.usersys.redhat.com> On Tue, 16 Dec 2014 10:55:52 +0100 thierry bordaz wrote: > On 12/15/2014 11:01 PM, Simo Sorce wrote: > > Hello fellow developers, I added this new design: > > http://www.freeipa.org/page/V4/Domain_Levels > > > > It is a prerequisite for both the Replica Promotion design: > > http://www.freeipa.org/page/V4/Replica_Promotion > > and the Topology plugins design: > > http://www.freeipa.org/page/V4/Manage_replication_topology > > (Ludwig will change this to include the changes we have discussed > > in a previous phone call, and which involve mostly Domain > > Level/Domain Upgrades/migrations issues) > > > > As usual feel free to add as needed or comments and ask questions. > > > > Simo. > > > Hello, > > A new/old replica can join a topology with a given Domain level. > This replica may miss the requirements to be running at the > current Domain level. A replica that lacks the requirements will not be able to join. > Does the new comer replica need to follow a procedure before > joining ? Newer replicas will use the new installation method, one of the things that will be checked is if the Domain Level is supported by the replica. If the Domain Level is higher than what is supported then joining the replica will fail. > Is there a 'gate keeper' replica that would grant the > authorization to join ? Not necessary. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Dec 16 14:22:31 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Dec 2014 09:22:31 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <54900A85.9090806@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> Message-ID: <20141216092231.4e0003ce@willson.usersys.redhat.com> On Tue, 16 Dec 2014 11:33:41 +0100 Ludwig Krispenz wrote: > Hi Simo, > > one thing is not quite clear to me: do you want a domain level per > feature or a global domain level or both ? The Domain Level is global. I described a "Feature Version" that is published by feature. The Feature Versions just state what is available they do not determine what is the current overall Domain Level. > For a single feature (eg topology management) it could be required > that it is available on all servers, so it will be active only if > it's domain level is set. But there could be another feature, > independent of this one, it also could require to be installed on all > servers, and wait until it's domain level is set. > If we would only one domainlevel this would mean that all features > need to be at a specific level until any of tehm could be enabled We need to keep it simple. We can't have multiple domain levels or it will quickly become a mess (test matrix will also explode). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Tue Dec 16 14:57:34 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 16 Dec 2014 15:57:34 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141216092231.4e0003ce@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> Message-ID: <5490485E.1080002@redhat.com> On 12/16/2014 03:22 PM, Simo Sorce wrote: > On Tue, 16 Dec 2014 11:33:41 +0100 > Ludwig Krispenz wrote: > >> Hi Simo, >> >> one thing is not quite clear to me: do you want a domain level per >> feature or a global domain level or both ? > The Domain Level is global. > I described a "Feature Version" that is published by feature. > The Feature Versions just state what is available they do not determine > what is the current overall Domain Level. Ok, just to confirm my understanding. - we have one domain level. - each (new) plugin or compoment has to define its minimal domain level and execute only features covered by this level - in addition, these plugins have to expose their (plugin) version on each server, allowing checks for setting the domain level > >> For a single feature (eg topology management) it could be required >> that it is available on all servers, so it will be active only if >> it's domain level is set. But there could be another feature, >> independent of this one, it also could require to be installed on all >> servers, and wait until it's domain level is set. >> If we would only one domainlevel this would mean that all features >> need to be at a specific level until any of tehm could be enabled > We need to keep it simple. We can't have multiple domain levels or it > will quickly become a mess (test matrix will also explode). > > HTH, > Simo. > From pspacek at redhat.com Tue Dec 16 15:32:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Dec 2014 16:32:33 +0100 Subject: [Freeipa-devel] [PATCH 0316] Fix crash triggered by zone objects with unexpected DN Message-ID: <54905091.5010201@redhat.com> Hello, Fix crash triggered by zone objects with unexpected DN. https://fedorahosted.org/bind-dyndb-ldap/ticket/148 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0316-Fix-crash-triggered-by-zone-objects-with-unexpected-.patch Type: text/x-patch Size: 4539 bytes Desc: not available URL: From simo at redhat.com Tue Dec 16 15:40:20 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Dec 2014 10:40:20 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <5490485E.1080002@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> Message-ID: <20141216104020.500670e2@willson.usersys.redhat.com> On Tue, 16 Dec 2014 15:57:34 +0100 Ludwig Krispenz wrote: > > On 12/16/2014 03:22 PM, Simo Sorce wrote: > > On Tue, 16 Dec 2014 11:33:41 +0100 > > Ludwig Krispenz wrote: > > > >> Hi Simo, > >> > >> one thing is not quite clear to me: do you want a domain level per > >> feature or a global domain level or both ? > > The Domain Level is global. > > I described a "Feature Version" that is published by feature. > > The Feature Versions just state what is available they do not > > determine what is the current overall Domain Level. > Ok, just to confirm my understanding. > > - we have one domain level. Yes. > - each (new) plugin or compoment has to define its minimal domain > level and execute only features covered by this level Each plugin may have different behavior based on the domain level it is enabled, however the highest level is open-ended. IE a plugin must not stop working if it see a higher level than was known when it was built. SO a plugin may have an if/else like this: if (level < MIN_DOM_LEVEL) { return; } else if (level < XYZ_DOM_LEVEL) { /* do something */ } else { /* do something else */ } The last branch is always there unless we are going to stop using a plugin and intentionally want it to stop working once the domain level is raised past the XYZ_DOM_LEVEL (whatever that will be). > - in addition, these plugins have to expose their (plugin) version > on each server, allowing checks for setting the domain level Yes, we can refine this part though, for example each plugin could publish the minimum domain level is supports instead of a version number if that is useful or easier to manage. But this is not sufficient to do checks, we still need to know, in some cases, also what is the maximum level known for some plugins (but not for others), so we'll still need a detailed list of things to check. If this is too complex however, maybe we can simply publish a "supported domain level" number per server, and deal internally within a server on how to publish it. Simo. > > > >> For a single feature (eg topology management) it could be required > >> that it is available on all servers, so it will be active only if > >> it's domain level is set. But there could be another feature, > >> independent of this one, it also could require to be installed on > >> all servers, and wait until it's domain level is set. > >> If we would only one domainlevel this would mean that all features > >> need to be at a specific level until any of tehm could be enabled > > We need to keep it simple. We can't have multiple domain levels or > > it will quickly become a mess (test matrix will also explode). > > > > HTH, > > Simo. > > > -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Tue Dec 16 16:14:13 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 16 Dec 2014 17:14:13 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <548F3349.4000307@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> Message-ID: <54905A55.5060209@redhat.com> On 15/12/14 20:15, Martin Basti wrote: > On 15/12/14 19:18, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4750 >> >> Patches need rebase and minor pytest modification to apply on master, >> I will do that after review. >> >> Patches for ipa-4-1 attached. >> >> > I forgot to fix copy paste error. > > Updated patches attached > Removed unneeded nsrecord validation in 2 tests updated patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0175.3-DNS-tests-separate-current-forward-zone-tests.patch Type: text/x-patch Size: 32152 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0176.3-New-test-cases-for-Forward_zones.patch Type: text/x-patch Size: 37118 bytes Desc: not available URL: From simo at redhat.com Tue Dec 16 16:44:50 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Dec 2014 11:44:50 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141216104020.500670e2@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> Message-ID: <20141216114451.657a311f@willson.usersys.redhat.com> On Tue, 16 Dec 2014 10:40:20 -0500 Simo Sorce wrote: > On Tue, 16 Dec 2014 15:57:34 +0100 > Ludwig Krispenz wrote: > > > > > On 12/16/2014 03:22 PM, Simo Sorce wrote: > > > On Tue, 16 Dec 2014 11:33:41 +0100 > > > Ludwig Krispenz wrote: > > > > > >> Hi Simo, > > >> > > >> one thing is not quite clear to me: do you want a domain level > > >> per feature or a global domain level or both ? > > > The Domain Level is global. > > > I described a "Feature Version" that is published by feature. > > > The Feature Versions just state what is available they do not > > > determine what is the current overall Domain Level. > > Ok, just to confirm my understanding. > > > > - we have one domain level. > > Yes. > > > - each (new) plugin or compoment has to define its minimal domain > > level and execute only features covered by this level > > Each plugin may have different behavior based on the domain level it > is enabled, however the highest level is open-ended. IE a plugin must > not stop working if it see a higher level than was known when it was > built. > > SO a plugin may have an if/else like this: > > if (level < MIN_DOM_LEVEL) { > return; > } else if (level < XYZ_DOM_LEVEL) { > /* do something */ > } else { > /* do something else */ > } > > The last branch is always there unless we are going to stop using a > plugin and intentionally want it to stop working once the domain level > is raised past the XYZ_DOM_LEVEL (whatever that will be). > > > - in addition, these plugins have to expose their (plugin) version > > on each server, allowing checks for setting the domain level > > Yes, > we can refine this part though, for example each plugin could publish > the minimum domain level is supports instead of a version number if > that is useful or easier to manage. But this is not sufficient to do > checks, we still need to know, in some cases, also what is the > maximum level known for some plugins (but not for others), so we'll > still need a detailed list of things to check. > > If this is too complex however, maybe we can simply publish a > "supported domain level" number per server, and deal internally within > a server on how to publish it. A "supported domain levels" range really, so we can say IPA v8.0 support level 2-3-4 but not 0 or 1 or 5 (which is supported only by v9.0 Actually, I think I will go and change the proposal this way, it will make it much easier to deal with for checks. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Tue Dec 16 18:02:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 16 Dec 2014 19:02:31 +0100 Subject: [Freeipa-devel] [PATCHES] 0682-0683 Use external pytest plugins: beakerlib and sourceorder Message-ID: <549073B7.5010902@redhat.com> Hello, I've split more pytest plugins from FreeIPA, so they can be used to test other projects. Releasing these plugins properly to Fedora is getting delayed, but they are on fedorahosted: https://fedorahosted.org/python-pytest-beakerlib/ https://fedorahosted.org/python-pytest-sourceorder/ and in my COPR: https://copr.fedoraproject.org/coprs/pviktori/pytest-plugins/ and also in the freeipa-master COPR: https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/builds/ Note that the BeakerLib plugin does not need to be installed to run tests. There's some integration code left in IPA to forward logging and to keep the --with-beakerlib option in ipa-test-task, but that's only activated if the plugin is available. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0682-ipatests-Use-pytest-beakerlib.patch Type: text/x-patch Size: 10572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0683-ipatests-Use-pytest-sourceorder.patch Type: text/x-patch Size: 6372 bytes Desc: not available URL: From mkosek at redhat.com Wed Dec 17 11:59:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Dec 2014 12:59:56 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141215170150.00437756@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> Message-ID: <5491703C.9090007@redhat.com> On 12/15/2014 11:01 PM, Simo Sorce wrote: > > Hello fellow developers, I added this new design: > http://www.freeipa.org/page/V4/Domain_Levels > > It is a prerequisite for both the Replica Promotion design: > http://www.freeipa.org/page/V4/Replica_Promotion > and the Topology plugins design: > http://www.freeipa.org/page/V4/Manage_replication_topology > (Ludwig will change this to include the changes we have discussed in a > previous phone call, and which involve mostly Domain Level/Domain > Upgrades/migrations issues) > > As usual feel free to add as needed or comments and ask questions. > > Simo. > Thanks! For starters, please follow http://www.freeipa.org/page/Feature_template next time :-) Don't worry, I updated current proposal to follow it. On top of what was already said, I have couple comments: 1) Relation between domain levels and FreeIPA versions It is now proposed as "numbers", how do we define the relation? Did you want to create new domain level on needed basis? So we would have mapping like Domain level 0 --> FreeIPA 4.1 or older Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin user life cycle Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts ? Would it be more transparent to simply use versions as AD does [1] and always define which features require it? I.e.: Domain level "4.2" Domain level "4.3" --> thin API client Domain level "4.4" --> no changes Domain level "5.0" --> IPA-IPA trusts 2) Backporting features Long standing problem with API version was if for example RHEL/CentOS 6.6 does not rebase, but only backports selected patches/features from higher versions. Should it bump the API/supported Domain Level? Or should it only bump Domain Level if and only if it backports *all* features for the respective domain level? 3) Storing server and global domain level in LDAP I added [2]. [1] http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels From lkrispen at redhat.com Wed Dec 17 12:56:24 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 17 Dec 2014 13:56:24 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <5491703C.9090007@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <5491703C.9090007@redhat.com> Message-ID: <54917D78.4050205@redhat.com> On 12/17/2014 12:59 PM, Martin Kosek wrote: > On 12/15/2014 11:01 PM, Simo Sorce wrote: >> Hello fellow developers, I added this new design: >> http://www.freeipa.org/page/V4/Domain_Levels >> >> It is a prerequisite for both the Replica Promotion design: >> http://www.freeipa.org/page/V4/Replica_Promotion >> and the Topology plugins design: >> http://www.freeipa.org/page/V4/Manage_replication_topology >> (Ludwig will change this to include the changes we have discussed in a >> previous phone call, and which involve mostly Domain Level/Domain >> Upgrades/migrations issues) >> >> As usual feel free to add as needed or comments and ask questions. >> >> Simo. >> > Thanks! For starters, please follow > > http://www.freeipa.org/page/Feature_template > > next time :-) Don't worry, I updated current proposal to follow it. > > On top of what was already said, I have couple comments: > > > 1) Relation between domain levels and FreeIPA versions > > It is now proposed as "numbers", how do we define the relation? Did you want to > create new domain level on needed basis? So we would have mapping like > > Domain level 0 --> FreeIPA 4.1 or older > Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin user life > cycle > Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client > Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts > > ? Would it be more transparent to simply use versions as AD does [1] and always > define which features require it? I.e.: > > Domain level "4.2" > Domain level "4.3" --> thin API client > Domain level "4.4" --> no changes > Domain level "5.0" --> IPA-IPA trusts > > > 2) Backporting features > Long standing problem with API version was if for example RHEL/CentOS 6.6 does > not rebase, but only backports selected patches/features from higher versions. > Should it bump the API/supported Domain Level? > > Or should it only bump Domain Level if and only if it backports *all* features > for the respective domain level? which function would detect if "all" features are backported, and which function would bump the server level ? maybe Simo's original proposal could be useful: each feature registers its feature level in the server entry, eg "topology/1.0", so all baclported features would be visible > > 3) Storing server and global domain level in LDAP > I added [2]. > > > [1] > http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx > [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mbasti at redhat.com Wed Dec 17 14:15:39 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 17 Dec 2014 15:15:39 +0100 Subject: [Freeipa-devel] [PATCHES 0175-0176] New forward zone test cases In-Reply-To: <54905A55.5060209@redhat.com> References: <548F260C.1080403@redhat.com> <548F3349.4000307@redhat.com> <54905A55.5060209@redhat.com> Message-ID: <5491900B.8060209@redhat.com> On 16/12/14 17:14, Martin Basti wrote: > On 15/12/14 20:15, Martin Basti wrote: >> On 15/12/14 19:18, Martin Basti wrote: >>> https://fedorahosted.org/freeipa/ticket/4750 >>> >>> Patches need rebase and minor pytest modification to apply on >>> master, I will do that after review. >>> >>> Patches for ipa-4-1 attached. >>> >>> >> I forgot to fix copy paste error. >> >> Updated patches attached >> > Removed unneeded nsrecord validation in 2 tests > > updated patches attached > Added: * find forward zone with --forward-policy=none (no fwzone exists) * find forward zone with --forward-policy=only (no fwzone exists) * find forward zone with --forward-policy=first (no fwzone exists) * enable enabled zone * disable disabled zone Patches attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0175.4-DNS-tests-separate-current-forward-zone-tests.patch Type: text/x-patch Size: 32152 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0176.4-New-test-cases-for-Forward_zones.patch Type: text/x-patch Size: 39232 bytes Desc: not available URL: From dkupka at redhat.com Wed Dec 17 14:33:53 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 17 Dec 2014 15:33:53 +0100 Subject: [Freeipa-devel] [PATCH] 0034 Always add /etc/hosts record when DNS is being configured. Message-ID: <54919451.7040101@redhat.com> https://fedorahosted.org/freeipa/ticket/4817 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0034-Always-add-etc-hosts-record-when-DNS-is-being-config.patch Type: text/x-patch Size: 1202 bytes Desc: not available URL: From tbabej at redhat.com Wed Dec 17 14:39:25 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 17 Dec 2014 15:39:25 +0100 Subject: [Freeipa-devel] [PATCHES] 0682-0683 Use external pytest plugins: beakerlib and sourceorder In-Reply-To: <549073B7.5010902@redhat.com> References: <549073B7.5010902@redhat.com> Message-ID: <5491959D.80309@redhat.com> On 12/16/2014 07:02 PM, Petr Viktorin wrote: > Hello, > I've split more pytest plugins from FreeIPA, so they can be used to > test other projects. > > Releasing these plugins properly to Fedora is getting delayed, but > they are on fedorahosted: > https://fedorahosted.org/python-pytest-beakerlib/ > https://fedorahosted.org/python-pytest-sourceorder/ > > and in my COPR: > https://copr.fedoraproject.org/coprs/pviktori/pytest-plugins/ > > and also in the freeipa-master COPR: > https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/builds/ > > Note that the BeakerLib plugin does not need to be installed to run > tests. There's some integration code left in IPA to forward logging > and to keep the --with-beakerlib option in ipa-test-task, but that's > only activated if the plugin is available. > These two patches work just fine. Glad to see the plugins extracted, let them be useful in the wild! ACK Pushed to master: bc5b13c3dac8e2b858bd397f91eddf738d13c832 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From simo at redhat.com Wed Dec 17 14:52:21 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Dec 2014 09:52:21 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <5491703C.9090007@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <5491703C.9090007@redhat.com> Message-ID: <20141217095221.423decc8@willson.usersys.redhat.com> On Wed, 17 Dec 2014 12:59:56 +0100 Martin Kosek wrote: > On 12/15/2014 11:01 PM, Simo Sorce wrote: > > > > Hello fellow developers, I added this new design: > > http://www.freeipa.org/page/V4/Domain_Levels > > > > It is a prerequisite for both the Replica Promotion design: > > http://www.freeipa.org/page/V4/Replica_Promotion > > and the Topology plugins design: > > http://www.freeipa.org/page/V4/Manage_replication_topology > > (Ludwig will change this to include the changes we have discussed > > in a previous phone call, and which involve mostly Domain > > Level/Domain Upgrades/migrations issues) > > > > As usual feel free to add as needed or comments and ask questions. > > > > Simo. > > > > Thanks! For starters, please follow > > http://www.freeipa.org/page/Feature_template > > next time :-) Don't worry, I updated current proposal to follow it. Ah you mean you broke and moved down one notch all the headings that I changed one level up because the default ones are ugly ? :-) Why do you start at == level instead of = ? Starting at == makes === almost disappear within the text and sections do not stand up anymore ... > On top of what was already said, I have couple comments: > > > 1) Relation between domain levels and FreeIPA versions > > It is now proposed as "numbers", how do we define the relation? Did > you want to create new domain level on needed basis? It is totally on a need to change basis. > So we would have mapping like > > Domain level 0 --> FreeIPA 4.1 or older > Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin > user life cycle > Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client > Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts NO. We change Domain Level only when there is a well defined *need*. If we change something that absolutely requires all of the servers to have it/update it then we have a candidate reason for a level change. Otherwise not. > ? Would it be more transparent to simply use versions as AD does [1] > and always define which features require it? I.e.: > > Domain level "4.2" > Domain level "4.3" --> thin API client > Domain level "4.4" --> no changes > Domain level "5.0" --> IPA-IPA trusts Certainly we'll need to document what Domain level a feature needs to be activated, it will be necessary because said feature will have to deactivate itself both in the CLI and UI if the domain level is not high enough, and appropriate error messages need to be returned. > 2) Backporting features > Long standing problem with API version was if for example RHEL/CentOS > 6.6 does not rebase, but only backports selected patches/features > from higher versions. Should it bump the API/supported Domain Level? If you create a frankenstein you need to make sure you backport all the features necessary to interoperate at a specific domain level, or you do not get to claim support for that level. > Or should it only bump Domain Level if and only if it backports *all* > features for the respective domain level? Exactly, you have to be consistent. > 3) Storing server and global domain level in LDAP > I added [2]. Thanks, although I think we'll need to store the domain level in it's own object. The reason is that plugins may end up listening in to see if it change and we do not want to have all of them parse every change that goes into cn=ipaConfig all the time. So I will change the container name. Simo. > > [1] > http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx > [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Dec 17 15:11:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 17 Dec 2014 16:11:27 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141217095221.423decc8@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <5491703C.9090007@redhat.com> <20141217095221.423decc8@willson.usersys.redhat.com> Message-ID: <54919D1F.20803@redhat.com> On 12/17/2014 03:52 PM, Simo Sorce wrote: > On Wed, 17 Dec 2014 12:59:56 +0100 > Martin Kosek wrote: > >> On 12/15/2014 11:01 PM, Simo Sorce wrote: >>> >>> Hello fellow developers, I added this new design: >>> http://www.freeipa.org/page/V4/Domain_Levels >>> >>> It is a prerequisite for both the Replica Promotion design: >>> http://www.freeipa.org/page/V4/Replica_Promotion >>> and the Topology plugins design: >>> http://www.freeipa.org/page/V4/Manage_replication_topology >>> (Ludwig will change this to include the changes we have discussed >>> in a previous phone call, and which involve mostly Domain >>> Level/Domain Upgrades/migrations issues) >>> >>> As usual feel free to add as needed or comments and ask questions. >>> >>> Simo. >>> >> >> Thanks! For starters, please follow >> >> http://www.freeipa.org/page/Feature_template >> >> next time :-) Don't worry, I updated current proposal to follow it. > > Ah you mean you broke and moved down one notch all the headings that I > changed one level up because the default ones are ugly ? :-) No? :-) In meadiawiki, the highest headings you are supposed to use is "==" as "=" generates

header and there should be just one

on the page - and that is the page name. > Why do you start at == level instead of = ? See the note in http://www.mediawiki.org/wiki/Help:Formatting#Level_2 This is the reason why I changed levels in the Feature template - to drive the good mediawiki practices. > Starting at == makes === almost disappear within the text and sections > do not stand up anymore ... Then the problem is not in levels, but in the CSS we use - this is something we can fix. >> On top of what was already said, I have couple comments: >> >> >> 1) Relation between domain levels and FreeIPA versions >> >> It is now proposed as "numbers", how do we define the relation? Did >> you want to create new domain level on needed basis? > > It is totally on a need to change basis. > >> So we would have mapping like >> >> Domain level 0 --> FreeIPA 4.1 or older >> Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology plugin >> user life cycle >> Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client >> Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts > > NO. > We change Domain Level only when there is a well defined *need*. > > If we change something that absolutely requires all of the servers to > have it/update it then we have a candidate reason for a level change. > Otherwise not. > >> ? Would it be more transparent to simply use versions as AD does [1] >> and always define which features require it? I.e.: >> >> Domain level "4.2" >> Domain level "4.3" --> thin API client >> Domain level "4.4" --> no changes >> Domain level "5.0" --> IPA-IPA trusts > > Certainly we'll need to document what Domain level a feature needs to > be activated, it will be necessary because said feature will have to > deactivate itself both in the CLI and UI if the domain level is not > high enough, and appropriate error messages need to be returned. I agree both on this comment and comment above. So you would like to push for numeric levels which we would then map in documentation with FreeIPA versions, right? > >> 2) Backporting features >> Long standing problem with API version was if for example RHEL/CentOS >> 6.6 does not rebase, but only backports selected patches/features >> from higher versions. Should it bump the API/supported Domain Level? > > If you create a frankenstein you need to make sure you backport all the > features necessary to interoperate at a specific domain level, or you > do not get to claim support for that level. > >> Or should it only bump Domain Level if and only if it backports *all* >> features for the respective domain level? > > Exactly, you have to be consistent. > >> 3) Storing server and global domain level in LDAP >> I added [2]. > > Thanks, although I think we'll need to store the domain level in it's > own object. The reason is that plugins may end up listening in to see > if it change and we do not want to have all of them parse every change > that goes into cn=ipaConfig all the time. > > So I will change the container name. Ok, makes sense. > > Simo. > >> >> [1] >> http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx >> [2] http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels > > > From simo at redhat.com Wed Dec 17 20:01:44 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Dec 2014 15:01:44 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <54917D78.4050205@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <5491703C.9090007@redhat.com> <54917D78.4050205@redhat.com> Message-ID: <20141217150144.17734aaa@willson.usersys.redhat.com> On Wed, 17 Dec 2014 13:56:24 +0100 Ludwig Krispenz wrote: > > On 12/17/2014 12:59 PM, Martin Kosek wrote: > > On 12/15/2014 11:01 PM, Simo Sorce wrote: > >> Hello fellow developers, I added this new design: > >> http://www.freeipa.org/page/V4/Domain_Levels > >> > >> It is a prerequisite for both the Replica Promotion design: > >> http://www.freeipa.org/page/V4/Replica_Promotion > >> and the Topology plugins design: > >> http://www.freeipa.org/page/V4/Manage_replication_topology > >> (Ludwig will change this to include the changes we have discussed > >> in a previous phone call, and which involve mostly Domain > >> Level/Domain Upgrades/migrations issues) > >> > >> As usual feel free to add as needed or comments and ask questions. > >> > >> Simo. > >> > > Thanks! For starters, please follow > > > > http://www.freeipa.org/page/Feature_template > > > > next time :-) Don't worry, I updated current proposal to follow it. > > > > On top of what was already said, I have couple comments: > > > > > > 1) Relation between domain levels and FreeIPA versions > > > > It is now proposed as "numbers", how do we define the relation? Did > > you want to create new domain level on needed basis? So we would > > have mapping like > > > > Domain level 0 --> FreeIPA 4.1 or older > > Domain level 1 --> FreeIPA 4.2 --> replica promotion, topology > > plugin user life cycle > > Domain level 2 --> FreeIPA 4.3 - FreeIPA 4.4 --> thin API client > > Domain level 3 --> FreeIPA 5.0 --> IPA-IPA trusts > > > > ? Would it be more transparent to simply use versions as AD does > > [1] and always define which features require it? I.e.: > > > > Domain level "4.2" > > Domain level "4.3" --> thin API client > > Domain level "4.4" --> no changes > > Domain level "5.0" --> IPA-IPA trusts > > > > > > 2) Backporting features > > Long standing problem with API version was if for example > > RHEL/CentOS 6.6 does not rebase, but only backports selected > > patches/features from higher versions. Should it bump the > > API/supported Domain Level? > > > > Or should it only bump Domain Level if and only if it backports > > *all* features for the respective domain level? > which function would detect if "all" features are backported, and > which function would bump the server level ? A function implemented by the framework. > maybe Simo's original proposal could be useful: each feature > registers its feature level in the server entry, eg "topology/1.0", > so all baclported features would be visible we can retain the publishing of the individual features, but we probably want to use only the coarse grained domain level range indicator to make a decision. Which means that if you lie because you backport some features and raise the level, but you do not backport them all, then the admin would be able to flip the switch to raise the level and then he may experience issues as the domain is not fully functional ... Simo. > > > > 3) Storing server and global domain level in LDAP > > I added [2]. > > > > > > [1] > > http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx > > [2] > > http://www.freeipa.org/page/V4/Domain_Levels#Storing_Domain_levels > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Thu Dec 18 09:56:47 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 18 Dec 2014 10:56:47 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141216114451.657a311f@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> <20141216114451.657a311f@willson.usersys.redhat.com> Message-ID: <5492A4DF.5030405@redhat.com> On 12/16/2014 05:44 PM, Simo Sorce wrote: > On Tue, 16 Dec 2014 10:40:20 -0500 > Simo Sorce wrote: > >> On Tue, 16 Dec 2014 15:57:34 +0100 >> Ludwig Krispenz wrote: >> >>> On 12/16/2014 03:22 PM, Simo Sorce wrote: >>>> On Tue, 16 Dec 2014 11:33:41 +0100 >>>> Ludwig Krispenz wrote: >>>> >>>>> Hi Simo, >>>>> >>>>> one thing is not quite clear to me: do you want a domain level >>>>> per feature or a global domain level or both ? >>>> The Domain Level is global. >>>> I described a "Feature Version" that is published by feature. >>>> The Feature Versions just state what is available they do not >>>> determine what is the current overall Domain Level. >>> Ok, just to confirm my understanding. >>> >>> - we have one domain level. >> Yes. Hello, Domain level can only be increased. Can it interfere with the ability of the admin to downgrade a software version ? thanks thierry >>> - each (new) plugin or compoment has to define its minimal domain >>> level and execute only features covered by this level >> Each plugin may have different behavior based on the domain level it >> is enabled, however the highest level is open-ended. IE a plugin must >> not stop working if it see a higher level than was known when it was >> built. >> >> SO a plugin may have an if/else like this: >> >> if (level < MIN_DOM_LEVEL) { >> return; >> } else if (level < XYZ_DOM_LEVEL) { >> /* do something */ >> } else { >> /* do something else */ >> } >> >> The last branch is always there unless we are going to stop using a >> plugin and intentionally want it to stop working once the domain level >> is raised past the XYZ_DOM_LEVEL (whatever that will be). >> >>> - in addition, these plugins have to expose their (plugin) version >>> on each server, allowing checks for setting the domain level >> Yes, >> we can refine this part though, for example each plugin could publish >> the minimum domain level is supports instead of a version number if >> that is useful or easier to manage. But this is not sufficient to do >> checks, we still need to know, in some cases, also what is the >> maximum level known for some plugins (but not for others), so we'll >> still need a detailed list of things to check. >> >> If this is too complex however, maybe we can simply publish a >> "supported domain level" number per server, and deal internally within >> a server on how to publish it. > A "supported domain levels" range really, so we can say IPA v8.0 support > level 2-3-4 but not 0 or 1 or 5 (which is supported only by v9.0 > > Actually, I think I will go and change the proposal this way, it will > make it much easier to deal with for checks. > > Simo. > From mbasti at redhat.com Thu Dec 18 12:08:55 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 18 Dec 2014 13:08:55 +0100 Subject: [Freeipa-devel] [PATCH] 0034 Always add /etc/hosts record when DNS is being configured. In-Reply-To: <54919451.7040101@redhat.com> References: <54919451.7040101@redhat.com> Message-ID: <5492C3D7.3050904@redhat.com> On 17/12/14 15:33, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4817 ACK -- Martin Basti From mkosek at redhat.com Thu Dec 18 12:10:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Dec 2014 13:10:24 +0100 Subject: [Freeipa-devel] [PATCH] 0034 Always add /etc/hosts record when DNS is being configured. In-Reply-To: <5492C3D7.3050904@redhat.com> References: <54919451.7040101@redhat.com> <5492C3D7.3050904@redhat.com> Message-ID: <5492C430.1010600@redhat.com> On 12/18/2014 01:08 PM, Martin Basti wrote: > On 17/12/14 15:33, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4817 > ACK Pushed to: master: 3c69435c1b18ad9827f53d31e97ee88fa0eb9370 ipa-4-1: 30868db4532c2118430b5c34799701d77461641c Martin From simo at redhat.com Thu Dec 18 13:52:59 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Dec 2014 08:52:59 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <5492A4DF.5030405@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> <20141216114451.657a311f@willson.usersys.redhat.com> <5492A4DF.5030405@redhat.com> Message-ID: <20141218085259.7b181292@willson.usersys.redhat.com> On Thu, 18 Dec 2014 10:56:47 +0100 thierry bordaz wrote: > On 12/16/2014 05:44 PM, Simo Sorce wrote: > > On Tue, 16 Dec 2014 10:40:20 -0500 > > Simo Sorce wrote: > > > >> On Tue, 16 Dec 2014 15:57:34 +0100 > >> Ludwig Krispenz wrote: > >> > >>> On 12/16/2014 03:22 PM, Simo Sorce wrote: > >>>> On Tue, 16 Dec 2014 11:33:41 +0100 > >>>> Ludwig Krispenz wrote: > >>>> > >>>>> Hi Simo, > >>>>> > >>>>> one thing is not quite clear to me: do you want a domain level > >>>>> per feature or a global domain level or both ? > >>>> The Domain Level is global. > >>>> I described a "Feature Version" that is published by feature. > >>>> The Feature Versions just state what is available they do not > >>>> determine what is the current overall Domain Level. > >>> Ok, just to confirm my understanding. > >>> > >>> - we have one domain level. > >> Yes. > Hello, > > Domain level can only be increased. Can it interfere with the ability > of the admin to downgrade a software version ? Yes it will interfere, but the domain level will never be automatically raised, so the admin has time to do tests for normal functionality, and can wait to raise the domain level if there are reports of issues with newer functionality. Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu Dec 18 14:26:51 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 18 Dec 2014 15:26:51 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141218085259.7b181292@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> <20141216114451.657a311f@willson.usersys.redhat.com> <5492A4DF.5030405@redhat.com> <20141218085259.7b181292@willson.usersys.redhat.com> Message-ID: <5492E42B.3040109@redhat.com> >> Hello, >> >> Domain level can only be increased. Can it interfere with the ability >> of the admin to downgrade a software version ? > Yes it will interfere, but the domain level will never be automatically > raised, so the admin has time to do tests for normal functionality, and > can wait to raise the domain level if there are reports of issues with > newer functionality. I think Thierry had the opposite direrction im mind. Everything is fine, the domain level is raised and then on one server the admin does a downgrade of ipa. Is this possible, what would happen ? > > Simo. > From mkosek at redhat.com Thu Dec 18 14:45:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Dec 2014 15:45:53 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <5492E42B.3040109@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> <20141216114451.657a311f@willson.usersys.redhat.com> <5492A4DF.5030405@redhat.com> <20141218085259.7b181292@willson.usersys.redhat.com> <5492E42B.3040109@redhat.com> Message-ID: <5492E8A1.6030500@redhat.com> On 12/18/2014 03:26 PM, Ludwig Krispenz wrote: > >>> Hello, >>> >>> Domain level can only be increased. Can it interfere with the ability >>> of the admin to downgrade a software version ? >> Yes it will interfere, but the domain level will never be automatically >> raised, so the admin has time to do tests for normal functionality, and >> can wait to raise the domain level if there are reports of issues with >> newer functionality. > I think Thierry had the opposite direrction im mind. Everything is fine, the > domain level is raised and then on one server the admin does a downgrade of > ipa. Is this possible, what would happen ? IPA does not support downgrades (AFAIK) - there is no ipa-ldap-downgrade command. It may work, it may not work - you are on your own here. Martin From simo at redhat.com Thu Dec 18 14:51:13 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Dec 2014 09:51:13 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <5492E42B.3040109@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> <20141216114451.657a311f@willson.usersys.redhat.com> <5492A4DF.5030405@redhat.com> <20141218085259.7b181292@willson.usersys.redhat.com> <5492E42B.3040109@redhat.com> Message-ID: <20141218095113.4a7c00ca@willson.usersys.redhat.com> On Thu, 18 Dec 2014 15:26:51 +0100 Ludwig Krispenz wrote: > > >> Hello, > >> > >> Domain level can only be increased. Can it interfere with the > >> ability of the admin to downgrade a software version ? > > Yes it will interfere, but the domain level will never be > > automatically raised, so the admin has time to do tests for normal > > functionality, and can wait to raise the domain level if there are > > reports of issues with newer functionality. > I think Thierry had the opposite direrction im mind. Everything is > fine, the domain level is raised and then on one server the admin > does a downgrade of ipa. Is this possible, what would happen ? Things will probably start breaking, don't do that. We do not support downgrades even now, so nothing new. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Dec 18 18:52:27 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 18 Dec 2014 13:52:27 -0500 Subject: [Freeipa-devel] [PATCH 0080] Expose the disabled User Auth Type In-Reply-To: <5480AE4D.2000800@redhat.com> References: <1415898295.9116.12.camel@redhat.com> <547F37D3.6040701@redhat.com> <1417717539.3111.6.camel@redhat.com> <5480AE4D.2000800@redhat.com> Message-ID: <1418928747.5774.24.camel@redhat.com> On Thu, 2014-12-04 at 19:56 +0100, Petr Vobornik wrote: > On 12/04/2014 07:25 PM, Nathaniel McCallum wrote: > > On Wed, 2014-12-03 at 17:18 +0100, Petr Vobornik wrote: > >> On 13.11.2014 18:04, Nathaniel McCallum wrote: > >>> Additionally, fix a small bug in ipa-kdb so that the disabled User > >>> Auth Type is properly handled. > >>> > >>> https://fedorahosted.org/freeipa/ticket/4720 > >>> > >> > >> The patch itself looks good to me, VERSION needs to be updated though. > >> > >> But I don't think it works. Don't know why. In my setup, user's config > >> was not ignored. > >> > >> When I tested login in Web UI with: > >> > >> - global config: disabled, otp > >> - user fbar's config: password > >> - fbar had an hotp token assigned > >> > >> I could still login with password and not with otp. If I added 'otp' to > >> fbar's config, I could also login with otp. > > > > How are you logging in? krb5 or LDAP bind? > > > > Forms-based in Web UI. It uses kinit internally. Alright, I was able to reproduce this problem via a bisect. I think you hit a bug that was introduced in 953c6846b7cb8d75253538ab92a1360fceee0c3c and fixed by 9baa93da1cbf56c2a6f7e82e099bc3ff3f19e2e4. Those patches existed in my local branch as one patchset, but was merged in two sections. Unfortunately, though I had discovered and fixed the bug, the fix went in the wrong patch in the series. So you just happened to hit the narrow window where the bug existed in master (but not my local tree). On current master, everything works. I also tested on 4.1.2. A similar bug exists there on the old ipa-pwd-extop code. So if we want to land this patch on 4.1.x, we will need a fix for that code to avoid creating a security hole. Attached is a rebased patch. It has no changes except the VERSION update. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0080.1-Expose-the-disabled-User-Auth-Type.patch Type: text/x-patch Size: 6762 bytes Desc: not available URL: From tbabej at redhat.com Fri Dec 19 14:05:19 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 19 Dec 2014 15:05:19 +0100 Subject: [Freeipa-devel] [PATCH 0296] ipatests: Make descriptions of declarative tests sorted according to their order Message-ID: <5494309F.9080505@redhat.com> Hi, this allows us to sort the descriptions and preserve the test order. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0296-ipatests-Make-descriptions-sorted-according-to-the-o.patch Type: text/x-patch Size: 1358 bytes Desc: not available URL: From lkrispen at redhat.com Fri Dec 19 16:01:56 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 19 Dec 2014 17:01:56 +0100 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <20141218085259.7b181292@willson.usersys.redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> <20141216114451.657a311f@willson.usersys.redhat.com> <5492A4DF.5030405@redhat.com> <20141218085259.7b181292@willson.usersys.redhat.com> Message-ID: <54944BF4.8020508@redhat.com> On 12/18/2014 02:52 PM, Simo Sorce wrote: > On Thu, 18 Dec 2014 10:56:47 +0100 > thierry bordaz wrote: > >> On 12/16/2014 05:44 PM, Simo Sorce wrote: >>> On Tue, 16 Dec 2014 10:40:20 -0500 >>> Simo Sorce wrote: >>> >>>> On Tue, 16 Dec 2014 15:57:34 +0100 >>>> Ludwig Krispenz wrote: >>>> >>>>> On 12/16/2014 03:22 PM, Simo Sorce wrote: >>>>>> On Tue, 16 Dec 2014 11:33:41 +0100 >>>>>> Ludwig Krispenz wrote: >>>>>> >>>>>>> Hi Simo, >>>>>>> >>>>>>> one thing is not quite clear to me: do you want a domain level >>>>>>> per feature or a global domain level or both ? >>>>>> The Domain Level is global. >>>>>> I described a "Feature Version" that is published by feature. >>>>>> The Feature Versions just state what is available they do not >>>>>> determine what is the current overall Domain Level. >>>>> Ok, just to confirm my understanding. >>>>> >>>>> - we have one domain level. >>>> Yes. >> Hello, >> >> Domain level can only be increased. Can it interfere with the ability >> of the admin to downgrade a software version ? > Yes it will interfere, but the domain level will never be automatically > raised, so the admin has time to do tests for normal functionality, and > can wait to raise the domain level if there are reports of issues with > newer functionality. there is one more scenario I would like to clarify. If a new replica is installed or a client promoted to a replica, this means th enew installation of a DS instance, which for some time is not connected to the rest of the topology until its shared date are initialized from an existing server in the topology. After the total init is complete, it can check the set domain level and act accordingly. But how should it act before, assuming domain level 0, or should admin/scripts set a temporary domain level in the neew server, even if it will be overwritten later by replica initialization ? > > Simo. > From simo at redhat.com Fri Dec 19 16:39:40 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Dec 2014 11:39:40 -0500 Subject: [Freeipa-devel] New/Updated FreeIPA design pages In-Reply-To: <54944BF4.8020508@redhat.com> References: <20141215170150.00437756@willson.usersys.redhat.com> <54900A85.9090806@redhat.com> <20141216092231.4e0003ce@willson.usersys.redhat.com> <5490485E.1080002@redhat.com> <20141216104020.500670e2@willson.usersys.redhat.com> <20141216114451.657a311f@willson.usersys.redhat.com> <5492A4DF.5030405@redhat.com> <20141218085259.7b181292@willson.usersys.redhat.com> <54944BF4.8020508@redhat.com> Message-ID: <20141219113940.6ffe2233@willson.usersys.redhat.com> On Fri, 19 Dec 2014 17:01:56 +0100 Ludwig Krispenz wrote: > > On 12/18/2014 02:52 PM, Simo Sorce wrote: > > On Thu, 18 Dec 2014 10:56:47 +0100 > > thierry bordaz wrote: > > > >> On 12/16/2014 05:44 PM, Simo Sorce wrote: > >>> On Tue, 16 Dec 2014 10:40:20 -0500 > >>> Simo Sorce wrote: > >>> > >>>> On Tue, 16 Dec 2014 15:57:34 +0100 > >>>> Ludwig Krispenz wrote: > >>>> > >>>>> On 12/16/2014 03:22 PM, Simo Sorce wrote: > >>>>>> On Tue, 16 Dec 2014 11:33:41 +0100 > >>>>>> Ludwig Krispenz wrote: > >>>>>> > >>>>>>> Hi Simo, > >>>>>>> > >>>>>>> one thing is not quite clear to me: do you want a domain level > >>>>>>> per feature or a global domain level or both ? > >>>>>> The Domain Level is global. > >>>>>> I described a "Feature Version" that is published by feature. > >>>>>> The Feature Versions just state what is available they do not > >>>>>> determine what is the current overall Domain Level. > >>>>> Ok, just to confirm my understanding. > >>>>> > >>>>> - we have one domain level. > >>>> Yes. > >> Hello, > >> > >> Domain level can only be increased. Can it interfere with the > >> ability of the admin to downgrade a software version ? > > Yes it will interfere, but the domain level will never be > > automatically raised, so the admin has time to do tests for normal > > functionality, and can wait to raise the domain level if there are > > reports of issues with newer functionality. > there is one more scenario I would like to clarify. If a new replica > is installed or a client promoted to a replica, this means th enew > installation of a DS instance, which for some time is not connected > to the rest of the topology until its shared date are initialized > from an existing server in the topology. After the total init is > complete, it can check the set domain level and act accordingly. > But how should it act before, assuming domain level 0, or should > admin/scripts set a temporary domain level in the neew server, even > if it will be overwritten later by replica initialization ? I would assume 0 until told otherwise for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From prashant at apigee.com Tue Dec 23 01:40:33 2014 From: prashant at apigee.com (Prashant Bapat) Date: Tue, 23 Dec 2014 07:10:33 +0530 Subject: [Freeipa-devel] SSH Public Key - Centralized Solution Message-ID: Hi, We are planning to roll out FreeIPA for our AWS infrastructure to be the central authentication service. Initially we plan to use the SSH publi keys, user and group management by FreeIPA. We are looking at rolling out the SSS on clients a little later. Two questions. 1. We need to be able to ensure that a user is limited only 2-3 SSH keys. 2. We need some way of forcing these key rotation once in say 90 days. In our existing setup we use a SSH CA based authentication. It has its own issues. But the rotation is handled by cert expiry every 90 days. Any suggestions/help would be appreciated. Thanks in advance. --Prashant -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Dec 23 14:15:34 2014 From: ayoung at redhat.com (Adam Young) Date: Tue, 23 Dec 2014 09:15:34 -0500 Subject: [Freeipa-devel] SSH Public Key - Centralized Solution In-Reply-To: References: Message-ID: <54997906.9000507@redhat.com> On 12/22/2014 08:40 PM, Prashant Bapat wrote: > Hi, > > We are planning to roll out FreeIPA for our AWS infrastructure to be > the central authentication service. Initially we plan to use the SSH > publi keys, user and group management by FreeIPA. We are looking at > rolling out the SSS on clients a little later. > > Two questions. > > 1. We need to be able to ensure that a user is limited only 2-3 SSH keys. SSH keys are a string attribute with a validator. In order to limit the number, you would need to modify the plugin here: https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/util.py#n310 > 2. We need some way of forcing these key rotation once in say 90 days. > > In our existing setup we use a SSH CA based authentication. It has its > own issues. But the rotation is handled by cert expiry every 90 days. This is going to be harder. With password you can validate on login, but there is caching involved with the public key, and I think you would need to take that into account to force invalidation. This is why certs are probably a better idea. Assuming you can flush the public keys fairly regularly, you would want to put the expiration checking on the accessor for the key. This is a direct ldap fetch and not managed by the IPA plugins. > > Any suggestions/help would be appreciated. > > Thanks in advance. > > --Prashant > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Tue Dec 23 16:09:40 2014 From: prashant at apigee.com (Prashant Bapat) Date: Tue, 23 Dec 2014 21:39:40 +0530 Subject: [Freeipa-devel] SSH Public Key - Centralized Solution In-Reply-To: <54997906.9000507@redhat.com> References: <54997906.9000507@redhat.com> Message-ID: Adam, Thanks much for the reply. I will take a look at the code. For the expiration part, do you think it would be a good idea to modify the LDAP schema to include the SSH Pubkey upload date and have a external script to scan the keys for their age and alert/remove the keys ? If yes could you please give me some pointers on how this can be done ? Thanks again. --Prashant On 23 December 2014 at 19:45, Adam Young wrote: > > On 12/22/2014 08:40 PM, Prashant Bapat wrote: > > Hi, > > We are planning to roll out FreeIPA for our AWS infrastructure to be the > central authentication service. Initially we plan to use the SSH publi > keys, user and group management by FreeIPA. We are looking at rolling out > the SSS on clients a little later. > > Two questions. > > 1. We need to be able to ensure that a user is limited only 2-3 SSH > keys. > > SSH keys are a string attribute with a validator. In order to limit the > number, you would need to modify the plugin here: > > > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/util.py#n310 > > > > 2. We need some way of forcing these key rotation once in say 90 days. > > In our existing setup we use a SSH CA based authentication. It has its > own issues. But the rotation is handled by cert expiry every 90 days. > > > This is going to be harder. With password you can validate on login, but > there is caching involved with the public key, and I think you would need > to take that into account to force invalidation. This is why certs are > probably a better idea. > > Assuming you can flush the public keys fairly regularly, you would want to > put the expiration checking on the accessor for the key. This is a direct > ldap fetch and not managed by the IPA plugins. > > > Any suggestions/help would be appreciated. > > Thanks in advance. > > --Prashant > > > _______________________________________________ > Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Wed Dec 24 03:20:29 2014 From: prashant at apigee.com (Prashant Bapat) Date: Wed, 24 Dec 2014 08:50:29 +0530 Subject: [Freeipa-devel] Modifying ID Range Message-ID: Hi, What I'm trying to do is to modify the Range FreeIPA uses. I removed the random Range Id created during install, added a new range that I wanted. But problem is when I try to add a new user or a group now its still using the old range that was created during installation. I tried restarting the ipa service but still no help. Any pointers to this will be appreciated. Thanks. --Prashant -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Tue Dec 30 00:57:45 2014 From: prashant at apigee.com (Prashant Bapat) Date: Tue, 30 Dec 2014 06:27:45 +0530 Subject: [Freeipa-devel] SSH Public Key - Centralized Solution In-Reply-To: References: <54997906.9000507@redhat.com> Message-ID: Hi Again, For enforcing SSH key rotation every N days, I'm thinking the following. Please let me know if this makes sense. 1. Limit the number of keys per user to 2. Control this via the webUI during they public key upload. 2. Append the current timestamp to the key during the upload. This gets stores in LDAP under "ipaSshPubKey" attribute. 3. Store all the key fingerprints permanently. Need to define a new attribute for this. Idea is that a ssh key never gets reused. During the upload verify that the key being uploaded is not already present in the historical store. 4. On the clients, use a ForcedCommand in SSH server and verify the timestamp from #2 above is older than N days. Deny user with a error message if true, allow if false. On similar lines of http://www.sshark.org/ Please let me know your thoughts around this. This is the limiting feature for us to implement FreeIPA in our org right now. Thanks in advance. --Prashant On 23 December 2014 at 21:39, Prashant Bapat wrote: > Adam, > > Thanks much for the reply. I will take a look at the code. > > For the expiration part, do you think it would be a good idea to modify > the LDAP schema to include the SSH Pubkey upload date and have a external > script to scan the keys for their age and alert/remove the keys ? If yes > could you please give me some pointers on how this can be done ? > > Thanks again. > --Prashant > > On 23 December 2014 at 19:45, Adam Young wrote: >> >> On 12/22/2014 08:40 PM, Prashant Bapat wrote: >> >> Hi, >> >> We are planning to roll out FreeIPA for our AWS infrastructure to be >> the central authentication service. Initially we plan to use the SSH publi >> keys, user and group management by FreeIPA. We are looking at rolling out >> the SSS on clients a little later. >> >> Two questions. >> >> 1. We need to be able to ensure that a user is limited only 2-3 SSH >> keys. >> >> SSH keys are a string attribute with a validator. In order to limit the >> number, you would need to modify the plugin here: >> >> >> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/util.py#n310 >> >> >> >> 2. We need some way of forcing these key rotation once in say 90 days. >> >> In our existing setup we use a SSH CA based authentication. It has its >> own issues. But the rotation is handled by cert expiry every 90 days. >> >> >> This is going to be harder. With password you can validate on login, but >> there is caching involved with the public key, and I think you would need >> to take that into account to force invalidation. This is why certs are >> probably a better idea. >> >> Assuming you can flush the public keys fairly regularly, you would want >> to put the expiration checking on the accessor for the key. This is a >> direct ldap fetch and not managed by the IPA plugins. >> >> >> Any suggestions/help would be appreciated. >> >> Thanks in advance. >> >> --Prashant >> >> >> _______________________________________________ >> Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: