From mkosek at redhat.com Thu May 2 10:51:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 May 2013 12:51:04 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517E9341.2080103@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> <517960EB.8030201@redhat.com> <517A5B48.9080208@redhat.com> <517AB320.50009@redhat.com> <517E9341.2080103@redhat.com> Message-ID: <51824518.4040104@redhat.com> On 04/29/2013 05:35 PM, Petr Viktorin wrote: > On 04/26/2013 07:02 PM, Dmitri Pal wrote: >> On 04/26/2013 06:47 AM, Petr Viktorin wrote: >>> On 04/25/2013 06:59 PM, Dmitri Pal wrote: >>>> On 04/25/2013 09:54 AM, Martin Kosek wrote: >>>>> On 04/25/2013 12:37 PM, Petr Viktorin wrote: >>>>>> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>>>>>> This new freeform host attribute will allow provisioning systems >>>>>>> to add custom tags for host objects which can be later used for >>>>>>> in automember rules or for additional local interpretation. >>>>>>> >>>>>>> Design page: >>>>>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>>>>> >>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>>>>>> >>> [...] >>>> >>>> Can we use this patch to create a HOWTO on how to add and LDAP attribute >>>> to IPA? >>> >>> Yes, I can annotate the patch and put it on the wiki. I'll do it once >>> it's pushed so I can link to it. >>> >>> I know we're trying to organize the wiki page names. What's the >>> correct location for a developer-focused HOWTO? >> >> I do not have a preference. Whatever makes sense. > > http://www.freeipa.org/page/HowTo/Add_a_new_attribute > >>> >>>> Also we have, I suspect a lot of metadata about attributes encoded in >>>> the framework, right? >>>> Why can't we use some kind of the data file(s) for it? This way one can >>>> add attributes dynamically and the framework would pick them up. >>>> It is clear that it would have to be done on all replicas >>> >>> So we should store it in LDAP and have it replicated. >> >> >> I am not against it. Files might be an interim step before getting there. > > Keep in mind that clients would need the info too. > >>>> but still it >>>> would not require people to change the code - only configuration. Have >>>> we ever thought about this? >>> >>> If you're talking about parameters in the the framework commands, I >>> think --setattr is fine. >>> Or is this also about the schema? Web UI? >>> >> >> There are three parts: >> a) Schema >> b) Code >> >> option: Str('userclass', attribute=True, cli_name='class', multivalue=True, >> required=False) >> ... >> option: Str('userclass', attribute=True, autofill=False, cli_name='class', >> multivalue=True, query=True, required=False) >> ... >> option: Str('userclass', attribute=True, autofill=False, cli_name='class', >> multivalue=True, required=False) >> >> + Str('userclass*', >> + cli_name='class', >> + label=_('Class'), >> + doc=_('Host category (semantics placed on this attribute are for ' >> + 'local interpretation)'), >> + ), >> ) + ticket_flags_params >> >> + test >> >> This code can be completely parametarized and values read from the LDAP >> or files > > Having one definitive list for the framework, UI, and various flags like > default_attributes is the better design, but sadly without much practical > advantage except the configurability. > > And the configurability would be limited. Lots of IPA code depends on "our" > attributes being there, so users would need to only add additional ones, or > risk breaking something. For small things a schema change and --setattr is > enough (except the Web UI needs a way to do setattr too). If they need to add > something big (custom validators, interdependencies between attributes), > they'll need to write code anyway. > >> c) UI metadata - should be similar to above >> >> Then adding a new field would be equivalent to changing the schema and >> adding an entry or two - it is not a a software update per say. >> >> We would need to keep the data version clear rather than in addition to >> the hardcoded version in the code > > It would be a pretty large change, and it would need to be designed carefully > to deal with replication, clients, data/schema/API versioning, etc. > Don't get me wrong, I'd love to implement this, but I don't think there's > enough demand/value to justify it. > > > I filed a RFE: https://fedorahosted.org/freeipa/ticket/3595 > Thanks. When I finish and deploy the mediawiki version with better CSS and syntax highlighing it will look even better :-) Martin From mkosek at redhat.com Thu May 2 10:52:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 May 2013 12:52:52 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517AB320.50009@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> <517960EB.8030201@redhat.com> <517A5B48.9080208@redhat.com> <517AB320.50009@redhat.com> Message-ID: <51824584.80107@redhat.com> On 04/26/2013 07:02 PM, Dmitri Pal wrote: > On 04/26/2013 06:47 AM, Petr Viktorin wrote: >> On 04/25/2013 06:59 PM, Dmitri Pal wrote: >>> On 04/25/2013 09:54 AM, Martin Kosek wrote: >>>> On 04/25/2013 12:37 PM, Petr Viktorin wrote: >>>>> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>>>>> This new freeform host attribute will allow provisioning systems >>>>>> to add custom tags for host objects which can be later used for >>>>>> in automember rules or for additional local interpretation. >>>>>> >>>>>> Design page: >>>>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>>>>> >> [...] >>> >>> Can we use this patch to create a HOWTO on how to add and LDAP attribute >>> to IPA? >> >> Yes, I can annotate the patch and put it on the wiki. I'll do it once >> it's pushed so I can link to it. >> >> I know we're trying to organize the wiki page names. What's the >> correct location for a developer-focused HOWTO? > > I do not have a preference. Whatever makes sense. > >> >>> Also we have, I suspect a lot of metadata about attributes encoded in >>> the framework, right? >>> Why can't we use some kind of the data file(s) for it? This way one can >>> add attributes dynamically and the framework would pick them up. >>> It is clear that it would have to be done on all replicas >> >> So we should store it in LDAP and have it replicated. > > > I am not against it. Files might be an interim step before getting there. > >> >>> but still it >>> would not require people to change the code - only configuration. Have >>> we ever thought about this? >> >> If you're talking about parameters in the the framework commands, I >> think --setattr is fine. >> Or is this also about the schema? Web UI? >> > > There are three parts: > a) Schema > b) Code > > option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) > ... > option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) > ... > option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) > > + Str('userclass*', > + cli_name='class', > + label=_('Class'), > + doc=_('Host category (semantics placed on this attribute are for ' > + 'local interpretation)'), > + ), > ) + ticket_flags_params > > + test > > This code can be completely parametarized and values read from the LDAP > or files > > c) UI metadata - should be similar to above > > Then adding a new field would be equivalent to changing the schema and > adding an entry or two - it is not a a software update per say. > > We would need to keep the data version clear rather than in addition to > the hardcoded version in the code d) custom normalizer - function able to normalize data added by user e) custom validator - function able of validation of user data f) custom processing based on the attribute which is being done in a pre or post callback I think that defining attribute in LDAP would solve only a small portion of user use cases. This approach would not be able to store d), e) and f) as I do not think we want to execute code stored in LDAP... I still think that custom user plugins for server/client part and for the Web UI is the way to go. Martin From jcholast at redhat.com Thu May 2 11:12:45 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 02 May 2013 13:12:45 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <51824584.80107@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> <517960EB.8030201@redhat.com> <517A5B48.9080208@redhat.com> <517AB320.50009@redhat.com> <51824584.80107@redhat.com> Message-ID: <51824A2D.1070802@redhat.com> On 2.5.2013 12:52, Martin Kosek wrote: > On 04/26/2013 07:02 PM, Dmitri Pal wrote: >> On 04/26/2013 06:47 AM, Petr Viktorin wrote: >>> On 04/25/2013 06:59 PM, Dmitri Pal wrote: >>>> Also we have, I suspect a lot of metadata about attributes encoded in >>>> the framework, right? >>>> Why can't we use some kind of the data file(s) for it? This way one can >>>> add attributes dynamically and the framework would pick them up. >>>> It is clear that it would have to be done on all replicas >>> >>> So we should store it in LDAP and have it replicated. >> >> >> I am not against it. Files might be an interim step before getting there. >> >>> >>>> but still it >>>> would not require people to change the code - only configuration. Have >>>> we ever thought about this? >>> >>> If you're talking about parameters in the the framework commands, I >>> think --setattr is fine. >>> Or is this also about the schema? Web UI? >>> >> >> There are three parts: >> a) Schema >> b) Code >> >> option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) >> ... >> option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) >> ... >> option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) >> >> + Str('userclass*', >> + cli_name='class', >> + label=_('Class'), >> + doc=_('Host category (semantics placed on this attribute are for ' >> + 'local interpretation)'), >> + ), >> ) + ticket_flags_params >> >> + test >> >> This code can be completely parametarized and values read from the LDAP >> or files >> >> c) UI metadata - should be similar to above >> >> Then adding a new field would be equivalent to changing the schema and >> adding an entry or two - it is not a a software update per say. >> >> We would need to keep the data version clear rather than in addition to >> the hardcoded version in the code > > d) custom normalizer - function able to normalize data added by user > > e) custom validator - function able of validation of user data > > f) custom processing based on the attribute which is being done in a pre or > post callback > > I think that defining attribute in LDAP would solve only a small portion of > user use cases. This approach would not be able to store d), e) and f) as I do > not think we want to execute code stored in LDAP... I still think that custom > user plugins for server/client part and for the Web UI is the way to go. +1, I think custom plugins is the way to go. But we should first make installing user plugins easier (allow loading plugins from arbitrary python packages - not just ipalib.plugins and friends - etc.) Honza -- Jan Cholasta From tbabej at redhat.com Thu May 2 12:26:27 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 02 May 2013 14:26:27 +0200 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <517FE22C.50607@redhat.com> References: <5164017C.1000101@redhat.com> <516715C1.9040607@redhat.com> <517FB9DE.8000404@redhat.com> <517FE22C.50607@redhat.com> Message-ID: <51825B73.3040506@redhat.com> On 04/30/2013 05:24 PM, Petr Viktorin wrote: > On 04/30/2013 02:32 PM, Tomas Babej wrote: >> On 04/11/2013 09:57 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> Hi, >>>> >>>> In ipa-replica-manage commands, we enforce that hostnames we work >>>> with are resolvable. However, this caused errors while deleting >>>> or disconnecting a ipa / winsync replica, if that replica was down >>>> and authoritative server for itself. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3524 >>>> >>>> Tomas >>> >>> I'm not sure this is going to do the right thing either. A lot of >>> these commands take the an argument as the remote master to run things >>> on, so we'd really only be validating one of the names. Not sure how >>> that helps us. >>> >> Actually, the patch tried to adress that. I carefully reviewed the >> effort, now we should be consistent in validating all the names. >> >>> What if we honor the --force flag for DNS lookup failures instead? Or, >>> since that could override it and do other things, a --no-lookup flag >>> perhaps? >>> >>> rob >> >> I added a --no-lookup flag for ipa-replica-manage that disables host >> existence check. >> >> Sending both patches rebased. >> >> Tomas > Thanks for the review, > The nolookup argument is never passed to get_ruv() when it is called > by list_ruv, get_rid_by_host, clean_ruv, abort_clean_ruv. Some of > these don't take the argument but are called with it. Lint error: > install/tools/ipa-replica-manage:1188: [E1121, main] Too many > positional arguments for function call > Fixed. > nolookup is also not passed to list_clean_ruv(), re_initialize(), > force_sync(), show_DNA_ranges() etc. > Fixed. > Git complains about some extra whitespace: > Applying: Enforce host existence only where needed in ipa-replica-manage > /home/pviktori/freeipa/.git/rebase-apply/patch:234: new blank line at > EOF. > + > warning: 1 line adds whitespace errors. > Fixed > > I added the ticket to the Minor Enhacements page: http://freeipa.org/page/V3_Minor_Enhancements Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0046-3-Handle-connection-timeout-in-ipa-replica-manage.patch Type: text/x-patch Size: 2037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0045-3-Enforce-host-existence-only-where-needed-in-ipa-repl.patch Type: text/x-patch Size: 14917 bytes Desc: not available URL: From akrivoka at redhat.com Thu May 2 12:54:17 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 02 May 2013 14:54:17 +0200 Subject: [Freeipa-devel] [PATCH] 1099 fix --no-sssd enrollment In-Reply-To: <518019FA.10307@redhat.com> References: <518019FA.10307@redhat.com> Message-ID: <518261F9.9050900@redhat.com> On 04/30/2013 09:22 PM, Rob Crittenden wrote: > Fix client enrollment when using --no-sssd and nss-pam-ldapd. At > version 0.8.4 the default was changed to map uniqueMember to member so > a mapping is no longer required, or possible. This causes the daemon > to not load. > > Remove the option and add a Conflicts on older versions. > > This is more a problem in F-18. I propose we backport this patch to > the ipa-3-1 branch. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu May 2 14:18:29 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 May 2013 16:18:29 +0200 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <51825B73.3040506@redhat.com> References: <5164017C.1000101@redhat.com> <516715C1.9040607@redhat.com> <517FB9DE.8000404@redhat.com> <517FE22C.50607@redhat.com> <51825B73.3040506@redhat.com> Message-ID: <518275B5.7030700@redhat.com> On 05/02/2013 02:26 PM, Tomas Babej wrote: > On 04/30/2013 05:24 PM, Petr Viktorin wrote: >> On 04/30/2013 02:32 PM, Tomas Babej wrote: >>> On 04/11/2013 09:57 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> In ipa-replica-manage commands, we enforce that hostnames we work >>>>> with are resolvable. However, this caused errors while deleting >>>>> or disconnecting a ipa / winsync replica, if that replica was down >>>>> and authoritative server for itself. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3524 >>>>> >>>>> Tomas >>>> >>>> I'm not sure this is going to do the right thing either. A lot of >>>> these commands take the an argument as the remote master to run things >>>> on, so we'd really only be validating one of the names. Not sure how >>>> that helps us. >>>> >>> Actually, the patch tried to adress that. I carefully reviewed the >>> effort, now we should be consistent in validating all the names. >>> >>>> What if we honor the --force flag for DNS lookup failures instead? Or, >>>> since that could override it and do other things, a --no-lookup flag >>>> perhaps? >>>> >>>> rob >>> >>> I added a --no-lookup flag for ipa-replica-manage that disables host >>> existence check. >>> >>> Sending both patches rebased. >>> >>> Tomas >> > Thanks for the review, >> The nolookup argument is never passed to get_ruv() when it is called >> by list_ruv, get_rid_by_host, clean_ruv, abort_clean_ruv. Some of >> these don't take the argument but are called with it. Lint error: >> install/tools/ipa-replica-manage:1188: [E1121, main] Too many >> positional arguments for function call >> > Fixed. >> nolookup is also not passed to list_clean_ruv(), re_initialize(), >> force_sync(), show_DNA_ranges() etc. >> > Fixed. >> Git complains about some extra whitespace: >> Applying: Enforce host existence only where needed in ipa-replica-manage >> /home/pviktori/freeipa/.git/rebase-apply/patch:234: new blank line at >> EOF. >> + >> warning: 1 line adds whitespace errors. >> > Fixed >> >> > I added the ticket to the Minor Enhacements page: > http://freeipa.org/page/V3_Minor_Enhancements > > Tomas Works for me, ACK -- Petr? From rcritten at redhat.com Thu May 2 14:47:07 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 May 2013 10:47:07 -0400 Subject: [Freeipa-devel] [PATCH] 1099 fix --no-sssd enrollment In-Reply-To: <518261F9.9050900@redhat.com> References: <518019FA.10307@redhat.com> <518261F9.9050900@redhat.com> Message-ID: <51827C6B.8040201@redhat.com> Ana Krivokapic wrote: > On 04/30/2013 09:22 PM, Rob Crittenden wrote: >> Fix client enrollment when using --no-sssd and nss-pam-ldapd. At >> version 0.8.4 the default was changed to map uniqueMember to member so >> a mapping is no longer required, or possible. This causes the daemon >> to not load. >> >> Remove the option and add a Conflicts on older versions. >> >> This is more a problem in F-18. I propose we backport this patch to >> the ipa-3-1 branch. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Works for me, ACK. Rebased, fixed small typo and pushed to master and ipa-3-1. rob From rcritten at redhat.com Thu May 2 14:58:52 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 May 2013 10:58:52 -0400 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <518275B5.7030700@redhat.com> References: <5164017C.1000101@redhat.com> <516715C1.9040607@redhat.com> <517FB9DE.8000404@redhat.com> <517FE22C.50607@redhat.com> <51825B73.3040506@redhat.com> <518275B5.7030700@redhat.com> Message-ID: <51827F2C.7010100@redhat.com> Petr Viktorin wrote: > On 05/02/2013 02:26 PM, Tomas Babej wrote: >> On 04/30/2013 05:24 PM, Petr Viktorin wrote: >>> On 04/30/2013 02:32 PM, Tomas Babej wrote: >>>> On 04/11/2013 09:57 PM, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> In ipa-replica-manage commands, we enforce that hostnames we work >>>>>> with are resolvable. However, this caused errors while deleting >>>>>> or disconnecting a ipa / winsync replica, if that replica was down >>>>>> and authoritative server for itself. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3524 >>>>>> >>>>>> Tomas >>>>> >>>>> I'm not sure this is going to do the right thing either. A lot of >>>>> these commands take the an argument as the remote master to run things >>>>> on, so we'd really only be validating one of the names. Not sure how >>>>> that helps us. >>>>> >>>> Actually, the patch tried to adress that. I carefully reviewed the >>>> effort, now we should be consistent in validating all the names. >>>> >>>>> What if we honor the --force flag for DNS lookup failures instead? Or, >>>>> since that could override it and do other things, a --no-lookup flag >>>>> perhaps? >>>>> >>>>> rob >>>> >>>> I added a --no-lookup flag for ipa-replica-manage that disables host >>>> existence check. >>>> >>>> Sending both patches rebased. >>>> >>>> Tomas >>> >> Thanks for the review, >>> The nolookup argument is never passed to get_ruv() when it is called >>> by list_ruv, get_rid_by_host, clean_ruv, abort_clean_ruv. Some of >>> these don't take the argument but are called with it. Lint error: >>> install/tools/ipa-replica-manage:1188: [E1121, main] Too many >>> positional arguments for function call >>> >> Fixed. >>> nolookup is also not passed to list_clean_ruv(), re_initialize(), >>> force_sync(), show_DNA_ranges() etc. >>> >> Fixed. >>> Git complains about some extra whitespace: >>> Applying: Enforce host existence only where needed in ipa-replica-manage >>> /home/pviktori/freeipa/.git/rebase-apply/patch:234: new blank line at >>> EOF. >>> + >>> warning: 1 line adds whitespace errors. >>> >> Fixed >>> >>> >> I added the ticket to the Minor Enhacements page: >> http://freeipa.org/page/V3_Minor_Enhancements >> >> Tomas > > Works for me, ACK > pushed both to master. I added the ticket # to the commit msg in patch 0046 so we have some frame of reference. rob From npmccallum at redhat.com Thu May 2 16:18:37 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 02 May 2013 12:18:37 -0400 Subject: [Freeipa-devel] Final OTP Review Message-ID: <1367511517.29881.12.camel@localhost.localdomain> Attached are the patches from the ongoing OTP review with rcrit. We believe these to be ready to merge. Please review. The first two patches just add the required schema. The third patch adds support for OTP to kdb. The fourth adds ipa-otpd, the otp companion daemon. The fifth, adds the 389DS bind plugin. The sixth patch is cosmetic (.gitignore). Code for managing tokens (CLI or GUI) remains to be written, though I do have a rudimentary script for adding tokens for testing. KNOWN ISSUES 1. ipa-otpd runs as root. This trade-off exists to permit autobinding for this PoC. Ideally, ipa-otpd would run as its own unprivileged user. I'd like to address this for the N+1 release. 2. krb5 currently requires the top three patches here in order to properly trigger the otp code path: https://github.com/greghudson/krb5/commits/keycheck. These should hopefully be merged upstream soon and will be backported to krb5 1.11 in Fedora 19 shortly. 3. krb5 tickets can't be issued. This is due to an upstream ticket issuance bug that was discovered on Monday. This occurs *after* the OTP has already been validated. We are working on a fix for this. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Ignore-log-files-from-automake-tests.patch Type: text/x-patch Size: 495 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-ipa-otp-389DS-bind-plugin.patch Type: text/x-patch Size: 72550 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-the-krb5-FreeIPA-RADIUS-companion-daemon.patch Type: text/x-patch Size: 59994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-ipa-kdb-Add-OTP-support.patch Type: text/x-patch Size: 6525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-IPA-OTP-schema-and-ACLs.patch Type: text/x-patch Size: 22741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-ipaUserAuthType-and-ipaUserAuthTypeClass.patch Type: text/x-patch Size: 4215 bytes Desc: not available URL: From npmccallum at redhat.com Thu May 2 16:21:29 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 02 May 2013 12:21:29 -0400 Subject: [Freeipa-devel] Possible fix for CA install bug? Message-ID: <1367511689.29881.14.camel@localhost.localdomain> When installing beta1, I encountered a bug where the CA install would fail. This may have already been fixed in dogtag or elsewhere, but if not, this patch WorksForMe. I have no idea if it is the "right" fix. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Fix-incorrect-path-breaking-CA-install.patch Type: text/x-patch Size: 963 bytes Desc: not available URL: From rcritten at redhat.com Thu May 2 17:50:27 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 May 2013 13:50:27 -0400 Subject: [Freeipa-devel] Possible fix for CA install bug? In-Reply-To: <1367511689.29881.14.camel@localhost.localdomain> References: <1367511689.29881.14.camel@localhost.localdomain> Message-ID: <5182A763.6030801@redhat.com> Nathaniel McCallum wrote: > When installing beta1, I encountered a bug where the CA install would > fail. This may have already been fixed in dogtag or elsewhere, but if > not, this patch WorksForMe. I have no idea if it is the "right" fix. Good catch. This change apparently was added during the last week of 10.0.2 development and I'm not sure how I missed it. I did at least one successful install using those bits. Maybe either my test was bogus or I had left-over kruft. In any case, we can specify the location directly to pkispawn and not have to move the file. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1100-dogtag.patch Type: text/x-diff Size: 1693 bytes Desc: not available URL: From rcritten at redhat.com Thu May 2 17:51:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 May 2013 13:51:13 -0400 Subject: [Freeipa-devel] Possible fix for CA install bug? In-Reply-To: <5182A763.6030801@redhat.com> References: <1367511689.29881.14.camel@localhost.localdomain> <5182A763.6030801@redhat.com> Message-ID: <5182A791.50503@redhat.com> Rob Crittenden wrote: > Nathaniel McCallum wrote: >> When installing beta1, I encountered a bug where the CA install would >> fail. This may have already been fixed in dogtag or elsewhere, but if >> not, this patch WorksForMe. I have no idea if it is the "right" fix. > > Good catch. This change apparently was added during the last week of > 10.0.2 development and I'm not sure how I missed it. I did at least one > successful install using those bits. Maybe either my test was bogus or I > had left-over kruft. > > In any case, we can specify the location directly to pkispawn and not > have to move the file. BTW, My patch 1098 bumps up the minimum version of dogtag to 10.0.2. rob From npmccallum at redhat.com Thu May 2 19:24:34 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 02 May 2013 15:24:34 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367511517.29881.12.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> Message-ID: <1367522674.29881.17.camel@localhost.localdomain> On Thu, 2013-05-02 at 12:18 -0400, Nathaniel McCallum wrote: > Attached are the patches from the ongoing OTP review with rcrit. We > believe these to be ready to merge. Please review. The first two patches > just add the required schema. The third patch adds support for OTP to > kdb. The fourth adds ipa-otpd, the otp companion daemon. The fifth, adds > the 389DS bind plugin. The sixth patch is cosmetic (.gitignore). > > Code for managing tokens (CLI or GUI) remains to be written, though I do > have a rudimentary script for adding tokens for testing. > > KNOWN ISSUES > 1. ipa-otpd runs as root. This trade-off exists to permit autobinding > for this PoC. Ideally, ipa-otpd would run as its own unprivileged user. > I'd like to address this for the N+1 release. > 2. krb5 currently requires the top three patches here in order to > properly trigger the otp code path: > https://github.com/greghudson/krb5/commits/keycheck. These should > hopefully be merged upstream soon and will be backported to krb5 1.11 in > Fedora 19 shortly. > 3. krb5 tickets can't be issued. This is due to an upstream ticket > issuance bug that was discovered on Monday. This occurs *after* the OTP > has already been validated. We are working on a fix for this. rcrit noticed that I wasn't using pkgconfig in patch #5, which I fixed. He also merged patch #6. Attached are the five remaining patches. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-ipa-otp-389DS-bind-plugin.patch Type: text/x-patch Size: 74582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-the-krb5-FreeIPA-RADIUS-companion-daemon.patch Type: text/x-patch Size: 59994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-ipa-kdb-Add-OTP-support.patch Type: text/x-patch Size: 6525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-IPA-OTP-schema-and-ACLs.patch Type: text/x-patch Size: 22741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-ipaUserAuthType-and-ipaUserAuthTypeClass.patch Type: text/x-patch Size: 4215 bytes Desc: not available URL: From rcritten at redhat.com Thu May 2 20:58:32 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 May 2013 16:58:32 -0400 Subject: [Freeipa-devel] [PATCHES] Fix minor issues in the extdom plugin In-Reply-To: <20130430100454.GA11687@localhost.localdomain> References: <20130430100454.GA11687@localhost.localdomain> Message-ID: <5182D378.5040205@redhat.com> Sumit Bose wrote: > Hi, > > while adding the SID based lookups to SSSD I would some minor issues in > the extdom plugin in code paths which were not used by the current > requests. > > Fixes https://fedorahosted.org/freeipa/ticket/3596 Alexander reports that these work fine, and they look ok to me. ACK, pushed to master rob From simo at redhat.com Thu May 2 21:39:30 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 02 May 2013 17:39:30 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367522674.29881.17.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> Message-ID: <1367530770.2976.126.camel@willson.li.ssimo.org> On Thu, 2013-05-02 at 15:24 -0400, Nathaniel McCallum wrote: > On Thu, 2013-05-02 at 12:18 -0400, Nathaniel McCallum wrote: > > Attached are the patches from the ongoing OTP review with rcrit. We > > believe these to be ready to merge. Please review. The first two patches > > just add the required schema. The third patch adds support for OTP to > > kdb. The fourth adds ipa-otpd, the otp companion daemon. The fifth, adds > > the 389DS bind plugin. The sixth patch is cosmetic (.gitignore). > > > > Code for managing tokens (CLI or GUI) remains to be written, though I do > > have a rudimentary script for adding tokens for testing. > > > > KNOWN ISSUES > > 1. ipa-otpd runs as root. This trade-off exists to permit autobinding > > for this PoC. Ideally, ipa-otpd would run as its own unprivileged user. > > I'd like to address this for the N+1 release. > > 2. krb5 currently requires the top three patches here in order to > > properly trigger the otp code path: > > https://github.com/greghudson/krb5/commits/keycheck. These should > > hopefully be merged upstream soon and will be backported to krb5 1.11 in > > Fedora 19 shortly. > > 3. krb5 tickets can't be issued. This is due to an upstream ticket > > issuance bug that was discovered on Monday. This occurs *after* the OTP > > has already been validated. We are working on a fix for this. > > rcrit noticed that I wasn't using pkgconfig in patch #5, which I fixed. > He also merged patch #6. Attached are the five remaining patches. > > Nathaniel Will do one patch at a time as these are huge. I think you should have separate mail threads per patch so that each can be independently tracked in patchwork. These patches are so huge I am going to have to write separate mails for each anyway. Patch 1 NACK: - I see GPLv2 boiler plate, but we should use v3. - Bad indentation with 2 spaces indent in several places. - not required, but I find much better to use braces around single line ifs, not only for pure stylistic reasons but for defensive programming, it's very common to make mistakes later when modifying existing code and forget to add braces when adding lines to the if statement. - we do not do a new line after a the return type when declaring functions. Not ok: int fn_name() { ok: int fn_name() { - Constructs like the following are not good: if (slapi_entry_attr_find(e, type, &attr) != 0 || !attr) Makes debugging hard and reading hard. It should be: ret = slapi_entry_attr_find(e, type, &attr); if (ret != 0 || attr) { do something; } In general it is not ok to call a function and test its value within an if statement except for trivial ones that return booleans. always: ret = fn() if (ret == ?) { } - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure (although I know slapi_ch_malloc() currently just aborts on failure, I think that is plain wrong which is why I would prefer using malloc/strdup, but well, I guess this is not something I am going to care too much about for now). - Please do not use if (1) { ... } constructs, it makes no sense, simply remove the if statement and leave the contents. - Please if you can use 'done' as a label to get out of a function - token_decode(), credentials_parse() and ipa_otp_do_otp_auth() are effectively returning a boolean state, please make them return bool and true for success, false for failure. (ps: I see this all over, please use bool everywhere you return effectively a boolean state, not going to point out every single function from now on) - indentation issues at lines 524 and 527 of the patch, both case should align after the previous line '(' - another bad testing pattern: do not do things like: ret = foo() == 0 if (ret) { ... } do: ret = fn() if (ret == 0) { ... } - Using a single ipa_otp_postop() function instead of one function per operation makes things less clear, as you have to create the boilerplate for each function seaprately anyway and then most of the function is in the switch case statements which are completely separate. The only common code is the initial checks that you have already split off in _stared()/_oktodo() functions anyway. Having separate function per operation would be preferable I think. - bad indentation line 1054,1055,1065,1074,1092 and so on ... they should be indented after the preceding line(s) '(' Also this is often the case with slapi_log_error() functions too, please indent after the opening '(' on previous lines, not at a random indentation. - Is the logic with auth_type_used correct ? At least the name of the variable sounds misleading, because you set it only if the authentication was successful but not set if it was 'used' but was unsuccessful. Made me look at it multiple times to reconstuct the logic. The var name could be better, however I also want a comment that explain exactly how we are going to manage authentication and fallbacks here as that logic is critical and is useful for anyone that is going to have to change this code later in order not to break it. - What about the comments labeled NGK ? Some of them seem to indicate the plugin still has some deficiencies we should fix ? If so they should use the label FIXME so that it gets readily highlighetd when looking at the code. - General question: how does this PRE_BIND plugin interact with ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? Are you going to cause that plugin not to run by returning a result directly in this function ? Or is this plugin configured to run only after the previous one went through ? I ask because I do not see any ordering information in the cn=config plugin configuration so it is not immediately clear to me. Continuing with otp.c: - what does 'egress' mean ? (can you just use 'done' as a standard label for exceptions ?) - Is it ok to call PK11_DestroyContext() if ctx is NULL ? Can't find much documentation but see #276314 / #276311 on bugzilla.mozilla.org - Can you please add a comment that describe which HMAC algorithm are you using (or a reference to a RFC of it ?) Unfortunately NSS makes thins a lot more cryptic than it should :( Also adding comments before the various NSS invocation to explain what they do would help, this code is obscure. - Why do we have ipa_otp_hotp if we implement only totp ? In general the code seem ok functionally, but the style must be fixed. In general please read http://www.freeipa.org/page/Coding_Style and conform to the style used in other plugins where they do not explicitly contradict the above document for uniformity. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu May 2 21:57:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 May 2013 17:57:50 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367530770.2976.126.camel@willson.li.ssimo.org> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> Message-ID: <5182E15E.5010601@redhat.com> Simo Sorce wrote: > On Thu, 2013-05-02 at 15:24 -0400, Nathaniel McCallum wrote: >> On Thu, 2013-05-02 at 12:18 -0400, Nathaniel McCallum wrote: >>> Attached are the patches from the ongoing OTP review with rcrit. We >>> believe these to be ready to merge. Please review. The first two patches >>> just add the required schema. The third patch adds support for OTP to >>> kdb. The fourth adds ipa-otpd, the otp companion daemon. The fifth, adds >>> the 389DS bind plugin. The sixth patch is cosmetic (.gitignore). >>> >>> Code for managing tokens (CLI or GUI) remains to be written, though I do >>> have a rudimentary script for adding tokens for testing. >>> >>> KNOWN ISSUES >>> 1. ipa-otpd runs as root. This trade-off exists to permit autobinding >>> for this PoC. Ideally, ipa-otpd would run as its own unprivileged user. >>> I'd like to address this for the N+1 release. >>> 2. krb5 currently requires the top three patches here in order to >>> properly trigger the otp code path: >>> https://github.com/greghudson/krb5/commits/keycheck. These should >>> hopefully be merged upstream soon and will be backported to krb5 1.11 in >>> Fedora 19 shortly. >>> 3. krb5 tickets can't be issued. This is due to an upstream ticket >>> issuance bug that was discovered on Monday. This occurs *after* the OTP >>> has already been validated. We are working on a fix for this. >> >> rcrit noticed that I wasn't using pkgconfig in patch #5, which I fixed. >> He also merged patch #6. Attached are the five remaining patches. >> >> Nathaniel > > > Will do one patch at a time as these are huge. > > I think you should have separate mail threads per patch so that each can > be independently tracked in patchwork. > These patches are so huge I am going to have to write separate mails for > each anyway. > > > > > Patch 1 NACK: > > - I see GPLv2 boiler plate, but we should use v3. > > - Bad indentation with 2 spaces indent in several places. > > - not required, but I find much better to use braces around single line > ifs, not only for pure stylistic reasons but for defensive programming, > it's very common to make mistakes later when modifying existing code and > forget to add braces when adding lines to the if statement. > > - we do not do a new line after a the return type when declaring > functions. > > Not ok: > int > fn_name() > { > > ok: > int fn_name() > { > > - Constructs like the following are not good: > > if (slapi_entry_attr_find(e, type, &attr) != 0 || !attr) > > Makes debugging hard and reading hard. It should be: > > ret = slapi_entry_attr_find(e, type, &attr); > if (ret != 0 || attr) { > do something; > } > > In general it is not ok to call a function and test its value within an > if statement except for trivial ones that return booleans. > always: > ret = fn() > if (ret == ?) { } > > - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > (although I know slapi_ch_malloc() currently just aborts on failure, I > think that is plain wrong which is why I would prefer using > malloc/strdup, but well, I guess this is not something I am going to > care too much about for now). > > - Please do not use if (1) { ... } constructs, it makes no sense, simply > remove the if statement and leave the contents. > > - Please if you can use 'done' as a label to get out of a function > > - token_decode(), credentials_parse() and ipa_otp_do_otp_auth() are > effectively returning a boolean state, please make them return bool and > true for success, false for failure. > (ps: I see this all over, please use bool everywhere you return > effectively a boolean state, not going to point out every single > function from now on) > > - indentation issues at lines 524 and 527 of the patch, both case should > align after the previous line '(' > > - another bad testing pattern: > do not do things like: > ret = foo() == 0 > if (ret) { ... } > > do: > > ret = fn() > if (ret == 0) { ... } > > > > - Using a single ipa_otp_postop() function instead of one function per > operation makes things less clear, as you have to create the boilerplate > for each function seaprately anyway and then most of the function is in > the switch case statements which are completely separate. The only > common code is the initial checks that you have already split off in > _stared()/_oktodo() functions anyway. > Having separate function per operation would be preferable I think. > > - bad indentation line 1054,1055,1065,1074,1092 and so on ... they > should be indented after the preceding line(s) '(' > Also this is often the case with slapi_log_error() functions too, please > indent after the opening '(' on previous lines, not at a random > indentation. > > > - Is the logic with auth_type_used correct ? > At least the name of the variable sounds misleading, because you set it > only if the authentication was successful but not set if it was 'used' > but was unsuccessful. Made me look at it multiple times to reconstuct > the logic. The var name could be better, however I also want a comment > that explain exactly how we are going to manage authentication and > fallbacks here as that logic is critical and is useful for anyone that > is going to have to change this code later in order not to break it. > > > - What about the comments labeled NGK ? Some of them seem to indicate > the plugin still has some deficiencies we should fix ? If so they should > use the label FIXME so that it gets readily highlighetd when looking at > the code. > > > - General question: how does this PRE_BIND plugin interact with > ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > Are you going to cause that plugin not to run by returning a result > directly in this function ? > Or is this plugin configured to run only after the previous one went > through ? > I ask because I do not see any ordering information in the cn=config > plugin configuration so it is not immediately clear to me. > > > Continuing with otp.c: > > - what does 'egress' mean ? > (can you just use 'done' as a standard label for exceptions ?) > > - Is it ok to call PK11_DestroyContext() if ctx is NULL ? > Can't find much documentation but see #276314 / #276311 on > bugzilla.mozilla.org > > > - Can you please add a comment that describe which HMAC algorithm are > you using (or a reference to a RFC of it ?) Unfortunately NSS makes > thins a lot more cryptic than it should :( > Also adding comments before the various NSS invocation to explain what > they do would help, this code is obscure. > > > - Why do we have ipa_otp_hotp if we implement only totp ? > > > > In general the code seem ok functionally, but the style must be fixed. > > In general please read http://www.freeipa.org/page/Coding_Style and > conform to the style used in other plugins where they do not explicitly > contradict the above document for uniformity. Simo, I've done an initial review of these and give them an ACK. If you'd like to take a second look it'd be great. At this point though I'm not sure I want to break this out into separate e-mails. I don't want process to get in the way of progress. rob From simo at redhat.com Thu May 2 22:12:37 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 02 May 2013 18:12:37 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <5182E15E.5010601@redhat.com> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <5182E15E.5010601@redhat.com> Message-ID: <1367532757.2976.141.camel@willson.li.ssimo.org> On Thu, 2013-05-02 at 17:57 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2013-05-02 at 15:24 -0400, Nathaniel McCallum wrote: > >> On Thu, 2013-05-02 at 12:18 -0400, Nathaniel McCallum wrote: > >>> Attached are the patches from the ongoing OTP review with rcrit. We > >>> believe these to be ready to merge. Please review. The first two patches > >>> just add the required schema. The third patch adds support for OTP to > >>> kdb. The fourth adds ipa-otpd, the otp companion daemon. The fifth, adds > >>> the 389DS bind plugin. The sixth patch is cosmetic (.gitignore). > >>> > >>> Code for managing tokens (CLI or GUI) remains to be written, though I do > >>> have a rudimentary script for adding tokens for testing. > >>> > >>> KNOWN ISSUES > >>> 1. ipa-otpd runs as root. This trade-off exists to permit autobinding > >>> for this PoC. Ideally, ipa-otpd would run as its own unprivileged user. > >>> I'd like to address this for the N+1 release. > >>> 2. krb5 currently requires the top three patches here in order to > >>> properly trigger the otp code path: > >>> https://github.com/greghudson/krb5/commits/keycheck. These should > >>> hopefully be merged upstream soon and will be backported to krb5 1.11 in > >>> Fedora 19 shortly. > >>> 3. krb5 tickets can't be issued. This is due to an upstream ticket > >>> issuance bug that was discovered on Monday. This occurs *after* the OTP > >>> has already been validated. We are working on a fix for this. > >> > >> rcrit noticed that I wasn't using pkgconfig in patch #5, which I fixed. > >> He also merged patch #6. Attached are the five remaining patches. > >> > >> Nathaniel > > > > > > Will do one patch at a time as these are huge. > > > > I think you should have separate mail threads per patch so that each can > > be independently tracked in patchwork. > > These patches are so huge I am going to have to write separate mails for > > each anyway. > > > > > > > > > > Patch 1 NACK: > > > > - I see GPLv2 boiler plate, but we should use v3. > > > > - Bad indentation with 2 spaces indent in several places. > > > > - not required, but I find much better to use braces around single line > > ifs, not only for pure stylistic reasons but for defensive programming, > > it's very common to make mistakes later when modifying existing code and > > forget to add braces when adding lines to the if statement. > > > > - we do not do a new line after a the return type when declaring > > functions. > > > > Not ok: > > int > > fn_name() > > { > > > > ok: > > int fn_name() > > { > > > > - Constructs like the following are not good: > > > > if (slapi_entry_attr_find(e, type, &attr) != 0 || !attr) > > > > Makes debugging hard and reading hard. It should be: > > > > ret = slapi_entry_attr_find(e, type, &attr); > > if (ret != 0 || attr) { > > do something; > > } > > > > In general it is not ok to call a function and test its value within an > > if statement except for trivial ones that return booleans. > > always: > > ret = fn() > > if (ret == ?) { } > > > > - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > > (although I know slapi_ch_malloc() currently just aborts on failure, I > > think that is plain wrong which is why I would prefer using > > malloc/strdup, but well, I guess this is not something I am going to > > care too much about for now). > > > > - Please do not use if (1) { ... } constructs, it makes no sense, simply > > remove the if statement and leave the contents. > > > > - Please if you can use 'done' as a label to get out of a function > > > > - token_decode(), credentials_parse() and ipa_otp_do_otp_auth() are > > effectively returning a boolean state, please make them return bool and > > true for success, false for failure. > > (ps: I see this all over, please use bool everywhere you return > > effectively a boolean state, not going to point out every single > > function from now on) > > > > - indentation issues at lines 524 and 527 of the patch, both case should > > align after the previous line '(' > > > > - another bad testing pattern: > > do not do things like: > > ret = foo() == 0 > > if (ret) { ... } > > > > do: > > > > ret = fn() > > if (ret == 0) { ... } > > > > > > > > - Using a single ipa_otp_postop() function instead of one function per > > operation makes things less clear, as you have to create the boilerplate > > for each function seaprately anyway and then most of the function is in > > the switch case statements which are completely separate. The only > > common code is the initial checks that you have already split off in > > _stared()/_oktodo() functions anyway. > > Having separate function per operation would be preferable I think. > > > > - bad indentation line 1054,1055,1065,1074,1092 and so on ... they > > should be indented after the preceding line(s) '(' > > Also this is often the case with slapi_log_error() functions too, please > > indent after the opening '(' on previous lines, not at a random > > indentation. > > > > > > - Is the logic with auth_type_used correct ? > > At least the name of the variable sounds misleading, because you set it > > only if the authentication was successful but not set if it was 'used' > > but was unsuccessful. Made me look at it multiple times to reconstuct > > the logic. The var name could be better, however I also want a comment > > that explain exactly how we are going to manage authentication and > > fallbacks here as that logic is critical and is useful for anyone that > > is going to have to change this code later in order not to break it. > > > > > > - What about the comments labeled NGK ? Some of them seem to indicate > > the plugin still has some deficiencies we should fix ? If so they should > > use the label FIXME so that it gets readily highlighetd when looking at > > the code. > > > > > > - General question: how does this PRE_BIND plugin interact with > > ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > > Are you going to cause that plugin not to run by returning a result > > directly in this function ? > > Or is this plugin configured to run only after the previous one went > > through ? > > I ask because I do not see any ordering information in the cn=config > > plugin configuration so it is not immediately clear to me. > > > > > > Continuing with otp.c: > > > > - what does 'egress' mean ? > > (can you just use 'done' as a standard label for exceptions ?) > > > > - Is it ok to call PK11_DestroyContext() if ctx is NULL ? > > Can't find much documentation but see #276314 / #276311 on > > bugzilla.mozilla.org > > > > > > - Can you please add a comment that describe which HMAC algorithm are > > you using (or a reference to a RFC of it ?) Unfortunately NSS makes > > thins a lot more cryptic than it should :( > > Also adding comments before the various NSS invocation to explain what > > they do would help, this code is obscure. > > > > > > - Why do we have ipa_otp_hotp if we implement only totp ? > > > > > > > > In general the code seem ok functionally, but the style must be fixed. > > > > In general please read http://www.freeipa.org/page/Coding_Style and > > conform to the style used in other plugins where they do not explicitly > > contradict the above document for uniformity. > > Simo, I've done an initial review of these and give them an ACK. If > you'd like to take a second look it'd be great. At this point though I'm > not sure I want to break this out into separate e-mails. I don't want > process to get in the way of progress. The second patch is big, I need more time to look at it. 3 and 5 look ok to me. On 4: - I would have called the file otp-aci.ldif (we have default-aci.ldif) not just otp.ldif - I really do not like the deny acis that much. We may need to fix this with the post 3.2 ticket to handle allows differently. The problem is that adding denies here will make that work more difficult and is also tricky top get right, see below: - Is it right to deny all ipatokenRadiusConfigLink, ipatokenRadiusUserName for reading ? If nobody can access this information what do we store it for ? IIRC deny-first wins and the following allow will simply be ignored ? 9.7.2.2 of RHDS manual seem to confirm this. Same comment with the rest of the ACIs whic I see follow the same pattern. Make sure to tyest with a user that is not cn=Directory Manager Simo. -- Simo Sorce * Red Hat, Inc * New York From alee at redhat.com Fri May 3 02:09:29 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 02 May 2013 22:09:29 -0400 Subject: [Freeipa-devel] Announcing the release of Dogtag 10.0.2 Message-ID: <1367546969.7810.35.camel@aleeredhat.laptop> The Dogtag team is proud to announce the second errata build for Dogtag v10.0.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repo. Please try it out and provide karma to move them to the F18 and F19 stable repos. Daily developer builds for Fedora 17, 18 and 19 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.2-2 pki-ra-10.0.2-2 pki-tps-10.0.2-2 dogtag-pki-10.0.2-1 dogtag-pki-theme-10.0.2-1 pki-console-10.0.2-2 == Highlights since Dogtag v. 10.0.1 == * A new Python client framework has been written to connect to the restful interface on the java subsystems. This interface was used for some installation functionality and will continue to be expanded. * pkispawn and pkidestroy were modified to use the new Python client framework and the dependency on jython was eliminated. * The installation interfaces were changed so that most of the installation interactions take place over the admin interface. * New command line parameters have been added to pkidestroy to provide the username and password of the security domain administrator to update the security domain. Formerly, no credentials were required because we used the subsystem certificate of the subsystem for authentication. The new method provides better auditing as to exactly who is de-registering and removing a subsystem. As such, use of the new options is recommended, and will be made mandatory in a future release. * Although it is possible to run Dogtag 9 style instances on Dogtag 10, these instances do not have the required configuration to expose the RESTful interface. A new servlet has been added to return 501 (Not implemented) on these instances when the REST URLs are accessed. This is only applicable on Fedora 18 (See Fedora 19 note below). * A new interactive mode has been added to pkispawn and pkidestroy. In this mode, users are prompted for details in order to set up the most basic servers. Any customizations would still need to be done through configuration files. Interactive mode is an excellent way for users to set up a server and become familiar with Dogtag. * Support has been added for the random generation of serial numbers for certificates issued. More details about this feature and how to enable it can be found here: http://pki.fedoraproject.org/wiki/Random_Certificate_Serial_Numbers * Nonces are used in Dogtag to prevent cross-site request forgery and replay attack, but they were stored in a global list. To prevent possible collisions with other user's nonces, they are now stored in each user's session. * Previously, session IDs were generated using /dev/random, which may block under certain circumstances, making server startup slow. To avoid this, the server configuration has been changed to use PKCS11PRNG provided by JSS. * A new upgrade framework has been added to allow instances to be automatically upgraded when new packages are installed. This framework will be used to eventually remove the need for migrations between releases. The upgrade scripts are invoked by postinstall scriptlets in the pki-base and pki-server packages. On completing an upgrade, users should check the upgrade logs in /var/log/pki/pki-upgrade-*.log and /var/log/pki/pki-server-upgrade-*.log for any errors. The upgrade scripts (pki-upgrade and pki-server-upgrade) can also be run manually. Additional troubleshooting information can be found at: http://pki.fedoraproject.org/wiki/Upgrade * New CLI has been added to simplify client certificate management including importing and trusting CA certificates. * Previously, the pki CLI tool used the same parameter (-w) to specify both user and client certificate database passwords. The CLI has been modified to use a new parameter (-c) for the database password, and -w for the user password. * Multiple additional fixes to pkispawn, pkidestroy, pki and their man pages. == Notes on Fedora 19 == Fedora 19 does not provide tomcat 6. Dogtag 9 style instances will therefore no longer work on Fedora 19. These instances need to be migrated to Dogtag 10. To prevent inadvertently disabling Dogtag instances, code has been added to prevent upgrades to Fedora 19 if Dogtag 9 instances exist. Details on how to upgrade Dogtag 9 instances and workarounds can be found at: http://pki.fedoraproject.org/wiki/Migrating_Dogtag_9_Instances_to_Dogtag_10 == Detailed Changes since Dogtag v. 10.0.1 == akoneru (23): #191 Map REST exceptions to HTTP status codes #217 CLI should display message on operations that complete with error #290 Add hints to option descriptions for cert-find cli command #383 Extend coverity tests to scan other subsystems (TPS, etc.) #452 Dogtag 10: Fix minor RA and TPS Configuration Wizard Panel issues #465 Verify 'pki_backup_keys=True' if 'pki_backup_password'is set #470 Prevent concurrent execution of pkispawn/pkidestroy #471 Update man pages for interactive pkispawn/pkidestroy #493 interpolation in pkispawn scripts should not apply to passwords #502 Change pkidestroy "-w" option to require a password file #507 Mark pki.conf as configuration file in RPM spec #509 man page for pkispawn should be modified to specify pki_ca_signing_subject_dn when setting up subordinate CA #514 Clean up pkispawn output #521 Separate python deployment engine from python deployment scriptlets source code #525 Incorrect info in pkispawn man page #536 Catch keyboard interrupt #542 Remove all "respawn()" logic from "pkispawn" #543 Incorrect user-show usage. #549 PKCS10Client tool throws java exception NoClassDefFoundError #563 Use timeout in configuration script #566 Mask sensitive parameters in archived config #592 pkispawn not reporting the error message when exceptions are thrown #593 Error caused by JSON Configuration result decoding when installing CA clone alee (9): #232 add python binding for pkispawn/ pkidestroy #419 REST interface for cert requests #532 refactor pkispawn to use new python client #546 Upgrade script for clone installation #564 Rename base/deploy to base/server #589 dependency needed for java-atk-wrapper in f19 #578 Rest API does not work on d9 -> d10 upgrade instances #590 pki-base needs to deliver /var/log/pki #597 Create 10.0.2 builds awnuk (7): #569 Port support for random certificate serial numbers to Dogtag 10 #570 Port patch allowing to support random certificate serial numbers for system certificates to Dogtag 10 #579 Port patch allowing to clone CA with random serial number enabled. #580 Port patch allowing to restart CA clone during configuration change to random serial numbers. #584 Port patch including system certificates with random serial numbers in the certificate counter. BZ 955784 - Correct Javascript inability to handle big numbers BZ 951501 - Coorects key IDs miscalculated by Javascript cfu (6): BZ 929043 - serverCert.profile with SAN results in SubjectAltNameException BZ 927545 - Transport Cert signing Algorithm doesn't show ECC Signing Algorithm BZ 904289 - Add ECC Support to Certificate Profiles BZ 902952 - RFE: Revocation routing with TPS and multiple non-cloned CAs BZ 903401 - TMS: RSA token enrollment failed : public key decode error #362 CMC ECC edewata (24) #190 REST interface for user-group membership. #291 Fix forma of validityUnit option in cert-find command #380 default install: part 2 #472 pkispawn should test DS info #473 pkispawn should test security domain info #474 Session-based nonces #476 Limit username & password authentication #477 Annotation for authentication methods #491 Prompt CLI user on certificate warnings. #497 Date format for cert-find #498 [RFE] Add dates to cert-find output #500 validityCount option returns 500 error #501 Add cert status option to cert-find #503 Dogtag 10: Security Domain Issues #511 Add cert-request-show command. #520 CLI returns 0 on error #523 Add CLI option to capture HTTP data #524 Tomcat blocks during startup #535 python-requests compatibility problem #541 Use FQDN instead of localhost in CLI #544 Implement upgrade framework #545 Upgrade script for random number generator #553 pki.conf needs to be delivered by pki-base #598 Upgrade script for JNI_JAR_DIR jmagne (1): #587 ipa-server-install crashes due to sslget error mharmsen (7): #409 Add pkispawn option to not copy the UI pieces (gifs, templates). #488 Dogtag 10: Fix cli 'cert-find' clientAuth issue #517 Clean up theme dependencies #518 Remove UI dependencies from pkispawn #602 pkiconsole cannot find 'jss4.jar' on Fedora 19 BZ 947524 - Clone installation does not work over NAT BZ 919476 - pkispawn crashes due to dangling symlink to jss4.jar From rcritten at redhat.com Fri May 3 02:29:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 02 May 2013 22:29:26 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367532757.2976.141.camel@willson.li.ssimo.org> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <5182E15E.5010601@redhat.com> <1367532757.2976.141.camel@willson.li.ssimo.org> Message-ID: <51832106.5000800@redhat.com> Simo Sorce wrote: > On Thu, 2013-05-02 at 17:57 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2013-05-02 at 15:24 -0400, Nathaniel McCallum wrote: >>>> On Thu, 2013-05-02 at 12:18 -0400, Nathaniel McCallum wrote: >>>>> Attached are the patches from the ongoing OTP review with rcrit. We >>>>> believe these to be ready to merge. Please review. The first two patches >>>>> just add the required schema. The third patch adds support for OTP to >>>>> kdb. The fourth adds ipa-otpd, the otp companion daemon. The fifth, adds >>>>> the 389DS bind plugin. The sixth patch is cosmetic (.gitignore). >>>>> >>>>> Code for managing tokens (CLI or GUI) remains to be written, though I do >>>>> have a rudimentary script for adding tokens for testing. >>>>> >>>>> KNOWN ISSUES >>>>> 1. ipa-otpd runs as root. This trade-off exists to permit autobinding >>>>> for this PoC. Ideally, ipa-otpd would run as its own unprivileged user. >>>>> I'd like to address this for the N+1 release. >>>>> 2. krb5 currently requires the top three patches here in order to >>>>> properly trigger the otp code path: >>>>> https://github.com/greghudson/krb5/commits/keycheck. These should >>>>> hopefully be merged upstream soon and will be backported to krb5 1.11 in >>>>> Fedora 19 shortly. >>>>> 3. krb5 tickets can't be issued. This is due to an upstream ticket >>>>> issuance bug that was discovered on Monday. This occurs *after* the OTP >>>>> has already been validated. We are working on a fix for this. >>>> >>>> rcrit noticed that I wasn't using pkgconfig in patch #5, which I fixed. >>>> He also merged patch #6. Attached are the five remaining patches. >>>> >>>> Nathaniel >>> >>> >>> Will do one patch at a time as these are huge. >>> >>> I think you should have separate mail threads per patch so that each can >>> be independently tracked in patchwork. >>> These patches are so huge I am going to have to write separate mails for >>> each anyway. >>> >>> >>> >>> >>> Patch 1 NACK: >>> >>> - I see GPLv2 boiler plate, but we should use v3. >>> >>> - Bad indentation with 2 spaces indent in several places. >>> >>> - not required, but I find much better to use braces around single line >>> ifs, not only for pure stylistic reasons but for defensive programming, >>> it's very common to make mistakes later when modifying existing code and >>> forget to add braces when adding lines to the if statement. >>> >>> - we do not do a new line after a the return type when declaring >>> functions. >>> >>> Not ok: >>> int >>> fn_name() >>> { >>> >>> ok: >>> int fn_name() >>> { >>> >>> - Constructs like the following are not good: >>> >>> if (slapi_entry_attr_find(e, type, &attr) != 0 || !attr) >>> >>> Makes debugging hard and reading hard. It should be: >>> >>> ret = slapi_entry_attr_find(e, type, &attr); >>> if (ret != 0 || attr) { >>> do something; >>> } >>> >>> In general it is not ok to call a function and test its value within an >>> if statement except for trivial ones that return booleans. >>> always: >>> ret = fn() >>> if (ret == ?) { } >>> >>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >>> (although I know slapi_ch_malloc() currently just aborts on failure, I >>> think that is plain wrong which is why I would prefer using >>> malloc/strdup, but well, I guess this is not something I am going to >>> care too much about for now). >>> >>> - Please do not use if (1) { ... } constructs, it makes no sense, simply >>> remove the if statement and leave the contents. >>> >>> - Please if you can use 'done' as a label to get out of a function >>> >>> - token_decode(), credentials_parse() and ipa_otp_do_otp_auth() are >>> effectively returning a boolean state, please make them return bool and >>> true for success, false for failure. >>> (ps: I see this all over, please use bool everywhere you return >>> effectively a boolean state, not going to point out every single >>> function from now on) >>> >>> - indentation issues at lines 524 and 527 of the patch, both case should >>> align after the previous line '(' >>> >>> - another bad testing pattern: >>> do not do things like: >>> ret = foo() == 0 >>> if (ret) { ... } >>> >>> do: >>> >>> ret = fn() >>> if (ret == 0) { ... } >>> >>> >>> >>> - Using a single ipa_otp_postop() function instead of one function per >>> operation makes things less clear, as you have to create the boilerplate >>> for each function seaprately anyway and then most of the function is in >>> the switch case statements which are completely separate. The only >>> common code is the initial checks that you have already split off in >>> _stared()/_oktodo() functions anyway. >>> Having separate function per operation would be preferable I think. >>> >>> - bad indentation line 1054,1055,1065,1074,1092 and so on ... they >>> should be indented after the preceding line(s) '(' >>> Also this is often the case with slapi_log_error() functions too, please >>> indent after the opening '(' on previous lines, not at a random >>> indentation. >>> >>> >>> - Is the logic with auth_type_used correct ? >>> At least the name of the variable sounds misleading, because you set it >>> only if the authentication was successful but not set if it was 'used' >>> but was unsuccessful. Made me look at it multiple times to reconstuct >>> the logic. The var name could be better, however I also want a comment >>> that explain exactly how we are going to manage authentication and >>> fallbacks here as that logic is critical and is useful for anyone that >>> is going to have to change this code later in order not to break it. >>> >>> >>> - What about the comments labeled NGK ? Some of them seem to indicate >>> the plugin still has some deficiencies we should fix ? If so they should >>> use the label FIXME so that it gets readily highlighetd when looking at >>> the code. >>> >>> >>> - General question: how does this PRE_BIND plugin interact with >>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >>> Are you going to cause that plugin not to run by returning a result >>> directly in this function ? >>> Or is this plugin configured to run only after the previous one went >>> through ? >>> I ask because I do not see any ordering information in the cn=config >>> plugin configuration so it is not immediately clear to me. >>> >>> >>> Continuing with otp.c: >>> >>> - what does 'egress' mean ? >>> (can you just use 'done' as a standard label for exceptions ?) >>> >>> - Is it ok to call PK11_DestroyContext() if ctx is NULL ? >>> Can't find much documentation but see #276314 / #276311 on >>> bugzilla.mozilla.org >>> >>> >>> - Can you please add a comment that describe which HMAC algorithm are >>> you using (or a reference to a RFC of it ?) Unfortunately NSS makes >>> thins a lot more cryptic than it should :( >>> Also adding comments before the various NSS invocation to explain what >>> they do would help, this code is obscure. >>> >>> >>> - Why do we have ipa_otp_hotp if we implement only totp ? >>> >>> >>> >>> In general the code seem ok functionally, but the style must be fixed. >>> >>> In general please read http://www.freeipa.org/page/Coding_Style and >>> conform to the style used in other plugins where they do not explicitly >>> contradict the above document for uniformity. >> >> Simo, I've done an initial review of these and give them an ACK. If >> you'd like to take a second look it'd be great. At this point though I'm >> not sure I want to break this out into separate e-mails. I don't want >> process to get in the way of progress. > > The second patch is big, I need more time to look at it. > > 3 and 5 look ok to me. > > On 4: > - I would have called the file otp-aci.ldif (we have default-aci.ldif) > not just otp.ldif I named it that because I snuck in the container as well. If the file is renamed we should really break that part out. > - I really do not like the deny acis that much. > We may need to fix this with the post 3.2 ticket to handle allows > differently. The problem is that adding denies here will make that work > more difficult and is also tricky top get right, see below: > > - Is it right to deny all ipatokenRadiusConfigLink, > ipatokenRadiusUserName for reading ? > If nobody can access this information what do we store it for ? > IIRC deny-first wins and the following allow will simply be ignored ? > 9.7.2.2 of RHDS manual seem to confirm this. > > Same comment with the rest of the ACIs whic I see follow the same > pattern. > > Make sure to tyest with a user that is not cn=Directory Manager I've tested them all with real data with the exception of the Radius acis, but since they follow the same pattern it should be ok. No user can read any attribute but ipaUserAuthType, and only a member of the admins group can write it. We are limited because we have a blanket read-all aci, so I had to go in and remove read access for each, then grant it back to admins. We will add in delegatable permissions in the future. This code is testable against 389-ds as-is. I was able to create a user, configure it for OTP, create a token, add it to my Android phone, and use that to do a simple bind against 389-ds. rob From npmccallum at redhat.com Fri May 3 05:27:45 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 03 May 2013 01:27:45 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367530770.2976.126.camel@willson.li.ssimo.org> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> Message-ID: <1367558865.29881.35.camel@localhost.localdomain> All issues fixed unless noted below... The attached patches are tested to work. On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > (although I know slapi_ch_malloc() currently just aborts on failure, I > think that is plain wrong which is why I would prefer using > malloc/strdup, but well, I guess this is not something I am going to > care too much about for now). Not fixed. > - Is the logic with auth_type_used correct ? > At least the name of the variable sounds misleading, because you set it > only if the authentication was successful but not set if it was 'used' > but was unsuccessful. Made me look at it multiple times to reconstuct > the logic. The var name could be better, however I also want a comment > that explain exactly how we are going to manage authentication and > fallbacks here as that logic is critical and is useful for anyone that > is going to have to change this code later in order not to break it. The variable is now gone. I re-factored the section to make the logic clearer and put a nice big comment up top. > - General question: how does this PRE_BIND plugin interact with > ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > Are you going to cause that plugin not to run by returning a result > directly in this function ? > Or is this plugin configured to run only after the previous one went > through ? > I ask because I do not see any ordering information in the cn=config > plugin configuration so it is not immediately clear to me. That is a good question for Nathan since he wrote this part of the code... > Continuing with otp.c: > > - what does 'egress' mean ? > (can you just use 'done' as a standard label for exceptions ?) Egress: Noun - The action of going out of or leaving a place: "direct means of access and egress". Verb - Go out of or leave (a place). In short: ingress means to enter and egress means to exit. I have changed all 'egress' labels to 'done'. > - Is it ok to call PK11_DestroyContext() if ctx is NULL ? > Can't find much documentation but see #276314 / #276311 on > bugzilla.mozilla.org I added if's for all of these just to be defensive. > - Can you please add a comment that describe which HMAC algorithm are > you using (or a reference to a RFC of it ?) Unfortunately NSS makes > thins a lot more cryptic than it should :( > Also adding comments before the various NSS invocation to explain what > they do would help, this code is obscure. Unfortunately, that codes is mostly copy/paste from an NSS example of how to do HMAC. It is just as unclear to me as it is to you. I have added a link to the example with a note about me not understanding how it works... The good news is that it passes all the unit tests which use values defined in the RFC. Also, valgrind reports no leaks or other errors. So even if I don't know *how* it works, I do know that it does, in fact, work. > - Why do we have ipa_otp_hotp if we implement only totp ? TOTP is a specialized case of HOTP. It is simply an alternative mechanism for calculating the counter input to HOTP. Note that ipa_otp_totp() is basically a one-liner. Since you *have* to implement HOTP to get TOTP, you might as well expose the HOTP implementation for future use. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-ipa-otp-389DS-bind-plugin.patch Type: text/x-patch Size: 76544 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-the-krb5-FreeIPA-RADIUS-companion-daemon.patch Type: text/x-patch Size: 59994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-ipa-kdb-Add-OTP-support.patch Type: text/x-patch Size: 6525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-IPA-OTP-schema-and-ACLs.patch Type: text/x-patch Size: 22741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-ipaUserAuthType-and-ipaUserAuthTypeClass.patch Type: text/x-patch Size: 4215 bytes Desc: not available URL: From nkinder at redhat.com Fri May 3 06:39:22 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 02 May 2013 23:39:22 -0700 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367558865.29881.35.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> Message-ID: <51835B9A.30201@redhat.com> On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: > All issues fixed unless noted below... The attached patches are tested > to work. > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > >> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >> (although I know slapi_ch_malloc() currently just aborts on failure, I >> think that is plain wrong which is why I would prefer using >> malloc/strdup, but well, I guess this is not something I am going to >> care too much about for now). > Not fixed. > >> - Is the logic with auth_type_used correct ? >> At least the name of the variable sounds misleading, because you set it >> only if the authentication was successful but not set if it was 'used' >> but was unsuccessful. Made me look at it multiple times to reconstuct >> the logic. The var name could be better, however I also want a comment >> that explain exactly how we are going to manage authentication and >> fallbacks here as that logic is critical and is useful for anyone that >> is going to have to change this code later in order not to break it. > The variable is now gone. I re-factored the section to make the logic > clearer and put a nice big comment up top. > >> - General question: how does this PRE_BIND plugin interact with >> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >> Are you going to cause that plugin not to run by returning a result >> directly in this function ? >> Or is this plugin configured to run only after the previous one went >> through ? >> I ask because I do not see any ordering information in the cn=config >> plugin configuration so it is not immediately clear to me. > That is a good question for Nathan since he wrote this part of the > code... We would need to set the precedence if you want a predictable/guaranteed execution order. If a pre-BIND plug-in callback returns non-zero (which you should do when the plug-in sends the result to the client directly), it will cause other pre-bind plug-ins to not be called. This is actually how all pre-op plug-ins work. If a pre-op callback returns an error, we don't call the rest of the pre-op plug-ins in the list. > >> Continuing with otp.c: >> >> - what does 'egress' mean ? >> (can you just use 'done' as a standard label for exceptions ?) > Egress: > Noun - The action of going out of or leaving a place: "direct means of > access and egress". > Verb - Go out of or leave (a place). > > In short: ingress means to enter and egress means to exit. > > I have changed all 'egress' labels to 'done'. > >> - Is it ok to call PK11_DestroyContext() if ctx is NULL ? >> Can't find much documentation but see #276314 / #276311 on >> bugzilla.mozilla.org > I added if's for all of these just to be defensive. > >> - Can you please add a comment that describe which HMAC algorithm are >> you using (or a reference to a RFC of it ?) Unfortunately NSS makes >> thins a lot more cryptic than it should :( >> Also adding comments before the various NSS invocation to explain what >> they do would help, this code is obscure. > Unfortunately, that codes is mostly copy/paste from an NSS example of > how to do HMAC. It is just as unclear to me as it is to you. I have > added a link to the example with a note about me not understanding how > it works... We should have Bob Relyea (cc'd) from the NSS development team take a look at it. -NGK > > The good news is that it passes all the unit tests which use values > defined in the RFC. Also, valgrind reports no leaks or other errors. So > even if I don't know *how* it works, I do know that it does, in fact, > work. > >> - Why do we have ipa_otp_hotp if we implement only totp ? > TOTP is a specialized case of HOTP. It is simply an alternative > mechanism for calculating the counter input to HOTP. Note that > ipa_otp_totp() is basically a one-liner. Since you *have* to implement > HOTP to get TOTP, you might as well expose the HOTP implementation for > future use. > > Nathaniel > From akrivoka at redhat.com Fri May 3 10:44:31 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 03 May 2013 12:44:31 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <517A5C3C.4010005@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <51795BE6.9090405@redhat.com> <517A5C3C.4010005@redhat.com> Message-ID: <5183950F.1050201@redhat.com> On 04/26/2013 12:51 PM, Petr Vobornik wrote: > On 04/25/2013 06:37 PM, Ana Krivokapic wrote: > >> >> 1) When in self service mode, you are now allowed to go to pages of >> related objects. If you go to e.g. User Groups for your user, there are >> Add/Delete buttons and they are enabled, but if you try to use them, you >> will be denied access. However, a message will appear, saying 'Items >> added' / 'Items removed' even though the operation had failed. Should we >> disable these options in self service mode? I think we should at least >> make sure that the misleading message which suggests that the actions >> was completed, does not appear. > > Regression. Links should not be clickable and buttons should be hidden. Add/Delete buttons are still enabled in self-service mode (e.g. https://ipahost/ipa/ui/index.html#/e/group/member_user/admins). I have found no other issues in recent commits (apart from the ones already reported). -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mkosek at redhat.com Fri May 3 10:43:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 May 2013 12:43:02 +0200 Subject: [Freeipa-devel] Possible fix for CA install bug? In-Reply-To: <5182A791.50503@redhat.com> References: <1367511689.29881.14.camel@localhost.localdomain> <5182A763.6030801@redhat.com> <5182A791.50503@redhat.com> Message-ID: <518394B6.5090203@redhat.com> On 05/02/2013 07:51 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Nathaniel McCallum wrote: >>> When installing beta1, I encountered a bug where the CA install would >>> fail. This may have already been fixed in dogtag or elsewhere, but if >>> not, this patch WorksForMe. I have no idea if it is the "right" fix. >> >> Good catch. This change apparently was added during the last week of >> 10.0.2 development and I'm not sure how I missed it. I did at least one >> successful install using those bits. Maybe either my test was bogus or I >> had left-over kruft. >> >> In any case, we can specify the location directly to pkispawn and not >> have to move the file. > > BTW, My patch 1098 bumps up the minimum version of dogtag to 10.0.2. > > rob I tested 1100 and it works great on master server. However when I am on replica, it always fails: # ipa-ca-install replica-info-vm-024.idm.lab.bos.redhat.com.gpg Directory Manager (existing master) password: ... Connection check OK Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpRR0ic3' returned non-zero exit status 1 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed CA installation log including pkispawn error attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-ca-install.log Type: text/x-log Size: 11472 bytes Desc: not available URL: From pvoborni at redhat.com Fri May 3 11:31:24 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 May 2013 13:31:24 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <5183950F.1050201@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <51795BE6.9090405@redhat.com> <517A5C3C.4010005@redhat.com> <5183950F.1050201@redhat.com> Message-ID: <5183A00C.7090905@redhat.com> On 05/03/2013 12:44 PM, Ana Krivokapic wrote: > On 04/26/2013 12:51 PM, Petr Vobornik wrote: >> On 04/25/2013 06:37 PM, Ana Krivokapic wrote: >> >>> >>> 1) When in self service mode, you are now allowed to go to pages of >>> related objects. If you go to e.g. User Groups for your user, there are >>> Add/Delete buttons and they are enabled, but if you try to use them, you >>> will be denied access. However, a message will appear, saying 'Items >>> added' / 'Items removed' even though the operation had failed. Should we >>> disable these options in self service mode? I think we should at least >>> make sure that the misleading message which suggests that the actions >>> was completed, does not appear. >> >> Regression. Links should not be clickable and buttons should be hidden. > > Add/Delete buttons are still enabled in self-service mode (e.g. > https://ipahost/ipa/ui/index.html#/e/group/member_user/admins). > > I have found no other issues in recent commits (apart from the ones > already reported). > I don't think that this is an issue. The buttons are disabled on self-service page. Other pages, accessible only by manual change of URL, aren't important in self-service mode. Question is if we should limit navigation only to user pages or just user details page. -- Petr Vobornik From pviktori at redhat.com Fri May 3 12:09:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 03 May 2013 14:09:15 +0200 Subject: [Freeipa-devel] [PATCH] 1098 catch cert-find errors on upgraded servers In-Reply-To: <517EDD81.9020005@redhat.com> References: <517ADB26.60402@redhat.com> <517E559F.60301@redhat.com> <517EDD81.9020005@redhat.com> Message-ID: <5183A8EB.9070809@redhat.com> On 04/29/2013 10:52 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/26/2013 09:53 PM, Rob Crittenden wrote: >>> A dogtag 9 -> 10 upgraded server doesn't provide the RESTful API so >>> therefore the cert-find command doesn't work. Starting with dogtag >>> 10.0.2 it is going to send back a 501 (HTTP Not implemented) in this >>> case so we at least have something to catch. >>> >>> This patch catches a 501 and returns a more specific message. >>> >>> 10.0.2 builds should be available this weekend, or you can pull from >>> their devel repo at: >>> >>> [dogtag-devel] >>> name=Dogtag development $releasever - $basearch >>> baseurl=http://nkinder.fedorapeople.org/dogtag-devel/fedora/$releasever/$basearch/os/ >>> >>> >>> >>> enabled=0 >>> gpgcheck=0 >>> >> >> With the new Dogtag, /root/.pki/pki-tomcat/ca_admin_cert.p12 is not >> created. Installation of a new server fails on copying that to >> /root/ca-agent.p12. Adding Ade to the thread, he should know more. >> >> >> On my instance upgraded from f17 to f18, I get 404 errors, not 501. >> >> $ rpm -q pki-base >> pki-base-10.0.2-1.fc18.noarch >> $ ./ipa cert-find >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (Not Found) >> $ curl -v http://`hostname`:9180/ca/rest/certs/search >> [...] >> < HTTP/1.1 404 Not Found >> < Server: Apache-Coyote/1.1 >> < Content-Type: text/html >> < Content-Length: 5723 >> < Date: Sun, 28 Apr 2013 23:08:44 GMT >> [...] > > This is caused by some syntax errors in the dogtag upgrade script. They > are working on a respin. See /var/log/pki/pki-server-upgrade-*.log > > rob > When I used yum upgrade for f17?f18, the pki-server-upgrade scriptlet failed; /var/log/pki/pki-server-upgrade-10.0.2.log says: Upgrading server at Fri May 3 07:37:44 EDT 2013. Upgrading from version 10.0.0 to 10.0.1: No upgrade scriptlets. Upgrading from version 10.0.1 to 10.0.2: 1. Replace random number generator ERROR: Failed upgrading Dogtag 9 pki-ca/ca subsystem. Upgrade failed in Dogtag 9 pki-ca/ca: However, after running the script manually, everything is back to normal. The patch works fine, it just needs a changelog rebase. ACK -- Petr? From tbabej at redhat.com Fri May 3 12:35:02 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 03 May 2013 14:35:02 +0200 Subject: [Freeipa-devel] [PATCH 0152] Replace TTL values > 2^31-1 with 0. In-Reply-To: <517FCAF5.70103@redhat.com> References: <517FCAF5.70103@redhat.com> Message-ID: <5183AEF6.9090702@redhat.com> On 04/30/2013 03:45 PM, Petr Spacek wrote: > Hello, > > Replace TTL values > 2^31-1 with 0. > > The rule comes from RFC 2181 section 8. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/117 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works fine. Just one question though, the patch as it is leaves the invalid TTL value in the tree, even though it is never interpreted as one (thanks to this patch). $ ipa dnsrecord-show ipa.example.com skuska --all dn: idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com Record name: skuska Time to live: 2147483648 A record: 192.168.0.1 objectclass: top, idnsrecord from /var/log/messages: named[18275]: entry 'idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com': entry TTL 2147483648 > MAXTTL, setting TTL to 0 Wouldn't that be confusing to the user? Shouldn't we fix the TTL value set in the entry as well? Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri May 3 12:37:46 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 03 May 2013 08:37:46 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <51832106.5000800@redhat.com> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <5182E15E.5010601@redhat.com> <1367532757.2976.141.camel@willson.li.ssimo.org> <51832106.5000800@redhat.com> Message-ID: <1367584666.2976.151.camel@willson.li.ssimo.org> On Thu, 2013-05-02 at 22:29 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2013-05-02 at 17:57 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Thu, 2013-05-02 at 15:24 -0400, Nathaniel McCallum wrote: > >>>> On Thu, 2013-05-02 at 12:18 -0400, Nathaniel McCallum wrote: > >>>>> Attached are the patches from the ongoing OTP review with rcrit. We > >>>>> believe these to be ready to merge. Please review. The first two patches > >>>>> just add the required schema. The third patch adds support for OTP to > >>>>> kdb. The fourth adds ipa-otpd, the otp companion daemon. The fifth, adds > >>>>> the 389DS bind plugin. The sixth patch is cosmetic (.gitignore). > >>>>> > >>>>> Code for managing tokens (CLI or GUI) remains to be written, though I do > >>>>> have a rudimentary script for adding tokens for testing. > >>>>> > >>>>> KNOWN ISSUES > >>>>> 1. ipa-otpd runs as root. This trade-off exists to permit autobinding > >>>>> for this PoC. Ideally, ipa-otpd would run as its own unprivileged user. > >>>>> I'd like to address this for the N+1 release. > >>>>> 2. krb5 currently requires the top three patches here in order to > >>>>> properly trigger the otp code path: > >>>>> https://github.com/greghudson/krb5/commits/keycheck. These should > >>>>> hopefully be merged upstream soon and will be backported to krb5 1.11 in > >>>>> Fedora 19 shortly. > >>>>> 3. krb5 tickets can't be issued. This is due to an upstream ticket > >>>>> issuance bug that was discovered on Monday. This occurs *after* the OTP > >>>>> has already been validated. We are working on a fix for this. > >>>> > >>>> rcrit noticed that I wasn't using pkgconfig in patch #5, which I fixed. > >>>> He also merged patch #6. Attached are the five remaining patches. > >>>> > >>>> Nathaniel > >>> > >>> > >>> Will do one patch at a time as these are huge. > >>> > >>> I think you should have separate mail threads per patch so that each can > >>> be independently tracked in patchwork. > >>> These patches are so huge I am going to have to write separate mails for > >>> each anyway. > >>> > >>> > >>> > >>> > >>> Patch 1 NACK: > >>> > >>> - I see GPLv2 boiler plate, but we should use v3. > >>> > >>> - Bad indentation with 2 spaces indent in several places. > >>> > >>> - not required, but I find much better to use braces around single line > >>> ifs, not only for pure stylistic reasons but for defensive programming, > >>> it's very common to make mistakes later when modifying existing code and > >>> forget to add braces when adding lines to the if statement. > >>> > >>> - we do not do a new line after a the return type when declaring > >>> functions. > >>> > >>> Not ok: > >>> int > >>> fn_name() > >>> { > >>> > >>> ok: > >>> int fn_name() > >>> { > >>> > >>> - Constructs like the following are not good: > >>> > >>> if (slapi_entry_attr_find(e, type, &attr) != 0 || !attr) > >>> > >>> Makes debugging hard and reading hard. It should be: > >>> > >>> ret = slapi_entry_attr_find(e, type, &attr); > >>> if (ret != 0 || attr) { > >>> do something; > >>> } > >>> > >>> In general it is not ok to call a function and test its value within an > >>> if statement except for trivial ones that return booleans. > >>> always: > >>> ret = fn() > >>> if (ret == ?) { } > >>> > >>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > >>> (although I know slapi_ch_malloc() currently just aborts on failure, I > >>> think that is plain wrong which is why I would prefer using > >>> malloc/strdup, but well, I guess this is not something I am going to > >>> care too much about for now). > >>> > >>> - Please do not use if (1) { ... } constructs, it makes no sense, simply > >>> remove the if statement and leave the contents. > >>> > >>> - Please if you can use 'done' as a label to get out of a function > >>> > >>> - token_decode(), credentials_parse() and ipa_otp_do_otp_auth() are > >>> effectively returning a boolean state, please make them return bool and > >>> true for success, false for failure. > >>> (ps: I see this all over, please use bool everywhere you return > >>> effectively a boolean state, not going to point out every single > >>> function from now on) > >>> > >>> - indentation issues at lines 524 and 527 of the patch, both case should > >>> align after the previous line '(' > >>> > >>> - another bad testing pattern: > >>> do not do things like: > >>> ret = foo() == 0 > >>> if (ret) { ... } > >>> > >>> do: > >>> > >>> ret = fn() > >>> if (ret == 0) { ... } > >>> > >>> > >>> > >>> - Using a single ipa_otp_postop() function instead of one function per > >>> operation makes things less clear, as you have to create the boilerplate > >>> for each function seaprately anyway and then most of the function is in > >>> the switch case statements which are completely separate. The only > >>> common code is the initial checks that you have already split off in > >>> _stared()/_oktodo() functions anyway. > >>> Having separate function per operation would be preferable I think. > >>> > >>> - bad indentation line 1054,1055,1065,1074,1092 and so on ... they > >>> should be indented after the preceding line(s) '(' > >>> Also this is often the case with slapi_log_error() functions too, please > >>> indent after the opening '(' on previous lines, not at a random > >>> indentation. > >>> > >>> > >>> - Is the logic with auth_type_used correct ? > >>> At least the name of the variable sounds misleading, because you set it > >>> only if the authentication was successful but not set if it was 'used' > >>> but was unsuccessful. Made me look at it multiple times to reconstuct > >>> the logic. The var name could be better, however I also want a comment > >>> that explain exactly how we are going to manage authentication and > >>> fallbacks here as that logic is critical and is useful for anyone that > >>> is going to have to change this code later in order not to break it. > >>> > >>> > >>> - What about the comments labeled NGK ? Some of them seem to indicate > >>> the plugin still has some deficiencies we should fix ? If so they should > >>> use the label FIXME so that it gets readily highlighetd when looking at > >>> the code. > >>> > >>> > >>> - General question: how does this PRE_BIND plugin interact with > >>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > >>> Are you going to cause that plugin not to run by returning a result > >>> directly in this function ? > >>> Or is this plugin configured to run only after the previous one went > >>> through ? > >>> I ask because I do not see any ordering information in the cn=config > >>> plugin configuration so it is not immediately clear to me. > >>> > >>> > >>> Continuing with otp.c: > >>> > >>> - what does 'egress' mean ? > >>> (can you just use 'done' as a standard label for exceptions ?) > >>> > >>> - Is it ok to call PK11_DestroyContext() if ctx is NULL ? > >>> Can't find much documentation but see #276314 / #276311 on > >>> bugzilla.mozilla.org > >>> > >>> > >>> - Can you please add a comment that describe which HMAC algorithm are > >>> you using (or a reference to a RFC of it ?) Unfortunately NSS makes > >>> thins a lot more cryptic than it should :( > >>> Also adding comments before the various NSS invocation to explain what > >>> they do would help, this code is obscure. > >>> > >>> > >>> - Why do we have ipa_otp_hotp if we implement only totp ? > >>> > >>> > >>> > >>> In general the code seem ok functionally, but the style must be fixed. > >>> > >>> In general please read http://www.freeipa.org/page/Coding_Style and > >>> conform to the style used in other plugins where they do not explicitly > >>> contradict the above document for uniformity. > >> > >> Simo, I've done an initial review of these and give them an ACK. If > >> you'd like to take a second look it'd be great. At this point though I'm > >> not sure I want to break this out into separate e-mails. I don't want > >> process to get in the way of progress. > > > > The second patch is big, I need more time to look at it. > > > > 3 and 5 look ok to me. > > > > On 4: > > - I would have called the file otp-aci.ldif (we have default-aci.ldif) > > not just otp.ldif > > I named it that because I snuck in the container as well. If the file is > renamed we should really break that part out. > > > - I really do not like the deny acis that much. > > We may need to fix this with the post 3.2 ticket to handle allows > > differently. The problem is that adding denies here will make that work > > more difficult and is also tricky top get right, see below: > > > > - Is it right to deny all ipatokenRadiusConfigLink, > > ipatokenRadiusUserName for reading ? > > If nobody can access this information what do we store it for ? > > IIRC deny-first wins and the following allow will simply be ignored ? > > 9.7.2.2 of RHDS manual seem to confirm this. > > > > Same comment with the rest of the ACIs whic I see follow the same > > pattern. > > > > Make sure to tyest with a user that is not cn=Directory Manager > > I've tested them all with real data with the exception of the Radius > acis, but since they follow the same pattern it should be ok. No user > can read any attribute but ipaUserAuthType, and only a member of the > admins group can write it. > > We are limited because we have a blanket read-all aci, so I had to go in > and remove read access for each, then grant it back to admins. We will > add in delegatable permissions in the future. > > This code is testable against 389-ds as-is. I was able to create a user, > configure it for OTP, create a token, add it to my Android phone, and > use that to do a simple bind against 389-ds. The ones I pointed out are all radius related and according to documentation if you deny all first a following allow would simply be ignored, so I am confused that it works. So I went ahead and test a rule just like the ones in the otp.ldif file on my ipa server, and admin cannot access denied attributes as long as the deny rule is there as it takes precedence. So I think it's a NACK. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri May 3 12:55:56 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 03 May 2013 14:55:56 +0200 Subject: [Freeipa-devel] [PATCH 0152] Replace TTL values > 2^31-1 with 0. In-Reply-To: <5183AEF6.9090702@redhat.com> References: <517FCAF5.70103@redhat.com> <5183AEF6.9090702@redhat.com> Message-ID: <5183B3DC.7070700@redhat.com> On 3.5.2013 14:35, Tomas Babej wrote: > On 04/30/2013 03:45 PM, Petr Spacek wrote: >> Hello, >> >> Replace TTL values > 2^31-1 with 0. >> >> The rule comes from RFC 2181 section 8. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/117 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK, works fine. > > Just one question though, the patch as it is leaves the invalid TTL value in > the tree, > even though it is never interpreted as one (thanks to this patch). > > $ ipa dnsrecord-show ipa.example.com skuska --all > dn: idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com > Record name: skuska > Time to live: 2147483648 > A record: 192.168.0.1 > objectclass: top, idnsrecord > > from /var/log/messages: > named[18275]: entry > 'idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com': > entry TTL 2147483648 > MAXTTL, setting TTL to 0 > > Wouldn't that be confusing to the user? Shouldn't we fix the TTL value set in > the entry as well? It is exactly what "original" BIND does. I would like to imitate the same behaviour if you are not against it strongly. I think that: 1) Somebody could use bind-dyndb-ldap with read-only access to LDAP. 2) It will unnecessarily complicate the code. -- Petr^2 Spacek From simo at redhat.com Fri May 3 12:58:34 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 03 May 2013 08:58:34 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367558865.29881.35.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> Message-ID: <1367585914.2976.157.camel@willson.li.ssimo.org> On Fri, 2013-05-03 at 01:27 -0400, Nathaniel McCallum wrote: > All issues fixed unless noted below... The attached patches are tested > to work. > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > > > - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > > (although I know slapi_ch_malloc() currently just aborts on failure, I > > think that is plain wrong which is why I would prefer using > > malloc/strdup, but well, I guess this is not something I am going to > > care too much about for now). > > Not fixed. > > > - Is the logic with auth_type_used correct ? > > At least the name of the variable sounds misleading, because you set it > > only if the authentication was successful but not set if it was 'used' > > but was unsuccessful. Made me look at it multiple times to reconstuct > > the logic. The var name could be better, however I also want a comment > > that explain exactly how we are going to manage authentication and > > fallbacks here as that logic is critical and is useful for anyone that > > is going to have to change this code later in order not to break it. > > The variable is now gone. I re-factored the section to make the logic > clearer and put a nice big comment up top. > > > - General question: how does this PRE_BIND plugin interact with > > ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > > Are you going to cause that plugin not to run by returning a result > > directly in this function ? > > Or is this plugin configured to run only after the previous one went > > through ? > > I ask because I do not see any ordering information in the cn=config > > plugin configuration so it is not immediately clear to me. > > That is a good question for Nathan since he wrote this part of the > code... > > > Continuing with otp.c: > > > > - what does 'egress' mean ? > > (can you just use 'done' as a standard label for exceptions ?) > > Egress: > Noun - The action of going out of or leaving a place: "direct means of > access and egress". > Verb - Go out of or leave (a place). > > In short: ingress means to enter and egress means to exit. > > I have changed all 'egress' labels to 'done'. > > > - Is it ok to call PK11_DestroyContext() if ctx is NULL ? > > Can't find much documentation but see #276314 / #276311 on > > bugzilla.mozilla.org > > I added if's for all of these just to be defensive. > > > - Can you please add a comment that describe which HMAC algorithm are > > you using (or a reference to a RFC of it ?) Unfortunately NSS makes > > thins a lot more cryptic than it should :( > > Also adding comments before the various NSS invocation to explain what > > they do would help, this code is obscure. > > Unfortunately, that codes is mostly copy/paste from an NSS example of > how to do HMAC. It is just as unclear to me as it is to you. I have > added a link to the example with a note about me not understanding how > it works... > > The good news is that it passes all the unit tests which use values > defined in the RFC. Also, valgrind reports no leaks or other errors. So > even if I don't know *how* it works, I do know that it does, in fact, > work. Ok I took a deper look and now understand what it is doing. I think it is implementing RFC 6234 HMAC, but can't say for sure. The first NSS call creates a key container, the second initializes the context and tells NSS which HMAC algorythm to use and what is the key. Then the 3 calls simply (1) start the hmac calculation, (2) add in the data to be signed and (3) extracts the final signature on the data to be returned. > > - Why do we have ipa_otp_hotp if we implement only totp ? > > TOTP is a specialized case of HOTP. It is simply an alternative > mechanism for calculating the counter input to HOTP. Note that > ipa_otp_totp() is basically a one-liner. Since you *have* to implement > HOTP to get TOTP, you might as well expose the HOTP implementation for > future use. Yeah I've seen that, looks a bit weird but makes perfect sense. I do not have any more concerns on patch 1, so it's an ACK from me for that one. I haven't yet gone through the whole companion daemon patch :/ The otp ACIs one I think is wrong though, so still no full ack on the whole patchset. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Fri May 3 13:03:25 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 03 May 2013 15:03:25 +0200 Subject: [Freeipa-devel] [PATCH] 133 Fix creation of reverse records for IPA masters during install Message-ID: <5183B59D.9040500@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-133-Fix-creation-of-reverse-records-for-IPA-masters-duri.patch Type: text/x-patch Size: 937 bytes Desc: not available URL: From tbabej at redhat.com Fri May 3 13:04:26 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 03 May 2013 15:04:26 +0200 Subject: [Freeipa-devel] [PATCH 0152] Replace TTL values > 2^31-1 with 0. In-Reply-To: <5183B3DC.7070700@redhat.com> References: <517FCAF5.70103@redhat.com> <5183AEF6.9090702@redhat.com> <5183B3DC.7070700@redhat.com> Message-ID: <5183B5DA.5010407@redhat.com> On 05/03/2013 02:55 PM, Petr Spacek wrote: > On 3.5.2013 14:35, Tomas Babej wrote: >> On 04/30/2013 03:45 PM, Petr Spacek wrote: >>> Hello, >>> >>> Replace TTL values > 2^31-1 with 0. >>> >>> The rule comes from RFC 2181 section 8. >>> >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/117 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> ACK, works fine. >> >> Just one question though, the patch as it is leaves the invalid TTL >> value in >> the tree, >> even though it is never interpreted as one (thanks to this patch). >> >> $ ipa dnsrecord-show ipa.example.com skuska --all >> dn: >> idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com >> Record name: skuska >> Time to live: 2147483648 >> A record: 192.168.0.1 >> objectclass: top, idnsrecord >> >> from /var/log/messages: >> named[18275]: entry >> 'idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com': >> >> entry TTL 2147483648 > MAXTTL, setting TTL to 0 >> >> Wouldn't that be confusing to the user? Shouldn't we fix the TTL >> value set in >> the entry as well? > > It is exactly what "original" BIND does. I would like to imitate the > same behaviour if you are not against it strongly. > > I think that: > 1) Somebody could use bind-dyndb-ldap with read-only access to LDAP. > 2) It will unnecessarily complicate the code. > I'm not strongly against it, just opening a discussion. I agree that this is probably a path of the least surprise if it imitates BIND behaviour. Read-only access is a reasonable argument as well. Have my confirmed ACK then, thanks for the clarification. Tomas From simo at redhat.com Fri May 3 13:08:39 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 03 May 2013 09:08:39 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <51835B9A.30201@redhat.com> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> Message-ID: <1367586519.2976.165.camel@willson.li.ssimo.org> On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: > On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: > > All issues fixed unless noted below... The attached patches are tested > > to work. > > > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > > > >> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > >> (although I know slapi_ch_malloc() currently just aborts on failure, I > >> think that is plain wrong which is why I would prefer using > >> malloc/strdup, but well, I guess this is not something I am going to > >> care too much about for now). > > Not fixed. > > > >> - Is the logic with auth_type_used correct ? > >> At least the name of the variable sounds misleading, because you set it > >> only if the authentication was successful but not set if it was 'used' > >> but was unsuccessful. Made me look at it multiple times to reconstuct > >> the logic. The var name could be better, however I also want a comment > >> that explain exactly how we are going to manage authentication and > >> fallbacks here as that logic is critical and is useful for anyone that > >> is going to have to change this code later in order not to break it. > > The variable is now gone. I re-factored the section to make the logic > > clearer and put a nice big comment up top. > > > >> - General question: how does this PRE_BIND plugin interact with > >> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > >> Are you going to cause that plugin not to run by returning a result > >> directly in this function ? > >> Or is this plugin configured to run only after the previous one went > >> through ? > >> I ask because I do not see any ordering information in the cn=config > >> plugin configuration so it is not immediately clear to me. > > That is a good question for Nathan since he wrote this part of the > > code... > We would need to set the precedence if you want a predictable/guaranteed > execution order. If a pre-BIND plug-in callback returns non-zero (which > you should do when the plug-in sends the result to the client directly), > it will cause other pre-bind plug-ins to not be called. This is > actually how all pre-op plug-ins work. If a pre-op callback returns an > error, we don't call the rest of the pre-op plug-ins in the list. Ok, but this does not answer my question. We definitely need to *always* run our other preop plugin as we do sanity checks like verifying if the user is enabled/disabled etc... Also we need to understand how to deal with migrating password auth when OTP is enabeld. TBH I think we should not have a separate OTP-auth plugin but we should probably have a single plugin that handles authentication and the 2 should be merged. Keeping them separate is going to cause more harm than good with unexpected interactions. We could still have 2 plugins and simply move the prebind action currently don in ipa-pwd-extop to the otp plugin by making some more code common. But it is probably easier to just merge OTP into ipa-pwd-extop right now than try to do a huge refactoring. We can always refactor the ipa-pwd-extop plugin later. > >> Continuing with otp.c: > >> > >> - what does 'egress' mean ? > >> (can you just use 'done' as a standard label for exceptions ?) > > Egress: > > Noun - The action of going out of or leaving a place: "direct means of > > access and egress". > > Verb - Go out of or leave (a place). > > > > In short: ingress means to enter and egress means to exit. > > > > I have changed all 'egress' labels to 'done'. > > > >> - Is it ok to call PK11_DestroyContext() if ctx is NULL ? > >> Can't find much documentation but see #276314 / #276311 on > >> bugzilla.mozilla.org > > I added if's for all of these just to be defensive. > > > >> - Can you please add a comment that describe which HMAC algorithm are > >> you using (or a reference to a RFC of it ?) Unfortunately NSS makes > >> thins a lot more cryptic than it should :( > >> Also adding comments before the various NSS invocation to explain what > >> they do would help, this code is obscure. > > Unfortunately, that codes is mostly copy/paste from an NSS example of > > how to do HMAC. It is just as unclear to me as it is to you. I have > > added a link to the example with a note about me not understanding how > > it works... > We should have Bob Relyea (cc'd) from the NSS development team take a > look at it. I took a second stab afresh this morning and grokked it. No more concerns from me. NSS'a API does look *very* ugly... Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Fri May 3 13:14:01 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 03 May 2013 15:14:01 +0200 Subject: [Freeipa-devel] [PATCH 0151] Disallow all zone transfers/queries if transfer/query policy configuration failed In-Reply-To: <5171201E.9030502@redhat.com> References: <5171201E.9030502@redhat.com> Message-ID: <5183B819.5060108@redhat.com> On 04/19/2013 12:44 PM, Petr Spacek wrote: > Hello, > > Disallow all zone transfers/queries if transfer/query policy > configuration failed. > > Without this patch the old policy stays in effect > if re-configuration with the new policy failed. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/116 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri May 3 13:23:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 May 2013 15:23:30 +0200 Subject: [Freeipa-devel] [PATCH] 133 Fix creation of reverse records for IPA masters during install In-Reply-To: <5183B59D.9040500@redhat.com> References: <5183B59D.9040500@redhat.com> Message-ID: <5183BA52.1090107@redhat.com> On 05/03/2013 03:03 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > This would fix the behavior, yes. But I think that it would be even better to fix add_ptr_rr function to avoid unconditionally adding trailing dot to fqdn: def add_ptr_rr(zone, ip_address, fqdn, dns_backup=None): name = get_reverse_record_name(zone, ip_address) add_rr(zone, name, "PTR", fqdn+".", dns_backup) Otherwise we may get hit by this issue next time if we normalize fqdn before passing it to add_ptr_rr. add_ns_rr already does this check: def add_ns_rr(zone, hostname, dns_backup=None, force=True): if not hostname.endswith('.'): hostname += '.' Martin From nmccallu at redhat.com Wed May 1 13:33:45 2013 From: nmccallu at redhat.com (Nathaniel McCallum) Date: Wed, 1 May 2013 09:33:45 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1367358393.29302.4.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> <1366292936.17909.3.camel@localhost.localdomain> <517B0017.8070209@redhat.com> <1367358393.29302.4.camel@localhost.localdomain> Message-ID: <2130523844.4679904.1367415225107.JavaMail.root@redhat.com> Below is my first stab at ACLs. They don't actually work right, but I'm not sure what I've done wrong. The basic gist is that nobody gets any permissions by default. Admins get full permissions and users get limited permissions for their own tokens. Any help would be appreciated. Nathaniel dn: $SUFFIX changetype: modify add: aci aci: (targetattrs = "ipatokenRadiusConfigLink || ipatokenRadiusUserName")(version 3.0; acl "RADIUS user configuration is priviledged"; deny (all) userdn = "ldap:///all";) aci: (targetattrs = "ipatokenRadiusConfigLink || ipatokenRadiusUserName")(version 3.0; acl "Admins can manage RADIUS user configuration"; allow (all) groupdn="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) aci: (targetfilter = "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; acl "RADIUS configuration is priviledged"; deny (all) userdn = "ldap:///all";) aci: (targetfilter = "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; acl "Admins can manage RADIUS configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version 3.0; acl "Token configuration is priviledged"; deny (all) userdn = "ldap:///all";) aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version 3.0; acl "Admins can manage token configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can read/add basic token info"; allow (read, add, search, compare) userattr = "ipatokenOwner#USERDN";) aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "*")(version 3.0; acl "TOTP Token configuration is priviledged"; deny (all) userdn = "ldap:///all";) aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "*")(version 3.0; acl "Admins can manage TOTP token configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep")(version 3.0; acl "Users can add TOTP token secrets"; allow (add, search) userattr = "ipatokenOwner#USERDN";) - ----- Original Message ----- From: "Nathaniel McCallum" To: "Rob Crittenden" Cc: freeipa-devel at redhat.com Sent: Tuesday, April 30, 2013 5:46:33 PM Subject: Re: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS On Fri, 2013-04-26 at 18:30 -0400, Rob Crittenden wrote: > Nathaniel McCallum wrote: > > On Fri, 2013-04-12 at 17:39 -0400, Nathaniel McCallum wrote: > >> On Fri, 2013-04-12 at 11:53 -0400, Nathaniel McCallum wrote: > >>> On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: > >>>> On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: > >>>>> Nathaniel McCallum wrote: > >>>>>> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > >>>>>>> I'm not sure how I'd test it if I got it built. > >>>>>> > >>>>>> I'm working on this. I hope to have a clear answer next week. Bear with > >>>>>> me... > >>>>>> > >>>>>>> Overall looks really good. > >>>>>> > >>>>>> I've split up the patch into multiple commits. I've also added .update > >>>>>> files and a patch for ipa-kdb to feed krb5 the right user string. > >>>>>> > >>>>>> https://github.com/npmccallum/freeipa/commits/otp > >>>>>> > >>>>>> Please take a look. I *think* I've got everything worked out so far with > >>>>>> the exception of bug numbers / urls. Should every patch have a separate > >>>>>> bug and a link to the design page? > >>>>> > >>>>> The ticket should go into every commit. I'd probably put the design link > >>>>> there too, just for completeness. Future bug fixes, et all aren't going > >>>>> to require the design page, but since these commits are all related to > >>>>> the initial feature it will be nice to have. > >>>>> > >>>>> You can have multiple patches on the same ticket/bug. > >>>> > >>>> https://github.com/npmccallum/freeipa/commits/otp > >>>> > >>>> All four commits now have bug numbers and design page links. I'm adding > >>>> the design page link to the tickets as we speak. > >>>> > >>>> Remaining issues (AFAICS): > >>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously > >>>> 2. ipatokenRadiusSecret is readable by an anonymous bind > >>> 3. ipatokenT?OTP.* are readable by an anonymous bind > >>> > >>> In the case of both #2 and #3, only admins should have RW. ipa-otpd > >>> needs read access to ipatokenRadiusSecret. The DS bind plugin below (#2) > >>> needs read access to ipatokenT?OTP.*. > >>> > >>>> Outstanding pieces: > >>>> 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 > >>>> 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 > >>>> 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 > >>>> 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 > >>>> > >>>> #1 and #2 are within the scope of F19 and should hopefully land shortly > >>>> (in separate commits). #3 and #4 are probably $nextrelease. > >>>> > >> > >> FYI - Here is an RPM with all of the code so far: > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=5247029 > > > > Updated RPMs, containing the new 389DS bind plugin and build for F19, > > are here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5270926 > > > > Nathaniel > > BuildRequires needed for whatever provides krad.h It is there already. I updated the spec file to have a hard dependency on krb5 >= 1.11. > A bunch of the files declare functions in each other. Is it cleaner to > put these into an include file? I'm gathering that this will always be > self-contained, so maybe this is ok. Most of the functions are only needed in one other file. I thought this was cleaner. I'm also open to suggestions on how to better split the files so there are less includes... > In entry_attr_get_berval() is it worth pointing out that there is no > need to free the value, or is that assumed because it uses > slapi_value_get_berval()? I would hope it is assumed by const. > If we detect that there is clock drift should we log it? Will we ever > try to report to the client (e.g. future enhancement)? There are lots of clock related enhancements that should be low-hanging fruit. > I wonder if the NSPR-version of some functions should be used since this > is running inside 389-ds, like PL_strcasecmp for strcasecmp() I did not fix this since strcasecmp() is available everywhere. > ops.c: > > pedantic: lack of spacing between if and parens Fixed. > sha384 is an allowed type only in otp.c. Is that needed? The RFC doesn't specify sha384 support. However, adding support for it is somewhat obvious. In the spirit of "being liberal in what you receive, strict in what you send" I added sha384 support in auth.c. Nathaniel _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel From thozza at redhat.com Fri May 3 13:19:18 2013 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 3 May 2013 09:19:18 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0152] Replace TTL values > 2^31-1 with 0. In-Reply-To: <5183B3DC.7070700@redhat.com> References: <517FCAF5.70103@redhat.com> <5183AEF6.9090702@redhat.com> <5183B3DC.7070700@redhat.com> Message-ID: <1756366503.3917102.1367587158522.JavaMail.root@redhat.com> ----- Original Message ----- > On 3.5.2013 14:35, Tomas Babej wrote: > > On 04/30/2013 03:45 PM, Petr Spacek wrote: > >> Hello, > >> > >> Replace TTL values > 2^31-1 with 0. > >> > >> The rule comes from RFC 2181 section 8. > >> > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/117 > >> > >> > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > ACK, works fine. > > > > Just one question though, the patch as it is leaves the invalid TTL value > > in > > the tree, > > even though it is never interpreted as one (thanks to this patch). > > > > $ ipa dnsrecord-show ipa.example.com skuska --all > > dn: > > idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com > > Record name: skuska > > Time to live: 2147483648 > > A record: 192.168.0.1 > > objectclass: top, idnsrecord > > > > from /var/log/messages: > > named[18275]: entry > > 'idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com': > > entry TTL 2147483648 > MAXTTL, setting TTL to 0 > > > > Wouldn't that be confusing to the user? Shouldn't we fix the TTL value set > > in > > the entry as well? > > It is exactly what "original" BIND does. I would like to imitate the same > behaviour if you are not against it strongly. > > I think that: > 1) Somebody could use bind-dyndb-ldap with read-only access to LDAP. > 2) It will unnecessarily complicate the code. > > -- > Petr^2 Spacek Review ACK. The patch looks good. I also agree with Peter's reasoning. There is also an error logged when the TTL has MSB set, so one can notice there is a bad TTL value set in LDAP. Regards, Tomas Hozza From pviktori at redhat.com Fri May 3 13:30:49 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 03 May 2013 15:30:49 +0200 Subject: [Freeipa-devel] [PATCH] 133 Fix creation of reverse records for IPA masters during install In-Reply-To: <5183B59D.9040500@redhat.com> References: <5183B59D.9040500@redhat.com> Message-ID: <5183BC09.2020801@redhat.com> On 05/03/2013 03:03 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > The patch fixes this particular problem, so ACK, but it'll be easy to make the mistake again. I think that add_ptr_rr should call normalize_zone instead of always adding the dot, or it should assert that fqdn doesn't end with a dot. Maybe we should wait for the next release with that change, though. -- Petr? From jcholast at redhat.com Fri May 3 13:34:38 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 03 May 2013 15:34:38 +0200 Subject: [Freeipa-devel] [PATCH] 133 Fix creation of reverse records for IPA masters during install In-Reply-To: <5183BA52.1090107@redhat.com> References: <5183B59D.9040500@redhat.com> <5183BA52.1090107@redhat.com> Message-ID: <5183BCEE.9060105@redhat.com> On 3.5.2013 15:23, Martin Kosek wrote: > On 05/03/2013 03:03 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> > > This would fix the behavior, yes. But I think that it would be even better to > fix add_ptr_rr function to avoid unconditionally adding trailing dot to fqdn: > > def add_ptr_rr(zone, ip_address, fqdn, dns_backup=None): > name = get_reverse_record_name(zone, ip_address) > add_rr(zone, name, "PTR", fqdn+".", dns_backup) > > Otherwise we may get hit by this issue next time if we normalize fqdn before > passing it to add_ptr_rr. add_ns_rr already does this check: > > def add_ns_rr(zone, hostname, dns_backup=None, force=True): > if not hostname.endswith('.'): > hostname += '.' > > > Martin > I don't see a point in doing this now. There are many occurences of uncoditional fqdn+'.' in the code and the proper fix would be to get rid of them all. I think this could be done in the scope of . Honza -- Jan Cholasta From mkosek at redhat.com Fri May 3 13:38:13 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 May 2013 15:38:13 +0200 Subject: [Freeipa-devel] [PATCH] 133 Fix creation of reverse records for IPA masters during install In-Reply-To: <5183BCEE.9060105@redhat.com> References: <5183B59D.9040500@redhat.com> <5183BA52.1090107@redhat.com> <5183BCEE.9060105@redhat.com> Message-ID: <5183BDC5.1050602@redhat.com> On 05/03/2013 03:34 PM, Jan Cholasta wrote: > On 3.5.2013 15:23, Martin Kosek wrote: >> On 05/03/2013 03:03 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >> >> This would fix the behavior, yes. But I think that it would be even better to >> fix add_ptr_rr function to avoid unconditionally adding trailing dot to fqdn: >> >> def add_ptr_rr(zone, ip_address, fqdn, dns_backup=None): >> name = get_reverse_record_name(zone, ip_address) >> add_rr(zone, name, "PTR", fqdn+".", dns_backup) >> >> Otherwise we may get hit by this issue next time if we normalize fqdn before >> passing it to add_ptr_rr. add_ns_rr already does this check: >> >> def add_ns_rr(zone, hostname, dns_backup=None, force=True): >> if not hostname.endswith('.'): >> hostname += '.' >> >> >> Martin >> > > I don't see a point in doing this now. There are many occurences of > uncoditional fqdn+'.' in the code and the proper fix would be to get rid of > them all. I think this could be done in the scope of > . > > Honza > I would not want to wait until then - this ticket won't be done in near future. Can you please just replace fqdn+"." and fqdn+'.' in bindinstance.py with normalize_zone(fqdn) for now? I saw about 8 occurrences there. This could fix a lot of potential errors we have now. Thanks, Martin From pvoborni at redhat.com Fri May 3 13:38:19 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 May 2013 15:38:19 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <517FFD07.3010607@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <51795BE6.9090405@redhat.com> <517A5C3C.4010005@redhat.com> <517A8FF2.6090107@redhat.com> <517AA817.1080303@redhat.com> <517FFD07.3010607@redhat.com> Message-ID: <5183BDCB.5030506@redhat.com> Update: * added ticket number to every commit, some commit messages improved * ~4 commits squashed * rebased on current master On 04/30/2013 07:19 PM, Petr Vobornik wrote: > Update: > * rebased on current master an force-pushed to private repo > * fixed crash when IPA installed without CA > * fixed bugs found by automated tests > ** crash on ssh key add > ** crash on host deletion > * added design page for #3236: > http://www.freeipa.org/page/V3/WebUI_extensible_navigation > * enabled adding facets without entity into menu (untested) > > Attaching two simple example plugins. > * simpleuser: replaces selfservice page with simpler one > * usermod: moves initials field in user page > ** example of adding a field > ** example of deleting a field > ** tries Spec_mod utility which proved to not be much useful yet because > it's search is limited only to one array, which is not enough > > To test the plugins put them into: > /usr/share/ipa/ui/js/plugins/usermod > /usr/share/ipa/ui/js/plugins/simpleuser > > > On 04/26/2013 06:15 PM, Petr Vobornik wrote: >> Another problem found: trustconfig had invalid spec which made the trust >> section quite unusable. >> >> Fixed and pushed to the private repo. >> >> I also took an opportunity and added missing parts of trust metadata for >> static testing. >> >> On 04/26/2013 04:32 PM, Petr Vobornik wrote: >>> Hi, >>> >>> 1, 2 and 3a are fixed and pushed to the private repo. Rest won't be >>> fixed during the refactoring. >>> >>> I changed SingletonRegistry behavior that it returns null when >>> builder/construction spec is missing. It's more consistent with build of >>> unsupported entities (also returns null). -- Petr Vobornik From jdennis at redhat.com Fri May 3 13:49:19 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 03 May 2013 09:49:19 -0400 Subject: [Freeipa-devel] [Pki-announce] Announcing the release of Dogtag 10.0.2 In-Reply-To: <1367546969.7810.35.camel@aleeredhat.laptop> References: <1367546969.7810.35.camel@aleeredhat.laptop> Message-ID: <5183C05F.1070300@redhat.com> On 05/02/2013 10:09 PM, Ade Lee wrote: > The Dogtag team is proud to announce the second errata build for > Dogtag v10.0.0. Just wanted to say the CS team is doing great work. Thanks for all these improvements! John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Fri May 3 14:04:56 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 May 2013 16:04:56 +0200 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <2130523844.4679904.1367415225107.JavaMail.root@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> <1366292936.17909.3.camel@localhost.localdomain> <517B0017.8070209@redhat.com> <1367358393.29302.4.camel@localhost.localdomain> <2130523844.4679904.1367415225107.JavaMail.root@redhat.com> Message-ID: <5183C408.10602@redhat.com> On 05/01/2013 03:33 PM, Nathaniel McCallum wrote: > Below is my first stab at ACLs. They don't actually work right, but I'm not sure what I've done wrong. The basic gist is that nobody gets any permissions by default. Admins get full permissions and users get limited permissions for their own tokens. Any help would be appreciated. We have an ACI allowing read access to all attributes or trees that were not forbidden: aci: (target != "ldap:///idnsname=*,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=c om")(targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sam baNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaN TTrustAuthOutgoing || ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anony mous access"; allow (read, search, compare) userdn = "ldap:///anyone";) If you want to hide some attributes from regular users and only allow them to be read by admins, you need to extend targetattr list. This can be done in ipaserver/install/plugins/update_anonymous_aci.py. > > Nathaniel > > dn: $SUFFIX > changetype: modify > add: aci > aci: (targetattrs = "ipatokenRadiusConfigLink || ipatokenRadiusUserName")(version 3.0; acl "RADIUS user configuration is priviledged"; deny (all) userdn = "ldap:///all";) > aci: (targetattrs = "ipatokenRadiusConfigLink || ipatokenRadiusUserName")(version 3.0; acl "Admins can manage RADIUS user configuration"; allow (all) groupdn="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) deny rule will override the allow rule so this won't allow admins to do anything. Couldn't we just add ipatokenRadiusConfigLink and ipatokenRadiusUserName to the global ACI blacklist above? Then you could delete both ACIs. Admins read&write access is already allowed by this ACI: aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sam baNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonica lName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration | | krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPw dHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLas tSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || ipaUniqueId || memberOf || serverHostName || enrolledBy || ipaNTHash")(version 3.0; acl "Ad min can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups ,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com";) > aci: (targetfilter = "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; acl "RADIUS configuration is priviledged"; deny (all) userdn = "ldap:///all";) > aci: (targetfilter = "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; acl "Admins can manage RADIUS configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) This won't work from the reasons above. Maybe we should add (targetfilter != "(objectClass=ipatokenRadiusConfiguration)") to the global ACI? > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version 3.0; acl "Token configuration is priviledged"; deny (all) userdn = "ldap:///all";) > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version 3.0; acl "Admins can manage token configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) We would just update global ACI. > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can read/add basic token info"; allow (read, add, search, compare) userattr = "ipatokenOwner#USERDN";) Looks ok. > aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "*")(version 3.0; acl "TOTP Token configuration is priviledged"; deny (all) userdn = "ldap:///all";) > aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "*")(version 3.0; acl "Admins can manage TOTP token configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) We would just update global ACI. > aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep")(version 3.0; acl "Users can add TOTP token secrets"; allow (add, search) userattr = "ipatokenOwner#USERDN";) Looks ok. Rob, Simo - does this proposal seams reasonable? Martin > - > > ----- Original Message ----- > From: "Nathaniel McCallum" > To: "Rob Crittenden" > Cc: freeipa-devel at redhat.com > Sent: Tuesday, April 30, 2013 5:46:33 PM > Subject: Re: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS > > On Fri, 2013-04-26 at 18:30 -0400, Rob Crittenden wrote: >> Nathaniel McCallum wrote: >>> On Fri, 2013-04-12 at 17:39 -0400, Nathaniel McCallum wrote: >>>> On Fri, 2013-04-12 at 11:53 -0400, Nathaniel McCallum wrote: >>>>> On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: >>>>>> On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: >>>>>>> Nathaniel McCallum wrote: >>>>>>>> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: >>>>>>>>> I'm not sure how I'd test it if I got it built. >>>>>>>> >>>>>>>> I'm working on this. I hope to have a clear answer next week. Bear with >>>>>>>> me... >>>>>>>> >>>>>>>>> Overall looks really good. >>>>>>>> >>>>>>>> I've split up the patch into multiple commits. I've also added .update >>>>>>>> files and a patch for ipa-kdb to feed krb5 the right user string. >>>>>>>> >>>>>>>> https://github.com/npmccallum/freeipa/commits/otp >>>>>>>> >>>>>>>> Please take a look. I *think* I've got everything worked out so far with >>>>>>>> the exception of bug numbers / urls. Should every patch have a separate >>>>>>>> bug and a link to the design page? >>>>>>> >>>>>>> The ticket should go into every commit. I'd probably put the design link >>>>>>> there too, just for completeness. Future bug fixes, et all aren't going >>>>>>> to require the design page, but since these commits are all related to >>>>>>> the initial feature it will be nice to have. >>>>>>> >>>>>>> You can have multiple patches on the same ticket/bug. >>>>>> >>>>>> https://github.com/npmccallum/freeipa/commits/otp >>>>>> >>>>>> All four commits now have bug numbers and design page links. I'm adding >>>>>> the design page link to the tickets as we speak. >>>>>> >>>>>> Remaining issues (AFAICS): >>>>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously >>>>>> 2. ipatokenRadiusSecret is readable by an anonymous bind >>>>> 3. ipatokenT?OTP.* are readable by an anonymous bind >>>>> >>>>> In the case of both #2 and #3, only admins should have RW. ipa-otpd >>>>> needs read access to ipatokenRadiusSecret. The DS bind plugin below (#2) >>>>> needs read access to ipatokenT?OTP.*. >>>>> >>>>>> Outstanding pieces: >>>>>> 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 >>>>>> 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 >>>>>> 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 >>>>>> 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 >>>>>> >>>>>> #1 and #2 are within the scope of F19 and should hopefully land shortly >>>>>> (in separate commits). #3 and #4 are probably $nextrelease. >>>>>> >>>> >>>> FYI - Here is an RPM with all of the code so far: >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5247029 >>> >>> Updated RPMs, containing the new 389DS bind plugin and build for F19, >>> are here: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5270926 >>> >>> Nathaniel >> >> BuildRequires needed for whatever provides krad.h > > It is there already. I updated the spec file to have a hard dependency > on krb5 >= 1.11. > >> A bunch of the files declare functions in each other. Is it cleaner to >> put these into an include file? I'm gathering that this will always be >> self-contained, so maybe this is ok. > > Most of the functions are only needed in one other file. I thought this > was cleaner. I'm also open to suggestions on how to better split the > files so there are less includes... > >> In entry_attr_get_berval() is it worth pointing out that there is no >> need to free the value, or is that assumed because it uses >> slapi_value_get_berval()? > > I would hope it is assumed by const. > >> If we detect that there is clock drift should we log it? Will we ever >> try to report to the client (e.g. future enhancement)? > > There are lots of clock related enhancements that should be low-hanging > fruit. > >> I wonder if the NSPR-version of some functions should be used since this >> is running inside 389-ds, like PL_strcasecmp for strcasecmp() > > I did not fix this since strcasecmp() is available everywhere. > >> ops.c: >> >> pedantic: lack of spacing between if and parens > > Fixed. > >> sha384 is an allowed type only in otp.c. Is that needed? > > The RFC doesn't specify sha384 support. However, adding support for it > is somewhat obvious. In the spirit of "being liberal in what you > receive, strict in what you send" I added sha384 support in auth.c. > > Nathaniel > > _______________________________________________ > 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 > From tbabej at redhat.com Fri May 3 14:16:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 03 May 2013 16:16:52 +0200 Subject: [Freeipa-devel] [PATCH 0148] Explicitly return SERVFAIL if PTR synchronization is misconfigured. In-Reply-To: <516D2BBA.2040407@redhat.com> References: <516D2BBA.2040407@redhat.com> Message-ID: <5183C6D4.1060209@redhat.com> On 04/16/2013 12:45 PM, Petr Spacek wrote: > Hello, > > Explicitly return SERVFAIL if PTR synchronization is misconfigured. > > SERVFAIL will be returned if PTR synchronization is enabled > in forward zone but reverse zone has dynamic updates disabled. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri May 3 14:20:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 May 2013 10:20:45 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <5183C408.10602@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> <1366292936.17909.3.camel@localhost.localdomain> <517B0017.8070209@redhat.com> <1367358393.29302.4.camel@localhost.localdomain> <2130523844.4679904.1367415225107.JavaMail.root@redhat.com> <5183C408.10602@redhat.com> Message-ID: <5183C7BD.3000904@redhat.com> Martin Kosek wrote: > On 05/01/2013 03:33 PM, Nathaniel McCallum wrote: >> Below is my first stab at ACLs. They don't actually work right, but I'm not sure what I've done wrong. The basic gist is that nobody gets any permissions by default. Admins get full permissions and users get limited permissions for their own tokens. Any help would be appreciated. > > We have an ACI allowing read access to all attributes or trees that were not > forbidden: > > aci: (target != "ldap:///idnsname=*,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=c > om")(targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sam > baNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaN > TTrustAuthOutgoing || ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anony > mous access"; allow (read, search, compare) userdn = "ldap:///anyone";) > > If you want to hide some attributes from regular users and only allow them to > be read by admins, you need to extend targetattr list. This can be done in > ipaserver/install/plugins/update_anonymous_aci.py. > >> >> Nathaniel >> >> dn: $SUFFIX >> changetype: modify >> add: aci >> aci: (targetattrs = "ipatokenRadiusConfigLink || ipatokenRadiusUserName")(version 3.0; acl "RADIUS user configuration is priviledged"; deny (all) userdn = "ldap:///all";) >> aci: (targetattrs = "ipatokenRadiusConfigLink || ipatokenRadiusUserName")(version 3.0; acl "Admins can manage RADIUS user configuration"; allow (all) groupdn="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > > deny rule will override the allow rule so this won't allow admins to do > anything. Couldn't we just add ipatokenRadiusConfigLink and > ipatokenRadiusUserName to the global ACI blacklist above? Then you could delete > both ACIs. Admins read&write access is already allowed by this ACI: > > aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sam > baNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonica > lName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration | > | krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPw > dHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLas > tSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || ipaUniqueId || > memberOf || serverHostName || enrolledBy || ipaNTHash")(version 3.0; acl "Ad > min can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups > ,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com";) > >> aci: (targetfilter = "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; acl "RADIUS configuration is priviledged"; deny (all) userdn = "ldap:///all";) >> aci: (targetfilter = "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; acl "Admins can manage RADIUS configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > > This won't work from the reasons above. Maybe we should add > > (targetfilter != "(objectClass=ipatokenRadiusConfiguration)") > > to the global ACI? > >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version 3.0; acl "Token configuration is priviledged"; deny (all) userdn = "ldap:///all";) >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version 3.0; acl "Admins can manage token configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > > We would just update global ACI. > >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial")(version 3.0; acl "Users can read/add basic token info"; allow (read, add, search, compare) userattr = "ipatokenOwner#USERDN";) > > Looks ok. > >> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "*")(version 3.0; acl "TOTP Token configuration is priviledged"; deny (all) userdn = "ldap:///all";) >> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "*")(version 3.0; acl "Admins can manage TOTP token configuration"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > > We would just update global ACI. > >> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || ipatokenTOTPclockOffset || ipatokenTOTPtimeStep")(version 3.0; acl "Users can add TOTP token secrets"; allow (add, search) userattr = "ipatokenOwner#USERDN";) > > Looks ok. > > Rob, Simo - does this proposal seams reasonable? Yes, this is the direction I've been moving this morning, doing some experimentation now using targetfilter. I'l be happy if we can avoid adding all these attributes to the global ACI. rob From mkosek at redhat.com Fri May 3 14:42:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 May 2013 16:42:15 +0200 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <5183C7BD.3000904@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> <1366292936.17909.3.camel@localhost.localdomain> <517B0017.8070209@redhat.com> <1367358393.29302.4.camel@localhost.localdomain> <2130523844.4679904.1367415225107.JavaMail.root@redhat.com> <5183C408.10602@redhat.com> <5183C7BD.3000904@redhat.com> Message-ID: <5183CCC7.20502@redhat.com> On 05/03/2013 04:20 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 05/01/2013 03:33 PM, Nathaniel McCallum wrote: >>> Below is my first stab at ACLs. They don't actually work right, but I'm not >>> sure what I've done wrong. The basic gist is that nobody gets any >>> permissions by default. Admins get full permissions and users get limited >>> permissions for their own tokens. Any help would be appreciated. >> >> We have an ACI allowing read access to all attributes or trees that were not >> forbidden: >> >> aci: (target != "ldap:///idnsname=*,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=c >> om")(targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sam >> baNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaN >> TTrustAuthOutgoing || ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anony >> mous access"; allow (read, search, compare) userdn = "ldap:///anyone";) >> >> If you want to hide some attributes from regular users and only allow them to >> be read by admins, you need to extend targetattr list. This can be done in >> ipaserver/install/plugins/update_anonymous_aci.py. >> >>> >>> Nathaniel >>> >>> dn: $SUFFIX >>> changetype: modify >>> add: aci >>> aci: (targetattrs = "ipatokenRadiusConfigLink || >>> ipatokenRadiusUserName")(version 3.0; acl "RADIUS user configuration is >>> priviledged"; deny (all) userdn = "ldap:///all";) >>> aci: (targetattrs = "ipatokenRadiusConfigLink || >>> ipatokenRadiusUserName")(version 3.0; acl "Admins can manage RADIUS user >>> configuration"; allow (all) >>> groupdn="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) >> >> deny rule will override the allow rule so this won't allow admins to do >> anything. Couldn't we just add ipatokenRadiusConfigLink and >> ipatokenRadiusUserName to the global ACI blacklist above? Then you could delete >> both ACIs. Admins read&write access is already allowed by this ACI: >> >> aci: (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sam >> baNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonica >> lName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration | >> | krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPw >> dHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLas >> tSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || ipaUniqueId || >> memberOf || serverHostName || enrolledBy || ipaNTHash")(version 3.0; acl "Ad >> min can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups >> ,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com";) >> >>> aci: (targetfilter = >>> "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; >>> acl "RADIUS configuration is priviledged"; deny (all) userdn = "ldap:///all";) >>> aci: (targetfilter = >>> "(objectClass=ipatokenRadiusConfiguration)")(targetattrs = "*")(version 3.0; >>> acl "Admins can manage RADIUS configuration"; allow (all) groupdn = >>> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) >> >> This won't work from the reasons above. Maybe we should add >> >> (targetfilter != "(objectClass=ipatokenRadiusConfiguration)") >> >> to the global ACI? >> >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version >>> 3.0; acl "Token configuration is priviledged"; deny (all) userdn = >>> "ldap:///all";) >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "*")(version >>> 3.0; acl "Admins can manage token configuration"; allow (all) groupdn = >>> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) >> >> We would just update global ACI. >> >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>> "ipatokenUniqueID || description || ipatokenOwner || ipatokenNotBefore || >>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>> ipatokenSerial")(version 3.0; acl "Users can read/add basic token info"; >>> allow (read, add, search, compare) userattr = "ipatokenOwner#USERDN";) >> >> Looks ok. >> >>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>> "*")(version 3.0; acl "TOTP Token configuration is priviledged"; deny (all) >>> userdn = "ldap:///all";) >>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>> "*")(version 3.0; acl "Admins can manage TOTP token configuration"; allow >>> (all) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) >> >> We would just update global ACI. >> >>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>> "ipatokenOTPkey || ipatokenOTPalgorithm || ipatokenOTPdigits || >>> ipatokenTOTPclockOffset || ipatokenTOTPtimeStep")(version 3.0; acl "Users >>> can add TOTP token secrets"; allow (add, search) userattr = >>> "ipatokenOwner#USERDN";) >> >> Looks ok. >> >> Rob, Simo - does this proposal seams reasonable? > > Yes, this is the direction I've been moving this morning, doing some > experimentation now using targetfilter. I'l be happy if we can avoid adding all > these attributes to the global ACI. > > rob > Not sure if we can avoid it though given our current ACI allowing access to anything that is not blacklisted in it. I think that update global ACI should look like that: aci: (target != "ldap:///idnsname=*,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com")(targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipatokenRadiusConfigLink || ipatokenRadiusUserName")(targetfilter = "(&(objectClass!=ipatokenRadiusConfiguration)(objectClass!=ipaToken)(objectClass!=ipatokenTOTP))")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";) I agree this is getting awkward, in this we will need to change the ACI structure. There is already an open ticket for that: https://fedorahosted.org/freeipa/ticket/3566 Martin From jcholast at redhat.com Fri May 3 15:13:43 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 03 May 2013 17:13:43 +0200 Subject: [Freeipa-devel] [PATCH] 133 Fix creation of reverse records for IPA masters during install In-Reply-To: <5183BDC5.1050602@redhat.com> References: <5183B59D.9040500@redhat.com> <5183BA52.1090107@redhat.com> <5183BCEE.9060105@redhat.com> <5183BDC5.1050602@redhat.com> Message-ID: <5183D427.1070203@redhat.com> On 3.5.2013 15:38, Martin Kosek wrote: > On 05/03/2013 03:34 PM, Jan Cholasta wrote: >> I don't see a point in doing this now. There are many occurences of >> uncoditional fqdn+'.' in the code and the proper fix would be to get rid of >> them all. I think this could be done in the scope of >> . >> >> Honza >> > > I would not want to wait until then - this ticket won't be done in near future. Maybe it should be done in near future then. > Can you please just replace fqdn+"." and fqdn+'.' in bindinstance.py with > normalize_zone(fqdn) for now? I saw about 8 occurrences there. OK. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-133.1-Fix-normalization-of-FQDNs-in-DNS-installer-code.patch Type: text/x-patch Size: 2526 bytes Desc: not available URL: From npmccallum at redhat.com Fri May 3 16:00:10 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 03 May 2013 12:00:10 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367586519.2976.165.camel@willson.li.ssimo.org> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> Message-ID: <1367596810.29881.37.camel@localhost.localdomain> On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: > On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: > > On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: > > > All issues fixed unless noted below... The attached patches are tested > > > to work. > > > > > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > > > > > >> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > > >> (although I know slapi_ch_malloc() currently just aborts on failure, I > > >> think that is plain wrong which is why I would prefer using > > >> malloc/strdup, but well, I guess this is not something I am going to > > >> care too much about for now). > > > Not fixed. > > > > > >> - Is the logic with auth_type_used correct ? > > >> At least the name of the variable sounds misleading, because you set it > > >> only if the authentication was successful but not set if it was 'used' > > >> but was unsuccessful. Made me look at it multiple times to reconstuct > > >> the logic. The var name could be better, however I also want a comment > > >> that explain exactly how we are going to manage authentication and > > >> fallbacks here as that logic is critical and is useful for anyone that > > >> is going to have to change this code later in order not to break it. > > > The variable is now gone. I re-factored the section to make the logic > > > clearer and put a nice big comment up top. > > > > > >> - General question: how does this PRE_BIND plugin interact with > > >> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > > >> Are you going to cause that plugin not to run by returning a result > > >> directly in this function ? > > >> Or is this plugin configured to run only after the previous one went > > >> through ? > > >> I ask because I do not see any ordering information in the cn=config > > >> plugin configuration so it is not immediately clear to me. > > > That is a good question for Nathan since he wrote this part of the > > > code... > > We would need to set the precedence if you want a predictable/guaranteed > > execution order. If a pre-BIND plug-in callback returns non-zero (which > > you should do when the plug-in sends the result to the client directly), > > it will cause other pre-bind plug-ins to not be called. This is > > actually how all pre-op plug-ins work. If a pre-op callback returns an > > error, we don't call the rest of the pre-op plug-ins in the list. > > Ok, but this does not answer my question. > We definitely need to *always* run our other preop plugin as we do > sanity checks like verifying if the user is enabled/disabled etc... > Also we need to understand how to deal with migrating password auth when > OTP is enabeld. > > TBH I think we should not have a separate OTP-auth plugin but we should > probably have a single plugin that handles authentication and the 2 > should be merged. Keeping them separate is going to cause more harm than > good with unexpected interactions. > > We could still have 2 plugins and simply move the prebind action > currently don in ipa-pwd-extop to the otp plugin by making some more > code common. But it is probably easier to just merge OTP into > ipa-pwd-extop right now than try to do a huge refactoring. We can always > refactor the ipa-pwd-extop plugin later. +1. Can we do this after 3.2? This is an experimental feature after all... Nathaniel From mkosek at redhat.com Fri May 3 16:13:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 May 2013 18:13:21 +0200 Subject: [Freeipa-devel] [PATCH] 133 Fix creation of reverse records for IPA masters during install In-Reply-To: <5183D427.1070203@redhat.com> References: <5183B59D.9040500@redhat.com> <5183BA52.1090107@redhat.com> <5183BCEE.9060105@redhat.com> <5183BDC5.1050602@redhat.com> <5183D427.1070203@redhat.com> Message-ID: <5183E221.5060203@redhat.com> On 05/03/2013 05:13 PM, Jan Cholasta wrote: > On 3.5.2013 15:38, Martin Kosek wrote: >> On 05/03/2013 03:34 PM, Jan Cholasta wrote: >>> I don't see a point in doing this now. There are many occurences of >>> uncoditional fqdn+'.' in the code and the proper fix would be to get rid of >>> them all. I think this could be done in the scope of >>> . >>> >>> Honza >>> >> >> I would not want to wait until then - this ticket won't be done in near future. > > Maybe it should be done in near future then. > >> Can you please just replace fqdn+"." and fqdn+'.' in bindinstance.py with >> normalize_zone(fqdn) for now? I saw about 8 occurrences there. > > OK. > > Updated patch attached. > > Honza > ACK. Pushed to master. Martin From simo at redhat.com Fri May 3 16:14:11 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 03 May 2013 12:14:11 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367596810.29881.37.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1367596810.29881.37.camel@localhost.localdomain> Message-ID: <1367597651.2976.173.camel@willson.li.ssimo.org> On Fri, 2013-05-03 at 12:00 -0400, Nathaniel McCallum wrote: > On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: > > On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: > > > On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: > > > > All issues fixed unless noted below... The attached patches are tested > > > > to work. > > > > > > > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > > > > > > > >> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > > > >> (although I know slapi_ch_malloc() currently just aborts on failure, I > > > >> think that is plain wrong which is why I would prefer using > > > >> malloc/strdup, but well, I guess this is not something I am going to > > > >> care too much about for now). > > > > Not fixed. > > > > > > > >> - Is the logic with auth_type_used correct ? > > > >> At least the name of the variable sounds misleading, because you set it > > > >> only if the authentication was successful but not set if it was 'used' > > > >> but was unsuccessful. Made me look at it multiple times to reconstuct > > > >> the logic. The var name could be better, however I also want a comment > > > >> that explain exactly how we are going to manage authentication and > > > >> fallbacks here as that logic is critical and is useful for anyone that > > > >> is going to have to change this code later in order not to break it. > > > > The variable is now gone. I re-factored the section to make the logic > > > > clearer and put a nice big comment up top. > > > > > > > >> - General question: how does this PRE_BIND plugin interact with > > > >> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > > > >> Are you going to cause that plugin not to run by returning a result > > > >> directly in this function ? > > > >> Or is this plugin configured to run only after the previous one went > > > >> through ? > > > >> I ask because I do not see any ordering information in the cn=config > > > >> plugin configuration so it is not immediately clear to me. > > > > That is a good question for Nathan since he wrote this part of the > > > > code... > > > We would need to set the precedence if you want a predictable/guaranteed > > > execution order. If a pre-BIND plug-in callback returns non-zero (which > > > you should do when the plug-in sends the result to the client directly), > > > it will cause other pre-bind plug-ins to not be called. This is > > > actually how all pre-op plug-ins work. If a pre-op callback returns an > > > error, we don't call the rest of the pre-op plug-ins in the list. > > > > Ok, but this does not answer my question. > > We definitely need to *always* run our other preop plugin as we do > > sanity checks like verifying if the user is enabled/disabled etc... > > Also we need to understand how to deal with migrating password auth when > > OTP is enabeld. > > > > TBH I think we should not have a separate OTP-auth plugin but we should > > probably have a single plugin that handles authentication and the 2 > > should be merged. Keeping them separate is going to cause more harm than > > good with unexpected interactions. > > > > We could still have 2 plugins and simply move the prebind action > > currently don in ipa-pwd-extop to the otp plugin by making some more > > code common. But it is probably easier to just merge OTP into > > ipa-pwd-extop right now than try to do a huge refactoring. We can always > > refactor the ipa-pwd-extop plugin later. > > +1. Can we do this after 3.2? This is an experimental feature after > all... You must assure ipa-pwd-extop is always invoked in all bind cases. I am not welded on how you do it. However *merging* plugins later will be messy as you have to deal with configuration changes as the plugin .so will disappear, so I would rather do it now. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Fri May 3 17:35:50 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 03 May 2013 12:35:50 -0500 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <51756B5E.8030604@redhat.com> References: <51756B5E.8030604@redhat.com> Message-ID: <5183F576.6070109@redhat.com> Hi, Sorry for the delay, I have some questions & comments. Registry: In the simpleuser.js the new 'user' entity is registered first then the old 'user' entity is removed, which could be confusing because they are both identified using 'user'. Should register() automatically remove the old object? Ideally a class should have complete methods to manage the objects it stores (e.g. unregister(), remove()). How is reg.entity created? Are there others beside 'entity'? How is Registries_registry in reg.js used? It doesn't seem to be used anywhere else. Plugins: In plugins.py the list of plugins is generated using os.listdir(). Then each plugin also has a list of dependencies which I suppose can include other plugins. Then when registering the plugin task, it will have a priority as well. So there seem to be several factors that determine the execution order of the plugins. There should be a document explaining how this will work, so plugin writers can be sure that the code will be executed at the right time. In general I'd avoid using task priority because it doesn't guarantee the correct execution order unless the priorities of all tasks are well coordinated (which might be challenging if there are multiple plugins owned by different people). Could you add more examples of simple plugins for various scenarios including custom entity, custom facet, custom field, custom menu? They can be included in the RPM for reference. Writing a plugin seems to still require programming skills, reliance on good docs, and probably even some source code familiarity. What do you think about simplifying this a little further? So we'll have 2 ways to define a plugin: one is programatically using the current framework already implemented (e.g. simpleuser.js), and the other is completely declaratively using a plain json data (e.g. simpleuser.json). The declarative plugin will obviously be more limited, but much simpler to use. Builder: > b) Second big issue was build of objects. Entities and facets have > complex build logic. It can be simplified into three steps: > 1) modifications of spec > 2) creation of object and class inheritance > 3) init logic Yes, creating an object has become very complicated now with the builders, factories, constructors, preops, postops, inits, overrides, diff, etc. I think the problem is that we're trying to create/modify the spec before creating the object and we need a whole set of mechanisms to do that. Maybe we can simplify it into two basic steps: 1. Create an empty/simple object. 2. Initialize the object. The initialization process could be split further into smaller operations such as: * Load the spec and modify it if necessary * Creating dependent objects and initializing them * Other initialization steps The builder, factory, preops, and postops can be included as part of the initialization step. They can be normal class methods rather than loosely defined functions and can be overridden by subclasses. There's probably a lot more details that need to be discussed. > 1. Move ./_base/metadata_provider to ./metadata? > Might simplify stuff. This seems to be IPA-specific, so yes. > 2. Move actions/buttons spec from factories to pre_ops associated with > the factories. > > Example of stuff to be moved (search.js): > spec.actions = spec.actions || []; > spec.actions.unshift( > 'refresh', > 'batch_remove', > 'add'); > > It may simplify/allow removal of those items in spec or pre_ops of child > factories. Currently there is no way how to intercept them. Sure, I don't see any problem with that. In general there is no major issue that would warrant a NACK. As long as the API is well documented for plugin writers it should be sufficient. -- Endi S. Dewata From nkinder at redhat.com Fri May 3 17:55:03 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 03 May 2013 10:55:03 -0700 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367597651.2976.173.camel@willson.li.ssimo.org> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1367596810.29881.37.camel@localhost.localdomain> <1367597651.2976.173.camel@willson.li.ssimo.org> Message-ID: <5183F9F7.4080907@redhat.com> On 05/03/2013 09:14 AM, Simo Sorce wrote: > On Fri, 2013-05-03 at 12:00 -0400, Nathaniel McCallum wrote: >> On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: >>> On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: >>>> On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: >>>>> All issues fixed unless noted below... The attached patches are tested >>>>> to work. >>>>> >>>>> On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: >>>>> >>>>>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >>>>>> (although I know slapi_ch_malloc() currently just aborts on failure, I >>>>>> think that is plain wrong which is why I would prefer using >>>>>> malloc/strdup, but well, I guess this is not something I am going to >>>>>> care too much about for now). >>>>> Not fixed. >>>>> >>>>>> - Is the logic with auth_type_used correct ? >>>>>> At least the name of the variable sounds misleading, because you set it >>>>>> only if the authentication was successful but not set if it was 'used' >>>>>> but was unsuccessful. Made me look at it multiple times to reconstuct >>>>>> the logic. The var name could be better, however I also want a comment >>>>>> that explain exactly how we are going to manage authentication and >>>>>> fallbacks here as that logic is critical and is useful for anyone that >>>>>> is going to have to change this code later in order not to break it. >>>>> The variable is now gone. I re-factored the section to make the logic >>>>> clearer and put a nice big comment up top. >>>>> >>>>>> - General question: how does this PRE_BIND plugin interact with >>>>>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >>>>>> Are you going to cause that plugin not to run by returning a result >>>>>> directly in this function ? >>>>>> Or is this plugin configured to run only after the previous one went >>>>>> through ? >>>>>> I ask because I do not see any ordering information in the cn=config >>>>>> plugin configuration so it is not immediately clear to me. >>>>> That is a good question for Nathan since he wrote this part of the >>>>> code... >>>> We would need to set the precedence if you want a predictable/guaranteed >>>> execution order. If a pre-BIND plug-in callback returns non-zero (which >>>> you should do when the plug-in sends the result to the client directly), >>>> it will cause other pre-bind plug-ins to not be called. This is >>>> actually how all pre-op plug-ins work. If a pre-op callback returns an >>>> error, we don't call the rest of the pre-op plug-ins in the list. >>> Ok, but this does not answer my question. >>> We definitely need to *always* run our other preop plugin as we do >>> sanity checks like verifying if the user is enabled/disabled etc... >>> Also we need to understand how to deal with migrating password auth when >>> OTP is enabeld. >>> >>> TBH I think we should not have a separate OTP-auth plugin but we should >>> probably have a single plugin that handles authentication and the 2 >>> should be merged. Keeping them separate is going to cause more harm than >>> good with unexpected interactions. >>> >>> We could still have 2 plugins and simply move the prebind action >>> currently don in ipa-pwd-extop to the otp plugin by making some more >>> code common. But it is probably easier to just merge OTP into >>> ipa-pwd-extop right now than try to do a huge refactoring. We can always >>> refactor the ipa-pwd-extop plugin later. >> +1. Can we do this after 3.2? This is an experimental feature after >> all... > You must assure ipa-pwd-extop is always invoked in all bind cases. I am > not welded on how you do it. > However *merging* plugins later will be messy as you have to deal with > configuration changes as the plugin .so will disappear, so I would > rather do it now. I think that they must be merged together if you want things to work properly. You can set the precedence to ensure that ipa-pwd-extop always runs first, but I don't think it will work properly if one is trying to do an OTP auth. The ipa-pwd-extop pre-bind callback is responsible for creating kerberos keys based off of the supplied credentials. It will only do this if the credentials sent by the client match one of the userPassword values. With an OTP auth, this will never match since the token code is combined with the password. The ipa-pwd-extop plug-in will just return 0 and the OTP plug-in will be called and processed as normal. This is OK, but it does mean that an OTP auth will not trigger generation of new Kerberos keys. The ideal scenario would be to combind the plug-ins so that ipa-pwd-extop could recognize an OTP authentication attempt, split the supplied credentials into the password and token code, then use the extracted password to generate Kerberos keys if needed. -NGK > > Simo. > From abokovoy at redhat.com Fri May 3 18:46:47 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 3 May 2013 21:46:47 +0300 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI Message-ID: <20130503184647.GV7607@redhat.com> Hi! Attached are patches to allow resolving SIDs in Web UI in external membership panel for groups. Please see more detailed description in the main patch. I haven't rebased it yet on top of Petr's Web UI rework, hopefully it should be simple. https://fedorahosted.org/freeipa/ticket/3302 Since framework doesn't allow to hide commands from CLI, underlying command is usable from CLI too: # ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} Name: enterprise read-only domain controllers at ad.lan SID: S-1-5-21-3502988750-125904550-3683905862-498 Name: administrator at ad.lan SID: S-1-5-21-3502988750-125904550-3683905862-500 Name: domain admins at ad.lan SID: S-1-5-21-3502988750-125904550-3683905862-512 -- / Alexander Bokovoy -------------- next part -------------- >From a1cffc2ecc0bba739c3b5a5130f939a90dd0b88e Mon Sep 17 00:00:00 2001 From: Petr Vobornik Date: Wed, 24 Apr 2013 13:48:07 +0200 Subject: [PATCH 2/3] Column promise support Column setup method can handle promise. It can be supplied directly or encapsulated in a object with temporal value: { promise: promise, temp: 'temp val' } Temporal value is displayed until promise is fulfilled. --- install/ui/src/freeipa/widget.js | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js index 17d9b8b..b55900d 100644 --- a/install/ui/src/freeipa/widget.js +++ b/install/ui/src/freeipa/widget.js @@ -1388,9 +1388,6 @@ IPA.column = function (spec) { } that.setup = function(container, record, suppress_link) { - - container.empty(); - var value = record[that.name]; var type; if (that.formatter) { @@ -1398,7 +1395,34 @@ IPA.column = function (spec) { value = that.formatter.format(value); type = that.formatter.type; } + + var promise, temp = ''; + if (value && typeof value.then === 'function') promise = value; + if (value && value.promise && typeof value.promise.then === 'function') { + promise = value.promise; + temp = value.temp || ''; + } + + if (promise) { + var fulfilled = false; + promise.then(function(val) { + fulfilled = true; + that.set_value(container, val, type, suppress_link); + }); + + if (fulfilled) return; + // val obj can contain temporal value which is displayed + // until promise is fulfilled + value = temp; + } + + that.set_value(container, value, type, suppress_link); + }; + + that.set_value = function(container, value, type, suppress_link) { + value = value ? value.toString() : ''; + container.empty(); var c; if (that.link && !suppress_link) { -- 1.8.1.4 -------------- next part -------------- >From 016d3c827f5f9cdecf0d731a993fe5ad92191b59 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 3 May 2013 21:26:08 +0300 Subject: [PATCH 1/3] web-ui: fix typo in link highliting --- install/ui/ipa.css | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/install/ui/ipa.css b/install/ui/ipa.css index 3e443d5..8afcfb1 100644 --- a/install/ui/ipa.css +++ b/install/ui/ipa.css @@ -779,7 +779,7 @@ div[name=settings].facet-group li a { border: none; } -.search-table > a:link, a:visted { +.search-table > a:link, a:visited { color:black; } -- 1.8.1.4 -------------- next part -------------- >From 879d686e5cf274446cf345f24be114d23bdc4db9 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Apr 2013 13:13:25 +0300 Subject: [PATCH 3/3] Resolve SIDs in Web UI Introduce new command, 'trust-resolve', to aid resolving SIDs to names in the Web UI. The command uses new SSSD interface, nss_idmap, to resolve actual SIDs. SSSD caches resolved data so that future requests to resolve same SIDs are returned from a memory cache. Web UI code is using Dojo/Deferred to deliver result of SID resolution out of band. Once resolved names are available, they replace SID values. Since Web UI only shows ~20 records per page, up to 20 SIDs are resolved at the same time. They all sent within the single request to the server. https://fedorahosted.org/freeipa/ticket/3302 --- API.txt | 7 ++++++ freeipa.spec.in | 4 +++ install/ui/src/freeipa/association.js | 45 +++++++++++++++++++++++++++++++++- install/ui/src/freeipa/entity.js | 10 +++++++- install/ui/src/freeipa/facet.js | 12 +++++++++ install/ui/src/freeipa/group.js | 6 ++--- ipalib/plugins/trust.py | 46 +++++++++++++++++++++++++++++++++++ 7 files changed, 125 insertions(+), 5 deletions(-) diff --git a/API.txt b/API.txt index c2400e9..e5bb7be 100644 --- a/API.txt +++ b/API.txt @@ -3398,6 +3398,13 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trust_resolve +args: 0,4,1 +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('sids+', csv=True) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) command: trust_show args: 1,4,3 arg: Str('cn', attribute=True, cli_name='realm', multivalue=False, primary_key=True, query=True, required=True) diff --git a/freeipa.spec.in b/freeipa.spec.in index 36e2a61..1f97418 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -211,6 +211,7 @@ Requires: samba4 Requires: samba4-winbind %endif Requires: libsss_idmap +Requires: libsss_nss_idmap-python # We use alternatives to divert winbind_krb5_locator.so plugin to libkrb5 # on the installes where server-trust-ad subpackage is installed because # IPA AD trusts cannot be used at the same time with the locator plugin @@ -839,6 +840,9 @@ fi %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt %changelog +* Fri May 03 2013 Alexander Bokovoy - 3.1.99-10 +- Add libsss_nss_idmap-python dependency for SID resolution + * Tue Apr 30 2013 Rob Crittenden - 3.1.99-9 - Add Conflicts on nss-pam-ldapd < 0.8.4. The mapping from uniqueMember to member is now done automatically and having it in the config file raises diff --git a/install/ui/src/freeipa/association.js b/install/ui/src/freeipa/association.js index c6b9e5a..dad138f 100644 --- a/install/ui/src/freeipa/association.js +++ b/install/ui/src/freeipa/association.js @@ -22,7 +22,7 @@ /* CURRENTLY ALSO REQUIRES search.js, because it reuses it's code to create * the AssociationList elements; IT NEEDS IT'S OWN CODE! */ -define(['./ipa', './jquery', './search', './dialog'], function(IPA, $) { +define(['dojo/Deferred','./ipa', './jquery', './search', './dialog'], function(Deferred, IPA, $) { IPA.associator = function (spec) { @@ -1355,6 +1355,49 @@ IPA.attribute_facet = function(spec, no_init) { return that; }; +IPA.sid_facet = function(spec, no_init) { + + spec.name = spec.name || 'sid_facet'; + + var that = IPA.attribute_facet(spec, no_init); + + that.load_records = function(value) { + var xlate = {} + var sidxlate_command = IPA.command({ + entity: 'trust', + method: 'resolve', + options: { + sids: '', + }, + }); + sidxlate_command.on_success = function(data, text_status, xhr) { + for(var i=0; i< data.result.result.length; i++) { + var entry = data.result.result[i] + if (entry.sid[0] in xlate) { + xlate[entry.sid[0]].resolve(entry.name[0]); + } + } + }; + that.table.empty(); + + var sids = new Array(); + for(var i=0; i< value.length; i++) { + var sid = value[i][that.attribute]; + var deferred = new Deferred(); + deferred.temp = sid; + value[i][that.attribute] = deferred; + xlate[sid] = deferred; + sids.push(sid) + that.add_record(value[i]); + }; + sidxlate_command.options.sids = sids; + sidxlate_command.execute(); + }; + + return that; +}; + + IPA.attr_read_only_evaluator = function(spec) { spec.name = spec.name || 'attr_read_only_evaluator'; diff --git a/install/ui/src/freeipa/entity.js b/install/ui/src/freeipa/entity.js index 08ba7e5..60fb45e 100644 --- a/install/ui/src/freeipa/entity.js +++ b/install/ui/src/freeipa/entity.js @@ -425,6 +425,14 @@ IPA.entity_builder = function() { return that; }; + that.sid_facet = function(spec) { + + spec.type = spec.type || 'sid'; + + that.facet(spec); + + return that; + }; that.standard_association_facets = function(spec) { spec = spec || {}; @@ -727,4 +735,4 @@ IPA.details_facet_update_policy = function(spec) { }; return {}; -}); \ No newline at end of file +}); diff --git a/install/ui/src/freeipa/facet.js b/install/ui/src/freeipa/facet.js index 3ad868e..8517507 100644 --- a/install/ui/src/freeipa/facet.js +++ b/install/ui/src/freeipa/facet.js @@ -1131,6 +1131,7 @@ IPA.facet_builder = function(entity) { that.prepare_methods.details = that.prepare_details_spec; that.prepare_methods.association = that.prepare_association_spec; that.prepare_methods.attribute = that.prepare_attribute_spec; + that.prepare_methods.sid = that.prepare_sid_spec; } that.build_facets = function() { @@ -1271,6 +1272,17 @@ IPA.facet_builder = function(entity) { return false; }; + that.prepare_sid_spec = function(spec) { + spec.title = spec.title || entity.metadata.label_singular; + spec.label = spec.label || entity.metadata.label_singular; + + var attr_metadata = IPA.get_entity_param(entity.name, spec.attribute); + spec.tab_label = spec.tab_label || attr_metadata.label; + spec.factory = spec.factory || IPA.sid_facet; + + return spec; + }; + init(); return that; diff --git a/install/ui/src/freeipa/group.js b/install/ui/src/freeipa/group.js index a84f49f..dbac380 100644 --- a/install/ui/src/freeipa/group.js +++ b/install/ui/src/freeipa/group.js @@ -105,11 +105,11 @@ IPA.group.entity = function(spec) { name: 'member_external', attribute: 'ipaexternalmember', tab_label: 'External', - facet_group: 'member', + facet_group: 'sid_facet', columns: [ { name: 'ipaexternalmember', - label: IPA.get_command_option('group_add_member', 'ipaexternalmember').label + label: IPA.get_command_option('group_add_member', 'ipaexternalmember').label, } ] @@ -257,4 +257,4 @@ IPA.group.make_external_action = function(spec) { IPA.register('group', IPA.group.entity); return {}; -}); \ No newline at end of file +}); diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index a252ad6..fa384c7 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -21,6 +21,7 @@ from ipalib.plugins.baseldap import * from ipalib.plugins.dns import dns_container_exists from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object +from types import NoneType from ipalib.parameters import Enum from ipalib import Command from ipalib import errors @@ -32,6 +33,12 @@ try: except Exception, e: _murmur_installed = False +try: + import pysss_nss_idmap #pylint: disable=F0401 + _nss_idmap_installed = True +except Exception, e: + _nss_idmap_installed = False + if api.env.in_server and api.env.context in ['lite', 'server']: try: import ipaserver.dcerpc #pylint: disable=F0401 @@ -687,3 +694,42 @@ class trustconfig_show(LDAPRetrieve): return dn api.register(trustconfig_show) + +import time +class trust_resolve(Command): + __doc__ = _('Resolve security identifiers of users and groups in trusted domains') + + takes_options = ( + Str('sids+', + label = _('Security Identifiers (SIDs)'), + csv = True, + ), + ) + + has_output_params = ( + Str('name', label= _('Name')), + Str('sid', label= _('SID')), + ) + + has_output = ( + output.ListOfEntries('result'), + ) + + def execute(self, *keys, **options): + result = list() + if not _nss_idmap_installed: + return dict(result=result) + try: + sids = map(lambda x: str(x), options['sids']) + xlate = pysss_nss_idmap.getnamebysid(sids) + for sid in xlate: + entry = dict() + entry['sid'] = [unicode(sid)] + entry['name'] = [unicode(xlate[sid])] + result.append(entry) + except ValueError, e: + pass + + return dict(result=result) + +api.register(trust_resolve) -- 1.8.1.4 From rcritten at redhat.com Fri May 3 19:30:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 May 2013 15:30:29 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367585914.2976.157.camel@willson.li.ssimo.org> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <1367585914.2976.157.camel@willson.li.ssimo.org> Message-ID: <51841055.7080902@redhat.com> Simo Sorce wrote: > On Fri, 2013-05-03 at 01:27 -0400, Nathaniel McCallum wrote: >> All issues fixed unless noted below... The attached patches are tested >> to work. >> >> On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: >> >>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >>> (although I know slapi_ch_malloc() currently just aborts on failure, I >>> think that is plain wrong which is why I would prefer using >>> malloc/strdup, but well, I guess this is not something I am going to >>> care too much about for now). >> >> Not fixed. >> >>> - Is the logic with auth_type_used correct ? >>> At least the name of the variable sounds misleading, because you set it >>> only if the authentication was successful but not set if it was 'used' >>> but was unsuccessful. Made me look at it multiple times to reconstuct >>> the logic. The var name could be better, however I also want a comment >>> that explain exactly how we are going to manage authentication and >>> fallbacks here as that logic is critical and is useful for anyone that >>> is going to have to change this code later in order not to break it. >> >> The variable is now gone. I re-factored the section to make the logic >> clearer and put a nice big comment up top. >> >>> - General question: how does this PRE_BIND plugin interact with >>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >>> Are you going to cause that plugin not to run by returning a result >>> directly in this function ? >>> Or is this plugin configured to run only after the previous one went >>> through ? >>> I ask because I do not see any ordering information in the cn=config >>> plugin configuration so it is not immediately clear to me. >> >> That is a good question for Nathan since he wrote this part of the >> code... >> >>> Continuing with otp.c: >>> >>> - what does 'egress' mean ? >>> (can you just use 'done' as a standard label for exceptions ?) >> >> Egress: >> Noun - The action of going out of or leaving a place: "direct means of >> access and egress". >> Verb - Go out of or leave (a place). >> >> In short: ingress means to enter and egress means to exit. >> >> I have changed all 'egress' labels to 'done'. >> >>> - Is it ok to call PK11_DestroyContext() if ctx is NULL ? >>> Can't find much documentation but see #276314 / #276311 on >>> bugzilla.mozilla.org >> >> I added if's for all of these just to be defensive. >> >>> - Can you please add a comment that describe which HMAC algorithm are >>> you using (or a reference to a RFC of it ?) Unfortunately NSS makes >>> thins a lot more cryptic than it should :( >>> Also adding comments before the various NSS invocation to explain what >>> they do would help, this code is obscure. >> >> Unfortunately, that codes is mostly copy/paste from an NSS example of >> how to do HMAC. It is just as unclear to me as it is to you. I have >> added a link to the example with a note about me not understanding how >> it works... >> >> The good news is that it passes all the unit tests which use values >> defined in the RFC. Also, valgrind reports no leaks or other errors. So >> even if I don't know *how* it works, I do know that it does, in fact, >> work. > > Ok I took a deper look and now understand what it is doing. > I think it is implementing RFC 6234 HMAC, but can't say for sure. > > The first NSS call creates a key container, the second initializes the > context and tells NSS which HMAC algorythm to use and what is the key. > > Then the 3 calls simply (1) start the hmac calculation, (2) add in the > data to be signed and (3) extracts the final signature on the data to be > returned. > >>> - Why do we have ipa_otp_hotp if we implement only totp ? >> >> TOTP is a specialized case of HOTP. It is simply an alternative >> mechanism for calculating the counter input to HOTP. Note that >> ipa_otp_totp() is basically a one-liner. Since you *have* to implement >> HOTP to get TOTP, you might as well expose the HOTP implementation for >> future use. > > Yeah I've seen that, looks a bit weird but makes perfect sense. > > I do not have any more concerns on patch 1, so it's an ACK from me for > that one. > > I haven't yet gone through the whole companion daemon patch :/ > > The otp ACIs one I think is wrong though, so still no full ack on the > whole patchset. > > Simo. This patch should fix things up. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-otp_aci.patch Type: text/x-diff Size: 13297 bytes Desc: not available URL: From rcritten at redhat.com Fri May 3 20:08:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 May 2013 16:08:11 -0400 Subject: [Freeipa-devel] [PATCH] 1098 catch cert-find errors on upgraded servers In-Reply-To: <5183A8EB.9070809@redhat.com> References: <517ADB26.60402@redhat.com> <517E559F.60301@redhat.com> <517EDD81.9020005@redhat.com> <5183A8EB.9070809@redhat.com> Message-ID: <5184192B.7090100@redhat.com> Petr Viktorin wrote: > On 04/29/2013 10:52 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/26/2013 09:53 PM, Rob Crittenden wrote: >>>> A dogtag 9 -> 10 upgraded server doesn't provide the RESTful API so >>>> therefore the cert-find command doesn't work. Starting with dogtag >>>> 10.0.2 it is going to send back a 501 (HTTP Not implemented) in this >>>> case so we at least have something to catch. >>>> >>>> This patch catches a 501 and returns a more specific message. >>>> >>>> 10.0.2 builds should be available this weekend, or you can pull from >>>> their devel repo at: >>>> >>>> [dogtag-devel] >>>> name=Dogtag development $releasever - $basearch >>>> baseurl=http://nkinder.fedorapeople.org/dogtag-devel/fedora/$releasever/$basearch/os/ >>>> >>>> >>>> >>>> >>>> enabled=0 >>>> gpgcheck=0 >>>> >>> >>> With the new Dogtag, /root/.pki/pki-tomcat/ca_admin_cert.p12 is not >>> created. Installation of a new server fails on copying that to >>> /root/ca-agent.p12. Adding Ade to the thread, he should know more. >>> >>> >>> On my instance upgraded from f17 to f18, I get 404 errors, not 501. >>> >>> $ rpm -q pki-base >>> pki-base-10.0.2-1.fc18.noarch >>> $ ./ipa cert-find >>> ipa: ERROR: Certificate operation cannot be completed: Unable to >>> communicate with CMS (Not Found) >>> $ curl -v http://`hostname`:9180/ca/rest/certs/search >>> [...] >>> < HTTP/1.1 404 Not Found >>> < Server: Apache-Coyote/1.1 >>> < Content-Type: text/html >>> < Content-Length: 5723 >>> < Date: Sun, 28 Apr 2013 23:08:44 GMT >>> [...] >> >> This is caused by some syntax errors in the dogtag upgrade script. They >> are working on a respin. See /var/log/pki/pki-server-upgrade-*.log >> >> rob >> > > When I used yum upgrade for f17?f18, the pki-server-upgrade scriptlet > failed; /var/log/pki/pki-server-upgrade-10.0.2.log says: > > Upgrading server at Fri May 3 07:37:44 EDT 2013. > Upgrading from version 10.0.0 to 10.0.1: > No upgrade scriptlets. > > Upgrading from version 10.0.1 to 10.0.2: > 1. Replace random number generator > ERROR: > Failed upgrading Dogtag 9 pki-ca/ca subsystem. > Upgrade failed in Dogtag 9 pki-ca/ca: > > However, after running the script manually, everything is back to > normal. The patch works fine, it just needs a changelog rebase. > > ACK > Rebased and pushed to master rob From sbose at redhat.com Fri May 3 20:29:57 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 3 May 2013 22:29:57 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130503184647.GV7607@redhat.com> References: <20130503184647.GV7607@redhat.com> Message-ID: <20130503202957.GI26881@localhost.localdomain> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached are patches to allow resolving SIDs in Web UI in external > membership panel for groups. Please see more detailed description in the > main patch. > > I haven't rebased it yet on top of Petr's Web UI rework, hopefully it > should be simple. > > https://fedorahosted.org/freeipa/ticket/3302 > > Since framework doesn't allow to hide commands from CLI, underlying > command is usable from CLI too: > # ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} > Name: enterprise read-only domain controllers at ad.lan > SID: S-1-5-21-3502988750-125904550-3683905862-498 > > Name: administrator at ad.lan > SID: S-1-5-21-3502988750-125904550-3683905862-500 > > Name: domain admins at ad.lan > SID: S-1-5-21-3502988750-125904550-3683905862-512 > > -- > / Alexander Bokovoy > + try: > + sids = map(lambda x: str(x), options['sids']) > + xlate = pysss_nss_idmap.getnamebysid(sids) The latest version, which is already committed to sssd, return a dict. The output of ipa trust-resolve now look like: [root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} SID: S-1-5-21-3090815309-2627318493-3395719201-500 Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} SID: S-1-5-21-3090815309-2627318493-3395719201-498 Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} SID: S-1-5-21-3090815309-2627318493-3395719201-513 > + for sid in xlate: > + entry = dict() > + entry['sid'] = [unicode(sid)] > + entry['name'] = [unicode(xlate[sid])] I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] here. > + result.append(entry) > + except ValueError, e: > + pass > + > + return dict(result=result) > + > +api.register(trust_resolve) > -- > 1.8.1.4 > I tried with firefox, but the SIDs of the external members are not resolved. Do I have to clean any firefox cache? bye, Sumit From rcritten at redhat.com Fri May 3 21:33:02 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 03 May 2013 17:33:02 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <51841055.7080902@redhat.com> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <1367585914.2976.157.camel@willson.li.ssimo.org> <51841055.7080902@redhat.com> Message-ID: <51842D0E.2010905@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2013-05-03 at 01:27 -0400, Nathaniel McCallum wrote: >>> All issues fixed unless noted below... The attached patches are tested >>> to work. >>> >>> On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: >>> >>>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >>>> (although I know slapi_ch_malloc() currently just aborts on failure, I >>>> think that is plain wrong which is why I would prefer using >>>> malloc/strdup, but well, I guess this is not something I am going to >>>> care too much about for now). >>> >>> Not fixed. >>> >>>> - Is the logic with auth_type_used correct ? >>>> At least the name of the variable sounds misleading, because you set it >>>> only if the authentication was successful but not set if it was 'used' >>>> but was unsuccessful. Made me look at it multiple times to reconstuct >>>> the logic. The var name could be better, however I also want a comment >>>> that explain exactly how we are going to manage authentication and >>>> fallbacks here as that logic is critical and is useful for anyone that >>>> is going to have to change this code later in order not to break it. >>> >>> The variable is now gone. I re-factored the section to make the logic >>> clearer and put a nice big comment up top. >>> >>>> - General question: how does this PRE_BIND plugin interact with >>>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >>>> Are you going to cause that plugin not to run by returning a result >>>> directly in this function ? >>>> Or is this plugin configured to run only after the previous one went >>>> through ? >>>> I ask because I do not see any ordering information in the cn=config >>>> plugin configuration so it is not immediately clear to me. >>> >>> That is a good question for Nathan since he wrote this part of the >>> code... >>> >>>> Continuing with otp.c: >>>> >>>> - what does 'egress' mean ? >>>> (can you just use 'done' as a standard label for exceptions ?) >>> >>> Egress: >>> Noun - The action of going out of or leaving a place: "direct means of >>> access and egress". >>> Verb - Go out of or leave (a place). >>> >>> In short: ingress means to enter and egress means to exit. >>> >>> I have changed all 'egress' labels to 'done'. >>> >>>> - Is it ok to call PK11_DestroyContext() if ctx is NULL ? >>>> Can't find much documentation but see #276314 / #276311 on >>>> bugzilla.mozilla.org >>> >>> I added if's for all of these just to be defensive. >>> >>>> - Can you please add a comment that describe which HMAC algorithm are >>>> you using (or a reference to a RFC of it ?) Unfortunately NSS makes >>>> thins a lot more cryptic than it should :( >>>> Also adding comments before the various NSS invocation to explain what >>>> they do would help, this code is obscure. >>> >>> Unfortunately, that codes is mostly copy/paste from an NSS example of >>> how to do HMAC. It is just as unclear to me as it is to you. I have >>> added a link to the example with a note about me not understanding how >>> it works... >>> >>> The good news is that it passes all the unit tests which use values >>> defined in the RFC. Also, valgrind reports no leaks or other errors. So >>> even if I don't know *how* it works, I do know that it does, in fact, >>> work. >> >> Ok I took a deper look and now understand what it is doing. >> I think it is implementing RFC 6234 HMAC, but can't say for sure. >> >> The first NSS call creates a key container, the second initializes the >> context and tells NSS which HMAC algorythm to use and what is the key. >> >> Then the 3 calls simply (1) start the hmac calculation, (2) add in the >> data to be signed and (3) extracts the final signature on the data to be >> returned. >> >>>> - Why do we have ipa_otp_hotp if we implement only totp ? >>> >>> TOTP is a specialized case of HOTP. It is simply an alternative >>> mechanism for calculating the counter input to HOTP. Note that >>> ipa_otp_totp() is basically a one-liner. Since you *have* to implement >>> HOTP to get TOTP, you might as well expose the HOTP implementation for >>> future use. >> >> Yeah I've seen that, looks a bit weird but makes perfect sense. >> >> I do not have any more concerns on patch 1, so it's an ACK from me for >> that one. >> >> I haven't yet gone through the whole companion daemon patch :/ >> >> The otp ACIs one I think is wrong though, so still no full ack on the >> whole patchset. >> >> Simo. > > This patch should fix things up. > > rob The ACIs to let a user manage their own OTP needed some tweaking. It was loading in the wrong place for new installs and in both cases it lacked read access to objectclass so nothing was actually being granted. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-otp_aci-2.patch Type: text/x-diff Size: 14334 bytes Desc: not available URL: From abokovoy at redhat.com Sat May 4 05:13:17 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 4 May 2013 08:13:17 +0300 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130503202957.GI26881@localhost.localdomain> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> Message-ID: <20130504051317.GW7607@redhat.com> On Fri, 03 May 2013, Sumit Bose wrote: >On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >> Hi! >> >> Attached are patches to allow resolving SIDs in Web UI in external >> membership panel for groups. Please see more detailed description in the >> main patch. >> >> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >> should be simple. >> >> https://fedorahosted.org/freeipa/ticket/3302 >> >> Since framework doesn't allow to hide commands from CLI, underlying >> command is usable from CLI too: >> # ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >> Name: enterprise read-only domain controllers at ad.lan >> SID: S-1-5-21-3502988750-125904550-3683905862-498 >> >> Name: administrator at ad.lan >> SID: S-1-5-21-3502988750-125904550-3683905862-500 >> >> Name: domain admins at ad.lan >> SID: S-1-5-21-3502988750-125904550-3683905862-512 >> >> -- >> / Alexander Bokovoy >> + try: >> + sids = map(lambda x: str(x), options['sids']) >> + xlate = pysss_nss_idmap.getnamebysid(sids) > >The latest version, which is already committed to sssd, return a dict. >The output of ipa trust-resolve now look like: > >[root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} > Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} > SID: S-1-5-21-3090815309-2627318493-3395719201-500 > > Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} > SID: S-1-5-21-3090815309-2627318493-3395719201-498 > > Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} > SID: S-1-5-21-3090815309-2627318493-3395719201-513 > >> + for sid in xlate: >> + entry = dict() >> + entry['sid'] = [unicode(sid)] >> + entry['name'] = [unicode(xlate[sid])] > >I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >here. Fixed, thanks! I also added type conversion to a text (user, group, both). The type is not shown by default in CLI but is available through --all option. We might consider using it in Web UI for visual hint about the name nature. >I tried with firefox, but the SIDs of the external members are not >resolved. Do I have to clean any firefox cache? No, you do not. When picking up changes from my development VM, I omitted one chunk in group.js where sid_facet was actually taken in use. Without that one nothing is used. Updated patch 0103 is attached, tested against sssd in ipa-devel repo which already includes your patches. -- / Alexander Bokovoy -------------- next part -------------- >From d2bab4c42487ca57557ce19d1b6b90a1fd220566 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Apr 2013 13:13:25 +0300 Subject: [PATCH 3/3] Resolve SIDs in Web UI Introduce new command, 'trust-resolve', to aid resolving SIDs to names in the Web UI. The command uses new SSSD interface, nss_idmap, to resolve actual SIDs. SSSD caches resolved data so that future requests to resolve same SIDs are returned from a memory cache. Web UI code is using Dojo/Deferred to deliver result of SID resolution out of band. Once resolved names are available, they replace SID values. Since Web UI only shows ~20 records per page, up to 20 SIDs are resolved at the same time. They all sent within the single request to the server. https://fedorahosted.org/freeipa/ticket/3302 --- API.txt | 7 +++++ freeipa.spec.in | 4 +++ install/ui/src/freeipa/association.js | 45 +++++++++++++++++++++++++++- install/ui/src/freeipa/entity.js | 10 ++++++- install/ui/src/freeipa/facet.js | 12 ++++++++ install/ui/src/freeipa/group.js | 4 +-- ipalib/plugins/trust.py | 56 +++++++++++++++++++++++++++++++++++ 7 files changed, 134 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index c2400e9..e5bb7be 100644 --- a/API.txt +++ b/API.txt @@ -3398,6 +3398,13 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trust_resolve +args: 0,4,1 +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('sids+', csv=True) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) command: trust_show args: 1,4,3 arg: Str('cn', attribute=True, cli_name='realm', multivalue=False, primary_key=True, query=True, required=True) diff --git a/freeipa.spec.in b/freeipa.spec.in index 36e2a61..1f97418 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -211,6 +211,7 @@ Requires: samba4 Requires: samba4-winbind %endif Requires: libsss_idmap +Requires: libsss_nss_idmap-python # We use alternatives to divert winbind_krb5_locator.so plugin to libkrb5 # on the installes where server-trust-ad subpackage is installed because # IPA AD trusts cannot be used at the same time with the locator plugin @@ -839,6 +840,9 @@ fi %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt %changelog +* Fri May 03 2013 Alexander Bokovoy - 3.1.99-10 +- Add libsss_nss_idmap-python dependency for SID resolution + * Tue Apr 30 2013 Rob Crittenden - 3.1.99-9 - Add Conflicts on nss-pam-ldapd < 0.8.4. The mapping from uniqueMember to member is now done automatically and having it in the config file raises diff --git a/install/ui/src/freeipa/association.js b/install/ui/src/freeipa/association.js index c6b9e5a..dad138f 100644 --- a/install/ui/src/freeipa/association.js +++ b/install/ui/src/freeipa/association.js @@ -22,7 +22,7 @@ /* CURRENTLY ALSO REQUIRES search.js, because it reuses it's code to create * the AssociationList elements; IT NEEDS IT'S OWN CODE! */ -define(['./ipa', './jquery', './search', './dialog'], function(IPA, $) { +define(['dojo/Deferred','./ipa', './jquery', './search', './dialog'], function(Deferred, IPA, $) { IPA.associator = function (spec) { @@ -1355,6 +1355,49 @@ IPA.attribute_facet = function(spec, no_init) { return that; }; +IPA.sid_facet = function(spec, no_init) { + + spec.name = spec.name || 'sid_facet'; + + var that = IPA.attribute_facet(spec, no_init); + + that.load_records = function(value) { + var xlate = {} + var sidxlate_command = IPA.command({ + entity: 'trust', + method: 'resolve', + options: { + sids: '', + }, + }); + sidxlate_command.on_success = function(data, text_status, xhr) { + for(var i=0; i< data.result.result.length; i++) { + var entry = data.result.result[i] + if (entry.sid[0] in xlate) { + xlate[entry.sid[0]].resolve(entry.name[0]); + } + } + }; + that.table.empty(); + + var sids = new Array(); + for(var i=0; i< value.length; i++) { + var sid = value[i][that.attribute]; + var deferred = new Deferred(); + deferred.temp = sid; + value[i][that.attribute] = deferred; + xlate[sid] = deferred; + sids.push(sid) + that.add_record(value[i]); + }; + sidxlate_command.options.sids = sids; + sidxlate_command.execute(); + }; + + return that; +}; + + IPA.attr_read_only_evaluator = function(spec) { spec.name = spec.name || 'attr_read_only_evaluator'; diff --git a/install/ui/src/freeipa/entity.js b/install/ui/src/freeipa/entity.js index 08ba7e5..60fb45e 100644 --- a/install/ui/src/freeipa/entity.js +++ b/install/ui/src/freeipa/entity.js @@ -425,6 +425,14 @@ IPA.entity_builder = function() { return that; }; + that.sid_facet = function(spec) { + + spec.type = spec.type || 'sid'; + + that.facet(spec); + + return that; + }; that.standard_association_facets = function(spec) { spec = spec || {}; @@ -727,4 +735,4 @@ IPA.details_facet_update_policy = function(spec) { }; return {}; -}); \ No newline at end of file +}); diff --git a/install/ui/src/freeipa/facet.js b/install/ui/src/freeipa/facet.js index 3ad868e..8517507 100644 --- a/install/ui/src/freeipa/facet.js +++ b/install/ui/src/freeipa/facet.js @@ -1131,6 +1131,7 @@ IPA.facet_builder = function(entity) { that.prepare_methods.details = that.prepare_details_spec; that.prepare_methods.association = that.prepare_association_spec; that.prepare_methods.attribute = that.prepare_attribute_spec; + that.prepare_methods.sid = that.prepare_sid_spec; } that.build_facets = function() { @@ -1271,6 +1272,17 @@ IPA.facet_builder = function(entity) { return false; }; + that.prepare_sid_spec = function(spec) { + spec.title = spec.title || entity.metadata.label_singular; + spec.label = spec.label || entity.metadata.label_singular; + + var attr_metadata = IPA.get_entity_param(entity.name, spec.attribute); + spec.tab_label = spec.tab_label || attr_metadata.label; + spec.factory = spec.factory || IPA.sid_facet; + + return spec; + }; + init(); return that; diff --git a/install/ui/src/freeipa/group.js b/install/ui/src/freeipa/group.js index a84f49f..bb8baa0 100644 --- a/install/ui/src/freeipa/group.js +++ b/install/ui/src/freeipa/group.js @@ -101,7 +101,7 @@ IPA.group.entity = function(spec) { association_facet({ name: 'member_group' }). - attribute_facet({ + sid_facet({ name: 'member_external', attribute: 'ipaexternalmember', tab_label: 'External', @@ -257,4 +257,4 @@ IPA.group.make_external_action = function(spec) { IPA.register('group', IPA.group.entity); return {}; -}); \ No newline at end of file +}); diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index a252ad6..e70e424 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -21,6 +21,7 @@ from ipalib.plugins.baseldap import * from ipalib.plugins.dns import dns_container_exists from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object +from types import NoneType from ipalib.parameters import Enum from ipalib import Command from ipalib import errors @@ -32,6 +33,12 @@ try: except Exception, e: _murmur_installed = False +try: + import pysss_nss_idmap #pylint: disable=F0401 + _nss_idmap_installed = True +except Exception, e: + _nss_idmap_installed = False + if api.env.in_server and api.env.context in ['lite', 'server']: try: import ipaserver.dcerpc #pylint: disable=F0401 @@ -687,3 +694,52 @@ class trustconfig_show(LDAPRetrieve): return dn api.register(trustconfig_show) + +if _nss_idmap_installed: + _idmap_type_dict = { + pysss_nss_idmap.ID_USER : 'user', + pysss_nss_idmap.ID_GROUP : 'group', + pysss_nss_idmap.ID_BOTH : 'both', + } + def idmap_type_string(level): + string = _idmap_type_dict.get(int(level), 'unknown') + return unicode(string) + +class trust_resolve(Command): + __doc__ = _('Resolve security identifiers of users and groups in trusted domains') + + takes_options = ( + Str('sids+', + label = _('Security Identifiers (SIDs)'), + csv = True, + ), + ) + + has_output_params = ( + Str('name', label= _('Name')), + Str('sid', label= _('SID')), + ) + + has_output = ( + output.ListOfEntries('result'), + ) + + def execute(self, *keys, **options): + result = list() + if not _nss_idmap_installed: + return dict(result=result) + try: + sids = map(lambda x: str(x), options['sids']) + xlate = pysss_nss_idmap.getnamebysid(sids) + for sid in xlate: + entry = dict() + entry['sid'] = [unicode(sid)] + entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] + entry['type'] = [idmap_type_string(xlate[sid][pysss_nss_idmap.TYPE_KEY])] + result.append(entry) + except ValueError, e: + pass + + return dict(result=result) + +api.register(trust_resolve) -- 1.8.1.4 From abokovoy at redhat.com Sat May 4 06:04:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 4 May 2013 09:04:00 +0300 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504051317.GW7607@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> Message-ID: <20130504060400.GX7607@redhat.com> On Sat, 04 May 2013, Alexander Bokovoy wrote: > On Fri, 03 May 2013, Sumit Bose wrote: >> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached are patches to allow resolving SIDs in Web UI in external >>> membership panel for groups. Please see more detailed description in the >>> main patch. >>> >>> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >>> should be simple. >>> >>> https://fedorahosted.org/freeipa/ticket/3302 >>> >>> Since framework doesn't allow to hide commands from CLI, underlying >>> command is usable from CLI too: >>> # ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >>> Name: enterprise read-only domain controllers at ad.lan >>> SID: S-1-5-21-3502988750-125904550-3683905862-498 >>> >>> Name: administrator at ad.lan >>> SID: S-1-5-21-3502988750-125904550-3683905862-500 >>> >>> Name: domain admins at ad.lan >>> SID: S-1-5-21-3502988750-125904550-3683905862-512 >>> >>> -- >>> / Alexander Bokovoy >>> + try: >>> + sids = map(lambda x: str(x), options['sids']) >>> + xlate = pysss_nss_idmap.getnamebysid(sids) >> >> The latest version, which is already committed to sssd, return a dict. >> The output of ipa trust-resolve now look like: >> >> [root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >> SID: S-1-5-21-3090815309-2627318493-3395719201-500 >> >> Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} >> SID: S-1-5-21-3090815309-2627318493-3395719201-498 >> >> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >> SID: S-1-5-21-3090815309-2627318493-3395719201-513 >> >>> + for sid in xlate: >>> + entry = dict() >>> + entry['sid'] = [unicode(sid)] >>> + entry['name'] = [unicode(xlate[sid])] >> >> I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >> here. > Fixed, thanks! > I also added type conversion to a text (user, group, both). The type is not shown by default > in CLI but is available through --all option. We might consider using it > in Web UI for visual hint about the name nature. > >> I tried with firefox, but the SIDs of the external members are not >> resolved. Do I have to clean any firefox cache? > No, you do not. When picking up changes from my development VM, I > omitted one chunk in group.js where sid_facet was actually taken in use. > Without that one nothing is used. > > Updated patch 0103 is attached, tested against sssd in ipa-devel repo > which already includes your patches. ... and here is rebase of install/ui/src/freeipa to Web UI refactoring branch, to help testing on top of Petr's changes. With this patch SID resolving works in new Web UI. There are probably some changes that could further be removed, I haven't looked into greater detail. Please note that attached patch only covers parts in install/ui/src/freeipa, you'd still need to add plugin changes from ipalib/plugins/trust.py. -- / Alexander Bokovoy -------------- next part -------------- diff --git a/install/ui/src/freeipa/association.js b/install/ui/src/freeipa/association.js index d33ec87..cd76b7e 100644 --- a/install/ui/src/freeipa/association.js +++ b/install/ui/src/freeipa/association.js @@ -23,6 +23,7 @@ * the AssociationList elements; IT NEEDS IT'S OWN CODE! */ define([ + 'dojo/Deferred', './ipa', './jquery', './navigation', @@ -31,7 +32,7 @@ define([ './text', './search', './dialog'], - function(IPA, $, navigation, phases, reg, text) { + function(Deferred, IPA, $, navigation, phases, reg, text) { IPA.associator = function (spec) { @@ -1364,6 +1365,49 @@ IPA.attribute_facet = function(spec, no_init) { return that; }; +IPA.sid_facet = function(spec, no_init) { + + spec.name = spec.name || 'sid_facet'; + + var that = IPA.attribute_facet(spec, no_init); + + that.load_records = function(value) { + var xlate = {} + var sidxlate_command = IPA.command({ + entity: 'trust', + method: 'resolve', + options: { + sids: '', + }, + }); + sidxlate_command.on_success = function(data, text_status, xhr) { + for(var i=0; i< data.result.result.length; i++) { + var entry = data.result.result[i] + if (entry.sid[0] in xlate) { + xlate[entry.sid[0]].resolve(entry.name[0]); + } + } + }; + that.table.empty(); + + var sids = new Array(); + for(var i=0; i< value.length; i++) { + var sid = value[i][that.attribute]; + var deferred = new Deferred(); + deferred.temp = sid; + value[i][that.attribute] = deferred; + xlate[sid] = deferred; + sids.push(sid) + that.add_record(value[i]); + }; + sidxlate_command.options.sids = sids; + sidxlate_command.execute(); + }; + + return that; +}; + + IPA.attr_read_only_evaluator = function(spec) { spec.name = spec.name || 'attr_read_only_evaluator'; diff --git a/install/ui/src/freeipa/entity.js b/install/ui/src/freeipa/entity.js index 427d300..d437346 100644 --- a/install/ui/src/freeipa/entity.js +++ b/install/ui/src/freeipa/entity.js @@ -323,6 +323,14 @@ exp.entity_builder =IPA.entity_builder = function(entity) { return that; }; + that.sid_facet = function(spec) { + + spec.type = spec.type || 'sid'; + + that.facet(spec); + + return that; + }; that.standard_association_facets = function(spec) { spec = spec || {}; @@ -662,4 +670,4 @@ registry.builder.post_ops.push( exp.entity_post_ops.deleter_dialog); return exp; -}); \ No newline at end of file +}); diff --git a/install/ui/src/freeipa/facet.js b/install/ui/src/freeipa/facet.js index f9510e7..ed508e7 100644 --- a/install/ui/src/freeipa/facet.js +++ b/install/ui/src/freeipa/facet.js @@ -1576,6 +1576,20 @@ exp.facet_preops = { })); return spec; + }, + + sid: function(spec, context) { + + var entity = context.entity; + su.context_entity(spec, context); + + spec.title = spec.title || entity.metadata.label_singular; + spec.label = spec.label || entity.metadata.label_singular; + + var attr_metadata = IPA.get_entity_param(entity.name, spec.attribute); + spec.tab_label = spec.tab_label || attr_metadata.label; + + return spec; } }; @@ -1621,6 +1635,14 @@ exp.register_facets = function() { exp.facet_preops.attribute ] }); + + f.register({ + type: 'sid', + factory: IPA.sid_facet, + pre_ops: [ + exp.facet_preops.sid + ] + }); }; exp.action = IPA.action = function(spec) { diff --git a/install/ui/src/freeipa/group.js b/install/ui/src/freeipa/group.js index 0408d0b..eba965f 100644 --- a/install/ui/src/freeipa/group.js +++ b/install/ui/src/freeipa/group.js @@ -111,7 +111,7 @@ return { name: 'member_group' }, { - $type: 'attribute', + $type: 'sid', name: 'member_external', attribute: 'ipaexternalmember', tab_label: 'External', @@ -280,4 +280,4 @@ exp.register = function() { phases.on('registration', exp.register); return exp; -}); \ No newline at end of file +}); diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js index 0fe046e..8f1208e 100644 --- a/install/ui/src/freeipa/widget.js +++ b/install/ui/src/freeipa/widget.js @@ -1404,9 +1404,6 @@ IPA.column = function (spec) { } that.setup = function(container, record, suppress_link) { - - container.empty(); - var value = record[that.name]; var type; if (that.formatter) { @@ -1414,7 +1411,34 @@ IPA.column = function (spec) { value = that.formatter.format(value); type = that.formatter.type; } + + var promise, temp = ''; + if (value && typeof value.then === 'function') promise = value; + if (value && value.promise && typeof value.promise.then === 'function') { + promise = value.promise; + temp = value.temp || ''; + } + + if (promise) { + var fulfilled = false; + promise.then(function(val) { + fulfilled = true; + that.set_value(container, val, type, suppress_link); + }); + + if (fulfilled) return; + // val obj can contain temporal value which is displayed + // until promise is fulfilled + value = temp; + } + + that.set_value(container, value, type, suppress_link); + }; + + that.set_value = function(container, value, type, suppress_link) { + value = value ? value.toString() : ''; + container.empty(); var c; if (that.link && !suppress_link) { From sbose at redhat.com Sat May 4 12:45:12 2013 From: sbose at redhat.com (Sumit Bose) Date: Sat, 4 May 2013 14:45:12 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504051317.GW7607@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> Message-ID: <20130504124512.GJ26881@localhost.localdomain> On Sat, May 04, 2013 at 08:13:17AM +0300, Alexander Bokovoy wrote: > On Fri, 03 May 2013, Sumit Bose wrote: > >On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: > >>Hi! > >> > >>Attached are patches to allow resolving SIDs in Web UI in external > >>membership panel for groups. Please see more detailed description in the > >>main patch. > >> > >>I haven't rebased it yet on top of Petr's Web UI rework, hopefully it > >>should be simple. > >> > >>https://fedorahosted.org/freeipa/ticket/3302 > >> > >>Since framework doesn't allow to hide commands from CLI, underlying > >>command is usable from CLI too: > >># ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} > >> Name: enterprise read-only domain controllers at ad.lan > >> SID: S-1-5-21-3502988750-125904550-3683905862-498 > >> > >> Name: administrator at ad.lan > >> SID: S-1-5-21-3502988750-125904550-3683905862-500 > >> > >> Name: domain admins at ad.lan > >> SID: S-1-5-21-3502988750-125904550-3683905862-512 > >> > >>-- > >>/ Alexander Bokovoy > >>+ try: > >>+ sids = map(lambda x: str(x), options['sids']) > >>+ xlate = pysss_nss_idmap.getnamebysid(sids) > > > >The latest version, which is already committed to sssd, return a dict. > >The output of ipa trust-resolve now look like: > > > >[root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} > > Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} > > SID: S-1-5-21-3090815309-2627318493-3395719201-500 > > > > Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} > > SID: S-1-5-21-3090815309-2627318493-3395719201-498 > > > > Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} > > SID: S-1-5-21-3090815309-2627318493-3395719201-513 > > > >>+ for sid in xlate: > >>+ entry = dict() > >>+ entry['sid'] = [unicode(sid)] > >>+ entry['name'] = [unicode(xlate[sid])] > > > >I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] > >here. > Fixed, thanks! > I also added type conversion to a text (user, group, both). The type is not shown by default > in CLI but is available through --all option. We might consider using it > in Web UI for visual hint about the name nature. > > >I tried with firefox, but the SIDs of the external members are not > >resolved. Do I have to clean any firefox cache? > No, you do not. When picking up changes from my development VM, I > omitted one chunk in group.js where sid_facet was actually taken in use. > Without that one nothing is used. > > Updated patch 0103 is attached, tested against sssd in ipa-devel repo > which already includes your patches. I'm sorry, it still does not work for me in firefox on F18 32bits. Can you give me some hints where to look what the WebUI is trying to do? 'ipa trust-resolve' on the command line is working well. bye, Sumit > -- > / Alexander Bokovoy From abokovoy at redhat.com Sat May 4 15:02:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 4 May 2013 18:02:27 +0300 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504124512.GJ26881@localhost.localdomain> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <20130504124512.GJ26881@localhost.localdomain> Message-ID: <20130504150227.GY7607@redhat.com> On Sat, 04 May 2013, Sumit Bose wrote: >On Sat, May 04, 2013 at 08:13:17AM +0300, Alexander Bokovoy wrote: >> On Fri, 03 May 2013, Sumit Bose wrote: >> >On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >> >>Hi! >> >> >> >>Attached are patches to allow resolving SIDs in Web UI in external >> >>membership panel for groups. Please see more detailed description in the >> >>main patch. >> >> >> >>I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >> >>should be simple. >> >> >> >>https://fedorahosted.org/freeipa/ticket/3302 >> >> >> >>Since framework doesn't allow to hide commands from CLI, underlying >> >>command is usable from CLI too: >> >># ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >> >> Name: enterprise read-only domain controllers at ad.lan >> >> SID: S-1-5-21-3502988750-125904550-3683905862-498 >> >> >> >> Name: administrator at ad.lan >> >> SID: S-1-5-21-3502988750-125904550-3683905862-500 >> >> >> >> Name: domain admins at ad.lan >> >> SID: S-1-5-21-3502988750-125904550-3683905862-512 >> >> >> >>-- >> >>/ Alexander Bokovoy >> >>+ try: >> >>+ sids = map(lambda x: str(x), options['sids']) >> >>+ xlate = pysss_nss_idmap.getnamebysid(sids) >> > >> >The latest version, which is already committed to sssd, return a dict. >> >The output of ipa trust-resolve now look like: >> > >> >[root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >> > Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >> > SID: S-1-5-21-3090815309-2627318493-3395719201-500 >> > >> > Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} >> > SID: S-1-5-21-3090815309-2627318493-3395719201-498 >> > >> > Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >> > SID: S-1-5-21-3090815309-2627318493-3395719201-513 >> > >> >>+ for sid in xlate: >> >>+ entry = dict() >> >>+ entry['sid'] = [unicode(sid)] >> >>+ entry['name'] = [unicode(xlate[sid])] >> > >> >I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >> >here. >> Fixed, thanks! >> I also added type conversion to a text (user, group, both). The type is not shown by default >> in CLI but is available through --all option. We might consider using it >> in Web UI for visual hint about the name nature. >> >> >I tried with firefox, but the SIDs of the external members are not >> >resolved. Do I have to clean any firefox cache? >> No, you do not. When picking up changes from my development VM, I >> omitted one chunk in group.js where sid_facet was actually taken in use. >> Without that one nothing is used. >> >> Updated patch 0103 is attached, tested against sssd in ipa-devel repo >> which already includes your patches. > >I'm sorry, it still does not work for me in firefox on F18 32bits. Can >you give me some hints where to look what the WebUI is trying to do? >'ipa trust-resolve' on the command line is working well. Navigate from top /ipa/ui to: - Identity|User groups - select specific group - select 'External' tab I recorded small animated sequence that shows how it looks in new Web UI: http://abbra.fedorapeople.org/.paste/freeipa-sid-resolve-new-web-ui.gif -- / Alexander Bokovoy From sbose at redhat.com Sat May 4 16:20:33 2013 From: sbose at redhat.com (Sumit Bose) Date: Sat, 4 May 2013 18:20:33 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504150227.GY7607@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <20130504124512.GJ26881@localhost.localdomain> <20130504150227.GY7607@redhat.com> Message-ID: <20130504162033.GK26881@localhost.localdomain> On Sat, May 04, 2013 at 06:02:27PM +0300, Alexander Bokovoy wrote: > On Sat, 04 May 2013, Sumit Bose wrote: > >On Sat, May 04, 2013 at 08:13:17AM +0300, Alexander Bokovoy wrote: > >>On Fri, 03 May 2013, Sumit Bose wrote: > >>>On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: > >>>>Hi! > >>>> > >>>>Attached are patches to allow resolving SIDs in Web UI in external > >>>>membership panel for groups. Please see more detailed description in the > >>>>main patch. > >>>> > >>>>I haven't rebased it yet on top of Petr's Web UI rework, hopefully it > >>>>should be simple. > >>>> > >>>>https://fedorahosted.org/freeipa/ticket/3302 > >>>> > >>>>Since framework doesn't allow to hide commands from CLI, underlying > >>>>command is usable from CLI too: > >>>># ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} > >>>> Name: enterprise read-only domain controllers at ad.lan > >>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 > >>>> > >>>> Name: administrator at ad.lan > >>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 > >>>> > >>>> Name: domain admins at ad.lan > >>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 > >>>> > >>>>-- > >>>>/ Alexander Bokovoy > >>>>+ try: > >>>>+ sids = map(lambda x: str(x), options['sids']) > >>>>+ xlate = pysss_nss_idmap.getnamebysid(sids) > >>> > >>>The latest version, which is already committed to sssd, return a dict. > >>>The output of ipa trust-resolve now look like: > >>> > >>>[root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} > >>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} > >>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 > >>> > >>> Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} > >>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 > >>> > >>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} > >>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 > >>> > >>>>+ for sid in xlate: > >>>>+ entry = dict() > >>>>+ entry['sid'] = [unicode(sid)] > >>>>+ entry['name'] = [unicode(xlate[sid])] > >>> > >>>I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] > >>>here. > >>Fixed, thanks! > >>I also added type conversion to a text (user, group, both). The type is not shown by default > >>in CLI but is available through --all option. We might consider using it > >>in Web UI for visual hint about the name nature. > >> > >>>I tried with firefox, but the SIDs of the external members are not > >>>resolved. Do I have to clean any firefox cache? > >>No, you do not. When picking up changes from my development VM, I > >>omitted one chunk in group.js where sid_facet was actually taken in use. > >>Without that one nothing is used. > >> > >>Updated patch 0103 is attached, tested against sssd in ipa-devel repo > >>which already includes your patches. > > > >I'm sorry, it still does not work for me in firefox on F18 32bits. Can > >you give me some hints where to look what the WebUI is trying to do? sorry, I meant how to debug the WebUI. > >'ipa trust-resolve' on the command line is working well. > Navigate from top /ipa/ui to: > - Identity|User groups > - select specific group > - select 'External' tab > > I recorded small animated sequence that shows how it looks in new Web > UI: http://abbra.fedorapeople.org/.paste/freeipa-sid-resolve-new-web-ui.gif I only see the SIDs with your patches applied. I used master with your git patches. Do I need the patches for the new WebUI and your additional patch for that as well? bye, Sumit > > -- > / Alexander Bokovoy From abokovoy at redhat.com Sat May 4 17:24:52 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 4 May 2013 20:24:52 +0300 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504162033.GK26881@localhost.localdomain> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <20130504124512.GJ26881@localhost.localdomain> <20130504150227.GY7607@redhat.com> <20130504162033.GK26881@localhost.localdomain> Message-ID: <20130504172452.GZ7607@redhat.com> On Sat, 04 May 2013, Sumit Bose wrote: >On Sat, May 04, 2013 at 06:02:27PM +0300, Alexander Bokovoy wrote: >> On Sat, 04 May 2013, Sumit Bose wrote: >> >On Sat, May 04, 2013 at 08:13:17AM +0300, Alexander Bokovoy wrote: >> >>On Fri, 03 May 2013, Sumit Bose wrote: >> >>>On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >> >>>>Hi! >> >>>> >> >>>>Attached are patches to allow resolving SIDs in Web UI in external >> >>>>membership panel for groups. Please see more detailed description in the >> >>>>main patch. >> >>>> >> >>>>I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >> >>>>should be simple. >> >>>> >> >>>>https://fedorahosted.org/freeipa/ticket/3302 >> >>>> >> >>>>Since framework doesn't allow to hide commands from CLI, underlying >> >>>>command is usable from CLI too: >> >>>># ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >> >>>> Name: enterprise read-only domain controllers at ad.lan >> >>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 >> >>>> >> >>>> Name: administrator at ad.lan >> >>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 >> >>>> >> >>>> Name: domain admins at ad.lan >> >>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 >> >>>> >> >>>>-- >> >>>>/ Alexander Bokovoy >> >>>>+ try: >> >>>>+ sids = map(lambda x: str(x), options['sids']) >> >>>>+ xlate = pysss_nss_idmap.getnamebysid(sids) >> >>> >> >>>The latest version, which is already committed to sssd, return a dict. >> >>>The output of ipa trust-resolve now look like: >> >>> >> >>>[root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >> >>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >> >>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 >> >>> >> >>> Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} >> >>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 >> >>> >> >>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >> >>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 >> >>> >> >>>>+ for sid in xlate: >> >>>>+ entry = dict() >> >>>>+ entry['sid'] = [unicode(sid)] >> >>>>+ entry['name'] = [unicode(xlate[sid])] >> >>> >> >>>I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >> >>>here. >> >>Fixed, thanks! >> >>I also added type conversion to a text (user, group, both). The type is not shown by default >> >>in CLI but is available through --all option. We might consider using it >> >>in Web UI for visual hint about the name nature. >> >> >> >>>I tried with firefox, but the SIDs of the external members are not >> >>>resolved. Do I have to clean any firefox cache? >> >>No, you do not. When picking up changes from my development VM, I >> >>omitted one chunk in group.js where sid_facet was actually taken in use. >> >>Without that one nothing is used. >> >> >> >>Updated patch 0103 is attached, tested against sssd in ipa-devel repo >> >>which already includes your patches. >> > >> >I'm sorry, it still does not work for me in firefox on F18 32bits. Can >> >you give me some hints where to look what the WebUI is trying to do? > >sorry, I meant how to debug the WebUI. Petr wrote these notes: http://pvoborni.fedorapeople.org/doc/debugging_web_ui.html You'd need to put breakpoint in association.js, in sidxlate_command.on_success(), once you used sync.sh to copy over non-compiled version of the UI javascript code. >> >'ipa trust-resolve' on the command line is working well. >> Navigate from top /ipa/ui to: >> - Identity|User groups >> - select specific group >> - select 'External' tab >> >> I recorded small animated sequence that shows how it looks in new Web >> UI: http://abbra.fedorapeople.org/.paste/freeipa-sid-resolve-new-web-ui.gif > >I only see the SIDs with your patches applied. I used master with your git >patches. Do I need the patches for the new WebUI and your additional >patch for that as well? GIT master with my patches should be enough -- if you used 0103 revision 1 Additional patch part is only for new Web UI rebase for instal/ui/src/freeipa/* -- / Alexander Bokovoy From jhrozek at redhat.com Sun May 5 19:42:16 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 5 May 2013 21:42:16 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130503184647.GV7607@redhat.com> References: <20130503184647.GV7607@redhat.com> Message-ID: <20130505194216.GB11252@hendrix.brq.redhat.com> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached are patches to allow resolving SIDs in Web UI in external > membership panel for groups. Please see more detailed description in the > main patch. > > I haven't rebased it yet on top of Petr's Web UI rework, hopefully it > should be simple. > > https://fedorahosted.org/freeipa/ticket/3302 > > Since framework doesn't allow to hide commands from CLI, underlying > command is usable from CLI too: > # ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} > Name: enterprise read-only domain controllers at ad.lan > SID: S-1-5-21-3502988750-125904550-3683905862-498 > > Name: administrator at ad.lan > SID: S-1-5-21-3502988750-125904550-3683905862-500 > > Name: domain admins at ad.lan > SID: S-1-5-21-3502988750-125904550-3683905862-512 Looks like Sumit is already on top of testing the patches, but for the record, you'd need SSSD-1.10 beta1 or newer in order to test the functionality. From mkosek at redhat.com Mon May 6 07:16:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 May 2013 09:16:41 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <5183F576.6070109@redhat.com> References: <51756B5E.8030604@redhat.com> <5183F576.6070109@redhat.com> Message-ID: <518758D9.6030003@redhat.com> On 05/03/2013 07:35 PM, Endi Sukma Dewata wrote: > Hi, > > Sorry for the delay, I have some questions & comments. > > Registry: > > In the simpleuser.js the new 'user' entity is registered first then the old > 'user' entity is removed, which could be confusing because they are both > identified using 'user'. Should register() automatically remove the old object? > Ideally a class should have complete methods to manage the objects it stores > (e.g. unregister(), remove()). > > How is reg.entity created? Are there others beside 'entity'? > > How is Registries_registry in reg.js used? It doesn't seem to be used anywhere > else. > > Plugins: > > In plugins.py the list of plugins is generated using os.listdir(). Then each > plugin also has a list of dependencies which I suppose can include other > plugins. Then when registering the plugin task, it will have a priority as well. > > So there seem to be several factors that determine the execution order of the > plugins. There should be a document explaining how this will work, so plugin > writers can be sure that the code will be executed at the right time. > > In general I'd avoid using task priority because it doesn't guarantee the > correct execution order unless the priorities of all tasks are well coordinated > (which might be challenging if there are multiple plugins owned by different > people). > > Could you add more examples of simple plugins for various scenarios including > custom entity, custom facet, custom field, custom menu? They can be included in > the RPM for reference. > > Writing a plugin seems to still require programming skills, reliance on good > docs, and probably even some source code familiarity. What do you think about > simplifying this a little further? So we'll have 2 ways to define a plugin: one > is programatically using the current framework already implemented (e.g. > simpleuser.js), and the other is completely declaratively using a plain json > data (e.g. simpleuser.json). The declarative plugin will obviously be more > limited, but much simpler to use. > > Builder: > >> b) Second big issue was build of objects. Entities and facets have >> complex build logic. It can be simplified into three steps: >> 1) modifications of spec >> 2) creation of object and class inheritance >> 3) init logic > > Yes, creating an object has become very complicated now with the builders, > factories, constructors, preops, postops, inits, overrides, diff, etc. I think > the problem is that we're trying to create/modify the spec before creating the > object and we need a whole set of mechanisms to do that. Maybe we can simplify > it into two basic steps: > > 1. Create an empty/simple object. > 2. Initialize the object. > > The initialization process could be split further into smaller operations such as: > > * Load the spec and modify it if necessary > * Creating dependent objects and initializing them > * Other initialization steps > > The builder, factory, preops, and postops can be included as part of the > initialization step. They can be normal class methods rather than loosely > defined functions and can be overridden by subclasses. There's probably a lot > more details that need to be discussed. > >> 1. Move ./_base/metadata_provider to ./metadata? >> Might simplify stuff. > > This seems to be IPA-specific, so yes. > >> 2. Move actions/buttons spec from factories to pre_ops associated with >> the factories. >> >> Example of stuff to be moved (search.js): >> spec.actions = spec.actions || []; >> spec.actions.unshift( >> 'refresh', >> 'batch_remove', >> 'add'); >> >> It may simplify/allow removal of those items in spec or pre_ops of child >> factories. Currently there is no way how to intercept them. > > Sure, I don't see any problem with that. > > In general there is no major issue that would warrant a NACK. As long as the > API is well documented for plugin writers it should be sufficient. > Thanks for review Endi! Since we do not have a NACK, lets do small changes we can do now for 3.2 GA and create tickets for the rest (can be done in 3.2 stabilization phase). Martin From mkosek at redhat.com Mon May 6 08:13:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 May 2013 10:13:21 +0200 Subject: [Freeipa-devel] [PATCH] 403 Update pki proxy configuration Message-ID: <51876621.4070903@redhat.com> Replicas with Dogtag pki-ca 10.0.2 CA require access to additional Dogtag REST API calls. Update pki proxy configuration to allow that. https://fedorahosted.org/freeipa/ticket/3601 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-403-update-pki-proxy-configuration.patch Type: text/x-patch Size: 1788 bytes Desc: not available URL: From sbose at redhat.com Mon May 6 08:47:14 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 6 May 2013 10:47:14 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504172452.GZ7607@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <20130504124512.GJ26881@localhost.localdomain> <20130504150227.GY7607@redhat.com> <20130504162033.GK26881@localhost.localdomain> <20130504172452.GZ7607@redhat.com> Message-ID: <20130506084713.GM26881@localhost.localdomain> On Sat, May 04, 2013 at 08:24:52PM +0300, Alexander Bokovoy wrote: > On Sat, 04 May 2013, Sumit Bose wrote: > >On Sat, May 04, 2013 at 06:02:27PM +0300, Alexander Bokovoy wrote: > >>On Sat, 04 May 2013, Sumit Bose wrote: > >>>On Sat, May 04, 2013 at 08:13:17AM +0300, Alexander Bokovoy wrote: > >>>>On Fri, 03 May 2013, Sumit Bose wrote: > >>>>>On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: > >>>>>>Hi! > >>>>>> > >>>>>>Attached are patches to allow resolving SIDs in Web UI in external > >>>>>>membership panel for groups. Please see more detailed description in the > >>>>>>main patch. > >>>>>> > >>>>>>I haven't rebased it yet on top of Petr's Web UI rework, hopefully it > >>>>>>should be simple. > >>>>>> > >>>>>>https://fedorahosted.org/freeipa/ticket/3302 > >>>>>> > >>>>>>Since framework doesn't allow to hide commands from CLI, underlying > >>>>>>command is usable from CLI too: > >>>>>># ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} > >>>>>> Name: enterprise read-only domain controllers at ad.lan > >>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 > >>>>>> > >>>>>> Name: administrator at ad.lan > >>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 > >>>>>> > >>>>>> Name: domain admins at ad.lan > >>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 > >>>>>> > >>>>>>-- > >>>>>>/ Alexander Bokovoy > >>>>>>+ try: > >>>>>>+ sids = map(lambda x: str(x), options['sids']) > >>>>>>+ xlate = pysss_nss_idmap.getnamebysid(sids) > >>>>> > >>>>>The latest version, which is already committed to sssd, return a dict. > >>>>>The output of ipa trust-resolve now look like: > >>>>> > >>>>>[root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} > >>>>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} > >>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 > >>>>> > >>>>> Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} > >>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 > >>>>> > >>>>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} > >>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 > >>>>> > >>>>>>+ for sid in xlate: > >>>>>>+ entry = dict() > >>>>>>+ entry['sid'] = [unicode(sid)] > >>>>>>+ entry['name'] = [unicode(xlate[sid])] > >>>>> > >>>>>I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] > >>>>>here. > >>>>Fixed, thanks! > >>>>I also added type conversion to a text (user, group, both). The type is not shown by default > >>>>in CLI but is available through --all option. We might consider using it > >>>>in Web UI for visual hint about the name nature. > >>>> > >>>>>I tried with firefox, but the SIDs of the external members are not > >>>>>resolved. Do I have to clean any firefox cache? > >>>>No, you do not. When picking up changes from my development VM, I > >>>>omitted one chunk in group.js where sid_facet was actually taken in use. > >>>>Without that one nothing is used. > >>>> > >>>>Updated patch 0103 is attached, tested against sssd in ipa-devel repo > >>>>which already includes your patches. > >>> > >>>I'm sorry, it still does not work for me in firefox on F18 32bits. Can > >>>you give me some hints where to look what the WebUI is trying to do? > > > >sorry, I meant how to debug the WebUI. > Petr wrote these notes: > http://pvoborni.fedorapeople.org/doc/debugging_web_ui.html > > You'd need to put breakpoint in association.js, in > sidxlate_command.on_success(), once you used sync.sh to > copy over non-compiled version of the UI javascript code. Thank you for the hints. Now I see the following, it is working as expected when I just call ./sync.sh -fc but the SIDs are not translated when I call ./sync.sh -fcC I didn't change anything at the *.js source files, just called sync.sh. Any ideas what might be wrong here? bye, Sumit > > >>>'ipa trust-resolve' on the command line is working well. > >>Navigate from top /ipa/ui to: > >> - Identity|User groups > >> - select specific group > >> - select 'External' tab > >> > >>I recorded small animated sequence that shows how it looks in new Web > >>UI: http://abbra.fedorapeople.org/.paste/freeipa-sid-resolve-new-web-ui.gif > > > >I only see the SIDs with your patches applied. I used master with your git > >patches. Do I need the patches for the new WebUI and your additional > >patch for that as well? > GIT master with my patches should be enough -- if you used 0103 revision 1 > > Additional patch part is only for new Web UI rebase for > instal/ui/src/freeipa/* > > -- > / Alexander Bokovoy From pvoborni at redhat.com Mon May 6 09:05:40 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 06 May 2013 11:05:40 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130506084713.GM26881@localhost.localdomain> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <20130504124512.GJ26881@localhost.localdomain> <20130504150227.GY7607@redhat.com> <20130504162033.GK26881@localhost.localdomain> <20130504172452.GZ7607@redhat.com> <20130506084713.GM26881@localhost.localdomain> Message-ID: <51877264.8030504@redhat.com> On 05/06/2013 10:47 AM, Sumit Bose wrote: > On Sat, May 04, 2013 at 08:24:52PM +0300, Alexander Bokovoy wrote: >> On Sat, 04 May 2013, Sumit Bose wrote: >>> On Sat, May 04, 2013 at 06:02:27PM +0300, Alexander Bokovoy wrote: >>>> On Sat, 04 May 2013, Sumit Bose wrote: >>>>> On Sat, May 04, 2013 at 08:13:17AM +0300, Alexander Bokovoy wrote: >>>>>> On Fri, 03 May 2013, Sumit Bose wrote: >>>>>>> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> Attached are patches to allow resolving SIDs in Web UI in external >>>>>>>> membership panel for groups. Please see more detailed description in the >>>>>>>> main patch. >>>>>>>> >>>>>>>> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >>>>>>>> should be simple. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3302 >>>>>>>> >>>>>>>> Since framework doesn't allow to hide commands from CLI, underlying >>>>>>>> command is usable from CLI too: >>>>>>>> # ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >>>>>>>> Name: enterprise read-only domain controllers at ad.lan >>>>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 >>>>>>>> >>>>>>>> Name: administrator at ad.lan >>>>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 >>>>>>>> >>>>>>>> Name: domain admins at ad.lan >>>>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 >>>>>>>> >>>>>>>> -- >>>>>>>> / Alexander Bokovoy >>>>>>>> + try: >>>>>>>> + sids = map(lambda x: str(x), options['sids']) >>>>>>>> + xlate = pysss_nss_idmap.getnamebysid(sids) >>>>>>> >>>>>>> The latest version, which is already committed to sssd, return a dict. >>>>>>> The output of ipa trust-resolve now look like: >>>>>>> >>>>>>> [root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >>>>>>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >>>>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 >>>>>>> >>>>>>> Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} >>>>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 >>>>>>> >>>>>>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >>>>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 >>>>>>> >>>>>>>> + for sid in xlate: >>>>>>>> + entry = dict() >>>>>>>> + entry['sid'] = [unicode(sid)] >>>>>>>> + entry['name'] = [unicode(xlate[sid])] >>>>>>> >>>>>>> I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >>>>>>> here. >>>>>> Fixed, thanks! >>>>>> I also added type conversion to a text (user, group, both). The type is not shown by default >>>>>> in CLI but is available through --all option. We might consider using it >>>>>> in Web UI for visual hint about the name nature. >>>>>> >>>>>>> I tried with firefox, but the SIDs of the external members are not >>>>>>> resolved. Do I have to clean any firefox cache? >>>>>> No, you do not. When picking up changes from my development VM, I >>>>>> omitted one chunk in group.js where sid_facet was actually taken in use. >>>>>> Without that one nothing is used. >>>>>> >>>>>> Updated patch 0103 is attached, tested against sssd in ipa-devel repo >>>>>> which already includes your patches. >>>>> >>>>> I'm sorry, it still does not work for me in firefox on F18 32bits. Can >>>>> you give me some hints where to look what the WebUI is trying to do? >>> >>> sorry, I meant how to debug the WebUI. >> Petr wrote these notes: >> http://pvoborni.fedorapeople.org/doc/debugging_web_ui.html >> >> You'd need to put breakpoint in association.js, in >> sidxlate_command.on_success(), once you used sync.sh to >> copy over non-compiled version of the UI javascript code. > > Thank you for the hints. Now I see the following, it is working > as expected when I just call > > ./sync.sh -fc > > but the SIDs are not translated when I call > > ./sync.sh -fcC > > I didn't change anything at the *.js source files, just called sync.sh. > Any ideas what might be wrong here? -C stands for: send a built/compiled version. Usually you have to create it first - it's not in git. so all ./make-ui.sh before ./sync.sh -fcC I will send comments for the patch later today - mostly nitpicks. > > bye, > Sumit >> >>>>> 'ipa trust-resolve' on the command line is working well. >>>> Navigate from top /ipa/ui to: >>>> - Identity|User groups >>>> - select specific group >>>> - select 'External' tab >>>> >>>> I recorded small animated sequence that shows how it looks in new Web >>>> UI: http://abbra.fedorapeople.org/.paste/freeipa-sid-resolve-new-web-ui.gif >>> >>> I only see the SIDs with your patches applied. I used master with your git >>> patches. Do I need the patches for the new WebUI and your additional >>> patch for that as well? >> GIT master with my patches should be enough -- if you used 0103 revision 1 >> >> Additional patch part is only for new Web UI rebase for >> instal/ui/src/freeipa/* >> >> -- >> / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Petr Vobornik From sbose at redhat.com Mon May 6 09:55:35 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 6 May 2013 11:55:35 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <51877264.8030504@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <20130504124512.GJ26881@localhost.localdomain> <20130504150227.GY7607@redhat.com> <20130504162033.GK26881@localhost.localdomain> <20130504172452.GZ7607@redhat.com> <20130506084713.GM26881@localhost.localdomain> <51877264.8030504@redhat.com> Message-ID: <20130506095535.GO26881@localhost.localdomain> On Mon, May 06, 2013 at 11:05:40AM +0200, Petr Vobornik wrote: > On 05/06/2013 10:47 AM, Sumit Bose wrote: > >On Sat, May 04, 2013 at 08:24:52PM +0300, Alexander Bokovoy wrote: > >>On Sat, 04 May 2013, Sumit Bose wrote: > >>>On Sat, May 04, 2013 at 06:02:27PM +0300, Alexander Bokovoy wrote: > >>>>On Sat, 04 May 2013, Sumit Bose wrote: > >>>>>On Sat, May 04, 2013 at 08:13:17AM +0300, Alexander Bokovoy wrote: > >>>>>>On Fri, 03 May 2013, Sumit Bose wrote: > >>>>>>>On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: > >>>>>>>>Hi! > >>>>>>>> > >>>>>>>>Attached are patches to allow resolving SIDs in Web UI in external > >>>>>>>>membership panel for groups. Please see more detailed description in the > >>>>>>>>main patch. > >>>>>>>> > >>>>>>>>I haven't rebased it yet on top of Petr's Web UI rework, hopefully it > >>>>>>>>should be simple. > >>>>>>>> > >>>>>>>>https://fedorahosted.org/freeipa/ticket/3302 > >>>>>>>> > >>>>>>>>Since framework doesn't allow to hide commands from CLI, underlying > >>>>>>>>command is usable from CLI too: > >>>>>>>># ipa trust-resolve --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} > >>>>>>>>Name: enterprise read-only domain controllers at ad.lan > >>>>>>>>SID: S-1-5-21-3502988750-125904550-3683905862-498 > >>>>>>>> > >>>>>>>>Name: administrator at ad.lan > >>>>>>>>SID: S-1-5-21-3502988750-125904550-3683905862-500 > >>>>>>>> > >>>>>>>>Name: domain admins at ad.lan > >>>>>>>>SID: S-1-5-21-3502988750-125904550-3683905862-512 > >>>>>>>> > >>>>>>>>-- > >>>>>>>>/ Alexander Bokovoy > >>>>>>>>+ try: > >>>>>>>>+ sids = map(lambda x: str(x), options['sids']) > >>>>>>>>+ xlate = pysss_nss_idmap.getnamebysid(sids) > >>>>>>> > >>>>>>>The latest version, which is already committed to sssd, return a dict. > >>>>>>>The output of ipa trust-resolve now look like: > >>>>>>> > >>>>>>>[root at ipa18-devel ~]# ipa trust-resolve --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} > >>>>>>>Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} > >>>>>>>SID: S-1-5-21-3090815309-2627318493-3395719201-500 > >>>>>>> > >>>>>>>Name: {'type': 2, 'name': u'enterprise read-only domain controllers at ad18.ipa18.devel'} > >>>>>>>SID: S-1-5-21-3090815309-2627318493-3395719201-498 > >>>>>>> > >>>>>>>Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} > >>>>>>>SID: S-1-5-21-3090815309-2627318493-3395719201-513 > >>>>>>> > >>>>>>>>+ for sid in xlate: > >>>>>>>>+ entry = dict() > >>>>>>>>+ entry['sid'] = [unicode(sid)] > >>>>>>>>+ entry['name'] = [unicode(xlate[sid])] > >>>>>>> > >>>>>>>I think you need entry['name'] = [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] > >>>>>>>here. > >>>>>>Fixed, thanks! > >>>>>>I also added type conversion to a text (user, group, both). The type is not shown by default > >>>>>>in CLI but is available through --all option. We might consider using it > >>>>>>in Web UI for visual hint about the name nature. > >>>>>> > >>>>>>>I tried with firefox, but the SIDs of the external members are not > >>>>>>>resolved. Do I have to clean any firefox cache? > >>>>>>No, you do not. When picking up changes from my development VM, I > >>>>>>omitted one chunk in group.js where sid_facet was actually taken in use. > >>>>>>Without that one nothing is used. > >>>>>> > >>>>>>Updated patch 0103 is attached, tested against sssd in ipa-devel repo > >>>>>>which already includes your patches. > >>>>> > >>>>>I'm sorry, it still does not work for me in firefox on F18 32bits. Can > >>>>>you give me some hints where to look what the WebUI is trying to do? > >>> > >>>sorry, I meant how to debug the WebUI. > >>Petr wrote these notes: > >>http://pvoborni.fedorapeople.org/doc/debugging_web_ui.html > >> > >>You'd need to put breakpoint in association.js, in > >>sidxlate_command.on_success(), once you used sync.sh to > >>copy over non-compiled version of the UI javascript code. > > > >Thank you for the hints. Now I see the following, it is working > >as expected when I just call > > > >./sync.sh -fc > > > >but the SIDs are not translated when I call > > > >./sync.sh -fcC > > > >I didn't change anything at the *.js source files, just called sync.sh. > >Any ideas what might be wrong here? > > -C stands for: send a built/compiled version. Usually you have to > create it first - it's not in git. > > so all ./make-ui.sh before ./sync.sh -fcC thanks, that did the trick and also told me why the packages created with 'make rpms' didn't work for me, because I forgot to add export BASE_OPTIONS="-Xss512k" to my build environment, because otherwise I see a StackOverflowError while uglifying. bye, Sumit > > I will send comments for the patch later today - mostly nitpicks. > > > >bye, > >Sumit > >> > >>>>>'ipa trust-resolve' on the command line is working well. > >>>>Navigate from top /ipa/ui to: > >>>>- Identity|User groups > >>>> - select specific group > >>>> - select 'External' tab > >>>> > >>>>I recorded small animated sequence that shows how it looks in new Web > >>>>UI: http://abbra.fedorapeople.org/.paste/freeipa-sid-resolve-new-web-ui.gif > >>> > >>>I only see the SIDs with your patches applied. I used master with your git > >>>patches. Do I need the patches for the new WebUI and your additional > >>>patch for that as well? > >>GIT master with my patches should be enough -- if you used 0103 revision 1 > >> > >>Additional patch part is only for new Web UI rebase for > >>instal/ui/src/freeipa/* > >> > >>-- > >>/ Alexander Bokovoy > > > >_______________________________________________ > >Freeipa-devel mailing list > >Freeipa-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > > -- > Petr Vobornik From tbabej at redhat.com Mon May 6 10:39:14 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 06 May 2013 12:39:14 +0200 Subject: [Freeipa-devel] [PATCH 0146] Disallow all dynamic updates if update policy configuration failed In-Reply-To: <516D0E7A.50202@redhat.com> References: <516D0E7A.50202@redhat.com> Message-ID: <51878852.4010802@redhat.com> On 04/16/2013 10:40 AM, Petr Spacek wrote: > Hello, > > Disallow all dynamic updates if update policy configuration failed. > > Without this patch the old update policy stays in effect > when re-configuration failed. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works as expected. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon May 6 11:05:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 06 May 2013 13:05:42 +0200 Subject: [Freeipa-devel] [PATCH] 403 Update pki proxy configuration In-Reply-To: <51876621.4070903@redhat.com> References: <51876621.4070903@redhat.com> Message-ID: <51878E86.50200@redhat.com> On 05/06/2013 10:13 AM, Martin Kosek wrote: > Replicas with Dogtag pki-ca 10.0.2 CA require access to additional > Dogtag REST API calls. Update pki proxy configuration to allow that. > > https://fedorahosted.org/freeipa/ticket/3601 > With this, Rob's patch 1100 and the latest Dogtag (10.0.2-4), the CA replica installs and works, both with a new and upgraded server. ACK -- Petr? From pviktori at redhat.com Mon May 6 11:05:48 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 06 May 2013 13:05:48 +0200 Subject: [Freeipa-devel] Possible fix for CA install bug? In-Reply-To: <518394B6.5090203@redhat.com> References: <1367511689.29881.14.camel@localhost.localdomain> <5182A763.6030801@redhat.com> <5182A791.50503@redhat.com> <518394B6.5090203@redhat.com> Message-ID: <51878E8C.1000503@redhat.com> On 05/03/2013 12:43 PM, Martin Kosek wrote: > On 05/02/2013 07:51 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Nathaniel McCallum wrote: >>>> When installing beta1, I encountered a bug where the CA install would >>>> fail. This may have already been fixed in dogtag or elsewhere, but if >>>> not, this patch WorksForMe. I have no idea if it is the "right" fix. >>> >>> Good catch. This change apparently was added during the last week of >>> 10.0.2 development and I'm not sure how I missed it. I did at least one >>> successful install using those bits. Maybe either my test was bogus or I >>> had left-over kruft. >>> >>> In any case, we can specify the location directly to pkispawn and not >>> have to move the file. >> >> BTW, My patch 1098 bumps up the minimum version of dogtag to 10.0.2. >> >> rob > > I tested 1100 and it works great on master server. However when I am on > replica, it always fails: > > # ipa-ca-install replica-info-vm-024.idm.lab.bos.redhat.com.gpg > Directory Manager (existing master) password: > ... > Connection check OK > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/16]: creating certificate server user > [2/16]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpRR0ic3' returned non-zero exit status 1 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > > CA installation log including pkispawn error attached. > > Martin > The bug Martin found was unrelated, and will be fixed with https://fedorahosted.org/freeipa/ticket/3601. ACK for rcrit-1100. -- Petr? From mkosek at redhat.com Mon May 6 11:28:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 May 2013 13:28:52 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504051317.GW7607@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> Message-ID: <518793F4.7050507@redhat.com> On 05/04/2013 07:13 AM, Alexander Bokovoy wrote: > On Fri, 03 May 2013, Sumit Bose wrote: >> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached are patches to allow resolving SIDs in Web UI in external >>> membership panel for groups. Please see more detailed description in the >>> main patch. >>> >>> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >>> should be simple. >>> >>> https://fedorahosted.org/freeipa/ticket/3302 >>> >>> Since framework doesn't allow to hide commands from CLI, underlying >>> command is usable from CLI too: >>> # ipa trust-resolve >>> --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >>> Name: enterprise read-only domain controllers at ad.lan >>> SID: S-1-5-21-3502988750-125904550-3683905862-498 >>> >>> Name: administrator at ad.lan >>> SID: S-1-5-21-3502988750-125904550-3683905862-500 >>> >>> Name: domain admins at ad.lan >>> SID: S-1-5-21-3502988750-125904550-3683905862-512 >>> >>> -- >>> / Alexander Bokovoy >>> + try: >>> + sids = map(lambda x: str(x), options['sids']) >>> + xlate = pysss_nss_idmap.getnamebysid(sids) >> >> The latest version, which is already committed to sssd, return a dict. >> The output of ipa trust-resolve now look like: >> >> [root at ipa18-devel ~]# ipa trust-resolve >> --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >> SID: S-1-5-21-3090815309-2627318493-3395719201-500 >> >> Name: {'type': 2, 'name': u'enterprise read-only domain >> controllers at ad18.ipa18.devel'} >> SID: S-1-5-21-3090815309-2627318493-3395719201-498 >> >> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >> SID: S-1-5-21-3090815309-2627318493-3395719201-513 >> >>> + for sid in xlate: >>> + entry = dict() >>> + entry['sid'] = [unicode(sid)] >>> + entry['name'] = [unicode(xlate[sid])] >> >> I think you need entry['name'] = >> [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >> here. > Fixed, thanks! > I also added type conversion to a text (user, group, both). The type is not > shown by default > in CLI but is available through --all option. We might consider using it > in Web UI for visual hint about the name nature. > >> I tried with firefox, but the SIDs of the external members are not >> resolved. Do I have to clean any firefox cache? > No, you do not. When picking up changes from my development VM, I > omitted one chunk in group.js where sid_facet was actually taken in use. > Without that one nothing is used. > > Updated patch 0103 is attached, tested against sssd in ipa-devel repo > which already includes your patches. > Thanks for the patch! Still, I have few comments: 1) Exception should be raised instead of returning empty result: + if not _nss_idmap_installed: + return dict(result=result) Otherwise people will be confused what's wrong. 2) Why do we hide error raised in SID processing code? ... + except ValueError, e: + pass ... I think that the try-catch should be as localized possible, ideally in the FOR loop. If processing of the second SID out of 10 fails, just one SID would be return, with no additional error. People will be confused what's wrong: # ipa trust-resolve --sids S-1-5-21-3035198329-144811719-1378114514-500 # This does not really tell me what's wrong. Could we rather return all requested SIDs either with a proper result or with a respective error? This is how I would image the translation to look like: ... try: sids = map(lambda x: str(x), options['sids']) xlate = pysss_nss_idmap.getnamebysid(sids) except SomeError, e: raise SomeException(e) for sid in xlate: entry = dict() entry['sid'] = ... try: name = ... type = ... entry['name'], entry['type'] = name, type except SomeError, e: entry['failedtranslation'] = unicode(e) results.append(entry) ... I filed ticket for SSSD part of the issue: https://fedorahosted.org/sssd/ticket/1911 3) Tab/Space indentation mix: + for sid in xlate: + entry = dict() + entry['sid'] = [unicode(sid)] 4) Unneeded import: from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object +from types import NoneType from ipalib.parameters import Enu Martin From mkosek at redhat.com Mon May 6 11:35:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 May 2013 13:35:45 +0200 Subject: [Freeipa-devel] [PATCH] 403 Update pki proxy configuration In-Reply-To: <51878E86.50200@redhat.com> References: <51876621.4070903@redhat.com> <51878E86.50200@redhat.com> Message-ID: <51879591.5020905@redhat.com> On 05/06/2013 01:05 PM, Petr Viktorin wrote: > On 05/06/2013 10:13 AM, Martin Kosek wrote: >> Replicas with Dogtag pki-ca 10.0.2 CA require access to additional >> Dogtag REST API calls. Update pki proxy configuration to allow that. >> >> https://fedorahosted.org/freeipa/ticket/3601 >> > > With this, Rob's patch 1100 and the latest Dogtag (10.0.2-4), the CA replica > installs and works, both with a new and upgraded server. > > ACK > Thanks. Pushed to master, ipa-3-1. Martin From mkosek at redhat.com Mon May 6 11:38:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 May 2013 13:38:19 +0200 Subject: [Freeipa-devel] Possible fix for CA install bug? In-Reply-To: <51878E8C.1000503@redhat.com> References: <1367511689.29881.14.camel@localhost.localdomain> <5182A763.6030801@redhat.com> <5182A791.50503@redhat.com> <518394B6.5090203@redhat.com> <51878E8C.1000503@redhat.com> Message-ID: <5187962B.8000001@redhat.com> On 05/06/2013 01:05 PM, Petr Viktorin wrote: > On 05/03/2013 12:43 PM, Martin Kosek wrote: >> On 05/02/2013 07:51 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Nathaniel McCallum wrote: >>>>> When installing beta1, I encountered a bug where the CA install would >>>>> fail. This may have already been fixed in dogtag or elsewhere, but if >>>>> not, this patch WorksForMe. I have no idea if it is the "right" fix. >>>> >>>> Good catch. This change apparently was added during the last week of >>>> 10.0.2 development and I'm not sure how I missed it. I did at least one >>>> successful install using those bits. Maybe either my test was bogus or I >>>> had left-over kruft. >>>> >>>> In any case, we can specify the location directly to pkispawn and not >>>> have to move the file. >>> >>> BTW, My patch 1098 bumps up the minimum version of dogtag to 10.0.2. >>> >>> rob >> >> I tested 1100 and it works great on master server. However when I am on >> replica, it always fails: >> >> # ipa-ca-install replica-info-vm-024.idm.lab.bos.redhat.com.gpg >> Directory Manager (existing master) password: >> ... >> Connection check OK >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >> seconds >> [1/16]: creating certificate server user >> [2/16]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpRR0ic3' returned non-zero exit status 1 >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Configuration of CA failed >> >> CA installation log including pkispawn error attached. >> >> Martin >> > > The bug Martin found was unrelated, and will be fixed with > https://fedorahosted.org/freeipa/ticket/3601. Right. > > ACK for rcrit-1100. > Pushed to master, ipa-3-1. Martin From pvoborni at redhat.com Mon May 6 11:48:19 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 06 May 2013 13:48:19 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130504060400.GX7607@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <20130504060400.GX7607@redhat.com> Message-ID: <51879883.3010502@redhat.com> Hello, here is review of Web UI part. ACK for abbra-102, it's a fix of error (typo), but it won't probably have any impact. Because links associated with 'a' elements are different than the resulting ones. NACK for abbra-103: NACK for abbra-pvoborni... (is included in new abbra-103) Are CLI and IPA-API parts of old abbra-103 in some different patch? We should make proper patches from the API/CLI part and WebUI part. Because of this I didn't test following fixes by using installed IPA with established trust. Attaching a diff with fixes for following errors of abbra-103: 1) There are jslint errors (missing semicolons, extra semicolons, trailing commas) (run `jslint -conf jsl.conf` in install/ui dir) Funny thing, I do the exact opposite mistakes when writing python code. 2) Do not use deferred directly as a value, use promise instead: > value[i][that.attribute] = { > promise: deferred.promise, > temp: sid > }; Latter is better because promise can't be changed by consumer component. Its resolution is still controlled by deferred. 3) We should not call trust-resolve when there are no sids. It's pointless and trust-resolve requires at least one sid (`Str('sids+',`) 4) I see that you copied attribute facet preop as sid preop but omitted adding of facet update policy. Is there a reason for it? IMO it's better just to copy the whole or don't do it at all and just specified the facet as: $type: 'attribute', $factory: IPA.sid_facet, This change is in fix2.diff. Nitpicks: a) Use `[]` instead of `new Array()` b) add space before `for` c) specifying sids: '' in command construction is not needed - it's set later -- Petr On 05/04/2013 08:04 AM, Alexander Bokovoy wrote: > On Sat, 04 May 2013, Alexander Bokovoy wrote: >> On Fri, 03 May 2013, Sumit Bose wrote: >>> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Attached are patches to allow resolving SIDs in Web UI in external >>>> membership panel for groups. Please see more detailed description in >>>> the >>>> main patch. >>>> >>>> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >>>> should be simple. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3302 >>>> >>>> Since framework doesn't allow to hide commands from CLI, underlying >>>> command is usable from CLI too: >>>> # ipa trust-resolve >>>> --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >>>> Name: enterprise read-only domain controllers at ad.lan >>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 >>>> >>>> Name: administrator at ad.lan >>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 >>>> >>>> Name: domain admins at ad.lan >>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 >>>> >>>> -- >>>> / Alexander Bokovoy >>>> + try: >>>> + sids = map(lambda x: str(x), options['sids']) >>>> + xlate = pysss_nss_idmap.getnamebysid(sids) >>> >>> The latest version, which is already committed to sssd, return a dict. >>> The output of ipa trust-resolve now look like: >>> >>> [root at ipa18-devel ~]# ipa trust-resolve >>> --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 >>> >>> Name: {'type': 2, 'name': u'enterprise read-only domain >>> controllers at ad18.ipa18.devel'} >>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 >>> >>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 >>> >>>> + for sid in xlate: >>>> + entry = dict() >>>> + entry['sid'] = [unicode(sid)] >>>> + entry['name'] = [unicode(xlate[sid])] >>> >>> I think you need entry['name'] = >>> [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >>> here. >> Fixed, thanks! >> I also added type conversion to a text (user, group, both). The type >> is not shown by default >> in CLI but is available through --all option. We might consider using it >> in Web UI for visual hint about the name nature. >> >>> I tried with firefox, but the SIDs of the external members are not >>> resolved. Do I have to clean any firefox cache? >> No, you do not. When picking up changes from my development VM, I >> omitted one chunk in group.js where sid_facet was actually taken in use. >> Without that one nothing is used. >> >> Updated patch 0103 is attached, tested against sssd in ipa-devel repo >> which already includes your patches. > > ... and here is rebase of install/ui/src/freeipa to Web UI refactoring > branch, to help testing on top of Petr's changes. With this patch SID > resolving works in new Web UI. > > There are probably some changes that could further be removed, I haven't > looked into greater detail. > > Please note that attached patch only covers parts in > install/ui/src/freeipa, you'd still need to add plugin changes from > ipalib/plugins/trust.py. > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: abbra-103-fix1.diff Type: text/x-patch Size: 1940 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abbra-103-fix2.diff Type: text/x-patch Size: 2055 bytes Desc: not available URL: From pspacek at redhat.com Mon May 6 12:03:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 May 2013 14:03:10 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <516FB717.9010203@redhat.com> References: <516FB717.9010203@redhat.com> Message-ID: <51879BFE.90601@redhat.com> On 18.4.2013 11:04, Petr Spacek wrote: > Hello, > > Clean up PTR record synchronization code and make it more robust. > > PTR record synchronization was split to smaller functions. > Input validation, error handling and logging was improved > significantly. Tbabej's GCC cries about uninitialized variable 'ptr_a_equal', but we weren't able to find any real error. This version of the patch contains a workaround for the GCC oddities. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0149-2-Clean-up-PTR-record-synchronization-code-and-make-it.patch Type: text/x-patch Size: 19012 bytes Desc: not available URL: From pspacek at redhat.com Mon May 6 12:04:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 May 2013 14:04:24 +0200 Subject: [Freeipa-devel] [PATCH 0150] Do not delete whole node during PTR record synchronization. In-Reply-To: <51700A04.3070305@redhat.com> References: <51700A04.3070305@redhat.com> Message-ID: <51879C48.9040709@redhat.com> On 18.4.2013 16:58, Petr Spacek wrote: > Hello, > > Do not delete whole node during PTR record synchronization. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/115 Tbabej's GCC cries about uninitialized variable 'delete_node', but we weren't able to find any real error. This version of the patch contains a workaround for the GCC oddities. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0150-2-Do-not-delete-whole-node-during-PTR-record-synchroni.patch Type: text/x-patch Size: 4184 bytes Desc: not available URL: From tbabej at redhat.com Mon May 6 12:45:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 06 May 2013 14:45:52 +0200 Subject: [Freeipa-devel] [PATCH 0147] Improve error logging for zones with idnsAllowDynUpdate == FALSE. In-Reply-To: <516D2B89.1090506@redhat.com> References: <516D2B89.1090506@redhat.com> Message-ID: <5187A600.4060604@redhat.com> On 04/16/2013 12:44 PM, Petr Spacek wrote: > Hello, > > Improve error logging for zones with idnsAllowDynUpdate == FALSE. > > Zones with dynamic updates disabled are re-configured with empty > update policy string, so the update is refused by BIND and > an error is logged. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works fine. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon May 6 13:28:59 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 06 May 2013 15:28:59 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <51879BFE.90601@redhat.com> References: <516FB717.9010203@redhat.com> <51879BFE.90601@redhat.com> Message-ID: <5187B01B.1060808@redhat.com> On 05/06/2013 02:03 PM, Petr Spacek wrote: > On 18.4.2013 11:04, Petr Spacek wrote: >> Hello, >> >> Clean up PTR record synchronization code and make it more robust. >> >> PTR record synchronization was split to smaller functions. >> Input validation, error handling and logging was improved >> significantly. > > Tbabej's GCC cries about uninitialized variable 'ptr_a_equal', but we > weren't able to find any real error. > > This version of the patch contains a workaround for the GCC oddities. > This fixes the problem. It was caused by turning on the gcc's optimalization flag -O2. ACK from me. Since this was a rather robust code change, a look second pair of eyes would be helpful. Tomas From tbabej at redhat.com Mon May 6 13:29:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 06 May 2013 15:29:08 +0200 Subject: [Freeipa-devel] [PATCH 0150] Do not delete whole node during PTR record synchronization. In-Reply-To: <51879C48.9040709@redhat.com> References: <51700A04.3070305@redhat.com> <51879C48.9040709@redhat.com> Message-ID: <5187B024.9020201@redhat.com> On 05/06/2013 02:04 PM, Petr Spacek wrote: > On 18.4.2013 16:58, Petr Spacek wrote: >> Hello, >> >> Do not delete whole node during PTR record synchronization. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/115 > > Tbabej's GCC cries about uninitialized variable 'delete_node', but we > weren't able to find any real error. > > This version of the patch contains a workaround for the GCC oddities. > This fixes the problem. It was caused by turning on the optimalization flag -O2. The patch works as expected, PTR record node is deleted if and only if it contains only pTRRecord. ACK. Tomas From pvoborni at redhat.com Mon May 6 15:05:20 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 06 May 2013 17:05:20 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <518758D9.6030003@redhat.com> References: <51756B5E.8030604@redhat.com> <5183F576.6070109@redhat.com> <518758D9.6030003@redhat.com> Message-ID: <5187C6B0.60200@redhat.com> On 05/06/2013 09:16 AM, Martin Kosek wrote: > On 05/03/2013 07:35 PM, Endi Sukma Dewata wrote: >> >> In general there is no major issue that would warrant a NACK. As long as the >> API is well documented for plugin writers it should be sufficient. >> > > Thanks for review Endi! Since we do not have a NACK, lets do small changes we > can do now for 3.2 GA and create tickets for the rest (can be done in 3.2 > stabilization phase). > > Martin > The beast is pushed to master. It's 136 commits: since f0c1c629d38bc34c5e8accd2971784c825c1319c to aedded862dce2c8450d0eef5eca3d854166af06b -- Petr Vobornik From thozza at redhat.com Mon May 6 15:40:37 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 06 May 2013 17:40:37 +0200 Subject: [Freeipa-devel] [PATCH 0141] Generalize attribute_name<->rdata_type conversions. In-Reply-To: <51630222.3010807@redhat.com> References: <51630222.3010807@redhat.com> Message-ID: <5187CEF5.7030200@redhat.com> On 04/08/2013 07:45 PM, Petr Spacek wrote: > Hello, > > Generalize attribute_name<->rdata_type conversions. > > Attribute names are generated on-the-fly: String "Record" is appended > to textual representation of DNS RDATA type. > > String "Record" is cut down from the attribute name during > attribute name to rdata type conversion. > > From now, the plugin doesn't add artificial limitation to supported > record types. ACK. The patch looks good. (I didn't do functional test) Cosmetic issue: I think it would be good to dynamically allocate "mod_type" in LDAPMod in every case and include the "mod_type" memory freeing in free_ldapmod() function. Now one has to be be careful when it is statically or dynamically allocated. Before it was static in every case. Regards, Tomas Hozza From mkosek at redhat.com Mon May 6 15:55:35 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 May 2013 17:55:35 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <518793F4.7050507@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <518793F4.7050507@redhat.com> Message-ID: <5187D277.9090902@redhat.com> On 05/06/2013 01:28 PM, Martin Kosek wrote: > On 05/04/2013 07:13 AM, Alexander Bokovoy wrote: >> On Fri, 03 May 2013, Sumit Bose wrote: >>> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Attached are patches to allow resolving SIDs in Web UI in external >>>> membership panel for groups. Please see more detailed description in the >>>> main patch. >>>> >>>> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >>>> should be simple. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3302 >>>> >>>> Since framework doesn't allow to hide commands from CLI, underlying >>>> command is usable from CLI too: >>>> # ipa trust-resolve >>>> --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >>>> Name: enterprise read-only domain controllers at ad.lan >>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 >>>> >>>> Name: administrator at ad.lan >>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 >>>> >>>> Name: domain admins at ad.lan >>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 >>>> >>>> -- >>>> / Alexander Bokovoy >>>> + try: >>>> + sids = map(lambda x: str(x), options['sids']) >>>> + xlate = pysss_nss_idmap.getnamebysid(sids) >>> >>> The latest version, which is already committed to sssd, return a dict. >>> The output of ipa trust-resolve now look like: >>> >>> [root at ipa18-devel ~]# ipa trust-resolve >>> --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 >>> >>> Name: {'type': 2, 'name': u'enterprise read-only domain >>> controllers at ad18.ipa18.devel'} >>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 >>> >>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 >>> >>>> + for sid in xlate: >>>> + entry = dict() >>>> + entry['sid'] = [unicode(sid)] >>>> + entry['name'] = [unicode(xlate[sid])] >>> >>> I think you need entry['name'] = >>> [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >>> here. >> Fixed, thanks! >> I also added type conversion to a text (user, group, both). The type is not >> shown by default >> in CLI but is available through --all option. We might consider using it >> in Web UI for visual hint about the name nature. >> >>> I tried with firefox, but the SIDs of the external members are not >>> resolved. Do I have to clean any firefox cache? >> No, you do not. When picking up changes from my development VM, I >> omitted one chunk in group.js where sid_facet was actually taken in use. >> Without that one nothing is used. >> >> Updated patch 0103 is attached, tested against sssd in ipa-devel repo >> which already includes your patches. >> > > Thanks for the patch! Still, I have few comments: > > 1) Exception should be raised instead of returning empty result: > > + if not _nss_idmap_installed: > + return dict(result=result) > > Otherwise people will be confused what's wrong. > > 2) Why do we hide error raised in SID processing code? > > ... > + except ValueError, e: > + pass > ... > > I think that the try-catch should be as localized possible, ideally in the FOR > loop. If processing of the second SID out of 10 fails, just one SID would be > return, with no additional error. People will be confused what's wrong: > > # ipa trust-resolve --sids S-1-5-21-3035198329-144811719-1378114514-500 > # > > This does not really tell me what's wrong. > > Could we rather return all requested SIDs either with a proper result or with a > respective error? This is how I would image the translation to look like: > > ... > try: > sids = map(lambda x: str(x), options['sids']) > xlate = pysss_nss_idmap.getnamebysid(sids) > except SomeError, e: > raise SomeException(e) > > for sid in xlate: > entry = dict() > entry['sid'] = ... > try: > name = ... > type = ... > entry['name'], entry['type'] = name, type > except SomeError, e: > entry['failedtranslation'] = unicode(e) > results.append(entry) > ... > > > I filed ticket for SSSD part of the issue: > https://fedorahosted.org/sssd/ticket/1911 > > 3) Tab/Space indentation mix: > > + for sid in xlate: > + entry = dict() > + entry['sid'] = [unicode(sid)] > > > 4) Unneeded import: > from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object > +from types import NoneType > from ipalib.parameters import Enu > > > Martin > As Alexander is not here ATM, sending updated patch based on current master branch (with Web UI refactoring) which also includes few squashes: - fix for my point 3) - fix for my point 4) - squashed Petr Vobornik's Web UI cleanups I tested it and it worked fine. As for the points 1) and 2) I will file a ticket, these are not critical. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-abbra-0103-2-Resolve-SIDs-in-Web-UI.patch Type: text/x-patch Size: 9928 bytes Desc: not available URL: From pvoborni at redhat.com Mon May 6 16:20:05 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 06 May 2013 18:20:05 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <5183F576.6070109@redhat.com> References: <51756B5E.8030604@redhat.com> <5183F576.6070109@redhat.com> Message-ID: <5187D835.5040000@redhat.com> On 05/03/2013 07:35 PM, Endi Sukma Dewata wrote: > Hi, > > Sorry for the delay, I have some questions & comments. > > Registry: > > In the simpleuser.js the new 'user' entity is registered first then the > old 'user' entity is removed, which could be confusing because they are > both identified using 'user'. Should register() automatically remove the > old object? I've mixed feelings about it. I would rather keep the methods simple - one task oriented. The issue was caused by other problem: The plugin had to wait for metadata and profile information (to check self-service). So the callback is called after menu is created and menu requires the entity to be resolved. Should we postpone the menu creation to a different phase? Maybe a new one? > Ideally a class should have complete methods to manage the > objects it stores (e.g. unregister(), remove()). This can be added. > > How is reg.entity created? Are there others beside 'entity'? Registries are created in related modules. So reg.entity get instantiated at the end of entity.js. There is one for each object type, which are, IIRC: action, facet, entity, field, validator and some others. > > How is Registries_registry in reg.js used? It doesn't seem to be used > anywhere else. Wow, I forgot about this peace of code. It isn't and should be removed. > > Plugins: > > In plugins.py the list of plugins is generated using os.listdir(). Then > each plugin also has a list of dependencies which I suppose can include > other plugins. Then when registering the plugin task, it will have a > priority as well. > > So there seem to be several factors that determine the execution order > of the plugins. There should be a document explaining how this will > work, so plugin writers can be sure that the code will be executed at > the right time. > > In general I'd avoid using task priority because it doesn't guarantee > the correct execution order unless the priorities of all tasks are well > coordinated (which might be challenging if there are multiple plugins > owned by different people). You are right and it gets more complicated with asynchronous tasks. If one wants to react to an asynchronous task, he has to do it next phase. We might set some fixed priorities for certain operations. Anyway the documentation is essential. > > Could you add more examples of simple plugins for various scenarios > including custom entity, custom facet, custom field, custom menu? They > can be included in the RPM for reference. Yes, I that's my plan. Another reason to do it to find limitations. > > Writing a plugin seems to still require programming skills, reliance on > good docs, and probably even some source code familiarity. What do you > think about simplifying this a little further? So we'll have 2 ways to > define a plugin: one is programatically using the current framework > already implemented (e.g. simpleuser.js), and the other is completely > declaratively using a plain json data (e.g. simpleuser.json). The > declarative plugin will obviously be more limited, but much simpler to use. I agree with the idea. But before creating declarative JSON format we should come up with a plugin API, which would be more-or-less stable and therefore plugins might be resilient to Web UI internals changes. When we have this API we might map it to a JSON representation. The hard part will be to find all the use-cases to cover. > > Builder: > >> b) Second big issue was build of objects. Entities and facets have >> complex build logic. It can be simplified into three steps: >> 1) modifications of spec >> 2) creation of object and class inheritance >> 3) init logic > > Yes, creating an object has become very complicated now with the > builders, factories, constructors, preops, postops, inits, overrides, > diff, etc. I think the problem is that we're trying to create/modify the > spec before creating the object and we need a whole set of mechanisms to > do that. Maybe we can simplify it into two basic steps: > > 1. Create an empty/simple object. > 2. Initialize the object. > > The initialization process could be split further into smaller > operations such as: > > * Load the spec and modify it if necessary > * Creating dependent objects and initializing them > * Other initialization steps > > The builder, factory, preops, and postops can be included as part of the > initialization step. They can be normal class methods rather than > loosely defined functions and can be overridden by subclasses. There's > probably a lot more details that need to be discussed. +1 Rewriting all the factories into classes will be a huge task though. At the moment, the biggest problem are spec modification which are not defaults (so they can't be overriden). Like the ones described bellow - #2. > >> 1. Move ./_base/metadata_provider to ./metadata? >> Might simplify stuff. > > This seems to be IPA-specific, so yes. https://fedorahosted.org/freeipa/ticket/3604 > >> 2. Move actions/buttons spec from factories to pre_ops associated with >> the factories. >> >> Example of stuff to be moved (search.js): >> spec.actions = spec.actions || []; >> spec.actions.unshift( >> 'refresh', >> 'batch_remove', >> 'add'); >> >> It may simplify/allow removal of those items in spec or pre_ops of child >> factories. Currently there is no way how to intercept them. https://fedorahosted.org/freeipa/ticket/3605 > > Sure, I don't see any problem with that. > > In general there is no major issue that would warrant a NACK. As long as > the API is well documented for plugin writers it should be sufficient. > -- Petr Vobornik From sbose at redhat.com Mon May 6 17:03:10 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 6 May 2013 19:03:10 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <5187D277.9090902@redhat.com> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <518793F4.7050507@redhat.com> <5187D277.9090902@redhat.com> Message-ID: <20130506170310.GB4481@localhost.localdomain> On Mon, May 06, 2013 at 05:55:35PM +0200, Martin Kosek wrote: > On 05/06/2013 01:28 PM, Martin Kosek wrote: > > On 05/04/2013 07:13 AM, Alexander Bokovoy wrote: > >> On Fri, 03 May 2013, Sumit Bose wrote: > >>> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: > >>>> Hi! > >>>> > >>>> Attached are patches to allow resolving SIDs in Web UI in external > >>>> membership panel for groups. Please see more detailed description in the > >>>> main patch. > >>>> > >>>> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it > >>>> should be simple. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/3302 > >>>> > >>>> Since framework doesn't allow to hide commands from CLI, underlying > >>>> command is usable from CLI too: > >>>> # ipa trust-resolve > >>>> --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} > >>>> Name: enterprise read-only domain controllers at ad.lan > >>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 > >>>> > >>>> Name: administrator at ad.lan > >>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 > >>>> > >>>> Name: domain admins at ad.lan > >>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 > >>>> > >>>> -- > >>>> / Alexander Bokovoy > >>>> + try: > >>>> + sids = map(lambda x: str(x), options['sids']) > >>>> + xlate = pysss_nss_idmap.getnamebysid(sids) > >>> > >>> The latest version, which is already committed to sssd, return a dict. > >>> The output of ipa trust-resolve now look like: > >>> > >>> [root at ipa18-devel ~]# ipa trust-resolve > >>> --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} > >>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} > >>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 > >>> > >>> Name: {'type': 2, 'name': u'enterprise read-only domain > >>> controllers at ad18.ipa18.devel'} > >>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 > >>> > >>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} > >>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 > >>> > >>>> + for sid in xlate: > >>>> + entry = dict() > >>>> + entry['sid'] = [unicode(sid)] > >>>> + entry['name'] = [unicode(xlate[sid])] > >>> > >>> I think you need entry['name'] = > >>> [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] > >>> here. > >> Fixed, thanks! > >> I also added type conversion to a text (user, group, both). The type is not > >> shown by default > >> in CLI but is available through --all option. We might consider using it > >> in Web UI for visual hint about the name nature. > >> > >>> I tried with firefox, but the SIDs of the external members are not > >>> resolved. Do I have to clean any firefox cache? > >> No, you do not. When picking up changes from my development VM, I > >> omitted one chunk in group.js where sid_facet was actually taken in use. > >> Without that one nothing is used. > >> > >> Updated patch 0103 is attached, tested against sssd in ipa-devel repo > >> which already includes your patches. > >> > > > > Thanks for the patch! Still, I have few comments: > > > > 1) Exception should be raised instead of returning empty result: > > > > + if not _nss_idmap_installed: > > + return dict(result=result) > > > > Otherwise people will be confused what's wrong. > > > > 2) Why do we hide error raised in SID processing code? > > > > ... > > + except ValueError, e: > > + pass > > ... > > > > I think that the try-catch should be as localized possible, ideally in the FOR > > loop. If processing of the second SID out of 10 fails, just one SID would be > > return, with no additional error. People will be confused what's wrong: > > > > # ipa trust-resolve --sids S-1-5-21-3035198329-144811719-1378114514-500 > > # > > > > This does not really tell me what's wrong. > > > > Could we rather return all requested SIDs either with a proper result or with a > > respective error? This is how I would image the translation to look like: > > > > ... > > try: > > sids = map(lambda x: str(x), options['sids']) > > xlate = pysss_nss_idmap.getnamebysid(sids) > > except SomeError, e: > > raise SomeException(e) > > > > for sid in xlate: > > entry = dict() > > entry['sid'] = ... > > try: > > name = ... > > type = ... > > entry['name'], entry['type'] = name, type > > except SomeError, e: > > entry['failedtranslation'] = unicode(e) > > results.append(entry) > > ... > > > > > > I filed ticket for SSSD part of the issue: > > https://fedorahosted.org/sssd/ticket/1911 > > > > 3) Tab/Space indentation mix: > > > > + for sid in xlate: > > + entry = dict() > > + entry['sid'] = [unicode(sid)] > > > > > > 4) Unneeded import: > > from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object > > +from types import NoneType > > from ipalib.parameters import Enu > > > > > > Martin > > > > As Alexander is not here ATM, sending updated patch based on current master > branch (with Web UI refactoring) which also includes few squashes: > - fix for my point 3) > - fix for my point 4) > - squashed Petr Vobornik's Web UI cleanups > > I tested it and it worked fine. As for the points 1) and 2) I will file a > ticket, these are not critical. > > Martin Patch is working as expected. So ACK from my side for the functional part. bye, Sumit From pspacek at redhat.com Mon May 6 17:56:09 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 06 May 2013 19:56:09 +0200 Subject: [Freeipa-devel] Cyrus SASL problem on Fedora 19? [heads up] Message-ID: <5187EEB9.8060703@redhat.com> Hello list, heads up - we have some problems with Cyrus SASL in Fedora 19. SASL connections via Unix socket are failing with weird error: (Note the 'SOCKET' piece.) $ ldapsearch -Y GSSAPI -H 'ldapi://%2fvar%2frun%2fslapd-TESTRELM-COM.socket' SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/SOCKET at TESTRELM.COM not found in Kerberos database) See https://bugzilla.redhat.com/show_bug.cgi?id=960222 for all the gory details. -- Petr^2 Spacek From mkosek at redhat.com Mon May 6 18:46:11 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 May 2013 20:46:11 +0200 Subject: [Freeipa-devel] [PATCH] Resolve SIDs in Web UI In-Reply-To: <20130506170310.GB4481@localhost.localdomain> References: <20130503184647.GV7607@redhat.com> <20130503202957.GI26881@localhost.localdomain> <20130504051317.GW7607@redhat.com> <518793F4.7050507@redhat.com> <5187D277.9090902@redhat.com> <20130506170310.GB4481@localhost.localdomain> Message-ID: <5187FA73.6010401@redhat.com> On 05/06/2013 07:03 PM, Sumit Bose wrote: > On Mon, May 06, 2013 at 05:55:35PM +0200, Martin Kosek wrote: >> On 05/06/2013 01:28 PM, Martin Kosek wrote: >>> On 05/04/2013 07:13 AM, Alexander Bokovoy wrote: >>>> On Fri, 03 May 2013, Sumit Bose wrote: >>>>> On Fri, May 03, 2013 at 09:46:47PM +0300, Alexander Bokovoy wrote: >>>>>> Hi! >>>>>> >>>>>> Attached are patches to allow resolving SIDs in Web UI in external >>>>>> membership panel for groups. Please see more detailed description in the >>>>>> main patch. >>>>>> >>>>>> I haven't rebased it yet on top of Petr's Web UI rework, hopefully it >>>>>> should be simple. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3302 >>>>>> >>>>>> Since framework doesn't allow to hide commands from CLI, underlying >>>>>> command is usable from CLI too: >>>>>> # ipa trust-resolve >>>>>> --sids=S-1-5-21-3502988750-125904550-3683905862-{500,512,498} >>>>>> Name: enterprise read-only domain controllers at ad.lan >>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-498 >>>>>> >>>>>> Name: administrator at ad.lan >>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-500 >>>>>> >>>>>> Name: domain admins at ad.lan >>>>>> SID: S-1-5-21-3502988750-125904550-3683905862-512 >>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>>> + try: >>>>>> + sids = map(lambda x: str(x), options['sids']) >>>>>> + xlate = pysss_nss_idmap.getnamebysid(sids) >>>>> >>>>> The latest version, which is already committed to sssd, return a dict. >>>>> The output of ipa trust-resolve now look like: >>>>> >>>>> [root at ipa18-devel ~]# ipa trust-resolve >>>>> --sids=S-1-5-21-3090815309-2627318493-3395719201-{498,500,513} >>>>> Name: {'type': 3, 'name': u'administrator at ad18.ipa18.devel'} >>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-500 >>>>> >>>>> Name: {'type': 2, 'name': u'enterprise read-only domain >>>>> controllers at ad18.ipa18.devel'} >>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-498 >>>>> >>>>> Name: {'type': 2, 'name': u'domain users at ad18.ipa18.devel'} >>>>> SID: S-1-5-21-3090815309-2627318493-3395719201-513 >>>>> >>>>>> + for sid in xlate: >>>>>> + entry = dict() >>>>>> + entry['sid'] = [unicode(sid)] >>>>>> + entry['name'] = [unicode(xlate[sid])] >>>>> >>>>> I think you need entry['name'] = >>>>> [unicode(xlate[sid][pysss_nss_idmap.NAME_KEY])] >>>>> here. >>>> Fixed, thanks! >>>> I also added type conversion to a text (user, group, both). The type is not >>>> shown by default >>>> in CLI but is available through --all option. We might consider using it >>>> in Web UI for visual hint about the name nature. >>>> >>>>> I tried with firefox, but the SIDs of the external members are not >>>>> resolved. Do I have to clean any firefox cache? >>>> No, you do not. When picking up changes from my development VM, I >>>> omitted one chunk in group.js where sid_facet was actually taken in use. >>>> Without that one nothing is used. >>>> >>>> Updated patch 0103 is attached, tested against sssd in ipa-devel repo >>>> which already includes your patches. >>>> >>> >>> Thanks for the patch! Still, I have few comments: >>> >>> 1) Exception should be raised instead of returning empty result: >>> >>> + if not _nss_idmap_installed: >>> + return dict(result=result) >>> >>> Otherwise people will be confused what's wrong. >>> >>> 2) Why do we hide error raised in SID processing code? >>> >>> ... >>> + except ValueError, e: >>> + pass >>> ... >>> >>> I think that the try-catch should be as localized possible, ideally in the FOR >>> loop. If processing of the second SID out of 10 fails, just one SID would be >>> return, with no additional error. People will be confused what's wrong: >>> >>> # ipa trust-resolve --sids S-1-5-21-3035198329-144811719-1378114514-500 >>> # >>> >>> This does not really tell me what's wrong. >>> >>> Could we rather return all requested SIDs either with a proper result or with a >>> respective error? This is how I would image the translation to look like: >>> >>> ... >>> try: >>> sids = map(lambda x: str(x), options['sids']) >>> xlate = pysss_nss_idmap.getnamebysid(sids) >>> except SomeError, e: >>> raise SomeException(e) >>> >>> for sid in xlate: >>> entry = dict() >>> entry['sid'] = ... >>> try: >>> name = ... >>> type = ... >>> entry['name'], entry['type'] = name, type >>> except SomeError, e: >>> entry['failedtranslation'] = unicode(e) >>> results.append(entry) >>> ... >>> >>> >>> I filed ticket for SSSD part of the issue: >>> https://fedorahosted.org/sssd/ticket/1911 >>> >>> 3) Tab/Space indentation mix: >>> >>> + for sid in xlate: >>> + entry = dict() >>> + entry['sid'] = [unicode(sid)] >>> >>> >>> 4) Unneeded import: >>> from ipalib import api, Str, StrEnum, Password, DefaultFrom, _, ngettext, Object >>> +from types import NoneType >>> from ipalib.parameters import Enu >>> >>> >>> Martin >>> >> >> As Alexander is not here ATM, sending updated patch based on current master >> branch (with Web UI refactoring) which also includes few squashes: >> - fix for my point 3) >> - fix for my point 4) >> - squashed Petr Vobornik's Web UI cleanups >> >> I tested it and it worked fine. As for the points 1) and 2) I will file a >> ticket, these are not critical. >> >> Martin > > Patch is working as expected. So ACK from my side for the functional > part. > > bye, > Sumit > Pushed to master. Martin From rcritten at redhat.com Tue May 7 03:38:27 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 06 May 2013 23:38:27 -0400 Subject: [Freeipa-devel] mod_auth_kerb and DIR ccache Message-ID: <51887733.7040008@redhat.com> The latest krb5 in F-19 updates-testing enables DIR ccache by default. This is breaking mod_auth_kerb. Attached is a WIP patch that works in permissive mode. At this point I'm not sure if we're better off trying to force a FILE ccache onto httpd in /tmp or go with the DIR method in which case we need to involve the SELinux folks. I think the DIR method is probably better long-term. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: ccache.patch Type: text/x-diff Size: 3023 bytes Desc: not available URL: From thozza at redhat.com Tue May 7 07:36:26 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 07 May 2013 09:36:26 +0200 Subject: [Freeipa-devel] [PATCH 0142] Improve LDAP error logging In-Reply-To: <51641740.5040601@redhat.com> References: <51641740.5040601@redhat.com> Message-ID: <5188AEFA.2040402@redhat.com> On 04/09/2013 03:27 PM, Petr Spacek wrote: > Hello, > > Improve LDAP error logging. > > Diagnostic error message is logged when it is available. > > > Plugin with this patch produces messages like: > > LDAP error: Server is unwilling to perform: Minimum SSF not met.: bind > to LDAP server failed > > intead of > > bind to LDAP server failed: Server is unwilling to perform > > > Second example is: > > LDAP error: Object class violation: attribute "mgrecord" not allowed > : while modifying(add) entry 'idnsName=pspacek, > idnsname=example.com,cn=dns,dc=e,dc=test' > > instead of > > "" > > :-D > > diff --git a/src/log.h b/src/log.h > index 312f24322fd0c6f9943c6beb810ac0bcd8f3896c..cbf1a3faaaccea7391d65d018e80d8ec688fc111 100644 > > --- a/src/log.h > > +++ b/src/log.h > > @@ -55,16 +55,30 @@ > > log_write(GET_LOG_LEVEL(level), format, ##__VA_ARGS__) > /* LDAP logging functions */ > -#define log_ldap_error(ld) \ > - do { \ > - int err; \ > - char *errmsg = ""; \ > - if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err) \ > - == LDAP_OPT_SUCCESS) \ > - errmsg = ldap_err2string(err); \ > - log_error_position("LDAP error: %s", errmsg); \ > - } while (0); \ > +#define LOG_LDAP_ERR_PREFIX "LDAP error: " > +#define log_ldap_error(ld, desc, ...) \ > + do { \ > + int err; \ > + char *errmsg = NULL; \ > + char *diagmsg = NULL; \ > + if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err) \ > + == LDAP_OPT_SUCCESS) { \ > + errmsg = ldap_err2string(err); \ Getting error msg for the first time here. > + if (ldap_get_option(ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, &diagmsg) \ > + == LDAP_OPT_SUCCESS && diagmsg != NULL) { \ > + errmsg = ldap_err2string(err); \ Again getting error msg with the same "err". Maybe a copy-paste error? > + log_error(LOG_LDAP_ERR_PREFIX "%s: %s: " desc, \ > + errmsg, diagmsg, ##__VA_ARGS__); \ > + ldap_memfree(diagmsg); \ > + } else \ > + log_error(LOG_LDAP_ERR_PREFIX "%s: " desc, \ > + errmsg, ##__VA_ARGS__); \ > + } else { \ > + log_error(LOG_LDAP_ERR_PREFIX \ > + ": " \ > + desc, ##__VA_ARGS__); \ > + } \ > + } while (0); > void > log_write(int level, const char *format, ...) ISC_FORMAT_PRINTF(2, 3); Regards, Tomas Hozza From thozza at redhat.com Tue May 7 08:16:22 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 07 May 2013 10:16:22 +0200 Subject: [Freeipa-devel] [PATCH 0143] Treat syntax errors in LDAP filters as fatal In-Reply-To: <51641A25.4040805@redhat.com> References: <51641A25.4040805@redhat.com> Message-ID: <5188B856.2070208@redhat.com> On 04/09/2013 03:39 PM, Petr Spacek wrote: > Hello, > > Treat syntax errors in LDAP filters as fatal. > > Filters are hardcoded at the moment, this is preventive action. > ACK. The patch looks good. (I didn't do functional test) Regards, Tomas Hozza From pviktori at redhat.com Tue May 7 11:02:02 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 07 May 2013 13:02:02 +0200 Subject: [Freeipa-devel] [PATCH] 0220 Only require libsss_nss_idmap-python in Fedora 19+ Message-ID: <5188DF2A.4000807@redhat.com> Hello, The patch for resolving SIDs added a dependency on a package that isn't available in Fedora 18. This makes the dependency optional. Obviously the SID resolution won't work in f18, but IPA should be installable. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0220-Only-require-libsss_nss_idmap-python-in-Fedora-19.patch Type: text/x-patch Size: 1291 bytes Desc: not available URL: From sbose at redhat.com Tue May 7 11:15:58 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 7 May 2013 13:15:58 +0200 Subject: [Freeipa-devel] [PATCH] 0220 Only require libsss_nss_idmap-python in Fedora 19+ In-Reply-To: <5188DF2A.4000807@redhat.com> References: <5188DF2A.4000807@redhat.com> Message-ID: <20130507111558.GI4481@localhost.localdomain> On Tue, May 07, 2013 at 01:02:02PM +0200, Petr Viktorin wrote: > Hello, > The patch for resolving SIDs added a dependency on a package that > isn't available in Fedora 18. This makes the dependency optional. > > Obviously the SID resolution won't work in f18, but IPA should be > installable. ACK bye, Sumit > > -- > Petr? From mkosek at redhat.com Tue May 7 11:19:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 07 May 2013 13:19:02 +0200 Subject: [Freeipa-devel] [PATCH] 0220 Only require libsss_nss_idmap-python in Fedora 19+ In-Reply-To: <20130507111558.GI4481@localhost.localdomain> References: <5188DF2A.4000807@redhat.com> <20130507111558.GI4481@localhost.localdomain> Message-ID: <5188E326.6050508@redhat.com> On 05/07/2013 01:15 PM, Sumit Bose wrote: > On Tue, May 07, 2013 at 01:02:02PM +0200, Petr Viktorin wrote: >> Hello, >> The patch for resolving SIDs added a dependency on a package that >> isn't available in Fedora 18. This makes the dependency optional. >> >> Obviously the SID resolution won't work in f18, but IPA should be >> installable. > > ACK > > bye, > Sumit Pushed to master. Martin From simo at redhat.com Tue May 7 12:35:37 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 07 May 2013 08:35:37 -0400 Subject: [Freeipa-devel] Cyrus SASL problem on Fedora 19? [heads up] In-Reply-To: <5187EEB9.8060703@redhat.com> References: <5187EEB9.8060703@redhat.com> Message-ID: <1367930137.20220.7.camel@willson.li.ssimo.org> On Mon, 2013-05-06 at 19:56 +0200, Petr Spacek wrote: > Hello list, > > heads up - we have some problems with Cyrus SASL in Fedora 19. > > SASL connections via Unix socket are failing with weird error: > > (Note the 'SOCKET' piece.) > > $ ldapsearch -Y GSSAPI -H 'ldapi://%2fvar%2frun%2fslapd-TESTRELM-COM.socket' > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Server > krbtgt/SOCKET at TESTRELM.COM not found in Kerberos database) > > > See https://bugzilla.redhat.com/show_bug.cgi?id=960222 for all the gory details. We moved it to an openldap bug actually, but the bug is there nevertheless. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue May 7 12:46:03 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 07 May 2013 14:46:03 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.1.4 Message-ID: <5188F78B.8020808@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.1.4. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 18 and is on its way to updates-testing: https://admin.fedoraproject.org/updates/freeipa-3.1.4-1.fc18 == Highlights in 3.1.4 == === New features === * Added support for new Dogtag 10.0.2 * Added support for new OpenSSH 6.2 * Added userClass attribute for hosts entries * Server/replica installation now accepts --mkhomedir option === Bug fixes === * New certificates issued by FreeIPA CA now contain correct OCSP/CRL URIs [1] * /etc/ipa directory ownership was fixed * Deprecated HBAC Source host related options were removed from CLI == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Due to changes related to OCSP/CRL URI fix [1], ipa-ca.DOMAIN DNS name is automatically converted from a set of CNAMEs to a set of A/AAAA records pointing to FreeIPA servers with CA configured. Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 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 == References == [1] http://freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs == Detailed Changelog since 3.1.3 == Alexander Bokovoy (1): * Enhance ipa-adtrust-install for domains with multiple IPA server Ana Krivokapic (8): * Add mkhomedir option to ipa-server-install and ipa-replica-install * Remove CA cert on client uninstall * Remove HBAC source hosts from web UI * Remove any reference to HBAC source hosts from help * Deprecate HBAC source hosts from CLI * Handle missing /etc/ipa in ipa-client-install * Fix the spec file * Add missing permissions to Host Administrators privilege Jan Cholasta (7): * Do actually stop pki_cad in stop_pkicad instead of starting it. * Use only one URL for OCSP and CRL in IPA certificate profile. * Use A/AAAA records instead of CNAME records in ipa-ca. * Delete DNS records in ipa-ca on ipa-csreplica-manage del. * Do not use new LDAP API in old code. * Use correct zone when removing DNS records of a master. * Add support for OpenSSH 6.2. Martin Kosek (4): * Require 389-base-base 1.3.0.5 * Add userClass attribute for hosts * Update pki proxy configuration * Become IPA 3.1.4 Petr Viktorin (2): * Display full command documentation in online help * Use two digits for each part of NUM_VERSION Rob Crittenden (3): * Handle socket.gethostbyaddr() exceptions when verifying hostnames. * Drop uniqueMember mapping with nss-pam-ldapd. * Specify the location for the agent PKCS#12 file so we don't have to move it. Sumit Bose (1): * ipa-pwd-extop: do not use dn until it is really set Tomas Babej (2): * Properly handle ipa-replica-install when its zone is not managed by IPA * Allow underscore in record targets From rcritten at redhat.com Tue May 7 14:41:09 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 May 2013 10:41:09 -0400 Subject: [Freeipa-devel] [PATCH] 1101 set httpd ccache Message-ID: <51891285.4070001@redhat.com> See the commit message for all the gory details but the bottom line is that mod_auth_kerb doesn't work with DIR ccache which is the default in the latest krb5 builds. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1101-ccache.patch Type: text/x-diff Size: 2591 bytes Desc: not available URL: From thozza at redhat.com Tue May 7 14:53:07 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 07 May 2013 16:53:07 +0200 Subject: [Freeipa-devel] [PATCH 0146] Disallow all dynamic updates if update policy configuration failed In-Reply-To: <516D0E7A.50202@redhat.com> References: <516D0E7A.50202@redhat.com> Message-ID: <51891553.9000606@redhat.com> On 04/16/2013 10:40 AM, Petr Spacek wrote: > Hello, > > Disallow all dynamic updates if update policy configuration failed. > > Without this patch the old update policy stays in effect > when re-configuration failed. > ACK. The patch looks good. (I didn't do functional test) Regards, Tomas Hozza From akrivoka at redhat.com Tue May 7 15:16:46 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 07 May 2013 17:16:46 +0200 Subject: [Freeipa-devel] [PATCH] 0026 Do not display success message on failure in web UI Message-ID: <51891ADE.3070803@redhat.com> https://fedorahosted.org/freeipa/ticket/3591 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0026-Do-not-display-success-message-on-failure-in-web-UI.patch Type: text/x-patch Size: 1514 bytes Desc: not available URL: From mkosek at redhat.com Tue May 7 16:34:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 07 May 2013 18:34:34 +0200 Subject: [Freeipa-devel] [PATCH] 1101 set httpd ccache In-Reply-To: <51891285.4070001@redhat.com> References: <51891285.4070001@redhat.com> Message-ID: <51892D1A.1030706@redhat.com> On 05/07/2013 04:41 PM, Rob Crittenden wrote: > See the commit message for all the gory details but the bottom line is that > mod_auth_kerb doesn't work with DIR ccache which is the default in the latest > krb5 builds. > > rob > Looks OK (just reading it). This fixes just new server install. What about upgrades? Won't updated FreeIPA servers' mod_auth_kerb crash too? Martin From simo at redhat.com Tue May 7 17:02:21 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 07 May 2013 13:02:21 -0400 Subject: [Freeipa-devel] [PATCH] 1101 set httpd ccache In-Reply-To: <51892D1A.1030706@redhat.com> References: <51891285.4070001@redhat.com> <51892D1A.1030706@redhat.com> Message-ID: <1367946141.20220.41.camel@willson.li.ssimo.org> On Tue, 2013-05-07 at 18:34 +0200, Martin Kosek wrote: > On 05/07/2013 04:41 PM, Rob Crittenden wrote: > > See the commit message for all the gory details but the bottom line is that > > mod_auth_kerb doesn't work with DIR ccache which is the default in the latest > > krb5 builds. > > > > rob > > > > Looks OK (just reading it). > > This fixes just new server install. What about upgrades? Won't updated FreeIPA > servers' mod_auth_kerb crash too? Indeed we need to fix on upgrade too. Simo. -- Simo Sorce * Red Hat, Inc * New York From akrivoka at redhat.com Tue May 7 17:50:42 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 07 May 2013 19:50:42 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add Message-ID: <51893EF2.6090308@redhat.com> Prompt for nameserver IP address in dnszone-add https://fedorahosted.org/freeipa/ticket/3603 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0027-Prompt-for-nameserver-IP-address-in-dnszone-add.patch Type: text/x-patch Size: 4314 bytes Desc: not available URL: From rcritten at redhat.com Tue May 7 18:04:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 May 2013 14:04:29 -0400 Subject: [Freeipa-devel] [PATCH] 1101 set httpd ccache In-Reply-To: <1367946141.20220.41.camel@willson.li.ssimo.org> References: <51891285.4070001@redhat.com> <51892D1A.1030706@redhat.com> <1367946141.20220.41.camel@willson.li.ssimo.org> Message-ID: <5189422D.6030104@redhat.com> Simo Sorce wrote: > On Tue, 2013-05-07 at 18:34 +0200, Martin Kosek wrote: >> On 05/07/2013 04:41 PM, Rob Crittenden wrote: >>> See the commit message for all the gory details but the bottom line is that >>> mod_auth_kerb doesn't work with DIR ccache which is the default in the latest >>> krb5 builds. >>> >>> rob >>> >> >> Looks OK (just reading it). >> >> This fixes just new server install. What about upgrades? Won't updated FreeIPA >> servers' mod_auth_kerb crash too? > > Indeed we need to fix on upgrade too. Yes, it was an oversight when I did the commit. Updated patch to include the one-liner upgrade call. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1101-2-ccache.patch Type: text/x-diff Size: 3108 bytes Desc: not available URL: From derek.p.moore at gmail.com Tue May 7 23:08:36 2013 From: derek.p.moore at gmail.com (Derek Moore) Date: Tue, 7 May 2013 18:08:36 -0500 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt Message-ID: I'm running FreeIPA 3.2.0 Beta 1 in Fedora 19 Alpha, and I'm running oVirt 3.3.0 pre-Beta in Fedora 18. In order to get oVirt's JGSS crap to work with FreeIPA, I had to change nsslapd-minssf to 1 (apparently a known issue right now in OpenJDK). But this setting seems to break ipa CLI, and when I change back to "nsslapd-minssf: 0" it stays broken, and FreeIPA's XML-RPC service returns a 500 error. Apache error_log says: [Tue May 07 17:06:04.698467 2013] [auth_kerb:error] [pid 705] [client 172.19.10.145:60593] Could not get default Kerberos ccache: No credentials cache found (-1765328189), referer: https://ds1.hackunix.org/ipa/xml [Tue May 07 17:06:04.703070 2013] [auth_kerb:error] [pid 705] [client 172.19.10.145:60593] gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Can't find client principal HTTP/ ds1.hackunix.org at HACKUNIX.ORG in cache collection), referer: https://ds1.hackunix.org/ipa/xml [Tue May 07 17:19:55.358418 2013] [auth_kerb:error] [pid 701] [client 172.19.10.145:60609] Could not get default Kerberos ccache: No credentials cache found (-1765328189), referer: https://ds1.hackunix.org/ipa/xml [Tue May 07 17:19:55.362419 2013] [auth_kerb:error] [pid 701] [client 172.19.10.145:60609] gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Can't find client principal HTTP/ ds1.hackunix.org at HACKUNIX.ORG in cache collection), referer: https://ds1.hackunix.org/ipa/xml Since I got FreeIPA up and running, I've only been messing with the nsslapd-minssf value to get oVirt's Java code working against it. Not sure why FreeAPI is permabroke when it is basically stock, and I'm just flipping one minssf bit. Thanks! Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed May 8 00:33:41 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 07 May 2013 20:33:41 -0400 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt In-Reply-To: References: Message-ID: <51899D65.5090806@redhat.com> On 05/07/2013 07:08 PM, Derek Moore wrote: > I'm running FreeIPA 3.2.0 Beta 1 in Fedora 19 Alpha, and I'm running > oVirt 3.3.0 pre-Beta in Fedora 18. > > In order to get oVirt's JGSS crap to work with FreeIPA, I had to > change nsslapd-minssf to 1 (apparently a known issue right now in > OpenJDK). But this setting seems to break ipa CLI, and when I change > back to "nsslapd-minssf: 0" it stays broken, and FreeIPA's XML-RPC > service returns a 500 error. > > Apache error_log says: > [Tue May 07 17:06:04.698467 2013] [auth_kerb:error] [pid 705] [client > 172.19.10.145:60593 ] Could not get > default Kerberos ccache: No credentials cache found (-1765328189), > referer: https://ds1.hackunix.org/ipa/xml > [Tue May 07 17:06:04.703070 2013] [auth_kerb:error] [pid 705] [client > 172.19.10.145:60593 ] gss_acquire_cred() > failed: Unspecified GSS failure. Minor code may provide more > information (, Can't find client principal > HTTP/ds1.hackunix.org at HACKUNIX.ORG > in cache collection), referer: > https://ds1.hackunix.org/ipa/xml > [Tue May 07 17:19:55.358418 2013] [auth_kerb:error] [pid 701] [client > 172.19.10.145:60609 ] Could not get > default Kerberos ccache: No credentials cache found (-1765328189), > referer: https://ds1.hackunix.org/ipa/xml > [Tue May 07 17:19:55.362419 2013] [auth_kerb:error] [pid 701] [client > 172.19.10.145:60609 ] gss_acquire_cred() > failed: Unspecified GSS failure. Minor code may provide more > information (, Can't find client principal > HTTP/ds1.hackunix.org at HACKUNIX.ORG > in cache collection), referer: > https://ds1.hackunix.org/ipa/xml > > > Since I got FreeIPA up and running, I've only been messing with the > nsslapd-minssf value to get oVirt's Java code working against it. > > Not sure why FreeAPI is permabroke when it is basically stock, and I'm > just flipping one minssf bit. Did you restart all IPA services including KDC after you changed the minssf? > > Thanks! > > Derek > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.p.moore at gmail.com Wed May 8 03:04:58 2013 From: derek.p.moore at gmail.com (Derek Moore) Date: Tue, 7 May 2013 22:04:58 -0500 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt In-Reply-To: <51899D65.5090806@redhat.com> References: <51899D65.5090806@redhat.com> Message-ID: <9E1EDFC8-ABE9-456C-811B-B30C192D0D66@gmail.com> > Did you restart all IPA services including KDC after you changed the minssf? Yes, tried many combinations of restarts and reboots trying to undo the breakage. I found a similar thread on here ("sudden ipa errors") where someone spent a lot of time debugging when suddenly RH support came back with an odd fix to krb5kdc.conf that doesn't apply to me since I'm not using a subdomain for the realm. Let me start over documenting the ipa steps better, I had to patch a few things along the way to get it to work (like the .pki to .dogtag problem on install). I'll report back... From derek.p.moore at gmail.com Wed May 8 03:44:58 2013 From: derek.p.moore at gmail.com (Derek Moore) Date: Tue, 7 May 2013 22:44:58 -0500 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt In-Reply-To: <9E1EDFC8-ABE9-456C-811B-B30C192D0D66@gmail.com> References: <51899D65.5090806@redhat.com> <9E1EDFC8-ABE9-456C-811B-B30C192D0D66@gmail.com> Message-ID: First I'll undo the oVirt/FreeIPA relationship: # engine-manage-domains -action=delete -domain=hackunix.org ... Manage Domains completed successfully # service ovirt-engine restart oVirt works with internal domain and admin user. Now let's uninstall FreeIPA: # pkidestroy -s CA -i pki-tomcat Loading deployment configuration from /var/lib/pki/pki-tomcat/ca/registry/ca/deployment.cfg. Uninstalling CA from /var/lib/pki/pki-tomcat. pkidestroy : WARNING ....... this 'CA' entry may not be registered with security domain 'IPA'! pkidestroy : ERROR ....... updateDomainXML FAILED to delete this 'CA' entry from security domain 'IPA': '' Uninstallation complete. # rm -rf /var/log/pki/pki-tomcat # rm -rf /etc/sysconfig/pki-tomcat # rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat # rm -rf /var/lib/pki/pki-tomcat # rm -rf /etc/pki/pki-tomcat # ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unconfiguring CA ipa : CRITICAL failed to uninstall CA instance Command '/usr/sbin/pkidestroy -i pki-tomcat -s CA' returned non-zero exit status 255 Unconfiguring named Unconfiguring web server Unconfiguring krb5kdc Unconfiguring kadmin Unconfiguring directory server Unconfiguring ipa_memcached # ipa-server-install I choose BIND integration, set my hostname, and now I get a new error: Server host name [localhost.localdomain]: ds1.hackunix.org [Errno 1] Unknown host So now I'm thinking that besides mucking with minssf I also turned on DNS for my domain, but everything in DNS should match what I started out with in /etc/hosts... Let me read what the install script is expecting here... brb On Tue, May 7, 2013 at 10:04 PM, Derek Moore wrote: > > > Did you restart all IPA services including KDC after you changed the > minssf? > > Yes, tried many combinations of restarts and reboots trying to undo the > breakage. > > I found a similar thread on here ("sudden ipa errors") where someone spent > a lot of time debugging when suddenly RH support came back with an odd fix > to krb5kdc.conf that doesn't apply to me since I'm not using a subdomain > for the realm. > > Let me start over documenting the ipa steps better, I had to patch a few > things along the way to get it to work (like the .pki to .dogtag problem on > install). > > I'll report back... -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.p.moore at gmail.com Wed May 8 19:09:57 2013 From: derek.p.moore at gmail.com (Derek Moore) Date: Wed, 8 May 2013 14:09:57 -0500 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt In-Reply-To: References: <51899D65.5090806@redhat.com> <9E1EDFC8-ABE9-456C-811B-B30C192D0D66@gmail.com> Message-ID: Setting /etc/hostname manually and several restarts and reboots later, I finally got the install to work (mostly) properly again last night. But I still cannot get the XML-RPC server to function properly, the end of the install script fails on /usr/sbin/ipa-client-install: ipalib.errors.NetworkError: cannot connect to ' https://ds1.hackunix.org/ipa/xml': Internal Server Error I can't get passed the "No credentials cache found" error in Apache. The credentials cache it's looking for is httpd's keytab? Thanks! Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed May 8 19:15:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 May 2013 15:15:50 -0400 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt In-Reply-To: References: <51899D65.5090806@redhat.com> <9E1EDFC8-ABE9-456C-811B-B30C192D0D66@gmail.com> Message-ID: <518AA466.7010507@redhat.com> Derek Moore wrote: > Setting /etc/hostname manually and several restarts and reboots later, I > finally got the install to work (mostly) properly again last night. > > But I still cannot get the XML-RPC server to function properly, the end > of the install script fails on /usr/sbin/ipa-client-install: > > ipalib.errors.NetworkError: cannot connect to > 'https://ds1.hackunix.org/ipa/xml': Internal Server Error > > I can't get passed the "No credentials cache found" error in Apache. The > credentials cache it's looking for is httpd's keytab? > We're fighting some issues with changes in support libraries. If you have openldap-2.4.35-3, the default value of SASL_NOCANON changed to on (at our request ironically) which breaks ldapi requests, which we also use. For 3.1.x and 3.2pre1 or beta1 I believe the only solution is to downgrade openldap. We are working with upstream and have provided a patch to the Fedora maintainer to mitigate this but it is yet unresolved. If you have krb5 1.11.2-4 then you need to add KRB5CCNAME=/tmp/krb5cc_48 to the end of /etc/sysconfig/httpd. The ccache format was changed to DIR and mod_auth_kerb doesn't support this yet. This fix should work with any version of IPA. rob From derek.p.moore at gmail.com Wed May 8 21:24:44 2013 From: derek.p.moore at gmail.com (Derek Moore) Date: Wed, 8 May 2013 16:24:44 -0500 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt In-Reply-To: <518AA466.7010507@redhat.com> References: <51899D65.5090806@redhat.com> <9E1EDFC8-ABE9-456C-811B-B30C192D0D66@gmail.com> <518AA466.7010507@redhat.com> Message-ID: Hey, that did it! You're the man! I didn't have to downgrade openldap, just changed /etc/openldap/ldap.conf to "SASL_NOCANON off". This allowed the install script to complete, and the install script overwrite ldap.conf anyway removing SASL_NOCANON altogether, so things still work. I rolled my own krb5/ldap/nss integration back in the early 2000s, so I feel you on all the the upstream lib dependencies. (I used phpLDAPadmin to administer my Directory, and I integrated sendmailMTA object which are very nice [after fixing one or two braindead things about their schema {an inetOrgPerson could not be a sendmailMTA receiver, i wanted merged objects, no separate objects}].) After following your advice, I can no longer use kpasswd to set user passwords, but I can reset passwords in the web frontend, so that's fine for now. FreeIPA seems very nice so far, I hope to be able to make meaningful contributions as I become more familiar with this complex integration product. Thanks! Derek On Wed, May 8, 2013 at 2:15 PM, Rob Crittenden wrote: > Derek Moore wrote: > >> Setting /etc/hostname manually and several restarts and reboots later, I >> finally got the install to work (mostly) properly again last night. >> >> But I still cannot get the XML-RPC server to function properly, the end >> of the install script fails on /usr/sbin/ipa-client-install: >> >> ipalib.errors.NetworkError: cannot connect to >> 'https://ds1.hackunix.org/ipa/**xml ': >> Internal Server Error >> >> I can't get passed the "No credentials cache found" error in Apache. The >> credentials cache it's looking for is httpd's keytab? >> >> > We're fighting some issues with changes in support libraries. > > If you have openldap-2.4.35-3, the default value of SASL_NOCANON changed > to on (at our request ironically) which breaks ldapi requests, which we > also use. For 3.1.x and 3.2pre1 or beta1 I believe the only solution is to > downgrade openldap. We are working with upstream and have provided a patch > to the Fedora maintainer to mitigate this but it is yet unresolved. > > If you have krb5 1.11.2-4 then you need to add KRB5CCNAME=/tmp/krb5cc_48 > to the end of /etc/sysconfig/httpd. The ccache format was changed to DIR > and mod_auth_kerb doesn't support this yet. This fix should work with any > version of IPA. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.p.moore at gmail.com Wed May 8 22:39:25 2013 From: derek.p.moore at gmail.com (Derek Moore) Date: Wed, 8 May 2013 17:39:25 -0500 Subject: [Freeipa-devel] FreeIPA quit working - or, IPA & oVirt In-Reply-To: References: <51899D65.5090806@redhat.com> <9E1EDFC8-ABE9-456C-811B-B30C192D0D66@gmail.com> <518AA466.7010507@redhat.com> Message-ID: F your I: The kpasswd issue was only temporary... A while later it was working just time. Setting passwords in the webUI wasn't enough for oVirt, I needed to set passwords with kpasswd. By the time I figured that out, kpasswd was working with no changes (kdestroy/kinit were done when it wasn't working). Thanks again for the help, both of you! On Wed, May 8, 2013 at 4:24 PM, Derek Moore wrote: > Hey, that did it! You're the man! > > I didn't have to downgrade openldap, just changed /etc/openldap/ldap.conf > to "SASL_NOCANON off". This allowed the install script to complete, and the > install script overwrite ldap.conf anyway removing SASL_NOCANON altogether, > so things still work. > > I rolled my own krb5/ldap/nss integration back in the early 2000s, so I > feel you on all the the upstream lib dependencies. (I used phpLDAPadmin to > administer my Directory, and I integrated sendmailMTA object which are very > nice [after fixing one or two braindead things about their schema {an > inetOrgPerson could not be a sendmailMTA receiver, i wanted merged objects, > no separate objects}].) > > After following your advice, I can no longer use kpasswd to set user > passwords, but I can reset passwords in the web frontend, so that's fine > for now. > > FreeIPA seems very nice so far, I hope to be able to make meaningful > contributions as I become more familiar with this complex integration > product. > > Thanks! > > Derek > > > On Wed, May 8, 2013 at 2:15 PM, Rob Crittenden wrote: > >> Derek Moore wrote: >> >>> Setting /etc/hostname manually and several restarts and reboots later, I >>> finally got the install to work (mostly) properly again last night. >>> >>> But I still cannot get the XML-RPC server to function properly, the end >>> of the install script fails on /usr/sbin/ipa-client-install: >>> >>> ipalib.errors.NetworkError: cannot connect to >>> 'https://ds1.hackunix.org/ipa/**xml ': >>> Internal Server Error >>> >>> I can't get passed the "No credentials cache found" error in Apache. The >>> credentials cache it's looking for is httpd's keytab? >>> >>> >> We're fighting some issues with changes in support libraries. >> >> If you have openldap-2.4.35-3, the default value of SASL_NOCANON changed >> to on (at our request ironically) which breaks ldapi requests, which we >> also use. For 3.1.x and 3.2pre1 or beta1 I believe the only solution is to >> downgrade openldap. We are working with upstream and have provided a patch >> to the Fedora maintainer to mitigate this but it is yet unresolved. >> >> If you have krb5 1.11.2-4 then you need to add KRB5CCNAME=/tmp/krb5cc_48 >> to the end of /etc/sysconfig/httpd. The ccache format was changed to DIR >> and mod_auth_kerb doesn't support this yet. This fix should work with any >> version of IPA. >> >> rob >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu May 9 07:17:05 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 May 2013 09:17:05 +0200 Subject: [Freeipa-devel] [PATCH] 1101 set httpd ccache In-Reply-To: <5189422D.6030104@redhat.com> References: <51891285.4070001@redhat.com> <51892D1A.1030706@redhat.com> <1367946141.20220.41.camel@willson.li.ssimo.org> <5189422D.6030104@redhat.com> Message-ID: <518B4D71.8050105@redhat.com> On 05/07/2013 08:04 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Tue, 2013-05-07 at 18:34 +0200, Martin Kosek wrote: >>> On 05/07/2013 04:41 PM, Rob Crittenden wrote: >>>> See the commit message for all the gory details but the bottom line is that >>>> mod_auth_kerb doesn't work with DIR ccache which is the default in the latest >>>> krb5 builds. >>>> >>>> rob >>>> >>> >>> Looks OK (just reading it). >>> >>> This fixes just new server install. What about upgrades? Won't updated FreeIPA >>> servers' mod_auth_kerb crash too? >> >> Indeed we need to fix on upgrade too. > > Yes, it was an oversight when I did the commit. Updated patch to include the > one-liner upgrade call. > > rob > ACK, works like a charm. Pushed to master. Martin From thozza at redhat.com Thu May 9 08:35:57 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 09 May 2013 10:35:57 +0200 Subject: [Freeipa-devel] [PATCH 0147] Improve error logging for zones with idnsAllowDynUpdate == FALSE. In-Reply-To: <516D2B89.1090506@redhat.com> References: <516D2B89.1090506@redhat.com> Message-ID: <518B5FED.7060104@redhat.com> On 04/16/2013 12:44 PM, Petr Spacek wrote: > Hello, > > Improve error logging for zones with idnsAllowDynUpdate == FALSE. > > Zones with dynamic updates disabled are re-configured with empty > update policy string, so the update is refused by BIND and > an error is logged. > ACK. The patch looks reasonable. (I didn't do functional test) Regards, Tomas Hozza From thozza at redhat.com Thu May 9 08:59:22 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 09 May 2013 10:59:22 +0200 Subject: [Freeipa-devel] [PATCH 0148] Explicitly return SERVFAIL if PTR synchronization is misconfigured. In-Reply-To: <516D2BBA.2040407@redhat.com> References: <516D2BBA.2040407@redhat.com> Message-ID: <518B656A.8030508@redhat.com> On 04/16/2013 12:45 PM, Petr Spacek wrote: > Hello, > > Explicitly return SERVFAIL if PTR synchronization is misconfigured. > > SERVFAIL will be returned if PTR synchronization is enabled > in forward zone but reverse zone has dynamic updates disabled. > What the patch does little bit differs from what the commit message says. Explanation follows: Snip from ldap_helper.c (starting line 2959): /* Get attribute "idnsAllowDynUpdate" for reverse zone or use default. */ dns_name_free(&zone_name, mctx); dns_name_init(&zone_name, NULL); CHECK(dn_to_dnsname(mctx, owner_zone_dn_ptr, &zone_name, NULL)); zone_settings = NULL; result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, &zone_settings); if (result != ISC_R_SUCCESS) { if (result == ISC_R_NOTFOUND) log_debug(3, "active zone '%s' not found", zone_dn); goto cleanup; ^ You replaced this goto with "CLEANUP_WITH(DNS_R_SERVFAIL)" but the check if dynamic updates in reverse zone are enabled is done in the following IF statement } CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); if (!zone_dyn_update) { log_debug(3, "dynamic update is not allowed in zone " "'%s'", zone_dn); CLEANUP_WITH(ISC_R_NOPERM); } The patch modifies the plugin to explicitly return SERVFAIL if there was some error while getting settings of PTR zone (the zone does not exist, etc). Maybe it would be good to explicitly return SERVFAIL also if dynamic updates in PTR zone are disabled and modify the commit message to better express what this patch does. Regards, Tomas Hozza From pspacek at redhat.com Thu May 9 10:35:54 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 May 2013 12:35:54 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <51893EF2.6090308@redhat.com> References: <51893EF2.6090308@redhat.com> Message-ID: <518B7C0A.7050808@redhat.com> Hello, On 7.5.2013 19:50, Ana Krivokapic wrote: > Prompt for nameserver IP address in dnszone-add > > https://fedorahosted.org/freeipa/ticket/3603 [...] > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index 3ad03402d5a3b66b0f64545ff8812e9201258d6e..0ee24b1bba6b499336b61d48ad5786df2ca05826 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -1781,6 +1781,8 @@ class dnszone_add(LDAPCreate): > ), > Str('ip_address?', _validate_ipaddr, > doc=_('Add forward record for nameserver located in the created zone'), > + label=_('Nameserver IP address'), > + alwaysask=True, > ), > ) If I understood correctly, IPA CLI will ask for IP address always - right? The problem is that IP address is explicitly required only if the name of the name server belongs to the new zone. There are three different cases: new zone = example.com. a) NS = ns.example.com. (i.e. absolute name) => IP address is required because NS is defined inside the new zone b) NS = ns (i.e. relative name) => IP address is required because NS is defined inside the new zone c) NS = ns.example.net. => IP address is not required because NS is defined outside the new zone I didn't do functional test, so I'm sorry if I missed the some important piece of the patch :-) -- Petr Spacek From akrivoka at redhat.com Thu May 9 10:44:52 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 09 May 2013 12:44:52 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518B7C0A.7050808@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7C0A.7050808@redhat.com> Message-ID: <518B7E24.5030608@redhat.com> On 05/09/2013 12:35 PM, Petr Spacek wrote: > Hello, > > On 7.5.2013 19:50, Ana Krivokapic wrote: >> Prompt for nameserver IP address in dnszone-add >> >> https://fedorahosted.org/freeipa/ticket/3603 > [...] > >> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >> index >> 3ad03402d5a3b66b0f64545ff8812e9201258d6e..0ee24b1bba6b499336b61d48ad5786df2ca05826 >> 100644 >> --- a/ipalib/plugins/dns.py >> +++ b/ipalib/plugins/dns.py >> @@ -1781,6 +1781,8 @@ class dnszone_add(LDAPCreate): >> ), >> Str('ip_address?', _validate_ipaddr, >> doc=_('Add forward record for nameserver located in the >> created zone'), >> + label=_('Nameserver IP address'), >> + alwaysask=True, >> ), >> ) > > If I understood correctly, IPA CLI will ask for IP address always - > right? The problem is that IP address is explicitly required only if > the name of the name server belongs to the new zone. Yes, it will always ask for the IP address, but it is not a required option - you can leave it blank and press [enter]. The same applies for web UI, you can just leave it blank. > > There are three different cases: > > new zone = example.com. > a) NS = ns.example.com. (i.e. absolute name) > => IP address is required because NS is defined inside the new zone > > b) NS = ns (i.e. relative name) > => IP address is required because NS is defined inside the new zone > > c) NS = ns.example.net. > => IP address is not required because NS is defined outside the new zone > > I didn't do functional test, so I'm sorry if I missed the some > important piece of the patch :-) > -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pspacek at redhat.com Thu May 9 10:44:57 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 May 2013 12:44:57 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518B7E24.5030608@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7C0A.7050808@redhat.com> <518B7E24.5030608@redhat.com> Message-ID: <518B7E29.302@redhat.com> On 9.5.2013 12:44, Ana Krivokapic wrote: > On 05/09/2013 12:35 PM, Petr Spacek wrote: >> Hello, >> >> On 7.5.2013 19:50, Ana Krivokapic wrote: >>> Prompt for nameserver IP address in dnszone-add >>> >>> https://fedorahosted.org/freeipa/ticket/3603 >> [...] >> >>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>> index >>> 3ad03402d5a3b66b0f64545ff8812e9201258d6e..0ee24b1bba6b499336b61d48ad5786df2ca05826 >>> 100644 >>> --- a/ipalib/plugins/dns.py >>> +++ b/ipalib/plugins/dns.py >>> @@ -1781,6 +1781,8 @@ class dnszone_add(LDAPCreate): >>> ), >>> Str('ip_address?', _validate_ipaddr, >>> doc=_('Add forward record for nameserver located in the >>> created zone'), >>> + label=_('Nameserver IP address'), >>> + alwaysask=True, >>> ), >>> ) >> >> If I understood correctly, IPA CLI will ask for IP address always - >> right? The problem is that IP address is explicitly required only if >> the name of the name server belongs to the new zone. > > Yes, it will always ask for the IP address, but it is not a required > option - you can leave it blank and press [enter]. The same applies for > web UI, you can just leave it blank. Unfortunately, the IP address is required for cases a) and b) and can't be specified in case c). >> There are three different cases: >> >> new zone = example.com. >> a) NS = ns.example.com. (i.e. absolute name) >> => IP address is required because NS is defined inside the new zone >> >> b) NS = ns (i.e. relative name) >> => IP address is required because NS is defined inside the new zone >> >> c) NS = ns.example.net. >> => IP address is not required because NS is defined outside the new zone >> >> I didn't do functional test, so I'm sorry if I missed the some >> important piece of the patch :-) -- Petr^2 Spacek From pviktori at redhat.com Thu May 9 10:45:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 May 2013 12:45:01 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <51893EF2.6090308@redhat.com> References: <51893EF2.6090308@redhat.com> Message-ID: <518B7E2D.9010301@redhat.com> On 05/07/2013 07:50 PM, Ana Krivokapic wrote: > Prompt for nameserver IP address in dnszone-add > > https://fedorahosted.org/freeipa/ticket/3603 See Petr ?pa?ek's mail for normal zones. Also when adding a reverse zone we should not ask: $ ipa dnszone-add --name-from-ip=80.142.15.0/24 --name-server=`hostname`. Zone name [15.142.80.in-addr.arpa.]: Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: [Nameserver IP address]: 1.2.3.4 ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created for for forward zones only The Web UI also asks for the NS IP address for reverse zones and fails when it's given. (Also, looking at the output above, asking for the zone name isn't useful for reverse zones, but I guess that's a different usability issue.) I think the easiest way to selectively ask in CLI is a custom interactive_prompt_callback (or we could have a separate dnszone-add-reverse command). As for the UI I don't know. The question is, do we want to go that far for this bug? -- Petr? From thozza at redhat.com Thu May 9 11:27:24 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 09 May 2013 13:27:24 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <516FB717.9010203@redhat.com> References: <516FB717.9010203@redhat.com> Message-ID: <518B881C.3020205@redhat.com> On 04/18/2013 11:04 AM, Petr Spacek wrote: > Hello, > > Clean up PTR record synchronization code and make it more robust. > > PTR record synchronization was split to smaller functions. > Input validation, error handling and logging was improved > significantly. > ACK. The patch looks OK! Regards, Tomas Hozza From pspacek at redhat.com Thu May 9 11:37:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 May 2013 13:37:45 +0200 Subject: [Freeipa-devel] [PATCH 0142] Improve LDAP error logging In-Reply-To: <5188AEFA.2040402@redhat.com> References: <51641740.5040601@redhat.com> <5188AEFA.2040402@redhat.com> Message-ID: <518B8A89.3020908@redhat.com> On 7.5.2013 09:36, Tomas Hozza wrote: > On 04/09/2013 03:27 PM, Petr Spacek wrote: >> Hello, >> >> Improve LDAP error logging. >> >> Diagnostic error message is logged when it is available. >> >> >> Plugin with this patch produces messages like: >> >> LDAP error: Server is unwilling to perform: Minimum SSF not met.: bind >> to LDAP server failed >> >> intead of >> >> bind to LDAP server failed: Server is unwilling to perform >> >> >> Second example is: >> >> LDAP error: Object class violation: attribute "mgrecord" not allowed >> : while modifying(add) entry 'idnsName=pspacek, >> idnsname=example.com,cn=dns,dc=e,dc=test' >> >> instead of >> >> "" >> >> :-D >> > > >> diff --git a/src/log.h b/src/log.h >> +#define LOG_LDAP_ERR_PREFIX "LDAP error: " >> +#define log_ldap_error(ld, desc, ...) \ >> + do { \ >> + int err; \ >> + char *errmsg = NULL; \ >> + char *diagmsg = NULL; \ >> + if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err) \ >> + == LDAP_OPT_SUCCESS) { \ >> + errmsg = ldap_err2string(err); \ > Getting error msg for the first time here. > >> + if (ldap_get_option(ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, &diagmsg) \ >> + == LDAP_OPT_SUCCESS && diagmsg != NULL) { \ >> + errmsg = ldap_err2string(err); \ > Again getting error msg with the same "err". Maybe a copy-paste error? > >> + log_error(LOG_LDAP_ERR_PREFIX "%s: %s: " desc, \ >> + errmsg, diagmsg, ##__VA_ARGS__); \ >> + ldap_memfree(diagmsg); \ >> + } else \ Revised version of the patch is attached. Thank you for catching it. -- Petr Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0142-2-Improve-LDAP-error-logging.patch Type: text/x-patch Size: 3982 bytes Desc: not available URL: From thozza at redhat.com Thu May 9 12:06:50 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 09 May 2013 14:06:50 +0200 Subject: [Freeipa-devel] [PATCH 0150] Do not delete whole node during PTR record synchronization. In-Reply-To: <51700A04.3070305@redhat.com> References: <51700A04.3070305@redhat.com> Message-ID: <518B915A.4030308@redhat.com> On 04/18/2013 04:58 PM, Petr Spacek wrote: > Hello, > > Do not delete whole node during PTR record synchronization. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/115 > ACK. The patch looks good. Regards, Tomas Hozza From mkosek at redhat.com Thu May 9 12:06:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 May 2013 14:06:59 +0200 Subject: [Freeipa-devel] [PATCH] 404 Do not add ipa-ca records on CA-less installs Message-ID: <518B9163.2010909@redhat.com> This should get to 3.2 GA. -- ipa-dns-install crashed when it was run on a CA-less server. https://fedorahosted.org/freeipa/ticket/3617 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-404-do-not-add-ipa-ca-records-on-ca-less-installs.patch Type: text/x-patch Size: 1094 bytes Desc: not available URL: From mkosek at redhat.com Thu May 9 12:10:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 May 2013 14:10:44 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518B7E2D.9010301@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> Message-ID: <518B9244.80901@redhat.com> On 05/09/2013 12:45 PM, Petr Viktorin wrote: > On 05/07/2013 07:50 PM, Ana Krivokapic wrote: >> Prompt for nameserver IP address in dnszone-add >> >> https://fedorahosted.org/freeipa/ticket/3603 > > See Petr ?pa?ek's mail for normal zones. > Also when adding a reverse zone we should not ask: > > $ ipa dnszone-add --name-from-ip=80.142.15.0/24 --name-server=`hostname`. > Zone name [15.142.80.in-addr.arpa.]: > Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: > [Nameserver IP address]: 1.2.3.4 > ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created for for > forward zones only > > The Web UI also asks for the NS IP address for reverse zones and fails when > it's given. > > > (Also, looking at the output above, asking for the zone name isn't useful for > reverse zones, but I guess that's a different usability issue.) > > > I think the easiest way to selectively ask in CLI is a custom > interactive_prompt_callback (or we could have a separate dnszone-add-reverse > command). As for the UI I don't know. > The question is, do we want to go that far for this bug? I do not like the alwaysask approach. I think it rather complicates things. I think we will indeed need to do the interactive_prompt_callback and in case when we detect the following cases (as per Petr Spacek's mail): new zone = example.com. a) NS = ns.example.com. (i.e. absolute name) => IP address is required because NS is defined inside the new zone b) NS = ns (i.e. relative name) => IP address is required because NS is defined inside the new zone we need to ask for IP address. As in this case, this is really not an option, but a required parameter. If possible, the same logic would be great to have for the UI. When deciding the question above, you can take advantage of get_name_in_zone function which will also work with cases like ipa dnszone-add example.com --name-server=@ --ip-address 10.16.78.47 Martin From thozza at redhat.com Thu May 9 12:20:37 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 09 May 2013 14:20:37 +0200 Subject: [Freeipa-devel] [PATCH 0151] Disallow all zone transfers/queries if transfer/query policy configuration failed In-Reply-To: <5171201E.9030502@redhat.com> References: <5171201E.9030502@redhat.com> Message-ID: <518B9495.3050909@redhat.com> On 04/19/2013 12:44 PM, Petr Spacek wrote: > Hello, > > Disallow all zone transfers/queries if transfer/query policy > configuration failed. > > Without this patch the old policy stays in effect > if re-configuration with the new policy failed. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/116 > ACK. Patch looks OK! Regards, Tomas Hozza From pviktori at redhat.com Thu May 9 12:39:29 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 May 2013 14:39:29 +0200 Subject: [Freeipa-devel] [PATCH] 404 Do not add ipa-ca records on CA-less installs In-Reply-To: <518B9163.2010909@redhat.com> References: <518B9163.2010909@redhat.com> Message-ID: <518B9901.1080606@redhat.com> On 05/09/2013 02:06 PM, Martin Kosek wrote: > This should get to 3.2 GA. > > -- > ipa-dns-install crashed when it was run on a CA-less server. > > https://fedorahosted.org/freeipa/ticket/3617 > This solves the issue, ACK -- Petr? From pspacek at redhat.com Thu May 9 12:53:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 May 2013 14:53:10 +0200 Subject: [Freeipa-devel] [PATCH 0148] Explicitly return SERVFAIL if PTR synchronization is misconfigured. In-Reply-To: <518B656A.8030508@redhat.com> References: <516D2BBA.2040407@redhat.com> <518B656A.8030508@redhat.com> Message-ID: <518B9C36.5040300@redhat.com> On 9.5.2013 10:59, Tomas Hozza wrote: > On 04/16/2013 12:45 PM, Petr Spacek wrote: >> Hello, >> >> Explicitly return SERVFAIL if PTR synchronization is misconfigured. >> >> SERVFAIL will be returned if PTR synchronization is enabled >> in forward zone but reverse zone has dynamic updates disabled. >> > > What the patch does little bit differs from what the commit > message says. Explanation follows: > > Snip from ldap_helper.c (starting line 2959): > > /* Get attribute "idnsAllowDynUpdate" for reverse zone or use default. */ > dns_name_free(&zone_name, mctx); > dns_name_init(&zone_name, NULL); > CHECK(dn_to_dnsname(mctx, owner_zone_dn_ptr, &zone_name, NULL)); > > zone_settings = NULL; > result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, > &zone_settings); > if (result != ISC_R_SUCCESS) { > if (result == ISC_R_NOTFOUND) > log_debug(3, "active zone '%s' not found", zone_dn); > goto cleanup; > ^ > You replaced this goto with "CLEANUP_WITH(DNS_R_SERVFAIL)" but > the check if dynamic updates in reverse zone are enabled > is done in the following IF statement > } > > CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); > if (!zone_dyn_update) { > log_debug(3, "dynamic update is not allowed in zone " > "'%s'", zone_dn); > CLEANUP_WITH(ISC_R_NOPERM); > } > > > The patch modifies the plugin to explicitly return SERVFAIL if there was > some error while getting settings of PTR zone (the zone does not exist, > etc). > > Maybe it would be good to explicitly return SERVFAIL also if dynamic > updates in PTR zone are disabled and modify the commit message to > better express what this patch does. You are right. Revised patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0148-2-Explicitly-return-SERVFAIL-if-PTR-synchronization-is.patch Type: text/x-patch Size: 19015 bytes Desc: not available URL: From mkosek at redhat.com Thu May 9 13:14:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 May 2013 15:14:07 +0200 Subject: [Freeipa-devel] [PATCH] 404 Do not add ipa-ca records on CA-less installs In-Reply-To: <518B9901.1080606@redhat.com> References: <518B9163.2010909@redhat.com> <518B9901.1080606@redhat.com> Message-ID: <518BA11F.1010706@redhat.com> On 05/09/2013 02:39 PM, Petr Viktorin wrote: > On 05/09/2013 02:06 PM, Martin Kosek wrote: >> This should get to 3.2 GA. >> >> -- >> ipa-dns-install crashed when it was run on a CA-less server. >> >> https://fedorahosted.org/freeipa/ticket/3617 >> > > This solves the issue, ACK > Thanks. Pushed to master. Martin From pspacek at redhat.com Thu May 9 15:23:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 May 2013 17:23:33 +0200 Subject: [Freeipa-devel] [PATCH 0148] Explicitly return SERVFAIL if PTR synchronization is misconfigured. In-Reply-To: <518B9C36.5040300@redhat.com> References: <516D2BBA.2040407@redhat.com> <518B656A.8030508@redhat.com> <518B9C36.5040300@redhat.com> Message-ID: <518BBF75.3060004@redhat.com> On 9.5.2013 14:53, Petr Spacek wrote: > On 9.5.2013 10:59, Tomas Hozza wrote: >> On 04/16/2013 12:45 PM, Petr Spacek wrote: >>> Hello, >>> >>> Explicitly return SERVFAIL if PTR synchronization is misconfigured. >>> >>> SERVFAIL will be returned if PTR synchronization is enabled >>> in forward zone but reverse zone has dynamic updates disabled. >>> >> >> What the patch does little bit differs from what the commit >> message says. Explanation follows: >> >> Snip from ldap_helper.c (starting line 2959): >> >> /* Get attribute "idnsAllowDynUpdate" for reverse zone or use default. */ >> dns_name_free(&zone_name, mctx); >> dns_name_init(&zone_name, NULL); >> CHECK(dn_to_dnsname(mctx, owner_zone_dn_ptr, &zone_name, NULL)); >> >> zone_settings = NULL; >> result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, >> &zone_settings); >> if (result != ISC_R_SUCCESS) { >> if (result == ISC_R_NOTFOUND) >> log_debug(3, "active zone '%s' not found", zone_dn); >> goto cleanup; >> ^ >> You replaced this goto with "CLEANUP_WITH(DNS_R_SERVFAIL)" but >> the check if dynamic updates in reverse zone are enabled >> is done in the following IF statement >> } >> >> CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); >> if (!zone_dyn_update) { >> log_debug(3, "dynamic update is not allowed in zone " >> "'%s'", zone_dn); >> CLEANUP_WITH(ISC_R_NOPERM); >> } >> >> >> The patch modifies the plugin to explicitly return SERVFAIL if there was >> some error while getting settings of PTR zone (the zone does not exist, >> etc). >> >> Maybe it would be good to explicitly return SERVFAIL also if dynamic >> updates in PTR zone are disabled and modify the commit message to >> better express what this patch does. > > You are right. Revised patch is attached. I sent a bad patch by mistake... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0148-3-Explicitly-return-SERVFAIL-if-PTR-synchronization-is.patch Type: text/x-patch Size: 1287 bytes Desc: not available URL: From jcholast at redhat.com Thu May 9 15:44:21 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 09 May 2013 17:44:21 +0200 Subject: [Freeipa-devel] [PATCH] 404 Do not add ipa-ca records on CA-less installs In-Reply-To: <518BA11F.1010706@redhat.com> References: <518B9163.2010909@redhat.com> <518B9901.1080606@redhat.com> <518BA11F.1010706@redhat.com> Message-ID: <518BC455.4040506@redhat.com> On 9.5.2013 15:14, Martin Kosek wrote: > On 05/09/2013 02:39 PM, Petr Viktorin wrote: >> On 05/09/2013 02:06 PM, Martin Kosek wrote: >>> This should get to 3.2 GA. >>> >>> -- >>> ipa-dns-install crashed when it was run on a CA-less server. >>> >>> https://fedorahosted.org/freeipa/ticket/3617 >>> >> >> This solves the issue, ACK >> > > Thanks. Pushed to master. > > Martin > Sorry for this, but NACK. With this patch ipa-ca records are not created for existing masters unless ipa-dns-install is run on a replica which has CA configured. You should instead put the ldap.get_entries() call in a try/except block and ignore the NotFound exception which causes the crash. You can test it by installing IPA without --setup-dns and without --external-ca on server1 and then installing a replica with --setup-dns and without --setup-ca on server2. After this, ipa-ca record for server1 should be created. Honza -- Jan Cholasta From mkosek at redhat.com Thu May 9 15:57:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 May 2013 17:57:37 +0200 Subject: [Freeipa-devel] [PATCH] 404 Do not add ipa-ca records on CA-less installs In-Reply-To: <518BC455.4040506@redhat.com> References: <518B9163.2010909@redhat.com> <518B9901.1080606@redhat.com> <518BA11F.1010706@redhat.com> <518BC455.4040506@redhat.com> Message-ID: <518BC771.40809@redhat.com> On 05/09/2013 05:44 PM, Jan Cholasta wrote: > On 9.5.2013 15:14, Martin Kosek wrote: >> On 05/09/2013 02:39 PM, Petr Viktorin wrote: >>> On 05/09/2013 02:06 PM, Martin Kosek wrote: >>>> This should get to 3.2 GA. >>>> >>>> -- >>>> ipa-dns-install crashed when it was run on a CA-less server. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3617 >>>> >>> >>> This solves the issue, ACK >>> >> >> Thanks. Pushed to master. >> >> Martin >> > > Sorry for this, but NACK. With this patch ipa-ca records are not created for > existing masters unless ipa-dns-install is run on a replica which has CA > configured. You should instead put the ldap.get_entries() call in a try/except > block and ignore the NotFound exception which causes the crash. > > You can test it by installing IPA without --setup-dns and without --external-ca > on server1 and then installing a replica with --setup-dns and without > --setup-ca on server2. After this, ipa-ca record for server1 should be created. > > Honza > Sending updated patch, please review if you can. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-405-fix-ipa-ca-dns-name-creation.patch Type: text/x-patch Size: 1766 bytes Desc: not available URL: From jcholast at redhat.com Thu May 9 16:01:40 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 09 May 2013 18:01:40 +0200 Subject: [Freeipa-devel] [PATCH] 404 Do not add ipa-ca records on CA-less installs In-Reply-To: <518BC771.40809@redhat.com> References: <518B9163.2010909@redhat.com> <518B9901.1080606@redhat.com> <518BA11F.1010706@redhat.com> <518BC455.4040506@redhat.com> <518BC771.40809@redhat.com> Message-ID: <518BC864.1030702@redhat.com> On 9.5.2013 17:57, Martin Kosek wrote: > On 05/09/2013 05:44 PM, Jan Cholasta wrote: >> Sorry for this, but NACK. With this patch ipa-ca records are not created for >> existing masters unless ipa-dns-install is run on a replica which has CA >> configured. You should instead put the ldap.get_entries() call in a try/except >> block and ignore the NotFound exception which causes the crash. >> >> You can test it by installing IPA without --setup-dns and without --external-ca >> on server1 and then installing a replica with --setup-dns and without >> --setup-ca on server2. After this, ipa-ca record for server1 should be created. >> >> Honza >> > > Sending updated patch, please review if you can. > > Martin > Looks good to me, ACK! -- Jan Cholasta From pviktori at redhat.com Thu May 9 16:05:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 May 2013 18:05:38 +0200 Subject: [Freeipa-devel] [PATCH] 0221 Update translations from Transifex Message-ID: <518BC952.90608@redhat.com> Hello, It's almost time to release, so let's merge the current state of translations. Since last release, there has been significant activity in Spanish, French, and Ukrainian. Thanks to all translators! The patch is again quite large, so I have not attached it. Please download it from here: https://github.com/encukou/freeipa/commit/09b6702905a9eaa2d590166060a02b4ab6f88992.patch install/po/bn_IN.po | 20 +- install/po/ca.po | 12 +- install/po/cs.po | 12 +- install/po/de.po | 14 +- install/po/es.po | 1386 +++++++++++++++++++++++++++++++++++++++++++++++++-- install/po/eu.po | 18 +- install/po/fr.po | 1341 +++++++++++++++++++++++++++++++++++++++++++++++-- install/po/id.po | 27 +- install/po/ipa.pot | 680 +++++++++++++------------ install/po/ja.po | 14 +- install/po/kn.po | 35 +- install/po/nl.po | 12 +- install/po/pl.po | 37 +- install/po/ru.po | 39 +- install/po/tg.po | 12 +- install/po/uk.po | 587 ++++++++++++++++++++-- install/po/zh_CN.po | 24 +- 17 files changed, 3615 insertions(+), 655 deletions(-) -- Petr? From akrivoka at redhat.com Thu May 9 17:03:17 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 09 May 2013 19:03:17 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518B9244.80901@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> Message-ID: <518BD6D5.40901@redhat.com> On 05/09/2013 02:10 PM, Martin Kosek wrote: > On 05/09/2013 12:45 PM, Petr Viktorin wrote: >> On 05/07/2013 07:50 PM, Ana Krivokapic wrote: >>> Prompt for nameserver IP address in dnszone-add >>> >>> https://fedorahosted.org/freeipa/ticket/3603 >> See Petr ?pa?ek's mail for normal zones. >> Also when adding a reverse zone we should not ask: >> >> $ ipa dnszone-add --name-from-ip=80.142.15.0/24 --name-server=`hostname`. >> Zone name [15.142.80.in-addr.arpa.]: >> Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: >> [Nameserver IP address]: 1.2.3.4 >> ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created for for >> forward zones only >> >> The Web UI also asks for the NS IP address for reverse zones and fails when >> it's given. >> >> >> (Also, looking at the output above, asking for the zone name isn't useful for >> reverse zones, but I guess that's a different usability issue.) >> >> >> I think the easiest way to selectively ask in CLI is a custom >> interactive_prompt_callback (or we could have a separate dnszone-add-reverse >> command). As for the UI I don't know. >> The question is, do we want to go that far for this bug? > I do not like the alwaysask approach. I think it rather complicates things. > > I think we will indeed need to do the interactive_prompt_callback and in case > when we detect the following cases (as per Petr Spacek's mail): > > new zone = example.com. > a) NS = ns.example.com. (i.e. absolute name) > => IP address is required because NS is defined inside the new zone > > b) NS = ns (i.e. relative name) > => IP address is required because NS is defined inside the new zone > > we need to ask for IP address. As in this case, this is really not an option, > but a required parameter. If possible, the same logic would be great to have > for the UI. > > When deciding the question above, you can take advantage of get_name_in_zone > function which will also work with cases like > ipa dnszone-add example.com --name-server=@ --ip-address 10.16.78.47 > > Martin Thanks all for the reviews. I addressed all comments in the attached updated patch. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0027-02-Prompt-for-nameserver-IP-address-in-dnszone-add.patch Type: text/x-patch Size: 6532 bytes Desc: not available URL: From rcritten at redhat.com Thu May 9 18:17:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 09 May 2013 14:17:39 -0400 Subject: [Freeipa-devel] [PATCH] 404 Do not add ipa-ca records on CA-less installs In-Reply-To: <518BC864.1030702@redhat.com> References: <518B9163.2010909@redhat.com> <518B9901.1080606@redhat.com> <518BA11F.1010706@redhat.com> <518BC455.4040506@redhat.com> <518BC771.40809@redhat.com> <518BC864.1030702@redhat.com> Message-ID: <518BE843.9080404@redhat.com> Jan Cholasta wrote: > On 9.5.2013 17:57, Martin Kosek wrote: >> On 05/09/2013 05:44 PM, Jan Cholasta wrote: >>> Sorry for this, but NACK. With this patch ipa-ca records are not >>> created for >>> existing masters unless ipa-dns-install is run on a replica which has CA >>> configured. You should instead put the ldap.get_entries() call in a >>> try/except >>> block and ignore the NotFound exception which causes the crash. >>> >>> You can test it by installing IPA without --setup-dns and without >>> --external-ca >>> on server1 and then installing a replica with --setup-dns and without >>> --setup-ca on server2. After this, ipa-ca record for server1 should >>> be created. >>> >>> Honza >>> >> >> Sending updated patch, please review if you can. >> >> Martin >> > > Looks good to me, ACK! > pushed to master From mkosek at redhat.com Thu May 9 19:53:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 May 2013 21:53:18 +0200 Subject: [Freeipa-devel] [PATCH] 0221 Update translations from Transifex In-Reply-To: <518BC952.90608@redhat.com> References: <518BC952.90608@redhat.com> Message-ID: <518BFEAE.4000703@redhat.com> On 05/09/2013 06:05 PM, Petr Viktorin wrote: > Hello, > It's almost time to release, so let's merge the current state of translations. > Since last release, there has been significant activity in Spanish, French, and > Ukrainian. > > Thanks to all translators! > > The patch is again quite large, so I have not attached it. Please download it > from here: > https://github.com/encukou/freeipa/commit/09b6702905a9eaa2d590166060a02b4ab6f88992.patch > > > install/po/bn_IN.po | 20 +- > install/po/ca.po | 12 +- > install/po/cs.po | 12 +- > install/po/de.po | 14 +- > install/po/es.po | 1386 +++++++++++++++++++++++++++++++++++++++++++++++++-- > install/po/eu.po | 18 +- > install/po/fr.po | 1341 +++++++++++++++++++++++++++++++++++++++++++++++-- > install/po/id.po | 27 +- > install/po/ipa.pot | 680 +++++++++++++------------ > install/po/ja.po | 14 +- > install/po/kn.po | 35 +- > install/po/nl.po | 12 +- > install/po/pl.po | 37 +- > install/po/ru.po | 39 +- > install/po/tg.po | 12 +- > install/po/uk.po | 587 ++++++++++++++++++++-- > install/po/zh_CN.po | 24 +- > 17 files changed, 3615 insertions(+), 655 deletions(-) > ACK. Pushed to master. Martin From pspacek at redhat.com Fri May 10 07:30:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 10 May 2013 09:30:13 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518BD6D5.40901@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> Message-ID: <518CA205.3000200@redhat.com> On 9.5.2013 19:03, Ana Krivokapic wrote: > On 05/09/2013 02:10 PM, Martin Kosek wrote: >> On 05/09/2013 12:45 PM, Petr Viktorin wrote: >>> On 05/07/2013 07:50 PM, Ana Krivokapic wrote: >>>> Prompt for nameserver IP address in dnszone-add >>>> >>>> https://fedorahosted.org/freeipa/ticket/3603 >>> See Petr ?pa?ek's mail for normal zones. >>> Also when adding a reverse zone we should not ask: >>> >>> $ ipa dnszone-add --name-from-ip=80.142.15.0/24 --name-server=`hostname`. >>> Zone name [15.142.80.in-addr.arpa.]: >>> Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: >>> [Nameserver IP address]: 1.2.3.4 >>> ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created for for >>> forward zones only >>> >>> The Web UI also asks for the NS IP address for reverse zones and fails when >>> it's given. >>> >>> >>> (Also, looking at the output above, asking for the zone name isn't useful for >>> reverse zones, but I guess that's a different usability issue.) >>> >>> >>> I think the easiest way to selectively ask in CLI is a custom >>> interactive_prompt_callback (or we could have a separate dnszone-add-reverse >>> command). As for the UI I don't know. >>> The question is, do we want to go that far for this bug? >> I do not like the alwaysask approach. I think it rather complicates things. >> >> I think we will indeed need to do the interactive_prompt_callback and in case >> when we detect the following cases (as per Petr Spacek's mail): >> >> new zone = example.com. >> a) NS = ns.example.com. (i.e. absolute name) >> => IP address is required because NS is defined inside the new zone >> >> b) NS = ns (i.e. relative name) >> => IP address is required because NS is defined inside the new zone >> >> we need to ask for IP address. As in this case, this is really not an option, >> but a required parameter. If possible, the same logic would be great to have >> for the UI. >> >> When deciding the question above, you can take advantage of get_name_in_zone >> function which will also work with cases like >> ipa dnszone-add example.com --name-server=@ --ip-address 10.16.78.47 >> >> Martin > > Thanks all for the reviews. I addressed all comments in the attached > updated patch. I went quickly through the patch and the logic seems okay. As a part of the patch I would recommend to change the error messages below to something more meaningful/accurate: > if zone_is_reverse(normalized_zone): > if not nameserver.endswith('.'): > raise errors.ValidationError(name='name-server', > error=_("Nameserver for reverse zone cannot be " > "a relative DNS name")) > elif nameserver_ip_address: > raise errors.ValidationError(name='ip_address', > error=_("Nameserver DNS record is created for " > "for forward zones only")) "Nameserver for reverse zone cannot be relative DNS name" => "Relative names in nameserver records for reverse zone are not supported" "Nameserver DNS record is created for for forward zones only" => "A/AAAA records in reverse zone are not supported" The problem is that both cases are completely legal from DNS point of view, but IPA interface do not allow to create such zones. The other option is to drop this 'if' branch completely, but it definitely should be in a separate patch or even a ticket. -- Petr^2 Spacek From pviktori at redhat.com Fri May 10 08:58:24 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 May 2013 10:58:24 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518CA205.3000200@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> Message-ID: <518CB6B0.3000204@redhat.com> On 05/10/2013 09:30 AM, Petr Spacek wrote: > On 9.5.2013 19:03, Ana Krivokapic wrote: >> On 05/09/2013 02:10 PM, Martin Kosek wrote: >>> On 05/09/2013 12:45 PM, Petr Viktorin wrote: >>>> On 05/07/2013 07:50 PM, Ana Krivokapic wrote: >>>>> Prompt for nameserver IP address in dnszone-add >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3603 >>>> See Petr ?pa?ek's mail for normal zones. >>>> Also when adding a reverse zone we should not ask: >>>> >>>> $ ipa dnszone-add --name-from-ip=80.142.15.0/24 >>>> --name-server=`hostname`. >>>> Zone name [15.142.80.in-addr.arpa.]: >>>> Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: >>>> [Nameserver IP address]: 1.2.3.4 >>>> ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created >>>> for for >>>> forward zones only >>>> >>>> The Web UI also asks for the NS IP address for reverse zones and >>>> fails when >>>> it's given. >>>> >>>> >>>> (Also, looking at the output above, asking for the zone name isn't >>>> useful for >>>> reverse zones, but I guess that's a different usability issue.) >>>> >>>> >>>> I think the easiest way to selectively ask in CLI is a custom >>>> interactive_prompt_callback (or we could have a separate >>>> dnszone-add-reverse >>>> command). As for the UI I don't know. >>>> The question is, do we want to go that far for this bug? >>> I do not like the alwaysask approach. I think it rather complicates >>> things. >>> >>> I think we will indeed need to do the interactive_prompt_callback and >>> in case >>> when we detect the following cases (as per Petr Spacek's mail): >>> >>> new zone = example.com. >>> a) NS = ns.example.com. (i.e. absolute name) >>> => IP address is required because NS is defined inside the new zone >>> >>> b) NS = ns (i.e. relative name) >>> => IP address is required because NS is defined inside the new zone >>> >>> we need to ask for IP address. As in this case, this is really not an >>> option, >>> but a required parameter. If possible, the same logic would be great >>> to have >>> for the UI. >>> >>> When deciding the question above, you can take advantage of >>> get_name_in_zone >>> function which will also work with cases like >>> ipa dnszone-add example.com --name-server=@ --ip-address 10.16.78.47 >>> >>> Martin >> >> Thanks all for the reviews. I addressed all comments in the attached >> updated patch. Thanks, it works nicely now. Could you add some tests? See tests/test_cmdline/test_cli.py for some examples of tests of interactive prompting. The Web UI works, but it'd be nice if a JS expert looked over the code. > I went quickly through the patch and the logic seems okay. > > As a part of the patch I would recommend to change the error messages > below to something more meaningful/accurate: > > > if zone_is_reverse(normalized_zone): > > if not nameserver.endswith('.'): > > raise errors.ValidationError(name='name-server', > > error=_("Nameserver for reverse zone cannot be " > > "a relative DNS name")) > > elif nameserver_ip_address: > > raise errors.ValidationError(name='ip_address', > > error=_("Nameserver DNS record is created for " > > "for forward zones only")) > > "Nameserver for reverse zone cannot be relative DNS name" > => "Relative names in nameserver records for reverse zone are not > supported" > > "Nameserver DNS record is created for for forward zones only" > => "A/AAAA records in reverse zone are not supported" > > The problem is that both cases are completely legal from DNS point of > view, but IPA interface do not allow to create such zones. > > > The other option is to drop this 'if' branch completely, but it > definitely should be in a separate patch or even a ticket. Is this going into this release? If yes, it's pretty late for string changes, both these and the "for for" typo fix in this patch, so we should leave them out. -- Petr? From akrivoka at redhat.com Fri May 10 11:30:25 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 10 May 2013 13:30:25 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518CB6B0.3000204@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> Message-ID: <518CDA51.3040208@redhat.com> On 05/10/2013 10:58 AM, Petr Viktorin wrote: > On 05/10/2013 09:30 AM, Petr Spacek wrote: >> On 9.5.2013 19:03, Ana Krivokapic wrote: >>> On 05/09/2013 02:10 PM, Martin Kosek wrote: >>>> On 05/09/2013 12:45 PM, Petr Viktorin wrote: >>>>> On 05/07/2013 07:50 PM, Ana Krivokapic wrote: >>>>>> Prompt for nameserver IP address in dnszone-add >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3603 >>>>> See Petr ?pa?ek's mail for normal zones. >>>>> Also when adding a reverse zone we should not ask: >>>>> >>>>> $ ipa dnszone-add --name-from-ip=80.142.15.0/24 >>>>> --name-server=`hostname`. >>>>> Zone name [15.142.80.in-addr.arpa.]: >>>>> Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: >>>>> [Nameserver IP address]: 1.2.3.4 >>>>> ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created >>>>> for for >>>>> forward zones only >>>>> >>>>> The Web UI also asks for the NS IP address for reverse zones and >>>>> fails when >>>>> it's given. >>>>> >>>>> >>>>> (Also, looking at the output above, asking for the zone name isn't >>>>> useful for >>>>> reverse zones, but I guess that's a different usability issue.) >>>>> >>>>> >>>>> I think the easiest way to selectively ask in CLI is a custom >>>>> interactive_prompt_callback (or we could have a separate >>>>> dnszone-add-reverse >>>>> command). As for the UI I don't know. >>>>> The question is, do we want to go that far for this bug? >>>> I do not like the alwaysask approach. I think it rather complicates >>>> things. >>>> >>>> I think we will indeed need to do the interactive_prompt_callback and >>>> in case >>>> when we detect the following cases (as per Petr Spacek's mail): >>>> >>>> new zone = example.com. >>>> a) NS = ns.example.com. (i.e. absolute name) >>>> => IP address is required because NS is defined inside the new zone >>>> >>>> b) NS = ns (i.e. relative name) >>>> => IP address is required because NS is defined inside the new zone >>>> >>>> we need to ask for IP address. As in this case, this is really not an >>>> option, >>>> but a required parameter. If possible, the same logic would be great >>>> to have >>>> for the UI. >>>> >>>> When deciding the question above, you can take advantage of >>>> get_name_in_zone >>>> function which will also work with cases like >>>> ipa dnszone-add example.com --name-server=@ --ip-address 10.16.78.47 >>>> >>>> Martin >>> >>> Thanks all for the reviews. I addressed all comments in the attached >>> updated patch. > > Thanks, it works nicely now. > Could you add some tests? See tests/test_cmdline/test_cli.py for some > examples of tests of interactive prompting. Added - updated patch attached. > > The Web UI works, but it'd be nice if a JS expert looked over the code. > >> I went quickly through the patch and the logic seems okay. >> >> As a part of the patch I would recommend to change the error messages >> below to something more meaningful/accurate: >> >> > if zone_is_reverse(normalized_zone): >> > if not nameserver.endswith('.'): >> > raise errors.ValidationError(name='name-server', >> > error=_("Nameserver for reverse zone >> cannot be " >> > "a relative DNS name")) >> > elif nameserver_ip_address: >> > raise errors.ValidationError(name='ip_address', >> > error=_("Nameserver DNS record is created >> for " >> > "for forward zones only")) >> >> "Nameserver for reverse zone cannot be relative DNS name" >> => "Relative names in nameserver records for reverse zone are not >> supported" >> >> "Nameserver DNS record is created for for forward zones only" >> => "A/AAAA records in reverse zone are not supported" >> >> The problem is that both cases are completely legal from DNS point of >> view, but IPA interface do not allow to create such zones. >> >> >> The other option is to drop this 'if' branch completely, but it >> definitely should be in a separate patch or even a ticket. > > Is this going into this release? If yes, it's pretty late for string > changes, both these and the "for for" typo fix in this patch, so we > should leave them out. > I moved the string changes into a separate patch. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0027-03-Prompt-for-nameserver-IP-address-in-dnszone-add.patch Type: text/x-patch Size: 9139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0028-Improve-error-messages-in-dnszone-add.patch Type: text/x-patch Size: 1860 bytes Desc: not available URL: From mkosek at redhat.com Fri May 10 11:54:11 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 May 2013 13:54:11 +0200 Subject: [Freeipa-devel] [PATCH] 406 Fix SASL_NOCANON behavior for LDAPI Message-ID: <518CDFE3.7090103@redhat.com> Add requires for openldap-2.4.35-4 to pickup fixed SASL_NOCANON behavior for socket based connections (#960222). -- I think this should get to 3.2 GA too to make sure that our ldapi works. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-406-fix-sasl_nocanon-behavior-for-ldapi.patch Type: text/x-patch Size: 1376 bytes Desc: not available URL: From abokovoy at redhat.com Fri May 10 12:06:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 May 2013 15:06:00 +0300 Subject: [Freeipa-devel] [PATCH] 406 Fix SASL_NOCANON behavior for LDAPI In-Reply-To: <518CDFE3.7090103@redhat.com> References: <518CDFE3.7090103@redhat.com> Message-ID: <20130510120600.GB26689@redhat.com> On Fri, 10 May 2013, Martin Kosek wrote: >Add requires for openldap-2.4.35-4 to pickup fixed SASL_NOCANON >behavior for socket based connections (#960222). > >-- > >I think this should get to 3.2 GA too to make sure that our ldapi works. ACK for patch, and yes, it should go to 3.2 as well. -- / Alexander Bokovoy From mkosek at redhat.com Fri May 10 12:18:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 May 2013 14:18:44 +0200 Subject: [Freeipa-devel] [PATCH] 406 Fix SASL_NOCANON behavior for LDAPI In-Reply-To: <20130510120600.GB26689@redhat.com> References: <518CDFE3.7090103@redhat.com> <20130510120600.GB26689@redhat.com> Message-ID: <518CE5A4.7060602@redhat.com> On 05/10/2013 02:06 PM, Alexander Bokovoy wrote: > On Fri, 10 May 2013, Martin Kosek wrote: >> Add requires for openldap-2.4.35-4 to pickup fixed SASL_NOCANON >> behavior for socket based connections (#960222). >> >> -- >> >> I think this should get to 3.2 GA too to make sure that our ldapi works. > ACK for patch, and yes, it should go to 3.2 as well. Pushed to master. Martin From pviktori at redhat.com Fri May 10 12:42:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 May 2013 14:42:14 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518CDA51.3040208@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> Message-ID: <518CEB26.3050404@redhat.com> On 05/10/2013 01:30 PM, Ana Krivokapic wrote: > On 05/10/2013 10:58 AM, Petr Viktorin wrote: >> On 05/10/2013 09:30 AM, Petr Spacek wrote: >>> On 9.5.2013 19:03, Ana Krivokapic wrote: >>>> On 05/09/2013 02:10 PM, Martin Kosek wrote: >>>>> On 05/09/2013 12:45 PM, Petr Viktorin wrote: >>>>>> On 05/07/2013 07:50 PM, Ana Krivokapic wrote: >>>>>>> Prompt for nameserver IP address in dnszone-add >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3603 >>>>>> See Petr ?pa?ek's mail for normal zones. >>>>>> Also when adding a reverse zone we should not ask: >>>>>> >>>>>> $ ipa dnszone-add --name-from-ip=80.142.15.0/24 >>>>>> --name-server=`hostname`. >>>>>> Zone name [15.142.80.in-addr.arpa.]: >>>>>> Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: >>>>>> [Nameserver IP address]: 1.2.3.4 >>>>>> ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created >>>>>> for for >>>>>> forward zones only >>>>>> >>>>>> The Web UI also asks for the NS IP address for reverse zones and >>>>>> fails when >>>>>> it's given. >>>>>> >>>>>> >>>>>> (Also, looking at the output above, asking for the zone name isn't >>>>>> useful for >>>>>> reverse zones, but I guess that's a different usability issue.) >>>>>> >>>>>> >>>>>> I think the easiest way to selectively ask in CLI is a custom >>>>>> interactive_prompt_callback (or we could have a separate >>>>>> dnszone-add-reverse >>>>>> command). As for the UI I don't know. >>>>>> The question is, do we want to go that far for this bug? >>>>> I do not like the alwaysask approach. I think it rather complicates >>>>> things. >>>>> >>>>> I think we will indeed need to do the interactive_prompt_callback and >>>>> in case >>>>> when we detect the following cases (as per Petr Spacek's mail): >>>>> >>>>> new zone = example.com. >>>>> a) NS = ns.example.com. (i.e. absolute name) >>>>> => IP address is required because NS is defined inside the new zone >>>>> >>>>> b) NS = ns (i.e. relative name) >>>>> => IP address is required because NS is defined inside the new zone >>>>> >>>>> we need to ask for IP address. As in this case, this is really not an >>>>> option, >>>>> but a required parameter. If possible, the same logic would be great >>>>> to have >>>>> for the UI. >>>>> >>>>> When deciding the question above, you can take advantage of >>>>> get_name_in_zone >>>>> function which will also work with cases like >>>>> ipa dnszone-add example.com --name-server=@ --ip-address 10.16.78.47 >>>>> >>>>> Martin >>>> >>>> Thanks all for the reviews. I addressed all comments in the attached >>>> updated patch. >> >> Thanks, it works nicely now. >> Could you add some tests? See tests/test_cmdline/test_cli.py for some >> examples of tests of interactive prompting. > > Added - updated patch attached. >> >> The Web UI works, but it'd be nice if a JS expert looked over the code. >> >>> I went quickly through the patch and the logic seems okay. >>> >>> As a part of the patch I would recommend to change the error messages >>> below to something more meaningful/accurate: >>> >>> > if zone_is_reverse(normalized_zone): >>> > if not nameserver.endswith('.'): >>> > raise errors.ValidationError(name='name-server', >>> > error=_("Nameserver for reverse zone >>> cannot be " >>> > "a relative DNS name")) >>> > elif nameserver_ip_address: >>> > raise errors.ValidationError(name='ip_address', >>> > error=_("Nameserver DNS record is created >>> for " >>> > "for forward zones only")) >>> >>> "Nameserver for reverse zone cannot be relative DNS name" >>> => "Relative names in nameserver records for reverse zone are not >>> supported" >>> >>> "Nameserver DNS record is created for for forward zones only" >>> => "A/AAAA records in reverse zone are not supported" >>> >>> The problem is that both cases are completely legal from DNS point of >>> view, but IPA interface do not allow to create such zones. >>> >>> >>> The other option is to drop this 'if' branch completely, but it >>> definitely should be in a separate patch or even a ticket. >> >> Is this going into this release? If yes, it's pretty late for string >> changes, both these and the "for for" typo fix in this patch, so we >> should leave them out. >> > > I moved the string changes into a separate patch. > You left the string change in the first patch. Otherwise, ACK for the Python part. In the UI, when you ender a reverse zone manually, the Nameserver IP address field should not be enabled at all (see screenshot: http://i.imgur.com/oj2LR2w.png) In the second patch, please also change the message in a test: FAIL: test_dns[10]: dnszone_add: Try to create reverse zone u'15.142.80.in-addr.arpa.' with NS record in it ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/home/pviktori/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/home/pviktori/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line 311, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/home/pviktori/freeipa/tests/util.py", line 348, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u"invalid 'name-server': Nameserver for reverse zone cannot be a relative DNS name" got = u"invalid 'name-server': Relative names in nameserver records for reverse zone are not supported" path = () -- Petr? From pviktori at redhat.com Fri May 10 12:47:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 May 2013 14:47:42 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518CEB26.3050404@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> Message-ID: <518CEC6E.7000301@redhat.com> On 05/10/2013 02:42 PM, Petr Viktorin wrote: > > You left the string change in the first patch. Otherwise, ACK for the > Python part. Sorry, I tested the wrong patch at first and left this in the message. Full ACK for the Python part. -- Petr? From akrivoka at redhat.com Fri May 10 13:57:29 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 10 May 2013 15:57:29 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518CEB26.3050404@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> Message-ID: <518CFCC9.4040409@redhat.com> On 05/10/2013 02:42 PM, Petr Viktorin wrote: > On 05/10/2013 01:30 PM, Ana Krivokapic wrote: >> On 05/10/2013 10:58 AM, Petr Viktorin wrote: >>> On 05/10/2013 09:30 AM, Petr Spacek wrote: >>>> On 9.5.2013 19:03, Ana Krivokapic wrote: >>>>> On 05/09/2013 02:10 PM, Martin Kosek wrote: >>>>>> On 05/09/2013 12:45 PM, Petr Viktorin wrote: >>>>>>> On 05/07/2013 07:50 PM, Ana Krivokapic wrote: >>>>>>>> Prompt for nameserver IP address in dnszone-add >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3603 >>>>>>> See Petr ?pa?ek's mail for normal zones. >>>>>>> Also when adding a reverse zone we should not ask: >>>>>>> >>>>>>> $ ipa dnszone-add --name-from-ip=80.142.15.0/24 >>>>>>> --name-server=`hostname`. >>>>>>> Zone name [15.142.80.in-addr.arpa.]: >>>>>>> Administrator e-mail address [hostmaster.15.142.80.in-addr.arpa.]: >>>>>>> [Nameserver IP address]: 1.2.3.4 >>>>>>> ipa: ERROR: invalid 'ip_address': Nameserver DNS record is created >>>>>>> for for >>>>>>> forward zones only >>>>>>> >>>>>>> The Web UI also asks for the NS IP address for reverse zones and >>>>>>> fails when >>>>>>> it's given. >>>>>>> >>>>>>> >>>>>>> (Also, looking at the output above, asking for the zone name isn't >>>>>>> useful for >>>>>>> reverse zones, but I guess that's a different usability issue.) >>>>>>> >>>>>>> >>>>>>> I think the easiest way to selectively ask in CLI is a custom >>>>>>> interactive_prompt_callback (or we could have a separate >>>>>>> dnszone-add-reverse >>>>>>> command). As for the UI I don't know. >>>>>>> The question is, do we want to go that far for this bug? >>>>>> I do not like the alwaysask approach. I think it rather complicates >>>>>> things. >>>>>> >>>>>> I think we will indeed need to do the interactive_prompt_callback >>>>>> and >>>>>> in case >>>>>> when we detect the following cases (as per Petr Spacek's mail): >>>>>> >>>>>> new zone = example.com. >>>>>> a) NS = ns.example.com. (i.e. absolute name) >>>>>> => IP address is required because NS is defined inside the new zone >>>>>> >>>>>> b) NS = ns (i.e. relative name) >>>>>> => IP address is required because NS is defined inside the new zone >>>>>> >>>>>> we need to ask for IP address. As in this case, this is really >>>>>> not an >>>>>> option, >>>>>> but a required parameter. If possible, the same logic would be great >>>>>> to have >>>>>> for the UI. >>>>>> >>>>>> When deciding the question above, you can take advantage of >>>>>> get_name_in_zone >>>>>> function which will also work with cases like >>>>>> ipa dnszone-add example.com --name-server=@ --ip-address 10.16.78.47 >>>>>> >>>>>> Martin >>>>> >>>>> Thanks all for the reviews. I addressed all comments in the attached >>>>> updated patch. >>> >>> Thanks, it works nicely now. >>> Could you add some tests? See tests/test_cmdline/test_cli.py for some >>> examples of tests of interactive prompting. >> >> Added - updated patch attached. >>> >>> The Web UI works, but it'd be nice if a JS expert looked over the code. >>> >>>> I went quickly through the patch and the logic seems okay. >>>> >>>> As a part of the patch I would recommend to change the error messages >>>> below to something more meaningful/accurate: >>>> >>>> > if zone_is_reverse(normalized_zone): >>>> > if not nameserver.endswith('.'): >>>> > raise errors.ValidationError(name='name-server', >>>> > error=_("Nameserver for reverse zone >>>> cannot be " >>>> > "a relative DNS name")) >>>> > elif nameserver_ip_address: >>>> > raise errors.ValidationError(name='ip_address', >>>> > error=_("Nameserver DNS record is created >>>> for " >>>> > "for forward zones only")) >>>> >>>> "Nameserver for reverse zone cannot be relative DNS name" >>>> => "Relative names in nameserver records for reverse zone are not >>>> supported" >>>> >>>> "Nameserver DNS record is created for for forward zones only" >>>> => "A/AAAA records in reverse zone are not supported" >>>> >>>> The problem is that both cases are completely legal from DNS point of >>>> view, but IPA interface do not allow to create such zones. >>>> >>>> >>>> The other option is to drop this 'if' branch completely, but it >>>> definitely should be in a separate patch or even a ticket. >>> >>> Is this going into this release? If yes, it's pretty late for string >>> changes, both these and the "for for" typo fix in this patch, so we >>> should leave them out. >>> >> >> I moved the string changes into a separate patch. >> > > You left the string change in the first patch. Otherwise, ACK for the > Python part. > > In the UI, when you ender a reverse zone manually, the Nameserver IP > address field should not be enabled at all (see screenshot: > http://i.imgur.com/oj2LR2w.png) > > Fixed. > > > In the second patch, please also change the message in a test: > > FAIL: test_dns[10]: dnszone_add: Try to create reverse zone > u'15.142.80.in-addr.arpa.' with NS record in it > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File "/home/pviktori/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line > 271, in > func = lambda: self.check(nice, **test) > File "/home/pviktori/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line > 285, in check > self.check_exception(nice, cmd, args, options, expected) > File "/home/pviktori/freeipa/tests/test_xmlrpc/xmlrpc_test.py", line > 311, in check_exception > assert_deepequal(expected.strerror, e.strerror) > File "/home/pviktori/freeipa/tests/util.py", line 348, in > assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > > expected = u"invalid 'name-server': Nameserver for reverse zone > cannot be a relative DNS name" > got = u"invalid 'name-server': Relative names in nameserver records > for reverse zone are not supported" > path = () > Fixed. Thanks for catching the bugs. Updated patches are attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0027-04-Prompt-for-nameserver-IP-address-in-dnszone-add.patch Type: text/x-patch Size: 9361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0028-02-Improve-error-messages-in-dnszone-add.patch Type: text/x-patch Size: 2719 bytes Desc: not available URL: From pviktori at redhat.com Fri May 10 14:38:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 May 2013 16:38:25 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518CFCC9.4040409@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> Message-ID: <518D0661.3050405@redhat.com> On 05/10/2013 03:57 PM, Ana Krivokapic wrote: [...] > Thanks for catching the bugs. Updated patches are attached. Thanks! It works nicely. Endi is doing a quick check of the Javascript, if he doesn't find an issue then ACK. If this still makes it into 3.2.0, please only push the first patch there. -- Petr? From tbabej at redhat.com Fri May 10 14:39:45 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 10 May 2013 16:39:45 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa Message-ID: <518D06B1.1060904@redhat.com> Hi, this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 See commit messages for details. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0055-Prompt-for-rid-base-when-dom-sid-specified-and-vice-.patch Type: text/x-patch Size: 2087 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0054-Add-prompt_param-method-to-avoid-code-duplication.patch Type: text/x-patch Size: 9003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0053-Remove-redundant-check-for-env.interactive.patch Type: text/x-patch Size: 872 bytes Desc: not available URL: From pviktori at redhat.com Fri May 10 14:54:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 May 2013 16:54:17 +0200 Subject: [Freeipa-devel] [PATCH] 0222 Remove code to install Dogtag 9 Message-ID: <518D0A19.5040800@redhat.com> Re-sending this patch as it should go into Work towards next release. Since we depend on Dogtag 10 now, there is no need to keep code that installs a Dogtag 9 CA. Support for upgraded Dogtag-9-style instances is left in. https://fedorahosted.org/freeipa/ticket/3529 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0222-Remove-code-to-install-Dogtag-9.patch Type: text/x-patch Size: 18897 bytes Desc: not available URL: From pviktori at redhat.com Fri May 10 14:54:39 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 10 May 2013 16:54:39 +0200 Subject: [Freeipa-devel] [PATCH] 0119 Switch client to JSON-RPC In-Reply-To: <5159FE2B.306@redhat.com> References: <50F53F2B.4020406@redhat.com> <511CF3D3.80107@redhat.com> <5159FE2B.306@redhat.com> Message-ID: <518D0A2F.6040401@redhat.com> On 04/01/2013 11:37 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 01/15/2013 12:36 PM, Petr Viktorin wrote: >>> I meant to hold this patch a while longer to let it mature, but from >>> what Brian Smith asked on the user list it seems it could help him. >>> >>> Design: http://freeipa.org/page/V3/JSON-RPC >>> Ticket: https://fedorahosted.org/freeipa/ticket/3299 >>> >>> See the design page for what the patch does. >>> >>> >>> As much as I've tried to avoid them, the code includes some workarounds: >>> It extends xmlrpclib to also support JSON. This is rather intrusive, but >>> to not do that I'd need to write a parallel stack for JSON, without the >>> help of a standard library. >>> The registration of either jsonclient or xmlclient as "rpcclient" in the >>> API also needs a bit of magic, since the framework requires the class >>> name to match the attribute. >>> >>> >>> To prevent backwards compatibility problems, we need to ensure that all >>> official JSON clients send the API version, so this patch should be >>> applied after my patches 0104-0106. >>> >> >> Updating to current master. > > Please reverse this change in ipalib/rpc.py: > > @@ -665,8 +788,6 @@ class xmlclient(Connectible): > except Exception, e: > if not fallback: > raise > - else: > - self.log.info('Connection to %s failed with %s', > url, e) > serverproxy = None > > This logs connection errors when the client fails over to another server. Thanks. Done, and rebased to master. > The changes look really good. The show stopper is that using jsonrpc > doesn't create a session key. I noticed that xmlrpc_uri is hardcoded > into ipalib/session.py but it appears the issue is deeper than that. That uses only the hostname from xmlrpc_uri. When using different hostnames in xmlrpc_uri and jsonrpc_uri *on the server*, it'll put the wrong domain in the cookie. In this case I think it's the configuration that's wrong. The real problem is that KerberossSession code which creates the cookie, was not called by the JSON server. Patch 0223 adds it. Patch 0224 adds the server class name (e.g. [jsonserver_kerb]) to the server logs. It should help debug problems specific to a backend/protocol. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0119.3-Switch-client-to-JSON-RPC.patch Type: text/x-patch Size: 39709 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0223.3-Make-jsonserver_kerb-start-a-cookie-based-session.patch Type: text/x-patch Size: 1580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0224.3-Add-server-protocol-type-to-rpcserver-logs.patch Type: text/x-patch Size: 2805 bytes Desc: not available URL: From pspacek at redhat.com Fri May 10 14:57:37 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 10 May 2013 16:57:37 +0200 Subject: [Freeipa-devel] [PATCH 0141] Generalize attribute_name<->rdata_type conversions In-Reply-To: <5187CEF5.7030200@redhat.com> References: <51630222.3010807@redhat.com> <5187CEF5.7030200@redhat.com> Message-ID: <518D0AE1.6040609@redhat.com> On 6.5.2013 17:40, Tomas Hozza wrote: > On 04/08/2013 07:45 PM, Petr Spacek wrote: >> Generalize attribute_name<->rdata_type conversions. >> >> Attribute names are generated on-the-fly: String "Record" is appended >> to textual representation of DNS RDATA type. >> >> String "Record" is cut down from the attribute name during >> attribute name to rdata type conversion. >> >> From now, the plugin doesn't add artificial limitation to supported >> record types. > > ACK. > > The patch looks good. (I didn't do functional test) > > Cosmetic issue: > I think it would be good to dynamically allocate "mod_type" in LDAPMod > in every case and include the "mod_type" memory freeing in > free_ldapmod() function. Now one has to be be careful when it is > statically or dynamically allocated. Before it was static in every case. It is good idea. This version of the patch contains ldap_mod_create() function which allocates the whole structure including mod_type of fixed size. All writes to mod_type checks the array length, so it should not cause any harm. The function modify_soa_record() still uses statically allocated LDAPMod structure with statically allocated strings for mod_type, but the LDAPMod structure never leave this function. There are no calls to ldap_mod_create() and ldap_mod_free(), so I think it is obvious. Tbabej, please try to dynamically update some A records with sync_ptr enabled. (And of course the support for some new type, like TLSA.) Thank you! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0141-2-Generalize-attribute_name-rdata_type-conversions.patch Type: text/x-patch Size: 10661 bytes Desc: not available URL: From rcritten at redhat.com Fri May 10 17:41:30 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 May 2013 13:41:30 -0400 Subject: [Freeipa-devel] Announcing FreeIPA 3.2.0 Message-ID: <518D314A.3090405@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.2.0. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 19 and is on its way to updates-testing. Many thanks to those that tested our alpha and beta releases and those that participated in the Fedora 19 Test day. Several issues were uncovered and resolved due to your hard work. == Highlights in 3.2.0 == === New features for 3.2.0 === * Support installing FreeIPA without an embedded Certificate Authority, with user-provided SSL certificates for the HTTP and Directory servers. [1] * New cert-find command. Search certificates in the Dogtag database based on their serial number, validity or revocation details. This feature is available both as a CLI command and Web UI page. [2] * New trustconfig-show and trustconfig-mod command. Show or modify AD Trust settings generated during AD Trust installation (ipa-adtrust-install) [3] * Multiple FreeIPA servers can now be designated as Domain Controllers for trusts with Active Directory [12] * New realmdomains-show and realmdomains-mod command. Manage list of DNS domains associated with FreeIPA realm (realmdomains sommand). This list is primarily used by AD, which can pull all domains managed by FreeIPA and use that list for routing authentication requests for domains which do not match FreeIPA realm name. [4] * Support trusted domain users in HBAC test command (hbactest command). * Allow filtering incoming trusted domain SIDs per-trust (trust-mod command). [5] * Configurable PAC type for services. Service commands can now configure a set of PAC types (MS-PAC, PAD, no PAC) that are supported and handled for the service. * Faster UI loading. FreeIPA Web UI application is now packaged in minimalized format. FreeIPA web server is now also able to transmit data in compressed format. [6] [7] * UI now accepts confirmation of cancel of its dialogs via keyboard [11] * Client reenrollment. A host that has been recreated can now be reenrolled to FreeIPA server using a backed up host keytab or admin credentials [8] * Service and Host commands now provide options to add or remove selected Kerberos flags [9] * Full system backup and restore [13] * Experimental extensible interface for Web UI [14] * Source hosts have been completely removed from HBAC. They haven't been used by SSSD for quite some time and are being removed to avoid the suggestion that they might actually do something. * Web UI is now capable to translate SIDs to user and group names for external group members * Updated French, Ukranian and Spanish translations. === Bug fixes === * Fixed migration from OpenLDAP. FreeIPA is now able to migrate users and groups from OpenLDAP database instances. * Migration process is now also a lot faster and provides more debug output (to httpd error log). * SUDO rules disabled by sudorule-disable command are now removed from ou=sudoers compat tree without a need to restart 389 Directory Server instance. * Fixed LDAP schema upgrade when upgrading from a pre-2.2.0 release * Fixed server installation with external CA (--external-ca) * Consolidate on-line help system, show help without need of valid Kerberos credentials (ipa help) * New LDAP plugin (ipa_dns) has been added to add missing idnsSOASerial attribute for replicas which either do not have integrated DNS service enabled to which have disabled SOA serial autoincrement * LDAP lockout plugin has been fixed so that lockout policies are applied consistently both for LDAP binds and Kerberos authentication * trust-resolve CLI command added to help resolving SIDs in Web UI to groups and users for external group members [16] * ... and many others stabilization fixes, see Detailed changelog for full details == Changes in API or CLI == === Dropped --selfsign option === FreeIPA servers prior to 3.2.0 could be installed with --selfsign option. This configured the server with a NSS database based Certificate Authority with a selfsigned CA certificate and limited certificate operation support. This option was always intended for development or testing purposes only and was not intended for use in production. This release drops this option and deprecates the functionality. FreeIPA servers installed with the --selfsign option will be converted to CA-less. See [15] for more information and instructions for manual certificate management. FreeIPA servers version 3.2.0 and later supports the following 2 flavors of certificate management: * FreeIPA with pki-ca (dogtag) with either a self-signed certificate or with a certificate signed by external CA (--external-ca option) * FreeIPA with no pki-ca installed with certificates signed and provided by an external CA [1] === Dropped CSV support === FreeIPA client CLI supported CSV in some arguments so that multiple values could be added with just one convenient option: ipa permission-add some-perm --permissions=read,write --attrs=sn,cn ipa dnsrecord-add example.com --a-rec=10.0.0.1,10.0.0.2 CSV parsing however introduces great difficulty when trying to include a value with an embedded space in it. Escaping these values is not intuitive and made it very difficult to add such values. The level of effort in working around the CSV problems has come to the point where the benefits of it are outweighed by the problems which lead to decision to drop CSV support in CLI altogether [10]. There are several ways to workaround lack of CSV: Provide an argument multiple times on the command-line: ipa permission-add some-perm --permissions=read --permissions=write --attrs=sn --attrs=cn ipa dnsrecord-add example.com --a-rec=10.0.0.1 --a-rec=10.0.0.2 Let BASH do the expansion for you: ipa permission-add some-perm --permissions={read,write} --attrs={sn,cn} ipa dnsrecord-add example.com --a-rec={10.0.0.1,10.0.0.2} == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Due to changes related to OCSP/CRL URI fix [1], ipa-ca.DOMAIN DNS name is automatically converted from a set of CNAMEs to a set of A/AAAA records pointing to FreeIPA servers with CA configured. FreeIPA servers installed with the --selfsign option will be converted to CA-less. See the section above titled "Dropped --selfsign option". Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == References == [1] http://freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs == Documentation == * [1] http://www.freeipa.org/page/V3/CA-less_install * [2] http://www.freeipa.org/page/V3/Cert_find * [3] http://www.freeipa.org/page/V3/Trust_config_command * [4] http://www.freeipa.org/page/V3/Realm_Domains * [5] http://www.freeipa.org/page/V3/Configurable_SID_Blacklists * [6] http://www.freeipa.org/page/V3/WebUI_gzip_compression * [7] http://www.freeipa.org/page/V3/WebUI_build * [8] http://www.freeipa.org/page/V3/Forced_client_re-enrollment * [9] http://www.freeipa.org/page/V3/Kerberos_Flags * [10] http://www.freeipa.org/page/V3/Drop_CSV * [11] http://www.freeipa.org/page/V3/WebUI_keyboard_confirmation * [12] http://www.freeipa.org/page/V3/MultipleTrustServers * [13] http://freeipa.org/page/V3/Backup_and_Restore * [14] http://www.freeipa.org/page/V3/WebUI_extensible_navigation * [15] http://www.freeipa.org/page/V3/Drop_selfsign_functionality * [16] http://www.freeipa.org/page/V3/Trust_resolve_command == Detailed Changelog since 3.1.0 == Alexander Bokovoy (9): * Update plugin to upload CA certificate to LDAP * ipasam: use base scope when fetching domain information about own domain * ipaserver/dcerpc: enforce search_s without schema checks for GC searching * ipa-replica-manage: migrate to single_value after LDAPEntry updates * Process exceptions when talking to Dogtag * ipasam: add enumeration of UPN suffixes based on the realm domains * Enhance ipa-adtrust-install for domains with multiple IPA server * spec: detect Kerberos DAL driver ABI change from installed krb5-devel * Resolve SIDs in Web UI Ana Krivokapic (24): * Raise ValidationError for incorrect subtree option. * Add crond as a default HBAC service * Take into consideration services when deleting replicas * Add list of domains associated to our realm to cn=etc * Improve error messages for external group members * Remove check for alphabetic only characters from domain name validation * Fix internal error for ipa show-mappings * Realm Domains page * Use default NETBIOS name in unattended ipa-adtrust-install * Add mkhomedir option to ipa-server-install and ipa-replica-install * Remove CA cert on client uninstall * Fix output for some CLI commands * Add missing summary message to dnszone_del * Remove HBAC source hosts from web UI * Remove any reference to HBAC source hosts from help * Deprecate HBAC source hosts from CLI * Integrate realmdomains with IPA DNS * Improve help text for HBAC service groups * Do not sort dictionaries in assert_deepequal utility function * Handle missing /etc/ipa in ipa-client-install * Fix the spec file * Do not display an interactive mode message in unattended mode * Add missing permissions to Host Administrators privilege * Always stop dirsrv in 'ipactl stop' Brian Cook (1): * Add DNS Setup Prompt to Install JR Aquino (1): * Allow PKI-CA Replica Installs when CRL exceeds default maxber value Jakub Hrozek (1): * Allow ipa-replica-conncheck and ipa-adtrust-install to read krb5 includedir Jan Cholasta (33): * Pylint cleanup. * Drop ipapython.compat. * Add support for RFC 6594 SSHFP DNS records. * Raise ValidationError on invalid CSV values. * Run interactive_prompt callbacks after CSV values are split. * Add custom mapping object for LDAP entry data. * Add make_entry factory method to LDAPConnection. * Remove the Entity class. * Remove the Entry class. * Use the dn attribute of LDAPEntry to set/get DNs of entries. * Preserve case of attribute names in LDAPEntry. * Aggregate IPASimpleLDAPObject in LDAPEntry. * Support attributes with multiple names in LDAPEntry. * Use full DNs in plugin code. * Remove DN normalization from the baseldap plugin. * Remove support for DN normalization from LDAPClient. * Fix remove while iterating in suppress_netgroup_memberof. * Remove disabled entries from sudoers compat tree. * Fix internal error in output_for_cli method of sudorule_{enable,disable}. * Do not fail if schema cannot be retrieved from LDAP server. * Allow disabling LDAP schema retrieval in LDAPClient and IPAdmin. * Allow disabling attribute decoding in LDAPClient and IPAdmin. * Disable schema retrieval and attribute decoding when talking to AD GC. * Add Kerberos ticket flags management to service and host plugins. * Do actually stop pki_cad in stop_pkicad instead of starting it. * Use only one URL for OCSP and CRL in IPA certificate profile. * Use A/AAAA records instead of CNAME records in ipa-ca. * Delete DNS records in ipa-ca on ipa-csreplica-manage del. * Use correct zone when removing DNS records of a master. * Add DNS records for existing masters when installing DNS for the first time. * Add ipa-ca records for existing CA masters when installing DNS for the first time. * Add support for OpenSSH 6.2. * Fix normalization of FQDNs in DNS installer code. John Dennis (2): * Cookie Expires date should be locale insensitive * Use secure method to acquire IPA CA certificate Lynn Root (3): * Added the ability to do Beta versioning * Fixed the catch of the hostname option during ipa-server-install * Raise ValidationError when CSR does not have a subject hostname Martin Kosek (65): * Add Lynn Root to Contributors.txt * Enable SSSD on client install * Fix delegation-find command --group handling * Do not crash when Kerberos SRV record is not found * permission-find no longer crashes with --targetgroup * Avoid CRL migration error message * Sort LDAP updates properly * Upgrade process should not crash on named restart * Installer should not connect to 127.0.0.1 * Fix migration for openldap DS * Remove unused krbV imports * Use fully qualified CCACHE names * Fix permission_find test error * Add trusconfig-show and trustconfig-mod commands * ipa-kdb: add sentinel for LDAPDerefSpec allocation * ipa-kdb: avoid ENOMEM when all SIDs are filtered out * ipa-kdb: reinitialize LDAP configuration for known realms * Add SID blacklist attributes * ipa-kdb: read SID blacklist from LDAP * ipa-sam: Fill SID blacklist when trust is added * ipa-adtrust-install should ask for SID generation * Test NetBIOS name clash before creating a trust * Generalize AD GC search * Do not hide SID resolver error in group-add-member * Add support for AD users to hbactest command * Fix hbachelp examples formatting * ipa-kdb: remove memory leaks * ipa-kdb: fix retry logic in ipadb_deref_search * Add autodiscovery section in ipa-client-install man pages * Avoid internal error when user is not Trust admin * Use fixed test domain in realmdomains test * Bump FreeIPA version for development branch * Remove ORDERING for IA5 attributeTypes * Fix includedir directive in krb5.conf template * Use new 389-ds-base cleartext password API * Do not hide idrange-add errors when adding trust * Preserve order of servers in ipa-client-install * Avoid multiple client discovery with fixed server list * Update named.conf parser * Use tkey-gssapi-keytab in named.conf * Do not force named connections on upgrades * ipa-client discovery with anonymous access off * Use temporary CCACHE in ipa-client-install * Improve client install LDAP cert retrieval fallback * Configure ipa_dns DS plugin on install and upgrade * Fix structured DNS record output * Bump selinux-policy requires * Clean spec file for Fedora 19 * Remove build warnings * Remove syslog.target from ipa.server * Put pid-file to named.conf * Update mod_wsgi socket directory * Normalize RA agent certificate * Require 389-base-base 1.3.0.5 * Change CNAME and DNAME attributes to single valued * Improve CNAME record validation * Improve DNAME record validation * Become 3.2.0 Prerelease 1 * Fix trustconfig-mod primary group error * Require new samba and krb5 * Add userClass attribute for hosts * Update pki proxy configuration * Do not add ipa-ca records on CA-less installs * Fix ipa-ca DNS name creation * Fix SASL_NOCANON behavior for LDAPI Nathaniel McCallum (1): * Ignore log files from automake tests Petr Spacek (1): * Add 389 DS plugin for special idnsSOASerial attribute handling Petr Viktorin (113): * Sort Options and Outputs in API.txt * Add the CA cert to LDAP after the CA install * Better logging for AdminTool and ipa-ldap-updater * Port ipa-replica-prepare to the admintool framework * Make ipapython.dogtag log requests at debug level, not info * Don't add another nsDS5ReplicaId on updates if one already exists * Improve `ipa --help` output * Print help to stderr on error * Store the OptionParser in the API, use it to print unified help messages * Simplify `ipa help topics` output * Add command summary to `ipa COMMAND --help` output * Mention `ipa COMMAND --help` as the preferred way to get command help * Parse command arguments before creating a context * Add tests for the help command & --help options * In topic help text, mention how to get help for commands * Check SSH connection in ipa-replica-conncheck * Use ipauniqueid for the RDN of sudo commands * Prevent a sudo command from being deleted if it is a member of a sudo rule * Update sudocmd ACIs to use targetfilter * Add the version option to all Commands * Add ipalib.messages * Add client capabilities, enable messages * Rename the "messages" Output of the i18n_messages command to "texts" * Fix permission validation and normalization in aci.py * Remove csv_separator and csv_skipspace Param arguments * Drop support for CSV in the CLI client * Update argument docs to reflect dropped CSV support * Update plugin docstrings (topic help) to reflect dropped CSV support * cli: Do interactive prompting after a context is created * Remove some unused imports * Remove unused methods from Entry, Entity, and IPAdmin * Derive Entity class from Entry, and move it to ldapupdate * Use explicit loggers in ldap2 code * Move LDAPEntry to ipaserver.ipaldap and derive Entry from it * Remove connection-creating code from ShemaCache * Move the decision to force schema updates out of IPASimpleLDAPObject * Move SchemaCache and IPASimpleLDAPObject to ipaserver.ipaldap * Start LDAPConnection, a common base for ldap2 and IPAdmin * Make IPAdmin not inherit from IPASimpleLDAPObject * Move schema-related methods to LDAPConnection * Move DN handling methods to LDAPConnection * Move filter making methods to LDAPConnection * Move entry finding methods to LDAPConnection * Remove unused proxydn functionality from IPAdmin * Move entry add, update, remove, rename to LDAPConnection * Implement some of IPAdmin's legacy methods in terms of LDAPConnection methods * Replace setValue by keyword arguments when creating entries * Use update_entry with a single entry in adtrustinstance * Replace entry.getValues() by entry.get() * Replace entry.setValue/setValues by item assignment * Replace add_s and delete_s by their newer equivalents * Change {add,update,delete}_entry to take LDAPEntries * Remove unused imports from ipaserver/install * Remove unused bindcert and bindkey arguments to IPAdmin * Turn the LDAPError handler into a context manager * Remove dbdir, binddn, bindpwd from IPAdmin * Remove IPAdmin.updateEntry calls from fix_replica_agreements * Remove IPAdmin.get_dns_sorted_by_length * Replace IPAdmin.checkTask by replication.wait_for_task * Introduce LDAPEntry.single_value for getting single-valued attributes * Remove special-casing for missing and single-valued attributes in LDAPUpdate._entry_to_entity * Replace entry.getValue by entry.single_value * Replace getList by a get_entries method * Remove toTupleList and attrList from LDAPEntry * Rename LDAPConnection to LDAPClient * Replace addEntry with add_entry * Replace deleteEntry with delete_entry * Fix typo and traceback suppression in replication.py * replace getEntry with get_entry (or get_entries if scope != SCOPE_BASE) * Inline inactivateEntry in its only caller * Inline waitForEntry in its only caller * Proxy LDAP methods explicitly rather than using __getattr__ * Remove search_s and search_ext_s from IPAdmin * Replace IPAdmin.start_tls_s by an __init__ argument * Remove IPAdmin.sasl_interactive_bind_s * Remove IPAdmin.simple_bind_s * Remove IPAdmin.unbind_s(), keep unbind() * Use ldap instead of _ldap in ipaldap * Do not use global variables in migration.py * Use IPAdmin rather than raw python-ldap in migration.bind * Use IPAdmin rather than raw python-ldap in ipactl * Remove some uses of raw python-ldap * Improve LDAPEntry tests * Fix installing server with external CA * Change DNA magic value to -1 to make UID 999 usable * Move ipaldap to ipapython * Remove ipaserver/ipaldap.py * Use IPAdmin rather than raw python-ldap in ipa-client-install * Use IPAdmin rather than raw python-ldap in migration.py and ipadiscovery.py * Remove unneeded python-ldap imports * Don't download the schema in ipadiscovery * ipa-server-install: Make temporary pin files available for the whole installation * ipa-server-install: Remove the --selfsign option * Remove unused ipapython.certdb.CertDB class * ipaserver.install.certs: Introduce NSSDatabase as a more generic certutil wrapper * Trust CAs from PKCS#12 files even if they don't have Friendly Names * dsinstance, httpinstance: Don't hardcode 'Server-Cert' * Support installing with custom SSL certs, without a CA * Load the CA cert into server NSS databases * Do not call cert-* commands in host plugin if a RA is not available * ipa-client-install: Do not request host certificate if server is CA-less * Display full command documentation in online help * Remove 'cn' attribute from idnsRecord and idnsZone objectClasses * ipa-server-install: correct help text for --external_{cert,ca}_file * Update translations from Transifex * Uninstall selfsign CA on upgrade * Remove obsolete self-sign references from man pages, docstrings, comments * Drop --selfsign server functionality * Use two digits for each part of NUM_VERSION * Fix syntax of the dc attributeType * Fix syntax errors in schema files * Only require libsss_nss_idmap-python in Fedora 19+ * Update translations from Transifex Petr Vobornik (181): * Make confirm_dialog a base class of revoke and restore certificate dialogs * Make confirm_dialog a base class for deleter dialog * Make confirm_dialog a base class for message_dialog * Confirm mixin * Confirm adder dialog by enter * Confirm error dialog by enter * Focus last dialog when some is closed * Confirm association dialogs by enter * Standardize login password reset, user reset password and host set OTP dialogs * Focus first input element after 'Add and Add another' * Enable mod_deflate * Use Uglify.js for JS optimization * Dojo Builder * Config files for builder of FreeIPA UI layer * Minimal Dojo layer * Web UI development environment directory structure and configuration * Web UI Sync development utility * Move of Web UI non AMD dep. libs to libs subdirectory * Move of core Web UI files to AMD directory * Update JavaScript Lint configuration file * AMD config file * Change Web UI sources to simple AMD modules * Updated makefiles to build FreeIPA Web UI layer * Change tests to use AMD loader * Fix BuildRequires: rhino replaced with java-1.7.0-openjdk * Develop.js extended * Allow to specify modules for which builder doesn't raise dependency error * Web UI build profile updated * Combobox keyboard support * Fix dirty state update of editable combobox * Fix handling of no_update flag in Web UI * Web UI: configurable SID blacklists * Web UI:Certificate pages * Web UI:Choose different search option for cert-find * Fixed Web UI build error caused by rhino changes in F19 * Nestable checkbox/radio widget * Added Web UI support for service PAC type option: NONE * Web UI: Disable cert functionality if a CA is not available * Add ipakrbokasdelegate option to service and host Web UI pages * Run permission target switch action only for visible widgets * Filter groups by type (POSIX, non-POSIX, external) * Global trust config page * Don't show trusts pages when trust is not configured * Fix regression in group type selection in group adder dialog * Fix: Certificate status is not visible in Service and Host page * jsl update * Update of Dojo build * Basic implementation of registers * i18n - internationalized text provider * Phases - application lifecycle * Config.js * Menu and application controller refactoring * Removed old navigation code * Remove IPA.nav usage, obsolete entity.get_primary_key * Fix nested facet search * Remove IPA.current_entity usage * Set pkeys to add,remove dialog * File dependencies added to Web UI Makefile * Add menu memory * Rename path array from hash to path in hash generation * Fix selection of menu in automember * Fix facet needs_update behavior * Removed incorrect success message when adding of external member failed * Removed entity.get_primary from association facet * get_primary_key function usages removed * DNS menu fixed * Certificates, Realm domains added to navigation * Remove old navigation code in certificates * Fix needs_update on object change * Don't expect key for singleton objects (dnsconfig, config, realmdomains) * Raise only one "set" event on facet.state.set * Fix dirty dialog behavior * Add handling of runtime and shutdown phase. App-init renamed to init. * Fix unit tests * Web UI plugin loader * Fix hbactest styles * Menu proxy * Proper removal of dns menu item when dns is not installed * Fixed errors in DNS pages * Fix in state change handling and reporting * Fix tab switching for nested entities * Fix add/deletion of automember rule - caused by not setting facet for entity adder dialog * Use dojo/on instead of dojo/topic for facet-xxx events' * Rename alternation phase to customization * Replace id usage in App widget by class * Add phase on exact position * Metadata and text providers * Limit Provider reporting * Use text.get for transforming values supplied by spec * Replace IPA.get_message with text.get * Replace IPA.messages with @i18n definition in spec objects * Replace IPA.messages with @i18n definition for label specs * Replace IPA.messages with @i18n definition for add_title specs * Replace IPA.messages with @i18n definition for remove_title specs * Replace IPA.messages with @i18n definition for message specs * Replace IPA.messages with @i18n definition for title specs * Use text.get in IPA.notify_success * Replace remaining IPA.messages with text.get calls * Fix facet section labels * Remove invalid label definition from cert search facet * Replace IPA.get_message with text.get * Remove text.get usage from spec * Add pre and post build operations * Spec modification by diff object * Builder: added pre_ops and post_ops * Modularize group.js * Modularize details.js * Builder: factory,ctor overrides, mass build * Replace old builder by new implementation * Rename build constructor to ctor * Spec utils * Basic build tests * Rename factory to $factory in spec objects * Builder: return null if no spec supplied * Builder: fix overrides names - add $ * Builder: fix infinite loop when using spec with circular dependency * Rename factory to $factory in spec objects modifications * Builder: return object when it's already built * Use IPA.object() as a base factory for framework objects * Handle built object in spec * Report phase errors * Builder: allow to use custom factory/ctor when using type * Fix construct registry map reference * Replace IPA.facet_builder with facets.builder * Builder: do not break on expected errors * Builder: remove item from singleton registry * Builder: fix inner array and obj references * Use entities module for entity registration, build and holding * Builder: add set method to Singleton_registry * Builder: build type without prior registration * Phases: warn when adding task for nonexistent phase * Builder: create Construct_registry by default in builder * Builder: global builder and registry * Replace IPA.widget_factories and IPA_field_factories with registry * Builder: allow string spec as spec property instead of type * Replace build logic in widget and field builder by new builder * Registry and builder for formatters * Builder: return null if no spec supplied - fix * Replace formatter creation with definition in specs * Builder and registry for validators * Change widget.build_child interface to the builder's * Builder and registry for actions * Replace usage of action factories with types * Fix incorrect type -> $type conversion * Make facet and entity policies declarative * Make summary conditions declarative * Allow metadata provider format for field metadata declaration * Replace IPA.get_entity_param calls in specs with provider strings * Replace IPA.get_command_option calls in specs with provider strings * Replace IPA.get_command_arg calls in specs with provider strings * Builders: allow pre_ops and post_ops in build overrides * Use builder for entity dialogs * Builder: allow registration without factory or ctor * Fix hbactest after rebase * Fix trustconfig after rebase * Entity registry and builder which allow definition by spec * Entity: allow definition of facet_groups in entity specs * Builder: handle expected errors in post_ops * Entity build: test for enabled in post_op * Convert definitions of entities to spec objects * Replace IPA.metadata.objects... with declarative definitions * Remove cert menu item when disabled * Don't automatically refresh facet after action success * Move spec creations of sudorule, hbacrule, netgroup and selinuxusermap details facet from their factories * Removal of IPA.metadata usages * Add widget updated event * Fix rule table add/delete button enablement * Replace ./facets with reg.facet * Remove entities.js, facets.js * Generate plugin index dynamically * Switch customization and registration phase * Do not offer already added members in association dialogs when different casing * Builder: fix join of pre_ops and post_ops arrays * Fix: make association facets in selfservice readonly * Builder: Singleton_registry: return null when construction spec not available * Navigation: handle invalid routes * Fix trustconfig specification * Fix WebUI crash when server installed as CA-less * Fix crash on ssh key add * Fix crash on host deleletion * Enable standalone facets in menu.add_item Rob Crittenden (29): * Convert uniqueMember members into DN objects. * Add Ana Krivokapic to Contributors.txt * Do SSL CA verification and hostname validation. * Don't initialize NSS if we don't have to, clean up unused cert refs * Update anonymous access ACI to protect secret attributes. * Make certmonger a (pre) requires on server, restart it before upgrading * Use new certmonger locking to prevent NSS database corruption. * Improve migration performance * Add LDAP server fallback to client installer * Prevent a crash when no entries are successfully migrated. * Implement the cert-find command for the dogtag CA backend. * Add missing v3 schema on upgrades, fix typo in schema. * Don't base64-encode the CA cert when uploading it during an upgrade. * Extend ipa-replica-manage to be able to manage DNA ranges. * Improve some error handling in ipa-replica-manage * Fix lockout of LDAP bind. * Fix two failing tests due to missing krb ticket flags * Full system backup and restore * Apply LDAP update files in blocks of 10, as originally designed. * Revert "Fix permission_find test error" * Become 3.2.0 Beta 1 * Handle socket.gethostbyaddr() exceptions when verifying hostnames. * Require version of NSS that properly parses base64-encoded certs * Drop uniqueMember mapping with nss-pam-ldapd. * Add Nathaniel McCallum to Contributors.txt * Handle a 501 in cert-find from dogtag as a "not supported" * Specify the location for the agent PKCS#12 file so we don't have to move it. * Set KRB5CCNAME so httpd s4u2proxy can with with newer krb5-server * Become 3.2.0 Simo Sorce (2): * Log info on failure to connect * Upload CA cert in the directory on install Sumit Bose (21): * ipa-kdb: remove unused variable * ipa-kdb: Uninitialized scalar variable in ipadb_reinit_mspac() * ipa-sam: Array compared against 0 in ipasam_set_trusted_domain() * ipa-kdb: Dereference after null check in ipa_kdb_mspac.c * ipa-lockout: Wrong sizeof argument in ipa_lockout.c * ipa-extdom: Double-free in ipa_extdom_common.c * ipa-pwd: Unchecked return value ipapwd_chpwop() * Revert "MS-PAC: Special case NFS services" * Add NFS specific default for authorization data type * ipa-kdb: Read global defaul ipaKrbAuthzData * ipa-kdb: Read ipaKrbAuthzData with other principal data * ipa-kdb: add PAC only if requested * Add unit test for get_authz_data_types() * Mention PAC issue with NFS in service plugin doc * Allow 'nfs:NONE' in global configuration * Add support for cmocka C-Unit Test framework * ipa-pwd-extop: do not use dn until it is really set * Do not lookup up the domain too early if only the SID is known * Do not store SID string in a local buffer * Allow ID-to-SID mappings in the extdom plugin * ipa-kdb: Free talloc autofree context when module is closed Timo Aaltonen (1): * convert the base platform modules into packages Tomas Babej (27): * Relax restriction for leading/trailing whitespaces in *-find commands * Forbid overlapping rid ranges for the same id range * Fix a typo in ipa-adtrust-install help * Prevent integer overflow when setting krbPasswordExpiration * Add option to specify SID using domain name to idrange-add/mod * Prevent changing protected group's name using --setattr * Use default.conf as flag of IPA client being installed * Make sure appropriate exit status is returned in make-test * Make options checks in idrange-add/mod consistent * Add trusted domain range objectclass when using idrange-mod * Perform secondary rid range overlap check for local ranges only * Add support for re-enrolling hosts using keytab * Make sure uninstall script prompts for reboot as last * Remove implicit Str to DN conversion using *-attr * Enforce exact SID match when adding or modifying a ID range * Allow host re-enrollment using delegation * Add logging to join command * Properly handle ipa-replica-install when its zone is not managed by IPA * Add nfs:NONE to default PAC types only when needed * Update only selected attributes for winsync agreement * Add hint message about --force-join option when enrollment fails * Avoid removing sss from nssswitch.conf during client uninstall * Allow underscore in record targets * Make gecos field editable in Web UI * Preserve already configured options in openldap conf * Enforce host existence only where needed in ipa-replica-manage * Handle connection timeout in ipa-replica-manage From edewata at redhat.com Fri May 10 20:37:27 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 10 May 2013 15:37:27 -0500 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518D0661.3050405@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> Message-ID: <518D5A87.6070105@redhat.com> On 5/10/2013 9:38 AM, Petr Viktorin wrote: > On 05/10/2013 03:57 PM, Ana Krivokapic wrote: > [...] >> Thanks for catching the bugs. Updated patches are attached. > > Thanks! It works nicely. > Endi is doing a quick check of the Javascript, if he doesn't find an > issue then ACK. > > If this still makes it into 3.2.0, please only push the first patch there. I tried this in the UI: Zone name: test.com Authoritative nameserver: ns.sometest.com. The 'Nameserver IP address' field is still enabled. This is because the name server is considered in the zone although it's actually not. The CLI seems to work fine, it didn't ask for IP address. The UI probably could be fixed using endsWith(ns, '.' + zone). Everything else looks fine. ACK with the fix. -- Endi S. Dewata From npmccallum at redhat.com Fri May 10 20:55:49 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 10 May 2013 16:55:49 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1367586519.2976.165.camel@willson.li.ssimo.org> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> Message-ID: <1368219349.2470.4.camel@localhost.localdomain> On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: > On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: > > On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: > > > All issues fixed unless noted below... The attached patches are tested > > > to work. > > > > > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > > > > > >> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > > >> (although I know slapi_ch_malloc() currently just aborts on failure, I > > >> think that is plain wrong which is why I would prefer using > > >> malloc/strdup, but well, I guess this is not something I am going to > > >> care too much about for now). > > > Not fixed. > > > > > >> - Is the logic with auth_type_used correct ? > > >> At least the name of the variable sounds misleading, because you set it > > >> only if the authentication was successful but not set if it was 'used' > > >> but was unsuccessful. Made me look at it multiple times to reconstuct > > >> the logic. The var name could be better, however I also want a comment > > >> that explain exactly how we are going to manage authentication and > > >> fallbacks here as that logic is critical and is useful for anyone that > > >> is going to have to change this code later in order not to break it. > > > The variable is now gone. I re-factored the section to make the logic > > > clearer and put a nice big comment up top. > > > > > >> - General question: how does this PRE_BIND plugin interact with > > >> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > > >> Are you going to cause that plugin not to run by returning a result > > >> directly in this function ? > > >> Or is this plugin configured to run only after the previous one went > > >> through ? > > >> I ask because I do not see any ordering information in the cn=config > > >> plugin configuration so it is not immediately clear to me. > > > That is a good question for Nathan since he wrote this part of the > > > code... > > We would need to set the precedence if you want a predictable/guaranteed > > execution order. If a pre-BIND plug-in callback returns non-zero (which > > you should do when the plug-in sends the result to the client directly), > > it will cause other pre-bind plug-ins to not be called. This is > > actually how all pre-op plug-ins work. If a pre-op callback returns an > > error, we don't call the rest of the pre-op plug-ins in the list. > > Ok, but this does not answer my question. > We definitely need to *always* run our other preop plugin as we do > sanity checks like verifying if the user is enabled/disabled etc... > Also we need to understand how to deal with migrating password auth when > OTP is enabeld. > > TBH I think we should not have a separate OTP-auth plugin but we should > probably have a single plugin that handles authentication and the 2 > should be merged. Keeping them separate is going to cause more harm than > good with unexpected interactions. > > We could still have 2 plugins and simply move the prebind action > currently don in ipa-pwd-extop to the otp plugin by making some more > code common. But it is probably easier to just merge OTP into > ipa-pwd-extop right now than try to do a huge refactoring. We can always > refactor the ipa-pwd-extop plugin later. The attached patches encompass an initial review of the companion daemon and merge of ipa-otp into ipa-pwd-extop. Unfortunately, merging ipa-otp into ipa-pwd-extop appears to have broken something during install, but I don't have enough familiarity with 389 to understand what I've broken. If I upgrade after an install, it appears to work. An RPM with the patches is available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5362935 Nathan / Rob / Simo, could you take a look and see what might be broken in ipa-pwd-extop? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Add-OTP-support-to-ipa-pwd-extop.patch Type: text/x-patch Size: 61146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Remove-unnecessary-prefixes-from-ipa-pwd-extop-files.patch Type: text/x-patch Size: 185438 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-the-krb5-FreeIPA-RADIUS-companion-daemon.patch Type: text/x-patch Size: 62453 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-ipa-kdb-Add-OTP-support.patch Type: text/x-patch Size: 6525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-IPA-OTP-schema-and-ACLs.patch Type: text/x-patch Size: 22589 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-ipaUserAuthType-and-ipaUserAuthTypeClass.patch Type: text/x-patch Size: 4215 bytes Desc: not available URL: From edewata at redhat.com Fri May 10 21:00:58 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 10 May 2013 16:00:58 -0500 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <5187D835.5040000@redhat.com> References: <51756B5E.8030604@redhat.com> <5183F576.6070109@redhat.com> <5187D835.5040000@redhat.com> Message-ID: <518D600A.70901@redhat.com> On 5/6/2013 11:20 AM, Petr Vobornik wrote: >> In the simpleuser.js the new 'user' entity is registered first then the >> old 'user' entity is removed, which could be confusing because they are >> both identified using 'user'. Should register() automatically remove the >> old object? > > I've mixed feelings about it. I would rather keep the methods simple - > one task oriented. > > The issue was caused by other problem: The plugin had to wait for > metadata and profile information (to check self-service). So the > callback is called after menu is created and menu requires the entity to > be resolved. Should we postpone the menu creation to a different phase? > Maybe a new one? I'm not sure exactly how the menu works, but if you create another phase how will it address the problem? As a side note, if the phases are implemented as regular class methods, the plugins probably can just override the method. You won't need to introduce a new phase. -- Endi S. Dewata From simo at redhat.com Fri May 10 21:12:38 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 May 2013 17:12:38 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1368219349.2470.4.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1368219349.2470.4.camel@localhost.localdomain> Message-ID: <1368220358.20220.194.camel@willson.li.ssimo.org> On Fri, 2013-05-10 at 16:55 -0400, Nathaniel McCallum wrote: > On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: > > On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: > > > On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: > > > > All issues fixed unless noted below... The attached patches are tested > > > > to work. > > > > > > > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > > > > > > > >> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > > > >> (although I know slapi_ch_malloc() currently just aborts on failure, I > > > >> think that is plain wrong which is why I would prefer using > > > >> malloc/strdup, but well, I guess this is not something I am going to > > > >> care too much about for now). > > > > Not fixed. > > > > > > > >> - Is the logic with auth_type_used correct ? > > > >> At least the name of the variable sounds misleading, because you set it > > > >> only if the authentication was successful but not set if it was 'used' > > > >> but was unsuccessful. Made me look at it multiple times to reconstuct > > > >> the logic. The var name could be better, however I also want a comment > > > >> that explain exactly how we are going to manage authentication and > > > >> fallbacks here as that logic is critical and is useful for anyone that > > > >> is going to have to change this code later in order not to break it. > > > > The variable is now gone. I re-factored the section to make the logic > > > > clearer and put a nice big comment up top. > > > > > > > >> - General question: how does this PRE_BIND plugin interact with > > > >> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > > > >> Are you going to cause that plugin not to run by returning a result > > > >> directly in this function ? > > > >> Or is this plugin configured to run only after the previous one went > > > >> through ? > > > >> I ask because I do not see any ordering information in the cn=config > > > >> plugin configuration so it is not immediately clear to me. > > > > That is a good question for Nathan since he wrote this part of the > > > > code... > > > We would need to set the precedence if you want a predictable/guaranteed > > > execution order. If a pre-BIND plug-in callback returns non-zero (which > > > you should do when the plug-in sends the result to the client directly), > > > it will cause other pre-bind plug-ins to not be called. This is > > > actually how all pre-op plug-ins work. If a pre-op callback returns an > > > error, we don't call the rest of the pre-op plug-ins in the list. > > > > Ok, but this does not answer my question. > > We definitely need to *always* run our other preop plugin as we do > > sanity checks like verifying if the user is enabled/disabled etc... > > Also we need to understand how to deal with migrating password auth when > > OTP is enabeld. > > > > TBH I think we should not have a separate OTP-auth plugin but we should > > probably have a single plugin that handles authentication and the 2 > > should be merged. Keeping them separate is going to cause more harm than > > good with unexpected interactions. > > > > We could still have 2 plugins and simply move the prebind action > > currently don in ipa-pwd-extop to the otp plugin by making some more > > code common. But it is probably easier to just merge OTP into > > ipa-pwd-extop right now than try to do a huge refactoring. We can always > > refactor the ipa-pwd-extop plugin later. > > The attached patches encompass an initial review of the companion daemon > and merge of ipa-otp into ipa-pwd-extop. Unfortunately, merging ipa-otp > into ipa-pwd-extop appears to have broken something during install, but > I don't have enough familiarity with 389 to understand what I've broken. > If I upgrade after an install, it appears to work. > > An RPM with the patches is available here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5362935 > > Nathan / Rob / Simo, could you take a look and see what might be broken > in ipa-pwd-extop? how did it fail ? Do you have an install log file that shows the error ? Simo. -- Simo Sorce * Red Hat, Inc * New York From akrivoka at redhat.com Sun May 12 13:10:41 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Sun, 12 May 2013 15:10:41 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518D5A87.6070105@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> <518D5A87.6070105@redhat.com> Message-ID: <518F94D1.2030508@redhat.com> On 05/10/2013 10:37 PM, Endi Sukma Dewata wrote: > On 5/10/2013 9:38 AM, Petr Viktorin wrote: >> On 05/10/2013 03:57 PM, Ana Krivokapic wrote: >> [...] >>> Thanks for catching the bugs. Updated patches are attached. >> >> Thanks! It works nicely. >> Endi is doing a quick check of the Javascript, if he doesn't find an >> issue then ACK. >> >> If this still makes it into 3.2.0, please only push the first patch there. > > I tried this in the UI: > > Zone name: test.com > Authoritative nameserver: ns.sometest.com. > > The 'Nameserver IP address' field is still enabled. This is because the name > server is considered in the zone although it's actually not. > > The CLI seems to work fine, it didn't ask for IP address. > > The UI probably could be fixed using endsWith(ns, '.' + zone). Everything else > looks fine. ACK with the fix. > Fixed, updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0027-05-Prompt-for-nameserver-IP-address-in-dnszone-add.patch Type: text/x-patch Size: 9367 bytes Desc: not available URL: From pviktori at redhat.com Mon May 13 09:47:44 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 13 May 2013 11:47:44 +0200 Subject: [Freeipa-devel] [PATCH] 225 Remove leading zero from IPA_NUM_VERSION Message-ID: <5190B6C0.8030809@redhat.com> Due to my mistake in commit 9125285, the IPA_NUM_VERSION variable contained a leading zero, so it was treated as octal in Python code. Bumping the development version to 3.2.99 resulted in 030299, an invalid value. Luckily, 320 < 030200 < 30200 so the ordering is not broken. Sorry for the mistake. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0225-Remove-leading-zero-from-IPA_NUM_VERSION.patch Type: text/x-patch Size: 956 bytes Desc: not available URL: From pviktori at redhat.com Mon May 13 10:00:53 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 13 May 2013 12:00:53 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518F94D1.2030508@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> <518D5A87.6070105@redhat.com> <518F94D1.2030508@redhat.com> Message-ID: <5190B9D5.5000102@redhat.com> On 05/12/2013 03:10 PM, Ana Krivokapic wrote: > On 05/10/2013 10:37 PM, Endi Sukma Dewata wrote: >> On 5/10/2013 9:38 AM, Petr Viktorin wrote: >>> On 05/10/2013 03:57 PM, Ana Krivokapic wrote: >>> [...] >>>> Thanks for catching the bugs. Updated patches are attached. >>> >>> Thanks! It works nicely. >>> Endi is doing a quick check of the Javascript, if he doesn't find an >>> issue then ACK. >>> >>> If this still makes it into 3.2.0, please only push the first patch there. >> >> I tried this in the UI: >> >> Zone name: test.com >> Authoritative nameserver: ns.sometest.com. >> >> The 'Nameserver IP address' field is still enabled. This is because the name >> server is considered in the zone although it's actually not. >> >> The CLI seems to work fine, it didn't ask for IP address. >> >> The UI probably could be fixed using endsWith(ns, '.' + zone). Everything else >> looks fine. ACK with the fix. >> > > Fixed, updated patch attached. ACK for both patches -- Petr? From tbabej at redhat.com Mon May 13 11:44:09 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 13 May 2013 13:44:09 +0200 Subject: [Freeipa-devel] [PATCH] 225 Remove leading zero from IPA_NUM_VERSION In-Reply-To: <5190B6C0.8030809@redhat.com> References: <5190B6C0.8030809@redhat.com> Message-ID: <5190D209.8000207@redhat.com> On 05/13/2013 11:47 AM, Petr Viktorin wrote: > Due to my mistake in commit 9125285, the IPA_NUM_VERSION variable > contained a leading zero, so it was treated as octal in Python code. > Bumping the development version to 3.2.99 resulted in 030299, an > invalid value. > Luckily, 320 < 030200 < 30200 so the ordering is not broken. > > Sorry for the mistake. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, solves the issue, thanks. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon May 13 12:50:07 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 13 May 2013 14:50:07 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <518F94D1.2030508@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> <518D5A87.6070105@redhat.com> <518F94D1.2030508@redhat.com> Message-ID: <5190E17F.5040306@redhat.com> On 05/12/2013 03:10 PM, Ana Krivokapic wrote: > On 05/10/2013 10:37 PM, Endi Sukma Dewata wrote: >> On 5/10/2013 9:38 AM, Petr Viktorin wrote: >>> On 05/10/2013 03:57 PM, Ana Krivokapic wrote: >>> [...] >>>> Thanks for catching the bugs. Updated patches are attached. >>> >>> Thanks! It works nicely. >>> Endi is doing a quick check of the Javascript, if he doesn't find an >>> issue then ACK. >>> >>> If this still makes it into 3.2.0, please only push the first patch there. >> >> I tried this in the UI: >> >> Zone name: test.com >> Authoritative nameserver: ns.sometest.com. >> >> The 'Nameserver IP address' field is still enabled. This is because the name >> server is considered in the zone although it's actually not. >> >> The CLI seems to work fine, it didn't ask for IP address. >> >> The UI probably could be fixed using endsWith(ns, '.' + zone). Everything else >> looks fine. ACK with the fix. >> > > Fixed, updated patch attached. > A nitpick for UI part which is not a blocker(nack) because we don't have any strict rules for following topic: We should avoid depending on widget's html output outside of the widget code. So we should use: zone_w.save()[0] instead of: $('input', zone_w.container).val(); same for `ns`. Unfortunately there is no text_widget.is_enabled() method so `zone_w.input.prop('disabled')` can't be replaced. -- Petr Vobornik From rcritten at redhat.com Mon May 13 12:58:07 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 13 May 2013 08:58:07 -0400 Subject: [Freeipa-devel] [PATCH] 225 Remove leading zero from IPA_NUM_VERSION In-Reply-To: <5190B6C0.8030809@redhat.com> References: <5190B6C0.8030809@redhat.com> Message-ID: <5190E35F.7090100@redhat.com> Petr Viktorin wrote: > Due to my mistake in commit 9125285, the IPA_NUM_VERSION variable > contained a leading zero, so it was treated as octal in Python code. > Bumping the development version to 3.2.99 resulted in 030299, an invalid > value. > Luckily, 320 < 030200 < 30200 so the ordering is not broken. > > Sorry for the mistake. > I think at least a comment somewhere is required too, probably in version.h, describing which versions were affected by this octal problem. rob From lslebodn at redhat.com Mon May 13 13:23:27 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 13 May 2013 15:23:27 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <51879BFE.90601@redhat.com> References: <516FB717.9010203@redhat.com> <51879BFE.90601@redhat.com> Message-ID: <20130513132327.GJ31485@mail.corp.redhat.com> On (06/05/13 14:03), Petr Spacek wrote: >On 18.4.2013 11:04, Petr Spacek wrote: >>Hello, >> >>Clean up PTR record synchronization code and make it more robust. >> >>PTR record synchronization was split to smaller functions. >>Input validation, error handling and logging was improved >>significantly. > >Tbabej's GCC cries about uninitialized variable 'ptr_a_equal', but we >weren't able to find any real error. > >This version of the patch contains a workaround for the GCC oddities. > >-- >Petr^2 Spacek >From 5e6abb29df58ce00ecf7045254dfc7fb09fc4650 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Tue, 16 Apr 2013 16:10:09 +0200 >Subject: [PATCH] Clean up PTR record synchronization code and make it more > robust. > >PTR record synchronization was split to smaller functions. >Input validation, error handling and logging was improved >significantly. > >Signed-off-by: Petr Spacek >--- > src/ldap_helper.c | 507 ++++++++++++++++++++++++++++++++++++------------------ > 1 file changed, 342 insertions(+), 165 deletions(-) > >diff --git a/src/ldap_helper.c b/src/ldap_helper.c >index 8448412b7a1a9150bd24d9ca46575c0402be0c9f..6c5cf2e79d762251954e3bb099dbef98a0b2d805 100644 >--- a/src/ldap_helper.c >+++ b/src/ldap_helper.c >@@ -2830,35 +2830,360 @@ cleanup: > #undef SET_LDAP_MOD > } > >+ >+#define SYNCPTR_PREF "PTR record synchronization " >+#define SYNCPTR_FMTPRE SYNCPTR_PREF "(%s) for A/AAAA '%s' " >+#define SYNCPTR_FMTPOST ldap_modop_str(mod_op), a_name_str >+ >+static const char * >+ldap_modop_str(unsigned int mod_op) { >+ static const char add[] = "addition"; >+ static const char del[] = "deletion"; ^^^^^ Declaration(definition) of string should be consistent everywhere in the source code. Please change "char _name[]" to "char * _name" Sorry for nitpicking, I know that semantically is it the same, but in the other places in source code, strings are defined like "(const)? char *". If you don't believe me, you can run next command :-) grep -Rn -E 'char.*=.*"[^"]*"' [snip] >+static isc_result_t >+ldap_find_ptr(ldap_instance_t *ldap_inst, const char *ip_str, >+ dns_name_t *ptr_name, ld_string_t *ptr_dn, >+ dns_name_t *zone_name) { >+ isc_result_t result; >+ isc_mem_t *mctx = ldap_inst->mctx; >+ >+ in_addr_t ip; >+ >+ /* Get string with IP address from change request >+ * and convert it to in_addr structure. */ >+ if ((ip = inet_addr(ip_str)) t) == 0) { ^^^^ If the input is invalid, INADDR_NONE (usually -1) is returned. For details: man inet_addr >+ log_bug(SYNCPTR_PREF " could not convert IP address " >+ "from string '%s'", ip_str); >+ CLEANUP_WITH(ISC_R_UNEXPECTED); >+ } LS From pviktori at redhat.com Mon May 13 13:40:58 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 13 May 2013 15:40:58 +0200 Subject: [Freeipa-devel] [PATCH] 225 Remove leading zero from IPA_NUM_VERSION In-Reply-To: <5190E35F.7090100@redhat.com> References: <5190B6C0.8030809@redhat.com> <5190E35F.7090100@redhat.com> Message-ID: <5190ED6A.8050002@redhat.com> On 05/13/2013 02:58 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Due to my mistake in commit 9125285, the IPA_NUM_VERSION variable >> contained a leading zero, so it was treated as octal in Python code. >> Bumping the development version to 3.2.99 resulted in 030299, an invalid >> value. >> Luckily, 320 < 030200 < 30200 so the ordering is not broken. >> >> Sorry for the mistake. >> > > I think at least a comment somewhere is required too, probably in > version.h, describing which versions were affected by this octal problem. > > rob Added. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0225.2-Remove-leading-zero-from-IPA_NUM_VERSION.patch Type: text/x-patch Size: 2291 bytes Desc: not available URL: From pspacek at redhat.com Mon May 13 14:32:32 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 13 May 2013 16:32:32 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <20130513132327.GJ31485@mail.corp.redhat.com> References: <516FB717.9010203@redhat.com> <51879BFE.90601@redhat.com> <20130513132327.GJ31485@mail.corp.redhat.com> Message-ID: <5190F980.7030802@redhat.com> On 13.5.2013 15:23, Lukas Slebodnik wrote: > On (06/05/13 14:03), Petr Spacek wrote: >> On 18.4.2013 11:04, Petr Spacek wrote: >>> Hello, >>> >>> Clean up PTR record synchronization code and make it more robust. >>> >>> PTR record synchronization was split to smaller functions. >>> Input validation, error handling and logging was improved >>> significantly. >> >> Tbabej's GCC cries about uninitialized variable 'ptr_a_equal', but we >> weren't able to find any real error. >> >> This version of the patch contains a workaround for the GCC oddities. >> >> -- >> Petr^2 Spacek > >>From 5e6abb29df58ce00ecf7045254dfc7fb09fc4650 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Tue, 16 Apr 2013 16:10:09 +0200 >> Subject: [PATCH] Clean up PTR record synchronization code and make it more >> robust. >> >> PTR record synchronization was split to smaller functions. >> Input validation, error handling and logging was improved >> significantly. >> >> Signed-off-by: Petr Spacek >> --- >> src/ldap_helper.c | 507 ++++++++++++++++++++++++++++++++++++------------------ >> 1 file changed, 342 insertions(+), 165 deletions(-) >> >> diff --git a/src/ldap_helper.c b/src/ldap_helper.c >> index 8448412b7a1a9150bd24d9ca46575c0402be0c9f..6c5cf2e79d762251954e3bb099dbef98a0b2d805 100644 >> --- a/src/ldap_helper.c >> +++ b/src/ldap_helper.c >> @@ -2830,35 +2830,360 @@ cleanup: >> #undef SET_LDAP_MOD >> } >> >> + >> +#define SYNCPTR_PREF "PTR record synchronization " >> +#define SYNCPTR_FMTPRE SYNCPTR_PREF "(%s) for A/AAAA '%s' " >> +#define SYNCPTR_FMTPOST ldap_modop_str(mod_op), a_name_str >> + >> +static const char * >> +ldap_modop_str(unsigned int mod_op) { >> + static const char add[] = "addition"; >> + static const char del[] = "deletion"; > ^^^^^ > Declaration(definition) of string should be consistent everywhere in the source code. > Please change "char _name[]" to "char * _name" > Sorry for nitpicking, I know that semantically is it the same, > but in the other places in source code, strings are > defined like "(const)? char *". > If you don't believe me, you can run next command :-) > > grep -Rn -E 'char.*=.*"[^"]*"' > > [snip] > >> +static isc_result_t >> +ldap_find_ptr(ldap_instance_t *ldap_inst, const char *ip_str, >> + dns_name_t *ptr_name, ld_string_t *ptr_dn, >> + dns_name_t *zone_name) { >> + isc_result_t result; >> + isc_mem_t *mctx = ldap_inst->mctx; >> + >> + in_addr_t ip; >> + >> + /* Get string with IP address from change request >> + * and convert it to in_addr structure. */ >> + if ((ip = inet_addr(ip_str)) t) == 0) { > ^^^^ > If the input is invalid, INADDR_NONE (usually -1) is returned. > For details: man inet_addr > >> + log_bug(SYNCPTR_PREF " could not convert IP address " >> + "from string '%s'", ip_str); >> + CLEANUP_WITH(ISC_R_UNEXPECTED); >> + } Thank you for catching this! Nobody noticed it for one and half year :-) In any case, this code can't handle IPv6 addresses. We will triage it tomorrow: https://fedorahosted.org/bind-dyndb-ldap/ticket/118 Fixed patch is attached. The new version includes also typo fix: " could" => "could". -- Petr Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0149-3-Clean-up-PTR-record-synchronization-code-and-make-it.patch Type: text/x-patch Size: 19022 bytes Desc: not available URL: From simo at redhat.com Mon May 13 14:49:02 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 13 May 2013 10:49:02 -0400 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <5190F980.7030802@redhat.com> References: <516FB717.9010203@redhat.com> <51879BFE.90601@redhat.com> <20130513132327.GJ31485@mail.corp.redhat.com> <5190F980.7030802@redhat.com> Message-ID: <1368456542.23582.0.camel@willson.li.ssimo.org> On Mon, 2013-05-13 at 16:32 +0200, Petr Spacek wrote: > + if ((ip = inet_addr(ip_str)) == INADDR_NONE) { This kind of construct is hard to read and debug in gdb I would suggest you do: ip = inet_addr(ip_str); if (ip == INADDER_NONE) { Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Mon May 13 14:51:16 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 13 May 2013 16:51:16 +0200 Subject: [Freeipa-devel] [PATCH] 0026 Do not display success message on failure in web UI In-Reply-To: <51891ADE.3070803@redhat.com> References: <51891ADE.3070803@redhat.com> Message-ID: <5190FDE4.2080200@redhat.com> On 05/07/2013 05:16 PM, Ana Krivokapic wrote: > https://fedorahosted.org/freeipa/ticket/3591 > 1) The change from on_success to on_error is causing problems when some command in a batch doesn't fail. Ie.: disable multiple users on user search facet. Disabling already disabled user causes an error. The dialog is shown but the page is not refreshed so the newly disabled records are still displayed as enabled. We might even call this case a success. IMO we shouldn't change the method because the batch itself succeeded. The problem should be fixed on caller side (users of batch command). 2) Also `ajax` context should be left there instead of `this`, otherwise it would get the context of on_ok handler: 3) (not an actual issue) Some of my old code doesn't contain space between for/if and opening curly bracet, opposite to the rest of the Web UI. Spaces should be added when touching these parts of code. -- Petr Vobornik From pspacek at redhat.com Mon May 13 15:22:15 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 13 May 2013 17:22:15 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <1368456542.23582.0.camel@willson.li.ssimo.org> References: <516FB717.9010203@redhat.com> <51879BFE.90601@redhat.com> <20130513132327.GJ31485@mail.corp.redhat.com> <5190F980.7030802@redhat.com> <1368456542.23582.0.camel@willson.li.ssimo.org> Message-ID: <51910527.4080606@redhat.com> On 13.5.2013 16:49, Simo Sorce wrote: > On Mon, 2013-05-13 at 16:32 +0200, Petr Spacek wrote: >> + if ((ip = inet_addr(ip_str)) == INADDR_NONE) { > > > This kind of construct is hard to read and debug in gdb > I would suggest you do: > ip = inet_addr(ip_str); > if (ip == INADDER_NONE) { I agree, done. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0149-4-Clean-up-PTR-record-synchronization-code-and-make-it.patch Type: text/x-patch Size: 19026 bytes Desc: not available URL: From pspacek at redhat.com Mon May 13 15:34:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 13 May 2013 17:34:33 +0200 Subject: [Freeipa-devel] [PATCH 0146] Disallow all dynamic updates if update policy configuration failed In-Reply-To: <51891553.9000606@redhat.com> References: <516D0E7A.50202@redhat.com> <51891553.9000606@redhat.com> Message-ID: <51910809.5090207@redhat.com> On 7.5.2013 16:53, Tomas Hozza wrote: > On 04/16/2013 10:40 AM, Petr Spacek wrote: >> Hello, >> >> Disallow all dynamic updates if update policy configuration failed. >> >> Without this patch the old update policy stays in effect >> when re-configuration failed. >> > > ACK. > > The patch looks good. (I didn't do functional test) Pushed to master: b21eb8a84e2c02e7dd090d24d68f1e385b0604c3 -- Petr^2 Spacek From pspacek at redhat.com Mon May 13 15:35:41 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 13 May 2013 17:35:41 +0200 Subject: [Freeipa-devel] [PATCH 0147] Improve error logging for zones with idnsAllowDynUpdate == FALSE. In-Reply-To: <518B5FED.7060104@redhat.com> References: <516D2B89.1090506@redhat.com> <518B5FED.7060104@redhat.com> Message-ID: <5191084D.2080500@redhat.com> On 9.5.2013 10:35, Tomas Hozza wrote: > On 04/16/2013 12:44 PM, Petr Spacek wrote: >> Hello, >> >> Improve error logging for zones with idnsAllowDynUpdate == FALSE. >> >> Zones with dynamic updates disabled are re-configured with empty >> update policy string, so the update is refused by BIND and >> an error is logged. >> > > ACK. > > The patch looks reasonable. (I didn't do functional test) Pushed to master: 88a472349aec5216467aa1e30a35b8689b1cd439 -- Petr^2 Spacek From tbabej at redhat.com Mon May 13 15:42:04 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 13 May 2013 17:42:04 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <518D06B1.1060904@redhat.com> References: <518D06B1.1060904@redhat.com> Message-ID: <519109CC.5090300@redhat.com> On 05/10/2013 04:39 PM, Tomas Babej wrote: > Hi, > > this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 > > See commit messages for details. > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I noticed during further development that logic in interactive_prompt_callback did not follow the pre_callback logic precisely. Fixed patches attached. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0055-2-Incorporate-interactive-prompts-in-idrange-add.patch Type: text/x-patch Size: 3237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0054-2-Add-prompt_param-method-to-avoid-code-duplication.patch Type: text/x-patch Size: 9003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0053-2-Remove-redundant-check-for-env.interactive.patch Type: text/x-patch Size: 872 bytes Desc: not available URL: From tbabej at redhat.com Mon May 13 15:45:27 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 13 May 2013 17:45:27 +0200 Subject: [Freeipa-devel] [PATCH 0056] Support multiple local domain ranges with RID base set Message-ID: <51910A97.6070809@redhat.com> Hi, In ipa-adtrust-install, "adding RID bases" step would fail if there was more than one local range defined. This can be a common case if e.g. there are users that migrated from previous IdM solution. With this patch, we fail only if there are multiple local ranges that do not have RID bases set. Keep in mind that overlap checking is ensured by ipa-range-check DS plugin. https://fedorahosted.org/freeipa/ticket/3498 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0056-Support-multiple-local-domain-ranges-with-RID-base-s.patch Type: text/x-patch Size: 4724 bytes Desc: not available URL: From tbabej at redhat.com Tue May 14 09:45:43 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 May 2013 11:45:43 +0200 Subject: [Freeipa-devel] [PATCH 0141] Generalize attribute_name<->rdata_type conversions In-Reply-To: <518D0AE1.6040609@redhat.com> References: <51630222.3010807@redhat.com> <5187CEF5.7030200@redhat.com> <518D0AE1.6040609@redhat.com> Message-ID: <519207C7.4030602@redhat.com> On 05/10/2013 04:57 PM, Petr Spacek wrote: > On 6.5.2013 17:40, Tomas Hozza wrote: >> On 04/08/2013 07:45 PM, Petr Spacek wrote: >>> Generalize attribute_name<->rdata_type conversions. >>> >>> Attribute names are generated on-the-fly: String "Record" is appended >>> to textual representation of DNS RDATA type. >>> >>> String "Record" is cut down from the attribute name during >>> attribute name to rdata type conversion. >>> >>> From now, the plugin doesn't add artificial limitation to supported >>> record types. >> >> ACK. >> >> The patch looks good. (I didn't do functional test) >> >> Cosmetic issue: >> I think it would be good to dynamically allocate "mod_type" in LDAPMod >> in every case and include the "mod_type" memory freeing in >> free_ldapmod() function. Now one has to be be careful when it is >> statically or dynamically allocated. Before it was static in every case. > > It is good idea. This version of the patch contains ldap_mod_create() > function which allocates the whole structure including mod_type of > fixed size. All writes to mod_type checks the array length, so it > should not cause any harm. > > The function modify_soa_record() still uses statically allocated > LDAPMod structure with statically allocated strings for mod_type, but > the LDAPMod structure never leave this function. There are no calls to > ldap_mod_create() and ldap_mod_free(), so I think it is obvious. > > Tbabej, please try to dynamically update some A records with sync_ptr > enabled. (And of course the support for some new type, like TLSA.) For the existing record types, the patch works fine. For any new types, a schema change is still required, since record types are still hardcoded in LDAP schema: LDAP error: Object class violation: attribute "tlsarecord" not allowed > > Thank you! > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue May 14 09:46:53 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 May 2013 11:46:53 +0200 Subject: [Freeipa-devel] [PATCH 0142] Improve LDAP error logging In-Reply-To: <5188AEFA.2040402@redhat.com> References: <51641740.5040601@redhat.com> <5188AEFA.2040402@redhat.com> Message-ID: <5192080D.2090008@redhat.com> On 05/07/2013 09:36 AM, Tomas Hozza wrote: > On 04/09/2013 03:27 PM, Petr Spacek wrote: >> Hello, >> >> Improve LDAP error logging. >> >> Diagnostic error message is logged when it is available. >> >> >> Plugin with this patch produces messages like: >> >> LDAP error: Server is unwilling to perform: Minimum SSF not met.: bind >> to LDAP server failed >> >> intead of >> >> bind to LDAP server failed: Server is unwilling to perform >> >> >> Second example is: >> >> LDAP error: Object class violation: attribute "mgrecord" not allowed >> : while modifying(add) entry 'idnsName=pspacek, >> idnsname=example.com,cn=dns,dc=e,dc=test' >> >> instead of >> >> "" >> >> :-D >> > >> diff --git a/src/log.h b/src/log.h >> index 312f24322fd0c6f9943c6beb810ac0bcd8f3896c..cbf1a3faaaccea7391d65d018e80d8ec688fc111 100644 >> >> --- a/src/log.h >> >> +++ b/src/log.h >> >> @@ -55,16 +55,30 @@ >> >> log_write(GET_LOG_LEVEL(level), format, ##__VA_ARGS__) >> /* LDAP logging functions */ >> -#define log_ldap_error(ld) \ >> - do { \ >> - int err; \ >> - char *errmsg = ""; \ >> - if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err) \ >> - == LDAP_OPT_SUCCESS) \ >> - errmsg = ldap_err2string(err); \ >> - log_error_position("LDAP error: %s", errmsg); \ >> - } while (0); \ >> +#define LOG_LDAP_ERR_PREFIX "LDAP error: " >> +#define log_ldap_error(ld, desc, ...) \ >> + do { \ >> + int err; \ >> + char *errmsg = NULL; \ >> + char *diagmsg = NULL; \ >> + if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err) \ >> + == LDAP_OPT_SUCCESS) { \ >> + errmsg = ldap_err2string(err); \ > Getting error msg for the first time here. > >> + if (ldap_get_option(ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, &diagmsg) \ >> + == LDAP_OPT_SUCCESS && diagmsg != NULL) { \ >> + errmsg = ldap_err2string(err); \ > Again getting error msg with the same "err". Maybe a copy-paste error? > >> + log_error(LOG_LDAP_ERR_PREFIX "%s: %s: " desc, \ >> + errmsg, diagmsg, ##__VA_ARGS__); \ >> + ldap_memfree(diagmsg); \ >> + } else \ >> + log_error(LOG_LDAP_ERR_PREFIX "%s: " desc, \ >> + errmsg, ##__VA_ARGS__); \ >> + } else { \ >> + log_error(LOG_LDAP_ERR_PREFIX \ >> + ": " \ >> + desc, ##__VA_ARGS__); \ >> + } \ >> + } while (0); >> void >> log_write(int level, const char *format, ...) ISC_FORMAT_PRINTF(2, 3); > > Regards, > > Tomas Hozza > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, provides the desired info. Tomas From tbabej at redhat.com Tue May 14 09:47:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 May 2013 11:47:46 +0200 Subject: [Freeipa-devel] [PATCH 0143] Treat syntax errors in LDAP filters as fatal In-Reply-To: <5188B856.2070208@redhat.com> References: <51641A25.4040805@redhat.com> <5188B856.2070208@redhat.com> Message-ID: <51920842.3090803@redhat.com> On 05/07/2013 10:16 AM, Tomas Hozza wrote: > On 04/09/2013 03:39 PM, Petr Spacek wrote: >> Hello, >> >> Treat syntax errors in LDAP filters as fatal. >> >> Filters are hardcoded at the moment, this is preventive action. >> > ACK. > > The patch looks good. (I didn't do functional test) > > > Regards, > > Tomas Hozza > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. It does not break anything :) Tomas From akrivoka at redhat.com Tue May 14 10:05:20 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 14 May 2013 12:05:20 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <5190E17F.5040306@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> <518D5A87.6070105@redhat.com> <518F94D1.2030508@redhat.com> <5190E17F.5040306@redhat.com> Message-ID: <51920C60.9040302@redhat.com> On 05/13/2013 02:50 PM, Petr Vobornik wrote: > On 05/12/2013 03:10 PM, Ana Krivokapic wrote: >> On 05/10/2013 10:37 PM, Endi Sukma Dewata wrote: >>> On 5/10/2013 9:38 AM, Petr Viktorin wrote: >>>> On 05/10/2013 03:57 PM, Ana Krivokapic wrote: >>>> [...] >>>>> Thanks for catching the bugs. Updated patches are attached. >>>> >>>> Thanks! It works nicely. >>>> Endi is doing a quick check of the Javascript, if he doesn't find an >>>> issue then ACK. >>>> >>>> If this still makes it into 3.2.0, please only push the first patch >>>> there. >>> >>> I tried this in the UI: >>> >>> Zone name: test.com >>> Authoritative nameserver: ns.sometest.com. >>> >>> The 'Nameserver IP address' field is still enabled. This is because >>> the name >>> server is considered in the zone although it's actually not. >>> >>> The CLI seems to work fine, it didn't ask for IP address. >>> >>> The UI probably could be fixed using endsWith(ns, '.' + zone). >>> Everything else >>> looks fine. ACK with the fix. >>> >> >> Fixed, updated patch attached. >> > > A nitpick for UI part which is not a blocker(nack) because we don't > have any strict rules for following topic: > > We should avoid depending on widget's html output outside of the > widget code. > > So we should use: > zone_w.save()[0] > instead of: > $('input', zone_w.container).val(); > > same for `ns`. Thanks, fixed. > > Unfortunately there is no text_widget.is_enabled() method so > `zone_w.input.prop('disabled')` can't be replaced. I implemented the `text_widget.is_enabled()` method, and replaced `zone_w.input.prop('disabled')` with `!zone_w.is_enabled()`. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0027-06-Prompt-for-nameserver-IP-address-in-dnszone-add.patch Type: text/x-patch Size: 9894 bytes Desc: not available URL: From akrivoka at redhat.com Tue May 14 11:36:32 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 14 May 2013 13:36:32 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <51920C60.9040302@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> <518D5A87.6070105@redhat.com> <518F94D1.2030508@redhat.com> <5190E17F.5040306@redhat.com> <51920C60.9040302@redhat.com> Message-ID: <519221C0.5050907@redhat.com> On 05/14/2013 12:05 PM, Ana Krivokapic wrote: > On 05/13/2013 02:50 PM, Petr Vobornik wrote: >> On 05/12/2013 03:10 PM, Ana Krivokapic wrote: >>> On 05/10/2013 10:37 PM, Endi Sukma Dewata wrote: >>>> On 5/10/2013 9:38 AM, Petr Viktorin wrote: >>>>> On 05/10/2013 03:57 PM, Ana Krivokapic wrote: >>>>> [...] >>>>>> Thanks for catching the bugs. Updated patches are attached. >>>>> Thanks! It works nicely. >>>>> Endi is doing a quick check of the Javascript, if he doesn't find an >>>>> issue then ACK. >>>>> >>>>> If this still makes it into 3.2.0, please only push the first patch >>>>> there. >>>> I tried this in the UI: >>>> >>>> Zone name: test.com >>>> Authoritative nameserver: ns.sometest.com. >>>> >>>> The 'Nameserver IP address' field is still enabled. This is because >>>> the name >>>> server is considered in the zone although it's actually not. >>>> >>>> The CLI seems to work fine, it didn't ask for IP address. >>>> >>>> The UI probably could be fixed using endsWith(ns, '.' + zone). >>>> Everything else >>>> looks fine. ACK with the fix. >>>> >>> Fixed, updated patch attached. >>> >> A nitpick for UI part which is not a blocker(nack) because we don't >> have any strict rules for following topic: >> >> We should avoid depending on widget's html output outside of the >> widget code. >> >> So we should use: >> zone_w.save()[0] >> instead of: >> $('input', zone_w.container).val(); >> >> same for `ns`. > Thanks, fixed. >> Unfortunately there is no text_widget.is_enabled() method so >> `zone_w.input.prop('disabled')` can't be replaced. > I implemented the `text_widget.is_enabled()` method, and replaced > `zone_w.input.prop('disabled')` with `!zone_w.is_enabled()`. > > Updated patch attached. Petr caught another bug: due to the return value of `text_widget.save()`, an exception was raised in the case of empty zone. This has been fixed in the attached patch. I also changed the name of the endsWith() function to ends_with(), to conform to our coding standard. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0027-07-Prompt-for-nameserver-IP-address-in-dnszone-add.patch Type: text/x-patch Size: 9910 bytes Desc: not available URL: From pspacek at redhat.com Tue May 14 12:01:41 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 14:01:41 +0200 Subject: [Freeipa-devel] [PATCH 0141] Generalize attribute_name<->rdata_type conversions In-Reply-To: <519207C7.4030602@redhat.com> References: <51630222.3010807@redhat.com> <5187CEF5.7030200@redhat.com> <518D0AE1.6040609@redhat.com> <519207C7.4030602@redhat.com> Message-ID: <519227A5.4000801@redhat.com> On 14.5.2013 11:45, Tomas Babej wrote: > On 05/10/2013 04:57 PM, Petr Spacek wrote: >> On 6.5.2013 17:40, Tomas Hozza wrote: >>> On 04/08/2013 07:45 PM, Petr Spacek wrote: >>>> Generalize attribute_name<->rdata_type conversions. >>>> >>>> Attribute names are generated on-the-fly: String "Record" is appended >>>> to textual representation of DNS RDATA type. >>>> >>>> String "Record" is cut down from the attribute name during >>>> attribute name to rdata type conversion. >>>> >>>> From now, the plugin doesn't add artificial limitation to supported >>>> record types. >>> >>> ACK. >>> >>> The patch looks good. (I didn't do functional test) >>> >>> Cosmetic issue: >>> I think it would be good to dynamically allocate "mod_type" in LDAPMod >>> in every case and include the "mod_type" memory freeing in >>> free_ldapmod() function. Now one has to be be careful when it is >>> statically or dynamically allocated. Before it was static in every case. >> >> It is good idea. This version of the patch contains ldap_mod_create() >> function which allocates the whole structure including mod_type of fixed >> size. All writes to mod_type checks the array length, so it should not cause >> any harm. >> >> The function modify_soa_record() still uses statically allocated LDAPMod >> structure with statically allocated strings for mod_type, but the LDAPMod >> structure never leave this function. There are no calls to ldap_mod_create() >> and ldap_mod_free(), so I think it is obvious. >> >> Tbabej, please try to dynamically update some A records with sync_ptr >> enabled. (And of course the support for some new type, like TLSA.) > For the existing record types, the patch works fine. > > For any new types, a schema change is still required, since record types are > still hardcoded in LDAP schema: > > LDAP error: Object class violation: attribute "tlsarecord" not allowed That is expected behaviour. The point is that schema change is much simpler than recompiling the bind-dyndb-ldap (and can be done at run-time). BTW schema file contains instructions how to add support for any record type in a way compatible with rest of the world: http://drift.uninett.no/nett/ip-nett/dnsattributes.schema Was it ACK? -- Petr^2 Spacek From tbabej at redhat.com Tue May 14 13:07:31 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 May 2013 15:07:31 +0200 Subject: [Freeipa-devel] [PATCH 0148] Explicitly return SERVFAIL if PTR synchronization is misconfigured. In-Reply-To: <518BBF75.3060004@redhat.com> References: <516D2BBA.2040407@redhat.com> <518B656A.8030508@redhat.com> <518B9C36.5040300@redhat.com> <518BBF75.3060004@redhat.com> Message-ID: <51923713.2040602@redhat.com> On 05/09/2013 05:23 PM, Petr Spacek wrote: > On 9.5.2013 14:53, Petr Spacek wrote: >> On 9.5.2013 10:59, Tomas Hozza wrote: >>> On 04/16/2013 12:45 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> Explicitly return SERVFAIL if PTR synchronization is misconfigured. >>>> >>>> SERVFAIL will be returned if PTR synchronization is enabled >>>> in forward zone but reverse zone has dynamic updates disabled. >>>> >>> >>> What the patch does little bit differs from what the commit >>> message says. Explanation follows: >>> >>> Snip from ldap_helper.c (starting line 2959): >>> >>> /* Get attribute "idnsAllowDynUpdate" for reverse zone or use >>> default. */ >>> dns_name_free(&zone_name, mctx); >>> dns_name_init(&zone_name, NULL); >>> CHECK(dn_to_dnsname(mctx, owner_zone_dn_ptr, &zone_name, NULL)); >>> >>> zone_settings = NULL; >>> result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, >>> &zone_settings); >>> if (result != ISC_R_SUCCESS) { >>> if (result == ISC_R_NOTFOUND) >>> log_debug(3, "active zone '%s' not found", zone_dn); >>> goto cleanup; >>> ^ >>> You replaced this goto with "CLEANUP_WITH(DNS_R_SERVFAIL)" but >>> the check if dynamic updates in reverse zone are enabled >>> is done in the following IF statement >>> } >>> >>> CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); >>> if (!zone_dyn_update) { >>> log_debug(3, "dynamic update is not allowed in zone " >>> "'%s'", zone_dn); >>> CLEANUP_WITH(ISC_R_NOPERM); >>> } >>> >>> >>> The patch modifies the plugin to explicitly return SERVFAIL if there >>> was >>> some error while getting settings of PTR zone (the zone does not exist, >>> etc). >>> >>> Maybe it would be good to explicitly return SERVFAIL also if dynamic >>> updates in PTR zone are disabled and modify the commit message to >>> better express what this patch does. >> >> You are right. Revised patch is attached. > > I sent a bad patch by mistake... > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I tested the patch. Works ok, ACK. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Tue May 14 13:53:17 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 14 May 2013 09:53:17 -0400 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1368219349.2470.4.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1368219349.2470.4.camel@localhost.localdomain> Message-ID: <1368539597.2470.9.camel@localhost.localdomain> On Fri, 2013-05-10 at 16:55 -0400, Nathaniel McCallum wrote: > On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: > > On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: > > > On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: > > > > All issues fixed unless noted below... The attached patches are tested > > > > to work. > > > > > > > > On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: > > > > > > > >> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure > > > >> (although I know slapi_ch_malloc() currently just aborts on failure, I > > > >> think that is plain wrong which is why I would prefer using > > > >> malloc/strdup, but well, I guess this is not something I am going to > > > >> care too much about for now). > > > > Not fixed. > > > > > > > >> - Is the logic with auth_type_used correct ? > > > >> At least the name of the variable sounds misleading, because you set it > > > >> only if the authentication was successful but not set if it was 'used' > > > >> but was unsuccessful. Made me look at it multiple times to reconstuct > > > >> the logic. The var name could be better, however I also want a comment > > > >> that explain exactly how we are going to manage authentication and > > > >> fallbacks here as that logic is critical and is useful for anyone that > > > >> is going to have to change this code later in order not to break it. > > > > The variable is now gone. I re-factored the section to make the logic > > > > clearer and put a nice big comment up top. > > > > > > > >> - General question: how does this PRE_BIND plugin interact with > > > >> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? > > > >> Are you going to cause that plugin not to run by returning a result > > > >> directly in this function ? > > > >> Or is this plugin configured to run only after the previous one went > > > >> through ? > > > >> I ask because I do not see any ordering information in the cn=config > > > >> plugin configuration so it is not immediately clear to me. > > > > That is a good question for Nathan since he wrote this part of the > > > > code... > > > We would need to set the precedence if you want a predictable/guaranteed > > > execution order. If a pre-BIND plug-in callback returns non-zero (which > > > you should do when the plug-in sends the result to the client directly), > > > it will cause other pre-bind plug-ins to not be called. This is > > > actually how all pre-op plug-ins work. If a pre-op callback returns an > > > error, we don't call the rest of the pre-op plug-ins in the list. > > > > Ok, but this does not answer my question. > > We definitely need to *always* run our other preop plugin as we do > > sanity checks like verifying if the user is enabled/disabled etc... > > Also we need to understand how to deal with migrating password auth when > > OTP is enabeld. > > > > TBH I think we should not have a separate OTP-auth plugin but we should > > probably have a single plugin that handles authentication and the 2 > > should be merged. Keeping them separate is going to cause more harm than > > good with unexpected interactions. > > > > We could still have 2 plugins and simply move the prebind action > > currently don in ipa-pwd-extop to the otp plugin by making some more > > code common. But it is probably easier to just merge OTP into > > ipa-pwd-extop right now than try to do a huge refactoring. We can always > > refactor the ipa-pwd-extop plugin later. > > The attached patches encompass an initial review of the companion daemon > and merge of ipa-otp into ipa-pwd-extop. Unfortunately, merging ipa-otp > into ipa-pwd-extop appears to have broken something during install, but > I don't have enough familiarity with 389 to understand what I've broken. > If I upgrade after an install, it appears to work. > > An RPM with the patches is available here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5362935 > > Nathan / Rob / Simo, could you take a look and see what might be broken > in ipa-pwd-extop? While I'm not quite sure what the problem was, I do know it appeared on the stock 3.2 F19 RPMs. I also fixed it by accident. I am certain it is unrelated to these patches. I have now tested install and upgrade with the six patches in the previous email and everything is in order, including permissions. At this point, we just need reviews/ACKs. Nathaniel From pspacek at redhat.com Tue May 14 13:55:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 15:55:53 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations Message-ID: <51924269.8020000@redhat.com> Hello list, I investigated various scenarios for DNSSEC integration and I would like to hear your opinions about proposed approach and it's effects. The most important finding is that bind-dyndb-ldap can't support DNSSEC without rewrite of the 'in-memory database' component. Fortunately, it seems that we can drop our own implementation of the internal DNS database (ldap_driver.c and cache.c) and re-use the database from BIND (so called RBTDB). I'm trying to reach Adam Tkac with the question "Why we decided to implement it again rather than re-use BIND's code?". Re-usage of BIND's implementation will have following properties: == Advantages == - Big part of DNSSEC implementation from BIND9 can be reused. - Overall plugin implementation will be simpler - we can drop many lines of our code and bugs. - Run-time performance could be much much better. - We will get implementation for these tickets "for free": -- #95 wildcard CNAME does NOT work -- #64 IXFR support (IMHO this is important!) -- #6 Cache non-existing records And partially: -- #7 Allow limiting of the cache == Disadvantages == - Support for configurations without persistent search will complicate things a lot. -- Proposal => Make persistent search obligatory. OpenLDAP supports LDAP SyncRepl, so it should be possible to make plugin compatible with 389 and OpenLDAP at the same time. I would defer this to somebody from users/OpenLDAP community. - Data from LDAP have to be dumped to memory (or to file) before the server will start replying to queries. => This is not nice, but servers usually are not restarted often. IMHO it is a good compromise between complexity and performance. => It should be possible to save old database to disk (during BIND shutdown or periodically) and re-use this old database during server startup. I.e. server will start replying immediately from 'old' database and then the server will switch to the new database when dump from LDAP is finished. => As a side effect, BIND can start even if connection to LDAP server is down - this can improve infrastructure resiliency a lot! == Uncertain effects == - Memory consumption will change, but I'm not sure in which direction. - SOA serial number maintenance is a open question. Decision if persistent search is a 'requirement' or not will have significant impact on the design, so I will write the design document when this decision is made. -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 14:20:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 16:20:24 +0200 Subject: [Freeipa-devel] [PATCH 0153] Update NEWS file for upcoming 3.2 release Message-ID: <51924828.1010902@redhat.com> Hello, Update NEWS file for upcoming 3.2 release. -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 14:20:43 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 16:20:43 +0200 Subject: [Freeipa-devel] [PATCH 0154] Bump NVR to 3.2 Message-ID: <5192483B.7020305@redhat.com> Hello, Bump NVR to 3.2. -- Petr^2 Spacek From pvoborni at redhat.com Tue May 14 14:24:43 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 14 May 2013 16:24:43 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <519221C0.5050907@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> <518D5A87.6070105@redhat.com> <518F94D1.2030508@redhat.com> <5190E17F.5040306@redhat.com> <51920C60.9040302@redhat.com> <519221C0.5050907@redhat.com> Message-ID: <5192492B.10608@redhat.com> On 05/14/2013 01:36 PM, Ana Krivokapic wrote: > On 05/14/2013 12:05 PM, Ana Krivokapic wrote: >> On 05/13/2013 02:50 PM, Petr Vobornik wrote: >>> A nitpick for UI part which is not a blocker(nack) because we don't >>> have any strict rules for following topic: >>> >>> We should avoid depending on widget's html output outside of the >>> widget code. >>> >>> So we should use: >>> zone_w.save()[0] >>> instead of: >>> $('input', zone_w.container).val(); >>> >>> same for `ns`. >> Thanks, fixed. >>> Unfortunately there is no text_widget.is_enabled() method so >>> `zone_w.input.prop('disabled')` can't be replaced. >> I implemented the `text_widget.is_enabled()` method, and replaced >> `zone_w.input.prop('disabled')` with `!zone_w.is_enabled()`. >> >> Updated patch attached. > > Petr caught another bug: due to the return value of > `text_widget.save()`, an exception was raised in the case of empty zone. > This has been fixed in the attached patch. > > I also changed the name of the endsWith() function to ends_with(), to > conform to our coding standard. > ACK -- Petr Vobornik From pspacek at redhat.com Tue May 14 14:36:51 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 16:36:51 +0200 Subject: [Freeipa-devel] [PATCH 0153] Update NEWS file for upcoming 3.2 release In-Reply-To: <51924828.1010902@redhat.com> References: <51924828.1010902@redhat.com> Message-ID: <51924C03.6000107@redhat.com> On 14.5.2013 16:20, Petr Spacek wrote: > Update NEWS file for upcoming 3.2 release. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0153-Update-NEWS-file-for-upcoming-3.2-release.patch Type: text/x-patch Size: 1416 bytes Desc: not available URL: From pspacek at redhat.com Tue May 14 14:37:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 16:37:10 +0200 Subject: [Freeipa-devel] [PATCH 0154] Bump NVR to 3.2 In-Reply-To: <5192483B.7020305@redhat.com> References: <5192483B.7020305@redhat.com> Message-ID: <51924C16.4090502@redhat.com> On 14.5.2013 16:20, Petr Spacek wrote: > Bump NVR to 3.2. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0154-Bump-NVR-to-3.2.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: From tbabej at redhat.com Tue May 14 14:41:27 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 May 2013 16:41:27 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <51910527.4080606@redhat.com> References: <516FB717.9010203@redhat.com> <51879BFE.90601@redhat.com> <20130513132327.GJ31485@mail.corp.redhat.com> <5190F980.7030802@redhat.com> <1368456542.23582.0.camel@willson.li.ssimo.org> <51910527.4080606@redhat.com> Message-ID: <51924D17.90907@redhat.com> On 05/13/2013 05:22 PM, Petr Spacek wrote: > On 13.5.2013 16:49, Simo Sorce wrote: >> On Mon, 2013-05-13 at 16:32 +0200, Petr Spacek wrote: >>> + if ((ip = inet_addr(ip_str)) == INADDR_NONE) { >> >> >> This kind of construct is hard to read and debug in gdb >> I would suggest you do: >> ip = inet_addr(ip_str); >> if (ip == INADDER_NONE) { > > I agree, done. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I tested the patch, works fine. ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue May 14 15:09:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:09:05 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust In-Reply-To: <51924D17.90907@redhat.com> References: <516FB717.9010203@redhat.com> <51879BFE.90601@redhat.com> <20130513132327.GJ31485@mail.corp.redhat.com> <5190F980.7030802@redhat.com> <1368456542.23582.0.camel@willson.li.ssimo.org> <51910527.4080606@redhat.com> <51924D17.90907@redhat.com> Message-ID: <51925391.40200@redhat.com> On 14.5.2013 16:41, Tomas Babej wrote: > On 05/13/2013 05:22 PM, Petr Spacek wrote: >> On 13.5.2013 16:49, Simo Sorce wrote: >>> On Mon, 2013-05-13 at 16:32 +0200, Petr Spacek wrote: >>>> + if ((ip = inet_addr(ip_str)) == INADDR_NONE) { >>> >>> >>> This kind of construct is hard to read and debug in gdb >>> I would suggest you do: >>> ip = inet_addr(ip_str); >>> if (ip == INADDER_NONE) { >> >> I agree, done. >> > I tested the patch, works fine. ACK Pushed to master: 8d12512d0eb4445f4966fd0e326cde9823f6a0bb -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:09:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:09:10 +0200 Subject: [Freeipa-devel] [PATCH 0150] Do not delete whole node during PTR record synchronization. In-Reply-To: <518B915A.4030308@redhat.com> References: <51700A04.3070305@redhat.com> <518B915A.4030308@redhat.com> Message-ID: <51925396.9070504@redhat.com> On 9.5.2013 14:06, Tomas Hozza wrote: > On 04/18/2013 04:58 PM, Petr Spacek wrote: >> Hello, >> >> Do not delete whole node during PTR record synchronization. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/115 >> > > ACK. > > The patch looks good. Pushed to master: 1c63c045b5238fb675b7a517876869bcace2cdab -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:09:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:09:13 +0200 Subject: [Freeipa-devel] [PATCH 0151] Disallow all zone transfers/queries if transfer/query policy configuration failed In-Reply-To: <518B9495.3050909@redhat.com> References: <5171201E.9030502@redhat.com> <518B9495.3050909@redhat.com> Message-ID: <51925399.2090703@redhat.com> On 9.5.2013 14:20, Tomas Hozza wrote: > On 04/19/2013 12:44 PM, Petr Spacek wrote: >> Hello, >> >> Disallow all zone transfers/queries if transfer/query policy >> configuration failed. >> >> Without this patch the old policy stays in effect >> if re-configuration with the new policy failed. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/116 >> > > ACK. > > Patch looks OK! Pushed to master: 0a5051392e218702a37073823101cbb6553b9445 -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:09:17 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:09:17 +0200 Subject: [Freeipa-devel] [PATCH 0152] Replace TTL values > 2^31-1 with 0. In-Reply-To: <1756366503.3917102.1367587158522.JavaMail.root@redhat.com> References: <517FCAF5.70103@redhat.com> <5183AEF6.9090702@redhat.com> <5183B3DC.7070700@redhat.com> <1756366503.3917102.1367587158522.JavaMail.root@redhat.com> Message-ID: <5192539D.4020205@redhat.com> On 3.5.2013 15:19, Tomas Hozza wrote: > ----- Original Message ----- >> On 3.5.2013 14:35, Tomas Babej wrote: >>> On 04/30/2013 03:45 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> Replace TTL values > 2^31-1 with 0. >>>> >>>> The rule comes from RFC 2181 section 8. >>>> >>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/117 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> ACK, works fine. >>> >>> Just one question though, the patch as it is leaves the invalid TTL value >>> in >>> the tree, >>> even though it is never interpreted as one (thanks to this patch). >>> >>> $ ipa dnsrecord-show ipa.example.com skuska --all >>> dn: >>> idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com >>> Record name: skuska >>> Time to live: 2147483648 >>> A record: 192.168.0.1 >>> objectclass: top, idnsrecord >>> >>> from /var/log/messages: >>> named[18275]: entry >>> 'idnsname=skuska,idnsname=ipa.example.com,cn=dns,dc=ipa,dc=example,dc=com': >>> entry TTL 2147483648 > MAXTTL, setting TTL to 0 >>> >>> Wouldn't that be confusing to the user? Shouldn't we fix the TTL value set >>> in >>> the entry as well? >> >> It is exactly what "original" BIND does. I would like to imitate the same >> behaviour if you are not against it strongly. >> >> I think that: >> 1) Somebody could use bind-dyndb-ldap with read-only access to LDAP. >> 2) It will unnecessarily complicate the code. >> >> -- >> Petr^2 Spacek > > Review ACK. > > The patch looks good. I also agree with Peter's reasoning. There is also > an error logged when the TTL has MSB set, so one can notice there is a bad > TTL value set in LDAP. Pushed to master: ccc439e5a5d8d2e0e6dbcb85351f48c501fdad03 -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:10:21 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:10:21 +0200 Subject: [Freeipa-devel] [PATCH 0148] Explicitly return SERVFAIL if PTR synchronization is misconfigured. In-Reply-To: <51923713.2040602@redhat.com> References: <516D2BBA.2040407@redhat.com> <518B656A.8030508@redhat.com> <518B9C36.5040300@redhat.com> <518BBF75.3060004@redhat.com> <51923713.2040602@redhat.com> Message-ID: <519253DD.2060606@redhat.com> On 14.5.2013 15:07, Tomas Babej wrote: > On 05/09/2013 05:23 PM, Petr Spacek wrote: >> On 9.5.2013 14:53, Petr Spacek wrote: >>> On 9.5.2013 10:59, Tomas Hozza wrote: >>>> On 04/16/2013 12:45 PM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> Explicitly return SERVFAIL if PTR synchronization is misconfigured. >>>>> >>>>> SERVFAIL will be returned if PTR synchronization is enabled >>>>> in forward zone but reverse zone has dynamic updates disabled. >>>>> >>>> >>>> What the patch does little bit differs from what the commit >>>> message says. Explanation follows: >>>> >>>> Snip from ldap_helper.c (starting line 2959): >>>> >>>> /* Get attribute "idnsAllowDynUpdate" for reverse zone or use default. */ >>>> dns_name_free(&zone_name, mctx); >>>> dns_name_init(&zone_name, NULL); >>>> CHECK(dn_to_dnsname(mctx, owner_zone_dn_ptr, &zone_name, NULL)); >>>> >>>> zone_settings = NULL; >>>> result = zr_get_zone_settings(ldap_inst->zone_register, &zone_name, >>>> &zone_settings); >>>> if (result != ISC_R_SUCCESS) { >>>> if (result == ISC_R_NOTFOUND) >>>> log_debug(3, "active zone '%s' not found", zone_dn); >>>> goto cleanup; >>>> ^ >>>> You replaced this goto with "CLEANUP_WITH(DNS_R_SERVFAIL)" but >>>> the check if dynamic updates in reverse zone are enabled >>>> is done in the following IF statement >>>> } >>>> >>>> CHECK(setting_get_bool("dyn_update", zone_settings, &zone_dyn_update)); >>>> if (!zone_dyn_update) { >>>> log_debug(3, "dynamic update is not allowed in zone " >>>> "'%s'", zone_dn); >>>> CLEANUP_WITH(ISC_R_NOPERM); >>>> } >>>> >>>> >>>> The patch modifies the plugin to explicitly return SERVFAIL if there was >>>> some error while getting settings of PTR zone (the zone does not exist, >>>> etc). >>>> >>>> Maybe it would be good to explicitly return SERVFAIL also if dynamic >>>> updates in PTR zone are disabled and modify the commit message to >>>> better express what this patch does. >>> >>> You are right. Revised patch is attached. >> >> I sent a bad patch by mistake... Pushed to master: 04b48143f592541d3c98e06229987e36dbaf6ec8 -- Petr^2 Spacek From tbabej at redhat.com Tue May 14 15:42:02 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 May 2013 17:42:02 +0200 Subject: [Freeipa-devel] [PATCH 0141] Generalize attribute_name<->rdata_type conversions In-Reply-To: <519227A5.4000801@redhat.com> References: <51630222.3010807@redhat.com> <5187CEF5.7030200@redhat.com> <518D0AE1.6040609@redhat.com> <519207C7.4030602@redhat.com> <519227A5.4000801@redhat.com> Message-ID: <51925B4A.6010706@redhat.com> On 05/14/2013 02:01 PM, Petr Spacek wrote: > On 14.5.2013 11:45, Tomas Babej wrote: >> On 05/10/2013 04:57 PM, Petr Spacek wrote: >>> On 6.5.2013 17:40, Tomas Hozza wrote: >>>> On 04/08/2013 07:45 PM, Petr Spacek wrote: >>>>> Generalize attribute_name<->rdata_type conversions. >>>>> >>>>> Attribute names are generated on-the-fly: String "Record" is appended >>>>> to textual representation of DNS RDATA type. >>>>> >>>>> String "Record" is cut down from the attribute name during >>>>> attribute name to rdata type conversion. >>>>> >>>>> From now, the plugin doesn't add artificial limitation to supported >>>>> record types. >>>> >>>> ACK. >>>> >>>> The patch looks good. (I didn't do functional test) >>>> >>>> Cosmetic issue: >>>> I think it would be good to dynamically allocate "mod_type" in LDAPMod >>>> in every case and include the "mod_type" memory freeing in >>>> free_ldapmod() function. Now one has to be be careful when it is >>>> statically or dynamically allocated. Before it was static in every >>>> case. >>> >>> It is good idea. This version of the patch contains ldap_mod_create() >>> function which allocates the whole structure including mod_type of >>> fixed >>> size. All writes to mod_type checks the array length, so it should >>> not cause >>> any harm. >>> >>> The function modify_soa_record() still uses statically allocated >>> LDAPMod >>> structure with statically allocated strings for mod_type, but the >>> LDAPMod >>> structure never leave this function. There are no calls to >>> ldap_mod_create() >>> and ldap_mod_free(), so I think it is obvious. >>> >>> Tbabej, please try to dynamically update some A records with sync_ptr >>> enabled. (And of course the support for some new type, like TLSA.) >> For the existing record types, the patch works fine. >> >> For any new types, a schema change is still required, since record >> types are >> still hardcoded in LDAP schema: >> >> LDAP error: Object class violation: attribute "tlsarecord" not allowed > > That is expected behaviour. The point is that schema change is much > simpler than recompiling the bind-dyndb-ldap (and can be done at > run-time). > > BTW schema file contains instructions how to add support for any > record type in a way compatible with rest of the world: > http://drift.uninett.no/nett/ip-nett/dnsattributes.schema > > Was it ACK? > I was not nacking, just pointing out. Tested with changed schema, works as expected. Here, have my ACK. Tomas From pspacek at redhat.com Tue May 14 15:47:59 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:47:59 +0200 Subject: [Freeipa-devel] [PATCH 0141] Generalize attribute_name<->rdata_type conversions In-Reply-To: <51925B4A.6010706@redhat.com> References: <51630222.3010807@redhat.com> <5187CEF5.7030200@redhat.com> <518D0AE1.6040609@redhat.com> <519207C7.4030602@redhat.com> <519227A5.4000801@redhat.com> <51925B4A.6010706@redhat.com> Message-ID: <51925CAF.2020303@redhat.com> On 14.5.2013 17:42, Tomas Babej wrote: > On 05/14/2013 02:01 PM, Petr Spacek wrote: >> On 14.5.2013 11:45, Tomas Babej wrote: >>> On 05/10/2013 04:57 PM, Petr Spacek wrote: >>>> On 6.5.2013 17:40, Tomas Hozza wrote: >>>>> On 04/08/2013 07:45 PM, Petr Spacek wrote: >>>>>> Generalize attribute_name<->rdata_type conversions. >>>>>> >>>>>> Attribute names are generated on-the-fly: String "Record" is appended >>>>>> to textual representation of DNS RDATA type. >>>>>> >>>>>> String "Record" is cut down from the attribute name during >>>>>> attribute name to rdata type conversion. >>>>>> >>>>>> From now, the plugin doesn't add artificial limitation to supported >>>>>> record types. >>>>> >>>>> ACK. >>>>> >>>>> The patch looks good. (I didn't do functional test) >>>>> >>>>> Cosmetic issue: >>>>> I think it would be good to dynamically allocate "mod_type" in LDAPMod >>>>> in every case and include the "mod_type" memory freeing in >>>>> free_ldapmod() function. Now one has to be be careful when it is >>>>> statically or dynamically allocated. Before it was static in every case. >>>> >>>> It is good idea. This version of the patch contains ldap_mod_create() >>>> function which allocates the whole structure including mod_type of fixed >>>> size. All writes to mod_type checks the array length, so it should not cause >>>> any harm. >>>> >>>> The function modify_soa_record() still uses statically allocated LDAPMod >>>> structure with statically allocated strings for mod_type, but the LDAPMod >>>> structure never leave this function. There are no calls to ldap_mod_create() >>>> and ldap_mod_free(), so I think it is obvious. >>>> >>>> Tbabej, please try to dynamically update some A records with sync_ptr >>>> enabled. (And of course the support for some new type, like TLSA.) >>> For the existing record types, the patch works fine. >>> >>> For any new types, a schema change is still required, since record types are >>> still hardcoded in LDAP schema: >>> >>> LDAP error: Object class violation: attribute "tlsarecord" not allowed >> >> That is expected behaviour. The point is that schema change is much simpler >> than recompiling the bind-dyndb-ldap (and can be done at run-time). >> >> BTW schema file contains instructions how to add support for any record type >> in a way compatible with rest of the world: >> http://drift.uninett.no/nett/ip-nett/dnsattributes.schema >> >> Was it ACK? >> > I was not nacking, just pointing out. Tested with changed schema, works as > expected. > > Here, have my ACK. Pushed to master: 35ac3e422376cc28040d03c7550c2c68a967a0cf -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:48:33 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:48:33 +0200 Subject: [Freeipa-devel] [PATCH 0143] Treat syntax errors in LDAP filters as fatal In-Reply-To: <51920842.3090803@redhat.com> References: <51641A25.4040805@redhat.com> <5188B856.2070208@redhat.com> <51920842.3090803@redhat.com> Message-ID: <51925CD1.3030208@redhat.com> On 14.5.2013 11:47, Tomas Babej wrote: > On 05/07/2013 10:16 AM, Tomas Hozza wrote: >> On 04/09/2013 03:39 PM, Petr Spacek wrote: >>> Hello, >>> >>> Treat syntax errors in LDAP filters as fatal. >>> >>> Filters are hardcoded at the moment, this is preventive action. >>> >> ACK. >> >> The patch looks good. (I didn't do functional test) >> >> >> Regards, >> >> Tomas Hozza >> > ACK. It does not break anything :) Pushed to master: 33133d9eaf757aef520e334e7e2eacce959f929c -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:49:03 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:49:03 +0200 Subject: [Freeipa-devel] [PATCH 0142] Improve LDAP error logging In-Reply-To: <5192080D.2090008@redhat.com> References: <51641740.5040601@redhat.com> <5188AEFA.2040402@redhat.com> <5192080D.2090008@redhat.com> Message-ID: <51925CEF.1050801@redhat.com> On 14.5.2013 11:46, Tomas Babej wrote: > On 05/07/2013 09:36 AM, Tomas Hozza wrote: >> On 04/09/2013 03:27 PM, Petr Spacek wrote: >>> Hello, >>> >>> Improve LDAP error logging. >>> >>> Diagnostic error message is logged when it is available. >>> >>> >>> Plugin with this patch produces messages like: >>> >>> LDAP error: Server is unwilling to perform: Minimum SSF not met.: bind >>> to LDAP server failed >>> >>> intead of >>> >>> bind to LDAP server failed: Server is unwilling to perform >>> >>> >>> Second example is: >>> >>> LDAP error: Object class violation: attribute "mgrecord" not allowed >>> : while modifying(add) entry 'idnsName=pspacek, >>> idnsname=example.com,cn=dns,dc=e,dc=test' >>> >>> instead of >>> >>> "" >>> >>> :-D >>> >> >>> diff --git a/src/log.h b/src/log.h >>> index >>> 312f24322fd0c6f9943c6beb810ac0bcd8f3896c..cbf1a3faaaccea7391d65d018e80d8ec688fc111 >>> 100644 >>> >>> --- a/src/log.h >>> >>> +++ b/src/log.h >>> >>> @@ -55,16 +55,30 @@ >>> >>> log_write(GET_LOG_LEVEL(level), format, ##__VA_ARGS__) >>> /* LDAP logging functions */ >>> -#define log_ldap_error(ld) \ >>> - do { \ >>> - int err; \ >>> - char *errmsg = ""; \ >>> - if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err) \ >>> - == LDAP_OPT_SUCCESS) \ >>> - errmsg = ldap_err2string(err); \ >>> - log_error_position("LDAP error: %s", errmsg); \ >>> - } while (0); \ >>> +#define LOG_LDAP_ERR_PREFIX "LDAP error: " >>> +#define log_ldap_error(ld, desc, ...) \ >>> + do { \ >>> + int err; \ >>> + char *errmsg = NULL; \ >>> + char *diagmsg = NULL; \ >>> + if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, >>> &err) \ >>> + == LDAP_OPT_SUCCESS) { \ >>> + errmsg = ldap_err2string(err); \ >> Getting error msg for the first time here. >> >>> + if (ldap_get_option(ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, >>> &diagmsg) \ >>> + == LDAP_OPT_SUCCESS && diagmsg != NULL) { \ >>> + errmsg = ldap_err2string(err); \ >> Again getting error msg with the same "err". Maybe a copy-paste error? >> >>> + log_error(LOG_LDAP_ERR_PREFIX "%s: %s: " desc, \ >>> + errmsg, diagmsg, ##__VA_ARGS__); \ >>> + ldap_memfree(diagmsg); \ >>> + } else \ >>> + log_error(LOG_LDAP_ERR_PREFIX "%s: " desc, \ >>> + errmsg, ##__VA_ARGS__); \ >>> + } else { \ >>> + log_error(LOG_LDAP_ERR_PREFIX \ >>> + ": " \ >>> + desc, ##__VA_ARGS__); \ >>> + } \ >>> + } while (0); >>> void >>> log_write(int level, const char *format, ...) ISC_FORMAT_PRINTF(2, 3); >> >> Regards, >> >> Tomas Hozza >> > ACK, provides the desired info. Pushed to master: af83758cb3f91129399494c95a1847814b1d71a8 -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:58:47 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:58:47 +0200 Subject: [Freeipa-devel] [PATCH 0153] Update NEWS file for upcoming 3.2 release In-Reply-To: <51924C03.6000107@redhat.com> References: <51924828.1010902@redhat.com> <51924C03.6000107@redhat.com> Message-ID: <51925F37.9020306@redhat.com> On 14.5.2013 16:36, Petr Spacek wrote: > On 14.5.2013 16:20, Petr Spacek wrote: >> Update NEWS file for upcoming 3.2 release. Pushed to master: bc647206677f54ecf14eb7f77984ec25070ddfc2 -- Petr^2 Spacek From pspacek at redhat.com Tue May 14 15:58:48 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 17:58:48 +0200 Subject: [Freeipa-devel] [PATCH 0154] Bump NVR to 3.2 In-Reply-To: <51924C16.4090502@redhat.com> References: <5192483B.7020305@redhat.com> <51924C16.4090502@redhat.com> Message-ID: <51925F38.3010901@redhat.com> On 14.5.2013 16:37, Petr Spacek wrote: > On 14.5.2013 16:20, Petr Spacek wrote: >> Bump NVR to 3.2. Pushed to master: eebb0679be611e325ce6c2938ac6c8ca5e734ea6 -- Petr^2 Spacek From tbabej at redhat.com Tue May 14 16:16:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 May 2013 18:16:20 +0200 Subject: [Freeipa-devel] Build fixes for F19 for bind-dyndb-ldap Message-ID: <51926354.5000007@redhat.com> Hi, This patch contains various (gcc-related) fixes to make build on F19 possible. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-tbabej-0001-Build-fixes-for-Fedora-19.patch Type: text/x-patch Size: 1806 bytes Desc: not available URL: From pspacek at redhat.com Tue May 14 16:27:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 May 2013 18:27:13 +0200 Subject: [Freeipa-devel] Build fixes for F19 for bind-dyndb-ldap In-Reply-To: <51926354.5000007@redhat.com> References: <51926354.5000007@redhat.com> Message-ID: <519265E1.4070800@redhat.com> On 14.5.2013 18:16, Tomas Babej wrote: > This patch contains various (gcc-related) fixes to make build > on F19 possible. Congratulations to your first patch for bind-dyndb-ldap! :-) ACK Pushed to master: c5716e660e145ebec6ff091e2479f93e4c54d464 -- Petr^2 Spacek From pvoborni at redhat.com Tue May 14 16:37:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 14 May 2013 18:37:29 +0200 Subject: [Freeipa-devel] [PATCH] 413 Fix: HBAC Test tab is missing Message-ID: <51926849.2090006@redhat.com> Fix for really stupid mistake with quite big impact... Caused by typo in metadata provider source path. No metadata -> no HBAC test entity -> no tab https://fedorahosted.org/freeipa/ticket/3627 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0413-Fix-HBAC-Test-tab-is-missing.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: From mkosek at redhat.com Tue May 14 16:39:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 May 2013 18:39:12 +0200 Subject: [Freeipa-devel] [PATCH] 407 Set KRB5CCNAME so that dirsrv can work with newer krb5-server Message-ID: <519268B0.8090808@redhat.com> The DIR ccache format is now the default in krb5-server 1.11.2-4 but /run/user/ isn't created for Apache by anything so it has no ccache (and it doesn't have SELinux permissions to write here either). Use KRB5CCNAME to set a file path instead in /etc/sysconfig/dirsrv. https://fedorahosted.org/freeipa/ticket/3628 ---- Without this patch, replication on F19 is broken. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-407-set-krb5ccname-so-that-dirsrv-can-work-with-newer-kr.patch Type: text/x-patch Size: 3014 bytes Desc: not available URL: From mkosek at redhat.com Tue May 14 16:47:03 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 May 2013 18:47:03 +0200 Subject: [Freeipa-devel] [PATCH] 413 Fix: HBAC Test tab is missing In-Reply-To: <51926849.2090006@redhat.com> References: <51926849.2090006@redhat.com> Message-ID: <51926A87.4030507@redhat.com> On 05/14/2013 06:37 PM, Petr Vobornik wrote: > Fix for really stupid mistake with quite big impact... > > Caused by typo in metadata provider source path. > > No metadata -> no HBAC test entity -> no tab > > https://fedorahosted.org/freeipa/ticket/3627 > ACK. Pushed to master. Martin From mkosek at redhat.com Tue May 14 16:50:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 May 2013 18:50:01 +0200 Subject: [Freeipa-devel] [PATCH] 225 Remove leading zero from IPA_NUM_VERSION In-Reply-To: <5190ED6A.8050002@redhat.com> References: <5190B6C0.8030809@redhat.com> <5190E35F.7090100@redhat.com> <5190ED6A.8050002@redhat.com> Message-ID: <51926B39.3000802@redhat.com> On 05/13/2013 03:40 PM, Petr Viktorin wrote: > On 05/13/2013 02:58 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Due to my mistake in commit 9125285, the IPA_NUM_VERSION variable >>> contained a leading zero, so it was treated as octal in Python code. >>> Bumping the development version to 3.2.99 resulted in 030299, an invalid >>> value. >>> Luckily, 320 < 030200 < 30200 so the ordering is not broken. >>> >>> Sorry for the mistake. >>> >> >> I think at least a comment somewhere is required too, probably in >> version.h, describing which versions were affected by this octal problem. >> >> rob > > Added. > This helps, thanks. ACK, pushed to master, ipa-3-1. Martin From mkosek at redhat.com Tue May 14 17:12:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 May 2013 19:12:01 +0200 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <1368539597.2470.9.camel@localhost.localdomain> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1368219349.2470.4.camel@localhost.localdomain> <1368539597.2470.9.camel@localhost.localdomain> Message-ID: <51927061.5040007@redhat.com> On 05/14/2013 03:53 PM, Nathaniel McCallum wrote: > On Fri, 2013-05-10 at 16:55 -0400, Nathaniel McCallum wrote: >> On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: >>> On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: >>>> On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: >>>>> All issues fixed unless noted below... The attached patches are tested >>>>> to work. >>>>> >>>>> On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: >>>>> >>>>>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >>>>>> (although I know slapi_ch_malloc() currently just aborts on failure, I >>>>>> think that is plain wrong which is why I would prefer using >>>>>> malloc/strdup, but well, I guess this is not something I am going to >>>>>> care too much about for now). >>>>> Not fixed. >>>>> >>>>>> - Is the logic with auth_type_used correct ? >>>>>> At least the name of the variable sounds misleading, because you set it >>>>>> only if the authentication was successful but not set if it was 'used' >>>>>> but was unsuccessful. Made me look at it multiple times to reconstuct >>>>>> the logic. The var name could be better, however I also want a comment >>>>>> that explain exactly how we are going to manage authentication and >>>>>> fallbacks here as that logic is critical and is useful for anyone that >>>>>> is going to have to change this code later in order not to break it. >>>>> The variable is now gone. I re-factored the section to make the logic >>>>> clearer and put a nice big comment up top. >>>>> >>>>>> - General question: how does this PRE_BIND plugin interact with >>>>>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >>>>>> Are you going to cause that plugin not to run by returning a result >>>>>> directly in this function ? >>>>>> Or is this plugin configured to run only after the previous one went >>>>>> through ? >>>>>> I ask because I do not see any ordering information in the cn=config >>>>>> plugin configuration so it is not immediately clear to me. >>>>> That is a good question for Nathan since he wrote this part of the >>>>> code... >>>> We would need to set the precedence if you want a predictable/guaranteed >>>> execution order. If a pre-BIND plug-in callback returns non-zero (which >>>> you should do when the plug-in sends the result to the client directly), >>>> it will cause other pre-bind plug-ins to not be called. This is >>>> actually how all pre-op plug-ins work. If a pre-op callback returns an >>>> error, we don't call the rest of the pre-op plug-ins in the list. >>> >>> Ok, but this does not answer my question. >>> We definitely need to *always* run our other preop plugin as we do >>> sanity checks like verifying if the user is enabled/disabled etc... >>> Also we need to understand how to deal with migrating password auth when >>> OTP is enabeld. >>> >>> TBH I think we should not have a separate OTP-auth plugin but we should >>> probably have a single plugin that handles authentication and the 2 >>> should be merged. Keeping them separate is going to cause more harm than >>> good with unexpected interactions. >>> >>> We could still have 2 plugins and simply move the prebind action >>> currently don in ipa-pwd-extop to the otp plugin by making some more >>> code common. But it is probably easier to just merge OTP into >>> ipa-pwd-extop right now than try to do a huge refactoring. We can always >>> refactor the ipa-pwd-extop plugin later. >> >> The attached patches encompass an initial review of the companion daemon >> and merge of ipa-otp into ipa-pwd-extop. Unfortunately, merging ipa-otp >> into ipa-pwd-extop appears to have broken something during install, but >> I don't have enough familiarity with 389 to understand what I've broken. >> If I upgrade after an install, it appears to work. >> >> An RPM with the patches is available here: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=5362935 >> >> Nathan / Rob / Simo, could you take a look and see what might be broken >> in ipa-pwd-extop? > > While I'm not quite sure what the problem was, I do know it appeared on > the stock 3.2 F19 RPMs. I also fixed it by accident. I am certain it is > unrelated to these patches. > > I have now tested install and upgrade with the six patches in the > previous email and everything is in order, including permissions. At > this point, we just need reviews/ACKs. > > Nathaniel > I tested IPA server upgrades, new installs and also adding 3.2+OTP replica for F18 3.1.4 IPA master. Everything seemed to work fine (when I added my patch 407 fixing the replication), I did not see any breakage. Issues I found with too much logging I reported should now be fixed on github, so this should be OK. So it is an ACK from my side if Rob does not discover some blocking issue. Martin From rcritten at redhat.com Tue May 14 21:01:54 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 May 2013 17:01:54 -0400 Subject: [Freeipa-devel] [PATCH] 407 Set KRB5CCNAME so that dirsrv can work with newer krb5-server In-Reply-To: <519268B0.8090808@redhat.com> References: <519268B0.8090808@redhat.com> Message-ID: <5192A642.60408@redhat.com> Martin Kosek wrote: > The DIR ccache format is now the default in krb5-server 1.11.2-4 > but /run/user/ isn't created for Apache by anything so it > has no ccache (and it doesn't have SELinux permissions to write here > either). > > Use KRB5CCNAME to set a file path instead in /etc/sysconfig/dirsrv. > > https://fedorahosted.org/freeipa/ticket/3628 > > ---- > > Without this patch, replication on F19 is broken. > > Martin > ACK, pushed to master and ipa-3-2 rob From mkosek at redhat.com Wed May 15 06:32:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 May 2013 08:32:49 +0200 Subject: [Freeipa-devel] [PATCH] 225 Remove leading zero from IPA_NUM_VERSION In-Reply-To: <51926B39.3000802@redhat.com> References: <5190B6C0.8030809@redhat.com> <5190E35F.7090100@redhat.com> <5190ED6A.8050002@redhat.com> <51926B39.3000802@redhat.com> Message-ID: <51932C11.3060209@redhat.com> On 05/14/2013 06:50 PM, Martin Kosek wrote: > On 05/13/2013 03:40 PM, Petr Viktorin wrote: >> On 05/13/2013 02:58 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> Due to my mistake in commit 9125285, the IPA_NUM_VERSION variable >>>> contained a leading zero, so it was treated as octal in Python code. >>>> Bumping the development version to 3.2.99 resulted in 030299, an invalid >>>> value. >>>> Luckily, 320 < 030200 < 30200 so the ordering is not broken. >>>> >>>> Sorry for the mistake. >>>> >>> >>> I think at least a comment somewhere is required too, probably in >>> version.h, describing which versions were affected by this octal problem. >>> >>> rob >> >> Added. >> > > This helps, thanks. ACK, pushed to master, ipa-3-1. > > Martin Rob also pushed the patch to ipa-3-2 (which I forgot) - thanks. Martin From ssorce at redhat.com Wed May 15 08:29:54 2013 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 15 May 2013 04:29:54 -0400 (EDT) Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <51924269.8020000@redhat.com> References: <51924269.8020000@redhat.com> Message-ID: <94125227.1971889.1368606594501.JavaMail.root@redhat.com> ----- Original Message ----- > Hello list, > > I investigated various scenarios for DNSSEC integration and I would like to > hear your opinions about proposed approach and it's effects. > > > The most important finding is that bind-dyndb-ldap can't support DNSSEC > without rewrite of the 'in-memory database' component. Can you elaborate why a rewrite would be needed ? What constraint we do not meet ? > Fortunately, it seems > that we can drop our own implementation of the internal DNS database > (ldap_driver.c and cache.c) and re-use the database from BIND (so called > RBTDB). > > I'm trying to reach Adam Tkac with the question "Why we decided to implement > it again rather than re-use BIND's code?". > > > Re-usage of BIND's implementation will have following properties: > > > == Advantages == > - Big part of DNSSEC implementation from BIND9 can be reused. > - Overall plugin implementation will be simpler - we can drop many lines of > our code and bugs. > - Run-time performance could be much much better. > > - We will get implementation for these tickets "for free": > -- #95 wildcard CNAME does NOT work > -- #64 IXFR support (IMHO this is important!) > -- #6 Cache non-existing records > > And partially: > -- #7 Allow limiting of the cache Sounds very interesting. > == Disadvantages == > - Support for configurations without persistent search will complicate things > a lot. > -- Proposal => Make persistent search obligatory. OpenLDAP supports LDAP > SyncRepl, so it should be possible to make plugin compatible with 389 and > OpenLDAP at the same time. I would defer this to somebody from users/OpenLDAP > community. Why the persistent search would be required ? > - Data from LDAP have to be dumped to memory (or to file) before the server > will start replying to queries. > => This is not nice, but servers usually are not restarted often. IMHO it is > a > good compromise between complexity and performance. I am not sure I understand what this means. Does it mean you cannot change single cache entries on the fly when a change happens in LDAP ? Or something else ? > => It should be possible to save old database to disk (during BIND shutdown > or > periodically) and re-use this old database during server startup. I.e. server > will start replying immediately from 'old' database and then the server will > switch to the new database when dump from LDAP is finished. This look like an advantage ? Why is it a disadvantage ? > => As a side effect, BIND can start even if connection to LDAP server is down > - this can improve infrastructure resiliency a lot! Same as above ? > == Uncertain effects == > - Memory consumption will change, but I'm not sure in which direction. > - SOA serial number maintenance is a open question. Why SOA serial is a problem ? > Decision if persistent search is a 'requirement' or not will have significant > impact on the design, so I will write the design document when this decision > is made. I would like to know more details about the reasons before I can usefully comment. Thanks for the research work done so far! Simo. -- Simo Sorce * Red Hat, Inc. * New York From pspacek at redhat.com Wed May 15 08:58:14 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 15 May 2013 10:58:14 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 3.2 Message-ID: <51934E26.2070108@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 3.2. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. The new version has also been built for Fedora 19: https://admin.fedoraproject.org/updates/FEDORA-2013-8036 This release includes several fixes. == Changes in 3.2 == [1] An error in dynamic update/transfer/query policy is interpreted as most restrictive policy, i.e. nobody is allowed to update/transfer/query the zone. https://fedorahosted.org/bind-dyndb-ldap/ticket/116 [2] Attempts to update zones with idnsAllowDynUpdate == FALSE are logged. [3] TTL values > 2^31-1 are interpreted as 0. https://fedorahosted.org/bind-dyndb-ldap/ticket/117 [4] All RR types supported by BIND are automatically supported by plugin. From now it is enough to add new attribute type to LDAP schema, no recompilation is required. [5] PTR record synchronization deletes only PTR records, but no other records (e.g. TXT) under names in the reverse zone. [6] Various improvements related to logging (dynamic updates, PTR record synchronization, LDAP error handling). == Upgrading == An server can be upgraded simply by installing updated rpms. BIND has to be restarted manually after the RPM installation. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 2.x version is supported under following conditions: - new object class idnsForwardZone is not utilized - record types not supported by 2.x versions are not utilized - configured connection count is >= 3 (to prevent deadlocks in 2.x releases) == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat From akrivoka at redhat.com Wed May 15 09:40:03 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 15 May 2013 11:40:03 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed Message-ID: <519357F3.3080408@redhat.com> Hello, See the commit message for details. https://fedorahosted.org/freeipa/ticket/3594 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0029-Make-sure-replication-works-after-DM-password-is-cha.patch Type: text/x-patch Size: 3361 bytes Desc: not available URL: From tbabej at redhat.com Wed May 15 10:04:02 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 15 May 2013 12:04:02 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <519357F3.3080408@redhat.com> References: <519357F3.3080408@redhat.com> Message-ID: <51935D92.8080407@redhat.com> On 05/15/2013 11:40 AM, Ana Krivokapic wrote: > Hello, > > See the commit message for details. > > https://fedorahosted.org/freeipa/ticket/3594 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel + def regenerate_ca_file(self, ca_file): + dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp() + keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp() + + os.write(dm_pwd_fd, self.dirman_password) + os.close(dm_pwd_fd) + + keydb_pwd = '' + with open('/etc/pki/pki-tomcat/password.conf') as f: + for line in f.readlines(): + key, value = line.strip().split('=') + if key == 'internal': + keydb_pwd = value + break + + os.write(keydb_pwd_fd, keydb_pwd) + os.close(keydb_pwd_fd) + + ipautil.run([ + '/usr/bin/PKCS12Export', + '-d', '/etc/pki/pki-tomcat/alias/', + '-p', keydb_pwd_fname, + '-w', dm_pwd_fname, + '-o', ca_file + ]) + If the PKCS12Export call fails (returns non-zero code), we raise exception here, and the temporary files are never removed. + os.remove(dm_pwd_fname) + os.remove(keydb_pwd_fname) This might not be a big issue since mkstemp() call creates temporary file readable and writable only be given user ID, however, we should not leave files with passwords in plaintext on the disk if it is not necessary. This can be easily prevented by wrapping the call up with try-chatch-finally block, or using raiseonerr=False options of run method. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed May 15 10:09:40 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 15 May 2013 12:09:40 +0200 Subject: [Freeipa-devel] [PATCH] 414-415 Move spec modifications from facet factories to pre_ops Message-ID: <51935EE4.70706@redhat.com> [PATCH] 414 Move spec modifications from facet factories to pre_ops ------------------------------------------------------------------- Spec modifications in factories makes inheritance and extensibility more difficult. Moving them to pre_ops allows modification of their output by other pre_ops. https://fedorahosted.org/freeipa/ticket/3605 [PATCH] 415 Unite and move facet pre_ops to related modules ----------------------------------------------------------- Facet pre_ops defined in ./facet module were moved to modules where facet are actually defined. Moved pre_ops were united with the ones defined for the facets in these modules. The move simplifies module dependencies - there is no reason to have general facet module dependent on specialized facet modules. Pre_ops uniting makes the code simpler. https://fedorahosted.org/freeipa/ticket/3605 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0414-Move-spec-modifications-from-facet-factories-to-pre_.patch Type: text/x-patch Size: 11863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0415-Unite-and-move-facet-pre_ops-to-related-modules.patch Type: text/x-patch Size: 12924 bytes Desc: not available URL: From pvoborni at redhat.com Wed May 15 10:19:32 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 15 May 2013 12:19:32 +0200 Subject: [Freeipa-devel] [PATCH] 416 Web UI: move ./_base/metadata_provider.js to ./metadata.js Message-ID: <51936134.3060401@redhat.com> Metadata provider is IPA specific object, not a framework object, so it should not be in _base directory. https://fedorahosted.org/freeipa/ticket/3604 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0416-Web-UI-move-.-_base-metadata_provider.js-to-.-metada.patch Type: text/x-patch Size: 7729 bytes Desc: not available URL: From pviktori at redhat.com Wed May 15 10:29:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 15 May 2013 12:29:41 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51935D92.8080407@redhat.com> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> Message-ID: <51936395.20409@redhat.com> On 05/15/2013 12:04 PM, Tomas Babej wrote: > On 05/15/2013 11:40 AM, Ana Krivokapic wrote: >> Hello, >> >> See the commit message for details. >> >> https://fedorahosted.org/freeipa/ticket/3594 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > + def regenerate_ca_file(self, ca_file): > + dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp() > + keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp() > + > + os.write(dm_pwd_fd, self.dirman_password) > + os.close(dm_pwd_fd) > + > + keydb_pwd = '' > + with open('/etc/pki/pki-tomcat/password.conf') as f: > + for line in f.readlines(): > + key, value = line.strip().split('=') > + if key == 'internal': > + keydb_pwd = value > + break > + > + os.write(keydb_pwd_fd, keydb_pwd) > + os.close(keydb_pwd_fd) > + > + ipautil.run([ > + '/usr/bin/PKCS12Export', > + '-d', '/etc/pki/pki-tomcat/alias/', > + '-p', keydb_pwd_fname, > + '-w', dm_pwd_fname, > + '-o', ca_file > + ]) > + > > If the PKCS12Export call fails (returns non-zero code), we raise > exception here, and the temporary files are never removed. > > + os.remove(dm_pwd_fname) > + os.remove(keydb_pwd_fname) > > This might not be a big issue since mkstemp() call creates temporary > file readable and writable only be given user ID, > however, we should not leave files with passwords in plaintext on the > disk if it is not necessary. > > This can be easily prevented by wrapping the call up with > try-chatch-finally block, or using raiseonerr=False options of run method. Or by using ipautil.write_tmp_file() ? the file it creates is always removed after it's closed/garbage collected, and it has a name attribute. -- Petr? From akrivoka at redhat.com Wed May 15 11:36:51 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 15 May 2013 13:36:51 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed In-Reply-To: <51936395.20409@redhat.com> References: <519357F3.3080408@redhat.com> <51935D92.8080407@redhat.com> <51936395.20409@redhat.com> Message-ID: <51937353.3090501@redhat.com> On 05/15/2013 12:29 PM, Petr Viktorin wrote: > On 05/15/2013 12:04 PM, Tomas Babej wrote: >> On 05/15/2013 11:40 AM, Ana Krivokapic wrote: >>> Hello, >>> >>> See the commit message for details. >>> >>> https://fedorahosted.org/freeipa/ticket/3594 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> + def regenerate_ca_file(self, ca_file): >> + dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp() >> + keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp() >> + >> + os.write(dm_pwd_fd, self.dirman_password) >> + os.close(dm_pwd_fd) >> + >> + keydb_pwd = '' >> + with open('/etc/pki/pki-tomcat/password.conf') as f: >> + for line in f.readlines(): >> + key, value = line.strip().split('=') >> + if key == 'internal': >> + keydb_pwd = value >> + break >> + >> + os.write(keydb_pwd_fd, keydb_pwd) >> + os.close(keydb_pwd_fd) >> + >> + ipautil.run([ >> + '/usr/bin/PKCS12Export', >> + '-d', '/etc/pki/pki-tomcat/alias/', >> + '-p', keydb_pwd_fname, >> + '-w', dm_pwd_fname, >> + '-o', ca_file >> + ]) >> + >> >> If the PKCS12Export call fails (returns non-zero code), we raise >> exception here, and the temporary files are never removed. >> >> + os.remove(dm_pwd_fname) >> + os.remove(keydb_pwd_fname) >> >> This might not be a big issue since mkstemp() call creates temporary >> file readable and writable only be given user ID, >> however, we should not leave files with passwords in plaintext on the >> disk if it is not necessary. >> >> This can be easily prevented by wrapping the call up with >> try-chatch-finally block, or using raiseonerr=False options of run >> method. > > Or by using ipautil.write_tmp_file() ? the file it creates is always > removed after it's closed/garbage collected, and it has a name attribute. > Updated patch uses `ipautil.write_tmp_file()`. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0029-02-Make-sure-replication-works-after-DM-password-is-cha.patch Type: text/x-patch Size: 3147 bytes Desc: not available URL: From tbabej at redhat.com Wed May 15 13:41:10 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 15 May 2013 15:41:10 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust Message-ID: <51939076.7060909@redhat.com> Hi, When removing an ID range using idrange-del command, validation in pre_callback ensures that the range does not belong to any active trust. In such case, ValidationError is raised. https://fedorahosted.org/freeipa/ticket/3615 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0057-Do-not-allow-removal-of-ID-range-of-an-active-trust.patch Type: text/x-patch Size: 2145 bytes Desc: not available URL: From pspacek at redhat.com Wed May 15 13:49:35 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 15 May 2013 15:49:35 +0200 Subject: [Freeipa-devel] [PATCH 0002] Add 'debug' statement to nsupdate commands generated by ipa-client-install Message-ID: <5193926F.7030601@redhat.com> Hello, This patch adds 'debug' and 'show' statements to nsupdate commands generated by ipa-client-install. https://fedorahosted.org/freeipa/ticket/3629 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0002-Add-debug-statement-to-nsupdate-commands-generated-b.patch Type: text/x-patch Size: 1575 bytes Desc: not available URL: From akrivoka at redhat.com Wed May 15 14:02:10 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 15 May 2013 16:02:10 +0200 Subject: [Freeipa-devel] [PATCH] 414-415 Move spec modifications from facet factories to pre_ops In-Reply-To: <51935EE4.70706@redhat.com> References: <51935EE4.70706@redhat.com> Message-ID: <51939562.8060406@redhat.com> On 05/15/2013 12:09 PM, Petr Vobornik wrote: > [PATCH] 414 Move spec modifications from facet factories to pre_ops > ------------------------------------------------------------------- > > Spec modifications in factories makes inheritance and extensibility > more difficult. > > Moving them to pre_ops allows modification of their output by other > pre_ops. > > https://fedorahosted.org/freeipa/ticket/3605 > > [PATCH] 415 Unite and move facet pre_ops to related modules > ----------------------------------------------------------- > > Facet pre_ops defined in ./facet module were moved to modules where > facet are actually defined. Moved pre_ops were united with the ones > defined for the facets in these modules. > > The move simplifies module dependencies - there is no reason to have > general facet module dependent on specialized facet modules. > > Pre_ops uniting makes the code simpler. > > https://fedorahosted.org/freeipa/ticket/3605 > > A minor nitpick - in patch 415: + if (indirect_members) { + if (indirect_members.indexOf(spec.other_entity) > -1) { + return true; + } + } This construct: if (A) { if (B) { do_something(); } } Can be replaced with: if (A && B) { do_something(); } The second option is more readable, and avoids nested ifs. I have found no other issues, so ACK from me. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Wed May 15 14:03:06 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 15 May 2013 16:03:06 +0200 Subject: [Freeipa-devel] [PATCH] 416 Web UI: move ./_base/metadata_provider.js to ./metadata.js In-Reply-To: <51936134.3060401@redhat.com> References: <51936134.3060401@redhat.com> Message-ID: <5193959A.1060903@redhat.com> On 05/15/2013 12:19 PM, Petr Vobornik wrote: > Metadata provider is IPA specific object, not a framework object, so > it should not be in _base directory. > > https://fedorahosted.org/freeipa/ticket/3604 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Wed May 15 14:36:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 15 May 2013 16:36:52 +0200 Subject: [Freeipa-devel] [PATCH 0058] Remove redundancy from hbactest help text Message-ID: <51939D84.5020802@redhat.com> Hi, I modified the SID in the second example. https://fedorahosted.org/freeipa/ticket/3625 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0058-Remove-redundancy-from-hbactest-help-text.patch Type: text/x-patch Size: 997 bytes Desc: not available URL: From mkosek at redhat.com Wed May 15 14:46:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 May 2013 16:46:57 +0200 Subject: [Freeipa-devel] [PATCH 0058] Remove redundancy from hbactest help text In-Reply-To: <51939D84.5020802@redhat.com> References: <51939D84.5020802@redhat.com> Message-ID: <51939FE1.1080603@redhat.com> On 05/15/2013 04:36 PM, Tomas Babej wrote: > Hi, > > I modified the SID in the second example. > > https://fedorahosted.org/freeipa/ticket/3625 > > Tomas > NACK. The hbactest command result was also intended to be different (see command below, DOMAIN\Otheruser should equal S-1-5-21-3035198329-144811719-1378114514-1203). Martin From tbabej at redhat.com Wed May 15 15:02:33 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 15 May 2013 17:02:33 +0200 Subject: [Freeipa-devel] [PATCH 0058] Remove redundancy from hbactest help text In-Reply-To: <51939FE1.1080603@redhat.com> References: <51939D84.5020802@redhat.com> <51939FE1.1080603@redhat.com> Message-ID: <5193A389.1070905@redhat.com> On 05/15/2013 04:46 PM, Martin Kosek wrote: > On 05/15/2013 04:36 PM, Tomas Babej wrote: >> Hi, >> >> I modified the SID in the second example. >> >> https://fedorahosted.org/freeipa/ticket/3625 >> >> Tomas >> > NACK. The hbactest command result was also intended to be different (see > command below, DOMAIN\Otheruser should equal > S-1-5-21-3035198329-144811719-1378114514-1203). > > Martin Now it should be consistent. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0058-2-Remove-redundancy-from-hbactest-help-text.patch Type: text/x-patch Size: 1279 bytes Desc: not available URL: From pspacek at redhat.com Wed May 15 15:11:20 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 15 May 2013 17:11:20 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <94125227.1971889.1368606594501.JavaMail.root@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> Message-ID: <5193A598.4050805@redhat.com> On 15.5.2013 10:29, Simo Sorce wrote: >> I investigated various scenarios for DNSSEC integration and I would like to >> hear your opinions about proposed approach and it's effects. >> >> >> The most important finding is that bind-dyndb-ldap can't support DNSSEC >> without rewrite of the 'in-memory database' component. > > Can you elaborate why a rewrite would be needed ? What constraint we do not meet ? We have three main problems - partially with data structures and mostly with the way how we work with the 'internal database': 1) DNSSEC requires strict record ordering, i.e. each record in database has to have predecessor and successor (ordering by name and then by record data). This can be done relatively simply, but it requires a full dump of the database. 2) On-line record signing requires a lot of data stored per-record+per-signature. This would require bigger effort than point 1), because many data structures and respective APIs and locking protocols have to be re-designed. 3) Our current 'internal database' acts as a 'cache', i.e. records can appear and disappear dynamically and the 'cache' is not considered as authoritative source of data: LDAP search is conducted each time when some data are not found etc. The result is that the same data can disappear and then appear again in the cache etc. Typical update scenario, with persistent search enabled: a) DNS UPDATE from client is received by BIND b) New data are written to LDAP c) DN of modified object is received via persistent search d) All RRs under the *updated name* are discarded from the cache <-- now the cache is not consistent with data in LDAP e) Object from LDAP is fetched by plugin <-- a query for the updated name will enforce instant cache refresh, because we know that the cache is not authoritative f) All RRs in the object are updated (in cache) The problem is that the cache in intermediate states (between <-- marks) can't be used as authoritative source and will produce incorrect signatures. The text below contains more details. Database's in BIND has concept of 'versions' ('transactions') which our internal cache do not implement ... It could be solved by proper locking, of course, but it will not be a piece of cake. We need to take care of many parallel updates, parallel queries and parallel re-signing at the same time. I don't say that it is impossible to implement our own backend with same properties as BIND's database, but I don't see the value (and I can see a lot of bugs :-). >> Fortunately, it seems >> that we can drop our own implementation of the internal DNS database >> (ldap_driver.c and cache.c) and re-use the database from BIND (so called >> RBTDB). >> >> I'm trying to reach Adam Tkac with the question "Why we decided to implement >> it again rather than re-use BIND's code?". >> >> >> Re-usage of BIND's implementation will have following properties: >> >> >> == Advantages == >> - Big part of DNSSEC implementation from BIND9 can be reused. >> - Overall plugin implementation will be simpler - we can drop many lines of >> our code and bugs. >> - Run-time performance could be much much better. >> >> - We will get implementation for these tickets "for free": >> -- #95 wildcard CNAME does NOT work >> -- #64 IXFR support (IMHO this is important!) >> -- #6 Cache non-existing records >> >> And partially: >> -- #7 Allow limiting of the cache > > Sounds very interesting. > > >> == Disadvantages == >> - Support for configurations without persistent search will complicate things >> a lot. >> -- Proposal => Make persistent search obligatory. OpenLDAP supports LDAP >> SyncRepl, so it should be possible to make plugin compatible with 389 and >> OpenLDAP at the same time. I would defer this to somebody from users/OpenLDAP >> community. > > Why the persistent search would be required ? As I mentioned above - you need database dump, because DNSSEC requires strict name and record ordering. It is possible to do incremental changes when the 'starting snapshot' is established, but it means that we need information about each particular change => that is what persistent search provides. >> - Data from LDAP have to be dumped to memory (or to file) before the server >> will start replying to queries. >> => This is not nice, but servers usually are not restarted often. IMHO it is >> a >> good compromise between complexity and performance. > > I am not sure I understand what this means. Does it mean you cannot change single > cache entries on the fly when a change happens in LDAP ? Or something else ? Sorry, I didn't explained this part in it's full depth. You can change everything run-time, but there are small details which complicates loading of the zone and run-time changes: 1) A normal zones requires SOA + NS + A/AAAA records (for NSs) to load. It is (hypothetically) possible to create empty zone, fill it with SOA, NS and A records and then incrementally add rest of the records. The problem is that you need to re-implement DNS resolution algorithm to find which records you need at the beginning (SOA, NS, A/AAAA) and then load the rest. I would like to avoid this re-implementation. It is not possible to re-use BIND's implementation because it is tied to the DB implementation ... but we can't load the database because it is missing SOA, NS and A/AAAA records. Chicken-egg problem. 2) The second reason why I want to make persistent search obligatory is that each change in DNSSEC signed zone requires a lot of work, so it is not a good idea to wait with the work to time when somebody asks for particular record. How it works without persistent search (now): 1) Query from a client is received by BIND 2) Internal cache is consulted 3) Record is not found in the cache - LDAP search is done 4) Fetched records in saved to the cache 5) Reply to client is constructed It is hard to work in the same way when DNSSEC is in place. Each change implicates re-signing of the particular RRset and it's neighbours, i.e.: 1) Query from a client is received by BIND 2) Internal cache is consulted 3) Record is not found in the cache - LDAP search is done 4) Fetched records in saved to the cache * 4b) New RRset is re-signed * 4c) Records neighbouring with the new RR has to be updated and re-signed 5) Reply to client is constructed The point is that you *can* do changes run-time, but you need to know about the changes as soon as possible because each change requires significant amount of work (and magic/mana :-). It opens a lot of opportunities for race condition problems. >> => It should be possible to save old database to disk (during BIND shutdown >> or >> periodically) and re-use this old database during server startup. I.e. server >> will start replying immediately from 'old' database and then the server will >> switch to the new database when dump from LDAP is finished. > > > This look like an advantage ? Why is it a disadvantage ? It was mentioned as 'proposed remedy' for the disadvantage above. >> => As a side effect, BIND can start even if connection to LDAP server is down >> - this can improve infrastructure resiliency a lot! > > Same as above ? The same here, it was mentioned as 'proposed remedy' for the disadvantage above. >> == Uncertain effects == >> - Memory consumption will change, but I'm not sure in which direction. >> - SOA serial number maintenance is a open question. > > Why SOA serial is a problem ? It simply needs more investigation. BIND's RBTDB maintains SOA serial internally (it is intertwined to transactions in the DB), so the write-back to LDAP could be very delicate operation. >> Decision if persistent search is a 'requirement' or not will have significant >> impact on the design, so I will write the design document when this decision >> is made. > > I would like to know more details about the reasons before I can usefully comment. I forgot to one another 'Uncertain effect': - Support for dynamically generated '_location' records will be a big adventure. It probably means no change from the state without persistent search :-) After basic exploration it seems doable, but still a bit uncertain. My personal conclusion is that re-using of BIND's backend will save a huge amount of work/code to maintain/bugs. -- Petr^2 Spacek From akrivoka at redhat.com Wed May 15 15:43:28 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 15 May 2013 17:43:28 +0200 Subject: [Freeipa-devel] [PATCH] 0026 Do not display success message on failure in web UI In-Reply-To: <5190FDE4.2080200@redhat.com> References: <51891ADE.3070803@redhat.com> <5190FDE4.2080200@redhat.com> Message-ID: <5193AD20.1050001@redhat.com> On 05/13/2013 04:51 PM, Petr Vobornik wrote: > On 05/07/2013 05:16 PM, Ana Krivokapic wrote: >> https://fedorahosted.org/freeipa/ticket/3591 >> > > 1) The change from on_success to on_error is causing problems when > some command in a batch doesn't fail. Ie.: disable multiple users on > user search facet. Disabling already disabled user causes an error. > The dialog is shown but the page is not refreshed so the newly > disabled records are still displayed as enabled. We might even call > this case a success. > > IMO we shouldn't change the method because the batch itself succeeded. > The problem should be fixed on caller side (users of batch command). > > 2) Also `ajax` context should be left there instead of `this`, > otherwise it would get the context of on_ok handler: > > 3) (not an actual issue) Some of my old code doesn't contain space > between for/if and opening curly bracet, opposite to the rest of the > Web UI. Spaces should be added when touching these parts of code. Since the problem occurs in the case when the batch succeeds, but some commands from the batch fail, it should be enough to modify the message that is displayed. I modified it so it shows exactly how many items from the batch succeeded. Updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0026-02-Do-not-display-success-message-on-failure-in-web-UI.patch Type: text/x-patch Size: 2850 bytes Desc: not available URL: From mkosek at redhat.com Wed May 15 16:18:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 May 2013 18:18:59 +0200 Subject: [Freeipa-devel] [PATCH 0058] Remove redundancy from hbactest help text In-Reply-To: <5193A389.1070905@redhat.com> References: <51939D84.5020802@redhat.com> <51939FE1.1080603@redhat.com> <5193A389.1070905@redhat.com> Message-ID: <5193B573.5090201@redhat.com> On 05/15/2013 05:02 PM, Tomas Babej wrote: > On 05/15/2013 04:46 PM, Martin Kosek wrote: >> On 05/15/2013 04:36 PM, Tomas Babej wrote: >>> Hi, >>> >>> I modified the SID in the second example. >>> >>> https://fedorahosted.org/freeipa/ticket/3625 >>> >>> Tomas >>> >> NACK. The hbactest command result was also intended to be different (see >> command below, DOMAIN\Otheruser should equal >> S-1-5-21-3035198329-144811719-1378114514-1203). >> >> Martin > > Now it should be consistent. > > Tomas ACK. Pushed to master, ipa-3-2. Martin From nicmac at gmail.com Thu May 16 00:33:07 2013 From: nicmac at gmail.com (Nicholas MacKenzie) Date: Wed, 15 May 2013 20:33:07 -0400 Subject: [Freeipa-devel] Freeipa-devel Digest, Vol 72, Issue 51 In-Reply-To: References: Message-ID: Unsubscribe On May 15, 2013 12:01 PM, wrote: > Send Freeipa-devel mailing list submissions to > freeipa-devel at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-devel > or, via email, send a message with subject or body 'help' to > freeipa-devel-request at redhat.com > > You can reach the person managing the list at > freeipa-devel-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-devel digest..." > > > Today's Topics: > > 1. Re: [PATCH] 0026 Do not display success message on failure in > web UI (Ana Krivokapic) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 May 2013 17:43:28 +0200 > From: Ana Krivokapic > To: Petr Vobornik > Cc: freeipa-devel > Subject: Re: [Freeipa-devel] [PATCH] 0026 Do not display success > message on failure in web UI > Message-ID: <5193AD20.1050001 at redhat.com> > Content-Type: text/plain; charset="iso-8859-1" > > On 05/13/2013 04:51 PM, Petr Vobornik wrote: > > On 05/07/2013 05:16 PM, Ana Krivokapic wrote: > >> https://fedorahosted.org/freeipa/ticket/3591 > >> > > > > 1) The change from on_success to on_error is causing problems when > > some command in a batch doesn't fail. Ie.: disable multiple users on > > user search facet. Disabling already disabled user causes an error. > > The dialog is shown but the page is not refreshed so the newly > > disabled records are still displayed as enabled. We might even call > > this case a success. > > > > IMO we shouldn't change the method because the batch itself succeeded. > > The problem should be fixed on caller side (users of batch command). > > > > 2) Also `ajax` context should be left there instead of `this`, > > otherwise it would get the context of on_ok handler: > > > > 3) (not an actual issue) Some of my old code doesn't contain space > > between for/if and opening curly bracet, opposite to the rest of the > > Web UI. Spaces should be added when touching these parts of code. > > Since the problem occurs in the case when the batch succeeds, but some > commands from the batch fail, it should be enough to modify the message > that is displayed. I modified it so it shows exactly how many items from > the batch succeeded. > > Updated patch is attached. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: > freeipa-akrivoka-0026-02-Do-not-display-success-message-on-failure-in-web-UI.patch > Type: text/x-patch > Size: 2849 bytes > Desc: not available > URL: < > https://www.redhat.com/archives/freeipa-devel/attachments/20130515/67c3a9c8/attachment.bin > > > > ------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > End of Freeipa-devel Digest, Vol 72, Issue 51 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcix133 at hotmail.com Thu May 16 05:50:21 2013 From: pcix133 at hotmail.com (daiEric) Date: Thu, 16 May 2013 05:50:21 +0000 Subject: [Freeipa-devel] installation freeipa on centos and ubuntu 13 Message-ID: hi? all where I can find the document about the installation freeipa on centos 6.3 and Ubuntu 13.04 thanks and best regardsEric dai -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu May 16 07:34:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 May 2013 09:34:38 +0200 Subject: [Freeipa-devel] installation freeipa on centos and ubuntu 13 In-Reply-To: References: Message-ID: <51948C0E.9000106@redhat.com> On 05/16/2013 07:50 AM, daiEric wrote: > hi? all > where I can find the document about the installation freeipa on centos 6.3 and > Ubuntu 13.04 > > thanks and best regards > Eric dai > Hello Eric, I do not know about CentOS, but you can find RHEL guide for FreeIPA here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html As for Ubuntu, I do not think that FreeIPA is packaged there yet. There were some actions in the past to make that happen but it has not finished yet. If you just want to try FreeIPA, I would recommend using Fedora 18. HTH, Martin From pspacek at redhat.com Thu May 16 07:48:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 16 May 2013 09:48:05 +0200 Subject: [Freeipa-devel] [PATCH 0155] Fix IPv6 handling in PTR record synchronization Message-ID: <51948F35.1010408@redhat.com> Hello, Fix IPv6 handling in PTR record synchronization. https://fedorahosted.org/bind-dyndb-ldap/ticket/118 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0155-Fix-IPv6-handling-in-PTR-record-synchronization.patch Type: text/x-patch Size: 3500 bytes Desc: not available URL: From mkosek at redhat.com Thu May 16 09:02:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 May 2013 11:02:38 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Prompt for nameserver IP address in dnszone-add In-Reply-To: <5192492B.10608@redhat.com> References: <51893EF2.6090308@redhat.com> <518B7E2D.9010301@redhat.com> <518B9244.80901@redhat.com> <518BD6D5.40901@redhat.com> <518CA205.3000200@redhat.com> <518CB6B0.3000204@redhat.com> <518CDA51.3040208@redhat.com> <518CEB26.3050404@redhat.com> <518CFCC9.4040409@redhat.com> <518D0661.3050405@redhat.com> <518D5A87.6070105@redhat.com> <518F94D1.2030508@redhat.com> <5190E17F.5040306@redhat.com> <51920C60.9040302@redhat.com> <519221C0.5050907@redhat.com> <5192492B.10608@redhat.com> Message-ID: <5194A0AE.2090707@redhat.com> On 05/14/2013 04:24 PM, Petr Vobornik wrote: > On 05/14/2013 01:36 PM, Ana Krivokapic wrote: >> On 05/14/2013 12:05 PM, Ana Krivokapic wrote: >>> On 05/13/2013 02:50 PM, Petr Vobornik wrote: >>>> A nitpick for UI part which is not a blocker(nack) because we don't >>>> have any strict rules for following topic: >>>> >>>> We should avoid depending on widget's html output outside of the >>>> widget code. >>>> >>>> So we should use: >>>> zone_w.save()[0] >>>> instead of: >>>> $('input', zone_w.container).val(); >>>> >>>> same for `ns`. >>> Thanks, fixed. >>>> Unfortunately there is no text_widget.is_enabled() method so >>>> `zone_w.input.prop('disabled')` can't be replaced. >>> I implemented the `text_widget.is_enabled()` method, and replaced >>> `zone_w.input.prop('disabled')` with `!zone_w.is_enabled()`. >>> >>> Updated patch attached. >> >> Petr caught another bug: due to the return value of >> `text_widget.save()`, an exception was raised in the case of empty zone. >> This has been fixed in the attached patch. >> >> I also changed the name of the endsWith() function to ends_with(), to >> conform to our coding standard. >> > > ACK > Pushed to master, ipa-3-2. Thanks! Martin From akrivoka at redhat.com Thu May 16 09:16:53 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 16 May 2013 11:16:53 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <51939076.7060909@redhat.com> References: <51939076.7060909@redhat.com> Message-ID: <5194A405.50804@redhat.com> On 05/15/2013 03:41 PM, Tomas Babej wrote: > Hi, > > When removing an ID range using idrange-del command, validation > in pre_callback ensures that the range does not belong to any > active trust. In such case, ValidationError is raised. > > https://fedorahosted.org/freeipa/ticket/3615 > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I suggest adding some unit tests to cover this change in functionality. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Thu May 16 10:37:15 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 16 May 2013 12:37:15 +0200 Subject: [Freeipa-devel] [PATCH 0002] Add 'debug' statement to nsupdate commands generated by ipa-client-install In-Reply-To: <5193926F.7030601@redhat.com> References: <5193926F.7030601@redhat.com> Message-ID: <5194B6DB.2020907@redhat.com> On 05/15/2013 03:49 PM, Petr Spacek wrote: > Hello, > > This patch adds 'debug' and 'show' statements to nsupdate commands > generated by ipa-client-install. > > https://fedorahosted.org/freeipa/ticket/3629 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel You probably want to add another 'show', before the last 'send' in the `update_ssh_keys()` function. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Thu May 16 11:20:28 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 May 2013 13:20:28 +0200 Subject: [Freeipa-devel] [PATCH] 0026 Do not display success message on failure in web UI In-Reply-To: <5193AD20.1050001@redhat.com> References: <51891ADE.3070803@redhat.com> <5190FDE4.2080200@redhat.com> <5193AD20.1050001@redhat.com> Message-ID: <5194C0FC.40703@redhat.com> On 05/15/2013 05:43 PM, Ana Krivokapic wrote: > On 05/13/2013 04:51 PM, Petr Vobornik wrote: >> On 05/07/2013 05:16 PM, Ana Krivokapic wrote: >>> https://fedorahosted.org/freeipa/ticket/3591 >>> >> >> 1) The change from on_success to on_error is causing problems when >> some command in a batch doesn't fail. Ie.: disable multiple users on >> user search facet. Disabling already disabled user causes an error. >> The dialog is shown but the page is not refreshed so the newly >> disabled records are still displayed as enabled. We might even call >> this case a success. >> >> IMO we shouldn't change the method because the batch itself succeeded. >> The problem should be fixed on caller side (users of batch command). >> >> 2) Also `ajax` context should be left there instead of `this`, >> otherwise it would get the context of on_ok handler: >> >> 3) (not an actual issue) Some of my old code doesn't contain space >> between for/if and opening curly bracet, opposite to the rest of the >> Web UI. Spaces should be added when touching these parts of code. > > Since the problem occurs in the case when the batch succeeds, but some > commands from the batch fail, it should be enough to modify the message > that is displayed. I modified it so it shows exactly how many items from > the batch succeeded. > > Updated patch is attached. > It's a good direction. 1) Search trough the code revealed that there are also other cases: a) in association_facet:association.js:1031,1082 - add and delete when bulk_associator (default) is used (ie. in group/member_user). Make sure that it doesn't crash when serial associator is used (it doesn't use batch command). b) sudo rule delete option Can be reproduced by using two Web UIs and trying to do the same action in both instances. 2) I wonder whether to not call notify_success when all commands in a batch fail. User should know what failed from the error dialog. But it is not sufficiently verbose in this matter, it should show how many commands succeeded and failed - https://fedorahosted.org/freeipa/ticket/1702 . Until then I'm hesitant to omit the notify_success call. On the other hand, it might be easier to do now. What do you think? -- Petr Vobornik From pvoborni at redhat.com Thu May 16 12:01:54 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 May 2013 14:01:54 +0200 Subject: [Freeipa-devel] [PATCH] 414-415 Move spec modifications from facet factories to pre_ops In-Reply-To: <51939562.8060406@redhat.com> References: <51935EE4.70706@redhat.com> <51939562.8060406@redhat.com> Message-ID: <5194CAB2.60001@redhat.com> On 05/15/2013 04:02 PM, Ana Krivokapic wrote: > On 05/15/2013 12:09 PM, Petr Vobornik wrote: >> [PATCH] 414 Move spec modifications from facet factories to pre_ops >> ------------------------------------------------------------------- >> >> Spec modifications in factories makes inheritance and extensibility >> more difficult. >> >> Moving them to pre_ops allows modification of their output by other >> pre_ops. >> >> https://fedorahosted.org/freeipa/ticket/3605 >> >> [PATCH] 415 Unite and move facet pre_ops to related modules >> ----------------------------------------------------------- >> >> Facet pre_ops defined in ./facet module were moved to modules where >> facet are actually defined. Moved pre_ops were united with the ones >> defined for the facets in these modules. >> >> The move simplifies module dependencies - there is no reason to have >> general facet module dependent on specialized facet modules. >> >> Pre_ops uniting makes the code simpler. >> >> https://fedorahosted.org/freeipa/ticket/3605 >> >> > > A minor nitpick - in patch 415: > > + if (indirect_members) { > + if (indirect_members.indexOf(spec.other_entity) > -1) { > + return true; > + } > + } > > This construct: > if (A) { > if (B) { > do_something(); > } > } > > Can be replaced with: > if (A && B) { > do_something(); > } > > The second option is more readable, and avoids nested ifs. Changed: - if (indirect_members) { - if (indirect_members.indexOf(spec.other_entity) > -1) { - return true; - } - } - return false; + var has_indirect = !!(indirect_members && indirect_members.indexOf(spec.other_entity) > -1); + return has_indirect; Updated patch attached. > > > I have found no other issues, so ACK from me. > > -- > Regards, > > Ana Krivokapic -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0414-Move-spec-modifications-from-facet-factories-to-pre_.patch Type: text/x-patch Size: 11863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0415-1-Unite-and-move-facet-pre_ops-to-related-modules.patch Type: text/x-patch Size: 12874 bytes Desc: not available URL: From akrivoka at redhat.com Thu May 16 14:26:10 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 16 May 2013 16:26:10 +0200 Subject: [Freeipa-devel] [PATCH] 0026 Do not display success message on failure in web UI In-Reply-To: <5194C0FC.40703@redhat.com> References: <51891ADE.3070803@redhat.com> <5190FDE4.2080200@redhat.com> <5193AD20.1050001@redhat.com> <5194C0FC.40703@redhat.com> Message-ID: <5194EC82.2030407@redhat.com> On 05/16/2013 01:20 PM, Petr Vobornik wrote: > On 05/15/2013 05:43 PM, Ana Krivokapic wrote: >> On 05/13/2013 04:51 PM, Petr Vobornik wrote: >>> On 05/07/2013 05:16 PM, Ana Krivokapic wrote: >>>> https://fedorahosted.org/freeipa/ticket/3591 >>>> >>> >>> 1) The change from on_success to on_error is causing problems when >>> some command in a batch doesn't fail. Ie.: disable multiple users on >>> user search facet. Disabling already disabled user causes an error. >>> The dialog is shown but the page is not refreshed so the newly >>> disabled records are still displayed as enabled. We might even call >>> this case a success. >>> >>> IMO we shouldn't change the method because the batch itself succeeded. >>> The problem should be fixed on caller side (users of batch command). >>> >>> 2) Also `ajax` context should be left there instead of `this`, >>> otherwise it would get the context of on_ok handler: >>> >>> 3) (not an actual issue) Some of my old code doesn't contain space >>> between for/if and opening curly bracet, opposite to the rest of the >>> Web UI. Spaces should be added when touching these parts of code. >> >> Since the problem occurs in the case when the batch succeeds, but some >> commands from the batch fail, it should be enough to modify the message >> that is displayed. I modified it so it shows exactly how many items from >> the batch succeeded. >> >> Updated patch is attached. >> > > It's a good direction. > > 1) Search trough the code revealed that there are also other cases: > a) in association_facet:association.js:1031,1082 - add and delete when > bulk_associator (default) is used (ie. in group/member_user). Make > sure that it doesn't crash when serial associator is used (it doesn't > use batch command). > b) sudo rule delete option > > Can be reproduced by using two Web UIs and trying to do the same > action in both instances. Fixed in updated patch. I also slightly reworded strings in internal.py, to avoid situations like "1 items were added". > > 2) I wonder whether to not call notify_success when all commands in a > batch fail. User should know what failed from the error dialog. But it > is not sufficiently verbose in this matter, it should show how many > commands succeeded and failed - > https://fedorahosted.org/freeipa/ticket/1702 . Until then I'm hesitant > to omit the notify_success call. On the other hand, it might be easier > to do now. What do you think? > I would not omit it - I think the displayed message is quite clear and no longer misleading. It is an extra piece of information for the user and could be useful in the case when all commands in a batch fail, as it is not immediately clear from the error dialog that this is what happened. I would leave it in for now, at least until we see what the solution for #1702 will look like. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0026-03-Do-not-display-success-message-on-failure-in-web-UI.patch Type: text/x-patch Size: 10721 bytes Desc: not available URL: From mkosek at redhat.com Fri May 17 07:42:13 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 May 2013 09:42:13 +0200 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <51927061.5040007@redhat.com> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1368219349.2470.4.camel@localhost.localdomain> <1368539597.2470.9.camel@localhost.localdomain> <51927061.5040007@redhat.com> Message-ID: <5195DF55.2080703@redhat.com> On 05/14/2013 07:12 PM, Martin Kosek wrote: > On 05/14/2013 03:53 PM, Nathaniel McCallum wrote: >> On Fri, 2013-05-10 at 16:55 -0400, Nathaniel McCallum wrote: >>> On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: >>>> On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: >>>>> On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: >>>>>> All issues fixed unless noted below... The attached patches are tested >>>>>> to work. >>>>>> >>>>>> On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: >>>>>> >>>>>>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >>>>>>> (although I know slapi_ch_malloc() currently just aborts on failure, I >>>>>>> think that is plain wrong which is why I would prefer using >>>>>>> malloc/strdup, but well, I guess this is not something I am going to >>>>>>> care too much about for now). >>>>>> Not fixed. >>>>>> >>>>>>> - Is the logic with auth_type_used correct ? >>>>>>> At least the name of the variable sounds misleading, because you set it >>>>>>> only if the authentication was successful but not set if it was 'used' >>>>>>> but was unsuccessful. Made me look at it multiple times to reconstuct >>>>>>> the logic. The var name could be better, however I also want a comment >>>>>>> that explain exactly how we are going to manage authentication and >>>>>>> fallbacks here as that logic is critical and is useful for anyone that >>>>>>> is going to have to change this code later in order not to break it. >>>>>> The variable is now gone. I re-factored the section to make the logic >>>>>> clearer and put a nice big comment up top. >>>>>> >>>>>>> - General question: how does this PRE_BIND plugin interact with >>>>>>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >>>>>>> Are you going to cause that plugin not to run by returning a result >>>>>>> directly in this function ? >>>>>>> Or is this plugin configured to run only after the previous one went >>>>>>> through ? >>>>>>> I ask because I do not see any ordering information in the cn=config >>>>>>> plugin configuration so it is not immediately clear to me. >>>>>> That is a good question for Nathan since he wrote this part of the >>>>>> code... >>>>> We would need to set the precedence if you want a predictable/guaranteed >>>>> execution order. If a pre-BIND plug-in callback returns non-zero (which >>>>> you should do when the plug-in sends the result to the client directly), >>>>> it will cause other pre-bind plug-ins to not be called. This is >>>>> actually how all pre-op plug-ins work. If a pre-op callback returns an >>>>> error, we don't call the rest of the pre-op plug-ins in the list. >>>> >>>> Ok, but this does not answer my question. >>>> We definitely need to *always* run our other preop plugin as we do >>>> sanity checks like verifying if the user is enabled/disabled etc... >>>> Also we need to understand how to deal with migrating password auth when >>>> OTP is enabeld. >>>> >>>> TBH I think we should not have a separate OTP-auth plugin but we should >>>> probably have a single plugin that handles authentication and the 2 >>>> should be merged. Keeping them separate is going to cause more harm than >>>> good with unexpected interactions. >>>> >>>> We could still have 2 plugins and simply move the prebind action >>>> currently don in ipa-pwd-extop to the otp plugin by making some more >>>> code common. But it is probably easier to just merge OTP into >>>> ipa-pwd-extop right now than try to do a huge refactoring. We can always >>>> refactor the ipa-pwd-extop plugin later. >>> >>> The attached patches encompass an initial review of the companion daemon >>> and merge of ipa-otp into ipa-pwd-extop. Unfortunately, merging ipa-otp >>> into ipa-pwd-extop appears to have broken something during install, but >>> I don't have enough familiarity with 389 to understand what I've broken. >>> If I upgrade after an install, it appears to work. >>> >>> An RPM with the patches is available here: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5362935 >>> >>> Nathan / Rob / Simo, could you take a look and see what might be broken >>> in ipa-pwd-extop? >> >> While I'm not quite sure what the problem was, I do know it appeared on >> the stock 3.2 F19 RPMs. I also fixed it by accident. I am certain it is >> unrelated to these patches. >> >> I have now tested install and upgrade with the six patches in the >> previous email and everything is in order, including permissions. At >> this point, we just need reviews/ACKs. >> >> Nathaniel >> > > I tested IPA server upgrades, new installs and also adding 3.2+OTP replica for > F18 3.1.4 IPA master. Everything seemed to work fine (when I added my patch 407 > fixing the replication), I did not see any breakage. > > Issues I found with too much logging I reported should now be fixed on github, > so this should be OK. > > So it is an ACK from my side if Rob does not discover some blocking issue. > > Martin We have all the acks now (some went off-list). Pushed to master, ipa-3-2. Thanks! Martin From pvoborni at redhat.com Fri May 17 10:38:45 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 May 2013 12:38:45 +0200 Subject: [Freeipa-devel] [PATCH] 416 Web UI: move ./_base/metadata_provider.js to ./metadata.js In-Reply-To: <5193959A.1060903@redhat.com> References: <51936134.3060401@redhat.com> <5193959A.1060903@redhat.com> Message-ID: <519608B5.7000408@redhat.com> On 05/15/2013 04:03 PM, Ana Krivokapic wrote: > On 05/15/2013 12:19 PM, Petr Vobornik wrote: >> Metadata provider is IPA specific object, not a framework object, so >> it should not be in _base directory. >> >> https://fedorahosted.org/freeipa/ticket/3604 >> > ACK > > -- > Regards, > > Ana Krivokapic Pushed to master, ipa-3-2. -- Petr Vobornik From pvoborni at redhat.com Fri May 17 10:39:13 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 May 2013 12:39:13 +0200 Subject: [Freeipa-devel] [PATCH] 414-415 Move spec modifications from facet factories to pre_ops In-Reply-To: <5194CAB2.60001@redhat.com> References: <51935EE4.70706@redhat.com> <51939562.8060406@redhat.com> <5194CAB2.60001@redhat.com> Message-ID: <519608D1.2070502@redhat.com> On 05/16/2013 02:01 PM, Petr Vobornik wrote: > On 05/15/2013 04:02 PM, Ana Krivokapic wrote: >> On 05/15/2013 12:09 PM, Petr Vobornik wrote: >>> [PATCH] 414 Move spec modifications from facet factories to pre_ops >>> ------------------------------------------------------------------- >>> >>> Spec modifications in factories makes inheritance and extensibility >>> more difficult. >>> >>> Moving them to pre_ops allows modification of their output by other >>> pre_ops. >>> >>> https://fedorahosted.org/freeipa/ticket/3605 >>> >>> [PATCH] 415 Unite and move facet pre_ops to related modules >>> ----------------------------------------------------------- >>> >>> Facet pre_ops defined in ./facet module were moved to modules where >>> facet are actually defined. Moved pre_ops were united with the ones >>> defined for the facets in these modules. >>> >>> The move simplifies module dependencies - there is no reason to have >>> general facet module dependent on specialized facet modules. >>> >>> Pre_ops uniting makes the code simpler. >>> >>> https://fedorahosted.org/freeipa/ticket/3605 >>> >>> >> >> A minor nitpick - in patch 415: >> >> + if (indirect_members) { >> + if (indirect_members.indexOf(spec.other_entity) > -1) { >> + return true; >> + } >> + } >> >> This construct: >> if (A) { >> if (B) { >> do_something(); >> } >> } >> >> Can be replaced with: >> if (A && B) { >> do_something(); >> } >> >> The second option is more readable, and avoids nested ifs. > > Changed: > - if (indirect_members) { > - if (indirect_members.indexOf(spec.other_entity) > -1) { > - return true; > - } > - } > - return false; > + var has_indirect = !!(indirect_members && > indirect_members.indexOf(spec.other_entity) > -1); > + return has_indirect; > > > Updated patch attached. > >> >> >> I have found no other issues, so ACK from me. >> >> -- >> Regards, >> >> Ana Krivokapic Pushed to master, ipa-3-2. -- Petr Vobornik From pvoborni at redhat.com Fri May 17 10:40:04 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 May 2013 12:40:04 +0200 Subject: [Freeipa-devel] [PATCH] 0026 Do not display success message on failure in web UI In-Reply-To: <5194EC82.2030407@redhat.com> References: <51891ADE.3070803@redhat.com> <5190FDE4.2080200@redhat.com> <5193AD20.1050001@redhat.com> <5194C0FC.40703@redhat.com> <5194EC82.2030407@redhat.com> Message-ID: <51960904.2060607@redhat.com> On 05/16/2013 04:26 PM, Ana Krivokapic wrote: > On 05/16/2013 01:20 PM, Petr Vobornik wrote: >> On 05/15/2013 05:43 PM, Ana Krivokapic wrote: >>> On 05/13/2013 04:51 PM, Petr Vobornik wrote: >>>> On 05/07/2013 05:16 PM, Ana Krivokapic wrote: >>>>> https://fedorahosted.org/freeipa/ticket/3591 >>>>> >>>> >>>> 1) The change from on_success to on_error is causing problems when >>>> some command in a batch doesn't fail. Ie.: disable multiple users on >>>> user search facet. Disabling already disabled user causes an error. >>>> The dialog is shown but the page is not refreshed so the newly >>>> disabled records are still displayed as enabled. We might even call >>>> this case a success. >>>> >>>> IMO we shouldn't change the method because the batch itself succeeded. >>>> The problem should be fixed on caller side (users of batch command). >>>> >>>> 2) Also `ajax` context should be left there instead of `this`, >>>> otherwise it would get the context of on_ok handler: >>>> >>>> 3) (not an actual issue) Some of my old code doesn't contain space >>>> between for/if and opening curly bracet, opposite to the rest of the >>>> Web UI. Spaces should be added when touching these parts of code. >>> >>> Since the problem occurs in the case when the batch succeeds, but some >>> commands from the batch fail, it should be enough to modify the message >>> that is displayed. I modified it so it shows exactly how many items from >>> the batch succeeded. >>> >>> Updated patch is attached. >>> >> >> It's a good direction. >> >> 1) Search trough the code revealed that there are also other cases: >> a) in association_facet:association.js:1031,1082 - add and delete when >> bulk_associator (default) is used (ie. in group/member_user). Make >> sure that it doesn't crash when serial associator is used (it doesn't >> use batch command). >> b) sudo rule delete option >> >> Can be reproduced by using two Web UIs and trying to do the same >> action in both instances. > Fixed in updated patch. I also slightly reworded strings in internal.py, > to avoid situations like "1 items were added". > >> >> 2) I wonder whether to not call notify_success when all commands in a >> batch fail. User should know what failed from the error dialog. But it >> is not sufficiently verbose in this matter, it should show how many >> commands succeeded and failed - >> https://fedorahosted.org/freeipa/ticket/1702 . Until then I'm hesitant >> to omit the notify_success call. On the other hand, it might be easier >> to do now. What do you think? >> > > I would not omit it - I think the displayed message is quite clear and > no longer misleading. It is an extra piece of information for the user > and could be useful in the case when all commands in a batch fail, as it > is not immediately clear from the error dialog that this is what > happened. I would leave it in for now, at least until we see what the > solution for #1702 will look like. > ACK and pushed to master, ipa-3-2. -- Petr Vobornik From pviktori at redhat.com Fri May 17 11:16:48 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 17 May 2013 13:16:48 +0200 Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <5195DF55.2080703@redhat.com> References: <1367511517.29881.12.camel@localhost.localdomain> <1367522674.29881.17.camel@localhost.localdomain> <1367530770.2976.126.camel@willson.li.ssimo.org> <1367558865.29881.35.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1368219349.2470.4.camel@localhost.localdomain> <1368539597.2470.9.camel@localhost.localdomain> <51927061.5040007@redhat.com> <5195DF55.2080703@redhat.com> Message-ID: <519611A0.7090402@redhat.com> On 05/17/2013 09:42 AM, Martin Kosek wrote: > On 05/14/2013 07:12 PM, Martin Kosek wrote: >> On 05/14/2013 03:53 PM, Nathaniel McCallum wrote: >>> On Fri, 2013-05-10 at 16:55 -0400, Nathaniel McCallum wrote: >>>> On Fri, 2013-05-03 at 09:08 -0400, Simo Sorce wrote: >>>>> On Thu, 2013-05-02 at 23:39 -0700, Nathan Kinder wrote: >>>>>> On 05/02/2013 10:27 PM, Nathaniel McCallum wrote: >>>>>>> All issues fixed unless noted below... The attached patches are tested >>>>>>> to work. >>>>>>> >>>>>>> On Thu, 2013-05-02 at 17:39 -0400, Simo Sorce wrote: >>>>>>> >>>>>>>> - (nit) slapi_ch_malloc/slapi_ch_strdup are not checked for failure >>>>>>>> (although I know slapi_ch_malloc() currently just aborts on failure, I >>>>>>>> think that is plain wrong which is why I would prefer using >>>>>>>> malloc/strdup, but well, I guess this is not something I am going to >>>>>>>> care too much about for now). >>>>>>> Not fixed. >>>>>>> >>>>>>>> - Is the logic with auth_type_used correct ? >>>>>>>> At least the name of the variable sounds misleading, because you set it >>>>>>>> only if the authentication was successful but not set if it was 'used' >>>>>>>> but was unsuccessful. Made me look at it multiple times to reconstuct >>>>>>>> the logic. The var name could be better, however I also want a comment >>>>>>>> that explain exactly how we are going to manage authentication and >>>>>>>> fallbacks here as that logic is critical and is useful for anyone that >>>>>>>> is going to have to change this code later in order not to break it. >>>>>>> The variable is now gone. I re-factored the section to make the logic >>>>>>> clearer and put a nice big comment up top. >>>>>>> >>>>>>>> - General question: how does this PRE_BIND plugin interact with >>>>>>>> ipapwd_pre_bind() in the ipa-pwd-extop() plugin ? >>>>>>>> Are you going to cause that plugin not to run by returning a result >>>>>>>> directly in this function ? >>>>>>>> Or is this plugin configured to run only after the previous one went >>>>>>>> through ? >>>>>>>> I ask because I do not see any ordering information in the cn=config >>>>>>>> plugin configuration so it is not immediately clear to me. >>>>>>> That is a good question for Nathan since he wrote this part of the >>>>>>> code... >>>>>> We would need to set the precedence if you want a predictable/guaranteed >>>>>> execution order. If a pre-BIND plug-in callback returns non-zero (which >>>>>> you should do when the plug-in sends the result to the client directly), >>>>>> it will cause other pre-bind plug-ins to not be called. This is >>>>>> actually how all pre-op plug-ins work. If a pre-op callback returns an >>>>>> error, we don't call the rest of the pre-op plug-ins in the list. >>>>> >>>>> Ok, but this does not answer my question. >>>>> We definitely need to *always* run our other preop plugin as we do >>>>> sanity checks like verifying if the user is enabled/disabled etc... >>>>> Also we need to understand how to deal with migrating password auth when >>>>> OTP is enabeld. >>>>> >>>>> TBH I think we should not have a separate OTP-auth plugin but we should >>>>> probably have a single plugin that handles authentication and the 2 >>>>> should be merged. Keeping them separate is going to cause more harm than >>>>> good with unexpected interactions. >>>>> >>>>> We could still have 2 plugins and simply move the prebind action >>>>> currently don in ipa-pwd-extop to the otp plugin by making some more >>>>> code common. But it is probably easier to just merge OTP into >>>>> ipa-pwd-extop right now than try to do a huge refactoring. We can always >>>>> refactor the ipa-pwd-extop plugin later. >>>> >>>> The attached patches encompass an initial review of the companion daemon >>>> and merge of ipa-otp into ipa-pwd-extop. Unfortunately, merging ipa-otp >>>> into ipa-pwd-extop appears to have broken something during install, but >>>> I don't have enough familiarity with 389 to understand what I've broken. >>>> If I upgrade after an install, it appears to work. >>>> >>>> An RPM with the patches is available here: >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5362935 >>>> >>>> Nathan / Rob / Simo, could you take a look and see what might be broken >>>> in ipa-pwd-extop? >>> >>> While I'm not quite sure what the problem was, I do know it appeared on >>> the stock 3.2 F19 RPMs. I also fixed it by accident. I am certain it is >>> unrelated to these patches. >>> >>> I have now tested install and upgrade with the six patches in the >>> previous email and everything is in order, including permissions. At >>> this point, we just need reviews/ACKs. >>> >>> Nathaniel >>> >> >> I tested IPA server upgrades, new installs and also adding 3.2+OTP replica for >> F18 3.1.4 IPA master. Everything seemed to work fine (when I added my patch 407 >> fixing the replication), I did not see any breakage. >> >> Issues I found with too much logging I reported should now be fixed on github, >> so this should be OK. >> >> So it is an ACK from my side if Rob does not discover some blocking issue. >> >> Martin > > We have all the acks now (some went off-list). Pushed to master, ipa-3-2. > > Thanks! > Martin > Just a note: With these patches, master no longer builds on Fedora 18. (no krb5-devel 1.11) -- Petr? From ssorce at redhat.com Fri May 17 12:23:48 2013 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 17 May 2013 08:23:48 -0400 (EDT) Subject: [Freeipa-devel] Final OTP Review In-Reply-To: <519611A0.7090402@redhat.com> References: <1367511517.29881.12.camel@localhost.localdomain> <51835B9A.30201@redhat.com> <1367586519.2976.165.camel@willson.li.ssimo.org> <1368219349.2470.4.camel@localhost.localdomain> <1368539597.2470.9.camel@localhost.localdomain> <51927061.5040007@redhat.com> <5195DF55.2080703@redhat.com> <519611A0.7090402@redhat.com> Message-ID: <1289993749.3416705.1368793428226.JavaMail.root@redhat.com> ----- Original Message ----- > > > > We have all the acks now (some went off-list). Pushed to master, ipa-3-2. > > > > Thanks! > > Martin > > > > Just a note: With these patches, master no longer builds on Fedora 18. > (no krb5-devel 1.11) If you want to still build on F18 you can simply do this: yum install --releasever=19 krb5-devel It will not drag in any large dependency set and will work just fine for clients as the ABI is compatible. However older FreeIPA Server builds will stop to work as the KDC driver needs a rebuild as the 1.11 vtable has changed slightly. Simo. -- Simo Sorce * Red Hat, Inc. * New York From pspacek at redhat.com Fri May 17 13:45:19 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 17 May 2013 15:45:19 +0200 Subject: [Freeipa-devel] [PATCH 0002] Add 'debug' statement to nsupdate commands generated by ipa-client-install In-Reply-To: <5194B6DB.2020907@redhat.com> References: <5193926F.7030601@redhat.com> <5194B6DB.2020907@redhat.com> Message-ID: <5196346F.8080008@redhat.com> On 16.5.2013 12:37, Ana Krivokapic wrote: > On 05/15/2013 03:49 PM, Petr Spacek wrote: >> Hello, >> >> This patch adds 'debug' and 'show' statements to nsupdate commands >> generated by ipa-client-install. >> >> https://fedorahosted.org/freeipa/ticket/3629 > > You probably want to add another 'show', before the last 'send' in the > `update_ssh_keys()` function. You are right. Corrected patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0002-2-Add-debug-statement-to-nsupdate-commands-generated-b.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: From akrivoka at redhat.com Fri May 17 13:58:21 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 17 May 2013 15:58:21 +0200 Subject: [Freeipa-devel] [PATCH 0002] Add 'debug' statement to nsupdate commands generated by ipa-client-install In-Reply-To: <5196346F.8080008@redhat.com> References: <5193926F.7030601@redhat.com> <5194B6DB.2020907@redhat.com> <5196346F.8080008@redhat.com> Message-ID: <5196377D.5080000@redhat.com> On 05/17/2013 03:45 PM, Petr Spacek wrote: > On 16.5.2013 12:37, Ana Krivokapic wrote: >> On 05/15/2013 03:49 PM, Petr Spacek wrote: >>> Hello, >>> >>> This patch adds 'debug' and 'show' statements to nsupdate commands >>> generated by ipa-client-install. >>> >>> https://fedorahosted.org/freeipa/ticket/3629 >> >> You probably want to add another 'show', before the last 'send' in the >> `update_ssh_keys()` function. > > You are right. Corrected patch is attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri May 17 14:11:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 17 May 2013 16:11:51 +0200 Subject: [Freeipa-devel] [PATCH] 0226 Relax getkeytab test to allow additional messages on stderr Message-ID: <51963AA7.1010206@redhat.com> Hello, The IPA test suite currently fails on f19 due to Camellia cipher that we don't enable by default. This makes the test ignore extra warnings on ipa-getkeytab's stderr. Note: I've skipped triage for this ticket because it's interfering with getting a CI server set up (#3621). -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0226-Relax-getkeytab-test-to-allow-additional-messages-on.patch Type: text/x-patch Size: 1177 bytes Desc: not available URL: From simo at redhat.com Mon May 20 12:07:34 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 20 May 2013 08:07:34 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <5193A598.4050805@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> Message-ID: <1369051654.6162.12.camel@willson.li.ssimo.org> On Wed, 2013-05-15 at 17:11 +0200, Petr Spacek wrote: > On 15.5.2013 10:29, Simo Sorce wrote: > >> I investigated various scenarios for DNSSEC integration and I would like to > >> hear your opinions about proposed approach and it's effects. > >> > >> > >> The most important finding is that bind-dyndb-ldap can't support DNSSEC > >> without rewrite of the 'in-memory database' component. > > > > Can you elaborate why a rewrite would be needed ? What constraint we do not meet ? > > We have three main problems - partially with data structures and mostly with > the way how we work with the 'internal database': > > 1) DNSSEC requires strict record ordering, i.e. each record in database has to > have predecessor and successor (ordering by name and then by record data). > This can be done relatively simply, but it requires a full dump of the database. > > 2) On-line record signing requires a lot of data stored > per-record+per-signature. This would require bigger effort than point 1), > because many data structures and respective APIs and locking protocols have to > be re-designed. > > 3) Our current 'internal database' acts as a 'cache', i.e. records can appear > and disappear dynamically and the 'cache' is not considered as authoritative > source of data: LDAP search is conducted each time when some data are not > found etc. The result is that the same data can disappear and then appear > again in the cache etc. > > Typical update scenario, with persistent search enabled: > a) DNS UPDATE from client is received by BIND > b) New data are written to LDAP > c) DN of modified object is received via persistent search > d) All RRs under the *updated name* are discarded from the cache > <-- now the cache is not consistent with data in LDAP > e) Object from LDAP is fetched by plugin > <-- a query for the updated name will enforce instant cache refresh, because > we know that the cache is not authoritative > f) All RRs in the object are updated (in cache) > > The problem is that the cache in intermediate states (between <-- marks) can't > be used as authoritative source and will produce incorrect signatures. The > text below contains more details. > > Database's in BIND has concept of 'versions' ('transactions') which our > internal cache do not implement ... It could be solved by proper locking, of > course, but it will not be a piece of cake. We need to take care of many > parallel updates, parallel queries and parallel re-signing at the same time. > > I don't say that it is impossible to implement our own backend with same > properties as BIND's database, but I don't see the value (and I can see a lot > of bugs :-). Well, we do not necessarily need all the same properties of bind's database, only those that allow us to properly handle DNSSEC, so let's try to uncover what those constrains are first, so I can understand why you propose this solution as better than something else. > >> Fortunately, it seems > >> that we can drop our own implementation of the internal DNS database > >> (ldap_driver.c and cache.c) and re-use the database from BIND (so called > >> RBTDB). > >> > >> I'm trying to reach Adam Tkac with the question "Why we decided to implement > >> it again rather than re-use BIND's code?". > >> > >> > >> Re-usage of BIND's implementation will have following properties: > >> > >> > >> == Advantages == > >> - Big part of DNSSEC implementation from BIND9 can be reused. > >> - Overall plugin implementation will be simpler - we can drop many lines of > >> our code and bugs. > >> - Run-time performance could be much much better. > >> > >> - We will get implementation for these tickets "for free": > >> -- #95 wildcard CNAME does NOT work > >> -- #64 IXFR support (IMHO this is important!) > >> -- #6 Cache non-existing records > >> > >> And partially: > >> -- #7 Allow limiting of the cache > > > > Sounds very interesting. > > > > > >> == Disadvantages == > >> - Support for configurations without persistent search will complicate things > >> a lot. > >> -- Proposal => Make persistent search obligatory. OpenLDAP supports LDAP > >> SyncRepl, so it should be possible to make plugin compatible with 389 and > >> OpenLDAP at the same time. I would defer this to somebody from users/OpenLDAP > >> community. > > > > Why the persistent search would be required ? > As I mentioned above - you need database dump, because DNSSEC requires strict > name and record ordering. > > It is possible to do incremental changes when the 'starting snapshot' is > established, but it means that we need information about each particular > change => that is what persistent search provides. Ok, so it is to have a complete view of the databse, I assume to reduce the number of re-computations needed for DNSSEC. > >> - Data from LDAP have to be dumped to memory (or to file) before the server > >> will start replying to queries. > >> => This is not nice, but servers usually are not restarted often. IMHO it is > >> a > >> good compromise between complexity and performance. > > > > I am not sure I understand what this means. Does it mean you cannot change single > > cache entries on the fly when a change happens in LDAP ? Or something else ? > Sorry, I didn't explained this part in it's full depth. > > You can change everything run-time, but there are small details which > complicates loading of the zone and run-time changes: > > 1) A normal zones requires SOA + NS + A/AAAA records (for NSs) to load. It is > (hypothetically) possible to create empty zone, fill it with SOA, NS and A > records and then incrementally add rest of the records. > > The problem is that you need to re-implement DNS resolution algorithm to find > which records you need at the beginning (SOA, NS, A/AAAA) and then load the rest. > > I would like to avoid this re-implementation. It is not possible to re-use > BIND's implementation because it is tied to the DB implementation ... but we > can't load the database because it is missing SOA, NS and A/AAAA records. > Chicken-egg problem. To be honest I am not sure I understand what's your point here. > 2) The second reason why I want to make persistent search obligatory is that > each change in DNSSEC signed zone requires a lot of work, so it is not a good > idea to wait with the work to time when somebody asks for particular record. > > How it works without persistent search (now): > 1) Query from a client is received by BIND > 2) Internal cache is consulted > 3) Record is not found in the cache - LDAP search is done > 4) Fetched records in saved to the cache > 5) Reply to client is constructed > > It is hard to work in the same way when DNSSEC is in place. Each change > implicates re-signing of the particular RRset and it's neighbours, i.e.: > 1) Query from a client is received by BIND > 2) Internal cache is consulted > 3) Record is not found in the cache - LDAP search is done > 4) Fetched records in saved to the cache > * 4b) New RRset is re-signed > * 4c) Records neighbouring with the new RR has to be updated and re-signed > 5) Reply to client is constructed Ok so the point here is that we want to do the signing at store time rather than read time. That is understandable. However we have 2 ways to look at it. 1. bind does the work 2. DS does the work I haven't seen any reasoning from you why letting Bind do this work is a better idea. I actually see some security reasons why putting this into a DS plugin can have quite some advantages instead. Have you considered doing this work in a DS plugin at all ? If you haven and have discarded the idea, can you say why ? > The point is that you *can* do changes run-time, but you need to know about > the changes as soon as possible because each change requires significant > amount of work (and magic/mana :-). > > It opens a lot of opportunities for race condition problems. Yes, I am really concerned about the race conditions of course, however I really wonder whether doing signing in bind is really a good idea. We need to synchronize these signatures to all masters right ? Doesn't that mean we need to store this data back in LDAP ? That means more round-trips before the data ends up being usable, and we do not have transactions in LDAP, so I am worried that doing the signing in Bind may not be the best way to go. > >> => It should be possible to save old database to disk (during BIND shutdown > >> or > >> periodically) and re-use this old database during server startup. I.e. server > >> will start replying immediately from 'old' database and then the server will > >> switch to the new database when dump from LDAP is finished. > > > > > > This look like an advantage ? Why is it a disadvantage ? > It was mentioned as 'proposed remedy' for the disadvantage above. I think having dual authoritative data sources may not be a good thing. > >> => As a side effect, BIND can start even if connection to LDAP server is down > >> - this can improve infrastructure resiliency a lot! > > > > Same as above ? > The same here, it was mentioned as 'proposed remedy' for the disadvantage above. When it comes to DNSSEC starting w/o LDAP may just mean that you have different signatures for the same records on different masters. Is that 'legale' according to DNSSEC ? > >> == Uncertain effects == > >> - Memory consumption will change, but I'm not sure in which direction. > >> - SOA serial number maintenance is a open question. > > > > Why SOA serial is a problem ? > It simply needs more investigation. BIND's RBTDB maintains SOA serial > internally (it is intertwined to transactions in the DB), so the write-back to > LDAP could be very delicate operation. It means all masters will often be out of sync, this is not very good. > >> Decision if persistent search is a 'requirement' or not will have significant > >> impact on the design, so I will write the design document when this decision > >> is made. > > > > I would like to know more details about the reasons before I can usefully comment. > > I forgot to one another 'Uncertain effect': > - Support for dynamically generated '_location' records will be a big > adventure. It probably means no change from the state without persistent > search :-) After basic exploration it seems doable, but still a bit uncertain. I need more info here, does it mean you have to store _location records when they are generated ? Maybe we can use the internal bind database just for _location "zone" ? > My personal conclusion is that re-using of BIND's backend will save a huge > amount of work/code to maintain/bugs. I can see that, unfortunately I fear it will make multi-master a lot more difficult at the same time. And given we do want to have multi-master properties we need to analyze that problem more carefully. Also by welding ourselves to internal Bind infrastructure too much, it will make it a lot more difficult for us to change the DNS infrastructure. Bind10 will be completely different internally, and we may simply decide to even not use bind10 at all and use a completely different engine going forward. So I am quite wary of welding ourselves even more to bind 9 internals. Simo. -- Simo Sorce * Red Hat, Inc * New York From tjaalton at ubuntu.com Mon May 20 13:09:04 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 20 May 2013 16:09:04 +0300 Subject: [Freeipa-devel] installation freeipa on centos and ubuntu 13 In-Reply-To: <51948C0E.9000106@redhat.com> References: <51948C0E.9000106@redhat.com> Message-ID: <519A2070.10202@ubuntu.com> On 16.05.2013 10:34, Martin Kosek wrote: > On 05/16/2013 07:50 AM, daiEric wrote: >> hi? all >> where I can find the document about the installation freeipa on centos 6.3 and >> Ubuntu 13.04 >> >> thanks and best regards >> Eric dai >> > > Hello Eric, > > I do not know about CentOS, but you can find RHEL guide for FreeIPA here: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > > As for Ubuntu, I do not think that FreeIPA is packaged there yet. There were > some actions in the past to make that happen but it has not finished yet. If > you just want to try FreeIPA, I would recommend using Fedora 18. freeipa-client is available, 13.04 has 3.1.2. It should work without too much fuss, and if not then file a bug on launchpad, or poke me on #ubuntu-freeipa (@freenode). -- t From tbabej at redhat.com Mon May 20 13:42:55 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 May 2013 15:42:55 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <5194A405.50804@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> Message-ID: <519A285F.7080006@redhat.com> On 05/16/2013 11:16 AM, Ana Krivokapic wrote: > On 05/15/2013 03:41 PM, Tomas Babej wrote: >> Hi, >> >> When removing an ID range using idrange-del command, validation >> in pre_callback ensures that the range does not belong to any >> active trust. In such case, ValidationError is raised. >> >> https://fedorahosted.org/freeipa/ticket/3615 >> >> Tomas >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I suggest adding some unit tests to cover this change in functionality. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I incorporated the unit tests. It had to use direct access to LDAP using ldapmodify since we need to create a mock AD trusted range first. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0057-2-Do-not-allow-removal-of-ID-range-of-an-active-trust.patch Type: text/x-patch Size: 7454 bytes Desc: not available URL: From abokovoy at redhat.com Mon May 20 14:29:41 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 May 2013 17:29:41 +0300 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <519A285F.7080006@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> Message-ID: <20130520142940.GR26689@redhat.com> On Mon, 20 May 2013, Tomas Babej wrote: >On 05/16/2013 11:16 AM, Ana Krivokapic wrote: >>On 05/15/2013 03:41 PM, Tomas Babej wrote: >>>Hi, >>> >>>When removing an ID range using idrange-del command, validation >>>in pre_callback ensures that the range does not belong to any >>>active trust. In such case, ValidationError is raised. >>> >>>https://fedorahosted.org/freeipa/ticket/3615 >>> >>>Tomas >>> >>> >>>_______________________________________________ >>>Freeipa-devel mailing list >>>Freeipa-devel at redhat.com >>>https://www.redhat.com/mailman/listinfo/freeipa-devel >> >>I suggest adding some unit tests to cover this change in functionality. >> >>-- >>Regards, >> >>Ana Krivokapic >>Associate Software Engineer >>FreeIPA team >>Red Hat Inc. >> >> >>_______________________________________________ >>Freeipa-devel mailing list >>Freeipa-devel at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-devel > >I incorporated the unit tests. It had to use direct access to LDAP >using ldapmodify since we need to create a mock AD trusted range >first. > >Tomas >From 57e98d6dc950d611e96e1ec2e264649a3d682c83 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 15 May 2013 15:37:15 +0200 >Subject: [PATCH] Do not allow removal of ID range of an active trust > >When removing an ID range using idrange-del command, validation >in pre_callback ensures that the range does not belong to any >active trust. In such case, ValidationError is raised. > >Unit tests to cover the functionality has been added. > >https://fedorahosted.org/freeipa/ticket/3615 >--- > ipalib/plugins/idrange.py | 17 ++++++- > tests/test_xmlrpc/test_range_plugin.py | 86 ++++++++++++++++++++++++++++++---- > tests/test_xmlrpc/xmlrpc_test.py | 5 ++ > 3 files changed, 97 insertions(+), 11 deletions(-) > >diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >index 54f6fbb3e19b9aa01dfde2a8d0c5da4498632386..a0309f82cc14117212c355547dac25b8c4e0f1e3 100644 >--- a/ipalib/plugins/idrange.py >+++ b/ipalib/plugins/idrange.py >@@ -434,14 +434,29 @@ class idrange_del(LDAPDelete): > > def pre_callback(self, ldap, dn, *keys, **options): > try: >- (old_dn, old_attrs) = ldap.get_entry(dn, ['ipabaseid', 'ipaidrangesize']) >+ (old_dn, old_attrs) = ldap.get_entry(dn, ['ipabaseid', >+ 'ipaidrangesize', >+ 'ipanttrusteddomainsid']) > except errors.NotFound: > self.obj.handle_not_found(*keys) > >+ # Check whether we leave any object with id in deleted range > old_base_id = int(old_attrs.get('ipabaseid', [0])[0]) > old_range_size = int(old_attrs.get('ipaidrangesize', [0])[0]) > self.obj.check_ids_in_modified_range( > old_base_id, old_range_size, 0, 0) >+ >+ # Check whether the range does not belong to the active trust >+ range_sid = old_attrs.get('ipanttrusteddomainsid') >+ >+ if range_sid is not None: >+ range_sid = range_sid[0] >+ result = api.Command['trust_find'](ipanttrusteddomainsid=range_sid) >+ >+ if result['count'] > 0: >+ raise errors.ValidationError(name='ID Range constraint', >+ error=_("ID range of an active trust cannot be deleted.")) >+ > return dn > > class idrange_find(LDAPSearch): >diff --git a/tests/test_xmlrpc/test_range_plugin.py b/tests/test_xmlrpc/test_range_plugin.py >index be8eac593a04c52aaaff61f980cfd5fd0899fabd..1f03d3fc570dbe978fd31569896857db9a972bfa 100644 >--- a/tests/test_xmlrpc/test_range_plugin.py >+++ b/tests/test_xmlrpc/test_range_plugin.py >@@ -22,6 +22,7 @@ Test the `ipalib/plugins/idrange.py` module, and XML-RPC in general. > """ > > from ipalib import api, errors, _ >+from ipapython.ipautil import run > from tests.util import assert_equal, Fuzzy > from xmlrpc_test import Declarative, fuzzy_digits, fuzzy_uuid > from tests.test_xmlrpc import objectclasses >@@ -31,57 +32,113 @@ testrange1 = u'testrange1' > testrange1_base_id = 900000 > testrange1_size = 99999 > testrange1_base_rid = 10000 >-testrange1_secondary_base_rid=200000 >+testrange1_secondary_base_rid = 200000 > > testrange2 = u'testrange2' > testrange2_base_id = 100 > testrange2_size = 50 > testrange2_base_rid = 100 >-testrange2_secondary_base_rid=1000 >+testrange2_secondary_base_rid = 1000 > > testrange3 = u'testrange3' > testrange3_base_id = 200 > testrange3_size = 50 > testrange3_base_rid = 70 >-testrange3_secondary_base_rid=1100 >+testrange3_secondary_base_rid = 1100 > > testrange4 = u'testrange4' > testrange4_base_id = 300 > testrange4_size = 50 > testrange4_base_rid = 200 >-testrange4_secondary_base_rid=1030 >+testrange4_secondary_base_rid = 1030 > > testrange5 = u'testrange5' > testrange5_base_id = 400 > testrange5_size = 50 > testrange5_base_rid = 1020 >-testrange5_secondary_base_rid=1200 >+testrange5_secondary_base_rid = 1200 > > testrange6 = u'testrange6' > testrange6_base_id = 130 > testrange6_size = 50 > testrange6_base_rid = 500 >-testrange6_secondary_base_rid=1300 >+testrange6_secondary_base_rid = 1300 > > testrange7 = u'testrange7' > testrange7_base_id = 600 > testrange7_size = 50 > testrange7_base_rid = 600 >-testrange7_secondary_base_rid=649 >+testrange7_secondary_base_rid = 649 > > testrange8 = u'testrange8' > testrange8_base_id = 700 > testrange8_size = 50 > testrange8_base_rid = 700 > >-user1=u'tuser1' >+testrange9 = u'testrange9' >+testrange9_base_id = 800 >+testrange9_size = 50 >+testrange9_base_rid = 800 >+ >+testrange9_add = """ >+version: 1 >+DN: cn={name},cn=ranges,cn=etc,{basedn} >+changetype: add >+cn: {name} >+objectClass: ipaIDrange >+objectClass: ipatrustedaddomainrange >+ipaBaseID: {base_id} >+ipaIDRangeSize: {size} >+ipaBaseRID: {base_rid} >+ipaNTTrustedDomainSID: S-1-5-21-259319770-2312917334-591429603 >+""".format(basedn=api.env['basedn'], >+ name=testrange9, >+ base_id=testrange9_base_id, >+ size=testrange9_size, >+ base_rid=testrange9_base_rid) >+ >+testrange9_del = """ >+version: 1 >+DN: cn={name},cn=ranges,cn=etc,{basedn} >+changetype: delete >+""".format(basedn=api.env['basedn'], name=testrange9) >+ >+user1 = u'tuser1' > user1_uid = 900000 >-group1=u'group1' >+group1 = u'group1' > group1_gid = 900100 > >+trusted_ad_range_ok = False >+ > class test_range(Declarative): >+ >+ def setUp(self): >+ super(test_range, self).setUp() >+ >+ ret = run(['ldapmodify', >+ '-Y', 'GSSAPI', >+ '-h', api.env['host']], >+ stdin=str(testrange9_add), raiseonerr=False) well, you can use python's ldap module directly, there is no need to call out to ldap utilities. -- / Alexander Bokovoy From pspacek at redhat.com Tue May 21 16:32:21 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 21 May 2013 18:32:21 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <1369051654.6162.12.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> Message-ID: <519BA195.9050504@redhat.com> Hello, I found that we (probably) misunderstood each other. The sky-high level overview of the proposal follow: NO CHANGE: 1) LDAP stores all *unsigned* data. 2) NO CHANGE: a) bind-dyndb-ldap *on each server* fetches all unsigned data from LDAP and store them in *in memory* database (we do it now) THE DIFFERENCE: b) All data will be stored in BIND's native RBT-database (RBTDB) instead of our own in-memory database. NEW PIECES: 3) Mechanisms implemented in BIND's RBTDB will do DNSSEC signing etc. for us. The BIND's feature is called 'in-line signing' and it can do all key/signature maintenance for us, including periodical zone re-signing etc. The whole point of this proposal is about code-reusage. I'm trying to avoid re-inventing of the wheel. Note that DNSSEC implementation in BIND has ~ 150 kiB of C code, stand-alone signing utilities add another ~ 200 kiB of code (~ 7000 lines) . I really don't want to re-write it again when it's not reasonable. Further comments are in-line. On 20.5.2013 14:07, Simo Sorce wrote: > On Wed, 2013-05-15 at 17:11 +0200, Petr Spacek wrote: >> On 15.5.2013 10:29, Simo Sorce wrote: >>>> I investigated various scenarios for DNSSEC integration and I would like to >>>> hear your opinions about proposed approach and it's effects. >>>> >>>> >>>> The most important finding is that bind-dyndb-ldap can't support DNSSEC >>>> without rewrite of the 'in-memory database' component. >>> >>> Can you elaborate why a rewrite would be needed ? What constraint we do not meet ? >> >> We have three main problems - partially with data structures and mostly with >> the way how we work with the 'internal database': >> >> 1) DNSSEC requires strict record ordering, i.e. each record in database has to >> have predecessor and successor (ordering by name and then by record data). >> This can be done relatively simply, but it requires a full dump of the database. >> >> 2) On-line record signing requires a lot of data stored >> per-record+per-signature. This would require bigger effort than point 1), >> because many data structures and respective APIs and locking protocols have to >> be re-designed. >> >> 3) Our current 'internal database' acts as a 'cache', i.e. records can appear >> and disappear dynamically and the 'cache' is not considered as authoritative >> source of data: LDAP search is conducted each time when some data are not >> found etc. The result is that the same data can disappear and then appear >> again in the cache etc. >> >> Typical update scenario, with persistent search enabled: >> a) DNS UPDATE from client is received by BIND >> b) New data are written to LDAP >> c) DN of modified object is received via persistent search >> d) All RRs under the *updated name* are discarded from the cache >> <-- now the cache is not consistent with data in LDAP >> e) Object from LDAP is fetched by plugin >> <-- a query for the updated name will enforce instant cache refresh, because >> we know that the cache is not authoritative >> f) All RRs in the object are updated (in cache) >> >> The problem is that the cache in intermediate states (between <-- marks) can't >> be used as authoritative source and will produce incorrect signatures. The >> text below contains more details. >> >> Database's in BIND has concept of 'versions' ('transactions') which our >> internal cache do not implement ... It could be solved by proper locking, of >> course, but it will not be a piece of cake. We need to take care of many >> parallel updates, parallel queries and parallel re-signing at the same time. >> >> I don't say that it is impossible to implement our own backend with same >> properties as BIND's database, but I don't see the value (and I can see a lot >> of bugs :-). > > Well, we do not necessarily need all the same properties of bind's > database, only those that allow us to properly handle DNSSEC, so let's > try to uncover what those constrains are first, so I can understand why > you propose this solution as better than something else. > >>>> Fortunately, it seems >>>> that we can drop our own implementation of the internal DNS database >>>> (ldap_driver.c and cache.c) and re-use the database from BIND (so called >>>> RBTDB). >>>> >>>> I'm trying to reach Adam Tkac with the question "Why we decided to implement >>>> it again rather than re-use BIND's code?". >>>> >>>> >>>> Re-usage of BIND's implementation will have following properties: >>>> >>>> >>>> == Advantages == >>>> - Big part of DNSSEC implementation from BIND9 can be reused. >>>> - Overall plugin implementation will be simpler - we can drop many lines of >>>> our code and bugs. >>>> - Run-time performance could be much much better. >>>> >>>> - We will get implementation for these tickets "for free": >>>> -- #95 wildcard CNAME does NOT work >>>> -- #64 IXFR support (IMHO this is important!) >>>> -- #6 Cache non-existing records >>>> >>>> And partially: >>>> -- #7 Allow limiting of the cache >>> >>> Sounds very interesting. >>> >>> >>>> == Disadvantages == >>>> - Support for configurations without persistent search will complicate things >>>> a lot. >>>> -- Proposal => Make persistent search obligatory. OpenLDAP supports LDAP >>>> SyncRepl, so it should be possible to make plugin compatible with 389 and >>>> OpenLDAP at the same time. I would defer this to somebody from users/OpenLDAP >>>> community. >>> >>> Why the persistent search would be required ? >> As I mentioned above - you need database dump, because DNSSEC requires strict >> name and record ordering. >> >> It is possible to do incremental changes when the 'starting snapshot' is >> established, but it means that we need information about each particular >> change => that is what persistent search provides. > > Ok, so it is to have a complete view of the databse, I assume to reduce > the number of re-computations needed for DNSSEC. I think it's inevitable, because you *need* the strict resource record ordering (see point 1 above) for the NSEC/NSEC3 record generation [1] - i.e. from the very beginning. Partial re-signing is inevitable after each change, but you can't start the signing process without the strict resource record ordering. [1] http://tools.ietf.org/html/rfc4034#section-6 >>>> - Data from LDAP have to be dumped to memory (or to file) before the server >>>> will start replying to queries. >>>> => This is not nice, but servers usually are not restarted often. IMHO it is >>>> a >>>> good compromise between complexity and performance. >>> >>> I am not sure I understand what this means. Does it mean you cannot change single >>> cache entries on the fly when a change happens in LDAP ? Or something else ? >> Sorry, I didn't explained this part in it's full depth. >> >> You can change everything run-time, but there are small details which >> complicates loading of the zone and run-time changes: >> >> 1) A normal zones requires SOA + NS + A/AAAA records (for NSs) to load. It is >> (hypothetically) possible to create empty zone, fill it with SOA, NS and A >> records and then incrementally add rest of the records. >> >> The problem is that you need to re-implement DNS resolution algorithm to find >> which records you need at the beginning (SOA, NS, A/AAAA) and then load the rest. >> >> I would like to avoid this re-implementation. It is not possible to re-use >> BIND's implementation because it is tied to the DB implementation ... but we >> can't load the database because it is missing SOA, NS and A/AAAA records. >> Chicken-egg problem. > > To be honest I am not sure I understand what's your point here. I'm not sure how to explain it without describing implementation in BIND. It is implementation detail, we can discuss it when we agree on all other things. >> 2) The second reason why I want to make persistent search obligatory is that >> each change in DNSSEC signed zone requires a lot of work, so it is not a good >> idea to wait with the work to time when somebody asks for particular record. >> >> How it works without persistent search (now): >> 1) Query from a client is received by BIND >> 2) Internal cache is consulted >> 3) Record is not found in the cache - LDAP search is done >> 4) Fetched records in saved to the cache >> 5) Reply to client is constructed >> >> It is hard to work in the same way when DNSSEC is in place. Each change >> implicates re-signing of the particular RRset and it's neighbours, i.e.: >> 1) Query from a client is received by BIND >> 2) Internal cache is consulted >> 3) Record is not found in the cache - LDAP search is done >> 4) Fetched records in saved to the cache >> * 4b) New RRset is re-signed >> * 4c) Records neighbouring with the new RR has to be updated and re-signed >> 5) Reply to client is constructed > > Ok so the point here is that we want to do the signing at store time > rather than read time. That is understandable. > However we have 2 ways to look at it. > 1. bind does the work > 2. DS does the work > > I haven't seen any reasoning from you why letting Bind do this work is > a better idea. Simply said - because all the code is already in BIND (the feature is called 'in-line signing', as I mentioned above). > I actually see some security reasons why putting this into a DS plugin > can have quite some advantages instead. Have you considered doing this It could improve the security a bit, I agree. But I don't think that it is so big advantage. BIND already has all the facilities for key material handling, so the only thing we have to solve is how to distribute keys from LDAP to running BIND. > work in a DS plugin at all ? If you haven and have discarded the idea, > can you say why ? 1) It would require pulling ~ 200 kiB (~ 7000 lines) of DNSSEC signing code into 389. 2) It would require pulling 'text->DNS wire format' parser into 389 (because our LDAP stores plain text data but the signing process works with DNS wire format). 3) It simplifies bind-dyndb-ldap, but we still need to re-implement DNS search algorithm which takes DNSSEC oddities into account. (Note that the DNS search algorithm is part of the database implementation. Bugs/limitations in our implementation are the reason why wildard records are not supported...) 4) I'm not sure how it will work with replication. How to ensure that new record will not appear in the zone until the associated RRset is (re)computed by DS? (BIND has transaction mechanism built-in to the internal RBTDB.) >> The point is that you *can* do changes run-time, but you need to know about >> the changes as soon as possible because each change requires significant >> amount of work (and magic/mana :-). >> >> It opens a lot of opportunities for race condition problems. > > Yes, I am really concerned about the race conditions of course, however > I really wonder whether doing signing in bind is really a good idea. > We need to synchronize these signatures to all masters right ? No, because signatures are computed and stored only in memory - and forgotten after BIND shutdown. Yes, it requires re-computing on each load, this is definitely disadvantage. > Doesn't that mean we need to store this data back in LDAP ? No, only 'normal' DNS updates containing unsigned data will be written back to LDAP. RRSIG and NSEC records will never reach LDAP. > That means more round-trips before the data ends up being usable, and we > do not have transactions in LDAP, so I am worried that doing the signing > in Bind may not be the best way to go. I'm proposing to re-use BIND's transaction mechanism built in internal database implementation. >>>> => It should be possible to save old database to disk (during BIND shutdown >>>> or >>>> periodically) and re-use this old database during server startup. I.e. server >>>> will start replying immediately from 'old' database and then the server will >>>> switch to the new database when dump from LDAP is finished. >>> >>> >>> This look like an advantage ? Why is it a disadvantage ? >> It was mentioned as 'proposed remedy' for the disadvantage above. > > I think having dual authoritative data sources may not be a good thing. Consistency is a reason why I want to make persistent search mandatory. IMHO persistent storage could save the day if LDAP is down for some reason. Old data in DNS are much better than no data in DNS. >>>> => As a side effect, BIND can start even if connection to LDAP server is down >>>> - this can improve infrastructure resiliency a lot! >>> >>> Same as above ? >> The same here, it was mentioned as 'proposed remedy' for the disadvantage above. > > When it comes to DNSSEC starting w/o LDAP may just mean that you have > different signatures for the same records on different masters. Is that > 'legale' according to DNSSEC ? 1) You will have same signatures as long as records in LDAP and saved copy of the database (on the disk) are equal. 2) I didn't find any new limitation imposed by DNSSEC. AFAIK some inconsistency between servers is normal state in DNS, because zone transfers take some time and the tree structure have many levels. The problems arise when data *in single database* (i.e. on one server) are inconsistent (e.g. signature != data in unsigned records). BIND solves this with it's built-in transaction mechanisms. >>>> == Uncertain effects == >>>> - Memory consumption will change, but I'm not sure in which direction. >>>> - SOA serial number maintenance is a open question. >>> >>> Why SOA serial is a problem ? >> It simply needs more investigation. BIND's RBTDB maintains SOA serial >> internally (it is intertwined to transactions in the DB), so the write-back to >> LDAP could be very delicate operation. > > It means all masters will often be out of sync, this is not very good. I don't think so. BIND can use timestamp-based serials in exactly same way as we do. The only problem is how to implement 'read from internal DB'->'write to LDAP' operation. It still needs more investigation. >>>> Decision if persistent search is a 'requirement' or not will have significant >>>> impact on the design, so I will write the design document when this decision >>>> is made. >>> >>> I would like to know more details about the reasons before I can usefully comment. >> >> I forgot to one another 'Uncertain effect': >> - Support for dynamically generated '_location' records will be a big >> adventure. It probably means no change from the state without persistent >> search :-) After basic exploration it seems doable, but still a bit uncertain. > > I need more info here, does it mean you have to store _location records > when they are generated ? I tend to do _location record generation during zone-load, so everything will be prepared when the query comes in. As a benefit it will allow zone transfers even for signed zones. This still needs more investigation. > Maybe we can use the internal bind database > just for _location "zone" ? I don't think that it is possible. If _location.client-a and _location.client-b reside in the single database then client-a and client-b have to reside in the same database. (The reason is that _location.client-a and _location.client-b do not have immediate common ancestor.) >> My personal conclusion is that re-using of BIND's backend will save a huge >> amount of work/code to maintain/bugs. > > I can see that, unfortunately I fear it will make multi-master a lot > more difficult at the same time. And given we do want to have > multi-master properties we need to analyze that problem more carefully. I agree. It is a delicate change and we should not hurry. > Also by welding ourselves to internal Bind infrastructure too much, it > will make it a lot more difficult for us to change the DNS > infrastructure. Bind10 will be completely different internally, and we > may simply decide to even not use bind10 at all and use a completely > different engine going forward. So I am quite wary of welding ourselves > even more to bind 9 internals. Ehm ... how to say that ... 'to late'. I wasn't around when DNS design was made, so I don't know all the reasons behind the decision, but IMHO we use completely non-standard/obscure hacks all the time. The proposal above doesn't extend our dependency on BIND, because we already depend on BIND9 *completely*. It is about dropping our own internal database implementation (buggy, incomplete, standard non-compliant) with the code from the original BIND (which is at least standard compliant). Do you want to go back to 'light side of the force'? So we should start with designing some LDAP->nsupdate gateway and use that for zone maintenance. It doesn't solve adding/reconfiguring of zones on run-time, but it could be handled by some stand-alone daemon with an abstraction layer at proper place. -- Petr^2 Spacek From simo at redhat.com Tue May 21 18:30:23 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 21 May 2013 14:30:23 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <519BA195.9050504@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> Message-ID: <1369161023.23339.20.camel@willson.li.ssimo.org> On Tue, 2013-05-21 at 18:32 +0200, Petr Spacek wrote: > Hello, > > I found that we (probably) misunderstood each other. The sky-high level > overview of the proposal follow: > > NO CHANGE: > 1) LDAP stores all *unsigned* data. > > 2) > NO CHANGE: > a) bind-dyndb-ldap *on each server* fetches all unsigned data from LDAP and > store them in *in memory* database (we do it now) > > THE DIFFERENCE: > b) All data will be stored in BIND's native RBT-database (RBTDB) instead of > our own in-memory database. > > NEW PIECES: > 3) > Mechanisms implemented in BIND's RBTDB will do DNSSEC signing etc. for us. The > BIND's feature is called 'in-line signing' and it can do all key/signature > maintenance for us, including periodical zone re-signing etc. > > > The whole point of this proposal is about code-reusage. I'm trying to avoid > re-inventing of the wheel. > > Note that DNSSEC implementation in BIND has ~ 150 kiB of C code, stand-alone > signing utilities add another ~ 200 kiB of code (~ 7000 lines) . I really > don't want to re-write it again when it's not reasonable. > > Further comments are in-line. Ok putting some numbers on this topic really helps, thanks! More inline. [..] > > I haven't seen any reasoning from you why letting Bind do this work is > > a better idea. > Simply said - because all the code is already in BIND (the feature is called > 'in-line signing', as I mentioned above). > > > I actually see some security reasons why putting this into a DS plugin > > can have quite some advantages instead. Have you considered doing this > It could improve the security a bit, I agree. But I don't think that it is so > big advantage. BIND already has all the facilities for key material handling, > so the only thing we have to solve is how to distribute keys from LDAP to > running BIND. Well it would mean sticking the key in ldap and letting Bind pull them from there based on ACIs ... The main issue would be changes in keys, but with the persistent search I guess that's also not a huge deal. > > work in a DS plugin at all ? If you haven and have discarded the idea, > > can you say why ? > 1) It would require pulling ~ 200 kiB (~ 7000 lines) of DNSSEC signing code > into 389. > > 2) It would require pulling 'text->DNS wire format' parser into 389 (because > our LDAP stores plain text data but the signing process works with DNS wire > format). > > 3) It simplifies bind-dyndb-ldap, but we still need to re-implement DNS search > algorithm which takes DNSSEC oddities into account. (Note that the DNS search > algorithm is part of the database implementation. Bugs/limitations in our > implementation are the reason why wildard records are not supported...) > > 4) I'm not sure how it will work with replication. How to ensure that new > record will not appear in the zone until the associated RRset is (re)computed > by DS? (BIND has transaction mechanism built-in to the internal RBTDB.) 389ds has internal transactions, which is why I was thinking to do the signatures on any change coming into LDAP (direct or via replication, within the transaction. > >> The point is that you *can* do changes run-time, but you need to know about > >> the changes as soon as possible because each change requires significant > >> amount of work (and magic/mana :-). > >> > >> It opens a lot of opportunities for race condition problems. > > > > Yes, I am really concerned about the race conditions of course, however > > I really wonder whether doing signing in bind is really a good idea. > > We need to synchronize these signatures to all masters right ? > No, because signatures are computed and stored only in memory - and forgotten > after BIND shutdown. Yes, it requires re-computing on each load, this is > definitely disadvantage. Ok I definitely need numbers here. Can you do a test with a normal, text based, Bind zone with 10k entries and see how much time it takes to re-sign everything ? I suspect that will be way too much, so we will have the added problem of having to maintain a local cache in order to be able to restart Bind and have it actually server results in a reasonable time w/o killing the machine completely. > > Doesn't that mean we need to store this data back in LDAP ? > No, only 'normal' DNS updates containing unsigned data will be written back to > LDAP. RRSIG and NSEC records will never reach LDAP. > > > That means more round-trips before the data ends up being usable, and we > > do not have transactions in LDAP, so I am worried that doing the signing > > in Bind may not be the best way to go. > I'm proposing to re-use BIND's transaction mechanism built in internal > database implementation. > > >>>> => It should be possible to save old database to disk (during BIND shutdown > >>>> or > >>>> periodically) and re-use this old database during server startup. I.e. server > >>>> will start replying immediately from 'old' database and then the server will > >>>> switch to the new database when dump from LDAP is finished. > >>> > >>> > >>> This look like an advantage ? Why is it a disadvantage ? > >> It was mentioned as 'proposed remedy' for the disadvantage above. > > > > I think having dual authoritative data sources may not be a good thing. > Consistency is a reason why I want to make persistent search mandatory. A persistent search does not guarantee consistency only that updates are sent to you as soon as they come in, you still may end up with bugs in the implementation where you do not catch something and get out of date, with the actual data in LDAP. > IMHO persistent storage could save the day if LDAP is down for some reason. > Old data in DNS are much better than no data in DNS. Depends how OLD :-) But maybe we can bake some timeouts in there and simply dump any cached data if it really is too old. > >>>> => As a side effect, BIND can start even if connection to LDAP server is down > >>>> - this can improve infrastructure resiliency a lot! > >>> > >>> Same as above ? > >> The same here, it was mentioned as 'proposed remedy' for the disadvantage above. > > > > When it comes to DNSSEC starting w/o LDAP may just mean that you have > > different signatures for the same records on different masters. Is that > > 'legale' according to DNSSEC ? > 1) You will have same signatures as long as records in LDAP and saved copy of > the database (on the disk) are equal. Well given an IPA infrastructure uses Dynamic Updates I expect data to change frequently enough that if you have an outage that lasts more than a handful of minutes the data in the saved copy will not match the data in LDAP. > 2) I didn't find any new limitation imposed by DNSSEC. AFAIK some > inconsistency between servers is normal state in DNS, because zone transfers > take some time and the tree structure have many levels. But in the bind case they assume a single master model, so they never have inconsistencies, right ? But in our case we have multiple masters, so I wonder if a client is going to have issues ... Are we guaranteed that if 2 servers have the exact same view they generate the exact same signatures ? If that is the case then maybe we are ok. > The problems arise when data *in single database* (i.e. on one server) are > inconsistent (e.g. signature != data in unsigned records). BIND solves this > with it's built-in transaction mechanisms. Understood. > >>>> == Uncertain effects == > >>>> - Memory consumption will change, but I'm not sure in which direction. > >>>> - SOA serial number maintenance is a open question. > >>> > >>> Why SOA serial is a problem ? > >> It simply needs more investigation. BIND's RBTDB maintains SOA serial > >> internally (it is intertwined to transactions in the DB), so the write-back to > >> LDAP could be very delicate operation. > > > > It means all masters will often be out of sync, this is not very good. > I don't think so. BIND can use timestamp-based serials in exactly same way as > we do. The only problem is how to implement 'read from internal DB'->'write to > LDAP' operation. It still needs more investigation. Well if we use timestamp based serials ... why do we need to write anything back ? :-) We can just let a DS plugin fill the serial in the SOA with a timestamp just for schema compatibility purposes and just assume bind has the same or a close enough serial internally. > >>>> Decision if persistent search is a 'requirement' or not will have significant > >>>> impact on the design, so I will write the design document when this decision > >>>> is made. > >>> > >>> I would like to know more details about the reasons before I can usefully comment. > >> > >> I forgot to one another 'Uncertain effect': > >> - Support for dynamically generated '_location' records will be a big > >> adventure. It probably means no change from the state without persistent > >> search :-) After basic exploration it seems doable, but still a bit uncertain. > > > > I need more info here, does it mean you have to store _location records > > when they are generated ? > I tend to do _location record generation during zone-load, so everything will > be prepared when the query comes in. As a benefit it will allow zone transfers > even for signed zones. This still needs more investigation. The idea is that _location is dynamic though, isn't it ? Anyway what if we do not sign _location records ? Will DNSSEC compliant clients fail in that case ? > > Maybe we can use the internal bind database > > just for _location "zone" ? > I don't think that it is possible. > > If _location.client-a and _location.client-b reside in the single database > then client-a and client-b have to reside in the same database. (The reason is > that _location.client-a and _location.client-b do not have immediate common > ancestor.) Uhmm right, nvm. > >> My personal conclusion is that re-using of BIND's backend will save a huge > >> amount of work/code to maintain/bugs. > > > > I can see that, unfortunately I fear it will make multi-master a lot > > more difficult at the same time. And given we do want to have > > multi-master properties we need to analyze that problem more carefully. > I agree. It is a delicate change and we should not hurry. > > > Also by welding ourselves to internal Bind infrastructure too much, it > > will make it a lot more difficult for us to change the DNS > > infrastructure. Bind10 will be completely different internally, and we > > may simply decide to even not use bind10 at all and use a completely > > different engine going forward. So I am quite wary of welding ourselves > > even more to bind 9 internals. > Ehm ... how to say that ... 'to late'. I wasn't around when DNS design was > made, so I don't know all the reasons behind the decision, but IMHO we use > completely non-standard/obscure hacks all the time. > > The proposal above doesn't extend our dependency on BIND, because we already > depend on BIND9 *completely*. Not really, all the data is currently in LDAP, all we need is to write a plugin for a different server and start serving data that way. However if DNSSEC is handled with bind, then rewriting the plugin will not be sufficient as we do not have the data in LDAP anymore, we also need to find out that part. I am not against your proposal because of this, just pointing out. > It is about dropping our own internal database > implementation (buggy, incomplete, standard non-compliant) with the code from > the original BIND (which is at least standard compliant). Understood. What changes are going to be required in bind-dyndb-ldap to use RBTDB from Bind ? Do we have interfaces already ? Or will it require additional changes to the glue code we currently use to load our plugin into bind ? > > Do you want to go back to 'light side of the force'? So we should start with > designing some LDAP->nsupdate gateway and use that for zone maintenance. It > doesn't solve adding/reconfiguring of zones on run-time, but it could be > handled by some stand-alone daemon with an abstraction layer at proper place. > Well the problem is loading of zones, that is why nsupdate can't be used, we'd have to dump zones on the fly at restart and pile up nsupdates if bind is not available, and then handle the case where for some reason nsupdate fails and bind and LDAP get out of sync. Also would mean nsupdates made by clients would not be reported back to LDAP. Using nsupdate was considered, it just is not feasible. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed May 22 10:30:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 22 May 2013 12:30:18 +0200 Subject: [Freeipa-devel] [PATCH] 0226 Relax getkeytab test to allow additional messages on stderr In-Reply-To: <51963AA7.1010206@redhat.com> References: <51963AA7.1010206@redhat.com> Message-ID: <519C9E3A.3010604@redhat.com> On 05/17/2013 04:11 PM, Petr Viktorin wrote: > Hello, > The IPA test suite currently fails on f19 due to Camellia cipher that we don't > enable by default. This makes the test ignore extra warnings on ipa-getkeytab's > stderr. > > > Note: I've skipped triage for this ticket because it's interfering with getting > a CI server set up (#3621). ACK. Before pushing, please also consider for ack&pushing attached patch. It will fix this test on Fedora 19 instances where DIR CCACHE is a default type of CCACHE. Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Handle-DIR-type-CCACHEs-in-cmdline-properly.patch Type: text/x-patch Size: 1929 bytes Desc: not available URL: From pviktori at redhat.com Wed May 22 10:34:21 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 22 May 2013 12:34:21 +0200 Subject: [Freeipa-devel] [PATCH 0002] Add 'debug' statement to nsupdate commands generated by ipa-client-install In-Reply-To: <5196377D.5080000@redhat.com> References: <5193926F.7030601@redhat.com> <5194B6DB.2020907@redhat.com> <5196346F.8080008@redhat.com> <5196377D.5080000@redhat.com> Message-ID: <519C9F2D.2070908@redhat.com> On 05/17/2013 03:58 PM, Ana Krivokapic wrote: > On 05/17/2013 03:45 PM, Petr Spacek wrote: >> On 16.5.2013 12:37, Ana Krivokapic wrote: >>> On 05/15/2013 03:49 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> This patch adds 'debug' and 'show' statements to nsupdate commands >>>> generated by ipa-client-install. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3629 >>> >>> You probably want to add another 'show', before the last 'send' in the >>> `update_ssh_keys()` function. >> >> You are right. Corrected patch is attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Pushed to master, ipa-3-2. -- Petr? From pviktori at redhat.com Wed May 22 12:13:44 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 22 May 2013 14:13:44 +0200 Subject: [Freeipa-devel] [PATCH] 0226 Relax getkeytab test to allow additional messages on stderr In-Reply-To: <519C9E3A.3010604@redhat.com> References: <51963AA7.1010206@redhat.com> <519C9E3A.3010604@redhat.com> Message-ID: <519CB678.1010707@redhat.com> On 05/22/2013 12:30 PM, Martin Kosek wrote: > On 05/17/2013 04:11 PM, Petr Viktorin wrote: >> Hello, >> The IPA test suite currently fails on f19 due to Camellia cipher that we don't >> enable by default. This makes the test ignore extra warnings on ipa-getkeytab's >> stderr. >> >> >> Note: I've skipped triage for this ticket because it's interfering with getting >> a CI server set up (#3621). > > ACK. Before pushing, please also consider for ack&pushing attached patch. It > will fix this test on Fedora 19 instances where DIR CCACHE is a default type of > CCACHE. > > Thanks, > Martin > ACK, I just added "test_" to the commit subject. Pushed both to master. -- Petr? From pspacek at redhat.com Wed May 22 15:01:14 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 22 May 2013 17:01:14 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <1369161023.23339.20.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> Message-ID: <519CDDBA.1010500@redhat.com> On 21.5.2013 20:30, Simo Sorce wrote: > On Tue, 2013-05-21 at 18:32 +0200, Petr Spacek wrote: >> Hello, >> >> I found that we (probably) misunderstood each other. The sky-high level >> overview of the proposal follow: >> >> NO CHANGE: >> 1) LDAP stores all *unsigned* data. >> >> 2) >> NO CHANGE: >> a) bind-dyndb-ldap *on each server* fetches all unsigned data from LDAP and >> store them in *in memory* database (we do it now) >> >> THE DIFFERENCE: >> b) All data will be stored in BIND's native RBT-database (RBTDB) instead of >> our own in-memory database. >> >> NEW PIECES: >> 3) >> Mechanisms implemented in BIND's RBTDB will do DNSSEC signing etc. for us. The >> BIND's feature is called 'in-line signing' and it can do all key/signature >> maintenance for us, including periodical zone re-signing etc. >> >> >> The whole point of this proposal is about code-reusage. I'm trying to avoid >> re-inventing of the wheel. >> >> Note that DNSSEC implementation in BIND has ~ 150 kiB of C code, stand-alone >> signing utilities add another ~ 200 kiB of code (~ 7000 lines) . I really >> don't want to re-write it again when it's not reasonable. >> >> Further comments are in-line. > > Ok putting some numbers on this topic really helps, thanks! > > More inline. > > [..] > >>> I haven't seen any reasoning from you why letting Bind do this work is >>> a better idea. >> Simply said - because all the code is already in BIND (the feature is called >> 'in-line signing', as I mentioned above). >> >>> I actually see some security reasons why putting this into a DS plugin >>> can have quite some advantages instead. Have you considered doing this >> It could improve the security a bit, I agree. But I don't think that it is so >> big advantage. BIND already has all the facilities for key material handling, >> so the only thing we have to solve is how to distribute keys from LDAP to >> running BIND. > > Well it would mean sticking the key in ldap and letting Bind pull them > from there based on ACIs ... > The main issue would be changes in keys, but with the persistent search > I guess that's also not a huge deal. Zone can be signed with multiple keys at same time, so key rotation is not a problem. Each signature contains key-id. >>> work in a DS plugin at all ? If you haven and have discarded the idea, >>> can you say why ? >> 1) It would require pulling ~ 200 kiB (~ 7000 lines) of DNSSEC signing code >> into 389. >> >> 2) It would require pulling 'text->DNS wire format' parser into 389 (because >> our LDAP stores plain text data but the signing process works with DNS wire >> format). >> >> 3) It simplifies bind-dyndb-ldap, but we still need to re-implement DNS search >> algorithm which takes DNSSEC oddities into account. (Note that the DNS search >> algorithm is part of the database implementation. Bugs/limitations in our >> implementation are the reason why wildard records are not supported...) >> >> 4) I'm not sure how it will work with replication. How to ensure that new >> record will not appear in the zone until the associated RRset is (re)computed >> by DS? (BIND has transaction mechanism built-in to the internal RBTDB.) > > 389ds has internal transactions, which is why I was thinking to do the > signatures on any change coming into LDAP (direct or via replication, > within the transaction. > >>>> The point is that you *can* do changes run-time, but you need to know about >>>> the changes as soon as possible because each change requires significant >>>> amount of work (and magic/mana :-). >>>> >>>> It opens a lot of opportunities for race condition problems. >>> >>> Yes, I am really concerned about the race conditions of course, however >>> I really wonder whether doing signing in bind is really a good idea. >>> We need to synchronize these signatures to all masters right ? >> No, because signatures are computed and stored only in memory - and forgotten >> after BIND shutdown. Yes, it requires re-computing on each load, this is >> definitely disadvantage. > > Ok I definitely need numbers here. > Can you do a test with a normal, text based, Bind zone with 10k entries > and see how much time it takes to re-sign everything ? > > I suspect that will be way too much, so we will have the added problem > of having to maintain a local cache in order to be able to restart Bind > and have it actually server results in a reasonable time w/o killing the > machine completely. Right, it is good idea. I never tried really big zone (for some reason?). Command: /usr/bin/time dnssec-signzone -n 1 -o example.net example.net Signing was limited to single core (parameter -n 1). Unsigned zone: 327 285 bytes, ~ 10 000 A records and several other records Signed zone: 10 847 688 bytes Results: 38.28user 0.09system 0:38.80elapsed 98%CPU (0avgtext+0avgdata 18032maxresident)k 0inputs+21200outputs (0major+4646minor)pagefaults 0swaps Wow, it is pretty slow. CPU: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Operating memory: 4 GB of DDR3 @ 1333 MHz The simplest way how to mitigate problem with slow start-up is: 1) Store signed version of the zone on the server's file system. 2) Load signed version from disk during start up. 3) In the background, do full zone reload+resign. 4) Switch old and new zones when it is done. It will consume some computing power during start up, but the implementation should be really simple. (BIND naturally can save and load zones :-)) >>> Doesn't that mean we need to store this data back in LDAP ? >> No, only 'normal' DNS updates containing unsigned data will be written back to >> LDAP. RRSIG and NSEC records will never reach LDAP. >> >>> That means more round-trips before the data ends up being usable, and we >>> do not have transactions in LDAP, so I am worried that doing the signing >>> in Bind may not be the best way to go. >> I'm proposing to re-use BIND's transaction mechanism built in internal >> database implementation. >> >>>>>> => It should be possible to save old database to disk (during BIND shutdown >>>>>> or >>>>>> periodically) and re-use this old database during server startup. I.e. server >>>>>> will start replying immediately from 'old' database and then the server will >>>>>> switch to the new database when dump from LDAP is finished. >>>>> >>>>> >>>>> This look like an advantage ? Why is it a disadvantage ? >>>> It was mentioned as 'proposed remedy' for the disadvantage above. >>> >>> I think having dual authoritative data sources may not be a good thing. >> Consistency is a reason why I want to make persistent search mandatory. > > A persistent search does not guarantee consistency only that updates are > sent to you as soon as they come in, you still may end up with bugs in > the implementation where you do not catch something and get out of date, > with the actual data in LDAP. > >> IMHO persistent storage could save the day if LDAP is down for some reason. >> Old data in DNS are much better than no data in DNS. > > Depends how OLD :-) > But maybe we can bake some timeouts in there and simply dump any cached > data if it really is too old. Yes, it can be configurable. "Stop responding if synchronization with LDAP is failing for at least xxxx seconds". >>>>>> => As a side effect, BIND can start even if connection to LDAP server is down >>>>>> - this can improve infrastructure resiliency a lot! >>>>> >>>>> Same as above ? >>>> The same here, it was mentioned as 'proposed remedy' for the disadvantage above. >>> >>> When it comes to DNSSEC starting w/o LDAP may just mean that you have >>> different signatures for the same records on different masters. Is that >>> 'legale' according to DNSSEC ? >> 1) You will have same signatures as long as records in LDAP and saved copy of >> the database (on the disk) are equal. > > Well given an IPA infrastructure uses Dynamic Updates I expect data to > change frequently enough that if you have an outage that lasts more than > a handful of minutes the data in the saved copy will not match the data > in LDAP. I agree, that is definitely true, but I think that the most important pieces are NS, SRV and A records for servers. They are not changed that often. IMHO admins would be happier if they have 100 records from 10 000 out of date but the infrastructure works than without any records at all (and broken infrastructure). Again, there can be some LDAP-synchonization-timeout and DNS server can stop responding to queries when synchronization is lost for longer time. >> 2) I didn't find any new limitation imposed by DNSSEC. AFAIK some >> inconsistency between servers is normal state in DNS, because zone transfers >> take some time and the tree structure have many levels. > > But in the bind case they assume a single master model, so they never > have inconsistencies, right ? > But in our case we have multiple masters, so I wonder if a client is > going to have issues ... > Are we guaranteed that if 2 servers have the exact same view they > generate the exact same signatures ? If that is the case then maybe we > are ok. > >> The problems arise when data *in single database* (i.e. on one server) are >> inconsistent (e.g. signature != data in unsigned records). BIND solves this >> with it's built-in transaction mechanisms. > > Understood. > >>>>>> == Uncertain effects == >>>>>> - Memory consumption will change, but I'm not sure in which direction. >>>>>> - SOA serial number maintenance is a open question. >>>>> >>>>> Why SOA serial is a problem ? >>>> It simply needs more investigation. BIND's RBTDB maintains SOA serial >>>> internally (it is intertwined to transactions in the DB), so the write-back to >>>> LDAP could be very delicate operation. >>> >>> It means all masters will often be out of sync, this is not very good. >> I don't think so. BIND can use timestamp-based serials in exactly same way as >> we do. The only problem is how to implement 'read from internal DB'->'write to >> LDAP' operation. It still needs more investigation. > > Well if we use timestamp based serials ... why do we need to write > anything back ? :-) We can just let a DS plugin fill the serial in the > SOA with a timestamp just for schema compatibility purposes and just > assume bind has the same or a close enough serial internally. You are right. The value in LDAP is mostly 'historical'. It is used only as 'starting value', i.e. the serial value used during BIND (re)start. >>>>>> Decision if persistent search is a 'requirement' or not will have significant >>>>>> impact on the design, so I will write the design document when this decision >>>>>> is made. >>>>> >>>>> I would like to know more details about the reasons before I can usefully comment. >>>> >>>> I forgot to one another 'Uncertain effect': >>>> - Support for dynamically generated '_location' records will be a big >>>> adventure. It probably means no change from the state without persistent >>>> search :-) After basic exploration it seems doable, but still a bit uncertain. >>> >>> I need more info here, does it mean you have to store _location records >>> when they are generated ? >> I tend to do _location record generation during zone-load, so everything will >> be prepared when the query comes in. As a benefit it will allow zone transfers >> even for signed zones. This still needs more investigation. > > The idea is that _location is dynamic though, isn't it ? The value seems to be 'dynamic', but only from client's point of view. AFAIK there are three options: 1) _location is configured for particular client statically in LDAP 2) Each individual server has own default value for _location (for clients without explicit configuration). 3) Each individual server can be configured to override all values in _location with one fixed value, i.e. all clients (e.g. in bandwith-constrained location) will use only the local server. This is how I understood the design. Is it correct? If it is, then the value is static from server's point of view. The 'dynamics' is a result of moving client, because client is asking different servers for an answer. > Anyway what if we do not sign _location records ? > Will DNSSEC compliant clients fail in that case ? I'm not 100 % sure, but I see two problems: 1) It seems that opt-out is allowed only for delegation points (NS records belonging to sub-domains). http://tools.ietf.org/html/rfc5155#section-6 2) Opt-out allows an attacked to insert unsigned data in the replies. http://www.stanford.edu/~jcm/papers/dnssec_ndss10.pdf section 3.4 Anyway, I don't think that it is necessary. >> > Maybe we can use the internal bind database >>> just for _location "zone" ? >> I don't think that it is possible. >> >> If _location.client-a and _location.client-b reside in the single database >> then client-a and client-b have to reside in the same database. (The reason is >> that _location.client-a and _location.client-b do not have immediate common >> ancestor.) > > Uhmm right, nvm. > >>>> My personal conclusion is that re-using of BIND's backend will save a huge >>>> amount of work/code to maintain/bugs. >>> >>> I can see that, unfortunately I fear it will make multi-master a lot >>> more difficult at the same time. And given we do want to have >>> multi-master properties we need to analyze that problem more carefully. >> I agree. It is a delicate change and we should not hurry. >> >>> Also by welding ourselves to internal Bind infrastructure too much, it >>> will make it a lot more difficult for us to change the DNS >>> infrastructure. Bind10 will be completely different internally, and we >>> may simply decide to even not use bind10 at all and use a completely >>> different engine going forward. So I am quite wary of welding ourselves >>> even more to bind 9 internals. >> Ehm ... how to say that ... 'to late'. I wasn't around when DNS design was >> made, so I don't know all the reasons behind the decision, but IMHO we use >> completely non-standard/obscure hacks all the time. >> >> The proposal above doesn't extend our dependency on BIND, because we already >> depend on BIND9 *completely*. > > Not really, all the data is currently in LDAP, all we need is to write a > plugin for a different server and start serving data that way. > > However if DNSSEC is handled with bind, then rewriting the plugin will > not be sufficient as we do not have the data in LDAP anymore, we also > need to find out that part. Ah okay, now I got what you meant. I didn't imagine that the 'write a plugin for a different server' part is the simple piece :-) > I am not against your proposal because of this, just pointing out. > >> It is about dropping our own internal database >> implementation (buggy, incomplete, standard non-compliant) with the code from >> the original BIND (which is at least standard compliant). > > Understood. > > What changes are going to be required in bind-dyndb-ldap to use RBTDB > from Bind ? Do we have interfaces already ? Or will it require > additional changes to the glue code we currently use to load our plugin > into bind ? I have some proof-of-concept code. AFAIK no change to public interfaces are necessary. There are 40 functions each database driver have to implement. Currently, we have own implementation for most of them and some of them are NULL because are required only for DNSSEC. The typical change from our implementation to the native one looks like this: static isc_result_t find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, dns_rdatatype_t type, unsigned int options, isc_stdtime_t now, dns_dbnode_t **nodep, dns_name_t *foundname, dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset) { - [next 200 lines of our code] + return dns_db_find(ldapdb->rbtdb, name, version, type, options, now, + nodep, foundname, rdataset, sigrdataset); } Most of the work is about understanding how the native database work. At the moment I'm able to load data from LDAP and push them to the native database except the zone serial. It definitely needs more investigation, but it seems doable. >> >> Do you want to go back to 'light side of the force'? So we should start with >> designing some LDAP->nsupdate gateway and use that for zone maintenance. It >> doesn't solve adding/reconfiguring of zones on run-time, but it could be >> handled by some stand-alone daemon with an abstraction layer at proper place. >> > > Well the problem is loading of zones, that is why nsupdate can't be > used, we'd have to dump zones on the fly at restart and pile up > nsupdates if bind is not available, and then handle the case where for > some reason nsupdate fails and bind and LDAP get out of sync. Yes, it is definitely not a simple task, but IMHO it could work. Some glue logic specific for particular DNS server will be required in any case (for zone addition/removal/reconfiguration - in BIND's case some tooling around 'rndc' tool), but most of the 'synchronization logic' can be done in generic way. I can imagine that 'synchronization daemon' could be simpler than current code (323 780 bytes ; 11 909 lines of C). > Also would mean nsupdates made by clients would not be reported back to > LDAP. I don't agree. DNS has incremental zone transfers (RFC 1995) and change notification mechanism (RFC 1996). A standard compliant DNS server can send notification about changes in the zone and the (hypothetical) 'synchronization daemon' can read the changes via IXFR. The way from LDAP to DNS is not simple, that is definitely true ... > Using nsupdate was considered, it just is not feasible. We should reconsider it during migration from BIND9 to something else :-) Have a nice day. -- Petr^2 Spacek From simo at redhat.com Wed May 22 19:58:40 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 22 May 2013 15:58:40 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <519CDDBA.1010500@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> Message-ID: <1369252720.2769.23.camel@willson.li.ssimo.org> On Wed, 2013-05-22 at 17:01 +0200, Petr Spacek wrote: > Right, it is good idea. I never tried really big zone (for some reason?). > > Command: /usr/bin/time dnssec-signzone -n 1 -o example.net example.net > Signing was limited to single core (parameter -n 1). > > Unsigned zone: 327 285 bytes, ~ 10 000 A records and several other records > Signed zone: 10 847 688 bytes > Results: > 38.28user 0.09system 0:38.80elapsed 98%CPU (0avgtext+0avgdata 18032maxresident)k > 0inputs+21200outputs (0major+4646minor)pagefaults 0swaps > > Wow, it is pretty slow. Yeah this is what I expected, crypto is not really fast. > CPU: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz > Operating memory: 4 GB of DDR3 @ 1333 MHz > > The simplest way how to mitigate problem with slow start-up is: > 1) Store signed version of the zone on the server's file system. > 2) Load signed version from disk during start up. > 3) In the background, do full zone reload+resign. > 4) Switch old and new zones when it is done. Maybe instead of 3/4 we can do something that requires less computation. We can take the list of records in the zone, and load the list of records from LDAP. Here we set also the persistent search but we lock it so any update is queued until we are done with the main resync task. (We can temporarily also refuse DNS Updates I guess) We cross check to find which records have been changed, which have been removed, and which have been added. Discard all the records that are unchanged (I assume the vast majority) and then proceed to delete/modify/add the difference. This would save a large amount of computation at every startup, even if in the background the main issue here is not just time, but the fact that you pegged the CPU to 98% for so long. > It will consume some computing power during start up, but the implementation > should be really simple. (BIND naturally can save and load zones :-)) I do not think the above would be much more difficult, and could save quite a lot of computing if done in the right order and within a bind database transaction I guess. > > Well given an IPA infrastructure uses Dynamic Updates I expect data to > > change frequently enough that if you have an outage that lasts more than > > a handful of minutes the data in the saved copy will not match the data > > in LDAP. > I agree, that is definitely true, but I think that the most important pieces > are NS, SRV and A records for servers. They are not changed that often. > > IMHO admins would be happier if they have 100 records from 10 000 out of date > but the infrastructure works than without any records at all (and broken > infrastructure). > > Again, there can be some LDAP-synchonization-timeout and DNS server can stop > responding to queries when synchronization is lost for longer time. This may be a reasonable compromise. > > The idea is that _location is dynamic though, isn't it ? > The value seems to be 'dynamic', but only from client's point of view. AFAIK > there are three options: > 1) _location is configured for particular client statically in LDAP > 2) Each individual server has own default value for _location (for clients > without explicit configuration). > 3) Each individual server can be configured to override all values in > _location with one fixed value, i.e. all clients (e.g. in bandwith-constrained > location) will use only the local server. > > This is how I understood the design. Is it correct? If it is, then the value > is static from server's point of view. The 'dynamics' is a result of moving > client, because client is asking different servers for an answer. Uhmm true, so we could simply store all the fields from within the plugin so that RBTDB can sign them too. I think my only concern is if the client can ever load some data from one server and then some other data from another and find mismatching signatures. > > Anyway what if we do not sign _location records ? > > Will DNSSEC compliant clients fail in that case ? > I'm not 100 % sure, but I see two problems: > > 1) It seems that opt-out is allowed only for delegation points (NS records > belonging to sub-domains). > http://tools.ietf.org/html/rfc5155#section-6 > > 2) Opt-out allows an attacked to insert unsigned data in the replies. > http://www.stanford.edu/~jcm/papers/dnssec_ndss10.pdf section 3.4 I think for location discovery this may be a problem we can accept. But if we can avoid it we probably should. > Anyway, I don't think that it is necessary. ok. > > What changes are going to be required in bind-dyndb-ldap to use RBTDB > > from Bind ? Do we have interfaces already ? Or will it require > > additional changes to the glue code we currently use to load our plugin > > into bind ? > > I have some proof-of-concept code. AFAIK no change to public interfaces are > necessary. > > There are 40 functions each database driver have to implement. Currently, we > have own implementation for most of them and some of them are NULL because are > required only for DNSSEC. > > The typical change from our implementation to the native one looks like this: > > static isc_result_t > find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, > dns_rdatatype_t type, unsigned int options, isc_stdtime_t now, > dns_dbnode_t **nodep, dns_name_t *foundname, dns_rdataset_t *rdataset, > dns_rdataset_t *sigrdataset) > { > - [next 200 lines of our code] > + return dns_db_find(ldapdb->rbtdb, name, version, type, options, now, > + nodep, foundname, rdataset, sigrdataset); > } > > Most of the work is about understanding how the native database work. I assume rbtdb is now pretty stable and semantic changes are quite unlikely ? > At the moment I'm able to load data from LDAP and push them to the native > database except the zone serial. It definitely needs more investigation, but > it seems doable. Well if we store the data in the b permanently and synchronize at startup I guess the serial problem vanishes completely ? (assuming we use timestamp based serials) > >> > >> Do you want to go back to 'light side of the force'? So we should start with > >> designing some LDAP->nsupdate gateway and use that for zone maintenance. It > >> doesn't solve adding/reconfiguring of zones on run-time, but it could be > >> handled by some stand-alone daemon with an abstraction layer at proper place. > >> > > > > Well the problem is loading of zones, that is why nsupdate can't be > > used, we'd have to dump zones on the fly at restart and pile up > > nsupdates if bind is not available, and then handle the case where for > > some reason nsupdate fails and bind and LDAP get out of sync. > > Yes, it is definitely not a simple task, but IMHO it could work. Some glue > logic specific for particular DNS server will be required in any case (for > zone addition/removal/reconfiguration - in BIND's case some tooling around > 'rndc' tool), but most of the 'synchronization logic' can be done in generic way. > > I can imagine that 'synchronization daemon' could be simpler than current code > (323 780 bytes ; 11 909 lines of C). No, trust me synchronization is alwys fraught with nasty corner cases and things getting out of sync. In fact I think we should implement the re-sync I am asking for at load time at regular intervals so that even if the internal database and LDAP go out fo sync we fix that every X hours by performing a smart re-sync (which hopefully normally will simply consist in comparing 2 snapshots (internal and LDAP) and finding that they are basically in sync). > > Also would mean nsupdates made by clients would not be reported back to > > LDAP. > I don't agree. DNS has incremental zone transfers (RFC 1995) and change > notification mechanism (RFC 1996). A standard compliant DNS server can send > notification about changes in the zone and the (hypothetical) 'synchronization > daemon' can read the changes via IXFR. And we are reimplementing half of the protocols again :) > The way from LDAP to DNS is not simple, that is definitely true ... > > > Using nsupdate was considered, it just is not feasible. > > We should reconsider it during migration from BIND9 to something else :-) Well, we'll think about that once we decide it is time I guess :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu May 23 12:35:21 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 23 May 2013 14:35:21 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <1369252720.2769.23.camel@willson.li.ssimo.org> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> Message-ID: <519E0D09.3010108@redhat.com> On 22.5.2013 21:58, Simo Sorce wrote: > On Wed, 2013-05-22 at 17:01 +0200, Petr Spacek wrote: >> Wow, it is pretty slow. > Yeah this is what I expected, crypto is not really fast. [...] >> The simplest way how to mitigate problem with slow start-up is: >> 1) Store signed version of the zone on the server's file system. >> 2) Load signed version from disk during start up. >> 3) In the background, do full zone reload+resign. >> 4) Switch old and new zones when it is done. > > Maybe instead of 3/4 we can do something that requires less computation. > We can take the list of records in the zone, and load the list of > records from LDAP. > > Here we set also the persistent search but we lock it so any update is > queued until we are done with the main resync task. > (We can temporarily also refuse DNS Updates I guess) > > We cross check to find which records have been changed, which have been > removed, and which have been added. > Discard all the records that are unchanged (I assume the vast majority) > and then proceed to delete/modify/add the difference. > > This would save a large amount of computation at every startup, even if > in the background the main issue here is not just time, but the fact > that you pegged the CPU to 98% for so long. > >> It will consume some computing power during start up, but the implementation >> should be really simple. (BIND naturally can save and load zones :-)) > > I do not think the above would be much more difficult, and could save > quite a lot of computing if done in the right order and within a bind > database transaction I guess. It sounds doable, I agree. Naturally, I plan to start with 'naive'/'in-memory only' implementation and add optimizations when the 'naive' part works. >>> The idea is that _location is dynamic though, isn't it ? [...] >> This is how I understood the design. Is it correct? If it is, then the value >> is static from server's point of view. The 'dynamics' is a result of moving >> client, because client is asking different servers for an answer. > > Uhmm true, so we could simply store all the fields from within the > plugin so that RBTDB can sign them too. > > I think my only concern is if the client can ever load some data from > one server and then some other data from another and find mismatching > signatures. I didn't find any note about cross-checks between DNS servers. IMHO it doesn't matter, as long as signature matches the public key in the zone. I think that some degree of inconsistency is natural part of DNS. Typically, all changes are propagated from the 'master'/'root of the tree topology' through multiple levels of slaves to the 'leaf slaves'. Signatures contain timestamps and are periodically re-computed (in order of weeks) and it takes some time to propagate new signatures through the whole tree. >>> What changes are going to be required in bind-dyndb-ldap to use RBTDB >>> from Bind ? Do we have interfaces already ? Or will it require >>> additional changes to the glue code we currently use to load our plugin >>> into bind ? >> >> I have some proof-of-concept code. AFAIK no change to public interfaces are >> necessary. >> >> There are 40 functions each database driver have to implement. Currently, we >> have own implementation for most of them and some of them are NULL because are >> required only for DNSSEC. >> >> The typical change from our implementation to the native one looks like this: >> >> static isc_result_t >> find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version, >> dns_rdatatype_t type, unsigned int options, isc_stdtime_t now, >> dns_dbnode_t **nodep, dns_name_t *foundname, dns_rdataset_t *rdataset, >> dns_rdataset_t *sigrdataset) >> { >> - [next 200 lines of our code] >> + return dns_db_find(ldapdb->rbtdb, name, version, type, options, now, >> + nodep, foundname, rdataset, sigrdataset); >> } >> >> Most of the work is about understanding how the native database work. > > I assume rbtdb is now pretty stable and semantic changes are quite > unlikely ? BIND (with our patches) has defined interface for database backends. Either bind-dyndb-ldap and RBTDB implement this interface, so semantic change is very very unlikely. The plan is to use the 'public' RBTDB interface to avoid any touch between bind-dyndb-ldap and 'internal knobs' in RBTDB. >> At the moment I'm able to load data from LDAP and push them to the native >> database except the zone serial. It definitely needs more investigation, but >> it seems doable. > > Well if we store the data in the b permanently and synchronize at > startup I guess the serial problem vanishes completely ? (assuming we > use timestamp based serials) Yes, basically we don't need to write it back to LDAP at all. The behaviour should be same as with current implementation. >>>> >>>> Do you want to go back to 'light side of the force'? So we should start with >>>> designing some LDAP->nsupdate gateway and use that for zone maintenance. It >>>> doesn't solve adding/reconfiguring of zones on run-time, but it could be >>>> handled by some stand-alone daemon with an abstraction layer at proper place. >>>> >>> >>> Well the problem is loading of zones, that is why nsupdate can't be >>> used, we'd have to dump zones on the fly at restart and pile up >>> nsupdates if bind is not available, and then handle the case where for >>> some reason nsupdate fails and bind and LDAP get out of sync. >> >> Yes, it is definitely not a simple task, but IMHO it could work. Some glue >> logic specific for particular DNS server will be required in any case (for >> zone addition/removal/reconfiguration - in BIND's case some tooling around >> 'rndc' tool), but most of the 'synchronization logic' can be done in generic way. >> >> I can imagine that 'synchronization daemon' could be simpler than current code >> (323 780 bytes ; 11 909 lines of C). > > No, trust me synchronization is alwys fraught with nasty corner cases > and things getting out of sync. In fact I think we should implement the > re-sync I am asking for at load time at regular intervals so that even > if the internal database and LDAP go out fo sync we fix that every X > hours by performing a smart re-sync (which hopefully normally will > simply consist in comparing 2 snapshots (internal and LDAP) and finding > that they are basically in sync). I agree that some periodical re-synchronization would be handy even for current solution. It looks that we agree on nearly all points (I apologize if overlooked something). I will prepare a design document for transition to RBTDB and then another design document for DNSSEC implementation. >>> Also would mean nsupdates made by clients would not be reported back to >>> LDAP. >> I don't agree. DNS has incremental zone transfers (RFC 1995) and change >> notification mechanism (RFC 1996). A standard compliant DNS server can send >> notification about changes in the zone and the (hypothetical) 'synchronization >> daemon' can read the changes via IXFR. > > And we are reimplementing half of the protocols again :) We don't have to implement LDAP protocol because we have openldap libraries and there are libraries for DNS too. Why we would have to implement DNS? :-) Anyway, it doesn't matter for now, I'm not pushing towards 'synchronization daemon' at the moment. -- Petr^2 Spacek From simo at redhat.com Thu May 23 14:32:18 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 May 2013 10:32:18 -0400 Subject: [Freeipa-devel] DNSSEC support design considerations In-Reply-To: <519E0D09.3010108@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> Message-ID: <1369319538.2769.24.camel@willson.li.ssimo.org> On Thu, 2013-05-23 at 14:35 +0200, Petr Spacek wrote: > > It looks that we agree on nearly all points (I apologize if > overlooked > something). I will prepare a design document for transition to RBTDB > and then > another design document for DNSSEC implementation. > ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 23 14:42:11 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 May 2013 10:42:11 -0400 Subject: [Freeipa-devel] CLDAP Netlogon fixes Message-ID: <1369320131.2769.30.camel@willson.li.ssimo.org> CLDAP fixes for: https://fedorahosted.org/freeipa/ticket/3639 Should be pretty straightforward. (pending testing) Alexander, please check they work for your 2012 setup too. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-CLDAP-Return-empty-reply-on-non-fatal-errors.patch Type: text/x-patch Size: 1659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CLDAP-Fix-domain-handling-in-netlogon-requests.patch Type: text/x-patch Size: 4278 bytes Desc: not available URL: From tbabej at redhat.com Thu May 23 17:17:00 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 23 May 2013 19:17:00 +0200 Subject: [Freeipa-devel] [PATCH 0059] Make testcert automagically when needed by unit test Message-ID: <519E4F0C.5040102@redhat.com> Hi, With this patch, there's no need to run make-testcert separately before running make-test. Unit test framework will check whether service.crt file exists, and if not, will generate one if needed. New location of service.crt file is in ~/.ipa directory. Part of https://fedorahosted.org/freeipa/ticket/3621 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0059-Make-testcert-automagically-when-needed-by-unit-test.patch Type: text/x-patch Size: 9492 bytes Desc: not available URL: From simo at redhat.com Thu May 23 17:22:35 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 May 2013 13:22:35 -0400 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <1369320131.2769.30.camel@willson.li.ssimo.org> References: <1369320131.2769.30.camel@willson.li.ssimo.org> Message-ID: <1369329755.2769.39.camel@willson.li.ssimo.org> On Thu, 2013-05-23 at 10:42 -0400, Simo Sorce wrote: > CLDAP fixes for: > https://fedorahosted.org/freeipa/ticket/3639 > > Should be pretty straightforward. > (pending testing) > > Alexander, > please check they work for your 2012 setup too. Alexander found a couple of typos and then the patches didn't work for him. The bug was that I forgot to consider the successful case in the switch statement I introduced at the last minute ... silly me. Tested this new set and works for me, Alexander please confirm. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-CLDAP-Return-empty-reply-on-non-fatal-errors.patch Type: text/x-patch Size: 1718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CLDAP-Fix-domain-handling-in-netlogon-requests.patch Type: text/x-patch Size: 4278 bytes Desc: not available URL: From abokovoy at redhat.com Thu May 23 18:02:04 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 23 May 2013 21:02:04 +0300 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <1369329755.2769.39.camel@willson.li.ssimo.org> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> Message-ID: <20130523180204.GG26689@redhat.com> On Thu, 23 May 2013, Simo Sorce wrote: >On Thu, 2013-05-23 at 10:42 -0400, Simo Sorce wrote: >> CLDAP fixes for: >> https://fedorahosted.org/freeipa/ticket/3639 >> >> Should be pretty straightforward. >> (pending testing) >> >> Alexander, >> please check they work for your 2012 setup too. > >Alexander found a couple of typos and then the patches didn't work for >him. > >The bug was that I forgot to consider the successful case in the switch >statement I introduced at the last minute ... silly me. > >Tested this new set and works for me, Alexander please confirm. Works for me now. There is still slight difference from what we see against Windows Server 2012. ---------------------------------------------------------------------------------- $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00))' netlogon version: 1 dn: netlogon:: FwAAAP0DAADBEtlp7qtnRa3yDLzj68BuBGJpcmQFY2xvbmUAwBgDcmVkwBgEQklSRAA FXFxSRUQAABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAOhACAAAAfwAAAQAAAAAAAAAAAAUAAAD/ //// $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone))' netlogon version: 1 dn: netlogon:: FwAAAP0DAADBEtlp7qtnRa3yDLzj68BuBGJpcmQFY2xvbmUAwBgDcmVkwBgEQklSRAA FXFxSRUQAABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAOhACAAAAfwAAAQAAAAAAAAAAAAUAAAD/ //// $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone1))' netlogon version: 1 dn: netlogon: $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\00\00\55\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone))' netlogon version: 1 dn: netlogon: ---------------------------------------------------------------------------------- As you can see, incorrect parameters still return empty dn and netlogon attributes while Windows Server 2012 returns empty response: $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon version: 1 Yet, since for trusts we care about explicit request with our domain name _and_ the case when DnsDomain is not specified, everything continues to work. So ACK. -- / Alexander Bokovoy From simo at redhat.com Thu May 23 19:06:44 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 May 2013 15:06:44 -0400 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <20130523180204.GG26689@redhat.com> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> <20130523180204.GG26689@redhat.com> Message-ID: <1369336004.2769.56.camel@willson.li.ssimo.org> On Thu, 2013-05-23 at 21:02 +0300, Alexander Bokovoy wrote: > On Thu, 23 May 2013, Simo Sorce wrote: > >On Thu, 2013-05-23 at 10:42 -0400, Simo Sorce wrote: > >> CLDAP fixes for: > >> https://fedorahosted.org/freeipa/ticket/3639 > >> > >> Should be pretty straightforward. > >> (pending testing) > >> > >> Alexander, > >> please check they work for your 2012 setup too. > > > >Alexander found a couple of typos and then the patches didn't work for > >him. > > > >The bug was that I forgot to consider the successful case in the switch > >statement I introduced at the last minute ... silly me. > > > >Tested this new set and works for me, Alexander please confirm. > Works for me now. There is still slight difference from what we see > against Windows Server 2012. > > ---------------------------------------------------------------------------------- > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00))' netlogon > version: 1 > > dn: > netlogon:: > FwAAAP0DAADBEtlp7qtnRa3yDLzj68BuBGJpcmQFY2xvbmUAwBgDcmVkwBgEQklSRAA > FXFxSRUQAABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAOhACAAAAfwAAAQAAAAAAAAAAAAUAAAD/ > //// > > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone))' netlogon > version: 1 > > dn: > netlogon:: > FwAAAP0DAADBEtlp7qtnRa3yDLzj68BuBGJpcmQFY2xvbmUAwBgDcmVkwBgEQklSRAA > FXFxSRUQAABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAOhACAAAAfwAAAQAAAAAAAAAAAAUAAAD/ > //// > > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone1))' netlogon > version: 1 > > dn: > netlogon: > > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\00\00\55\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone))' netlogon > version: 1 > > dn: > netlogon: > ---------------------------------------------------------------------------------- > > As you can see, incorrect parameters still return empty dn and netlogon > attributes while Windows Server 2012 returns empty response: > > $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon > version: 1 > > Yet, since for trusts we care about explicit request with our domain name _and_ the > case when DnsDomain is not specified, everything continues to work. > > So ACK. I can easily avoid returning the empty netlogon field, which is what I wanted to do. I'll see if I can also avoid returning the DN. Let me try just one more revision. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu May 23 19:12:15 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 23 May 2013 15:12:15 -0400 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <1369336004.2769.56.camel@willson.li.ssimo.org> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> <20130523180204.GG26689@redhat.com> <1369336004.2769.56.camel@willson.li.ssimo.org> Message-ID: <1369336335.2769.58.camel@willson.li.ssimo.org> On Thu, 2013-05-23 at 15:06 -0400, Simo Sorce wrote: > On Thu, 2013-05-23 at 21:02 +0300, Alexander Bokovoy wrote: > > On Thu, 23 May 2013, Simo Sorce wrote: > > >On Thu, 2013-05-23 at 10:42 -0400, Simo Sorce wrote: > > >> CLDAP fixes for: > > >> https://fedorahosted.org/freeipa/ticket/3639 > > >> > > >> Should be pretty straightforward. > > >> (pending testing) > > >> > > >> Alexander, > > >> please check they work for your 2012 setup too. > > > > > >Alexander found a couple of typos and then the patches didn't work for > > >him. > > > > > >The bug was that I forgot to consider the successful case in the switch > > >statement I introduced at the last minute ... silly me. > > > > > >Tested this new set and works for me, Alexander please confirm. > > Works for me now. There is still slight difference from what we see > > against Windows Server 2012. > > > > ---------------------------------------------------------------------------------- > > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00))' netlogon > > version: 1 > > > > dn: > > netlogon:: > > FwAAAP0DAADBEtlp7qtnRa3yDLzj68BuBGJpcmQFY2xvbmUAwBgDcmVkwBgEQklSRAA > > FXFxSRUQAABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAOhACAAAAfwAAAQAAAAAAAAAAAAUAAAD/ > > //// > > > > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone))' netlogon > > version: 1 > > > > dn: > > netlogon:: > > FwAAAP0DAADBEtlp7qtnRa3yDLzj68BuBGJpcmQFY2xvbmUAwBgDcmVkwBgEQklSRAA > > FXFxSRUQAABdEZWZhdWx0LUZpcnN0LVNpdGUtTmFtZQDAOhACAAAAfwAAAQAAAAAAAAAAAAUAAAD/ > > //// > > > > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\06\00\00\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone1))' netlogon > > version: 1 > > > > dn: > > netlogon: > > > > $ ldapsearch -LL -H cldap://red.bird.clone -b "" -s base '(&(NtVer=\00\00\55\00)(AAC=\00\00\00\00)(DnsDOmain=bird.clone))' netlogon > > version: 1 > > > > dn: > > netlogon: > > ---------------------------------------------------------------------------------- > > > > As you can see, incorrect parameters still return empty dn and netlogon > > attributes while Windows Server 2012 returns empty response: > > > > $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon > > version: 1 > > > > Yet, since for trusts we care about explicit request with our domain name _and_ the > > case when DnsDomain is not specified, everything continues to work. > > > > So ACK. > > I can easily avoid returning the empty netlogon field, which is what I > wanted to do. > I'll see if I can also avoid returning the DN. > > Let me try just one more revision. It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY completely as they were supposed to, and only return a LDAP_RES_SEARCH_RESULT record. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-CLDAP-Return-empty-reply-on-non-fatal-errors.patch Type: text/x-patch Size: 2380 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CLDAP-Fix-domain-handling-in-netlogon-requests.patch Type: text/x-patch Size: 4278 bytes Desc: not available URL: From tbabej at redhat.com Fri May 24 07:57:48 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 24 May 2013 09:57:48 +0200 Subject: [Freeipa-devel] [PATCH 0059] Make testcert automagically when needed by unit test In-Reply-To: <519E4F0C.5040102@redhat.com> References: <519E4F0C.5040102@redhat.com> Message-ID: <519F1D7C.3000700@redhat.com> On 05/23/2013 07:17 PM, Tomas Babej wrote: > Hi, > > With this patch, there's no need to run make-testcert separately > before running make-test. Unit test framework will check whether > service.crt file exists, and if not, will generate one if needed. > > New location of service.crt file is in ~/.ipa directory. > > Part of https://fedorahosted.org/freeipa/ticket/3621 > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I just noticed that one of the descriptions referred to the old service.cert path. Fixed, updated patch attached. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0059-2-Make-testcert-automagically-when-needed-by-unit-test.patch Type: text/x-patch Size: 9537 bytes Desc: not available URL: From pviktori at redhat.com Fri May 24 12:02:18 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 24 May 2013 14:02:18 +0200 Subject: [Freeipa-devel] [PATCH 0059] Make testcert automagically when needed by unit test In-Reply-To: <519F1D7C.3000700@redhat.com> References: <519E4F0C.5040102@redhat.com> <519F1D7C.3000700@redhat.com> Message-ID: <519F56CA.5030305@redhat.com> On 05/24/2013 09:57 AM, Tomas Babej wrote: > On 05/23/2013 07:17 PM, Tomas Babej wrote: >> Hi, >> >> With this patch, there's no need to run make-testcert separately >> before running make-test. Unit test framework will check whether >> service.crt file exists, and if not, will generate one if needed. >> >> New location of service.crt file is in ~/.ipa directory. >> >> Part of https://fedorahosted.org/freeipa/ticket/3621 >> >> Tomas Thanks, it works well. However it would be nice to not repeat this code in every test that needs the cert: +servercert = '' + +# Create the testing server cert if it does not already exist +# Returns True if successful, error message if not +if not os.path.exists(testcert.CERTPATH): + servercert_ret = testcert.main() + +if os.path.exists(testcert.CERTPATH): + fd = open(testcert.CERTPATH, 'r') + servercert = fd.readlines() + servercert = ''.join(servercert) + servercert = x509.strip_header(servercert) + fd.close() + + Please put this in testcert.py and just call something like `servercert = testcert.get_testcert()`. class test_host(Declarative): + def setUp(self): + super(Declarative, self).setUp() + if servercert == '': + raise nose.SkipTest('Testcert generation problem: %s' % + servercert_ret) + Do we really want to skip the test here? IMO if we cannot generate the cert, we should fail (`assert servercert`). -- Petr? From mkosek at redhat.com Fri May 24 12:37:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 May 2013 14:37:12 +0200 Subject: [Freeipa-devel] [PATCH] 408 Avoid exporting KRB5_KTNAME in dirsrv env Message-ID: <519F5EF8.50407@redhat.com> The variable is already defined, exporting in dirsrv systemd environment is not needed and produces a (benign) error. --- Avoids this /var/log/messages error on F19: May 24 08:29:49 localhost systemd[1]: Ignoring invalid environment 'export KRB5_KTNAME=/etc/dirsrv/ds.keytab': /etc/sysconfig/dirsrv Pushed as a one(two)-liner to master, ipa-3-2. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-408-avoid-exporting-krb5_ktname-in-dirsrv-env.patch Type: text/x-patch Size: 1918 bytes Desc: not available URL: From tbabej at redhat.com Fri May 24 13:26:22 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 24 May 2013 15:26:22 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <20130520142940.GR26689@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> Message-ID: <519F6A7E.306@redhat.com> On 05/20/2013 04:29 PM, Alexander Bokovoy wrote: > On Mon, 20 May 2013, Tomas Babej wrote: >> On 05/16/2013 11:16 AM, Ana Krivokapic wrote: >>> On 05/15/2013 03:41 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> When removing an ID range using idrange-del command, validation >>>> in pre_callback ensures that the range does not belong to any >>>> active trust. In such case, ValidationError is raised. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3615 >>>> >>>> Tomas >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> I suggest adding some unit tests to cover this change in functionality. >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> I incorporated the unit tests. It had to use direct access to LDAP >> using ldapmodify since we need to create a mock AD trusted range first. >> >> Tomas > We got rid of openldap utilities now. While using python.ldap module, I also made the tests much more robust and added a new test case. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0057-3-Do-not-allow-removal-of-ID-range-of-an-active-trust.patch Type: text/x-patch Size: 8849 bytes Desc: not available URL: From abokovoy at redhat.com Sun May 26 18:56:28 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 26 May 2013 21:56:28 +0300 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <519F6A7E.306@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> Message-ID: <20130526185628.GJ26689@redhat.com> On Fri, 24 May 2013, Tomas Babej wrote: >On 05/20/2013 04:29 PM, Alexander Bokovoy wrote: >>On Mon, 20 May 2013, Tomas Babej wrote: >>>On 05/16/2013 11:16 AM, Ana Krivokapic wrote: >>>>On 05/15/2013 03:41 PM, Tomas Babej wrote: >>>>>Hi, >>>>> >>>>>When removing an ID range using idrange-del command, validation >>>>>in pre_callback ensures that the range does not belong to any >>>>>active trust. In such case, ValidationError is raised. >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/3615 >>>>> >>>>>Tomas >>>>> >>>>> >>>>>_______________________________________________ >>>>>Freeipa-devel mailing list >>>>>Freeipa-devel at redhat.com >>>>>https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>>I suggest adding some unit tests to cover this change in functionality. >>>> >>>>-- >>>>Regards, >>>> >>>>Ana Krivokapic >>>>Associate Software Engineer >>>>FreeIPA team >>>>Red Hat Inc. >>>> >>>> >>>>_______________________________________________ >>>>Freeipa-devel mailing list >>>>Freeipa-devel at redhat.com >>>>https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>>I incorporated the unit tests. It had to use direct access to >>>LDAP using ldapmodify since we need to create a mock AD trusted >>>range first. >>> >>>Tomas >> >We got rid of openldap utilities now. While using python.ldap module, >I also made the tests much more robust and added a new test case. In general patches look fine, there is one small nitpick. I'll run tests on Monday and then will provide final ACK. >--- a/tests/test_xmlrpc/test_range_plugin.py >+++ b/tests/test_xmlrpc/test_range_plugin.py >@@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and XML-RPC in general. > """ > > from ipalib import api, errors, _ >+from ipapython.ipautil import run This import is unused, can be removed. -- / Alexander Bokovoy From tbabej at redhat.com Mon May 27 08:03:23 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 27 May 2013 10:03:23 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <20130526185628.GJ26689@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> Message-ID: <51A3134B.2060502@redhat.com> On 05/26/2013 08:56 PM, Alexander Bokovoy wrote: > On Fri, 24 May 2013, Tomas Babej wrote: >> On 05/20/2013 04:29 PM, Alexander Bokovoy wrote: >>> On Mon, 20 May 2013, Tomas Babej wrote: >>>> On 05/16/2013 11:16 AM, Ana Krivokapic wrote: >>>>> On 05/15/2013 03:41 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> When removing an ID range using idrange-del command, validation >>>>>> in pre_callback ensures that the range does not belong to any >>>>>> active trust. In such case, ValidationError is raised. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3615 >>>>>> >>>>>> Tomas >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> I suggest adding some unit tests to cover this change in >>>>> functionality. >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Ana Krivokapic >>>>> Associate Software Engineer >>>>> FreeIPA team >>>>> Red Hat Inc. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> I incorporated the unit tests. It had to use direct access to LDAP >>>> using ldapmodify since we need to create a mock AD trusted range >>>> first. >>>> >>>> Tomas >>> >> We got rid of openldap utilities now. While using python.ldap module, >> I also made the tests much more robust and added a new test case. > In general patches look fine, there is one small nitpick. > I'll run tests on Monday and then will provide final ACK. > >> --- a/tests/test_xmlrpc/test_range_plugin.py >> +++ b/tests/test_xmlrpc/test_range_plugin.py >> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and >> XML-RPC in general. >> """ >> >> from ipalib import api, errors, _ >> +from ipapython.ipautil import run > This import is unused, can be removed. > Fixed, thanks for catching that. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0057-4-Do-not-allow-removal-of-ID-range-of-an-active-trust.patch Type: text/x-patch Size: 8658 bytes Desc: not available URL: From tbabej at redhat.com Mon May 27 08:27:23 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 27 May 2013 10:27:23 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <51A3134B.2060502@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> Message-ID: <51A318EB.7000902@redhat.com> On 05/27/2013 10:03 AM, Tomas Babej wrote: > On 05/26/2013 08:56 PM, Alexander Bokovoy wrote: >> On Fri, 24 May 2013, Tomas Babej wrote: >>> On 05/20/2013 04:29 PM, Alexander Bokovoy wrote: >>>> On Mon, 20 May 2013, Tomas Babej wrote: >>>>> On 05/16/2013 11:16 AM, Ana Krivokapic wrote: >>>>>> On 05/15/2013 03:41 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> When removing an ID range using idrange-del command, validation >>>>>>> in pre_callback ensures that the range does not belong to any >>>>>>> active trust. In such case, ValidationError is raised. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3615 >>>>>>> >>>>>>> Tomas >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>>> I suggest adding some unit tests to cover this change in >>>>>> functionality. >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Ana Krivokapic >>>>>> Associate Software Engineer >>>>>> FreeIPA team >>>>>> Red Hat Inc. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> I incorporated the unit tests. It had to use direct access to LDAP >>>>> using ldapmodify since we need to create a mock AD trusted range >>>>> first. >>>>> >>>>> Tomas >>>> >>> We got rid of openldap utilities now. While using python.ldap >>> module, I also made the tests much more robust and added a new test >>> case. >> In general patches look fine, there is one small nitpick. >> I'll run tests on Monday and then will provide final ACK. >> >>> --- a/tests/test_xmlrpc/test_range_plugin.py >>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, >>> and XML-RPC in general. >>> """ >>> >>> from ipalib import api, errors, _ >>> +from ipapython.ipautil import run >> This import is unused, can be removed. >> > Fixed, thanks for catching that. > > Updated patch attached. > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Additionally, I removed one redundant variable upon further review. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0057-5-Do-not-allow-removal-of-ID-range-of-an-active-trust.patch Type: text/x-patch Size: 8636 bytes Desc: not available URL: From pspacek at redhat.com Mon May 27 08:41:06 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 27 May 2013 10:41:06 +0200 Subject: [Freeipa-devel] [Patchwork] command line client Message-ID: <51A31C22.6050806@redhat.com> Hello, see https://www.varnish-cache.org/patchwork/help/pwclient/ -- Petr^2 Spacek From pspacek at redhat.com Mon May 27 08:45:23 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 27 May 2013 10:45:23 +0200 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <51A31C22.6050806@redhat.com> References: <51A31C22.6050806@redhat.com> Message-ID: <51A31D23.4080106@redhat.com> Hello Simo, could you install/allow XMLRPC for our Patchwork, please? I found the CLI for Patchwork but it requires XMLRPC. On 27.5.2013 10:41, Petr Spacek wrote: > see https://www.varnish-cache.org/patchwork/help/pwclient/ -- Petr^2 Spacek From akrivoka at redhat.com Mon May 27 11:47:25 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 27 May 2013 13:47:25 +0200 Subject: [Freeipa-devel] [PATCH] 0222 Remove code to install Dogtag 9 In-Reply-To: <518D0A19.5040800@redhat.com> References: <518D0A19.5040800@redhat.com> Message-ID: <51A347CD.7050704@redhat.com> On 05/10/2013 04:54 PM, Petr Viktorin wrote: > Re-sending this patch as it should go into Work towards next release. > > > Since we depend on Dogtag 10 now, there is no need to keep code > that installs a Dogtag 9 CA. > > Support for upgraded Dogtag-9-style instances is left in. > > https://fedorahosted.org/freeipa/ticket/3529 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Works well, ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon May 27 12:38:23 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 27 May 2013 14:38:23 +0200 Subject: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show Message-ID: <51A353BF.1070807@redhat.com> Hi, In trust_show command, make sure that --raw flag is honoured. Attributes ipanttrusttype and ipanttrustdirection are no longer translated to strings from their raw ldap values when --raw is used. https://fedorahosted.org/freeipa/ticket/3525 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0060-Do-not-translate-trust-type-and-direction-with-raw-i.patch Type: text/x-patch Size: 1780 bytes Desc: not available URL: From akrivoka at redhat.com Mon May 27 13:04:05 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 27 May 2013 15:04:05 +0200 Subject: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show In-Reply-To: <51A353BF.1070807@redhat.com> References: <51A353BF.1070807@redhat.com> Message-ID: <51A359C5.6030905@redhat.com> On 05/27/2013 02:38 PM, Tomas Babej wrote: > Hi, > > In trust_show command, make sure that --raw flag is honoured. > Attributes ipanttrusttype and ipanttrustdirection are no longer > translated to strings from their raw ldap values when --raw is > used. > > https://fedorahosted.org/freeipa/ticket/3525 > > Tomas The patch causes these two attributes to not be displayed, when --raw switch is used: [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com Realm name: addomain.example.com Domain NetBIOS name: ADDOMAIN Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322 Trust direction: Two-way trust Trust type: Active Directory domain [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com --raw cn: addomain.example.com ipantflatname: ADDOMAIN ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From simo at redhat.com Mon May 27 13:57:49 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 27 May 2013 09:57:49 -0400 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <51A31D23.4080106@redhat.com> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> Message-ID: <1369663069.2769.81.camel@willson.li.ssimo.org> On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: > Hello Simo, > > could you install/allow XMLRPC for our Patchwork, please? > > I found the CLI for Patchwork but it requires XMLRPC. > > On 27.5.2013 10:41, Petr Spacek wrote: > > see https://www.varnish-cache.org/patchwork/help/pwclient/ > Should be enabled now. Btw, I may need to put the patchwork instance in maintenance mode on Wednesday. The extent of the outage will depend on the amount of work needed to replace a hard drive. Will try to keep the list posted. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon May 27 14:07:29 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 27 May 2013 16:07:29 +0200 Subject: [Freeipa-devel] [PATCHES 0156-0158] Automatically disable empty zones when necessary Message-ID: <51A368A1.9070102@redhat.com> Hello, this patch set enables bind-dyndb-ldap to automatically unload empty zone (see RFC 6303) if an explicit configuration for this zone is present in LDAP. Please test it with idnsZone and also idnsForwardZone objectClasses. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0156-Separate-generic-zone-removal-code-to-function-delet.patch Type: text/x-patch Size: 2718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0157-Automatically-unload-pre-defined-empty-zone-if-the-r.patch Type: text/x-patch Size: 2766 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0158-Automatically-unload-pre-defined-empty-zone-if-the-f.patch Type: text/x-patch Size: 2163 bytes Desc: not available URL: From tbabej at redhat.com Mon May 27 14:07:48 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 27 May 2013 16:07:48 +0200 Subject: [Freeipa-devel] [PATCH 0059] Make testcert automagically when needed by unit test In-Reply-To: <519F56CA.5030305@redhat.com> References: <519E4F0C.5040102@redhat.com> <519F1D7C.3000700@redhat.com> <519F56CA.5030305@redhat.com> Message-ID: <51A368B4.3010804@redhat.com> On 05/24/2013 02:02 PM, Petr Viktorin wrote: > On 05/24/2013 09:57 AM, Tomas Babej wrote: >> On 05/23/2013 07:17 PM, Tomas Babej wrote: >>> Hi, >>> >>> With this patch, there's no need to run make-testcert separately >>> before running make-test. Unit test framework will check whether >>> service.crt file exists, and if not, will generate one if needed. >>> >>> New location of service.crt file is in ~/.ipa directory. >>> >>> Part of https://fedorahosted.org/freeipa/ticket/3621 >>> >>> Tomas > > Thanks, it works well. > However it would be nice to not repeat this code in every test that > needs the cert: > > +servercert = '' > + > +# Create the testing server cert if it does not already exist > +# Returns True if successful, error message if not > +if not os.path.exists(testcert.CERTPATH): > + servercert_ret = testcert.main() > + > +if os.path.exists(testcert.CERTPATH): > + fd = open(testcert.CERTPATH, 'r') > + servercert = fd.readlines() > + servercert = ''.join(servercert) > + servercert = x509.strip_header(servercert) > + fd.close() > + > + > > Please put this in testcert.py and just call something like > `servercert = testcert.get_testcert()`. > > class test_host(Declarative): > > + def setUp(self): > + super(Declarative, self).setUp() > + if servercert == '': > + raise nose.SkipTest('Testcert generation problem: %s' % > + servercert_ret) > + > > Do we really want to skip the test here? IMO if we cannot generate the > cert, we should fail (`assert servercert`). > Thank you for the comments. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0059-3-Make-testcert-automagically-when-needed-by-unit-test.patch Type: text/x-patch Size: 9554 bytes Desc: not available URL: From pspacek at redhat.com Mon May 27 14:36:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 27 May 2013 16:36:26 +0200 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <1369663069.2769.81.camel@willson.li.ssimo.org> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> Message-ID: <51A36F6A.6020609@redhat.com> On 27.5.2013 15:57, Simo Sorce wrote: > On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: >> Hello Simo, >> >> could you install/allow XMLRPC for our Patchwork, please? >> >> I found the CLI for Patchwork but it requires XMLRPC. >> >> On 27.5.2013 10:41, Petr Spacek wrote: >>> see https://www.varnish-cache.org/patchwork/help/pwclient/ >> > > Should be enabled now. Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): xmlrpclib.ProtocolError: -- Petr^2 Spacek From simo at redhat.com Mon May 27 20:05:02 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 27 May 2013 16:05:02 -0400 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <51A36F6A.6020609@redhat.com> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> <51A36F6A.6020609@redhat.com> Message-ID: <1369685102.2769.93.camel@willson.li.ssimo.org> On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: > On 27.5.2013 15:57, Simo Sorce wrote: > > On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: > >> Hello Simo, > >> > >> could you install/allow XMLRPC for our Patchwork, please? > >> > >> I found the CLI for Patchwork but it requires XMLRPC. > >> > >> On 27.5.2013 10:41, Petr Spacek wrote: > >>> see https://www.varnish-cache.org/patchwork/help/pwclient/ > >> > > > > Should be enabled now. > > Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): > > xmlrpclib.ProtocolError: NOT FOUND> I've restarted the apahe server, apparently not all threads would see the new config w/o a full reload. Simo. -- Simo Sorce * Red Hat, Inc * New York From nicmac at gmail.com Tue May 28 07:28:50 2013 From: nicmac at gmail.com (Nicholas MacKenzie) Date: Tue, 28 May 2013 03:28:50 -0400 Subject: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket Message-ID: Hello, I have seen this happen on multiple fresh installs now. Can anyone shed any light on it? I am unable to add a trust because of this, I assume. An smbclient lookup against the DC works. ====================== # ipa trust-add --type=ad ad.dc.com --admin username --password Active directory domain administrator's password: ipa: ERROR: Cannot find specified domain or server name ====================== /var/log/httpd/error_log: [Tue May 28 07:05:01 2013] [error] ipa: INFO: admin at IPA.DC.COM: trust_add(u' ad.dc.sita.aero', trust_46'): NotFound ====================== # ipactl restart Restarting Directory Service Shutting down dirsrv: IPA-DC-COM. [ OK ] PKI-IPA... [ OK ] Starting dirsrv: IPA-DC-COM ...[28/May/2013:07:09:24 +0000] ipa_cldap_init_service - [file ipa_cldap.c, line 148]: Failed to create socket [28/May/2013:07:09:24 +0000] ipa_cldap_init - [file ipa_cldap.c, line 207]: Failed to initialize CLDAP Plugin ===================== # smbclient -L ad_server -U admin\\username lp_load_ex: changing to config backend registry Enter admin\username's password: Domain=[AD] OS=[Windows Server 2008 R2 Enterprise 7601 Service Pack 1] Server=[Windows Server 2008 R2 Enterprise 6.1] Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin Apps Disk C$ Disk Default share D$ Disk Default share Global Disk Install Disk IPC$ IPC Remote IPC NETLOGON Disk Logon server share P$ Disk Default share R$ Disk Default share Software$ Disk SYSVOL Disk Logon server share Domain=[AD] OS=[Windows Server 2008 R2 Enterprise 7601 Service Pack 1] Server=[Windows Server 2008 R2 Enterprise 6.1] Server Comment --------- ------- Workgroup Master --------- ------- Thanks! Nic -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue May 28 07:46:50 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 10:46:50 +0300 Subject: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket In-Reply-To: References: Message-ID: <20130528074650.GQ26689@redhat.com> On Tue, 28 May 2013, Nicholas MacKenzie wrote: >Hello, > >I have seen this happen on multiple fresh installs now. Can anyone shed any >light on it? I am unable to add a trust because of this, I assume. An >smbclient lookup against the DC works. >====================== ># ipa trust-add --type=ad ad.dc.com --admin username --password >Active directory domain administrator's password: >ipa: ERROR: Cannot find specified domain or server name >====================== >/var/log/httpd/error_log: >[Tue May 28 07:05:01 2013] [error] ipa: INFO: admin at IPA.DC.COM: trust_add(u' >ad.dc.sita.aero', trust_46'): NotFound >====================== ># ipactl restart >Restarting Directory Service >Shutting down dirsrv: > IPA-DC-COM. [ OK ] > PKI-IPA... [ OK ] >Starting dirsrv: > IPA-DC-COM ...[28/May/2013:07:09:24 +0000] ipa_cldap_init_service - >[file ipa_cldap.c, line 148]: Failed to create socket What operating system is that? Here is what we have in ipa_cldap.c: ctx->sd = socket(PF_INET6, SOCK_DGRAM, 0); if (ctx->sd == -1) { LOG_FATAL("Failed to create socket\n"); ret = EIO; goto done; } So we failed to create a socket using PF_INET6 family. It looks like you don't have IPv6 enabled in your kernel? -- / Alexander Bokovoy From nicmac at gmail.com Tue May 28 08:24:53 2013 From: nicmac at gmail.com (Nicholas MacKenzie) Date: Tue, 28 May 2013 04:24:53 -0400 Subject: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket In-Reply-To: <20130528074650.GQ26689@redhat.com> References: <20130528074650.GQ26689@redhat.com> Message-ID: You were spot on about that. I enabled IPv6 and now the CLDAP plugin installs fine. I am now faced with this... dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED Failed to bind to uuid 12345778-1234-abcd-ef00-0123456789ab for 12345778-1234-abcd-ef00-0123456789ab at ncacn_ip_tcp: domain_controller.ad.dc.com[49500] NT_STATUS_NET_WRITE_FAULT [Tue May 28 08:20:03 2013] [error] ipa: INFO: admin at IPA.DC.COM: trust_add(u' ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username', realm_passwd=u'********', range_size=200000, all=False, raw=False, version=u'2.46'): ACIError On Tue, May 28, 2013 at 3:46 AM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Nicholas MacKenzie wrote: > >> Hello, >> >> I have seen this happen on multiple fresh installs now. Can anyone shed >> any >> light on it? I am unable to add a trust because of this, I assume. An >> smbclient lookup against the DC works. >> ====================== >> # ipa trust-add --type=ad ad.dc.com --admin username --password >> Active directory domain administrator's password: >> ipa: ERROR: Cannot find specified domain or server name >> ====================== >> /var/log/httpd/error_log: >> [Tue May 28 07:05:01 2013] [error] ipa: INFO: admin at IPA.DC.COM: >> trust_add(u' >> ad.dc.sita.aero', trust_46'): NotFound >> ====================== >> # ipactl restart >> Restarting Directory Service >> Shutting down dirsrv: >> IPA-DC-COM. [ OK ] >> PKI-IPA... [ OK ] >> Starting dirsrv: >> IPA-DC-COM ...[28/May/2013:07:09:24 +0000] ipa_cldap_init_service - >> [file ipa_cldap.c, line 148]: Failed to create socket >> > What operating system is that? > > Here is what we have in ipa_cldap.c: > ctx->sd = socket(PF_INET6, SOCK_DGRAM, 0); > if (ctx->sd == -1) { > LOG_FATAL("Failed to create socket\n"); > ret = EIO; > goto done; > } > > So we failed to create a socket using PF_INET6 family. It looks like you > don't have IPv6 enabled in your kernel? > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicmac at gmail.com Tue May 28 08:28:36 2013 From: nicmac at gmail.com (Nicholas MacKenzie) Date: Tue, 28 May 2013 04:28:36 -0400 Subject: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket In-Reply-To: References: <20130528074650.GQ26689@redhat.com> Message-ID: Nevermind. I used the Administrator account and all is well. This is a lovely site. Added Active Directory trust for realm "ad.dc.com" -------------------------------------------------------- Realm name: ad.dc.com Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-1226121717-3896983829-760149474 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified On Tue, May 28, 2013 at 4:24 AM, Nicholas MacKenzie wrote: > You were spot on about that. I enabled IPv6 and now the CLDAP plugin > installs fine. I am now faced with this... > > dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED > Failed to bind to uuid 12345778-1234-abcd-ef00-0123456789ab for > 12345778-1234-abcd-ef00-0123456789ab at ncacn_ip_tcp: > domain_controller.ad.dc.com[49500] NT_STATUS_NET_WRITE_FAULT > [Tue May 28 08:20:03 2013] [error] ipa: INFO: admin at IPA.DC.COM: > trust_add(u'ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username', > realm_passwd=u'********', range_size=200000, all=False, raw=False, > version=u'2.46'): ACIError > > > > On Tue, May 28, 2013 at 3:46 AM, Alexander Bokovoy wrote: > >> On Tue, 28 May 2013, Nicholas MacKenzie wrote: >> >>> Hello, >>> >>> I have seen this happen on multiple fresh installs now. Can anyone shed >>> any >>> light on it? I am unable to add a trust because of this, I assume. An >>> smbclient lookup against the DC works. >>> ====================== >>> # ipa trust-add --type=ad ad.dc.com --admin username --password >>> Active directory domain administrator's password: >>> ipa: ERROR: Cannot find specified domain or server name >>> ====================== >>> /var/log/httpd/error_log: >>> [Tue May 28 07:05:01 2013] [error] ipa: INFO: admin at IPA.DC.COM: >>> trust_add(u' >>> ad.dc.sita.aero', trust_46'): NotFound >>> ====================== >>> # ipactl restart >>> Restarting Directory Service >>> Shutting down dirsrv: >>> IPA-DC-COM. [ OK ] >>> PKI-IPA... [ OK ] >>> Starting dirsrv: >>> IPA-DC-COM ...[28/May/2013:07:09:24 +0000] ipa_cldap_init_service - >>> [file ipa_cldap.c, line 148]: Failed to create socket >>> >> What operating system is that? >> >> Here is what we have in ipa_cldap.c: >> ctx->sd = socket(PF_INET6, SOCK_DGRAM, 0); >> if (ctx->sd == -1) { >> LOG_FATAL("Failed to create socket\n"); >> ret = EIO; >> goto done; >> } >> >> So we failed to create a socket using PF_INET6 family. It looks like you >> don't have IPv6 enabled in your kernel? >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue May 28 08:30:42 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 11:30:42 +0300 Subject: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket In-Reply-To: References: <20130528074650.GQ26689@redhat.com> Message-ID: <20130528083042.GR26689@redhat.com> On Tue, 28 May 2013, Nicholas MacKenzie wrote: >You were spot on about that. I enabled IPv6 and now the CLDAP plugin >installs fine. I am now faced with this... > >dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED >Failed to bind to uuid 12345778-1234-abcd-ef00-0123456789ab for >12345778-1234-abcd-ef00-0123456789ab at ncacn_ip_tcp: >domain_controller.ad.dc.com[49500] NT_STATUS_NET_WRITE_FAULT >[Tue May 28 08:20:03 2013] [error] ipa: INFO: admin at IPA.DC.COM: trust_add(u' >ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username', >realm_passwd=u'********', range_size=200000, all=False, raw=False, >version=u'2.46'): ACIError Specify your AD admin username fully-qualified, either DOMAIN\username or username at REALM. -- / Alexander Bokovoy From pspacek at redhat.com Tue May 28 08:38:17 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 28 May 2013 10:38:17 +0200 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <1369685102.2769.93.camel@willson.li.ssimo.org> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> <51A36F6A.6020609@redhat.com> <1369685102.2769.93.camel@willson.li.ssimo.org> Message-ID: <51A46CF9.8040004@redhat.com> On 27.5.2013 22:05, Simo Sorce wrote: > On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: >> On 27.5.2013 15:57, Simo Sorce wrote: >>> On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: >>>> Hello Simo, >>>> >>>> could you install/allow XMLRPC for our Patchwork, please? >>>> >>>> I found the CLI for Patchwork but it requires XMLRPC. >>>> >>>> On 27.5.2013 10:41, Petr Spacek wrote: >>>>> see https://www.varnish-cache.org/patchwork/help/pwclient/ >>>> >>> >>> Should be enabled now. >> >> Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): >> >> xmlrpclib.ProtocolError: > NOT FOUND> > > I've restarted the apahe server, apparently not all threads would see > the new config w/o a full reload. I confirm that it works now. BTW did you considered migration to freeipa.org? :-) -- Petr^2 Spacek From thozza at redhat.com Tue May 28 08:44:38 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 28 May 2013 04:44:38 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0155] Fix IPv6 handling in PTR record synchronization In-Reply-To: <51948F35.1010408@redhat.com> References: <51948F35.1010408@redhat.com> Message-ID: <60029332.4612034.1369730678231.JavaMail.root@redhat.com> ACK The patch looks good and works as expected. Regards, Tomas Hozza ----- Original Message ----- > Hello, > > Fix IPv6 handling in PTR record synchronization. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/118 > > -- > Petr^2 Spacek > From mkosek at redhat.com Tue May 28 08:46:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 28 May 2013 10:46:09 +0200 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <51A46CF9.8040004@redhat.com> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> <51A36F6A.6020609@redhat.com> <1369685102.2769.93.camel@willson.li.ssimo.org> <51A46CF9.8040004@redhat.com> Message-ID: <51A46ED1.1060906@redhat.com> On 05/28/2013 10:38 AM, Petr Spacek wrote: > On 27.5.2013 22:05, Simo Sorce wrote: >> On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: >>> On 27.5.2013 15:57, Simo Sorce wrote: >>>> On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: >>>>> Hello Simo, >>>>> >>>>> could you install/allow XMLRPC for our Patchwork, please? >>>>> >>>>> I found the CLI for Patchwork but it requires XMLRPC. >>>>> >>>>> On 27.5.2013 10:41, Petr Spacek wrote: >>>>>> see https://www.varnish-cache.org/patchwork/help/pwclient/ >>>>> >>>> >>>> Should be enabled now. >>> >>> Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): >>> >>> xmlrpclib.ProtocolError: >> NOT FOUND> >> >> I've restarted the apahe server, apparently not all threads would see >> the new config w/o a full reload. > > I confirm that it works now. BTW did you considered migration to freeipa.org? :-) We could eventually migrate it to OpenShift just like FreeIPA.org's mediawiki site. As patchwork is based on Django which is common on OpenShift, it should not be so difficult. We could then create alias patchwork.freeipa.org if we want to use it. Martin From tbabej at redhat.com Tue May 28 11:20:04 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 28 May 2013 13:20:04 +0200 Subject: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show In-Reply-To: <51A359C5.6030905@redhat.com> References: <51A353BF.1070807@redhat.com> <51A359C5.6030905@redhat.com> Message-ID: <51A492E4.4050707@redhat.com> On 05/27/2013 03:04 PM, Ana Krivokapic wrote: > On 05/27/2013 02:38 PM, Tomas Babej wrote: >> Hi, >> >> In trust_show command, make sure that --raw flag is honoured. >> Attributes ipanttrusttype and ipanttrustdirection are no longer >> translated to strings from their raw ldap values when --raw is >> used. >> >> https://fedorahosted.org/freeipa/ticket/3525 >> >> Tomas > The patch causes these two attributes to not be displayed, when --raw > switch is used: > > [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com > Realm name: addomain.example.com > Domain NetBIOS name: ADDOMAIN > Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322 > Trust direction: Two-way trust > Trust type: Active Directory domain > > [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com --raw > cn: addomain.example.com > ipantflatname: ADDOMAIN > ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322 > Thanks. Updated patch attached. I modified trust-find according to the new behaviour. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0060-2-Do-not-translate-trust-type-and-direction-with-raw-i.patch Type: text/x-patch Size: 3557 bytes Desc: not available URL: From abokovoy at redhat.com Tue May 28 11:50:59 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 14:50:59 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts Message-ID: <20130528115059.GS26689@redhat.com> Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD > 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn at REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn at REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) -- / Alexander Bokovoy From simo at redhat.com Tue May 28 12:12:09 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 28 May 2013 08:12:09 -0400 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <51A46ED1.1060906@redhat.com> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> <51A36F6A.6020609@redhat.com> <1369685102.2769.93.camel@willson.li.ssimo.org> <51A46CF9.8040004@redhat.com> <51A46ED1.1060906@redhat.com> Message-ID: <1369743129.2769.94.camel@willson.li.ssimo.org> On Tue, 2013-05-28 at 10:46 +0200, Martin Kosek wrote: > On 05/28/2013 10:38 AM, Petr Spacek wrote: > > On 27.5.2013 22:05, Simo Sorce wrote: > >> On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: > >>> On 27.5.2013 15:57, Simo Sorce wrote: > >>>> On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: > >>>>> Hello Simo, > >>>>> > >>>>> could you install/allow XMLRPC for our Patchwork, please? > >>>>> > >>>>> I found the CLI for Patchwork but it requires XMLRPC. > >>>>> > >>>>> On 27.5.2013 10:41, Petr Spacek wrote: > >>>>>> see https://www.varnish-cache.org/patchwork/help/pwclient/ > >>>>> > >>>> > >>>> Should be enabled now. > >>> > >>> Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): > >>> > >>> xmlrpclib.ProtocolError: >>> NOT FOUND> > >> > >> I've restarted the apahe server, apparently not all threads would see > >> the new config w/o a full reload. > > > > I confirm that it works now. BTW did you considered migration to freeipa.org? :-) > > We could eventually migrate it to OpenShift just like FreeIPA.org's mediawiki > site. As patchwork is based on Django which is common on OpenShift, it should > not be so difficult. We could then create alias patchwork.freeipa.org if we > want to use it. Yup, I think we should do it, Petr are you ihnterested in comaintainng it if we move it to an OpenShift instance ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Tue May 28 12:12:36 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 28 May 2013 14:12:36 +0200 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130528115059.GS26689@redhat.com> References: <20130528115059.GS26689@redhat.com> Message-ID: <20130528121236.GE4551@hendrix.brq.redhat.com> On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: > = Dependencies = > > Depends on SSSD implementing IPA server mode (sssd 1.10.x) Nitpick -- currently this is planned for 1.11 From abokovoy at redhat.com Tue May 28 12:35:13 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 15:35:13 +0300 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <51A318EB.7000902@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> <51A318EB.7000902@redhat.com> Message-ID: <20130528123513.GT26689@redhat.com> On Mon, 27 May 2013, Tomas Babej wrote: >>>> We got rid of openldap utilities now. While using python.ldap >>>> module, I also made the tests much more robust and added a new >>>> test case. >>> In general patches look fine, there is one small nitpick. >>> I'll run tests on Monday and then will provide final ACK. >>> >>>> --- a/tests/test_xmlrpc/test_range_plugin.py >>>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` >>>> module, and XML-RPC in general. >>>> """ >>>> >>>> from ipalib import api, errors, _ >>>> +from ipapython.ipautil import run >>> This import is unused, can be removed. >>> >> Fixed, thanks for catching that. >> >> Updated patch attached. So I tried to run this test on a machine where there is already trust established and I think there should be done some changes. Probably it would be wise to add pre-start procedure to pull existing ranges and define constants for the ranges so that they don't overlap with existing ones. Perhaps selecting something from a top of the range space... Attached is the log. -- / Alexander Bokovoy -------------- next part -------------- test_range pre-cleanup[0]: ('idrange_del', [u'testrange1', u'testrange2', u'testrange3', u'testrange4', u'testrange5', u'testrange6', u'testrange7', u'testrange8'], {'continue': True}) ... ok test_range pre-cleanup[1]: ('user_del', [u'tuser1'], {}) ... ok test_range pre-cleanup[2]: ('group_del', [u'group1'], {}) ... ok test_range[0]: idrange_add: Create ID range u'testrange1' ... ERROR test_range[1]: idrange_show: Retrieve ID range u'testrange1' ... ERROR test_range[2]: user_add: Create user u'tuser1' in ID range u'testrange1' ... ok test_range[3]: group_add: Create group u'group1' in ID range u'testrange1' ... ok test_range[4]: idrange_mod: Try to modify ID range u'testrange1' to get out bounds object #1 ... FAIL test_range[5]: idrange_mod: Try to modify ID range u'testrange1' to get out bounds object #2 ... FAIL test_range[6]: idrange_mod: Try to modify ID range u'testrange1' to get out bounds object #3 ... FAIL test_range[7]: idrange_mod: Modify ID range u'testrange1' ... ERROR test_range[8]: idrange_del: Try to delete ID range u'testrange1' with active IDs inside it ... FAIL test_range[9]: user_del: Delete user u'tuser1' ... ok test_range[10]: group_del: Delete group u'group1' ... ok test_range[11]: idrange_del: Delete ID range u'testrange1' ... ERROR test_range[12]: idrange_add: Create ID range u'testrange2' ... ERROR test_range[13]: idrange_mod: Try to modify ID range u'testrange2' so that its rid ranges are overlapping themselves ... FAIL test_range[14]: idrange_add: Try to create ID range u'testrange3' with overlapping rid range ... FAIL test_range[15]: idrange_add: Try to create ID range u'testrange4' with overlapping secondary rid range ... FAIL test_range[16]: idrange_add: Try to create ID range u'testrange5' with primary range overlapping secondary rid range ... FAIL test_range[17]: idrange_add: Try to create ID range u'testrange6' with overlapping id range ... FAIL test_range[18]: idrange_add: Try to create ID range u'testrange7' with rid ranges overlapping themselves ... ok test_range[19]: idrange_del: Delete ID range u'testrange2' ... ERROR test_range[20]: idrange_add: Create ID range u'testrange8' ... ok test_range[21]: idrange_mod: Try to modify ID range u'testrange8' so it has only primary rid range set ... ok test_range[22]: idrange_del: Delete ID range u'testrange8' ... ok test_range[23]: idrange_del: Delete non-active AD trusted range u'testrange9' ... ok test_range[24]: idrange_del: Try to delete active AD trusted range u'testrange10' ... ok test_range post-cleanup[0]: ('idrange_del', [u'testrange1', u'testrange2', u'testrange3', u'testrange4', u'testrange5', u'testrange6', u'testrange7', u'testrange8'], {'continue': True}) ... ok test_range post-cleanup[1]: ('user_del', [u'tuser1'], {}) ... ok test_range post-cleanup[2]: ('group_del', [u'group1'], {}) ... ok ====================================================================== ERROR: test_range[0]: idrange_add: Create ID range u'testrange1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 289, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 326, in check_output got = api.Command[cmd](*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 735, in run return self.forward(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 756, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/rpc.py", line 712, in forward raise error(message=e.faultString) DatabaseError: Constraint violation: New primary rid range overlaps with existing primary rid range. ====================================================================== ERROR: test_range[1]: idrange_show: Retrieve ID range u'testrange1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 289, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 326, in check_output got = api.Command[cmd](*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 735, in run return self.forward(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 756, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/rpc.py", line 712, in forward raise error(message=e.faultString) NotFound: testrange1: range not found ====================================================================== ERROR: test_range[7]: idrange_mod: Modify ID range u'testrange1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 289, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 326, in check_output got = api.Command[cmd](*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 735, in run return self.forward(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 756, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/rpc.py", line 712, in forward raise error(message=e.faultString) NotFound: testrange1: range not found ====================================================================== ERROR: test_range[11]: idrange_del: Delete ID range u'testrange1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 289, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 326, in check_output got = api.Command[cmd](*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 735, in run return self.forward(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 756, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/rpc.py", line 712, in forward raise error(message=e.faultString) NotFound: testrange1: range not found ====================================================================== ERROR: test_range[12]: idrange_add: Create ID range u'testrange2' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 289, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 326, in check_output got = api.Command[cmd](*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 735, in run return self.forward(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 756, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/rpc.py", line 712, in forward raise error(message=e.faultString) DatabaseError: Constraint violation: New secondary rid range overlaps with existing primary rid range. ====================================================================== ERROR: test_range[19]: idrange_del: Delete ID range u'testrange2' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 289, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 326, in check_output got = api.Command[cmd](*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 735, in run return self.forward(*args, **options) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/frontend.py", line 756, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/ipalib/rpc.py", line 712, in forward raise error(message=e.faultString) NotFound: testrange2: range not found ====================================================================== FAIL: test_range[4]: idrange_mod: Try to modify ID range u'testrange1' to get out bounds object #1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 304, in check_exception UNEXPECTED % (cmd, name, args, options, e.__class__.__name__, e) AssertionError: Expected 'idrange_mod' to raise ValidationError, but caught different. args = [u'testrange1'] options = {'ipabaseid': 90001, 'version': u'2.58'} NotFound: testrange1: range not found ====================================================================== FAIL: test_range[5]: idrange_mod: Try to modify ID range u'testrange1' to get out bounds object #2 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 304, in check_exception UNEXPECTED % (cmd, name, args, options, e.__class__.__name__, e) AssertionError: Expected 'idrange_mod' to raise ValidationError, but caught different. args = [u'testrange1'] options = {'version': u'2.58', 'ipaidrangesize': 100} NotFound: testrange1: range not found ====================================================================== FAIL: test_range[6]: idrange_mod: Try to modify ID range u'testrange1' to get out bounds object #3 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 304, in check_exception UNEXPECTED % (cmd, name, args, options, e.__class__.__name__, e) AssertionError: Expected 'idrange_mod' to raise ValidationError, but caught different. args = [u'testrange1'] options = {'ipabaseid': 100, 'version': u'2.58', 'ipaidrangesize': 100} NotFound: testrange1: range not found ====================================================================== FAIL: test_range[8]: idrange_del: Try to delete ID range u'testrange1' with active IDs inside it ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 304, in check_exception UNEXPECTED % (cmd, name, args, options, e.__class__.__name__, e) AssertionError: Expected 'idrange_del' to raise ValidationError, but caught different. args = [u'testrange1'] options = {'version': u'2.58'} NotFound: testrange1: range not found ====================================================================== FAIL: test_range[13]: idrange_mod: Try to modify ID range u'testrange2' so that its rid ranges are overlapping themselves ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 304, in check_exception UNEXPECTED % (cmd, name, args, options, e.__class__.__name__, e) AssertionError: Expected 'idrange_mod' to raise ValidationError, but caught different. args = [u'testrange2'] options = {'ipabaserid': 1000, 'version': u'2.58'} NotFound: testrange2: range not found ====================================================================== FAIL: test_range[14]: idrange_add: Try to create ID range u'testrange3' with overlapping rid range ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 311, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/util.py", line 348, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u'Constraint violation: New primary rid range overlaps with existing primary rid range.' got = u'Constraint violation: New secondary rid range overlaps with existing primary rid range.' path = () ====================================================================== FAIL: test_range[15]: idrange_add: Try to create ID range u'testrange4' with overlapping secondary rid range ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 311, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/util.py", line 348, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u'Constraint violation: New secondary rid range overlaps with existing secondary rid range.' got = u'Constraint violation: New secondary rid range overlaps with existing primary rid range.' path = () ====================================================================== FAIL: test_range[16]: idrange_add: Try to create ID range u'testrange5' with primary range overlapping secondary rid range ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 311, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/util.py", line 348, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u'Constraint violation: New primary rid range overlaps with existing secondary rid range.' got = u'Constraint violation: New primary rid range overlaps with existing primary rid range.' path = () ====================================================================== FAIL: test_range[17]: idrange_add: Try to create ID range u'testrange6' with overlapping id range ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 271, in func = lambda: self.check(nice, **test) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 285, in check self.check_exception(nice, cmd, args, options, expected) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/test_xmlrpc/xmlrpc_test.py", line 311, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/root/rpmbuild/BUILD/freeipa-3.2.99GIT1a3f0f1/tests/util.py", line 348, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u'Constraint violation: New base range overlaps with existing base range.' got = u'Constraint violation: New secondary rid range overlaps with existing primary rid range.' path = () ---------------------------------------------------------------------- Ran 31 tests in 4.891s FAILED (errors=6, failures=9) From abokovoy at redhat.com Tue May 28 12:35:51 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 15:35:51 +0300 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <1369336335.2769.58.camel@willson.li.ssimo.org> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> <20130523180204.GG26689@redhat.com> <1369336004.2769.56.camel@willson.li.ssimo.org> <1369336335.2769.58.camel@willson.li.ssimo.org> Message-ID: <20130528123550.GU26689@redhat.com> On Thu, 23 May 2013, Simo Sorce wrote: >> > As you can see, incorrect parameters still return empty dn and netlogon >> > attributes while Windows Server 2012 returns empty response: >> > >> > $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon >> > version: 1 >> > >> > Yet, since for trusts we care about explicit request with our domain name _and_ the >> > case when DnsDomain is not specified, everything continues to work. >> > >> > So ACK. >> >> I can easily avoid returning the empty netlogon field, which is what I >> wanted to do. >> I'll see if I can also avoid returning the DN. >> >> Let me try just one more revision. > >It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY >completely as they were supposed to, and only return a >LDAP_RES_SEARCH_RESULT record. Thanks. Tested and it works fine. -- / Alexander Bokovoy From tbabej at redhat.com Tue May 28 13:27:37 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 28 May 2013 15:27:37 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <20130528123513.GT26689@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> <51A318EB.7000902@redhat.com> <20130528123513.GT26689@redhat.com> Message-ID: <51A4B0C9.40005@redhat.com> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: > On Mon, 27 May 2013, Tomas Babej wrote: >>>>> We got rid of openldap utilities now. While using python.ldap >>>>> module, I also made the tests much more robust and added a new >>>>> test case. >>>> In general patches look fine, there is one small nitpick. >>>> I'll run tests on Monday and then will provide final ACK. >>>> >>>>> --- a/tests/test_xmlrpc/test_range_plugin.py >>>>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>>>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, >>>>> and XML-RPC in general. >>>>> """ >>>>> >>>>> from ipalib import api, errors, _ >>>>> +from ipapython.ipautil import run >>>> This import is unused, can be removed. >>>> >>> Fixed, thanks for catching that. >>> >>> Updated patch attached. > So I tried to run this test on a machine where there is already trust > established and I think there should be done some changes. I perused the log. Seems that the failures you're experiencing are not relevant to the patch itself, since the newly added tests passed. This is problem with test_range_plugin.py tests that has been there for quite a while, the parameters of the ranges such as size, and base ID/RID/secondary RID are hardcoded in the test case. > Probably it would be wise to add pre-start procedure to pull existing > ranges and define constants for the ranges so that they don't overlap > with existing ones. Perhaps selecting something from a top of the range > space... > > Attached is the log I agree. This has not been relevant until now, since we did not do much testing on IPA instances with trusts set up, and even then there's random factor in having the overlap with the already created trust range. I'd propose fixing this in a separate effort as a part of continouous integration improvements. I see it as a separate issue of its own. What do you think? Tomas From abokovoy at redhat.com Tue May 28 13:48:34 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 16:48:34 +0300 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <51A4B0C9.40005@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> <51A318EB.7000902@redhat.com> <20130528123513.GT26689@redhat.com> <51A4B0C9.40005@redhat.com> Message-ID: <20130528134833.GX26689@redhat.com> On Tue, 28 May 2013, Tomas Babej wrote: >On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>On Mon, 27 May 2013, Tomas Babej wrote: >>>>>>We got rid of openldap utilities now. While using >>>>>>python.ldap module, I also made the tests much more robust >>>>>>and added a new test case. >>>>>In general patches look fine, there is one small nitpick. >>>>>I'll run tests on Monday and then will provide final ACK. >>>>> >>>>>>--- a/tests/test_xmlrpc/test_range_plugin.py >>>>>>+++ b/tests/test_xmlrpc/test_range_plugin.py >>>>>>@@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` >>>>>>module, and XML-RPC in general. >>>>>>""" >>>>>> >>>>>>from ipalib import api, errors, _ >>>>>>+from ipapython.ipautil import run >>>>>This import is unused, can be removed. >>>>> >>>>Fixed, thanks for catching that. >>>> >>>>Updated patch attached. >>So I tried to run this test on a machine where there is already trust >>established and I think there should be done some changes. > >I perused the log. Seems that the failures you're experiencing are >not relevant to the patch itself, >since the newly added tests passed. > >This is problem with test_range_plugin.py tests that has been there >for quite a while, the parameters >of the ranges such as size, and base ID/RID/secondary RID are >hardcoded in the test case. Yep. >>Probably it would be wise to add pre-start procedure to pull existing >>ranges and define constants for the ranges so that they don't overlap >>with existing ones. Perhaps selecting something from a top of the range >>space... >> >>Attached is the log > >I agree. This has not been relevant until now, since we did not do >much testing on IPA instances >with trusts set up, and even then there's random factor in having the >overlap with the already created >trust range. > >I'd propose fixing this in a separate effort as a part of continouous >integration improvements. I see it >as a separate issue of its own. > >What do you think? Please file a separate ticket then. ACK for this one. -- / Alexander Bokovoy From pspacek at redhat.com Tue May 28 13:55:48 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 28 May 2013 15:55:48 +0200 Subject: [Freeipa-devel] [PATCH 0159] Deprecate configuration without persistent search Message-ID: <51A4B764.7040301@redhat.com> Hello, Deprecate configuration without persistent search. https://fedorahosted.org/bind-dyndb-ldap/ticket/120 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0159-Deprecate-configuration-without-persistent-search.patch Type: text/x-patch Size: 1084 bytes Desc: not available URL: From mkosek at redhat.com Tue May 28 14:12:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 28 May 2013 16:12:38 +0200 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <20130528123550.GU26689@redhat.com> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> <20130523180204.GG26689@redhat.com> <1369336004.2769.56.camel@willson.li.ssimo.org> <1369336335.2769.58.camel@willson.li.ssimo.org> <20130528123550.GU26689@redhat.com> Message-ID: <51A4BB56.9050700@redhat.com> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: > On Thu, 23 May 2013, Simo Sorce wrote: >>> > As you can see, incorrect parameters still return empty dn and netlogon >>> > attributes while Windows Server 2012 returns empty response: >>> > >>> > $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base >>> '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon >>> > version: 1 >>> > >>> > Yet, since for trusts we care about explicit request with our domain name >>> _and_ the >>> > case when DnsDomain is not specified, everything continues to work. >>> > >>> > So ACK. >>> >>> I can easily avoid returning the empty netlogon field, which is what I >>> wanted to do. >>> I'll see if I can also avoid returning the DN. >>> >>> Let me try just one more revision. >> >> It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY >> completely as they were supposed to, and only return a >> LDAP_RES_SEARCH_RESULT record. > Thanks. > > Tested and it works fine. > ACK. Pushed to master, ipa-3-1, ipa-3-0. I will release 3.1.5 soon to Fedora 18 to fix cooperation with realmd. Martin From mkosek at redhat.com Tue May 28 14:13:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 28 May 2013 16:13:51 +0200 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <51A4BB56.9050700@redhat.com> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> <20130523180204.GG26689@redhat.com> <1369336004.2769.56.camel@willson.li.ssimo.org> <1369336335.2769.58.camel@willson.li.ssimo.org> <20130528123550.GU26689@redhat.com> <51A4BB56.9050700@redhat.com> Message-ID: <51A4BB9F.8010505@redhat.com> On 05/28/2013 04:12 PM, Martin Kosek wrote: > On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >> On Thu, 23 May 2013, Simo Sorce wrote: >>>>> As you can see, incorrect parameters still return empty dn and netlogon >>>>> attributes while Windows Server 2012 returns empty response: >>>>> >>>>> $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base >>>> '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon >>>>> version: 1 >>>>> >>>>> Yet, since for trusts we care about explicit request with our domain name >>>> _and_ the >>>>> case when DnsDomain is not specified, everything continues to work. >>>>> >>>>> So ACK. >>>> >>>> I can easily avoid returning the empty netlogon field, which is what I >>>> wanted to do. >>>> I'll see if I can also avoid returning the DN. >>>> >>>> Let me try just one more revision. >>> >>> It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY >>> completely as they were supposed to, and only return a >>> LDAP_RES_SEARCH_RESULT record. >> Thanks. >> >> Tested and it works fine. >> > > ACK. Pushed to master, ipa-3-1, ipa-3-0. Sorry, off-by-one error :-) The actual branches where I pushed this were master, ipa-3-2 and ipa-3-1. Martin > > I will release 3.1.5 soon to Fedora 18 to fix cooperation with realmd. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From pviktori at redhat.com Tue May 28 14:37:20 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 28 May 2013 16:37:20 +0200 Subject: [Freeipa-devel] [PATCH 0059] Make testcert automagically when needed by unit test In-Reply-To: <51A368B4.3010804@redhat.com> References: <519E4F0C.5040102@redhat.com> <519F1D7C.3000700@redhat.com> <519F56CA.5030305@redhat.com> <51A368B4.3010804@redhat.com> Message-ID: <51A4C120.8090808@redhat.com> On 05/27/2013 04:07 PM, Tomas Babej wrote: > On 05/24/2013 02:02 PM, Petr Viktorin wrote: >> On 05/24/2013 09:57 AM, Tomas Babej wrote: >>> On 05/23/2013 07:17 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> With this patch, there's no need to run make-testcert separately >>>> before running make-test. Unit test framework will check whether >>>> service.crt file exists, and if not, will generate one if needed. >>>> >>>> New location of service.crt file is in ~/.ipa directory. >>>> >>>> Part of https://fedorahosted.org/freeipa/ticket/3621 >>>> >>>> Tomas >> >> Thanks, it works well. >> However it would be nice to not repeat this code in every test that >> needs the cert: >> >> +servercert = '' >> + >> +# Create the testing server cert if it does not already exist >> +# Returns True if successful, error message if not >> +if not os.path.exists(testcert.CERTPATH): >> + servercert_ret = testcert.main() >> + >> +if os.path.exists(testcert.CERTPATH): >> + fd = open(testcert.CERTPATH, 'r') >> + servercert = fd.readlines() >> + servercert = ''.join(servercert) >> + servercert = x509.strip_header(servercert) >> + fd.close() >> + >> + >> >> Please put this in testcert.py and just call something like >> `servercert = testcert.get_testcert()`. >> >> class test_host(Declarative): >> >> + def setUp(self): >> + super(Declarative, self).setUp() >> + if servercert == '': >> + raise nose.SkipTest('Testcert generation problem: %s' % >> + servercert_ret) >> + >> >> Do we really want to skip the test here? IMO if we cannot generate the >> cert, we should fail (`assert servercert`). >> > Thank you for the comments. > > Updated patch attached. > > Tomas Okay, I ran it again. Please also remove make-testcert from the Makefile. I now get lots of errors from the test suite, starting with these: cannot connect to 'https://vm-050.idm.lab.bos.redhat.com:443/ca/eeca/ca/profileSubmitSSLClient': [Errno -8054] (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. Does this not happen in your setup? -- Petr? From akrivoka at redhat.com Tue May 28 14:49:42 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 28 May 2013 16:49:42 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists Message-ID: <51A4C406.5000206@redhat.com> Hello, This patch addresses https://fedorahosted.org/freeipa/ticket/3634 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0030-Require-rid-base-and-secondary-rid-base-options-in-i.patch Type: text/x-patch Size: 5194 bytes Desc: not available URL: From mkosek at redhat.com Tue May 28 15:21:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 28 May 2013 17:21:50 +0200 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <51A4BB9F.8010505@redhat.com> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> <20130523180204.GG26689@redhat.com> <1369336004.2769.56.camel@willson.li.ssimo.org> <1369336335.2769.58.camel@willson.li.ssimo.org> <20130528123550.GU26689@redhat.com> <51A4BB56.9050700@redhat.com> <51A4BB9F.8010505@redhat.com> Message-ID: <51A4CB8E.9000005@redhat.com> On 05/28/2013 04:13 PM, Martin Kosek wrote: > On 05/28/2013 04:12 PM, Martin Kosek wrote: >> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>> On Thu, 23 May 2013, Simo Sorce wrote: >>>>>> As you can see, incorrect parameters still return empty dn and netlogon >>>>>> attributes while Windows Server 2012 returns empty response: >>>>>> >>>>>> $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base >>>>> '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon >>>>>> version: 1 >>>>>> >>>>>> Yet, since for trusts we care about explicit request with our domain name >>>>> _and_ the >>>>>> case when DnsDomain is not specified, everything continues to work. >>>>>> >>>>>> So ACK. >>>>> >>>>> I can easily avoid returning the empty netlogon field, which is what I >>>>> wanted to do. >>>>> I'll see if I can also avoid returning the DN. >>>>> >>>>> Let me try just one more revision. >>>> >>>> It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY >>>> completely as they were supposed to, and only return a >>>> LDAP_RES_SEARCH_RESULT record. >>> Thanks. >>> >>> Tested and it works fine. >>> >> >> ACK. Pushed to master, ipa-3-1, ipa-3-0. > > Sorry, off-by-one error :-) The actual branches where I pushed this were > master, ipa-3-2 and ipa-3-1. > > Martin > >> >> I will release 3.1.5 soon to Fedora 18 to fix cooperation with realmd. >> >> Martin >> I just noticed a strange behavior when I was sanity testing upcoming 3.1.5 release: # ldapsearch -LL -H cldap://vm-037.idm.lab.bos.redhat.com -b "" -s base '(&(DnsDomain=foo)(NtVer=\06\00\00\00)(AAC=\00\00\00\00))' version: 1 # ... this looks correct. But following call hangs: # ldapsearch -LL -H cldap://vm-037.idm.lab.bos.redhat.com -b "" -s base '(NtVer=\06\00\00\00)' version: 1 ^C This does not look right. Am I doing something wrong? Martin From akrivoka at redhat.com Tue May 28 15:32:27 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 28 May 2013 17:32:27 +0200 Subject: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show In-Reply-To: <51A492E4.4050707@redhat.com> References: <51A353BF.1070807@redhat.com> <51A359C5.6030905@redhat.com> <51A492E4.4050707@redhat.com> Message-ID: <51A4CE0B.4030105@redhat.com> On 05/28/2013 01:20 PM, Tomas Babej wrote: > On 05/27/2013 03:04 PM, Ana Krivokapic wrote: >> On 05/27/2013 02:38 PM, Tomas Babej wrote: >>> Hi, >>> >>> In trust_show command, make sure that --raw flag is honoured. >>> Attributes ipanttrusttype and ipanttrustdirection are no longer >>> translated to strings from their raw ldap values when --raw is >>> used. >>> >>> https://fedorahosted.org/freeipa/ticket/3525 >>> >>> Tomas >> The patch causes these two attributes to not be displayed, when --raw >> switch is used: >> >> [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com >> Realm name: addomain.example.com >> Domain NetBIOS name: ADDOMAIN >> Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322 >> Trust direction: Two-way trust >> Trust type: Active Directory domain >> >> [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com --raw >> cn: addomain.example.com >> ipantflatname: ADDOMAIN >> ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322 >> > Thanks. Updated patch attached. > > I modified trust-find according to the new behaviour. > > Tomas > > Works nicely. Please just amend the commit message to mention that the trust-find command is also affected. ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pviktori at redhat.com Tue May 28 15:55:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 28 May 2013 17:55:28 +0200 Subject: [Freeipa-devel] [PATCHES] 0227-0229 freeipa-tests package & Beaker integration plugin Message-ID: <51A4D370.6030307@redhat.com> Hello, Patch 0227 creates the freeipa-tests package. As a system package, it needs a more unique name than "tests", so I renamed it to "ipatests". I also changed imports and references to it. Sorry to everyone developing tests right now ?? there will be conflicts, but hopefully they'll be straightforward. Note that the test suite does not yet pass when run outside the Git tree. Work on that is ongoing but not a priority right now (it's more important to get some integration tests running). Help would be appreciated :) Patch 0228 adds a wrapper based on make-test which runs the system-installed test suite. freeipa-tests installs it as /usr/bin/ipa-run-tests. As I said above the tests currently fail when run this way. Patch 0229 adds a Nose plugin for integration with BeakerLib[1]. When the plugin is loaded (ipa-run-tests does that) and enabled (using the --with-beakerlib option), it hooks into Nose and runs rlPhase*, rlPass, rlFail and rlLog* Bash functions at appropriate events. To test, I do this: On Fedora 19, modify /etc/fedora-release to remove the ? and ? characters, otherwise you'll get an UnicodeDecodeError from BeakerLib's XML journal backend (BZ#700525). sudo yum install beakerlib . /usr/share/beakerlib/beakerlib.sh ( rlJournalStart; ipa-run-tests --with-beakerlib test_ipalib/test_backend.py; python -c 'print "="*100' rlJournalPrintText --full-journal; rlJournalEnd) You can run any other test, of course, but test_backend should be fairly portable, and one of the tests shows off the logging integration. [1] https://fedorahosted.org/beakerlib/ -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0227-Make-an-ipa-tests-package.patch Type: text/x-patch Size: 71146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0228-Add-ipa-run-tests-command.patch Type: text/x-patch Size: 2517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0229-Add-Nose-plugin-for-BeakerLib-integration.patch Type: text/x-patch Size: 11056 bytes Desc: not available URL: From simo at redhat.com Tue May 28 16:19:49 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 28 May 2013 12:19:49 -0400 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <1369663069.2769.81.camel@willson.li.ssimo.org> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> Message-ID: <1369757989.2769.112.camel@willson.li.ssimo.org> On Mon, 2013-05-27 at 09:57 -0400, Simo Sorce wrote: > On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: > > Hello Simo, > > > > could you install/allow XMLRPC for our Patchwork, please? > > > > I found the CLI for Patchwork but it requires XMLRPC. > > > > On 27.5.2013 10:41, Petr Spacek wrote: > > > see https://www.varnish-cache.org/patchwork/help/pwclient/ > > > > Should be enabled now. > > Btw, I may need to put the patchwork instance in maintenance mode on > Wednesday. The extent of the outage will depend on the amount of work > needed to replace a hard drive. > > Will try to keep the list posted. Server is now down for maintenance. Should be up in a few hours. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue May 28 18:46:29 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 28 May 2013 14:46:29 -0400 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <1369757989.2769.112.camel@willson.li.ssimo.org> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> <1369757989.2769.112.camel@willson.li.ssimo.org> Message-ID: <1369766789.2769.113.camel@willson.li.ssimo.org> On Tue, 2013-05-28 at 12:19 -0400, Simo Sorce wrote: > On Mon, 2013-05-27 at 09:57 -0400, Simo Sorce wrote: > > On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: > > > Hello Simo, > > > > > > could you install/allow XMLRPC for our Patchwork, please? > > > > > > I found the CLI for Patchwork but it requires XMLRPC. > > > > > > On 27.5.2013 10:41, Petr Spacek wrote: > > > > see https://www.varnish-cache.org/patchwork/help/pwclient/ > > > > > > > Should be enabled now. > > > > Btw, I may need to put the patchwork instance in maintenance mode on > > Wednesday. The extent of the outage will depend on the amount of work > > needed to replace a hard drive. > > > > Will try to keep the list posted. > > > Server is now down for maintenance. > > Should be up in a few hours. The server is back up. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue May 28 19:28:24 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 28 May 2013 15:28:24 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130528115059.GS26689@redhat.com> References: <20130528115059.GS26689@redhat.com> Message-ID: <51A50558.50704@redhat.com> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: > Hi, > > > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > = Overview = > > Since version 3.0 FreeIPA supports cross-realm trusts with Active > Directory. In order to allow AD users to utilize services on IPA > clients, up to date version of SSSD should be configured at the IPA > client. In case it is not possible to install and configure SSSD > 1.09, > Active Directory users cannot access services on IPA clients. > > This feature is designed to bridge the gap and provide minimal > compatibility level that allows to log-in to IPA clients for AD users. > IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd > version. > = Use Cases = > > Access to IPA client machine resources for AD users in case IPA client > cannot utilize up to date version of SSSD with native support for IPA > cross-realm trusts. > > = Design= > Since IPA client is configured with the use of older SSSD or > nss_ldap/pam_ldap, all work should be performed at the IPA master. > Primary design decision is to provide a separate LDAP tree, similar to > compat tree, that has following features: > > * information about both IPA and AD users can be queried; > * it ispossible to enumerate members of IPA and AD groups; > * authentication bind to IPA LDAP as AD users should automatically > * trigger obtaining ticket from AD DC; in case TGT is obtained, > * authentication bind should be treated as successful. > > From a client perspective, use of the separate LDAP tree is viewed as > traditional nss_ldap/pam_ldap configuration. > > Proposed base for the LDAP tree: > '''cn=users,cn=trust-accounts,dc=example,dc=com''' > > = Implementation = > > # IPA server sets SSSD configuration to 'ipa_server_mode = true' on > install or upgrade > # ipa-adtrust-install configures additional directory server plugin to > serve trusted domains tree > # Directory server plugin uses getpwnam_r(), getgrnam_r() and related > calls to obtain information about AD user. For IPA users the > information is fetched directly from the LDAP. > # IPA KDC database driver adds MS-PAC information into ticket granting > ticket for host/fqdn at REALM principal of IPA master. This is required > to allow SSSD on IPA master to authenticate against AD using > host/fqdn at REALM principal. > > For SSSD design see > https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > > = Feature Management = > > === UI === > > The feature is transparent and not exposed in UI > > === CLI === > > The feature is not directly exposed in CLI. > IPA idrange management is expanded to specify idrange type (IPA local, > AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users > SIDs are mapped to POSIX IDs. > > = Major configuration options and enablement = > > sssd.conf will have 'ipa_server_mode = true' set for IPA master. > > = Replication = > > No effect on replication. Since directory server plugin is only > configured when ipa-adtrust-install is run, IPA masters may opt out from > serving AD clients. > > = Updates and Upgrades = > > During upgrade of IPA master, sssd.conf should be updated to set > 'ipa_server_mode = true'. > > = Dependencies = > > Depends on SSSD implementing IPA server mode (sssd 1.10.x) > > = External Impact = > > https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > > = Backup and Restore = > > No external configuration files are affected > > = Test Plan = > > Testing the feature will require following: > > # Configure IPA to serve AD trusts > # Establish trust with AD domain > # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree > # Attempt to log-in to the client as AD user > > = RFE Author = > > [[User:Ab|ab]] ([[User talk:Ab|talk]]) > Can you please explain how the older SSSD or other UNIX versions would use Kerberos for authentication? I thought we would have to issue some patch for client to switch the clients from using Kerberos for authentication to using LDAP. Alternatively we should modify KDC to use the new extop and go though the SSSD on the IPA side but I do not see it mentioned anywhere. Can we get a bit more clarity about the Kerberos authentication workflow? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Tue May 28 19:48:31 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 22:48:31 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <51A50558.50704@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> Message-ID: <20130528194831.GY26689@redhat.com> On Tue, 28 May 2013, Dmitri Pal wrote: >On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: >> Hi, >> >> >> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >> >> = Overview = >> >> Since version 3.0 FreeIPA supports cross-realm trusts with Active >> Directory. In order to allow AD users to utilize services on IPA >> clients, up to date version of SSSD should be configured at the IPA >> client. In case it is not possible to install and configure SSSD > 1.09, >> Active Directory users cannot access services on IPA clients. >> >> This feature is designed to bridge the gap and provide minimal >> compatibility level that allows to log-in to IPA clients for AD users. >> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >> version. >> = Use Cases = >> >> Access to IPA client machine resources for AD users in case IPA client >> cannot utilize up to date version of SSSD with native support for IPA >> cross-realm trusts. >> >> = Design= >> Since IPA client is configured with the use of older SSSD or >> nss_ldap/pam_ldap, all work should be performed at the IPA master. >> Primary design decision is to provide a separate LDAP tree, similar to >> compat tree, that has following features: >> >> * information about both IPA and AD users can be queried; >> * it ispossible to enumerate members of IPA and AD groups; >> * authentication bind to IPA LDAP as AD users should automatically >> * trigger obtaining ticket from AD DC; in case TGT is obtained, >> * authentication bind should be treated as successful. >> >> From a client perspective, use of the separate LDAP tree is viewed as >> traditional nss_ldap/pam_ldap configuration. >> >> Proposed base for the LDAP tree: >> '''cn=users,cn=trust-accounts,dc=example,dc=com''' >> >> = Implementation = >> >> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on >> install or upgrade >> # ipa-adtrust-install configures additional directory server plugin to >> serve trusted domains tree >> # Directory server plugin uses getpwnam_r(), getgrnam_r() and related >> calls to obtain information about AD user. For IPA users the >> information is fetched directly from the LDAP. >> # IPA KDC database driver adds MS-PAC information into ticket granting >> ticket for host/fqdn at REALM principal of IPA master. This is required >> to allow SSSD on IPA master to authenticate against AD using >> host/fqdn at REALM principal. >> >> For SSSD design see >> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >> >> = Feature Management = >> >> === UI === >> >> The feature is transparent and not exposed in UI >> >> === CLI === >> >> The feature is not directly exposed in CLI. >> IPA idrange management is expanded to specify idrange type (IPA local, >> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users >> SIDs are mapped to POSIX IDs. >> >> = Major configuration options and enablement = >> >> sssd.conf will have 'ipa_server_mode = true' set for IPA master. >> >> = Replication = >> >> No effect on replication. Since directory server plugin is only >> configured when ipa-adtrust-install is run, IPA masters may opt out from >> serving AD clients. >> >> = Updates and Upgrades = >> >> During upgrade of IPA master, sssd.conf should be updated to set >> 'ipa_server_mode = true'. >> >> = Dependencies = >> >> Depends on SSSD implementing IPA server mode (sssd 1.10.x) >> >> = External Impact = >> >> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >> >> = Backup and Restore = >> >> No external configuration files are affected >> >> = Test Plan = >> >> Testing the feature will require following: >> >> # Configure IPA to serve AD trusts >> # Establish trust with AD domain >> # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree >> # Attempt to log-in to the client as AD user >> >> = RFE Author = >> >> [[User:Ab|ab]] ([[User talk:Ab|talk]]) >> > > >Can you please explain how the older SSSD or other UNIX versions would >use Kerberos for authentication? pam_krb5 should work as it is, as well as older SSSD, since any AD user attempting to connect using GSSAPI to IPA services will have cross-realm TGT issued for us by the trusting AD DC prior to that attempt. The whole idea was to make sure for old clients these users will look like normal users, via nss_ldap/SSSD. We still will need to configure principal mapping in /etc/krb5.conf like we do for AD users with trusts. >I thought we would have to issue some patch for client to switch the >clients from using Kerberos for authentication to using LDAP. No need to. pam_ldap would go through LDAP bind automatically, that's why the proposal talks about attempting to obtain TGT in place of a user instead of proxying such LDAP bind back to AD DC. This would require us enforcing clear password bind over TLS/SSL but it is simpler to achieve. -- / Alexander Bokovoy From dpal at redhat.com Tue May 28 20:14:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 28 May 2013 16:14:42 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130528194831.GY26689@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> Message-ID: <51A51032.4090502@redhat.com> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Dmitri Pal wrote: >> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: >>> Hi, >>> >>> >>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >>> >>> = Overview = >>> >>> Since version 3.0 FreeIPA supports cross-realm trusts with Active >>> Directory. In order to allow AD users to utilize services on IPA >>> clients, up to date version of SSSD should be configured at the IPA >>> client. In case it is not possible to install and configure SSSD > >>> 1.09, >>> Active Directory users cannot access services on IPA clients. >>> >>> This feature is designed to bridge the gap and provide minimal >>> compatibility level that allows to log-in to IPA clients for AD users. >>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >>> version. >>> = Use Cases = >>> >>> Access to IPA client machine resources for AD users in case IPA client >>> cannot utilize up to date version of SSSD with native support for IPA >>> cross-realm trusts. >>> >>> = Design= >>> Since IPA client is configured with the use of older SSSD or >>> nss_ldap/pam_ldap, all work should be performed at the IPA master. >>> Primary design decision is to provide a separate LDAP tree, similar to >>> compat tree, that has following features: >>> >>> * information about both IPA and AD users can be queried; >>> * it ispossible to enumerate members of IPA and AD groups; >>> * authentication bind to IPA LDAP as AD users should automatically >>> * trigger obtaining ticket from AD DC; in case TGT is obtained, >>> * authentication bind should be treated as successful. >>> >>> From a client perspective, use of the separate LDAP tree is viewed as >>> traditional nss_ldap/pam_ldap configuration. >>> >>> Proposed base for the LDAP tree: >>> '''cn=users,cn=trust-accounts,dc=example,dc=com''' >>> >>> = Implementation = >>> >>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on >>> install or upgrade >>> # ipa-adtrust-install configures additional directory server plugin to >>> serve trusted domains tree >>> # Directory server plugin uses getpwnam_r(), getgrnam_r() and related >>> calls to obtain information about AD user. For IPA users the >>> information is fetched directly from the LDAP. >>> # IPA KDC database driver adds MS-PAC information into ticket granting >>> ticket for host/fqdn at REALM principal of IPA master. This is required >>> to allow SSSD on IPA master to authenticate against AD using >>> host/fqdn at REALM principal. >>> >>> For SSSD design see >>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>> >>> = Feature Management = >>> >>> === UI === >>> >>> The feature is transparent and not exposed in UI >>> >>> === CLI === >>> >>> The feature is not directly exposed in CLI. >>> IPA idrange management is expanded to specify idrange type (IPA local, >>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD >>> users >>> SIDs are mapped to POSIX IDs. >>> >>> = Major configuration options and enablement = >>> >>> sssd.conf will have 'ipa_server_mode = true' set for IPA master. >>> >>> = Replication = >>> >>> No effect on replication. Since directory server plugin is only >>> configured when ipa-adtrust-install is run, IPA masters may opt out >>> from >>> serving AD clients. >>> >>> = Updates and Upgrades = >>> >>> During upgrade of IPA master, sssd.conf should be updated to set >>> 'ipa_server_mode = true'. >>> >>> = Dependencies = >>> >>> Depends on SSSD implementing IPA server mode (sssd 1.10.x) >>> >>> = External Impact = >>> >>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>> >>> = Backup and Restore = >>> >>> No external configuration files are affected >>> >>> = Test Plan = >>> >>> Testing the feature will require following: >>> >>> # Configure IPA to serve AD trusts >>> # Establish trust with AD domain >>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible >>> tree >>> # Attempt to log-in to the client as AD user >>> >>> = RFE Author = >>> >>> [[User:Ab|ab]] ([[User talk:Ab|talk]]) >>> >> >> >> Can you please explain how the older SSSD or other UNIX versions would >> use Kerberos for authentication? > pam_krb5 should work as it is, as well as older SSSD, since any AD user > attempting to connect using GSSAPI to IPA services will have cross-realm > TGT issued for us by the trusting AD DC prior to that attempt. > > The whole idea was to make sure for old clients these users will look > like normal users, via nss_ldap/SSSD. > > We still will need to configure principal mapping in /etc/krb5.conf like > we do for AD users with trusts. > >> I thought we would have to issue some patch for client to switch the >> clients from using Kerberos for authentication to using LDAP. > No need to. pam_ldap would go through LDAP bind automatically, that's > why the proposal talks about attempting to obtain TGT in place of a user > instead of proxying such LDAP bind back to AD DC. This would require us > enforcing clear password bind over TLS/SSL but it is simpler to achieve. > I am missing something. How a simple kinit would work? Can you please describe the sequence and workflow? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Tue May 28 20:29:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 May 2013 23:29:00 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <51A51032.4090502@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> Message-ID: <20130528202900.GZ26689@redhat.com> On Tue, 28 May 2013, Dmitri Pal wrote: >On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >> On Tue, 28 May 2013, Dmitri Pal wrote: >>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> >>>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >>>> >>>> = Overview = >>>> >>>> Since version 3.0 FreeIPA supports cross-realm trusts with Active >>>> Directory. In order to allow AD users to utilize services on IPA >>>> clients, up to date version of SSSD should be configured at the IPA >>>> client. In case it is not possible to install and configure SSSD > >>>> 1.09, >>>> Active Directory users cannot access services on IPA clients. >>>> >>>> This feature is designed to bridge the gap and provide minimal >>>> compatibility level that allows to log-in to IPA clients for AD users. >>>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >>>> version. >>>> = Use Cases = >>>> >>>> Access to IPA client machine resources for AD users in case IPA client >>>> cannot utilize up to date version of SSSD with native support for IPA >>>> cross-realm trusts. >>>> >>>> = Design= >>>> Since IPA client is configured with the use of older SSSD or >>>> nss_ldap/pam_ldap, all work should be performed at the IPA master. >>>> Primary design decision is to provide a separate LDAP tree, similar to >>>> compat tree, that has following features: >>>> >>>> * information about both IPA and AD users can be queried; >>>> * it ispossible to enumerate members of IPA and AD groups; >>>> * authentication bind to IPA LDAP as AD users should automatically >>>> * trigger obtaining ticket from AD DC; in case TGT is obtained, >>>> * authentication bind should be treated as successful. >>>> >>>> From a client perspective, use of the separate LDAP tree is viewed as >>>> traditional nss_ldap/pam_ldap configuration. >>>> >>>> Proposed base for the LDAP tree: >>>> '''cn=users,cn=trust-accounts,dc=example,dc=com''' >>>> >>>> = Implementation = >>>> >>>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on >>>> install or upgrade >>>> # ipa-adtrust-install configures additional directory server plugin to >>>> serve trusted domains tree >>>> # Directory server plugin uses getpwnam_r(), getgrnam_r() and related >>>> calls to obtain information about AD user. For IPA users the >>>> information is fetched directly from the LDAP. >>>> # IPA KDC database driver adds MS-PAC information into ticket granting >>>> ticket for host/fqdn at REALM principal of IPA master. This is required >>>> to allow SSSD on IPA master to authenticate against AD using >>>> host/fqdn at REALM principal. >>>> >>>> For SSSD design see >>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>> >>>> = Feature Management = >>>> >>>> === UI === >>>> >>>> The feature is transparent and not exposed in UI >>>> >>>> === CLI === >>>> >>>> The feature is not directly exposed in CLI. >>>> IPA idrange management is expanded to specify idrange type (IPA local, >>>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD >>>> users >>>> SIDs are mapped to POSIX IDs. >>>> >>>> = Major configuration options and enablement = >>>> >>>> sssd.conf will have 'ipa_server_mode = true' set for IPA master. >>>> >>>> = Replication = >>>> >>>> No effect on replication. Since directory server plugin is only >>>> configured when ipa-adtrust-install is run, IPA masters may opt out >>>> from >>>> serving AD clients. >>>> >>>> = Updates and Upgrades = >>>> >>>> During upgrade of IPA master, sssd.conf should be updated to set >>>> 'ipa_server_mode = true'. >>>> >>>> = Dependencies = >>>> >>>> Depends on SSSD implementing IPA server mode (sssd 1.10.x) >>>> >>>> = External Impact = >>>> >>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>> >>>> = Backup and Restore = >>>> >>>> No external configuration files are affected >>>> >>>> = Test Plan = >>>> >>>> Testing the feature will require following: >>>> >>>> # Configure IPA to serve AD trusts >>>> # Establish trust with AD domain >>>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible >>>> tree >>>> # Attempt to log-in to the client as AD user >>>> >>>> = RFE Author = >>>> >>>> [[User:Ab|ab]] ([[User talk:Ab|talk]]) >>>> >>> >>> >>> Can you please explain how the older SSSD or other UNIX versions would >>> use Kerberos for authentication? >> pam_krb5 should work as it is, as well as older SSSD, since any AD user >> attempting to connect using GSSAPI to IPA services will have cross-realm >> TGT issued for us by the trusting AD DC prior to that attempt. >> >> The whole idea was to make sure for old clients these users will look >> like normal users, via nss_ldap/SSSD. >> >> We still will need to configure principal mapping in /etc/krb5.conf like >> we do for AD users with trusts. >> >>> I thought we would have to issue some patch for client to switch the >>> clients from using Kerberos for authentication to using LDAP. >> No need to. pam_ldap would go through LDAP bind automatically, that's >> why the proposal talks about attempting to obtain TGT in place of a user >> instead of proxying such LDAP bind back to AD DC. This would require us >> enforcing clear password bind over TLS/SSL but it is simpler to achieve. >> >I am missing something. How a simple kinit would work? >Can you please describe the sequence and workflow? I'm talking about the case when AD user logs in into IPA client using PuTTY from Windows machine. In such case there is already service ticket and cross-realm TGT available. For kinit on IPA client all what is needed is /etc/krb5.conf configuration that forces to talk to AD DC for principals in AD realm. It can be done via SRV records in DNS or manually in /etc/krb5.conf. For example, on the machine I'm writing this email I added manual routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do following: # klist klist: No credentials cache found (ticket cache DIR::/run/user/0/krb5cc/tkt) # kinit Administrator at AD.LAN Password for Administrator at AD.LAN: Warning: Your password will expire in 2 days on ??. 31 ??? 2013 07:29:10 # klist Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO Default principal: Administrator at AD.LAN Valid starting Expires Service principal 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN renew until 04.06.2013 23:24:44 # kvno HTTP/red.bird.clone at BIRD.CLONE HTTP/red.bird.clone at BIRD.CLONE: kvno = 2 # klist Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO Default principal: Administrator at AD.LAN Valid starting Expires Service principal 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN renew until 04.06.2013 23:24:44 28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/BIRD.CLONE at AD.LAN renew until 04.06.2013 23:24:44 28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone at BIRD.CLONE renew until 04.06.2013 23:24:44 -- / Alexander Bokovoy From dpal at redhat.com Tue May 28 23:37:04 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 28 May 2013 19:37:04 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130528202900.GZ26689@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> Message-ID: <51A53FA0.6060305@redhat.com> On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Dmitri Pal wrote: >> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >>> On Tue, 28 May 2013, Dmitri Pal wrote: >>>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> >>>>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >>>>> >>>>> = Overview = >>>>> >>>>> Since version 3.0 FreeIPA supports cross-realm trusts with Active >>>>> Directory. In order to allow AD users to utilize services on IPA >>>>> clients, up to date version of SSSD should be configured at the IPA >>>>> client. In case it is not possible to install and configure SSSD > >>>>> 1.09, >>>>> Active Directory users cannot access services on IPA clients. >>>>> >>>>> This feature is designed to bridge the gap and provide minimal >>>>> compatibility level that allows to log-in to IPA clients for AD >>>>> users. >>>>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >>>>> version. >>>>> = Use Cases = >>>>> >>>>> Access to IPA client machine resources for AD users in case IPA >>>>> client >>>>> cannot utilize up to date version of SSSD with native support for IPA >>>>> cross-realm trusts. >>>>> >>>>> = Design= >>>>> Since IPA client is configured with the use of older SSSD or >>>>> nss_ldap/pam_ldap, all work should be performed at the IPA master. >>>>> Primary design decision is to provide a separate LDAP tree, >>>>> similar to >>>>> compat tree, that has following features: >>>>> >>>>> * information about both IPA and AD users can be queried; >>>>> * it ispossible to enumerate members of IPA and AD groups; >>>>> * authentication bind to IPA LDAP as AD users should automatically >>>>> * trigger obtaining ticket from AD DC; in case TGT is obtained, >>>>> * authentication bind should be treated as successful. >>>>> >>>>> From a client perspective, use of the separate LDAP tree is viewed as >>>>> traditional nss_ldap/pam_ldap configuration. >>>>> >>>>> Proposed base for the LDAP tree: >>>>> '''cn=users,cn=trust-accounts,dc=example,dc=com''' >>>>> >>>>> = Implementation = >>>>> >>>>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on >>>>> install or upgrade >>>>> # ipa-adtrust-install configures additional directory server >>>>> plugin to >>>>> serve trusted domains tree >>>>> # Directory server plugin uses getpwnam_r(), getgrnam_r() and >>>>> related >>>>> calls to obtain information about AD user. For IPA users the >>>>> information is fetched directly from the LDAP. >>>>> # IPA KDC database driver adds MS-PAC information into ticket >>>>> granting >>>>> ticket for host/fqdn at REALM principal of IPA master. This is required >>>>> to allow SSSD on IPA master to authenticate against AD using >>>>> host/fqdn at REALM principal. >>>>> >>>>> For SSSD design see >>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>>> >>>>> = Feature Management = >>>>> >>>>> === UI === >>>>> >>>>> The feature is transparent and not exposed in UI >>>>> >>>>> === CLI === >>>>> >>>>> The feature is not directly exposed in CLI. >>>>> IPA idrange management is expanded to specify idrange type (IPA >>>>> local, >>>>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD >>>>> users >>>>> SIDs are mapped to POSIX IDs. >>>>> >>>>> = Major configuration options and enablement = >>>>> >>>>> sssd.conf will have 'ipa_server_mode = true' set for IPA master. >>>>> >>>>> = Replication = >>>>> >>>>> No effect on replication. Since directory server plugin is only >>>>> configured when ipa-adtrust-install is run, IPA masters may opt out >>>>> from >>>>> serving AD clients. >>>>> >>>>> = Updates and Upgrades = >>>>> >>>>> During upgrade of IPA master, sssd.conf should be updated to set >>>>> 'ipa_server_mode = true'. >>>>> >>>>> = Dependencies = >>>>> >>>>> Depends on SSSD implementing IPA server mode (sssd 1.10.x) >>>>> >>>>> = External Impact = >>>>> >>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>>> >>>>> = Backup and Restore = >>>>> >>>>> No external configuration files are affected >>>>> >>>>> = Test Plan = >>>>> >>>>> Testing the feature will require following: >>>>> >>>>> # Configure IPA to serve AD trusts >>>>> # Establish trust with AD domain >>>>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible >>>>> tree >>>>> # Attempt to log-in to the client as AD user >>>>> >>>>> = RFE Author = >>>>> >>>>> [[User:Ab|ab]] ([[User talk:Ab|talk]]) >>>>> >>>> >>>> >>>> Can you please explain how the older SSSD or other UNIX versions would >>>> use Kerberos for authentication? >>> pam_krb5 should work as it is, as well as older SSSD, since any AD user >>> attempting to connect using GSSAPI to IPA services will have >>> cross-realm >>> TGT issued for us by the trusting AD DC prior to that attempt. >>> >>> The whole idea was to make sure for old clients these users will look >>> like normal users, via nss_ldap/SSSD. >>> >>> We still will need to configure principal mapping in /etc/krb5.conf >>> like >>> we do for AD users with trusts. >>> >>>> I thought we would have to issue some patch for client to switch the >>>> clients from using Kerberos for authentication to using LDAP. >>> No need to. pam_ldap would go through LDAP bind automatically, that's >>> why the proposal talks about attempting to obtain TGT in place of a >>> user >>> instead of proxying such LDAP bind back to AD DC. This would require us >>> enforcing clear password bind over TLS/SSL but it is simpler to >>> achieve. >>> >> I am missing something. How a simple kinit would work? >> Can you please describe the sequence and workflow? > I'm talking about the case when AD user logs in into IPA client using > PuTTY from Windows machine. In such case there is already service ticket > and cross-realm TGT available. > > For kinit on IPA client all what is needed is /etc/krb5.conf > configuration that forces to talk to AD DC for principals in AD realm. > > It can be done via SRV records in DNS or manually in /etc/krb5.conf. > > For example, on the machine I'm writing this email I added manual > routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do > following: > > # klist > klist: No credentials cache found (ticket cache > DIR::/run/user/0/krb5cc/tkt) > # kinit Administrator at AD.LAN > Password for Administrator at AD.LAN: Warning: Your password will expire > in 2 days on ??. 31 ??? 2013 07:29:10 > # klist > Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO > Default principal: Administrator at AD.LAN > > Valid starting Expires Service principal > 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN > renew until 04.06.2013 23:24:44 > # kvno HTTP/red.bird.clone at BIRD.CLONE > HTTP/red.bird.clone at BIRD.CLONE: kvno = 2 > # klist > Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO > Default principal: Administrator at AD.LAN > > Valid starting Expires Service principal > 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN > renew until 04.06.2013 23:24:44 > 28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/BIRD.CLONE at AD.LAN > renew until 04.06.2013 23:24:44 > 28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone at BIRD.CLONE > renew until 04.06.2013 23:24:44 > This is exactly the problem I am try to get to. Let us take CentOS 6.3 machine and configure SSSD against IPA. It has absolutely no knowledge about AD. This is the whole point. But AD users should be able to walk to the console and authenticate. The flow will be: User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD But there is no design for such flow. And IMO it is too much. What you are suggesting here is a sort of "split brain solution" that we did not recommend in the past are we going to change out assessment of this approach? But even if we say that we allow older SSSD to talk to AD directly how we configure SSSD to know about AD. The changes that you suggest need to be done on the older clients so do we need to issue patches for them? Is so that should be covered in the design. I was thinking that since we can't really do User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD because it is too much we would patch the client to configure LDAP + LDAP instead of Kerberos + LDAP. In this case the LDAP server on IPA would talk to SSSD as we designed. Same would work for other UNIXes. Yes this is a limitation but also a reason to adopt latest client. But I am open to alternatives. But they need to be clearly spelled out. So to summarize we are talking about the case: a) Legacy/UNIX systems are configured to authenticate/joined to IPA and do not know about AD b) User from AD walks to the console and uses his name and password He needs to be authenticated. How? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Wed May 29 05:38:37 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 29 May 2013 08:38:37 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <51A53FA0.6060305@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> Message-ID: <20130529053837.GA26689@redhat.com> On Tue, 28 May 2013, Dmitri Pal wrote: >On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: >> On Tue, 28 May 2013, Dmitri Pal wrote: >>> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >>>> On Tue, 28 May 2013, Dmitri Pal wrote: >>>>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >>>>>> >>>>>> = Overview = >>>>>> >>>>>> Since version 3.0 FreeIPA supports cross-realm trusts with Active >>>>>> Directory. In order to allow AD users to utilize services on IPA >>>>>> clients, up to date version of SSSD should be configured at the IPA >>>>>> client. In case it is not possible to install and configure SSSD > >>>>>> 1.09, >>>>>> Active Directory users cannot access services on IPA clients. >>>>>> >>>>>> This feature is designed to bridge the gap and provide minimal >>>>>> compatibility level that allows to log-in to IPA clients for AD >>>>>> users. >>>>>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >>>>>> version. >>>>>> = Use Cases = >>>>>> >>>>>> Access to IPA client machine resources for AD users in case IPA >>>>>> client >>>>>> cannot utilize up to date version of SSSD with native support for IPA >>>>>> cross-realm trusts. >>>>>> >>>>>> = Design= >>>>>> Since IPA client is configured with the use of older SSSD or >>>>>> nss_ldap/pam_ldap, all work should be performed at the IPA master. >>>>>> Primary design decision is to provide a separate LDAP tree, >>>>>> similar to >>>>>> compat tree, that has following features: >>>>>> >>>>>> * information about both IPA and AD users can be queried; >>>>>> * it ispossible to enumerate members of IPA and AD groups; >>>>>> * authentication bind to IPA LDAP as AD users should automatically >>>>>> * trigger obtaining ticket from AD DC; in case TGT is obtained, >>>>>> * authentication bind should be treated as successful. >>>>>> >>>>>> From a client perspective, use of the separate LDAP tree is viewed as >>>>>> traditional nss_ldap/pam_ldap configuration. >>>>>> >>>>>> Proposed base for the LDAP tree: >>>>>> '''cn=users,cn=trust-accounts,dc=example,dc=com''' >>>>>> >>>>>> = Implementation = >>>>>> >>>>>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on >>>>>> install or upgrade >>>>>> # ipa-adtrust-install configures additional directory server >>>>>> plugin to >>>>>> serve trusted domains tree >>>>>> # Directory server plugin uses getpwnam_r(), getgrnam_r() and >>>>>> related >>>>>> calls to obtain information about AD user. For IPA users the >>>>>> information is fetched directly from the LDAP. >>>>>> # IPA KDC database driver adds MS-PAC information into ticket >>>>>> granting >>>>>> ticket for host/fqdn at REALM principal of IPA master. This is required >>>>>> to allow SSSD on IPA master to authenticate against AD using >>>>>> host/fqdn at REALM principal. >>>>>> >>>>>> For SSSD design see >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>>>> >>>>>> = Feature Management = >>>>>> >>>>>> === UI === >>>>>> >>>>>> The feature is transparent and not exposed in UI >>>>>> >>>>>> === CLI === >>>>>> >>>>>> The feature is not directly exposed in CLI. >>>>>> IPA idrange management is expanded to specify idrange type (IPA >>>>>> local, >>>>>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD >>>>>> users >>>>>> SIDs are mapped to POSIX IDs. >>>>>> >>>>>> = Major configuration options and enablement = >>>>>> >>>>>> sssd.conf will have 'ipa_server_mode = true' set for IPA master. >>>>>> >>>>>> = Replication = >>>>>> >>>>>> No effect on replication. Since directory server plugin is only >>>>>> configured when ipa-adtrust-install is run, IPA masters may opt out >>>>>> from >>>>>> serving AD clients. >>>>>> >>>>>> = Updates and Upgrades = >>>>>> >>>>>> During upgrade of IPA master, sssd.conf should be updated to set >>>>>> 'ipa_server_mode = true'. >>>>>> >>>>>> = Dependencies = >>>>>> >>>>>> Depends on SSSD implementing IPA server mode (sssd 1.10.x) >>>>>> >>>>>> = External Impact = >>>>>> >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>>>> >>>>>> = Backup and Restore = >>>>>> >>>>>> No external configuration files are affected >>>>>> >>>>>> = Test Plan = >>>>>> >>>>>> Testing the feature will require following: >>>>>> >>>>>> # Configure IPA to serve AD trusts >>>>>> # Establish trust with AD domain >>>>>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible >>>>>> tree >>>>>> # Attempt to log-in to the client as AD user >>>>>> >>>>>> = RFE Author = >>>>>> >>>>>> [[User:Ab|ab]] ([[User talk:Ab|talk]]) >>>>>> >>>>> >>>>> >>>>> Can you please explain how the older SSSD or other UNIX versions would >>>>> use Kerberos for authentication? >>>> pam_krb5 should work as it is, as well as older SSSD, since any AD user >>>> attempting to connect using GSSAPI to IPA services will have >>>> cross-realm >>>> TGT issued for us by the trusting AD DC prior to that attempt. >>>> >>>> The whole idea was to make sure for old clients these users will look >>>> like normal users, via nss_ldap/SSSD. >>>> >>>> We still will need to configure principal mapping in /etc/krb5.conf >>>> like >>>> we do for AD users with trusts. >>>> >>>>> I thought we would have to issue some patch for client to switch the >>>>> clients from using Kerberos for authentication to using LDAP. >>>> No need to. pam_ldap would go through LDAP bind automatically, that's >>>> why the proposal talks about attempting to obtain TGT in place of a >>>> user >>>> instead of proxying such LDAP bind back to AD DC. This would require us >>>> enforcing clear password bind over TLS/SSL but it is simpler to >>>> achieve. >>>> >>> I am missing something. How a simple kinit would work? >>> Can you please describe the sequence and workflow? >> I'm talking about the case when AD user logs in into IPA client using >> PuTTY from Windows machine. In such case there is already service ticket >> and cross-realm TGT available. >> >> For kinit on IPA client all what is needed is /etc/krb5.conf >> configuration that forces to talk to AD DC for principals in AD realm. >> >> It can be done via SRV records in DNS or manually in /etc/krb5.conf. >> >> For example, on the machine I'm writing this email I added manual >> routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do >> following: >> >> # klist >> klist: No credentials cache found (ticket cache >> DIR::/run/user/0/krb5cc/tkt) >> # kinit Administrator at AD.LAN >> Password for Administrator at AD.LAN: Warning: Your password will expire >> in 2 days on ??. 31 ??? 2013 07:29:10 >> # klist >> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO >> Default principal: Administrator at AD.LAN >> >> Valid starting Expires Service principal >> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN >> renew until 04.06.2013 23:24:44 >> # kvno HTTP/red.bird.clone at BIRD.CLONE >> HTTP/red.bird.clone at BIRD.CLONE: kvno = 2 >> # klist >> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO >> Default principal: Administrator at AD.LAN >> >> Valid starting Expires Service principal >> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN >> renew until 04.06.2013 23:24:44 >> 28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/BIRD.CLONE at AD.LAN >> renew until 04.06.2013 23:24:44 >> 28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone at BIRD.CLONE >> renew until 04.06.2013 23:24:44 >> > >This is exactly the problem I am try to get to. >Let us take CentOS 6.3 machine and configure SSSD against IPA. It has >absolutely no knowledge about AD. This is the whole point. >But AD users should be able to walk to the console and authenticate. The >flow will be: >User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD >But there is no design for such flow. And IMO it is too much. For this use case LDAP-based authentication has to be configured. For any remote login we can rely on Kerberos authentication. For over console login we cannot rely on Kerberos authentication without explicit help from either KDC or SSSD. What we can do in our KDB driver is to force KDC to issue KDC referral for users from trusted domains, rewriting the realm and redirecting to AD DC. This is how AD DC performs in a forest when a client talks to non-root DC in request of a ticket for a service in a trusted domain. However, I think it could be a good target for 3.4. >What you are suggesting here is a sort of "split brain solution" that we >did not recommend in the past are we going to change out assessment of >this approach? No. What I suggested did not include direct console logins. >So to summarize we are talking about the case: >a) Legacy/UNIX systems are configured to authenticate/joined to IPA and >do not know about AD >b) User from AD walks to the console and uses his name and password > >He needs to be authenticated. How? See above. KDC needs to recognize this user is from a trusted domain (by the domain's realm) and issue a referral to AD DCs which handle it. -- / Alexander Bokovoy From sbose at redhat.com Wed May 29 07:28:48 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 29 May 2013 09:28:48 +0200 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130529053837.GA26689@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> Message-ID: <20130529072848.GA28888@localhost.localdomain> On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Dmitri Pal wrote: > >On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: > >>On Tue, 28 May 2013, Dmitri Pal wrote: > >>>On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: > >>>>On Tue, 28 May 2013, Dmitri Pal wrote: > >>>>>On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: > >>>>>>Hi, > >>>>>> > >>>>>> > >>>>>>http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > >>>>>> > >>>>>>= Overview = > >>>>>> > >>>>>>Since version 3.0 FreeIPA supports cross-realm trusts with Active > >>>>>>Directory. In order to allow AD users to utilize services on IPA > >>>>>>clients, up to date version of SSSD should be configured at the IPA > >>>>>>client. In case it is not possible to install and configure SSSD > > >>>>>>1.09, > >>>>>>Active Directory users cannot access services on IPA clients. > >>>>>> > >>>>>>This feature is designed to bridge the gap and provide minimal > >>>>>>compatibility level that allows to log-in to IPA clients for AD > >>>>>>users. > >>>>>>IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd > >>>>>>version. > >>>>>>= Use Cases = > >>>>>> > >>>>>>Access to IPA client machine resources for AD users in case IPA > >>>>>>client > >>>>>>cannot utilize up to date version of SSSD with native support for IPA > >>>>>>cross-realm trusts. > >>>>>> > >>>>>>= Design= > >>>>>>Since IPA client is configured with the use of older SSSD or > >>>>>>nss_ldap/pam_ldap, all work should be performed at the IPA master. > >>>>>>Primary design decision is to provide a separate LDAP tree, > >>>>>>similar to > >>>>>>compat tree, that has following features: > >>>>>> > >>>>>>* information about both IPA and AD users can be queried; > >>>>>>* it ispossible to enumerate members of IPA and AD groups; > >>>>>>* authentication bind to IPA LDAP as AD users should automatically > >>>>>>* trigger obtaining ticket from AD DC; in case TGT is obtained, > >>>>>>* authentication bind should be treated as successful. > >>>>>> > >>>>>>From a client perspective, use of the separate LDAP tree is viewed as > >>>>>>traditional nss_ldap/pam_ldap configuration. > >>>>>> > >>>>>>Proposed base for the LDAP tree: > >>>>>>'''cn=users,cn=trust-accounts,dc=example,dc=com''' > >>>>>> > >>>>>>= Implementation = > >>>>>> > >>>>>># IPA server sets SSSD configuration to 'ipa_server_mode = true' on > >>>>>>install or upgrade > >>>>>># ipa-adtrust-install configures additional directory server > >>>>>>plugin to > >>>>>>serve trusted domains tree > >>>>>># Directory server plugin uses getpwnam_r(), getgrnam_r() and > >>>>>>related > >>>>>>calls to obtain information about AD user. For IPA users the > >>>>>>information is fetched directly from the LDAP. > >>>>>># IPA KDC database driver adds MS-PAC information into ticket > >>>>>>granting > >>>>>>ticket for host/fqdn at REALM principal of IPA master. This is required > >>>>>>to allow SSSD on IPA master to authenticate against AD using > >>>>>>host/fqdn at REALM principal. > >>>>>> > >>>>>>For SSSD design see > >>>>>>https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > >>>>>> > >>>>>>= Feature Management = > >>>>>> > >>>>>>=== UI === > >>>>>> > >>>>>>The feature is transparent and not exposed in UI > >>>>>> > >>>>>>=== CLI === > >>>>>> > >>>>>>The feature is not directly exposed in CLI. > >>>>>>IPA idrange management is expanded to specify idrange type (IPA > >>>>>>local, > >>>>>>AD trust, AD with winsync, IPA trust, ..) to affect the way how AD > >>>>>>users > >>>>>>SIDs are mapped to POSIX IDs. > >>>>>> > >>>>>>= Major configuration options and enablement = > >>>>>> > >>>>>>sssd.conf will have 'ipa_server_mode = true' set for IPA master. > >>>>>> > >>>>>>= Replication = > >>>>>> > >>>>>>No effect on replication. Since directory server plugin is only > >>>>>>configured when ipa-adtrust-install is run, IPA masters may opt out > >>>>>>from > >>>>>>serving AD clients. > >>>>>> > >>>>>>= Updates and Upgrades = > >>>>>> > >>>>>>During upgrade of IPA master, sssd.conf should be updated to set > >>>>>>'ipa_server_mode = true'. > >>>>>> > >>>>>>= Dependencies = > >>>>>> > >>>>>>Depends on SSSD implementing IPA server mode (sssd 1.10.x) > >>>>>> > >>>>>>= External Impact = > >>>>>> > >>>>>>https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > >>>>>> > >>>>>>= Backup and Restore = > >>>>>> > >>>>>>No external configuration files are affected > >>>>>> > >>>>>>= Test Plan = > >>>>>> > >>>>>>Testing the feature will require following: > >>>>>> > >>>>>># Configure IPA to serve AD trusts > >>>>>># Establish trust with AD domain > >>>>>># Configure a client to use nss_ldap/pam_ldap against AD-compatible > >>>>>>tree > >>>>>># Attempt to log-in to the client as AD user > >>>>>> > >>>>>>= RFE Author = > >>>>>> > >>>>>>[[User:Ab|ab]] ([[User talk:Ab|talk]]) > >>>>>> > >>>>> > >>>>> > >>>>>Can you please explain how the older SSSD or other UNIX versions would > >>>>>use Kerberos for authentication? > >>>>pam_krb5 should work as it is, as well as older SSSD, since any AD user > >>>>attempting to connect using GSSAPI to IPA services will have > >>>>cross-realm > >>>>TGT issued for us by the trusting AD DC prior to that attempt. > >>>> > >>>>The whole idea was to make sure for old clients these users will look > >>>>like normal users, via nss_ldap/SSSD. > >>>> > >>>>We still will need to configure principal mapping in /etc/krb5.conf > >>>>like > >>>>we do for AD users with trusts. > >>>> > >>>>>I thought we would have to issue some patch for client to switch the > >>>>>clients from using Kerberos for authentication to using LDAP. > >>>>No need to. pam_ldap would go through LDAP bind automatically, that's > >>>>why the proposal talks about attempting to obtain TGT in place of a > >>>>user > >>>>instead of proxying such LDAP bind back to AD DC. This would require us > >>>>enforcing clear password bind over TLS/SSL but it is simpler to > >>>>achieve. > >>>> > >>>I am missing something. How a simple kinit would work? > >>>Can you please describe the sequence and workflow? > >>I'm talking about the case when AD user logs in into IPA client using > >>PuTTY from Windows machine. In such case there is already service ticket > >>and cross-realm TGT available. > >> > >>For kinit on IPA client all what is needed is /etc/krb5.conf > >>configuration that forces to talk to AD DC for principals in AD realm. > >> > >>It can be done via SRV records in DNS or manually in /etc/krb5.conf. > >> > >>For example, on the machine I'm writing this email I added manual > >>routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do > >>following: > >> > >># klist > >>klist: No credentials cache found (ticket cache > >>DIR::/run/user/0/krb5cc/tkt) > >># kinit Administrator at AD.LAN > >>Password for Administrator at AD.LAN: Warning: Your password will expire > >>in 2 days on ??. 31 ??? 2013 07:29:10 > >># klist > >>Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO > >>Default principal: Administrator at AD.LAN > >> > >>Valid starting Expires Service principal > >>28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN > >> renew until 04.06.2013 23:24:44 > >># kvno HTTP/red.bird.clone at BIRD.CLONE > >>HTTP/red.bird.clone at BIRD.CLONE: kvno = 2 > >># klist > >>Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO > >>Default principal: Administrator at AD.LAN > >> > >>Valid starting Expires Service principal > >>28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN > >> renew until 04.06.2013 23:24:44 > >>28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/BIRD.CLONE at AD.LAN > >> renew until 04.06.2013 23:24:44 > >>28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone at BIRD.CLONE > >> renew until 04.06.2013 23:24:44 > >> > > > >This is exactly the problem I am try to get to. > >Let us take CentOS 6.3 machine and configure SSSD against IPA. It has > >absolutely no knowledge about AD. This is the whole point. > >But AD users should be able to walk to the console and authenticate. The > >flow will be: > >User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD > >But there is no design for such flow. And IMO it is too much. > For this use case LDAP-based authentication has to be configured. > > For any remote login we can rely on Kerberos authentication. > > For over console login we cannot rely on Kerberos authentication without > explicit help from either KDC or SSSD. > > What we can do in our KDB driver is to force KDC to issue KDC referral > for users from trusted domains, rewriting the realm and redirecting to > AD DC. This is how AD DC performs in a forest when a client talks to > non-root DC in request of a ticket for a service in a trusted domain. > > However, I think it could be a good target for 3.4. > > >What you are suggesting here is a sort of "split brain solution" that we > >did not recommend in the past are we going to change out assessment of > >this approach? > No. What I suggested did not include direct console logins. > > >So to summarize we are talking about the case: > >a) Legacy/UNIX systems are configured to authenticate/joined to IPA and > >do not know about AD > >b) User from AD walks to the console and uses his name and password > > > >He needs to be authenticated. How? > See above. KDC needs to recognize this user is from a trusted domain (by > the domain's realm) and issue a referral to AD DCs which handle it. If I understand the issue correctly then only 'dns_lookup_kdc = true' must be set in /etc/krb5.conf on the client. For passowrd based console logins the client must the able to resolve the trusted AD DC with a DNS SRV lookup and must be able to connect to one of the returned DCs because only the AD DC can authenticate the user. It is the same way as this type of authentication is working for sssd in 6.4. And it is basically the same way as it works for Windows clients, only that here the AD DC of the Windows client is contacted first and returns a Kerberos client referral to the Windows client as Alexander mentioned above. Then the Windows client also has to find a DC of the trusted domain and send the request to the trusted DC. HTH bye, Sumit > > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pspacek at redhat.com Wed May 29 08:06:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 May 2013 10:06:26 +0200 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <1369743129.2769.94.camel@willson.li.ssimo.org> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> <51A36F6A.6020609@redhat.com> <1369685102.2769.93.camel@willson.li.ssimo.org> <51A46CF9.8040004@redhat.com> <51A46ED1.1060906@redhat.com> <1369743129.2769.94.camel@willson.li.ssimo.org> Message-ID: <51A5B702.7080603@redhat.com> On 28.5.2013 14:12, Simo Sorce wrote: > On Tue, 2013-05-28 at 10:46 +0200, Martin Kosek wrote: >> On 05/28/2013 10:38 AM, Petr Spacek wrote: >>> On 27.5.2013 22:05, Simo Sorce wrote: >>>> On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: >>>>> On 27.5.2013 15:57, Simo Sorce wrote: >>>>>> On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: >>>>>>> Hello Simo, >>>>>>> >>>>>>> could you install/allow XMLRPC for our Patchwork, please? >>>>>>> >>>>>>> I found the CLI for Patchwork but it requires XMLRPC. >>>>>>> >>>>>>> On 27.5.2013 10:41, Petr Spacek wrote: >>>>>>>> see https://www.varnish-cache.org/patchwork/help/pwclient/ >>>>>>> >>>>>> >>>>>> Should be enabled now. >>>>> >>>>> Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): >>>>> >>>>> xmlrpclib.ProtocolError: >>>> NOT FOUND> >>>> >>>> I've restarted the apahe server, apparently not all threads would see >>>> the new config w/o a full reload. >>> >>> I confirm that it works now. BTW did you considered migration to freeipa.org? :-) >> >> We could eventually migrate it to OpenShift just like FreeIPA.org's mediawiki >> site. As patchwork is based on Django which is common on OpenShift, it should >> not be so difficult. We could then create alias patchwork.freeipa.org if we >> want to use it. > > Yup, > I think we should do it, Petr are you ihnterested in comaintainng it if > we move it to an OpenShift instance ? I'm sorry, but I have hands full with labs in Brno and Boston and I don't want to raise the speed of losing my hair. -- Petr^2 Spacek From pviktori at redhat.com Wed May 29 08:13:39 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 May 2013 10:13:39 +0200 Subject: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show In-Reply-To: <51A4CE0B.4030105@redhat.com> References: <51A353BF.1070807@redhat.com> <51A359C5.6030905@redhat.com> <51A492E4.4050707@redhat.com> <51A4CE0B.4030105@redhat.com> Message-ID: <51A5B8B3.3030207@redhat.com> On 05/28/2013 05:32 PM, Ana Krivokapic wrote: > On 05/28/2013 01:20 PM, Tomas Babej wrote: >> On 05/27/2013 03:04 PM, Ana Krivokapic wrote: >>> On 05/27/2013 02:38 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> In trust_show command, make sure that --raw flag is honoured. >>>> Attributes ipanttrusttype and ipanttrustdirection are no longer >>>> translated to strings from their raw ldap values when --raw is >>>> used. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3525 >>>> >>>> Tomas >>> The patch causes these two attributes to not be displayed, when --raw >>> switch is used: >>> >>> [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com >>> Realm name: addomain.example.com >>> Domain NetBIOS name: ADDOMAIN >>> Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322 >>> Trust direction: Two-way trust >>> Trust type: Active Directory domain >>> >>> [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com --raw >>> cn: addomain.example.com >>> ipantflatname: ADDOMAIN >>> ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322 >>> >> Thanks. Updated patch attached. >> >> I modified trust-find according to the new behaviour. >> >> Tomas >> >> > Works nicely. > > Please just amend the commit message to mention that the trust-find > command is also affected. > > ACK. > Pushed to master. -- Petr? From tbabej at redhat.com Wed May 29 08:24:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 29 May 2013 10:24:08 +0200 Subject: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show In-Reply-To: <51A4CE0B.4030105@redhat.com> References: <51A353BF.1070807@redhat.com> <51A359C5.6030905@redhat.com> <51A492E4.4050707@redhat.com> <51A4CE0B.4030105@redhat.com> Message-ID: <51A5BB28.4050503@redhat.com> On 05/28/2013 05:32 PM, Ana Krivokapic wrote: > On 05/28/2013 01:20 PM, Tomas Babej wrote: >> On 05/27/2013 03:04 PM, Ana Krivokapic wrote: >>> On 05/27/2013 02:38 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> In trust_show command, make sure that --raw flag is honoured. >>>> Attributes ipanttrusttype and ipanttrustdirection are no longer >>>> translated to strings from their raw ldap values when --raw is >>>> used. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3525 >>>> >>>> Tomas >>> The patch causes these two attributes to not be displayed, when --raw >>> switch is used: >>> >>> [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com >>> Realm name: addomain.example.com >>> Domain NetBIOS name: ADDOMAIN >>> Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322 >>> Trust direction: Two-way trust >>> Trust type: Active Directory domain >>> >>> [akrivoka at vm-040 freeipa]$ ipa trust-show addomain.example.com --raw >>> cn: addomain.example.com >>> ipantflatname: ADDOMAIN >>> ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322 >>> >> Thanks. Updated patch attached. >> >> I modified trust-find according to the new behaviour. >> >> Tomas >> >> > Works nicely. > > Please just amend the commit message to mention that the trust-find > command is also affected. > > ACK. > Commit message ammended. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0060-3-Do-not-translate-trust-type-and-direction-with-raw-i.patch Type: text/x-patch Size: 3628 bytes Desc: not available URL: From pvoborni at redhat.com Wed May 29 08:38:41 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 29 May 2013 10:38:41 +0200 Subject: [Freeipa-devel] [PATCH] 417 Regression fix: missing control buttons in nested search facets Message-ID: <51A5BE91.3030306@redhat.com> Automount maps, keys and dnsrecord search facet are missing control buttons (add, delete, refresh). Regression introduced by 6e90920233cc9a7c9feb040dea22cda837715c39 - 'Move spec modifications from facet factories to pre_ops'. https://fedorahosted.org/freeipa/ticket/3605 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0417-Regression-fix-missing-control-buttons-in-nested-sea.patch Type: text/x-patch Size: 3254 bytes Desc: not available URL: From tbabej at redhat.com Wed May 29 08:55:42 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 29 May 2013 10:55:42 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <20130528134833.GX26689@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> <51A318EB.7000902@redhat.com> <20130528123513.GT26689@redhat.com> <51A4B0C9.40005@redhat.com> <20130528134833.GX26689@redhat.com> Message-ID: <51A5C28E.2070303@redhat.com> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Tomas Babej wrote: >> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>> On Mon, 27 May 2013, Tomas Babej wrote: >>>>>>> We got rid of openldap utilities now. While using python.ldap >>>>>>> module, I also made the tests much more robust and added a new >>>>>>> test case. >>>>>> In general patches look fine, there is one small nitpick. >>>>>> I'll run tests on Monday and then will provide final ACK. >>>>>> >>>>>>> --- a/tests/test_xmlrpc/test_range_plugin.py >>>>>>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>>>>>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` >>>>>>> module, and XML-RPC in general. >>>>>>> """ >>>>>>> >>>>>>> from ipalib import api, errors, _ >>>>>>> +from ipapython.ipautil import run >>>>>> This import is unused, can be removed. >>>>>> >>>>> Fixed, thanks for catching that. >>>>> >>>>> Updated patch attached. >>> So I tried to run this test on a machine where there is already trust >>> established and I think there should be done some changes. >> >> I perused the log. Seems that the failures you're experiencing are >> not relevant to the patch itself, >> since the newly added tests passed. >> >> This is problem with test_range_plugin.py tests that has been there >> for quite a while, the parameters >> of the ranges such as size, and base ID/RID/secondary RID are >> hardcoded in the test case. > Yep. > > >>> Probably it would be wise to add pre-start procedure to pull existing >>> ranges and define constants for the ranges so that they don't overlap >>> with existing ones. Perhaps selecting something from a top of the range >>> space... >>> >>> Attached is the log >> >> I agree. This has not been relevant until now, since we did not do >> much testing on IPA instances >> with trusts set up, and even then there's random factor in having the >> overlap with the already created >> trust range. >> >> I'd propose fixing this in a separate effort as a part of continouous >> integration improvements. I see it >> as a separate issue of its own. >> >> What do you think? > Please file a separate ticket then. > > ACK for this one. > For the record: https://fedorahosted.org/freeipa/ticket/3662 Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed May 29 10:06:47 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 29 May 2013 12:06:47 +0200 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130528115059.GS26689@redhat.com> References: <20130528115059.GS26689@redhat.com> Message-ID: <20130529100647.GC28888@localhost.localdomain> On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: > Hi, > > > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > = Overview = > > Since version 3.0 FreeIPA supports cross-realm trusts with Active > Directory. In order to allow AD users to utilize services on IPA > clients, up to date version of SSSD should be configured at the IPA > client. In case it is not possible to install and configure SSSD > 1.09, > Active Directory users cannot access services on IPA clients. > > This feature is designed to bridge the gap and provide minimal > compatibility level that allows to log-in to IPA clients for AD users. > IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd > version. > > = Use Cases = > > Access to IPA client machine resources for AD users in case IPA client > cannot utilize up to date version of SSSD with native support for IPA > cross-realm trusts. > > = Design= > > Since IPA client is configured with the use of older SSSD or > nss_ldap/pam_ldap, all work should be performed at the IPA master. > Primary design decision is to provide a separate LDAP tree, similar to > compat tree, that has following features: > > * information about both IPA and AD users can be queried; > * it ispossible to enumerate members of IPA and AD groups; > * authentication bind to IPA LDAP as AD users should automatically > * trigger obtaining ticket from AD DC; in case TGT is obtained, > * authentication bind should be treated as successful. > > From a client perspective, use of the separate LDAP tree is viewed as > traditional nss_ldap/pam_ldap configuration. > > Proposed base for the LDAP tree: > '''cn=users,cn=trust-accounts,dc=example,dc=com''' I guess older SSSD versions, e.g. 1.8. might be the most difficult use cases because they already support some specific features for IPA users and groups, e.g. HBAC, netgroups, SELinux and automount maps. Since most of them depends on DNs one way or the other I think older SSSD version must continue to use the main tree for IPA users and groups and local look at the new tree for trusted accounts. Luckily multiple search bases were introduced in SSSD 1.7, I wonder if older version have to be supported as well? But if multiple search bases are used the IPA users and groups should not be visible in the new tree for trusted accounts. Maybe the new plugin can offer different trees like - cn=users,cn=trust-accounts,dc=example,dc=com - cn=users,cn=trust-accounts-sssd,dc=example,dc=com where the first contains IPA and AD accounts as mentioned above and the latter only the AD accounts? Since we are planning to do the lookups on the fly I think both trees can be handled in the same code path and the path name is just config option which switches the IPA accounts on and off respectively. With iyet another tree it might be also possible to support either rfc2307 or rfc2037bis. I assume that the plan is that the new tree will use rfc2307bis but I wonder if we have to support clients which only support rcf2307. bye, Sumit > > = Implementation = > > # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade > # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree > # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. > # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn at REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn at REALM principal. > > For SSSD design see > https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > > = Feature Management = > > === UI === > > The feature is transparent and not exposed in UI > > === CLI === > > The feature is not directly exposed in CLI. > > IPA idrange management is expanded to specify idrange type (IPA local, > AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users > SIDs are mapped to POSIX IDs. > > = Major configuration options and enablement = > > sssd.conf will have 'ipa_server_mode = true' set for IPA master. > > = Replication = > > No effect on replication. Since directory server plugin is only > configured when ipa-adtrust-install is run, IPA masters may opt out from > serving AD clients. > > = Updates and Upgrades = > > During upgrade of IPA master, sssd.conf should be updated to set > 'ipa_server_mode = true'. > > = Dependencies = > > Depends on SSSD implementing IPA server mode (sssd 1.10.x) > > = External Impact = > > https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > > = Backup and Restore = > > No external configuration files are affected > > = Test Plan = > > Testing the feature will require following: > > # Configure IPA to serve AD trusts > # Establish trust with AD domain > # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree > # Attempt to log-in to the client as AD user > > = RFE Author = > > [[User:Ab|ab]] ([[User talk:Ab|talk]]) > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Wed May 29 10:25:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 29 May 2013 12:25:18 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <20130528134833.GX26689@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> <51A318EB.7000902@redhat.com> <20130528123513.GT26689@redhat.com> <51A4B0C9.40005@redhat.com> <20130528134833.GX26689@redhat.com> Message-ID: <51A5D78E.8020706@redhat.com> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Tomas Babej wrote: >> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>> On Mon, 27 May 2013, Tomas Babej wrote: >>>>>>> We got rid of openldap utilities now. While using python.ldap module, I >>>>>>> also made the tests much more robust and added a new test case. >>>>>> In general patches look fine, there is one small nitpick. >>>>>> I'll run tests on Monday and then will provide final ACK. >>>>>> >>>>>>> --- a/tests/test_xmlrpc/test_range_plugin.py >>>>>>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>>>>>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and >>>>>>> XML-RPC in general. >>>>>>> """ >>>>>>> >>>>>>> from ipalib import api, errors, _ >>>>>>> +from ipapython.ipautil import run >>>>>> This import is unused, can be removed. >>>>>> >>>>> Fixed, thanks for catching that. >>>>> >>>>> Updated patch attached. >>> So I tried to run this test on a machine where there is already trust >>> established and I think there should be done some changes. >> >> I perused the log. Seems that the failures you're experiencing are not >> relevant to the patch itself, >> since the newly added tests passed. >> >> This is problem with test_range_plugin.py tests that has been there for quite >> a while, the parameters >> of the ranges such as size, and base ID/RID/secondary RID are hardcoded in >> the test case. > Yep. > > >>> Probably it would be wise to add pre-start procedure to pull existing >>> ranges and define constants for the ranges so that they don't overlap >>> with existing ones. Perhaps selecting something from a top of the range >>> space... >>> >>> Attached is the log >> >> I agree. This has not been relevant until now, since we did not do much >> testing on IPA instances >> with trusts set up, and even then there's random factor in having the overlap >> with the already created >> trust range. >> >> I'd propose fixing this in a separate effort as a part of continouous >> integration improvements. I see it >> as a separate issue of its own. >> >> What do you think? > Please file a separate ticket then. > > ACK for this one. > May-be-NACK. Would it make sense to replace the error with DependentEntry error? We use in cases like this elsewhere and I think it makes more sense in this case too. Martin From pspacek at redhat.com Wed May 29 10:31:50 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 May 2013 12:31:50 +0200 Subject: [Freeipa-devel] [PATCH 0155] Fix IPv6 handling in PTR record synchronization In-Reply-To: <60029332.4612034.1369730678231.JavaMail.root@redhat.com> References: <51948F35.1010408@redhat.com> <60029332.4612034.1369730678231.JavaMail.root@redhat.com> Message-ID: <51A5D916.90308@redhat.com> On 28.5.2013 10:44, Tomas Hozza wrote: > ACK > > The patch looks good and works as expected. Pushed to master: 304b7e74e9d92d0973ef4428be7b9794c8905056 -- Petr^2 Spacek From pvoborni at redhat.com Wed May 29 11:15:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 29 May 2013 13:15:29 +0200 Subject: [Freeipa-devel] [PATCH] 418 Make ssbrowser.html work in IE 10 Message-ID: <51A5E351.3000301@redhat.com> Manual configuration page for other browsers (ssbrowser.html) doesn't work in IE 10 - error page is displayed. This patch is conditioning creation of Firefox configuration object so that configure.jar is requested only in Firefox. IE doesn't request it and so it does not fail. https://fedorahosted.org/freeipa/ticket/3645 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0418-Make-ssbrowser.html-work-in-IE-10.patch Type: text/x-patch Size: 1978 bytes Desc: not available URL: From abokovoy at redhat.com Wed May 29 11:39:21 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 29 May 2013 14:39:21 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130529100647.GC28888@localhost.localdomain> References: <20130528115059.GS26689@redhat.com> <20130529100647.GC28888@localhost.localdomain> Message-ID: <20130529113921.GH26689@redhat.com> On Wed, 29 May 2013, Sumit Bose wrote: >On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: >> Hi, >> >> >> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >> >> = Overview = >> >> Since version 3.0 FreeIPA supports cross-realm trusts with Active >> Directory. In order to allow AD users to utilize services on IPA >> clients, up to date version of SSSD should be configured at the IPA >> client. In case it is not possible to install and configure SSSD > 1.09, >> Active Directory users cannot access services on IPA clients. >> >> This feature is designed to bridge the gap and provide minimal >> compatibility level that allows to log-in to IPA clients for AD users. >> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >> version. >> >> = Use Cases = >> >> Access to IPA client machine resources for AD users in case IPA client >> cannot utilize up to date version of SSSD with native support for IPA >> cross-realm trusts. >> >> = Design= >> >> Since IPA client is configured with the use of older SSSD or >> nss_ldap/pam_ldap, all work should be performed at the IPA master. >> Primary design decision is to provide a separate LDAP tree, similar to >> compat tree, that has following features: >> >> * information about both IPA and AD users can be queried; >> * it ispossible to enumerate members of IPA and AD groups; >> * authentication bind to IPA LDAP as AD users should automatically >> * trigger obtaining ticket from AD DC; in case TGT is obtained, >> * authentication bind should be treated as successful. >> >> From a client perspective, use of the separate LDAP tree is viewed as >> traditional nss_ldap/pam_ldap configuration. >> >> Proposed base for the LDAP tree: >> '''cn=users,cn=trust-accounts,dc=example,dc=com''' > >I guess older SSSD versions, e.g. 1.8. might be the most difficult use >cases because they already support some specific features for IPA users >and groups, e.g. HBAC, netgroups, SELinux and automount maps. Since most >of them depends on DNs one way or the other I think older SSSD version >must continue to use the main tree for IPA users and groups and local >look at the new tree for trusted accounts. Luckily multiple search bases >were introduced in SSSD 1.7, I wonder if older version have to be >supported as well? But if multiple search bases are used the IPA users >and groups should not be visible in the new tree for trusted accounts. > >Maybe the new plugin can offer different trees like > - cn=users,cn=trust-accounts,dc=example,dc=com > - cn=users,cn=trust-accounts-sssd,dc=example,dc=com > >where the first contains IPA and AD accounts as mentioned above and the >latter only the AD accounts? Since we are planning to do the lookups on >the fly I think both trees can be handled in the same code path and the >path name is just config option which switches the IPA accounts on and >off respectively. > >With iyet another tree it might be also possible to support either rfc2307 or >rfc2037bis. I assume that the plan is that the new tree will use >rfc2307bis but I wonder if we have to support clients which only support >rcf2307. Yep. Summarizing for the list discussion we had with Sumit on IRC, I think we can re-use slapi-nis plugin for the purpose of this feature. The way slapi-nis works for schema compatibility is that one needs to define first a subtree to search against, with a filter, and then additional transformations are applied to the result of search. The end result is presented to the client. What we need to do is to make possible to return a result of initial 'search' against SSSD instead of actual LDAP subtree. A 'search' result is then processed according to defined transformation rules. slapi-nis supports multiple resulting trees already, this solves the problem Sumit raises above. Additionally, for LDAP auth bind we need to make sure it is actually possible to hook to in a directory server plugin for a virtual DN like slapi-nis presents. This is something Sumit and I need to check with 389-ds developers. We already have some support for that with new feature to allow fallbacks for SASL auth but in this case we need to use simple bind to get hold of the password (to kinit agasint AD DC) over secure channel. -- / Alexander Bokovoy From akrivoka at redhat.com Wed May 29 11:43:58 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 29 May 2013 13:43:58 +0200 Subject: [Freeipa-devel] [PATCH] 417 Regression fix: missing control buttons in nested search facets In-Reply-To: <51A5BE91.3030306@redhat.com> References: <51A5BE91.3030306@redhat.com> Message-ID: <51A5E9FE.3040305@redhat.com> On 05/29/2013 10:38 AM, Petr Vobornik wrote: > Automount maps, keys and dnsrecord search facet are missing control > buttons (add, delete, refresh). > > Regression introduced by 6e90920233cc9a7c9feb040dea22cda837715c39 - > 'Move spec modifications from facet factories to pre_ops'. > > https://fedorahosted.org/freeipa/ticket/3605 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This fixes the issue, ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed May 29 12:57:23 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 May 2013 14:57:23 +0200 Subject: [Freeipa-devel] [PATCH 0160] Fix crash triggered by missing sasl_user parameter Message-ID: <51A5FB33.7000802@redhat.com> Hello, Fix crash triggered by missing sasl_user parameter. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0160-Fix-crash-triggered-by-missing-sasl_user-parameter.patch Type: text/x-patch Size: 1152 bytes Desc: not available URL: From pspacek at redhat.com Wed May 29 13:09:39 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 May 2013 15:09:39 +0200 Subject: [Freeipa-devel] [PATCH 0161] Validate authentication settings strictly Message-ID: <51A5FE13.9080200@redhat.com> Hello, Validate authentication settings strictly. - auth_method 'SASL' do not accept bind_dn and password options - auth_method 'simple' do not accept sasl_* and krb5_* options - auth_method 'none' do not accept any of options above -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0161-Validate-authentication-settings-strictly.patch Type: text/x-patch Size: 3576 bytes Desc: not available URL: From akrivoka at redhat.com Wed May 29 13:24:41 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 29 May 2013 15:24:41 +0200 Subject: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod Message-ID: <51A60199.5000009@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3636 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0031-Deprecate-options-dom-sid-and-dom-name-in-idrange-mo.patch Type: text/x-patch Size: 4060 bytes Desc: not available URL: From simo at redhat.com Wed May 29 13:29:43 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 29 May 2013 09:29:43 -0400 Subject: [Freeipa-devel] [Patchwork] command line client In-Reply-To: <51A5B702.7080603@redhat.com> References: <51A31C22.6050806@redhat.com> <51A31D23.4080106@redhat.com> <1369663069.2769.81.camel@willson.li.ssimo.org> <51A36F6A.6020609@redhat.com> <1369685102.2769.93.camel@willson.li.ssimo.org> <51A46CF9.8040004@redhat.com> <51A46ED1.1060906@redhat.com> <1369743129.2769.94.camel@willson.li.ssimo.org> <51A5B702.7080603@redhat.com> Message-ID: <1369834183.2769.134.camel@willson.li.ssimo.org> On Wed, 2013-05-29 at 10:06 +0200, Petr Spacek wrote: > On 28.5.2013 14:12, Simo Sorce wrote: > > On Tue, 2013-05-28 at 10:46 +0200, Martin Kosek wrote: > >> On 05/28/2013 10:38 AM, Petr Spacek wrote: > >>> On 27.5.2013 22:05, Simo Sorce wrote: > >>>> On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: > >>>>> On 27.5.2013 15:57, Simo Sorce wrote: > >>>>>> On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: > >>>>>>> Hello Simo, > >>>>>>> > >>>>>>> could you install/allow XMLRPC for our Patchwork, please? > >>>>>>> > >>>>>>> I found the CLI for Patchwork but it requires XMLRPC. > >>>>>>> > >>>>>>> On 27.5.2013 10:41, Petr Spacek wrote: > >>>>>>>> see https://www.varnish-cache.org/patchwork/help/pwclient/ > >>>>>>> > >>>>>> > >>>>>> Should be enabled now. > >>>>> > >>>>> Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): > >>>>> > >>>>> xmlrpclib.ProtocolError: >>>>> NOT FOUND> > >>>> > >>>> I've restarted the apahe server, apparently not all threads would see > >>>> the new config w/o a full reload. > >>> > >>> I confirm that it works now. BTW did you considered migration to freeipa.org? :-) > >> > >> We could eventually migrate it to OpenShift just like FreeIPA.org's mediawiki > >> site. As patchwork is based on Django which is common on OpenShift, it should > >> not be so difficult. We could then create alias patchwork.freeipa.org if we > >> want to use it. > > > > Yup, > > I think we should do it, Petr are you ihnterested in comaintainng it if > > we move it to an OpenShift instance ? > > I'm sorry, but I have hands full with labs in Brno and Boston and I don't want > to raise the speed of losing my hair. No worries, however I'll wait for a volunteer before trying to move the hosting to something I am not familiar with. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed May 29 13:53:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 29 May 2013 09:53:14 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130529072848.GA28888@localhost.localdomain> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> Message-ID: <51A6084A.7050500@redhat.com> On 05/29/2013 03:28 AM, Sumit Bose wrote: > On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: >> On Tue, 28 May 2013, Dmitri Pal wrote: >>> On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: >>>> On Tue, 28 May 2013, Dmitri Pal wrote: >>>>> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 28 May 2013, Dmitri Pal wrote: >>>>>>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >>>>>>>> >>>>>>>> = Overview = >>>>>>>> >>>>>>>> Since version 3.0 FreeIPA supports cross-realm trusts with Active >>>>>>>> Directory. In order to allow AD users to utilize services on IPA >>>>>>>> clients, up to date version of SSSD should be configured at the IPA >>>>>>>> client. In case it is not possible to install and configure SSSD > >>>>>>>> 1.09, >>>>>>>> Active Directory users cannot access services on IPA clients. >>>>>>>> >>>>>>>> This feature is designed to bridge the gap and provide minimal >>>>>>>> compatibility level that allows to log-in to IPA clients for AD >>>>>>>> users. >>>>>>>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >>>>>>>> version. >>>>>>>> = Use Cases = >>>>>>>> >>>>>>>> Access to IPA client machine resources for AD users in case IPA >>>>>>>> client >>>>>>>> cannot utilize up to date version of SSSD with native support for IPA >>>>>>>> cross-realm trusts. >>>>>>>> >>>>>>>> = Design= >>>>>>>> Since IPA client is configured with the use of older SSSD or >>>>>>>> nss_ldap/pam_ldap, all work should be performed at the IPA master. >>>>>>>> Primary design decision is to provide a separate LDAP tree, >>>>>>>> similar to >>>>>>>> compat tree, that has following features: >>>>>>>> >>>>>>>> * information about both IPA and AD users can be queried; >>>>>>>> * it ispossible to enumerate members of IPA and AD groups; >>>>>>>> * authentication bind to IPA LDAP as AD users should automatically >>>>>>>> * trigger obtaining ticket from AD DC; in case TGT is obtained, >>>>>>>> * authentication bind should be treated as successful. >>>>>>>> >>>>>>> >From a client perspective, use of the separate LDAP tree is viewed as >>>>>>>> traditional nss_ldap/pam_ldap configuration. >>>>>>>> >>>>>>>> Proposed base for the LDAP tree: >>>>>>>> '''cn=users,cn=trust-accounts,dc=example,dc=com''' >>>>>>>> >>>>>>>> = Implementation = >>>>>>>> >>>>>>>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on >>>>>>>> install or upgrade >>>>>>>> # ipa-adtrust-install configures additional directory server >>>>>>>> plugin to >>>>>>>> serve trusted domains tree >>>>>>>> # Directory server plugin uses getpwnam_r(), getgrnam_r() and >>>>>>>> related >>>>>>>> calls to obtain information about AD user. For IPA users the >>>>>>>> information is fetched directly from the LDAP. >>>>>>>> # IPA KDC database driver adds MS-PAC information into ticket >>>>>>>> granting >>>>>>>> ticket for host/fqdn at REALM principal of IPA master. This is required >>>>>>>> to allow SSSD on IPA master to authenticate against AD using >>>>>>>> host/fqdn at REALM principal. >>>>>>>> >>>>>>>> For SSSD design see >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>>>>>> >>>>>>>> = Feature Management = >>>>>>>> >>>>>>>> === UI === >>>>>>>> >>>>>>>> The feature is transparent and not exposed in UI >>>>>>>> >>>>>>>> === CLI === >>>>>>>> >>>>>>>> The feature is not directly exposed in CLI. >>>>>>>> IPA idrange management is expanded to specify idrange type (IPA >>>>>>>> local, >>>>>>>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD >>>>>>>> users >>>>>>>> SIDs are mapped to POSIX IDs. >>>>>>>> >>>>>>>> = Major configuration options and enablement = >>>>>>>> >>>>>>>> sssd.conf will have 'ipa_server_mode = true' set for IPA master. >>>>>>>> >>>>>>>> = Replication = >>>>>>>> >>>>>>>> No effect on replication. Since directory server plugin is only >>>>>>>> configured when ipa-adtrust-install is run, IPA masters may opt out >>>>>>>> from >>>>>>>> serving AD clients. >>>>>>>> >>>>>>>> = Updates and Upgrades = >>>>>>>> >>>>>>>> During upgrade of IPA master, sssd.conf should be updated to set >>>>>>>> 'ipa_server_mode = true'. >>>>>>>> >>>>>>>> = Dependencies = >>>>>>>> >>>>>>>> Depends on SSSD implementing IPA server mode (sssd 1.10.x) >>>>>>>> >>>>>>>> = External Impact = >>>>>>>> >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >>>>>>>> >>>>>>>> = Backup and Restore = >>>>>>>> >>>>>>>> No external configuration files are affected >>>>>>>> >>>>>>>> = Test Plan = >>>>>>>> >>>>>>>> Testing the feature will require following: >>>>>>>> >>>>>>>> # Configure IPA to serve AD trusts >>>>>>>> # Establish trust with AD domain >>>>>>>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible >>>>>>>> tree >>>>>>>> # Attempt to log-in to the client as AD user >>>>>>>> >>>>>>>> = RFE Author = >>>>>>>> >>>>>>>> [[User:Ab|ab]] ([[User talk:Ab|talk]]) >>>>>>>> >>>>>>> >>>>>>> Can you please explain how the older SSSD or other UNIX versions would >>>>>>> use Kerberos for authentication? >>>>>> pam_krb5 should work as it is, as well as older SSSD, since any AD user >>>>>> attempting to connect using GSSAPI to IPA services will have >>>>>> cross-realm >>>>>> TGT issued for us by the trusting AD DC prior to that attempt. >>>>>> >>>>>> The whole idea was to make sure for old clients these users will look >>>>>> like normal users, via nss_ldap/SSSD. >>>>>> >>>>>> We still will need to configure principal mapping in /etc/krb5.conf >>>>>> like >>>>>> we do for AD users with trusts. >>>>>> >>>>>>> I thought we would have to issue some patch for client to switch the >>>>>>> clients from using Kerberos for authentication to using LDAP. >>>>>> No need to. pam_ldap would go through LDAP bind automatically, that's >>>>>> why the proposal talks about attempting to obtain TGT in place of a >>>>>> user >>>>>> instead of proxying such LDAP bind back to AD DC. This would require us >>>>>> enforcing clear password bind over TLS/SSL but it is simpler to >>>>>> achieve. >>>>>> >>>>> I am missing something. How a simple kinit would work? >>>>> Can you please describe the sequence and workflow? >>>> I'm talking about the case when AD user logs in into IPA client using >>>> PuTTY from Windows machine. In such case there is already service ticket >>>> and cross-realm TGT available. >>>> >>>> For kinit on IPA client all what is needed is /etc/krb5.conf >>>> configuration that forces to talk to AD DC for principals in AD realm. >>>> >>>> It can be done via SRV records in DNS or manually in /etc/krb5.conf. >>>> >>>> For example, on the machine I'm writing this email I added manual >>>> routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do >>>> following: >>>> >>>> # klist >>>> klist: No credentials cache found (ticket cache >>>> DIR::/run/user/0/krb5cc/tkt) >>>> # kinit Administrator at AD.LAN >>>> Password for Administrator at AD.LAN: Warning: Your password will expire >>>> in 2 days on ??. 31 ??? 2013 07:29:10 >>>> # klist >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO >>>> Default principal: Administrator at AD.LAN >>>> >>>> Valid starting Expires Service principal >>>> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN >>>> renew until 04.06.2013 23:24:44 >>>> # kvno HTTP/red.bird.clone at BIRD.CLONE >>>> HTTP/red.bird.clone at BIRD.CLONE: kvno = 2 >>>> # klist >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO >>>> Default principal: Administrator at AD.LAN >>>> >>>> Valid starting Expires Service principal >>>> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN >>>> renew until 04.06.2013 23:24:44 >>>> 28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/BIRD.CLONE at AD.LAN >>>> renew until 04.06.2013 23:24:44 >>>> 28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone at BIRD.CLONE >>>> renew until 04.06.2013 23:24:44 >>>> >>> This is exactly the problem I am try to get to. >>> Let us take CentOS 6.3 machine and configure SSSD against IPA. It has >>> absolutely no knowledge about AD. This is the whole point. >>> But AD users should be able to walk to the console and authenticate. The >>> flow will be: >>> User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD >>> But there is no design for such flow. And IMO it is too much. >> For this use case LDAP-based authentication has to be configured. >> >> For any remote login we can rely on Kerberos authentication. >> >> For over console login we cannot rely on Kerberos authentication without >> explicit help from either KDC or SSSD. >> >> What we can do in our KDB driver is to force KDC to issue KDC referral >> for users from trusted domains, rewriting the realm and redirecting to >> AD DC. This is how AD DC performs in a forest when a client talks to >> non-root DC in request of a ticket for a service in a trusted domain. >> >> However, I think it could be a good target for 3.4. >> >>> What you are suggesting here is a sort of "split brain solution" that we >>> did not recommend in the past are we going to change out assessment of >>> this approach? >> No. What I suggested did not include direct console logins. >> >>> So to summarize we are talking about the case: >>> a) Legacy/UNIX systems are configured to authenticate/joined to IPA and >>> do not know about AD >>> b) User from AD walks to the console and uses his name and password >>> >>> He needs to be authenticated. How? >> See above. KDC needs to recognize this user is from a trusted domain (by >> the domain's realm) and issue a referral to AD DCs which handle it. > If I understand the issue correctly then only 'dns_lookup_kdc = true' > must be set in /etc/krb5.conf on the client. > > For passowrd based console logins the client must the able to resolve > the trusted AD DC with a DNS SRV lookup and must be able to connect to > one of the returned DCs because only the AD DC can authenticate the > user. It is the same way as this type of authentication is working for > sssd in 6.4. And it is basically the same way as it works for Windows > clients, only that here the AD DC of the Windows client is contacted > first and returns a Kerberos client referral to the Windows client as > Alexander mentioned above. Then the Windows client also has to find a DC > of the trusted domain and send the request to the trusted DC. > > HTH > > bye, > Sumit This whole discussion is missing from the design page. However we are not yet out of the woods. In the upstream version we need to support SSSD 1.5 and later on Fedora, RHEL CentOS, etc. pam_krb5 from 1.7 and later Solaris 10, 11 AIX 6.x HP-UX may be For UNIXes you really can't patch the client so there should be a procedure to setup these clients. In most cases these clients use LDAP rather than kerberos so I think it is acceptable to not support Kerberos console login from those systems for AD users. The systems should be configured using LDAP against IPA and would know only native IPA users (in console login). But if Kerberos can be made to work fine I am all for it. For those clients we do not have an automated install procedure so it is given that the setup will be manual. For Lunix and older SSSD version we in fact have a problem. What I want to avoid is to have to define procedures and patches for all the clients. However if you use ipa-client-install it would configure sssd the old way. How to make it configured the new way? Manually? This is error prone and people will be reluctant to reconfigure SSSD. Automatically? Means patches to all the versions of the clients. How we are going to deal with the huge test matrix? In any case we need to come with the good automated test procedure that would: 1) Install old version of SSSD 2) Run test with AD user - fail 3) Apply patch or change configuration 4) Run test with AD user - success That should be implemented for all versions of SSSD 1.5 - 1.8 And all this should be a part of the design. >> >> -- >> / Alexander Bokovoy >> >> _______________________________________________ >> 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From thozza at redhat.com Wed May 29 14:38:38 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 29 May 2013 10:38:38 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES 0156-0158] Automatically disable empty zones when necessary In-Reply-To: <51A368A1.9070102@redhat.com> References: <51A368A1.9070102@redhat.com> Message-ID: <518597696.5093778.1369838318430.JavaMail.root@redhat.com> ACK. Patches look good and work as expected! Regards, Tomas Hozza ----- Original Message ----- > Hello, > > this patch set enables bind-dyndb-ldap to automatically unload empty zone > (see > RFC 6303) if an explicit configuration for this zone is present in LDAP. > > Please test it with idnsZone and also idnsForwardZone objectClasses. > > -- > Petr^2 Spacek > From pspacek at redhat.com Wed May 29 14:56:58 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 May 2013 16:56:58 +0200 Subject: [Freeipa-devel] [PATCHES 0156-0158] Automatically disable empty zones when necessary In-Reply-To: <518597696.5093778.1369838318430.JavaMail.root@redhat.com> References: <51A368A1.9070102@redhat.com> <518597696.5093778.1369838318430.JavaMail.root@redhat.com> Message-ID: <51A6173A.6000900@redhat.com> On 29.5.2013 16:38, Tomas Hozza wrote: > ACK. > > Patches look good and work as expected! Pushed to master: 96f795180d182bcc008159e5ce0102af9fc8324f, 3df30edeae3e1025c899338b554460aa9f0c742e, c9cdbe34b0d9a514d2b95a295d239ce0b2a0386f -- Petr^2 Spacek From pspacek at redhat.com Wed May 29 15:16:06 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 29 May 2013 17:16:06 +0200 Subject: [Freeipa-devel] [PATCH 0159] Deprecate configuration without persistent search In-Reply-To: <51A4B764.7040301@redhat.com> References: <51A4B764.7040301@redhat.com> Message-ID: <51A61BB6.4080406@redhat.com> On 28.5.2013 15:55, Petr Spacek wrote: > Hello, > > Deprecate configuration without persistent search. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/120 This version of the patch adds notice to the README. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0159-2-Deprecate-configuration-without-persistent-search.patch Type: text/x-patch Size: 2377 bytes Desc: not available URL: From nicmac at gmail.com Wed May 29 23:09:16 2013 From: nicmac at gmail.com (Nicholas MacKenzie) Date: Wed, 29 May 2013 19:09:16 -0400 Subject: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket In-Reply-To: <20130528083042.GR26689@redhat.com> References: <20130528074650.GQ26689@redhat.com> <20130528083042.GR26689@redhat.com> Message-ID: Agreed. I was using an AD Enterprise Admin account from an "ADMIN" realm out of habit. Once I used the "Administrator" user from the "AD" realm it was fine. Thanks again. On Tue, May 28, 2013 at 4:30 AM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Nicholas MacKenzie wrote: > >> You were spot on about that. I enabled IPv6 and now the CLDAP plugin >> installs fine. I am now faced with this... >> >> dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED >> Failed to bind to uuid 12345778-1234-abcd-ef00-**0123456789ab for >> 12345778-1234-abcd-ef00-**0123456789ab at ncacn_ip_tcp: >> domain_controller.ad.dc.com[**49500] NT_STATUS_NET_WRITE_FAULT >> [Tue May 28 08:20:03 2013] [error] ipa: INFO: admin at IPA.DC.COM: >> trust_add(u' >> ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username', >> realm_passwd=u'********', range_size=200000, all=False, raw=False, >> version=u'2.46'): ACIError >> > Specify your AD admin username fully-qualified, either DOMAIN\username > or username at REALM. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diane at ghic.org Thu May 30 06:26:17 2013 From: diane at ghic.org (Diane Trout) Date: Wed, 29 May 2013 23:26:17 -0700 Subject: [Freeipa-devel] Minor error: format not a string literal and no format arguments [-Werror=format-security] Message-ID: <2421658.MiZkXgAtf3@myrada> Hi, I was trying to compile freeipa on debian and the compiler threw a minor error. Resolve a -Werror=format-security error. ipa_extdom_extop.c: In function 'ipa_extdom_extop': ipa_extdom_extop.c:144:9: error: format not a string literal and no format arguments [-Werror=format-security] --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -141,7 +141,7 @@ free(req); free(res); if (err_msg != NULL) { - LOG(err_msg); + LOG("%s", err_msg); } slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL); return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; From sbose at redhat.com Thu May 30 09:01:02 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 30 May 2013 11:01:02 +0200 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <51A6084A.7050500@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> Message-ID: <20130530090102.GC1945@localhost.localdomain> On Wed, May 29, 2013 at 09:53:14AM -0400, Dmitri Pal wrote: > On 05/29/2013 03:28 AM, Sumit Bose wrote: > > On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: > >> On Tue, 28 May 2013, Dmitri Pal wrote: > >>> On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: > >>>> On Tue, 28 May 2013, Dmitri Pal wrote: > >>>>> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: > >>>>>> On Tue, 28 May 2013, Dmitri Pal wrote: > >>>>>>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> > >>>>>>>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > >>>>>>>> > >>>>>>>> = Overview = > >>>>>>>> > >>>>>>>> Since version 3.0 FreeIPA supports cross-realm trusts with Active > >>>>>>>> Directory. In order to allow AD users to utilize services on IPA > >>>>>>>> clients, up to date version of SSSD should be configured at the IPA > >>>>>>>> client. In case it is not possible to install and configure SSSD > > >>>>>>>> 1.09, > >>>>>>>> Active Directory users cannot access services on IPA clients. > >>>>>>>> > >>>>>>>> This feature is designed to bridge the gap and provide minimal > >>>>>>>> compatibility level that allows to log-in to IPA clients for AD > >>>>>>>> users. > >>>>>>>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd > >>>>>>>> version. > >>>>>>>> = Use Cases = > >>>>>>>> > >>>>>>>> Access to IPA client machine resources for AD users in case IPA > >>>>>>>> client > >>>>>>>> cannot utilize up to date version of SSSD with native support for IPA > >>>>>>>> cross-realm trusts. > >>>>>>>> > >>>>>>>> = Design= > >>>>>>>> Since IPA client is configured with the use of older SSSD or > >>>>>>>> nss_ldap/pam_ldap, all work should be performed at the IPA master. > >>>>>>>> Primary design decision is to provide a separate LDAP tree, > >>>>>>>> similar to > >>>>>>>> compat tree, that has following features: > >>>>>>>> > >>>>>>>> * information about both IPA and AD users can be queried; > >>>>>>>> * it ispossible to enumerate members of IPA and AD groups; > >>>>>>>> * authentication bind to IPA LDAP as AD users should automatically > >>>>>>>> * trigger obtaining ticket from AD DC; in case TGT is obtained, > >>>>>>>> * authentication bind should be treated as successful. > >>>>>>>> > >>>>>>> >From a client perspective, use of the separate LDAP tree is viewed as > >>>>>>>> traditional nss_ldap/pam_ldap configuration. > >>>>>>>> > >>>>>>>> Proposed base for the LDAP tree: > >>>>>>>> '''cn=users,cn=trust-accounts,dc=example,dc=com''' > >>>>>>>> > >>>>>>>> = Implementation = > >>>>>>>> > >>>>>>>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on > >>>>>>>> install or upgrade > >>>>>>>> # ipa-adtrust-install configures additional directory server > >>>>>>>> plugin to > >>>>>>>> serve trusted domains tree > >>>>>>>> # Directory server plugin uses getpwnam_r(), getgrnam_r() and > >>>>>>>> related > >>>>>>>> calls to obtain information about AD user. For IPA users the > >>>>>>>> information is fetched directly from the LDAP. > >>>>>>>> # IPA KDC database driver adds MS-PAC information into ticket > >>>>>>>> granting > >>>>>>>> ticket for host/fqdn at REALM principal of IPA master. This is required > >>>>>>>> to allow SSSD on IPA master to authenticate against AD using > >>>>>>>> host/fqdn at REALM principal. > >>>>>>>> > >>>>>>>> For SSSD design see > >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > >>>>>>>> > >>>>>>>> = Feature Management = > >>>>>>>> > >>>>>>>> === UI === > >>>>>>>> > >>>>>>>> The feature is transparent and not exposed in UI > >>>>>>>> > >>>>>>>> === CLI === > >>>>>>>> > >>>>>>>> The feature is not directly exposed in CLI. > >>>>>>>> IPA idrange management is expanded to specify idrange type (IPA > >>>>>>>> local, > >>>>>>>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD > >>>>>>>> users > >>>>>>>> SIDs are mapped to POSIX IDs. > >>>>>>>> > >>>>>>>> = Major configuration options and enablement = > >>>>>>>> > >>>>>>>> sssd.conf will have 'ipa_server_mode = true' set for IPA master. > >>>>>>>> > >>>>>>>> = Replication = > >>>>>>>> > >>>>>>>> No effect on replication. Since directory server plugin is only > >>>>>>>> configured when ipa-adtrust-install is run, IPA masters may opt out > >>>>>>>> from > >>>>>>>> serving AD clients. > >>>>>>>> > >>>>>>>> = Updates and Upgrades = > >>>>>>>> > >>>>>>>> During upgrade of IPA master, sssd.conf should be updated to set > >>>>>>>> 'ipa_server_mode = true'. > >>>>>>>> > >>>>>>>> = Dependencies = > >>>>>>>> > >>>>>>>> Depends on SSSD implementing IPA server mode (sssd 1.10.x) > >>>>>>>> > >>>>>>>> = External Impact = > >>>>>>>> > >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > >>>>>>>> > >>>>>>>> = Backup and Restore = > >>>>>>>> > >>>>>>>> No external configuration files are affected > >>>>>>>> > >>>>>>>> = Test Plan = > >>>>>>>> > >>>>>>>> Testing the feature will require following: > >>>>>>>> > >>>>>>>> # Configure IPA to serve AD trusts > >>>>>>>> # Establish trust with AD domain > >>>>>>>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible > >>>>>>>> tree > >>>>>>>> # Attempt to log-in to the client as AD user > >>>>>>>> > >>>>>>>> = RFE Author = > >>>>>>>> > >>>>>>>> [[User:Ab|ab]] ([[User talk:Ab|talk]]) > >>>>>>>> > >>>>>>> > >>>>>>> Can you please explain how the older SSSD or other UNIX versions would > >>>>>>> use Kerberos for authentication? > >>>>>> pam_krb5 should work as it is, as well as older SSSD, since any AD user > >>>>>> attempting to connect using GSSAPI to IPA services will have > >>>>>> cross-realm > >>>>>> TGT issued for us by the trusting AD DC prior to that attempt. > >>>>>> > >>>>>> The whole idea was to make sure for old clients these users will look > >>>>>> like normal users, via nss_ldap/SSSD. > >>>>>> > >>>>>> We still will need to configure principal mapping in /etc/krb5.conf > >>>>>> like > >>>>>> we do for AD users with trusts. > >>>>>> > >>>>>>> I thought we would have to issue some patch for client to switch the > >>>>>>> clients from using Kerberos for authentication to using LDAP. > >>>>>> No need to. pam_ldap would go through LDAP bind automatically, that's > >>>>>> why the proposal talks about attempting to obtain TGT in place of a > >>>>>> user > >>>>>> instead of proxying such LDAP bind back to AD DC. This would require us > >>>>>> enforcing clear password bind over TLS/SSL but it is simpler to > >>>>>> achieve. > >>>>>> > >>>>> I am missing something. How a simple kinit would work? > >>>>> Can you please describe the sequence and workflow? > >>>> I'm talking about the case when AD user logs in into IPA client using > >>>> PuTTY from Windows machine. In such case there is already service ticket > >>>> and cross-realm TGT available. > >>>> > >>>> For kinit on IPA client all what is needed is /etc/krb5.conf > >>>> configuration that forces to talk to AD DC for principals in AD realm. > >>>> > >>>> It can be done via SRV records in DNS or manually in /etc/krb5.conf. > >>>> > >>>> For example, on the machine I'm writing this email I added manual > >>>> routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do > >>>> following: > >>>> > >>>> # klist > >>>> klist: No credentials cache found (ticket cache > >>>> DIR::/run/user/0/krb5cc/tkt) > >>>> # kinit Administrator at AD.LAN > >>>> Password for Administrator at AD.LAN: Warning: Your password will expire > >>>> in 2 days on ??. 31 ??? 2013 07:29:10 > >>>> # klist > >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO > >>>> Default principal: Administrator at AD.LAN > >>>> > >>>> Valid starting Expires Service principal > >>>> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN > >>>> renew until 04.06.2013 23:24:44 > >>>> # kvno HTTP/red.bird.clone at BIRD.CLONE > >>>> HTTP/red.bird.clone at BIRD.CLONE: kvno = 2 > >>>> # klist > >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO > >>>> Default principal: Administrator at AD.LAN > >>>> > >>>> Valid starting Expires Service principal > >>>> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN > >>>> renew until 04.06.2013 23:24:44 > >>>> 28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/BIRD.CLONE at AD.LAN > >>>> renew until 04.06.2013 23:24:44 > >>>> 28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone at BIRD.CLONE > >>>> renew until 04.06.2013 23:24:44 > >>>> > >>> This is exactly the problem I am try to get to. > >>> Let us take CentOS 6.3 machine and configure SSSD against IPA. It has > >>> absolutely no knowledge about AD. This is the whole point. > >>> But AD users should be able to walk to the console and authenticate. The > >>> flow will be: > >>> User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD > >>> But there is no design for such flow. And IMO it is too much. > >> For this use case LDAP-based authentication has to be configured. > >> > >> For any remote login we can rely on Kerberos authentication. > >> > >> For over console login we cannot rely on Kerberos authentication without > >> explicit help from either KDC or SSSD. > >> > >> What we can do in our KDB driver is to force KDC to issue KDC referral > >> for users from trusted domains, rewriting the realm and redirecting to > >> AD DC. This is how AD DC performs in a forest when a client talks to > >> non-root DC in request of a ticket for a service in a trusted domain. > >> > >> However, I think it could be a good target for 3.4. > >> > >>> What you are suggesting here is a sort of "split brain solution" that we > >>> did not recommend in the past are we going to change out assessment of > >>> this approach? > >> No. What I suggested did not include direct console logins. > >> > >>> So to summarize we are talking about the case: > >>> a) Legacy/UNIX systems are configured to authenticate/joined to IPA and > >>> do not know about AD > >>> b) User from AD walks to the console and uses his name and password > >>> > >>> He needs to be authenticated. How? > >> See above. KDC needs to recognize this user is from a trusted domain (by > >> the domain's realm) and issue a referral to AD DCs which handle it. > > If I understand the issue correctly then only 'dns_lookup_kdc = true' > > must be set in /etc/krb5.conf on the client. > > > > For passowrd based console logins the client must the able to resolve > > the trusted AD DC with a DNS SRV lookup and must be able to connect to > > one of the returned DCs because only the AD DC can authenticate the > > user. It is the same way as this type of authentication is working for > > sssd in 6.4. And it is basically the same way as it works for Windows > > clients, only that here the AD DC of the Windows client is contacted > > first and returns a Kerberos client referral to the Windows client as > > Alexander mentioned above. Then the Windows client also has to find a DC > > of the trusted domain and send the request to the trusted DC. > > > > HTH > > > > bye, > > Sumit > > > This whole discussion is missing from the design page. > However we are not yet out of the woods. > > In the upstream version we need to support SSSD 1.5 and later on Fedora, > RHEL CentOS, etc. > pam_krb5 from 1.7 and later > Solaris 10, 11 > AIX 6.x > HP-UX may be > > For UNIXes you really can't patch the client so there should be a > procedure to setup these clients. > In most cases these clients use LDAP rather than kerberos so I think it > is acceptable to not support Kerberos console login from those systems > for AD users. > The systems should be configured using LDAP against IPA and would know > only native IPA users (in console login). > But if Kerberos can be made to work fine I am all for it. For those > clients we do not have an automated install procedure so it is given > that the setup will be manual. There are two type of Kerberos based authentication here. First and preferred one, if the client can handle Kerberos authentication it should do it directly against AD. In most cases this would give the user a valid ticket in his credential cache which he can use for SSO to other services. Second is the Kerberos authentication we are planning on the server side. The client does an authenticated LDAP bind to validate the credentials the user gave at the login prompt. Since the IPA server cannot do the validation itself it will forward the credentials via the PAM pass-through plugin which in the end will do a kinit with the forwarded credentials of the user. In this case the user on the client will not have any Kerberos tickets after login, but at least authentication of AD users would be possible even for an LDAP only client. > > For Lunix and older SSSD version we in fact have a problem. > What I want to avoid is to have to define procedures and patches for all ^^^^^^ ? > the clients. However if you use ipa-client-install it would configure > sssd the old way. > How to make it configured the new way? Manually? This is error prone and > people will be reluctant to reconfigure SSSD. Automatically? Means > patches to all the versions of the clients. > How we are going to deal with the huge test matrix? I think rolling out patches to old sssd versions is not a good idea and I think we won't have the time to prepare all the needed patches in a reasonable time-frame. For SSSD versions which do not allow multiple search bases (1.5 and 1.6) I would suggest to add a new domain section for the AD user with LDAP and Kerberos provider. This would allow IPA users to works as before and add the AD users to the client. Maybe this would also be a better solution for the other SSSD versions instead of multiple search bases, at least it's a solution for all versions. Since we have the python config API for SSSD the needed changes to the sssd.conf might be scriptable with a reasonable effort. Maybe this can be added to ipa-client-install with a new option like --enable-legacy-trust-support which can add the news section to existing configuration or include it for new installations? bye, Sumit > > In any case we need to come with the good automated test procedure that > would: > 1) Install old version of SSSD > 2) Run test with AD user - fail > 3) Apply patch or change configuration > 4) Run test with AD user - success > > That should be implemented for all versions of SSSD 1.5 - 1.8 > And all this should be a part of the design. > > >> > >> -- > >> / Alexander Bokovoy > >> > >> _______________________________________________ > >> 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 > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jhrozek at redhat.com Thu May 30 09:18:58 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 30 May 2013 11:18:58 +0200 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130530090102.GC1945@localhost.localdomain> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> Message-ID: <20130530091858.GB19954@hendrix.brq.redhat.com> On Thu, May 30, 2013 at 11:01:02AM +0200, Sumit Bose wrote: > > For Lunix and older SSSD version we in fact have a problem. > > What I want to avoid is to have to define procedures and patches for all > ^^^^^^ ? > > the clients. However if you use ipa-client-install it would configure > > sssd the old way. > > How to make it configured the new way? Manually? This is error prone and > > people will be reluctant to reconfigure SSSD. Automatically? Means > > patches to all the versions of the clients. > > How we are going to deal with the huge test matrix? > > I think rolling out patches to old sssd versions is not a good idea and > I think we won't have the time to prepare all the needed patches in a > reasonable time-frame. > > For SSSD versions which do not allow multiple search bases (1.5 and 1.6) > I would suggest to add a new domain section for the AD user with LDAP > and Kerberos provider. This would allow IPA users to works as before and > add the AD users to the client. Maybe this would also be a better > solution for the other SSSD versions instead of multiple search bases, > at least it's a solution for all versions. > +1, I remember that the patches to support multiple search bases were highly non-trivial and caused some regressions at the time (which is completely understandable given their size). Backporting them would be a devel and QE nightmare, we would have to backport not only the patches but all the fixes for the regressions. The only drawback of multiple domains is slightly worse performance as with multiple domains you need to iterate over the domains in the responders and contact the DP for every domains while with multiple search bases the whole logic happens in the DP without the round-trips to PAM or NSS responders. This disadvantage doesn't apply when using FQDNs as then you shortcut to the correct domain already. > Since we have the python config API for SSSD the needed changes to the > sssd.conf might be scriptable with a reasonable effort. Maybe this can > be added to ipa-client-install with a new option like > --enable-legacy-trust-support which can add the news section to existing > configuration or include it for new installations? > > bye, > Sumit From sbose at redhat.com Thu May 30 09:35:32 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 30 May 2013 11:35:32 +0200 Subject: [Freeipa-devel] Minor error: format not a string literal and no format arguments [-Werror=format-security] In-Reply-To: <2421658.MiZkXgAtf3@myrada> References: <2421658.MiZkXgAtf3@myrada> Message-ID: <20130530093532.GD1945@localhost.localdomain> On Wed, May 29, 2013 at 11:26:17PM -0700, Diane Trout wrote: > Hi, > > I was trying to compile freeipa on debian and the compiler threw a minor > error. > > Resolve a -Werror=format-security error. > > ipa_extdom_extop.c: In function 'ipa_extdom_extop': > ipa_extdom_extop.c:144:9: error: format not a string literal and no format > arguments [-Werror=format-security] > > --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c > +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c > @@ -141,7 +141,7 @@ > free(req); > free(res); > if (err_msg != NULL) { > - LOG(err_msg); > + LOG("%s", err_msg); > } > slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL); > return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; This is obviously correct, ACK. Do you have a chance to resent the patch as a git formatted one? If not, I can prepare one for you and resent it. bye, Sumit > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Thu May 30 10:30:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 30 May 2013 13:30:44 +0300 Subject: [Freeipa-devel] [PATCH 0056] Support multiple local domain ranges with RID base set In-Reply-To: <51910A97.6070809@redhat.com> References: <51910A97.6070809@redhat.com> Message-ID: <20130530103044.GO26689@redhat.com> On Mon, 13 May 2013, Tomas Babej wrote: >Hi, > >In ipa-adtrust-install, "adding RID bases" step would fail >if there was more than one local range defined. This can be a >common case if e.g. there are users that migrated from previous >IdM solution. > >With this patch, we fail only if there are multiple local ranges >that do not have RID bases set. > >Keep in mind that overlap checking is ensured by ipa-range-check >DS plugin. > >https://fedorahosted.org/freeipa/ticket/3498 ACK. I initially didn't like that lambda use for the reason it is used only once but I can live with that. -- / Alexander Bokovoy From mkosek at redhat.com Thu May 30 10:36:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 30 May 2013 12:36:39 +0200 Subject: [Freeipa-devel] [PATCH 0056] Support multiple local domain ranges with RID base set In-Reply-To: <20130530103044.GO26689@redhat.com> References: <51910A97.6070809@redhat.com> <20130530103044.GO26689@redhat.com> Message-ID: <51A72BB7.7010600@redhat.com> On 05/30/2013 12:30 PM, Alexander Bokovoy wrote: > On Mon, 13 May 2013, Tomas Babej wrote: >> Hi, >> >> In ipa-adtrust-install, "adding RID bases" step would fail >> if there was more than one local range defined. This can be a >> common case if e.g. there are users that migrated from previous >> IdM solution. >> >> With this patch, we fail only if there are multiple local ranges >> that do not have RID bases set. >> >> Keep in mind that overlap checking is ensured by ipa-range-check >> DS plugin. >> >> https://fedorahosted.org/freeipa/ticket/3498 > ACK. > > I initially didn't like that lambda use for the reason it is used only > once but I can live with that. > Pushed to master, ipa-3-2. Martin From mkosek at redhat.com Thu May 30 10:41:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 30 May 2013 12:41:18 +0200 Subject: [Freeipa-devel] CLDAP Netlogon fixes In-Reply-To: <51A4CB8E.9000005@redhat.com> References: <1369320131.2769.30.camel@willson.li.ssimo.org> <1369329755.2769.39.camel@willson.li.ssimo.org> <20130523180204.GG26689@redhat.com> <1369336004.2769.56.camel@willson.li.ssimo.org> <1369336335.2769.58.camel@willson.li.ssimo.org> <20130528123550.GU26689@redhat.com> <51A4BB56.9050700@redhat.com> <51A4BB9F.8010505@redhat.com> <51A4CB8E.9000005@redhat.com> Message-ID: <51A72CCE.2040001@redhat.com> On 05/28/2013 05:21 PM, Martin Kosek wrote: > On 05/28/2013 04:13 PM, Martin Kosek wrote: >> On 05/28/2013 04:12 PM, Martin Kosek wrote: >>> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>>> On Thu, 23 May 2013, Simo Sorce wrote: >>>>>>> As you can see, incorrect parameters still return empty dn and netlogon >>>>>>> attributes while Windows Server 2012 returns empty response: >>>>>>> >>>>>>> $ ldapsearch -LL -H cldap://altai.ad.lan -b "" -s base >>>>>> '(&(NtVer=\00\00\00\55\00)(AAC=\00\00\00\00))' netlogon >>>>>>> version: 1 >>>>>>> >>>>>>> Yet, since for trusts we care about explicit request with our domain name >>>>>> _and_ the >>>>>>> case when DnsDomain is not specified, everything continues to work. >>>>>>> >>>>>>> So ACK. >>>>>> >>>>>> I can easily avoid returning the empty netlogon field, which is what I >>>>>> wanted to do. >>>>>> I'll see if I can also avoid returning the DN. >>>>>> >>>>>> Let me try just one more revision. >>>>> >>>>> It was a simple fix, attached patches omit LDAP_RES_SERAHC_ENTRY >>>>> completely as they were supposed to, and only return a >>>>> LDAP_RES_SEARCH_RESULT record. >>>> Thanks. >>>> >>>> Tested and it works fine. >>>> >>> >>> ACK. Pushed to master, ipa-3-1, ipa-3-0. >> >> Sorry, off-by-one error :-) The actual branches where I pushed this were >> master, ipa-3-2 and ipa-3-1. >> >> Martin >> >>> >>> I will release 3.1.5 soon to Fedora 18 to fix cooperation with realmd. >>> >>> Martin >>> > > I just noticed a strange behavior when I was sanity testing upcoming 3.1.5 release: > > # ldapsearch -LL -H cldap://vm-037.idm.lab.bos.redhat.com -b "" -s base > '(&(DnsDomain=foo)(NtVer=\06\00\00\00)(AAC=\00\00\00\00))' > version: 1 > > # > > ... this looks correct. But following call hangs: > > # ldapsearch -LL -H cldap://vm-037.idm.lab.bos.redhat.com -b "" -s base > '(NtVer=\06\00\00\00)' > version: 1 > > ^C > > This does not look right. Am I doing something wrong? > > Martin > ACK for Alexander's patch reviewed off list (attached). Pushed to master, ipa-3-2, ipa-3-1. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-abbra-104-Fix-cldap-parser-2.patch Type: text/x-patch Size: 2323 bytes Desc: not available URL: From abokovoy at redhat.com Thu May 30 11:40:20 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 30 May 2013 14:40:20 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130530090102.GC1945@localhost.localdomain> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> Message-ID: <20130530114020.GP26689@redhat.com> On Thu, 30 May 2013, Sumit Bose wrote: >On Wed, May 29, 2013 at 09:53:14AM -0400, Dmitri Pal wrote: >> On 05/29/2013 03:28 AM, Sumit Bose wrote: >> > On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: >> >> On Tue, 28 May 2013, Dmitri Pal wrote: >> >>> On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: >> >>>> On Tue, 28 May 2013, Dmitri Pal wrote: >> >>>>> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >> >>>>>> On Tue, 28 May 2013, Dmitri Pal wrote: >> >>>>>>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts >> >>>>>>>> >> >>>>>>>> = Overview = >> >>>>>>>> >> >>>>>>>> Since version 3.0 FreeIPA supports cross-realm trusts with Active >> >>>>>>>> Directory. In order to allow AD users to utilize services on IPA >> >>>>>>>> clients, up to date version of SSSD should be configured at the IPA >> >>>>>>>> client. In case it is not possible to install and configure SSSD > >> >>>>>>>> 1.09, >> >>>>>>>> Active Directory users cannot access services on IPA clients. >> >>>>>>>> >> >>>>>>>> This feature is designed to bridge the gap and provide minimal >> >>>>>>>> compatibility level that allows to log-in to IPA clients for AD >> >>>>>>>> users. >> >>>>>>>> IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd >> >>>>>>>> version. >> >>>>>>>> = Use Cases = >> >>>>>>>> >> >>>>>>>> Access to IPA client machine resources for AD users in case IPA >> >>>>>>>> client >> >>>>>>>> cannot utilize up to date version of SSSD with native support for IPA >> >>>>>>>> cross-realm trusts. >> >>>>>>>> >> >>>>>>>> = Design= >> >>>>>>>> Since IPA client is configured with the use of older SSSD or >> >>>>>>>> nss_ldap/pam_ldap, all work should be performed at the IPA master. >> >>>>>>>> Primary design decision is to provide a separate LDAP tree, >> >>>>>>>> similar to >> >>>>>>>> compat tree, that has following features: >> >>>>>>>> >> >>>>>>>> * information about both IPA and AD users can be queried; >> >>>>>>>> * it ispossible to enumerate members of IPA and AD groups; >> >>>>>>>> * authentication bind to IPA LDAP as AD users should automatically >> >>>>>>>> * trigger obtaining ticket from AD DC; in case TGT is obtained, >> >>>>>>>> * authentication bind should be treated as successful. >> >>>>>>>> >> >>>>>>> >From a client perspective, use of the separate LDAP tree is viewed as >> >>>>>>>> traditional nss_ldap/pam_ldap configuration. >> >>>>>>>> >> >>>>>>>> Proposed base for the LDAP tree: >> >>>>>>>> '''cn=users,cn=trust-accounts,dc=example,dc=com''' >> >>>>>>>> >> >>>>>>>> = Implementation = >> >>>>>>>> >> >>>>>>>> # IPA server sets SSSD configuration to 'ipa_server_mode = true' on >> >>>>>>>> install or upgrade >> >>>>>>>> # ipa-adtrust-install configures additional directory server >> >>>>>>>> plugin to >> >>>>>>>> serve trusted domains tree >> >>>>>>>> # Directory server plugin uses getpwnam_r(), getgrnam_r() and >> >>>>>>>> related >> >>>>>>>> calls to obtain information about AD user. For IPA users the >> >>>>>>>> information is fetched directly from the LDAP. >> >>>>>>>> # IPA KDC database driver adds MS-PAC information into ticket >> >>>>>>>> granting >> >>>>>>>> ticket for host/fqdn at REALM principal of IPA master. This is required >> >>>>>>>> to allow SSSD on IPA master to authenticate against AD using >> >>>>>>>> host/fqdn at REALM principal. >> >>>>>>>> >> >>>>>>>> For SSSD design see >> >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >> >>>>>>>> >> >>>>>>>> = Feature Management = >> >>>>>>>> >> >>>>>>>> === UI === >> >>>>>>>> >> >>>>>>>> The feature is transparent and not exposed in UI >> >>>>>>>> >> >>>>>>>> === CLI === >> >>>>>>>> >> >>>>>>>> The feature is not directly exposed in CLI. >> >>>>>>>> IPA idrange management is expanded to specify idrange type (IPA >> >>>>>>>> local, >> >>>>>>>> AD trust, AD with winsync, IPA trust, ..) to affect the way how AD >> >>>>>>>> users >> >>>>>>>> SIDs are mapped to POSIX IDs. >> >>>>>>>> >> >>>>>>>> = Major configuration options and enablement = >> >>>>>>>> >> >>>>>>>> sssd.conf will have 'ipa_server_mode = true' set for IPA master. >> >>>>>>>> >> >>>>>>>> = Replication = >> >>>>>>>> >> >>>>>>>> No effect on replication. Since directory server plugin is only >> >>>>>>>> configured when ipa-adtrust-install is run, IPA masters may opt out >> >>>>>>>> from >> >>>>>>>> serving AD clients. >> >>>>>>>> >> >>>>>>>> = Updates and Upgrades = >> >>>>>>>> >> >>>>>>>> During upgrade of IPA master, sssd.conf should be updated to set >> >>>>>>>> 'ipa_server_mode = true'. >> >>>>>>>> >> >>>>>>>> = Dependencies = >> >>>>>>>> >> >>>>>>>> Depends on SSSD implementing IPA server mode (sssd 1.10.x) >> >>>>>>>> >> >>>>>>>> = External Impact = >> >>>>>>>> >> >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode >> >>>>>>>> >> >>>>>>>> = Backup and Restore = >> >>>>>>>> >> >>>>>>>> No external configuration files are affected >> >>>>>>>> >> >>>>>>>> = Test Plan = >> >>>>>>>> >> >>>>>>>> Testing the feature will require following: >> >>>>>>>> >> >>>>>>>> # Configure IPA to serve AD trusts >> >>>>>>>> # Establish trust with AD domain >> >>>>>>>> # Configure a client to use nss_ldap/pam_ldap against AD-compatible >> >>>>>>>> tree >> >>>>>>>> # Attempt to log-in to the client as AD user >> >>>>>>>> >> >>>>>>>> = RFE Author = >> >>>>>>>> >> >>>>>>>> [[User:Ab|ab]] ([[User talk:Ab|talk]]) >> >>>>>>>> >> >>>>>>> >> >>>>>>> Can you please explain how the older SSSD or other UNIX versions would >> >>>>>>> use Kerberos for authentication? >> >>>>>> pam_krb5 should work as it is, as well as older SSSD, since any AD user >> >>>>>> attempting to connect using GSSAPI to IPA services will have >> >>>>>> cross-realm >> >>>>>> TGT issued for us by the trusting AD DC prior to that attempt. >> >>>>>> >> >>>>>> The whole idea was to make sure for old clients these users will look >> >>>>>> like normal users, via nss_ldap/SSSD. >> >>>>>> >> >>>>>> We still will need to configure principal mapping in /etc/krb5.conf >> >>>>>> like >> >>>>>> we do for AD users with trusts. >> >>>>>> >> >>>>>>> I thought we would have to issue some patch for client to switch the >> >>>>>>> clients from using Kerberos for authentication to using LDAP. >> >>>>>> No need to. pam_ldap would go through LDAP bind automatically, that's >> >>>>>> why the proposal talks about attempting to obtain TGT in place of a >> >>>>>> user >> >>>>>> instead of proxying such LDAP bind back to AD DC. This would require us >> >>>>>> enforcing clear password bind over TLS/SSL but it is simpler to >> >>>>>> achieve. >> >>>>>> >> >>>>> I am missing something. How a simple kinit would work? >> >>>>> Can you please describe the sequence and workflow? >> >>>> I'm talking about the case when AD user logs in into IPA client using >> >>>> PuTTY from Windows machine. In such case there is already service ticket >> >>>> and cross-realm TGT available. >> >>>> >> >>>> For kinit on IPA client all what is needed is /etc/krb5.conf >> >>>> configuration that forces to talk to AD DC for principals in AD realm. >> >>>> >> >>>> It can be done via SRV records in DNS or manually in /etc/krb5.conf. >> >>>> >> >>>> For example, on the machine I'm writing this email I added manual >> >>>> routing to my VMs with AD and IPA to /etc/krb5.conf and I'm able to do >> >>>> following: >> >>>> >> >>>> # klist >> >>>> klist: No credentials cache found (ticket cache >> >>>> DIR::/run/user/0/krb5cc/tkt) >> >>>> # kinit Administrator at AD.LAN >> >>>> Password for Administrator at AD.LAN: Warning: Your password will expire >> >>>> in 2 days on ??. 31 ??? 2013 07:29:10 >> >>>> # klist >> >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO >> >>>> Default principal: Administrator at AD.LAN >> >>>> >> >>>> Valid starting Expires Service principal >> >>>> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN >> >>>> renew until 04.06.2013 23:24:44 >> >>>> # kvno HTTP/red.bird.clone at BIRD.CLONE >> >>>> HTTP/red.bird.clone at BIRD.CLONE: kvno = 2 >> >>>> # klist >> >>>> Ticket cache: DIR::/run/user/0/krb5cc/tktP0IiKO >> >>>> Default principal: Administrator at AD.LAN >> >>>> >> >>>> Valid starting Expires Service principal >> >>>> 28.05.2013 23:24:44 29.05.2013 09:24:44 krbtgt/AD.LAN at AD.LAN >> >>>> renew until 04.06.2013 23:24:44 >> >>>> 28.05.2013 23:25:45 29.05.2013 09:24:44 krbtgt/BIRD.CLONE at AD.LAN >> >>>> renew until 04.06.2013 23:24:44 >> >>>> 28.05.2013 23:26:42 29.05.2013 09:24:44 HTTP/red.bird.clone at BIRD.CLONE >> >>>> renew until 04.06.2013 23:24:44 >> >>>> >> >>> This is exactly the problem I am try to get to. >> >>> Let us take CentOS 6.3 machine and configure SSSD against IPA. It has >> >>> absolutely no knowledge about AD. This is the whole point. >> >>> But AD users should be able to walk to the console and authenticate. The >> >>> flow will be: >> >>> User -> SSSD -> kerberos library -> KDC -> ???? -> SSSD on IPA -> AD >> >>> But there is no design for such flow. And IMO it is too much. >> >> For this use case LDAP-based authentication has to be configured. >> >> >> >> For any remote login we can rely on Kerberos authentication. >> >> >> >> For over console login we cannot rely on Kerberos authentication without >> >> explicit help from either KDC or SSSD. >> >> >> >> What we can do in our KDB driver is to force KDC to issue KDC referral >> >> for users from trusted domains, rewriting the realm and redirecting to >> >> AD DC. This is how AD DC performs in a forest when a client talks to >> >> non-root DC in request of a ticket for a service in a trusted domain. >> >> >> >> However, I think it could be a good target for 3.4. >> >> >> >>> What you are suggesting here is a sort of "split brain solution" that we >> >>> did not recommend in the past are we going to change out assessment of >> >>> this approach? >> >> No. What I suggested did not include direct console logins. >> >> >> >>> So to summarize we are talking about the case: >> >>> a) Legacy/UNIX systems are configured to authenticate/joined to IPA and >> >>> do not know about AD >> >>> b) User from AD walks to the console and uses his name and password >> >>> >> >>> He needs to be authenticated. How? >> >> See above. KDC needs to recognize this user is from a trusted domain (by >> >> the domain's realm) and issue a referral to AD DCs which handle it. >> > If I understand the issue correctly then only 'dns_lookup_kdc = true' >> > must be set in /etc/krb5.conf on the client. >> > >> > For passowrd based console logins the client must the able to resolve >> > the trusted AD DC with a DNS SRV lookup and must be able to connect to >> > one of the returned DCs because only the AD DC can authenticate the >> > user. It is the same way as this type of authentication is working for >> > sssd in 6.4. And it is basically the same way as it works for Windows >> > clients, only that here the AD DC of the Windows client is contacted >> > first and returns a Kerberos client referral to the Windows client as >> > Alexander mentioned above. Then the Windows client also has to find a DC >> > of the trusted domain and send the request to the trusted DC. >> > >> > HTH >> > >> > bye, >> > Sumit >> >> >> This whole discussion is missing from the design page. >> However we are not yet out of the woods. >> >> In the upstream version we need to support SSSD 1.5 and later on Fedora, >> RHEL CentOS, etc. >> pam_krb5 from 1.7 and later >> Solaris 10, 11 >> AIX 6.x >> HP-UX may be >> >> For UNIXes you really can't patch the client so there should be a >> procedure to setup these clients. >> In most cases these clients use LDAP rather than kerberos so I think it >> is acceptable to not support Kerberos console login from those systems >> for AD users. >> The systems should be configured using LDAP against IPA and would know >> only native IPA users (in console login). >> But if Kerberos can be made to work fine I am all for it. For those >> clients we do not have an automated install procedure so it is given >> that the setup will be manual. > >There are two type of Kerberos based authentication here. First and >preferred one, if the client can handle Kerberos authentication it >should do it directly against AD. In most cases this would give the user >a valid ticket in his credential cache which he can use for SSO to other >services. > >Second is the Kerberos authentication we are planning on the server >side. The client does an authenticated LDAP bind to validate the >credentials the user gave at the login prompt. Since the IPA server >cannot do the validation itself it will forward the credentials via the >PAM pass-through plugin which in the end will do a kinit with the >forwarded credentials of the user. In this case the user on the client >will not have any Kerberos tickets after login, but at least >authentication of AD users would be possible even for an LDAP only >client. > >> >> For Lunix and older SSSD version we in fact have a problem. >> What I want to avoid is to have to define procedures and patches for all > ^^^^^^ ? >> the clients. However if you use ipa-client-install it would configure >> sssd the old way. >> How to make it configured the new way? Manually? This is error prone and >> people will be reluctant to reconfigure SSSD. Automatically? Means >> patches to all the versions of the clients. >> How we are going to deal with the huge test matrix? > >I think rolling out patches to old sssd versions is not a good idea and >I think we won't have the time to prepare all the needed patches in a >reasonable time-frame. > >For SSSD versions which do not allow multiple search bases (1.5 and 1.6) >I would suggest to add a new domain section for the AD user with LDAP >and Kerberos provider. This would allow IPA users to works as before and >add the AD users to the client. Maybe this would also be a better >solution for the other SSSD versions instead of multiple search bases, >at least it's a solution for all versions. > >Since we have the python config API for SSSD the needed changes to the >sssd.conf might be scriptable with a reasonable effort. Maybe this can >be added to ipa-client-install with a new option like >--enable-legacy-trust-support which can add the news section to existing >configuration or include it for new installations? Bigger question is what is simpler: write configuration instructions or modify/provide additional script for old SSSD? Remeber that trusts with AD are most likely established when IPA clients are already rolled out. Changing ipa-client-install is not helpful for this case since the clients are already there. Perhaps a better approach would be documentation for non-SSSD case and a simple snippet that can be run alone or in use with puppet/etc to deploy massively. The snippet would use SSSDConfig Python API to add needed modifications to the clients' SSSD configuration. We can even extend IPA server tools to allow generating such snippets based on the trusts configuration. After all, we do have control over IPA server in such cases. I have updated wiki page with discussed ideas. -- / Alexander Bokovoy From akrivoka at redhat.com Thu May 30 12:17:51 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 30 May 2013 14:17:51 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <519109CC.5090300@redhat.com> References: <518D06B1.1060904@redhat.com> <519109CC.5090300@redhat.com> Message-ID: <51A7436F.7060302@redhat.com> On 05/13/2013 05:42 PM, Tomas Babej wrote: > On 05/10/2013 04:39 PM, Tomas Babej wrote: >> Hi, >> >> this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 >> >> See commit messages for details. >> >> Tomas >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I noticed during further development that logic in > interactive_prompt_callback did not follow the pre_callback logic > precisely. > > Fixed patches attached. > > Tomas Hi, Patches work fine. I would suggest incorporating a fix for ticket https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The issue from ticket #3634 is closely connected to this one, and with the introduction of prompt_param() functionality, including a fix for it would require minimal effort. You can look at my patch (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) and if you think the approach is right, adjust accordingly and incorporate it in your patchset. Other (minor) comments: * The last change in ipalib/plugins/idrange.py seems like you wanted to fix the fact that the lines weren't properly indented (they weren't multiples of 4). However, you also need to fix the previous line (raise ...). * There are a lot of unused imports in ipalib/frontend.py. Since you are already touching imports in your patch, could you clean up the unused imports as well. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu May 30 12:28:40 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 30 May 2013 14:28:40 +0200 Subject: [Freeipa-devel] [PATCH 0061/0063] Add ipaRangeType attribute to LDAP Schema Message-ID: <51A745F8.80509@redhat.com> Hi, This adds a new LDAP attribute ipaRangeType with OID 2.16.840.1.113730.3.8.11.41 to the LDAP Schema. ObjectClass ipaIDrange has been altered to require ipaRangeType attribute. Part of https://fedorahosted.org/freeipa/ticket/3647 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0061-Add-ipaRangeType-attribute-to-LDAP-Schema.patch Type: text/x-patch Size: 5854 bytes Desc: not available URL: From tbabej at redhat.com Thu May 30 12:29:23 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 30 May 2013 14:29:23 +0200 Subject: [Freeipa-devel] [PATCH 0062/0063] Add update plugin to fill in ipaRangeType attribute Message-ID: <51A74623.5080906@redhat.com> Hi, Previously, we deduced the range type from the range objectclass and filled in virtual attribute in post_callback phase. Having a ipaRangeType attributeType in schema, we need to fill the attribute values to ranges created in previous IPA versions. The plugin follows the same approach, setting ipa-local or ipa-ad-trust value to the ipaRangeType attribute according to the objectclass of the range. Part of https://fedorahosted.org/freeipa/ticket/3647 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0062-Add-update-plugin-to-fill-in-ipaRangeType-attribute.patch Type: text/x-patch Size: 6542 bytes Desc: not available URL: From tbabej at redhat.com Thu May 30 12:30:06 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 30 May 2013 14:30:06 +0200 Subject: [Freeipa-devel] [PATCH 0063/0063] Extend idrange commands to support new range origin Message-ID: <51A7464E.30407@redhat.com> Hi, Following values of ipaRangeType attribute are supported and translated accordingly in the idrange commands: 'ipa-local': 'local domain range' 'ipa-ad-winsync': 'Active Directory winsync range' 'ipa-ad-trust': 'Active Directory domain range' 'ipa-ad-trust-posix': 'Active Directory trust range with POSIX attributes' 'ipa-ipa-trust': 'IPA trust range' Part of https://fedorahosted.org/freeipa/ticket/3647 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0063-Extend-idrange-commands-to-support-new-range-origin-.patch Type: text/x-patch Size: 5949 bytes Desc: not available URL: From akrivoka at redhat.com Thu May 30 12:41:37 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 30 May 2013 14:41:37 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Ignore files generated by build Message-ID: <51A74901.6030206@redhat.com> Hello, This patch adds some additional files to .gitignore. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0032-Ignore-files-generated-by-build.patch Type: text/x-patch Size: 997 bytes Desc: not available URL: From tbabej at redhat.com Thu May 30 13:07:16 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 30 May 2013 15:07:16 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Ignore files generated by build In-Reply-To: <51A74901.6030206@redhat.com> References: <51A74901.6030206@redhat.com> Message-ID: <51A74F04.2000500@redhat.com> On 05/30/2013 02:41 PM, Ana Krivokapic wrote: > Hello, > > This patch adds some additional files to .gitignore. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu May 30 14:35:31 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 30 May 2013 16:35:31 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <51A5D78E.8020706@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> <51A318EB.7000902@redhat.com> <20130528123513.GT26689@redhat.com> <51A4B0C9.40005@redhat.com> <20130528134833.GX26689@redhat.com> <51A5D78E.8020706@redhat.com> Message-ID: <51A763B3.8040201@redhat.com> On 05/29/2013 12:25 PM, Martin Kosek wrote: > On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >> On Tue, 28 May 2013, Tomas Babej wrote: >>> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>>> On Mon, 27 May 2013, Tomas Babej wrote: >>>>>>>> We got rid of openldap utilities now. While using python.ldap module, I >>>>>>>> also made the tests much more robust and added a new test case. >>>>>>> In general patches look fine, there is one small nitpick. >>>>>>> I'll run tests on Monday and then will provide final ACK. >>>>>>> >>>>>>>> --- a/tests/test_xmlrpc/test_range_plugin.py >>>>>>>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>>>>>>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and >>>>>>>> XML-RPC in general. >>>>>>>> """ >>>>>>>> >>>>>>>> from ipalib import api, errors, _ >>>>>>>> +from ipapython.ipautil import run >>>>>>> This import is unused, can be removed. >>>>>>> >>>>>> Fixed, thanks for catching that. >>>>>> >>>>>> Updated patch attached. >>>> So I tried to run this test on a machine where there is already trust >>>> established and I think there should be done some changes. >>> I perused the log. Seems that the failures you're experiencing are not >>> relevant to the patch itself, >>> since the newly added tests passed. >>> >>> This is problem with test_range_plugin.py tests that has been there for quite >>> a while, the parameters >>> of the ranges such as size, and base ID/RID/secondary RID are hardcoded in >>> the test case. >> Yep. >> >> >>>> Probably it would be wise to add pre-start procedure to pull existing >>>> ranges and define constants for the ranges so that they don't overlap >>>> with existing ones. Perhaps selecting something from a top of the range >>>> space... >>>> >>>> Attached is the log >>> I agree. This has not been relevant until now, since we did not do much >>> testing on IPA instances >>> with trusts set up, and even then there's random factor in having the overlap >>> with the already created >>> trust range. >>> >>> I'd propose fixing this in a separate effort as a part of continouous >>> integration improvements. I see it >>> as a separate issue of its own. >>> >>> What do you think? >> Please file a separate ticket then. >> >> ACK for this one. >> > May-be-NACK. > > Would it make sense to replace the error with DependentEntry error? We use in > cases like this elsewhere and I think it makes more sense in this case too. > > Martin Sure, I changed the error class in idrange.py and tests accordingly. I ran the unit tests again to verify the changes. Here is the updated patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0057-6-Do-not-allow-removal-of-ID-range-of-an-active-trust.patch Type: text/x-patch Size: 8697 bytes Desc: not available URL: From dpal at redhat.com Thu May 30 23:43:37 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 30 May 2013 19:43:37 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130530114020.GP26689@redhat.com> References: <20130528115059.GS26689@redhat.com> <51A50558.50704@redhat.com> <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> Message-ID: <51A7E429.7090704@redhat.com> [...] >>> >>> For Lunix and older SSSD version we in fact have a problem. >>> What I want to avoid is to have to define procedures and patches for >>> all >> ^^^^^^ ? >>> the clients. However if you use ipa-client-install it would configure >>> sssd the old way. >>> How to make it configured the new way? Manually? This is error prone >>> and >>> people will be reluctant to reconfigure SSSD. Automatically? Means >>> patches to all the versions of the clients. >>> How we are going to deal with the huge test matrix? >> >> I think rolling out patches to old sssd versions is not a good idea and >> I think we won't have the time to prepare all the needed patches in a >> reasonable time-frame. >> >> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) >> I would suggest to add a new domain section for the AD user with LDAP >> and Kerberos provider. This would allow IPA users to works as before and >> add the AD users to the client. Maybe this would also be a better >> solution for the other SSSD versions instead of multiple search bases, >> at least it's a solution for all versions. >> >> Since we have the python config API for SSSD the needed changes to the >> sssd.conf might be scriptable with a reasonable effort. Maybe this can >> be added to ipa-client-install with a new option like >> --enable-legacy-trust-support which can add the news section to existing >> configuration or include it for new installations? > Bigger question is what is simpler: write configuration instructions or > modify/provide additional script for old SSSD? > > Remeber that trusts with AD are most likely established when IPA clients > are already rolled out. Changing ipa-client-install is not helpful for > this case since the clients are already there. > > Perhaps a better approach would be documentation for non-SSSD case and a > simple snippet that can be run alone or in use with puppet/etc to deploy > massively. The snippet would use SSSDConfig Python API to add needed > modifications to the clients' SSSD configuration. > > We can even extend IPA server tools to allow generating such snippets > based on the trusts configuration. After all, we do have control over > IPA server in such cases. > > > I have updated wiki page with discussed ideas. Sorry but this is not enough. I do not see a discussion the design about the client side solutuon procedure. I am looking for a session that would contain a table (or like): -------------------------------------------------------------------------- | Type/Version of the client | Action | -------------------------------------------------------------------------- | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | | | a domain following following steps ...| -------------------------------------------------------------------------- | Clients that have SSSD | If the client is already installed | | before 1.9 | and configured do X | | | If it is a fresh install of the | | | client do Y | -------------------------------------------------------------------------- | SSSD 1.9 and later | Use the following ipa-client-install | | | flags XYZ and/or authconfig command | | | ABC | -------------------------------------------------------------------------- Can something like this be added to wiki and corresponding tickets to provide a testable replacements for XYZ above be filed in trac? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Fri May 31 07:54:53 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 31 May 2013 10:54:53 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <51A7E429.7090704@redhat.com> References: <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> <51A7E429.7090704@redhat.com> Message-ID: <20130531075453.GS26689@redhat.com> On Thu, 30 May 2013, Dmitri Pal wrote: >[...] >>>> >>>> For Lunix and older SSSD version we in fact have a problem. >>>> What I want to avoid is to have to define procedures and patches for >>>> all >>> ^^^^^^ ? >>>> the clients. However if you use ipa-client-install it would configure >>>> sssd the old way. >>>> How to make it configured the new way? Manually? This is error prone >>>> and >>>> people will be reluctant to reconfigure SSSD. Automatically? Means >>>> patches to all the versions of the clients. >>>> How we are going to deal with the huge test matrix? >>> >>> I think rolling out patches to old sssd versions is not a good idea and >>> I think we won't have the time to prepare all the needed patches in a >>> reasonable time-frame. >>> >>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) >>> I would suggest to add a new domain section for the AD user with LDAP >>> and Kerberos provider. This would allow IPA users to works as before and >>> add the AD users to the client. Maybe this would also be a better >>> solution for the other SSSD versions instead of multiple search bases, >>> at least it's a solution for all versions. >>> >>> Since we have the python config API for SSSD the needed changes to the >>> sssd.conf might be scriptable with a reasonable effort. Maybe this can >>> be added to ipa-client-install with a new option like >>> --enable-legacy-trust-support which can add the news section to existing >>> configuration or include it for new installations? >> Bigger question is what is simpler: write configuration instructions or >> modify/provide additional script for old SSSD? >> >> Remeber that trusts with AD are most likely established when IPA clients >> are already rolled out. Changing ipa-client-install is not helpful for >> this case since the clients are already there. >> >> Perhaps a better approach would be documentation for non-SSSD case and a >> simple snippet that can be run alone or in use with puppet/etc to deploy >> massively. The snippet would use SSSDConfig Python API to add needed >> modifications to the clients' SSSD configuration. >> >> We can even extend IPA server tools to allow generating such snippets >> based on the trusts configuration. After all, we do have control over >> IPA server in such cases. >> >> >> I have updated wiki page with discussed ideas. > >Sorry but this is not enough. >I do not see a discussion the design about the client side solutuon >procedure. > >I am looking for a session that would contain a table (or like): > >-------------------------------------------------------------------------- >| Type/Version of the client | Action | >-------------------------------------------------------------------------- >| Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | >| | a domain following following steps ...| >-------------------------------------------------------------------------- >| Clients that have SSSD | If the client is already installed | >| before 1.9 | and configured do X | >| | If it is a fresh install of the | >| | client do Y | >-------------------------------------------------------------------------- >| SSSD 1.9 and later | Use the following ipa-client-install | >| | flags XYZ and/or authconfig command | >| | ABC | >-------------------------------------------------------------------------- > >Can something like this be added to wiki and corresponding tickets to provide a testable >replacements for XYZ above be filed in trac? I've added more, including three tickets to cover specific configurations. Unfortunately, we have limits in multiple search bases approach by the commercial UNIX vendors since their LDAP modules do not support multiple search bases. For all of those platforms there is PADL pam_ldap available which can be used for the same purpose. If we still want to support native pam_ldap on Solaris (which don't work with multiple search bases), we'd have to merge LDAP trees. #3670 [RFE] tool to create configurations for old legacy clients for trusts https://fedorahosted.org/freeipa/ticket/3670 #3671 add support for SSSD 1.5-1.8 configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3671 #3672 add support for PADL pam_ldap/nss_ldap configurations to ipa-advise-client https://fedorahosted.org/freeipa/ticket/3672 ipa-advise-client tool would look up existing IPA server configuration and decide how should look sample configuration for the specified case. It will generate a script that will output needed configuration files (or their snippets) or commands that should be executed on the client side. The reason for this indirection is to allow greater flexibility in future, like being able to check PAM configuration at the client side before recommending changes (or run authconfig). -- / Alexander Bokovoy From pviktori at redhat.com Fri May 31 08:27:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 31 May 2013 10:27:51 +0200 Subject: [Freeipa-devel] [PATCH] 0222 Remove code to install Dogtag 9 In-Reply-To: <51A347CD.7050704@redhat.com> References: <518D0A19.5040800@redhat.com> <51A347CD.7050704@redhat.com> Message-ID: <51A85F07.7030201@redhat.com> On 05/27/2013 01:47 PM, Ana Krivokapic wrote: > On 05/10/2013 04:54 PM, Petr Viktorin wrote: >> Re-sending this patch as it should go into Work towards next release. >> >> >> Since we depend on Dogtag 10 now, there is no need to keep code >> that installs a Dogtag 9 CA. >> >> Support for upgraded Dogtag-9-style instances is left in. >> >> https://fedorahosted.org/freeipa/ticket/3529 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Works well, ACK. Pushed to master -- Petr? From pviktori at redhat.com Fri May 31 08:53:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 31 May 2013 10:53:07 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Ignore files generated by build In-Reply-To: <51A74F04.2000500@redhat.com> References: <51A74901.6030206@redhat.com> <51A74F04.2000500@redhat.com> Message-ID: <51A864F3.6080902@redhat.com> On 05/30/2013 03:07 PM, Tomas Babej wrote: > On 05/30/2013 02:41 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch adds some additional files to .gitignore. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > > Tomas > Pushed to master: 64738ba94ed83397a66d577482039778b261536d -- Petr? From mkosek at redhat.com Fri May 31 08:56:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 31 May 2013 10:56:50 +0200 Subject: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust In-Reply-To: <51A763B3.8040201@redhat.com> References: <51939076.7060909@redhat.com> <5194A405.50804@redhat.com> <519A285F.7080006@redhat.com> <20130520142940.GR26689@redhat.com> <519F6A7E.306@redhat.com> <20130526185628.GJ26689@redhat.com> <51A3134B.2060502@redhat.com> <51A318EB.7000902@redhat.com> <20130528123513.GT26689@redhat.com> <51A4B0C9.40005@redhat.com> <20130528134833.GX26689@redhat.com> <51A5D78E.8020706@redhat.com> <51A763B3.8040201@redhat.com> Message-ID: <51A865D2.8020605@redhat.com> On 05/30/2013 04:35 PM, Tomas Babej wrote: > On 05/29/2013 12:25 PM, Martin Kosek wrote: >> On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >>> On Tue, 28 May 2013, Tomas Babej wrote: >>>> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>>>> On Mon, 27 May 2013, Tomas Babej wrote: >>>>>>>>> We got rid of openldap utilities now. While using python.ldap module, I >>>>>>>>> also made the tests much more robust and added a new test case. >>>>>>>> In general patches look fine, there is one small nitpick. >>>>>>>> I'll run tests on Monday and then will provide final ACK. >>>>>>>> >>>>>>>>> --- a/tests/test_xmlrpc/test_range_plugin.py >>>>>>>>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>>>>>>>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and >>>>>>>>> XML-RPC in general. >>>>>>>>> """ >>>>>>>>> >>>>>>>>> from ipalib import api, errors, _ >>>>>>>>> +from ipapython.ipautil import run >>>>>>>> This import is unused, can be removed. >>>>>>>> >>>>>>> Fixed, thanks for catching that. >>>>>>> >>>>>>> Updated patch attached. >>>>> So I tried to run this test on a machine where there is already trust >>>>> established and I think there should be done some changes. >>>> I perused the log. Seems that the failures you're experiencing are not >>>> relevant to the patch itself, >>>> since the newly added tests passed. >>>> >>>> This is problem with test_range_plugin.py tests that has been there for quite >>>> a while, the parameters >>>> of the ranges such as size, and base ID/RID/secondary RID are hardcoded in >>>> the test case. >>> Yep. >>> >>> >>>>> Probably it would be wise to add pre-start procedure to pull existing >>>>> ranges and define constants for the ranges so that they don't overlap >>>>> with existing ones. Perhaps selecting something from a top of the range >>>>> space... >>>>> >>>>> Attached is the log >>>> I agree. This has not been relevant until now, since we did not do much >>>> testing on IPA instances >>>> with trusts set up, and even then there's random factor in having the overlap >>>> with the already created >>>> trust range. >>>> >>>> I'd propose fixing this in a separate effort as a part of continouous >>>> integration improvements. I see it >>>> as a separate issue of its own. >>>> >>>> What do you think? >>> Please file a separate ticket then. >>> >>> ACK for this one. >>> >> May-be-NACK. >> >> Would it make sense to replace the error with DependentEntry error? We use in >> cases like this elsewhere and I think it makes more sense in this case too. >> >> Martin > > Sure, I changed the error class in idrange.py and tests accordingly. > > I ran the unit tests again to verify the changes. > > Here is the updated patch. > > Tomas ACK. Pushed to master, ipa-3-2. Martin From akrivoka at redhat.com Fri May 31 10:08:08 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 31 May 2013 12:08:08 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range Message-ID: <51A87688.2070107@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3635. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0033-Fail-when-adding-a-trust-with-a-different-range.patch Type: text/x-patch Size: 4003 bytes Desc: not available URL: From tbabej at redhat.com Fri May 31 10:25:26 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 31 May 2013 12:25:26 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <51A7436F.7060302@redhat.com> References: <518D06B1.1060904@redhat.com> <519109CC.5090300@redhat.com> <51A7436F.7060302@redhat.com> Message-ID: <51A87A96.6080404@redhat.com> On 05/30/2013 02:17 PM, Ana Krivokapic wrote: > On 05/13/2013 05:42 PM, Tomas Babej wrote: >> On 05/10/2013 04:39 PM, Tomas Babej wrote: >>> Hi, >>> >>> this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 >>> >>> See commit messages for details. >>> >>> Tomas >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> I noticed during further development that logic in >> interactive_prompt_callback did not follow the pre_callback logic >> precisely. >> >> Fixed patches attached. >> >> Tomas > Hi, > > Patches work fine. > > I would suggest incorporating a fix for ticket > https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The > issue from ticket #3634 is closely connected to this one, and with the > introduction of prompt_param() functionality, including a fix for it > would require minimal effort. You can look at my patch > (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) > and if you think the approach is right, adjust accordingly and > incorporate it in your patchset. > > Other (minor) comments: > > * The last change in ipalib/plugins/idrange.py seems like you wanted > to fix the fact that the lines weren't properly indented (they weren't > multiples of 4). However, you also need to fix the previous line > (raise ...). > * There are a lot of unused imports in ipalib/frontend.py. Since you > are already touching imports in your patch, could you clean up the > unused imports as well. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I addressed the minor issues. Updated patches are attached. Regarding your patch, I agree. I sent a reply to its thread. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0055-3-Incorporate-interactive-prompts-in-idrange-add.patch Type: text/x-patch Size: 3364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0054-3-Add-prompt_param-method-to-avoid-code-duplication.patch Type: text/x-patch Size: 9384 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0053-3-Remove-redundant-check-for-env.interactive.patch Type: text/x-patch Size: 872 bytes Desc: not available URL: From tbabej at redhat.com Fri May 31 10:25:34 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 31 May 2013 12:25:34 +0200 Subject: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod In-Reply-To: <51A60199.5000009@redhat.com> References: <51A60199.5000009@redhat.com> Message-ID: <51A87A9E.2040404@redhat.com> On 05/29/2013 03:24 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3636 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I edited your patch to use newly introduced prompt_param method as agreed in my patches 53-55 thread. The functional part itself looks good, the tests though, are dependent on the environment. The particular code branch of tests that is being executed depends on the fact whether any trust is estabilished on that particular FreeIPA instance the test suite is being run on. I suggest you create a mock trust LDAP entry as in my patch 57 that has been just pushed to master, and test both cases (whether the interactive prompt behaves correctly both with the trust estabilished and without it). Maybe we should move the setUpClass/tearDownClass logic to tests/util.py to avoid code duplication. Attaching the updated patch (apply on top of tbabej-55-3). Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0030-Require-rid-base-and-secondary-rid-base-options-in-i.patch Type: text/x-patch Size: 5320 bytes Desc: not available URL: From tbabej at redhat.com Fri May 31 10:51:43 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 31 May 2013 12:51:43 +0200 Subject: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod In-Reply-To: <51A87A9E.2040404@redhat.com> References: <51A60199.5000009@redhat.com> <51A87A9E.2040404@redhat.com> Message-ID: <51A880BF.2010108@redhat.com> On 05/31/2013 12:25 PM, Tomas Babej wrote: > On 05/29/2013 03:24 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3636 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I edited your patch to use newly introduced prompt_param method as > agreed in my patches 53-55 thread. > > The functional part itself looks good, the tests though, are dependent > on the environment. The particular > code branch of tests that is being executed depends on the fact > whether any trust is estabilished on that > particular FreeIPA instance the test suite is being run on. > > I suggest you create a mock trust LDAP entry as in my patch 57 that > has been just pushed to master, > and test both cases (whether the interactive prompt behaves correctly > both with the trust estabilished > and without it). > > Maybe we should move the setUpClass/tearDownClass logic to > tests/util.py to avoid code duplication. > > Attaching the updated patch (apply on top of tbabej-55-3). > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Wrong thread, sorry. This applies to patch 30. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri May 31 11:46:49 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 31 May 2013 13:46:49 +0200 Subject: [Freeipa-devel] [PATCHES] 0230-0234 Integtration testing framework Message-ID: <51A88DA9.806@redhat.com> Apply on top of my patches 0227-0234. These patches add an initial integration testing framework. Patch 0230 adds a plugin for ordered test classes. Nose orders methods within a test suite alphabetically, but we generally want to run them in the order defined. This adds the @ordered decorator that causes Nose to do just that, provided the plugin is loaded and enabled, and that the methods are defined in the same file. The ipa-run-tests wrapper is changed to enable the plugin. In the future we may want to use this for unit tests as well. It might also make sense to separate it from the FreeIPA project altogether. Patch 0231 adds configuration for tests. This reads environment variables like: - MASTER (FQDN of initial server) - REPLICA (space-separated FQDNs of replicas) - CLIENT (space-separated FQDNs of clients), - IPATEST_DIR (directory the tests use on the remote machines) etc., and loads them into an easy-to use Python object. A tool called ipa-test-config is provided that generates a full set of environment variables for shell-based tests from these, either global or specific for a given host. If environment variables don't work for us, alternate configuration methods can be added in the future. Patch 0232 adds an integration test framework. This extends Host object available from the configuration with methods to run commands and copy files on the remote host, and adds a base class for integration tests which can currently install and uninstall IPA in a "star" topology. (In the future, the install/uninstall code should also be made available as a shell command.) A simple test for user replication between two masters is provided. Log files from the remote hosts can be marked for collection, but the actual collection is left to a Nose plugin. The base class uses the @ordered decorator mentioned above. Patch 0233 improves on how commands are run on remote hosts. In the previous patch, the process's stdin and stdout were combined as a quick hack to avoid the problem that if we first read stdout and then stderr, then stderr's buffer can fill up and we'd deadlock (and the other way around). With this patch the streams are read in parallel. In the future this can be extended to calling whole commands in parallel (e.g. uninstalling IPA on all the hosts at once). Patch 0234 adds log collection to the BeakerLib integration plugin. This tars up the marked logs, downloads then, and calls rlFileSubmit on them. --- Example procedure to run the integration tests: Prepare two machines. Install IPA on them, enable root to SSH in, configure/disable firewall, apply current workarounds (RPM downgrading, SELinux), etc. (The plan is to provide no setup automation as part of the FreeIPA project, since systems/setups differ too much.) I'll use "vm-116.idm.lab.bos.redhat.com" and "vm-089.idm.lab.bos.redhat.com" here. The rest of the instructions apply to the "local" machine. Install the RPMs. On F19, remove special characters from /etc/fedora-release (BZ#700525). Enter: export MASTER=vm-116.idm.lab.bos.redhat.com export REPLICA=vm-089.idm.lab.bos.redhat.com export IPA_ROOT_SSH_PASSWORD= ... and any extra config you might want ($FORWARDER, $DOMAIN, ..) `ipa-test-config --global` should now print out something like: export IPATEST_DIR='/root/ipatests' export IPv6SETUP='' export IPADEBUG='' export IPA_ROOT_SSH_PASSWORD= export ADMINID='admin' export ADMINPW='Secret123' export ROOTDN='cn=Directory Manager' export ROOTDNPWD='Secret123' export DNSFORWARD='8.8.8.8' export NISDOMAIN='ipatest' export NTPSERVER='2.pool.ntp.org' export DOMAIN_env1='idm.lab.bos.redhat.com' export RELM_env1='IDM.LAB.BOS.REDHAT.COM' export BASEDN_env1='dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' export MASTER_env1='vm-116.idm.lab.bos.redhat.com' export BEAKERMASTER_env1='vm-116.idm.lab.bos.redhat.com' export BEAKERMASTER_IP_env1='10.16.78.116' export MASTER1_env1='vm-116.idm.lab.bos.redhat.com' export BEAKERMASTER1_env1='vm-116.idm.lab.bos.redhat.com' export BEAKERMASTER1_IP_env1='10.16.78.116' export REPLICA_env1='vm-089.idm.lab.bos.redhat.com' export BEAKERREPLICA_env1='vm-089.idm.lab.bos.redhat.com' export BEAKERREPLICA_IP_env1='10.16.78.89' export REPLICA1_env1='vm-089.idm.lab.bos.redhat.com' export BEAKERREPLICA1_env1='vm-089.idm.lab.bos.redhat.com' export BEAKERREPLICA1_IP_env1='10.16.78.89' export CLIENT_env1='' export BEAKERCLIENT_env1='' export BEAKERCLIENT_IP_env1='' export OTHER_env1='' export BEAKEROTHER_env1='' export BEAKEROTHER_IP_env1='' export MASTER='vm-116.idm.lab.bos.redhat.com' export BEAKERMASTER='vm-116.idm.lab.bos.redhat.com' export MASTERIP='10.16.78.116' export SLAVE='vm-089.idm.lab.bos.redhat.com' export REPLICA='vm-089.idm.lab.bos.redhat.com' export BEAKERSLAVE='vm-089.idm.lab.bos.redhat.com' export SLAVEIP='10.16.78.89' Now run: ( . /usr/share/beakerlib/beakerlib.sh rlJournalStart ipa-run-tests test_integration/test_simple_replication.py --with-beakerlib python -c 'print "="*100' rlJournalPrintText --full-journal rlJournalEnd ) The BeakerLib logging interleaved with Nose is a bit messy but better than nothing. Note that the output is buffered so installation/uninstallation may appear hung (use top on the remote host to see real-time activity). Or you can run without BeakerLib: ipa-run-tests test_integration/test_simple_replication.py (Here the most time-consuming operations, setup & teardown, are not shown at all) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0230-Add-a-plugin-for-test-ordering.patch Type: text/x-patch Size: 4190 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0231-Add-a-framework-for-integration-test-configuration.patch Type: text/x-patch Size: 21290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0232-Add-a-framework-for-integration-testing.patch Type: text/x-patch Size: 22703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0233-Introduce-a-class-for-remote-commands.patch Type: text/x-patch Size: 10810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0234-Collect-logs-from-tests.patch Type: text/x-patch Size: 7020 bytes Desc: not available URL: From tbabej at redhat.com Fri May 31 11:56:30 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 31 May 2013 13:56:30 +0200 Subject: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod In-Reply-To: <51A880BF.2010108@redhat.com> References: <51A60199.5000009@redhat.com> <51A87A9E.2040404@redhat.com> <51A880BF.2010108@redhat.com> Message-ID: <51A88FEE.1090203@redhat.com> On 05/31/2013 12:51 PM, Tomas Babej wrote: > On 05/31/2013 12:25 PM, Tomas Babej wrote: >> On 05/29/2013 03:24 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3636 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> I edited your patch to use newly introduced prompt_param method as >> agreed in my patches 53-55 thread. >> >> The functional part itself looks good, the tests though, are >> dependent on the environment. The particular >> code branch of tests that is being executed depends on the fact >> whether any trust is estabilished on that >> particular FreeIPA instance the test suite is being run on. >> >> I suggest you create a mock trust LDAP entry as in my patch 57 that >> has been just pushed to master, >> and test both cases (whether the interactive prompt behaves correctly >> both with the trust estabilished >> and without it). >> >> Maybe we should move the setUpClass/tearDownClass logic to >> tests/util.py to avoid code duplication. >> >> Attaching the updated patch (apply on top of tbabej-55-3). >> >> Tomas >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Wrong thread, sorry. This applies to patch 30. > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > I tested the *patch 31*, both with new and old client, works fine. ACK Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thozza at redhat.com Fri May 31 12:07:27 2013 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 31 May 2013 08:07:27 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0160] Fix crash triggered by missing sasl_user parameter In-Reply-To: <51A5FB33.7000802@redhat.com> References: <51A5FB33.7000802@redhat.com> Message-ID: <1388581366.5830954.1370002047640.JavaMail.root@redhat.com> ACK Works as expected. Regards, Tomas Hozza ----- Original Message ----- > Hello, > > Fix crash triggered by missing sasl_user parameter. > > -- > Petr^2 Spacek > From mkosek at redhat.com Fri May 31 12:21:53 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 31 May 2013 14:21:53 +0200 Subject: [Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod In-Reply-To: <51A88FEE.1090203@redhat.com> References: <51A60199.5000009@redhat.com> <51A87A9E.2040404@redhat.com> <51A880BF.2010108@redhat.com> <51A88FEE.1090203@redhat.com> Message-ID: <51A895E1.3010906@redhat.com> On 05/31/2013 01:56 PM, Tomas Babej wrote: > On 05/31/2013 12:51 PM, Tomas Babej wrote: >> On 05/31/2013 12:25 PM, Tomas Babej wrote: >>> On 05/29/2013 03:24 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3636 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> I edited your patch to use newly introduced prompt_param method as agreed in >>> my patches 53-55 thread. >>> >>> The functional part itself looks good, the tests though, are dependent on >>> the environment. The particular >>> code branch of tests that is being executed depends on the fact whether any >>> trust is estabilished on that >>> particular FreeIPA instance the test suite is being run on. >>> >>> I suggest you create a mock trust LDAP entry as in my patch 57 that has been >>> just pushed to master, >>> and test both cases (whether the interactive prompt behaves correctly both >>> with the trust estabilished >>> and without it). >>> >>> Maybe we should move the setUpClass/tearDownClass logic to tests/util.py to >>> avoid code duplication. >>> >>> Attaching the updated patch (apply on top of tbabej-55-3). >>> >>> Tomas >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Wrong thread, sorry. This applies to patch 30. >> >> Tomas >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > I tested the *patch 31*, both with new and old client, works fine. > > ACK > > Tomas > Pushed to master. Martin From thozza at redhat.com Fri May 31 13:21:49 2013 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 31 May 2013 09:21:49 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0161] Validate authentication settings strictly In-Reply-To: <51A5FE13.9080200@redhat.com> References: <51A5FE13.9080200@redhat.com> Message-ID: <1617278605.5857933.1370006509585.JavaMail.root@redhat.com> ACK. Works OK. Regards, Tomas Hozza ----- Original Message ----- > Hello, > > Validate authentication settings strictly. > > - auth_method 'SASL' do not accept bind_dn and password options > - auth_method 'simple' do not accept sasl_* and krb5_* options > - auth_method 'none' do not accept any of options above > > -- > Petr^2 Spacek > From simo at redhat.com Fri May 31 13:29:22 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 31 May 2013 09:29:22 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130531075453.GS26689@redhat.com> References: <20130528194831.GY26689@redhat.com> <51A51032.4090502@redhat.com> <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> <51A7E429.7090704@redhat.com> <20130531075453.GS26689@redhat.com> Message-ID: <1370006962.2769.196.camel@willson.li.ssimo.org> On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: > On Thu, 30 May 2013, Dmitri Pal wrote: > >[...] > >>>> > >>>> For Lunix and older SSSD version we in fact have a problem. > >>>> What I want to avoid is to have to define procedures and patches for > >>>> all > >>> ^^^^^^ ? > >>>> the clients. However if you use ipa-client-install it would configure > >>>> sssd the old way. > >>>> How to make it configured the new way? Manually? This is error prone > >>>> and > >>>> people will be reluctant to reconfigure SSSD. Automatically? Means > >>>> patches to all the versions of the clients. > >>>> How we are going to deal with the huge test matrix? > >>> > >>> I think rolling out patches to old sssd versions is not a good idea and > >>> I think we won't have the time to prepare all the needed patches in a > >>> reasonable time-frame. > >>> > >>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) > >>> I would suggest to add a new domain section for the AD user with LDAP > >>> and Kerberos provider. This would allow IPA users to works as before and > >>> add the AD users to the client. Maybe this would also be a better > >>> solution for the other SSSD versions instead of multiple search bases, > >>> at least it's a solution for all versions. > >>> > >>> Since we have the python config API for SSSD the needed changes to the > >>> sssd.conf might be scriptable with a reasonable effort. Maybe this can > >>> be added to ipa-client-install with a new option like > >>> --enable-legacy-trust-support which can add the news section to existing > >>> configuration or include it for new installations? > >> Bigger question is what is simpler: write configuration instructions or > >> modify/provide additional script for old SSSD? > >> > >> Remeber that trusts with AD are most likely established when IPA clients > >> are already rolled out. Changing ipa-client-install is not helpful for > >> this case since the clients are already there. > >> > >> Perhaps a better approach would be documentation for non-SSSD case and a > >> simple snippet that can be run alone or in use with puppet/etc to deploy > >> massively. The snippet would use SSSDConfig Python API to add needed > >> modifications to the clients' SSSD configuration. > >> > >> We can even extend IPA server tools to allow generating such snippets > >> based on the trusts configuration. After all, we do have control over > >> IPA server in such cases. > >> > >> > >> I have updated wiki page with discussed ideas. > > > >Sorry but this is not enough. > >I do not see a discussion the design about the client side solutuon > >procedure. > > > >I am looking for a session that would contain a table (or like): > > > >-------------------------------------------------------------------------- > >| Type/Version of the client | Action | > >-------------------------------------------------------------------------- > >| Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | > >| | a domain following following steps ...| > >-------------------------------------------------------------------------- > >| Clients that have SSSD | If the client is already installed | > >| before 1.9 | and configured do X | > >| | If it is a fresh install of the | > >| | client do Y | > >-------------------------------------------------------------------------- > >| SSSD 1.9 and later | Use the following ipa-client-install | > >| | flags XYZ and/or authconfig command | > >| | ABC | > >-------------------------------------------------------------------------- > > > >Can something like this be added to wiki and corresponding tickets to provide a testable > >replacements for XYZ above be filed in trac? > I've added more, including three tickets to cover specific > configurations. > > Unfortunately, we have limits in multiple search bases approach by > the commercial UNIX vendors since their LDAP modules do not support > multiple search bases. For all of those platforms there is PADL pam_ldap > available which can be used for the same purpose. > > If we still want to support native pam_ldap on Solaris (which don't work > with multiple search bases), we'd have to merge LDAP trees. Alexander, in my initial proposal I said that trusted users should be put in the same tree as compat users, it was exactly to address this problem. We do not need to cause more problems by using multiple search trees IMO. Simo. > #3670 [RFE] tool to create configurations for old legacy clients for trusts > https://fedorahosted.org/freeipa/ticket/3670 > > #3671 add support for SSSD 1.5-1.8 configurations to ipa-advise-client > https://fedorahosted.org/freeipa/ticket/3671 > > #3672 add support for PADL pam_ldap/nss_ldap configurations to ipa-advise-client > https://fedorahosted.org/freeipa/ticket/3672 > > ipa-advise-client tool would look up existing IPA server configuration > and decide how should look sample configuration for the specified case. > It will generate a script that will output needed configuration files > (or their snippets) or commands that should be executed on the client > side. > > The reason for this indirection is to allow greater flexibility in > future, like being able to check PAM configuration at the client side > before recommending changes (or run authconfig). > > -- Simo Sorce * Red Hat, Inc * New York From akrivoka at redhat.com Fri May 31 13:35:37 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 31 May 2013 15:35:37 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <51A87A96.6080404@redhat.com> References: <518D06B1.1060904@redhat.com> <519109CC.5090300@redhat.com> <51A7436F.7060302@redhat.com> <51A87A96.6080404@redhat.com> Message-ID: <51A8A729.9030108@redhat.com> On 05/31/2013 12:25 PM, Tomas Babej wrote: > On 05/30/2013 02:17 PM, Ana Krivokapic wrote: >> On 05/13/2013 05:42 PM, Tomas Babej wrote: >>> On 05/10/2013 04:39 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 >>>> >>>> See commit messages for details. >>>> >>>> Tomas >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> I noticed during further development that logic in >>> interactive_prompt_callback did not follow the pre_callback logic precisely. >>> >>> Fixed patches attached. >>> >>> Tomas >> Hi, >> >> Patches work fine. >> >> I would suggest incorporating a fix for ticket >> https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The issue >> from ticket #3634 is closely connected to this one, and with the introduction >> of prompt_param() functionality, including a fix for it would require minimal >> effort. You can look at my patch >> (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) and if >> you think the approach is right, adjust accordingly and incorporate it in >> your patchset. >> >> Other (minor) comments: >> >> * The last change in ipalib/plugins/idrange.py seems like you wanted to fix >> the fact that the lines weren't properly indented (they weren't multiples of >> 4). However, you also need to fix the previous line (raise ...). >> * There are a lot of unused imports in ipalib/frontend.py. Since you are >> already touching imports in your patch, could you clean up the unused imports >> as well. >> >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I addressed the minor issues. Updated patches are attached. > > Regarding your patch, I agree. I sent a reply to its thread. > > Tomas ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri May 31 13:35:09 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 31 May 2013 16:35:09 +0300 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <1370006962.2769.196.camel@willson.li.ssimo.org> References: <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> <51A7E429.7090704@redhat.com> <20130531075453.GS26689@redhat.com> <1370006962.2769.196.camel@willson.li.ssimo.org> Message-ID: <20130531133508.GT26689@redhat.com> On Fri, 31 May 2013, Simo Sorce wrote: >On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: >> On Thu, 30 May 2013, Dmitri Pal wrote: >> >[...] >> >>>> >> >>>> For Lunix and older SSSD version we in fact have a problem. >> >>>> What I want to avoid is to have to define procedures and patches for >> >>>> all >> >>> ^^^^^^ ? >> >>>> the clients. However if you use ipa-client-install it would configure >> >>>> sssd the old way. >> >>>> How to make it configured the new way? Manually? This is error prone >> >>>> and >> >>>> people will be reluctant to reconfigure SSSD. Automatically? Means >> >>>> patches to all the versions of the clients. >> >>>> How we are going to deal with the huge test matrix? >> >>> >> >>> I think rolling out patches to old sssd versions is not a good idea and >> >>> I think we won't have the time to prepare all the needed patches in a >> >>> reasonable time-frame. >> >>> >> >>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) >> >>> I would suggest to add a new domain section for the AD user with LDAP >> >>> and Kerberos provider. This would allow IPA users to works as before and >> >>> add the AD users to the client. Maybe this would also be a better >> >>> solution for the other SSSD versions instead of multiple search bases, >> >>> at least it's a solution for all versions. >> >>> >> >>> Since we have the python config API for SSSD the needed changes to the >> >>> sssd.conf might be scriptable with a reasonable effort. Maybe this can >> >>> be added to ipa-client-install with a new option like >> >>> --enable-legacy-trust-support which can add the news section to existing >> >>> configuration or include it for new installations? >> >> Bigger question is what is simpler: write configuration instructions or >> >> modify/provide additional script for old SSSD? >> >> >> >> Remeber that trusts with AD are most likely established when IPA clients >> >> are already rolled out. Changing ipa-client-install is not helpful for >> >> this case since the clients are already there. >> >> >> >> Perhaps a better approach would be documentation for non-SSSD case and a >> >> simple snippet that can be run alone or in use with puppet/etc to deploy >> >> massively. The snippet would use SSSDConfig Python API to add needed >> >> modifications to the clients' SSSD configuration. >> >> >> >> We can even extend IPA server tools to allow generating such snippets >> >> based on the trusts configuration. After all, we do have control over >> >> IPA server in such cases. >> >> >> >> >> >> I have updated wiki page with discussed ideas. >> > >> >Sorry but this is not enough. >> >I do not see a discussion the design about the client side solutuon >> >procedure. >> > >> >I am looking for a session that would contain a table (or like): >> > >> >-------------------------------------------------------------------------- >> >| Type/Version of the client | Action | >> >-------------------------------------------------------------------------- >> >| Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | >> >| | a domain following following steps ...| >> >-------------------------------------------------------------------------- >> >| Clients that have SSSD | If the client is already installed | >> >| before 1.9 | and configured do X | >> >| | If it is a fresh install of the | >> >| | client do Y | >> >-------------------------------------------------------------------------- >> >| SSSD 1.9 and later | Use the following ipa-client-install | >> >| | flags XYZ and/or authconfig command | >> >| | ABC | >> >-------------------------------------------------------------------------- >> > >> >Can something like this be added to wiki and corresponding tickets to provide a testable >> >replacements for XYZ above be filed in trac? >> I've added more, including three tickets to cover specific >> configurations. >> >> Unfortunately, we have limits in multiple search bases approach by >> the commercial UNIX vendors since their LDAP modules do not support >> multiple search bases. For all of those platforms there is PADL pam_ldap >> available which can be used for the same purpose. >> >> If we still want to support native pam_ldap on Solaris (which don't work >> with multiple search bases), we'd have to merge LDAP trees. > >Alexander, in my initial proposal I said that trusted users should be >put in the same tree as compat users, it was exactly to address this >problem. > >We do not need to cause more problems by using multiple search trees >IMO. Ok, since I wanted to re-use slapi-nis anyway, this only means adding one more config attribute to slapi-nis configuration that will ask it to look into NSS in addition to the main query. In which order these queries should be performed? first to LDAP then NSS or first to NSS then to LDAP? I guess the answer depends on specific setup -- if all your users in AD, you'd like to look at them first. -- / Alexander Bokovoy From thozza at redhat.com Fri May 31 14:01:27 2013 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 31 May 2013 10:01:27 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0159] Deprecate configuration without persistent search In-Reply-To: <51A61BB6.4080406@redhat.com> References: <51A4B764.7040301@redhat.com> <51A61BB6.4080406@redhat.com> Message-ID: <1638001085.5875003.1370008887189.JavaMail.root@redhat.com> ACK. Looks good. Regards, Tomas Hozza ----- Original Message ----- > On 28.5.2013 15:55, Petr Spacek wrote: > > Hello, > > > > Deprecate configuration without persistent search. > > > > https://fedorahosted.org/bind-dyndb-ldap/ticket/120 > > This version of the patch adds notice to the README. > > -- > Petr^2 Spacek > From simo at redhat.com Fri May 31 14:17:54 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 31 May 2013 10:17:54 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <20130531133508.GT26689@redhat.com> References: <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> <51A7E429.7090704@redhat.com> <20130531075453.GS26689@redhat.com> <1370006962.2769.196.camel@willson.li.ssimo.org> <20130531133508.GT26689@redhat.com> Message-ID: <1370009874.2769.199.camel@willson.li.ssimo.org> On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: > On Fri, 31 May 2013, Simo Sorce wrote: > >On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: > >> On Thu, 30 May 2013, Dmitri Pal wrote: > >> >[...] > >> >>>> > >> >>>> For Lunix and older SSSD version we in fact have a problem. > >> >>>> What I want to avoid is to have to define procedures and patches for > >> >>>> all > >> >>> ^^^^^^ ? > >> >>>> the clients. However if you use ipa-client-install it would configure > >> >>>> sssd the old way. > >> >>>> How to make it configured the new way? Manually? This is error prone > >> >>>> and > >> >>>> people will be reluctant to reconfigure SSSD. Automatically? Means > >> >>>> patches to all the versions of the clients. > >> >>>> How we are going to deal with the huge test matrix? > >> >>> > >> >>> I think rolling out patches to old sssd versions is not a good idea and > >> >>> I think we won't have the time to prepare all the needed patches in a > >> >>> reasonable time-frame. > >> >>> > >> >>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) > >> >>> I would suggest to add a new domain section for the AD user with LDAP > >> >>> and Kerberos provider. This would allow IPA users to works as before and > >> >>> add the AD users to the client. Maybe this would also be a better > >> >>> solution for the other SSSD versions instead of multiple search bases, > >> >>> at least it's a solution for all versions. > >> >>> > >> >>> Since we have the python config API for SSSD the needed changes to the > >> >>> sssd.conf might be scriptable with a reasonable effort. Maybe this can > >> >>> be added to ipa-client-install with a new option like > >> >>> --enable-legacy-trust-support which can add the news section to existing > >> >>> configuration or include it for new installations? > >> >> Bigger question is what is simpler: write configuration instructions or > >> >> modify/provide additional script for old SSSD? > >> >> > >> >> Remeber that trusts with AD are most likely established when IPA clients > >> >> are already rolled out. Changing ipa-client-install is not helpful for > >> >> this case since the clients are already there. > >> >> > >> >> Perhaps a better approach would be documentation for non-SSSD case and a > >> >> simple snippet that can be run alone or in use with puppet/etc to deploy > >> >> massively. The snippet would use SSSDConfig Python API to add needed > >> >> modifications to the clients' SSSD configuration. > >> >> > >> >> We can even extend IPA server tools to allow generating such snippets > >> >> based on the trusts configuration. After all, we do have control over > >> >> IPA server in such cases. > >> >> > >> >> > >> >> I have updated wiki page with discussed ideas. > >> > > >> >Sorry but this is not enough. > >> >I do not see a discussion the design about the client side solutuon > >> >procedure. > >> > > >> >I am looking for a session that would contain a table (or like): > >> > > >> >-------------------------------------------------------------------------- > >> >| Type/Version of the client | Action | > >> >-------------------------------------------------------------------------- > >> >| Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | > >> >| | a domain following following steps ...| > >> >-------------------------------------------------------------------------- > >> >| Clients that have SSSD | If the client is already installed | > >> >| before 1.9 | and configured do X | > >> >| | If it is a fresh install of the | > >> >| | client do Y | > >> >-------------------------------------------------------------------------- > >> >| SSSD 1.9 and later | Use the following ipa-client-install | > >> >| | flags XYZ and/or authconfig command | > >> >| | ABC | > >> >-------------------------------------------------------------------------- > >> > > >> >Can something like this be added to wiki and corresponding tickets to provide a testable > >> >replacements for XYZ above be filed in trac? > >> I've added more, including three tickets to cover specific > >> configurations. > >> > >> Unfortunately, we have limits in multiple search bases approach by > >> the commercial UNIX vendors since their LDAP modules do not support > >> multiple search bases. For all of those platforms there is PADL pam_ldap > >> available which can be used for the same purpose. > >> > >> If we still want to support native pam_ldap on Solaris (which don't work > >> with multiple search bases), we'd have to merge LDAP trees. > > > >Alexander, in my initial proposal I said that trusted users should be > >put in the same tree as compat users, it was exactly to address this > >problem. > > > >We do not need to cause more problems by using multiple search trees > >IMO. > Ok, since I wanted to re-use slapi-nis anyway, this only means adding > one more config attribute to slapi-nis configuration that will ask it to > look into NSS in addition to the main query. > > In which order these queries should be performed? first to LDAP then NSS > or first to NSS then to LDAP? I guess the answer depends on specific > setup -- if all your users in AD, you'd like to look at them first. If we cache stuff in memory I am not sure it matters much. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri May 31 14:35:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 31 May 2013 10:35:16 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <1370009874.2769.199.camel@willson.li.ssimo.org> References: <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> <51A7E429.7090704@redhat.com> <20130531075453.GS26689@redhat.com> <1370006962.2769.196.camel@willson.li.ssimo.org> <20130531133508.GT26689@redhat.com> <1370009874.2769.199.camel@willson.li.ssimo.org> Message-ID: <51A8B524.5070303@redhat.com> Simo Sorce wrote: > On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: >> On Fri, 31 May 2013, Simo Sorce wrote: >>> On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: >>>> On Thu, 30 May 2013, Dmitri Pal wrote: >>>>> [...] >>>>>>>> >>>>>>>> For Lunix and older SSSD version we in fact have a problem. >>>>>>>> What I want to avoid is to have to define procedures and patches for >>>>>>>> all >>>>>>> ^^^^^^ ? >>>>>>>> the clients. However if you use ipa-client-install it would configure >>>>>>>> sssd the old way. >>>>>>>> How to make it configured the new way? Manually? This is error prone >>>>>>>> and >>>>>>>> people will be reluctant to reconfigure SSSD. Automatically? Means >>>>>>>> patches to all the versions of the clients. >>>>>>>> How we are going to deal with the huge test matrix? >>>>>>> >>>>>>> I think rolling out patches to old sssd versions is not a good idea and >>>>>>> I think we won't have the time to prepare all the needed patches in a >>>>>>> reasonable time-frame. >>>>>>> >>>>>>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) >>>>>>> I would suggest to add a new domain section for the AD user with LDAP >>>>>>> and Kerberos provider. This would allow IPA users to works as before and >>>>>>> add the AD users to the client. Maybe this would also be a better >>>>>>> solution for the other SSSD versions instead of multiple search bases, >>>>>>> at least it's a solution for all versions. >>>>>>> >>>>>>> Since we have the python config API for SSSD the needed changes to the >>>>>>> sssd.conf might be scriptable with a reasonable effort. Maybe this can >>>>>>> be added to ipa-client-install with a new option like >>>>>>> --enable-legacy-trust-support which can add the news section to existing >>>>>>> configuration or include it for new installations? >>>>>> Bigger question is what is simpler: write configuration instructions or >>>>>> modify/provide additional script for old SSSD? >>>>>> >>>>>> Remeber that trusts with AD are most likely established when IPA clients >>>>>> are already rolled out. Changing ipa-client-install is not helpful for >>>>>> this case since the clients are already there. >>>>>> >>>>>> Perhaps a better approach would be documentation for non-SSSD case and a >>>>>> simple snippet that can be run alone or in use with puppet/etc to deploy >>>>>> massively. The snippet would use SSSDConfig Python API to add needed >>>>>> modifications to the clients' SSSD configuration. >>>>>> >>>>>> We can even extend IPA server tools to allow generating such snippets >>>>>> based on the trusts configuration. After all, we do have control over >>>>>> IPA server in such cases. >>>>>> >>>>>> >>>>>> I have updated wiki page with discussed ideas. >>>>> >>>>> Sorry but this is not enough. >>>>> I do not see a discussion the design about the client side solutuon >>>>> procedure. >>>>> >>>>> I am looking for a session that would contain a table (or like): >>>>> >>>>> -------------------------------------------------------------------------- >>>>> | Type/Version of the client | Action | >>>>> -------------------------------------------------------------------------- >>>>> | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | >>>>> | | a domain following following steps ...| >>>>> -------------------------------------------------------------------------- >>>>> | Clients that have SSSD | If the client is already installed | >>>>> | before 1.9 | and configured do X | >>>>> | | If it is a fresh install of the | >>>>> | | client do Y | >>>>> -------------------------------------------------------------------------- >>>>> | SSSD 1.9 and later | Use the following ipa-client-install | >>>>> | | flags XYZ and/or authconfig command | >>>>> | | ABC | >>>>> -------------------------------------------------------------------------- >>>>> >>>>> Can something like this be added to wiki and corresponding tickets to provide a testable >>>>> replacements for XYZ above be filed in trac? >>>> I've added more, including three tickets to cover specific >>>> configurations. >>>> >>>> Unfortunately, we have limits in multiple search bases approach by >>>> the commercial UNIX vendors since their LDAP modules do not support >>>> multiple search bases. For all of those platforms there is PADL pam_ldap >>>> available which can be used for the same purpose. >>>> >>>> If we still want to support native pam_ldap on Solaris (which don't work >>>> with multiple search bases), we'd have to merge LDAP trees. >>> >>> Alexander, in my initial proposal I said that trusted users should be >>> put in the same tree as compat users, it was exactly to address this >>> problem. >>> >>> We do not need to cause more problems by using multiple search trees >>> IMO. >> Ok, since I wanted to re-use slapi-nis anyway, this only means adding >> one more config attribute to slapi-nis configuration that will ask it to >> look into NSS in addition to the main query. >> >> In which order these queries should be performed? first to LDAP then NSS >> or first to NSS then to LDAP? I guess the answer depends on specific >> setup -- if all your users in AD, you'd like to look at them first. > > If we cache stuff in memory I am not sure it matters much. Note that AFAIK there is no option in slapi-nis to look at nss. It is probably safe to assume that the sssd loop protection will suffice. This may be quite a change too, as slapi-nis won't be able to rely on watching for MOD to update itself and instead will need to be a general-purpose cache, or ALWAYS look up the entry (or entries) in nss and rely on the local sssd cache to prevent performance issues. rob From simo at redhat.com Fri May 31 15:42:12 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 31 May 2013 11:42:12 -0400 Subject: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts In-Reply-To: <51A8B524.5070303@redhat.com> References: <20130528202900.GZ26689@redhat.com> <51A53FA0.6060305@redhat.com> <20130529053837.GA26689@redhat.com> <20130529072848.GA28888@localhost.localdomain> <51A6084A.7050500@redhat.com> <20130530090102.GC1945@localhost.localdomain> <20130530114020.GP26689@redhat.com> <51A7E429.7090704@redhat.com> <20130531075453.GS26689@redhat.com> <1370006962.2769.196.camel@willson.li.ssimo.org> <20130531133508.GT26689@redhat.com> <1370009874.2769.199.camel@willson.li.ssimo.org> <51A8B524.5070303@redhat.com> Message-ID: <1370014932.2769.200.camel@willson.li.ssimo.org> On Fri, 2013-05-31 at 10:35 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 2013-05-31 at 16:35 +0300, Alexander Bokovoy wrote: > >> On Fri, 31 May 2013, Simo Sorce wrote: > >>> On Fri, 2013-05-31 at 10:54 +0300, Alexander Bokovoy wrote: > >>>> On Thu, 30 May 2013, Dmitri Pal wrote: > >>>>> [...] > >>>>>>>> > >>>>>>>> For Lunix and older SSSD version we in fact have a problem. > >>>>>>>> What I want to avoid is to have to define procedures and patches for > >>>>>>>> all > >>>>>>> ^^^^^^ ? > >>>>>>>> the clients. However if you use ipa-client-install it would configure > >>>>>>>> sssd the old way. > >>>>>>>> How to make it configured the new way? Manually? This is error prone > >>>>>>>> and > >>>>>>>> people will be reluctant to reconfigure SSSD. Automatically? Means > >>>>>>>> patches to all the versions of the clients. > >>>>>>>> How we are going to deal with the huge test matrix? > >>>>>>> > >>>>>>> I think rolling out patches to old sssd versions is not a good idea and > >>>>>>> I think we won't have the time to prepare all the needed patches in a > >>>>>>> reasonable time-frame. > >>>>>>> > >>>>>>> For SSSD versions which do not allow multiple search bases (1.5 and 1.6) > >>>>>>> I would suggest to add a new domain section for the AD user with LDAP > >>>>>>> and Kerberos provider. This would allow IPA users to works as before and > >>>>>>> add the AD users to the client. Maybe this would also be a better > >>>>>>> solution for the other SSSD versions instead of multiple search bases, > >>>>>>> at least it's a solution for all versions. > >>>>>>> > >>>>>>> Since we have the python config API for SSSD the needed changes to the > >>>>>>> sssd.conf might be scriptable with a reasonable effort. Maybe this can > >>>>>>> be added to ipa-client-install with a new option like > >>>>>>> --enable-legacy-trust-support which can add the news section to existing > >>>>>>> configuration or include it for new installations? > >>>>>> Bigger question is what is simpler: write configuration instructions or > >>>>>> modify/provide additional script for old SSSD? > >>>>>> > >>>>>> Remeber that trusts with AD are most likely established when IPA clients > >>>>>> are already rolled out. Changing ipa-client-install is not helpful for > >>>>>> this case since the clients are already there. > >>>>>> > >>>>>> Perhaps a better approach would be documentation for non-SSSD case and a > >>>>>> simple snippet that can be run alone or in use with puppet/etc to deploy > >>>>>> massively. The snippet would use SSSDConfig Python API to add needed > >>>>>> modifications to the clients' SSSD configuration. > >>>>>> > >>>>>> We can even extend IPA server tools to allow generating such snippets > >>>>>> based on the trusts configuration. After all, we do have control over > >>>>>> IPA server in such cases. > >>>>>> > >>>>>> > >>>>>> I have updated wiki page with discussed ideas. > >>>>> > >>>>> Sorry but this is not enough. > >>>>> I do not see a discussion the design about the client side solutuon > >>>>> procedure. > >>>>> > >>>>> I am looking for a session that would contain a table (or like): > >>>>> > >>>>> -------------------------------------------------------------------------- > >>>>> | Type/Version of the client | Action | > >>>>> -------------------------------------------------------------------------- > >>>>> | Solaris/HP-UX/AIX (non sssd) | Configure manually to recognize AD as | > >>>>> | | a domain following following steps ...| > >>>>> -------------------------------------------------------------------------- > >>>>> | Clients that have SSSD | If the client is already installed | > >>>>> | before 1.9 | and configured do X | > >>>>> | | If it is a fresh install of the | > >>>>> | | client do Y | > >>>>> -------------------------------------------------------------------------- > >>>>> | SSSD 1.9 and later | Use the following ipa-client-install | > >>>>> | | flags XYZ and/or authconfig command | > >>>>> | | ABC | > >>>>> -------------------------------------------------------------------------- > >>>>> > >>>>> Can something like this be added to wiki and corresponding tickets to provide a testable > >>>>> replacements for XYZ above be filed in trac? > >>>> I've added more, including three tickets to cover specific > >>>> configurations. > >>>> > >>>> Unfortunately, we have limits in multiple search bases approach by > >>>> the commercial UNIX vendors since their LDAP modules do not support > >>>> multiple search bases. For all of those platforms there is PADL pam_ldap > >>>> available which can be used for the same purpose. > >>>> > >>>> If we still want to support native pam_ldap on Solaris (which don't work > >>>> with multiple search bases), we'd have to merge LDAP trees. > >>> > >>> Alexander, in my initial proposal I said that trusted users should be > >>> put in the same tree as compat users, it was exactly to address this > >>> problem. > >>> > >>> We do not need to cause more problems by using multiple search trees > >>> IMO. > >> Ok, since I wanted to re-use slapi-nis anyway, this only means adding > >> one more config attribute to slapi-nis configuration that will ask it to > >> look into NSS in addition to the main query. > >> > >> In which order these queries should be performed? first to LDAP then NSS > >> or first to NSS then to LDAP? I guess the answer depends on specific > >> setup -- if all your users in AD, you'd like to look at them first. > > > > If we cache stuff in memory I am not sure it matters much. > > Note that AFAIK there is no option in slapi-nis to look at nss. It is > probably safe to assume that the sssd loop protection will suffice. > > This may be quite a change too, as slapi-nis won't be able to rely on > watching for MOD to update itself and instead will need to be a > general-purpose cache, or ALWAYS look up the entry (or entries) in nss > and rely on the local sssd cache to prevent performance issues. My initial proposal was to always lookup via NSS and rely on sssd fast cache to avoid costly operations, at least for individual lookups. for enumerations it will be sorta expensive, but that is fine IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York From akrivoka at redhat.com Fri May 31 16:49:28 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 31 May 2013 18:49:28 +0200 Subject: [Freeipa-devel] [PATCHES 0053-0055] Prompt for RID base if trusted domain SID / name is specified and vice versa In-Reply-To: <51A8A729.9030108@redhat.com> References: <518D06B1.1060904@redhat.com> <519109CC.5090300@redhat.com> <51A7436F.7060302@redhat.com> <51A87A96.6080404@redhat.com> <51A8A729.9030108@redhat.com> Message-ID: <51A8D498.3090901@redhat.com> On 05/31/2013 03:35 PM, Ana Krivokapic wrote: > On 05/31/2013 12:25 PM, Tomas Babej wrote: >> On 05/30/2013 02:17 PM, Ana Krivokapic wrote: >>> On 05/13/2013 05:42 PM, Tomas Babej wrote: >>>> On 05/10/2013 04:39 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> this patcheset deals with https://fedorahosted.org/freeipa/ticket/3602 >>>>> >>>>> See commit messages for details. >>>>> >>>>> Tomas >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> I noticed during further development that logic in >>>> interactive_prompt_callback did not follow the pre_callback logic precisely. >>>> >>>> Fixed patches attached. >>>> >>>> Tomas >>> Hi, >>> >>> Patches work fine. >>> >>> I would suggest incorporating a fix for ticket >>> https://fedorahosted.org/freeipa/ticket/3634 into this patchset. The issue >>> from ticket #3634 is closely connected to this one, and with the >>> introduction of prompt_param() functionality, including a fix for it would >>> require minimal effort. You can look at my patch >>> (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00297.html) and >>> if you think the approach is right, adjust accordingly and incorporate it in >>> your patchset. >>> >>> Other (minor) comments: >>> >>> * The last change in ipalib/plugins/idrange.py seems like you wanted to fix >>> the fact that the lines weren't properly indented (they weren't multiples of >>> 4). However, you also need to fix the previous line (raise ...). >>> * There are a lot of unused imports in ipalib/frontend.py. Since you are >>> already touching imports in your patch, could you clean up the unused >>> imports as well. >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> I addressed the minor issues. Updated patches are attached. >> >> Regarding your patch, I agree. I sent a reply to its thread. >> >> Tomas > ACK > After a second look, you seem to have removed to many imports from ipalib/frontend.py and now the doctests are failing. The import of `Password` from `parameters` should be put back in. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Fri May 31 17:35:53 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 31 May 2013 19:35:53 +0200 Subject: [Freeipa-devel] [PATCH 0030] Require rid-base and secondary-rid-base options in idrange-add when trust exists In-Reply-To: <51A4C406.5000206@redhat.com> References: <51A4C406.5000206@redhat.com> Message-ID: <51A8DF79.9070700@redhat.com> On 05/28/2013 04:49 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses https://fedorahosted.org/freeipa/ticket/3634 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This updated patch applies on top of tbabej's patches 0053-0055. As suggested by Tom?s( (https://www.redhat.com/archives/freeipa-devel/2013-May/msg00352.html), I refactored support of "mock" LDAP objects to tests/util, and modified test_range_plugin and test_cli to use it. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0030-02-Require-rid-base-and-secondary-rid-base-options-in-i.patch Type: text/x-patch Size: 12779 bytes Desc: not available URL: From nicmac at gmail.com Fri May 31 20:47:09 2013 From: nicmac at gmail.com (Nicholas MacKenzie) Date: Fri, 31 May 2013 16:47:09 -0400 Subject: [Freeipa-devel] IPAv3.1 and Redhat 6.4 Message-ID: Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any rumors surrounding release dates? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri May 31 21:13:19 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 31 May 2013 17:13:19 -0400 Subject: [Freeipa-devel] IPAv3.1 and Redhat 6.4 In-Reply-To: References: Message-ID: <51A9126F.5090005@redhat.com> On 05/31/2013 04:47 PM, Nicholas MacKenzie wrote: > Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any rumors > surrounding release dates? > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel 6.4 has SSSD 1.9 and IPA 3.0 There are no plans to port 3.1+ server versions to RHEL6.x. There are considerations to backport SSSD and ipa-client to 6.x. Version is yet TBD but for 6.5 we are focusing on porting selcted fixes for SSSD 1.9 and IPA 3.0. What functionality you are looking for? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Fri May 31 23:27:08 2013 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 31 May 2013 16:27:08 -0700 Subject: [Freeipa-devel] IPAv3.1 and Redhat 6.4 In-Reply-To: <51A9126F.5090005@redhat.com> References: <51A9126F.5090005@redhat.com> Message-ID: On Fri, May 31, 2013 at 2:13 PM, Dmitri Pal wrote: > On 05/31/2013 04:47 PM, Nicholas MacKenzie wrote: > > Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any rumors > surrounding release dates? > > > _______________________________________________ > Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel > > 6.4 has SSSD 1.9 and IPA 3.0 > There are no plans to port 3.1+ server versions to RHEL6.x. > There are considerations to backport SSSD and ipa-client to 6.x. Version > is yet TBD but for 6.5 we are focusing on porting selcted fixes for SSSD > 1.9 and IPA 3.0. > With this being the case, will there be an upgrade path to RHEL 7.x and IPA 3.2.x? Since upgrade from RHEL 6.x to 7.x will probably not work, would replication to a higher version work or maybe the backup that Rob was working on? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: